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

Наткнулся на неплохой мануал с примерами по spring-security и oauth

Как известно, в spring-security сам черт ногу сломит, а если туда oauth добавить, то, вообще, никогда в жизни не разберёшься. В мануале автор неплохо объясняет, как что устроено с точки зрения спринга.

Как сэкономить 120 000 $ в год на инфраструктуре? Просто возьмите старый проверенный EC2

Ситуация: клиент попросил оценить, не слишком ли много тратить 240 000 $ в год на инфраструктуру приложения, которое обслуживает 35 пользователей с 9:00 до 18:00.

Что мы нашли под капотом:
— 6 микросервисов, потому что модно и молодёжно
— по 2 инстансы каждого, потому что отказоустойчивость
— по 2 инстанса БД на каждый сервис, см. пункт выше
— деплой на AWS Fargate

Стоило это все 8000 $ в месяц на боевом сервере + столько же на UAT-стенде с зеркалом, который должен был быть у клиента по требованию регулятора.

Что мы изменили

1. Смёржили всё в два сервиса.

Микросервисы — отличная технология, когда вам нужно независимо масштабировать сервисы, устойчивость к отказам и независимый деплоймент сервисов. Но это при условии, что у вас микросервисы независимы и у вас зрелые Devops-практики. У нашего же клиента был типичный Distributed big ball of mud, который сводил все преимущества микросервисов в ноль.

2. Перевели деплой с AWS Fargate на EC2.

У AWS есть 2 варианта деплоя контейнеров:
— традиционный EC2. Вам выделяется виртуальная машина или несколько, в каждую машину напихивается столько контейнеров, сколько влезет.
— новый-молодежный Fargate, в котором кубернетису не нужно думать, раскидывать контейнеры по виртуалкам. Просто указываем, сколько каждому контейнеру нужно CPU и памяти, а тёмные электрические силы Амазона дальше сами всё делают.

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

EC2 стоил 3000 $ вместо 8000 $ за Fargate, получилось 60 тысяч экономии в год. Столько же удалось сэкономить на UAT-стенде. Итого те самые 120 тысяч в год из заголовка.

Здравствуйте! Это пост с набросом. Вы предупреждены.

Преамбула: в одном из архитектурных чатов у нас развернулась дискуссия по поводу специальности «разработчик»: стала она уже рабочей или ещё нет.

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

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

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

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

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

Как Netflix мигрировали на новый API и ничего не потеряли. Вторая часть

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

Для A\B-тестов Netflix поделили миллион пользователей на 2 группы:
— контрольную на старом API
— экспериментальную на новом.

Обе группы пользовались сервисом, а разработчики тщательно сравнивали quality of experience metrics: как часто возникают ошибки на клиенте, latency и прочее.

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

A\B-тесты оказались хорошим инструментом для проверки нефункциональных характеристик. За полгода Netflix уравняли показатели и мигрировали всех пользователей на новый API.

Как Netflix мигрировали на новый API и ничего не потеряли. Первая часть

У Netflix недавно рассказали, как они мигрировали на новый API без даунтайма.

Вот самое любопытное:

Netflix мигрирует с legacy API на GraphQL. Просто выключить старый API и включить новый они не могут: обязательно что-нибудь пойдёт не так и будет стоить дорого.

Чтобы проверить новый API в боевых условиях, но без ущерба для пользователей, они деплоят его рядом со старым и проверяют через Reply Testing.

Когда получается, запрос пользователя отправляется на оба API: на новый и на старый, а ответы сравниваются. Если есть разница, значит, что-то в новом API упустили. Например:

/data/videos/0/tags/3/id: (81496962, null)

Очевидно, забыли про поле ID и отдаём null.

А тут слетела локализация:

/data/videos/0/tags/5/displayName: (Série, value: “S\303\251rie”)

В статье пишут, что Reply Testing помог Netflix выявить следующие ошибки:
— encoding errors
— локализация
— формат даты и времени
— ну и, конечно, числа с плавающей точкой

А в следующей заметке поговорим, как они использовали A\B-тесты.

Для чего же всё-таки нужно резюме

Представьте, заходите вы в чат, а там два полярных мнения:

1. Резюме бесполезно. Соискатели всё врут, поэтому работодатели резюме не читают и всё нужное узнают на собеседовании.

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

Какое сами лайкните, а какое друзьям перешлёте?

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

Полезное для линуксоидов и маководов

SDKMAN — пакетный менеджер для JVM-мира. Позволяет устанавливать и жонглировать SDKашками и инструментами без геморроя и ручных манипуляций с переменными окружения, как, например, в brew.

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

Работает на большинстве Unix-образных систем и вроде как даже на винде через Cygwin, но я не пробовал. Не заменит brew или же apt, но рулить Java-миром через него однозначно удобнее. Крайне рекомендую к установке.

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

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

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

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

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

StringConcat - разработка без боли и сожалений pinned «Практический курс Разработка Enterprise-приложений без боли и сожалений На конференциях все рассказывают об успехах и высоких нагрузках. Но в реальности архитектура не предусматривает изменений, требования меняются каждый спринт, а разработчики тушат пожары…»

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

⚠️ Описанное ниже применимо, если вы работаете по ТК в окружении адекватных менеджеров.

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

1️⃣ Соберите числовые показатели, которым сотрудник должен соответствовать. Показатели нужны понятные, отслеживаемые и общедоступные — по SMART.

2️⃣ Поговорите с сотрудником ещё раз. Постарайтесь выяснить, какие у него проблемы и почему он так хуёво работает.

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

Если у сотрудника проблемы, на этом этапе он перестанет отмалчиваться и всё можно будет обсудить и попробовать исправить. Иначе идём далее.

3️⃣Назначьте условный испытательный срок внутри команды, около месяца. Если сотрудник справился — проблема вроде как решена. Если не справился — у вас появляется аргумент для кадровиков.

4️⃣ Кадровики назначат сотруднику сокращенный испытательный срок, по результатам которого рассмотрят увольнение по ТК.

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

Хочу похвастаться, я стал тренером Tech Lead Development Program в Thoughtworks! 🥳🥳🥳

Конкретно я рассказываю про то как выстроить техническую стратегию на проекте и про нефункциональные требования.

Когда дал джунам проект и вышел из кабинета
https://coub.com/view/3bmi5r

Продолжаем говорить про собеседование в Thoughtworks

Этап 2. Технический кругозор (1,5 часа)
Для начала кандидата спрашивают о прошлых проектах: что было интересного и чем можно гордиться.

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

Почему выбрали микросервисы — поможет понять, анализировал ли кандидат другие варианты или взял первое, что попалось
Что бы вы сделали по другому — покажет, рефлексировал ли кандидат над содеянным
Если кандидат упомянул, что знает несколько языков, спросим какой из них любимый и почему
Можно спросить о технических деталях — про особенности распределенных транзакций и всякие garbage collector’ы, — если только кандидат упоминал, что работал с ними

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

Этап 3. Culture Fit
Финальная часть собеседования, на которой оценивается насколько органично кандидат вольётся в коллектив. Для этого задаём стандартные поведенческие вопросы про ситуации на работе, два стула, вот это всё.

Если вы дошли до этого этапа, считайте что офер у вас уже есть.
Завалиться можно на каком-нибудь некрасивом поступке. Например, один кандидат игнорировал вопросы девушки и общался только с парнем.

Если вам понравился процесс и вы готовы попробовать свои силы, то сейчас Thoughtworks набирает разработчиков во Въетнам 😉

Завтра заканчивается предзапись на курс "Разработка Enterprise-приложений без боли и сожалений" (тариф максимальная прокачка)

Подробнее по ссылке - t.me/stringconcat/142
Места ещё есть.

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

1. Опыт работы на коммерческих проектах.
2. Знакомство с основными паттернами и инструментами разработки.

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

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

Как можно себя проверить?

У нас есть бесплатный курс "Поваренная книга
Дядюшки Боба: как готовить Clean Architecture". Справляетесь с поваренной книгой? Значит справитесь и с основным курсом.

Проверить себя: t.me/sc_stringconcat_bot
Записаться на курс: howto.stringconcat.com/enterprise

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

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

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

Теперь посмотрим как это имплементируется в собеседованиях:

Этап 0. Собеседование с HR
Достаточно быть более-менее адекватным: не пускать слюни на интервью, более-менее понимать что тебя спрашивают по-английски. Хотя надо признать, что даже HR’ы наврят ли пропустят кандидата после фразы «а я без тестов в прод деплою прям с ноута».

Этап 1. Coding Challenge (1,5 часа)
Вам заранее высылают маленький проект на вашем любимом языке и дают ознакомится с кодом.
На самом собеседование вас обязательно спросят, что понравилось в коде, а что бы вы улучшили.
Бывали случаи, когда ребята с 5+ годами опыта говорили, что все хорошо, но лучше использовать 2 отступа вместо 4 и комментарии добавить. Тут, конечно, можно уже и не кодить. Я лично, по крайней мере от Лидов, ожидаю критику архитектуры.

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

По секрету скажу, что к этой задаче достаточно немного порефактрить и написать 5 строчек продакшен-кода. И тесты, куда же без них.

Кстати, напишите в комментариях, а что бы вы исправили вот в этом тестовом проекте. Можете выбрать любой язык 😉

Продолжение следует…

Почему я (Сергей) решил учить английский

Шел 2016 год, стартап, в котором я работал, банкротится и мы всей командой разработчиков идем на onside собеседование Crossover(Это американский бодишоп на который можно работать удаленно и получать не самую высокую зарплату по меркам США, но очень приличную по любым другим меркам). К слову зарплата маячила в районе 8-10k USD в месяц. Я прохожу несколько этапов coding-challenge, коллеги постепенно отваливаются. И вот остается человек 5 из 30+ и последний этап — собеседование на английском. После которого мне говорят: ты, конечно, парень умный, но приходи к нам как подтянешь немного английский. Вот так из-за английского от меня уплыли 10к USD в 2016 году в провинциальной России…

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

Мой товарищ написал очень хороший гайд по тому, как ему удалось выучить английский до уровня C2.
Если вы решили что английский вам нужен — приятного чтения: https://howto.stringconcat.com/blog/how-to-learn-english

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

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

О чем ты узнаешь:
- Как понять действительно ли вам нужны микросервисы
- Каких проблем добавляют микросервисы
- Основные паттерны и антипаттерны при построении микросервисных архитектур
- Где находятся границы микросервисов и причем тут Domain-Driven Design

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

О чем ты узнаешь:
- Какие есть способы взаимодействия программных систем
- Чем они характеризуются
- Как выбрать подходящую модель взаимодействия
- Какие организационно-технические средства помогут сделать процесс интеграции менее болезненным
Практика: изучение паттернов на примере кода

10. Тесты и тестирование
Писать тесты или нет? Если да, то для чего? И почему наши тесты снова "протухли"? Ставим точку в этих вопросах.

О чем ты узнаешь:
- Какие виды тестов существуют
- Чем они характеризуются и для чего нужны
- Что такое пирамида тестирования и почему именно пирамида, а не ромб или квадрат
- Как поддерживать отслеживать качество тестов и поддерживать их в надлежащем виде
- Зачем на самом деле нужен тестировщик
Практика: разбор пирамиды тестирования на примере проекта

Старт новой группы – 10 июня!
Для записи переходите на сайт и выбирайте тариф «максимальная прокачка»: howto.stringconcat.com/enterprise

В прошлом посте https://t.me/stringconcat/142 мы объявили о старте предзаписи на курс "Разработка Enterprise-приложений без боли и сожалений" (тариф максимальная прокачка)

Сегодня расскажем о программе курса. Курс затрагивает такие темы:

1. Разработка и управление требованиями
Разработка требований — самый важный этап в жизненном цикле ПО. Если вы думаете, что требования нужны только аналитикам, то сильно заблуждаетесь, ведь если неправильно разработать требования, то о качественном продукте можно забыть.

О чем ты узнаешь:
- Какие бывают требования и какую роль они выполняют
- Как подстраиваться под постоянное изменение требований
- Различие в водопадном подходе и Agile с точки зрения требований
- В чем разница между UseCase и UserStory, что из этого и когда использовать
- Как разрабатывать требования и не утонуть в неопределенности
Практика: Разработка требований через построение карт пользовательских историй

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

О чем ты узнаешь:
- Что такое CI на самом деле
- Зачем в современном мире нужен trunk-based development
- Когда правильно организовывать репозитории
- Всегда ли нужны code-review
Практика: построение процесса непрерывной интеграции

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

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

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

О чем ты узнаешь:
- Какие основные проблемы сопровождают проект на уровне кода
- Какие метрики кода существуют и зачем они нужны
- Что такое SOLID на самом деле и зачем он нужен
- Как организовывать модульность и какие способы ее оценки существуют
- Как защитить свою архитектуру
Практика: разбор проекта на основе метрик

5. Эволюция проекта: от MVC до Clean Architecture
На небольшом примере рассматриваем эволюцию проекта, какие кризисы он переживает и зачем все это нужно. Узнайте, на каком этапе развития находится ваш проект и что его ждет, если ничего не предпринять.

6. Sensible defaults
Практики, которые используются в приличных заведениях и чтобы от них отступить нужны веские причины.

О чем ты узнаешь:
- Как экстремальное программирование помогает справиться с неопределенностью
- Разработка через тестирование (TDD) — что это такое и почему тесты всего лишь побочный эффект методологии.
- Как парное программирование экономит время
Практика: парное программирование по TDD

7. Domain-Driven Design
Самая сложная часть курса и мозг вашего приложения. Разбираемся, почему разработчикам так тяжело понимать заказчиков и пользователей, а добавление одной кнопки требует 5 человеко-месяцев.

О чем ты узнаешь:
- Как работают стратегические паттерны и зачем они нужны
- Из каких строительных блоков состоит модель предметной области
- Почему так важно понимать что ты разрабатываешь
- Как коммуникация между бизнесом и технарями влияет на успех проекта
Практика: EventStorming и разбор примера кода на основе тактических паттернов