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

Шел 2021 год, русские хакеры продолжают переигрывать и уничтожать загнивающий Запад, вмешиваясь в выборы, ломая фейсбуки и пентагоны. Тем временем на Хабре выходят статьи о создании неубиваемых Kubernetes-кластеров, которые, по видимому, всех нас переживут. А кто-нибудь подумал о простых пацанах (пацанессах)??? Как быть обычному программисту, который хочет свой небольшой кластер и ламповый CI/CD с автодеплоем приложения, чтобы кенты с района не засмеяли?

Всем привет, меня зовут Алексей и я алкоголик разработчик на Python/Go в Домклик. Сегодня мы будем понижать порог входа в self-hosted Kubernetes и GitLab AutoDevops.

Эта статья является переводом материала «When to Mock».

Использование моков в модульном тестировании является спорной темой. Автор оригинала заметил, что на протяжении всей своей карьеры в программировании он сначала перешел от «моков почти для каждой зависимости» к политике «без моков», а затем к «только моки для внешних зависимостей».

Ни одна из этих практик не является достаточно хорошей. В этой статье Владимир Хориков покажет, какие зависимости следует мокать, а какие использовать как есть в тестах.

За 21 год существования в SuperJob разработали три версии реализации API для интеграций с бэкендом. Во время разработки последней они решили пересмотреть подход к версионированию. Сейчас в актуальной реализации порядка 379 эндпойнтов, более 900 моделей сущностей и 11 поддерживаемых мажорных версий. Когда проект развивается, вместе с ним меняются и требования к API, а значит неизбежно нарушение обратной совместимости.

Опытом решения этой проблемы поделился Антон Золотилин из SuperJob. Вы увидите самые распространенные решения проблемы версионирования web-API и подход, который реализовал у себя SuperJob. А в качестве бонуса узнаете, как это решение помогает значительно сократить рост затрат на тестирование версий с помощью Impact-анализа.

Меня зовут Леонид Талалаев, я занимаюсь разработкой внутреннего облака Одноклассников one-cloud, про которое уже рассказывали на Хабре. 

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

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

Для управления сетевым трафиком до недавнего времени мы использовали решение на основе дисциплины Hierarchical Fair Service Queue из Linux Traffic Control. Сегодня пойдет речь про проблему масштабирования в Linux Traffic Control, известную как root qdisc locking. И про то, как нам удалось ее решить, переделав управление сетевым трафиком с использованием eBPF.

• Организационные
  　Культура разработки performance-first
  　Бюджет скорости
  　Performance mantras
• Те, что можно использовать независимо от языка и его реализации
  　Смена языка или фреймворка
  　Смена алгоритма
  　Оптимизация алгоритма
  　Вынос инвариантов на уровень выше
  　Boolean short circuit
  　Досрочный выход из цикла
  　Предвычисление
• Для языков/фреймворков, в которых нет ленивых вычислений и приёма copy-on-write
  　Shortcut fusion
  　Ленивое вычисление
  　Copy-on-write
  　Оверинжиниринг
• Зависящие от железа
  　Разворачивание мелких циклов
  　Предсказание ветвлений (Branch prediction)
  　Доступ к памяти: направление итерации
  　Доступ к памяти: [i][j] vs [j][i]
• Для языков со сборкой мусора
  　Мутабельность
  　Zero memory allocation или GC-free
• Специфичные для JavaScript
  　Антипаттерн: накопление строк в массиве
  　Антипаттерн: Lodash _.defaults
  　Idle Until Urgent
  　Даунгрейд кода: ES6 → ES5
• Примеры из код-ревью

Наверно все работали с формами и понимают как это сложно. В свое время я смотрел разные решения и одним из лучших был Vuetify. Сейчас решений стало больше, но все они однотипны (я не буду брать во внимание форм генераторы). В чем то это связано с ограничением самого Vue и его философией. Но для меня все таки странно, что время идет, а прогресса нет. Странно что люди вокруг пытаются меня убедить что это нормально.

Я попытаюсь рассказать о ключевых ошибках при работе с формами и дам рекомендации как их не допустить. Также рассмотрим идеально не идеальный пример работы с формой. А выводы каждый сделает сам.

Мой уход из Яндекса, как не потерять мотивацию за полгода подготовки в FAANG и реджект в Google.

• Идентификация — это заявление о том, кем вы являетесь. В зависимости от ситуации, это может быть имя, адрес электронной почты, номер учетной записи, итд.
• Аутентификация — предоставление доказательств, что вы на самом деле есть тот, кем идентифицировались (от слова “authentic” — истинный, подлинный).
• Авторизация — проверка, что вам разрешен доступ к запрашиваемому ресурсу.

Let's Encrypt — это центр сертификации, который предоставляет бесплатные сертификаты в полностью автоматизированном процессе. Эти сертификаты выдаются по протоколу ACME. За последние два года в Интернете широко использовалась технология Let’s Encrypt — более 50% веб-сертификатов SSL / TLS теперь выдает Let’s Encrypt.

В этом посте описывается, как выдавать сертификаты Let's Encrypt для внутренних серверов.

Автор: Владимир Герасименко

В продолжение темы про торговлю ядерными технологиями Абдул Кадыр Ханом и получение Пакистаном доступа к ним. Напомню основные моменты: В 1971 году в результате вмешательства Индии в Бангладешское восстание Пакистан теряет огромные территории (нынешний Бангладеш) и перед страной маячит угроза полного поражения в грядущем противостоянии. Срочно нужен был выход в виде собственного ядерного арсенала. Эта же мысль засела в голове молодого, амбициозного и талантливого "экспата" в голландском Делфте - Абдул Кадыр-Хана. Он как раз получил профильное образование вкупе с гражданством и устроился работать в FDO – дочку франко-германского концерна URENCO, конструировавшего и производившего оборудование для атомной отрасли Европы. В итоге 30-летней деятельности Хану удалось переправить на родину необходимую документацию для создания пакистанской Бомбы, но с производственными мощностями не заладилось - и тут на сцену выходит наш сегодняшний герой - швейцарец Фридрих Тиннер, с которым Хан немало контактировал ещё во время работы в FDO. 

Фридрих, как оказалось, держал в руках все нити поставок оборудования для проектов Хана. И только в 1999 году ЦРУ, пытаясь понять откуда у Ирана технологии для обогащения урана, случайно по наводке немцев вышли на Тиннера и его сыновей. Завербовав их, американцы получили просто вал информации, который их обескуражил.

Хабру катастрофически не хватает такого формата постов как "продолжение" или "дополнение". После написания статьи зачастую появляется материал, который хотелось бы добавить к сказанному, но update'ить статью, с её сроком жизни в 1-2 дня, бессмысленно, а писать в комментариях невозможно из-за объёма материала. В то же время этого материала может быть недостаточно для новой статьи, да и, в силу того, что он сильно перекликается с предыдущей статьёй, придется либо постоянно её цитировать, либо оставлять пробелы, подразумевая, что читатель понимает о чем идет речь.

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

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

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

Говоря коротко, С работает везде. Этот язык — не просто большой динозавр, которому каким-то образом удалось дожить до наших дней. Он крайне практичен, поэтому невероятно успешен. Удивительно, но истоки С далеки от успехов. Он стал итогом десятилетий неудач, и, если бы не старания любящего программировать на каникулах школьного учителя, язык мог бы не появиться. Это история о невероятно медленных компьютерах, трёх Дэвидах и давнем наследии языка C. К старту курса о программировании на С++ делимся переводом статьи с краткой биографией Кристофера Стрэтчи.

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

Есть мануалы о том, как настроить связку NiFi и NiFi Registry со включенной аутентификацией и авторизацией. Но... используются самоподписанные серты.

Есть отдельные мануалы, как прикрутить коммерческий серт для NiFi; соответственно для NiFi Registry "кагбэ так же". Но взаимная аутентификация и авторизация будет происходить с использованием Two way SSL... а у нас же LDAP... и обеспечить потом связность сладкой парочки с использованием только внешнего каталога у вас на голой интуиции не получится.

Есть мануалы по связке с LDAP и для NiFi, и для NiFi Registry. Нооо... как и в предыдущем "но", возникают вопросы, как обойтись потом только LDAP'ом, потому что у нас же еще NiFi Cli, а он в LDAP не умеет.

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

Так вышло, что на заре моей карьеры в IT меня покусал Oracle -- тогда я ещё не знал ни одной ORM, но уже шпарил SQL и знал, насколько огромны возможности БД.

Знакомство с DjangoORM ввело меня в глубокую фрустрацию. Вместо возможностей -- хрена с два, а не составной первичный ключ или оконные функции. Специфические фичи БД проще забыть. Добивало то, что по цене нулевой гибкости мне продавали падение же производительности -- сборка ORM-запроса не бесплатная. Ну и вишенка на торте -- в дополнение к синтаксису SQL надо знать ещё и синтаксис ORM, который этот SQL сгенерирует. Недостатки, которые я купил за дополнительную когнитивную нагрузку -- вот уж где достижение индустрии. Поэтому я всерьёз считал, что без ORM проще, гибче и в разы производительнее -- ведь у вас в руках все возможности БД.

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