Потому что одинаковый набор ПО на разных ОС, частенько, имеет совершенно разные проблемы.
Когда долгое время в команде в подавляющем большинстве случаев используется Mac OS и различные GNU Linux дистрибутивы, то получается так, что с большинством проблем ты и твоя команда уже сталкивались, вы знаете как их решить. В самом худшем случае — помощь для Mac OS и GNU Linux в гугле находится довольно скоро. И, зачастую, для Mac OS даже не приходится какой-то отдельный подход выискивать.
А теперь в нашу команду приходит разработчик на Windows, у которого возникают какие-то свои совершенно волшебные проблемы, с которыми помочь не только мы, но и гугл особо не в силах, у него всё почему-то начинает тормозить, файлы в VM не синхронизируются, о нормальном запуске проекта с помощью Docker (к слову, у нас всё на заранее сбилденных образах, поэтому подниматься должно прекрасно) и говорить не приходится.
Особые умельцы не говорят о своих проблемах и поднимают проект как-то по своему, в итоге, во время разработки, их изменения не работают на стейджинге так, как хотелось бы, а ответ от разработчика банален — «У меня локально всё работает».
Во избежания подобного беспорядка, мы стараемся просто не работать с разработчиками, которые используют Windows. К сожалению, мы его не осилили. К счастью, разработчиков, использующих Windows не так много.
Всё вышесказанное относится к веб-разработке на Python + Django.
Но они мне все не понравились, по тем или иным причинам.
У меня возникают подобные ощущения от использования большинства уже готовых инструментов. Всегда кажется, что что-то не то, что-то не так, тут нелогично, там сложно. В итоге разрабатываешь своё решение. В последнее время очень стараюсь отказаться от подобного подхода.
Это так, просто размышления и крик души.
C Django Fluent Pages и Django Fluent Contents у самого сложились очень сложные взаимоотношения, и всё же я плачу, колюсь, но кушаю кактус. В итоге не пойму, то ли так всё хорошо, что я продолжаю использовать, то ли так всё плохо, что плачу.
Как-то сервер (по крайней мере в первой задаче) не совсем похож на реально встречающийся в работе.
* uname -a говорит, что это убунта.
* Apt'a нет, зато есть yum
* Vim или nano по-умолчанию не установлены (окей, установим в ubunt'e через yum (!))
* При обращении к сайту, который нужно поднять, в логах nginx, php-fpm пусто
* Хотите полностью уронить сайт? service nginx stop, открываем тестовый сайт, а там всё так же 502.
* Окей, установим lynx и обратимся к localhost и увидим наконец хоть какой-то результат в логах — «Primary script unknown», с этим уже можно работать, но не нужно. Потому что таких волшебных серверов, в вашей работе, я думаю, не встретится.
Когда долгое время в команде в подавляющем большинстве случаев используется Mac OS и различные GNU Linux дистрибутивы, то получается так, что с большинством проблем ты и твоя команда уже сталкивались, вы знаете как их решить. В самом худшем случае — помощь для Mac OS и GNU Linux в гугле находится довольно скоро. И, зачастую, для Mac OS даже не приходится какой-то отдельный подход выискивать.
А теперь в нашу команду приходит разработчик на Windows, у которого возникают какие-то свои совершенно волшебные проблемы, с которыми помочь не только мы, но и гугл особо не в силах, у него всё почему-то начинает тормозить, файлы в VM не синхронизируются, о нормальном запуске проекта с помощью Docker (к слову, у нас всё на заранее сбилденных образах, поэтому подниматься должно прекрасно) и говорить не приходится.
Особые умельцы не говорят о своих проблемах и поднимают проект как-то по своему, в итоге, во время разработки, их изменения не работают на стейджинге так, как хотелось бы, а ответ от разработчика банален — «У меня локально всё работает».
Во избежания подобного беспорядка, мы стараемся просто не работать с разработчиками, которые используют Windows. К сожалению, мы его не осилили. К счастью, разработчиков, использующих Windows не так много.
Всё вышесказанное относится к веб-разработке на Python + Django.
У меня возникают подобные ощущения от использования большинства уже готовых инструментов. Всегда кажется, что что-то не то, что-то не так, тут нелогично, там сложно. В итоге разрабатываешь своё решение. В последнее время очень стараюсь отказаться от подобного подхода.
Это так, просто размышления и крик души.
C Django Fluent Pages и Django Fluent Contents у самого сложились очень сложные взаимоотношения, и всё же я плачу, колюсь, но кушаю кактус. В итоге не пойму, то ли так всё хорошо, что я продолжаю использовать, то ли так всё плохо, что плачу.
* uname -a говорит, что это убунта.
* Apt'a нет, зато есть yum
* Vim или nano по-умолчанию не установлены (окей, установим в ubunt'e через yum (!))
* При обращении к сайту, который нужно поднять, в логах nginx, php-fpm пусто
* Хотите полностью уронить сайт? service nginx stop, открываем тестовый сайт, а там всё так же 502.
* Окей, установим lynx и обратимся к localhost и увидим наконец хоть какой-то результат в логах — «Primary script unknown», с этим уже можно работать, но не нужно. Потому что таких волшебных серверов, в вашей работе, я думаю, не встретится.