Комментарии 56
Ну и в Options, Unity можно поснимать галочки с пунктов Show borders и Show badges, чтобы Linux окна никак не выделялись на фоне остальных. Хотя это совсем не обязательно.
А можно совсем не ставить никаких иксов.
Пробовал работать на Windows. Поставил все, что надо, промучился неделю, поставил Fedora второй операционкой.
Была предпринята попытка настроить подсистему Ubuntu на Windows. Потыкался, что-то попытался поставить и настроить. Это не работает, то глючит, документации внятной не найдешь.
Странно, у меня завелась с пол-тыка. Всё, в целом, работало. Виртуалки, в общем-то уже и не нужны.
Иногда бывает гемор, когда в проекте используются компоненты, которые идут только под Линукс. Например, системы очередей и отложенного выполнения.
Ковырял как напрямую этот WSL, так и докер в нем. Все работает замечательно, никаких проблем сейчас нет (но еще этим летом они все же были). Единственное ограничение, которое сейчас мне мешает, это невозможность в vs code заставить python работать через через баш, хотя в теории достаточно прописать путь к питону как bash -ic python. Но issue есть и скоро вроде починят.
А почему не dual boot? Мне в целом не понятно, по какой причине windows может быть удобнее как рабочая среда для программиста, если вы не связаны с .net.
Все верно, у нормального программиста на рабочем месте должен быть линукс. Об этом я написал в самом начале статьи. Но я не совсем программист, у меня кроме разработки еще куча побочных задач, которые занимают даже больше рабочего времени и требуют Windows приложений.
Ну и dual boot в таких условиях это дико неудобно.
Ну и dual boot в таких условиях это дико неудобно.
у нормального программиста на рабочем месте должен быть линукс
Это такой обязательный атрибут чтобы приобщиться к "илите"?
Не имею ничего против линукса, но почему не допускается вариант, что может быть удобнее windows?
Мы работаем, в первую очередь, с набором ПО, а не с самой операционной системой. И набор ПО под windows для решаемых мною задач мне нравится больше.
Скажем, полноценного аналога Total Commander до сих пор нету.
И, раз уж речь в статье про веб разработку, то и аналога OpenServer нету. А он крайне удобен.
Потому что одинаковый набор ПО на разных ОС, частенько, имеет совершенно разные проблемы.
Когда долгое время в команде в подавляющем большинстве случаев используется Mac OS и различные GNU Linux дистрибутивы, то получается так, что с большинством проблем ты и твоя команда уже сталкивались, вы знаете как их решить. В самом худшем случае — помощь для Mac OS и GNU Linux в гугле находится довольно скоро. И, зачастую, для Mac OS даже не приходится какой-то отдельный подход выискивать.
А теперь в нашу команду приходит разработчик на Windows, у которого возникают какие-то свои совершенно волшебные проблемы, с которыми помочь не только мы, но и гугл особо не в силах, у него всё почему-то начинает тормозить, файлы в VM не синхронизируются, о нормальном запуске проекта с помощью Docker (к слову, у нас всё на заранее сбилденных образах, поэтому подниматься должно прекрасно) и говорить не приходится.
Особые умельцы не говорят о своих проблемах и поднимают проект как-то по своему, в итоге, во время разработки, их изменения не работают на стейджинге так, как хотелось бы, а ответ от разработчика банален — «У меня локально всё работает».
Во избежания подобного беспорядка, мы стараемся просто не работать с разработчиками, которые используют Windows. К сожалению, мы его не осилили. К счастью, разработчиков, использующих Windows не так много.
Всё вышесказанное относится к веб-разработке на Python + Django.
Когда долгое время в команде в подавляющем большинстве случаев используется Mac OS и различные GNU Linux дистрибутивы, то получается так, что с большинством проблем ты и твоя команда уже сталкивались, вы знаете как их решить. В самом худшем случае — помощь для Mac OS и GNU Linux в гугле находится довольно скоро. И, зачастую, для Mac OS даже не приходится какой-то отдельный подход выискивать.
А теперь в нашу команду приходит разработчик на Windows, у которого возникают какие-то свои совершенно волшебные проблемы, с которыми помочь не только мы, но и гугл особо не в силах, у него всё почему-то начинает тормозить, файлы в VM не синхронизируются, о нормальном запуске проекта с помощью Docker (к слову, у нас всё на заранее сбилденных образах, поэтому подниматься должно прекрасно) и говорить не приходится.
Особые умельцы не говорят о своих проблемах и поднимают проект как-то по своему, в итоге, во время разработки, их изменения не работают на стейджинге так, как хотелось бы, а ответ от разработчика банален — «У меня локально всё работает».
Во избежания подобного беспорядка, мы стараемся просто не работать с разработчиками, которые используют Windows. К сожалению, мы его не осилили. К счастью, разработчиков, использующих Windows не так много.
Всё вышесказанное относится к веб-разработке на Python + Django.
и требуют Windows приложений
VirtualBox с виндой в Seamless mode пробовали?
Статья называется
Открываю вижу:
Где тут настройка Windows?
PS. Когда я хочу кушать, я покупаю еду, а не завод по изготовлению полуфабрикатов.
Настройка Windows для веб разработки в 2017 году
Открываю вижу:
Xubuntu 14.02 64-bit как подсистема линукс
Где тут настройка Windows?
PS. Когда я хочу кушать, я покупаю еду, а не завод по изготовлению полуфабрикатов.
PhpStorm цепляет на себя композер, месс дететкор, код сниффер и юнит тесты. XAMPP крутит апач и базу — хватает по самые уши, если что-то нужно особенное типа gearman или redis то есть виртуалка — centos с командной строкой, которая подхватывает расшаренную с ней папку htdocs и запускает своим апачем, контент же продолжает использовать mysql с винды по айпишнику.
В винде вообще ничего настраивать не нужно (ну, хостс по вкусу), в виртуалке и линуксе по минимуму по стандартным мануалам.
Честно говоря, очередной набор костылей. Есть же Docker(в винду же завезли уже?), вот она веб-разработка в 2017 году.
А вы статью то прочитали, или сразу комментировать пошли? Докер на винде работает медленно. Обходные пути вроде как есть, но выглядит это как раз, как костыли.
Я не сомневаюсь что у вас есть какие-то проблемы, но у нас вся разработка идёт через Docker for Windows и не могу сказать что мы как-то страдаем от скорости дисковой системы. Учитывая, что затем развёртка на прод идёт также в контейнерах, мы получаем максимально идентичное окружение у разработчиков.
Докер на Win10 работает нативно быстро, если используется Hyper-V драйвер. Тормоза вольюмов VBox можно обойти, настроив файл-синк проекта шторма в руками созданный докер-хост на убунте. Если у вас Win10 — то просто поменяйте подсистему виртуализации и все залетает
Автор, а с какими проблемами с VirtualBox вы столкнулись? Там тоже есть Seamless-режим, и он вроде как работает в свежих версиях GNU/Linux дистрибутивов. По функционалу оно точно не уступает 7 версии WMware Player.
Лично у меня при установке Ubuntu Server 16 с установкой ubuntu-desktop --no-install-recommends в принципе не хотят работать иксы (после логина, выкидывает назад на экран логина), и даже с полной установкой десктопа не устанавливаются дополнения virtual box. Следовательно, даже буфер обмена не пашет.
Может я конечно невнимательно прочитал, но у меня вопрос:
Веб-разработка, за исключением очень редких случаев, делается на интерпретируемых языках, а значит, им плевать на каком типе ОС стартовать (ок, редкие проблемы типа Unicorn на Linux можно обойти).
Какую конкретно техническую проблему решает все это нагромождение?
Веб-разработка, за исключением очень редких случаев, делается на интерпретируемых языках, а значит, им плевать на каком типе ОС стартовать (ок, редкие проблемы типа Unicorn на Linux можно обойти).
Какую конкретно техническую проблему решает все это нагромождение?
Веб разработка помимо языков программирования включает в себя много других технологий. Веб серверы, базы данных, сборщики и препроцессоры на NodeJS, Memcache, Varnish, Selenium, Apache Solr, Git, Bash скрипты и много еще всякого, особенного на сложных проекта. Большинство из этих нехнологий можно установить на Windows, но результат не всегда такой же как в Linux.
Самая большая проблема это отсутствие нативной поддержки Docker контейнеров, (Docker for Windows пока ещё не очень хвалят).
Самая большая проблема это отсутствие нативной поддержки Docker контейнеров, (Docker for Windows пока ещё не очень хвалят).
Так, давайте по списку:
Вопрос «Какую конкретно техническую проблему решает все это нагромождение?» остался открытым :-)
- NodeJS, Memcache — абсолютно одинаковое поведение, что на Windows, что на Linux.
- Selenium — не используется на Dev (он нужен для QA). Но даже если бы использовался, то попал бы в список выше к ноде и мэмкэшу.
- Varnish — не имеет к приложению никакого отношения. Это реверс-прокси.
- Apache Solr — написана на Java, с ее хваленой кросс-платформенностью
- Git — он обязан стоять на Windows при любом раскладе, потому что там IDE
- Bash — не нужен в веб-разработке
Вопрос «Какую конкретно техническую проблему решает все это нагромождение?» остался открытым :-)
Мы уже 5+ лет разрабатываем довольно сложный web проект под Windows. Со всем как-то справляемся. Гит (сервер), в офисе, правда, стоит под виртуалкой на линуксе, поставили один раз, вместе с виртуалкой сразу, настроили под себя и забыли.
Присоединюсь, абсолютно никаких проблем в веб-разработке на «венде» нет, как и собственно не понятно какие проблемы затрагивает автор в статье (конкретно не приведено ни 1 проблемы, которую автор решил или настроил). Дополню список:
Не обессудьте, но все же несколько «камней» в огород *nix кинуть тоже можно — как часто работаете с версткой? Как там photoshop? Я все понимаю, есть gimp и krita, но не зря большинство дизайнерских разработок в формате .psd…
Поэтому тоже присоединяюсь к вопросу — какую именно техническую проблему решает автор статьи?
P.S. — почему автор выбрал 14.04? Мы живем в разных ветках времени с вами? 16.04 вышла полтора года назад, на носу — 18.04 LTS с gnome.
- Веб-сервер: никаких проблем, подымайте nginx/apache, готовые бинарники всегда есть на сайтах разработчиков
- Базы данных: mysql,pgsql а так же ряд noSql вполне удовлетворительно работают, бинарники опять же есть на сайтах разработчиков
- git отлично работает из cmd/powershell, кроме того есть очень удобные GUI для новичков (привет от github for desktop)
- Интерпретаторы: php 5/7 TS/NTS, ASP.NET, ruby. Единственное, где я «хапнул горя» был python 3.5.x, где возникли проблемы со сборкой, если верно помню, драйвера для субдб из pip
- Проблема с докером действительно существует в win, но она не настолько критична для dev-env
Не обессудьте, но все же несколько «камней» в огород *nix кинуть тоже можно — как часто работаете с версткой? Как там photoshop? Я все понимаю, есть gimp и krita, но не зря большинство дизайнерских разработок в формате .psd…
Поэтому тоже присоединяюсь к вопросу — какую именно техническую проблему решает автор статьи?
P.S. — почему автор выбрал 14.04? Мы живем в разных ветках времени с вами? 16.04 вышла полтора года назад, на носу — 18.04 LTS с gnome.
как часто работаете с версткой? Как там photoshop? Я все понимаю, есть gimp и krita, но не зря большинство дизайнерских разработок в формате .psd
Avocode прекрасно закрывает этот вопрос
Бекенд + сервер у нас свой, Delphi. Апач, насколько я знаю, работает без вопросов под Win.
БД — firebird или postgres. Так как разработка ведётся под Delphi, проблем с базами нет вообще — можно почти любую относительно быстро и просто подключить.
Гуёвые GIT клиенты под виндой работают без вопросов.
Фронт — jQuery. В основном у нас не вёрстка, а довольно навороченное веб-приложение (WebGL). Постепенно переползаем под UniGUI.
БД — firebird или postgres. Так как разработка ведётся под Delphi, проблем с базами нет вообще — можно почти любую относительно быстро и просто подключить.
Гуёвые GIT клиенты под виндой работают без вопросов.
Фронт — jQuery. В основном у нас не вёрстка, а довольно навороченное веб-приложение (WebGL). Постепенно переползаем под UniGUI.
Selenium — не используется на DevИспольуется. Тесты это часть проекта. Их приходится писать, дебажить и т.д.
Bash — не нужен в веб-разработкеНужен. Очень помогает автоматизировать рутинные задачи.
Вопрос остался открытымВы пропустили в своём списке «главную» проблему — Докер. Он сейчас в большом тренде. У некоторых компаний наличие Докера на локальной машине это системное требование. Докер испольуются для быстрого разворачивания сложного рабочего окружения, его унификации в команде, для одновременного запуска нескольких версий одного и того же программного обеспечения. Ну и всякие модные нынче микросервисы тоже хотят его.
P.S. Локальное окружение очень зависит от масштаба и сложности проектов. Тем кто занимается разработкой небольших сайтов с упором на вёрстку, Windows вполне даже подходит. На другой стороне средние и крупные проекты у которых сложность локального стека может зашкаливать.
Bash — не нужен в веб-разработке
Нужен. Очень помогает автоматизировать рутинные задачи.
На винде есть ему альтернатива — powershell. Синтаксис там, не спорю, другой — но не могу сказать что одна из программ заведомо хуже другой. Как правила, аргументы за bash сводятся к привычке.
Ну и bash тоже не проблема на винде использовать — он есть в составе MSYS, Cygwin и WSL. Выбирайте любой.
PS если стоит Git for Windows — загляните в папку usr\bin которая там внутрях :-)
Испольуется. Тесты это часть проекта. Их приходится писать, дебажить и т.д.
Разработчики пишут модульные тесты, а не интеграционные/системные. Для них Selenium не нужен.
Очень помогает автоматизировать рутинные задачи.
Например?
Вы пропустили в своём списке «главную» проблему — Докер. Он сейчас в большом тренде. У некоторых компаний наличие Докера на локальной машине это системное требование.
Трэнды, хайпы, моды — это все понятно. Я ж спрашивал про техническое обоснование. Если вы работаете на Windows, это не значит, что вы должны сегодня же удалить все docker-compose/Dockerfile файлы. Нет, пусть они там будут, они правда нужны для других целей.
На другой стороне средние и крупные проекты у которых сложность локального стека может зашкаливать.
Средние и крупные проекты — там уже не веб-разработка. Нельзя целый огромный проект назвать вэбом, только потому, что у него есть веб-интерфейс, который даже не поднимает разработчик, который пишет там какие-то недра. К тому же я все еще сомневаюсь, что что-то из этого стэка не встает на Windows.
P.S. это не я вас минусую.
А какие проблемы с Selenium? У меня codeception для AcceptanceTests вполне безошибочно работает с selenium'ом и драйвером для chrome, настройка закончилась загрузкой selenium-standalone.jar и chrome-driver.exe.
Docker на win вполне себе работает, возможно с некоторыми проблемами в виртуализации, но по моему мнению для dev-env этого хватает за глаза.
Так это не проблема венды, это конкретно проблема самого проекта в плохой организации его структуры или неудачном выборе инструментария…
Docker на win вполне себе работает, возможно с некоторыми проблемами в виртуализации, но по моему мнению для dev-env этого хватает за глаза.
На другой стороне средние и крупные проекты у которых сложность локального стека может зашкаливать.
Так это не проблема венды, это конкретно проблема самого проекта в плохой организации его структуры или неудачном выборе инструментария…
А когда вы стартанули свой проект на PHP 7.1?
Как-то статья вообще ни о чем. В итоге всё свелось к банальной виртуалке. Зачем вообще было писать статью?
Я лично достаточно долго использовал виртуалку, но всё равно это не очень комфортно, так как тормоза портят всё удовольствие. В итоге сейчас у меня отдельная впс, на которой ведется вся разработка. При этом можно менять как перчатки с минимумом усилий и саму машину с которой вести разработку. И опять же можно работать хоть из под винды, хоть из под линукса.
Я лично достаточно долго использовал виртуалку, но всё равно это не очень комфортно, так как тормоза портят всё удовольствие. В итоге сейчас у меня отдельная впс, на которой ведется вся разработка. При этом можно менять как перчатки с минимумом усилий и саму машину с которой вести разработку. И опять же можно работать хоть из под винды, хоть из под линукса.
Так вышло, что на моей работе используется только Windows. Переход на какую-то другую ОС просто невозможен. Порядка 50 серверов работают с MySQL 5.7, PHP7.1 и Apache 2.4. MySQL и Apache легко устанавливаются как службы Windows и управляются как из консоли так и обычным способом из списка служб. Каждая программа настраивалась отдельно, потом создавался образ системы и дальше уже он раскатывалась на все машины. На машине разработчика PhpStorm или IntelliJ IDEA запустить не проблема. Также используем MySQL Workbench, Git, Composer и т.д. Каких-то особых проблем с запуском софта или потребностей использовать XAMMP, Denwer и т.п. не возникало.
Оставлю только одно слово Vagrant
берем xubuntu 14.02
Это что еще за зверь? О_о
Знаю 14.04 и там уже давно есть 14.04.5
Я в Вашем случае использую VirtualBox в котором крутится Ubuntu 16.04 (без Х) + LXD
Не знаю, что Вам не понравилось / не удалось в связке Win10 + вся удобная среда разработки + WSL.
Мое утро (иногда день, вечер или ночь) начинается так: запускается винда, запускается PhpStorm, DataGrip, прочие мелочи для удобной жизни, дальше запускается WSL, вводится команда ./start.sh, и поехали.
sudo service postgresql start
sudo service redis-server start
sudo service elasticsearch start
sudo service gearman-job-server start
sudo service rabbitmq-server start
sudo service php7.1-fpm start
sudo service supervisor start
sudo service nginx start(да-да, мне все еще иногда бывает нужен gearman)
все пакеты php и nginx работают из коробки человека с ником ondrej
sudo apt-add-repository ppa:ondrej/php
sudo apt-add-repository ppa:ondrej/nginxвсе проекты находятся в своих папках где они обычно лежат в винде: C:\Users\...\PhpStormProjects\MyProject, доступ к ним легко получается по алиасу /mnt/c/Users/.../PhpStormProjects/MyProject. Единственное условие, чтобы юзернейм виндового юзера был латинницей (не знаю, может уже пофиксили), либо класть проекты в папку "не по умолчанию".
Поскольку WSL и все-все-все работает локально и используется мной для целей разработки/тестирования, мне не нужно заморачиваться насчет прав доступа, мой юзер WSL добавлен в sudoers и в группу root. Вебсервер и прочее заводится с полпинка и ни на что не жалуется. В хосты прописываем что-то вроде myproject.local 127.0.0.1 и вуаля, радуемся жизни.
Если кому-то интересно, могу запилить подробное описание всего процесса настройки, но я думаю из здесь присутствующих это вряд ли кому-то будет интересно, ибо все и так уже все умеют.
Друзья, я думаю, у всех разные проекты, разные задачи. Кому-то подходит одно, другому другое. Я тоже очень долго сидел на Windows, о чем написано в статье. Потом это стало крайне неудобно, в связи с ростом проектов и ростом стеков технологий, а также работой всей остальной команды под Linux. Пришлось искать решение, на что я потратил очень немало времени. Возможно, кто-то другой сбережет свое время благодаря этой статьей.
Я поделился своим опытом, может он кому-то окажется полезным. Может кто-то найдет для себя приемлемое решение из комментариев. Это тоже хорошо. Поэтому всем, кто поделился своим рецептом, большое спасибо!
Я поделился своим опытом, может он кому-то окажется полезным. Может кто-то найдет для себя приемлемое решение из комментариев. Это тоже хорошо. Поэтому всем, кто поделился своим рецептом, большое спасибо!
Проблема поста — не в вашем опыте, а в том что заголовок не соответствует содержанию.
Ну может быть я и ошибся с заголовком. Посоветуете подходящий?
Я вижу, вы расстроились, что вас тут закидали. Не расстраивайтесь. Вам нужно просто доработать и статья будет очень полезная.
Во-первых, нужно переработать это с учетом того, что существует Vagrant.
Во-вторых, это можно сделать с быстрым Docker'ом — не надо использовать shared volumes просто.
После этого название статьи само отрисуется.
Во-первых, нужно переработать это с учетом того, что существует Vagrant.
Во-вторых, это можно сделать с быстрым Docker'ом — не надо использовать shared volumes просто.
После этого название статьи само отрисуется.
Ну в общем то да.
А как работать то без shared volumes? Docker-sync или еще что-то? Возможно, но к моменту, когда я до него дошел, у меня накопилась определенная усталость от разных костылей и проблем на Windows, которых у коллег с Linux не было.
А как работать то без shared volumes? Docker-sync или еще что-то? Возможно, но к моменту, когда я до него дошел, у меня накопилась определенная усталость от разных костылей и проблем на Windows, которых у коллег с Linux не было.
По поводу shared volume. Вы можете подключать двумя путями:
В первом случае — это shared volume (который называется foo и который видно в docker volume list). Во втором случае вы просто получаете прокинутый вниз до хост-машины маунт. Как раз в ту директорию, в которую у вас и IDE смотрит (и в ней в директорию foo).
Работает очень быстро.
Одна проблема вас только ждет: docker конфликтует с Hyper-V functions, а VirtualBox от них зависит. Придется переключать в зависимости от того, что выбрали.
- -v foo:/mnt
- -v ./foo:/mnt
В первом случае — это shared volume (который называется foo и который видно в docker volume list). Во втором случае вы просто получаете прокинутый вниз до хост-машины маунт. Как раз в ту директорию, в которую у вас и IDE смотрит (и в ней в директорию foo).
Работает очень быстро.
Одна проблема вас только ждет: docker конфликтует с Hyper-V functions, а VirtualBox от них зависит. Придется переключать в зависимости от того, что выбрали.
Зачем тащить иксы, если нужно просто запуске веб-сервера? Ubuntu server тут за глаза. И уже давно 16 версия актуальна.
А так да в целом статья не соотвествует заголовку. Причем тут windows если все равно все к линуксу свелось? Не проще уж тогда сразу на линуксе сидеть?
А так да в целом статья не соотвествует заголовку. Причем тут windows если все равно все к линуксу свелось? Не проще уж тогда сразу на линуксе сидеть?
Непонятно почему Вы ругаете Windows, если и сами на ней работаете?
Если Вы считаете себя разработчиком, то не открываете же Вы IDE под Linux на 30 сек?
Поэтому установите вторую систему и перегрузка в другую ОС для Вас самый оптимальный вариант. И нет никаких проблем: можно использовать все прелести Linux, и спокойно работать в своей любимой Windows!
Если Вы считаете себя разработчиком, то не открываете же Вы IDE под Linux на 30 сек?
Поэтому установите вторую систему и перегрузка в другую ОС для Вас самый оптимальный вариант. И нет никаких проблем: можно использовать все прелести Linux, и спокойно работать в своей любимой Windows!
Посидел подумал и появилось пару вопросов:
1. Зачем ставить VMware если есть Hyper-V из коробки
2. Зачем ставить Xubuntu если у неё даже нет дистрибутива для сервера, у них даже на сайте написано что дистрибутив для рабочих станиций.
И я не понимаю зачем ставить рабочий сервер с интерфейсом. Если начинать привыкать к консоли, то лучший выбор это — веб сервер. На веб сервере все близко: git, composer, ssh, nginx, php — всё консольное, всё близко и часто используется.
1. Зачем ставить VMware если есть Hyper-V из коробки
2. Зачем ставить Xubuntu если у неё даже нет дистрибутива для сервера, у них даже на сайте написано что дистрибутив для рабочих станиций.
Xubuntu is perfect for those who want the most out of their desktops, laptops and netbooks with a modern look and enough features for efficient, daily usage. It works well on older hardware too.
И я не понимаю зачем ставить рабочий сервер с интерфейсом. Если начинать привыкать к консоли, то лучший выбор это — веб сервер. На веб сервере все близко: git, composer, ssh, nginx, php — всё консольное, всё близко и часто используется.
Мой опыт говорит, что Windows это не прихоть, а необходимость.
В некоторых компаниях, политика компании разрешает только Windows. Не разрешает виртуалки и вторую ось. А локального админа, чтоб хотя бы hosts править, приходится вымаливать через руководство.
И не подумайте, что компании плохие, просто админам так проще, когда у них несколько сотен компов, а разрабов, которым нужны никсы, всего десяток или два.
С той же проблемой сталкиваются дизайнеры на маках.
Решений проблемы много.
В одной из компаний мне не давали локального админа. Я плюнул и притащил свой ноутбук с ubuntu. Тоже решение.
Поменял заголовок на максимально близкий к содержанию статьи.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Настройка среды для веб разработки в Windows на основе виртуальной машины VMware Player