Пользователь
0,0
рейтинг
16 апреля 2012 в 23:05

Разработка → PHP — отстой! Но я люблю его! перевод

Буквально вчера я прочёл весьма занимательный пост PHP: a fractal of bad design (русский вариант на хабреприм. перев.). Этот неоднозначный и провокационный топик широко обсуждается всем PHP-сообществом. Честно говоря, там есть как действительно хорошие позиции и замечания, так и откровенные ошибки, не позволяющие увидеть всю картину в целом.


Небольшие ошибки


В посте достаточно много ошибок и вообще автор путает божий дар с яичницей. Позвольте мне выделить главные:
  • Нет отладчика – в PHP есть xdebug, который великолепно работает как интерактивный отладчик.
  • Нет поддержки тредов – это так, но он отмечает это за недостаток, когда я нахожу это положительным; потому как жизненный цикл приложения начинается с запроса (я раскрою этот тезис чуть более подробно)
  • == бесполезен – да нет, он весьма полезен, если использовать его правильным образом. Да, я соглашусь, что использую его всё меньше и меньше, но когда он вам нужен – он полезен…
  • Проблемы видимости с глобальными переменными – он находит в этом нечто диковинное. Честно говоря, по мне это одна из тех вещей, в которых PHP превосходит практически все другие языки. Если вы не видите global $var внутри какого-то блока, вы знаете, что переменная локальная. Поэтому просто посмотрев на декларацию функции, вы немедленно можете оценить, какое должно быть внешнее окружение без отслеживания каждой отдельной переменной (и не просите вашу IDE сделать это для вас).
  • Константы определяются с помощью вызова функции – это так, но автор забывает о синтаксисе `const FOO = «bar»;`, который является валидным и не является вызовом функции.
  • Статические переменные внутри методов экземпляра глобальны – это правда, потому что это именно то, для чего они предназначены. В Python мы бы использовали `obj.__class__.varname`…
  • PHP привязан к Apache – это откровенная чушь: существует куча приложений, которым Apache не нужен. Просто Apache на большинстве платформ по умолчанию конфигурируется с mod_php. Но по мне, настройка nginx+FastCGI гораздо легче, нежели настройка mod_php под Apache.
  • Нет простого способа «отделить» PHP-приложение и его зависимости от остальной системы – это неправда, так как есть suphp и FastCGI; это ведь действительно просто запустить несколько различных инстансов PHP, работающих на разных версиях. Да, в самом деле, с mod_php вам придётся разделять инстансы Apache, но есть и другие способы организации сервера, нежели mod_php, так что это не совсем честно – списывать на PHP ограничения Apache.
  • Секция особенностей – вот с этого момента я потерялся. Вплоть до этого он говорил об особенностях языка (и с большинством я бы согласился). Но с этого места начинается разговор о библиотеках и фреймворках. Да, в PHP нет системы шаблонов. Но разве есть она в Python или Ruby? В Django и Ruby On Rails есть, а как же тогда Zend и Symfony? В PHP нет XSS-фильтра, но ведь их нет и в Python и Ruby, лишь в фреймворках. PHP не поддерживает роутинг, но разве Python и Ruby поддерживают? Зато есть dev server. И поддержка интерактивного отладчика (xdebug). И такая же ерунда с вопросами безопасности.

В-общем, из всего большого поста, пунктов, которые действительно могут вызвать недовольство, мало. Там написано весьма много, но с таким напыщенным стилем это не очень приятно чтиво.

Мой взгляд



На самом деле с большинством написанного я соглашусь. PHP – противоречив. Многословен. Там действительно есть примеры неадекватного поведения. У него есть много проблем. Порой он уродлив. Иногда он неуклюж в обиходе. Многое оставляет желать лучшего.

Но в то же время он необычайно мощный. Легко и просто можно написать работающее приложение. Действительно легко создать масштабный проект. Несложно его расширять. И что по-настоящему просто – это получить помощь (в Интернете вас поддержит одно из крупнейших и самых активных программистских сообществ).

Однако, есть одна вещь, которая не добавляет языку популярности: возможность использования не-разработчиками. Просто взгляните вокруг на опен-сорсные веб-проекты и вы поймёте, что PHP – это победа. Я имею в виду весь этот рынок CMS, на котором к PHP конкуренты просто не подберутся и на пушечный выстрел (Wordpress, Joomla!, Drupal, vBulletin, MODx, TYPO и т. д.). Посмотрите на любой сетевой рынок услуг, и PHP будет там доминировать (или просто иметь сильнейшее влияние). Всё дело в том, что развернуть PHP-сайт до смешного просто. Так просто, что даже не-разработчики могут это сделать.

Как говорит Brandon Savage: It's About The Customer (А кто клиент?). И это – тот большой кусок пирога, который был упущен в оригинальном посте. В самом деле, с точки зрения разработчика в PHP чего-то не хватает. Но с каких пор разработчик определяет что успешно? Если бы разработчик это определял, то софт типа Wordpress, jQuery и Jenkins/Hudson не достигли бы такого успеха (ибо их исходные коды под характерным вопросом качества). Но они достигли, потому что решают проблему и решают её хорошо.

Всё дело в том что у PHP есть много преимуществ над другими языками. Вот лишь то, что всплыло у меня в голове:
  • HTTP – это объект первого класса. Никакие другие популярные языки этого не предоставляют. Ни Python, ни Ruby, ни C, ни JavaScript. В PHP встроена поддержка HTTP на низком уровне. Вы можете поспорить, что это не так оптимально, но это первый класс. Вам не надо никаких библиотек или фреймворков, чтобы говорить на HTTP.
  • SAPI — это объект первого класса (Server API, mod_php vs CGI vs FastCGI, etc). Это означает то, что PHP разрабатывался так, чтобы быть за плечами более сильного сервера. Также это означает то что передача кода от CLI к API сервера – тривиальна (надо просто посмотреть, как получаются переменны запроса). Нет никакой необходимости использовать библиотеки или фреймоворки, чтобы взаимодействовать с сервером. WSGI в Python в принципе не зря ест свой хлеб, но по-прежнему вам надо подключить библиотеку для общения с сервером. Это делает PHP весьма простым для построения фундамента web-приложений.
  • Цикл жизни приложения от запроса к запросу. В оригинальном посте это было отмечено как негативный аспект. Каждый новый запрос запускает заново PHP (ну, не весь PHP, а ваше PHP приложение) Это хорошая штука, так как (цитата по Rasmus Lerdorf, создатель PHP в интервью) «The shared-nothing architecture of PHP… leads to infinite horizontal scalability in the language itself.» (дословно: «Не позволяющая ничего шарить архитектура PHP … ведёт к бесконечной горизонтальной масштабируемости языка как такового»).
  • Просто громадная база пользователей. Да, и у других языков есть куча последователей, но никто и близко не подбирается к PHP. И лично я думаю, что это – наиболее значимый аспект из всех. Это ковчег, полный знаний о том, как расширить PHP и как решить почти любую проблему. Если вы знаете, что вы делаете, то вы всё, что надо, найдёте.


Этих 4 причин для меня достаточно, чтобы считать PHP моим основным языком. Я знаю и активно применяю Python и серверный JS (node.js в настоящее время), да и знаком ещё с несколькими языками. Но я по прежнему придерживаюсь и буду придерживаться PHP для своих основных проектов, потому что хотя он и не безупречен, он работает…

А ваши мысли?
Перевод: Anthony Ferrara
Алексей Соловьёв @mrxak
карма
26,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (605)

  • –28
    PHP — хороший язык. Интеграция в html у него лучше чем у любого другого языка (кроме javasript и vb). Правда относится к нему хорошо я стал только после того, как перестал его использовать для серьезных проектов. Со временем остаются только хорошие воспоминания.
    • +52
      >>Интеграция в html

      что?
      • +18
        Как непрограмист могу сказать что если человек и выразился неправильно, по сути он прав — как включить php-код в html-страничку знают все, а как запустить на своём хостинге скрипты написанные на Ruby, Питоне, Перле и пр. — далеко не все. Это я перечислил популярные интрпертируемые языки, а ведь кто-то и на С++ веб-приложения пишет.
        Если что не так написал, просьба пояснить, а не минусовать, goto строка 1
        • –4
          Пхп просто самый распространенный. «Интеграция в html», если можно так выразиться, у пхп как раз дохлая и заключается в банальном выводе переменных через echo. Я бы не назвал это интеграцией.
          Так везде можно.
          Ну и для, например, питона есть много разных шаблонизаторов.
          Равно как и для пхп есть, к примеру, smarty.
          • +16
            У слову пхп сам по себе шаблонизатор.

            Сейчас <?=date('Y')?> год
            


            Мне кажется именно это имелось ввиду под словами «Интеграция в html у него лучше»
            • 0
              У меня двойственное отнощение к short tags. C одной стороны, это удобно. С другой, не рекомендуется к применению, особенно если не известно заранее, где может развертываться приложение.
              • +5
                С выходом 5.4 можно писать <?= $var ?> без включенной директивы short_open_tags
              • +19
                Да ладно, везде где пишут о short tags, там же пишут о том, что мол лучше им не пользоваться, потому что «не известно заранее, где может развертываться приложение». Как по мне, то обращать внимание на такую вещь не нужно (если, конечно, вы не разрабатываете wordpress или еще что-то суперюзерфрендли). Вы ведь не будете думать что вот мол, не буду писать на utf-8, мало ли у кого-то сервак на cp1251 заточен. Или, допустим, не буду включать вот этот гем в свой rails проект, потому что он под винду не компилится (да и вообще может у юзера gcc в линуксе отсутствует).

                Согласитесь же, что <?= "" ?> куда более сексуально, чем <?php echo "" ?>
                :)
                • +1
                  Хотя конечно с кодировкой сравнение некорректное.
                • 0
                  Соглашусь, но уже приучил себя к полному варианту)
            • +3
              о, а подсветочка-то все-таки хромает :)
            • 0
              Это же просто сокращенная форма записи <?php echo ?>… От того что оно на 7 символов короче пхп не становится сразу круто интегрированным в хтмл)
              Как по мне так наличие в питоне встроенного полноценного шаблонизатора обеспечивает куда лучшую интеграцию.
              • +2
                Да я вообще никак не хотел акцентироваться на сокращенной записи:) Да хоть на 20 длиннее.

                Смысл в другом — пхп-скрипт это шаблон. Весь текст (а обычно это хтмл) из него напрямую перенаправляется браузеру, пока не встретятся тэги <?php, <?.. То что внутри этих тэгов — это логика шаблона, код оттуда интерпретируется, он также может возвращать данные, которые будут отправлены браузеру, а может и не возвращать.

                Мне кажется, что это можно назвать «круто интегрированным в хтмл» :)

                Про питон — я не писал скрипты для вэба на голом питоне (и других языках), поэтому про интегрированность в хтмл их, я сказать ничего не могу. Но сдается мне, что там все несколько иначе:)
                • 0
                  Питон без использования шаблонизаторов, в том числе и встроенных — это будет просто .py файлик который через print выводит весь хтмл код целиком.

                  Но смысла так делать совсем нету, для питона есть вагон разных шаблонизаторов на любой вкус и они очень удобные.
                  Собственно для пхп шаблонизаторы тоже есть, но при них я ничего такого хорошего сказать не могу, тот же Smarty мне как то совсем не понравился.
                  • 0
                    Smarty — не айс. Смотрите «Twig»
                    • 0
                      По иронии, Twig — слизали с питоновского django шаблонизатора 1 к 1 =)
                      • +1
                        Ну вот и славно. Значит в обоих языках есть отличные шаблонизаторы!
                      • 0
                        К чему ирония, если об этом в README написано?
                        • 0
                          Ну тут беседа идёт python vs php в каком то смысле и выяснилось что лучший шаблонизатор тот который сделали питонисты.
        • +2
          А зачем в программировании такие люди? Которые кроме на работу с echo ни на что не способны?
          • +1
            Спросите у людей, которые платят им деньги. Есть спрос — предложение появится.
            • –1
              Спрос на низкокачественных программистов? Нет, ну ок, хорошо что эту нишу заняло php.
              • +1
                Спрос на дешевых. И с этой ниши PHP вытесняют, но пока массового перелома в сознании заказчиков не произошло.
                • –1
                  Да и слава богу, пусть дешевые php программисты, не понимающие вообще ничего, не использующие ar или шаблонизатор дальше клепают сайты визитки. По сути все идет как надо :)
                  • +1
                    А как быть дешевым, использующим AR (хотя DM+UoW больше нравится) и Smarty/Twig?
                    • 0
                      К таким я могу относится как к людям, вы, собственно говоря — тоже.
                  • +8
                    Ruby — пузырь. Ставки по сравнению с PHP аналогичного уровня x2, а то и X3 непонятно почему, если на нем и писать легче и все такое.

                    Потому многие на него и переходят, как только уровень позволит. А это, обычно, происходит раньше, чем человек осилил нормальные фреймворки на php и полноценно использует хотя бы PHP 5.3.

                    Вот и получается, основными аргументами в пользу Ruby приводят фичи Rails, типа «смотрите тут можно запросы не писать, а так по модному метод класса вызвать». Все это, даже то, чего не было до Rails, уже давно перетащили в PHP-фреймворки. Да, шок: и роуты и орм реализованы и на других языках.

                    На мой взляд, грамотные аргументы в пользу Руби должны выглядеть примерно так:
                    — наверное, самый большой набор инструментов для работы с ООП, который даже вводит ряд новых приемов по организации структуры классов
                    — согласованный и лаконичный синтаксис
                    — многопоточность

                    Но никак не «на PHP одни быдлокодеры».
                    • 0
                      Ну в целом я с вами согласен. Не очень ясно про рейты и как вы сранивали кондидатов, но я не буду уточнять.
                    • –4
                      Пузырь?! Чего вдруг пузырь? Вот скажите мне: хоть 1 из 10 пхп-программистов пишет тесты? Вряд ли больше. Ну и раз речь зашла о пхп-фрейворках, то почему-то многие усиленно стараются быть похожи/копируют рельсы. С чего бы это?

                      Да ну и сам руби хорош хотя бы за вот такие конструкции: (1..10).inject(:+)
                      И кучи чего ещё.
                      • 0
                        С того, что рельсы это реально хорошая идея, наверное?
                        • 0
                          Во-первых, рельсы не есть руби
                          Во-вторых, рельсы действительно хорошая идея (-:

                          Иначе бы её не копировали бы.
                          • +2
                            Ну вот мне нравится идея рельсов, но не нравится идея руби. Мне С-подобный синтаксис нравится. Расстрелять?
                            • –1
                              Ну расстреливать никого не надо в любом случае (-:
                            • –1
                              Используйте аналоги. (на php)
                              • 0
                                Так я и использую. Python+webpy ещё тоже ничего для более фундаментальных вещей, как по мне.
                      • +2
                        Вот почему ruby разработчик начального/среднего уровня стоит на рынке дороже php того же уровня? Если порог вхождения ниже, код пишется проще и быстрее, фреймворки гениальны и т. п.? Работать выходит проще, а платят больше?
                        • 0
                          Отвечу словами Matz-а: Я не знаю ни одного безработного ruby-программиста (-:
                          А если есть много безработных пхп-программистов, то зачем платить больше?!
                          • +5
                            Мне вот всё равно писать на незнакомом php-фреймворке или на RoR/Django. Но для RoR я недоквалифицирован, а для PHP перквалифицирован на уровень ЗП ~800-1000 у.е. (Питер). На RoR требуют BDD, а на PHP не хотят слышать о TDD, например. На RoR требуют git (да ещё аккаунт на gihub зачем-то), а я к Mercurial привык, а работодатели так вообще VCS не используют.

                            Могу я считать себя безработным ruby-программистом? :)
                            • +1
                              Как говорят у нас в Одессе, запретить я Вам этого не могу (-:

                              Лично я просто не приемлю крайностей: пхп-руби-питон или там виндоус-линукс и т.п.
                              В web-программировании уж так заведено, что знать просто один язык невозможно, как мне видится.
                            • +1
                              Вне спора о качествах того или иного решения (было время, я коммитил в PHP и активно поддерживал его документацию), я отвечу на оба вопроса.

                              Платят больше потому, что рубистов – меньше. А меньше их потому что порог вхождения в рельсы больше. Я не раз видел округлившиеся глаза человека, которому рассказывали про ассеты, кофи, сасс и хамл. Хотя ничего, привыкают. Другая проблема с порогом вхождения – другая религия, касающаяся циклов разработки. В мире руби совсем иной подход к BC. Это подстегивает и заставляет быть более социальным и быстрым. И это развивает. Либо люди уходят. Уровень ruby-разработчиков по этой причине растет быстрее, либо скатывается в 0. Сообщество заставляет их учиться, а не дает возможность, как в случае с PHP.

                              Аккаунт на гитхабе нужен по описанной выше причине – это способ взаимодействия с этим сообществом. Большая часть рубистов, с которой мне доводилось работать, хоть в каком-нибудь опен-сорсе да поучавствовали. Если не свое корыто, так чужое подлатали. Гитхаб – история взаимодействия с сообществом, которая для рубистов ОЧЕНЬ важна. Это – показатель перспективности и живости. А перспективность, ивость, другими словами потенциал, – самая важная характеристика разработчика. Выучить можно любой язык.

                              Я никаким образом не объясняю этим, что руби – лучше. Мое _личное_ мнение на этот вопрос следующее: PHP должен быть вытеснен Groovy или чем-то подобным. Потому что он усиленно растет в Яву, а Ява форкается в то, что похоже на PHP. Факт в том, что вторых младенцев карма и архитектура в разы лучше.
                              • 0
                                Попытки использовать хамл или *сс я делаю и в пхп, но получается только в тех, которые под контролем vcs (обычно mercurial) и capistrano. Но к этим приложениям особых требований нет, я их сам формирую и могу себя убедить в их полезности. Заказчиков не могу. Ну не понимают они, что сайт им я сделаю за 100 рублей в час, а для малейшего изменения вёрстки придётся искать верстальщика, который возьмёт 200…
                                • 0
                                  Времени правки займут меньше. Более дорогие специалисты, использующие новые технологии, работают быстрее. В этом их смысл. Если это не так, либо специалисты плохие, либо технологиям грош-цена, либо это какой-то специфический случай.

                                  Это, правда, не отменяет проблемы необходимости минимального распространения. Конкретно у хамла с этим большие проблемы.
                                  • 0
                                    Займёт правка час или два не суть для моих заказчиков. Их интересует конечная цена. Мне тоже по сути всё равно, даже интересней когда два часа займёт (за те же деньги).
                                    • 0
                                      Меньше денег – меньше ставка. Разве не логично?

                                      P.S. мои сообщения личные пришли?
                        • –1
                          Даладно? От рубиста начального уровня требуют понимания ООП и метапрограммирования. От php-иста начального уровня понимания echo?
                          • 0
                            Формально обычно требования одни в вакансиях (кроме нюансов), но от рубистов уже на собеседованиях выясняется, что знание инфраструктуры (ака экосистемы) подразумевается, а не только языка/фреймворка. Спросят невзначай «какие гемы для авторизации лучше использовать?» и ответ «я гемы не использую, работаю с исходниками с гитхаба» не устраивает.
                        • 0
                          Расскажу историю. Есть у меня знакомый, у него небольшая веб-студия. Распиарил я ему рельсы, написал для него сайт студии небольшой за пиво (для друга же :). Рельсы ему понравились, мол быстро и т.д. После этого он общался с начальником отдела разработки одного крупного новосибирского сайта (они там на php пишут) и спросил: «А как с руби/рельсами у вас дела обстоят»? Он ему ответил, что руби вообще какой-то непонятный язык, да и разработчики на RoR хотят больше денег, чем php'шники. Вот так :)

                          Сам на рельсах пишу, в Новосибе вакансий вообще нету (или я где-то не там ищу). Поэтому приходится с зарубежниками работать. И тут возникает некая конкуренция: за рубежом платят больше, чем в среднем по России. Значит, если в России работать, то хочется зарплату не ниже. Возможно еще и поэтому многие рельсовики требуют зарплату больше.
                      • +7
                        Пузырь, потому, что язык распиарили, а специалистов под него недостаточно.

                        На Ruby, тоже, хватает некомпетентных программистов. Нет, конечно, новичков в программировании относительно мало, плюс все сразу с Rails начинают, а не с устаревших говно-CMS, где файлы по 2к строк без единой фукнции, не говоря уже о классах. Еще там сразу git, тесты и другие строгости.
                        Но видел уже разное, хотя опыт и минимальный.

                        Rails хороший фреймворк, кто спорит? Я о том и говорю, что на PHP есть фреймворки со скопированной идеологией, есть более строгие с хорошо проработанным ООП, есть упрощенные, любой на выбор. И я говорю о качественные MVC-фреймворках с ORM и аналогом роутов.

                        Если отбросить нюансы, что как язык Ruby лучше PHP, глупо это не признавать. Но, на мой взгляд, уже не настолько, что бы перевешивать плюсы инфраструктуры PHP, которые только укрепились.
                        • 0
                          Да никто ничего не пиарит, я особенно и не замечаю (-:

                          Закрепилась не инфраструктура, а стереотипы. 9 из 10 студий предложат сайт на пхп. Потому что другого в наличии нет, а на 500$ всегда можно взять студента.

                          И не высок/низок порог вхождения в руби/пхп, а порог развёртывания приложения и количество недорогих хостеров. Вот большинство и идёт по пути наименьшего сопротивления: побыстрее нагенерить всякой лабуды и запихнуть в биржи ссылок.
                          • 0
                            А студент, знающий ruby, за 500 уже не пойдёт?
                            • 0
                              Согласен, с числом погорячился (-:
                          • +2
                            Владельцы программистских контор пиарят RoR, что бы обосновать завышенные зарплаты (и свои проценты) своим заказчикам.

                            В общем, для меня это выражается в том, что уже не один PM мне говорил, что на RoR разработка в разы быстрее, код не получится плохим и его сможет поддерживать любой программист, итд итп. На вопросы как и почему, ничего внятного не отвечают, в лучшем случае что-то очень общее про гемы и ORM скажут.

                            Я готов поверить, что лет так 7 назад, когда Rails только набирал обороты он был единственным веб-фреймворком современного типа и действительно давал существенный прирост в разработке. Но даже если так, то информация уже сильно устарела.

                            Да многие, идут по пути наименьшего сопротивления и в данном случае, на мой взгляд, это оправдано.
                            • 0
                              Ну я не знаком с владельцами, которые пишут только на рельсах. Чаще скорее наоборот: только на пхп.

                              Видите ли, в чём ещё дело… в мире руби рельсы — это 98% от всех используемых фреймворков. есть другие, но они не стоят даже рядом. Поэтому рельсы — это как стандарт. Практически любой рубист откроет проект на рельсах и легко разберётся.

                              В пхп слишком велико разнообразие фреймворков… Я не говорю, что они плохие, просто они разные. И различие между Zend, Yii или там CI достаточно велико. Это не хорошо и не плохо, это просто факт. И при переключении с одного фреймворка на другой не знакомый будет некоторая задержка.
                      • 0
                        Имхо, вообще сомнительно, что сильно больше чем 1 из 10 программистов пишет тесты… И не факт, что это плохо…
                    • –2
                      Потому многие на него и переходят, как только уровень позволит. А это, обычно, происходит раньше, чем человек осилил нормальные фреймворки на php и полноценно использует хотя бы PHP 5.3.

                      любой фреймворк — это жертва производительностью в угоду удобству и фичам. чем больше фич — тем более это заметно на производительности.

                      и если для того, чтобы нормально программировать на языке X нужны фреймворки — это плохой язык.
                      • +1
                        То есть Вы сейчас говорите, что Python и Ruby для веба существенно более ужасны, чем PHP, я правильно понял? :) Чтобы нормально программировать на них для веба однозначно нужны фреймворки. Без вариантов.
                        • 0
                          Для PHP не нужны, он сам микрофреймворк по сути. Важность этого факта уменьшается, но до ноля ещё далеко.
                        • 0
                          что вы подразумеваете «для веба»?

                          вот серверную часть простенького чатика на php сколько времени вы будете писать? чатик выбран как частный случай ситуации, когда у вас, допустим, 8к клиентов и им всем надо разослать идентичные данные(это может быть и сервис с курсами валют/пробки итп).
                          • 0
                            А есть (с точки зрения написания) большая разница писать на php, python или C чатик (если не пользоваться многопоточностью)? Так же слушаем сокет, также его обрабатываем.
                            • 0
                              >Так же слушаем сокет, также его обрабатываем.

                              отличное описание! 99% протоколов с логикой запрос/ответ попадают под это определение.
                              не стесняйтесь, раскройте мысль, потаённую в «обрабатываем».
                              давайте даже упростим: события(и сообщения) генерирует само приложение.
                              • 0
                                Ну я же не знаю протокол чатика :) Но суть одна и та же — биндинги к сокетным функциям ОС.

                                Про «упростим» немного не понял. В каком виде получаем сообщения? Нужна ли чатику работа с тормозными функциями типа работы с БД или ФС? Блокировки ресурсов и т. п.?

                                Кстати, простенький чатик делается вообще через авторефреш страницы и тут уже совсем без разницы на чём его делать. PHP вон пишут выдерживает 800 rps (правда железо не описано).
                                • 0
                                  >Про «упростим» немного не понял. В каком виде получаем сообщения?

                                  допустим, раз в секунду рассылать всем подключенным клиентам json вида:
                                  {«time»:«unix_timestamp», «connected»: число_клиентов_онлайн }

                                  • 0
                                    Вариантов много, от написания своего веб-сервера до авторефреша страницы браузере, а страницу через apache+cgi отдавать. Количество клиентов онлайн можно хранить в локальном контексте сервера, а можно на удаленном сервере и изменять/получать через SOAP.

                                    Принципиальной разницы на чём это писать не вижу, разве что в некоторых языках это может оказаться в стандартной либе, а в некоторых сторонние придётся подключать.

                                    Другое дело, если по каким-то причинам использовать cgi не следует :)
                                    • 0
                                      >Количество клиентов онлайн можно хранить в локальном контексте сервера, а можно на удаленном сервере и изменять/получать через SOAP.

                                      а можно просто в мемкеше держать и через incr/decr менять :)))

                                      >Другое дело, если по каким-то причинам использовать cgi не следует :)

                                      например по той, что изначально упомянуто 8к клиентов онлайн, т.е. у вас 8к файловых дескрипторов на которых вы ждёте какие-то события.

                                      если же рефрешить страничку, допустим, 1 раз в секунду — это 8к rps, на котором cgi так же умрёт.

                                      если же взять не json, а google protobuf, то можно хорошо сэкономить на трафике. Вот только весь профит бинарного протокола будет сведён на ноль http-заголовками в варианте с рефрешем.
                          • +2
                            А Вы отдаёте себе отчёт, что абсолютно бОльшая часть веба это не чатики и их более общие случаи типа курсов валют и пробок, а CMS, форумы и тому подобные вещи, причём для многих из которых 8К это их месячная посещаемость?
                            • 0
                              ну тут упоминали facebook и проекты с высокой посещаемостью.
                              и вроде как на дворе мир web2.0 с реалтаймом.
                              websockets есть уже почти везде, на подходе webRTC.

                              а странички с посещаемостью полчеловека в минуту писать можно на чём угодно.
                              • +2
                                Да тут уже много чего упоминали :)

                                > а странички с посещаемостью полчеловека в минуту писать можно на чём угодно.

                                О чём и речь, коллега! А таких страничек нужно много-много. А как писать фейсбук и прочие проекты с высокой посещаемостью это вообще не вопрос языка ни разу. И не фреймворка. Даже автор оригинальной статьи про это пишет.
                                • 0
                                  Автор исходной статьи пишет, что при достаточно высокой квалификации грабельки, заботливо положенные авторами языка можно объезжать.

                                  В facebook было написано много кода на php и когда возникли сложности с производительностью, как я понимаю, дешевле оказалось изобрести hiphop, нежели переписывать и переучивать имеющийся штат разработчиков.

                                  Всё, опять же, сводится к правильному инструменту под задачу. Беда php в том, что уж очень много задач, для которых есть инструменты лучше.

                                  Например, много ли вы знаете серверов трансляций на php?

                                  на эрланге есть erlyvideo, на python — flumotion (да и я писал свой сервер для онлайн трансляции — 19к онлайн-клиентов на тестах было. написано на python).
                                  • 0
                                    Но эти задачи не самые распространенные (в количестве постановок). И я не думаю, что будет хорошей идеей (для меня) говорить работодателю, что, скажем, ему нужно нанимать python-программиста вместо меня. Да покупать (v)DS вместо шареда, да ещё грамотного админа в комплекте. Действительно, мне «дешевле» «изобрести» hiphop.
                                  • +1
                                    > Беда php в том, что уж очень много задач, для которых есть инструменты лучше.

                                    Это не так. Переход на питон и джангу для среднего пхп-разработчика это вообще не проблема, как почему-то многие пытаются представить. А если этот переход ещё и ростом дохода подкрепить, то исход будет массовый :) Питон очень простой язык, а джанго работает по сути так же, как любой другой MVC фреймворк.

                                    Вот буквально несколько часов назад консультировал одного разработчика на питоне (он на PHP не программировал никогда и Питон для него фактически первый язык, Дельфи считать не будем) по вопросам того, как сделать одну хитрую штуку, связанную с FastCGI. И знаете что, он её пытался сам написать 2 дня, я накидал её за 10 минут с помощью Гугла и мануалов, при том, что я не имею опыта в Python практически никакого. Но я начинал ещё с Перла и я прекрасно понимаю, как эта вся веб-кухня работает в целом. Вот это гораздо важнее, а не особенности оператора ===. Особенностей везде хватает. Тот же руби или перл это же одна большая особенность по большому счёту :) И ничего — многим нравится. И это нормально.
                                    • 0
                                      Переход на питон и джангу для среднего пхп-разработчика это вообще не проблема, как почему-то многие пытаются представить.

                                      Кстати, да, согласен. И даже без роста доходов с радостью бы перешёл. Перейти с ZF или Symfony2 на RoR или Django не сильно сложнее чем на Yii или CakePHP. MVC он в Африке MVC, а писать всё же приятней. Про тех, кто писал только под WordPress или Joomla -отдельный разговор, их средними php-разработчиками язык не поворачивается называть.
                              • 0
                                «Реалтайм» (без хайлоада) тоже на чём угодно можно писать (серверную часть), тормозить будут, имхо, прежде всего СУБД/ФС. Другое дело, что межзапросное кэширование на PHP стандартными средствами не очень тривиально. То же чтение настроек приложения из конфига на каждый запрос и вообще его явная инициализация явно избыточны, но, увы, многие приложения не рассчитаны на работу в условиях когда после завершения работы не происходит полная реинициализация глобального контекста. Но, имхо, это проблема больше разработчиков, а не языка. На любом языке я тоже напишу приложение, которое работает только в CGI режиме.
                                • 0
                                  смотря что за субд. если речь о рсубд — тут да. если же мы говорим о mongo или хранилищах вроде redis/tarantool — то это весьма сложно.

                                  >То же чтение настроек приложения из конфига на каждый запрос и вообще его явная инициализация явно избыточны

                                  для этого надо настройки хранить в mongo, сам конфиг кешировать в рамках процесса.

                                  >Но, имхо, это проблема больше разработчиков, а не языка. На любом языке я тоже напишу приложение, которое работает только в CGI режиме.

                                  а на любом языке вы сделаете «горячую» замену кода в работающем приложении?

                                  на python я такую штуку сделал.
                                  • 0
                                    Я и на монго напишу тормозяще :) Ну нет, вроде быстродействующих средств осуществлять композицию. Агрегацию есть, а композицию нет. Как не крути, но получить сравнимое время выборки, скажем, по комментам на хабре и по топику, и по автору получится только если оба будут тормозить. Или дублировать информацию для разных срезов.

                                    Над остальными задачами не думал.
                                  • 0
                                    На php горячую замену кода делали люди года 3-4 назад. В чем собственно вопрос?

                                    Но она нужна лишь для тех «костыльных» приложений на других языках, которые не работают в изначальной идеологии php — запустился, быстро отработал, умер.
                                    • 0
                                      >запустился, быстро отработал, умер.

                                      прощай highload.
                                      • 0
                                        Разве? Вы много хайлоадов написали? :)
    • 0
      Очевидно, все твои проекты «СЕРЬЕЗНЕЕ» этих: facebook, контакт, youtube, wikipedia,…?
    • 0
      Очевидно, все Твои новые проекты «серьезнее» этих: fracebook, youtube, wikipedia, контакт?
  • +24
    > Я имею в виду весь этот рынок CMS, на котором к PHP конкуренты просто не подберутся и на пушечный выстрел (Wordpress, Joomla!, Drupal, vBulletin, MODx, TYPO и т. д.).

    И слава богам. Последнее, что я хотел бы увидеть в своей жизни это массово-разрабатываемые cms-ки на rails.
    • –2
      Согласен с вами :) Хорошо, что комьюнити рельс пока не страдает от перенасыщения «хреновых» разработчиков.
    • +5
      Вы правы, но все же, какие на python/ruby есть хорошие аналоги Wordpress/Magento/MODx/etc., хотя бы по одной на область применения? Иначе получается не язык, а игрушка для высоких нагрузок (пишем с нуля) или просто поиграться (пишем с нуля). Я хотя и пхп-ник, но пишу на Синатре (очень уж мне нравится) и изредка на RoR. Но без нормальной работы, например, в финансовой сфере, продажи, магазины, язык так и остается «для избранных».
      • –1
        spreecommerce.com/
        В нее недавно влили достаточно денег, чтобы она стала очень крутой :) Я уже молчу о том, что система расширений рвет в жопу магенту.
      • 0
        Я смутно понимаю необходимость CMS на рельсах. Для более-менее нестандартного сайта все равно придется кастомизировать CMS, добавлять какие-то свои модули и т.д. За аналогичное время безо всяких CMS собирается кастомный сайт со сторонними гемами. Нужен и-нет магаз – бери spree, нужны блоги/новости – есть много готовых решений, хотя и свое пишется за 5 минут. Нужна админка – activeadmin, нужно что-то еще – поищи нужный гем, с вероятностью 99% что-то готовое уже есть.

        + совсем не понял про «для избранных»: куча вакансий, куча проектов. Конечно, меньше, чем на php, но достаточно :)
        • 0
          Ниша one-click-cms'очек давно забита php и это нормально, другой вопрос, что при реквест кастомной фичи от заказчика начинается ад в глаза php программистов. Я собственно говоря имел опыт, когда рельсовиков пригласили взамен php, потому что поддерживать drupal ни у кого уже не было сил :)
        • 0
          Многие нестандартные сайты начинаются со стандартных, в которых сразу нужны магазин, блог, новости и админка (в терминах предметной области, а не структуры БД). Плюс возможность устанавливать сторонние модули из этой админки «в один клик», без программирования и консоли. То есть CMS это продукт для веб-мастера, а то и вообще менеджера, а не программиста. Самое главное в нём, пожалуй, как раз админка.
          • 0
            Хм, ну поставить CMS и начать работать сразу, не будучи программистом – ладно, довод в пользу CMS. Только вот решение это не оч дальновидное с точки зрения бизнеса: бизнес так или иначе вырастет, потребуется что-то нестандартное и придется звать программиста, который будет все это дело кастомизировать. Но кастомизировать он будет уже что-то готовое. И не факт, что выбранное правильно (может менеджер плохую CMS выбрал, он ведь может такое :)

            И вот тут возникает проблема: кастомизировать уже готовое или написать заново. Владелец бизнеса очень неохотно (судя по моему опыту) пойдет на переписывание, т.к. с его точки зрения кастомизировать проще. Но адекватный человек за такую неблагодарную работу захочет довольно много денег, чтобы компенсировать свои предстоящие душевные травмы. Владелец бизнеса столько платить, возможно, не захочет и наймет кого-то другого с более низкой квалификацией за 100р. Замкнутый круг.

            Мораль такова: каждый должен делать свое дело. Программист – разрабатывает, веб-мастер поддерживает, менеджет штаны просиживает.
            • +2
              Для бизнеса зачастую определяющим является минимизация стартовых затрат денег и времени. Грубо говоря, побыстрее и подешевле запустить. И однозначно сказать, что это недальновидно сложно. Потратить час/день/неделю/месяц работы веб-мастера или день/неделю/месяц/год работы программиста ради сайта, на который неизвестно зайдёт ли вообще кто-то нибудь кроме директора? Очень многие постараются минимизировать риски потери денег. И «скупой платит дважды» тут не совсем корректно употреблять.

              А вот если сайт, запущенный за час, уже начал приносить деньги, то тут уже другие критерии должны работать, да и заплатить хорошо хоть за квалифицированную переделку с ноля, хоть за квалифицированную кастомизацию можно себе позволить, не трогая другие статьи доходов, не изымая денег из оборотных капиталов, а на «самообеспечении».

  • +10
    "… потому что хотя он и не безупречен, он работает…" — самые главные слова. Соглашусь со всем. Статья «PHP: a fractal of bad design» настолько массивна, что у читателя не возникает сомнений, что что-то там может быть неправдой. Спасибо за перевод :)
    • 0
      Абсолютно же не важно на чем работать, да? ;)
      • +1
        по мне так, главное чтобы самому тебе нравилось и было удобно! :)
  • +6
    Не буду особо цепляться, НО:
    HTTP – это объект первого класса. Никакие другие популярные языки этого не предоставляют. Ни Python, ни Ruby, ни C, ни JavaScript. PHP и HTTP – одного поля ягоды. Вы можете поспорить, что это не так оптимально, но это первый класс. Вам не надо никаких библиотек или фреймворков, чтобы говорить на HTTP.
    HTTP — не объект, а протокол )))

    PHP и HTTP разного поля ягоды, ибо одно — язык программирования, а другое протокол передачи гипертекста

    Вам обязательно надо библиотеки и/или фреймворки, потому что иначе вы напишете ужаснейший велосипед на PHP в котором будет куча дыр. Да и если вы будете писать на голом PHP работу вы вряд ли найдёте приемлимую.
    • +3
      > Да и если вы будете писать на голом PHP работу вы вряд ли найдёте приемлимую.

      А вот в этом я не уверен. PHP позволяет с минимальными усилиями писать программный код любому индивиду, способному хоть как-то последовательно формулировать выполнение задач (порядок действий). На рынке труда программистов не хватает, очень не хватает. Поэтому на работу обладая даже минимальными навыками в PHP устроится легко. Зарплата, конечно, будет низкой, но зато это работа в офисе, и есть прямой путь профессионального роста.
      • –10
        >PHP позволяет с минимальными усилиями писать программный код любому индивидуинвалиду, способному хоть как-то последовательно формулировать выполнение задач (порядок действий).

        Не удержался, простите:)
        • +3
          Вы наверно не летаете на самолетах с автопилотом потому что в это время можно посадить макаку за штурвал.
      • 0
        я с вами согласен, но как бы я не любил php думаю всю жизнь на такой работе не проживешь :(
        • +1
          Почему нет если не забывать о саморазвитии? Работа в проектах с многомиллионной, а то и почти миллиардной аудиторией не может быть достаточно интересной разве?
          • 0
            интересна, стремлюсь к этому как могу, даже фейсбук доказал что на пхп можно делать огромные приложения, просто не хочу знать только один язык, их ведь так много и каждый заточен под свои задачи, думаю будет правильно использовать все что есть а не зацикливатся. в общем это только мое мнение.
            • +1
              Facebook транслирует PHP-код в С++ код и выполняется нативно.
              См. HipHop
              • +1
                Ну и что? А С++ тоже компилится и выполняется нативно. Главное, какой язык читают люди.
                • 0
                  для python есть транслятор cython.
                  интеграция с сишными/плюсовыми библиотеками делается за несколько минут.

                  не нравится встроенная реализация регекспов? ок, можно взять из libpcre/re2 или яндексовскую pire ( clubs.ya.ru/company/replies.xml?item_no=30753 )

                  хотим actor model(в erlang-style) — берем gevent + zeromq.

                  бесшовная интеграция с C++ (и наоборот).

                  Основная идея оптимизации со скриптовыми языками — это профайлинг + переписывание горячих участков на C/C++.
                  Легко ли это делать для php?
            • 0
              Зацикливаться зачастую заставляют внешние по отношению к собственно разработке условия, экономические например.
    • +1
      «Да и если вы будете писать на голом PHP работу вы вряд ли найдёте приемлимую.», но разве чистый PHP не является основой а «библиотеки и/или фреймворки» подбираются под конкретную задачу?
      • 0
        Я например некоторые библиотеки сам себе писал, так сказать под себя.
        • –2
          Например свое подобие ActiveRecord'а
          • +1
            Ну да, каждый PHP-программист должен написать СвоюСамуюЛучшуюВмире ЦМС )))
            • 0
              И что в этом плохого? Если бы это было не так, то тот же WordPress не появился бы, как и куча других популярных CMS. А так есть конкуренция, есть развитие.
              • +1
                На самом деле написание собственной ORM отлично прокачивает скил проектирования, особенно если уйти в сторону от ActiveRecord и прочитать в процессе разработки соответствующую литературу (для начала, «шаблоны корпоративных приложений», потом может и на UML потянет и т.д.).

                Безусловно, библиотеки нужны, но знать как они устроены и быть способным при необходимости написать что-то большее гораздо важнее для профессионального программиста. Кроме того, развитая способность к разработке чего то нестандартного позволит перейти на уровень выше и стать проектировщиком, с этого момента часть скучной и неинтересной работы по написанию очевидного кода (= рутины) можно переложить на тех кто в это время полностью освоил какой либо разработанный вами framework :)

                Поэтому изучение одного framework-а, который все делает за вас, считаю тупиковым, т.к. он ведет к отмиранию способности проектировать что-то большее чем набор контроллером в моделей (если это вообще можно считать проектированием). И кстати, тут на хабре где-то год назад наверное проскакивал топик/вопрос от человека который пошел по пути потребления и в итоге обнаружил, что стал не способен создать ничего нового. Найти не смог, к сожалению.

                Поэтому велосипедить надо, но в меру.
                • 0
                  Упс, промахнулся, это ответ на ироничный комментарий solver-а
                • 0
                  Создание сайтов давным-давно стало рутиной. Зачем искать что-то там, где уже ничего нет?

                  Если создание сайтов — рутина, бессмысленная и беспощадная, изучение одного-двух хороших фреймворков позволяет справляться с этой рутиной быстрее и безболезненней, оставляя время на личную жизнь и развитие в более перспективных профессиональных областях…
                  • +1
                    > Создание сайтов давным-давно стало рутиной.
                    К счастью интересные задачи все еще встречаются.

                    > более перспективных профессиональных областях…
                    Проектирование, по вашему, недостаточно перспективно?
                  • 0
                    Ну так само собой, php-программистов — миллионы, никто их не пускает в серьезные интересные проекты. Интересный проект гораздо проще получить если ты рельсовик или питонист :)
                    • 0
                      Уж слишком вы категоричны.
                      Не соглашусь с вами.

                      Знаю системы на РНР, которые работают на целую республику.
                      Питонистов и рубистов туда никто не пускает.

                      Да и, уж простите, но Фейсбук также с вами не согласен.
                      • 0
                        Вы меня не так поняли, потому что я не очень хорошо выразился. Суть в том, что найти хорошую работу среднестатистическому php программисту труднее, чем рельсовику :) Мне, по крайней мере, так кажется.

                        А на счет вашего тонкого замечания в сторону рельс — я вот сейчас работаю над проектом где мы используем Rails + EventMachine (руби аналог node.js) + websocket и прочие comet реализации.
                        • 0
                          А начинающему проще. Мне, по крайней мере, так кажется. :)

                          А для websocket использую phpdaemon сейчас. Когда возниткнут проблемы с масштабированием буду их решать, по мере поступления.
                    • +1
                      p.s. И что для вас «интересный» проект? Сборка готовых гемов?
              • +1
                WP отличная штука, слава богу, что наблюдается последнее время тренд ухода с него на более легкие и человечные решения, по крайней мере в прослойке программистов :)
                • 0
                  WP отличная штука

                  С точки зрения пользователя — бесспорно, а с точки зрения разработчика и интегратора… ну, it depends. Уж сколько говнокодерских плагинов и шаблонов (среди коммерческих в том числе) к нему, просто не пересчитать. Никогда не угадаешь, где тебя бомба замедленного действия поджидает, через которую могут весь сайт положить.
            • 0
              Мало того я ее написал и скоро представлю на обозрение, не сказал бы что она лучшая, но во всяком случае для меня она в разы проще как в написании модулей так и в обработке контента, а оно и естественно потому что сделана на собственном мини MVC фреймворке, при этом функционал не меньше чем у вордпресс + есть модуль магазина =).
          • 0
            Наверное очень красиво получилось =P
            • –5
              )))) Ну актив рекорд типа того

              $order_cart = Db_Lib::Init()
              -> select(«shop_orders_products», "*")
              -> where(array(«id_order» => $_GET['id']))
              -> query()
              -> fetch_rows();
              • +4
                Ну наверное это красиво, я на php не работаю слава богу, в рельсе было бы как-то так:

                ShopOrderProducts.find(params[:id])


                но вы продолжайте ;)
                • +1
                  И зачем вы так? =) Пошел учить рельсу )))))
                  • +1
                    Учите Ruby, рельса это второе :)
                    • +1
                      Я прост думал Ryby on Rails это и есть язык, сори за нубство
                      • +4
                        :D типичный php программист
                • +4
                  ShopOrderProducts.find(params[:id])


                  Ну на пхп тоже можно так написать:
                  ShopOrderProducts::find($params->id)
                  


                  Покажите, что стоит за вашим find.
                  • 0
                    На пхп? Вызвать метод класса? Или может это какая-то библиотека? ;)

                    Я так понимаю вам интересен оверхед от всех этих красивых абстракций? Ну так вот — он небольшой ;) Проекты с нагрузкой нормально работают.
                    • +1
                      Ну да. Что на пхп, что на руби можно написать библиотеку, которая предоставит такой синтаксис.
                      Вопрос в том, что надо сделать, чтобы можно было писать это.

                      Я не про производительность. Уверен, запрос к базе, что в пхп, что в руби выполнится с одной скоростью.
                      • 0
                        Ну если хотите использовать ActiveRecord без рельс, то можно сделать что-то подобное — snippets.aktagon.com/snippets/257-How-to-use-ActiveRecord-without-Rails, при этом надо понимать, вы из коробки будете иметь разные енвайроменты, миграции и тп.
                        • +4
                          Ну и в ПХП можно использовать какую-либо библиотеку (например, Doctrine), которая предоставляет интерфейс. Сам не использовал, т.к. сидел на Kohana, а потом ушёл из серверного программирования
                          • –2
                            Я кстате и не спорю, что в php тоже есть хорошие решения, беда в том, что вы первый человек в этом треде, который говорит об этом ;)
                            • –1
                              А зачем играть в а у меня есть то-то а у меня есть то-то, это не конструктивно.
                              • +1
                                Почему?
                                • 0
                                  потому что всем известно, что языки мощные и есть сопутствующий инструментарий. Это как сравнивать Ламборгини и Феррари вроде один уровень, а разница в мелочах.
                            • 0
                              Я кстате и не спорю, что в php тоже есть хорошие решения, беда в том, что вы первый человек в этом треде, который говорит об этом ;)

                              Ну в кое-каком роде согласен, что пхп — это фильтр, на котором отсеялось и осталось огромное количество горе-разработчиков.
                              Но надо быть и объективным тоже ;)
                              • 0
                                Я дико объективен :)
                            • 0
                              Зачем говорить об очевидных вещах?

                              Но если хочется… Кстати, а в руби запилили поддержку DataMappper, UnitOfWOrk и т. п.? Или всё так же любой проект на рельсах с БД нарушает принцип единственной ответственности? :)
                              • 0
                                У рельс один простой паттерн — ActiveRecord, сами понимаете, он отличается от UnitOfWork.
                                dm -> datamapper.org/ (http://rubydoc.info/gems/datamapper2/0.0.1/DataMapper/UnitOfWork)
                                • +1
                                  TableDataGateway ещё проще :)

                                  А этот DataMapper как-то производит впечатление, что в нём от паттерна только название.
                                  # create makes the resource immediately
                                  @post = Post.create(
                                    :title      => "My first DataMapper post",
                                    :body       => "A lot of text ...",
                                    :created_at => Time.now
                                  )
                                  
                                  # Or new gives you it back unsaved, for more operations
                                  @post = Post.new(:title => ..., ...)
                                  @post.save                           # persist the resource
                                  


                                  Как-то это у меня с ActiveRecord больше ассоциируется.
                                  • 0
                                    Это вполне возможно, вообще очень редко слышо о UnitOfWork в руби мире, не особо оно популярно.
                  • 0
                    Подозреваю, что без кодогенератора не получится. В руби, если не изменяет память, как и в JS, класс — это тоже объект, и в него можно сколько угодно добавлять методы. А вот в PHP такое не прокатит.
                    • 0
                      Подобное можно сделать через магические методы и callback-и
                      • +1
                        autoload решает
                    • 0
                      class ShopOrderProductsTable extends AbstractTable {
                        protected $tableName = 'shop_orders_products';
                      
                        public function findByOrderId ($id) {
                          return $this->find(['order_id' => $id]);
                      }
                      


                      Как-то так можно обходиться без кодогенерации. Зачем добавлять методы динамически, если структура БД известна на этапе «компиляции»?
                      • 0
                        Я так понимаю, тут спорят об active record. А там не принято создавать отдельный класс на entity и отдельный — на таблицу. Там сам entity содержит статические методы для поиска по множеству объектов данного типа. Вот я про такое и писал. Вот только действительно, в 5.3 появился __callStatic, который и такое может. Однако, мне не совсем понятно, как оно будет работать с наследованием, да и сама необходимость наследования несколько смущает.
                        • +1
                          Это я отношу к деталям реализации. И, да, можно заменить на статические методы класса сущности — дело вкуса, имхо. Но я не понимаю зачем нужны __callStatic и прочее метапрограммирование для использования ActiveRecord? Наследования вполне достаточно. В базовом классе универсальный метод поиска, в наследниках — конкретные ради соблюдения DRY и инакпсуляции, которые вызывают универсальный базового
                          • 0
                            Но я не понимаю зачем нужны __callStatic и прочее метапрограммирование для использования ActiveRecord? Наследования вполне достаточно. В базовом классе универсальный метод поиска, в наследниках — конкретные ради соблюдения DRY и инакпсуляции, которые вызывают универсальный базового

                            Вопрос: кто реализует конкретные статические методы в наследниках? И всё-таки, наследование реализации — это не самый лучший подход, особенно, если требуется «унаследовать» статические методы.
                            • 0
                              Наследник реализует. Расширяет интерфейс родителя. У родителя, скажем, только find(), ну, пускай findById(). Наследник (пускай для класса записи в блоге) добавляет (при необходимости) findByTitle(), findByBody(), findByDate(), findByAuthor(), которые вызывают find базового класса с соответствующими параметрами.
              • +4
                Вот кто вас учил так поля называть? Почему не order_id? а? Вот схуяли тут id_order?
                Больше всего ненавижу php за то, что нет никаких конвенций и каждый называет свои колонки как попало. Вот в чем беда php :)
                • –2
                  очень просто пробегая глазами по колонкам я сразу по префиксу понимаю что это поле идентификатор.
                  • +2
                    В общем идите почитайте как в рельсах придумали делать нейминг переменных и чего угодно так, чтобы потом блювать от нейминга, который люди любят применять в php. Попробуйте, это интересно по крайней мере.
                    • –1
                      мой проект не был задуман как опен сурц, поэтому я делал нейминги так как мне удобнее., за совет спасибо, почитаю
                      • +1
                        Ну и что? Если для себя — значит можно создавать и пораждать трешняк чтоли? Вы как программист всегда должны писать хороший код :)
                        • –3
                          Я все еще уверен что ставить префикс впереди удобнее и нагляднее )

                          Ушел обедать, всем приятного )
                          • 0
                            может быть те, кто ставит минус дадут аргументацию?
                            • +1
                              мне на минусы как бы пофигу, просто интересно — неужели

                              id_primary
                              id_node
                              id_parent
                              name_last
                              name_first
                              status_view
                              status_action

                              не дает сразу понять какие колонки за что отвечают?

                              • +5
                                Потому что среди «parent» и «id» для нас важнее «parent». Нам надо знать, что это "родительский идентификатор", а не "идентификатор родителя". Аналогично с «view», к которому status всего-лишь дополняющий суффикс.
                                • 0
                                  врят ли у нас будет несколько родительских идентификаторов, т.к. вся остальная информация подтянется по этому ключу, а вот идентификаторов впринципе у нас может быть несколько и глядя на колонки мы сразу видим что есть идентификаторы, что поля состояний, а что поля наименований.
                                  • 0
                                    А ваабще я думаю все зависит от структуры приложения и помоему свобода выбора в ПХП даже плюс, мало того если ты работаешь в готовом фреймворке тебе необходимо его изучить и ты после этого все равно будет использовать принятое там наименование. Все дело привычки. А бегать между разными разработками и надеятся что везде все будет одинаковое — безнадежно помоему.
                                    • 0
                                      Пхп как язык помоему изначально обречен был на обростание фреймворками, т.к. в нативном варианте он Уе**н простите )
                                    • 0
                                      Причем тут свобода? Вы вообще работали в команде? Руководили группой людей?
                                      Есть конаны, которые позволяют делать хорошо, унифицированно в тех местах, где это нужно. Простой пример — нейминг колонок в бд, когда существуют некие правила — такой код можно отдать другому человеку и он с легкостью разберется в нем. В противном случае получается, что каждый городит свой велосипед в задачах, где это соверешенно ненужно. Кто-то называет колонку id как nid, vid или primary_id, а почему нельзя идентификатор объекта называть просто и понятно — id?
                                      • –1
                                        Ой не не не про тим кодинг я не спорю, я же говорю относительно своего проекта.

                                        Я даже спорить не буду — в серьезном проекте самое главное и самая первая задача — это прописать изначально от и до весь стиль написания, раздать всем мануалы и заставить выучить.
                                        • 0
                                          Вот и представте, такой мануал дается любому рубисту в каждой книге :) (рельсовику — тоже)

                                          А теперь представте — все стараются писать хорошо с самого начала, а не только в биг-тимах.
                                          • +1
                                            Да я не спорю, стандарты — это ваабще п**нно и мегакруто, но раз ПХП неимеет строгой стандартизации — это не повод его не использовать при его других плюсах.

                                            Для разработчика действительно приятнее и полезнее и экономнее, когда он знает что возьмет другой проект и там будет все так, как он привык.

                                            Увы в ПХП не так, но мне кажеться ПХП тем не менее достойный язык, и называть ПХП-кодеров ака Горе, негоже.
                                            • 0
                                              Вот для того чтобы найти компромисс люби и выбирают какой нибудь фреймвор и пользуют его, оставляя за собой все остальные преимущества языка.

                                              КОДИТЬ на ПХП нативно — ЭТО ЗЛО!
                                  • 0
                                    Почему не будет? Денормализация мощный инструмент оптимизации. И ищу я прежде всего «родителя», а не «идентификатор». От общего к частному. В том месте где мне потребуется что-то от родителя, я сначала напишу parent, а лишь потом буду думать что мне нужен его идентификатор (да и IDE может не дать возможности думать, а подскажет что вариантов кроме parent_id собственно и нет), а вот мысль «мне нужен идентификатор, а потом разберусь чего» мне сложно представить.

                                    Хотя, конечно, это лишь мой способ мышления. Но тогда, наверное, вам в подавляющем большинстве (всех) ООП ЯП не нравится, что приходится писать что вроде $parent->id, а не id->$parent?
                                    • 0
                                      Нет, просто вы сейчас на объекты перекинулись там естественно я выбрал бы вариант $parent->id, а я мыслил со стороны именно наименования колонок в бд, т.к. врятли в записи у меня parent будет упоминаться несколько раз.
                                      • +1
                                        $item->parent->id или $item->id->parent?
                                        • 0
                                          :D да хватит с ним спорить, он придумал мудацкое название колонки, а теперь пытается доказать, что этот выбор был чем-то оправдан :)
                                          • +1
                                            Я доказать не пытаюсь я лишь объясняю почему я так сделал
                                        • +1
                                          смотря чем являются parent и id, если id — это коллекция идентификаторов которые есть у $item тогда сами понимаете.
                                      • 0
                                        Тем более не понятно, тут так мыслите, а тут так :)

                                        А вот идентификаторы как раз могут много раз появляться. И не лучше ли уникальные части имён выносить вперёд, а их «тип» оставлять в качестве суффикса? Даже из чисто практических соображений: набираете код, нужен вам идентификатор родителя, набрали parent (а то и просто p) и умный редактор дополнил до parent_id (других вариантов нет, вы говорите). А так нужно набрать id_ (ну, i), а редактор до id_parent дополнить не сможет, так как у вас куча имён, начинающихся на id_. Лишних три нажатия клавиши на каждое использование.
                                        • +1
                                          а если есть child, next итд, то мне ненужно помнить какие они есть — я печатаю id_ и ide как бы подскажет какой именно нужен child, parent или next. Разве так не удобнее?
                                          • +1
                                            Все относительно и зависит от того пытаюсь ли я обратиться к вложенному объекту либо выбрать объект по значению свойства.
                                          • +1
                                            Вы просто привыкшие к Активрекордам не учитываете что в нативном пхп значение ячейки еще не является явной ссылкой на другой объект в другой таблице, а является как бы свойством объекта-строки, и только потом по желанию программиста по значению этого свойства может быть подгружен другой объект-запись из таблицы.
                                            • +1
                                              Меня сложно назвать привыкшим к активрекордам, я ещё на PHP3 писал говнокод, но уже тогда именовал поля как parent_id, а не id_parent. Для меня важнее всегда была сущность, а не её идентификатор. Да и просто
                                              ON author.user_id = user.id
                                              
                                              выглядит, имхо, лучше чем
                                              ON author.id_user = user.id
                                              
                                              — глаз не спотыкается на id, идёт последовательное уточнение согласно иерархии предметной области.
                                              • 0
                                                Ну просто я расцениваю поля записи как свойства этой конкретной записи
                                          • 0
                                            Мне IDE подскажет parent, child, next и т. п. сразу после нажатия ->, а вам надо будет ввести id_ :)
                                            • 0
                                              а разве он вам не подскажет еще и остальные колонки? name, status итд,
                                              • 0
                                                Он мне подскажет parent_id, parent_name, parent_status в одном месте, а вам раскидает по всему списку.
                                                • 0
                                                  а зачем мне в записи держать что-то от парент кроме как его айди, по которому можно получить все остальное.
                                                  • 0
                                                    таблица1 — id, name
                                                    таблица2 — parent_name, parent_id

                                                    так чтоли? это же бред
                                                    • 0
                                                      id, name
                                                      id, name, parent_id, parent_name

                                                      так точнее
                                                      • 0
                                                        видно что parent_name явно дублирует данные
                                                        • 0
                                                          соответственно такой колонки не должно быть
                                                          • 0
                                                            Очень смелое утверждение. Вы против любого кэширования? Там же данные тоже дублируются.
                                                            • 0
                                                              Ну нет что Вы меня уже совсем за еретика считаете )))
                                                              • 0
                                                                Так это то же самое кэширование. Денормализация называется.
                                                            • 0
                                                              И между прочим они дублюруются но уже в принципиально другом формате =P
                                                              • 0
                                                                Если конечно это не кеширование самого мускуля
                                                  • 0
                                                    Чтобы получить это тем же запросом что и id, причём без тормозных джойнов. Страница с комментариями или форума — зачем чтобы вывести ник и ид (в ссылке) лезть в другую таблицу?
                                                    • 0
                                                      Да и опять возвращаемся к упоминанию об архитектуре и начинаем все по кругу, да действительно такие моменты бывают, поэтому чтобы обратиться к именам я уже буду писать name_parent или name_this. и буду знать что сейчас я обращаюсь к колонкам с именами того объекта с которым работаю, т.к. parent в данном случае мне ваабще не интересен, я даже не обращаюсь к нему а беру данные прямо из строки с которой работаю.
                                                      • 0
                                                        В ссылке нужно имя и ид. Имля для пользователя, ид для урла. Неужто SELECT id_user, name_user удобнее чем SELECT user_id, user_name?
                                                        • 0
                                                          пробегая по первому варианту и не читая все слова до конца ибо имя колонки может быть ololo_user_parent_fucking_shiity мы сразу видим что запрос возвращает айди и имя, а чьи мы узнаем только вчитавшись
                                                          • 0
                                                            а в вашем случае если колонок много нам придеться вчитываться ибо если нет все что мы увидим user_ user_ user_ user_ итд
                                                            • 0
                                                              тоесть из ващего примера мы получим одну единицу информации — объект к которому мы обратимся а в моем сразу две итд по нарастающей
                              • –2
                                Я вас поддерживаю.

                                id_order лучше, чем order_id.
                                • 0
                                  Ну щас и вам пол кармы снесут )))) Спасибо )
                                  • 0
                                    Мне глубоко по барабану.
                                    Я даже не знаю, что это такое.
                                    • 0
                                      и то верно )
                • +1
                  там и переменные и функции (включая base library) как попало названы :)
                  • +1
                    Ну что ж поделать, зато они его <<любят>> ;)
                    • 0
                      Нативный пхп, да неоднозначен, но в фреймворках вполне нормальные нейминги похожие на Java а-ля getModelAttribute() итд. и потом у ПХП есть преимущество — он поддерживается везде, коммюнити как ни крути шире и все оттуда вытекающее.
                      • +1
                        что вытекающее? Миллион программист, которые не знают что такое шаблонизатор?
                        • 0
                          программистов*
                        • 0
                          из большЕго комьюнити и поддержки вытекает следующее

                          бОльшее количество разработок, взять те же цмс
                          бОльшее количество разработчиков что дает более низкие цены на разработку ввиду конкуренции

                          этого уже достаточно.
                          • 0
                            из бОльшего* =)
                          • 0
                            Стоп стоп стоп. С чего вы взяли что на php больше разработок? CMS? Почему вы думаете что этого мало на руби?

                            Низкая цена — да. Вы представитель бизнеса?
                            • 0
                              Хотя бы с того что PHP популярнее и появился раньше.

                              en.wikipedia.org/wiki/List_of_content_management_systems

                              Вот тут посмотрите таблички, сколько ЦМС на Пыхе и Сколько на раби, вопросы еще есть?

                              Не совсем представитель бизнеса, но это важно иметь ввиду.
                              • –1
                                И дальше то что? Ок, php заняло нишу кмс-ок, которые расширяются через жопу и половина кода держат бек-ворд-компобилити до php4, дальше то что? Теперь и мне писать под друпал, от которого сами кор-девелоперы ноют и плачут?
                              • +1
                                зачем вам это иметь ввиду? Вам нравится, когда вам мало платят?
                                • –1
                                  Мне платят достаточно, а вот спрос на меня есть всегда и предполагаю еще долго не иссякнет, мало того я еще и выбираю какой заказ брать а какой нет, а не жду очередного. Я конечно не знаю как у Вас но я во всяком случае за свой спрос уверен на 100%.

                                  Кстати по поводу когда в различных Друпалах и Вебасистах — это реально сущщий ад и блевотня, кстати именно она то и сподвигла на написание велосипеда, т.к. ассинезатором скриптов я быть нехотел.
                                  • 0
                                    Чувак, попробуй взгляни на эко-систему руби иди пайтона, тебе больше понравится.
                                    • 0
                                      Скиньте ссылочки, если не трудно, я почитаю, я всегда открыт для новых знаний и аргументированных довыдов. Буду благодарен.
                                      • 0
                                        Блин, довОдов.
                                        • 0
                                          • 0
                                            Спасибо, ну то что код у рельс и питона приятнее, я конечно давно заметил, спорить не буду — это так и есть, поэтому я и заговорил именно о! других преимуществах ПХП. Ну посморим, тенденции меняются =) Спасибо за дискус.
                                      • 0
                                        Если вы про ссылки на экосистему ruby/python, то вот по поводу ruby ruby-toolbox.
                                        • 0
                                          Спасибо
                • 0
                  А какое отношение колонки имеют к PHP? Вы ещё скажите, что не любите PHP, потому что индексы в БД не используются :)
              • 0
                Не вижу тут ничего от ActiveRecord. Больше похоже на обвязку для SQL. ActiveRecord заключается прежде всего в прозрачной связи объектов языка и строк в БД, в отсутствии необходимости думать в терминах SQL.
                • 0
                  Согласен. Я неправильно употребил термин. Не знаю как такая обвязка называется.
    • +1
      PHP и HTTP разного поля ягоды

      В оригинале было «PHP has HTTP interaction baked right in.», что, если дословно: «Взаимодействие PHP и HTTP взросло (выпечено) в одной печи», как-то так. Посчитал, что ближайший русский аналог — как раз про ягоды с поля.
      • +2
        Где там одна печь — там написано, что взаимодействие с хттп замечено внутрь пхп
        • –1
          Замечено то есть
      • +2
        «baked in» = «встроенно»
        • –1
          Я как-то не нашёл сочетания «bake(d) in» и посчитал, что in относится к right. Исправлю тогда с вашего позволения.
          • 0
            Дословный перевод — запечено. В кулинарном смысле, так сказать :)
            • 0
              Взаимодействие с HTTP встроено (запечено) в PHP.
  • +2
    > Но с каких пор разработчик определяет что успешно? Если бы разработчик это определял, то софт типа Wordpress, jQuery и Jenkins/Hudson не достигли бы такого успеха (ибо их исходные коды под характерным вопросом качества).

    Странное заявление. Разработчик вполне может судить о тех инструментах, с которыми ему приходится работать. Вообще не понимаю, зачем мешать в одну кучу языки-фреймворки и продукты, рассчитанные на конечного пользователя.
    • 0
      Тот же Wordpress это по сути не CMS (хотя и можеет выступать в её роли), а CMF. Расширить или изменить базовую функциональность (пускай даже с учетом сторонних модулей) — нужно писать php-код. Да что там, функциональность, вёрстку натянуть — нужен код. То есть продукты как бы для конечного пользователя на PHP от самого PHP неотделимы для этого пользователя. И наверное основное применение PHP это кастомизация этих продуктов.
      • 0
        Да, был у нас проект, точнее говоря удалось мне понаблюдать за проектом, который представлял из себя туристический портал — интернет магазин на WP, писали его типичные php программисты. Естественно никто во всем этом дерьме не пытался даже разбираться.
        • 0
          А что для вас значит «типичный php-программист»? Как по мне, так язык в этом термине вторичен. Я ищу работу прежде всего программиста, а то, что php — так исторически сложилось, что я знаю его лучше, более полезен буду работодателю в качестве программиста, использующего php, а не ruby/python/java/c#/js/vb/asm/… в которых я знаю только азы — буду тратить оплачиваемое время на разбирательство с нюансами. А уж если и настройкой среды исполнения придётся заниматься…
          • –1
            Для меня основная масса php программистов это:
            1) отсуствие scm
            2) всякое говно на уровне базы данных (отсуствие индексов, идиотские названия всего и вся)
            3) херовый код, который мы просто выкинули, потому что люди кроме книг по php ничего никогда в своей жизни не читали и не видели (я говорю о тонне книг на тему разработки ПО)
            • 0
              Хм… значит мне как-то больше попадались нетипичные php-программисты, потому у меня о типичных представление несколько другое.

              А SCM (если я правильно понял VCS?) и уровень БД вообще к языку отношения не имеет. Я на VC++ и VB писал без VCS и индексов (вернее индексировал всё подряд), а на C вообще всё в файлах хранил, без всяких БД — прямой перебор — самый простой способ поиска :), а на php использую, и над индексами думаю, запросы профилирую и т. п.
              • 0
                Я говорю с вами о культуре. Эко системе вокруг языка.

                Под SCM я имею ввиду git/svn.
                • +1
                  Если я сегодня начну писать на ruby, разве моя культура изменится? Я стану использовать git (а не любимый Mercurial), как-то по другому именовать таблицы и колонки БД?

                  А я под VCS имею в виду mercurial/svn :)
                  • 0
                    Вы относите себя к числу таланлтивых php программистов? ;)
                    • 0
                      Я отношу себя к числу программистов. Какой инструмент использовать — вторично, просто php «легче» и привычнее, в «активном словаре» находится. Как, например, английскую IT-литературу (тот же Ruby Way) я без словаря читаю, а юридическую или художественную так не получается. А так хоть на ассемблере могу сайт сделать (делал), хоть на Эрланге (делал, даже без Нитрогена :) ).
                      • 0
                        Ну тогда зачем вы мне жизненные вопросы задаете? У вас вон и так все хорошо :)
                        • 0
                          Хочется лучшего, в том числе писать за деньги на рельсах.
                          • 0
                            Тогда стоит начать, ничего сложного в рельсах и руби нет.
                            • 0
                              А я и начал, только уровень «могу бложик на RoR написать» не востребован.
      • 0
        Расширить или изменить базовую функциональность (пускай даже с учетом сторонних модулей) — нужно писать php-код

        А в случае с CMS разве не так же? Или это миф о том, что CMS — это только то, что «из коробки».
  • 0
    Спасибо за перевод.
    Думаю, эта статья поработает достойным реверсом.
    • –25
      Читал оригинал. Перевод — так себе. Несколько строк прочёл и… дальше не захотел.

      «Дебаггер»… Такое ощущение, что перевод написан быдлокодером со стажем.
      • +2
        Вообще это уже устоявшееся русское слово. Викисловарь о нём знает. Если Вам режет слух, могу заменить на отладчик.
        • –10
          Вы меня извините за мою резкую критику. Просто по знакомым сижу (есть и евангелисты, и быдлокодеры). Первые, в 99 из 100 случаев называют «отладчиком».
          • +1
            У вас очень мощная выборка! Целый 100 «евангелистов» (между прочим, почитайте, что такое «евангелист»). Просто монстр статистики
          • +3
            Вот мы и нашли лакмусовую бумажку идентификации быдлокодеров! Срочно телеграфируйте всем HR-ам, люди должны знать об этом!
          • +1
            Нехорошо обычно упоминать про возраст автора комментария, но я в ваши годы не знал и трёх хороших программистов. Завидую современной молодёжи!
        • –1
          >> «Устоявшееся русское слово...»

          Вот только этого не надо. Это жаргонизм, не более того. Иностранного происхождения, смею заметить.
        • +2
          Хотя я сам стронник (дада) англицизмов, но отладчик отличное слово (:
          • 0
            Исправил.
            • +4
              Зря. Пошли на поводу у троллей
  • +5
    Многое верно описано. Единственное, в Ruby есть встроенный шаблонизатор — erb (embedded ruby).
    • 0
      Равно как и в питоне есть Template
      • –1
        На самом деле и там и там они не built-in функции, автор это имел в виду. Надо сделать require или import, но тогда и в PHP можно что-нибудь подключить, например, тот же Zend.
        • 0
          Нет ну так нельзя рассуждать. В питоне по умолчанию вообще практически ничего нет, там вполне базовый функционал всегда импортировать нужно. Это просто особенность языка.
          Если уж сравнивать то сравнивать это нужно не с Zend, а с модулями пхп, без которых он например с mysql общаться не сможет.
  • +4
    Но разве есть она в Python или Ruby?

    В Ruby есть ERB в стандартной библиотеке.

  • –4
    В ПХП много таких вещей, который по началу бесят, но если к ним привыкнуть, то все становиться более чем хорошо
    • +1
      А стоит ли привыкать к тому, что бесит? Разве fun не главное?
      • +7
        Главное — результат
        • 0
          А что является результатом в описанном выше случае? Привычка?) Или выход на новый энергетический уровень посредством преодоления себя?)

          Цель можно достигнуть, совершенно разными способами. Не лучше ли выбирать те, которые «не бесят»?)
          • –3
            Бесит то, что ПХП требует от разработчика больше низкоуровневых манипуляций, за что, кстати я ему очень благодарен
            • +6
              Стокгольмский синдром?)
              • 0
                Да нет. Просто я действительно понимаю как он все работает теперь на низком уровне
                • +6
                  На всех семи уровнях модели OSI?
            • +22
              Программисты на С++ все как один одновременно поперхнулись бубликом.

              Как в свое время, впрочем, поперхивались программисты на ассемблере, когда С++ стал считаться низкоуровневым.
              • +13
                За «в свое время поперхивались» поставил бы пять:)
              • 0
                Все в мире относительно
              • +10
                Да тут многие C# считают низкоуровневым :)
        • 0
          Зачем? Вы получаете 100 тысяч рублей и считаете, что за эти деньги можно терпеть херовый дизайн языка? :D
      • –2
        Стоит если оно того стоит
      • +3
        Кушать хочется…
        • 0
          Тогда идите и работайте с .NET или RoR. Такие товарищи куда дороже и не менее востребованы. Это не аргумент.
          • 0
            По вашим словам при любых раскладах программировать на PHP не стоит
            • 0
              Отнюдь. Своя ниша-то у него есть. Но «Кушать хочется» — не аргумент в пользу технологии, по поводу которой обсуждается: «стоит ли привыкать к тому, что бесит».

              Кушать хочется — это аргумент, когда нет аналогов и все, что остается — использовать «что есть». Но тут выбор то богат. И с точки зрения оплачиваемости, PHP отнюдь не самый-самый.

              Субъективно, я бы при любом раскладе и не писал на PHP :) Хотя и работал с ним долгие 3-4 года, можно сказать первый язык в реальных проектах был.

              Сейчас для веба изначально осваивал бы Python/Django или RoR, а также ASP.NET MVC.
          • 0
            Опыт на PHP есть, на RoR/Django нет. PHP бесит, но за него платят. Лично мне платят, а за RoR лично мне не платят. Даже когда предлагаю сделать на RoR в два раза дешевле, то все равно настаивают на PHP.
    • 0
      Отличный подход :)
  • +23
    Недавно менял проприетарное решение по windows на собственное решение на php (denwer+мини-сайт) для производственного процесса одной организации. Хвалой был тезис сисадмина — «техническая сторона меня удивила — всё работает просто и понятно!». Теперь они высказали желание съехать с windows под linux и с обычным LAMP продолжить функционирование без оплаты лицензий за mssql+server2003.

    Ключевые слова: просто, удобно и быстро. Но качество зависит от исполнителя, поэтому как верно подмечено — чем шире рынок, тем он разнообразней (от шедевров, до школьных поделок).
    • +4
      Вот кстати не ради холивора, а почему «просто, удобно, быстро» преподносится как конкурентное преимущество php-стэка?

      Можно сделать просто, удобно и быстро, используя практически все что угодно. Был бы разработчик толковый.
      Опять же, для развертывания есть масса инструментов, не имеющих непосредственного отношения к php.

      Что именно-то просто, удобно и быстро?
      • +7
        Если сравнивать Windows 2003 + MSSQL с LAMP стеком, то здесь всё весьма тривиально, как мне кажется: в Windows вам нужно отдельно ставить Windows, настраивать на нём лицензии и т.д., покупать MS SQL Server за несколько (десятков) тысяч долларов — тратить на это много времени и денег, после чего это добро ещё и устанавливать надо, что тоже занимает порядочно времени.

        В LAMP стеке вы буквально делаете следующее: ставите, к примеру, debian minimal за 10-20 минут (включая скачивание дистрибутива, нарезку и установку :)), после чего пишете

        sudo apt-get install apache2 php5 mysql-server

        Ждете 5-10 минут, пока это всё скачается и настроится и вас готовый апач с базой данных, ничего покупать не надо :). После чего копируете свой сайтик в /var/www, заливаете дамп (можно встроенным mysql клиентом, командой «source имя_дампа.sql») и работаете. Для того, чтобы это было более секьюрно, может потребоваться донастройка MySQL (что можно делать даже простым ручным редактированием таблиц из базы mysql), но в целом это всё делается за ещё 5-10 минут, и я не преувеличиваю :).

        Для Windows вы будете один только клиент для базы данных скачивать и устанавливать (иногда с правками в реестре, потому что на русскую версию винды оно в какой-то версии вообще не встанет :)) то же количество времени :).
        • +12
          Быстро ставите дебиан, быстро его настраиваете, быстро пишите sudo apt-get install бла-бла-бла, быстро делаете сайтик, быстро его копируете по ssh, быстро дампите базу, быстро ее заливаете на продакшен, быстро в ручную редактируете какие-то там таблицы в mysql, быстро (главное быстро!).

          Чтобы так быстро получилось нужны какие-нибудь метамфетамины, иначе никак, я думаю.
          • +1
            О где же тот дивный новый мир, в котором люди будут знать слова one, click и deployment:)
            • +1
              Насколько я понимаю, речь шла об 1 или буквально двух-трёх серверах, для которых готовить дистрибутив с автоматическим развертыванием не имеет никакого смысла, как мне кажется. С другой стороны, я вам привел совершенно реальные цифры по тому, сколько времени занимает установка ОС и соответствующего веб-сервера :). Получается быстро не потому, что нужно куда-то спешить, а потому, что там делать особо ничего и не надо — простейший LAMP поднимается и настраивается, по сути, из коробки.
              • –4
                Есть опыт поддержки в продакшене двух-трех серверов на которых крутится одно приложение? Думаю нет. Попробуй каково это, потом расскажешь:)
                • +7
                  Ээээ… Ну, есть опыт в работе с одним приложением на каких-то там 1000 серверах, но это, конечно же, мелочи по сравнению с вашими целыми 2-3 ;)
                  • –5
                    1000 серверов это ботнет что ли?
                  • +1
                    И да, не с нашими, с вашими:) Не я в начал про количества рассказывать.

                    1000 серверов тоже быстро-быстро? Там таблички, туда денвер, здесь apt-get'ом апдейты подоткнуть?)
                    • +1
                      Ну, в Badoo не используется apt, потому что там SLES, но в целом всё очень просто и очень быстро работает (конечно, ни о каких Денверах речи не идет, но всё сделано именно такими очень простыми способами, потому что какие-то сложные решения на таких масштабах работают и управляются значительно хуже).
                      Например одна из недавно оптимизированных мной операций — раскладка новой версии кода на все эти 1000 машин (в случае с PHP приложение и исходный код это одно и то же) у нас занимает около 1-2 минут — как вы думаете, это много :)? И нет, это не ботнет — чтобы обрабатывать 30к запросов к вебу в секунду, требуется иметь много серверов (из этих 1000 машин веб-серверами являются около 150-200 машин).
                      • +1
                        Так все-таки все руками быстро-быстро, или нет, я не понял? «Такими очень простыми способами» это какими?

                        Оптимизировал деплой — написал скрипт который по ssh раскидывает архивы? Или пулит из гита затеганную версию? Так все же не руками? Ну и капистрано, паппет, шеф какой-нибудь это конечно не тру:)

                        По-поводу машин хорошо:) 150-200 веб-серверов:) 800-850 остальных, это стационарные машины разработчиков?))

                        • +1
                          Через некоторое время должна будет выйти моя статья про то, как мы это сделали, в блоге Badoo — сможете узнать подробности. А так, да, раскладывайтесь с помощью git pull / svn up в 1000 потоков, убивайте свои сервера ;).
                          • 0
                            Не понял зачем мне сервера убивать и что мне делать c git pull в 1000 потоков?

                            Ну и все-таки, сам-то пробовал держать 2-3 продакшен сервера теми методами, которые народу выше советовал?)
                            • 0
                              На самом деле, такой способ установки я не придумал — так устанавливались сервера на моей предыдущей работе и работало это очень хорошо. Конечно, на серверах с большой нагрузкой (даже если это буквально 2-3 сервера) неплохо бы иметь мониторинг, бэкапы, ротейт логов и другие полезные вещи, но для минимальной установки это всё не обязательно.

                              Я изначально описывал ситуацию, когда вам нужно организовать небольшой сервис для «для производственного процесса одной организации» и хватит одного сервера за глаза. На одном ubuntu server до сих пор работают такие сервисы на моём первом месте работы и с ними за всё время проблем не возникало, поскольку они просто сидят себе тихонечко и выполняют свою работу и жрать не просят. Именно об этом, насколько я понимаю, говорил автор: если от системы требуется что-то простое, то LAMP будет прекрасно работать и не будет требовать от сисадмина, по сути, ничего — он может действительно просто оставить систему и не трогать её, пока не скончается железо.

                              Я кстати даже php-демонов на windows server 2003 под денвером содержал в «энтерпрайз-системе» и с php-частью никогда проблем не было :).
                              • –1
                                Ну тогда я вообще ничего не понимаю. Если это просто сервер которой «стоит и есть не просит», туда все что угодно можно воткнуть и оно будет нормально работать. В чем плюс LAMP перед каким-нибудь MS SQL Express, или как он там называется? Или перед любым другим решением?

                                Или мы говорим не о том, что «с целью», а о том, что «вопреки»?
                                • +1
                                  Например, куда удобнее иметь централизованный, интегрированный в ОС механизм обновлений для среды выполнения, чем следить за обновлениями минимум двух продуктов (самой ОС и SQL сервера).
                                  • 0
                                    А зачем обновлять что-то что крутится, свои задачи выполняет и лишнего времени не просит?

                                    Чтобы после обновления что-нибудь отвалилось?) Оно же бывает, что обновишься, а потом сидишь и думаешь, какой черт потянул кнопки нажимать:)
                                    • 0
                                      Фиксы уязвимостей, например.
                                      • +1
                                        Кто ломать будет?) Предыдущий оратор же дал вполне ясную вводную — тише воды даниже травы, «обеспечение производственного процесса одной организации»:)

                                        Софистика это все вобщем. Если само работает — то и пусть работает. А если требуется периодическое вмешательство, то надо делать по уму, чтобы минимизировать время, которое приходится затрачивать.
                                        • +2
                                          Вот из таких-то машин и собирают ботнеты и/или спаммерские фермы
                        • 0
                          Ну и конечно же не руками, а простыми скриптами это делается, но суть именно в том, что эти скрипты занимают от силы 100 строк и почти вся их работа заключается в проверке на ошибки, а не в выполнении «полезной работы». А если надо обслуживать 2-3 сервера, то сгодится любой вариант, о чём я и говорил, собственно.
                          • –1
                            Ну вот пообслуживай, расскажешь:) Ты же в баду, я подозреваю не один работаешь, и материально ответственным за простой серверов лицом не являешься?

                            Что такое скрипты по 100 строк и что такое работа, заключающаяся, в проверке на ошибки мне не понять. Ну пишете вы свои велосипеды, для своих исторически сформировавшихся задач, что ж всем теперь так делать и на такую модель работы ориентироваться? Сделали хайлоад, молодцы, но каждый хайлоад уникален.

                            И когда нам надо что-то руками настраивать, куда-то складывать и еще дампить и таблички править это не просто и не быстро. Это геморрой, который в будущем с большой долей вероятности потребует оперативного вмешательства.
                            Не надо вобщем давать людям дурные советы.

                            • +1
                              Один сервер — разворачиваем/апдейтим ручками. Несколько серверов (пускай даже тысячи) с одной конфигурацией — пишем скриптик. Зоопарк конфигураций/приложений — используем тяжёлую артиллерию типа капистрано и шефа, унифицируя процесс.

                              Возможно, после овладения артиллерией захочется и в более простых случаях её использовать. Но не получится это из пушки по воробьям?
                              • 0
                                Если из пушки стрелять картечью и воробьев много, то скорее всего все будет ок:)

                                Капистрано, на мой взгляд, однозначный маст хэв.
                                • +1
                                  А одна, но жирная ворона? :)

                                  Для начала VCS были бы однозначным мастхэвом и то хорошо.
                                  • 0
                                    Без VCS это уж совсем хардкор, я даже думать о таком не хочу:)
                    • +1
                      Нет, зачем руками? Всё автоматизируется, и при количестве серверов более нескольких, разворачивается chef, puppet или другой аналог.
                      • +1
                        Да вот и мне же интересно что да как.
      • +1
        Быстро — потому что практически любой может взять нечто денвера и одной из самоучителей может за вечер набросать прямо на домашнем компе себе более-менее интерактивный сайтик.
        Просто — потому что опять же любой может начиная от чего-то простого за один вечер развивать и параллельно развиваться.
        Удобно — потому что если хочется чего-то простого, ты делаешь это просто и так как удобнее тебе, а если нужно чего-то сложного — PHP позволяет делать и очень сложные вещи.
        При этом PHP сейчас есть на любом хостинге, при желании и бесплатный вменяемый найти нетрудно.

        Наверное как-то так.
        Впрочем по-моему в каждом языке есть свои сильные и слабые стороны, меня очень удивляет и забавляет когда многие почему-то начинают называть PHP полным говном.
        • 0
          Т.е. хорошо, быстро и удобно в том случае, когда хочется несильно парясь развернуть типовой cms-сайт на недорогом хостинге? С такой формулировкой я согласен. Но речь вроде бы шла не совсем об этом?

          А вот понятия «сделать просто и так, как удобно тебе» и «использование cms» совершенно несовместимы на мой взгляд.
        • –2
          Насчет «полным говном» — не про меня. Никогда не считал PHP «полным говном». Просто лично мне не понятно, зачем сейчас нужен PHP человеку, который всерьез собирается связать свою профессию с web-разработкой.
          • +6
            То есть, вы считаете, что PHP нет места в веб-разработке :)? Или, к примеру, нет спроса на PHP-программистов? Почему вы считаете, что PHP не нужен человеку, который всерьез собирается связать свою профессию с web-разработкой? Вы, возможно, слышали, что сайты вроде facebook, vkontakte, yandex, badoo, wikipedia имеют веб-бэкенды на PHP и не отказались бы от хороших разработчиков на этих языках :)?
            • 0
              Не надо на «Вы», я пока еще не пенсионер.

              Ну и что что контакт, фейсбук и кто-то там еще сделан на php? Ну сделан, так масса других проектов сделана с использованием других средств. Да и что-то мне подсказывает, что они одним php не ограничиваются, стэк технологий у них довольно большой.

              Фейсбук, собственно говоря, когда начинался? В то время было много альтернатив PHP? Контакт тоже не вчера появился на рынке. А сейчас альтернативы есть. И хорошие. Почему бы не использовать их?

              Я не понимаю, подхода, когда мы давимся, плюемся, прем сквозь тернии, но все равно продолжаем и продолжаем что-то там делать и что-то кому-то доказывать.

              • +2
                Проблема в том, что альтернативы не настолько сильно лучшие наверное, иначе бы все сразу и начали только их использовать. :)
                • 0
                  Ну так может быть всем и не надо? Зачем хорошему, состоявшемуся PHP-разработчику переходить на что-то другое?
                  • 0
                    А зачем начинающему разработчику осваивать что-то другое (кроме расширения кругозора), если явных плюсов особо нет, а спрос больше именно на PHP? Может даже в недалеком будущем что-то поменяется, но далеко не у всех есть талант/навыки прогнозирования рынков (а если есть, то может, не разработчиком идти работать? :) ).
                    • 0
                      Дык есть же явные плюсы:) Мир на месте ведь не стоит, все новое ведь не с потолка берется:)

                      Хотя если хочется поддерживать старый код и работать в кубикле, имея над душой 10 проджект-менеджеров, лидов и кто там еще бывает в настоящих командах, то наверное не стоит:)

                      Насчет идти работать «не разработчиком» вполне вариант:) Много их, в последнее время, этих разработчиков стало, а толкового не найти:)
                      • +3
                        Так и PHP на месте не стоит, переживать по поводу «старого кода» особо не приходится, современные php-фреймворки предполагают активное использование современных (5.3) фич. А вот экономических обоснований переписать с нуля старый код на RoR/Django/..., когда можно его плавно перевести на использование php-фреймворка, избавляясь как от depricated фич языка, так и от ошибок проектирования приложения, я придумать не могу. Свои личные, эстетические есть. Убедить заказчика, что развитие должно быть заморожено на время ради удовлетворения моих эстетических запросов как-то не получается.