Лидер мнений в AI сфере сделал приложение-будильник за 3 запроса!
Все это — собачья чушь.
20 лет назад автор фреймворка Ruby on Rails заявлял, что теперь каждый может сделать за 15 минут блог на его гениальном фреймворке.
20 лет спустя ни одна CMS на Rails ни занимает ни одного процента рынка.
WordPress занимает 40-70%.
AI открывает нереальные просторы для создания сервисов и приложений!!!!
Ну и где? Где где эта лавина коммерческих продуктов и сервисов?
Нигде. И не будет этой лавины.
Ровно потому, что из 1.000.000 самых талантливых программистов, которыми заполнен наш мир, только единицы смогли создать свой продукт и стать коммерчески успешными.
Создание продукта это не просто кодинг. Это совершенно другая деятельность, где никакой AI никогда не поможет.
AI это хороший помощник. Но творческих и морально-волевых качеств он не прибавит.
Я надеюсь, что это последнее изобретение, которое мне пришлось сделать и я наконец смогу сфокусироваться на проекте, как на продукте, а не как на площадке, на которой я собираю свой JavaScript фреймворк, реализующий c нуля и переосмысливая многие идеи экосистем Ruby и Ruby on Rails.
Теперь, когда с настройкой и внезапной унификацией хелперов и окружений разобрались начинается следующая часть проблем.
Раньше (при синхронной загрузке) правильно инициализировались валидации, тк валидации хочется тоже показывать на языке пользователя.
Однако при асинхронном способе загрузке локалей теперь в момент инициализации схемы валидации не известно какой язык текущий. И идет фолбек на дефольтный.
И получается, что какой бы язык не выбрал пользователь — ошибки валиадции на дефолтном языке. Те на английском (в моем случае)
Исправить поведение можно передачей функции трансляции в момент инициализации компонент и схемы валидации. При использовании разных языков компонеты будут перерисовываться с учетом языка и инициализировать схему валидаций под текущий язык;
Поймать и понять и скорректировать такое поведение с учетом новых требований — это ресурс нескольких дней/недель в рамках работы в компании.
AI тут не помогает, тк он
1) не знает всех деталей желаемого 2) передача этих деталей невозможна в разовом формате, тк недостаточно информации о поведении системы 3) AI не знает особенностей поведения инструментов в разных окружениях 4) AI начинает зацикливаться и не может полностью "почувствовать задачу"
Итого: 1) чтобы получить итоговый результат, надо сформулировать задачу. 2) Чтобы сформулировать задачу — надо провести исследование. 3) Исследование для формулирования задачи приводит к фактическому решению задачи.
Допустим, мы взяли популярную библиотеку, чтобы в React приложении менять языки (локали)
Для простоты грузим все языки при загрузке приложения.
Так же можно поступать и в storybook, и в тестах.
В какой-то момент локалей становится больше и ты хочешь грузить их по необходимости. Переключил пользователь язык — загрузил условный китайский и приложение мгновенно его начало использовать.
Это значит, что для одного из окружений надо сделать асинхнонную подгрузку. Поменять конфиг, поменять подход загрузки приложения, чтобы оно вовремя знало что и как показывать.
В этот момент начинаются разногласия в окружениях, потому-что тебе не надо делать тоже самое для тестов. Там достаточно одной локали. В крайнем случае 2 если надо проверить переключение языков.
В этот момент оказывается, что при разных подходах загрузки, конфигурация странно влияет на хелперы трансляции и надо изобретать обертки, чтобы с этим справится.
— Сохраняюсь в Git, чтобы видеть и контролировать все новые правки — Прошу реализовать форму с нужными полями + прикладываю пример уже готовой формы — Проверяю базовую работоспособность — Внимательное ревью — Прошу раскидать большой массив кода на части — Проверяю базовую работоспособность — Прохожу по каждой детали и прошу внести правки — Проверяю базовую работоспособность — Запускаю тесты — Пытаюсь понять что идет не так на не работающих кейсах — Прошу исправить и Запускаю тесты, пока не станут зелеными — Проверка сторибука — Запуск, отладка существующих тестов / Исключение регрессии — Рефекторинг и формирование общих решений — Запуск, отладка существующих тестов / Исключение регрессии — Сохраняю в Git текущую порцию результата
На что обращаю внимание: — декомпозиция — валидация данных — локализация — нейминг — консистентность — типизация — отсутствие случайных и ненужных деталей — присутствие важных деталей
Вчера я вычистил первый Business Action до состояния, когда я стал им доволен.
Все на своих местах. Все так, как я хочу видеть.
Я подключаю необходимые типы, запросы, валидации, респонсеры и фокусируюсь только на логике действия.
Если пришли не валидные параметры запроса — возврат ошибки.
Если валидные — получаем переменные.
Проверяем пользователя на существование в Базе данных.
Возвращает результат.
Но самый блеск в этом коде — это валидатор, который жестко требует строго соответствия параметров, которые приходят от пользователя.
Привет Rails Strong Parameters!
Одна лишь эта строчка тут так удивила своей простой, силой и удобством, что у меня натурально случился взрыв мозга.
Благодаря тому, что у меня полный JavaScript/TypeScript стек — я могу практически все писать в едином стиле и на фронте и на бэке и держать жесткий контракт в разных частях системы и делать DRY решения по всему проекту.
Если взять в совокупности, ну, недели 3 я развлекался над бекендом.
Это все, конечно, размазано на несколько месяцев в перерывах между созвонами, консультациями, рутинным кодом и личными делами.
За это время я реализовал
✅ Коннектор к БД с транзакциями ✅ Миграции + database cleaner ✅ Довольно мощный роутер ✅ Подготовил окружение для тестов ✅ Strong Params в рельсовом стиле на Zod ✅ Архитектуру на основе Business Actions. ✅ Довольно хорошая типизация на TypeScript
У меня нет ORM. На JavaScript они все откровенное 💩 Славься Ruby on Rails! 👑
В этот раз я отказался от ORM. Вышел за границы личных ментальных искажений и принял факт, что лучше SQL ничего не придумано. (Спасибо проекту из Пенсильванского Университета, для которого я писал много SQL и познал дзен)
Я чертовски доволен результатом.
Я в одно лицо переработал под себя и кучу идей Rails. Взял все лучшее из обоих экосистем. Заставил работать и планирую развивать успех.
