Anthropic и Стэнфорд доказали, что ИИ пожирает рабочие места молодых.

Медиа опять ликуют, все заголовки кричат, LinkedIn (и внезапно threads) рыдает, нууууу, надеюсь, чашка чая наготове - потому что мы сейчас будем опять разбираться, а правда ли это :)

спойлер: все не так однозначно

Меня зовут Эдгар Сипки, и я как обычно вещаю про современную it индустрию и бизнес в нем - кстати, подпишись ка на канальчик мой

Тезис статьи простой: исследование действительно серьёзное, но выводы - преждевременные опережающие реальность И (ИЛИ) не учитывают рынок в целом, а учитывают только один из текущих факторов.

В первой части мы разобрали protoc-gen-validate и spec-first подход к валидации. Я обещал рассказать про protovalidateну и вот, держите :)

И самый первый вопрос конечно, а зачем вообще появился protovalidate, если PGV уже есть и работает?

Protobuf как контракт: spec‑first валидация с protoc‑gen‑validate

Первая статья из мини‑серии про валидацию на базе Protobuf. В этой части — концепция spec‑first и protoc‑gen‑validate. В следующей поговорим про protovalidate и то, почему его вообще имеет смысл рассматривать как «следующее поколение» (или же как очередная эволюция в обратную сторону?)

Также, чтобы не пропустить следующую часть, очень рекомендую подписаться на мой телеграмм канал :-)

На днях подходит ко мне коллега с вопросом: «Слушай, а как в Go сделать замену логики функции в тесте?»

Я уточняю, что он имеет в виду. А он такой: «Ну, хочу monkey patching, чтобы подменять функции из коробки. Типа time.Now возвращала фиксированное время, uuid.New конкретный ID. Чтобы удобно тестироваться».

И тут я, конечно, немного завис :D

Да, технически в Go есть способы делать monkey patching (еще и есть библиотека) через unsafe, через подмену указателей на функции в рантайме. Но это настолько хрупкое и непредсказуемое решение, что я бы не советовал тащить его в продакшен-код. Особенно когда есть нормальный, идиоматичный способ решить эту задачу.

Предыдущая часть

Картина мира: почему браузер — главный блокер для «настоящего» gRPC

Если коротко, gRPC живёт поверх HTTP/2 и активно полагается на стримы. А в браузере до сих пор нет низкоуровневого API, который позволил бы JavaScript управлять HTTP/2‑стримами на том уровне, который нужен gRPC. Даже unary‑вызов в gRPC — это частный случай стрима: открыли поток, отдали запрос, забрали ответ, закрылись. Пока браузеры не дадут этот «рычаг», все WEB‑решения — это компромиссы разной степени изящности.

Чем это оборачивается на практике:

Нативные bidi‑стримы из браузера недоступны

Приходится конвертировать транспорт: HTTP/1.1 или WebSocket → что‑то «похоже на gRPC» → gRPC/HTTP2 на бэкенде

Добавляются прокси, адаптеры и слой совместимости, где теряется часть достоинств «чистого» gRPC

Одна из самых основных проблем в работе с gRPC - необходимость наружу вытаскивать отдельно REST API для web клиента, но, надо ли отдельно его писать, или можно как-то унифицировать и эту историю?

И вот начал я копать эту тему, и чем глубже копал, тем больше удивлялся. Оказывается, за последние почти 10 лет было целых ТРИ ЧЕТЫРЕ серьезных попытки затащить gRPC в веб. И знаете что самое смешное? Самая первая попытка, сделанная в 2015 году японкой-одиночкой (в команде с коллегами), до сих пор остается самым адекватным решением. А Google со всеми своими миллиардами и армией разработчиков так и не смог ничего нормального придумать. Но обо всем по порядку.

Ах, да, меня зовут Эдгар Сипки, я все также евангелист gRPC && OpenSource :) Кстати, мой канал, там я гораздо чаще пишу (а скоро еще и начну снимать очень много крутого контента про gRPC и Go), ну и конечно один из основателей инструмента EasyP

Ссылка на полный доклад, если хочется посмотреть - YouTube

Просыпаюсь утром, открываю свой чат с GPT, начинаю увлеченно обсуждать архитектуру нового проекта. Через час диалог превращается в философский трактат о смысле жизни, еще через час - в рецепт борща. И вот, когда я пытаюсь вернуться к архитектуре, модель смотрит на меня как на незнакомца: "А что за проект? Борщ, говорите?"

Если очень коротко, у современных LLM есть одна маленькая проблема, они вполне страдают тем же самым “альцгеймером”, что и люди, хоть и причины немного иные (а может и нет) и это конечно не медицинский диагноз, а конкретная технологическая проблема, которое бьет не только по качеству результата, но и по нашим с вами кошелькам :)

В итоге, пройдя 10 кругов ада, так и решил наконец сесть и разобраться, а почему они начинают забывать все важные детали, а также можно ли как-то удешевить таки API в подобных задачах?

Решил я ворваться тоже в “Сезон Open Source”, но как обычно в стиле «🐢» а не вот эти вот ваши молнии.

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

Чаще всего я настраивал это все на уровне кода, но, некоторый период назад наткнулся на Modelfile и решил изучить и попробовать его, в ходе экспериментов наткнулся на реально большое число неожиданностей и решил таки написать о нем тут подробнее :)

Modelfile позволяет упаковывать модели и формировать готовых агентов. В нем оказалось много реально неожиданного поведения, и одновременно с этим есть сложности и странности. Однако с его помощью можно взять множество разных моделей из того же Hugging Face и запустить под Ollama, а самое важное, удобства в тюнинге (или же наоборот отупливании модели :D ).

Ребята зарелизили новую крупную фичу, и, как по мне, это самая крупная механика с момента выхода dev containers, так как это показывает, насколько всё-таки AI всё глубже интегрируется в разработку.

Docker Model Runner - фактически инструментарий для запуска моделей локально, и это буквально полный конкурент для Ollama, но, будем объективны, пока что ещё очень сырой.

Когда я пытался подключить AFFiNE к Ollama или к DeepSeek я сразу столкнулся с большой проблемой, AFFiNE попросту не умеет работать с моделями отличными от GPT, вопрос, почему? Да потому что ребята просто захардкодили названия моделей в коде
Честности ради, ребята все еще в бете, так что причину отлично понимаю

Покопавшись в коде, я понял, что там попросту ну никак нельзя конфигурировать что либо КРОМЕ url и API ключа от OpenAI, так как названия моделей буквально захардкожены

9 сентября — это был последний день, когда мы могли еще нормально использовать Notion. Объективно, я что тогда, что сейчас так и не нашел инструмента лучше, удобнее, гибче и ПРОЩЕ, чем Notion. Да, он во всем был лучше как для жизни, так и для работы.

В конце концов, о его уходе анонсировали еще в конце августа, и я до сих пор помню статью «Obsidian — Notion свободного человека», после которой я, как и, думаю, многие другие, пытались пересесть. Однако у меня так и не вышло это, как бы я ни пытался — всегда слишком много сложностей и деталей. Так вот, эта история про поиск альтернативы.

Джарвис — мечта многих гиков. Однако будем объективны: мы реально все ближе к его появлению. Я бы не очень хотел, чтобы все мои запросы передавались на серверы OpenAI, DeepSeek, Anthropic и других компаний. Ну и ещё с лета начал свою домашнюю рубрику — ЭЭЭЭКСПЕРИМЕНТЫ на домашнем сервере.

Я хотел собрать домашнюю станцию с полностью самостоятельной, self-hosted LLM моделью и настроить всё под себя. Однако я не знал, какой мощности сервер нужен, чтобы получить адекватную работоспособность. Практически не найти в сети нужные тесты, бенчмарки и эксперименты, так что, немного погрустив, нашел в шкафу свой старый добрый Intel NUC и понял — он и будет моим тестовым стендом!

Когда про DeepSeek-r1 начали говорить уже из каждого утюга, я долго думал, а стоит ли еще и свои 5 копеек вставлять в эту историю, и подумал, конечно же да! Ведь могу.

Если коротко, просыпаюсь в понедельник и вижу сотни постов в час на тему «революции в ИИ», «гигантский скачок в развитии LLM», «Акции big tech компаний падают», «NVIDIA потеряла сотни миллиардов долларов» — все эти статьи и посты имели кое-что общее — упоминание DeepSeek. Первое, что я почувствовал, это, конечно, небольшое недоумение — так он уже несколько дней точно лежит в библиотеке ollama, а до этого еще лежал на hugging face, да еще и я уже и развернул его на домашнем сервере и тестирую, так почему он внезапно то хайповать стал?!

Подумал, подумал, и пошел работать, лишь к вечеру вернувшись к этому вопросу. Решил разобраться, откры Хабр и понял, что уже куча опубликованных статей в стиле «⚡️», так что решил подождать чуть более логичных рассуждений обо всей этой истории. В итоге, время шло-шло-шло, я уже состарился на целую неделю, параллельно изучая причины происходящего, но, так и не дождался полноценного разбора произошедшего, так что я решил написать статью в стиле «🐢».

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

Введение: Пересмотр Традиций в Мире Go

В мире разработки на Go выбор фреймворка часто превращается в лояльность, сопоставимую с выбором между Apple и Android. Фреймворки вроде Gin, Echo и Beego долгие годы были верными спутниками программистов, помогая быстро развертывать проекты и достигать первых успехов. Они предлагали удобные инструменты и привычные шаблоны работы, но со временем становится очевидным, что у каждого свой «язык». Это создаёт трудности при переходе между ними или интеграции с другими системами.

Если для компиляции proto-файлов вы всё ещё используете protoc, самое время перестать и перейти на buf. Разберём, как это сделать и почему это необходимо. Также рассмотрим проблемы доступа к buf.build.

Меня зовут Эдгар Сипки, я Go-разработчик в Ozon Fintech. buf — мощная утилита для линтинга протофайлов, проверки обратной совместимости API, генерации кода и валидации запросов. Однако, из-за санкций она недоступна в России. Поэтому я расскажу, как мы разрабатывали собственное решение в рамках импортозамещения.