Все так хвалят Cursor, но почему-то никто не пишет про проблемы с Remote SSH.

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

Останусь пока на VSC + Roo + Codeium

Переехали (с webpack) на rspack в рабочих проектах. При всей моей изначальной скептичности — оно работает и даёт стабильное x2 к скорости и холодной и горячей сборки. В абсолютных цифрах для DataLens это 1m 40s -> 0m 50s холодной и 20s -> 8s горячей дев-сборки. И ~5m 16s -> 2m 18s продовой.
Завелось вообще всё, включая Статоскоп.

Так как у нас унифицирована сборка через общую абстракцию https://github.com/gravity-ui/app-builder, то для проектов переезд — фактически переключение галочки в конфиге. Если интересно повторить, то смотреть начиная с этого PR https://github.com/gravity-ui/app-builder/pull/177.

Я ещё понаблюдаю конечно, но пока очень радует.

С тех пор я и не люблю 1 апреля

Раз уж вспомнили о железках. Нужен совет чата

Притащил тут на днях домой 4k+ монитор и пытаюсь его подключить к немолодому системнику с PCI Express 2.0. Оказалось, что ни одна карточка на PCIe 2.0 4k не тянет (в продаже остались только GeForce 710/730). Ну, т.е. тянет, но только на 30Гц =) Но, к счастью, PCIe обратно совместим, потому взял у товарища пыльный, но легендарный GeForce 1050Ti, воткнул, и вроде всё отлично работает. Но шумит!

Потому вопрос. Какую видеокарту воткнуть в немолодой системник, чтобы пропускной PCIe 2.0 хватило и при этом сама карта была тихая и холодная? И без внешнего питания.

Не для игор, в игры мы не играем.

Завтра читаю доклад, но не там где вы подумали (нет, не на Холи). И не для программистов, а для аналитиков. Буду рассказывать биайщикам, как здорово жить с JavaScript

https://yandex.cloud/ru/events/1120

В статье про трейсинг в Deno самое ценное как по мне — это ссылка на OpenTelemetry LGTM stack Графаны. Как раз тут дебажил поддержку OpenTelemetry в нашем @gravity-ui/nodekit, поднял этот контейнер и кайфанул. Подключаем у себя otel-клиент, заводим данные в контейнер, открываем Tempo и наслаждаемся.

И, да, смотрите на скрин, это не просто трейсы между микросервисами, otel сам проинструментировал само node.js приложение.

Вернулся пока на Garmin Forerunner 255. Устал мириться с существенными минусами Suunto, при всей их красоте:

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


Тотальный отказ от MIP продолжает меня огорчать.

Все побежали и мы побежали

Ну как, выбор между Roo и Cline сделали? На Claude, небось? Мемори банки собрали? В своей продукт добавили агента? А моделька в продукте у вас какая — Qwen или DeepSeek? Как так нет локальной модели, а куда вы будете грузить пользовательские данные? А как тюнили под задачи, RAG? А MCP-сервер уже запилили? В опенсорс его закинули?

Что ж так быстро-то всё меняется, выдохнуть некогда. Архитектуркой бы позаниматься, долги позакрывать. Но некогда. Рынок требует AI. Надо пережить эту волну, но кто бы знал, какая будет следующая.

А вот на фоне этих новостей, про опенсорсивание экстеншена Copilot. Меня тут не беспокоит потенциальная смерть Cursor (а как мы знаем давно строить бизнес поверх чужого продукта — штука опасная). Я так-то вообще курсором пока не проникся, мне хватает Roo + наш Code Assistant, который наконец-то заменил мне Codeium (TIL он теперь windsurf)

Мне стало интересно, а что там в мире JetBrains происходит? Вижу, что рядом ребята сидят и держат открытыми Idea и Cursor/Roo. Одно для кодинга, второе для вайбинга. Гуглёж подсказал, что пилится свой агент Junie, но что там под капотом? Какая моделька? И какая бы она прекрасная не была — хочется же менять и пробовать разное. И для NDA локальные модельки нужны.

В общем если кто в курсе — покидайте статьи/доклады, что там у JB, какой курс.

Сидел с утра собирал memory bank в Roo. Потрясающая штука, даже если им не пользоваться (а почему?), но просто почитать — вот он твой проект как на ладони. Но, конечно, нужно покопаться в нём вместе с нейронкой, направить её в правильную сторону.

Это, кстати, причина, почему roo, а не cline. В cline всё как-то победнее (ну это просто связано с меньшим количеством режимов работы агента).

Если кратко, то memory bank это просто папочка со структурированным описанием вашего проекта, на которую вы натравливаете агента через промт (не вручную конечно же, агенты умеют подмешивать промты из конфига).

UPD: Ну и это конечно уже вчерашний день, потому что теперь есть Context Portal MCP 😃 С RAG конечно же.

Из рабочего чата

RAG на коленке

Решил тут на днях собрать пруф оф концепт чат бота по документации внутреннего проекта. Раз проект внутренний, то никакая LLM про его документацию не знает и, тем более, сходить по сети за ней не может. А значит нужен RAG. Вот тут можете можете почитать, что это такое. TLDR — смотрим, что пользователь спросил, находим нужные разделы в документации и подмешиваем в промт. Дальше моделька сама справится.

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

Результат офигенный конечно. Но вот зараза, у меня нет под рукой нейронок для эмбеддинга. Во внешний мир ходить не хочу, проект внутренний. Что же делать, как показать пруф оф концепт? Собираем с Клодом веб-скрейпер на плейрайте, дербаним доку в JSON, кормим этот JSON приложению на ноде, обслуживающему чат. Теперь на каждый запрос пользователя выбираем слова подлинней, лезем в JSON и находим совпадения (ахах, да, можно было бы и морфологию прикрутить, но некогда, работа не ждёт). Собираем промпт по совпадениям и закидываем в LLM вместе с запросом пользователя. И оно работает. Да, неоптимально, чертовски неоптимально. Но для PoC за глаза хватило.

Apple released container CLI

WWDC is ongoing and one of the news, which unfairly is not spotlighted enough is the containerization framework, which the Apple team published and even open-sourced (!). It's written on Swift and provides the OCI-complaint API. Unfortunately, it's still a virtual machine, but the Apple team refers to it as a micro virtual machine, which can be launched sub secondly with the help of optimized Linux kernel configuration. You can even try it on MacOS 15, but with the crucial limitation: all containers will be run on their own networks. But starting from macOS 26 you can run containers connected.

Good then nothing, but not as good as run containers natively on Linux.

Вообще конечно все эти AI-агенты просто возвращают мне радость программирования. Машина наконец-то делает то, что должна — скучную рутину. А мы парим над этим и раздаём указания. Проверяем теорию за теорией, собираем пруф оф концепты за нефиг делать и тут же без жалости (икеа-эффекта нет) выкидываем. Делаем за день недельную работу.

Я прямо очень доволен. Старички вроде меня снова в строю и могут поделать архитектурку.

Vite is generally known for its unbundled native ESM dev server, which is responsible for the fast startup time and almost instant feedback. Nevertheless, we’ve seen limitations of this approach for projects at unconventional scale, especially in Enterprise setups. To address these, we are working on a full-bundle mode for the dev server.

Наконец-то! Говорил же об этом с первого дня :)

Ну понятно, ребята ждали Rolldown

Ого! 11 лет назад были Яндекс Деньги, спорные ThinkPad’ы, XSLT и XScript и тот же самый кабинет в Бенуа, в котором сижу сегодня. И за окном всё тот же изгиб Невы. И даже место то же, только стол повёрнут иначе, потому что места в кабинете стало больше, гораздо больше.

11 лет не непрерывных конечно, погулял по рынку. «Деньги» за эти годы отделились, переименовались в «Юмани» и уехали на 6-й этаж. А я вот вернулся на четвёртый в Облако.

О, первый раз могу показать чем занимался последние несколько месяцев в виде промо

https://datalens.yandex.cloud/?_lang=ru#neuroanalytic

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

Да, внутри уже пользуемся и профит с этого ощущаем.
Да, делать это интересно.
Да, у нас в команде этим занимаются фронтенд-инженеры.
Да, все задачи тут больше на смекалочку. Как уговорить промптом модельку, как нафаршировать её даными и не вывалиться из контекстного окна. Как собрать RAG когда у тебя под рукой нет ни эмбеддингов ни даже обычного поиска и т.д.
Да, может и хайп. Но результаты работы LLM и правда удивляют (в хорошую сторону).

Под прошлым постом были вопросы — а почему, собственно, у вас в команде некие фронтенд-инженеры занимаются тем, чем занимаются. Своё виденье я ещё попробую расписать, но тут вовремя приехала выжимка Фаулера от Максима

Expert Generalists

Статья в блоге Мартина Фаулера про T-shaped специалистов. Точнее, все текущие термины (T-shape, П-shape, и другие) плохо подходят, поэтому в статье вводится термин Expert-Generalist, который означает, что человек одновременно является и экспертом (в противовес generalist) и использует свою экспертизу во многих областях (в противовес эксперту в одной области).

В данном случае имеется в виду, что человек является экспертом в фундаментальных понятиях, которые позволяют ему быть успешным в областях, которые построены на этих понятиях. Классический пример из IT, это когда человек имеет опыт написания ПО на 3-4 языка программирования и ему после этого уже не так важно, на каком именно другом языке писать код, пока этот язык следует общим парадигмам (основан на том же фундаменте). Условно, человек, который писал на JS, PHP, JAVA, C++ с легкостью может войти в Go, Rust, Kotlin. Но, вероятно, столкнется с некоторыми проблемами при входе в Haskell. Но, скорее всего, сможет это сделать в короткие сроки.

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

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

В чем сила таких специалистов:

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

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

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

Ключевые качества экспертов-генералистов:
- Любознательность
- Умение сотрудничать
- Фокус на клиенте (бизнесовая направленность)
- Ставка на фундаментальные знания
- Широта знаний
- Способность понимать позицию смежных доменов (например, понимать проблемы SRE или DevOps)

Многие эксперты-генералисты вырастают в технических лидеров

Встает закономерны вопрос: "где брать таких специалистов?". Текущий найм устроен так, что мы скорее наймем ультра-эксперта в технологии, чем наймем человека, который любознателен и умеет погружаться в новые домены. В статье предлагается подход из двух решений:
- Перестать смотреть только на узкие хард-скилы. Вместо этого следует проверять человека на обучаемость, любознательность, создание условий для совместной работы
- Проводить внутренние тренинги и воркшопы, цель которых - погрузить специалистов в смежные области. В Thoughtworks есть 3 воркшопа, в которых специалисты делают решения из смежных областей. В рамках воркшопа они реализуют простые прототипы kafka, kubernetes, delta lake (штука для работы с данными). Создав прототип, люди начинают понимать базовые принципы, на которых основаны эти системы и начинают видеть рабочие ситуации с другой стороны

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

Для каждой ключевой компетенции в команде нужен 1-2 специалиста.

---

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



https://martinfowler.com/articles/expert-generalist.html

#managment #tshape #martinFowler

Обещал же расписать.

Прошу не проецировать на весь Яндекс, так как все бизнес-юниты работают совершенно с разными подходами. Более того, даже внутри одного БЮ может быть разный подход в разных командах.

Так вот, в нашей команде все занимаются почти всем. Да, фронтендера не попросят писать под на Питоне, бэкендера не отправят на Реакт. Но девопс, БД, сеть — такие задачи могут прилететь любому. Если этот любой готов к этому (и это важно). Мы знаем, кто к чему тяготеет, и насильно не отправим человека решать задачи, не свойственные его скиллам.

Т.е. пресловутый t-shape присутствует, и у каждого своя палочка своей конфигурации. Тут задача — удерживать команду в балансе, чтобы всё не упиралось в одного узкого специалиста (а так оно и будет, если вы уйдёте в гипер-специализацию). Два-три человека должны быть в каждой области.

То есть в команде не случайные люди — она собрана исходя из этой специфики изначально. И это работает.

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

Это не плохо и не хорошо, это просто вот такой вот подход, который в наших условиях работает.

Для себя я вижу здесь только возможности роста как специалиста, и во многом это и была причина, по которой я выбрал команду. Мне не так интересно получить от бэкендера эндпоинт для AI — интересно разобраться самому.