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

А вот и запись встречи про выгорание в Книжном клубе.rar подъехала. Пару комментариев: 1. В списке книг не упомянули «Стечение сложных обстоятельств» Юрия Власова. Люто мотивирующая книга, благодаря ней в том числе я выбрался из тлена 2. На встрече был вопрос: «Как отличить усталость от сожженых мозгов?» Забыл упомянуть важный момент. Жженые мозги иногда сопровождаются характерным запахом соматическими проявлениями. Например, у меня каждый понедельник поднималась температура до 37,5, а потом вообще чуть не заехал в больничку. Не факт что у вас будет так же, но имхо признак очень характерный

Резюме — никому не нужно? Конечно, да… ну почти. Все говорят: «Резюме никто не читает, это просто формальность». Да-да, HR’ы пролистывают, нанимающие менеджеры не открывают, а CTO вообще отправляют в мусорку. Ага, конечно. Недавно у меня случилась история, которая блестяще доказывает обратное. Мне посоветовали кандидата. Я открываю его CV — чисто чтобы убедиться, что пересылаю HR’ам нужный файл, и… чуть не упал со стула. Парень оказался: • соавтором книги по функциональному программированию, • участвовал в проектировании StashAway (если вы в финтехе — знаете, насколько это громко), • контрибьютил в известные open source проекты. Вместо того чтобы переслать его HR’ам, я кинул резюме прямо CTO. Тот, не моргнув глазом: «Я сам с ним поговорю». Дальше было только веселее: • любой инженер, которому я показывал резюме, готов был брать парня без собеседования, • HR’ы внезапно начали работать в три раза быстрее (ну наконец-то нашли кнопку «ускорить»), • еще до интервью мы уже приготовили ему место в топовой команде банка. И тут… барабанная дробь… он завалил coding interview. Причём у нас оно максимально щадящее: никаких извращений с алгоритмами или «расскажи все ключевые слова языка». Просто напиши понятный код, прикрути тесты — и живи спокойно. Когда он провалился, никто не поверил интервьюерам. «Да вы слишком строгие!» — сказали мы и пошли проверять код сами. Увы, код реально не тянул. Даже харизма книги по FP не спасла. Какой вывод? • Запоминающееся резюме — это половина собеседования. • Люди будут предвзято позитивно настроены ещё до того, как вы откроете рот. • Но дальше придётся всё-таки не облажаться с базовыми вещами. В следующей статье расскажу, как сделать резюме, которое работает на вас ещё до первого «Здравствуйте».

В опросе всего 5% выбрали релокацию как способ увеличить доход. Пять процентов! Видимо, остальные 95% верят, что «счастье не в деньгах». Или в их случае — «счастье не в переезде». Но давайте честно: этот пункт явно недооценили. Релокация ≠ «с концами» Не обязательно сразу жечь мосты и продавать бабушкину дачу в Рязани. Можно рассматривать это как «длительный рабочий туризм». Только вместо магнитиков домой привезёте опыт, деньги и новые ругательства от чтения индусского кода в оригинале. Куда ехать? Если вы доросли до уровня senior developer и ещё не обзавелись детьми, то вам прямая дорога в Сингапур, ОАЭ, Гонконг или Швейцарию. Там и зарплаты жирные, и налоги низкие. Правда, иногда налоги настолько низкие, что социальная защита тоже где-то на уровне «держитесь, там вы справитесь». Почему именно Senior? Потому что ни одна компания не будет сжигать свои квоты на джунов и мидлов. Квоты — это как безлимитка на доставку: тратить её на доширак обидно, а вот на хороший стейк — в самый раз. Почему без детей? Потому что в странах с низкими налогами детские садики и школы тоже низкотаксированные — то есть платные. Тысяча долларов в месяц за школу — и вся выгода от низких налогов испарилась. И золотого унитаза в этих школах не будет. У моих детей в школе (в Сингапуре) кондиционер есть. Но один и в кабинете директора. Корни и любовь до гроба Здесь без розовых очков. В этих странах вам рады, пока вы приносите пользу. Как только вы состаритесь, потеряете работу или решите «жить для себя» — чемодан, вокзал, родина. Это не романтика, это чисто деловые отношения. «Любовь» строго до окончания рабочего контракта. Сколько платят? Очень примерно: • Сингапур, ОАЭ, Гонконг: 70–120k USD в год. • Швейцария: по слухам, немного щедрее — 90–120k. Бонусы (кроме зарплаты): • Нетворкинг. Вряд ли вы подружитесь с местными, но любой белый человек для другого белого в этих странах — уже «друг, брат и почти сестра». • Опыт международной разработки. И это реально ценится. Как сказал один мой менеджер в Сингапуре: «Сергей, не придирайся на собеседованиях к людям, которые уже сюда приехали. Если они пробились в Сингапур — они и так топ». Какую страну вы бы порекомендовали?

Обещал видоски - первый пошёл. Разбираемся как быть с валидацией на беке, как сделать ее консистентной между системами, причём тут property testing и WAF. ВК | YouTube

Всем привет! Напоминаем, что через час (20:00 по Москве) у нас состоится гостевой выпуск, в рамках которого мы обсудим с Евгением Лукьяновым из "StringConcat" темы вокруг выгорания! Запасайте печеньки, задавайте ваши вопросы по ссылке, и ждём вас на грядущем эфире! 🔗 Ссылка на подключение: Толк

🔥 В следующий четверг иду в Книжный клуб .rar обсуждать (внезапно!) выгорание. А поскольку я в этом деле спец (горел уже раза три) — есть чем поделиться 🙂 📚 Книжный клуб .rar — это сообщество айтишников и увлечённых людей, где вместе читаем книги по разработке и другим темам. Каждую неделю — по 1–3 главы, плюс живые обсуждения, где новички и эксперты делятся разным взглядом на идеи. 📅 Когда: 11.09.2025 в 20:00 по МСК (следующий четверг) 📍 Где: Книжный клуб .rar

В комментах к прошлому посту справедливо спросили: а зачем вообще такая строгая валидация? Хороший вопрос. Давайте разберёмся. Первый сценарий — когда нам нужно просто что-то отобразить. В этом случае можно обойтись минимальными проверками. Условно, проверили, что поле не пустое — и хватит. Тут и правда нет смысла городить сложные правила, мы скорее переживаем за то, чтобы верстка не поехала. Второй сценарий — когда объект реально участвует в предметной области. И вот тут начинаются настоящие приключения. Например, числовые значения. Их желательно приводить к конкретной точности. Иначе арифметика начинает жить своей жизнью: где-то округлили слишком рано, где-то потеряли пару копеек — и всё, отчёт уже не сходится. Сначала ошибка на пару рублей, потом на пару сотен тысяч, и внезапно прибыль компании уже не прибыль. Другой пример — ИНН. Если пользователь ошибся хотя бы в одной цифре, этот ИНН может улететь в другие системы, включая государственные. А дальше начинается квест. Пользователь приходит и говорит: «Ой, знаете, я там одну циферку перепутал, давайте поменяем». А мы понимаем, что этот «битый» ИНН уже где-то в налоговой, где-то в бухгалтерии, где-то в стороннем сервисе (ведь там есть валидация, правда же?). И исправить это всё задним числом — очень сложно. Вот поэтому строгая валидация — это не перфекционизм. Это защита от будущих проблем. Да, иногда можно ограничиться проверкой «строка не пустая». Но если речь идёт о данных, которые реально живут в предметной области и пересекают границы разных систем, здесь без жёстких правил никак.

Работаем со студентами над курсовым проектом и неожиданно уперлись в проблему, которая на первый взгляд кажется тривиальной. Value Object. Казалось бы, что может быть проще? Паттерн элементарный, тесты пишутся очень просто, всё логично и прозрачно. Но на практике именно с него начались настоящие трудности. Почему? Потому что Value Object требует не просто «обернуть данные», а заранее продумать все варианты валидации и граничные условия. Если раньше хватало поставить что-то вроде @NotBlank в контроллере и надеяться, что кто-то потом в сервисе провалидирует (нет), то теперь приходится разбирать детали: - Какой должна быть минимальная и максимальная длина имени (к примеру, азиатское имя может состоять из одной буквы)? - Допустимы ли цифры или спецсимволы? (а если человек зовётся «X Æ A-12 »? Представляю что испытали разработчики государственных систем США увидев ТАКОЕ) - Что делать с иностранцами: если имя написано латиницей, должна ли и фамилия быть латиницей? - А если человек решит использовать двойную фамилию через дефис? (и не один раз). Даже такие на первый взгляд простые сущности, как ФИО, внезапно превращаются в головоломку. Хорошо, когда у нас есть чёткие и формализованные правила валидации — например, для ИНН или паспорта. Но даже здесь не всё так очевидно. Даже если формат существует, он далеко не всегда прост. Возьмём, например, VIN-код автомобиля. Казалось бы, жёстко стандартизированная штука. Но при ближайшем рассмотрении выясняется, что у него есть куча скрытых нюансов: одни символы можно использовать, другие нельзя, разные страны добавляют свои исключения, часть информации хитро кодируется внутри строки. И вот тут-то и проявляется неожиданная сложность: Value Object, который выглядит как «простейший паттерн», на деле заставляет глубоко задумываться о бизнес-логике и реальных ограничениях данных. Простой паттерн вдруг превращается в философский вопрос: «А что вообще считать правильным значением?», ибо даже часть ограничений или форматов может оказаться нерелевантным для конкретной предметки. В итоге даже самое базовое поле уже не сводится к «строка не пуста». Оно превращается в полноценное проектное решение, за которым стоит куча вопросов, дискуссий и иногда ощущение, что проще сменить профессию. Мораль: простые паттерны на практике оказываются не такими простыми. Они вытягивают наружу то, что мы обычно привыкли замалчивать — правила, форматы, ограничения и вариации реальной жизни. И да, внезапно выясняется: самая сложная часть в коде — это не алгоритмы, а люди с их «Фёдорами-Алексеями Петровичами 2».

Снова побуду капитаном очевидностью. Намедни обсуждали вопрос сравнения (equals) агрегатов. И здесь важно помнить: сравнение — это всегда контекстно зависимая операция. Почему так? Потому что невозможно сравнивать «вообще» — всегда есть цель, ради которой мы это делаем. - Если нужно понять, что речь идет об одинаковых ссылках на участок памяти, то сравниваем собственно по ссылке

a === b

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

a.id == b.id

- Если важно отследить изменения, которые произошли в процессе работы, тогда сравнивается содержимое.

a.id == b.id && a.field1 == b.field1

Причем механизм сравнения полей тоже может отличаться в зависимости от контекста И здесь ключевой момент: невозможно заранее выделить универсальный набор параметров для сравнения. Критерии будут зависеть от конкретной задачи и того результата, который мы хотим получить. Это, кстати, один из частых источников ошибок в проектах: мы пытаемся придумать «универсальный способ сравнения», а потом обнаруживаем, что он не подходит в половине случаев. Поэтому каждый раз, когда возникает вопрос сравнения, полезно начать с простого: для чего мы это делаем?

с недавнего собеса: - как работают слои в докеробразах, кэш? - {мои ответы} .... A FEW MOMENTS LATER - {мои вопросы} .... - а как вы деплоитесь на прод? - rsync

Вакансия: Платформ-лид в Яндекс Крауд Компания Яндекс открыла позицию платформ-лида. В описании упоминаются: • DDD • Clean Architecture • Trunk-based Development • Event Storming • TDD И нет, это не красивая замануха. Я общался с техдиректором направления — они действительно собираются внедрять все эти практики (и кое-что уже внедрено). Из хорошего: количество собеседований сократили, так что можно попробовать свои силы; По всем вопросам пишите CTO @Dzirtik P.S.: Это не реклама, а вакансия от проверенных людей. Публикуем, потому что таких позиций на рынке 3,5 штуки.

Cultural map на пальцах. И без переломов Недавно мой коллега, коренной британец, с пафосом викторианского джентльмена пожаловался на американцев в стиле «Ну тупые». Его пример: в Британии — horse riding, в американском английском — horseback riding. Мол, зачем эти уточнения? Ну и так же ясно, куда именно надо садиться на лошадь. Не на хвост же, хотя, конечно, в жизни всякое бывает. Но на русском это вообще будет «верховая езда». И тут мы пошли ещё дальше: мы даже не уточняем, на ком или чём мы там верхом. Всем и так понятно, что не на корове (а вот когда Шурик в Кавказской пленнице на осле ехал — это все еще верховая езда?) Это, кстати, отлично иллюстрирует книгу The Culture Map. По мнению автора, одна из ключевых разниц между странами — это сколько контекста подразумевается в сказанном. • У американцев контекста почти нет: что сказали, то и имели в виду. Пример: «Let’s meet at 3 p.m. at Starbucks on 5th Avenue» — это буквально приглашение встретиться в 15:00, в конкретном Старбаксе, на конкретной улице. • У британцев контекста больше: надо понять подтекст, тон, скрытую вежливость. Пример: «We should get together sometime» — значит «Мы, конечно, никогда не встретимся, но я вежливо изображаю заинтересованность, чтобы не показаться хамом». • В России уровень контекста ещё выше: половина смысла в интонации, а вторая половина — в том, что не сказано. Пример: «Надо бы встретиться» — в зависимости от тона это может значить: 1. «Я тебя реально хочу увидеть» 2. «Мы больше никогда не увидимся» 3. «Ты мне должен денег» 4. «Я уже возле твоего дома» В общем, чем восточнее, тем меньше слов и тем больше догадок. Книга однозначно рекомендована к прочтению.

Иногда у них даже получается

ИИ снова в новостях: то удалил БД, то слил данные. Ничего удивительного — ИИ может "глючить". Но вот что странно: никто толком не понимает, как он работает (исследования только начались), а его уже внедряют повсюду. Что же может пойти не так? P.S.: А ещё это огромное хранилище уязвимостей — под LLM даже свой OWASP Top-10 появился.

Кто думает, что работает в компании по производству обсуждений ставьте лойс

Ну что, дорогие разработчики, давайте признаем что всё что мы умеем делать эффективно — это затягивать 15 минутный стендап митинг на 40 минут.

Относительно недавно ходил на собеседование в проект, который оказался не просто легаси, а настоящим памятником древним IT-цивилизациям. Переписывают они сие говно мамонта, с какого-то настолько забытого языка, что я даже название не запомнил (и вообще впервые о нём слышал). Переписывают один в один, со всеми костылями, техдолгом и хранимками на Oracle. Оригинальная компания-поставщик решения уже потонула, а поддерживать изделие как-то нужно, поэтому и перепиливают на джаве. Стоило мне упомянуть, что веду канал и курсы, как лицо собеседующего скривилось в судорогах и из него полился классический корпоративный буллшит вида: «ммм… невовлечённость…». По их логике, я должен радостно отказаться от всего живого ради возможности обмазываться копролитами. Идеальное описание такой вакансии звучало бы так — «Умеете включать компьютер и не ходите под себя? Приходите! Платим сотни нефти». Разумеется, деньги — аргумент. Можно хотя бы поплакать в свою финансовую подушку, когда следующий HR с неподдельной скукой будет слушать, как вы вовлечённо закапывали свои навыки, амбиции и ментальное здоровье. Но вообще мне повезло, со мной хотя бы пообщались.

Мы все живые люди, а не собственность работодателя. Работа — это просто работа. И многих HR сам факт этого доводит до микроинсульта. Если бы не кредиты, ипотеки и не современная экономическая система — большинство из нас вообще бы не работали, а занимались бы чем-то реально интересным. Будем честны: какой вообще интерес — до конца жизни перекладывать JSON на одной из этих джейсоноразвесочных фабрик, коими стали огромное количество проектов? И если уж мы начали оценивать вовлечённость по внешним признакам — может, стоит проверить, нет ли у автора поста детей, супругов, собакенов? Ведь это всё тоже мешает KPI-экстазу.

Божественный костыль для тех, кто не умеет Ах, ИИ — новая волшебная таблетка! Достаточно добавить «с ИИ» в описание проекта, и вот уже инвесторы бегут со следующей порцией подливы, клиенты оттягивают вам резинку труханов, чтобы напихать хрустящих купюр, а код сам себя пишет. Напоминает вам что-то? Например, NoSQL в 2010-м, микросервисы в 2013-м и блокчейн в 2017-м — только вид сбоку. Конечно, есть команды, которые реально получают буст от ИИ. Но сюрприз-сюрприз: у них и до этого всё было неплохо — и требования вменяемые, и в коде разобраться можно. А есть другие. Те, кто уже в своём коде не разбирается, но свято верит, что вот-вот появится ИИ, в который можно запихнуть весь проект, нажать кнопку «Сделать хорошо» — и вуаля, можно идти пить тыквенный латте (это не шутка, я слышал такие разговоры). Так вот, друзья мои, если вручную вы сделать хорошо не можете, то никакой ИИ вам не поможет. Он лишь быстрее нагенерирует вам ещё больше лапши.