На маке меня всегда бесило, когда скачиваешь какой-нибудь текстовый файл (.log, .md или .sh), мак предлагает открыть его через xcode. Я бы с удовольствием снес бы его вообще, если бы от него половина пакетов из brew не зависела. Как я не пытался выбрать приложение по умолчанию, в следующий раз — снова здорово, xcode.

В итоге мне помогла установка duti:

brew install duti

duti -s com.apple.TextEdit .md all

osascript -e 'id of app "TextEdit"' # чтобы получить id приложения

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

Когда я только пришел в компанию и мне показали процесс управления бэклогом, моя первая реакция была “Bitch, you live like this?”. Появилась работенка, которая хорошо скрещивает сразу несколько моих привычных активностей:

• разгребание и причесывание большого бэклога — в каждой компании такое делал, вот только масштаб тут был не ~500 тикетов, а несколько тысяч, да еще и все публично.
• налаживание процессов — “обожаю” зрелость процессов на уровне “ну как-нибудь образуется” и “да, посмотрю как будет время”.
• “доделывание” — 20% усилий на 80% результата были уже потрачены, я добавил сверху еще 80.
• автоматизация всякой дичи — тут были вертолеты от GitHub и его API, штук пять багов им отправил, а местами настолько все плохо, что приходится парсить HTML :/
• документирование — процессы, принципы, инструкции и т.п.

И это все было побочной активностью, и по большей части было сделано руками, без ИИ. Только в конце, когда разгребал stale тикеты, навайбкодил, прости господи, скилл для поиска дупликатов и воспроизведения багов. Честно говоря, совсем не ожидал хороших результатов от такого, но с учетом того, что решение все равно принимали люди, а результат нейронки был просто вспомогательной информацией, получилось нормально: больше 500 тикетов через него прошло, процент ошибок не очень высокий.

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

Уже в каждом утюге обсудили эту тему, но пусть и у меня будет, чтобы можно было ссылаться.

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

Пришел ИИ, и все стало как в анекдоте (“печатаю 1000 знаков в минуту, правда, такая ерунда получается…”). Начались (продолжились) разговоры, что разработчики не нужны. Проблема в том, что большая часть разработки — это определение требований, выработка понимания предметной области, формализация модели, согласование видения, определение способа решения и т.п., думание мозгами и взаимодействие с коллегами. Написание кода помогает исследовать, но вторично, да и занимает малую часть времени разработчика. А если в компании еще невнятные цели или мутные процессы, то вопросы скорости разработки вообще не очень релевантны. Про согласования с другими командами вообще молчу.

Ок, даже если у вас все хорошо с постановкой задач и прекрасные процессы, то с ускорением кодинга вы просто перенесли нагрузку из одного места в другое, а именно на QA и код-ревью и/или на продактов/аналитиков. И если вы оптимизируете не самое узкое место, то вместо более быстрой системы получаете более сломанную.

Стало дешевле делать прототипы. В том числе ненужные прототипы: да, код стало легче производить, и теперь вместо того, чтобы тратить усилия на другие вещи, кода стало тупо больше: стало тяжелее сказать “нет”. Больше кода → больше расходов на его обслуживание и поддержку. Наконец, не стоит забывать, что готовый код != готовый продукт.

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

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

Сейчас, когда стало очень легко делегировать мышление, часто встречается ситуация, когда кто-то тупо постит вывод нейронки без какой-то обработки. Что весьма грубо: скопипастить сообщение в/из чат-бота кто угодно может, и лишняя прослойка тут ни к чему. Если нечего толкового сказать — лучше промолчать. Чтобы с этим бороться, можно в качестве ссылки указывать no slop grenade или stop sloppypasta. Но если это не очень работает, а коллектив толерантен к токсичности, можно ввести в оборот и более агрессивные методы.

Когда фронтенд собирается из нескольких модулей, то роутинг становится проблемой: хороший UX часто требует на странице из одного модуля ссылаться на путь в другом модуле. Такие связи довольно произвольные, и чтобы избежать связи всех со всеми и циклических зависимостей, надо что-то делать.

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

Окей, может тогда сделаем модуль или файлик под пути с константами и все будут зависеть от него? Это получается почти God-object, со всеми вытекающими. При этом тяжело следить, как модули связаны между собой. И может остаться путь, на который уже никто не ссылается. Есть еще вариации вроде генерации общего файла (например, из путей в модулях) или роутинг на основе расположения исходников (например, “/user/$id” лежит в папке “/user”), но проблемы там похожие. Можно поиграться с динамической регистрацией путей, но это уже рантайм.

Ладно, можно сделать объявление путей локальным для модуля, и сделать по модулю чисто с путями. Т.е. для users будет routes-users с белым списком путей, которые торчат наружу. В этом подходе плохо, что число модулей удваивается.

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

На днях я узнал, что это

[&]<[:_:]>([[=({})]][:(_,_):])[[=^^::,=_]]{}

— валидная лямбда в C++26. Дело Perl живет:)

Недавно я стал довольно много играть во всякие головоломки с этого и связанных сайтов. Головоломки можно разбить на 3 условных категории. В первой я достаточно быстро нашел набор локальных паттернов, и после этого решение ищется легко, практически машинально. Вторая группа уже посложнее: паттерны не очень локальные, и надо смотреть на взаимосвязи нескольких строк или столбцов. Иногда там еще и очень мало корректных следующих шагов, а найти их тяжело. Наконец, третья категория: в ней приходится опускаться до поиска с возвратом (aka backtracking), потому что не ясно, есть ли способ получше.

В какой-то момент для головоломки из последней категории я решил попросить у ChatGPT подсказку. В ответ он мне выдал лабуду, которая противоречит правилам и самой себе. Я парой запросов пытался добиться чего-то более адекватного, но это было бесполезно. Позже я попробовал Claude. Он пыхтел 20 минут, но все-таки выдал подсказку, которую можно было использовать.

И я навайбкодил (прости господи) приложение для решения головоломки (скриншот → подсказка). Опус 4.8 выдал первый результат через час (1 промпт + пара отвеченных вопросов). Я специально выбрал стек технологий, с которым не знаком (предлагался Kotlin/JS, Elm и Rust, но на них у меня есть (руками!) написанные приложения). Разумеется, первые результаты выглядели по-уродски и не работали. Были проблемы с обработкой скриншотов и цветовыми схемами. На их исправления понадобился еще час примерно.

Получившаяся решалка… выдавала тоже лабуду, на уровне ответов ChatGPT. Что странно, с учетом того, что клод в режиме чата справлялся. Позже я понял, что проблема все еще в обработке изображений. Мне даже пришлось самому печатать тестовые данные! Но даже этого было недостаточно. Все еще оставались проблемы с цветовыми схемами. Я временно на это забил и сфокусировался на логике.

Вскоре я нашел пример, который не решался набором правил. К сожалению, пришлось разрешить использовать поиск с возвратом. Потратил весьма приличное время на тестирование и улучшение подсказок, но в итоге все заработало. К сожалению, агент довольно быстро дошел до состояния, когда он думает, что проблема исправлена, но она еще есть. Я увлекся и не сразу осознал, что надо было его заставить на все писать тесты. Другой проблемой был Firefox и его функции безопасности с canvas, но после нескольких отладочных сборок и это починилось. А попутно и проблемы с обработкой скриншотов сошли на нет.

Как и ожидалось, отладка заняла существенно больше времени, чем первый MVP. Несмотря на то, что клод делал основную работу и все заняло больше итераций, чем я ожидал, мне все равно нравится результат. И я ощущаю, что что-то разработал, несмотря на опасения об обратном. Наконец, я стал решать эти головоломки лучше (абсолютно бесполезный навык).

MVP был на грани размера контекста — 99.9% от миллиона токенов (но потом сжал его, конечно). Некоторый код я посмотрел наискосок и совсем не впечатлился, ReScript меня никак не зацепил.

Если интересно, попробовать можно на http://localhost:5050 тут.

Занятное исследование про защищенность сетей спутниковой связи.

Если вкратце — все очень плохо™. 50% соединений не используют шифрование. При этом можно найти кучу конфиденциальных данных — ключи шифрования, звонки, видеопотоки, управление промышленностью, энергетикой, ретейлом, банковские операции и даже данные военных. И все это можно получить с одной точки без дорогого оборудования.

Полтора года назад было занятно попросить ChatGPT сгенерировать картинку, как он вас видит. Но это легко сделать — персонального контекста полно. И сделать это можете только вы. А как вас видят другие люди?

Раньше можно было посмотреть, что знает о вас интернет, загуглив свое имя или ник. Но пользоваться поиском уже не модно, нейронки же! Теперь можно посмотреть, что они знают о вас на уровне весов:

Vlad Chesnokov

ov7a

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