По-моему это чепуха. Знакомые, незнакомые, этикет. Интернет стирает многие границы, какой смысл их искусственным образом придерживаться? Можно подумать, что тут все в смокингах и пенсне перед мониторами сидят:)
Меня совершенно не парит как ко мне обращаются, если обращаются по-делу. Можно на «ты», можно на «вы», совершенно не критично, главное чтобы было что обсудить, но вот витиеватые любезности зачастую смешат:)
Раздражает совершенно дурацкая манера пользователей хабра обращаться друг к другу на «Вы» с большой буквы к месту и не к месту:) Особенно смешны комментарии вида "… а мы с Вами на Ты не переходили...":)
Видимо у нас с вами есть некая хитра дифференциация по части заказчиков:)
На моем веку встречалось два вида — первые имеют инфраструктуру и хотят в эту инфраструктуру решение. Причем, что важно, у них уже есть люди, которые готовы заниматься саппортом.
Второй тип это люди, которые хотят чтобы было сделано хорошо и в срок, остальное их, как правило не интересует. И самое главное, они хотят чтобы после того, как было сделано — жило спокойно и кушать не просило.
Закзачик, который говорит «Вот сделайте мне на X/Y/Z» а я уж дальше сам это нонсенс. Потому что «дальше сам» работает не всегда так, как хотелось бы обеим сторонам.
Насчет хостинга — я не понимаю, почему наличие большого количества хостинг-планов является плюсом. Для разработчика гораздо более удобно и выгодно в долгосрочной перспективе крутить приложения на своих серверах (ну это конечно же при условии непротивления и адекватности заказчика).
Это обман. Заказчик так, или иначе всегда будет зависеть от разработчика. От этого никуда не деться.
После того, как система разработана ее нужно поддерживать. Во всех смыслах. Управлять контентом, дорабатывать, исправлять ошибки и пр.
Подход «Реализовал — выкатил — получил деньги — до свиданья», подход совершенно бредовый и не выгодный ни одной из сторон (исключения конечно бывают, но тем не менее). Заказчику выгодно платить деньги и получать результат. В случае когда разработчик на колене пилит cms, отдает ее заказчику и на этом все заканчивается, заказчик находится в гораздо большем минусе, чем кажется на первый взгляд. Ему нужно думать про хостинг, про контент менеджера, про нового программиста, который за 10 копеек будет прикручивать какой-нибудь новый функционал. На все это уходит время, на все это уходят деньги, на все это уходят нервы (общаться с бестолковыми фрилансерами у которых день уходит на то чтобы цвет фона поменять!).
Гораздо приятнее когда приложение работает, и контент обновляется, и цвет можно изменить в предсказуемое время за предсказуемые деньги.
И разработчику не выгодно отпускать своего заказчика. Нужно предоставлять полный спектр услуг. Разработка приложения, поддержка в продакшене, менеджмент контента. Поддержка предполагает абонентскую плату, и для разработчика это плюс, т.к. мелкая копейка капает, а приложение есть не просит. А если допилить нужно, то опять же, условия оговариваются.
О каких хостингах вы говорите? Что за чепуха? VPS стоит не так уж дорого.
Какая-то дурная статья. Такое впечатление, что все хотят исключительно cms-ки, и автор пытается показать что в мире ruby с cms-ками все в порядке, и по этому ruby/rails могут составить конкуренцию php-стэку. Хочу Фейсбук — бери Диаспору, это как-то очень странно звучит:)
Вообще преимущество rails, на мой взгляд, в том, что это не cms-ориентированное решение. Рассуждать в данном случае нужно не с позиции заказчика, а с позиции разработчика. Заказчику должно быть по барабану на чем делать, главное чтобы быстро, качественно и недорого. Заказчика не должны парить фреймворки, хостинги, дальнейшая поддержка и прочее-прочее-прочее. Если разработчик ставит заказчика в такие рамки, то он просто дурак. Разработчик делает решение, выкатывает его на свои сервера, поддерживает и получает за это деньги. Слово «хостинг», должно остаться в прошлом.
Ну а если заказчика парят вопросы технологий и хостингов, то пусть заказывает себе решение на PHP, зачем его в чем-то переубеждать?
Кто ломать будет?) Предыдущий оратор же дал вполне ясную вводную — тише воды даниже травы, «обеспечение производственного процесса одной организации»:)
Софистика это все вобщем. Если само работает — то и пусть работает. А если требуется периодическое вмешательство, то надо делать по уму, чтобы минимизировать время, которое приходится затрачивать.
Фреймворки понятное дело предполагают, и PHP развивается. Но что предложат молодому разработчику, который приходит в среднюю PHP-команду? CMS-ки допиливать? Поддерживать решения которым 3+ лет?
Понятно дело, что и на ПХП делаются интересные проекты, но размер рынка вакансий и соискателей это же медаль, которая имеет две стороны.
Насчет переписывать с нуля что-то на рельсо-джанги, я же вроде такого никогда никому не советовал:) Пожелания заказчика и экономическая целесообразность прежде всего.
Вобщем, я спать пойду) Мое мнение такое — все что на пхп написано и успешно работает переписывать никуда не надо. PHP-гуру всякие рельсы нужны как собаке пятая нога. А вот тем, кто только выбирает я бы рекомендовал смотреть в сторону трендов. Ну и конечно все это имхо, основанное на личном опыте:)
Ну тогда я вообще ничего не понимаю. Если это просто сервер которой «стоит и есть не просит», туда все что угодно можно воткнуть и оно будет нормально работать. В чем плюс LAMP перед каким-нибудь MS SQL Express, или как он там называется? Или перед любым другим решением?
Или мы говорим не о том, что «с целью», а о том, что «вопреки»?
Дык есть же явные плюсы:) Мир на месте ведь не стоит, все новое ведь не с потолка берется:)
Хотя если хочется поддерживать старый код и работать в кубикле, имея над душой 10 проджект-менеджеров, лидов и кто там еще бывает в настоящих командах, то наверное не стоит:)
Насчет идти работать «не разработчиком» вполне вариант:) Много их, в последнее время, этих разработчиков стало, а толкового не найти:)
Ну вот пообслуживай, расскажешь:) Ты же в баду, я подозреваю не один работаешь, и материально ответственным за простой серверов лицом не являешься?
Что такое скрипты по 100 строк и что такое работа, заключающаяся, в проверке на ошибки мне не понять. Ну пишете вы свои велосипеды, для своих исторически сформировавшихся задач, что ж всем теперь так делать и на такую модель работы ориентироваться? Сделали хайлоад, молодцы, но каждый хайлоад уникален.
И когда нам надо что-то руками настраивать, куда-то складывать и еще дампить и таблички править это не просто и не быстро. Это геморрой, который в будущем с большой долей вероятности потребует оперативного вмешательства.
Не надо вобщем давать людям дурные советы.
Так все-таки все руками быстро-быстро, или нет, я не понял? «Такими очень простыми способами» это какими?
Оптимизировал деплой — написал скрипт который по ssh раскидывает архивы? Или пулит из гита затеганную версию? Так все же не руками? Ну и капистрано, паппет, шеф какой-нибудь это конечно не тру:)
По-поводу машин хорошо:) 150-200 веб-серверов:) 800-850 остальных, это стационарные машины разработчиков?))
Меня совершенно не парит как ко мне обращаются, если обращаются по-делу. Можно на «ты», можно на «вы», совершенно не критично, главное чтобы было что обсудить, но вот витиеватые любезности зачастую смешат:)
На моем веку встречалось два вида — первые имеют инфраструктуру и хотят в эту инфраструктуру решение. Причем, что важно, у них уже есть люди, которые готовы заниматься саппортом.
Второй тип это люди, которые хотят чтобы было сделано хорошо и в срок, остальное их, как правило не интересует. И самое главное, они хотят чтобы после того, как было сделано — жило спокойно и кушать не просило.
Закзачик, который говорит «Вот сделайте мне на X/Y/Z» а я уж дальше сам это нонсенс. Потому что «дальше сам» работает не всегда так, как хотелось бы обеим сторонам.
Насчет хостинга — я не понимаю, почему наличие большого количества хостинг-планов является плюсом. Для разработчика гораздо более удобно и выгодно в долгосрочной перспективе крутить приложения на своих серверах (ну это конечно же при условии непротивления и адекватности заказчика).
После того, как система разработана ее нужно поддерживать. Во всех смыслах. Управлять контентом, дорабатывать, исправлять ошибки и пр.
Подход «Реализовал — выкатил — получил деньги — до свиданья», подход совершенно бредовый и не выгодный ни одной из сторон (исключения конечно бывают, но тем не менее). Заказчику выгодно платить деньги и получать результат. В случае когда разработчик на колене пилит cms, отдает ее заказчику и на этом все заканчивается, заказчик находится в гораздо большем минусе, чем кажется на первый взгляд. Ему нужно думать про хостинг, про контент менеджера, про нового программиста, который за 10 копеек будет прикручивать какой-нибудь новый функционал. На все это уходит время, на все это уходят деньги, на все это уходят нервы (общаться с бестолковыми фрилансерами у которых день уходит на то чтобы цвет фона поменять!).
Гораздо приятнее когда приложение работает, и контент обновляется, и цвет можно изменить в предсказуемое время за предсказуемые деньги.
И разработчику не выгодно отпускать своего заказчика. Нужно предоставлять полный спектр услуг. Разработка приложения, поддержка в продакшене, менеджмент контента. Поддержка предполагает абонентскую плату, и для разработчика это плюс, т.к. мелкая копейка капает, а приложение есть не просит. А если допилить нужно, то опять же, условия оговариваются.
О каких хостингах вы говорите? Что за чепуха? VPS стоит не так уж дорого.
Вообще преимущество rails, на мой взгляд, в том, что это не cms-ориентированное решение. Рассуждать в данном случае нужно не с позиции заказчика, а с позиции разработчика. Заказчику должно быть по барабану на чем делать, главное чтобы быстро, качественно и недорого. Заказчика не должны парить фреймворки, хостинги, дальнейшая поддержка и прочее-прочее-прочее. Если разработчик ставит заказчика в такие рамки, то он просто дурак. Разработчик делает решение, выкатывает его на свои сервера, поддерживает и получает за это деньги. Слово «хостинг», должно остаться в прошлом.
Ну а если заказчика парят вопросы технологий и хостингов, то пусть заказывает себе решение на PHP, зачем его в чем-то переубеждать?
Софистика это все вобщем. Если само работает — то и пусть работает. А если требуется периодическое вмешательство, то надо делать по уму, чтобы минимизировать время, которое приходится затрачивать.
Чтобы после обновления что-нибудь отвалилось?) Оно же бывает, что обновишься, а потом сидишь и думаешь, какой черт потянул кнопки нажимать:)
Понятно дело, что и на ПХП делаются интересные проекты, но размер рынка вакансий и соискателей это же медаль, которая имеет две стороны.
Насчет переписывать с нуля что-то на рельсо-джанги, я же вроде такого никогда никому не советовал:) Пожелания заказчика и экономическая целесообразность прежде всего.
Вобщем, я спать пойду) Мое мнение такое — все что на пхп написано и успешно работает переписывать никуда не надо. PHP-гуру всякие рельсы нужны как собаке пятая нога. А вот тем, кто только выбирает я бы рекомендовал смотреть в сторону трендов. Ну и конечно все это имхо, основанное на личном опыте:)
Или мы говорим не о том, что «с целью», а о том, что «вопреки»?
Хотя если хочется поддерживать старый код и работать в кубикле, имея над душой 10 проджект-менеджеров, лидов и кто там еще бывает в настоящих командах, то наверное не стоит:)
Насчет идти работать «не разработчиком» вполне вариант:) Много их, в последнее время, этих разработчиков стало, а толкового не найти:)
Капистрано, на мой взгляд, однозначный маст хэв.
Что такое скрипты по 100 строк и что такое работа, заключающаяся, в проверке на ошибки мне не понять. Ну пишете вы свои велосипеды, для своих исторически сформировавшихся задач, что ж всем теперь так делать и на такую модель работы ориентироваться? Сделали хайлоад, молодцы, но каждый хайлоад уникален.
И когда нам надо что-то руками настраивать, куда-то складывать и еще дампить и таблички править это не просто и не быстро. Это геморрой, который в будущем с большой долей вероятности потребует оперативного вмешательства.
Не надо вобщем давать людям дурные советы.
Ну и все-таки, сам-то пробовал держать 2-3 продакшен сервера теми методами, которые народу выше советовал?)
Оптимизировал деплой — написал скрипт который по ssh раскидывает архивы? Или пулит из гита затеганную версию? Так все же не руками? Ну и капистрано, паппет, шеф какой-нибудь это конечно не тру:)
По-поводу машин хорошо:) 150-200 веб-серверов:) 800-850 остальных, это стационарные машины разработчиков?))