Comments 12
Хоспаде. История попыток применения странных и неподходящих инструментов. Такое ощущение, что цель была - потренироваться в разных технологиях, не важно, подходят ли они продукту.
Ну да, конечно, всего-то второй по популярности движок для поиска, второй по популярности веб-фреймворк и самая производительная библиотека для подстветки синтаксиса :)
Scala
Compass Search зависел от множества внешних библиотек: Hibernate, Spring, генераторы байткода
Apache Tiles
Слой интеграции со Spring MVC
Mootools
Установка JDK (обычные JSP-страницы на JRE не работали); Установка сервлет-контейнера Tomcat или Jetty; Копирование приложения Пастера в специальный каталог webapps; Запуск сервлет-контейнера.
И это все вместо того, чтобы просто написать приложение на PHP.
Не, это явно был полигон для тренировок, а не приложение )
Так в чем суть? При чем здесь Андрей Карпати?
Эх... Вот бы ии агенты умели брать такие проекты, и актуализировать их...
А, заодно, в процессе актуализации, ещё и мониторинг, логгирование, ci/cd, безопасность с лучшими практиками выравнивать.
По сути, ведь, следуя принципу, что лучшее ТЗ это код, вот он, идеальный кейс для ии. Брать старый, но полезный продукт, и его актуализировать. Поженить отполированную десятилетиями идею с передним краем технологий. Что может быть лучше?
Что ИИ-агент примет за вас решение какую библиотеку втянуть внутрь и поддерживать самостоятельно а какую заменить? Или расскажет про несовместимости?
Что самостоятельно поймёт алгоритм, вложенный автором (даже, если он нелогичен), напишет на него тесты и убедится, что старый код их проходит, после чего воспроизведет алгоритм на новых технологиях, убедившись, что тесты остались зелёными, и мигрирует данные. Соответственно, я получу проект, который делает именно то, что делал оригинальный, но уже без остановившихся в развитии технологий под капотом. А, в идеале, ещё и стандартизированный. Скажем, есть политика партии в компании, что пишет код на раст и ES6, данные храним в pgsql, деплоим в GCP, а мониторим и алертим через ELK. Соответственно, все (за исключением каких-то специфических вещей типа монте-карло на GPU, или распределенных аналитических мап-редьюсов), что через эту мясорубку прошло, станет именно таким. Независимо от того, была там входе джава, ms access, или вообще запущенный на сервере excel.
Это красивая теория, сколь-нибудь сложную систему невозможно покрыть тестами ни целиком ни в достаточном для такой переделки объеме.
И менять технологии, как-либо влияющие на user experience тоже нельзя - получите другой продукт, который не факт что понравится пользователям.
Примеров масса.
Посмотрим. Помню, ещё в самом начале хайпа, мож, году в 2022м или начале 23го, не помню, но в то время, когда кодинг на LLM был чем-то странным, надо было сложный эвристический алгоритм сделать, ну, я его и сделал на питоне, посидев в дебаггере пару часов. Отдал пыхеру для внедрения в прод, потом написал ему уточнить, как будет внедрять, отдельным сервисом, или cli дергать, или ещё как-то, на что он ответил, что ещё час назад через гпт прогнал, 100% рабочий код на пхп получил, в свой проект вставил, и уже давно делает другие задачи.
Я то понимаю, что пример слишком прост, но, объективно, задача портирования одной логики между технологиями - вещь, которую можно идеально сформулировать, создать идеальную песочницу для reinforcement learning, и идеально оценить, имея код проекта с хорошим покрытыем тестами. Соответственно, что-что, а это уж машина как-то осилит
задача портирования одной логики между технологиями
Что будет если "портировать" раллийные колеса или форсированный v12 из Ламборгини в Жигули? Как думаете, это сделает Жигули спорткаром? Сможет она участвовать в гонках и не развалится ли на поворотах?
Продукт это всегда совокупность свойств, не что-то одно. Часто даже сами авторы не понимают этого.
как хорошо что я увлёкся асмом на пиках.
33 несчастья или история одного проекта