В этой статье я продолжаю делиться результатами изучения создания телеграм-ботов в 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) применяется динамическое связывание объектов программы в режиме выполнения. В моей библиотеке это достигается за счёт размещения в коде конструкторов (или фабричных функций) инструкций по созданию нужных им зависимостей, которые интерпретируются Контейнером Объектов при работе программы и на основании которых загружаются нужные исходники и создаются нужные зависимости.

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

В этом посте я попытаюсь формализовать и систематизировать своё собственное понимание, какой должна быть структура SPA-приложений. Это очень субъективное изложение, отражающее мой собственный опыт. Оно относится к определённому классу веб-приложений (SPA, PWA) и не претендует на универсальность.

В контексте данной статьи SPA-приложение - это классическое клиент-серверное приложение, где клиент существует в браузере (как правило, в пределах одной страницы) и взаимодействует с сервером посредством HTTP-запросов. Приложение разрабатывается в виде набора npm-пакетов в стиле “модульный монолит”. Серверная часть реализована на движке Node.js.

Мне тут на днях попеняли, что, мол, я не в курсе, "что из esm до сих пор нельзя собрать бандл без транспиляции". Ну что я могу сказать... я действительно не в курсе :) На мой взгляд, es-модули придумали как раз для того, чтобы загружать по мере необходимости JS-код непосредственно в браузер, и собирать модули в бандлы - это, ну... как гладить кошку против шерсти.

Я понимаю, что традиции / привычки / требования бизнеса / обратная совместимость / корпоративная этика и т.п. говорят о том, что код для браузерных приложений должен поставляться в бандлах и точка! Тем не менее, в некоторых случаях (малые приложения, быстрое прототипирование, распределённая разработка) сборка бандлов является излишней и код в браузер можно и нужно загружать непосредственно в виде es-модулей.

Когда писал код очередной функции по форматированию даты, поймал себя на мысли, что делаю это уже с стотысячпятисотый раз. Разные ЯП, разные проекты, разные предметные области - а делать приходится одно и то же. Шлёпать формы на фронте, пилить CRUD на бэке, гонять между ними XML/JSON - вот и всё веб-программирование, по большому счёту. Раз за разом делаешь очень похожую работу, которая всегда чуть-чуть отличается от того, что было ранее.

Эта статья — изложение персонального опыта работы с кэшем на стороне браузера при создании веб‑приложений. В повседневной разработке я использую десктопный Chrome. У него есть панель инструментов и он в принципе удобен для разработчика. Но когда нужно проверять приложение на смартфонах, начинается геморрой — каким образом доставить на смартфон новый код, если там уже есть старый? Больше всего меня бесит Safari on iPhone. Если в Chrome есть возможность удалить все данные для отдельного сайта, то в iPhone все данные удаляются для всего Safari. Если и есть в iPhone какой‑нибудь способ удалить через конфигурацию смартфона/приложения данные для отдельного сайта, то мне так и не удалось его найти. Буду благодарен, если кто‑либо мне о нём сообщит в комментах.

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

Развитие идей Web 2.0 привело к тому, что пользователи сами стали товаром. Вернее, товаром стала информация об их связях и предпочтениях, которую собирают и монетизируют корпорации типа Google и Facebook. В ответ на это у многих пользователей появилось желание не делиться своими персональными данными с корпорациями, а хранить свои данные в недоступном для корпораций месте. Размышлениям о том, к каким последствиям может привести персонализация хранимых данных, и посвящена данная публикация. Сразу предупреждаю - это просто моё растекание мыслью по древу, а не "сборник рецептов" или разъяснения "как всё устроено". Не очаровывайтесь, чтобы не разочароваться :)

В данной статье я публикую свои размышления по поводу идентификации пользователей в плавно привходящей третьей версии веба - Web 3.0. Если коротко, то, в отличие от стремящегося к гипер-централизации Web 2.0 (в пределе - по одному веб-приложению разного типа на всё человечество с центром у какой-нибудь глобальной корпорации), Web 3.0 отличается как раз таки децентрализацией и повышенным вниманием к конфиденциальности пользовательских данных (хотя ничего не мешает тем же глобальным корпорациям контролировать функциональность этих децентрализованных приложений на уровне кода приложения или среды его выполнения - браузера или ОС).

Так какие же требования к идентификации могут предъявлять веб-приложения современного настоящего и ближайшего будущего?

Написать этот пост меня побудила статья "В чем конечная цель программирования?" и её обсуждение в комментах. Я поставил свой плюс за статью сразу же, как прочитал первое предложение:

> В том, чтобы иметь код, который легко изменять.

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

Но статья с таким очевидным (ну, лично для меня) выводом имеет, по состоянию на сегодня, оценку "-5" ("8" - в плюс, "13" - в минус). Под катом мои размышления о возможных причинах этого.

Этот пост не является прямым продолжением вот этого, скорее он является следствием. Как раз тот случай, когда “после” - таки значит “вследствие”. В оригинальном посте утверждалось, что Вселенная виртуальна, что прошлое вычисляется на лету, а случайности - псевдослучайны (что даёт возможность вычислять будущее). Я так широко не замахиваюсь, я лишь хочу изложить свою точку зрения, чем, на мой взгляд, Вселенная похожа на экран дисплея. Абсолютно ненаучное изложение, пригодное лишь для размягчения айтишных мозгов, утомлённых "греблей на галерах”. Заранее прошу прощения у тех, чей интеллект почувствует себя оскорблённым чтением сего опуса - я пока ещё не научился мыслить красиво. Тех же, кто не боится запачкать себя “псевдонаукой” - прошу под кат. Не волнуйтесь, длинных формул не будет.

В предыдущих публикациях (раз, два) я рассматривал возможности использования внедрения зависимостей в чистом JavaScript (без TypeScript, аннотаций и транспиляции). В данной публикации я продолжаю погружаться в вопросы использования DI в JS и более пристально рассматриваю роль идентификатора зависимости в создании объектов контейнером.

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

В своём предыдущем посте я попытался объяснить, что такое "инверсия контроля" и в каких случаях использование внедрения зависимостей в JS (ES6+) становится оправданным (если у вас в кодовой базе десятки npm-пакетов, в каждом из которых сотни, а то и тысячи es6-модулей). В этом посте я шаг за шагом покажу, как можно построить собственный контейнер объектов, который будет загружать исходный код es6-модулей, создавать нужные зависимости и вставлять их в нужные места. Сразу предупреждаю, что для упрощения изложения в демо-коде будут использоваться определённые допущения, связанные с генерацией объектов. Целью статьи является демонстрация собственно технологии внедрения зависимости, а не готового "всепогодного" решения. По итогу у вас должно сложиться понимание, как в ES6+ можно сделать свой контейнер объектов, если он вам вдруг по какой-то причине понадобится.

Этот пост является ещё одной попыткой сформулировать идею, зачем нужно внедрение зависимостей в ванильном JavaScript (именно в ES6+, а не в TS).

Основная сложность в том, что шаблон «внедрение зависимостей» (DI) есть следствие применение на практике «принципа инверсии зависимостей» (DIP). Классическая формулировка этого принципа выглядит так:

• A. Модули верхних уровней не должны зависеть от модулей нижних уровней. Оба типа модулей должны зависеть от абстракций.

• B. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.

Для JS‑программиста данная формулировка представляет определённую сложность в силу того, что в JS нет классических абстракций (в виде «интерфейсов» из других ЯП). В JS вообще нет абстракций, тут всё очень конкретно: вот объекты, вот примитивы — комбинируй.

Тем не менее, если спуститься с уровня теории на уровень практики, внедрение зависимостей вполне успешно может применяться даже в таком «конкретном» языке.

“Введение менеджера пакетов в веб-браузеры является интересной идеей, и на самом деле такой функционал уже существует в некоторых формах. Однако, на данный момент он не является стандартной функцией браузеров.” (с) da Vinci, text-002, OpenAI