IT

Идеальное помещение для студии звукозаписи Выбор подходящего пространства — ключ к созданию качественной студии звукозаписи, где будет комфортно работать и приятно находиться клиентам. В первую очередь обратите внимание на акустику помещения. Оно должно минимизировать отражения звука и посторонние шумы. Оптимальны комнаты с неровными поверхностями стен и возможностью установки звукопоглощающих материалов. Распланируйте зоны для записи, работы звукорежиссера и зоны ожидания. Помещение должно быть достаточно просторным, чтобы разместить все необходимое оборудование и обеспечить удобство для сотрудников и посетителей. Выбирайте локацию вдали от шумных улиц и с удобным подъездом для клиентов. Очень важна стабильная электросеть с достаточным количеством выделенных розеток для техники. Также позаботьтесь о хорошей вентиляции — чтобы техника не перегревалась, а атмосфера оставалась комфортной. Дополнительный бонус — наличие зоны отдыха и удобных санитарных комнат. Фаундер | Бизнес и Стартапы

Модель тройного долга от соавтора фреймворка SPACE Маргарет-Энн Стори, соавтор фреймворка SPACE для повышения продуктивности разработчиков, недавно представила свою модель тройного долга (Triple Debt Model), в которой скрытые человеческие издержки ускоренной с помощью ИИ разработки программного обеспечения рассматриваются в трех категориях: технический долг, который накапливается в коде. когнитивный долг, который накапливается в людях, входящих в команду. долг намерений, который накапливается во внешних знаниях, состоящих из лежащих в основе проекта соображений, целей и проектных ограничений, которые недостаточно задокументированы. И идея там довольно простая: AI позволяет нам быстрее производить код, но это совсем не значит, что мы автоматически быстрее производим хорошие и понятные системы. Просто долг начинает накапливаться немного в других местах😉 Всего Стори выделяет три вида долга: 1. Технический долг Плохие архитектурные решения, костыли, сложный код, отсутствие тестов и все то, что потом делает систему дорогой в изменении и поддержке. Причем тут есть забавный парадокс. Именно этот долг AI потенциально умеет неплохо сокращать: -отрефакторить код; -написать тесты и т.п. То есть код может становиться даже лучше. 2. Когнитивный долг Это долг, который накапливается уже в голове разработчика: агент написал 1000 строк хорошего кода. И даже тесты все зеленые. Так что вперед и PR в проде. Только инженер, который этот PR принял, понимает систему чуть хуже, чем если бы писал это изменение самостоятельно. А потом еще один PR. И еще один. Иииии в какой-то момент получается довольно странная система: код работает, но никто толком не понимает почему. Скорость производства кода растет быстрее скорости нашего понимания системы. Вот это Стори и называет cognitive debt. И да, тот факт, что скорость производства выросла - это супер! В этом вся суть моей работы, в принципе. 3. Долг намерений — Intent Debt А вот это типовая проблема, которая всплыла наверх. Раньше она тоже была, но мы особо ей внимание не уделяли. Можно прекрасно понимать, как работает код, но совершенно не понимать: почему он работает именно так? Какие продуктовые ограничения существовали? Что вообще хотел пользователь? Какие компромиссы были приняты? Все это обычно живет где-то между: - ADR; - документацией; - и, конечно же в голове того самого Тим-лида😁 А теперь представьте AI-first разработку. Один агент написал изменение. Через полгода другой агент должен его изменить. И второй агент пытается понять намерения первого агента… по коду первого агента. Ну удачи. В мире AI-разработки документация, ADR, спецификации, acceptance criteria и domain model — это уже не какая-то бюрократия рядом с разработкой. Это внешняя память вашей системы (на следующей неделе расскажу, как решают и эту задачку) Причем память нужна уже не только людям, но и агентам. Последние пару лет мы в основном спрашивали: как заставить AI писать больше хорошего кода? Но следующий вопрос будет: как сделать так, чтобы люди и AI продолжали понимать систему, пока AI пишет все больше кода? Потому что код становится все дешевле. А вот понимание: -зачем система существует; - почему она устроена именно так; - какие ограничения нельзя нарушать; становится только дороже. И возможно, через несколько лет главным инженерным активом компании будет уже не сам код. А накопленный контекст вокруг него.

Лучший ход Кажется, я долго искал критерий хорошего архитектурного решения. Сейчас думаю про четыре штуки, которые одновременно делает "лучший ход":

1. Даёт локальную пользу уже сейчас. 2. Уменьшает глобальный разрыв в системе 3. Делает следующий хороший ход дешевле. 4. Увеличивает вероятность того, что этот путь повторят другие.

Последний пункт кажется самым важным. Если решение приходится каждый раз продавливать заново, ландшафт не изменился. Настоящий рефакторинг: изменение формы поверхности, по которой движется вся система, без переписывания кода.

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

Возможно, именно это и является настоящей единицей эволюции сложных систем. Если так смотреть, эволюция сложных систем идёт не через новые объекты, функции или процессы. Она идёт через сдвиги в стоимости следующего перехода. Хороший пример из нашей работы — текстовый daily в Slack по шаблону «доставлено / планирую / блокеры». Проверяется по всем четырём пунктам: Локальная польза сейчас — утром за 2 минуты команда видит, кто чем занят, без созвона. Закрывает разрыв — не нужно дёргать людей в личку «ну что там у тебя», блокеры всплывают сами. Удешевляет следующий шаг — если у кого-то затык, помочь можно сразу, а не когда уже сгорело. Повторяют другие — новый человек в команде заходит в канал, смотрит вверх, копирует формат. Никто не объясняет заново. Форма поверхности изменена: написать по шаблону дешевле, чем не написать. Поэтому шаблон живёт сам, без напоминаний. А теперь посмотрите на свою команду. Поищите такие примеры — где хороший ход стал дешевле плохого сам собой, без напоминаний и продавливания. Делитесь в комментариях. Давайте обмениваться опытом 👇

Вас в Телеге теперь будут категорически приветствовать, а ещё "шептать" В бете новой версии Телеграм для Android нашли намёк на две весьма интересные (но ИМХО спорные) - обе про то, как писать людям так, чтобы не видели остальные. Первая - приветственные сообщения. В настройках группы или канала можно будет сделать несколько заготовок, и Телега покажет их каждому новому подписчику лично. То есть, прям в канале (как последний пост), но только ему, другие не увидят. А через какое-то время сообщение исчезнет вообще. Это такая раскачка новых подписчиков сходу. Ну, ничё так. Слать такие приветики может админ от своего имени (анонимно), или через ботов. Скам-каналы уже делают заготовки "Админ канала хочет с вами связаться" 😂 Вторая фича - "шёпот". Боты (написано именно про ботов, но может и юзеры тоже) смогут слать приватные сообщения конкретному человеку внутри чата. То есть, внутри чата, без перехода в личку, но чтобы их видел только адресат. Примерно как в первой фиче, но только не админ-подписчик, а юзер-юзер. Годится для личных подсказок и точечного контакта без засорения чата и, вероятно, для старого-доброго скама. В общем, если играли в ММО - то механика вас не удивит. Ждём настройку "не шептать мне на ушкО" в Premium 👍 P.S. Это конечно всё круто, но поможет ли это подтвердить возраст в кабэшечке? А? То-то же. Фичизм

Открытие дня. Все же знают dependabot, который обновляет зависимости всего и вся на гитхабе? Причем речь не только про пакетные менеджеры всех языков, но и например github actions и даже версии образов в Dockerfile. Так вот есть такое же решение, не привязанное к вендору. Небольшая предыстория. Помимо гитхаба у нас есть свой гитлаб с большим количеством реп, в котором так же находится инфраструктура запуска практик Хекслета. В нее входит репа с кучей Dockerfile под разные экосистемы, которые мы используем как базовые образы для практик запускающихся в браузере. В этой репе есть просто все что только можно себе представить: версии образов, версии дев тулов, версии зависимостей, причем часто указываемые напрямую в Dockerfile. Обновлять все это добро раньше было отдельным приключением. С иишкой стало проще, но один фиг это процедура, которой надо заниматься. А на днях делая очередное обновление, я подумал какого хрена, по-любому должно же что-то быть. Попросил клод найти и он нашел. Оказалось что есть такая штука как Rennovate, которая очень похожа на dependabot, но работает еще круче. Мало того, что она может обновлять все версии в стандартных случаях, так эта фигня умеет обновлять версии, которые заданы числами в разных местах за счет спец разметки:

# renovate: datasource=maven packageName=org.apache.maven:maven
ARG MAVEN_VERSION=4.0.0-rc-6
# renovate: datasource=java-version packageName=java-jdk
ARG JAVA_VERSION=25

Все это расставил сам клод и написал мне такую таску:

make deps-check 
images/base/Dockerfile            setuptools       83.0.0  -> 84.0.0
images/java-base/Dockerfile       java-jdk       25      -> 25.0.4+7.0.LTS
images/multi-language/Dockerfile  java-jdk   25      -> 25.0.4+7.0.LTS

Ну и все это добро отлично подключается к ci и шлет пулреквесты с обновками. Пользуйтесь