StringConcat - разработка без боли и сожалений
Open in Telegram
Полезный блог от разработчиков для разработчиков. Наш сайт: howto.stringconcat.ru
Show more3 707
Subscribers
+224 hours
+117 days
+730 days
Data loading in progress...
Similar Channels
No data
Any problems? Please refresh the page or contact our support manager.
Tags Cloud
Incoming and Outgoing Mentions
---
---
---
---
---
---
Attracting Subscribers
September '26
September '26
+18
in 0 channels
August '26
+23
in 0 channels
Get PRO
July '26
+14
in 0 channels
Get PRO
June '26
+24
in 0 channels
Get PRO
May '26
+33
in 0 channels
Get PRO
April '26
+35
in 0 channels
Get PRO
March '26
+91
in 0 channels
Get PRO
February '26
+130
in 0 channels
Get PRO
January '26
+168
in 0 channels
Get PRO
December '25
+62
in 0 channels
Get PRO
November '25
+55
in 0 channels
Get PRO
October '25
+165
in 0 channels
Get PRO
September '25
+88
in 1 channels
Get PRO
August '25
+227
in 0 channels
Get PRO
July '25
+275
in 0 channels
Get PRO
June '25
+209
in 0 channels
Get PRO
May '25
+158
in 1 channels
Get PRO
April '25
+45
in 1 channels
Get PRO
March '25
+42
in 0 channels
Get PRO
February '25
+29
in 0 channels
Get PRO
January '25
+34
in 0 channels
Get PRO
December '24
+68
in 0 channels
Get PRO
November '24
+47
in 0 channels
Get PRO
October '24
+70
in 0 channels
Get PRO
September '24
+97
in 0 channels
Get PRO
August '24
+150
in 1 channels
Get PRO
July '24
+100
in 1 channels
Get PRO
June '24
+35
in 0 channels
Get PRO
May '24
+27
in 0 channels
Get PRO
April '24
+30
in 0 channels
Get PRO
March '24
+47
in 0 channels
Get PRO
February '24
+42
in 0 channels
Get PRO
January '24
+60
in 1 channels
Get PRO
December '23
+56
in 0 channels
Get PRO
November '23
+64
in 1 channels
Get PRO
October '23
+107
in 0 channels
Get PRO
September '23
+245
in 0 channels
Get PRO
August '23
+94
in 0 channels
Get PRO
July '23
+63
in 0 channels
Get PRO
June '23
+142
in 0 channels
Get PRO
May '23
+319
in 0 channels
Get PRO
April '23
+281
in 0 channels
Get PRO
March '23
+55
in 0 channels
Get PRO
February '23
+35
in 0 channels
Get PRO
January '23
+68
in 0 channels
Get PRO
December '22
+27
in 0 channels
Get PRO
November '22
+18
in 0 channels
Get PRO
October '22
+42
in 0 channels
Get PRO
September '22
+24
in 0 channels
Get PRO
August '22
+40
in 0 channels
Get PRO
July '22
+41
in 0 channels
Get PRO
June '22
+34
in 0 channels
Get PRO
May '22
+53
in 0 channels
Get PRO
April '22
+13
in 0 channels
Get PRO
March '22
+13
in 0 channels
Get PRO
February '22
+26
in 0 channels
Get PRO
January '22
+17
in 0 channels
Get PRO
December '21
+28
in 0 channels
Get PRO
November '21
+20
in 0 channels
Get PRO
October '21
+191
in 0 channels
Get PRO
September '21
+41
in 0 channels
Get PRO
August '21
+58
in 0 channels
Get PRO
July '21
+130
in 0 channels
Get PRO
June '21
+39
in 0 channels
Get PRO
May '21
+236
in 0 channels
| Date | Subscriber Growth | Mentions | Channels | |
| 06 September | 0 | |||
| 05 September | +3 | |||
| 04 September | +9 | |||
| 03 September | +5 | |||
| 02 September | 0 | |||
| 01 September | +1 |
Channel Posts
| 2 | В комментариях к предыдущему посту читатели оставили пару комментов. Они интересные, поэтому давайте разберём. Кратко передам суть первого:
VO на практике бывает очень локальным, поэтому не всегда есть смысл их выделять в отдельные классы и можно вообще оставить.
То, что логика локальная, — это не значит, что её необходимо оставлять как есть (иначе получатся анемичные объекты с логикой в агрегатах). Конкретно в моём случае эта логика постоянно переиспользовалась в разных местах, в том числе за пределами агрегата (для построения графиков, отчётиков и т. д.).
Сам VO распространяется не на все контексты — ограничение таки есть (это сам контекст как раз). Также в тексте есть про общие типы, которые могут использоваться везде. Это как раз норм, так как логика 100% всегда одинаковая (email он и в Африке email), но там тоже есть оговорки (подробнее в статье).
Второй комментарий придётся разобрать по частям.
Получается, во-первых, что VO должен что-то знать об объектах, из которых он может быть сконвертирован (например, IP-адрес знает о том, что может быть создан из строки и о формате этой самой строки),
В целом это норм, обычно на практике проблем не вызывает. При работе с VO мы примерно представляем, из чего собирается объект (email — строка, денежка — double BigDecimal). Если есть проблемы с тем, во что сериализовывать и десериализовывать, — можно воспользоваться механизмом функций-расширений (об этом тоже есть в статье).
VO должен заботиться о том, чтобы отдать клиенту ошибку создания в красивом и понятном виде. А в этом последнем трудно соперничать со специальными инструментами валидации, которые готовы тебе указать локализацию вплоть до json-path свойства и позиции в строке.
Вот как раз-таки и не должен. У VO клиент — это вызывающий его код, а не конечный потребитель. Вы бы знали, сколько раз я переделывал с JSON-ов не на JSON-ы и обратно, подключал вообще не HTTP-каналы и т. д. Если логика отображения заложена в VO, вы никогда больше не сможете поменять бизнес-логику, потому что «ой-ой, у нас отображение формочки сломалось».
Плюс множество встроенных валидаторов этих инструментов, которые придётся тогда игнорировать и велосипедить.
«А минусы?» Тут возникает проблема — а какой валидатор брать? Спринговый? Хиберовский? Ещё какой-то? Выпилили/обновили Хибер — а что теперь делать? Поэтому вся логика валидации аккуратно запихана в сам домен. Вообще мы используем инструмент для валидации в виде ArrowKt, про это тоже есть в посте. Он действительно упрощает сбор ошибок, и мы считаем его частью домена на системном уровне.
На другой стороне инфраструктуры (ORM) тоже достаточно заморочек с сериализацией/поиском по ValueObject. Entity Framework дотнетовский за последние годы многому в этом направлении научился, но всё равно сохраняются ограничения на применимость VO-подхода "мощностью" нижележащего ORM-фреймворка.
Собсна, в этом и заключается суть чистой архитектуры — отделить инфру от домена. Очень любим такой подход, потому что уже наелись. Про сохранение тоже в статье было — проблем, как правило, не вызывает, если умело пользоваться. | 711 |
| 3 | Знаем, что большинству удобнее читать текст, чем смотреть видосики, поэтому решили выложить в открытый доступ текстовую версию видосов про Value Objects.
Внутри — примеры из реальных проектов с логикой чуть сложнее, чем просто валидация, а ещё разбор такого явления, как коллекции в виде VO.
P.S. Если найдёте опечатку или какой-нибудь косяк — пишите прямо там, в комментах. Мы вроде всё вычитывали, но где-то на 35-й странице внимание начинает немного угасать
Ну и ставьте лойсы и делитесь постом. Если такой формат зайдёт — будем делать больше текстовых материалов. | 1 036 |
| 4 |  Notebook → прод, метод на 1000 строк, цикл в цикле в цикле, никто не понимает что происходит - это классика от MLщиков. Мы применили DDD и чистую архитектуру к реальному ML-проекту. Value Objects, агрегаты, доменные сервисы, порты — на конкретных примерах кода (осторожно, петухон).
Читать что получилось → | 1 642 |
| 5 | Я на работе запилил такое правило — мы работаем с подходом Monolith First. Это когда мы сначала запиливаем монолит, а потом нарезаем его по мере необходимости. Тут даже не то чтобы правило, меня прям бомбить начинает от слова «микросервисы».
А всё почему? Да потому что вы, наверное, помните офигительную историю про 80 микросервисов. Выяснилось, что, чтобы собрать эти 80 микросов, нам нужно 220(!) репозиториев. Ну а вендор, который продал это чудище, просто сказал: «У меня лапки, я не могу поддерживать это больше». Даже развернуть на новом стенде оказалось нереально.
И тут хорошо видна ещё одна проблема с вендорами. Мы обычно думаем, что покупаем у них продукт, который потом будем несколько лет развивать и поддерживать. А вендор зачастую думает, что он делает проект. Есть набор задач, за который ему заплатили, — надо этот набор и закрыть. Что будет с системой через два года, когда её придётся обновлять, развивать или просто развернуть на новом стенде, — это уже как бы отдельная история (обычно после нас хоть трава не расти).
Получается интересная ситуация: мы строим продукт, а вендор закрывает проект. И вот из таких проектов потом и вырастают 80 микросервисов, 220 репозиториев и система, которую уже никто не может нормально собрать.
Зато как красиво звучали слова про масштабируемость (наверное). | 2 006 |
| 6 | Как ИИ превратил плохих менеджеров в плохих разработчиков
Не знаю, как у вас, но у меня с появлением ИИ собеседования превратились в боль.
Раньше плохих разработчиков можно было отсеять ещё на этапе тестового задания. Сейчас любое тестовое выполняют как минимум на «сойдёт»:
— пользоваться ИИ не запретишь;
— какое-никакое решение он всё-таки состряпает.
Поэтому количество очных собеседований у нас выросло в разы.
Но недавно я столкнулся с новым типом кандидатов: плохими менеджерами, которые с помощью ИИ переквалифицировались в плохих разработчиков.
Попался мне один такой. Рассказываю.
Читаю резюме — вроде всё нормально, но нет какого-то коннекта на уровне «свой — чужой». Чувствую подвох. Резюме слишком вылизано, в достижениях слишком много бизнесовых показателей. Разработчики обычно так не пишут.
Открываю тестовое — и там тоже на первый взгляд всё хорошо. Но вместо Gradle вижу build.sh, который заканчивается командой:
javac -d "$BUILD_DIR" "@$SOURCES_FILE"
Уже подозрительно.
На собеседовании выяснилось, что кандидат работал менеджером разработчиков в крупном криптостартапе. После внедрения ИИ многих менеджеров там заставили писать код.
В ядро продукта их, конечно, никто не пустил, но поручили делать сопутствующие инструменты — например, для KYC.
На собеседовании кандидат не смог реализовать ни одного бизнес-требования. А когда мы попросили отрефакторить компонент бизнес-логики и сделать его немного более объектно-ориентированным, он почему-то начал рассуждать про JSON.
В общем, будьте внимательны. Обязательно просите кандидатов писать код прямо на собеседовании. Я все так же против того, чтобы заставлять на собеседованиях вертеть деревья. Но отрефакторить свой код, заимплементировать фичу и написать на это тест кандидат, имхо, обязан.
И на сладкое.
Файл с тестовым заданием назывался ATM-final-v6. Внутри лежал Git-репозиторий с одним-единственным коммитом.
Ну а что? В требованиях было сказано использовать Git. Вот, пожалуйста, использовал.
Расскажите в комментариях как ИИ повлиял на процессы собеседований в ваших командах | 2 035 |
| 7 | Тут опять произошло прекрасное.
Исследователи из JFrog решили проверить, что там с найденными (как выяснилось, в основном ИИ) уязвимостями в SQLite, и оказалось, что из 55 зарегистрированных CVE реальной была всего одна, а остальные — обычные галлюцинации ИИ: тут и выдуманные методы, и несуществующие пути эксплуатации, и нерабочие эксплоиты, и прочие радости жизни. Самое фиговое, что эти уязвимости уже успели попасть в CVE. То есть в следующем релизе вполне возможно, что какой-нибудь сканер начнет сношать вам мозг относительно критической уязвимости, которой никогда не существовало.
Можно подумать, что ИИ тут бесполезна. Но нет.
На мой взгляд, ИИ сейчас довольно неплохо работает там, где есть четко сформулированные правила, которые можно проверить. Например, при разработке агрегатов и инвариантов к ним. Можно попросить ИИ оценить белые пятна: не нарушается ли владение объектами, не забыли ли мы проверить уникальность, нет ли сценария, при котором агрегат может попасть в неконсистентное состояние и все в этом духе. Понятно, что это не магический анализатор, который найдет все проблемы. Но результаты иногда бывают довольно неожиданные и реально полезные. Как минимум, помогает посмотреть на модель с другой стороны и найти потенциальные баги до того, как они доедут до прода.
Вторая полезная штука — проверить наличие или отсутствие проверок безопасности. Но тут есть важный момент (и, кстати, он справедлив и для первого случая). Эти проверки должны быть единообразны и желательно централизованы.
Условно, если у вас простая модель разделения доступа, то на каждом контроллере должна быть аннотация @Secured (или что-то подобное), а не где-то глубоко в DAO. Иначе вы просто сожжете токены ибо ИИ не сможет понять, что именно является правилом, а что случайностью.
Вообще, для таких критичных вещей я большой фанат подхода fail fast. В одном из проектов мы сделали следующим образом: если в конфигурации явно не задано, какая роль нужна для контроллера (или он не добавлен в список исключений), приложение просто не стартует. Что-то вроде: .addRole(SomeController::method, Roles.ADMIN)
Но это довольно примитивный случай. Проблемы начинаются дальше. Например, нам нужно проверить не просто наличие роли, а доступ к конкретному ресурсу. Пользователь может видеть только свои счета, свои документы и т.д. Тут уже одной аннотации с ролью на контроллере может быть недостаточно. И вот здесь как раз хорошо работает комбинация из архитектурных правил, статического анализа и ИИ. Допустим, мы договариваемся, что любой Use Case, который работает со счетом, обязан использовать интерфейс безопасности: CheckHasAccountAccess(accountUID)
Дальше можно кастомный статанализатор (мы так делали, дописывали правила уже к существующему), который будет проверять наличие такого вызова (и имеет ли он вообще отношение к сущностям, над которыми происходит действие), можно ронять сборку при нарушении правила, а еще можно попросить ИИ проверить не упустили ли мы чего.
Конечно, это не панацея и не заменяет нормальные тесты и security review. Но вероятность забыть критичную проверку становится заметно ниже. Мне вообще кажется, что именно в этом сейчас одна из самых сильных сторон ИИ. Мы не пытаемся заставить его быть магическим сканером уязвимостей, который найдет неизвестную дыру в миллионах строк кода, а использовать его как дополнительный слой контроля за тем, что ваши собственные правила действительно соблюдаются. Но для этого сначала нужно эти правила иметь . Если у вас просто сопли, размазанные по всему проекту, слоям и сервисам (99% того что я видел выглядит именно так), то ИИ просто поможет вам быстрее расстаться с бюджетом | 1 533 |
| 8 | No text... | 1 593 |
| 9 |  No text... | 1 936 |
| 10 |  А теперь первый душный пост на нашем новом ресурсе. Выжимка из опыта — как построить команду мечты.
Внутри:
- Почему команда мечты — это не 10 суперзвёзд, работающих по 16 часов (а суперзвезда вообще антипаттерн)
- Каких людей надо гнать ссаными тряпками в первую очередь
- Какие роли необходимы в команде
- Почему собес почти ничего не решает
- И как понять на нём, что перед вами хорошая команда, а не очередной филиал ада
Читать → | 2 135 |
| 11 | Небольшой лайтовый пост про то кто мы такие и чему учим (считайте, что разбирался с редактором сайта). Следующий, с пониженым содержанием кислорода уже в работе. | 2 378 |
| 12 | Magnum Opus
Итак, ребята, немного новостей.
1. Как вы знаете, мы занимаемся обучением, и у нас есть курс «Разработка без боли и сожалений». Написали мы его около 6 лет назад, и за это время он не потерял актуальности (а во времена ИИ стал даже актуальнее, ИМХО). Но пришла пора обновлений.
За эти годы мы гораздо лучше поняли текущие потребности, накопилось большое количество материала и т.д. Что хочется сделать? Добавить больше практики: как самостоятельной, так и в формате разборов. Очень много вопросов из серии «а как вот это сделать?», поэтому решили, что проще показать и заставить вас повторить. Еще хочется добавить новые темы: немного ИИ, безопасности, производительности, миграций и т.д. Раньше этого не было в явном виде, но сейчас потребность уже есть.
Мы уже приступили к обновлению, делаем это не спеша. Это не наша основная деятельность, над нами нет KPI, менеджерок, эйчарок и т.д., поэтому можем делать все в свое удовольствие и никуда не торопиться. Это наше отдохновение от корпоративных болот, эдакий Magnum Opus.
2. Если все получится, то, возможно, будет отдельный курс про инженерный ИИ в разработке, в соавторстве с ребятами из научной среды. Идея в том, чтобы рассказать, как использовать ИИ в разработке и получать воспроизводимый (!) результат. Сразу скажу, что это довольно сильно отличается от вайбкодинга — тут опять придется думать (опять все строится на тех вещах, о которых мы много лет рассказываем на канале). Но пока окончательной договоренности нет. Надеемся, что получится. А может и нет, штош.
3. Еще накопилось некоторое количество духоты (и не очень духоты), которую уже можно выкладывать на YouTube и в блог. В прошлом году выпускали материалы довольно активно, а потом немного придавило личными и рабочими делами. Обещаем исправиться.
4. Есть еще некоторое количество тем, которыми не очень хочется делиться с большим интернетом, потому что нас, как обычно, обольют говном за непопулярное мнение. Скорее всего, сделаем подписку с символическим платежом и будем выкладывать такое туда по мере сил. Заодно уже завели проект на sponsr. Хотим постепенно дублировать туда вообще все наши материалы в том числе и заметки, забекапиться так сказать (на самом деле хочется просто вернуться в юность, когда мы читали емеил-рассылки и учились по ним программировать).
Сайт пока отключен. Если вам интересно поучаствовать в курсе — можете написать мне в личку.
Как говорят у нас, рәхим итегез! | 2 572 |
| 13 |  Про языки программирования в эпоху ИИ.
Можно подумать, что сейчас уже не так важно, какой язык мы используем. Но не совсем. Скорее, подвергается инфляции сам навык кодинга (хотя фронтендеры еще с 2010-х должны были привыкнуть, что их навыки регулярно обесцениваются с выходом очередного фреймворка).
Так вот, суть языка никуда не девается. Более того, если мы рассматриваем тру-инженерный подход, то нам нужно как-то валидировать выхлоп LLM. И тут очень кстати оказываются нормальная модульность, типы, статический анализ и прочие скучные вещи, которые почему-то снова становятся актуальными (опять ничего нового).
Есть ощущение, что в эпоху ИИ язык все больше становится не только способом писать код, но и способом ограничивать пространство ошибок. Чем больше инвариантов и ограничений можно выразить средствами самого языка, тем меньше шансов, что модель сгенерирует что-то неожиданное (это работает и с разработкой через органическую нейросеть). В этом смысле, например, Python выглядит менее удачным выбором для разработки больших систем с активным использованием ИИ. Не потому, что кто вообще придумал это убожество на нем нельзя писать, и уж тем более не потому, что на нем не делают больших проектов (делают, к сожалению). А потому, что многие гарантии остаются на уровне соглашений и линтеров. Типизация появилась позже и по большей части тоже работает вне языка. В результате часть ошибок всплывает уже в рантайме, а вы тратите больше времени и больше токенов на их поиск и исправление.
Возможно в эпоху LLM хорошие языки — это не те, на которых быстрее наговнокодить, а те, на которых проще ловить косяки электроболванов | 1 895 |
| 14 | Handbook: Как не быть уволенным когда все косячат с деплойментом? (продолжение, начало про деплоймент из закрытой комнаты)
Как вы понимаете, при деплойменте из закрытой комнаты ни один деплоймент гладко не проходит.
А если что-то пошло не так, нужен виноватый. И тут процесс поставлен на поток. Раз в полгода нанимается новый деплоймент-менеджер, который, офигевая, собирает все эти подписи.
- Потом происходит деплоймент с неизменным факапом.
- Виновным назначается деплоймент-менеджер.
- Деплоймент-менеджер отправляется на февральский мороз.
- Тут же открывается вакансия нового деплоймент-менеджера.
Ну хоть тут процесс у банка отработан. И заметьте, для этого никому не надо запираться в той комнате с HR менеджером и камерой.
Почему я не попал в тот банк?
Когда мы торговались за зарплату, я неосмотрительно выдал:
Я обмениваю международную компанию с хорошей репутацией на местный банк, поэтому хотелось бы компенсировать эту потерю прибавкой к зарплате.
От HR я узнал, что этим самым оскорбил банк до глубины души. Они правда не считают, что хоть сколько-нибудь хуже Thoughtworks. Более того, подозреваю, что где-то существует подписанный документ, подтверждающий это.
Хотя звоночки были уже на собеседовании
Меня брали, чтобы я помог командам писать код лучше.
Это как раз то, чем я занимался уже лет пять и, чёрт подери, умею. Но мне сказали, что код лично мне писать не придётся.
А придётся писать регламенты.
Что-то вроде:
«Регламент 001 на использование TDD в рамках процесса разработки системы».
«Регламент 002 о порядке применения регламента 001».
«Регламент 003 о внесении изменений в регламент 002». | 1 752 |
| 15 | Помните, я рассказывал про софтину из 50 микросервисов? На прошлой неделе мне показали изделие уже из 80! В код я ещё не смотрел, но, зная, какие задачи оно решает и сколько у него пользователей, всё это выглядит как нечто избыточное.
Я даже боюсь представить, сколько человекочасов там закопано в инфраструктуру, интеграции, деплои, мониторинг и прочую деятельность, которая никак не приближает никого к решению задач и какие последствия для отрасли в целом имеет такой подход.
Чтобы не было недопонимания: мы не говорим что микросы не нужны. Проблема в том, что благодаря хайпу прошлого десятилетия (а точнее армии мутных татуированных типов, которые разбираются разве что в средствах для ухода за бородой своего парня) микросервисы впаривали направо и налево. Мы с Серёжей даже видели курс, где единственным обоснованием их применения было что-то вроде "куда же в 2k1x без микросервисов" (я сейчас не утрирую).
Хайп прошёл и многие уже успели на собственном опыте узнать, сколько стоит поддержка распределённой системы, которая никогда не должна была быть таковой. Но расслабляться рано. Те же самые люди, которые вчера продавали микросервисы как универсальное решение всех проблем сегодня с тем же энтузиазмом продают вайбкодинг. | 2 057 |
| 16 | Тут, оказывается, вышел OWASP Top 10 2025.
Из интересного (на мой взгляд):
Software Supply Chain Failures — теперь на 3-м месте. Если старый A06:2021 в основном смотрел на зависимости (поставил старую или уязвимую библиотеку — получил дыру уровня Log4Shell), то теперь речь идет уже обо всей цепочке поставки ПО: репозитории, CI/CD, IDE, механизмы обновлений. Атакуют не только сам пакет, но и весь путь его доставки. Например, через компрометацию мейнтейнера, взлом вендора с последующей поставкой зараженных зависимостей и библиотек и т.д. То есть неприятный сюрприз может приехать от вполне легитимного поставщика. Если раньше такие истории считались скорее экзотикой, то теперь они добрались до 3-го места (особенно с учетом возможностей ИИ).
Mishandling of Exceptional Conditions — новый пункт. Суть в том, что приложение некорректно реагирует на сбои: неожиданный ввод, обрыв сети, нехватку памяти, ошибки БД и прочие нештатные ситуации. В результате проблему либо не замечают, либо никак на нее не реагируют, а иногда пользователю вообще отдают полный стектрейс. Здесь, кстати, есть неявная связь с вайбкодингом: ИИ очень любит упрощать подобные моменты. Про корректную обработку ошибок я даже рассказывал на Подлодке. Приятно все-таки иногда угадывать тренды — примерно как с девальвацией навыков кодинга в последние годы.
Как минимум рекомендую ознакомиться. | 2 130 |
| 17 | Время страшилок: деплоймент из закрытой комнаты.
Когда меня уволили из Thoughtworks два года назад, я чуть не попал в местный банк BOU (название изменено). О его корпоративной культуре ходили легенды, которые ужасали даже китайцев.
Недавно я познакомился с человеком, который как Thoughtwork'er проработал там целых три месяца.
Три месяца. По местным меркам это уже ветеран и носитель сакральных знаний.
Сейчас расскажу об особенностях разработки. Заваривайте чаёк.
Деплоймент из закрытой комнаты
Хотите задеплоить фикс на прод? Включить VPN, выполнить команду или в крайнем случае нажать кнопку Deploy Prod на дашборде CI/CD? Нет!
Деплоймент происходит только из специальной комнаты, которую можно открыть только изнутри. Да, именно так.
Во время деплоймента у вас за спиной будет стоять ещё один человек. А за его спиной будет висеть камера.
И да, это значит, что в этой команде постоянно кто-то должен находиться в комнате даже тогда, когда никакого деплоймента нет. Даже сейчас. У меня нет идей зачем.
Подготовка к деплойменту
Всем вендорам банк платит по факту деплоймента в прод, а не по отработанным часам, поэтому мой товарищ был кровно заинтересован в том, чтобы его проект всё-таки увидел прод.
Но чтобы попасть в закрытую комнату, нужно получить sign-off на деплоймент.
Занимается этим деплоймент-менеджер.
Мой друг начал регулярно задалбывать этого менеджера вопросами о том, получил ли он все необходимые подписи.
Через непродолжительные два месяца менеджер радостно сообщил, что разрешение наконец получено, и достал из стола внушительную папку документов.
На каждом листе стояли подписи разных вышестоящих начальников.
Были ли там распечатки кода — история умалчивает.
Но после истории с комнатой я бы уже ничему не удивлялся. | 2 049 |
| 18 | Энтерпрайз-код 11/10
Небольшой пятничный кек. Коллеги поделились кулстори. Есть некая система, которая ходит к этим самым коллегам по HTTP и периодически присылает кривые жсоны. Например:
{
"id": 123123,
"name": ,
"attr": false
}
То кавычки забудут, то ещё чего.
Как такое возможно, спросите вы? А всё потому, что этот жсон формируется огромным 30-этажным SQL-запросом из coalesce и конкатенаций. Что-то типа:
-- job security 99lvl, LLM себя из розетки выключит увидев такое
SELECT concat('{','"id":',t.id,',','"name":"',coalesce(coalesce(u.name,(select name from users where id=t.user_id and rownum=1)),' '),'",','"attr":',case when row_number() over (partition by t.user_id order by t.created_at) = 1 then lower(cast(t.attr as varchar(10))) else lower(cast(t.attr as varchar(10))) end,',','"settings":{','"lang":"',coalesce(u.lang,(select lang from user_prefs where user_id=t.user_id and rownum=1),'ru'),'",','"theme":',case when u.theme is null then 'null' when u.theme=1 then '"light"' when u.theme=2 then '"dark"' else concat('"',u.theme,'"') end,',','"notifications":',coalesce(cast(u.notif as varchar),(select cast(prefs as varchar) from user_prefs where user_id=t.user_id and rownum=1),'false'),'},','"roles":',(select concat('[',string_agg(concat('"',r.role_name,'"'),','),']') from user_roles r where r.user_id=u.id group by r.user_id),',','"history":{','"prev_name":"',lag(u.name) over (partition by t.user_id order by t.created_at desc),'",','"next_name":"',lead(u.name) over (partition by t.user_id order by t.created_at desc),'"},','"recursive_check":',case when t.id=(select max(id) from requests where user_id=t.user_id) then concat('"FINALLY_',t.id,'"') else concat('"NOT_FINALLY_',(select concat('SUB_',t2.id) from requests t2 where t2.user_id=t.user_id and rownum=1),'"') end,case when exists(select 1 from dual where t.id>0) then ',' else '' end,'}','}') as json_response FROM requests t left join users u on t.user_id=u.id where t.status='active' and row_number() over (order by t.created_at)>0 order by t.created_at desc
Я даже не знаю, как это комментировать и сколько SQL-инъекций с прочими уязвимостями сидит в такой конструкции. Зато теперь понятно, почему на просьбу добавить новое поле они реагируют так нервно.
В общем, отдать JSON прямо из базы можно через какой-нибудь json_agg, но не напрямую же (наверное, это будет недостаточно энтерпрайзно, да и админа БД просто так, что ли, нанимали?) | 2 058 |
| 19 | Случилась очередная офигительная история у Meta (Компания Meta, владеющая Facebook, Instagram и WhatsApp, запрещена в РФ и признана экстремистской) с их AI. Если коротко, злоумышленники разговорили ИИ-ассистента, уговорили его сменить email на свой и сбросить пароль (социнженерия, только для нейросетки). Бот без проблем отправил код подтверждения на новый адрес. Даже двухфакторка не спасла. Говорят, спёрли кучу аккаунтов (сколько именно — молчат). Пример эксплуатации по ссылке.
Дайте непонятно как работающей штуковине полный доступ, повесьте на неё критически важные процессы. И что может пойти не так? | 2 396 |
| 20 | Не так давно писали про выкрутасы вендоров, а теперь случилось страшное: у них закончились деньги. По стону в кулуарах наблюдаем следующее — оказывается, у заказчиков и клиентов деньги тоже понемногу заканчиваются или хотя бы приходится их считать. Кто-то переходит на четырёхдневку, кто-то сокращает разрабов. В общем, приятного мало. Самая мякотка — у некоторых проблемы начались из-за технического долга. Если раньше, когда мы с Серёжей заикались о техдолге, нам снисходительно говорили: «ой да мы тут просто баблом зальём/людей наймем/etc, ты не сечёшь», — то теперь ВНЕЗАПНО это бабло кончилось, а проценты платить всё равно нужно. Наверное, надо просто побольше татуированных ажаиль-коучей нанять ИИшки внедрить, тогда точно придём к успеху. В общем, запасаемся попкорном и надеемся, что нас пронесёт.
А что у вас происходит? | 2 087 |
