Ну чего сразу мрачные, был разрабом, значит знаешь как делать чтобы было хорошо. Даже если самому не писать, кто-то должен думать над архитектурой, тем как оно будет работать, где оно будет жить, как масштабироваться, как обеспечиваться отказоустойчивость. Про все эти мелочи кто-то должен думать, роботы хоть и могут все это обеспечить, их как минимум надо носом ткнуть. Короче нормально все будет, просто разрабы становятся менеджерами над роботами. Ну и никто не отменял ревью.
да, я видел этот замечательный параграф. Но думаю что код в много маленьких md не запихать. Тут нужен LSP, и вот он как раз позволит сэкономить уйму контекста потому что позволит нормально сращивать где что используется. Распихивание инфы в маленькие md не особо имеет смысл если для выполнения задачи модель все их прочитает.
В теории, ide может более грамотно работать с контекстом. Потому что у нее в индексе есть все связи между фунциями, а cli вероятно этим не заморачивается и пихает в контекст файлы целиком.
Cli обертки в целом делают тоже самое что любые другие, просто им встроили тулы позволяющими вызывать произвольные команды в терминале вашего компудахтера, без лишнего гемора. В целом это просто встроенные mcp.
Ps. Gemini cli может все тоже самое, а gemini 3 pro имеет весьма солидный бесплатный лимит.
Да, дело даже не в избыточности. Просто сама идея использовать контейнеры как некий заменитель виртуалки, немного сбивает с толку, и вызывает некоторое отрицание.
В таком подходе зависимости проекта не смешиваются с системным питоном и не протекают между стадиями сборки.
Думаю что в контейнере в принципе не нужно иметь больше одного питона, того который нужен для выполнения приложения. В случае если это соблюдается, то потребности в venv как будто бы отпадает.
Кроме того, на практике многие инструменты, типа, линтеры, чекеры, форматтеры и автокомплитеры (black, pylint, ruff, lsp и т. д.) ожидают наличие виртуального окружения или, по крайней мере, работают с ним более предсказуемо.
Я не очень понимаю зачем всё это нужно в контейнере. В всяком случае этого точно не должно быть в prod контейнере. По моему мнению, все это должно быть на рабочем месте у разраба а не в контейнере. По хорошему контейнер должен содержать только то что необходимо для работы приложения, а именно - код и установленные зависимости. Без изменения зависимостей сборка контейнера может укладываться в один вызов copy, что очень быстро.
poetry install в режиме установки root пакета требует наличия readme и исходного кода проекта.
Исходный код для установки зависимостей как раз не нужен, нужен только список зависимостей, которые нужно скачать\поставить (успешно эксплуатирую этот подход).
Человечество изобрело виртуальные частные сети, а при остром желании tls прикручивается к чему угодно.
S3 это такое же хранилище как любое иное и уж точно лучше чем ftp в плане возможностей. В случае сравнения с ftp вообще никаких "других" задач тут нету. Складывать\скачивать файлики можно, управление доступами есть. При необходимости файлики можно еще и красиво раздавать без необходимости ставить ftp клиент (который выпилили). ftp давно пора закопать и забыть.
На гитхабе релизы Minio от 2016 года доступны, для "домашнего" проекта, использовать немного устаревшую версию вполне допустимо, особенно если в мир не торчит. Плюс есть все еще бесплатный radosgw. Почти наверняка есть более близкие аналоги s3 интерфейса над файловой системой.
Зачем внутри контейнера нужен venv, это и так изолированная среда?
Зачем копировать src до вызова установки зависимостей, это решение приводит к тому что любое изменение кода приводит к необходимости пересобирать слой, вместо того чтобы взять слой с уже установленными зависимостями? Для ci пайплайнов такие упущения ведут к долгим пересборкам контейнеров, а они по хорошему не должны занимать дольше пары минут (нужно максимально использовать кеш слоев и кеш самого poetry).
Снятие лимитов тоже крайне сомнительная история, лимиты не просто так придуманы, они страхуют от ошибок. Например чтобы приложение не на открывало несколько десятков тысяч коннектов, из за какого нибудь бага. Для прода это особенно спорная история.
все верно, пусть игру гробит разработчик, а не лохалихатор который выкупил права и может крутить магазином как угодно. ВоВ кстати уже столько лет хоронят, странно что все еще жив. Наверно ничего ужасного с ним не происходит.
Сравнение изначально некорректное. Поскольку используются услуги открытые на разном железе заведомо находящемся в разных условиях в плане нагрузки на аппаратные компоненты. Не говоря о том что ноды "под куб" и "под вм" могут ощутимо отличаться аппаратной конфигурацией.
Для корректных замеров нужно использовать одну и туже вм (или набор вм). В идеале, с контролем того на какой ноде вм запускается при перезагрузке.
Окей, тоесть вы просто берете ollama, раните там какой то gguf. И видимо далее используете ollama api чтобы просто кидать запросики из java (или чего то еще) ?
Я почему то подумал что речь про оптимизацию и приложение целиком собрано в go монолит, вероятно с использованием langchaingo/eino и вот это все за 2-4 недели
Очень хотелось бы посмотреть на то как приложение для прода собирается за 2-4 недели, без возможности использовать фреймворки. Под go с этим вообще весьма туго, есть всего пара фреймворков
Вы сейчас описали любую профессию и процесс через который проходит любой человек который еще не обладает желаемым знанием. Инструкция вида "нажми две кнопки и все поедет' это продукт который упрощает жизнь тому кто не захотел тратить время и учится всему что лежит под капотом. За это многие готовы платить.
Даже если блогер что-то расскажет, это не будет полным и рабочим решением без вагона подводных граблей.
Ссылку на гитхаб не видно. На сколько знаю, уже давно есть несколько имплантации mcp для golang.
Вероятно еще какое то время будет полезно смотреть на код, но писать код руками скоро перестанут.
Ну чего сразу мрачные, был разрабом, значит знаешь как делать чтобы было хорошо.
Даже если самому не писать, кто-то должен думать над архитектурой, тем как оно будет работать, где оно будет жить, как масштабироваться, как обеспечиваться отказоустойчивость. Про все эти мелочи кто-то должен думать, роботы хоть и могут все это обеспечить, их как минимум надо носом ткнуть. Короче нормально все будет, просто разрабы становятся менеджерами над роботами. Ну и никто не отменял ревью.
да, я видел этот замечательный параграф. Но думаю что код в много маленьких md не запихать. Тут нужен LSP, и вот он как раз позволит сэкономить уйму контекста потому что позволит нормально сращивать где что используется. Распихивание инфы в маленькие md не особо имеет смысл если для выполнения задачи модель все их прочитает.
В теории, ide может более грамотно работать с контекстом. Потому что у нее в индексе есть все связи между фунциями, а cli вероятно этим не заморачивается и пихает в контекст файлы целиком.
Cli обертки в целом делают тоже самое что любые другие, просто им встроили тулы позволяющими вызывать произвольные команды в терминале вашего компудахтера, без лишнего гемора. В целом это просто встроенные mcp.
Ps. Gemini cli может все тоже самое, а gemini 3 pro имеет весьма солидный бесплатный лимит.
Да, дело даже не в избыточности. Просто сама идея использовать контейнеры как некий заменитель виртуалки, немного сбивает с толку, и вызывает некоторое отрицание.
Спасибо что поделились опытом.
Думаю что в контейнере в принципе не нужно иметь больше одного питона, того который нужен для выполнения приложения. В случае если это соблюдается, то потребности в venv как будто бы отпадает.
Я не очень понимаю зачем всё это нужно в контейнере. В всяком случае этого точно не должно быть в prod контейнере. По моему мнению, все это должно быть на рабочем месте у разраба а не в контейнере. По хорошему контейнер должен содержать только то что необходимо для работы приложения, а именно - код и установленные зависимости. Без изменения зависимостей сборка контейнера может укладываться в один вызов copy, что очень быстро.
Исходный код для установки зависимостей как раз не нужен, нужен только список зависимостей, которые нужно скачать\поставить (успешно эксплуатирую этот подход).
Докачка и на http отлично реализуется, еще в времена dial-up это активно использовалось.
Домашний проект, при чем тут интернет вообще.
Человечество изобрело виртуальные частные сети, а при остром желании tls прикручивается к чему угодно.
S3 это такое же хранилище как любое иное и уж точно лучше чем ftp в плане возможностей. В случае сравнения с ftp вообще никаких "других" задач тут нету. Складывать\скачивать файлики можно, управление доступами есть. При необходимости файлики можно еще и красиво раздавать без необходимости ставить ftp клиент (который выпилили). ftp давно пора закопать и забыть.
На гитхабе релизы Minio от 2016 года доступны, для "домашнего" проекта, использовать немного устаревшую версию вполне допустимо, особенно если в мир не торчит. Плюс есть все еще бесплатный radosgw. Почти наверняка есть более близкие аналоги s3 интерфейса над файловой системой.
Зачем внутри контейнера нужен venv, это и так изолированная среда?
Зачем копировать src до вызова установки зависимостей, это решение приводит к тому что любое изменение кода приводит к необходимости пересобирать слой, вместо того чтобы взять слой с уже установленными зависимостями? Для ci пайплайнов такие упущения ведут к долгим пересборкам контейнеров, а они по хорошему не должны занимать дольше пары минут (нужно максимально использовать кеш слоев и кеш самого poetry).
Снятие лимитов тоже крайне сомнительная история, лимиты не просто так придуманы, они страхуют от ошибок. Например чтобы приложение не на открывало несколько десятков тысяч коннектов, из за какого нибудь бага. Для прода это особенно спорная история.
+1, очень странно выбирать ftp когда есть Minio/nfs/smb. И тем более странно что если облака не подходят, предлагается это дело размещать на vds.
все верно, пусть игру гробит разработчик, а не лохалихатор который выкупил права и может крутить магазином как угодно. ВоВ кстати уже столько лет хоронят, странно что все еще жив. Наверно ничего ужасного с ним не происходит.
С жанром все нормально, просто если и играть в ММО, то только в то что разработчик игры сам издаёт.
Медаль за отвагу весит дофига. Но вообще, нативки выглядят так хорошо, что это подойдет исключительно не притязательным пользователям.
В прочем, vr игр нет, так что какая разница.
Сравнение изначально некорректное. Поскольку используются услуги открытые на разном железе заведомо находящемся в разных условиях в плане нагрузки на аппаратные компоненты. Не говоря о том что ноды "под куб" и "под вм" могут ощутимо отличаться аппаратной конфигурацией.
Для корректных замеров нужно использовать одну и туже вм (или набор вм). В идеале, с контролем того на какой ноде вм запускается при перезагрузке.
Окей, тоесть вы просто берете ollama, раните там какой то gguf. И видимо далее используете ollama api чтобы просто кидать запросики из java (или чего то еще) ?
Я почему то подумал что речь про оптимизацию и приложение целиком собрано в go монолит, вероятно с использованием langchaingo/eino и вот это все за 2-4 недели
Много воды, почти никакой конкретики.
Очень хотелось бы посмотреть на то как приложение для прода собирается за 2-4 недели, без возможности использовать фреймворки. Под go с этим вообще весьма туго, есть всего пара фреймворков
Вы сейчас описали любую профессию и процесс через который проходит любой человек который еще не обладает желаемым знанием. Инструкция вида "нажми две кнопки и все поедет' это продукт который упрощает жизнь тому кто не захотел тратить время и учится всему что лежит под капотом. За это многие готовы платить.
Даже если блогер что-то расскажет, это не будет полным и рабочим решением без вагона подводных граблей.
Материал ни о чем, рынок стагнирует. В части гарнитур все железо+- одинаковое.
Такой же ящик как и q3..