Сергей Шевченко ^{3 месяца назад}

MVC — это шаблон программирования, который позволяет разделить логику приложения на три части:

Model (модель) — получает данные от контроллера, выполняет необходимые операции и передаёт их виду.

View (вид или представление) — получает данные от модели и выводит их для пользователя.

Controller (контроллер) — обрабатывает действия пользователя, проверяет полученные данные и передаёт их модели.

Этот паттерн разработки нужен для того, чтобы разделить логические части приложения и создавать их отдельно друг от друга. То есть писать независимые блоки кода, которые можно как угодно менять, не затрагивая другие.

Наверно три основные библиотеки, которые использую вместе с Django, это Celery для асинхронных тасков, Django Rest Framework для REST API и Python Social Auth для интеграции с соцсетями.

Рефакторинг через TDD помогает обезопасить себя от неочевидных ошибок, здесь также очень сильно зависит от того, насколько правильно разработчик понимает текущую бизнес-логику. Если тесты хорошо провалидированы, то промахов не возникает. Отмечу, что регрессионное тестирование всё равно проводится после написания тестов.

Касательно целесообразности, то конечно, проводить рефакторинг ради рефакторинга — сомнительная идея. Если код работает и он потенциально не расширяется, а самое важное, что это не является часто изменяемой функцией приложения и не приносит сильных неудобств, то можно оставить такой код до лучших времен.

Все просто: рефакторинг кода является необходимой частью разработки программного обеспечения, а также процессом, который следует не только не бояться, но и приветствовать. Хотя на первый взгляд рефакторинг может показаться сложным и довольно затратным по времени, но именно он является ключевым инструментом для поддержания качества кода и обеспечения его эффективности и гибкости в долгосрочной перспективе.

Важно понимать, что рефакторинг это еще и непрерывный процесс, который должен быть внедрен в процесс разработки. Регулярное обновление и улучшение кода помогает снизить технический долг, упростить сопровождение кода и повысить эффективность работы команды.

И главное — не бойтесь рефакторинга, ведь он помогает создавать качественные и гибкие программные решения.

Вот несколько рекомендаций, которые помогут выбрать доменное имя:

1. Длина доменного имени. Чем короче домен, тем лучше. Лучше, если адрес сайта будет состоять из 10–12 символов.
2. Правильные сокращения. Выбирайте логичные сокращения и избегайте неочевидных, а также сленга или других слов, которые будут непонятны основной аудитории.
3. Использование ключевых и ассоциативных слов. Этот вариант хорош по нескольким причинам:
это серьёзное преимущество при продвижении в поисковых системах;
такие домены проще запомнить.
4. Подбор правильных букв. Если вы хотите видеть в качестве адреса своего сайта какое-то слово или словосочетание на латинице, то подобрать доменное имя будет несложно.
5. Не используйте цифры и дефисы. Такие домены хуже воспринимаются пользователями и поисковыми системами.
6. Использование дополнительных слов. Иногда подобрать доменное имя бывает непросто из-за того, что желаемый домен уже занят. В этом случае вам помогут дополнительные слова.
7. Уникальность доменного имени. Хорошим решением будет выбрать уникальное доменное имя, непохожее на названия других компаний.
8. Не смешивайте слова из разных языков. Все домены со смешением плохо звучат, плохо запоминаются и негативно воспринимаются поисковыми системами.
9. Региональные зоны в доменном имени. Выбирать их следует в соответствии с назначением сайта и сферой деятельности компании.

Сайты на доменах Ру/Рф вполне могут стоять выше в выдаче Гугла, чем «крутые» доткомы. Если запрос идет из России, то никакой разницы нет, какая там доменная зона. Крайне не советую тратить деньги на импортные домены и сеошников, которые разводят на их регистрацию «ради продвижения».

Три базовых правила:

Подбирайте название сайта и доменную зону под ваш бренд. Желательно, чтобы название компании было включено в имя.

Ключевые качества — благозвучность, краткость, легкозапоминаемость. Чем короче адрес сайта и чем меньше в нем дефисов и прочих усложнений — тем клиентам будет проще вас найти.

Сразу регистрируйте имена в разных доменных зонах, настраивайте редирект на один основной домен.

Озеро данных

Напротив, озеро данных обычно используется как термин для описания определенного типа файла или уровня хранения больших двоичных объектов, который позволяет хранить практически неограниченные объемы структурированных и неструктурированных данных по мере необходимости в архитектуре больших данных.

Некоторые компании будут использовать термин «Озеро данных» для обозначения не только уровня хранения, но и всех связанных с ним инструментов, от приема данных, ETL, анализа, машинного обучения, аналитики, вплоть до стеков хранилищ данных и, возможно, даже BI и инструментов визуализации. Однако, как архитектор больших данных, я нахожу такое использование термина запутанным и предпочитаю говорить об озере данных и инструментах вокруг него как об отдельных компонентах с отдельными возможностями и обязанностями. Таким образом, ответственность озера данных заключается в том, чтобы быть центральным хранилищем с высокой надежностью для любого типа данных, которые вы, возможно, захотите сохранить в состоянии покоя.

По мнению большинства, термин «озеро данных» был введен Джеймсом Диксоном, основателем и техническим директором Pentaho, который описывает его следующим образом:

“Если вы представляете datamart как хранилище бутилированной воды – очищенной, упакованной и структурированной для удобства потребления, – то озеро данных — это большой водоем в более естественном состоянии. Содержимое озера данных поступает из источника для заполнения озера, и различные пользователи озера могут приходить, чтобы исследовать его, нырять в воду или брать пробы ”.

Amazon Web Services определяет это на своей странице «Что такое озеро данных»:

Озеро данных — это централизованное хранилище, которое позволяет вам хранить все ваши структурированные и неструктурированные данные в любом масштабе. Вы можете хранить свои данные как есть, без необходимости их предварительного структурирования, и запускать различные виды аналитики — от информационных панелей и визуализаций до обработки больших объемов данных, аналитики в реальном времени и машинного обучения для принятия более эффективных решений.

Из Википедии:

Озеро данных — это система или хранилище данных, хранящихся в их естественном формате, обычно в виде больших двоичных объектов или файлов. Озеро данных обычно представляет собой единое хранилище всех корпоративных данных, включая необработанные копии исходных системных данных и преобразованные данные, используемые для таких задач, как отчетность, визуализация, аналитика и машинное обучение.

И, наконец, Gartner:

Озеро данных — это набор экземпляров хранения различных ресурсов данных, дополнительных к исходным источникам данных. Эти ресурсы хранятся в почти точной копии исходного формата. Цель озера данных — предоставить неочищенный вид данных только самым высококвалифицированным аналитикам, помочь им изучить свои методы уточнения данных и анализа независимо от каких-либо компромиссов с системой записей, которые могут существовать в традиционном аналитическом хранилище данных (таком как витрина данных или хранилище данных).

В локальных кластерах озеро данных обычно относится к основному хранилищу в кластере в распределенной файловой системе, обычно HDFS, хотя существуют и другие файловые системы, такие как GFS, используемая в Google, или файловая система MapR в кластерах MapR.

В облаке озера данных обычно хранятся не в кластерах, поскольку постоянно поддерживать работу кластера экономически невыгодно, а в надежных облачных хранилищах, таких как Amazon S3, Azure ADLS или Google Cloud Storage. Затем вычислительные кластеры можно запускать по запросу и беспрепятственно подключать к облачному хранилищу для выполнения преобразований, машинного обучения, аналитических заданий и т.д.

Если в кратце то расскажу свой опыт по работе с CRM системами:
IQ300 — крутая CRM но очень сложная по своей сути.

Битрикс 24 — хороша для продаж, но главный минус в том что защита безопасности в настройках групп пользователей полное дно, его там просто нет, по факту курьер (если он продвинутый пользователь Битрикса) может видеть всех сотрудников вплоть до директора.

Мегаплан — хороший вариант, но маловато функционалки

AmoCRM — это просто чистый хайп, не стал бы ее устанавливать

DST CRM — не подходит для конкретных продаж т.к. функционал больше сделан под управление проектами и работать с услугами, вот в услугах и управлении компанией и сотрудниками самое то

Удивительно, что упомянули Nagios, но забыли про Prometheus

Поисковики борются за уникальность контента в сети, и борьба эта, должен сказать, ведется довольно жестко. Сайты-копии полностью или частично повторяющие контент «склеиваются», и в результате в поисковой выдаче мы видим только один из сайтов. С точки зрения борьбы с пиратством – довольно правильное решение, но и вебмастеру надо держать ухо востро.

Изначально приобретая домен и подключая к нему сайт, мы уже имеем два зеркала: domen.ru и www.domen.ru. Собственно, ничего страшного, но когда страницы нашего сайта начинают отрастать ссылочной массой, мы не можем контролировать — какой именно адрес указан в ссылке. В результате получаем, что примерно половина ссылок ведет на domen.ru, а половина на www.domen.ru. Яндекс, считая эти два адреса дублями, склеивает их в один – половину ссылок мы просто теряем!

Чтобы избежать данной проблемы, необходимо указать главное зеркало сайта – желаемый урл, который и будет виден в результатах выдачи. Сделать это можно несколькими способами: записать соответствующее правило директиве host в robots.txt, или настроить серверный редирект (лучше сразу 301, 302 предпочтительнее если необходимо «подклеить» неуникальные страницы на одном сайте) со страниц одного сайта на другой. Первый способ практичнее и предпочтительнее, если мы имеем дело с одним доменом и необходимо избавиться от www (или, наоборот, оставить только адрес с ними). Но, когда мы переносим сайт на новый домен, то придется использовать именно редирект, причем, чтобы не потерять позиции в выдаче, его придется настраивать для каждой страницы. Дело весьма хлопотное и трудоемкое, особенно при переезде больших проектов.

Чтобы помочь роботу быстрее произвести переиндексацию на главное зеркало при его смене в Яндекс Вебмастере имеется опция: Настройка индексирования → Главное зеркало. Где можно указать предпочтительное имя, вот только это не панацея и редирект использовать все равно придется.

Поисковики борются за уникальность контента в сети, и борьба эта, должен сказать, ведется довольно жестко. Сайты-копии полностью или частично повторяющие контент «склеиваются», и в результате в поисковой выдаче мы видим только один из сайтов. С точки зрения борьбы с пиратством – довольно правильное решение, но и вебмастеру надо держать ухо востро.

Изначально приобретая домен и подключая к нему сайт, мы уже имеем два зеркала: domen.ru и www.domen.ru. Собственно, ничего страшного, но когда страницы нашего сайта начинают отрастать ссылочной массой, мы не можем контролировать — какой именно адрес указан в ссылке. В результате получаем, что примерно половина ссылок ведет на domen.ru, а половина на www.domen.ru. Яндекс, считая эти два адреса дублями, склеивает их в один – половину ссылок мы просто теряем!

Чтобы избежать данной проблемы, необходимо указать главное зеркало сайта – желаемый урл, который и будет виден в результатах выдачи. Сделать это можно несколькими способами: записать соответствующее правило директиве host в robots.txt, или настроить серверный редирект (лучше сразу 301, 302 предпочтительнее если необходимо «подклеить» неуникальные страницы на одном сайте) со страниц одного сайта на другой. Первый способ практичнее и предпочтительнее, если мы имеем дело с одним доменом и необходимо избавиться от www (или, наоборот, оставить только адрес с ними). Но, когда мы переносим сайт на новый домен, то придется использовать именно редирект, причем, чтобы не потерять позиции в выдаче, его придется настраивать для каждой страницы. Дело весьма хлопотное и трудоемкое, особенно при переезде больших проектов.

Чтобы помочь роботу быстрее произвести переиндексацию на главное зеркало при его смене в Яндекс Вебмастере имеется опция: Настройка индексирования → Главное зеркало. Где можно указать предпочтительное имя, вот только это не панацея и редирект использовать все равно придется.

Вот о бритве Оккама в ICANN, похоже, не слыхали, здесь вы правы :)

IANA придумала. А то, что изначально домены только для Штатов — так, не поверите, Internet и DNS вообще в США были придуманы. Так уж исторически сложилось.

Выделение тематических доменов полезно хотя бы потому, что по домену orange.mobi можно сразу понять, что это — международный оператор мобильной связи Orange, а orange.crimea.ua — его крымское представительство.

.Train, .doglovers сейчас нет. Если вы считаете, что они необходимы, предложите, отправьте заявку.

Вообще, конечно, система немного неоднозначная, но она есть и она работает.

Что такое GitHub и чем он отличается от Git

GitHub — это облачная платформа для хостинга IT-проектов и совместной разработки, под капотом которой находится популярная система контроля версий Git, а также полноценная социальная сеть для разработчиков.

Здесь можно найти кучу open-source-проектов на разных языках и поучаствовать в них, разместить своё портфолио с примерами кода, чтобы приложить ссылку к резюме, подглядывать в открытых проектах интересные архитектурные решения, смотреть, как опытные разработчики пишут код, и скачивать огромное количество полезных в разработке и бесплатных инструментов для разработки. Кстати, некоторые умельцы умудряются собирать в GitHub целые библиотеки — книг и статей, а не программистские либы :)

И да, если вы недовольны какими-то фичами в любимой открытой программе и она выложена на GitHub, вы всегда можете прийти и поругаться в комментариях к проекту :) А лучше всего — оформить issue (мы расскажем, что это) и самостоятельно пофиксить проблему на радость всем пользователям. Не забывайте и благодарить авторов классных открытых проектов — донатами и просто тёплыми словами. Им будет очень приятно.

Придя практически в любую IT-компанию, вы столкнётесь с тем, что код где-то хранится — и в подавляющем большинстве случаев этим «где-то» будет именно GitHub. У GitHub есть довольно известный конкурент — GitLab, он тоже основан на Git, но это разные платформы разных компаний, хотя их функциональность очень похожа.

А ещё не стоит путать GitHub и Git. GitHub — лишь одна из реализаций системы контроля версий Git (только взгляните на полный список Git-клиентов с графическим интерфейсом), в которую добавлено много удобных инструментов и возможностей (те же комментарии, issues, гиперссылки, форматированный текст и тому подобное). Помните, GitHub можно использовать и без знания Git (обратное тоже верно).

Ну как, звучит круто? Тогда приступайте к нашему гайду о том, как пользоваться GitHub, чтобы во всём разобраться и вообще понять, нужен ли он вам прямо сейчас.

Придя практически в любую IT-компанию, вы столкнётесь с тем, что код где-то хранится — и в подавляющем большинстве случаев этим «где-то» будет именно GitHub. У GitHub есть довольно известный конкурент — GitLab, он тоже основан на Git, но это разные платформы разных компаний, хотя их функциональность очень похожа.

А ещё не стоит путать GitHub и Git. GitHub — лишь одна из реализаций системы контроля версий Git (только взгляните на полный список Git-клиентов с графическим интерфейсом), в которую добавлено много удобных инструментов и возможностей (те же комментарии, issues, гиперссылки, форматированный текст и тому подобное). Помните, GitHub можно использовать и без знания Git (обратное тоже верно).

Я рассматривал Docker Swarm когда выбирал систему управления контейнерами. Выбор между Kubernetes и Docker Swarm сводится к необходимому функционалу. Это связано с тем, что изначальные задачи у них различаются.

Docker Swarm — способ использовать несколько машин как единую виртуальную среду для запуска контейнеров.

Kubernetes же позволяет не только запустить несколько машин, но и занимается балансировкой нагрузки, контролем запущенности и обновлением контейнеров (есть функция rolling-update позволяющая без простоя обновить pod'ы внутри RC).

Морочиться стоит в случае если:

Есть необходимость регулярного безпростойного деплоя
Необходимо обеспечить высокую отказоустойчивость
Необходимо обеспечить горизонтальную масштабируемость и балансировку не прибегая к «зоопарку» ПО
Вы не боитесь использовать в продакшне ПО находящееся в стадии альфа стадии разработки

Возможно я ошибаюсь на счёт Swarm, буду благодарен за дополнительную информацию по опыту работы с ним.

Даже если «порог входа довольно простой» — то такой порог уже в абсолютно всех языках. Нужно только знать «кнопочки и визуальный эффект» от первых этапов программирования.
Но для меня JavaScript стал слишком тошнотворным.
Если раньше все кто умел и не умел прикручивал библиотеки и готовые простые решения для сайтов типа JQuery, то написание теперь собственного решения требует множество знаний, которые не описываются в учебниках «выше операторов и работы с prototype». А читабельность такого кода на JS — вообще отвратительна… она называется «мы задумали, а вы как хотите — разгрёбывайте».

Чего только стоит самостоятельная попытка изучения, так чтобы проще и доходчивей:
НУ как вообще нормальному человеку изучить разделы 6,7 и 9 из списка этого сайта: learn.javascript.ru, так чтобы и глазом не моргнув суметь рассказать, что сам то понял, если понял…

Поэтому спрос на JS будет! и 1 подходящий к 10-ти неподходящих представителей, и даже потом 1 к 100..., но чтобы его одолеть в том виде какой он сейчас — я не гений.
Я кое-как выучил скрытую функцию, и кое как применял на протяжении 2х лет,… постоянно путаюсь в чтении передачи в функцию и из неё, превращение функции в классы с методами, из-за отличаемого синтаксиса от всех «разумных классических» языков. Меня «типает от JQuery.Deferred… Promise», из-за слабого преподавания на сайтах… Т.е. я постоянно забываю применение….этот весь идиотизм в JS.

Дополнительные ссылки появляются, если сайт получил достаточный уровень уважения от поисковой системы (возраст, качество внешних ссылок, релевантность страниц сайту, других параметров, что сигнализируют о качестве сайта).

Как только ПС автоматически проставит дополнительные ссылки, в панели Google Webmaster появиться возможность управлять внешними ссылками.

Это проблема всех Yii'шников, которые переходят на любой другой нормальный фрейм. И это не было бы проблемой (например, используя Laravel можно использовать подходы Symfony, Zend или какой-нибудь Spring смело, и наоборот), если бы в Yii было бы сделано что-то грамотно, но увы.