Старый дракон сломал зуб

Несколько постов выше я рассказывал вам про интеграцию Vite в Ruby/Rails приложение.

Это правда не сложно:
1️⃣ сделать авто запуск Vite при запуске Rails
2️⃣ Модифицировать rake assets:precompile для проды
3️⃣ Написать пару хелперов для вставки ассетов на страницу в Dev и Prod режимах.
4️⃣ Для особо упоротых типа меня сделать Proxy Middleware, чтобы все выглядело так, словно работает на одном хосте и порту.

Я довольно быстро сделал это все. До момента вывода в продакшн все было идеально.

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

Мне показалось, что моя реализация этого разбора на сложном проекте может быть довольно опасным занятием.

Качественный разбор Vite манифеста — это дело практики и тестирования. А времени на это у меня нет.

Мне достаточно хорошо платят, чтобы я вовремя предупреждал о возможных ограничениях и проблемах там, где у меня нет уверенности в хорошем результате. А тут у меня ее не было.

Как разрулить?

1️⃣ с клиентом мы договорились, что в условиях ограниченного времени нам нужен план B. И если не удастся использовать кастомную интаграцию, то мы всегда сможем вернуться к популярному решению.

2️⃣ Из кастомной интеграции не было уверенности только в хелперах вставки кода на страницу. Чем переизобретать велосипед, лучше взять готовое решение. Это и сделаем.

Итого:

Только один фрагмент задачи (да, важный) — придется на какое-то время использовать из ViteRuby.

Все остальное в чистом виде фронтового инструментария.

Разбор Vite манифеста в ViteRuby в традиции Ruby/Rails экосистемы неоправданно переусложнен.

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

Будет интересно довести ее до конца.

Я не ожидал, что разбор Vite манифеста нужно делать руками. в Webpack было проще. Но это было много лет назад.

Что не так c Vite манифестом?

В условиях ограниченного времени я не стал рисковать и взял готовое решение по интеграции ассетов на страницу прямо из ViteRuby.

Опасения у меня вызвала вот эта логика, которая собирает массив зависимостей, сплющивает, почему-то удаляет пустые значения (откуда они там вообще?) еще и удаляет дубликаты.

Что у вас тут вообще происходит? Разве это все не должно быть уже посчитано?

Разве не должно быть описано в документации по интеграции?

В общем, я так подумал, что миллионы леммингов не могут ошибаться и не нужно пренебрегать их опытом.

Нужно просто взять готовые хелперы и использовать их, а глубоко разобраться с вопросом позже.

На тему парсинга и сбора Vite ассетов можно сделать мини расследование и написать статью.

Обратите внимание на прекрасную новую фишку гитхаба — он теперь не плохо рассказывает что происходит в коде. Вот это чудеса!

https://www.oreilly.com/radar/the-end-of-programming-as-we-know-it/

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

Каждое упрощение программирования создавало новых программистов, а не убирало старых – Например, Windows упростил доступ к низкоуровневому программированию, а появление веба и мобильных устройств потребовало еще больше специалистов. Аналогично, API и облачные сервисы упростили разработку, но не уменьшили спрос на программистов.

Искусственный интеллект изменит задачи программистов, но не заменит их – AI-инструменты позволяют создавать код быстрее и удобнее, но все равно требуют контроля со стороны людей. Программисты превращаются в менеджеров цифровых сотрудников (ИИ-систем), создавая, настраивая и поддерживая их.

"Гибель упрямого разработчика" – Те, кто не адаптируется к новым инструментам (например, к ИИ в программировании), могут потерять конкурентоспособность. Но те, кто освоит новые технологии, останутся востребованными.

Опытные программисты используют ИИ эффективнее, чем новички – Хотя начинающие могут легко создать прототип с помощью AI, без глубоких знаний они не смогут исправлять ошибки и дорабатывать сложные проекты. Опытные разработчики, использующие AI, будут более продуктивными.

https://www.oreilly.com/radar/the-end-of-programming-as-we-know-it/

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

"Кодинг с AI" – новая парадигма программирования – Мы находимся в начале эры AI-ориентированного программирования (CHOP – Chat-Oriented Programming). AI-инструменты будут помогать в кодинге, но их использование потребует новых навыков.

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

Те, кто освоит AI, останутся в профессии – Будущее за теми, кто научится использовать ИИ в программировании, а не за теми, кто сопротивляется новым технологиям.

Автоматизация не снижает потребность в специалистах, а создает новые задачи – Как и в индустриальной революции, автоматизация освобождает людей для более сложных и творческих задач, а не делает их ненужными.

Атомарность, Атомарность, Атомарность

Пока коллеги по цеху спорят, есть ли шанс у кодинга c AI или нет шансов. Есть ли буст в разработке или нет — я работаю учителем-методистом для AI.

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

Все правила разработки и оформления кода педантично и фанатично описали в документации.

Благодаря этому компания из сотен разработчиков работала как единый организм. Нельзя было написать код, который бы не следовал правилам.

То, что случайно не попадало в документ — при первом же случае туда вносилось.

Любой комментарий на код-ревью всегда был подкреплен ссылкой на документ с правилами.

Безумно? Но это работало чтобы удерживать высочайшее качество кода в огромной компании.

Сегодня — я тоже самое делаю для AI.

Требования из книги правил и рецептов надо применять точечно. Иначе AI делает дичь.

АТОМАРНОСТЬ!