Проблема не в ТЗ, проблема в тебе

Я часто сталкивался с проблемой плохо составленного ТЗ. В начале карьеры, остужая жопу после очередного возгорания, я думал:
«Это просто конкретная компания ничего не понимает»,
«Просто они маленькие»,
«Просто они бедные чтоб нанять, аналитика»,
«У них нет нормальной культуры».
Но с опытом понял: это не зависит ни от размера компании, ни от процессов, ни от “культуры”.

Конечно, можно сказать:
«Я сюда пришёл код писать, а не разбираться с хотелками бизнеса»,
«Как оплачено — так и нахуячено».
И в этом есть доля правды. Но только доля.🤷

Во-первых, перекладывание ответственности — это детская позиция.
Почему? Потому что в ней нет причинно-следственных связей. А если их нет, значит, лобные доли ещё не дозрели. То есть ты либо ребёнок, либо идиот. Давай выберем первое — хотя бы будет надежда.

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

Во-вторых, те, кто пишет ТЗ, часто сами не до конца понимают, чего хотят в итоге.
Хорошо это или плохо — неважно. Это просто факт.
И если ты им не поможешь — тебе же потом с этим возиться. Ты будешь 100500 раз вносить правки, плодить новые баги, и снова возвращаться к пункту №1 — горящей заднице.

В-третьих, ты же профи, да?
Код сам по себе — сферический конь в вакууме.
Хоть миллион строк напиши — если они не решают проблему человека, это просто миллион строк. Бесполезных, прям как твоя бывшая.

Компания, где ты работаешь, зарабатывает на решении чужих проблем.
Проблема клиента → проблема компании → твоя проблема.
Цепочка простая. И раз уж она заканчивается на тебе, именно ты можешь сделать так, чтобы всё не развалилось.

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

Потому что если ты этого не сделаешь, то гореть тебе. И не только по срокам. Такие дела.

Презентация Apple убила Flutter?

После очередного WWDC интернет гудит спорами - годно ли “жидкое стекло”, или это нечитаемое дерьмо? Что, в целом, ожидаемо. Каждая презентация вызывает кучу споров, и это уже стало нормой. Казалось бы, при чём тут Flutter?

Под весёлые мемасики вылезли KMP-шники и реактивщики с криками: «А мы уже умеем работать с Liquid Glass, а Flutter - нет! А еще в iOS 26 beta 1 выпилили JIT, теперь уж точно Flutter умрёт». С такими лозунгами ребзи удалились раскидываться по интернету какашками и копать очередную могилу.

Правда, они забывают, что в самом начале у Flutter не было JIT, да и решение этой проблемы уже давно готовится командой. Скорее всего, будут шаманить над AOT-компилятором с резервным интерпретатором для hot reload, так что скорее всего изменений в производительности при дебаге не заметим.

Такие дела.

https://www.reddit.com/r/EmulationOniOS/s/KwGXTmB4Nn

Пока Хабр проводит миллиард проверок статьи, решил продублировать её здесь.

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


https://telegra.ph/Tehnicheski-dizajn-06-16

Комьюнити не заставило долго ждать

В дополнение к посту

Не прошло и недели, а проблема наличия Liquid Glass на Flutter решена.

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

Видимо хейтерам снова придется прятать лопаты. Похороны отменяются…

Пакет

Спустя почти неделю Хабр наконец опубликовал мою статью.

Причин может быть две: либо дело в новом аккаунте, либо в скорости модерации. Какой из этих вариантов верный - узнаю в следующий раз.

Волна лейоффов, экспоненциальный рост возможностей AI, миллиард статей и видео на тему «когда тебя заменит AI». Что вообще происходит и чего действительно стоит ждать?

А сегодня в завтрашний день не все могут смотреть. Вернее, смотреть могут не только лишь все. Мало кто может это делать.

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

Сначала - почему пришлось потратить много времени. Я не гонюсь за охватами - для меня качество важнее количества (по крайней мере, когда речь о контенте). А для качественного анализа нужно много данных, мнений лидеров индустрии, практических кейсов и т.д. Плюс - пришлось самому потыкать и поковырять немало моделей, ну и n8n конечно же.

Если коротко: для оптимизации рутинных задач, облегчения обучения и быстрого поиска - LLM'ки моё почтение.

Но, как обычно, есть и обратная сторона медали. За такими инструментами НУЖНО следить. Ждать волшебной таблетки не стоит. С дуру можно и рак 4 стадии нагуглить при головной боли.

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

Недавно старина Сэм (Альтман) опубликовал эссе, где поделился своим видением будущего. Привёл расчёт стоимости GPT-запросов в ватт-часах и галлонах воды, говорил про горизонт возможностей, и вообще - много всего наговорил. Но если смотреть в целом:

Что меняется?
Возможности ИИ повышают продуктивность и усиливают человека - ДА
Разница между специалистом и новичком всё ещё есть - ДА
В одного стало легче собрать проект - ДА
Пробелы в знаниях можно закрыть при помощи ИИ - ДА, но если у тебя есть база
Обучение новым технологиям стало проще - ДА
Скорость реализации выросла на порядок - ДА, но только если ты понимаешь, что делаешь

Получается, можно уволить половину разрабов и заменить их LLM? И да, и нет.

С одной стороны, как показал кейс X (Twitter), можно сократить половину штата и не увидеть провала в качестве, даже без активного внедрения LLM. С другой стороны - можно просто разослать письма работникам с угрозами проверить их скилл работы с LLM. Ну мы же теперь AI-first, правильно?
Почему такая стратегия может быть эффективной? Потому что рынок незрелый и разбалансированный. Спрос на специалистов большой, а качественных предложений - немного. Джуны борются за офферы в кровавой мясорубке, сеньоры устраивают "Голодные игры" для HR.
Крупные компании часто нанимают «на вырост», потому что если ты не пылесосишь рынок - за тебя это делает конкурент. А в момент, когда надо резко масштабироваться - ресурсов нет. Тогда включается стратегия: x3 к зарплате, тайская массажистка и доставка колумбийского кофе прямым рейсом. Работает - но только пока деньги дешёвые.
Как только начинается кризис, компании начинают выравнивать баланс, и первыми под нож идут эти избыточные косты. Рынок балансируется.

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

Ну окей, увольнять всех не будем, качество вырастет - и всё?
А вот тут самое интересное.
На мой скромный взгляд, наступает эра маленьких команд и соло-разработчиков.
Теперь ты можешь компенсировать нехватку ресурсов через LLM. Если фокусироваться на оркестрировании агентов, ты можешь покрыть сразу несколько ролей - и не сильно просесть в качестве (если сосредоточен и понимаешь процесс).
Важно понимать: огромные проекты по-прежнему требуют толпы людей, документации и бюрократии.

Но вот если ты делаешь небольшой нишевой проект сам или с маленькой командой - LLM становится твоей волшебной палочкой.
И это интересно не только вам - маленьким/соло командам. Это начинает интересовать и инвесторов. Почему? Потому что меньше людей = меньше костов.

Звучит логично? И в подтверждение — Bloomberg недавно выпустил статью:
в условиях дорогих денег и кризисного климата выручка компании становится вторичной. Главное - отношение метрик к фонду оплаты труда.

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

В заключение:
Если ты боишься LLM - значит, тебя напугали.
Такие дела.

Ты должен был бороться со злом, а не примкнуть к нему

С 2026 года верификация Android приложений станет обязательной. Делается это, конечно же, «в целях безопасности пользователей».

Пока что это выглядит как выстрел себе в ногу. Долгие годы в спорах между андроедами и яблочниками главным аргументом первых была возможность устанавливать APK из любых источников.
Если в Android действительно нельзя будет отключить проверку подписи APK, то останется 0 причин не перейти на iOS.

Ребята на Graphene и других альтернативках - к вам вопросов нет…

Подъехало обновление Flutter Handbook от Яндекса.

Первая версия была крайне урезанная, видимо прогревали гоев😅

Работа проделана большая, читать достаточно приятно. Да, некоторые темы не до конца раскрыты (прим. работа с нативом), но это не отменяет всего объема.

Кто-то скажет кровавый энтерпрайз, но ребята отдают медятину бесплатно.

В ожидании нового дизайна решил не сидеть сложа руки в вечер пятницы и устроил своему проекту небольшой субботник. Но как показала практика небольшой превратился в достаточно БОЛЬШОЙ.

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

Под переработку попали база данных и сервисы.

🎯 Общая статистика
• Добавлено строк: +5 563
• Удалено строк: -398
• Тесты: 39 -> 223 (+472%)
(да, я тоже удивился)

Теперь подробнее

1. Оптимизация БД
Переписал часть запросов, добавил индексы, улучшил производительность.
Да, можно было сделать это сразу, но я торопился собрать pre-MVP и проверить гипотезы. Теперь вот разгребаю 😂

2. Рефакторинг сервисов
- оптимизировал запросы
- добавил документацию
- обновил тесты
- навёл порядок с валидацией изображений

3. Полностью переработал Экспорт/Импорт бэкапов
Теперь есть шифрование (local/password/hybrid), инкрементальные бэкапы, автоматические сохранения, ротация старых копий, валидация и статистика.

Бонус: раскопки косяков

Нашёл классическую проблему N+1 (привет усталости и желанию закончить побыстрее).

Что получилось :
• 500 запросов -> 4 запроса
• 5-10 секунд -> 8 ms на 100 элементов (примерно в 500 раз быстрее)
• добавил batch-операции
• перешёл на type-safe Drift API вместо customSelect

Вот такой продуктивный субботник получился 💪

Получил книгу от Ever Secure аккурат к отпуску. Читается легко, местами орал в голосину.

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

По вайбу - чистые «Вредные советы» из детской книги. Время идет, советы не меняются.

Из любимого.

Если хотите максимально ускорить Time-to-Market и при этом устроить ад для безопасников, просто игнорируйте всю «формальную часть» проекта. Не давайте покоя менеджерам, заменяя реальные документы на какой-нибудь нескончаемый поток воды или абракадабру, создавайте легенду о том, что документация - для слабаков, а вы тут настоящий профессионал, который творит, опираясь только на вдохновение.

Классика жанра. Хотя апогей когда менеджер говорит: «Нет времени на доку, просто запомни, что ты сделал».

Как превратить баг в фичу за 3 шага - Переименуйте проблему
Пример:
Баг: «Приложение крашит телефон».
Фича: «Функция экстренной разрядки батареи для цифрового детокса».

Это уже не «не баг, а фича», это почти дзен.

Мы же не хакеры. Мы интерфейсы рисуем и пишем код. Миндальный рафф, пожалуйста....

Почему-то до сих пор считается, что безопасностью занимаются девопсы и бэкенд, а фронтам надо просто кнопки красить. Спасибо чёрным шляпам за то, что часть фронтендеров уже в курсе, что localStorage с нешифрованными данными идея так себе, и что в поле имя пользователя вполне может прилететь скрипт (привет, XSS).

А вот когда начинаешь говорить об этом с мобильными разработчиками, глаза округляются до максимума.
SQL-инъекция? В мобильном приложении? Да вы что, так не бывает!

Бывает. И это, если честно, довольно стрёмно.

Оценка стоимости актива по учебнику:
в "Сколько компания потеряет, если актив недоступен в течение суток?"
Оценка стоимости по практике:
о. "Сколько мы готовы заплатить хакерам, чтобы получить его обратно прямо сейчас?"

Комментариев не требуется.

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

Немного здоровой паранойи ещё никому не вредило ни продукту, ни бабуле, которая шлёт внукам открытки в WhatsApp.

Такие дела.