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

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

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

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