Практика распила монолита

Несколько лет в индустрии шли жаркие споры "микросервисы против монолитов". У каждой из сторон было множество адептов. Однозначного решения нет.

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

— контейнеризация и хранение контейнеров

— применение API Gateway, настоящего швейцарского ножа в мире микросервисов для решения сотни инфраструктурных задач

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

— tracing, прослеживание пути запроса среди множества сервисов. Предлагаемое решение jaeger мы уже упоминали в отдельном посте про разухабистое логгирование

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

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

В заключении автор напоминает: прежде чем внедрять — подумайте, какие задачи и проблемы вы этим решаете. Эта истина применима к любой технологии
#skills

Покоряем большие CSV

Классная практическая статья Working with large CSV files in Python from Scratch рассказывает о хитростях работы с большими CSV-файлами.

В статье рассматриваются примеры:
— подсчёт строк в большом файле. Для этого применяется mmap, который использует низкоуровневое API операционной системы. Это позволяет ускорить чтение большого файла. Сам mmap заслуживает отдельной статьи. В ней с примерами на питоне объясняется, откуда берётся ускорение, плюс другие интересности, в том числе уровня системных вызовов ядра

— разбиение большого файла на части, с которыми дальше удобнее работать

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

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

Мы на практике неоднократно сталкивались с гигабайтными CSV, которые иногда даже не умещались в оперативную память.

Например, вы знаете, что линуксовый sort --unique читает файл целиком в оперативную память? А для работы ему надо примерно в 2,5 раза больше памяти, чем весит исходный файл. То есть для сортировки файла в 10 гигов нужно около 25 гигов оперативной памяти. Решение этой проблемы заслуживает отдельного поста.
#python

Составляем документацию разработчика пошагово без диет и тренировок

Мы уже писали о своём опыте документирования проектов.

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

Начинается статья с интересной блок-схемы, где отображены типичные вопросы по документации:
— Есть ли у вас документация?
— Актуальна ли она?
— Легко ли её найти?
— Читает ли её кто-то?
— В одном ли месте всё собрано?

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

Часто полезная информация разбросана по разным источникам. Как подключиться к инфре писали в общем чате, нюансы работы с сервисом написали в личку, R&D таки зафиксировали в конфлюенс. Поэтому на первом шаге рекомендуется собрать всё вместе.

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

Чтобы понять, о чём реально стоит писать, соберите обратную связь. Прошерстите чатики, комменты под инструкциями. Если часто спрашивают, как поменять конфиги там-то — отлично, именно об этом и стоит писать.

Неочевидный, но важный момент. Вход в документацию начинается с поиска. Если где-то будет написано: кронджоба, джоба, cron, то нужный материал не найдётся. Поэтому договоритесь о единой терминологии и стиле написания. У нас, например, простое правило: любые термины пишем в их каноническом виде на английском языке.

Стоит позаботиться также о читабельности. Тут все банально — на текст должно быть приятно смотреть. В статье на этот счёт есть конкретный набор советов.

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

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

Кино на выходные

Думаю, вы слышали о Стивене Хокинге. В 21 год ему поставили диагноз "боковой амиотрофический склероз" и предположили, что жить ему осталось 2.5 года. Болезнь прогрессировала, он перестал ходить, потом утратил возможность двигать руками. После воспаления лёгких он утратил способность говорить.

...В 2018 году он умер в возрасте 76 лет. Практически не имея возможности контактировать с окружающим миром, он вёл исследования, писал книги, выступал и даже летал в невесомости.

К просмотру рекомендуется фильм Вселенная Стивена Хокинга (2014) и одна из его книг, Краткая история времени.

#fun #films #books

Проектируем систему — System Design

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

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

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

О типовых решениях разных задач обязательно нужно знать, чтобы не городить очередной велосипед при решении новой проблемы. На эту тему у нас был отдельный пост.
#skills #резюме

Этапы выполнения запросов в PostgreSQL

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

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

И тут уже сложно без понимания EXPLAIN. Ведь анализатор строит дерево плана. Тот или иной запрос можно выполнить по-разному, поэтому и план запроса не один. Для выбора наилучшего оптимизатор применяет хитрые алгоритмы и оценивает стоимость запроса.

Как итог: чтиво направлено больше на понимание кишочков, но менее захватывающим от этого не становится.

Статья является первой из цикла. Далее автор освещает использование статистики, индексное и последовательное сканирования, соединение вложенным циклом или хешированием. Всё это приблизит к глубокому пониманию того, как выполняются запросы в PostgreSQL.
#skills #database

Python import: Advanced Techniques and Tips

Импорты в питоне могут стать головной болью начинающего разработчика, особенно при переходе от запуска в IDE разработчика на чужую машину. Полезно один раз детально разобраться в этой теме. В статье рассматриваются разные вопросы работы с пакетами в питоне. Доступен перевод в двух частях: часть 1, часть 2.

Начинается статья с базового описания модуля как пространства имён и применения dir для его исследования. Далее объединение модулей в пакет и разные варианты импорта.
В статье также подробно освещаются следующие темы:
— абсолютные и относительные импорты. На практике относительные импорты — зло, PEP8 рекомендует применять абсолютные импорты в большинстве ситуаций

— import path и порядок поиска модулей

— создании своего пакета для PyPI. Классический setup.py, плюс установка изменяемого пакета для удобной разработки без необходимости переустановки. Интересным дополнением является включение ресурсов или данных в пакет на примере иконок для GUI-приложения

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

— перезагрузку модулей. Проблема в том, что повторный импорт не приводит к перечитыванию модуля, по факту используется старая версия. Для перезагрузки модуля надо использовать importlib.reload. Этот и предыдущий пункты позволяют вместе организовать динамические плагины в проекте

— работу с разными модулями в зависимости от доступности библиотек или версии интерпретатора. Это позволяет применять разные библиотеки. Нет bokeh для визуализации? Используем matplotlib. Не все фичи будут доступны, но будет работать

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

Заход на правильную организацию импортов был в посте об анализаторах кода.
#python

Жизненная история

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

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

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

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

Пока происходили все эти события, бизнес вырос в пять раз. Монолит переехал на микросервисы. Инфраструктуру перенесли в kubernetes, что позволило создать распределённое отказоустойчивое решение в трёх дата-центрах.

Автор выделяет следующие преимущества kubernetes:
— канареечные выкаты, позволяющие производить A/B-тестирование
— деплой без даунтайма
— балансировка нагрузки
— горизонтальное автомасштабирование
— интеграция запуска тестов в CI с различными хитрыми конфигурациями
#skills

Частичное клонирование репозитория

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

В git есть возможность частично клонировать репозиторий (partial clone). В статье рассматриваются разные способы частичного клонирования. Каждый раз мы выбираем, какие объекты клонировать не нужно.
— blobless clone не клонирует blob объекты
— treeless clone не клонирует директории
— shallow clone — самый минималистичный вариант. С помощью параметра depth можно выбирать глубину клонирования истории, например, только последний коммит.

По каждому из пунктов автор приводит наглядные картинки и рассматривает особенности применения других команд при partial clone.

Для работы с ограниченной рабочей копией есть интересная команда sparse-checkout. На github более подробная статья с примерами применения этой команды.
#skills

Признаки хорошего логирования

Продолжим тему разухабистого логирования. Насколько подробно и много нужно писать в лог?

Иногда смотришь на портянку логов и понимаешь, что ничего непонятно. Однотипные строчки следуют одна за другой, глаза разбегаются. Логов так много, что ими уже никто не пользуется. Бывает и противоположный случай. Приложение явно работает, кряхтит шестеренками, а в stdout логов всего пара строк. И тоже возникают вопросики, что же там происходит. Поэтому важно отслеживать объём генерируемых логов. Логов должно быть не слишком много, но и не слишком мало.

"DB Connected", "Test completed", "Message processing completed" — подобные записи в логах порождают много вопросов. Что? Куда? Важно стараться давать больше конкретики. Если подключаетесь к базе, то укажите IP и порт. Запускаются какие-то тесты — стоит указать, какие именно. Прошла обработка сообщения — укажите, что за обработка.

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

На практике мы встречали попытки обратить внимание, показать важность лог сообщений различными символами. "!!! DB Connected" — примерно такое можно встретить. Не надо так. Это усложняет чтение и затрудняет поиск того, что действительно нужно найти. Для выделения важности логов придумали уровни логирования. Вот ими и стоит пользоваться.

И напоследок: логи, как и код, стоит рефакторить, критически смотреть на их информативность и необходимость.
#devfm #skills

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

Никаких больше споров Python или Java. Знакомимся с "идеальным языком программирования" DreamBerd.

К каждому привычному элементу в программировании автор подошёл донельзя творчески. Как вам константные переменные? Их можно изменять, но нельзя переприсваивать.

К чему проблемы с индексом начала массива, 0 или 1? Давайте использовать -1. И разрешать использовать нецелые числа для индексов.

Туда же спор о "табы против пробелов". Очень просто — для отступа нужно использовать 3 пробела. Кстати, минус 3 пробела тоже работает.

Конечно, для сравнения можно использовать ==, === и даже ====.

Булевы переменный могут хранить true, false и maybe. Для классов можно создавать только 1 экземпляр. Всё равно большинство разработчиком больше не требуется.

Читайте и наслаждайтесь.
#fun

Введение в Kubernetes

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

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

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

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

Первая статья — концептуальное введение о необходимости оркестрации контейнеров без привязки к кубернетесу.

Вторая статья освещает основные концепции — cluster, nodes, pods, namespaces, кто на ком стоял.

Третья подробнее рассказывает о супер-важной штуке в кубере — подах (pods). Почему не хватает контейнера, из чего состоит под, в каких состояниях он может быть и как проверить его работоспособность.

Кто-то должен управлять всем развернутым зоопарком, предоставлять API для взаимодействия, решать на каком узле запустить под, контролировать работоспособность различных частей кластера и пытаться приводить всё к требуемому состоянию (desired state). Четвертая статья рассказывает о мастер-ноде и компонентах, которые берут на себя все эти задачи.

Пятая статья вводит ещё один набор концепций, которые активно применяются в кубернетесе — deployments, stateful set, daemon, jobs. Со всем этим неизбежно сталкиваешься на практике.

И заключительная, шестая статья рассказывает о том, как устроено взаимодействие различных частей в кластере, какие IP-адреса существуют, для чего они используются и как в обращении с ними помогают load balancer и ingress controller.

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

🔥, если интересна тема кубернетеса.
#skills

Доступаемся до ChatGPT

Нейросеть ChatGPT уже многие попробовали, и это просто вау! Для тех, кто ещё не пробовал — очень рекомендуем. Интересные варианты использования:
— можно решать и оптимизировать задачи на программирование. В комментариях к посту про быстрый поиск в 37 Гб файле подписчик уточняющими вопросами уровня "а как можно улучшить" заставил нейросеть пройти те же шаги, что и автор статьи

— проходить собеседования, причём и теорию, и практику. ChatGPT умеет писать код -__-

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

— писать рефераты и конспекты. Нам прислали интереснейший пример: для подготовки к экзамену студент ввёл "напиши небольшой конспект для экзамена на тему ХХХ" и получил действительно годную выжимку по вопросу. 20 минут и готов конспект для подготовки по всем вопросам к экзамену

Какие ещё есть примеры использования? Проявите фантазию и делитесь в комментариях.

Из грустного: сервис не работает из России, но думаем с VPN уже все разобрались :)

Также требуется регистрация. На этот случай рекомендуем удобный сервис BugMeNot. Просто вводите сайт, а в ответ будет предложены учетные данные для входа.

BugMeNot бывает полезен, когда не хочешь регистрироваться на каком-нибудь ресурсе.
#edu

Google Coding Interview With An Artificial Intelligence (ChatGPT)

В видео Clément Mihailescu, бывший Software Engineer из гугла, а нынче со-основатель площадки AlgoExpert, сервиса платной подготовки к интервью проводит mock google coding interview с чат-ботом. Иногда в процессе бот отваливался. Сами вопросы:
— напиши функцию определения палиндрома. Интересно то, что на повторный вопрос ChatGPT выдал совершенно другой код. Первый раз код был "в лоб", очень длинный и хорошо документированный. Второй раз код был в стиле Си-хакеров, пусть код и на JavaScript

— оцени сложность по памяти и времени этого алгоритма (space-time complexity). Автор комментирует ответы бота и восторгается, как внимательно в ответе раскрываются нюансы и граничные случаи

— поиск подстроки, которая является самым длинным палиндромом заданной строки. Вопрос с подвохом — решение в лоб имеет сложность O(n^3), а оптимальное решение O(n^2). Как вы понимаете, ChatGPT сразу выдаёт решение квадратичной сложности. Сам автор говорит, что когда-то не смог решить эту задачу на своём собеседовании в Lyft. Причём при очередной попытке задать этот же вопрос бот выдал решение O(n^3), но подметил, что это решение "не самое эффективное, но простое и его проще понять"

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

JWT и его друзья

Хорошая заметка, чтобы вникнуть в token-based authentication.

Начинается всё банально — чем аутентификация отличается от авторизации. Дальше интереснее — access и refresh-токены. Что это, как устроены, почему они в паре и какое имеют отношение к авторизации.

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

Очень важно уметь правильно обращаться с токенами и хранить их. Во многих мануалах на просторах интернета учат, как делать проще, но не как делать правильно.

В заключение автор кратенько сравнивает JWT со столь привычными для многих cookie sessions и даёт несколько практических советов.

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

Для проекта средних размеров предлагаем взять популярное open source решение — Keycloak и развернуть его как сервис. Да, сначала будет непросто и нужно разобраться в особенностях. Но на длинной дистации это правильное решение.
#skills

Классные pre-commit хуки

Мы уже рассказывали, что на всех проектах используем утилиту pre-commit с линтерами. Но её можно настроить на другие полезные штуки. Нашли репозиторий с различными pre-commit хуками.

Нам показались интересными:
– проверка на добавление больших файлов в репозиторий. Бывает полезно, чтобы случайно что-то большое и лишнее не закомитить
– проверить, что исполняемые файлы содержат шебанг
– проверить корректность json-, toml-, xml-файлов
– проверить, что у файлов с тестами корректные названия. Это особенно важно, когда тесты автоматически прогоняются в CI/CD-пайплайнах
– проверить, что нигде случайно не комитятся секреты. Это частая проблема, когда в репозиториях находят какие-нибудь переменные окружения SECRET_KEY

Список не ограничивается перечисленным, загляните в репозиторий, может обнаружите что-то интересное для себя.
#skills

Manticore Search

Для полнотекстового поиска во многих проектах активно применяется Elasticsearch. Он же работает в системах для аналитики логов. Пример тому – всем известный ELK-стек. Но не эластиком единым.

Мы начали смотреть в сторону разных поисковых движков и пока остановились на Manticore Search.

Рекомендуем статью Manticore — альтернатива Эластику на C++. Автор начинает с исторической справки, как появился и развивался проект.

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

Конечно, стоит критически относиться ко всем описанным тестам. Статья всё-таки подготовлена ребятами из мантикоры. Если бы статью писал кто-то из эластика, он бы нашел, о чём хорошем рассказать. Как говорится: если вы такие умные, то почему такие бедные?

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

Планируем попробовать мантикору в своём проекте. О причинах выбора и результатах расскажем позже.

В заключение, Manticore Search – заслуживающий внимания проект, о котором стоит знать, как о потенциальной альтернативе эластику.
#skills #database

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

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

Венгерский математик Абрахам Вальд решил, что укреплять нужно места без пробоин. Если самолёт с пробоиной вернулся на базу, значит, повреждение не критичное. Это называется систематическая ошибка выжившего — survivorship bias. Мы судим о вернувшихся самолётах и не учитываем сбитые.

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

Ставшие успешными Джобс, Гейтс и Цукерберг не закончили университет. Но не это причина их успеха. Вообще бесполезны рекомендации от успешных людей и важны истории поражений.

#fun

Backup: январь

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

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

Архитектура проекта
— Проектируем систему — System Design
— Практика распила монолита
— Жизненная история. Выбираемся из болота большого проекта
— БезТЗатый программист

Интересное по Python
— Python import: Advanced Techniques and Tips
— Классные pre-commit хуки
— Покоряем большие CSV

Используем базы данных
— Индексы в PostgreSQL
— Этапы выполнения запросов в PostgreSQL
— Manticore Search как замена Elasticsearch

Крутые базовые материалы
— Вспоминая git
— Признаки хорошего логирования
— Частичное клонирование репозитория

Строим веб-приложение
— Кажется, ваше приложение сейчас пятисотит
— Авторизация через OAuth и OIDC
— JWT и его друзья

Нейросети нас заменят
— Доступаемся до ChatGPT
— Google Coding Interview With An Artificial Intelligence (ChatGPT)

#backup

Практикуем Kubernetes

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

В этот раз посмотрим практическое руководство на официальном сайте кубера.

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

Все руководства, помимо практической части, сопровождаются теоретическими материалами.

Из приятного — можно ничего не устанавливать себе на компьютер, а пройти всё в терминале на сайте. Для большего погружения рекомендуем всё-таки развернуть у себя Minikube и делать практику локально.
#skills

Правильная структура ответа на собеседовании

Классический анекдот. Студент сдаёт экзамен по зоологии, а подготовился только к вопросу про блох. Тянет билет — там про собак. Начинает отвечать, что собака — млекопитающее, у неё есть голова, 4 лапы, хвост, всё это обильно покрыто шерстью, а в шерсти — блохи! И подробнейшим образом про блох. Преподаватель прерывает и просит рассказать про кошек. Студент снова: голова, усики, лапы, хвост и много шерсти, в которой — блохи, и опять про блох. Преподаватель снова прерывает и просит рассказать про рыб. Студент: тааак, рыбы., рыбы... плавают в воде, дышат жабрами, покрыты чешуёй. В чешуе блохи не водятся. Это спасает рыб от проблем с блохами. И снова про блох...

Рекомендуем версию этого анекдота с интересной историей из жизни про экзамен в РХТУ им. Менделеева. К чему это мы?

При ответе на собеседовании или на экзамене важно показать обширность и глубину ваших знаний. Выгодно максимально подробно отвечать, даже если ответ не совсем по теме. Забыли, что значит D в SOLID? Постарайтесь построить ответ так, чтобы максимально подробно рассказать про знакомые буквы. В процессе вспомнили другие темы, например, аббревиатуры, связанные с исходным вопросом? Пускайте в ход DRY, YAGNI, KISS, NIH-синдром, bus-factor и кучу другого материала, по возможности вплетая его в повествование. Высока вероятность, что собеседник забудет, что вы не до конца ответили на поставленный вопрос. Чем уместнее вы притянули смежные темы, тем менее заметна попытка скрыть незнание. Если тема совсем не к месту, то будет обратный эффект с обнаружением вашего незнания.

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

Но не злоупотребляйте таким приёмом. В работе важно уметь честно признать, что чего-то не знаешь. Нельзя знать всего, надо учиться у коллег, в том числе на правильном code review.

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

#devfm #sudo #edu #резюме