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 писать. И уже не важно, что нужно бизнесу, что пользователю, — начальник выбрал, ты кивнул. Для сравнения в Скандинавии царит дух равенства и даже тимлид не может решать за всю команду. Любое решение придётся продавать, а команда может его не принять. И я такое встречал даже в банке. По моим наблюдениям в атмосфере равенства получаются более качественные продукты: каждый в команде чувствует причастность и ответственность за результат. При подходе «спустили сверху» причастности не ощущается. С другой стороны, скандинавы некоторые проблемы решают месяцами, утопая в бесконечных обсуждениях. Китайцам же консенсус искать не нужно, за них всё Конфуций решил.

Мы уже рассказывали, как нанимать и мотивировать людей. Теперь расскажем, как их правильно увольнять — не нарушая прав, не превышая полномочий, без людоедства и произвола ⚠️ Описанное ниже применимо, если вы работаете по ТК в окружении адекватных менеджеров. Представим, что у нас есть разраб и он косячит так, что за ним потом прибирают все. Допустим также, что мы уже испробовали все мирные способы: поговорили по душам, отправляли в отпуск, приглашали в офис массажиста. Разработчик раскаялся, распрямился и порозовел, но творить дичь не перестал. Остаётся только уволить. 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 и разбор примера кода на основе тактических паттернов

Продолжаем (а может даже завершаем) цикл телеперерач о чистой артихектуре. Теперь с кодом! https://www.youtube.com/watch?v=q6NPKBek-BE