Пятничное развлекательное

20 лет назад на Бродвейском театре был поставлен мюзикл Avenue Q. Одной из песен в мюзикле была The Internet Is For Porn, которая завирусилась и породила целую волну клипов. Звук использован с видеорядом из World of Warcraft, Диснеевских мультиков, Гарри Поттера и многих других.

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

Текст песни и перевод тут. Подробнее про сам мюзикл, история распространения на knowyourmeme.

А вообще, правило 34.

#fun

GitOps – все ли так классно?

GitOps – подход, при котором всё состояние системы описывается в едином git-репозитории, а за синхронизацию с развёрнутой системой отвечает некий gitops-оператор. Звучит удобно.

В статье Что же такое GitOps? Его свойства и недостатки ребята из Фланта со всех сторон рассматривают этот подход.

Чтобы говорить о плюсах и минусах, хорошо бы с чем-то сравнивать. И автор сравнивает GitOps с так называемым CIOps. CIOps наиболее распространённый способ, когда деплоим просто из CI-системы. Этот способ подразумевает хранение конфигурационных файлов не в едином репозитории, а в репозиториях приложений.

В статьях, продвигающих gitops, нам говорят, что есть git-репозиторий и именно он является единственной точкой входа. Но это не совсем так. Ещё есть contaner registry – и как раз он вносит нюансы в стройную картину мира.

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

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

#skills

NULL в PostgreSQL

Очень захватывающая статья, погружающая в специфику NULL. Вроде понятно, что это такое, но всё не так просто – точнее, неопределённо.

Перечислим ряд особенностей NULL, которые нам показались интересными.

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

Следующее, что важно понимать — чем NULL не является. Пустая строка, ноль, пустой массив, массив NULL – это всё не NULL. Но есть особенность – запись, в которой все поля NULL сама является NULL. В статье автор приводит неочевидные примеры на этот счёт.

Если в каких-то бинарных операциях затаится NULL, то на выходе результат окажется тоже NULL. Но и в этом случае есть небольшие особенности.

Сравнивать что-то с NULL мало полезно — все равно получим NULL. Даже если захотим сравнить NULL и NULL. В результате получим сами знаете что.

Оказывается, имеет смысл писать "IS TRUE", а не "= TRUE". Потому что результат первой операции всегда будет TRUE или FALSE, а вот во втором варианте может выскочить неожиданный NULL.

Если хочется посчитать NULL или найти не NULL аргумент, то для этого есть специальные функции num_nulls и coalesce.

Такой привычный COUNT – и тот работает с подвохом. COUNT по конкретному полю посчитает только строки, где выражение NOT NULL, а вот COUNT(*) посчитает всё, включая NULL.

Если при сортировках хочется управлять NULL, то есть ключевое слово NULLS FIRST.

С индексами тоже интересно. Postgres использует индекс для поиска NULL значений. Если значений NULL много, плохая селективность, то лучше использовать последовательное сканирование вместо индекса. Чтобы исключить NULL из индекса можно использовать partial индекс с наложением условия IS NOT NULL. Автор дает практические советы, как найти кандидатов на такую оптимизацию.

Общий совет: если не планируете явно обрабатывать NULL, то стоит навешивать ограничение NOT NULL. Говоря об ограничениях, UNIQUE позволяет создать несколько записей со значением NULL, но в Postgres 14 появилась возможность запретить несколько NULL-записей.

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

#skills #database

Как сдвинуть гору Фудзи

Классическая книжка про подготовку к собеседованиям в Microsoft. Написана аж в 2003 году, но по факту покрывает практику собеседований примерно с 2000 по 2015 годы в компаниях из FAANG (Facebook/Meta*, Amazon, Apple, Netflix, Google/Alphabet), и примерно с 2010 по 2020 во многие российские.

О чём речь? Кто-то решил, что решение логических головоломок позволяет выявлять гениальных разработчиков, и такой формат собеседования ушёл в народ. И на собеседованиях стали давать логические задачи уровня "почему люки круглые", "за сколько взвешиваний можно найти одну из восьми фальшивых монет" и прочие крайне релевантные вопросы для middle python developer.

К великому удовольствию, эту практику признали порочной и почти повсеместно от неё отказались. Умение решать логические задачки говорит только об умении решать логические задачки. Но подобные задачи всё ещё можно встретить на собеседовании. Кроме того, книга Как сдвинуть гору Фудзи не только о логических задачках, но и о правильном подходе к построению ответа на собеседовании. Эта часть совершенно не устарела, поэтому рекомендуем книгу к прочтению. Кроме того, многие головоломки оттуда просто прикольные.

Рассмотрим несколько примеров. Наши ответы несколько отличаются от книги.

Вопрос 1, чисто на логику: "почему канализационные люки круглые". Тут неплохо бы показать ваше умение рассмотреть ситуацию со всех сторон:
– люки бывают квадратные, можно загуглить варианты
– круглая крышка не провалится вниз. Да, есть другие математические фигуры с таким же свойством, например, треугольник Рёло. Но круг из этих фигур требует наименьшего количества материала для производства
– человек в сечение круглый, поэтому канализационный колодец имеет форму цилиндра, поэтому крышка круглая
– круглую крышку можно катить

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

Вопрос 2. Ближе к реальной деятельности разработчика. Сколько всего бензоколонок в стране? Для ответа на этот вопрос нужно оценить число людей в стране, среднее число автомобилей на человека, среднюю частоту заправок автомобиля, среднее время заправки и так далее. Уметь оценить подобного рода величины при достаточно скудных входных данных полезно для system design, например, вспомним задачу проектирования поиска организаций по картам, где оценивалось число бизнесов в стране для определения размера базы данных.

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

Вопрос 3. Как тестировать солонку. Тут отправим вас к посту про тестирование карандаша.

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

#edu #резюме

Упрощаем жизнь руководителю

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

Ситуация. Документация проекта разбросана в разных местах, что, как мы писали, нехорошо. Что-то в confluence, что-то в вики проекта, что-то в ридми, что-то в головах разработчиков. Варианты действий
– публично ныть, что бардак
– жаловаться тимлиду, что бардак
– уволиться, потому что бардак :)
– действовать самостоятельно путём переноса документации в общее место и убеждения других разработчиков делать также. Этот вариант неплох для инициативных ребят, которые потом могут стать неплохими тимлидами сами
– прийти к руководителю и предложить хранить доку в общем месте. Предложить конкретное место с некоторым обоснованием из плюсов и минусов. Руководитель не всегда может видеть беду, разработчику виднее. Можно предложить ему style guide или какой-то набор практик для внедрения.

Руководитель будет рад таким инициативам от вас. Или нет, психология – наука не точная.

#devfm #edu

Мемоизация и каррирование в Python

Небольшая статья о полезных фичах питона. Мемоизация – это сохранение результатов предыдущих вычислений, которое можно использовать для ускорения кода. Для ускорения вычисления числа Фиббоначи автор вручную создаёт декоратор, являющийся аналогом functools.lru_cache. Это стратегия кэширования least recently used, то есть удаления самых старых данных.

Каррирование – это техника преобразования функций, которая получила своё название в честь Хаскелла Карри. Язык Haskell тоже в его честь назвали. Вместо применения функции с N аргументами мы порождаем отдельную функцию с меньшим числом аргументов. Автор показывает каррирование и частичное применение на примерах.

А мы рассмотрим свой пример. Пусть у нас есть функция оценки студентов:
def add_mark(student, mark, date)

Из неё можно породить функции

add_mark_5(student, date)
add_mark_4(student, date)
add_mark_3(student, date)

Зачем? Меньше писать кода и меньше пространства для ошибок, так как мы не даём поставить произвольную оценку

А с помощью functools.partial мы можем ещё и динамически создавать частичные функции. Зафиксируем дату.

# заменяем третий аргумент на текущую дату
add_mark_today = partial(add_mark, date=datetime.datetime.now())
# теперь дату в параметры не пишем
add_mark_today("Ivan", 5)

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

#python

Введение в logging на Python

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

Пора немного углубиться в детали логирования. Разберём модуль logging из стандартной библиотеки питона. В статье автор даёт пример лога своего проекта, подробно описывает сущность logger, после чего
– описывает уровни логирования debug-info-warning-error-critical, не забывает о методе exception, который работает как error плюс выводит информацию об исключении

– объясняет, что такое handler и разбирает некоторые варианты использования. К logger можно привязать несколько обработчиков, чтобы одновременно писать в несколько локаций. На наш взгляд, сейчас эта настройка потеряла актуальность – писать надо в стандартные потоки упакованного в докер приложения, а дальше собирать логи снаружи

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

– применяет Filter, чтобы перестать писать часть сообщений, или, наоборот, писать только определённые сообщения в лог. Бывает удобно, но на текущий момент чаще это решается снаружи путём поиска по логам

– применяет LoggerAdapter для внедрения дополнительной информации в лог-сообщение

– применяет extra для логирования сущностей или их частей, например, включения в лог текста запроса веб-сервера

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

– напоминает о наследовании логера, что позволяет упростить настройку логирования в модулях, указывая только индивидуальные настройки – общая часть будет взята из класса-родителя

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

#python

Пятничное развлекательное

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

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

#fun

Подготовка к интервью в Тинькофф

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

Посмотрим на процесс найма в Тинькофф. На странице описан общих ход ИТ-собеседований в компанию и детали по каждому из направлений — frontend, backend, мобильная разработка, SRE, машинное обучение, QA и BI-аналитика.

Ценность представляют материалы для подготовки. Например, для backend техническое собеседование состоит из трёх секций:
– секция по платформе или языку
– алгоритмы
– дизайн распределённых систем, он же system design

На странице даны ссылки на классические сайты типа leetcode / hackerrank / codeforces, ссылки на качественные курсы по алгоритмам на coursera, классические книжки: Кормен по алгоритмам и Cracking the Coding Interview. По system design даны и те ресурсы, о которых мы уже писали, и другие: Architectural Katas и "Высоконагруженные приложения" Мартина Клеппмана.

Для подготовки к SRE даны ровно те же источники. SRE – это Site Reliability Engineering, такие ребятки, которые отвечают за бесперебойную работу высоконагруженных сервисов. Такая смесь девопса, админа и разработчика, в результате чего под SRE понимают очень широкую область работы и в каждой компании свою. Несмотря на те же источники, секции несколько отличаются:
– алгоритмы
– system design
– выявление и устранение проблем. Дана архитектура и описан сбой. Цель – выявить проблему и предложить фикс
– общие технические вопросы – Linux, сети, базы данных

Для machine learning специалиста три секции:
– алгоритмы
– ML
– ML-design

Начало по литкоду и алгоритмам такое же, но дальше добавляется специфика ML. Тут платные и бесплатные книги по статистике, pattern recognition и глубокому обучению, подборка
awesome-machine-learning и сайт по deep learning от Ian Goodfellow, который создал GAN и о котором мы писали. Тут же ссылки на 4 проекта с набором вопросов к собеседованию по ML и ссылки на пачку бесплатных материалов курсам: яндексовые deep learning, reinforcement learning, NLP, он же Natural Language Processing, курс от Catalyst, битая ссылка на курс Machine Learning for Data Analysis на курсере (вот правильный линк) и подборку курсов по ML. Есть отдельный блок по дизайну ML-систем с набором ресурсов.

#skills #резюме

The Lesson to Unlearn — Вредные уроки

Мы уже вспоминали эссе Пола Грэма о хорошей и плохой прокрастинации. Рекомендуем прочитать его эссе "Вредные уроки". Ниже дадим ряд выдержек.

Самый вредный навык, привитый вам учебными заведениями — умение получать хорошие оценки. Важны знания, а не оценки. Автор вспоминает, что в студенческое время максимум усилий в учёбе он прилагал только во время подготовки к экзаменам. В теории, вы получаете знания по предмету на лекциях, при чтении дополнительных материалов и выполнении заданий, а экзамен потом показывает, насколько хорошо вы эти знания усвоили. На практике же интенсивная подготовка идёт только к экзаменам и почти никогда — во время семестра.

Следующая проблема вытекает из предыдущей. Время подготовки ограничено, поэтому нужно выбрать, что именно ботать. Во время подготовки можно пропускать все темы, которые не встречаются в билетах, всё дополнительное и интересное. Более того, преподаватели склонны иметь любимые вопросы, значит, можно готовиться только к ним. Если мы говорим о тестах, то вообще нужно готовиться строго по вопросам. Привет, ЕГЭ!

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

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

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

Умение взломать неэффективный тест становится всё менее важным по мере ослабевания взаимосвязи между работой и вышестоящими инстанциями.

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

#edu

You Suck at Excel with Joel Spolsky

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

Если вы каким-то боком касаетесь работы с табличными данными, то видео просто маст-хев. Сможете производить впечатление на не-айтишников своими познаниями. Ещё обратите внимание, как динамично Джоел проводит демонстрацию. Хороший пример, чтобы научиться выступать. В видео есть

– базовые вещи вроде объединения столбцов, копирования значений вместо формул, растягивания формулы вниз разными способами вроде двойного клика или ctrl+D и прочие штуки

– авторазмер ширины колонки/столбца по двойному клику, выставление одинаковой ширины у множества колонок/столбцов

– мощные внутренности в виде RC-значений. Теперь понятно, как внутри организованы ссылки на ячейки в экселе. RC это RowColumn-нотация, и запись вроде RC[-1] означает текущий Row и Column минус один. То есть каждая ячейка содержит относительную ссылку

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

– продвинутые фишки вроде заполнения выделенных диапазонов с помощью ctrl-enter, продвинутая работа с диапазонами на примере арифметических операций сразу с диапазоном значений, копирования форматирования

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

– удобная горячая клавиша F4 для повтора последнего действия. Прямо как точка в vim :) Интересно, что F4 применительно к формуле меняет относительную ссылку на абсолютную, а применительно к ячейке применяет последнее действие

– совсем продвинутые вещи вроде создания хитро вычисляемых полей с помощью vlookup (ВПР в русифицированной версии) на примере вычисления налоговой ставки в зависимости от локации, подбора значений в экселе (goal seek) на примере поиска нужного процента премии сотрудникам при заданном общем бюджете, сводных таблиц (pivot tables) для визуализации многомерных данных. Нагляднее в видео

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

Есть занятная история, как Джоэл прошёл строгое ревью Билла Гейтса My First BillG Review. В то время степенью успешности ревью было число слов fuck, которые Гейтс произнесёт во время встречи. Спольски хвастается всего 4 fuck на своём ревью, что было рекордом в то время.

Джоэл Спольски известен за классический Закон дырявых абстракций. Интересные мысли про переписывание проекта есть в статье Грабли, на которые не стоит наступать.

#skills

Очереди – что сложного то?

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

Подождите, очередь – это когда с одной с стороны положили, а с другой стороны кто-то забрал? Почти, но всё немного сложнее. Особенно в распределённых системах, особенно когда сообщений десятки тысяч в секунду.

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

Начинается всё с базовых понятий, какие вообще бывают способы организации очередей: put/take, pub/sub, request/response.

Для применения очередей существует множество инструментов.
– Apache Kafka реплицируемый шардируемый лог сообщений для стриминга. Мы кафку очень любим, и о ней были отдельные посты (раз, два)
– RabbitMQ – традиционный pub/sub broker. В отличие от Kafka, у кролика нет ограничений на количество потребителей. Кролик часто используется как шина данных между сервисами
– NATS обеспечивает быстрый неперсистентный обмен сообщениями, высокую производительность и масштабируемость
– Tarantool – это in-memory db, которая может быть использована для организации очередей. Примечателен тем, что можно написать свою очередь на стероидах, со своим процессингом, логикой и приоритетами

На самом деле очень важно знать особенности и отличия этих инструментов, чтобы применять их к месту. На этот счёт в конце статьи у автора также есть размышления.

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

Говоря о проблемах – они у очередей есть.
– на уровне алгоритма важно решить, что делать при отказе консьюмера, который уже взял сообщение. Best Effort – просто вернуть сообщение обратно. Но не во всех брокерах так можно. В таком случае можно настроить dead letter queue – отдельную очередь со своей логикой обработки таких сообщений.
– а ещё бывают проблемы приоритизации, когда из-за множества задач с высоким приоритетом консьюмер может никогда не добраться до задач с низким.
– на сетевом уровне существует undefined behavior, то есть сообщение отправлено, но мы не знаем, оно дошло и получено или потерялось
– помимо сети есть диск, который влияет на пропускную способность и задержку в обработке, которая может оказаться не предсказуемой

Чтобы обеспечить доступность (avalability) и надёжность (durability) применяются разные топологии:
– single instance – самый простой вариант. Один брокер, одна очередь, продюсер и консьюмер. Немасштабируемо, низкая доступность и надежность.
– multi instance – можно масштабировать и ставить столько очередей сколько нужно. С надежностью и доступностью получше, но если одна из очередей грохнется, то данные из нее потеряются.
– идём дальше и дублируем уже сами очереди
– автор не останавливается на этом и рассказывает о реплицировании, реплика-сетах, кворумах, кворумных очередях.

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

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

Напоследок ценная мысель: если вы не знаете, как ваша система падает и поднимается, быстро вы её не поднимите.

#skills

Backup: февраль

В этом месяце мы много говорили о проектировании, деплое и инфраструктурных технологиях. Не забыли о собеседованиях, питоне и софт-скиллах

Архитектура проекта и деплой
Design distributed cache
Стратегии деплоя
GitOps – все ли так классно?
За всё хорошее, против всего плохого

Важные инструменты
Практикуем Kubernetes
Как kafka хранит данные
Очереди – что сложного то?
Нестареющая классика, шпаргалка по SSH

Интересное по Python
Многопоточный Python на примерах: избавляемся от дедлоков
Мемоизация и каррирование в Python
Введение в logging на Python

Подготовка в собеседованиями
Правильная структура ответа на собеседовании
Как сдвинуть гору Фудзи
Подготовка к интервью в Тинькофф

PostgreSQL
Буфферный кеш в PostgreSQL
NULL в PostgreSQL

Нетехнические навыки:
Моё разочарование в софте
The Lesson to Unlearn — Вредные уроки от Пола Грэма
Упрощаем жизнь руководителю

Необычное для нас: You Suck at Excel with Joel Spolsky

Если пропустили, то подборка за январь

#backup

Пятничное развлекательное

Почему я идиот. Чудесный клип Александра Пушного, созданный на основе интернет-запросов пользователей почти 10 лет назад.

Пушного я люблю за многое. И старая-добрая программа Галилео, и Апож. Кстати, забавный факт из интервью Пушного — руководители хотели убрать детей от Галилео, и Пушной добавил брутальности. А детям зашло, и программа стала очень популярной среди детей и взрослых. В пандемию Пушной записал приятные rock-титры к Галилео.

Пушной был камео в обзоре BadComedian, о чём есть тоже забавная история. А совсем в старые времена Пушной выступал в КВН в роли Стинга. Приходите в комменты с ностальгией :)

#fun

Постигаем gRPC

Классический вариант межсервисного взаимодействия – REST. Но есть альтернативы, например, gRPC.

В своём докладе ребята из Яндекса рассказывают об опыте применения gRPC. Сначала, конечно, о проблемах, которые хотелось бы решить. Не просто же так тащить новую технологию в прод.

Среди хотелок автор выделяет:
– наличие клиентов на разных языках, да ещё чтобы не нужно было самим писать, а ещё чтобы клиент мог быть и синхронным, и асинхронным
– поддержка обратной совместимости сервисов, что особенно важно для множества параллельных релизов разных сервисов
– удобная обработка ошибок без нагромождения своего велосипеда
– управление таймаутами со стороны клиента, чтобы можно было отменить запрос

Далее автор переходит непосредственно к gRPC и рассказывает, как именно эти хотелки удовлетворяются.
На практическом примере показывает реализацию unary call – классического запроса/ответа и streaming для длительного соединения. Если с unary call всё ясно, то streaming может быть полезен для скачивания и загрузки больших сообщений частями или для отправки серверных пушей.

В статье затрагиваются темы: как избежать частых проблем, если вы начинаете использовать gRPC после REST, как возвращать ошибки, реализовать трассировку, отлаживать запросы и тестировать вызовы клиентов.

Если первая статья больше концептуальная, то для любителей питона есть замечательное практическое руководство Python Microservices With gRPC. Можно брать и делать. Сначала рассматриваются теоретические вопросы микросервисов, gRPC, когда применять. Далее практика – реализация микросервиса, деплой и тестирование. В конце приводится набор практик, которые стоит применять при использовании gRPC.

#skills

Микросервисы. Очередное рассуждение

В последнее время активно исследую вопросы, связанные с микросервисной архитектурой. Наткнулся на статью-рассуждение Микросервисы и неизбежная боль?

Автор начинает с того, что сам термин "микросервис" неоднозначен и приводит разные определения. Я с ним согласен. Думаю, что чересчур много внимания уделяется микро. Мне же нравится обобщённое определение, что микросервисная архитектура – это стиль проектирования, который разбивает приложение на отдельные сервисы с разными функциями. И важно, что в нём ни слова о размере.

Далее по классике микросервисы сравниваются с service-oriented architecture (SOA) и монолитом. Тут нет ничего нового. Выделю отличия микросервисов от SOA:
– в SOA, как правило, сервис – это крупное монолитное приложение. Возможно, даже ставшее отдельным сервисом не по архитектурной задумке, а в силу исторических причин
– в SOA используется глобальная модель данных и общая БД
– в SOA для межсервисного взаимодействия используются умные и тяжеловесные протоколы вроде SOAP

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

Что ж, у меня двоякое отношение к сказанному. Могу лишь сделать вывод, что любую архитектуру можно испортить. Ничего удивительного, микросервисы – не золотая пуля, они несут в себе набор проблем и ограничений. Важность перечисленных проблем в том, что о них нужно знать заранее, тщательно отслеживать и вовремя реагировать. Предупрежден – значит вооружён.

Возвращаясь к проблемам, для организации микросервисной архитектуры должны быть выстроены процессы и инженерная культура, созданы шаблонные сервисы, особое внимание должно уделяться CI/CD и observability.

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

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

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

#skills

ngrok

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

Для этого есть замечательная утилита ngrok. Одна команда и готово.

У ребят всё сделано по-человечески – можно поднять в докере и настроить end-to-end шифрование. На этом возможности не заканчиваются. Есть качественная документация, можно узнать, как воплотить в жизнь самые разные хотелки.

Не пугайтесь раздела pricing на сайте. Для подобного базового использования – всё бесплатно.

А чтобы объединить разные устройства на хозяйстве в одну сеть и иметь отовсюду к ним доступ, пользуюсь еще одной замечательной утилитой tailscale. Примечательно, что у ребят тоже хорошая документация и блог, где они описывают различные хитрые сценарии применения. Например, как кодить на айпаде в vscode.

#tools

Следим за Postgres

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

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

Для отслеживания размера БД автор приводит запросы для получения:
– размера табличных пространств
– размера базы данных
– размера схем в базе данных
– размера таблиц

Это всё цветочки и, как правило, можно посмотреть в любом клиенте.
А когда не проходит какой-нибудь запрос или миграция виснет, тут уже становится интереснее. Где-то что-то блокируется.

Для отслеживания блокировок автор приводит запрос для получения заблокированных запросов и снятия блокировок.

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

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

#skills #database

Teamlead roadmap

В разработке нужны не только разработчики. В зависимости от размера, для проекта могут требоваться тимлид, CTO, PM и ещё десяток разных аббревиатур. Чёткого деления по задачам нет, и в разных компаниях разное видение ответственности каждого из работников. И один человек может брать одновременно тимлидом и CTO.

В итоге тимлиды в команде часто выполняют достаточно уникальный набор задач, являющийся миксом из множества ролей. В предлагаемом роадмапе детализированы личные навыки тимлида и различные управленческие роли:
– administrator, ответственный за управление циклом разработки проекта
– integrator, понимающий потребности бизнеса и его долгосрочной стратегии, способный донести эти потребности до команды
– people manager, занимающийся людьми, организацией работы команды в самом широком смысле включая найм, мотивацию, поддержку процесса работы и увольнения
– product owner, способный стратегически мыслить в рамках продукта
– technical lead, стратегически отвечающий за техническую часть

Каждое из направлений состоит из множества навыков. По большинству навыков есть подробное описание и дополнительные материалы для изучения, статьи и книги. Например, мы обсуждали code review из роли technical lead.

Топовый роадмап для разработчиков был раньше.

#edu

Пятничное развлекательное

Есть такое хобби – экстраполировать. В шуточной статье Python 3.14 Will be Faster than C++ демонстрируется результат бенчмарка производительности питона от версии 3.5 до версии 3.11. Изложение приправлено изрядной долей юмора, have fun.

#fun