А что так много в последнее время хайпа вокруг n8n? Подобные no code решения и 5 лет назад существовали, да и стали поддерживать нейронки ещё с 2023 года. Ещё тогда все ноуклдеры кричали о повальной автоматизации целых офисов.
Потом, как-то это всё забылось в инфополе из-за хайпа ИИ и вайбкодинга, а сейчас, что-то опять про nocode стали вспоминать.
Если дать ему доступ ко всему проекту на Github, и он начнет там ворочать - это можно легко что-то пропустить.
Так Codex и решает эту проблему. Ему даёшь доступ к репозиторию.
Описываешь задачу например исправь ошибку или напиши новый функционал. Как всегда, чем более грамотно технически задать вопрос, тем лучше будет результат.
Далее, Codex начинает работать над задачей, он сам ищет связанные файлы и сканирует, то что ему нужно. Чем-то похоже на курсор, только более комплексно.
Далее, он на каждую выполненную задачу создаёт отдельную ветку и Pull Request. Это очень удобно. В пул реквесте можно исправить конфликты, если таковые есть, хранить в ветках информацию о задачах, просматривать изменения в интерфейсе гитхаба или вообще любого инструмента для работы с git.
Если код кривой, то можно пул реквест закрыть не применив.
Из доп. плюсов можно настроить окружение. Например можно прописать команды, которые он выполнит после завершения задачи, например установить зависимости и сделать билд или запустить автотесты, он автоматом поправит ошибки, если таковые будут при выполнении команд.
И на мой взгляд самое удобное, он может работать параллельно над несколькими задачами и поскольку Codex работает с github можно не бояться, что 2 задачи изменят один и тот же код, т.к. всегда можно исправить конфликты (а они бывают редко) в пул реквестах.
В общем, я за Codex готов теперь любые деньги платить, т.к. он и с разными ЯП работает (со всеми что и обычный GPT) и интеграцию с гитхабом имеет, и контекст довольно большой держит, и даже может вполне писать код используя малоизвестные библиотеки. Можно например не тянуть всю папку с библиотеками в реозиторий, а временно только с вашей библиотекой и он будет её использовать в написании кода. Я кстати для своих пед проектов (где и использую кодекс), делаю под каждый пул задач новый репозиторий, куда выгружаю, только необходимый для понимания контекста нейронки код.
В общем звучит, как реклама, но я просто правда впечатлён Codex, наверное единственная нейронка после самого GPT, которая меня реально удивила.
Я вообще не понял к чему вы это. Каким боком orm и то что вы видели плохих бэкендеров, относится к перегруженности фронтенд фреймворков?
> я - сеньор дотнет бэкенд девелопер, мне эти ваши фронтовые свистоперделки не нужны Тут вообще не понял к чему это и как в теории "фронтенд свистоперделки", относятся к плохому бэкенду? Открою секрет, на бэкенде и фронтенде оптимизация и архитектурные подходы разные, по очевидным причинам. Я не говорю, что фронтенд вообще не нужен, давай те всё на html писать. А писал, что многие фронтенд проекты на нём чаще всего "перегружены" из-за фреймвороков и это проблема не отдельных людей, а фронтенда в целом.
> Entity Framework почему то гарантии 600+ запросов в БД на один запрос в API, и 10 юзеров не могут нормально работать с сайтом Просто в дополнении, я не знаю как можно даже в теории использовать ORM так чтобы 1 запрос к серверу генерил 600 запросов в бд, учитывая, что большинство из ORM чуть ли не автоматом применяет жадные загрузки, имеет встроенный функционал для батчинга и т.д.
И это тоже проблема, потому что многие браузеры так же по факту набор готовых библиотек, зачастую с кучей мусора и легаси внутри, прикрученных к форку хромиума.
> проблема более прозаична - бабки Но лично я и не предлагаю писать прямо всё с нуля. Если вы писали на php наверное 100% сталкивались с symfony или laravel. Эти фреймворки, по факту собраны из десятка никак не связанных библиотек, каждую из которых я могу использовать отдельно в ванильном php и к каждой я могу в теории сделать fork чтобы, например убрать тот функционал, который не использую (но это уже оверхед). Почему нельзя делать так же для js?
> Аналогия: я могу писать на чистом SQL, а могу взять орм. Кстати очень хороший пример, учитывая что ORM есть на любой вкус и цвет от минималистичных, до "приборных панелей космического корабля". И это хороший пример того, что когда я использую ORM (готовую, самописную не важно), то мне не нужно чаще всего для её использования ставить целый отдельный фреймворк. с папкой модулей на 500мб весом. Опять же аналогия из php. Я могу писать на ванильной php, но использовать только готовый router, минималистичную orm и этого уже будет достаточно. Я вот этого не понимаю, почему так же не принято делать в js? Если нужно написать большой проект, то окей проблем в фреймворках не вижу, но для большинства проектов они избыточны имхо. Точнее избыточно их содержимое.
Спасибо. Я скорее про то, что фреймворки превратились в большие мусорки, куда навалено всё подряд и даже в крупных проектах зачастую не используется и половина от функционала ядра, который попадает зачастую полностью в конечный билд.
Касаемо солидности, то это в целом проблема IT. Я часто от заказчиков слышал, мол "мы не хотим чтобы вы использовали этот стек, потому что это не солидно". Это, к сожалению есть везде.
Я предлагаю использовать в фреймворках только то, что нужно, а не тянуть за собой кучу бесполезных библиотек по типу is-num, is-string и т.д. Уже молчу про то, что появились мета фреймворки, которые наваливают ещё больше анюзлес кода в проекты.
Касаемо ssr, то имхо, но как по мне it сфера потратила десяток лет, чтобы от этого уйти, но по итогу фронтендеры изобрели php5 с phpQuery из-за чего мы снова видим в коде например sql запросы в html тегах. Однако это отступление
Опять же у вас странная позиция. ssr это всё же больше про бэкенд решение, я же говорил про фронтенд фреймворки и что они сильно захламлены.
Я вообще не понимаю зачем нужны эти фаши курсоры, клауди апи и т.д. если OpenAi создал Codex. Пока он в тестовом режиме и в будущем, вроде как буду вводиться лимиты, но как понял это затронет больше энтерпрайз тарифы.
Ах да, чтобы использовать Codex, нужно на минимальном уровне уметь пользоваться гитхабом, но большинство вайб кодеров не в состоянии его осилить, судя по комментариям под видео и статьями о Кодексе.
Можете кидать в меня камнями, но большинство фреймворков вообще избыточны и многое можно создать без них на js/ts. Единственное для чего нужны фреймворки - библиотеки компонентов и разный сахар, что позволяет делать проекты быстрее. Однако какой ценой. Вы в папку node_modules пустого проекта на том же react давно заглядывали? Поизучайте на досуге сколько там мусора на несколько сотен мегабайт и всё это тянется в конечные билды. Имхо, но оно того не стоит. Да, можно стать богом оптимизации веб пака и vite, "обвесить" их десятками плагинов, но это не спасёт от попадания мусора в билды. Лично мне бы хватило пачки готовых компонентов под чистый ts на котором можно спокойно реализовывать бизнес логику, как удобно. Хоть в функциональном стиле, хоть в ООП, что лучше для того или иного проекта. Однако, я больше бэкендер и может, чего-то не понимаю.
Для меня веб разработка, это любая серверная разработка, начиная от банальных сайтов и заканчивая теми же игровыми серверами или финтех решение, которое вы упомянули.
Видимо значение "веб разработки" с годами изменилось, потому что я из того, поколения, когда под вебом понималось далеко не только крудошлёпство. И имел ввиду, что к оффлайн приложениям термин хайлоад если и применяется то намного реже.
что же все-таки не так с ООП, если лично мне быстрее, проще и понятнее — реализовывать свои проекты на функциональном эликсире
И далее разговор о проблемах только ООП, и не слово о проблемах с аллокациями памяти и сборщиками мусора, работой с общими состояниями, тот же спагетти код с монадами в сложных проектах. Ваша статья воспринимается, как противопоставление ФП против ООП, даже если вы так не считаете.
Иными словами, в ООП нет ничего прям плохого, но только пока вы не погрузились в сильно связанный хайлоад.
Может вы и не работаете с вебом, но это была ваша претензия к ООП в контексте веба. Ведь термин хайлоад, чаще всего применяется в контексте работы с веб бэкендом.
Объектная модель всем хороша в однопоточной среде.
Что? На C#, Java, C++ например ООП нормально работает в многопоточности. Честно, дальше не читал, но судя по комментариям, там перлов много. Уже молчу, что по логике автора, те же проблемы могут возникать вполне себе и при ФП. Потому что конкурентоспособность никто не отменял и изменение одного и того же объекта может вызвать такие же проблемы.
Вообще, проблема многопоточности имеется в основном на web бэкенде. Изначально подразумевалось, что потоки должны быть изолированы и потом уже добавили возможность получать или изменять данные из одного потока в другом при помощи всяких invoke. Однако, на серверах может крутиться множество потоков, либо, как с node js, один основной поток и очереди на выполнение в нём кода. При этом все эти потоки по сути выполняют один и тот же код, с одними и теми же данными, что и является проблемой организации конкурентного доступа, а не парадигмы. В других многопоточных приложениях, обычно не такое большое количество потоков и важнее синхронизация данных между ними. Например, игра в которой game loop это один поток с рендером и логикой, звуки про омываются во втором потоке, ui например это третий поток. Пример стрёмный, но в контексте хороший. В такой игре мы имеем изолированные потоки, выполняющие разный код с разной бизнес логикой, их всего 3 и важна синхронизация данных между ними. А на бэкенде код и бизнес логика одна порой на сотни потоков, что приводит к другим проблемам.
Только не надо мне говорить, что качество промышленной продукции в СССР было гамном
А теперь будьте добры, показать где, я такое написал, это уже "борьба с соломенным чучелом".
Я говорил про то, что СССР понимал проблему бюрократии и то что IT может её решить. Вы сами пишите про какию-то бабку Маню с тётей Клавой, явно не представляя, как выглядит даже сейчас выглядит архивно-документационный отдел. Уж простите но тётя Клава в две руки не потянула бы документооборот и отчётность на заводе. Касаемо предоставленных вами данных, честно самому лень чекать, но GPT 4.5 с вами не совсем согласен.
Я удивился на этом моменте, когда у них на производстве в теории можно было прогонять через рабочее место одну и ту же деталь, а записывать, как несколько. Любой ОТК, подобные махинации очень быстро раскроет.
Папочки это прошлый век, можно сделать так же нормальный электронный документооборот и тех. процесс по отделам, чтобы можно было проследить например весь путь детали и где были проблемы.
Было всё тоже самое, но с огромным количеством бюрократии, которую сейчас можно заменить ERP (правда S3 и кубер имхо тут и правда немного лишние). СССР кстати, так же сильно развивал компьютеризацию, потому что это могло бы спасти страну от бюрократии, но до рассвета IT, не дожил.
Про объёмы производства, надо задавать вопросы не начальству и программистам, а тем-кто за 30 лет у власти сначала всё разрушил, а потом не смог или не хотел ничего восстанавливать. Вот сейчас во время войны, что-то впопыхах пытаются оживить.
Заграницей спад количества вакансий по ощущениям ещё больше.
То что, многие уехали из России после войны, на найм не сильно повлияло. Думаете заграницей так легко устроиться или перевезти туда свой бизнес? В части стран, даже имея внж не всегда оно даёт право на работу. Во многих странах ЕС например, работодатель должен доказать почему он берёт на работу иностранца, а не местного, у которого кроме визы ничего нет. Так что огромное количество программистов уехало забугор, но работает дальше в России.
Касаемо кризиса найма, то война конечно повлияла, но экономически, плюс лопнуло 2 пузыря за последние 3 года, это AI пузырь и пост ковидные сокращения бюджетов и темпов разработки. Отсюда и кризис по всему миру, а война это доп. условие для ухудшения просто.
Есть визуальное программирование, но что-то те, кто пытались на нём создавать большие проекты без единой строчки кода в текстовых файлах, не особо довольны таким экспириенсом)
А что так много в последнее время хайпа вокруг n8n? Подобные no code решения и 5 лет назад существовали, да и стали поддерживать нейронки ещё с 2023 года. Ещё тогда все ноуклдеры кричали о повальной автоматизации целых офисов.
Потом, как-то это всё забылось в инфополе из-за хайпа ИИ и вайбкодинга, а сейчас, что-то опять про nocode стали вспоминать.
Угу, я пробовал копайлот, но он очень слаб, даже платный. Там есть несколько нейронок внутри и они все подходят только для снипетов.
Пробовал warp cli и мне понравилось. Codex лично для меня спасение от рутины, учитывая параллельную работу.
Так Codex и решает эту проблему. Ему даёшь доступ к репозиторию.
Описываешь задачу например исправь ошибку или напиши новый функционал. Как всегда, чем более грамотно технически задать вопрос, тем лучше будет результат.
Далее, Codex начинает работать над задачей, он сам ищет связанные файлы и сканирует, то что ему нужно. Чем-то похоже на курсор, только более комплексно.
Далее, он на каждую выполненную задачу создаёт отдельную ветку и Pull Request. Это очень удобно. В пул реквесте можно исправить конфликты, если таковые есть, хранить в ветках информацию о задачах, просматривать изменения в интерфейсе гитхаба или вообще любого инструмента для работы с git.
Если код кривой, то можно пул реквест закрыть не применив.
Из доп. плюсов можно настроить окружение. Например можно прописать команды, которые он выполнит после завершения задачи, например установить зависимости и сделать билд или запустить автотесты, он автоматом поправит ошибки, если таковые будут при выполнении команд.
И на мой взгляд самое удобное, он может работать параллельно над несколькими задачами и поскольку Codex работает с github можно не бояться, что 2 задачи изменят один и тот же код, т.к. всегда можно исправить конфликты (а они бывают редко) в пул реквестах.
В общем, я за Codex готов теперь любые деньги платить, т.к. он и с разными ЯП работает (со всеми что и обычный GPT) и интеграцию с гитхабом имеет, и контекст довольно большой держит, и даже может вполне писать код используя малоизвестные библиотеки. Можно например не тянуть всю папку с библиотеками в реозиторий, а временно только с вашей библиотекой и он будет её использовать в написании кода. Я кстати для своих пед проектов (где и использую кодекс), делаю под каждый пул задач новый репозиторий, куда выгружаю, только необходимый для понимания контекста нейронки код.
В общем звучит, как реклама, но я просто правда впечатлён Codex, наверное единственная нейронка после самого GPT, которая меня реально удивила.
Я вообще не понял к чему вы это. Каким боком orm и то что вы видели плохих бэкендеров, относится к перегруженности фронтенд фреймворков?
> я - сеньор дотнет бэкенд девелопер, мне эти ваши фронтовые свистоперделки не нужны
Тут вообще не понял к чему это и как в теории "фронтенд свистоперделки", относятся к плохому бэкенду? Открою секрет, на бэкенде и фронтенде оптимизация и архитектурные подходы разные, по очевидным причинам. Я не говорю, что фронтенд вообще не нужен, давай те всё на html писать. А писал, что многие фронтенд проекты на нём чаще всего "перегружены" из-за фреймвороков и это проблема не отдельных людей, а фронтенда в целом.
> Entity Framework почему то гарантии 600+ запросов в БД на один запрос в API, и 10 юзеров не могут нормально работать с сайтом
Просто в дополнении, я не знаю как можно даже в теории использовать ORM так чтобы 1 запрос к серверу генерил 600 запросов в бд, учитывая, что большинство из ORM чуть ли не автоматом применяет жадные загрузки, имеет встроенный функционал для батчинга и т.д.
И это тоже проблема, потому что многие браузеры так же по факту набор готовых библиотек, зачастую с кучей мусора и легаси внутри, прикрученных к форку хромиума.
> проблема более прозаична - бабки
Но лично я и не предлагаю писать прямо всё с нуля. Если вы писали на php наверное 100% сталкивались с symfony или laravel. Эти фреймворки, по факту собраны из десятка никак не связанных библиотек, каждую из которых я могу использовать отдельно в ванильном php и к каждой я могу в теории сделать fork чтобы, например убрать тот функционал, который не использую (но это уже оверхед). Почему нельзя делать так же для js?
> Аналогия: я могу писать на чистом SQL, а могу взять орм.
Кстати очень хороший пример, учитывая что ORM есть на любой вкус и цвет от минималистичных, до "приборных панелей космического корабля". И это хороший пример того, что когда я использую ORM (готовую, самописную не важно), то мне не нужно чаще всего для её использования ставить целый отдельный фреймворк. с папкой модулей на 500мб весом. Опять же аналогия из php. Я могу писать на ванильной php, но использовать только готовый router, минималистичную orm и этого уже будет достаточно. Я вот этого не понимаю, почему так же не принято делать в js? Если нужно написать большой проект, то окей проблем в фреймворках не вижу, но для большинства проектов они избыточны имхо. Точнее избыточно их содержимое.
Спасибо. Я скорее про то, что фреймворки превратились в большие мусорки, куда навалено всё подряд и даже в крупных проектах зачастую не используется и половина от функционала ядра, который попадает зачастую полностью в конечный билд.
Касаемо солидности, то это в целом проблема IT. Я часто от заказчиков слышал, мол "мы не хотим чтобы вы использовали этот стек, потому что это не солидно". Это, к сожалению есть везде.
Действительно, а потом открываешь 10 вкладок в браузере и 10гб оперативки, как не бывало.
Я предлагаю использовать в фреймворках только то, что нужно, а не тянуть за собой кучу бесполезных библиотек по типу is-num, is-string и т.д. Уже молчу про то, что появились мета фреймворки, которые наваливают ещё больше анюзлес кода в проекты.
Касаемо ssr, то имхо, но как по мне it сфера потратила десяток лет, чтобы от этого уйти, но по итогу фронтендеры изобрели php5 с phpQuery из-за чего мы снова видим в коде например sql запросы в html тегах. Однако это отступление
Опять же у вас странная позиция. ssr это всё же больше про бэкенд решение, я же говорил про фронтенд фреймворки и что они сильно захламлены.
Что? Для таких задач использовать ts/js очень странное решение. Обычно подобное пишут на Java, C#, Rust и т.д.
Зачем мне писать очередной JWT менеджер? Я вообще не особо люблю JWT.
> Такое чуство что вы кроме 5 страничных проектов ни чего более крупного не пытались делать....
Причём тут страницы проекта, если вы говорите вообще о бэкенд технологиях?
Я вообще не понимаю зачем нужны эти фаши курсоры, клауди апи и т.д. если OpenAi создал Codex. Пока он в тестовом режиме и в будущем, вроде как буду вводиться лимиты, но как понял это затронет больше энтерпрайз тарифы.
Ах да, чтобы использовать Codex, нужно на минимальном уровне уметь пользоваться гитхабом, но большинство вайб кодеров не в состоянии его осилить, судя по комментариям под видео и статьями о Кодексе.
Можете кидать в меня камнями, но большинство фреймворков вообще избыточны и многое можно создать без них на js/ts. Единственное для чего нужны фреймворки - библиотеки компонентов и разный сахар, что позволяет делать проекты быстрее. Однако какой ценой. Вы в папку node_modules пустого проекта на том же react давно заглядывали? Поизучайте на досуге сколько там мусора на несколько сотен мегабайт и всё это тянется в конечные билды. Имхо, но оно того не стоит. Да, можно стать богом оптимизации веб пака и vite, "обвесить" их десятками плагинов, но это не спасёт от попадания мусора в билды. Лично мне бы хватило пачки готовых компонентов под чистый ts на котором можно спокойно реализовывать бизнес логику, как удобно. Хоть в функциональном стиле, хоть в ООП, что лучше для того или иного проекта. Однако, я больше бэкендер и может, чего-то не понимаю.
Для меня веб разработка, это любая серверная разработка, начиная от банальных сайтов и заканчивая теми же игровыми серверами или финтех решение, которое вы упомянули.
Видимо значение "веб разработки" с годами изменилось, потому что я из того, поколения, когда под вебом понималось далеко не только крудошлёпство. И имел ввиду, что к оффлайн приложениям термин хайлоад если и применяется то намного реже.
И далее разговор о проблемах только ООП, и не слово о проблемах с аллокациями памяти и сборщиками мусора, работой с общими состояниями, тот же спагетти код с монадами в сложных проектах. Ваша статья воспринимается, как противопоставление ФП против ООП, даже если вы так не считаете.
Может вы и не работаете с вебом, но это была ваша претензия к ООП в контексте веба. Ведь термин хайлоад, чаще всего применяется в контексте работы с веб бэкендом.
Что? На C#, Java, C++ например ООП нормально работает в многопоточности. Честно, дальше не читал, но судя по комментариям, там перлов много. Уже молчу, что по логике автора, те же проблемы могут возникать вполне себе и при ФП. Потому что конкурентоспособность никто не отменял и изменение одного и того же объекта может вызвать такие же проблемы.
Вообще, проблема многопоточности имеется в основном на web бэкенде. Изначально подразумевалось, что потоки должны быть изолированы и потом уже добавили возможность получать или изменять данные из одного потока в другом при помощи всяких invoke. Однако, на серверах может крутиться множество потоков, либо, как с node js, один основной поток и очереди на выполнение в нём кода. При этом все эти потоки по сути выполняют один и тот же код, с одними и теми же данными, что и является проблемой организации конкурентного доступа, а не парадигмы. В других многопоточных приложениях, обычно не такое большое количество потоков и важнее синхронизация данных между ними. Например, игра в которой game loop это один поток с рендером и логикой, звуки про омываются во втором потоке, ui например это третий поток. Пример стрёмный, но в контексте хороший. В такой игре мы имеем изолированные потоки, выполняющие разный код с разной бизнес логикой, их всего 3 и важна синхронизация данных между ними. А на бэкенде код и бизнес логика одна порой на сотни потоков, что приводит к другим проблемам.
А теперь будьте добры, показать где, я такое написал, это уже "борьба с соломенным чучелом".
Я говорил про то, что СССР понимал проблему бюрократии и то что IT может её решить. Вы сами пишите про какию-то бабку Маню с тётей Клавой, явно не представляя, как выглядит даже сейчас выглядит архивно-документационный отдел. Уж простите но тётя Клава в две руки не потянула бы документооборот и отчётность на заводе. Касаемо предоставленных вами данных, честно самому лень чекать, но GPT 4.5 с вами не совсем согласен.
Я удивился на этом моменте, когда у них на производстве в теории можно было прогонять через рабочее место одну и ту же деталь, а записывать, как несколько. Любой ОТК, подобные махинации очень быстро раскроет.
Папочки это прошлый век, можно сделать так же нормальный электронный документооборот и тех. процесс по отделам, чтобы можно было проследить например весь путь детали и где были проблемы.
Было всё тоже самое, но с огромным количеством бюрократии, которую сейчас можно заменить ERP (правда S3 и кубер имхо тут и правда немного лишние). СССР кстати, так же сильно развивал компьютеризацию, потому что это могло бы спасти страну от бюрократии, но до рассвета IT, не дожил.
Про объёмы производства, надо задавать вопросы не начальству и программистам, а тем-кто за 30 лет у власти сначала всё разрушил, а потом не смог или не хотел ничего восстанавливать. Вот сейчас во время войны, что-то впопыхах пытаются оживить.
Заграницей спад количества вакансий по ощущениям ещё больше.
То что, многие уехали из России после войны, на найм не сильно повлияло. Думаете заграницей так легко устроиться или перевезти туда свой бизнес? В части стран, даже имея внж не всегда оно даёт право на работу. Во многих странах ЕС например, работодатель должен доказать почему он берёт на работу иностранца, а не местного, у которого кроме визы ничего нет. Так что огромное количество программистов уехало забугор, но работает дальше в России.
Касаемо кризиса найма, то война конечно повлияла, но экономически, плюс лопнуло 2 пузыря за последние 3 года, это AI пузырь и пост ковидные сокращения бюджетов и темпов разработки. Отсюда и кризис по всему миру, а война это доп. условие для ухудшения просто.
Есть визуальное программирование, но что-то те, кто пытались на нём создавать большие проекты без единой строчки кода в текстовых файлах, не особо довольны таким экспириенсом)
Статья хорошая, но кому лень читать, советую сразу перейти в конец к Выводам. Там кратко написана база.