Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 171
Когда тебе задут вопрос о смене платформы и языка ты почувствуешь неприятное легкое покалываение. Это твоя гордость. Пошли ее ко всем чертям. От гордости одни проблемы. Толку от нее никакого. (с) Бульварное чтиво
А я наоборот не понимаю какая нафик гордость? Наоборот больше будешь гордиться, когда выучишь какой-то дополнительный язык. Я например себя в первую очередь программистом считаю, а во-вторую уже дотнетчиком.
Именно так. Осваивать новое лучше всего на реальных целях.
А тут ещё за это платит заказчик, то грех не попробовать.
А тут ещё за это платит заказчик, то грех не попробовать.
Я, скажем, осваиваю то, что считаю нужным, полезным, эффективным и перспективным. Иными словами, я принимаю решение совершенствоваться именно в этой среде, так как она явилась следствием моего осознанного выбора. Выбор же среды заказчиком осознан (предположим, что осознан) заказчиком, который, скорее всего, разбирается в вопросе хуже меня, и поэтому переменить среду под обстоятельства, это значит сойти с избранного мной пути, то есть ответ нет.
А во точно правильно прочитали комментарий выше? Как раз автор ответа и говорит «От гордости одни проблемы.»
По-моему, с точки зрения разработчика, PHP может быть ценен только тем, что с ним у разработчика может быть большой опыт работы.
А вот менять на PHP, а не с PHP на… как то… )
А вот менять на PHP, а не с PHP на… как то… )
Инфраструктура для PHP дешевле, масштабировать проще.
То что инфрастуктура дешевле, скорее всего правда.
А вот на счет масштабирования, то я в корне не согласен.
Вот если вы пишете под Azure то там масштабирование на лицо.
А вот на счет масштабирования, то я в корне не согласен.
Вот если вы пишете под Azure то там масштабирование на лицо.
Какое из масштабирований? Можно подробнее?
Горизонтальное.
А о каком ещё тут можно говорить, может я не о том подумал? оО
А о каком ещё тут можно говорить, может я не о том подумал? оО
Вообще стоит, наверное, учитывать, что масштабировать пласт логики (а это .NET vs PHP в данном примере) не так уж и сложно — ну поставил hadoop в качестве распредилителя нагрузки, ну настроил его один раз. Проблемы нет. Облако (Azure) лишь это и дает в данном случае.
Если и есть проблема перехода с А на Б, то это проблема с масштабированием хранилища и очередей запросов к нему. Но это вряд ли проблема платформы, как правило хранилище — это не часть платформы, а отдельная сущность.
То есть, резюмируя: вопрос масштабирования системы в большей части связан с хранением данных, нежели с платформой для их обработки.
Если и есть проблема перехода с А на Б, то это проблема с масштабированием хранилища и очередей запросов к нему. Но это вряд ли проблема платформы, как правило хранилище — это не часть платформы, а отдельная сущность.
То есть, резюмируя: вопрос масштабирования системы в большей части связан с хранением данных, нежели с платформой для их обработки.
Вообще стоит, наверное, учитывать, что масштабировать пласт логики (а это .NET vs PHP в данном примере) не так уж и сложно — ну поставил hadoop в качестве распредилителя нагрузки, ну настроил его один раз. Проблемы нет.
WAT? Hadoop, как балансир? Как Вы собираетесь распределять нагрузку MapRed'ом? Или у Вас о-о-очень терпеливые клиенты.
Azure дает требование к написанию приложения, что бы оно могло горизонтально маштабироваться.
А 99% продуктов на PHP не имеют такой возможности, потому что не написаны с учётом этого требования.
И «проще масштабировать» тут никакого не будет. Скорее всего придется переписать львиную долю кода, если не всё приложение.
А 99% продуктов на PHP не имеют такой возможности, потому что не написаны с учётом этого требования.
И «проще масштабировать» тут никакого не будет. Скорее всего придется переписать львиную долю кода, если не всё приложение.
Так стало яснее, но все еще не ясно, на каком уровне мы будем горизонтально масштабироваться. Логично предположить, что масштабирование лучше всего производить не доходя даже до приложения, распределяя нагрузку между серверами на уровне выше. Само приложение может масштабироваться «форкая» или «тредя» свои отдельные компоненты или процессы.
И теперь возникает вопрос, что именно умеет делать код, написанный под Azure, чего нельзя повторить на других языках или на уровень выше, в неком метадиспетчере?
И теперь возникает вопрос, что именно умеет делать код, написанный под Azure, чего нельзя повторить на других языках или на уровень выше, в неком метадиспетчере?
Господа минусящие, если вы не согласны, то не стесняйтесь, высказывайте свое мнение, где я не прав, или почему я не прав. Мне интересна эта тема, готов конструктивно обсуждать.
Не знаю почти ничего про Azure, но знаю, что PHP «из коробки» слабо приспособлен к масштабированию по серверам, по крайней мере алгоритмами типа round-robin на балансировщике. Большинство веб-приложений на PHP активно используют механизм сессий, а по умолчанию они хранятся в файлах в локальной ФС сервера. В принципе проблема решаемая, но на это тоже нужно тратить время и проверять разные варианты под боевой или аналогичной ей нагрузке. В Azzure, вероятно, это проблема решена изначально.
Обычно всегда соглашаюсь сменить платформу.
Но тут нюанс, при переходе с Perl, Ruby или Python на PHP выигрыша нет.
Обычно проще доказать, что более эффективен обратный переход.
Но тут нюанс, при переходе с Perl, Ruby или Python на PHP выигрыша нет.
Обычно проще доказать, что более эффективен обратный переход.
Окей, я согласился перейти на Perl, Ruby или Python.
Мне нужны следующие аналоги PHP
* SimpleXML
* Шаблонизатор хотя бы уровня Smarty2, которы может расширяться разработчиком, имеет блоки, фукции, модификаторы
Это всего лишь две технологии, которые «держат» меня на PHP
ООП вырожденный до наследования от одного абстрактного класса.
Обвязка в виде роутеров, MVC, и прочего не интересует.
Что посоветуете?
Мне нужны следующие аналоги PHP
* SimpleXML
* Шаблонизатор хотя бы уровня Smarty2, которы может расширяться разработчиком, имеет блоки, фукции, модификаторы
Это всего лишь две технологии, которые «держат» меня на PHP
ООП вырожденный до наследования от одного абстрактного класса.
Обвязка в виде роутеров, MVC, и прочего не интересует.
Что посоветуете?
Написать свои? :)
Это ведь не так сложно как кажется. Особенно когда есть прототип в виде этих самых библиотек в другой платформе.
Конечно не весь функционал, но только то что реально нужно — пишется быстро.
Это ведь не так сложно как кажется. Особенно когда есть прототип в виде этих самых библиотек в другой платформе.
Конечно не весь функционал, но только то что реально нужно — пишется быстро.
Подход «написать с нуля» мне импонирует, но это чревато бесполезной тратой времени. Бизнес требует скорости разработки, стабильности работы, дешевизне, и переписывание технологий с нуля не сильно хорошо укладываются в первые два пункта.
Так не с нуля ведь. Есть готовый прототип который Вам нравится. Это значительно упрощает процесс.
Я в свое время пересел на велосипеды, явно не рассчитал необходимые ресурсы. Примерно половину решений пришлось изменить в пользу тех которые были у «конкурентов». Но зато я знаю почему они сделали именно так :)
А если быть умнее чем я и делать сразу как в оригинале, без выпендрежа, то все выходит намного быстрее.
Хотя может быть я и необъективен. У меня простенький заказ уже два года висит по причине того, что клиент всё время меняет ТЗ. Это какое-то экстремистское экстремальное программирование выходит. Так что у меня уже такое чувство, что самое страшное в программировании это ТЗ, а все остальное «за ночь напишем» :)
Я в свое время пересел на велосипеды, явно не рассчитал необходимые ресурсы. Примерно половину решений пришлось изменить в пользу тех которые были у «конкурентов». Но зато я знаю почему они сделали именно так :)
А если быть умнее чем я и делать сразу как в оригинале, без выпендрежа, то все выходит намного быстрее.
Хотя может быть я и необъективен. У меня простенький заказ уже два года висит по причине того, что клиент всё время меняет ТЗ. Это какое-то экстремистское экстремальное программирование выходит. Так что у меня уже такое чувство, что самое страшное в программировании это ТЗ, а все остальное «за ночь напишем» :)
Как-то слабо вас PHP держит.
Python:
— lxml
— Jinja2. В symfony2 используется его порт, названный Twig. Отличный шаблонизатор.
Ruby:
— LibXML
— erb и куча альтернатив.
Замечательные языки, между прочим. Как и PHP, у которого есть только одна существенная проблема — он в мейнстриме, а значит, есть куча говнарей, пишущих на нём мозговыносящие опусы, иногда, что страшнее всего, коммерчески успешные. И что бы там ни говорили паладины святых войн, ненавидят они PHP именно из-за говнарей, чей код им довелось поддерживать, а не из-за отсутствия генераторов (до 5.5) или плохих лямбд etc.
Рядовому php-девелоперу приходится иметь дело с таким говнищем как Bitrix, wordpress, ShopCMS и прочими нейромедиаторами, но пока есть Symfony2 и другие качественные продукты, а также адекватные разработчики, PHP имеет право на существование.
Одним языком ограничиваться не стоит, в любом случае. Да и десятью тоже.
Python:
— lxml
— Jinja2. В symfony2 используется его порт, названный Twig. Отличный шаблонизатор.
Ruby:
— LibXML
— erb и куча альтернатив.
Замечательные языки, между прочим. Как и PHP, у которого есть только одна существенная проблема — он в мейнстриме, а значит, есть куча говнарей, пишущих на нём мозговыносящие опусы, иногда, что страшнее всего, коммерчески успешные. И что бы там ни говорили паладины святых войн, ненавидят они PHP именно из-за говнарей, чей код им довелось поддерживать, а не из-за отсутствия генераторов (до 5.5) или плохих лямбд etc.
Рядовому php-девелоперу приходится иметь дело с таким говнищем как Bitrix, wordpress, ShopCMS и прочими нейромедиаторами, но пока есть Symfony2 и другие качественные продукты, а также адекватные разработчики, PHP имеет право на существование.
Одним языком ограничиваться не стоит, в любом случае. Да и десятью тоже.
lxml не замена SimpleXML. Писать в три раза больше, особенно xpath не порадовал, постоянно контекст рутового объекта используется.
Jinja понравился, вроде все есть, что нужно.
Остальное посмотрю позже.
Jinja понравился, вроде все есть, что нужно.
Остальное посмотрю позже.
В Beautiful Soup нет xpath(), но упомянутый lxml вполне справляется с его обязанностями.
Писать в три раза больше, особенно xpath не порадовал, постоянно контекст рутового объекта используется.Есть подмодуль lxml.etree, где элементы могут вызывать xpath() в собственном контексте.
Писать в три раза больше — у меня совсем скромный опыт разработки на питоне, но всегда получалось наоборот. У подмодулей lxml.* неплохой набор классов и их методов — думаю, с их помощью вполне возможно писать лаконичный код.
Писать в три раза больше — у меня совсем скромный опыт разработки на питоне, но всегда получалось наоборот.
Речь шла про код работы с SimpleXML и lxml.
$sxe = simplexml_load_string('<body><elements><element/></elements></body>');
$res = $sxe->elements->xpath('element');
echo( $res[0]->getName() );
Можете аналог на Python привести? Я не силен просто в нем, могу серьезно заблуждаться…
root = etree.fromstring('<body><elements><element/></elements></body>')
res = root.find('elements').findall('element')
print res[0].tag
Как-то так.
root.find('elements').findall('element')Теперь представьте, что вы находитесь где-то в середине DOM, дерева, и вам нужно с этого места найти ноды по xpath. Как вы это сделаете? А если «это место» — итерируемая нода?
Тут мне идею закинули, что лучше всего написать отдельно интерфейс к etree, чтобы получить наибольшее совпадение с SimpleXML
Представил, .xpath() у этой ноды вызову. А что с итерируемой нодой?
Писать интерфейс: если вам нравится Python и SimpleXML, то идея не так уж плоха. А если просто SimpleXML, то разумно пользоваться им на PHP. Инструменты нужно выбирать исходя из требований задачи, а освоив новый язык — вы пополните набор этих инструментов и познакомитесь с новыми техниками, которые помогут найти элегантные решения при разработке на ранее известном языке.
В PHP 5.5 появятся генераторы — благодаря Python, я уже представляю, зачем они нужны и зачем не нужны.
Писать интерфейс: если вам нравится Python и SimpleXML, то идея не так уж плоха. А если просто SimpleXML, то разумно пользоваться им на PHP. Инструменты нужно выбирать исходя из требований задачи, а освоив новый язык — вы пополните набор этих инструментов и познакомитесь с новыми техниками, которые помогут найти элегантные решения при разработке на ранее известном языке.
В PHP 5.5 появятся генераторы — благодаря Python, я уже представляю, зачем они нужны и зачем не нужны.
Smarty2 простенький шаблонизатор? o_O
На примеры посмотрю, спасибо за информацию!
На примеры посмотрю, спасибо за информацию!
Наследования нет, песочиницы нет.
Наследование темплейтов считаю злом, песочницы реализуются инстансами самого шаблонизатора, если я правильно мысль понял.
Это все признаки «простого» шаблонизатора? :)
Это все признаки «простого» шаблонизатора? :)
А я считаю величайшим благом в истории шаблонизаторов :)
Не видел ни одного простого шаблонизатора с наследованием. С песочницей (невозможностью взаимодействовать с приложением как-то кроме явных контрактов, в частности с невозможностью вызывать произвольные функции и методы стандартной либы и приложения, только белый список, заданный разработчиком приложения) видел, а вот с наследованием — нет.
Хотя, может у нас разные понятия «простого шаблонизатора».
Не видел ни одного простого шаблонизатора с наследованием. С песочницей (невозможностью взаимодействовать с приложением как-то кроме явных контрактов, в частности с невозможностью вызывать произвольные функции и методы стандартной либы и приложения, только белый список, заданный разработчиком приложения) видел, а вот с наследованием — нет.
Хотя, может у нас разные понятия «простого шаблонизатора».
Готов конструктивно пообсуждать наследование в шаблонизаторах.
Песочницы не считаю полезным не потому что они бесполезны как класс, а потому что это накладывает существенные ограничения на возможности кодера, который с шаблонами работает. Для меня это похоже на то, что сначала вы отрезаете себе руку, а потом пытаетесь пристроить какой-то девайс для того, чтобы поковыряться в носу. На любое расширение функциональности шаблона нужно обязательно регистрировать методы где-то еще. Для меня это выглядит как экономически бесполезное действие.
А вот наследования — это для меня из разряда усложнителей жизни. Эта технология приводит к усложнению как самого кода, так и ловли ошибок в нем, что в свою очередь снова же экономически неэффективно. А еще нужно заботиться о зонах видимости переменных, глубине перекрытий, названий блоков. Объектно-ориентированный подход к построению темплейтов может сыграть весьма злую шутку в самый неподходящий момент. Это как и OOCSS, прикольно пока не попадутся первые грабли.
Песочницы не считаю полезным не потому что они бесполезны как класс, а потому что это накладывает существенные ограничения на возможности кодера, который с шаблонами работает. Для меня это похоже на то, что сначала вы отрезаете себе руку, а потом пытаетесь пристроить какой-то девайс для того, чтобы поковыряться в носу. На любое расширение функциональности шаблона нужно обязательно регистрировать методы где-то еще. Для меня это выглядит как экономически бесполезное действие.
А вот наследования — это для меня из разряда усложнителей жизни. Эта технология приводит к усложнению как самого кода, так и ловли ошибок в нем, что в свою очередь снова же экономически неэффективно. А еще нужно заботиться о зонах видимости переменных, глубине перекрытий, названий блоков. Объектно-ориентированный подход к построению темплейтов может сыграть весьма злую шутку в самый неподходящий момент. Это как и OOCSS, прикольно пока не попадутся первые грабли.
Хинт: шаблонизатор, позволяющий запускать все встроенные функции php из шаблона, плюс многопользовательское публичное приложение, позволяющие загружать пользовательские шаблоны (темы), изменять глобальные переменные и т. п. Всё ещё считаете песочницу бесполезными как класс?
Вот есть главный шаблон от верстальщика, есть шаблоны разделов (условно контроллеров), основанных на нем и есть шаблоны каждой страницы (условно методов контроллеров). Как это будет выглядеть без наследования? Шаблон каждой страницы из пары include в начале и пары в конце в самом простом случае? Или я чего-то не знаю о Smarty2?
Вот есть главный шаблон от верстальщика, есть шаблоны разделов (условно контроллеров), основанных на нем и есть шаблоны каждой страницы (условно методов контроллеров). Как это будет выглядеть без наследования? Шаблон каждой страницы из пары include в начале и пары в конце в самом простом случае? Или я чего-то не знаю о Smarty2?
Задача с загружаемыми шаблонами решается путем выбора шаблонизатора, отличного от используемого в основном приложении, который не допускает вообще выполнения или компиляции в освновном языке программирования. Например XSLT. Чисто как пример, не считая разумности такого выбора. Да, это будет аналог песочницы, если уж так рассудить, но не будет сковывать возможностей пользователя или разработчика, потому что будет отличным от основного шаблонизатора системы. Другими словами, вместо одного шаблонизатора я лучше выберу два, при этом один должен принципиально отличаться.
Постройте одностраничное приложение, где кусочки догружаются в виде HTML, и вам не нужно будет делать наследование. Каждый контроллер будет «плеваться» своим личным куском кода, которому все равно, где он будет вставлен, или кто его вызывал. :)
С другой стороны, «наследование» в Smarty2 можно сделать без инклудов, просто переопределяя переменные, которые будут содержать нужные куски кода. А можно формировать промежуточный код с инструкциями и данными для унифицированного рендерера. Т.е. каждый контроллер не лично темплейтирует данные, а возвращает некие инструкции, которые потом обрабатываются в основном «компиляторе» страницы. В таком случае, если что-то неправильно работает, то нужно идти только в одно место, чтобы узнать, кто накосячил — в «компилятор». С наследуемыми шаблонами придется пересматривать всю цепочку наследования, что отнимает время, так как код может быть размазан тонким слоем по всей системе. Значит любые изменения нужно тщательно тестировать.
Я возмущаюсь не простив наследования, а против увеличения шанса допустить ошибку и размножению этих самых мест потенциальной ошибки. Мое кредо — как можно дешевле вносить изменения.
Постройте одностраничное приложение, где кусочки догружаются в виде HTML, и вам не нужно будет делать наследование. Каждый контроллер будет «плеваться» своим личным куском кода, которому все равно, где он будет вставлен, или кто его вызывал. :)
С другой стороны, «наследование» в Smarty2 можно сделать без инклудов, просто переопределяя переменные, которые будут содержать нужные куски кода. А можно формировать промежуточный код с инструкциями и данными для унифицированного рендерера. Т.е. каждый контроллер не лично темплейтирует данные, а возвращает некие инструкции, которые потом обрабатываются в основном «компиляторе» страницы. В таком случае, если что-то неправильно работает, то нужно идти только в одно место, чтобы узнать, кто накосячил — в «компилятор». С наследуемыми шаблонами придется пересматривать всю цепочку наследования, что отнимает время, так как код может быть размазан тонким слоем по всей системе. Значит любые изменения нужно тщательно тестировать.
Я возмущаюсь не простив наследования, а против увеличения шанса допустить ошибку и размножению этих самых мест потенциальной ошибки. Мое кредо — как можно дешевле вносить изменения.
Соглашусь с тем, что пользовательские шаблоны лучше формировать через другой шаблонизатор.
Типичный пример, — Liquid.
Но основная суть в том, что PHP лишь адаптирует идеи с других сред разработки, и благодаря синтаксису и библиотекам, не лучшим образом.
У него только один плюс, — простота и дешевизна развертывания. Если проектов несколько, плюса уже нет.
P.S.: И да, поддерживать проекты на PHP может быть дешевле. А может и не быть. Каркасов уровня Rails нет, есть только близкие к нему.
Типичный пример, — Liquid.
Но основная суть в том, что PHP лишь адаптирует идеи с других сред разработки, и благодаря синтаксису и библиотекам, не лучшим образом.
У него только один плюс, — простота и дешевизна развертывания. Если проектов несколько, плюса уже нет.
P.S.: И да, поддерживать проекты на PHP может быть дешевле. А может и не быть. Каркасов уровня Rails нет, есть только близкие к нему.
Я не хочу спорить на тему, почему PHP или Ruby или Python хорош или плох. Однако могу сказать одно, достаточно несколько уйти от классического ООП в сторону конфигурационно-сценарийного подхода, и тут разница в языках становится несколько несущественной. Мир программирования не сошелся клином только на одной методике разработки, есть куча примеров того, как различные подходы к организации кода спокойно себе живут, цветут и пахнут.
Но ведь придется и пользовательские шаблоны поддерживать, и свои — затраты на поддержку возрастут, в саппорте нужны будут люди знающие два шаблонизатора, а не один, а такие люди денег обычно больше просят или нужно тратиться на их обучение, и бояться как бы конкуренты не сманили более высокими зарплатами. Опять же режим песочницы можно локально включать и отключать динамически в нормальных «родных» шаблонизаторах, а не только на этапе конфигурации приложения и глобально.
Имхо, если уж строить одностраничные приложения, то шаблонизация должна быть на стороне клиента полностью. Сервер в ответ на запрос клиента (браузера в данном контексте) передает только данные: AJAX(ML), AJAJ(SON), AJAY(AML) или что — не суть. Ну, кроме статической (в понятиях веб 1.0 :) первой страницы и собственно шаблонов на языке какого-то JS-шаблонизатора. Но опять же не уверен, что это экономически выгодно в проектах малого и среднего масштаба, где разделение труда на сервер- и клиент-сайд разработчиков недостижимый идеал. Даже по себе сужу — сейчас я на JS могу плагины JQuery прикрутить, простую валидацию без них сделать, даже кроссбраузерный (в разумных пределах) AJAX-запрос написать могу (с помощью Гугла), но за более-менее серьезное одностраничное приложение с конкретным дедлайном не возьмусь за фиксированную цену, если она мой привычный рейт, умноженный на пессимистичный прогноз сколько времени мне займет обучиться писать полномасштабные приложения на JS, не превышает в разы. То есть мое обучение и все риски моей тупости за счет заказчика. А когда обучусь, то я буду просить уже не 300 рублей в час, а 500 минимум, а то и 1000.
Можно сделать многое. Но про экономический смысл не я первый заикнулся :) И почему только в компилятор нужно идти? А если контроллер что-то не то выдал ему? И с «размазан по всей системе» не согласен. По иерархии шаблонов — да, размазан, но обычно не столь катастрофично, чтобы зная приложение быстро не локализовать ошибку. Но вот ваше предложение, чтобы контроллер передавал какой-то код, который будет ещё-кто транслировать в HTML, мне кажется ещй больше размазанным и экономически невыгодным. Если, конечно, этот код не XML 9формируемый без шаблонизаторов), а транслятор не XSLT-процессор и стоимость верстальщиков, знающих XSLT устраивает :)
Имхо, если уж строить одностраничные приложения, то шаблонизация должна быть на стороне клиента полностью. Сервер в ответ на запрос клиента (браузера в данном контексте) передает только данные: AJAX(ML), AJAJ(SON), AJAY(AML) или что — не суть. Ну, кроме статической (в понятиях веб 1.0 :) первой страницы и собственно шаблонов на языке какого-то JS-шаблонизатора. Но опять же не уверен, что это экономически выгодно в проектах малого и среднего масштаба, где разделение труда на сервер- и клиент-сайд разработчиков недостижимый идеал. Даже по себе сужу — сейчас я на JS могу плагины JQuery прикрутить, простую валидацию без них сделать, даже кроссбраузерный (в разумных пределах) AJAX-запрос написать могу (с помощью Гугла), но за более-менее серьезное одностраничное приложение с конкретным дедлайном не возьмусь за фиксированную цену, если она мой привычный рейт, умноженный на пессимистичный прогноз сколько времени мне займет обучиться писать полномасштабные приложения на JS, не превышает в разы. То есть мое обучение и все риски моей тупости за счет заказчика. А когда обучусь, то я буду просить уже не 300 рублей в час, а 500 минимум, а то и 1000.
Можно сделать многое. Но про экономический смысл не я первый заикнулся :) И почему только в компилятор нужно идти? А если контроллер что-то не то выдал ему? И с «размазан по всей системе» не согласен. По иерархии шаблонов — да, размазан, но обычно не столь катастрофично, чтобы зная приложение быстро не локализовать ошибку. Но вот ваше предложение, чтобы контроллер передавал какой-то код, который будет ещё-кто транслировать в HTML, мне кажется ещй больше размазанным и экономически невыгодным. Если, конечно, этот код не XML 9формируемый без шаблонизаторов), а транслятор не XSLT-процессор и стоимость верстальщиков, знающих XSLT устраивает :)
Выбирая технологии по типу XSLT, которые имею стабильную и законченную функциональность, которая отлажена уже с годами, затраты на поддержку стремятся к нулю. Затраты на поддержку не возрастут, потому что для этого есть функциональное разделение ролей среди программистов и саппортеров. Другими словами, не обязательно всем знать обо всех технологиях, которые используются в проекте.
Разработчики twitter'а с вами не согласны. Если и есть что-то дорогое и неэффективное, так это шаблонизация на стороне клиента. Основная проблема в том, что вы не можете предугадать железо, на котором ваше приложение будет работать. С сервером проще, мы можете легко мониторить нагрузку и подстраиваться под конфигурацию. Поэтому, после жалоб на новый интерфейс твиттера, что он во-первых долго загружается (1MB скриптов не хухры-мухры), а потом еще и тормозит нещадно через время, они решили вернуть генерацию контента на сторону сервера.
Одностраничное приложение требует гораздо большего изменения мышления и подходов, чем многостраничное. И многие привычные паттерны там просто не работают.
Экономическая выгода бывает двух типов — дешево писать и дешево поддерживать. Идея с компилятором — это как раз намеренное усложнение разработки, чтобы потом было легко поддерживать. Вы банально сокращаете количество мест, куда нужно заглянуть еще, чтобы понять, на каком уровне произошла ошибка. Я недавно имел глупость сделать var_dump одной структуры в Symfony 1.4. Мой браузер сказал «ёк». :) Отсутствие дебага делает исправление ошибок испытанием на нервную уравновешенность :)
Имхо, если уж строить одностраничные приложения, то шаблонизация должна быть на стороне клиента полностью.
Разработчики twitter'а с вами не согласны. Если и есть что-то дорогое и неэффективное, так это шаблонизация на стороне клиента. Основная проблема в том, что вы не можете предугадать железо, на котором ваше приложение будет работать. С сервером проще, мы можете легко мониторить нагрузку и подстраиваться под конфигурацию. Поэтому, после жалоб на новый интерфейс твиттера, что он во-первых долго загружается (1MB скриптов не хухры-мухры), а потом еще и тормозит нещадно через время, они решили вернуть генерацию контента на сторону сервера.
Одностраничное приложение требует гораздо большего изменения мышления и подходов, чем многостраничное. И многие привычные паттерны там просто не работают.
Экономическая выгода бывает двух типов — дешево писать и дешево поддерживать. Идея с компилятором — это как раз намеренное усложнение разработки, чтобы потом было легко поддерживать. Вы банально сокращаете количество мест, куда нужно заглянуть еще, чтобы понять, на каком уровне произошла ошибка. Я недавно имел глупость сделать var_dump одной структуры в Symfony 1.4. Мой браузер сказал «ёк». :) Отсутствие дебага делает исправление ошибок испытанием на нервную уравновешенность :)
С поддержкой перегнул, да. В саппорте человек, знающий внутренний шаблонизатор не нужен. Но я не про поддержку технологии со стороны разработчиков (хотя и там он нужна и разработчик знающий и Smarty, и XSLT по идее должен стоить дороже, чем знающий только Twig :), а про поддержку пользователей. А в случае PHP как-то в голову других технологий по типу XSLT в голову не приходит, кроме самого XSLT. И что-то мне подсказывает, что саппортер, знающий XSLT будет обходится дороже, чем знающий Twig, а проблем у пользователей будет больше с XSLT, а значит саппортеров понадобится больше.
Возможно, разработчики twitter правы :) Но даже они сделали такую попытку, а значит недостатки клиентской шаблонизации не очевидны. Хотя, возможно, у меня подсознание их понимает и потому протестует против одностраничных приложений. А отдавать фрагменты HTML как-то совсем не хочется. Как раз потому что это размазывает место возможной ошибки. Появляется, как минимум, такая точка отказа как неправильное внедрение фрагмента в страницу, его несогласованность со страницей, за которую непонятно кто отвечает — фронтендер или серверсайдер. По-моему, это типичная костыльная оптимизация, когда ради скорости плюем на «правильность» архитектуры, а значит и простоту поддержки. Прибегать к ней стоит, по-моему, только если все другие варианты себя исчерпали.
Возможно, разработчики twitter правы :) Но даже они сделали такую попытку, а значит недостатки клиентской шаблонизации не очевидны. Хотя, возможно, у меня подсознание их понимает и потому протестует против одностраничных приложений. А отдавать фрагменты HTML как-то совсем не хочется. Как раз потому что это размазывает место возможной ошибки. Появляется, как минимум, такая точка отказа как неправильное внедрение фрагмента в страницу, его несогласованность со страницей, за которую непонятно кто отвечает — фронтендер или серверсайдер. По-моему, это типичная костыльная оптимизация, когда ради скорости плюем на «правильность» архитектуры, а значит и простоту поддержки. Прибегать к ней стоит, по-моему, только если все другие варианты себя исчерпали.
На самом деле никто не мешает сделать шаблонизатор, который для конечного потребителя будет выглядеть похожим на обычный, внутри иметь XSLT или еще что-нибудь.
Например вот так:
Это будет 100% гарантированная «песочница», тупо реализовываться, иметь простой синтаксис.
Разработчики twitter попали в одну маленькую ловушку: эйфория от демо-сцен, где количество элементов было «детским». Плюс подходы а-ля jQuery, сначала выбрать ноды для работы, потом с ними что-то делать, не подходят. С ростом количества элементов тормоза растут непропорционально. Плюс нужно постоянно держать «живые» обработчики актуальными, что, в свою очередь, тоже жрет ресурсы.
Насчет кусочков HTML, нет там никаких проблем с размазыванием ошибки. Наоборот, все очень сильно локализируется. И нет проблем с внедрением кода на страницу, вставили и все. Код тупой что двери.
Также опасения по поводу ответственности напрасны, вернее проблема одинакова для любого проекта.
Зато красота архитектуры в таком проекте — загляденье просто. Все настолько тупо и просто делается, что потом удивляешься, как можно работать как-то по-другому…
Я пять лет такие проекты делаю :)
Например вот так:
<ul>
<forearch from="/users/user" item="user">
<li><user:first_name /> <user:last_name /></li>
</foreach>
</ul>
Это будет 100% гарантированная «песочница», тупо реализовываться, иметь простой синтаксис.
Разработчики twitter попали в одну маленькую ловушку: эйфория от демо-сцен, где количество элементов было «детским». Плюс подходы а-ля jQuery, сначала выбрать ноды для работы, потом с ними что-то делать, не подходят. С ростом количества элементов тормоза растут непропорционально. Плюс нужно постоянно держать «живые» обработчики актуальными, что, в свою очередь, тоже жрет ресурсы.
Насчет кусочков HTML, нет там никаких проблем с размазыванием ошибки. Наоборот, все очень сильно локализируется. И нет проблем с внедрением кода на страницу, вставили и все. Код тупой что двери.
Также опасения по поводу ответственности напрасны, вернее проблема одинакова для любого проекта.
Зато красота архитектуры в таком проекте — загляденье просто. Все настолько тупо и просто делается, что потом удивляешься, как можно работать как-то по-другому…
Я пять лет такие проекты делаю :)
Я лет пять, а то и семь назад попробовал сделать и ужаснулся получившейся архитектуре даже на серевр-сайде Код в контроллере (хотя таких слов не знал ещё) типа
приводит меня в ужас.
$output = '<table class="super">';
foreach ($table as $row) {
$ouput .= '<tr>';
foreach ($row as $cell) {
$ouput .= '<td>' . $cell . '</td>';
}
$ouput .= '</tr>';
}
$ouput .= '</table>';
приводит меня в ужас.
Ммм… у меня есть ощущение, что мы говорим про разные вещи…
Можно подробнее, почему был выбран такой стиль темплейтирования данных? Чем это было обусловлено?
Можно подробнее, почему был выбран такой стиль темплейтирования данных? Чем это было обусловлено?
У меня тоже с какого-то момента :(
Раз мы не отдаем полную HTML-страницу, то использование нормального шаблонизатора будет ненужным оверхидом. Были ещё варианты оформить вывод через использование php как шаблонизатора, то есть через
Раз мы не отдаем полную HTML-страницу, то использование нормального шаблонизатора будет ненужным оверхидом. Были ещё варианты оформить вывод через использование php как шаблонизатора, то есть через
<?=... ?>, альтернативный синтаксис и т. п. в теле контроллера, или через оперирование DOM с последующим экспортом в HTML, но замеры показали, что это самый быстрый способ. Использование шаблонизатора нужно для создания уровня абстракции, которая понятна двум типам работников: бэкэнд-программистам и кодерам. Это своеобразная точка обмена.
Хоть мы не отдаем страницу полностью, ее части тоже требуют удобства темплейтирования. Если раньше вы собирали страницу в одном месте и одним махом, то с одностраничным интерфейсом вы делаете то же самое, только контроллер не делает ничего лишнего, кроме как собирает требуемый кусочек информации.
Тот же Хабр можно собрать из следующих кусков
* index
* информация о пользователе
* меню
* основной контент
* комментарии
* рекламный блок
* Лучшее за 24 часа
* События
*…
Загружается index, в него в 6 потоков подгружаются блоки. Контроллер, отвечающий за лучшее, будет выдавать только темплейт со списком лучшего. Это супер, потому что он может обновляться совершенно асинхронно, не нагружать лишний раз сервер, быть простым в исполнении
Хоть мы не отдаем страницу полностью, ее части тоже требуют удобства темплейтирования. Если раньше вы собирали страницу в одном месте и одним махом, то с одностраничным интерфейсом вы делаете то же самое, только контроллер не делает ничего лишнего, кроме как собирает требуемый кусочек информации.
Тот же Хабр можно собрать из следующих кусков
* index
* информация о пользователе
* меню
* основной контент
* комментарии
* рекламный блок
* Лучшее за 24 часа
* События
*…
Загружается index, в него в 6 потоков подгружаются блоки. Контроллер, отвечающий за лучшее, будет выдавать только темплейт со списком лучшего. Это супер, потому что он может обновляться совершенно асинхронно, не нагружать лишний раз сервер, быть простым в исполнении
Но это же и шестикратная нагрузка на соединение браузера с сервером, соединение апп-сервера с БД или кэшем, и прочие per-request задачи. И, вроде, браузеры не позволяют иметь больше двух потоков по умолчанию к одному домену, а значит ещё и чисто линейная задержка возникнет, нет? Или каждому «файлу» свой домен?
Я то же самое делаю через include/render, по web-socket получаю от сервера сообщение об изменении страницы и обновляю страницу. Это позволяет держать мне клиент-сайд часть минимально простой (единственная реакция — рефреш — на серверное событие, минимум клиентских событий, требующих специальных обработчиков — остальное простые ссылки). Как мне кажется, обработка каждого клика на клиент-сайде возьмет ресурсов на клиенте не сильно меньше чем ещё и шаблонизация. Я ошибаюсь в порядках оценки ресурсов обработчиков с манипуляцией DOM и шаблонизацией, или в количество переходит в качество и где нагрузка N допустима, там 2N недопустима?
P.S. А вообще мы как-то ушли от обсуждения песочницы к одностраничным приложениям. Если использовать шаблонизатор для генерации ответов от контроллера, то шаблоны смогут получать доступ ко всему приложению и среде выполнения, хоть полный хтмл, хоть частичный.
Я то же самое делаю через include/render, по web-socket получаю от сервера сообщение об изменении страницы и обновляю страницу. Это позволяет держать мне клиент-сайд часть минимально простой (единственная реакция — рефреш — на серверное событие, минимум клиентских событий, требующих специальных обработчиков — остальное простые ссылки). Как мне кажется, обработка каждого клика на клиент-сайде возьмет ресурсов на клиенте не сильно меньше чем ещё и шаблонизация. Я ошибаюсь в порядках оценки ресурсов обработчиков с манипуляцией DOM и шаблонизацией, или в количество переходит в качество и где нагрузка N допустима, там 2N недопустима?
P.S. А вообще мы как-то ушли от обсуждения песочницы к одностраничным приложениям. Если использовать шаблонизатор для генерации ответов от контроллера, то шаблоны смогут получать доступ ко всему приложению и среде выполнения, хоть полный хтмл, хоть частичный.
На скачивание — 6 потоков минимальное. Некоторые браузеры до 10 позволяют.
Линейная задержка возникает, конечно же, но меня это особо не волнует, я даже последовательно контент загружаю, не мультипоточно. И это все равно получается быстрее, чем загрузить одну «большую» страницу.
Некоторые данные оседают в кэшах, поэтому догружаются еще быстрее, минуя запросы к базам данных.
Ошибка и там и там. Шаблонизация на уровне чистой манипуляции DOM — самая медленная. innerHTML работает быстрее, так как задействует парсер браузера минуя JS-интерпретатор. Опять же, возникает другая проблема: JS не умеет «выплевывать» любой нагенеренный контент в stdout, поэтому придется использовать конкатенацию строк или реплейсить строки через RegExp'ы. Везде получаем деградацию по скорости.
В одностраничных интерфейсах в совокупности с ненавязчивым JS получаем еще один костыль — нужно следить за вновь созданными нодами в DOM-дереве, чтобы функциональность не страдала. С ростом количества нод до 5000 и выше «следильщики» будут отжирать львиную долю времени после шаблонизации. А 5К нод для одностраничных приложений — не проблема вообще.
Поэтому я выкинул почти полностью шаблонизацию на JS, так как сервер + рендерер браузера справляются с задачей поставки контента потребителю быстрее всего. В топку ушел ненавязчивый Javascript, ибо при длительном использовании интерфейса он является причиной падения скорости работы приложения в целом. Не подходит и jQuery-way, когда сначала набирается пул нод для работы, а потом с ними поочередно выполняются какие-то действия. Зачастую слишком большая зона видимости получается, в селектор попадает дофига лишнего.
Линейная задержка возникает, конечно же, но меня это особо не волнует, я даже последовательно контент загружаю, не мультипоточно. И это все равно получается быстрее, чем загрузить одну «большую» страницу.
Некоторые данные оседают в кэшах, поэтому догружаются еще быстрее, минуя запросы к базам данных.
Ошибка и там и там. Шаблонизация на уровне чистой манипуляции DOM — самая медленная. innerHTML работает быстрее, так как задействует парсер браузера минуя JS-интерпретатор. Опять же, возникает другая проблема: JS не умеет «выплевывать» любой нагенеренный контент в stdout, поэтому придется использовать конкатенацию строк или реплейсить строки через RegExp'ы. Везде получаем деградацию по скорости.
В одностраничных интерфейсах в совокупности с ненавязчивым JS получаем еще один костыль — нужно следить за вновь созданными нодами в DOM-дереве, чтобы функциональность не страдала. С ростом количества нод до 5000 и выше «следильщики» будут отжирать львиную долю времени после шаблонизации. А 5К нод для одностраничных приложений — не проблема вообще.
Поэтому я выкинул почти полностью шаблонизацию на JS, так как сервер + рендерер браузера справляются с задачей поставки контента потребителю быстрее всего. В топку ушел ненавязчивый Javascript, ибо при длительном использовании интерфейса он является причиной падения скорости работы приложения в целом. Не подходит и jQuery-way, когда сначала набирается пул нод для работы, а потом с ними поочередно выполняются какие-то действия. Зачастую слишком большая зона видимости получается, в селектор попадает дофига лишнего.
Как посчитать эту прибыль?
Senior .net переобучается на php. Через какое время он станет senior php?
Senior .net переобучается на php. Через какое время он станет senior php?
тут вопрос о том что .net разработчикам предложили переквалифицироваться в php. Вопрос не про прибыль компании а про людей. Стоит ли им переучиваться или нет
Недавно нам предложили в точности да наоборот, 6 лет до этого писал на php последние несколько лет ZendFramework и doctrine 2, в последнее время стали писать на ZF2 и он действительно очень не плох, но вот предложили начать писать на C# asp.net с сохранением зарплаты. И я согласился, собственно вместе с большей частью основной команды, т.к. хоть я и был senior php — я им и остался, а изучать что-то новое это всегда полезно — новые возможности. Мое мнение, если устраивает зарплата, то стоит попробовать, тем более вернуться назад вам никогда никто не запретит.
Было такое… в результате идет перескок на Ryby/Puthon или, что чаще всего, на ASP.NET MVC.
Я не могу в это поверить, .net переквалифицируются в php, при условии достаточной лояльности к новому языку\платформе
Я был бы только рад такой возможности освоить новые знания на реальном заказе. Другое дело, что заказчик должен понимать, что исполнитель может не знать новую платформу так хорошо, как свою родную. Мнение, что PHP плохой язык — это всё предрассудки. На нём можно писать качественный код, точно так же как и на других языках. У него много плюсов и ваш заказчик это прекрасно понимает.
Вариант с mono рассматривали, даже успешно мигрировали большую часть проекта за короткое время, но заказчик, хочет интеграцию не на уровне интерфейса, а на уровне кода, возможно из-за того, что проект будет на поддержке совместно с другими проектами из пакета, которые уже реализованны на php
Если под словом «интеграция» не понимать хардкод и забивание патчей кулаками, не вижу особых проблем.
Для достаточно тесной интеграции можно попробовать «оживить» pecl/mono — это всяко менее затратно, чем все переписывать на php.
Для достаточно тесной интеграции можно попробовать «оживить» pecl/mono — это всяко менее затратно, чем все переписывать на php.
Думается мне, что, возможно, заказчик не понимает, что переписать всё на php возможно будет дороже чем написать адаптеры к своим сервисам.
Слишком много всяких нюансов же, что-бы вот так сразу ответить.
Сам проект, деньги, время, команда, условия поддержки и так далее.
Сам проект, деньги, время, команда, условия поддержки и так далее.
Согласился бы если бы было перспективно, интересен сам проект(бизнес область а не платформа или язык) или денежно.
Все равно на чем писать, главное как и что писать.
Все равно на чем писать, главное как и что писать.
Если заказчик платит за время адаптации и обучения, то сменю. И с удовольствием изучу что-нибудь новое для себя. Но, опять же, заказчик должен быть осведомлён обо всех последствиях, как то: увеличение сроков, увеличение рисков, небольшое (будем честными!) снижение качества финального продукта.
С ASP.NET на PHP? Низачто.
Вообще, конечно, странно. Мне кажется, дешевле будет нанять php-программистов, которые бы всё сделали. Ведь нужно не просто конструкция-в-конструкцию портировать, а реально знать особенности обоих языков.
Вообще, конечно, странно. Мне кажется, дешевле будет нанять php-программистов, которые бы всё сделали. Ведь нужно не просто конструкция-в-конструкцию портировать, а реально знать особенности обоих языков.
Боюсь, что с .Net 3.5+ на PHP слазить будет оооооччень болезненно. Я уже и не представляю себе жизнь без linq, лямбд, анонимных типов и так далее, не говоря уже о самой BCL
А что мешает просто адаптировать под mono и пускать себе на никсах?
С PHP на ASP.NET? Вот уж точно ни за что!)
Задротское корпоративное программирование с жесткой привязкой к майкрософту? Отлично для карьеры, наверное, но как и, например, 1С — вызывает позывы к суициду у многих разработчиков еще на уровне знакомства.
Задротское корпоративное программирование с жесткой привязкой к майкрософту? Отлично для карьеры, наверное, но как и, например, 1С — вызывает позывы к суициду у многих разработчиков еще на уровне знакомства.
Я, ни в коем случае, не пытаюсь говорить за всех, но точно знаю что я не одинок. Я лично отказывался изучать asp уже пару раз, и некоторые мои знакомые тоже. Как правило это касается «свободных» разработчиков и фрилансеров.
Ну, тут можно только отправить для начала разобраться в теме, прежде чем с умным видом высказывать ничем не подкованные заведомо ложные утверждения.
оо… это же хабрахабр, я и забыл.
с чем же разбираться? вот с этим www.gotdotnet.ru/forums/4/143137/?
с чем же разбираться? вот с этим www.gotdotnet.ru/forums/4/143137/?
ASP .NET вроде как свободный продукт. А у C# есть реализации не только от Microsoft.
Вроде как — тут ключевые слова.
Ну разве это что-то меняет? Вы видели реальные проекты на моно или может быть видели asp.net работающей без остальной виндоуз-инфраструктуры? да даже администрировать IIS большая часть моих знакомых программистов и админов — отказались бы сразу.
Но тут видимо аудитория оочень корпоративная. В карму только не лезьте блин, я старательно поддерживаю легкий плюс.)
Но тут видимо аудитория оочень корпоративная. В карму только не лезьте блин, я старательно поддерживаю легкий плюс.)
Чем вам IIS не угодил? =) А MVC под Apache 2.0 лицензией.
Вот пример на Ubuntu: Xamarin.com
Вот пример на Ubuntu: Xamarin.com
Server:Apache/2.2.20 (Ubuntu)
Vary:Accept-Encoding
Via:1.1 varnish
X-AspNet-Version:4.0.30319
X-AspNetMvc-Version:3.0
X-Powered-By:Mono
X-Varnish:187530159
Как человек, программирующий на 1с, c# и php, скажу, что c# совсем не то же самое, что 1с :). Скорее это у php подобная слава :)
Ну толсто же!..
Нет разницы на чем писать. Есть разница что именно писать.
Однажды подрабатывал на одних и пришлось поучить как раз php — заказчик заплатил за адаптацию и обучение. Ну, что-то новое для себя вынес — понял, что на пхп я если и соглашусь ещё когда писать, то только за деньги, которые в нашем регионе пхп разработчикам не платят :). Но это мои собственные тараканы. А вот, скажем, предложи сейчас кто нечто подобное, но с целевым языком, скажем, эрлангом, согласился бы почти не раздумывая :).
Смотря на сколько новая платформа далека от старой. К примеру если я пишу сайт на Python \ Django, то сменить на Ruby \ Rails вполне возможно. Но заказчик должен понимать, что на изучение уйдет время. А вот если заказчику вдруг внезапно захочется сменить платформу на ASP.NET, то уже задумаюсь.
Сделать ASP.net routing на расширение .php и пусть радуется заказчик.
Работать нужно так, чтоб нравилось.
Переписывать уже готовый проект скучно.
Перейти с .net на php…
Все зависит от вашего отношения к работе — если это просто зарабатывание денег, однозначно да. Если работа для вас что то большее (а для меня это дело всей жизни) то однозначно нет.
Переписывать уже готовый проект скучно.
Перейти с .net на php…
Все зависит от вашего отношения к работе — если это просто зарабатывание денег, однозначно да. Если работа для вас что то большее (а для меня это дело всей жизни) то однозначно нет.
Если мне новая платформа интересна, то разумеется да, но если меня попросят, к примеру, переписать все на чем-нибудь таком, что у меня вызывает отторжение, то я пошлю нафиг с такими предложениями.
У меня был личный опыт такой: PHP -> ASP.NET C# -> PHP.
Сейчас я точно не перешел бы с PHP на классический ASP.NET.
С ASP.NET MVC на PHP, ну очень сильно бы задумался.
Ну а в целом, PHP на месте не стоит, в нем появляются новые возможности, а также активно развиваются очень приятные фреймворки.
Сейчас я точно не перешел бы с PHP на классический ASP.NET.
С ASP.NET MVC на PHP, ну очень сильно бы задумался.
Ну а в целом, PHP на месте не стоит, в нем появляются новые возможности, а также активно развиваются очень приятные фреймворки.
Сделайте ход конем — предложите заказчику переписать его проекты на .NET!
Мне нравится осваивать новые вещи, особенно когда за это платит заказчик или работодатель.
(Но не пхп, конечно.)
(Но не пхп, конечно.)
Лично я бы не согласился. Правило 10 000 часов никто не отменял.
Зависит от того на какую зарплату мог бы рассчитывать в случае смены работы с учетом новых знаний и от того насколько интересная была бы для меня задача.
На php навряд ли захотел бы переходить.
На php навряд ли захотел бы переходить.
Мой первый заказчик настолько поверил в меня — что буквально уговорил взяться за проект, хотя я честно признался что хорошо шарю только в олимпиадных программках, а больших проектов не писал ни разу.
Проект в итоге пришлось пару раз начинать писать заново, но во весь стек технологий окунулся с головой и получил неоценимый опыт. За что очень благодарен тому заказчику и отношусь лояльно к его просьбам иногда что-то быстренько добавить/переделать в его продуктах.
Осваивал кстати Django/Python + jQuery/JS + Less/CSS
Проект в итоге пришлось пару раз начинать писать заново, но во весь стек технологий окунулся с головой и получил неоценимый опыт. За что очень благодарен тому заказчику и отношусь лояльно к его просьбам иногда что-то быстренько добавить/переделать в его продуктах.
Осваивал кстати Django/Python + jQuery/JS + Less/CSS
Переход с .NET стека на PHP может быть очень болезненным из-за отсутствия привычного инструментария и из-за вольностей которые позволяет PHP. Первое можно более-менее сносно решить, второе только в головах и решать нужно строгими ограничениями того «что можно, а за что линейкой по рукам». Если будете пробовать то я бы посоветовал PhpStorm и все-все-все покрывать огромным количеством хинтов через phpDoc, иначе будет «боль, адъ и содомия». Шторм, конечно, умен, но далеко не всегда может сам разрулить те-же типы без подсказок. И уж точно не будет настолько интеллектуален как Resharper если вы не будете ему в этом помогать… В общем за «гибкость» придется платить отсутствием всех тек клевых инструментов которые есть у .net/c# :(
Я бы не стал слушать советов человека, который первым делом говорит об IDE. Почему шторм, а не эклипс, например? У меня вот шторм тормозит на стареньком пне и я использую eclipse 7. Из всего функционала мне необходим поиск — замена с регулярными выражениями, удобная навигация, хоткеи и шаблоны команд. Это есть в любой IDE. Позвольте узнать, чего такого полезного есть в PhpStorm, что могло бы повысить мою производительность труда или облегчить процесс разработки? Мне действительно интересно, т.к. я сейчас перешел на PhpStorm, но не вижу никаких плюсов.
Из всего функционала мне необходим поиск — замена с регулярными выражениями, удобная навигация, хоткеи и шаблоны команд.
Ну и не пользуйте шторм, я ведь не заставляю. Но выражаю обоснованное сомнение в том что разработчик из .net стека обходится такими же требованиями к главному средству разработки.
Это есть в любой IDE. Позвольте узнать, чего такого полезного есть в PhpStorm, что могло бы повысить мою производительность труда или облегчить процесс разработки?
Ну, не знаю… Это примерно как сравнить VS+(ReSharper|codeRush|Visual Assist X|etc) со стоковым SharpDevelop не первой свежести. Извините за прямоту.
Мне действительно интересно, т.к. я сейчас перешел на PhpStorm, но не вижу никаких плюсов.
Тут кроме как посоветовать больше читать и интересоваться его плюшками, пытаться примерить их на себя или попробовать использовать, не смотря на кажущуюся ненужность, ничего посоветовать не могу. Может ваш привычный workflow не позволяет ему раскрыться, а пересматривать его не хотите, ведь он вас всем устраивает.
Мне было просто. после VS для C# и IDEA для Java я много лет испытывал нехватку подобного инструмента для PHP (пользовал ZendStudio, версию не помню, те которые на эклипсе). И когда появился первый шторм он уже был на голову выше конкурентов. Сейчас уже 6-я версия на подходе и я радуюсь. Я сейчас даже не смогу назвать что именно мне в нем надо (по идее всё). Многие пользуют vim/emacs(я не умею) или SublimeText и счастливы. А я не могу пользоваться Sublime кроме как для работы с текстом, вот не могу и капец. Скриптик подправить — пожалуйста, работать в нем — не получается, постоянно чего-то не хватает :(
Если работать с кодом как с текстом то разницу, наверное, будет сложно почувствовать. Но если смотреть на код как на сложную структуру взаимосвязей объектов то она становится видна. Шторм понимает контекст, типы, выдает умные подсказки, обращает внимание на потенциальные скользкие места и еще много-много вкусного. Но это вкусное нужно распробовать.
В общем могу только удачи пожелать в освоении Шторма, он того стоит.
Совершенно верно, мы сейчас не сравниваем IDE с легковестным редактором с подсветкой. Плюс IDE в том, что мы можем смотреть на большой проект свысока (навигация и поиск) и то что она упрощает задачи рефакторинга. Я даже не хочу услышать от вас какой-либо анализ отличий между популярными IDE. Мне просто интересны ваши случаи использования, что-нибудь такое, что я мог бы перенести в свою практику. Пока всё что вы описали, я и так использую, как вы поняли это всё работает в старом эклипсе 7, но это сейчас не важно.
Сорри, не могу вот так с наскоку сказать почему мне шторм удобнее. Как-то вот по совокупности плюшек он для меня комфортен. Ради интереса в прошлом году пробовал NetBeans и ZendStudio последние на тот момент, и было некомфортно. Не потому что хоткеи не такие, а просто в течении дня в какой-то момент появлялась естественная необходимость в какой-нибудь плюшке шторма и я ее не находил. В итоге после нескольких раз возвращался в шторм. можете считать мою любовь к шторму иррациональной, но мне сложно выразить его преимущества словами. Короче, я как тупой фанатик нутром ощущаю что шторм рулит, но объяснить не могу.
П.С.: вот прямо сейчас вливаюсь в коллектив, в новый для меня проект. По идее собран он из знакомых компонентов и все должно быть, на первый взгляд, просто. Но «remote: Counting objects: 964102, done» и я понимаю, что без очень удобной IDE я с ним буду знакомиться годами.
П.С.: вот прямо сейчас вливаюсь в коллектив, в новый для меня проект. По идее собран он из знакомых компонентов и все должно быть, на первый взгляд, просто. Но «remote: Counting objects: 964102, done» и я понимаю, что без очень удобной IDE я с ним буду знакомиться годами.
Вот вы пишете, что шторм выдаёт умные подсказки. Как я могу судить, он с ними перебарщивает и выдаёт очень много совершенно лишних и необоснованных «подсказок», видимо из-за того, что не может определить некоторые связи правильно.
видимо из-за того, что не может определить некоторые связи правильно.
Таки да. За гибкость PHP приходится платить такую цену. Даже человек не всегда может правильно определить что же ему вернет тот-или иной __magic геттер, чего уж от там… Подсказывайте или подавляйте лишние сообщение через supress…
и все-все-все покрывать огромным количеством хинтов через phpDoc
И уж точно не будет настолько интеллектуален как Resharper если вы не будете ему в этом помогать…
Согласился бы, при достаточном уровне лояльности и интереса. Правда, я про .NET стек знаю только то, что он ещё не очень поддерживается на *unix платформах, этого мне достаточно :) Но если нет интереса, тогда зачем вообще оно нужно? Я сам по клиент-сайду с JS больше, а для сервера предпочёл бы Node.js, но если бы мне предложили (и предлагали, да) написать проект на чём-то другом, то я бы сильно задумался. На RoR — согласился бы, на Python/Django — возможно, не уверен. На Erlang/Clojure — согласился. Знаю про них не много, и из лиспов писал только на Scheme, но это интересно. На Java или PHP — не согласился бы. Это не интересно.
Ай, как это я неплохо промахнулся веткой. А по сабжу — для IDEA есть vim плагин, кстати. Поможет любителям вима в переходе.
Ай, как это я неплохо промахнулся веткой. А по сабжу — для IDEA есть vim плагин, кстати. Поможет любителям вима в переходе.
о, вот может Вы мне ответите? ещё какая-нибудь IDE понимает эти хинты? а то получается немеряное количество говна в коде только для PhpStorm.
Это говно называется — комментарии в формате PHPDoc. Любой приличный разработчик их пишет независимо от IDE.
phpDoc я пишу — и много, но перед каждым сомнительным присвоением переменной писать var — особенно если это понимает только шторм — мне не очень нравится.
Как минимум, их понимают все нормальные иде: zend, phped, phpstorm судя по моему коду 5-летней давности
bitbucket.org/xumix/cakephp-sphinx-behavior/src/25bd61fb18e3cade10f96d546c921e92a4e95fcf/sphinx.php?at=default
bitbucket.org/xumix/cakephp-sphinx-behavior/src/25bd61fb18e3cade10f96d546c921e92a4e95fcf/sphinx.php?at=default
ага, понятно. вобщем, это обсуждение таки сподвигло меня погуглить насчет использования этого метода в NetBeans. что ж, я давно хотел поменять его на что-нибудь другое.
Ну, в нетбинсе тоже работает вроде как stackoverflow.com/questions/1798477/variable-type-hinting-in-netbeans-php
второе только в головах и решать нужно строгими ограничениями того «что можно, а за что линейкой по рукам».ага, а к Perl'у, видимо, вообще за версту подходить нельзя.
ага, а к Perl'у, видимо, вообще за версту подходить нельзя.
Вы не поверите! :)
Но да, к перлу у меня именно такое отношение. Где-то отстрелить себе ногу проще, где-то сложнее, но перл просто создан для отстреливания ног :) Т.ч. я к нему на ВЫ и только с cookbook'ом или обложившись словарями(манами).
тут я плакал :)
кстати, самое смешное, после 4 лет на Perl/Python с таким же отношением пришел в компанию, где работают на PHP.
работал 1 месяц. из достижений,
1) поднял инсталляцию Redmine и все такое в традициях Devops (и в то время перевел отдел на нее, уж не знаю что там с ней сейчас);
2) перевел малую часть внутреннего интерфейса на Twitter Bootstrap;
3) потерял прибыль компании за одни-двое сутки где-то, за счет закоммиченной фигни по какой-то задаче.
и это, по факту, нервно. привык уже к другому процессу.
P.S.: де факто процесс важнее языка. Perl mongers в крупных компаниях более склонны к дисциплине посредством регламентов, и это спасает.
кстати, самое смешное, после 4 лет на Perl/Python с таким же отношением пришел в компанию, где работают на PHP.
работал 1 месяц. из достижений,
1) поднял инсталляцию Redmine и все такое в традициях Devops (и в то время перевел отдел на нее, уж не знаю что там с ней сейчас);
2) перевел малую часть внутреннего интерфейса на Twitter Bootstrap;
3) потерял прибыль компании за одни-двое сутки где-то, за счет закоммиченной фигни по какой-то задаче.
и это, по факту, нервно. привык уже к другому процессу.
P.S.: де факто процесс важнее языка. Perl mongers в крупных компаниях более склонны к дисциплине посредством регламентов, и это спасает.
Все бы ничего, но этот пакет продается совместно с серверами, на базе *nix платформы, а наш продукт написан на ASP.NET MVC
Может лучше переписать код на Java? С C# на Java проще перейти, чем на PHP, т.к. языки похожи.
Вообще, было бы легче понять вашу ситуацию при наличии большего количества деталей — пока не совсем понятно, почему нет возможности предоставить php-проектам необходимые wcf-сервисы, организовать общие бд или что им там нужно. В чем заключается планируемая интеграция?
А если конкретно на вопрос отвечать — не советую. Это не последний в жизни проект, а распыляться на php (даже за счет заказчика), это не то же самое, что выучить F#, XNA, WPF (исхожу из предположения, что как web-разработчик вы до сих пор не фокусировались на них), проекты на которых вполне могут появиться в дальнейшем. Зато время на изучение этих технологий будет не жалко потратить, в отличие от времени на php, за которое можно как минимум прокачаться в MVC 4 и .NET 4.5.
А если конкретно на вопрос отвечать — не советую. Это не последний в жизни проект, а распыляться на php (даже за счет заказчика), это не то же самое, что выучить F#, XNA, WPF (исхожу из предположения, что как web-разработчик вы до сих пор не фокусировались на них), проекты на которых вполне могут появиться в дальнейшем. Зато время на изучение этих технологий будет не жалко потратить, в отличие от времени на php, за которое можно как минимум прокачаться в MVC 4 и .NET 4.5.
Ой, промахнулся, этот комментарий предназначался Вам.
Нет, с php, к сожалению (а может наоборот, к счастью)), не знаком, иначе привел бы аргументы совсем по существу. Но сейчас объясню, почему не советую с ним связываться.
Сразу скажу, что никакой расовой ненависти к нему не испытываю, да и речь пойдет не обо мне. Дело в том, что за время работы в нескольких местах успел столкнуться с 6 разработчиками, пришедшими в .net из php. Приходили они уже сразу на MVC (я даже в одной компании, пока полностью не перешли на MVC, чувствовал себя малость ущемленным, потому что мне, как более сведущему, приходилось больше заниматься поддержкой старых WebForms-проектов), и наверно поэтому ни одной жалобы от них я не услышал — наоборот, все, как один, вспоминали php неприятными словами. Php-разработчики.
Поэтому мне кажется пустой тратой времени, зная .NET, связываться с php.
А насчет интеграции — все-таки не могу представить сценарий, при котором невозможно наладить связь между .net и php, и не совсем понимаю, что значит «на поддержке» — заказчик что, хочет, чтобы после сдачи проекта дальнейшим развитием занималась не ваша компания?
Сразу скажу, что никакой расовой ненависти к нему не испытываю, да и речь пойдет не обо мне. Дело в том, что за время работы в нескольких местах успел столкнуться с 6 разработчиками, пришедшими в .net из php. Приходили они уже сразу на MVC (я даже в одной компании, пока полностью не перешли на MVC, чувствовал себя малость ущемленным, потому что мне, как более сведущему, приходилось больше заниматься поддержкой старых WebForms-проектов), и наверно поэтому ни одной жалобы от них я не услышал — наоборот, все, как один, вспоминали php неприятными словами. Php-разработчики.
Поэтому мне кажется пустой тратой времени, зная .NET, связываться с php.
А насчет интеграции — все-таки не могу представить сценарий, при котором невозможно наладить связь между .net и php, и не совсем понимаю, что значит «на поддержке» — заказчик что, хочет, чтобы после сдачи проекта дальнейшим развитием занималась не ваша компания?
А они использовали на PHP ООП и паттерны, MVC-фреймворки и *DD или писали «простыни спагетти», пользуясь практиками 10+летней давности? Я с современными практиками познакомился в контексте PHP и они вызвали у меня прямо эйфорию. Когда просто из интереса и для расширения кругозора стал изучать другие платформы (RoR, Django, ASP .NET MVC, ещё что-то), то уже такого восторга, заставляющего плеваться на PHP, не было. Разве что когда Erlang изучал, но это на все императивные языки :)
такого восторга, заставляющего плеваться на PHP
На PHP плюются не потому что сидели в болоте, а тут нос из тины высунули — глядь солнышко светит, птички поют, а не пиявки за пятки кусают. Нет. PHP хороший язык, но работая с ним всегда приходится держать что-то в уме (тут помнить; здесь записать напоминалочку; там не забыть что вот так нельзя, хотя это вовсе и не явно). Все эти модные практики. паттернны, методологии и чего там типа модного/свежего/прогрессивного, они есть везде, они не зависят от стека и не могут быть причиной радости/ненависти при смене платформы.
Просто переход на языки с явной статической типизацией это как с должности воспитателя старшей садиковой группы перейти на какую-нибудь армейскую начальственную должность, да еще и с секретаршей телепаткой. В саду было интересно, но постоянно приходилось суетиться, мирить, находить общий язык и требовалось много снисходительности и терпения, а теперь, конечно, не так весело, зато дисциплина и порядок, и в голова отдыхает, а если вдруг что понадобится секретарша тут же напомнит/прояснит/проконсультирует. Обычно осознание этой разницы и является причиной хая PHP. Но это в первый раз так, если периодически переключаться между стеками то желание хаять со временем проходит и остается понимание что они просто разные. Настолько разные что смысла сравнивать нет, есть смысл использовать сильные стороны той с которой работаешь в данный момент.
Я видел разные переходы. И сам перешел на PHP с C++. Для многих (не для всех) переход на другую платформу связан не только с удобством языка как такового, но и открытием новых практик, которых никто не мешал применять и на старой платформе, но как-то не довелось с ними столкнуться.
А хаят PHP не только перешедшие на языки со статической типизации. Я бы даже сказал не столько, а сколько «братья по разуму», перешедшие на Ruby, Python или Perl. А аналог статической типизации в PHP я и сам с удовольствием использую, хотелось бы чуть больше у него возможностей (определять параметры функций/методов и для скаляров, типизированные массивы и определять возвращаемое значение), но вот никаких сожалений от того, что не могу определить тип переменной не испытываю.
А хаят PHP не только перешедшие на языки со статической типизации. Я бы даже сказал не столько, а сколько «братья по разуму», перешедшие на Ruby, Python или Perl. А аналог статической типизации в PHP я и сам с удовольствием использую, хотелось бы чуть больше у него возможностей (определять параметры функций/методов и для скаляров, типизированные массивы и определять возвращаемое значение), но вот никаких сожалений от того, что не могу определить тип переменной не испытываю.
>Обычно осознание этой разницы и является причиной хая PHP
Не, вряд ли. Тогда такой же «хай» был бы на любые другие языки с динамической типизацией. Я с текущей явы с удовольствием перейду на руби и груви, пожав плечами на питон, поскребя затылок на перл (туда меня, правда, вряд ли возьмут за утратой навыков по давности лет), но ни за что на пхп (на постоянку — вообще не, а за халтурку запрошу денег, которых мне не предложат). Все эти языки я знаю в той или иной степени, на некоторых писал продакшн код (втч на пхп). Такие дела…
Не, вряд ли. Тогда такой же «хай» был бы на любые другие языки с динамической типизацией. Я с текущей явы с удовольствием перейду на руби и груви, пожав плечами на питон, поскребя затылок на перл (туда меня, правда, вряд ли возьмут за утратой навыков по давности лет), но ни за что на пхп (на постоянку — вообще не, а за халтурку запрошу денег, которых мне не предложат). Все эти языки я знаю в той или иной степени, на некоторых писал продакшн код (втч на пхп). Такие дела…
Все то, что сейчас приходит в PHP, было в той же Java уже много лет назад. Тот же фреймворк Symfony 2 — вообще попытка писать на Java с синтаксисом PHP. При этом ладно бы все эти современные практики, паттерны и т.п. не просто копировались бы, а эволюционировали, так ведь пишешь и мысли «а вот это на Java спроектировано лучше» возникают постоянно.
Сейчас на основной работе являюсь разработчиком сразу и на Java, и на PHP. Для серьезного проекта сходу не могу придумать ни одного довода в пользу PHP. Пожалуй, только шаблонизация удобнее и проще реализуется. Ну, порой, еще напрягает разных структур данных плодить там, где в PHP массивами обойтись можно, но зато дисциплинирует и заставляет думать над тем, что пишешь.
Многие говорят, да и я раньше говорил, что PHP разработчиков проще найти и они дешевле. Ага, если бы! Чтобы найти одного адекватного PHP'шника, надо такое кол-во резюме отсмотреть и людей отсобеседовать, что порой просто вешаться хочется. Возможно, мое «адекватный разработчик» — это на самом деле уровень, как минимум, senior'а, но, блин, после опыта на той же Java с ее возможностям и требованиям к знаниям и опыту (привет многопоточность, к примеру), PHP кажется каким-то детским садом.
Кстати, при всем при этом и у Java минусов хватает. Это даже с учетом того, что идеальных решений не может быть в принципе.
Не, не спорю, относительно простенький сайт почему бы не написать и на PHP (тот же интернет-магазин с кучей плюшек — это тоже простенький сайт, ничего кроме совершенно банальной логики и UI там нет (утрирую, конечно)). Особенно если опыта на PHP больше у конкретного человека или команды. Но ведь одним этим даже и веб-программирование не ограничивается.
ЗЫ: С .net'ом не работал, так что тут прокомментировать не могу.
Сейчас на основной работе являюсь разработчиком сразу и на Java, и на PHP. Для серьезного проекта сходу не могу придумать ни одного довода в пользу PHP. Пожалуй, только шаблонизация удобнее и проще реализуется. Ну, порой, еще напрягает разных структур данных плодить там, где в PHP массивами обойтись можно, но зато дисциплинирует и заставляет думать над тем, что пишешь.
Многие говорят, да и я раньше говорил, что PHP разработчиков проще найти и они дешевле. Ага, если бы! Чтобы найти одного адекватного PHP'шника, надо такое кол-во резюме отсмотреть и людей отсобеседовать, что порой просто вешаться хочется. Возможно, мое «адекватный разработчик» — это на самом деле уровень, как минимум, senior'а, но, блин, после опыта на той же Java с ее возможностям и требованиям к знаниям и опыту (привет многопоточность, к примеру), PHP кажется каким-то детским садом.
Кстати, при всем при этом и у Java минусов хватает. Это даже с учетом того, что идеальных решений не может быть в принципе.
Не, не спорю, относительно простенький сайт почему бы не написать и на PHP (тот же интернет-магазин с кучей плюшек — это тоже простенький сайт, ничего кроме совершенно банальной логики и UI там нет (утрирую, конечно)). Особенно если опыта на PHP больше у конкретного человека или команды. Но ведь одним этим даже и веб-программирование не ограничивается.
ЗЫ: С .net'ом не работал, так что тут прокомментировать не могу.
Как по мне, основные преимущества PHP лежат вне языка, библиотек, фреймворков и прочих инструментов разработчиков. Это, во-первых, большое количество CMS различного уровня и для различных ниш, а, во-вторых, простота их разворачивания и администрирования (пока не требуется горизонтальное масштабирование). Уникальный проект я, пожалуй, тоже не стал бы сейчас на PHP писать, если логика в нём заметно серьезнее CRUD планируется, но вот когда реч заходит о массовом продукте, который, утрируя, должна суметь любая секретарша развернуть…
Вот-вот. Пхп+мускул есть везде.
Любой «софт для домохозяек» пишешь не только на связке мускул-пхп, но и используя только синтаксис 5.3 и только с теми модулями которые популярны. Я до сих пор половину уже доступного функционала мускула не использую «на всякий случай». Иногда приходится чуть ли не EAV лепить там, где можно было бы легко взять что-то вроде mongoDB, только для универсальной совместимости.
Любой «софт для домохозяек» пишешь не только на связке мускул-пхп, но и используя только синтаксис 5.3 и только с теми модулями которые популярны. Я до сих пор половину уже доступного функционала мускула не использую «на всякий случай». Иногда приходится чуть ли не EAV лепить там, где можно было бы легко взять что-то вроде mongoDB, только для универсальной совместимости.
Templates в Symfony удобнее реализованы, чем, например, во FreeMarker? Вы серьёзно? Или что-то другое имелось ввиду?
Поэтому мне кажется пустой тратой времени, зная .NET, связываться с php.
При тесном контакте, можно для себя, как специалиста выяснить в чем +\- реализации проектов на новом стеке технологий. В нашем случае есть возможность сравнить технологии (и результат их использования) без особых усилий. В будущем если нам предстоить выбирать технологии, нам будет из чего это делать. Так что может не такая уж и пустая )
заказчик что, хочет, чтобы после сдачи проекта дальнейшим развитием занималась не ваша компания
Наш проект имеет вполне видимый набор фичь, который вряд ли будет меняться после релиза. Поэтому, да, думаю что фикс разных багов, или неболшие доделки после релиза вполне могут уйти на сторону заказчика.
К сожалению я сам не обладаю достаточной информацией о будущей интеграции. Подробности будем узнавать позже. Чуть выше я предположил еще 1 вариант, почему был выбран именно php.
У Вас в профле написано asp.net разработчик, а был ли у Вас опыт работы на php?
У Вас в профле написано asp.net разработчик, а был ли у Вас опыт работы на php?
Где вы таких заказчиков находите? Колитесь! :)
А если серьезно, то с удовольствием бы, если заказчик понимает что времени это займет больше, код будет не столь оптимальным и качественным и всё это обойдется ему в какую-то дополнительную сумму и на собственно разработку, и на поддержку.
Главная причина того, чтосменил бы освоил бы с радостью ещё одну платформу на реальном проекте — возможность лучше оценивать области применимости обеих, их плюсы и минусы самому, а не доверяя экспертам с неизвестными субъективными пристрастиями. Чтобы на следующем проекте новому заказчику сказать: «это можно сделать на платформе А, времени займет столько-то, плюсы такие-то, минусы такие-то, а можно сделать на B за столько-то с другими плюсами и минусами — выбирайте.»
Программируйте с использованием языка, а не на языке!
А если серьезно, то с удовольствием бы, если заказчик понимает что времени это займет больше, код будет не столь оптимальным и качественным и всё это обойдется ему в какую-то дополнительную сумму и на собственно разработку, и на поддержку.
Главная причина того, что
Программируйте с использованием языка, а не на языке!
Это сегодня клиент на PHP писать попросит, завтра и пол сменить закажет! (с) Тайский юмор
Нужно быть разработчиком 80 левела, чтобы безболезненно осваивать новый язык на коммерческом проекте.
PHP, ASP, Python, Ruby, Perl — что-то мне подсказывает, что независимо от выбора языка, на выходе получится brainfuck.
Академический интерес разумно удовлетворять на экспериментальных проектах, которые вряд ли обретут успех, но зато используют возможности языка по полной программе.
Если вы хороший разработчик, то заказчик не почувствует разницы. В отличие от вас. Я бы не стал так рисковать нервами, временем и, возможно, репутацией.
Есть ли смысл осваивать PHP ради единственного проекта? Боюсь, вы успеете только проникнуться ненавистью к этому языку, как некоторые комментаторы.
Есть ли смысл осваивать его самостоятельно, когда можно (как советовали выше) нанять сложившихся специалистов, а собственное время потратить на изучение более прикладных вещей?
PHP, ASP, Python, Ruby, Perl — что-то мне подсказывает, что независимо от выбора языка, на выходе получится brainfuck.
Академический интерес разумно удовлетворять на экспериментальных проектах, которые вряд ли обретут успех, но зато используют возможности языка по полной программе.
Если вы хороший разработчик, то заказчик не почувствует разницы. В отличие от вас. Я бы не стал так рисковать нервами, временем и, возможно, репутацией.
Есть ли смысл осваивать PHP ради единственного проекта? Боюсь, вы успеете только проникнуться ненавистью к этому языку, как некоторые комментаторы.
Есть ли смысл осваивать его самостоятельно, когда можно (как советовали выше) нанять сложившихся специалистов, а собственное время потратить на изучение более прикладных вещей?
Раз вы задаете такой вопрос то вы плохие программисты.
Надо работать не на уровне языка, а на уровне интерфейсов.
Если бы у вас все было хорошо вы могли бы просто выдать этим «другим своим продуктам заказчика» предоставить API и всё. Интеграция на другом уровне не должна обсуждаться вообще.
ах да, я забываю, кто пишет веб на дотнете.
Надо работать не на уровне языка, а на уровне интерфейсов.
Если бы у вас все было хорошо вы могли бы просто выдать этим «другим своим продуктам заказчика» предоставить API и всё. Интеграция на другом уровне не должна обсуждаться вообще.
ах да, я забываю, кто пишет веб на дотнете.
Ээээ. А что мешает немного подправить код, чтобы тот завёлся на Mono? Всего-то перевести БД на любую из никсовых, да вычистить зависимости от виндовых компонент.
Проголосовал «Согласился», но вопрос стоит не корректно. Дело в том что в настоящий момент я бы в жизни не пошел изучать проприетарную платформу и/или язык. Потому ASP.NET/MSSQL выпали бы из списка. Нашел бы доводы, убедить клиента использовать открытые инструменты. Если бы не помогло, то вероятнее всего обратился бы к друзьям-коллегам и разделил бы проект с ними. В любом случае клиента терять нельзя, клиент — кормилец! А уж как реализовать проект — это дело техники.
>>Дело в том что в настоящий момент я бы в жизни не пошел изучать проприетарную платформу и/или язык.
Религиозные убеждения?
Религиозные убеждения?
ASP.NET MVC Framework распространяется под Apache License, язык C# имеет минимум 2 свободных реализации.
А эти свободные реализации, случаем, не отстают от microsoft-овской на пару версий? И Вы пробовали юзать их в реальном проекте под web?
Моно вполне на уровне. Причем Мигель весьма активно общается и некоторые косяки выправляют, что бы не было проблем с лицензиями и тд. Еще пилят такие штуки:Mono.Simd.
Не заглядывали на чем SDK для Playstation Vita? Sony Launches Beta SDK for Android and PlayStation Gaming Program. Можно еще и Unity до кучи вспомнить.
Не заглядывали на чем SDK для Playstation Vita? Sony Launches Beta SDK for Android and PlayStation Gaming Program. Можно еще и Unity до кучи вспомнить.
То, что уже чуть ли не половина гнома написана на моно как-бы в курсе. Но GUI — это одно, а вот реального большого и серьезного проекта под web на mono как-то не встречал.
Running Orchard on Mono. Юзкейсы этого проекта покрывают львиную долю того, что можно захотеть в Web проекте. Покажите что-то посложнее(в техническом плане) и можно уже будет обсуждать.
Если проект (не только предметная область, но и архитектура самого проекта, плюс все уровни от концепции до границы, где начинается реализация) хорошо изучен, задокументирован, согласован, стабилен — то есть определённая вероятность того, что выбор языка программирования для реализации проекта не будет существенным; разумеется, для этого должно быть явное требование максимальной абстрагированности реализации от выбора языка программирования и, если надо, — среды (вплоть до операционной системы и программной платформы). Даже если проект не влезает в такие требования, вполне можно поднапрячься и проанализировать, хотя бы на бумаге, насколько реален рефакторинг проекта в эту сторону. Если ответ на вопрос «что надо кодить?» — пройденный этап, как, например, таблица умножения для старшеклассника, только начинающего изучать [новый] алгоритмический язык, для которого поставили задачку вывести эту таблицу на экран — а он знает её наизусть, причём уже не первый год — то почему бы и нет? ведь для него реализуемость задачи, так сказать, математически доказана, и он знает, что на компьютере такое можно делать, и любой вполне развитый язык программирования справится с этим. Опять же, никто не отменял практику написания прототипов, [грубо] оценивающих совместимость требований проекта со средой программирования. Однако, если надо перенести сложный проект, и трудоёмкость этого переноса оценивается как большая, то да — вопрос нетривиален; но надо учесть, что рано или поздно реализация любого сложного проекта рискует стать унаследованным ПО, поэтому у проектов с претензией на долгожительство должны быть ресурсы для регулярных перевыпусков своих реализаций в новых окружениях. Также, можно подумать о кроссплатформенности или хотя бы о её аналогии и методах, применяемых при её использовании: в том смысле, что при появлении новой (необязательно принципиально новой) платформы проект должен попытаться сделать свою реализацию под неё. При этом в природе существуют такие пугающие воображение параноидальные варианты реализации, как прикладное ядро, написанное на отдельно стоящем языке программирования прикладного уровня, не зависящее от основного языка реализации, «живущее своей жизнью»; генератор исходного кода для нужной среды программирования; и т. п. Хотя, конечно, пока проект юн, надо начинать с простого и очевидного.
Если заказчик готов оплатить переобучение команды и поиск ошибок, допущенных при портировании — отчего бы и нет, может быть полезный опыт. Но что-то мне подсказывает, что от выставленного счёта у него могут волосы встать дыбом.
Сейчас нахожусь именно в такой ситуации — проект на C++/.NET будет с нуля переписан на PHP. Спокойно фиксю баги в старом проекте и подыскиваю работу. В промежутках пишу свой проект. Как только прозвенит звонок всем идти на PHP, уйду в другую компанию.
Для меня существенным критерием был бы вопрос необходимости перехода обратно. И вопрос работы параллельно в разных платформах. Не то чтобы это был бы критический фактор, но важный.
Помню одно время я писал много параллельно то на пхп то на 1с.
Всё время руки сами вместо ; печатал : (в русской раскладке точка с запятой нажимается без шифта, а в английской раскладке с шифтом, один палец нажимал по русски, другой по английски). И это только моторика. Каша в виде того, что тут фреймворк делает одной строчкой, а тут надо десять строк писать и т.п. тоже мешает.
Помню одно время я писал много параллельно то на пхп то на 1с.
Всё время руки сами вместо ; печатал : (в русской раскладке точка с запятой нажимается без шифта, а в английской раскладке с шифтом, один палец нажимал по русски, другой по английски). И это только моторика. Каша в виде того, что тут фреймворк делает одной строчкой, а тут надо десять строк писать и т.п. тоже мешает.
В свое время перешел с PHP на Ruby on Rails, потому что предложили работу на нем + обучение. По-моему, я очень везучий человек :)
На мой взгляд, данный вопрос, поставленный без явного указания платформ, никакого смысла не имеет. Это как спросить согласитесь ли вы поменять одну машину на другую. На какую?
Если как указано в предисловии (.NET -> PHP) — никогда. Смысл?
Да, заказчику это выгодно. Его можно понять. А мне — не выгодно, ибо придётся тратить время моей жизни на изучение более слабой (что бы не сказать больше) платформы. Разумеется, как профессионал, я с этим справлюсь, но, как профессионал, я также заинтересован в профессиональном росте, а не деградации. А заказчиков вокруг много. И PHP разработчиков также достаточно. Изучить сопоставимый по уровню продукт — это всегда пожалуйста. Вширь ещё расти можно, а вот вниз — нельзя.
В общем случае более сложная и мощная платформа даёт больше возможностей, включая финансовые. Для того люди и стремятся к профессиональному росту.
Согласится ли, к примеру, лётчик-истребитель променять свою лётную машину на, скажем, кукурузник? :)
Если как указано в предисловии (.NET -> PHP) — никогда. Смысл?
Да, заказчику это выгодно. Его можно понять. А мне — не выгодно, ибо придётся тратить время моей жизни на изучение более слабой (что бы не сказать больше) платформы. Разумеется, как профессионал, я с этим справлюсь, но, как профессионал, я также заинтересован в профессиональном росте, а не деградации. А заказчиков вокруг много. И PHP разработчиков также достаточно. Изучить сопоставимый по уровню продукт — это всегда пожалуйста. Вширь ещё расти можно, а вот вниз — нельзя.
В общем случае более сложная и мощная платформа даёт больше возможностей, включая финансовые. Для того люди и стремятся к профессиональному росту.
Согласится ли, к примеру, лётчик-истребитель променять свою лётную машину на, скажем, кукурузник? :)
Согласится ли, к примеру, лётчик-истребитель променять свою лётную машину на, скажем, кукурузник? :)
Не поверите… :-)
Правда тут важно другое. Мои знакомые которые пересаживались на машины относились к двум категориям:
1 — вопрос здоровья. У человека был выбор или на землю, или на гражданку
2 — вопрос того что именно с этим кукурузником делать. Скажем так иногда задачи бывают настолько интересны, что люди пересаживаются на кукурузники.
Что более сложная и мощная платформа дает больше возможностей почти бесспорно (есть отсечение части задач по минимальным требованиям). Но ведь никто не говорит о полной смене платформы в профессиональной деятельности. Пост об освоении ещё одной платформы, расширении списка доступных инструментов. Нет выбора пересесть с истребителя на кукурузник, есть предложение на некоторое время забыть про истребитель (в свободное от раюоты время никто не запрещает на нем летать), освоить кукурузник, выполнить на нем одну задачу и вернуться на истребитель.
А вот что дает больше возможностей — чуть более лучшее (за счет непрерывной практики) владение истребителем, или чуть более худшее, истребителем, но и приличное кукурузником — вопрос не однозначный. Лучше иметь и молоток, и микроскоп, по-моему, чем что-то одно.
А вот что дает больше возможностей — чуть более лучшее (за счет непрерывной практики) владение истребителем, или чуть более худшее, истребителем, но и приличное кукурузником — вопрос не однозначный. Лучше иметь и молоток, и микроскоп, по-моему, чем что-то одно.
Теоретически, всё верно. Практически, многое зависит от человека. Специфика софтверной индустрии — очень быстрая динамика. Месяц-два отвлечения, ещё куда не шло. А вот полгода, уже тяжелее. Начинаешь мыслить другими категориями, все базовые фреймворки обновились на пару версий, да и вообще как-то выпадаешь…
Высокая ЗП она потому и высокая, что ты постоянно на уровне. Если ты ушёл на годик в другую сферу, то ты ещё конечно опытный профи, но побуксуешь месячишко когда вернёшься. Это значит, что проектировать сходу не сможешь, вначале нужно будет подосвежиться знаниями.
В случае автора топика, заказчик будет планомерно разбавлять ASP людей, PHP людьми, что бы они подхватили предметную область. В итоге, через годик, команда ASP парней будет в нише PHP с соответствующими этой нише зарплатами и уровнем мышления. Такова жестокая реальность быстроразвивающейся софтверной индустрии.
Высокая ЗП она потому и высокая, что ты постоянно на уровне. Если ты ушёл на годик в другую сферу, то ты ещё конечно опытный профи, но побуксуешь месячишко когда вернёшься. Это значит, что проектировать сходу не сможешь, вначале нужно будет подосвежиться знаниями.
В случае автора топика, заказчик будет планомерно разбавлять ASP людей, PHP людьми, что бы они подхватили предметную область. В итоге, через годик, команда ASP парней будет в нише PHP с соответствующими этой нише зарплатами и уровнем мышления. Такова жестокая реальность быстроразвивающейся софтверной индустрии.
Среди платформ к которым я лоялен, думаю, плохих для меня нет, потому готов менять их т.к. это даёт радость изучения чего то нового (в данном случае идеальный вариант, за счёт заказчика). Притом опытному программисту не так важно на чем писать, с большой вероятностью хороший код получится на любой платформе к которой он лоялен. Говорю это основываясь не столько на смене платформ сколько на одновременном их использовании в разных проектах.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Опрос. Готовы ли вы сменить язык программирования и платформу по предложению заказчика?