Gorelykh Anatoly


Kanal geosi va tili: ko‘rsatilmagan, ko‘rsatilmagan
Toifa: ko‘rsatilmagan


M-Shaped SOER, 10+ yrs.
Directions: Beckend, Mobile.
Stack: Go (Gin, Vanila), Flutter, Python (FastAPI), TypeScript. MongoDB, PostgreSQL, Docker, Git (Gitlab CI, Gitea Actions).
- https://github.com/Rosherh
- https://vc.ru/id5810978

Связанные каналы

Kanal geosi va tili
ko‘rsatilmagan, ko‘rsatilmagan
Toifa
ko‘rsatilmagan
Statistika
Postlar filtri


Парадокс Джевонса в IT. Отвечаю на тезис: программисты скоро станут не нужны.

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


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

Сегодня в IT сфере я отчетливо вижу, как на фоне AI кодинга, парадокс Джевонса отлично себя показывает.

Да, есть ускорение в написание кода, но работать меньше не выходит, т.к. нужно не только писать промпты, но и также читать то, что ты пишешь. Валидировать выполненную работу за LLM'кой. И быть ответственным за то, что ты в конечном итоге разрабатываешь.

В итоге получаем:
1. Экспоненциальный рост объёма кода. А спрос порождает спрос на реализацию фич.
2. Новые слои абстракции. Поверьте, чем код пишется быстрее, тем системы становятся сложнее. В условиях продакшена, где бизнес, бабки и т.д. велик риск больших потерь. Так или иначе программист обязан понимать то, что реализовывается за счет LLM, т.к. ответственность с моделей взять не получится. Не говорю про безопасность, эта область всё ещё максимальной концентрации ответственности.
3. Уходит рутина, когда за счет LLM можно нагенерировать простые скрипты, и не тратить большое кол-во времени, но растёт потребность в архитекторах, надёжности, безопасности и тех, кто может оценить результат, сгенерированный моделями.

Считаю, что тезис "программисты - более не нужны" всё ещё чушь и не соответствует действительности.


Сегодня немного побаловался с нейронкой от Kimi K2.6. Попросил её провести анкетирование на поиск своего Икигай.

В целом, она подтверждает то, к чему я давно пришёл по своему соображению, но до сих пор всё откладывается, т.к. у меня довольно много барьеров начать, ну и в частности банально нет сил, после рабочего дня... А планирование не всегда удается(


Окно, которое мы приняли за стену - Гараж 2.0.

Достаёт уже читать про ИИ, где из каждого утюга слышится - ИИ заменит тех, других, отберёт работу и всё такое. Я смотрю на это иначе.

ИИ для меня не только инструмент, но и "дополнительные руки". Этим всем нужно хорошо владеть, чтобы и работать, и реализывать давно заброшенные проекты. Это возвращение той эпохи, когда один человек в гараже мог сделать что-то, о чём заговорит весь мир. Взять например OpenClaw или Hermes (и тут не дело в ошибке выжившего, тут именно сам факт того, что вы можете что-то сделать).

Да, профессия будет трансформироваться, ничто не бывает вечно. Сейчас, кажется, что фронтенд, как отдельная профессия, уйдёт. Но, специалисты перетекут в fullstack, в T/M-Shaped (тут ещё и экономическая ситуация подталкивает к широкому профилю).

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

К слову, в Китайских соц. сетях вообще сильно форсится подъем робототехники за счет ИИ, всякие DIY штуки, каэф.

В общем, я не знаю, кем буду через пять лет. Но знаю, что выбор будет шире, чем сейчас. И это, если честно, прёт!


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


В Go context.Background() часто используют как дефолтный вариант, когда непонятно, что передать. Я тоже так делал, пока не столкнулся с последствиями.

Проблема в том, что Background() не несет никаких сигналов об отмене и не ограничен по времени. Если функция начала I/O-операцию с таким контекстом, она будет ждать до победного конца. Клиент разорвал соединение, запрос уже не нужен, но горутина продолжает висеть и занимать ресурсы.

Сейчас у меня простое правило: если функция делает хоть один внешний вызов, она принимает ctx context.Context первым аргументом. Без исключений.

Часто можно встретить код по типу


func FetchUser(id int) (*User, error) {
resp, err := http.Get(fmt.Sprintf("/users/%d", id))
// ...
}


Здесь http.Get использует context.Background() неявно. Запрос может зависнуть, и никакого способа его прервать извне нет.

Хорошей практикой будет:


func FetchUser(ctx context.Context, id int) (*User, error) {
req, err := http.NewRequestWithContext(ctx, "GET", url, nil)
if err != nil {
return nil, err
}
resp, err := http.DefaultClient.Do(req)
// ...
}


Теперь, если вызывающий код отменит контекст или сработает таймаут, запрос прервется сразу. Не дожидаясь TCP-таймаута, не через 30 секунд по умолчанию, а мгновенно.

Когда можно использовать context.Background()? В целом, я выделаю следующие моменты: в функции main, где запускается все приложение. В init, если там происходит инициализация, не связанная с внешними вызовами. Если вы явно тестируете поведение без отмены. Во всех остальных случаях контекст должен приходить сверху. Однако, для пет-проектов, где нет строгих требований к проекту, можно и принебречь 😅.

В тестах тоже стоит использовать не Background(), а context.WithTimeout. Даже если тест достаточно быстро выполняется. Зависший тест с таймаутом падает понятно и быстро. Зависший тест с Background() висит вечно, и причина неочевидна - приходится дебажить и тратить время на отладку.

Хранить контекст в поле структуры считается антипаттерном и должен передаваться параметром через каждый вызов. Конечно, кажется многословным, но зато всегда видно, какой контекст действует в данной точке, и откуда он взялся.


type Server struct {
ctx context.Context // так не стоит
}

func (s *Server) Handle(ctx context.Context, req Request) {
// правильно — ctx приходит с запросом
}


Конечно, для скриптов и пет-проектов это может показаться излишним. Но как только код выходит за пределы одного файла или начинает обрабатывать внешние запросы — передача контекста становится не формальностью, а частью корректной работы программы.


Разрыв **пы происходит, когда читаю в некоторых пабликах, как специалисты отвечают на ряд поставленных вопросов.

— Какой у тебя технический стэк?

Figma, Miro, Notion, Python, Git, SQL и разные таски.


Вызываем пояснительную бригаду.

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

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

Что хотят услышать на вопрос «Какой у тебя стек?»

Конкретику и понимание процессов. Идеальный ответ звучит как технический рецепт:

«бек пишу на Python (FastAPI/Django), работаю с реляционными БД (PostgreSQL), контейнеризация Docker, местами Podman, по CI/CD - проект собираю в GitLab», где запускают интеграционные тесты, собираются метрики и если все ок, деплоится на прод.


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

❌ Главные ошибки при рассказе о стеке:

1. Смешивать инженерию и воркспейс. Figma, Miro, Notion, Jira, Confluence — это рабочие инструменты и среды для коммуникации. Они не компилируют код, не лежат на проде и не падают в 3 часа ночи. Это не стек.

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

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


📦 OpenCV на Go: почему это не только про Python, и куда движется ML в экосистеме

Сегодня хочу поделиться мыслями о том, что многие считают нишевым направлением, но оно стремительно набирает обороты - это компьютерное зрение и ML на Go.

Что такое OpenCV?

OpenCV - это библиотека, написанная на С++, которая позволяет применить алгоритмы обработки и анализа цифровых изображений и видепотоков, включая фильтрацию, геометрические трансформации, извлечение признаков, сегментацию, обнаружение и распознавание объектов, трекинг движения объектов и т.д. - всё это объединяется под понятием Компьютерного Зрения.


Почему Python?

Исторически сложилось, что работать с данными проще всего на Python - благодаря его лаконичному синтаксису и богатой экосистеме (а.к.а. Батарейки). К обработке данных добавилось направление ML, и Python стал де-факто стандартом при работе с моделями ИИ. То же самое произошло и с CV: Python-обёртка cv2 стала основным интерфейсом к ядру OpenCV. Данная связка отлично подходит для прототипирования и исследований, даже простые бизнесовые задачи закрываются, но есть задачи с рядом жестких требований:

1. Требуется довольно простой деплой всей системы, желательно без зависимостей от окружения и конфликтов версий.
2. Нужна минимальная задержка и максимальная пропускная способность с возможностью обслуживать тысячи+ запросов.
3. Для максимальной пропускной способности должна быть эффективная модель параллельного выполнения обработки данных.
4. Для IoT-устройств и встраиваемых систем с ресурсными лимитами непозволительно хранить что-то лишнее.

Что собственно с GO?

Go поддерживает CGO вызовы (а в версии Go 1.26 ещё и улучшения накинули), поэтому точно также можем вызывать C-код. Основной инструмент gocv, активно поддерживается и является полноценной обёрткой над OpenCV 4.x. Поддержка CUDA для GPU-ускорения есть, но требует ручной сборки с нужными флагами.

Часто для продакшена используется связка в виде:

[Видеоисточник] → [Go: захват + предобработка] → [OpenCV: resize, normalize] → [ONNX Runtime/TensorRT: инференс] → [Go: постобработка NMS + бизнес-логика] → [gRPC/HTTP ответ]


В целом получаем сильные стороны каждого инструмента: Go для конкурентности и сетевого взаимодействия, специализированные runtime'ы для вычислений на GPU.

Не думаю, что Go претендует на место Jupyter Notebook. На проде, как часть микросервиса, где нужна быстрая верификация, обработка и контроль качества на конвейере очень даже хорошо интегрируется.

С чем столкнулся из неприятного?

1. Нормального аналога NumPy нет, а те решения, что есть, развиваются довольно медленно.
2. Обучение моделей с нуля на Go - экзотика, проще на Python обучить модель, конвертнуть в ONNX и подключить к Go.

В целом, перспективы у направления есть и надеюсь, что оно будет развиваться должным образом!


Пока что концепт-дизайн микроблога. Люблю минимализм и хорошую типографию!


Хочется писать довольно не большие, но практические статьи. В формате ТГ это не удобно, скорее всего реализую свой мини бложик, и часть заметок из своего Obsidian перенесу туда, возможно кому-то будет полезно, заодно какой-то да трафик принесет.

Как обычно, я использую генерацию статичных страниц на AstroJS + React.


Каждый раз, когда я начинаю пользоваться ИИшкой, для решения мелких, пусть даже неинтересных, но тех задач, которые связанны с программированием, то возникает ощущаение, будто ломается мой внутренний "Инженер" и начинаю чувствовать себя тупеньким 🥴


Так сложилось, что мне нравятся разные направления в IT сфере, и именно поэтому большую часть времени я работал и работаю Fullstack'ом. За 10 лет опыта, я изучил такие направления как: веб разработку (фронтенд, бекенд), мобильную разработку и немного Data Science.

Позднее в интернете начали появляться статьи про M-Shaped специалистов (концепция T-Shaped специалистов) — т.е. люди с глубой экспертностью нескольких областей, но довольно близкие между собой.

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


Если что есть агент от OpenCode, поддерживает множество разных провайдеров, есть GUI клиент. Поэтому не вижу надобности теперь в Qwen Code. Т.к. OpenCode можно настроить на их API.


Для тех, кто пользовался Qwen Code - https://qwen.ai/qwencode. Это терминальный агент, адаптированный под AI модели Qwen, огорчу, но вчера разработчики отключили бесплатный тариф на использование. Теперь при авторизации через Qwen Auth появляется надпись

Qwen OAuth free tier was discontinued on 2026-04-15. Please select Coding Plan or API Key instead.


Грустно, конечно, но халява закончилась.

13 ta oxirgi post ko‘rsatilgan.