StringConcat - разработка без боли и сожалений

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

⚠️ Осторожно! В комментах местами портал в дурку, посему приглашаем к веселью (вы знаете что делать).

Приятного просмотра!

Channel photo updated

Нас много раз спрашивали как удобнее всего обрабатывать ошибки и исключения. Рассказываем, как мы это делаем и почему стандартный try-catch не всегда удобен.

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

Приятного просмотра!

Мы не знаем кто автор, но это просто шедеврально

Погнали! https://youtube.com/live/HYI5XzQFE3U?feature=share

Напоминаем, что сегодня состоится встреча. Ссылку скинем перед началом. Не пропустите!

На следующей неделе планируем провести стрим на тему «Внедрение DDD на практике — профиты и проблемы».

К нам в гости придет наш товарищ Константин Шибков, старший Java разработчик СДЕК, автор курсов и статей по разработке, соорганизатор митапа про бережливые бизнес процессы AgileUfa и клуба разработчиков JavaKeyFrames.

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

Ссылку пришлем позже, приходите и задавайте вопросы 🙂

Предварительно, запланировали стрим в четверг 31 октября в 18:00 МСК

К посту про SQL. Пока лазил на сайте Postgres Professional, наткнулся ещё на одну интересную книгу — «Путеводитель по базам данных».

Что внутри:
— Какие структуры данных используются для построения СУБД
— На каких алгоритмах построены распределённые СУБД
— Репликация и бекапы
— Журналирование
— Управление доступом

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

#полезнота

Последние несколько месяцев слышал от разных людей (у нас и за границей) похожие истории про техдолг:

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

В общем, долго клали болт на соответствие потребностей и реализации, и вот вдруг ВНЕЗАПНО что-то пошло не так.

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

Происходит ли у вас что-то подобное? Поделитесь, нам важно это знать :3

Ребята из Postgres Professional написали неплохую книгу «PostgreSQL 16 изнутри»

Какие темы охватывает книга:
— Устройство shared buffer
— Как работает WAL
— Как выполняются запросы
— Зачем нам вакуум
— Как работают индексы
— Как устроен MVCC
— etc

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

Просвещайтесь!

#полезнота

Небольшая заметка о стрессоустойчивости и вреде гиблых проектов https://vk.com/@-200496256-timlid-ozverel

Антипаттерн «Кадастровый инженер»

Хочет всё размежевать, чтобы не слиплось. Считает, что разделение по репозиториям и приложениям — панацея от скверны лапшекода. Мол, щас всё растащим, и никто не сможет использовать Х в У.

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

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

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

Как понять, что разделили неправильно? Когда для одной задачи вам приходится коммитить сразу в несколько репозиториев и в строгой последовательности. У репозиториев оказался слишком высокий coupling. Да, представьте coupling и cohesion применим и в рамках git-репозитория.

Почему агрегаты должны хранить свои секреты

Когда в чате обсуждают агрегаты, то в первую очередь упоминают инварианты и транзакционные границы, но есть еще один критический аспект, который нельзя игнорировать: сокрытие деталей внутренних сущностей. Агрегаты должны быть не просто контейнерами для реализации бизнес-правил - они также должны защищать свою внутреннюю структуру. Одна из важнейших функций агрегата - обеспечить, чтобы его внутренние сущности и объекты значений не использовались (и тем более не изменялись) внешним кодом. Например, агрегат Order может содержать список элементов Product. Вместо того чтобы разрешать доступ, например order.Products.Add(product), лучше добавить метод order.AddProduct(product).

Почему? Потому что таким образом агрегат контролирует все необходимые проверки и пересчеты внутри себя. Это сохраняет логику последовательной, гарантируя, что когда нам надо пересчитать что-то вроде TotalPrice, то мы сделаем это в одном месте и сразу для всех. Внешний код не должен знать, как именно это делается. Но это не все, самое важное:

Сохранение секретов == гибкость

Когда агрегаты скрывают свою внутреннюю структуру, наша система становится гораздо более гибкой. Вы можете рефакторить внутрянку, не переживая за другие части кодовой базы. Внешние компоненты взаимодействуют с агрегатами через четко определенный интерфейс (aggregate root, корень агрегата), что делает наш код более устойчивым к изменениям.

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

Ну вы поняли как действовать!

Первые впечатления от работы

Ситуация. Разрабатываем anticorruption layer между бравыми цифровыми сервисами банка и глючным core. Проекту три месяца. У всех разработчиков опыта минимум 7 лет. Из репозитория машет маленький-жук навозник, почти свалявший себе шарик говна. Буду вести репортаж, как мы всё это будем пересаживать на рельсы clean architecture.

Пока план такой:
1. Понять, как должно быть, и насколько мы далеки от этого
2. Найти единомышленников или хотя бы неравнодушных
3 .Разработать план рефакторинга, включив туда как можно больше людей. Чтобы все были повязаны и не саботировали потом.
4. Запихнуть задачи на рефакторинг в ближайшие спринты. Чего ждать.

На следующей неделе расскажу, как пошло.

Нам писали, что курс «Поваренная книга дядюшки Боба» тормозит. Докладываю: курс перезалит, теперь можно смотреть без регистрации, VPN и тормозов. Даже с мобилы.

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

Значит, у архитектора есть 2 большие задачи.

Задача раз: выработать нефункциональные требования, а потом на их основе нарисовать архитектуру. Задача сложная, но с ней более-менее большинство справляется.
Задача два: проследить, чтобы команда соблюдала заложенные в архитектуру принципы. С этим справляются уже не все, зачастую фантазии хватает только разносить всех на code review. Если у архитектора команда на 5-7 разработчиков, то так прожить ещё можно. А если у вас целый департамент на 50-70 программистов — ну такое.

Конечно, нужно автоматизировать битьё разработчиков по рукам. Например, автоматически проверять % покрытия тестами, или code style. Как правило, они интегрируются в систему сборки и запускаются автоматически, заваливая билд, если какая-то договорённость не соблюдена.

Но если репозиториев уже под сотню, и они плодятся каждый день? Тогда следить за соблюдением договорённостей помогает вот это:
— везде интегрирован jacoco, который проверяет покрытие тестами хотя бы 80%
— во всех репозиториях используется один code style
— все зависимости тянутся только из внутреннего репозитория

Делюсь подсмотренным приёмом: использовать стандартизированный gradle. Как правило, любая сборка состоит из интегрированных плагинов, конфигурация которых вручную копируется из одного проекта в другой. Но можно сделать собственный gradle wrapper со всеми установленными и настроенными плагинами.

Как работает
Архитектор один раз создёет репозиторий, который будет билдить gradle wrapper. Он публикуется в артифактори и становится доступен для скачивания как обычный пакет.

Далее архитектор создает обычный файл build.gradle, добавляет зависимости по вкусу, типа спринга или junit, и настраивает плагины, к примеру, jacoco. Зовётся это init scripts. Архитектор публикует грейдл, рассылает всем разработчикам ссылку на него и идёт спокойно пить пиво. Теперь разработчики при создании проекта указывают, что wrapper надо скачивать не с gradle.org, а из вашего репозитория.

gradle-wrapper.properties
distributionUrl=https://artifactory.your.org/repository/gradle-8.5.zip

Профит! Теперь в проект интегрировано всё минимально необходимое.

Фича зовётся gradle init scripts

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

Практикуете на работе? Микросервисы уже внедрили?🙂

Пока Сережа наслаждается успехом, мы снова возвращаемся к духоте.

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

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

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

Что ещё можно добавить в такую доку?
— контекст: зачем мы вообще это делаем, какую задачу решаем
— модель предметной области на основе Event Storming
— use case и альтернативные сценарии
— макеты в Фигме
— какая документация должна родиться
— какие метрики нужно вывести
— какие алерты настроить
— что поменяется в инфраструктуре
— риски безопасности
— любые другие технические подробности
— ссылки на другие документы

Несколько важных наблюдений

1. Документ обычно описывает ближайшую задачу, никаких «на вырост». Версии тут как таковых нет, потому что мы очень плохо можем в дифф.

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

3. Документирование может отмереть, если команда нарастит квалификацию и достаточно сработается. Это нормально, потому что цель — не бумажка, а общее понимание результата.

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

Как я получал оффер от банка

В Thoughtworks меня только-только сократили, я написал в LinkedIn, что я бедный и несчастный, ищу работу, и лёг спать.

В 11:00 следующего дня в телеграме мне пишет неизвестный: «я не знаю кто ты, но я тебя найду уже 3 человека сказали, что я обязан с тобой поговорить. Если нужна работа, приезжай в офис».

Первым рекомендателем оказался мой бывший коллега, Thoughtworker старой закалки. Он перешёл в этот банк несколько лет назад. Увидел мой пост и с утра пошёл к СТО сказать, что есть я, которого ещё вчера Thoughtworks предлагал им взять в аренду в 2 раза дороже, чем я сегодня стою.

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

Но их всех опередил мой бывший проджект-менеджер, который решил позвонить этому СТО ещё вечером накануне.

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

Вывод: личные контакты решают. Если у вас проблема — расскажите о ней, и помощь может прийти оттуда, откуда не ждали.

ВНЕЗАПНО, немного про метрики. Обычно для отслеживания работы приложений мы используем несколько приёмов:

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

2. Тащим временные метрики
С ними чуть сложнее. Нужно обмазывать метриками вручную каждый функциональный уровень (слой, если хотите) условной аннотацией @Timed:
— Контроллер (обычно в том же спринге метрики выведены)
— Сервисы уровня приложений
— Все внешние адаптеры, не важно, куда мы ходим, в БД или внешнюю систему

3. Тащим количество событий предметной области по каждому из типов
Служит косвенным признаком, что с системой всё хорошо. Технически всё может быть исправно, но по какой-то причине пользователи перестали жмакать кнопки, по количеству событий можем заметить, что что-то не так.

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

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

Полюби легаси, %username%

Намедни листал вакансии (нет, меня пока ещё не попёрли), наткнулся на формулировку типа «проект не легаси» и задумался. В айтишной среде под легаси всегда понимают что-то плохое, древнее и такое тоскливо-мерзкое, что не хочется и палкой трогать.

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

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

Попадались ли вам такие артефакты? Верите ли вы в них? Становится ли мир лучше или будущее человечества мрачно и безысходно? Нам важно это знать

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

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

Мы обещали помочь, и вот наше предложение!

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

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

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

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

Что нужно сделать:
0. Важно: Участвовать могут только те, кто сейчас ищет работу или планирует сменить ее в ближайшие 2 месяца.
1. Оставить комментарий «Хочу карьерную консультацию».
2. Мы свяжемся с вами и отправим небольшую анкету.
3. По результатам анкетирования выберем 10 человек и назначим встречу.

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

Я ходил на собеседование в очень странный стартап. Как вы помните, я ищу работу, чтобы меня не попёрли из Сингапура, а потому хожу на всякие собеседования. Сегодня расскажу о беседе с Head of Product, который раньше работал в Гугле.

Перед собеседованием HR предупредил меня, что на этом этапе срезается большинство разработчиков, поскольку продукту не интересны истории о смене одной БД на другую. Это внушало оптимизм. Ещё впечатляло, что в стартапе работали ребята 35–50, от 10 лет в профильной отрасли. Большинство успело поработать в Google, BlackRock или Github. Поэтому было интересно посмотреть, как стратап строит найм таких специалистов.

Первое, что я услышал, было «наконец-то я вижу резюме, по которому видно что человек приносил пользу компании, а не кафки крутил». Следующий час я рассказывал истории как мы что-то улучшали в продукте, как мерили эти улучшения, а в конце ответа я не забывал спрашивать «а как у вас дела обстоят с этим?» Это было одно из лучших собеседований в моей жизни. Я вышел с пониманием что:

— Интервьюер читал моё резюме до собеседования, и оно ему пришлось по душе
— Я отвечал именно то, что хотел услышать интервьюер
— Я не потел, пытаясь вспомнить примеры из жизни, а просто доставал по одной из уже заранее заготовленных историй
— Правильно подготовил резюме, потому что перерыл кучу материала по подготовке резюме и провалидировал эти материалы с HR’ами и консультантами
— Лекция про behavior interview вполне рабочая: стоит записать по одной истории на каждый принцип, чтобы на собеседовании петь соловьём, а стрессовать и рефлексировать дома.

Вывод такой: чем сеньёристей люди, которым попадается резюме такого формата, тем больше они его ценят. Чтобы попасть на позицию рядового гребца, вам, конечно, такое резюме не обязательно, напишите java 5+ лет. Но если хочется попасть выше и зарабатывать много денег, то советую заглянуть на наш курс. Там не только про оформление резюме и собеседования, но и про выстраивание долгосрочной карьеры.

Хотел спросить, с чем вы больше всего испытывает трудности. Ставьте реакцию под постом, а мы подумаем, как вам помочь.
😱 Пройти кодинг интервью
😭 Пройти систем-дизайн интервью
❤️ Рассказать о своём опыте так, чтобы заслушались
😎 Как выбрать следующую компанию и не тратить ещё год в болотце
🙊 Другое, напишу в комментах

Первые 2,5 недели поиска работы из 8. Напоминаю, что я в Сингапуре, а поэтому через 8 недель безработного меня отсюда попрут.

Результаты
— Откликнулся на 25 вакансий, по рекомендациям — на 8
— Прошёл 15 собеседований
— Получил 0 (ноль) оферов

Выводы

Все колотят понты. Даже маленький стартап на 4 стула должен проводить не менее 5 раундов собеседований, иначе не солидно. Стандартный процесс: HR → вопросы по SOLID → кодинг-интервью → беседа с PM → беседа с основателем.
На контрасте видел рекламу Альфа-Банка: собеседуют в 2 этапа, а решение принимают за день. Молодцы!

Публичность помогает. Я поставил статус «Ищу работу» в LinkedIn и рассказал об этом друзьям и в соцсетях, в итоге мне передали контакты заинтересованных во мне людей.

Нетворкинг работает. Абсолютно все собеседования, которые у меня были, я получил благодаря нетворкингу. Мне пишут люди, с которыми я когда-то работал или онбордил в ThoughtWorks. Пишут даже знакомые знакомых. Эффективность нетворкинга настолько меня удивляет, что я решил перезаписать лекцию для нашего курса про карьеру: 3 месяца назад я недостаточно эмоционально и глубоко рассказал, насколько важен нетворкинг.

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

Мои наблюдения за обстановкой на мировом рынке. Субъективно, но непредвзято.

1 Звонил индус-HR, который 2 года назад пытался продать меня в одну компанию. Говорит, искать некого, работы нет, на хлеб не хватает. Предлагал свои услуги.

2. В чате русских экспатов в Гонконге бывший менеджер Яндекса готов заплатить 2000 $ за рекомендацию в местную компанию, если он туда устроится.

3. Француз думает переехать вместе с русской женой в Россию, чтобы получить разрешение на работу. Во Франции работу найти нереально.

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

5. Товарищ из европейского Гугла с уровнем скилов «пройду собес не просыпаясь» переживает из-за недавних сокращений и чувствует себя не очень уверенно.

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

Конечно, это не объективная картина, но ещё 2 года назад такие истории звучали дико и смешно. А сегодня звучит обыденно.

Как думаете: отчего так, долго ли продлится и доберется ли тренд до России?