Этот скрипт я как раз и писал с прицелом на то, чтобы сэкономить на черновой работе: быстро получить основу, а потом уже доводить руками. Полностью заменить верстальщика оно пока вряд ли сможет, но как стартовый инструмент экономит время. И под каждый отдельно взятый сайт можно промпт чуть менять и приближать к нужному результату.
Да, по сути всё сводится к GPT-Vision + текстовый промпт. Только я обернул это в готовый скрипт: автоматическая загрузка скринов, кодирование в base64, вызов API и сохранение адаптивного html на Tailwind. В итоге получается быстро перегонять любой сайт или даже дизайнерский PNG в адаптивную вёрстку. То есть идея простая, но пользоваться уже удобнее, чем делать всё вручную
Согласен, podman для CentOS/RedHat-дистров роднее и no-daemon у него круто реализован.
Тут docker просто уже стоял (исторически на CentOS 7 так чаще), а для задач типа dev-containers они почти одинаковы, тем более CLI совместим.
Но есть нюанс: образ с моей сборкой nvim можно легко забрать через docker save и кинуть на другой сервер (через docker load), и он там сразу заработает в том же виде. С podman это чуть сложнее для mix-инфраструктуры.
По задержке могу сказать так: на Linux разницы почти нет, потому что Docker использует тот же kernel, только в отдельных namespaces.
Я делал microbenchmark запуска Neovim (nvim --headless +qall) — получалось ~0.0170s нативно и ~0.0172s в docker, то есть разница <1%, что полностью в рамках погрешности.
На глаз и по ощущениям (открытие файлов, LSP hints, Telescope) тоже одинаково.
Так что на Linux это почти «натив», зато плюс: среда всегда повторяемая и можно быстро rebuild для другой конфигурации.
Да, всё верно, по-хорошему стоило бы сразу добавить -u $(id -u):$(id -g), чтобы uid/gid совпадали и файлы создавались с нужными правами. Что-то вроде:
docker run -it -u $(id -u):$(id -g)
В моём случае я для статьи просто поленился это прописывать — хотел сосредоточиться на nvim в docker. Но да, для «боевого» сценария с общей рабочей папкой или CI это было бы правильнее.
Да, открывать файлы по ssh и запускать nvim локально — это удобно, когда нужен просто редактор.
Но если проект требует LSP, линтеров, сборок — то серверное окружение (gcc, system includes, venv, специфические пакеты) должно совпадать.
Запуская nvim локально через scp://, ты получаешь autocomplete и проверки на своей машине, которые могут отличаться от того, что есть на сервере.
Поэтому docker здесь — не про «фигню», а про то, чтобы поднять точную среду сборки и анализа прямо на сервере, и получать LSP-диагностику ровно под ту систему, где это реально работает.
Vtun можно засунуть в ssh туннель. Они сами об этом говорят у себя в FAQ. После этого vtun превращается в еще большего Неуловимого Джо ))
Can I use vtun over SSH ?
Yes, via the port forwarding feature of ssh. Don't enable vtun's encryption as ssh does its own encryption. Also, make sure to select the TCP protocol as SSH can forward TCP but not UDP. An example session might look something like this
Да, но цель была, чтобы работало везде и у всех. То есть работало на андроидах, айфонах, айпадах. У бабушек, у дедушек, у соседки Даши, которая, постит фоточки в инсту. Когда едешь в метро, чтобы всё работало и т.д.
У менять есть з самые дешевые виртуалки в России, на разных хостингах. На каждом из них я настроил по одному варианту. Пока все три варианта работают. В том числе и vtun без шифрования и без сжатия. Будем посмотреть, что будет дальше ))
Да, пробовал. И даже на китайском )).
Это один из вариантов, который я перебирал:
https://github.com/leigest519/ScreenCoder/blob/main/html_generator.py
Этот скрипт я как раз и писал с прицелом на то, чтобы сэкономить на черновой работе: быстро получить основу, а потом уже доводить руками. Полностью заменить верстальщика оно пока вряд ли сможет, но как стартовый инструмент экономит время. И под каждый отдельно взятый сайт можно промпт чуть менять и приближать к нужному результату.
Да, по сути всё сводится к GPT-Vision + текстовый промпт. Только я обернул это в готовый скрипт: автоматическая загрузка скринов, кодирование в base64, вызов API и сохранение адаптивного html на Tailwind. В итоге получается быстро перегонять любой сайт или даже дизайнерский PNG в адаптивную вёрстку. То есть идея простая, но пользоваться уже удобнее, чем делать всё вручную
del
Спаси Господи!
Согласен, podman для CentOS/RedHat-дистров роднее и no-daemon у него круто реализован.
Тут docker просто уже стоял (исторически на CentOS 7 так чаще), а для задач типа dev-containers они почти одинаковы, тем более CLI совместим.
Но есть нюанс: образ с моей сборкой nvim можно легко забрать через docker save и кинуть на другой сервер (через docker load), и он там сразу заработает в том же виде.
С podman это чуть сложнее для mix-инфраструктуры.
Спасибо, рад что статья полезна.
По задержке могу сказать так: на Linux разницы почти нет, потому что Docker использует тот же kernel, только в отдельных namespaces.
Я делал microbenchmark запуска Neovim (nvim --headless +qall) — получалось ~0.0170s нативно и ~0.0172s в docker, то есть разница <1%, что полностью в рамках погрешности.
На глаз и по ощущениям (открытие файлов, LSP hints, Telescope) тоже одинаково.
Так что на Linux это почти «натив», зато плюс: среда всегда повторяемая и можно быстро rebuild для другой конфигурации.
От себя добавлю. sshfs для LSP — это боль: он бесконечно тормозит, treesitter и autocompletion умирают на latency.
Плюс, если на одном сервере python 3.2, а на другом 3.10 — локально придётся держать весь зоопарк, чтобы LSP / linters совпадали.
А так запускаешь docker прямо на сервере, и получаешь точно ту среду, в которой реально работает код — без костылей. Сразу же.
https://habr.com/ru/articles/696700/
Когда нужен просто старый vim — тогда хватает старого .vimrc, без докера и LSP.
Иногда нужен современный Neovim с LSP, treesitter и прочими фишками прямо на сервере, где локальная среда важна (тот же gcc, venv, include headers).
А одноплатники тут вообще не при чём — задача не в том, чтобы экономить, а чтобы получить определенную dev-среду.
Старый vim я и так могу поднять за 5 минут с git clone .vimrc. Но когда нужен современный nvim с lua + LSP — проще кинуть в докер.
Вот и все дела. Ничего тут нет особенного.
Просто в моём случае он нужен на сервере. Одно другому не мешает.
Да, всё верно, по-хорошему стоило бы сразу добавить
-u $(id -u):$(id -g), чтобы uid/gid совпадали и файлы создавались с нужными правами. Что-то вроде:В моём случае я для статьи просто поленился это прописывать — хотел сосредоточиться на nvim в docker. Но да, для «боевого» сценария с общей рабочей папкой или CI это было бы правильнее.
Да, открывать файлы по
sshи запускатьnvimлокально — это удобно, когда нужен просто редактор.Но если проект требует LSP, линтеров, сборок — то серверное окружение (gcc, system includes, venv, специфические пакеты) должно совпадать.
Запуская
nvimлокально черезscp://, ты получаешь autocomplete и проверки на своей машине, которые могут отличаться от того, что есть на сервере.Поэтому docker здесь — не про «фигню», а про то, чтобы поднять точную среду сборки и анализа прямо на сервере, и получать LSP-диагностику ровно под ту систему, где это реально работает.
Остальное - это эмоции.
Vtun можно засунуть в ssh туннель. Они сами об этом говорят у себя в FAQ. После этого vtun превращается в еще большего Неуловимого Джо ))
Can I use vtun over SSH ?
Yes, via the port forwarding feature of ssh. Don't enable vtun's encryption as ssh does its own encryption. Also, make sure to select the TCP protocol as SSH can forward TCP but not UDP. An example session might look something like this
https://vtun.sourceforge.net/faq.html
Спасибо. Чем больше вариантов, тем лучше.
Благодарю.
Ага, понятно, трафик в Россию в p2p не засовываете. А как вы вычисляете, что request идет в Россию?
Да, но цель была, чтобы работало везде и у всех. То есть работало на андроидах, айфонах, айпадах. У бабушек, у дедушек, у соседки Даши, которая, постит фоточки в инсту. Когда едешь в метро, чтобы всё работало и т.д.
У менять есть з самые дешевые виртуалки в России, на разных хостингах. На каждом из них я настроил по одному варианту. Пока все три варианта работают. В том числе и vtun без шифрования и без сжатия. Будем посмотреть, что будет дальше ))
А сервер где физически находится? В России? И как называется дата-центр куда не доходят пакеты?
Супер. Прикольно. Попробую.