Путь айтишника (@the_programmer_path) — посты канала в Telegram

1 августа 2026

Путь айтишника

Ссылка
нажмите — покажем

Иногда самые интересные инженерные решения появляются не на этапе проектирования, а уже когда система почти готова — именно так у меня и получилось с микросервисом по обработке чеков. Пока разбирался с архитектурой, наткнулся на интересную идею. После основной нейронки рекомендуют запускать ещё одну, которая проверяет результат её работы. Подход называется LLM-as-a-Judge. Логика простая. Промпт — это не программа, а скорее набор рекомендаций. Нейронка может интерпретировать их по-своему: придумать новый код ошибки, добавить несуществующую деталь устройства или сделать ещё что-нибудь творческое. Как поётся в песне: «Фантазёр, ты меня называла». Первые версии промпта для проверяющей модели оказались слишком суровыми. Почти на каждый ответ она выдавала что-то вроде: «Представленные рекомендации недостаточно обоснованы и не опираются на фактические данные и подтверждённые взаимосвязи». Да здравствует математическая логика. В итоге пришлось смягчить требования: теперь она отбрасывает только откровенные фантазии, а не пытается переписать весь результат. Фронтендер уже начал писать код под мой сервис. Посмотрим, как всё это покажет себя в реальной работе. Параллельно решил попробовать Codex для написания скриптов на PowerShell. Остался приятно удивлён. Для системного администратора это очень сильный язык: работа с базами данных, почтой, сетью, журналированием, многопоточностью — всё есть из коробки. Отдельный плюс — PowerShell уже встроен в Windows вместе с IDE. Если вы администрируете Windows-серверы или просто хотите автоматизировать домашний компьютер, язык точно стоит изучить. Осваивается он достаточно быстро, а пользы приносит много. Ещё посмотрел курс «Летняя сессия Яндекса» по AI. В основном рассказывали про экосистему Яндекса и её продукты. Если сравнивать с ChatGPT или DeepSeek, то какого-то принципиального технологического разрыва я не увидел. Зато у Яндекса хорошо выстроена именно экосистема: можно собрать полноценный проект, практически не выходя за пределы их … Читать полностью →

124 · 04:21

8 августа 2026

Путь айтишника

Фотография

81 · 04:45

Ссылка
нажмите — покажем

Иногда кажется, что самая сложная часть корпоративной системы — написать код. А потом начинаешь выяснять, кто какую полку в Wiki должен видеть, и внезапно оказываешься где-то между Keycloak, OLAP-кубом и многомерной вселенной, в которой возможно вообще всё. У нас есть большая корпоративная система Service Desk (SD), и захотели к ней прикрутить документацию в виде Wiki. Выбор пал на BookStack https://www.bookstackapp.com/. BookStack мне понравился своей концепцией книжного шкафа: есть шкаф, на нём полки, в полках книги, у книг главы и страницы. Всё довольно наглядно и хорошо ложится на корпоративную документацию. Но дальше захотелось, чтобы пользователь один раз авторизовался в Service Desk и с этой же учёткой автоматически входил в BookStack. Это называется SSO — Single Sign-On, или «единый вход». Между SD и BookStack в качестве прослойки используется Keycloak https://www.keycloak.org/, который и должен реализовать всю эту историю через протокол OpenID Connect (OIDC). Keycloak оказался системой весьма замысловатой и, мягко говоря, не самой дружелюбной. Например, пользователи и клиенты — совершенно разные сущности, как группы и роли. Самое интересное, что сущности с похожими названиями есть ещё и в BookStack, только означают они уже немного другое. В какой-то момент начинаешь подозревать, что главная задача Keycloak — не авторизовать пользователя, а проверить твою веру в человечество. Но техническая часть оказалась не самой сложной. В голове у бизнеса пока есть только крупные мазки и общее желание: «нужно разграничить доступ». А как только начинаешь выяснять, какой пользователь, с какой ролью, из какого подразделения должен видеть конкретную полку, книгу или главу, возникает дикая таксономия во главе с OLAP-кубом. Получается многомерная вселенная прав доступа, в которой возможно практически всё. Был даже созвон с нашим корпоративным архитектором. Посмотрели на эту неведомую зверушку, обсудили варианты, и архитектор взял паузу подумать, как всё это правильно реализова… Читать полностью →

1 · 117 · 04:45

15 августа 2026

Путь айтишника

Фотография

83 · 09:14

Ссылка
нажмите — покажем

За неделю AI успел побыть у меня программистом и уборщиком файловой помойки. И неожиданно именно последнее оказалось одним из самых полезных применений. Иногда не нужно просить AI сделать стартап на миллион — достаточно заставить его разобрать папку, к которой сам боишься подходить годами. Завершил мини-проект по загрузке записей звонков в Yandex SpeechSense и заодно познакомился с gRPC. До этого я в основном работал с REST, который древний как мамонт, но всё ещё живее всех живых. А Яндекс решил сделать API SpeechSense через gRPC — технологии уже десять лет, но для меня это оказался новый и довольно интересный мир. Если сильно упрощать, в REST клиент и сервер обычно обмениваются JSON: формат понятный человеку, но довольно многословный — имена полей повторяются в каждом объекте, а данные передаются текстом. В gRPC контракты сервисов заранее описываются в .proto-файлах, данные сериализуются через Protocol Buffers (Protobuf) и передаются поверх HTTP/2 в бинарном формате. В итоге меньше данных гоняется по сети, есть строгая типизация, а клиент и сервер заранее знают, чем именно должны обмениваться. Мне gRPC понравился именно этой строгостью: контракты определены заранее, меньше пространства для самодеятельности, данные передаются компактнее. Но хоронить REST я бы точно не стал — он будет жить ещё очень и очень долго. Просто теперь у меня появился ещё один инструмент и понимание, зачем он вообще нужен. Вот хорошее видео «gRPC для новичков» https://www.youtube.com/watch?v=DGBLwNN-YM4 Ладно, программирование — это всё хорошо. А может AI решить какую-нибудь совершенно рядовую задачу прямо на моём компьютере? У меня есть папка Docum, которая за годы превратилась в натуральную файлопомойку. Разобрать её руками можно, но страшно даже представить, сколько времени уйдёт. И тут я вспомнил про подход PARA. Смысл PARA простой: вся информация раскладывается всего по четырём папкам. Projects (Проекты) — то, над чем работаю сейчас и у чего есть конкретный результат и финишная черта. A… Читать полностью →

2 · 107 · 09:14

22 августа 2026

Путь айтишника

Фотография

85 · 03:53

Ссылка
нажмите — покажем

Есть ощущение, что ИИ действительно ускоряет работу — ровно до того момента, пока сам понимаешь, что он делает. Стоит потерять контроль, и вместо экономии времени можно получить очень убедительное решение совсем не той задачи. Всю неделю внедрял Cursor в свою работу. Думал, что после WebStorm придётся долго привыкать, но переход оказался довольно безболезненным. Хотя разница между ними хорошо показывает два разных подхода: IDE, где почти всё есть из коробки, и редактор, который сначала представляет собой скелет, а потом обрастает нужными плагинами. Cursor — это ИИ-редактор на базе Visual Studio Code, поэтому первое время непривычно было работать с Git, а сильнее всего мешало отсутствие привычной панели для npm-скриптов. В WebStorm нужный функционал обычно уже есть — остаётся его настроить. В VS Code логика другая: доставляешь плагины и собираешь редактор под себя. Поставил всё необходимое, например Better Scripts для npm-скриптов, и проблема исчезла. Особенно понравилось решать через Cursor задачи по системному администрированию. Если продукт один, обычно и самому понятно, куда смотреть. Но когда нужно интегрировать две-три системы, поиск решения легко занимает день и больше: документация, конфиги, права, особенности каждой системы. Cursor сам заходил на сервер, искал варианты решения и реализовывал их. В таких задачах экономия времени получается вполне ощутимая. Но волшебная палочка быстро сломалась об Yandex SpeechSense. Там достаточно сложная система управления правами и доступами, и даже с MCP автоматически настроить необходимые права не получилось. Пришлось читать документацию и выполнять настройку вручную — по старинке. Хорошее напоминание, что ИИ особенно полезен, когда сам понимаешь внутренний процесс и можешь быстро заметить, что он пошёл куда-то совсем не туда. А уехать он может далеко. Иногда смотрю на очередное решение и диву даюсь: технически всё выглядит убедительно, только к конкретной задаче имеет весьма отдалённое отношение. В таких случаях я п… Читать полностью →

1 · 102 · 03:53

29 августа 2026

Путь айтишника

Фотография

64 · 05:12

Ссылка
нажмите — покажем

Самые интересные задачи в IT обычно начинаются со слов «да тут всё просто». На этой неделе я дважды наступил на эти грабли: сначала с локальными LLM, потом с логированием скачиваний в NextCloud. Решил проверить, насколько хорошо LLM работает локально. А вдруг наступит чебурнет? Железо у меня дома не самое выдающееся: RTX 3050 8 ГБ + i5-12600 + 48 ГБ RAM. Установил LM Studio и довольно быстро выяснил, что 8 ГБ видеопамяти для нейронок — это маловато. Поэтому выбрал две модели, которые туда влезают: qwen2.5-coder-7b-instruct для программирования и универсальную qwen3.5-9b. Сама по себе LLM умеет немного: получила текст, вернула текст. Чтобы началась «магия», нужна обвязка — LLM harness, который позволяет модели работать с файлами, запускать команды и использовать другие инструменты. В качестве такой обвязки взял OpenCode https://opencode.ai/, подключил локальные модели и попросил написать простейшую программу — генератор паролей. qwen2.5-coder долго думала и родила чудо-юдо в одном файле. Дизайн — без слёз не посмотришь, зато относительно работает. qwen3.5-9b тоже долго думала и выдала результат заметно красивее. Всё хорошо, только не работает. Для сравнения дал ту же задачу Cursor — он быстро сделал красивый и рабочий вариант. Чуда не произошло. Если хочется качественно и быстро, придётся либо радикально обновлять железо, желательно парой мощных видеокарт, либо работать по подписке. Я пока за подписку: к хорошему быстро привыкаешь. На работе тем временем появилась задача, которая звучала ещё проще: в NextCloud нужно увидеть, какой пользователь скачал какой файл. По собственному опыту знаю — самые сложные задачи начинаются именно с одной такой фразы. Сначала попросил Cursor написать расширенный лог для Nginx. Он написал, только в лог начало попадать вообще всё. Результат мне сильно не понравился, поэтому пришлось самому вспоминать, как устроено логирование в Nginx. Посмотрел два видео: "Логирование в Angie" https://www.youtube.com/watch?v=UDpeDHQmcic "Директива locati… Читать полностью →

78 · 05:12

Фотография

81 · 05:13

5 сентября 2026

Путь айтишника

Фотография

67 · 05:06

Ссылка
нажмите — покажем

Иногда полезно залезть в область, в которой вообще не собираешься становиться специалистом. Просто чтобы лучше понимать, что происходит рядом с твоей основной работой, и не воспринимать чужую профессию как магию. Неожиданно для себя решил немного заняться дизайном. У меня есть годовые цели, и мы с ChatGPT посмотрели на календарь: скоро новый год, а к некоторым из них я даже не приступал. Одна из таких целей — дизайн. Формально дизайном я занимаюсь давно: открытки к 8 Марта, простые сайты и прочее высокое искусство. UX/UI-дизайнером становиться не собираюсь — это отдельная и довольно сложная профессия. Но фронтендеру базовое понимание дизайна полезно: поправить компоновку, цвет, шрифт или готовый макет, не дёргая дизайнера из-за каждой мелочи. Поэтому нашёл курс по Figma и повторил первый макет. Сама Figma оказалась не такой страшной. Когда-то я работал в CorelDraw и Adobe Illustrator, поэтому логика знакома: группировка, выравнивание, цвет, обводка, размеры. Главная проблема таких программ для меня всегда одна — надо учить горячие клавиши, иначе однотипные действия начинают съедать уйму времени. Параллельно читаю «Типы в языках программирования» Бенджамина Пирса и дошёл до ООП. Обычно ООП объясняют через животных: есть класс «Животное», от него наследуются кошка и собака, одна мяукает, другая лает. Все всё поняли, аплодисменты, расходимся. Но внутри никаких кошечек и собачек, конечно, нет. Пирс показывает объектную модель без привычной магии классов. Оказывается, основные механизмы ООП можно собрать из более простых конструкций языка: объект → запись функций; метод → функция; переменные экземпляра → ссылки (ref); инкапсуляция → замыкание; наследование → расширение записи методов; self → рекурсивная передача объекта самому себе. То есть ООП не требует специальных «объектно-ориентированных» конструкций языка. Классы — во многом удобная оболочка над функциями, записями, ссылками и рекурсией. После такого разбора на привычное ООП начинаешь смотреть немного иначе. И ещё … Читать полностью →

72 · 05:09

12 сентября 2026

Путь айтишника

Фотография

59 · 04:50

Ссылка
нажмите — покажем

Начал проходить курс «Computer Science во Frontend». Первая тема — массивы. Казалось бы, что там вообще может быть сложного? Но довольно быстро выясняется, что привычный Array в JavaScript — это достаточно хитрая абстракция, а не просто кусок непрерывной памяти, как массив в C. Обычно этого совершенно достаточно, пока не приходится лезть в бинарные данные. И вот тут появляются типизированные массивы — TypedArray. Это структуры JavaScript для работы с числами одного типа в непрерывной области памяти. Сама память хранится в ArrayBuffer, а Uint8Array, Int32Array, Float64Array и другие типы позволяют смотреть на неё по-разному. В отличие от обычного Array, размер такого массива фиксирован, а один и тот же ArrayBuffer можно одновременно интерпретировать разными способами. Но если требуется прочитать бинарный файл какого-нибудь неведомого формата, веселье только начинается. Одни данные могут занимать один байт, другие два или четыре, а многобайтовые числа ещё и записываются в разном порядке: little-endian или big-endian. Для такой работы есть DataView, который позволяет читать из ArrayBuffer значения нужного типа, с нужного смещения и с нужным порядком байтов. С текстом отдельная история. UTF-8 и UTF-16 используют переменное количество байтов для представления символов, поэтому просто читать файл по одному байту и считать, что каждый байт равен одному символу, не получится. Для декодирования текста есть отдельные инструменты вроде TextDecoder, а TypedArray и DataView остаются уровнем ниже — они работают непосредственно с байтами и числами. Получается довольно занятная схема: сначала считываем бинарный файл в область памяти ArrayBuffer, а потом накладываем на неё нужные представления. Причём при работе с многобайтовыми типами приходится учитывать смещения и выравнивание данных. В какой-то момент понимаешь, что фраза «просто прочитать несколько байтов из файла» звучит примерно так же оптимистично, как «просто подключить ещё один сервис». Если сократить всю тему до одной схе… Читать полностью →

59 · 04:50

19 сентября 2026

Путь айтишника

Фотография

49 · 05:58

Ссылка
нажмите — покажем

Чем дальше прохожу «Computer Science во Frontend», тем чаще оказывается, что привычные вещи устроены совсем не так просто, как кажутся сверху. Массив уже оказался не совсем массивом, теперь добрался до RxJS и устройства памяти процесса. В обоих случаях примерно одна история: пока работаешь через удобную абстракцию — всё понятно, а стоит заглянуть внутрь, начинается самое интересное. Начал проходить миникурс по RxJS https://rxjs-course-avy.web.app/. В React основной подход довольно понятный: изменилось состояние → компонент перерендерился, а асинхронность обычно закрывается через Promise, async/await, useEffect, TanStack Query или внешний state-менеджер. В Angular потоки встроены в экосистему гораздо глубже, поэтому здесь приходится немного перестраивать привычный способ мышления. Многие данные во frontend — это вообще не одно значение, а поток значений во времени: ввод пользователя, HTTP-запросы, события роутера, WebSocket, таймеры. Observable позволяет такие потоки объединять, фильтровать и преобразовывать через map, switchMap, combineLatest, debounceTime и другие операторы. Современный Angular при этом разделяет задачи: Signals удобны для состояния UI, а RxJS остаётся сильным инструментом для сложной асинхронности. По собственному опыту особенно хорошо смысл потоков становится понятен, когда появляется два-три зависимых асинхронных запроса, а предыдущие ещё надо уметь отменять. Можно собрать это на Promise и async/await, но довольно быстро начинается ручное управление состояниями, отменами и гонками. С потоками такая логика иногда получается заметно чище, хотя первое время на RxJS смотришь примерно как на отдельный язык программирования внутри TypeScript. Параллельно в курсе «Computer Science во Frontend» дошёл до сегментов памяти программы. Со школы помню классическую картинку: есть код программы, данные, куча растёт вверх, стек растёт вниз — всё просто и понятно. И это даже не то чтобы неправильно. Просто реальная память процесса, как обычно, решила не ограничив… Читать полностью →

53 · 05:58

Фотография

63 · 05:59

3 октября 2026

Путь айтишника

Фотография

21 · 05:56

Продолжаю смотреть курс «Computer Science во Frontend». Дошёл до многопоточности. Ну какая многопоточность в JavaScript? Это не про нас. JavaScript однопоточный. Многопоточность — это где-то там, в больших и мощных Java и Go. Но, как обычно, есть нюансы. Причём сразу два: есть Web Workers, которые предоставляет окружение, и есть асинхронность, которой тоже нужно как-то грамотно управлять. Посмотрел на пример с Web Worker, где автор создаёт два потока, — без слёз на этот код не посмотреть. Worker выполняет отдельный JS-файл, а если хочется собрать всё динамически, начинаются развлечения: функцию превращаем в строку, оборачиваем в Blob, создаём URL и только потом отдаём Worker. Извращение ещё то. Поэтому если мне действительно понадобится удобная многопоточность, я лучше возьму Go. В JavaScript это инструмент скорее для отдельных специфических задач, чем повседневная модель программирования. А вот управление асинхронностью оказалось намного интереснее. Мне понравилась структура со страшным названием «асинхронный семафор (барьер)». Идея очень простая: есть несколько независимых операций, и продолжить работу можно только после завершения всех. Например, при запуске проекта нужно подключиться к базе данных, прочитать YAML-конфиг и поднять Redis. Только когда готовы все три компонента, выполняем callback. (см. рисунок) В примере есть три флага. expectedFlags хранит полный набор условий, а readyFlags — уже выполненные. Каждый участник после завершения работы «поднимает» свой флаг, а барьер проверяет, собрались ли все. Set здесь особенно удобен: повторный barrier.set('database') ничего не сломает и не увеличит счётчик, потому что одинаковые значения в Set не дублируются. Просто и достаточно элегантно. У меня когда-то была аналогичная задача на фронте: выполнить код только после того, как всё загрузилось и инициализировалось. Проект был древний и страшный, а я помню, как извращался с Redux. Решение в итоге собрал из говна и палок. Сейчас смотрю на барьер и думаю: вот же оно.… Читать полностью →

19 · 05:56

Фотография

21 · 05:57

10 октября 2026

Путь айтишника

Фотография

15 · 07:25

Функциональное программирование меня неожиданно увлекло. Особенно рекурсия, которую я считал довольно простой конструкцией: функция вызывает саму себя, и всё. Оказалось, что существует как минимум пять её разновидностей, некоторые весьма замысловатые. А началось всё с бумажной книги, которую я купил давным-давно. Заодно вспомнил интересную методику чтения, позволяющую не тратить десятки часов на книги. В чистом функциональном программировании нет привычных циклов for и while. Вместо них используют рекурсию и функции высшего порядка вроде map, filter и reduce. Вспомнил, что давно купил книгу Мануэля Рубио-Санчеса «Введение в рекурсивное программирование». Решил наконец до неё добраться и выяснил, что существует пять основных типов рекурсии: Линейная — один рекурсивный вызов, например факториал: n * factorial(n - 1). Хвостовая — рекурсивный вызов выполняется последним: return factorial(n - 1, n * acc). Допускает оптимизацию стека, но в JavaScript она не гарантирована. Множественная — несколько вызовов, например Фибоначчи: fibonacci(n - 1) + fibonacci(n - 2). Взаимная — функции вызывают друг друга: isEven() и isOdd(). Вложенная — результат одного вызова передаётся другому: f(f(n - 1)). Классический пример — алгоритм Маккарти 91, который для чисел ≤ 100 возвращает 91, а для чисел > 100 — число минус 10. Все типы рекурсии я привёл на картинке. Особенно понравился алгоритм Маккарти 91. Выглядит как математическая магия: функция вызывает саму себя внутри собственного вызова, но результат вполне предсказуемый. Казалось бы, знакомая конструкция, а сколько интересного обнаруживается, если копнуть глубже. Но вернёмся к книге. Она бумажная, а читать техническую литературу от корки до корки — удовольствие сомнительное, особенно когда половина материала уже знакома. Вспомнил методику Андрея Парабеллума из книги «Быстрые результаты. 10-дневная программа повышения личной эффективности». Идея простая: в большинстве книг Non-fiction информация повторяется, а основные мысли зачастую… Читать полностью →

1 · 14 · 07:29

Фотография

14 · 07:30

17 октября 2026

Путь айтишника

Фотография

29 · 05:27

Недавно ко мне обратился знакомый программист и рассказал, что есть ненулевой шанс попасть под сокращение. Я вспомнил, что меня самого увольняли раза три-четыре, так что определённый опыт накопился. Сразу оговорюсь: это мой личный опыт, а не универсальная инструкция для всего IT. Как только в компании начинаются разговоры про оптимизацию, повышение эффективности бизнеса и сложную экономическую ситуацию, я бы задумался. Насколько проект, над которым я работаю, критичен для бизнеса? Некритичный проект могут просто закрыть, а на критичном оставить двух-трёх человек для поддержки. Причём уволить могут довольно быстро, иногда за пару недель. Первое — финансовая подушка. Я бы начал откладывать деньги, чтобы накопить хотя бы 3–6 месячных окладов. Меня несколько раз увольняли в самые «удачные» периоды: декабрь-январь или летом. В первом случае все на праздниках, во втором — в отпусках. Деньги нужны не только для оплаты коммуналки и питания, но и чтобы не бросаться на первый попавшийся оффер. Второе — алгоритмы. Причём не видео «Все алгоритмы за два часа», а полноценный курс по решению задач с LeetCode. На собеседовании могут дать две-три задачи по двадцать минут, и это скорее математические головоломки, чем реальное программирование. Я бы не советовал часами биться над каждой задачей самостоятельно. Лучше разобрать существующее решение, воспроизвести его без подсказок и закрепить на похожих задачах. В идеале — 200–300 задач и около полугода подготовки. Рекомендую курс «Подготовка к алгоритмическому собеседованию в BigTech». Самое обидное, что в реальной работе большинство этих трюков практически не используется. Третье — резюме и собеседования. Сейчас HR активно используют ИИ, поэтому резюме стоит оптимизировать под ключевые слова вакансий, но главное — показать результаты своей работы, а не просто перечислить технологии. Ещё рекомендую посмотреть записи технических собеседований на YouTube и пройти хотя бы одно пробное. На повторение теории вроде асинхронности JS, сборки м… Читать полностью →

30 · 05:28