Комментарии

Спасибо познавательно.

Долго искал решение наподобие Django, на Nodejs, но так и не нашел, пробовал разные поделки типа keystone, feather JS и т.д, потом увлёкся Python и сейчас осваиваю Django, в целом нравится, пока делаю для себя блог, в дальнейшем есть планы на интернет магазин, да знаю что все уже давно есть на PHP, но PHP не хочется учить. Было бы неплохо увидеть статью, про то что используют разработчики при разработке различных проектов на Django, какие библиотеки есть для него и т.д.

вот тут то я и вижу основную проблему. очевидность это антоним TDD, так как если вы кейс тестами покрыли — то он для вас очевиден и предсказуем.

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

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

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

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

На словах оно всегда красиво, а на деле никакое tdd не спасет от рандомных или совсем неочевидных регрессий.

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

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

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

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

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

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

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

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

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

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

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

Регистрируйте домен в зоне com у нормального зарубежного регистратора и не будете иметь проблем

Озеро данных

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

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

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

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

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

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

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

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

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

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

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

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

Я не могу сказать, что раньше сталкивался с термином «большое хранилище», но, отвечая на первоначальный вопрос, нет, data lake и big data — это не одно и то же, хотя, честно говоря, ими часто пользуются, и определения различаются в зависимости от того, кого вы спрашиваете, но я попробую попробовать:
Большие данные

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

Иногда это может быть вопросом самого объема данных: как только вы достигаете сотен терабайт или петабайт, ваши старые добрые базы данных RDBMS, как правило, отказываются работать, и мы вынуждены распределять наши данные по множеству дисков, а не только по одному большому. И на этих объемах мы захотим распараллелить наши рабочие нагрузки, что приведет к созданию таких вещей, как базы данных MPP, экосистема Hadoop и обработка на основе DAG.

Однако сам по себе объем не говорит всей истории. Популярное определение больших данных описывается так называемыми «4 Против»: объем, разнообразие, скорость и достоверность. В двух словах:

Объем — как упоминалось выше, относится к трудностям, вызванным размером данных

Разнообразие — относится к внутренней сложности работы с разрозненными типами данных; некоторые из ваших данных будут структурированными (например, таблицы данных SQL), в то время как другие данные могут быть либо полуструктурированными (XML-документы), либо неструктурированными (файлы изображений raw), и технология для работы с этим разнообразием нетривиальна

Скорость — относится к скорости, с которой могут генерироваться новые данные; при сборе событий реального времени, таких как данные Интернета вещей, или веб-трафик, или финансовые транзакции, или изменения в базе данных, или что-либо еще, что происходит в режиме реального времени, «скорость» поступления данных в ваши системы (а во многих случаях и из них) может легко превысить возможности традиционных технологий баз данных, что требует какой-либо масштабируемой шины сообщений (Kafka) и, возможно, сложной инфраструктуры обработки событий (такой как Spark Streaming или Apache Flink).

Достоверность — последняя буква «V» обозначает дополнительную сложность работы с данными, которые часто поступают из источников, находящихся вне вашего контроля, и которые могут содержать данные, которые являются недействительными, ошибочными, вредоносными, искаженными или все вышеперечисленное. Это увеличивает потребность в проверке достоверности данных, проверке качества данных, нормализации данных и многом другом.

В этом определении «большие данные» — это данные, которые из-за особых проблем, связанных с 4 V, непригодны для обработки с помощью традиционных технологий баз данных; в то время как «инструменты для обработки больших данных» — это инструменты, специально разработанные для решения этих проблем.

Озеро данных и Большие данные — это одно и то же?

Я пытаюсь все понять, есть ли реальная разница между data lake и Big data, если вы проверите концепции, оба похожи на большое хранилище, которое сохраняет информацию до тех пор, пока она не станет необходимой, итак, когда мы можем сказать, что используем big data или data lake?

Очень удобный интерфейс, Журнал записи продуман до мелочей. Большое количество инструментов, которые позволяют автоматизировать все задачи, оптимизировать работу специалистов и администраторов, и работать с клиентами. Особенно нравится, что мы можем работать с активацией “уснушек” или точечно отправлять специальные акции, не создавая отдельных списков в эксель или в журналах. В системе DST Мед Центр всё на автомате, постоянные обновления и они бесплатны, что не может не подкупать. Платформа постоянно развивается и обновляется. Если есть вопросы, ребята из техподдержки всегда очень объемно и качественно консультируют, скидывают все необходимые ссылки на Базу знаний (в ней, если поискать, есть ответы на все наши вопросы) Все наши врачи, администраторы, и я, очень рады, что мы остановили свой выбор на DST Мед Центр. По цене, качеству и предложенному функционалу на высоте, доступны и для небольших клиник, как наша. Здорово, что реализовали интеграцию с Rrnova. Однозначно рекомендую!

Вы можете создать такой контейнер. :)

О, хоспаде, куда катиться мир!?
В современном мире чтобы захостить одну страничку с одной формой надо поднять целый датацентр? Я уже скучаю по моему старому прокту, где весь вебсервер представлял собой ядро линуха и Busybox в качестве основной системы + веб сервер и sh скрипты в качестве CGI бакэнда…

Ну вообще то это на подобие надстройки над LXC, который автоматизирует поднятие контейнера его настройку, связь контейнеров и storage… Можно хранить контейнеры в гите в виде скриптов build для docker и после с лёгкостью поднимать это окружение на серверах. Но в действительности я бы это сравнил с system.d

Я так понимаю докер — нечто среднее между механизмом Chroot и OpenVZ контейнерами?

Если рассмотреть три наиболее распространенных и перспективных протокола для идентификации пользователей: OAuth 2.0, OpenID Connect, WebAuthn то:

OAuth 2.0 — используется для регистрации и входа пользователей на сайты с помощью соцсетей. А также для получения данных пользователей из соцсетей.

OpenID Connect — используется для аутентификации пользователей и позволят предоставить им доступ к своим закрытым данным на сайтах. Также OpenID Connect служит для реализации сложных сценариев взаимодействия в корпоративных SSO системах.

WebAuthn — используется для добавления на сайт возможности аутентификации с помощью внешнего физического ключа или отпечатка пальца.

Ну и сами выводы:

Очевидно, что современный сайт должен реализовать все возможные способы регистрации и авторизации, чтобы у пользователя был осознанный выбор.

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

Имеет смысл отдать аутентификацию пользователей облачным платформам, таким как Facebook или Google, т.к. в них работают лучшие специалисты по безопасности, которые могут предусмотреть все нюансы безопасности.

Предлагаю с оптимизмом смотреть в будущее, т.к. протокол WebAuthn — реальный шанс избавится от парольного ада нашего времени!

Ключевое отличие OAuth 2.0 от OAuth 1.0:+ простота. В новой версии нет громоздких схем подписи, сокращено количество запросов, необходимых для авторизации (Этот вариант требует поднятия в приложении окна браузера, но не требует серверной части и дополнительного вызова сервер-сервер для обмена authorization code на access token). — Протокол OAuth 2.0 обратно не совместим с протоколом OAuth 1.0 — OAuth 2.0 — развивающийся стандарт.

Спасибо за статью, а если простым языком чтоб объяснить не разработчику — чем все же отличается oauth 1 0 от 2 0 можете сказать?