Этот пост — мой личный разбор по итогам двух недель разработки простой файловой CMS для одного из моих пет-проектов. Мне нужен был SSR-сайт с мультиязычным контентом — около десятка страниц на двух языках. Всё под Git-контролем, переводы я делал вручную через DeepSeek API и выкладывал на продакшн через GitHub Actions.

В какой-то момент стало понятно: отслеживать и переводить все мелкие изменения вручную — неудобно и утомительно. Тогда я решил автоматизировать этот процесс и взял в напарники ИИ. Не для вайбкодинга и генерации «по настроению», а для настоящего парного программирования.

Результат — рабочий open-source проект, который можно развернуть, изучить и использовать. Но главное — это опыт. Это была не просто реализация CMS, а переосмысление роли ИИ в разработке. Под катом — мои подходы, наблюдения и выводы.

Эта статья для тех, кто, как и я, хочет программировать на JavaScript в Java-стиле. Для тех, кто находит вдохновение в балансе между строгой архитектурной дисциплиной Java и творческой свободой JavaScript. Ранее я уже публиковал "философию" своей платформы TeqFW, а также инструкции для LLM (раз, два) по оформлению es-модулей в приложениях, написанных в стиле TeqFW. На этот раз я делюсь инструкцией для LLM по использованию внедрения зависимостей в таких приложениях.

Для тех, кто не совсем понимает, что значит "программировать на JavaScript в Java-стиле", приведу рабочий пример — это Node.js-утилита @flancer64/smtp-logger. Она сохраняет в базу данных все email'ы, которые Postfix отправляет наружу. Мне как раз понадобился такой функционал — и я реализовал его в стиле TeqFW: с явным управлением зависимостями и строгой модульной структурой.

Под катом - пример JS-кода в Java-стиле.

Я ранее описал принципы, которыми руководствуюсь при разработке веб-приложений, а также требования, предъявляемые со стороны платформы TeqFW к JS-коду. В этой публикации я покажу, как выглядит код типового модуля платформы, где не используется статический импорт. Хочу сразу отметить, что кажущаяся сложность материалов обусловлена непривычностью представленных концепций. Наработанный опыт и инерция мышления — сильные вещи! Тем, кто имеет ограниченный опыт в JS-разработке, этот материал будет проще для восприятия, в то время как опытным разработчикам предстоит преодолеть барьер устоявшихся привычек. На мой взгляд, несмотря на то что "TypeScript — это суперсет JavaScript", самыми сложными концепции платформы станут именно для TS-разработчиков.

Ну, вот - я предупредил, дальнейшее чтение - на ваш страх и риск.

Ни у кого не получится показать другому то, что тот не хочет или не может увидеть. Объяснять и показывать нужно только тем, кто а) может понять, б) хочет понять. В этой публикации я демонстрирую пару своих документов для LLM, которые предписывают "силиконовым", какими правилами им следует руководствоваться при создании кода для моей платформы. "Силиконовым" можно впаривать любую дичь - они всеядные (могут понять) и покладистые (согласны понять). За это мы их и любим!

Кому интересно, что за инструкции - прошу под кат. Кто хочет сразу получить ответ на вопрос в заголовке - могут задать его (и множество других) соответствующему преднастроенному GPT-чату. Кто не хочет ни того, ни другого - в вашей ленте есть ещё куча других, более интересных публикаций.

Аудитория Хабра, в силу своей айтишности и любознательности, отлично подходит для различного рода экспериментов . Этот документ - эксперимент. Создан мной в соавторстве с LLM и предназначен как для людей, так и для LLM. Хочу увидеть реакцию людей. Реакцию LLM я уже видел.

Всё изложенное касается только разработчиков на JavaScript (JS !== TS).

Философия Tequila Framework (TeqFW) — это мой личный взгляд на организацию разработки веб-приложений. Я, Алекс Гусев, сформировал этот подход, исходя из собственного опыта, который сосредоточен на модульных монолитах с одной базой данных. Этот документ отражает именно такой контекст и не претендует на универсальность.

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

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

На днях с коллегой @nin-jin возник небольшой спор в комментариях к статье "ООП: худшее, что случалось с программированием". Мы обсуждали, что является истинным IoC: "контекст окружения" (Ambient Context) или же "внедрение зависимостей" (Dependency Injection).

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

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

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

Мысль моя простая и на целую статью её не хватает, но на Хабре под постом комменты хуже создаются, а мне интересна обратная связь. Поэтому вот. Извиняюсь, если кого задело:)

Некоторые говорят, что ИИ скоро заменят программистов. Типа, LLM «мыслит» точно так же, как и человек, только шире и быстрее. Достаточно увеличить контекст до каких‑нибудь внушительных размеров и LLM спокойно начнёт писать портянки кода и связывать их воедино. Вот только мой личный опыт меня убеждает, что с размера текста в 4–5К токенов LLM начинает дико лажать с его модификацией. Он начинает его регенерировать заново. Не исправлять, а именно регенерировать — так ему проще.

Думаю, что проблему можно решить через закольцовывание рассуждений (Reasoning, Chain of Thought) — разбиение контекста на части, анализ, кластеризация и иерархическая структуризация об общего к частному и обратно.

Скорее всего, «кожаные», включая меня, примерно так и решают задачи. Вот только вопрос, будет ли это выгодно чисто экономически с точки зрения расхода энергии? Не окажется ли на уровне современных технологий, что LLM может написать программу уровня самой LLM, но для выработки энергии для этого процесса придётся сжечь всё ископаемое топливо или выпарить Средиземное Море для охлаждения реакторов АЭС?

«Кожаные», между тем, справились с задачей лишь слегка подтаяв ледники Гренландии. При этом написав ещё кучу разных программ, ненужных и устаревших по большей части.

Вот и вопрос: а будет ли экономически эффективно заменять «кожаных» программистов «силиконовыми» чисто с точки зрения энергопотребления?

Одним словом: симбиоз. Кооперация ради эффективности. Человечество совместно с AGI (или AGI совместно с человечеством) составят более устойчивую конструкцию, чем каждый из компонентов по отдельности.

В общем-то, это основная мысль, которую я хотел донести до читателя. Лично мне кажется, что идея кристально ясная и дальнейшего уточнения не требует. Кто-то с этим согласен или, наоборот, несогласен. Если есть желание высказаться - вам в комменты. Под катом же немного рассуждений для тех, кому "сомнительно".

В комментах к статье "Синглтон - корень всех зол", который вообще-то про паттерн проектирования, я высказал мысль, что в функциональном программировании "все функции - синглтоны" (это уже в смысле lifestyle - больше одной функции на приложение не нужно). Тут же мне более опытные коллеги насовали в панамку, что "функции не синглтоны, потому что существуют замыкания". Я, конечно, "сварщик не настоящий" - в ФП серьёзно никогда не игрался, но основные идеи вроде как у всех на слуху: неизменяемость данных, чистота функций, функция как аргумент / результат другой функции.

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

Тем не менее, мысль про замыкания надо было как-то подумать - не, ну а вдруг?! Под катом я привожу результаты своих изысканий на примере очень простого функционала на JS, написанного в трёх разных стилях.

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

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

Около трёх месяцев назад я задумался о том, что в ближайшем будущем взаимодействие человека с техносферой (программно-аппаратно-сетевой инфраструктурой) будет происходить скорее через мессенджеры, такие как Telegram, чем через привычный браузер. Частое использование чатов на смартфоне быстро подтолкнуло меня к попытке снова попробовать голосовой ввод вместо привычных тапов по виртуальной клавиатуре или набора слов жестами. К моему приятному удивлению, распознавание голоса сейчас достигло очень высокого уровня как на Android, так и на iPhone. Причём настолько высокого, что STT (speech-to-text) стал для меня основным способом ввода текста в чатах, включая браузер.

Поскольку искусственный интеллект в целом, и технологии OpenAI в частности, уже практически стали повседневной нормой (по крайней мере, для меня), я, естественно, начал использовать голосовое общение и в GPT-чатах. А узнав о действиях (actions) в настраиваемых GPT-чатах, я сразу загорелся идеей соединить GPT-чат с каким-нибудь внешним приложением. Однако на этом этапе встал вопрос: как аутентифицировать пользователей чата во внешнем приложении? Несмотря на то что OpenAI предлагает использовать OAuth 2.0 для интеграции, в этой статье я рассмотрю альтернативный вариант — парольную аутентификацию, которая, на мой взгляд, лучше подходит для голосового взаимодействия.

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

В этой статье я продолжаю делиться результатами изучения создания телеграм-ботов в nodejs, начатой в предыдущих публикациях (раз, два). На этот раз я покажу, как организовать интерактивные диалоги с пользователями, используя модуль conversations библиотеки grammY. Мы рассмотрим, как настроить библиотеку для работы с диалогами, управлять их завершением, а также реализовать ветвления и циклы. Этот подход станет основой для более сложных проектов, где важно взаимодействие с пользователем.

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

Если коротко, то использование ChatGPT для автоматизации генерации кода эффективно при работе с шаблонами. Генерация однотипных фрагментов на основе шаблонов ускоряет процесс разработки и снижает количество рутинных задач. Чем точнее структура и наименования в шаблонах, тем легче модели корректно выполнять замены,

Для тех же, кто хочет более детально ознакомиться с процессом взаимодействия человека и ChatGPT при создании JavaScript-проекта - добро пожаловать под кат.

Я продолжаю описывать собственное погружение в мир телеграм-ботов, начатое в предыдущей публикации. Тогда я создал простого бота на Node.js с тремя стандартными командами (/start, /help, /settings) с использованием библиотеки grammY, который мог работать в режимах long polling и webhook. В этот раз я разработал бота, который манипулирует данными в базе по шаблону CRUD + List (CRUDL) с помощью аргументов команд. Из-за своей простоты, граничащей с примитивностью, это решение не подходит для коммерческих проектов, но может быть полезным в персональных проектах.

Время от времени я встречаю на страницах Хабра мысль, что современные браузеры не соответствуют современным требованиям, стали слишком сложными, делают всё не так и не туда, и вообще - ниша “забронзовела”, поделилась между игроками (Blink, WebKit, Gecko) и новичкам с новыми движками в неё стало невозможно попасть в принципе. В своей прошлой статье я коснулся основ работы с телеграм-ботами и в какой-то момент мне показалось, что я увидел прообраз “браузера будущего” - приложения, через которое люди будут подключаться к Сети совсем скоро (а некоторые подключаются уже сейчас).

Под катом я попытался формализовать словами свои субъективные ощущения (КДПВ не моя, это всё DALL-E).

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

Так как я предпочитаю использовать JavaScript и на фронте, и на бэке, то среда существования для бота была определена сразу же - nodejs. Осталось определиться с библиотекой - Telegraf или grammY? Так как у второй в примере использовался кошерный import, а у первой - старомодный require, я выбрал grammY.

Под катом - пример телеграм-бота в виде nodejs-приложения с использованием библиотеки grammY, который запускается как в режиме long pooling, так и в режиме webhook, созданный с применением моей любимой технологии - внедрения зависимостей через конструктор (TL;DR).

Когда я писал свою статью про интерфейсы в JS на примере фильма "Перевозчик" с Джейсоном Стейтемом, я решил использовать ChatGPT, чтобы он мне помог с фактологией. Например, выяснить, сколько весила сумка с девушкой-китаянкой и откуда-куда её должен был перевезти Фрэнк Мартин (герой Стэйтема). Хотя я пересмотрел фильм перед написанием статьи, поиск нужных сцен казался мне утомительным, и я решил срезать путь, обратившись к ChatGPT. Ведь всем известно, что ИИ скоро выкинет старый добрый поиск через Гугл на обочину истории.

Однако, результат меня разочаровал. Если коротко, то ChatGPT (как и любая LLM) работает с вероятностями и ей очень сложно, на грани невозможного, признать, что она чего-то там не знает. Она будет выдавать всякий мусор с очень низким правдоподобием, но так не скажет "извини, чувак, я не в курсе". Ну а если с деталями, то добро пожаловать под кат.

На эту статью меня сподвигла переписка в комментах с коллегой @iliazeus и его вопрос, как в @teqfw/di код может зависеть от интерфейса, а не от его имплементации. В своём ответе я попытался провести параллели с героем Джейсона Стэйтэма из фильма "Перевозчик" - с Фрэнком Мартином. У Фрэнка было три правила (условия контракта) и любой, кто удовлетворял этим правилам (и имел достаточно денег), мог нанять Фрэнка в качестве первозчика.

Ниже я продемонстрирую на примере Фрэнка Мартина, каким образом могут работать интерфейсы в обычном JS (не TS).

Эта статья для тех, кто знает, что такое “внедрение зависимостей” и имеет практический опыт его использования. Меня зовут Алекс Гусев и я являюсь автором библиотеки “@teqfw/di”. Цель моей библиотеки - дать возможность использовать функционал “внедрение зависимостей через конструктор” в проектах на JS (фронт и бэк) и TS (бэк). Минимальной единицей внедрения является отдельный экспорт es6-модуля. Поэтому библиотека не может использоваться с модулями CJS или UMD.

В основу внедрения зависимостей заложена идея о том, что вместо статического связывания исходного кода на этапе написания (через import) применяется динамическое связывание объектов программы в режиме выполнения. В моей библиотеке это достигается за счёт размещения в коде конструкторов (или фабричных функций) инструкций по созданию нужных им зависимостей, которые интерпретируются Контейнером Объектов при работе программы и на основании которых загружаются нужные исходники и создаются нужные зависимости.

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