Будни разработчика

#ссылка дня Поскольку не говорить про ИИ и агентсткую разработку не получается, давайте пробовать хотя бы извлекать из этого пользу. Многие боятся (возможно, небезосновательно), что мы все забудем как писать код. Что пропадёт тот самый обмен опытом, умениями, лучшими практиками и так далее. Вот только... Вот только пока что всё ровно наоборот! Все же знают, что такое skills? Буквально — умения. А skills в контексте ИИ-агентов — это буквально описание лучших практик. Вот это делай, вот это не делай, а в случае таких-то условий, поступай вот так. Люди создают целые маркетплейсы скиллов, конкурируют за лучшие из них, пишут решения для своей работы. А самое главное, скиллы — это, буквально, текст! Который и прочитать может кто угодно. Да, сжато, но всё же. Ладно, к чему это я. Anthropic выкатили гайд по созданию скиллов. Да, формально — для Claude, но все известные мне инструменты подхватывают скиллы Клода вообще без проблем. И почему-то по принятой в западном сегменте интернета традиции — в абсолютно ублюдочном формате презентационного PDF на 33 страницы. К счастью, нашёлся человек, который не только перевёл это на русский, но и оформил в виде нормального веб-решения: https://fkonovalov.github.io/claude-skills-guide-ru/ fkonovalov, спасибо! :) #ai #skills

#статья дня Как вообще меняется JavaScript? В блоге Bloomberg вышла интересная история про Temporal — новый API для дат и времени. Но статья на самом деле не столько про сам API, сколько про то, как такие вещи вообще появляются в языке. Объект Date появился в JavaScript в 1995 году и, по сути, был просто позаимствован из Java. Тогда это казалось нормальным решением. Спойлер: нет. Проблема в том, что веб сильно вырос, а Date почти не менялся. Со временем стало понятно, что работать с датами в JavaScript неудобно: таймзоны, переходы на летнее время, странный парсинг строк. Экосистема ответила библиотеками вроде Moment.js, date-fns и Luxon. Их скачивают десятки миллионов раз в неделю — почти каждый проект как-то решает эту проблему. В 2017 году появилась идея сделать нормальный API прямо в стандарте. Так началась история Temporal. Дальше — девять лет обсуждений и доработок. В работе участвовали инженеры из Microsoft, Google, Mozilla, Bloomberg и Igalia. Предложение прошло весь процесс TC39 и в итоге стало крупнейшим добавлением в ECMAScript со времён ES2015. Любопытная деталь: для реализации Temporal разработчики движков даже сделали общую библиотеку на Rust — temporal_rs. Редкость! Ещё, конечно, поражает количество тестов. В общем, это хороший текст про то, как вообще принимаются изменения в современном JavaScript. Стадии, обзоры альтернатив, обсуждения. Почитать: https://bloomberg.github.io/js-blog/post/temporal/ #javascript #temporal

#событие дня Я понятия не имею, как я пропустил! Итак, соревнование March MadCSS! 16 лучших фронтенд-разработчиков схлестнутся в жаркой битве по вёрстке интерфейсов. Ну, я надеюсь, вам что-то говорят имена Josh Cameau, Wes Bos, Kyle Cook, Chris Coyier... если нет — очень зря! Первый раунд был неделю назад и его можно посмотреть на YouTube: https://www.youtube.com/watch?v=nuxSFTjXrhI А второй как раз будет сегодня. И да, даже лучшие верстальщики мира гуглят, как выровнять текст. Сайт ивента с турнирной таблицей и мерчом: https://madcss.com/ Смотрим? #css #dev #battle

#инструмент дня Иногда мелкие неудобства в разработке настолько привычны, что мы перестаём их замечать. Один из таких примеров — бесконечные localhost:3000, localhost:5173, localhost:8080. Запускаешь несколько сервисов — фронтенд, API, сторибук, документацию — и через час уже не помнишь, что было на каком порту. Перезапустил сторибук — и он уже на другом. Бесит. В Vercel Labs решили попробовать убрать саму причину проблемы и выпустили экспериментальный инструмент Portless. Идея очень простая: вместо портов использовать локальные доменные имена. Было так:

    
        
http://localhost:3000
http://localhost:8080
http://localhost:5173
{}
    

Стало так:

    
        
http://app.localhost
http://api.localhost
http://docs.localhost
{}
    

Домены просто пробрасываются на реальные порты. Но разработчику больше не нужно их помнить. Самое интересное — почему это вообще стало возможным. Несколько лет назад в спецификациях закрепили правило: любой домен вида *.localhost должен автоматически резолвиться в loopback-адрес (127.0.0.1). Браузеры реализовали это поведение, поэтому api.localhost, app.localhost и любые другие подобные имена гарантированно указывают на ваш компьютер и даже считаются безопасным контекстом для веб-API. Это открыло путь для инструментов, которые делают локальную разработку похожей на продакшен и больше не вспоминать, где был :3000, а где :5173. Такая схема неожиданно удобна и для AI-инструментов. Когда адрес сервиса всегда один и тот же (app.localhost), кодовые агенты не ломаются из-за того, что dev-сервер внезапно переехал на другой порт. В общем, такое мы одобряем. Впрочем, никто никогда не мешал поднять локальный nginx и делать вообще что угодно. #dev #port

Я довольно часто вижу тексты про выгорание и «научитесь отдыхать», и каждый раз немного спотыкаюсь об один момент. Там обычно много советов про хард-стопы, не писать после восьми, не работать в отпуске — и это всё, конечно, правильно. Но создаётся ощущение, что проблема будто бы решается просто дисциплиной: возьми и выключи работу из головы. Вот в тему поста Димы из Яндекс Лавки — поймал себя на мысли, что на практике это у многих работает чуть сложнее. Мозг продолжает крутить работу не из вредности. Он просто пытается дожевать то, что осталось незакрытым: нерешённую задачу, странное решение, ощущение, что что-то пошло не так. И сколько ни говори себе «стоп», если внутри висит этот незакрытый хвост — он всё равно будет возвращаться. Иногда помогает довольно простая вещь: довести мысль до какого-то финала. Принять решение. Даже если это решение — «ну и чёрт с ним». Недавно у меня сломался чемодан — крепление колёс. Первый раз починил. Второй раз починил. На третий раз даже приготовил всё для ремонта — и вдруг понял, что это уже какой-то чемодан без ручки. В итоге просто вынес его на помойку. Тоже решение проблемы. И удивительным образом после этого голова про чемодан больше не думает вообще. С рабочими задачами часто так же. Иногда мозгу нужно не «перестань думать», а точка: решение, план, отказ, перенос, признание, что это не стоит времени. Как только она появляется — он обычно довольно охотно отпускает.

#инструмент дня Я в универе постоянно делал презентации для своих работ и семинаров. Ну просто как минимум потому, что старание — это всегда плюс балл не только к оценке, но и к репутации. Это, кстати, вполне себе лайфхак. Пишите лабы по программированию на двух языках, делайте нормальные доки — и будет вам легко. Но не суть. Я сильно пристрастился к тачпаду на ноутбуке, потому все визуальные задачи, где нужно было мышевозить, давались с трудом. Когда готовишь документ, горячие клавиши спасают, а уж сейчас всё сразу в Markdown по-умолчанию пишешь и голова не болит. Но вот презентации и электронные схемы — дело другое. И если для схем я ещё готов подключить мышь, напрячься и так далее, то презентации я писал на HTML, используя https://revealjs.com/. Но инструмент, который хочу показать сегодня — это https://sli.dev/ Что он делает? Из видео, в общем, понятно — преобразует Markdown-файлы во всё те же презентации! Это очень круто, почти один уровень с Mermaid по удобству. Горячая рекомендация. #markdown #tool #presentation

#заметка дня Минутка дедовского нытья после очередного разговора про LLM-кодинг в очередном чатике. Иногда хочется задать собеседнику очень простой вопрос: а ты вообще пробовал ну… читать? Не «читать книги, чтобы стать лучше». А в рабочем. Читать текст. Потому что если так посмотреть, почти всё, что мы делаем с кодом, — это именно чтение. Мы читаем код. Читаем результаты поиска. Читаем ошибки. Читаем документацию. Читаем чужие pull request’ы, логи, комментарии, ответы в чатах. Писать зачастую приходится намного меньше, чем читать и разбираться в уже написанном. И на этом фоне довольно забавно выглядят разговоры про ИИ. Постоянно всплывает вопрос: «а кто будет ответственен за код?» или «а что он там вообще делает?» В смысле, блин, что делает?! Ты читать-то пробовал?! Вся ирония в том, что ИИ как раз очень много пишет. Пишет, что собирается сделать, показывает diff, объясняет шаги, ссылается на документацию. В конце ещё и резюмирует результат. То есть по сути ведёт подробный текстовый отчёт о своей работе. Я Copilot, зачастую, даже тормозить успеваю в процессе раздумий, ну потому что вижу, что начинает думать херню. И это, внезапно, оказывается удобным способом учиться. Можно спросить, почему он сделал именно так. Можно вытащить из ответа незнакомый термин и пойти почитать отдельно. Можно, наконец, разобраться в библиотеке или подходе, до которого раньше не доходили руки. Причём, как ни странно, это ещё и хорошо помогает с двумя вещами, которые знакомы почти каждому разработчику: страхом чистого листа и синдромом самозванца. Потому что у вайбкодеров из отдела продаж или у дизайнеров, которые прям щас утверждают, что готовы тебя заменить, никакого синдрома самозванца не наблюдается. Потому что перед тобой уже не пустота и не абстрактное «сделай систему», а текст: код, diff, объяснение, план действий. Дальше по накатанной. Поэтому когда разговор снова возвращается к классическому «а кто будет ответственен за код», мне каждый раз кажется, что проблема на самом деле не там. Проблема не в ИИ. Проблема в том, что всё это требует одной довольно старой привычки — читать. А ты так и не научился. #llm #work

#инструмент дня Тактильный отклик на телефонах — штука потрясающая. Конечно, лучше когда он реализован линейным актуатором, но и обычная вибрация сойдёт. Обратная связь в играх, уведомления об успехе-неуспехе, просто подтверждение действия — вот это вот всё. Правда, думаю, из-за избыточного использования вибрации в DuoLingo, Taptic Engine на моём iPhone и разболтался... Так вот, давно уже существует API navigator.vibrate(). Позволяет ли Apple его использовать на своих устройствах? Конечно же, нет. Но при этом есть интересная штука. На iOS любой чекбокс можно превратить в переключатель атрибутом switch. И что делает такой переключатель, когда на него нажисают? Правильно, откликается вибрацией. И это могло остаться незамеченным, но нашлись люди, которые на базе одной только этой штуки сделали целую библиотеку обратной связи! Встречайте: https://haptics.lochie.me/ Одиночные сигналы, паттерны вибрации — вот это вот всё. Не, ну вы понимаете, да? Создают виртуальные переключатели и теребонькают их. Fuck you Apple в чистом виде. Результат весьма убедительный. Надеюсь, это немного заставит Apple пересмотреть политику в API браузера. #vibrate #haptic #taptic

15 марта у Яндекса пройдёт митап AI Dev Day — встреча про реальный опыт внедрения AI-инструментов в процессы разработки. Вместе с инженерами и руководителями из Яндекса, Авито, Сбера, Т-Банка и Ozon будем обсуждать, как компании внедряют AI в разработку, какими метриками пытаются измерять его влияние и какие проблемы возникают на практике. Сейчас почти у всех в работе есть AI-инструменты, но главный вопрос остаётся тем же: как понять, что это реально ускоряет разработку, а не просто создаёт ощущение продуктивности. Из программы особенно интересен доклад Андрея Попова (Яндекс) про то, как команды подходят к оценке эффективности AI-инструментов и какие сигналы вообще можно считать доказательством пользы. Когда речь идёт о больших кодовых базах и десятках команд, измерить влияние AI оказывается гораздо сложнее, чем кажется. Формат будет полезным не только для ML-инженеров — это скорее разговор про разработку вообще: backend, frontend, мобильные команды, аналитиков и тимлидов, которые уже используют AI-инструменты и пытаются встроить их в процессы. 📅 15 марта 📍 онлайн + офлайн в Москве (офис Яндекса в Красной Розе) Программа и регистрация

#заметка дня Продолжение эпопеи про пульт для телевизоров на Flutter. В последнем посте я писал об неком подобии игры в CTF на сайте Samsung Apps. Что появилось с тех пор? Вообще, достаточно многое, но сейчас — чуть более прозаичная тема. Как это обычно бывает, иногда приходится внимательно смотреть, как те же задачи решают другие. Наткнулся на один пример, который идёт ровно по поему плану. Удивило, что у них — одна кнопка для play/pause, как на обычных пультах. Я был почти уверен, что без реального знания состояния плеера это корректно не сделать. Стало принципиально интересно, как они это реализовали. Попробовал декомпилировать через Ghidra — толком не вышло. Кроме строк ничего полезного вытащить не удалось, и там — ничего примечательного: ни скрытых команд, ни дополнительных кнопок. Тогда пришлось идти по сетевому следу. Поднял сервер, отвечающий на SSDP-запросы, начал сниффать весь трафик на предмет поисковых строк, логировать каждый запрос и его аргументы. Многие вещи пришлось копировать с реального телевизора — в том числе DMR-запросы (Digital Media Renderer, часть стандарта DLNA), через которые устройство объявляет и принимает мультимедийные возможности. Больше всего времени ушло на корректный ответ токен-авторизации: нужно было добиться, чтобы приложение приняло фейковый ответ. Ирония в том, что моё приложение в своё время вообще не проверяло формат ответа и не ждало подтверждения — вроде как получил токен и достаточно. Убил пару часов, а оказалось... ...оказалось эти гении просто отправляют pause и ставят у себя флажок. Следующее нажатие — play. Потом снова pause... ну вы поняли. Если видео не играет — нажать надо два раза. А если с другого пульта остановить воспроизведение — тоже. Я ожидал API, а получил социальную инженерию, на которую сам и попался. Надо было просто потестировать дольше минуты. Тем временем мой пульт уверенно движется к релизу: аккуратно выглядит на разных мобильных устройствах, на десктопах появились горячие клавиши, помимо Samsung Tizen теперь частично поддерживается и LG webOS, а ещё можно кастить фотографии на экран телевизора. Для публикации в Google Play нужно 12 тестировщиков — если хотите поучаствовать, буду рад услышать. #flutter #remote #smarttv