Comments 605
PHP — хороший язык. Интеграция в html у него лучше чем у любого другого языка (кроме javasript и vb). Правда относится к нему хорошо я стал только после того, как перестал его использовать для серьезных проектов. Со временем остаются только хорошие воспоминания.
>>Интеграция в html
что?
что?
Как непрограмист могу сказать что если человек и выразился неправильно, по сути он прав — как включить php-код в html-страничку знают все, а как запустить на своём хостинге скрипты написанные на Ruby, Питоне, Перле и пр. — далеко не все. Это я перечислил популярные интрпертируемые языки, а ведь кто-то и на С++ веб-приложения пишет.
Если что не так написал, просьба пояснить, а не минусовать, goto строка 1
Если что не так написал, просьба пояснить, а не минусовать, goto строка 1
Пхп просто самый распространенный. «Интеграция в html», если можно так выразиться, у пхп как раз дохлая и заключается в банальном выводе переменных через echo. Я бы не назвал это интеграцией.
Так везде можно.
Ну и для, например, питона есть много разных шаблонизаторов.
Равно как и для пхп есть, к примеру, smarty.
Так везде можно.
Ну и для, например, питона есть много разных шаблонизаторов.
Равно как и для пхп есть, к примеру, smarty.
У слову пхп сам по себе шаблонизатор.
Мне кажется именно это имелось ввиду под словами «Интеграция в html у него лучше»
Сейчас <?=date('Y')?> год
Мне кажется именно это имелось ввиду под словами «Интеграция в html у него лучше»
У меня двойственное отнощение к short tags. C одной стороны, это удобно. С другой, не рекомендуется к применению, особенно если не известно заранее, где может развертываться приложение.
С выходом 5.4 можно писать <?= $var ?> без включенной директивы short_open_tags
Да ладно, везде где пишут о short tags, там же пишут о том, что мол лучше им не пользоваться, потому что «не известно заранее, где может развертываться приложение». Как по мне, то обращать внимание на такую вещь не нужно (если, конечно, вы не разрабатываете wordpress или еще что-то суперюзерфрендли). Вы ведь не будете думать что вот мол, не буду писать на utf-8, мало ли у кого-то сервак на cp1251 заточен. Или, допустим, не буду включать вот этот гем в свой rails проект, потому что он под винду не компилится (да и вообще может у юзера gcc в линуксе отсутствует).
Согласитесь же, что <?= "" ?> куда более сексуально, чем <?php echo "" ?>
:)
Согласитесь же, что <?= "" ?> куда более сексуально, чем <?php echo "" ?>
:)
о, а подсветочка-то все-таки хромает :)
Это же просто сокращенная форма записи <?php echo ?>… От того что оно на 7 символов короче пхп не становится сразу круто интегрированным в хтмл)
Как по мне так наличие в питоне встроенного полноценного шаблонизатора обеспечивает куда лучшую интеграцию.
Как по мне так наличие в питоне встроенного полноценного шаблонизатора обеспечивает куда лучшую интеграцию.
Да я вообще никак не хотел акцентироваться на сокращенной записи:) Да хоть на 20 длиннее.
Смысл в другом — пхп-скрипт это шаблон. Весь текст (а обычно это хтмл) из него напрямую перенаправляется браузеру, пока не встретятся тэги <?php, <?.. То что внутри этих тэгов — это логика шаблона, код оттуда интерпретируется, он также может возвращать данные, которые будут отправлены браузеру, а может и не возвращать.
Мне кажется, что это можно назвать «круто интегрированным в хтмл» :)
Про питон — я не писал скрипты для вэба на голом питоне (и других языках), поэтому про интегрированность в хтмл их, я сказать ничего не могу. Но сдается мне, что там все несколько иначе:)
Смысл в другом — пхп-скрипт это шаблон. Весь текст (а обычно это хтмл) из него напрямую перенаправляется браузеру, пока не встретятся тэги <?php, <?.. То что внутри этих тэгов — это логика шаблона, код оттуда интерпретируется, он также может возвращать данные, которые будут отправлены браузеру, а может и не возвращать.
Мне кажется, что это можно назвать «круто интегрированным в хтмл» :)
Про питон — я не писал скрипты для вэба на голом питоне (и других языках), поэтому про интегрированность в хтмл их, я сказать ничего не могу. Но сдается мне, что там все несколько иначе:)
Питон без использования шаблонизаторов, в том числе и встроенных — это будет просто .py файлик который через print выводит весь хтмл код целиком.
Но смысла так делать совсем нету, для питона есть вагон разных шаблонизаторов на любой вкус и они очень удобные.
Собственно для пхп шаблонизаторы тоже есть, но при них я ничего такого хорошего сказать не могу, тот же Smarty мне как то совсем не понравился.
Но смысла так делать совсем нету, для питона есть вагон разных шаблонизаторов на любой вкус и они очень удобные.
Собственно для пхп шаблонизаторы тоже есть, но при них я ничего такого хорошего сказать не могу, тот же Smarty мне как то совсем не понравился.
А зачем в программировании такие люди? Которые кроме на работу с echo ни на что не способны?
Спросите у людей, которые платят им деньги. Есть спрос — предложение появится.
Спрос на низкокачественных программистов? Нет, ну ок, хорошо что эту нишу заняло php.
Спрос на дешевых. И с этой ниши PHP вытесняют, но пока массового перелома в сознании заказчиков не произошло.
Да и слава богу, пусть дешевые php программисты, не понимающие вообще ничего, не использующие ar или шаблонизатор дальше клепают сайты визитки. По сути все идет как надо :)
А как быть дешевым, использующим AR (хотя DM+UoW больше нравится) и Smarty/Twig?
Ruby — пузырь. Ставки по сравнению с PHP аналогичного уровня x2, а то и X3 непонятно почему, если на нем и писать легче и все такое.
Потому многие на него и переходят, как только уровень позволит. А это, обычно, происходит раньше, чем человек осилил нормальные фреймворки на php и полноценно использует хотя бы PHP 5.3.
Вот и получается, основными аргументами в пользу Ruby приводят фичи Rails, типа «смотрите тут можно запросы не писать, а так по модному метод класса вызвать». Все это, даже то, чего не было до Rails, уже давно перетащили в PHP-фреймворки. Да, шок: и роуты и орм реализованы и на других языках.
На мой взляд, грамотные аргументы в пользу Руби должны выглядеть примерно так:
— наверное, самый большой набор инструментов для работы с ООП, который даже вводит ряд новых приемов по организации структуры классов
— согласованный и лаконичный синтаксис
— многопоточность
Но никак не «на PHP одни быдлокодеры».
Потому многие на него и переходят, как только уровень позволит. А это, обычно, происходит раньше, чем человек осилил нормальные фреймворки на php и полноценно использует хотя бы PHP 5.3.
Вот и получается, основными аргументами в пользу Ruby приводят фичи Rails, типа «смотрите тут можно запросы не писать, а так по модному метод класса вызвать». Все это, даже то, чего не было до Rails, уже давно перетащили в PHP-фреймворки. Да, шок: и роуты и орм реализованы и на других языках.
На мой взляд, грамотные аргументы в пользу Руби должны выглядеть примерно так:
— наверное, самый большой набор инструментов для работы с ООП, который даже вводит ряд новых приемов по организации структуры классов
— согласованный и лаконичный синтаксис
— многопоточность
Но никак не «на PHP одни быдлокодеры».
Ну в целом я с вами согласен. Не очень ясно про рейты и как вы сранивали кондидатов, но я не буду уточнять.
Пузырь?! Чего вдруг пузырь? Вот скажите мне: хоть 1 из 10 пхп-программистов пишет тесты? Вряд ли больше. Ну и раз речь зашла о пхп-фрейворках, то почему-то многие усиленно стараются быть похожи/копируют рельсы. С чего бы это?
Да ну и сам руби хорош хотя бы за вот такие конструкции: (1..10).inject(:+)
И кучи чего ещё.
Да ну и сам руби хорош хотя бы за вот такие конструкции: (1..10).inject(:+)
И кучи чего ещё.
UFO just landed and posted this here
Вот почему ruby разработчик начального/среднего уровня стоит на рынке дороже php того же уровня? Если порог вхождения ниже, код пишется проще и быстрее, фреймворки гениальны и т. п.? Работать выходит проще, а платят больше?
Отвечу словами Matz-а: Я не знаю ни одного безработного ruby-программиста (-:
А если есть много безработных пхп-программистов, то зачем платить больше?!
А если есть много безработных пхп-программистов, то зачем платить больше?!
Мне вот всё равно писать на незнакомом php-фреймворке или на RoR/Django. Но для RoR я недоквалифицирован, а для PHP перквалифицирован на уровень ЗП ~800-1000 у.е. (Питер). На RoR требуют BDD, а на PHP не хотят слышать о TDD, например. На RoR требуют git (да ещё аккаунт на gihub зачем-то), а я к Mercurial привык, а работодатели так вообще VCS не используют.
Могу я считать себя безработным ruby-программистом? :)
Могу я считать себя безработным ruby-программистом? :)
Как говорят у нас в Одессе, запретить я Вам этого не могу (-:
Лично я просто не приемлю крайностей: пхп-руби-питон или там виндоус-линукс и т.п.
В web-программировании уж так заведено, что знать просто один язык невозможно, как мне видится.
Лично я просто не приемлю крайностей: пхп-руби-питон или там виндоус-линукс и т.п.
В web-программировании уж так заведено, что знать просто один язык невозможно, как мне видится.
Вне спора о качествах того или иного решения (было время, я коммитил в PHP и активно поддерживал его документацию), я отвечу на оба вопроса.
Платят больше потому, что рубистов – меньше. А меньше их потому что порог вхождения в рельсы больше. Я не раз видел округлившиеся глаза человека, которому рассказывали про ассеты, кофи, сасс и хамл. Хотя ничего, привыкают. Другая проблема с порогом вхождения – другая религия, касающаяся циклов разработки. В мире руби совсем иной подход к BC. Это подстегивает и заставляет быть более социальным и быстрым. И это развивает. Либо люди уходят. Уровень ruby-разработчиков по этой причине растет быстрее, либо скатывается в 0. Сообщество заставляет их учиться, а не дает возможность, как в случае с PHP.
Аккаунт на гитхабе нужен по описанной выше причине – это способ взаимодействия с этим сообществом. Большая часть рубистов, с которой мне доводилось работать, хоть в каком-нибудь опен-сорсе да поучавствовали. Если не свое корыто, так чужое подлатали. Гитхаб – история взаимодействия с сообществом, которая для рубистов ОЧЕНЬ важна. Это – показатель перспективности и живости. А перспективность, ивость, другими словами потенциал, – самая важная характеристика разработчика. Выучить можно любой язык.
Я никаким образом не объясняю этим, что руби – лучше. Мое _личное_ мнение на этот вопрос следующее: PHP должен быть вытеснен Groovy или чем-то подобным. Потому что он усиленно растет в Яву, а Ява форкается в то, что похоже на PHP. Факт в том, что вторых младенцев карма и архитектура в разы лучше.
Платят больше потому, что рубистов – меньше. А меньше их потому что порог вхождения в рельсы больше. Я не раз видел округлившиеся глаза человека, которому рассказывали про ассеты, кофи, сасс и хамл. Хотя ничего, привыкают. Другая проблема с порогом вхождения – другая религия, касающаяся циклов разработки. В мире руби совсем иной подход к BC. Это подстегивает и заставляет быть более социальным и быстрым. И это развивает. Либо люди уходят. Уровень ruby-разработчиков по этой причине растет быстрее, либо скатывается в 0. Сообщество заставляет их учиться, а не дает возможность, как в случае с PHP.
Аккаунт на гитхабе нужен по описанной выше причине – это способ взаимодействия с этим сообществом. Большая часть рубистов, с которой мне доводилось работать, хоть в каком-нибудь опен-сорсе да поучавствовали. Если не свое корыто, так чужое подлатали. Гитхаб – история взаимодействия с сообществом, которая для рубистов ОЧЕНЬ важна. Это – показатель перспективности и живости. А перспективность, ивость, другими словами потенциал, – самая важная характеристика разработчика. Выучить можно любой язык.
Я никаким образом не объясняю этим, что руби – лучше. Мое _личное_ мнение на этот вопрос следующее: PHP должен быть вытеснен Groovy или чем-то подобным. Потому что он усиленно растет в Яву, а Ява форкается в то, что похоже на PHP. Факт в том, что вторых младенцев карма и архитектура в разы лучше.
Попытки использовать хамл или *сс я делаю и в пхп, но получается только в тех, которые под контролем vcs (обычно mercurial) и capistrano. Но к этим приложениям особых требований нет, я их сам формирую и могу себя убедить в их полезности. Заказчиков не могу. Ну не понимают они, что сайт им я сделаю за 100 рублей в час, а для малейшего изменения вёрстки придётся искать верстальщика, который возьмёт 200…
Времени правки займут меньше. Более дорогие специалисты, использующие новые технологии, работают быстрее. В этом их смысл. Если это не так, либо специалисты плохие, либо технологиям грош-цена, либо это какой-то специфический случай.
Это, правда, не отменяет проблемы необходимости минимального распространения. Конкретно у хамла с этим большие проблемы.
Это, правда, не отменяет проблемы необходимости минимального распространения. Конкретно у хамла с этим большие проблемы.
Даладно? От рубиста начального уровня требуют понимания ООП и метапрограммирования. От php-иста начального уровня понимания echo?
Формально обычно требования одни в вакансиях (кроме нюансов), но от рубистов уже на собеседованиях выясняется, что знание инфраструктуры (ака экосистемы) подразумевается, а не только языка/фреймворка. Спросят невзначай «какие гемы для авторизации лучше использовать?» и ответ «я гемы не использую, работаю с исходниками с гитхаба» не устраивает.
Расскажу историю. Есть у меня знакомый, у него небольшая веб-студия. Распиарил я ему рельсы, написал для него сайт студии небольшой за пиво (для друга же :). Рельсы ему понравились, мол быстро и т.д. После этого он общался с начальником отдела разработки одного крупного новосибирского сайта (они там на php пишут) и спросил: «А как с руби/рельсами у вас дела обстоят»? Он ему ответил, что руби вообще какой-то непонятный язык, да и разработчики на RoR хотят больше денег, чем php'шники. Вот так :)
Сам на рельсах пишу, в Новосибе вакансий вообще нету (или я где-то не там ищу). Поэтому приходится с зарубежниками работать. И тут возникает некая конкуренция: за рубежом платят больше, чем в среднем по России. Значит, если в России работать, то хочется зарплату не ниже. Возможно еще и поэтому многие рельсовики требуют зарплату больше.
Сам на рельсах пишу, в Новосибе вакансий вообще нету (или я где-то не там ищу). Поэтому приходится с зарубежниками работать. И тут возникает некая конкуренция: за рубежом платят больше, чем в среднем по России. Значит, если в России работать, то хочется зарплату не ниже. Возможно еще и поэтому многие рельсовики требуют зарплату больше.
Пузырь, потому, что язык распиарили, а специалистов под него недостаточно.
На Ruby, тоже, хватает некомпетентных программистов. Нет, конечно, новичков в программировании относительно мало, плюс все сразу с Rails начинают, а не с устаревших говно-CMS, где файлы по 2к строк без единой фукнции, не говоря уже о классах. Еще там сразу git, тесты и другие строгости.
Но видел уже разное, хотя опыт и минимальный.
Rails хороший фреймворк, кто спорит? Я о том и говорю, что на PHP есть фреймворки со скопированной идеологией, есть более строгие с хорошо проработанным ООП, есть упрощенные, любой на выбор. И я говорю о качественные MVC-фреймворках с ORM и аналогом роутов.
Если отбросить нюансы, что как язык Ruby лучше PHP, глупо это не признавать. Но, на мой взгляд, уже не настолько, что бы перевешивать плюсы инфраструктуры PHP, которые только укрепились.
На Ruby, тоже, хватает некомпетентных программистов. Нет, конечно, новичков в программировании относительно мало, плюс все сразу с Rails начинают, а не с устаревших говно-CMS, где файлы по 2к строк без единой фукнции, не говоря уже о классах. Еще там сразу git, тесты и другие строгости.
Но видел уже разное, хотя опыт и минимальный.
Rails хороший фреймворк, кто спорит? Я о том и говорю, что на PHP есть фреймворки со скопированной идеологией, есть более строгие с хорошо проработанным ООП, есть упрощенные, любой на выбор. И я говорю о качественные MVC-фреймворках с ORM и аналогом роутов.
Если отбросить нюансы, что как язык Ruby лучше PHP, глупо это не признавать. Но, на мой взгляд, уже не настолько, что бы перевешивать плюсы инфраструктуры PHP, которые только укрепились.
Да никто ничего не пиарит, я особенно и не замечаю (-:
Закрепилась не инфраструктура, а стереотипы. 9 из 10 студий предложат сайт на пхп. Потому что другого в наличии нет, а на 500$ всегда можно взять студента.
И не высок/низок порог вхождения в руби/пхп, а порог развёртывания приложения и количество недорогих хостеров. Вот большинство и идёт по пути наименьшего сопротивления: побыстрее нагенерить всякой лабуды и запихнуть в биржи ссылок.
Закрепилась не инфраструктура, а стереотипы. 9 из 10 студий предложат сайт на пхп. Потому что другого в наличии нет, а на 500$ всегда можно взять студента.
И не высок/низок порог вхождения в руби/пхп, а порог развёртывания приложения и количество недорогих хостеров. Вот большинство и идёт по пути наименьшего сопротивления: побыстрее нагенерить всякой лабуды и запихнуть в биржи ссылок.
А студент, знающий ruby, за 500 уже не пойдёт?
Владельцы программистских контор пиарят RoR, что бы обосновать завышенные зарплаты (и свои проценты) своим заказчикам.
В общем, для меня это выражается в том, что уже не один PM мне говорил, что на RoR разработка в разы быстрее, код не получится плохим и его сможет поддерживать любой программист, итд итп. На вопросы как и почему, ничего внятного не отвечают, в лучшем случае что-то очень общее про гемы и ORM скажут.
Я готов поверить, что лет так 7 назад, когда Rails только набирал обороты он был единственным веб-фреймворком современного типа и действительно давал существенный прирост в разработке. Но даже если так, то информация уже сильно устарела.
Да многие, идут по пути наименьшего сопротивления и в данном случае, на мой взгляд, это оправдано.
В общем, для меня это выражается в том, что уже не один PM мне говорил, что на RoR разработка в разы быстрее, код не получится плохим и его сможет поддерживать любой программист, итд итп. На вопросы как и почему, ничего внятного не отвечают, в лучшем случае что-то очень общее про гемы и ORM скажут.
Я готов поверить, что лет так 7 назад, когда Rails только набирал обороты он был единственным веб-фреймворком современного типа и действительно давал существенный прирост в разработке. Но даже если так, то информация уже сильно устарела.
Да многие, идут по пути наименьшего сопротивления и в данном случае, на мой взгляд, это оправдано.
Ну я не знаком с владельцами, которые пишут только на рельсах. Чаще скорее наоборот: только на пхп.
Видите ли, в чём ещё дело… в мире руби рельсы — это 98% от всех используемых фреймворков. есть другие, но они не стоят даже рядом. Поэтому рельсы — это как стандарт. Практически любой рубист откроет проект на рельсах и легко разберётся.
В пхп слишком велико разнообразие фреймворков… Я не говорю, что они плохие, просто они разные. И различие между Zend, Yii или там CI достаточно велико. Это не хорошо и не плохо, это просто факт. И при переключении с одного фреймворка на другой не знакомый будет некоторая задержка.
Видите ли, в чём ещё дело… в мире руби рельсы — это 98% от всех используемых фреймворков. есть другие, но они не стоят даже рядом. Поэтому рельсы — это как стандарт. Практически любой рубист откроет проект на рельсах и легко разберётся.
В пхп слишком велико разнообразие фреймворков… Я не говорю, что они плохие, просто они разные. И различие между Zend, Yii или там CI достаточно велико. Это не хорошо и не плохо, это просто факт. И при переключении с одного фреймворка на другой не знакомый будет некоторая задержка.
Имхо, вообще сомнительно, что сильно больше чем 1 из 10 программистов пишет тесты… И не факт, что это плохо…
Потому многие на него и переходят, как только уровень позволит. А это, обычно, происходит раньше, чем человек осилил нормальные фреймворки на php и полноценно использует хотя бы PHP 5.3.
любой фреймворк — это жертва производительностью в угоду удобству и фичам. чем больше фич — тем более это заметно на производительности.
и если для того, чтобы нормально программировать на языке X нужны фреймворки — это плохой язык.
любой фреймворк — это жертва производительностью в угоду удобству и фичам. чем больше фич — тем более это заметно на производительности.
и если для того, чтобы нормально программировать на языке X нужны фреймворки — это плохой язык.
UFO just landed and posted this here
Для PHP не нужны, он сам микрофреймворк по сути. Важность этого факта уменьшается, но до ноля ещё далеко.
что вы подразумеваете «для веба»?
вот серверную часть простенького чатика на php сколько времени вы будете писать? чатик выбран как частный случай ситуации, когда у вас, допустим, 8к клиентов и им всем надо разослать идентичные данные(это может быть и сервис с курсами валют/пробки итп).
вот серверную часть простенького чатика на php сколько времени вы будете писать? чатик выбран как частный случай ситуации, когда у вас, допустим, 8к клиентов и им всем надо разослать идентичные данные(это может быть и сервис с курсами валют/пробки итп).
А есть (с точки зрения написания) большая разница писать на php, python или C чатик (если не пользоваться многопоточностью)? Так же слушаем сокет, также его обрабатываем.
>Так же слушаем сокет, также его обрабатываем.
отличное описание! 99% протоколов с логикой запрос/ответ попадают под это определение.
не стесняйтесь, раскройте мысль, потаённую в «обрабатываем».
давайте даже упростим: события(и сообщения) генерирует само приложение.
отличное описание! 99% протоколов с логикой запрос/ответ попадают под это определение.
не стесняйтесь, раскройте мысль, потаённую в «обрабатываем».
давайте даже упростим: события(и сообщения) генерирует само приложение.
Ну я же не знаю протокол чатика :) Но суть одна и та же — биндинги к сокетным функциям ОС.
Про «упростим» немного не понял. В каком виде получаем сообщения? Нужна ли чатику работа с тормозными функциями типа работы с БД или ФС? Блокировки ресурсов и т. п.?
Кстати, простенький чатик делается вообще через авторефреш страницы и тут уже совсем без разницы на чём его делать. PHP вон пишут выдерживает 800 rps (правда железо не описано).
Про «упростим» немного не понял. В каком виде получаем сообщения? Нужна ли чатику работа с тормозными функциями типа работы с БД или ФС? Блокировки ресурсов и т. п.?
Кстати, простенький чатик делается вообще через авторефреш страницы и тут уже совсем без разницы на чём его делать. PHP вон пишут выдерживает 800 rps (правда железо не описано).
>Про «упростим» немного не понял. В каком виде получаем сообщения?
допустим, раз в секунду рассылать всем подключенным клиентам json вида:
{«time»:«unix_timestamp», «connected»: число_клиентов_онлайн }
допустим, раз в секунду рассылать всем подключенным клиентам json вида:
{«time»:«unix_timestamp», «connected»: число_клиентов_онлайн }
Вариантов много, от написания своего веб-сервера до авторефреша страницы браузере, а страницу через apache+cgi отдавать. Количество клиентов онлайн можно хранить в локальном контексте сервера, а можно на удаленном сервере и изменять/получать через SOAP.
Принципиальной разницы на чём это писать не вижу, разве что в некоторых языках это может оказаться в стандартной либе, а в некоторых сторонние придётся подключать.
Другое дело, если по каким-то причинам использовать cgi не следует :)
Принципиальной разницы на чём это писать не вижу, разве что в некоторых языках это может оказаться в стандартной либе, а в некоторых сторонние придётся подключать.
Другое дело, если по каким-то причинам использовать cgi не следует :)
>Количество клиентов онлайн можно хранить в локальном контексте сервера, а можно на удаленном сервере и изменять/получать через SOAP.
а можно просто в мемкеше держать и через incr/decr менять :)))
>Другое дело, если по каким-то причинам использовать cgi не следует :)
например по той, что изначально упомянуто 8к клиентов онлайн, т.е. у вас 8к файловых дескрипторов на которых вы ждёте какие-то события.
если же рефрешить страничку, допустим, 1 раз в секунду — это 8к rps, на котором cgi так же умрёт.
если же взять не json, а google protobuf, то можно хорошо сэкономить на трафике. Вот только весь профит бинарного протокола будет сведён на ноль http-заголовками в варианте с рефрешем.
а можно просто в мемкеше держать и через incr/decr менять :)))
>Другое дело, если по каким-то причинам использовать cgi не следует :)
например по той, что изначально упомянуто 8к клиентов онлайн, т.е. у вас 8к файловых дескрипторов на которых вы ждёте какие-то события.
если же рефрешить страничку, допустим, 1 раз в секунду — это 8к rps, на котором cgi так же умрёт.
если же взять не json, а google protobuf, то можно хорошо сэкономить на трафике. Вот только весь профит бинарного протокола будет сведён на ноль http-заголовками в варианте с рефрешем.
UFO just landed and posted this here
ну тут упоминали facebook и проекты с высокой посещаемостью.
и вроде как на дворе мир web2.0 с реалтаймом.
websockets есть уже почти везде, на подходе webRTC.
а странички с посещаемостью полчеловека в минуту писать можно на чём угодно.
и вроде как на дворе мир web2.0 с реалтаймом.
websockets есть уже почти везде, на подходе webRTC.
а странички с посещаемостью полчеловека в минуту писать можно на чём угодно.
UFO just landed and posted this here
Автор исходной статьи пишет, что при достаточно высокой квалификации грабельки, заботливо положенные авторами языка можно объезжать.
В facebook было написано много кода на php и когда возникли сложности с производительностью, как я понимаю, дешевле оказалось изобрести hiphop, нежели переписывать и переучивать имеющийся штат разработчиков.
Всё, опять же, сводится к правильному инструменту под задачу. Беда php в том, что уж очень много задач, для которых есть инструменты лучше.
Например, много ли вы знаете серверов трансляций на php?
на эрланге есть erlyvideo, на python — flumotion (да и я писал свой сервер для онлайн трансляции — 19к онлайн-клиентов на тестах было. написано на python).
В facebook было написано много кода на php и когда возникли сложности с производительностью, как я понимаю, дешевле оказалось изобрести hiphop, нежели переписывать и переучивать имеющийся штат разработчиков.
Всё, опять же, сводится к правильному инструменту под задачу. Беда php в том, что уж очень много задач, для которых есть инструменты лучше.
Например, много ли вы знаете серверов трансляций на php?
на эрланге есть erlyvideo, на python — flumotion (да и я писал свой сервер для онлайн трансляции — 19к онлайн-клиентов на тестах было. написано на python).
Но эти задачи не самые распространенные (в количестве постановок). И я не думаю, что будет хорошей идеей (для меня) говорить работодателю, что, скажем, ему нужно нанимать python-программиста вместо меня. Да покупать (v)DS вместо шареда, да ещё грамотного админа в комплекте. Действительно, мне «дешевле» «изобрести» hiphop.
UFO just landed and posted this here
Переход на питон и джангу для среднего пхп-разработчика это вообще не проблема, как почему-то многие пытаются представить.
Кстати, да, согласен. И даже без роста доходов с радостью бы перешёл. Перейти с ZF или Symfony2 на RoR или Django не сильно сложнее чем на Yii или CakePHP. MVC он в Африке MVC, а писать всё же приятней. Про тех, кто писал только под WordPress или Joomla -отдельный разговор, их средними php-разработчиками язык не поворачивается называть.
Кстати, да, согласен. И даже без роста доходов с радостью бы перешёл. Перейти с ZF или Symfony2 на RoR или Django не сильно сложнее чем на Yii или CakePHP. MVC он в Африке MVC, а писать всё же приятней. Про тех, кто писал только под WordPress или Joomla -отдельный разговор, их средними php-разработчиками язык не поворачивается называть.
«Реалтайм» (без хайлоада) тоже на чём угодно можно писать (серверную часть), тормозить будут, имхо, прежде всего СУБД/ФС. Другое дело, что межзапросное кэширование на PHP стандартными средствами не очень тривиально. То же чтение настроек приложения из конфига на каждый запрос и вообще его явная инициализация явно избыточны, но, увы, многие приложения не рассчитаны на работу в условиях когда после завершения работы не происходит полная реинициализация глобального контекста. Но, имхо, это проблема больше разработчиков, а не языка. На любом языке я тоже напишу приложение, которое работает только в CGI режиме.
смотря что за субд. если речь о рсубд — тут да. если же мы говорим о mongo или хранилищах вроде redis/tarantool — то это весьма сложно.
>То же чтение настроек приложения из конфига на каждый запрос и вообще его явная инициализация явно избыточны
для этого надо настройки хранить в mongo, сам конфиг кешировать в рамках процесса.
>Но, имхо, это проблема больше разработчиков, а не языка. На любом языке я тоже напишу приложение, которое работает только в CGI режиме.
а на любом языке вы сделаете «горячую» замену кода в работающем приложении?
на python я такую штуку сделал.
>То же чтение настроек приложения из конфига на каждый запрос и вообще его явная инициализация явно избыточны
для этого надо настройки хранить в mongo, сам конфиг кешировать в рамках процесса.
>Но, имхо, это проблема больше разработчиков, а не языка. На любом языке я тоже напишу приложение, которое работает только в CGI режиме.
а на любом языке вы сделаете «горячую» замену кода в работающем приложении?
на python я такую штуку сделал.
Я и на монго напишу тормозяще :) Ну нет, вроде быстродействующих средств осуществлять композицию. Агрегацию есть, а композицию нет. Как не крути, но получить сравнимое время выборки, скажем, по комментам на хабре и по топику, и по автору получится только если оба будут тормозить. Или дублировать информацию для разных срезов.
Над остальными задачами не думал.
Над остальными задачами не думал.
На php горячую замену кода делали люди года 3-4 назад. В чем собственно вопрос?
Но она нужна лишь для тех «костыльных» приложений на других языках, которые не работают в изначальной идеологии php — запустился, быстро отработал, умер.
Но она нужна лишь для тех «костыльных» приложений на других языках, которые не работают в изначальной идеологии php — запустился, быстро отработал, умер.
Очевидно, все твои проекты «СЕРЬЕЗНЕЕ» этих: facebook, контакт, youtube, wikipedia,…?
Очевидно, все Твои новые проекты «серьезнее» этих: fracebook, youtube, wikipedia, контакт?
> Я имею в виду весь этот рынок CMS, на котором к PHP конкуренты просто не подберутся и на пушечный выстрел (Wordpress, Joomla!, Drupal, vBulletin, MODx, TYPO и т. д.).
И слава богам. Последнее, что я хотел бы увидеть в своей жизни это массово-разрабатываемые cms-ки на rails.
И слава богам. Последнее, что я хотел бы увидеть в своей жизни это массово-разрабатываемые cms-ки на rails.
Согласен с вами :) Хорошо, что комьюнити рельс пока не страдает от перенасыщения «хреновых» разработчиков.
Вы правы, но все же, какие на python/ruby есть хорошие аналоги Wordpress/Magento/MODx/etc., хотя бы по одной на область применения? Иначе получается не язык, а игрушка для высоких нагрузок (пишем с нуля) или просто поиграться (пишем с нуля). Я хотя и пхп-ник, но пишу на Синатре (очень уж мне нравится) и изредка на RoR. Но без нормальной работы, например, в финансовой сфере, продажи, магазины, язык так и остается «для избранных».
spreecommerce.com/
В нее недавно влили достаточно денег, чтобы она стала очень крутой :) Я уже молчу о том, что система расширений рвет в жопу магенту.
В нее недавно влили достаточно денег, чтобы она стала очень крутой :) Я уже молчу о том, что система расширений рвет в жопу магенту.
Я смутно понимаю необходимость CMS на рельсах. Для более-менее нестандартного сайта все равно придется кастомизировать CMS, добавлять какие-то свои модули и т.д. За аналогичное время безо всяких CMS собирается кастомный сайт со сторонними гемами. Нужен и-нет магаз – бери spree, нужны блоги/новости – есть много готовых решений, хотя и свое пишется за 5 минут. Нужна админка – activeadmin, нужно что-то еще – поищи нужный гем, с вероятностью 99% что-то готовое уже есть.
+ совсем не понял про «для избранных»: куча вакансий, куча проектов. Конечно, меньше, чем на php, но достаточно :)
+ совсем не понял про «для избранных»: куча вакансий, куча проектов. Конечно, меньше, чем на php, но достаточно :)
Ниша one-click-cms'очек давно забита php и это нормально, другой вопрос, что при реквест кастомной фичи от заказчика начинается ад в глаза php программистов. Я собственно говоря имел опыт, когда рельсовиков пригласили взамен php, потому что поддерживать drupal ни у кого уже не было сил :)
Многие нестандартные сайты начинаются со стандартных, в которых сразу нужны магазин, блог, новости и админка (в терминах предметной области, а не структуры БД). Плюс возможность устанавливать сторонние модули из этой админки «в один клик», без программирования и консоли. То есть CMS это продукт для веб-мастера, а то и вообще менеджера, а не программиста. Самое главное в нём, пожалуй, как раз админка.
Хм, ну поставить CMS и начать работать сразу, не будучи программистом – ладно, довод в пользу CMS. Только вот решение это не оч дальновидное с точки зрения бизнеса: бизнес так или иначе вырастет, потребуется что-то нестандартное и придется звать программиста, который будет все это дело кастомизировать. Но кастомизировать он будет уже что-то готовое. И не факт, что выбранное правильно (может менеджер плохую CMS выбрал, он ведь может такое :)
И вот тут возникает проблема: кастомизировать уже готовое или написать заново. Владелец бизнеса очень неохотно (судя по моему опыту) пойдет на переписывание, т.к. с его точки зрения кастомизировать проще. Но адекватный человек за такую неблагодарную работу захочет довольно много денег, чтобы компенсировать свои предстоящие душевные травмы. Владелец бизнеса столько платить, возможно, не захочет и наймет кого-то другого с более низкой квалификацией за 100р. Замкнутый круг.
Мораль такова: каждый должен делать свое дело. Программист – разрабатывает, веб-мастер поддерживает, менеджет штаны просиживает.
И вот тут возникает проблема: кастомизировать уже готовое или написать заново. Владелец бизнеса очень неохотно (судя по моему опыту) пойдет на переписывание, т.к. с его точки зрения кастомизировать проще. Но адекватный человек за такую неблагодарную работу захочет довольно много денег, чтобы компенсировать свои предстоящие душевные травмы. Владелец бизнеса столько платить, возможно, не захочет и наймет кого-то другого с более низкой квалификацией за 100р. Замкнутый круг.
Мораль такова: каждый должен делать свое дело. Программист – разрабатывает, веб-мастер поддерживает, менеджет штаны просиживает.
Для бизнеса зачастую определяющим является минимизация стартовых затрат денег и времени. Грубо говоря, побыстрее и подешевле запустить. И однозначно сказать, что это недальновидно сложно. Потратить час/день/неделю/месяц работы веб-мастера или день/неделю/месяц/год работы программиста ради сайта, на который неизвестно зайдёт ли вообще кто-то нибудь кроме директора? Очень многие постараются минимизировать риски потери денег. И «скупой платит дважды» тут не совсем корректно употреблять.
А вот если сайт, запущенный за час, уже начал приносить деньги, то тут уже другие критерии должны работать, да и заплатить хорошо хоть за квалифицированную переделку с ноля, хоть за квалифицированную кастомизацию можно себе позволить, не трогая другие статьи доходов, не изымая денег из оборотных капиталов, а на «самообеспечении».
А вот если сайт, запущенный за час, уже начал приносить деньги, то тут уже другие критерии должны работать, да и заплатить хорошо хоть за квалифицированную переделку с ноля, хоть за квалифицированную кастомизацию можно себе позволить, не трогая другие статьи доходов, не изымая денег из оборотных капиталов, а на «самообеспечении».
"… потому что хотя он и не безупречен, он работает…" — самые главные слова. Соглашусь со всем. Статья «PHP: a fractal of bad design» настолько массивна, что у читателя не возникает сомнений, что что-то там может быть неправдой. Спасибо за перевод :)
Не буду особо цепляться, НО:
HTTP – это объект первого класса. Никакие другие популярные языки этого не предоставляют. Ни Python, ни Ruby, ни C, ни JavaScript. PHP и HTTP – одного поля ягоды. Вы можете поспорить, что это не так оптимально, но это первый класс. Вам не надо никаких библиотек или фреймворков, чтобы говорить на HTTP.
HTTP — не объект, а протокол )))
PHP и HTTP разного поля ягоды, ибо одно — язык программирования, а другое протокол передачи гипертекста
Вам обязательно надо библиотеки и/или фреймворки, потому что иначе вы напишете ужаснейший велосипед на PHP в котором будет куча дыр. Да и если вы будете писать на голом PHP работу вы вряд ли найдёте приемлимую.
HTTP – это объект первого класса. Никакие другие популярные языки этого не предоставляют. Ни Python, ни Ruby, ни C, ни JavaScript. PHP и HTTP – одного поля ягоды. Вы можете поспорить, что это не так оптимально, но это первый класс. Вам не надо никаких библиотек или фреймворков, чтобы говорить на HTTP.
HTTP — не объект, а протокол )))
PHP и HTTP разного поля ягоды, ибо одно — язык программирования, а другое протокол передачи гипертекста
Вам обязательно надо библиотеки и/или фреймворки, потому что иначе вы напишете ужаснейший велосипед на PHP в котором будет куча дыр. Да и если вы будете писать на голом PHP работу вы вряд ли найдёте приемлимую.
> Да и если вы будете писать на голом PHP работу вы вряд ли найдёте приемлимую.
А вот в этом я не уверен. PHP позволяет с минимальными усилиями писать программный код любому индивиду, способному хоть как-то последовательно формулировать выполнение задач (порядок действий). На рынке труда программистов не хватает, очень не хватает. Поэтому на работу обладая даже минимальными навыками в PHP устроится легко. Зарплата, конечно, будет низкой, но зато это работа в офисе, и есть прямой путь профессионального роста.
А вот в этом я не уверен. PHP позволяет с минимальными усилиями писать программный код любому индивиду, способному хоть как-то последовательно формулировать выполнение задач (порядок действий). На рынке труда программистов не хватает, очень не хватает. Поэтому на работу обладая даже минимальными навыками в PHP устроится легко. Зарплата, конечно, будет низкой, но зато это работа в офисе, и есть прямой путь профессионального роста.
>PHP позволяет с минимальными усилиями писать программный код любому индивидуинвалиду, способному хоть как-то последовательно формулировать выполнение задач (порядок действий).
Не удержался, простите:)
Не удержался, простите:)
я с вами согласен, но как бы я не любил php думаю всю жизнь на такой работе не проживешь :(
Почему нет если не забывать о саморазвитии? Работа в проектах с многомиллионной, а то и почти миллиардной аудиторией не может быть достаточно интересной разве?
интересна, стремлюсь к этому как могу, даже фейсбук доказал что на пхп можно делать огромные приложения, просто не хочу знать только один язык, их ведь так много и каждый заточен под свои задачи, думаю будет правильно использовать все что есть а не зацикливатся. в общем это только мое мнение.
Facebook транслирует PHP-код в С++ код и выполняется нативно.
См. HipHop
См. HipHop
Ну и что? А С++ тоже компилится и выполняется нативно. Главное, какой язык читают люди.
для python есть транслятор cython.
интеграция с сишными/плюсовыми библиотеками делается за несколько минут.
не нравится встроенная реализация регекспов? ок, можно взять из libpcre/re2 или яндексовскую pire ( clubs.ya.ru/company/replies.xml?item_no=30753 )
хотим actor model(в erlang-style) — берем gevent + zeromq.
бесшовная интеграция с C++ (и наоборот).
Основная идея оптимизации со скриптовыми языками — это профайлинг + переписывание горячих участков на C/C++.
Легко ли это делать для php?
интеграция с сишными/плюсовыми библиотеками делается за несколько минут.
не нравится встроенная реализация регекспов? ок, можно взять из libpcre/re2 или яндексовскую pire ( clubs.ya.ru/company/replies.xml?item_no=30753 )
хотим actor model(в erlang-style) — берем gevent + zeromq.
бесшовная интеграция с C++ (и наоборот).
Основная идея оптимизации со скриптовыми языками — это профайлинг + переписывание горячих участков на C/C++.
Легко ли это делать для php?
Зацикливаться зачастую заставляют внешние по отношению к собственно разработке условия, экономические например.
«Да и если вы будете писать на голом PHP работу вы вряд ли найдёте приемлимую.», но разве чистый PHP не является основой а «библиотеки и/или фреймворки» подбираются под конкретную задачу?
Я например некоторые библиотеки сам себе писал, так сказать под себя.
Например свое подобие ActiveRecord'а
Ну да, каждый PHP-программист должен написать СвоюСамуюЛучшуюВмире ЦМС )))
И что в этом плохого? Если бы это было не так, то тот же WordPress не появился бы, как и куча других популярных CMS. А так есть конкуренция, есть развитие.
На самом деле написание собственной ORM отлично прокачивает скил проектирования, особенно если уйти в сторону от ActiveRecord и прочитать в процессе разработки соответствующую литературу (для начала, «шаблоны корпоративных приложений», потом может и на UML потянет и т.д.).
Безусловно, библиотеки нужны, но знать как они устроены и быть способным при необходимости написать что-то большее гораздо важнее для профессионального программиста. Кроме того, развитая способность к разработке чего то нестандартного позволит перейти на уровень выше и стать проектировщиком, с этого момента часть скучной и неинтересной работы по написанию очевидного кода (= рутины) можно переложить на тех кто в это время полностью освоил какой либо разработанный вами framework :)
Поэтому изучение одного framework-а, который все делает за вас, считаю тупиковым, т.к. он ведет к отмиранию способности проектировать что-то большее чем набор контроллером в моделей (если это вообще можно считать проектированием). И кстати, тут на хабре где-то год назад наверное проскакивал топик/вопрос от человека который пошел по пути потребления и в итоге обнаружил, что стал не способен создать ничего нового. Найти не смог, к сожалению.
Поэтому велосипедить надо, но в меру.
Безусловно, библиотеки нужны, но знать как они устроены и быть способным при необходимости написать что-то большее гораздо важнее для профессионального программиста. Кроме того, развитая способность к разработке чего то нестандартного позволит перейти на уровень выше и стать проектировщиком, с этого момента часть скучной и неинтересной работы по написанию очевидного кода (= рутины) можно переложить на тех кто в это время полностью освоил какой либо разработанный вами framework :)
Поэтому изучение одного framework-а, который все делает за вас, считаю тупиковым, т.к. он ведет к отмиранию способности проектировать что-то большее чем набор контроллером в моделей (если это вообще можно считать проектированием). И кстати, тут на хабре где-то год назад наверное проскакивал топик/вопрос от человека который пошел по пути потребления и в итоге обнаружил, что стал не способен создать ничего нового. Найти не смог, к сожалению.
Поэтому велосипедить надо, но в меру.
Упс, промахнулся, это ответ на ироничный комментарий solver-а
Создание сайтов давным-давно стало рутиной. Зачем искать что-то там, где уже ничего нет?
Если создание сайтов — рутина, бессмысленная и беспощадная, изучение одного-двух хороших фреймворков позволяет справляться с этой рутиной быстрее и безболезненней, оставляя время на личную жизнь и развитие в более перспективных профессиональных областях…
Если создание сайтов — рутина, бессмысленная и беспощадная, изучение одного-двух хороших фреймворков позволяет справляться с этой рутиной быстрее и безболезненней, оставляя время на личную жизнь и развитие в более перспективных профессиональных областях…
> Создание сайтов давным-давно стало рутиной.
К счастью интересные задачи все еще встречаются.
> более перспективных профессиональных областях…
Проектирование, по вашему, недостаточно перспективно?
К счастью интересные задачи все еще встречаются.
> более перспективных профессиональных областях…
Проектирование, по вашему, недостаточно перспективно?
Ну так само собой, php-программистов — миллионы, никто их не пускает в серьезные интересные проекты. Интересный проект гораздо проще получить если ты рельсовик или питонист :)
Уж слишком вы категоричны.
Не соглашусь с вами.
Знаю системы на РНР, которые работают на целую республику.
Питонистов и рубистов туда никто не пускает.
Да и, уж простите, но Фейсбук также с вами не согласен.
Не соглашусь с вами.
Знаю системы на РНР, которые работают на целую республику.
Питонистов и рубистов туда никто не пускает.
Да и, уж простите, но Фейсбук также с вами не согласен.
Вы меня не так поняли, потому что я не очень хорошо выразился. Суть в том, что найти хорошую работу среднестатистическому php программисту труднее, чем рельсовику :) Мне, по крайней мере, так кажется.
А на счет вашего тонкого замечания в сторону рельс — я вот сейчас работаю над проектом где мы используем Rails + EventMachine (руби аналог node.js) + websocket и прочие comet реализации.
А на счет вашего тонкого замечания в сторону рельс — я вот сейчас работаю над проектом где мы используем Rails + EventMachine (руби аналог node.js) + websocket и прочие comet реализации.
p.s. И что для вас «интересный» проект? Сборка готовых гемов?
WP отличная штука, слава богу, что наблюдается последнее время тренд ухода с него на более легкие и человечные решения, по крайней мере в прослойке программистов :)
WP отличная штука
С точки зрения пользователя — бесспорно, а с точки зрения разработчика и интегратора… ну, it depends. Уж сколько говнокодерских плагинов и шаблонов (среди коммерческих в том числе) к нему, просто не пересчитать. Никогда не угадаешь, где тебя бомба замедленного действия поджидает, через которую могут весь сайт положить.
Мало того я ее написал и скоро представлю на обозрение, не сказал бы что она лучшая, но во всяком случае для меня она в разы проще как в написании модулей так и в обработке контента, а оно и естественно потому что сделана на собственном мини MVC фреймворке, при этом функционал не меньше чем у вордпресс + есть модуль магазина =).
Наверное очень красиво получилось =P
)))) Ну актив рекорд типа того
$order_cart = Db_Lib::Init()
-> select(«shop_orders_products», "*")
-> where(array(«id_order» => $_GET['id']))
-> query()
-> fetch_rows();
$order_cart = Db_Lib::Init()
-> select(«shop_orders_products», "*")
-> where(array(«id_order» => $_GET['id']))
-> query()
-> fetch_rows();
Ну наверное это красиво, я на php не работаю слава богу, в рельсе было бы как-то так:
но вы продолжайте ;)
ShopOrderProducts.find(params[:id])
но вы продолжайте ;)
И зачем вы так? =) Пошел учить рельсу )))))
ShopOrderProducts.find(params[:id])Ну на пхп тоже можно так написать:
ShopOrderProducts::find($params->id)
Покажите, что стоит за вашим find.
На пхп? Вызвать метод класса? Или может это какая-то библиотека? ;)
Я так понимаю вам интересен оверхед от всех этих красивых абстракций? Ну так вот — он небольшой ;) Проекты с нагрузкой нормально работают.
Я так понимаю вам интересен оверхед от всех этих красивых абстракций? Ну так вот — он небольшой ;) Проекты с нагрузкой нормально работают.
Ну да. Что на пхп, что на руби можно написать библиотеку, которая предоставит такой синтаксис.
Вопрос в том, что надо сделать, чтобы можно было писать это.
Я не про производительность. Уверен, запрос к базе, что в пхп, что в руби выполнится с одной скоростью.
Вопрос в том, что надо сделать, чтобы можно было писать это.
Я не про производительность. Уверен, запрос к базе, что в пхп, что в руби выполнится с одной скоростью.
Ну если хотите использовать ActiveRecord без рельс, то можно сделать что-то подобное — snippets.aktagon.com/snippets/257-How-to-use-ActiveRecord-without-Rails, при этом надо понимать, вы из коробки будете иметь разные енвайроменты, миграции и тп.
Ну и в ПХП можно использовать какую-либо библиотеку (например, Doctrine), которая предоставляет интерфейс. Сам не использовал, т.к. сидел на Kohana, а потом ушёл из серверного программирования
Я кстате и не спорю, что в php тоже есть хорошие решения, беда в том, что вы первый человек в этом треде, который говорит об этом ;)
А зачем играть в а у меня есть то-то а у меня есть то-то, это не конструктивно.
Я кстате и не спорю, что в php тоже есть хорошие решения, беда в том, что вы первый человек в этом треде, который говорит об этом ;)
Ну в кое-каком роде согласен, что пхп — это фильтр, на котором отсеялось и осталось огромное количество горе-разработчиков.
Но надо быть и объективным тоже ;)
Зачем говорить об очевидных вещах?
Но если хочется… Кстати, а в руби запилили поддержку DataMappper, UnitOfWOrk и т. п.? Или всё так же любой проект на рельсах с БД нарушает принцип единственной ответственности? :)
Но если хочется… Кстати, а в руби запилили поддержку DataMappper, UnitOfWOrk и т. п.? Или всё так же любой проект на рельсах с БД нарушает принцип единственной ответственности? :)
У рельс один простой паттерн — ActiveRecord, сами понимаете, он отличается от UnitOfWork.
dm -> datamapper.org/ (http://rubydoc.info/gems/datamapper2/0.0.1/DataMapper/UnitOfWork)
dm -> datamapper.org/ (http://rubydoc.info/gems/datamapper2/0.0.1/DataMapper/UnitOfWork)
TableDataGateway ещё проще :)
А этот DataMapper как-то производит впечатление, что в нём от паттерна только название.
Как-то это у меня с ActiveRecord больше ассоциируется.
А этот 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 больше ассоциируется.
Подозреваю, что без кодогенератора не получится. В руби, если не изменяет память, как и в JS, класс — это тоже объект, и в него можно сколько угодно добавлять методы. А вот в PHP такое не прокатит.
Подобное можно сделать через магические методы и callback-и
class ShopOrderProductsTable extends AbstractTable {
protected $tableName = 'shop_orders_products';
public function findByOrderId ($id) {
return $this->find(['order_id' => $id]);
}
Как-то так можно обходиться без кодогенерации. Зачем добавлять методы динамически, если структура БД известна на этапе «компиляции»?
Я так понимаю, тут спорят об active record. А там не принято создавать отдельный класс на entity и отдельный — на таблицу. Там сам entity содержит статические методы для поиска по множеству объектов данного типа. Вот я про такое и писал. Вот только действительно, в 5.3 появился __callStatic, который и такое может. Однако, мне не совсем понятно, как оно будет работать с наследованием, да и сама необходимость наследования несколько смущает.
Это я отношу к деталям реализации. И, да, можно заменить на статические методы класса сущности — дело вкуса, имхо. Но я не понимаю зачем нужны __callStatic и прочее метапрограммирование для использования ActiveRecord? Наследования вполне достаточно. В базовом классе универсальный метод поиска, в наследниках — конкретные ради соблюдения DRY и инакпсуляции, которые вызывают универсальный базового
Но я не понимаю зачем нужны __callStatic и прочее метапрограммирование для использования ActiveRecord? Наследования вполне достаточно. В базовом классе универсальный метод поиска, в наследниках — конкретные ради соблюдения DRY и инакпсуляции, которые вызывают универсальный базового
Вопрос: кто реализует конкретные статические методы в наследниках? И всё-таки, наследование реализации — это не самый лучший подход, особенно, если требуется «унаследовать» статические методы.
Наследник реализует. Расширяет интерфейс родителя. У родителя, скажем, только find(), ну, пускай findById(). Наследник (пускай для класса записи в блоге) добавляет (при необходимости) findByTitle(), findByBody(), findByDate(), findByAuthor(), которые вызывают find базового класса с соответствующими параметрами.
Вот кто вас учил так поля называть? Почему не order_id? а? Вот схуяли тут id_order?
Больше всего ненавижу php за то, что нет никаких конвенций и каждый называет свои колонки как попало. Вот в чем беда php :)
Больше всего ненавижу php за то, что нет никаких конвенций и каждый называет свои колонки как попало. Вот в чем беда php :)
очень просто пробегая глазами по колонкам я сразу по префиксу понимаю что это поле идентификатор.
В общем идите почитайте как в рельсах придумали делать нейминг переменных и чего угодно так, чтобы потом блювать от нейминга, который люди любят применять в php. Попробуйте, это интересно по крайней мере.
мой проект не был задуман как опен сурц, поэтому я делал нейминги так как мне удобнее., за совет спасибо, почитаю
Ну и что? Если для себя — значит можно создавать и пораждать трешняк чтоли? Вы как программист всегда должны писать хороший код :)
Я все еще уверен что ставить префикс впереди удобнее и нагляднее )
Ушел обедать, всем приятного )
Ушел обедать, всем приятного )
может быть те, кто ставит минус дадут аргументацию?
мне на минусы как бы пофигу, просто интересно — неужели
id_primary
id_node
id_parent
name_last
name_first
status_view
status_action
не дает сразу понять какие колонки за что отвечают?
id_primary
id_node
id_parent
name_last
name_first
status_view
status_action
не дает сразу понять какие колонки за что отвечают?
Потому что среди «parent» и «id» для нас важнее «parent». Нам надо знать, что это "родительский идентификатор", а не "идентификатор родителя". Аналогично с «view», к которому status всего-лишь дополняющий суффикс.
врят ли у нас будет несколько родительских идентификаторов, т.к. вся остальная информация подтянется по этому ключу, а вот идентификаторов впринципе у нас может быть несколько и глядя на колонки мы сразу видим что есть идентификаторы, что поля состояний, а что поля наименований.
А ваабще я думаю все зависит от структуры приложения и помоему свобода выбора в ПХП даже плюс, мало того если ты работаешь в готовом фреймворке тебе необходимо его изучить и ты после этого все равно будет использовать принятое там наименование. Все дело привычки. А бегать между разными разработками и надеятся что везде все будет одинаковое — безнадежно помоему.
Пхп как язык помоему изначально обречен был на обростание фреймворками, т.к. в нативном варианте он Уе**н простите )
Причем тут свобода? Вы вообще работали в команде? Руководили группой людей?
Есть конаны, которые позволяют делать хорошо, унифицированно в тех местах, где это нужно. Простой пример — нейминг колонок в бд, когда существуют некие правила — такой код можно отдать другому человеку и он с легкостью разберется в нем. В противном случае получается, что каждый городит свой велосипед в задачах, где это соверешенно ненужно. Кто-то называет колонку id как nid, vid или primary_id, а почему нельзя идентификатор объекта называть просто и понятно — id?
Есть конаны, которые позволяют делать хорошо, унифицированно в тех местах, где это нужно. Простой пример — нейминг колонок в бд, когда существуют некие правила — такой код можно отдать другому человеку и он с легкостью разберется в нем. В противном случае получается, что каждый городит свой велосипед в задачах, где это соверешенно ненужно. Кто-то называет колонку id как nid, vid или primary_id, а почему нельзя идентификатор объекта называть просто и понятно — id?
Ой не не не про тим кодинг я не спорю, я же говорю относительно своего проекта.
Я даже спорить не буду — в серьезном проекте самое главное и самая первая задача — это прописать изначально от и до весь стиль написания, раздать всем мануалы и заставить выучить.
Я даже спорить не буду — в серьезном проекте самое главное и самая первая задача — это прописать изначально от и до весь стиль написания, раздать всем мануалы и заставить выучить.
Вот и представте, такой мануал дается любому рубисту в каждой книге :) (рельсовику — тоже)
А теперь представте — все стараются писать хорошо с самого начала, а не только в биг-тимах.
А теперь представте — все стараются писать хорошо с самого начала, а не только в биг-тимах.
Да я не спорю, стандарты — это ваабще п**нно и мегакруто, но раз ПХП неимеет строгой стандартизации — это не повод его не использовать при его других плюсах.
Для разработчика действительно приятнее и полезнее и экономнее, когда он знает что возьмет другой проект и там будет все так, как он привык.
Увы в ПХП не так, но мне кажеться ПХП тем не менее достойный язык, и называть ПХП-кодеров ака Горе, негоже.
Для разработчика действительно приятнее и полезнее и экономнее, когда он знает что возьмет другой проект и там будет все так, как он привык.
Увы в ПХП не так, но мне кажеться ПХП тем не менее достойный язык, и называть ПХП-кодеров ака Горе, негоже.
Почему не будет? Денормализация мощный инструмент оптимизации. И ищу я прежде всего «родителя», а не «идентификатор». От общего к частному. В том месте где мне потребуется что-то от родителя, я сначала напишу parent, а лишь потом буду думать что мне нужен его идентификатор (да и IDE может не дать возможности думать, а подскажет что вариантов кроме parent_id собственно и нет), а вот мысль «мне нужен идентификатор, а потом разберусь чего» мне сложно представить.
Хотя, конечно, это лишь мой способ мышления. Но тогда, наверное, вам в подавляющем большинстве (всех) ООП ЯП не нравится, что приходится писать что вроде $parent->id, а не id->$parent?
Хотя, конечно, это лишь мой способ мышления. Но тогда, наверное, вам в подавляющем большинстве (всех) ООП ЯП не нравится, что приходится писать что вроде $parent->id, а не id->$parent?
Нет, просто вы сейчас на объекты перекинулись там естественно я выбрал бы вариант $parent->id, а я мыслил со стороны именно наименования колонок в бд, т.к. врятли в записи у меня parent будет упоминаться несколько раз.
$item->parent->id или $item->id->parent?Тем более не понятно, тут так мыслите, а тут так :)
А вот идентификаторы как раз могут много раз появляться. И не лучше ли уникальные части имён выносить вперёд, а их «тип» оставлять в качестве суффикса? Даже из чисто практических соображений: набираете код, нужен вам идентификатор родителя, набрали parent (а то и просто p) и умный редактор дополнил до parent_id (других вариантов нет, вы говорите). А так нужно набрать id_ (ну, i), а редактор до id_parent дополнить не сможет, так как у вас куча имён, начинающихся на id_. Лишних три нажатия клавиши на каждое использование.
А вот идентификаторы как раз могут много раз появляться. И не лучше ли уникальные части имён выносить вперёд, а их «тип» оставлять в качестве суффикса? Даже из чисто практических соображений: набираете код, нужен вам идентификатор родителя, набрали parent (а то и просто p) и умный редактор дополнил до parent_id (других вариантов нет, вы говорите). А так нужно набрать id_ (ну, i), а редактор до id_parent дополнить не сможет, так как у вас куча имён, начинающихся на id_. Лишних три нажатия клавиши на каждое использование.
а если есть child, next итд, то мне ненужно помнить какие они есть — я печатаю id_ и ide как бы подскажет какой именно нужен child, parent или next. Разве так не удобнее?
Все относительно и зависит от того пытаюсь ли я обратиться к вложенному объекту либо выбрать объект по значению свойства.
Вы просто привыкшие к Активрекордам не учитываете что в нативном пхп значение ячейки еще не является явной ссылкой на другой объект в другой таблице, а является как бы свойством объекта-строки, и только потом по желанию программиста по значению этого свойства может быть подгружен другой объект-запись из таблицы.
Меня сложно назвать привыкшим к активрекордам, я ещё на PHP3 писал говнокод, но уже тогда именовал поля как parent_id, а не id_parent. Для меня важнее всегда была сущность, а не её идентификатор. Да и просто
ON author.user_id = user.id
ON author.id_user = user.id
Мне IDE подскажет parent, child, next и т. п. сразу после нажатия ->, а вам надо будет ввести id_ :)
а разве он вам не подскажет еще и остальные колонки? name, status итд,
Он мне подскажет parent_id, parent_name, parent_status в одном месте, а вам раскидает по всему списку.
а зачем мне в записи держать что-то от парент кроме как его айди, по которому можно получить все остальное.
таблица1 — id, name
таблица2 — parent_name, parent_id
так чтоли? это же бред
таблица2 — parent_name, parent_id
так чтоли? это же бред
Чтобы получить это тем же запросом что и id, причём без тормозных джойнов. Страница с комментариями или форума — зачем чтобы вывести ник и ид (в ссылке) лезть в другую таблицу?
Да и опять возвращаемся к упоминанию об архитектуре и начинаем все по кругу, да действительно такие моменты бывают, поэтому чтобы обратиться к именам я уже буду писать name_parent или name_this. и буду знать что сейчас я обращаюсь к колонкам с именами того объекта с которым работаю, т.к. parent в данном случае мне ваабще не интересен, я даже не обращаюсь к нему а беру данные прямо из строки с которой работаю.
В ссылке нужно имя и ид. Имля для пользователя, ид для урла. Неужто
SELECT id_user, name_user удобнее чем SELECT user_id, user_name?
Я вас поддерживаю.
id_order лучше, чем order_id.
id_order лучше, чем order_id.
там и переменные и функции (включая base library) как попало названы :)
Ну что ж поделать, зато они его <<любят>> ;)
Нативный пхп, да неоднозначен, но в фреймворках вполне нормальные нейминги похожие на Java а-ля getModelAttribute() итд. и потом у ПХП есть преимущество — он поддерживается везде, коммюнити как ни крути шире и все оттуда вытекающее.
что вытекающее? Миллион программист, которые не знают что такое шаблонизатор?
программистов*
из большЕго комьюнити и поддержки вытекает следующее
бОльшее количество разработок, взять те же цмс
бОльшее количество разработчиков что дает более низкие цены на разработку ввиду конкуренции
этого уже достаточно.
бОльшее количество разработок, взять те же цмс
бОльшее количество разработчиков что дает более низкие цены на разработку ввиду конкуренции
этого уже достаточно.
из бОльшего* =)
Стоп стоп стоп. С чего вы взяли что на php больше разработок? CMS? Почему вы думаете что этого мало на руби?
Низкая цена — да. Вы представитель бизнеса?
Низкая цена — да. Вы представитель бизнеса?
Хотя бы с того что PHP популярнее и появился раньше.
en.wikipedia.org/wiki/List_of_content_management_systems
Вот тут посмотрите таблички, сколько ЦМС на Пыхе и Сколько на раби, вопросы еще есть?
Не совсем представитель бизнеса, но это важно иметь ввиду.
en.wikipedia.org/wiki/List_of_content_management_systems
Вот тут посмотрите таблички, сколько ЦМС на Пыхе и Сколько на раби, вопросы еще есть?
Не совсем представитель бизнеса, но это важно иметь ввиду.
И дальше то что? Ок, php заняло нишу кмс-ок, которые расширяются через жопу и половина кода держат бек-ворд-компобилити до php4, дальше то что? Теперь и мне писать под друпал, от которого сами кор-девелоперы ноют и плачут?
зачем вам это иметь ввиду? Вам нравится, когда вам мало платят?
Мне платят достаточно, а вот спрос на меня есть всегда и предполагаю еще долго не иссякнет, мало того я еще и выбираю какой заказ брать а какой нет, а не жду очередного. Я конечно не знаю как у Вас но я во всяком случае за свой спрос уверен на 100%.
Кстати по поводу когда в различных Друпалах и Вебасистах — это реально сущщий ад и блевотня, кстати именно она то и сподвигла на написание велосипеда, т.к. ассинезатором скриптов я быть нехотел.
Кстати по поводу когда в различных Друпалах и Вебасистах — это реально сущщий ад и блевотня, кстати именно она то и сподвигла на написание велосипеда, т.к. ассинезатором скриптов я быть нехотел.
Чувак, попробуй взгляни на эко-систему руби иди пайтона, тебе больше понравится.
Скиньте ссылочки, если не трудно, я почитаю, я всегда открыт для новых знаний и аргументированных довыдов. Буду благодарен.
Блин, довОдов.
Если вы про ссылки на экосистему ruby/python, то вот по поводу ruby ruby-toolbox.
А какое отношение колонки имеют к PHP? Вы ещё скажите, что не любите PHP, потому что индексы в БД не используются :)
Не вижу тут ничего от ActiveRecord. Больше похоже на обвязку для SQL. ActiveRecord заключается прежде всего в прозрачной связи объектов языка и строк в БД, в отсутствии необходимости думать в терминах SQL.
PHP и HTTP разного поля ягоды
В оригинале было «PHP has HTTP interaction baked right in.», что, если дословно: «Взаимодействие PHP и HTTP взросло (выпечено) в одной печи», как-то так. Посчитал, что ближайший русский аналог — как раз про ягоды с поля.
В оригинале было «PHP has HTTP interaction baked right in.», что, если дословно: «Взаимодействие PHP и HTTP взросло (выпечено) в одной печи», как-то так. Посчитал, что ближайший русский аналог — как раз про ягоды с поля.
> Но с каких пор разработчик определяет что успешно? Если бы разработчик это определял, то софт типа Wordpress, jQuery и Jenkins/Hudson не достигли бы такого успеха (ибо их исходные коды под характерным вопросом качества).
Странное заявление. Разработчик вполне может судить о тех инструментах, с которыми ему приходится работать. Вообще не понимаю, зачем мешать в одну кучу языки-фреймворки и продукты, рассчитанные на конечного пользователя.
Странное заявление. Разработчик вполне может судить о тех инструментах, с которыми ему приходится работать. Вообще не понимаю, зачем мешать в одну кучу языки-фреймворки и продукты, рассчитанные на конечного пользователя.
Тот же Wordpress это по сути не CMS (хотя и можеет выступать в её роли), а CMF. Расширить или изменить базовую функциональность (пускай даже с учетом сторонних модулей) — нужно писать php-код. Да что там, функциональность, вёрстку натянуть — нужен код. То есть продукты как бы для конечного пользователя на PHP от самого PHP неотделимы для этого пользователя. И наверное основное применение PHP это кастомизация этих продуктов.
Да, был у нас проект, точнее говоря удалось мне понаблюдать за проектом, который представлял из себя туристический портал — интернет магазин на WP, писали его типичные php программисты. Естественно никто во всем этом дерьме не пытался даже разбираться.
А что для вас значит «типичный php-программист»? Как по мне, так язык в этом термине вторичен. Я ищу работу прежде всего программиста, а то, что php — так исторически сложилось, что я знаю его лучше, более полезен буду работодателю в качестве программиста, использующего php, а не ruby/python/java/c#/js/vb/asm/… в которых я знаю только азы — буду тратить оплачиваемое время на разбирательство с нюансами. А уж если и настройкой среды исполнения придётся заниматься…
Для меня основная масса php программистов это:
1) отсуствие scm
2) всякое говно на уровне базы данных (отсуствие индексов, идиотские названия всего и вся)
3) херовый код, который мы просто выкинули, потому что люди кроме книг по php ничего никогда в своей жизни не читали и не видели (я говорю о тонне книг на тему разработки ПО)
1) отсуствие scm
2) всякое говно на уровне базы данных (отсуствие индексов, идиотские названия всего и вся)
3) херовый код, который мы просто выкинули, потому что люди кроме книг по php ничего никогда в своей жизни не читали и не видели (я говорю о тонне книг на тему разработки ПО)
Хм… значит мне как-то больше попадались нетипичные php-программисты, потому у меня о типичных представление несколько другое.
А SCM (если я правильно понял VCS?) и уровень БД вообще к языку отношения не имеет. Я на VC++ и VB писал без VCS и индексов (вернее индексировал всё подряд), а на C вообще всё в файлах хранил, без всяких БД — прямой перебор — самый простой способ поиска :), а на php использую, и над индексами думаю, запросы профилирую и т. п.
А SCM (если я правильно понял VCS?) и уровень БД вообще к языку отношения не имеет. Я на VC++ и VB писал без VCS и индексов (вернее индексировал всё подряд), а на C вообще всё в файлах хранил, без всяких БД — прямой перебор — самый простой способ поиска :), а на php использую, и над индексами думаю, запросы профилирую и т. п.
Я говорю с вами о культуре. Эко системе вокруг языка.
Под SCM я имею ввиду git/svn.
Под SCM я имею ввиду git/svn.
Если я сегодня начну писать на ruby, разве моя культура изменится? Я стану использовать git (а не любимый Mercurial), как-то по другому именовать таблицы и колонки БД?
А я под VCS имею в виду mercurial/svn :)
А я под VCS имею в виду mercurial/svn :)
Вы относите себя к числу таланлтивых php программистов? ;)
Я отношу себя к числу программистов. Какой инструмент использовать — вторично, просто php «легче» и привычнее, в «активном словаре» находится. Как, например, английскую IT-литературу (тот же Ruby Way) я без словаря читаю, а юридическую или художественную так не получается. А так хоть на ассемблере могу сайт сделать (делал), хоть на Эрланге (делал, даже без Нитрогена :) ).
Расширить или изменить базовую функциональность (пускай даже с учетом сторонних модулей) — нужно писать php-код
А в случае с CMS разве не так же? Или это миф о том, что CMS — это только то, что «из коробки».
Спасибо за перевод.
Думаю, эта статья поработает достойным реверсом.
Думаю, эта статья поработает достойным реверсом.
Читал оригинал. Перевод — так себе. Несколько строк прочёл и… дальше не захотел.
«Дебаггер»… Такое ощущение, что перевод написан быдлокодером со стажем.
«Дебаггер»… Такое ощущение, что перевод написан быдлокодером со стажем.
Вообще это уже устоявшееся русское слово. Викисловарь о нём знает. Если Вам режет слух, могу заменить на отладчик.
Вы меня извините за мою резкую критику. Просто по знакомым сижу (есть и евангелисты, и быдлокодеры). Первые, в 99 из 100 случаев называют «отладчиком».
У вас очень мощная выборка! Целый 100 «евангелистов» (между прочим, почитайте, что такое «евангелист»). Просто монстр статистики
Вот мы и нашли лакмусовую бумажку идентификации быдлокодеров! Срочно телеграфируйте всем HR-ам, люди должны знать об этом!
Нехорошо обычно упоминать про возраст автора комментария, но я в ваши годы не знал и трёх хороших программистов. Завидую современной молодёжи!
>> «Устоявшееся русское слово...»
Вот только этого не надо. Это жаргонизм, не более того. Иностранного происхождения, смею заметить.
Вот только этого не надо. Это жаргонизм, не более того. Иностранного происхождения, смею заметить.
Хотя я сам стронник (дада) англицизмов, но отладчик отличное слово (:
Многое верно описано. Единственное, в Ruby есть встроенный шаблонизатор — erb (embedded ruby).
В ПХП много таких вещей, который по началу бесят, но если к ним привыкнуть, то все становиться более чем хорошо
А стоит ли привыкать к тому, что бесит? Разве fun не главное?
Главное — результат
А что является результатом в описанном выше случае? Привычка?) Или выход на новый энергетический уровень посредством преодоления себя?)
Цель можно достигнуть, совершенно разными способами. Не лучше ли выбирать те, которые «не бесят»?)
Цель можно достигнуть, совершенно разными способами. Не лучше ли выбирать те, которые «не бесят»?)
Бесит то, что ПХП требует от разработчика больше низкоуровневых манипуляций, за что, кстати я ему очень благодарен
Зачем? Вы получаете 100 тысяч рублей и считаете, что за эти деньги можно терпеть херовый дизайн языка? :D
Стоит если оно того стоит
Кушать хочется…
Тогда идите и работайте с .NET или RoR. Такие товарищи куда дороже и не менее востребованы. Это не аргумент.
По вашим словам при любых раскладах программировать на PHP не стоит
Отнюдь. Своя ниша-то у него есть. Но «Кушать хочется» — не аргумент в пользу технологии, по поводу которой обсуждается: «стоит ли привыкать к тому, что бесит».
Кушать хочется — это аргумент, когда нет аналогов и все, что остается — использовать «что есть». Но тут выбор то богат. И с точки зрения оплачиваемости, PHP отнюдь не самый-самый.
Субъективно, я бы при любом раскладе и не писал на PHP :) Хотя и работал с ним долгие 3-4 года, можно сказать первый язык в реальных проектах был.
Сейчас для веба изначально осваивал бы Python/Django или RoR, а также ASP.NET MVC.
Кушать хочется — это аргумент, когда нет аналогов и все, что остается — использовать «что есть». Но тут выбор то богат. И с точки зрения оплачиваемости, PHP отнюдь не самый-самый.
Субъективно, я бы при любом раскладе и не писал на PHP :) Хотя и работал с ним долгие 3-4 года, можно сказать первый язык в реальных проектах был.
Сейчас для веба изначально осваивал бы Python/Django или RoR, а также ASP.NET MVC.
Опыт на PHP есть, на RoR/Django нет. PHP бесит, но за него платят. Лично мне платят, а за RoR лично мне не платят. Даже когда предлагаю сделать на RoR в два раза дешевле, то все равно настаивают на PHP.
Отличный подход :)
Недавно менял проприетарное решение по windows на собственное решение на php (denwer+мини-сайт) для производственного процесса одной организации. Хвалой был тезис сисадмина — «техническая сторона меня удивила — всё работает просто и понятно!». Теперь они высказали желание съехать с windows под linux и с обычным LAMP продолжить функционирование без оплаты лицензий за mssql+server2003.
Ключевые слова: просто, удобно и быстро. Но качество зависит от исполнителя, поэтому как верно подмечено — чем шире рынок, тем он разнообразней (от шедевров, до школьных поделок).
Ключевые слова: просто, удобно и быстро. Но качество зависит от исполнителя, поэтому как верно подмечено — чем шире рынок, тем он разнообразней (от шедевров, до школьных поделок).
Вот кстати не ради холивора, а почему «просто, удобно, быстро» преподносится как конкурентное преимущество php-стэка?
Можно сделать просто, удобно и быстро, используя практически все что угодно. Был бы разработчик толковый.
Опять же, для развертывания есть масса инструментов, не имеющих непосредственного отношения к php.
Что именно-то просто, удобно и быстро?
Можно сделать просто, удобно и быстро, используя практически все что угодно. Был бы разработчик толковый.
Опять же, для развертывания есть масса инструментов, не имеющих непосредственного отношения к php.
Что именно-то просто, удобно и быстро?
Если сравнивать 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 вы будете один только клиент для базы данных скачивать и устанавливать (иногда с правками в реестре, потому что на русскую версию винды оно в какой-то версии вообще не встанет :)) то же количество времени :).
В 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 вы будете один только клиент для базы данных скачивать и устанавливать (иногда с правками в реестре, потому что на русскую версию винды оно в какой-то версии вообще не встанет :)) то же количество времени :).
Быстро ставите дебиан, быстро его настраиваете, быстро пишите sudo apt-get install бла-бла-бла, быстро делаете сайтик, быстро его копируете по ssh, быстро дампите базу, быстро ее заливаете на продакшен, быстро в ручную редактируете какие-то там таблицы в mysql, быстро (главное быстро!).
Чтобы так быстро получилось нужны какие-нибудь метамфетамины, иначе никак, я думаю.
Чтобы так быстро получилось нужны какие-нибудь метамфетамины, иначе никак, я думаю.
О где же тот дивный новый мир, в котором люди будут знать слова one, click и deployment:)
Насколько я понимаю, речь шла об 1 или буквально двух-трёх серверах, для которых готовить дистрибутив с автоматическим развертыванием не имеет никакого смысла, как мне кажется. С другой стороны, я вам привел совершенно реальные цифры по тому, сколько времени занимает установка ОС и соответствующего веб-сервера :). Получается быстро не потому, что нужно куда-то спешить, а потому, что там делать особо ничего и не надо — простейший LAMP поднимается и настраивается, по сути, из коробки.
Есть опыт поддержки в продакшене двух-трех серверов на которых крутится одно приложение? Думаю нет. Попробуй каково это, потом расскажешь:)
Ээээ… Ну, есть опыт в работе с одним приложением на каких-то там 1000 серверах, но это, конечно же, мелочи по сравнению с вашими целыми 2-3 ;)
1000 серверов это ботнет что ли?
И да, не с нашими, с вашими:) Не я в начал про количества рассказывать.
1000 серверов тоже быстро-быстро? Там таблички, туда денвер, здесь apt-get'ом апдейты подоткнуть?)
1000 серверов тоже быстро-быстро? Там таблички, туда денвер, здесь apt-get'ом апдейты подоткнуть?)
Ну, в Badoo не используется apt, потому что там SLES, но в целом всё очень просто и очень быстро работает (конечно, ни о каких Денверах речи не идет, но всё сделано именно такими очень простыми способами, потому что какие-то сложные решения на таких масштабах работают и управляются значительно хуже).
Например одна из недавно оптимизированных мной операций — раскладка новой версии кода на все эти 1000 машин (в случае с PHP приложение и исходный код это одно и то же) у нас занимает около 1-2 минут — как вы думаете, это много :)? И нет, это не ботнет — чтобы обрабатывать 30к запросов к вебу в секунду, требуется иметь много серверов (из этих 1000 машин веб-серверами являются около 150-200 машин).
Например одна из недавно оптимизированных мной операций — раскладка новой версии кода на все эти 1000 машин (в случае с PHP приложение и исходный код это одно и то же) у нас занимает около 1-2 минут — как вы думаете, это много :)? И нет, это не ботнет — чтобы обрабатывать 30к запросов к вебу в секунду, требуется иметь много серверов (из этих 1000 машин веб-серверами являются около 150-200 машин).
Так все-таки все руками быстро-быстро, или нет, я не понял? «Такими очень простыми способами» это какими?
Оптимизировал деплой — написал скрипт который по ssh раскидывает архивы? Или пулит из гита затеганную версию? Так все же не руками? Ну и капистрано, паппет, шеф какой-нибудь это конечно не тру:)
По-поводу машин хорошо:) 150-200 веб-серверов:) 800-850 остальных, это стационарные машины разработчиков?))
Оптимизировал деплой — написал скрипт который по ssh раскидывает архивы? Или пулит из гита затеганную версию? Так все же не руками? Ну и капистрано, паппет, шеф какой-нибудь это конечно не тру:)
По-поводу машин хорошо:) 150-200 веб-серверов:) 800-850 остальных, это стационарные машины разработчиков?))
Через некоторое время должна будет выйти моя статья про то, как мы это сделали, в блоге Badoo — сможете узнать подробности. А так, да, раскладывайтесь с помощью git pull / svn up в 1000 потоков, убивайте свои сервера ;).
Не понял зачем мне сервера убивать и что мне делать c git pull в 1000 потоков?
Ну и все-таки, сам-то пробовал держать 2-3 продакшен сервера теми методами, которые народу выше советовал?)
Ну и все-таки, сам-то пробовал держать 2-3 продакшен сервера теми методами, которые народу выше советовал?)
На самом деле, такой способ установки я не придумал — так устанавливались сервера на моей предыдущей работе и работало это очень хорошо. Конечно, на серверах с большой нагрузкой (даже если это буквально 2-3 сервера) неплохо бы иметь мониторинг, бэкапы, ротейт логов и другие полезные вещи, но для минимальной установки это всё не обязательно.
Я изначально описывал ситуацию, когда вам нужно организовать небольшой сервис для «для производственного процесса одной организации» и хватит одного сервера за глаза. На одном ubuntu server до сих пор работают такие сервисы на моём первом месте работы и с ними за всё время проблем не возникало, поскольку они просто сидят себе тихонечко и выполняют свою работу и жрать не просят. Именно об этом, насколько я понимаю, говорил автор: если от системы требуется что-то простое, то LAMP будет прекрасно работать и не будет требовать от сисадмина, по сути, ничего — он может действительно просто оставить систему и не трогать её, пока не скончается железо.
Я кстати даже php-демонов на windows server 2003 под денвером содержал в «энтерпрайз-системе» и с php-частью никогда проблем не было :).
Я изначально описывал ситуацию, когда вам нужно организовать небольшой сервис для «для производственного процесса одной организации» и хватит одного сервера за глаза. На одном ubuntu server до сих пор работают такие сервисы на моём первом месте работы и с ними за всё время проблем не возникало, поскольку они просто сидят себе тихонечко и выполняют свою работу и жрать не просят. Именно об этом, насколько я понимаю, говорил автор: если от системы требуется что-то простое, то LAMP будет прекрасно работать и не будет требовать от сисадмина, по сути, ничего — он может действительно просто оставить систему и не трогать её, пока не скончается железо.
Я кстати даже php-демонов на windows server 2003 под денвером содержал в «энтерпрайз-системе» и с php-частью никогда проблем не было :).
Ну тогда я вообще ничего не понимаю. Если это просто сервер которой «стоит и есть не просит», туда все что угодно можно воткнуть и оно будет нормально работать. В чем плюс LAMP перед каким-нибудь MS SQL Express, или как он там называется? Или перед любым другим решением?
Или мы говорим не о том, что «с целью», а о том, что «вопреки»?
Или мы говорим не о том, что «с целью», а о том, что «вопреки»?
Например, куда удобнее иметь централизованный, интегрированный в ОС механизм обновлений для среды выполнения, чем следить за обновлениями минимум двух продуктов (самой ОС и SQL сервера).
А зачем обновлять что-то что крутится, свои задачи выполняет и лишнего времени не просит?
Чтобы после обновления что-нибудь отвалилось?) Оно же бывает, что обновишься, а потом сидишь и думаешь, какой черт потянул кнопки нажимать:)
Чтобы после обновления что-нибудь отвалилось?) Оно же бывает, что обновишься, а потом сидишь и думаешь, какой черт потянул кнопки нажимать:)
Фиксы уязвимостей, например.
Кто ломать будет?) Предыдущий оратор же дал вполне ясную вводную — тише воды даниже травы, «обеспечение производственного процесса одной организации»:)
Софистика это все вобщем. Если само работает — то и пусть работает. А если требуется периодическое вмешательство, то надо делать по уму, чтобы минимизировать время, которое приходится затрачивать.
Софистика это все вобщем. Если само работает — то и пусть работает. А если требуется периодическое вмешательство, то надо делать по уму, чтобы минимизировать время, которое приходится затрачивать.
Ну и конечно же не руками, а простыми скриптами это делается, но суть именно в том, что эти скрипты занимают от силы 100 строк и почти вся их работа заключается в проверке на ошибки, а не в выполнении «полезной работы». А если надо обслуживать 2-3 сервера, то сгодится любой вариант, о чём я и говорил, собственно.
Ну вот пообслуживай, расскажешь:) Ты же в баду, я подозреваю не один работаешь, и материально ответственным за простой серверов лицом не являешься?
Что такое скрипты по 100 строк и что такое работа, заключающаяся, в проверке на ошибки мне не понять. Ну пишете вы свои велосипеды, для своих исторически сформировавшихся задач, что ж всем теперь так делать и на такую модель работы ориентироваться? Сделали хайлоад, молодцы, но каждый хайлоад уникален.
И когда нам надо что-то руками настраивать, куда-то складывать и еще дампить и таблички править это не просто и не быстро. Это геморрой, который в будущем с большой долей вероятности потребует оперативного вмешательства.
Не надо вобщем давать людям дурные советы.
Что такое скрипты по 100 строк и что такое работа, заключающаяся, в проверке на ошибки мне не понять. Ну пишете вы свои велосипеды, для своих исторически сформировавшихся задач, что ж всем теперь так делать и на такую модель работы ориентироваться? Сделали хайлоад, молодцы, но каждый хайлоад уникален.
И когда нам надо что-то руками настраивать, куда-то складывать и еще дампить и таблички править это не просто и не быстро. Это геморрой, который в будущем с большой долей вероятности потребует оперативного вмешательства.
Не надо вобщем давать людям дурные советы.
Один сервер — разворачиваем/апдейтим ручками. Несколько серверов (пускай даже тысячи) с одной конфигурацией — пишем скриптик. Зоопарк конфигураций/приложений — используем тяжёлую артиллерию типа капистрано и шефа, унифицируя процесс.
Возможно, после овладения артиллерией захочется и в более простых случаях её использовать. Но не получится это из пушки по воробьям?
Возможно, после овладения артиллерией захочется и в более простых случаях её использовать. Но не получится это из пушки по воробьям?
Нет, зачем руками? Всё автоматизируется, и при количестве серверов более нескольких, разворачивается chef, puppet или другой аналог.
Быстро — потому что практически любой может взять нечто денвера и одной из самоучителей может за вечер набросать прямо на домашнем компе себе более-менее интерактивный сайтик.
Просто — потому что опять же любой может начиная от чего-то простого за один вечер развивать и параллельно развиваться.
Удобно — потому что если хочется чего-то простого, ты делаешь это просто и так как удобнее тебе, а если нужно чего-то сложного — PHP позволяет делать и очень сложные вещи.
При этом PHP сейчас есть на любом хостинге, при желании и бесплатный вменяемый найти нетрудно.
Наверное как-то так.
Впрочем по-моему в каждом языке есть свои сильные и слабые стороны, меня очень удивляет и забавляет когда многие почему-то начинают называть PHP полным говном.
Просто — потому что опять же любой может начиная от чего-то простого за один вечер развивать и параллельно развиваться.
Удобно — потому что если хочется чего-то простого, ты делаешь это просто и так как удобнее тебе, а если нужно чего-то сложного — PHP позволяет делать и очень сложные вещи.
При этом PHP сейчас есть на любом хостинге, при желании и бесплатный вменяемый найти нетрудно.
Наверное как-то так.
Впрочем по-моему в каждом языке есть свои сильные и слабые стороны, меня очень удивляет и забавляет когда многие почему-то начинают называть PHP полным говном.
Т.е. хорошо, быстро и удобно в том случае, когда хочется несильно парясь развернуть типовой cms-сайт на недорогом хостинге? С такой формулировкой я согласен. Но речь вроде бы шла не совсем об этом?
А вот понятия «сделать просто и так, как удобно тебе» и «использование cms» совершенно несовместимы на мой взгляд.
А вот понятия «сделать просто и так, как удобно тебе» и «использование cms» совершенно несовместимы на мой взгляд.
Насчет «полным говном» — не про меня. Никогда не считал PHP «полным говном». Просто лично мне не понятно, зачем сейчас нужен PHP человеку, который всерьез собирается связать свою профессию с web-разработкой.
То есть, вы считаете, что PHP нет места в веб-разработке :)? Или, к примеру, нет спроса на PHP-программистов? Почему вы считаете, что PHP не нужен человеку, который всерьез собирается связать свою профессию с web-разработкой? Вы, возможно, слышали, что сайты вроде facebook, vkontakte, yandex, badoo, wikipedia имеют веб-бэкенды на PHP и не отказались бы от хороших разработчиков на этих языках :)?
Не надо на «Вы», я пока еще не пенсионер.
Ну и что что контакт, фейсбук и кто-то там еще сделан на php? Ну сделан, так масса других проектов сделана с использованием других средств. Да и что-то мне подсказывает, что они одним php не ограничиваются, стэк технологий у них довольно большой.
Фейсбук, собственно говоря, когда начинался? В то время было много альтернатив PHP? Контакт тоже не вчера появился на рынке. А сейчас альтернативы есть. И хорошие. Почему бы не использовать их?
Я не понимаю, подхода, когда мы давимся, плюемся, прем сквозь тернии, но все равно продолжаем и продолжаем что-то там делать и что-то кому-то доказывать.
Ну и что что контакт, фейсбук и кто-то там еще сделан на php? Ну сделан, так масса других проектов сделана с использованием других средств. Да и что-то мне подсказывает, что они одним php не ограничиваются, стэк технологий у них довольно большой.
Фейсбук, собственно говоря, когда начинался? В то время было много альтернатив PHP? Контакт тоже не вчера появился на рынке. А сейчас альтернативы есть. И хорошие. Почему бы не использовать их?
Я не понимаю, подхода, когда мы давимся, плюемся, прем сквозь тернии, но все равно продолжаем и продолжаем что-то там делать и что-то кому-то доказывать.
Проблема в том, что альтернативы не настолько сильно лучшие наверное, иначе бы все сразу и начали только их использовать. :)
Ну так может быть всем и не надо? Зачем хорошему, состоявшемуся PHP-разработчику переходить на что-то другое?
А зачем начинающему разработчику осваивать что-то другое (кроме расширения кругозора), если явных плюсов особо нет, а спрос больше именно на PHP? Может даже в недалеком будущем что-то поменяется, но далеко не у всех есть талант/навыки прогнозирования рынков (а если есть, то может, не разработчиком идти работать? :) ).
Дык есть же явные плюсы:) Мир на месте ведь не стоит, все новое ведь не с потолка берется:)
Хотя если хочется поддерживать старый код и работать в кубикле, имея над душой 10 проджект-менеджеров, лидов и кто там еще бывает в настоящих командах, то наверное не стоит:)
Насчет идти работать «не разработчиком» вполне вариант:) Много их, в последнее время, этих разработчиков стало, а толкового не найти:)
Хотя если хочется поддерживать старый код и работать в кубикле, имея над душой 10 проджект-менеджеров, лидов и кто там еще бывает в настоящих командах, то наверное не стоит:)
Насчет идти работать «не разработчиком» вполне вариант:) Много их, в последнее время, этих разработчиков стало, а толкового не найти:)
Так и PHP на месте не стоит, переживать по поводу «старого кода» особо не приходится, современные php-фреймворки предполагают активное использование современных (5.3) фич. А вот экономических обоснований переписать с нуля старый код на RoR/Django/..., когда можно его плавно перевести на использование php-фреймворка, избавляясь как от depricated фич языка, так и от ошибок проектирования приложения, я придумать не могу. Свои личные, эстетические есть. Убедить заказчика, что развитие должно быть заморожено на время ради удовлетворения моих эстетических запросов как-то не получается.
Фреймворки понятное дело предполагают, и PHP развивается. Но что предложат молодому разработчику, который приходит в среднюю PHP-команду? CMS-ки допиливать? Поддерживать решения которым 3+ лет?
Понятно дело, что и на ПХП делаются интересные проекты, но размер рынка вакансий и соискателей это же медаль, которая имеет две стороны.
Насчет переписывать с нуля что-то на рельсо-джанги, я же вроде такого никогда никому не советовал:) Пожелания заказчика и экономическая целесообразность прежде всего.
Вобщем, я спать пойду) Мое мнение такое — все что на пхп написано и успешно работает переписывать никуда не надо. PHP-гуру всякие рельсы нужны как собаке пятая нога. А вот тем, кто только выбирает я бы рекомендовал смотреть в сторону трендов. Ну и конечно все это имхо, основанное на личном опыте:)
Понятно дело, что и на ПХП делаются интересные проекты, но размер рынка вакансий и соискателей это же медаль, которая имеет две стороны.
Насчет переписывать с нуля что-то на рельсо-джанги, я же вроде такого никогда никому не советовал:) Пожелания заказчика и экономическая целесообразность прежде всего.
Вобщем, я спать пойду) Мое мнение такое — все что на пхп написано и успешно работает переписывать никуда не надо. PHP-гуру всякие рельсы нужны как собаке пятая нога. А вот тем, кто только выбирает я бы рекомендовал смотреть в сторону трендов. Ну и конечно все это имхо, основанное на личном опыте:)
Порог вхождения высокий. Я после 4+ лет разработки на PHP перешел на RoR — рад и счастлив. Но без опыта программирования на других языках и без знания разнообразных паттернов — я бы не смог писать на RoR.
С PHP начать, все-таки по-моему проще, ту же работу найти проблем не составляет, даже если знаний почти вообще нет. Опять же если заниматься всерьез, а не на уровне «клепать сайты на cms» то перейти потом на что-то другое будет несложно.
Лично я начинал когда выбор был по сути между perl и php, причем perl мне тогда казался приятнее. В последнее время для web-разработки я присматривался к питону и руби, но стараюсь писать на PHP, больше нравится, наверное просто привычка. Впрочем опять же заработать денег на PHP проще.
А вообще больше всего мне нравится java, но до серьезной разработки на ней я еще пока не дорос :)))
Лично я начинал когда выбор был по сути между perl и php, причем perl мне тогда казался приятнее. В последнее время для web-разработки я присматривался к питону и руби, но стараюсь писать на PHP, больше нравится, наверное просто привычка. Впрочем опять же заработать денег на PHP проще.
А вообще больше всего мне нравится java, но до серьезной разработки на ней я еще пока не дорос :)))
Примерно такая же ситуация, правда косюсь больше в сторону C# под Mono, да и Perl приятным после C/C++ как-то не показался, но всерьёз его рассматривал, да.
Судя по некоторым ява-сеньорам, которые по уровню тянут лишь на уровне, а требуют после 3 лет работы как за тимлида…
Вообщем, думаю, 3-4 книжки, две из которых по основам, еще одна по j2ee 6-й и последняя по уже все равно чему и ты готов к зарабатыванию денег на яве.
Вообщем, думаю, 3-4 книжки, две из которых по основам, еще одна по j2ee 6-й и последняя по уже все равно чему и ты готов к зарабатыванию денег на яве.
> очень удивляет и забавляет когда многие почему-то начинают называть PHP полным говном
кмк, для них слишком высокий порог вхождения! )) так или иначе, собака лает, караван идет!
кмк, для них слишком высокий порог вхождения! )) так или иначе, собака лает, караван идет!
PHP — отстой! Но я люблю его!