Часть корпоративной культуры — «ценности», которые выдают мудрые C-level мужи устами HR. Идея-то в целом неплохая: когда есть высокий уровень неопределенности и/или требуется принять стратегическое решение, ценности могут скорректировать направление, и их озвучивание поможет в спорах «как правильно» или «кто не прав». На практике они красиво где-то там записаны на портале, и в лучшем случае работяги о них вспоминают, только когда на перформанс-ревью спрашивают про их вклад в аспекте этих ценностей, и еще иногда можно услышать их упоминание в презентации особо воодушевленного и верующего менеджера. Вообще, сходство с религией довольно интересное: есть какие-то заветы, «как надо», можно ими махать у лица, некоторые фанатеют, но реальность полна разочарований. А служители вокруг них пытаются оправдать свою значимость. Простой народ может либо отказаться от этой шелухи, либо следовать формально — чтобы отстали или чтобы помочь коллеге, играя по правилам. Попытка привить ценности будет тщетна, если они не соблюдаются. При здоровой организационной и инженерной культуре прописывать ценности имеет смысл разве что для онбординга: остальные и так следуют им, а культура насаждается личным примером коллег и впитывается из окружения.

Хороший проект, где на одной карте показываются не только исторические границы государств, но и примечательные (выборочные) исторические события и личности.

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

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

Написала ли нейронка хорошее ревью? Нет. Сделала ли она фокус на важном? Опять нет. Может быть, ее вариант хотя бы был вдохновляющим, или там были вдохновляющие идеи? Тоже нет. Ладно, ну хотя бы она смогла все данные собрать, откуда я указал? Да, вы угадали, еще одно “нет”. Окей, ну хотя бы она сжато смогла пересказать результаты и разбить их на категории, это же основная работа ЛЛМ-ки? Да, опять “нет”:)

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

С группировкой нейронка справилась плохо — читала только заголовки, хотя у нее были и подробные описания, и в итоге несколько раз в кучу смешались кони, люди и залпы тысячи орудий (совершенно не связанные друг с другом).

Ну а с фокусом все просто: любая мелкая задача воспринимается с восхищением, как будто это достижение уровня техлида. При этом данные о приоритетах компании и команды были, но сопоставить задачи с ними нейронка не смогла (но это может быть вопросиком к исходным данным). В итоге фокус был совсем не на том, что нужно.

Разумеется, со структурой была шляпа, а ЛЛМ-измы были load-bearing.

В целом конечно польза была, особенно относительно сбора данных и поиска “улик” (хотя заметки все еще писать проще). Еще неплохо работает как резиновая утка и как редактор. Ну и еще как ревьюер, чтобы галочки закрыть. В общем, если не очень важно что там написано, то можно оставить и первый вариант…

Я думал, что основное отличие RISC от CISC — это меньшее количество команд и их простота, и даже писал когда-то про это. Однако смешнявка заставила разобраться в вопросе, и мне объяснили, что ARM активно эволюционирует, и под RISC стоит понимать “короткие инструкции, кодируемые одинаковым количеством байт” (хотя и это не точно, потому что есть расширение для RISC-V с переменной длиной команд). Иными словами, RISC — это скорее про простоту декодера команд внутри процессора.

Просто хорошая техническая статья про оптимизацию структур данных для хранения DNS-кэша: сначала померили, потом определили паттерн и характер данных, выкинули ненужное, подобрали правильные структуры и поигрались с указателями. В итоге — 50% меньше памяти и скорость на 43% выше.

И да, разумеется, эти оптимизации окупаются только на больших масштабах — в типичном приложении (пока) еще читаемость и простота будут важнее.

Одна из немногих книг по программированию, которая произвела на меня в свое время впечатление — The Art of Unix Programming. Примерно в 2007 году, когда я ее читал в бумажном варианте, это еще был свежак (книга 2003 года), но автор стоит на плечах гигантов и, в целом, там написаны довольно базовые принципы.

Не уверен, что она на 100% актуальна сегодня, потому что часть глав — история, а часть могла морально устареть. Однако если почитать принципы Unix из первой главы, то вроде все по делу. Вспоминается давний спор с одним из коллег, где я указывал на превосходство текстового формата над бинарным по умолчанию, в том числе опираясь на тезисы из книжки. А на прошлой неделе вместо паручасового пыхтения с ручным вводом данных в экзотическом редакторе, я сделал за минуту пример, сохранил в текстовый файл, показал агенту исходник и пример, и все было готово за 5 минут.

И кстати, а какие программы агенты используют? Да это же продвинутые пользователи всех базовых консольных утилит. Современная агентская разработка вряд ли была возможна без этого неказистого вороха программ с текстовыми интерфейсами, которые как раз следуют философии Unix…

Когда в 2021 Firefox объявили об удалении поддержки FTP — я немного расстроился, ведь я еще застал времена, когда протокол активно использовался. Причиной называли безопасность, и по делу, но можно назвать и другую: экосистема поменялась, и протокол проще удалить, чем тратить ресурсы на поддержку в коде. Если раньше FTP использовался для шаринга всякого по локалке, для загрузки сайтов и файлов на хостинг и т.п., то сейчас его почти везде вытеснили HTTPS, S3, торренты и т.п. Единственное место которое пришло на ум, — зеркала дистрибутивов, но даже там теперь его убрали. Сейчас поверх HTTP столько оптимизаций накручено, что тяжело найти сферический сценарий в вакууме, где FTP будет лучше.

А FTP мне, кажется, так и не понадобился за 5 лет — так что и правильно, что выпилили его.

Несколько раз натыкался на Fil-C, альтернативный компилятор Си с гарантиями безопасности памяти, но все никак не доходили руки изучить подробнее. А тут вышел хороший доклад от создателя.

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

А так в докладе обозначена проблема, обозначены предыдущие попытки решения (тысячи их), рассказана основная идея подхода (хранить границы рядом с самими указателями) и несколько интересных деталей. А также раскрыта цена — скорость будет меньше в 4 раза, памяти примерно в 2 раза больше, и надо перекомпилировать все зависимости (благо, что для большинства библиотек не надо делать изменений). Приятным бонусом за перекомпиляцию идет безопасность памяти для системных вызовов.

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

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

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

Причем как для процессора, так и для мясного мозга.

Уже неоднократно упоминал это на канале в рамках других обсуждений (например, про количество мониторов) — ну, очевидно же! Но, увы, реальность полна разочарований :(

Исторически я стараюсь на работе делать одну задачу за раз, и фоново получаются всякие чтения чатов и мелочевка. Если цикл обратной связи большой (например, куча тестов вертится на CI) — можно взять параллельно другую задачку, пока первая простаивает. С агентами можно еще какую-то мелочевку взять третьей, но тут мой лимит кончается. Было пару раз, когда я постоянно переключался между 3-4 задачами, и каждой уделял крошечный квант внимания — во-первых, на выходе получалась шляпа, во-вторых, под вечер голова была как вареная. Стараюсь больше так не делать.

Так вот, при этом я слышу как некоторые коллеги хвастаются, насколько они AI-native и рассказывают о 20-30 агентах, работающих одновременно… Выдают ли они результаты хотя бы в 10 раз лучше? Скорее нет. Может, они стали больше делать? Может, но я уже вторую неделю слышу как высокоприоритетная задача все еще в процессе и почти готова (хотя там для MVP дня на два фокусированной работы) — ее делает рой агентов, и задача инженера, как у Микеланджело, выкинуть ненужное (ага, удачи это сделать с тысячами строк баша и сотней коммитов). Про качество даже упоминать не буду.

В общем, агенты — большое искушение делать еще больше, еще продуктивнее, еще быстрее! Но ментальная нагрузка на переключение контекста может съесть всю потенциальную выгоду: ресурсов в итоге будет потрачено больше, а результат не будет гарантированно лучше.