В свете исследования "Веб-разработчики пишут небезопасный код по умолчанию" мне подумалось, что именно так может звучать один из базовых вопросов на собеседовании с точки зрения проверки знания web-разработчика от уровня Junior до Senior.

Тема с одной стороны в общем-то простая, а с другой - многогранная. Можно сделать “на коленке”, а можно и “по-взрослому” -  зависит от знаний конкретного девелопера и технического задания. Ну и не привязывается к конкретному языку. Что nodejs, что .net, что PHP - на ответы это не влияет. Ну и отлично же! Давайте попробуем.

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

Как бы вы ответили на конкретный вопрос? Попробуйте проверить себя и потратить пару минут на обдумывание прежде чем читать ответ.

Восклицательным знаком ⚠ помечены вопросы, на которых можно "засыпаться" и оставить плохое впечатление о себе у интервьюера. Так же я позволил себе добавить еще пункты, которые подразумевают "Регистрацию", но по касательной. Многие ответы обрамил ссылками, которые помогут разобраться чуть глубже в конкретном вопросе, думаю будет полезно.

Итак, за вёсла!

Вступление

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

В качестве прикладного дополнения к рассуждениям мы разработали несколько Proof of Concept, сопроводили их разработку краткими пояснениями и приложили исходный код PoC.

Перевод эссе профессора Фримана Дж. Дайсона, в котором он пытается объяснить причину контринтуитивности таких понятий как "поле".

Если вы хотя бы однажды разрабатывали большую систему на Java и сопровождали её, то, наверняка, сталкивались с неудобствами настройки тех или иных процессов в системе. 

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

Каждый раз менять всё это в коде, пересобирать и перенакатывать на реал — не комильфо.

Естественно все эти параметры нужно выносить в файлы конфигов и считывать их оттуда — все так делают.

В Java из коробки для этого есть некий Properties. Но пользоваться им крайне неудобно. Во-первых, UTF-8 там не работают, во-вторых — если вы поменяли какой-нибудь параметр в конфиге, то чтобы новое значение попало в систему — требуется перезапуск приложения. А если вы не хотите его перезапускать, или это невозможно в 11 утра — час пиковой нагрузки. И отложить на потом не вариант — нужно срочно. Что делать? Нужно чтобы конфиги перечитывались на «горячую», т. е. без перезапуска системы.

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

И вот ещё что: представьте у вас крупная система в которой уже накопилось около тридцати конфигурационных файлов, и в каждом по десятку параметров. И вам нужно накатить новую инстанцию. Как вы будете настраивать эти конфиги? Создавать каждый вручную? В каждом прописывать имена параметров и их значения, вспоминая что каждый из них значит? А если забыли? А есть документация? А эта документация актуальная? А если вы ошибётесь в одной буковке параметра — позволит ли вам система при старте сразу объяснить что не так? Или она свалится в час ночи, когда вы крепко спите? Вам придётся просыпаться, включать как-то мозг и разбираться во всей этой истории…

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

Введение

Во время работы над задачами машинного обучения с онлайн-данными есть необходимость собирать различные сущности в одну для дальнейшего анализа и оценки. Процесс сбора должен быть удобным и быстрым. А также часто должен предусматривать бесшовный переход от процесса разработки к промышленному использованию без дополнительных усилий и рутинной работы. Для решения этой проблемы можно воспользоваться подходом с использованием Feature Store. Этот подход со многими деталями описан вот здесь: Meet Michelangelo: Uber’s Machine Learning Platform. В этой статье описывается интерпретация указанного решения для управления признаками в виде прототипа.

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

Векторные языки мало известны широкому кругу программистов и занимают узкую нишу обработки данных в финансах, статистике и прикладной математике. Хотя сам векторный подход (или, точнее, программирование с помощью массивов) распространен гораздо шире, чем может показаться. Он реализован в известных библиотеках (NumPy), популярном языке статистиков R, математических пакетах (MATLAB), даже в современных языках программирования (Julia). Однако, возможность умножить матрицу на вектор простым выражением (A*v) – это всего лишь вершина айсберга возможностей, которыми обладают полноценные векторные языки. При том, что эти языки не так сильно отличаются от обычных, как может показаться на первый взгляд, они заставляют программиста мыслить совершенно в других категориях и реализовывать алгоритмы способами, которые никогда не придут в голову человеку, привыкшему к Java или даже Haskell. Их характерной чертой, например, является выворачивание наизнанку циклов – вместо того, чтобы спускаться по вложенным циклам вниз к простым значениям и там использовать их в функциях, вы оперируете сложными объектами целиком, давая указания языку, какие именно части этих объектов и как именно вы хотите использовать и так много раз в одном выражении. В этой статье я хочу познакомить вас с этим оригинальным подходом к реализации алгоритмов.

Чуть больше года назад я столкнулся с тем, что на внутреннем проекте совсем не айтишной компании вырос целый отдел веб-разработки, которым мне и довелось руководить. Рабочий процесс вроде как устаканился и всех устраивал, но оставались проблемы:

• Проверка каждой ветки проходила локально. Приходилось откатывать базу от изменений с предыдущей проверки, билдить фронт. Когда несколько разработчиков вот-вот закончат работы и осталось проверить каждую по мелочи — это превращалось в ад;
• Различались окружения на проде и между разработчиками, что приводило к ошибкам: “у меня всё работает”.

Внутренний перфекционист жаждал организовать всё правильно. Делюсь результатами поисков ответа на вопрос: «а как, собственно, “правильно”»?

Мы добились

• Легкого и быстрого деплоя в production (ради эксперимента выводили каждый день две недели подряд);
• Гарантию защищённости от ошибок из-за различий в окружении приложения;
• Можем организовать эффективное взаимодействие с заказчиком:
  
  • демонстрировать каждую feature-ветку;
  • давать гостевой доступ для создания задач и наблюдения над ходом работ.

Данная статья будет полезна, если вы:

• начинающая IT-компания или в первый раз столкнулись с работой в команде над большим проектом;
• хотите обновить свой устаревший процесс разработки (workflow);
• ищете лучшие практики и хотите посмотреть, как у других;
• часто натыкаетесь на статьи про DevOps, CI/CD, облака и хотите, чтобы у вас одним нажатием кнопки создавались тестовые окружения, а очередное обновление прода не было рулеткой.

Под катом вы найдёте

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

В данном руководстве мы рассмотрим подключение и настройку системы логирования в Spring Boot проекте и отправку логов в ELK с помощью Filebeat. Руководство предназначено для разработчиков начального уровня.

Логирование и зачем оно нужно

Когда я только начинал работать программистом один мой старший коллега любил повторять: "Если у тебя нет логов, то у тебя нет ничего". Действительно, столкнувшись с первым же багом на тестовых стендах или хуже того в промышленной среде, первое что нам будет нужно это логи приложения и удобный доступ к ним. За сами логи отвечают разработчики приложения, которые должны обеспечить логирование поведения системы таким образом, чтобы в любой момент можно было понять что происходит с системой и главное что с ней не так.

Следующий вопрос — это удобство доступа к логам. Обычно при локальном тестировании мы видим лог в консоли приложения, а на тестовым стенде — в специальных лог файлах на сервере. Удобно ли и безопасно ли каждый раз подключаться к стенду, искать нужную директорию и читать файлы логов оттуда? Практика показывает что нет и это вторая проблема которую призван решить ряд продуктов, обеспечивающих удобный доступ к логам и поиск в них важной информации. Сегодня мы очень кратко поговорим о одной из групп таких продуктов, так называемом стеке ELK (Elasticsearch — Logstash — Kibana) и более подробно о Filebeat — Open source продукте, обеспечивающем удобный механизм доставки логов до ELK.

CREATE TABLE hier(
  id
    integer
      PRIMARY KEY
, pid
    integer
      REFERENCES hier
, data
    json
);

CREATE INDEX ON hier(pid); -- не забываем, что FK не подразумевает автосоздание индекса, в отличие от PK