Какие существуют онлайн-IDE для разработки на PHP, устанавливаемые на unix-сервер?
Существуют ли в природе такие PHP-IDE, которые можно поставить на свой сервер и работать в ней удаленно?
В чем, собственно, прикол:
Иногда мне удобнее работать с разных машин (домашней, рабочей, ноут...), чем таскать везде ноут. От этого standalone-IDE от этого становятся менее удобными, потому что:
- если разворачивать проект локально - то синхронизация с удаленным сервером - это отдельный ад.
- если разворачивать полу-локально (файлы локально, но при каждом сохранении отправляются на сервер) - это всеравно гемор с синхронизацией в момент смены машины.
Ну и синхронизация средствами IDE - штука не очень надежная. раз сбой, два сбой - и уже никакой уверенности, что у меня локальная и удаленная копия идентичны... приходится полный аплоад/даунлоад делать.
Я одно время пробовал синхроинизроваться через git при смене машины (reset --hard при каждом пересаживании), в дополнение к синхронизации на лету при сохранении, но там тоже свои бесячие заморочки начались (типа задвоенного обновления, когда IDE воспринимает обнову через гит как изменение файлов, и начинает заливать эти же файлы повторно на сервак... а там еще SASS замечает изменения, перекомпилирует всё что ни попадя, после чего IDE тоже замечает изменения и начинает отправлять все css-ки... вобщем, адешник начинается )))
- если подмонтировать удаленный сервер себе к локальной машине как диск (ssрfs, netdrive и прочее) - и хранить проект именно там - получается почти отлично (в любой момент открываешь актуальный проект, без необходимости доп.синхронизации), но скорость обмена не дает корректно работать кодо-анализаторам (индексация простого проекта занимает десятки минут, а среднестатистический сайт на битриксе я на НетБинсе так и не открыл таким макаром, хотя заблаговременно исключил все тяжелые папки из индекса).
Собственно, воображение рисует такое решение:
- проект хранится удаленно (как исходники, так и вся служебная инфа)
- IDE также хранится удаленно (важно! ровно там же, где исходники, т.е. на моем сервере).
- IDE запускается удаленно (браузер? терминал? ...)
... короче, эдакий брат phpMyAdmin-а, только для PHP.
Да, я знаю про облачные IDE а-ля CodeAnywhere и собратья, но они все работают со своего сервера, а значит, возникнет ровно та же история, что и с вариантом "IDE локально, сорцы - удаленно" - т.е. переиндексация проекта встанет колом.
Вобщем, вопрос - решал ли кто-то такую задачу? Нашли ли решение?
И существуют ли в природе такие ИДЕшки?
1) прожектор - да, тоже обратил внимание, поизучаю. спасибо.
2) а вот насчет коде-виз-ми...
- версия для установки на свой сервер - судя по всему, доступна только в Ентерпрайз лицензии... я забыл написать, что я не миллионер? ))
- а в случае работы на серверах JB - я так и не понял, где сам код хранится и запускается?
Вам подойдет даже Premium US $10.00 в месяц
Ограничений по длительности сеанса нет
То что вы подумали про локальнуюсеть подразумевает подключение напрямую от клиента к клиенту
в премиуми в комюнити версии подключение пробрасывается через сервера JB но лагов вообще нет
Прожектор - штука прикольная. Полноценная ИДЕ в браузере - это забавно :)
Ставится несложно, но работает неспешншо, и почему-то регулярно вылетает :\
И главная беда (на что я делал ставку) - индексация проекта заметно не ускорилась (по сравнению с работой полностью на локалке). час ожидания - около 5% прогресса... а я всего лишь инет-магаз на Битриксе хотел открыть )) со всем ядром, да, но так было надо...
Уже отвечал в подобной теме тут
В вашем случае можно попробовать использовать VSCode с Remote Development (remote SSH | Remote - Containers | Remote - WSL)
Конечно VSCode все-таки придется установить локально и установить расширение. А вот остальное уже подхватится с сервера. В дальнейшем, при установке расширений в VSCode, вы будете иметь возможность установить их не на локальную машину - а на сервер.
хм... а я верно понял, что весь анализ кода делается именно расширением на сервере (и в трафик между локальной машиной и сервером не попадает)? в данном случае это - ключевой момент (т.к. в противном случае я бы ограничился sshfs, и спокойно жил бы "как будто локально").
...а вообще, поигрался с VSCode, и прямо скажу - не в восторге от автокомплита :\
там какие-то доп.плагины надо ставить, чтобы он научился хотя бы свойства/методы для объекта (скажем, для переменной с явно заданным типом - классом) корректно предлагать? или он всегда вот так вот всё подряд подсовывает, не особо анализируя весь проект?
спустя примерно месяц экспериментов - беру свои слова назад.
VSCode с установленными Intelephence и NamespaceResolver-ом, после небольших плясок с настройкой - оказался довольно годным вариантом. С т.з. работы с кодовой базой - конечно, отстает от Штормов и Нетбинов, но с т.з. быстродействия - на 3 головы обгоняет (что при многословной кодовой базе (битрикс со всем его ядром) и средненьким железе - имхо, даже перевешивает... например, окончания индексации всего проекта теми же Штормом и Бином я ни разу так и не дождался, что сводит на нет большинство их преимуществ).
Remote development оказался простым, как валанок, в настройке, и достаточно шустрым и стабильным (опять же, по сравнению с прожектором, который на недорогой VDS-ке подтупляет все-таки заметно, что в браузере, что в нативке "на этом конце").
Александр Х, некоторые VSCode используют еще и в portable варианте. Делают настройки соединения с сервером и записывают на флешку.
Кстати, VSCode особенно весело использовать с windows-планшетами (x86) с клавиатурой. С одной стороны и мобильное решение, с другой стороны если подключить монитор по HDMI, отдельные клавиатуру и мышь по USB, а у VDS увеличить мощности (ОЗУ там 32 или 64 ГБ), то в итоге получается гибридная рабочая станция :-)
Я одно время пробовал синхроинизроваться через git при смене машины (reset --hard при каждом пересаживании)
Честно говоря, IMHO вам следует научиться работать с git, потому что reset --hard при каждом пересаживании - это вы прямо вообще неправильно пользуетесь инструментом.
А так git это именно то, что надо для синхронизации.
это неправильно, но гитом для такой цели вообще пользоваться - неправильно, как по мне )
тут уж либо так, либо "не гитом", имхо.
а давайте поиграем в "критикуешь-предагай" :)
вот как бы вы правильно использовали гит для моих целей?
Имеем:
- 1 сервер, 2 локальных машины.
- необходимость почти моментальной отправки с локальной машины на сервер (чтобы "сохранил локальный файл, и тут же обновил страницу в браузере с сервера")
- пересаживания с машины на машину 100500 раз в произвольный момент времени (ну т.е. нормально оформлять коммит каждый раз - не вариант.. работа внезапно бросается на пол-пути, и начинается с того же места с другой машины... ну вот такие вот условия). Что в купе с предыдущим пунктом постоянно дает ситуацию, когда код синхронизирован между сервером и одной из локалок (а на другой он всегда отстает).
Как бы вы предложили организовать процесс, чтобы при этом и 100500 промежуточных коммитов не плодить, и "commit --amend && push -f" + "reset --hard" не делать?
Проблема в том, что у тебя неправильный workflow. Точнее его вообще нет.
Ты придумал неудобный способ работы с кодом, и пытаешься найти инструмент, который сделает за тебя магию.
Но самодисциплина - как раз именно то, что нужно.
Отправлять моментальные правки с локальной машины на сервер и при этом бросить работу в произвольный момент - означает риски в продакшене.
Нужно чтобы на каждой машине был локальный сервер, на котором можно "обновить браузер", проверить что все работает, а на сервер отправлять уже коммит.
Именно так, а не иначе.
Если же воркфлоу делать в принципе не хочешь по личным причинам - мучайся. Бери какой-нить google drive и синхронизируй автоматом все файлы. поместить весь git репо в гуглдрайв и будет синхронизироваться работа на всех устройствах.
Но опять повторю - твой способ работы это очень плохая самодисциплина. В попытке сделать себе "удобно" и сэкономить пару минут на возможность бросить работу в любой момент - ты делаешь хуже. Лучше выделять на работу более спланированное время с полноценными коммитами. Делать красивую историю коммитов не обязательно, все можно делать в отдельном бренче и мержить его в мастер через squash уже в самом конце.
во-первых, причем тут продакшен? разработческих серверов не существует чтоли?
есть деплой с дев-сервера на прод - там всё более-менее по-уму, цельными оттестированными коммитами.
а есть перескакивание с места на место во время работы на дев-сервере. тут и ресет-хард не так страшен, если другого выхода нет.
во-вторых, рассуждения о самодисциплине и планировании - это уже из серии об идеальном мире. это всё хорошо, когда это возможно, но не всё в мире крутится вокруг разработчика и его взгляда на жизнь, не всегда он имеет возможность диктовать условия. особенно, если разработчик еще параллельно еще и лицо от бизнеса (и решает еще и задачи, которые не будут ждать, пока он оформит коммит, а просто протухнут и приведут к убыткам).
ну окей, я вашу позицию услышал. она, в теории, верна, и на практике во многих случаях верна, но в моем конкретном случае - неприменима, с учетом реальных обстоятельств.
и суть вопроса - именно в поиске способа к этим обстоятельствам адаптироваться.
образно говоря, если к вам, как к доктору, пришел пациент со сломанной спиной - немного странно не учитывать текущую ситуацию, и советовать ему заняться спортом и приседать со штангой, чтобы ее упрепить :))) вцелом - совет верный, но здесь и сейчас - бесполезный.
образно говоря, если к вам, как к доктору, пришел пациент со сломанной спиной - немного странно не учитывать текущую ситуацию, и советовать ему заняться спортом и приседать со штангой, чтобы ее упрепить :)
Пример такой, что пришли вы со сломанной спиной и говорите - спина болит, а я хочу приседать со штангой. А я вам и говорю - что то, что вы делаете неправильно. Надо чтобы спина зажила, а там возможно уже и нельзя будет приседать со штангой.
Ваши обстоятельства действительно следует править.
да, в качестве инструмента попроще - google drive и другие подобные сервисы (я не работал с яндекс диском или еще чем-то подобным). Они просто синхронизируют указанную вами директорию с облачным диском. Соответственно ставишь google drive на все нужные компы и каждый раз как сохраняешь файл, изменения сразу в облако. Включил другой комп - оно из облака посинкало локально. Идеальное решение.
DEV сервера - ну на них по кусочкам сохранять что-либо коммитами тоже не есть гуд. Туда нужно отправлять уже более-менее законченные коммиты.
Пример такой, что пришли вы со сломанной спиной и говорите - спина болит, а я хочу приседать со штангой. А я вам и говорю - что то, что вы делаете неправильно. Надо чтобы спина зажила, а там возможно уже и нельзя будет приседать со штангой.
Ваши обстоятельства действительно следует править.
ну дык я ж и не говорю, что совет плохой... вцелом - да, всё верно, надо жить правильно, а неправильно - не надо... но это всё потом, когда заживет... а болит она сейчас... и вот прям здесь и сейчас мне от совета "надо делатьп равильно" легче ни капли не становится ))
да, в качестве инструмента попроще - google drive и другие подобные сервисы (я не работал с яндекс диском или еще чем-то подобным). Они просто синхронизируют указанную вами директорию с облачным диском. Соответственно ставишь google drive на все нужные компы и каждый раз как сохраняешь файл, изменения сразу в облако. Включил другой комп - оно из облака посинкало локально. Идеальное решение.
пробовал, в шапке же писал об этом... медленно очень. поправил, сохранил - и сиди жди, когда оно там до сервака долетит...
DEV сервера - ну на них по кусочкам сохранять что-либо коммитами тоже не есть гуд. Туда нужно отправлять уже более-менее законченные коммиты.
в смысле - а разрабатывать только на локальном сервере?
хотя... может и вариант, конечно... если разработка на локальном севрере - то и скорость гуглодрайвовой синхронизации не так парит, наверное...
парит только необходимость LAMP со всем окружением под виндой на древнем ноуте поднимать...
Вам по-моему нужен просто облачный клиент синхронизации папок по типу облака от mail.ru...
P.s. - то что вы описали называется терминальный сервер. Собственно погуглите и выберите подходящее решение. А идешка может быть любая.
да, пробовал в дропбоксе и на гуглдиске в свое время держать исходники... но пересаживание на другую машину - это тоже вечное ожидание, пока все прогрузится. А учитывая, что мне оно надо скорее для хотфиксов, чем для полноценной разработки (т.е. часто, но по 5..10 минут за раз) - то хочется избавиться от долгой загрузки проекта (возможно, даже ценой снижения общей скорости работы ИДЕ в процессе).
плюс, мне не понравилось очень задумчивая отправка изменений при сохранении... ну т.е. я сделал фикс, сохранил - а сайт обновить можно только через секунд 10..15, если повезет...
Дмитрий, ну не, vim - не считово )) я умные автокомплиты хочу, и анализ очепяток, как минимум ))
без этого всего - я и в NPP могу (особенно, когда сервак как диск подключен - удобно для небольших переделок). И все бы прекрасно, даже подсветка есть и автокомплыты какие-никакие - но хочется навигации по коду нормальной, и чтобы автокоплитило с умом, ну и очепятки подсвечивало...
Александр Х, ну может как то можно шторм на колдовать, как по мне самая топ ide
Там же недавно какую то штуку онлайн кодинг с шарой сделали, может получиться подружить
попробуй syncthing или resilio sync
на подобии rsync, только демоны и слушают поток inotify т.е. изменения в фс ловят сразу по окончанию записи в файл.
либо вариант с подключением удаленной фс сервера напрямую, к примеру через sshfs
pfg21,
насчет синхронизаторов - а как они ведут себя в случае обрыва связи (если файл не удалось синхроинизировать - при восстановлении они повторят попытку? с конфликтами умеют работать?)
насчет sshfs - я щас так и работаю, но такой вариант позволяет на этом конце только простой редактор иметь, а не полноценный ИДЕ, который регулярно тотально шерстит всю кодовую базу и строит индексы (т.к. скорость чтения не позволяет)
pfg21, настроил syncthing, потестил...
ну вобщем, инструмент, конечно, рабочий, но чудом тут и не пахнет.
около 10 секунд всреднем с момента сохранения на локальной до завершения обновления на сервере.
ваще не быстро (ну т.е. быстрее, чем те же дропбоксы с гуглдрайвами "через облако", но все равно до комфортной работы очень и очень далеко).
ну и та же проблема, что и с облачными дисками - нет никакого индикатора перед глазами, что "всё, изменения окончательно долетели до сервера, можно жать F5"... был бы лаг секунды 2-3, без него еще можно было бы жить.
резюмирую опыт ковыряния с этим вариантом:
+ работает быстрее гугл-драйвов и прочих дропбоксов.
+ пойнт-ту-пойнт синхронизация - это +100 к секьюрности.
- настраивается геморнее на порядок.
- наглядность использования - тоже отстает, даже в связке с индикаторами.
однако, для моих целей - увы, не самый удобный вариант.
но для каких-то других - вполне.
Изучите что такое докер и проблем у вас не будет, окружение везде одно, ну а что бы базы данных были одни просто надо развернуть где то на сервере копию для разработки.
Сам работаю и с ноута и рабочего компа, и с домашнего. Проблем нет.
У вас код в Гите должен быть.
Вы описали проблему того что трудно настраивать инфраструктуру, синхронизировать код.
Гит даёт один код везде, докер даёт одну инфраструктуру одинаковую
part_os, вообще-то, проблему я описал какраз обратную.
инфраструктура у меня одна (удаленный сервер, там и код, и веб-сервер с базами).
мне код с 2х машин надо редактировать (со всеми плюшками IDE).
- либо синхронизировать между сервером и 2-мя локальными (и git-а здесь явно недостаточно, как минимум, потому что синхронизация "туда" должна быть быстрой (секунда-две максимум, в момент сохранения).
- либо иметь возможность редактировать его прямо на сервере (но при этом не плодить гигантский трафик, когда IDE шерстит и анализирует код по всему проекту... соответственно, sshfs, как и удаленные веб-IDE - тоже мимо).
У вас какой то своеобразный, мягко говоря, взгляд. Вы смешали два процесса в один.
Кодить на проде это плохо. Не хочу даже рассказывать почему.
Использовать инфраструктуру прода для разработки тоже.
Процесс разработки новых фич или же починка багов. И процесс выкатки правок на прод это разные процессы.
Когда вы на проекте будете не одни. Поймёте это все.
part_os, а причем тут прод вообще?
серверов под разработку не существует чтоли? :))
как выше написал уже (в другой ветке) -
- есть дев-сервер (и проблема с пересадкой между машинами при работе на нем), где и грязные методы - не такой уж грех, пока за его пределы не уходят.
- а есть прод, куда уходит уже по-уму, цельными вылизанными коммитами (иногда дополнительно через стейдж, если шибко надо).
и даже когда я на проекте не один - на своем дев-сервере я все равно один.
Средний
