Комментарии 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(:+)
И кучи чего ещё.
НЛО прилетело и опубликовало эту надпись здесь
Вот почему 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 нужны фреймворки — это плохой язык.
НЛО прилетело и опубликовало эту надпись здесь
Для 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-заголовками в варианте с рефрешем.
НЛО прилетело и опубликовало эту надпись здесь
ну тут упоминали facebook и проекты с высокой посещаемостью.
и вроде как на дворе мир web2.0 с реалтаймом.
websockets есть уже почти везде, на подходе webRTC.
а странички с посещаемостью полчеловека в минуту писать можно на чём угодно.
и вроде как на дворе мир web2.0 с реалтаймом.
websockets есть уже почти везде, на подходе webRTC.
а странички с посещаемостью полчеловека в минуту писать можно на чём угодно.
НЛО прилетело и опубликовало эту надпись здесь
Автор исходной статьи пишет, что при достаточно высокой квалификации грабельки, заботливо положенные авторами языка можно объезжать.
В facebook было написано много кода на php и когда возникли сложности с производительностью, как я понимаю, дешевле оказалось изобрести hiphop, нежели переписывать и переучивать имеющийся штат разработчиков.
Всё, опять же, сводится к правильному инструменту под задачу. Беда php в том, что уж очень много задач, для которых есть инструменты лучше.
Например, много ли вы знаете серверов трансляций на php?
на эрланге есть erlyvideo, на python — flumotion (да и я писал свой сервер для онлайн трансляции — 19к онлайн-клиентов на тестах было. написано на python).
В facebook было написано много кода на php и когда возникли сложности с производительностью, как я понимаю, дешевле оказалось изобрести hiphop, нежели переписывать и переучивать имеющийся штат разработчиков.
Всё, опять же, сводится к правильному инструменту под задачу. Беда php в том, что уж очень много задач, для которых есть инструменты лучше.
Например, много ли вы знаете серверов трансляций на php?
на эрланге есть erlyvideo, на python — flumotion (да и я писал свой сервер для онлайн трансляции — 19к онлайн-клиентов на тестах было. написано на python).
Но эти задачи не самые распространенные (в количестве постановок). И я не думаю, что будет хорошей идеей (для меня) говорить работодателю, что, скажем, ему нужно нанимать python-программиста вместо меня. Да покупать (v)DS вместо шареда, да ещё грамотного админа в комплекте. Действительно, мне «дешевле» «изобрести» hiphop.
НЛО прилетело и опубликовало эту надпись здесь
Переход на питон и джангу для среднего пхп-разработчика это вообще не проблема, как почему-то многие пытаются представить.
Кстати, да, согласен. И даже без роста доходов с радостью бы перешёл. Перейти с 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 полным говном
кмк, для них слишком высокий порог вхождения! )) так или иначе, собака лает, караван идет!
кмк, для них слишком высокий порог вхождения! )) так или иначе, собака лает, караван идет!
Вы когда-нибудь ставили рельсы под винду, если нет, то скажу прямо — ставить WAMP-стек на винду — просто, удобно, быстро:-)
влажные фантазии? промрешение с mssql он переводил на денвер+пхп, лол. SAP заодно бы им на Друпале переписал бы, чего уж
Ну зачем так сразу, надо же подробности выяснить:) Может там сложный случай:)
Вам показать ЭТО промрешение? Это MSACCESS +MSSQL. Один сервер, второй под бекап. Операторы в винде. Клиенты тоже вынуждены сидеть в винде. Поддержка отсутствует. Вскрыть MSACCESS не смогли, исправить логику под новый процесс — не смогли. Вся ферма стала ненужной.
Полученное решение в разы проще: веб-сервер, mysql. Операторы и клиенты пересели в веб-браузер (хоть винда, хоть тонкие клиенты, хоть телефон). Для защиты от органов — быстрый переезд на шаред-хостинг за границу.
Для владельцев остались исходники, которые они смогут править под свои нужды хоть на free-lance за 1000 рублей.
Полученное решение в разы проще: веб-сервер, mysql. Операторы и клиенты пересели в веб-браузер (хоть винда, хоть тонкие клиенты, хоть телефон). Для защиты от органов — быстрый переезд на шаред-хостинг за границу.
Для владельцев остались исходники, которые они смогут править под свои нужды хоть на free-lance за 1000 рублей.
Думаю что к этому посту(переводу) можно добавить множество контрпримеров на примеры из обсуждаемой статьи. По поводу того же сравнения строк есть strncmp и прочие функции…
О мощи русского интеллекта.
В различных баснях великого русского поэта и ученого Ивана Андреевича Крылова слово «слон» упоминается 14 раз в самых разных ракурсах.
Он предвидел накал страстей вокруг PHP:
В различных баснях великого русского поэта и ученого Ивана Андреевича Крылова слово «слон» упоминается 14 раз в самых разных ракурсах.
Он предвидел накал страстей вокруг PHP:
Имхо пхп vs others это классический Mappers vs packers (в терминах программистского камня). Обратите внимание, что основные тезисы не противоречат друг другу — противники скорее формулируют претензии в терминах интеллектуальной неопрятности: замусоренное пространство имен, отсутствие четких соглашений и т.д. Сторонники, оперируют доводами практики: дохренища дешевых кодеров, готового кода, дешевого хостинга и т.д. — что даже не относится к тезису «плохого дизайна» вообще никак. В доводах автора статьи проскальзывает отношение к подключению библиотеки как к какому-то тяжелому дейтвию, а не к декларации о намерении использовать некую функциональность.
Оппонент же ничуть не оспаривает практичности пхп, наверное, ему приходится из-за этой практичности с ним работать, хотя чувствуется, что ему претит «думать на пхп».
В этом что-то есть от сожительства с богатой, но отвратительной до глубины души, женой
Оппонент же ничуть не оспаривает практичности пхп, наверное, ему приходится из-за этой практичности с ним работать, хотя чувствуется, что ему претит «думать на пхп».
В этом что-то есть от сожительства с богатой, но отвратительной до глубины души, женой
Хорошо сказано:)
Особенно про женушку.
Даже не отвратительной скорее, а с недостатками, но в темноте разница скрывается :)
Я бы сказал наоборот: PHP — это такая прелестная на первый взгляд девушка, в которую влюбляются неопытные подростки. Но за внешней смазливостью скрывается дурной нрав, мерзкий характер, да и в постели она бревно. Вокруг есть девушки не столь смазливенькие, но в целом симпатичные и при этом умные и добрые.
Спасибо за статью, она была необходима. После прочтения PHP: a fractal of bad design у меня настолько сильно чесалось, что чуть было сам статью не написал, только Вы и лень спасли мир от этого.
Дизайн PHP действительно плох, но всё-таки поддержу автора поста. У капитана, написавшего прошлый пост, есть намного более очевидный косяк, цитирую
На лицо непонимание разницы между private/protected :)
Subclasses cannot override private methods. Subclass overrides of public methods can’t even see, let alone call, the superclass’s private methods. Problematic for, say, test mocks.
На лицо непонимание разницы между private/protected :)
Да вроде все нормально, главное — в последнем предложении. Есть в пхп способ проюниттестать приватные методы? Сам я незнаю, если че Ж)
$class = new ReflectionClass ($myClass);
$method = $class->getMethod ('privateMethodX');
$method->setAccessible(true);
$output = $method->invoke ($myClass, $arg1, $arg2);
Приватные методы не надо юниттестить — они не часть интерфейса
НЛО прилетело и опубликовало эту надпись здесь
если приватные методы в чужой библиотеке — их не надо мокать так как они не интерфейс. Если приватные методы под контролем — их не надо мокать, потому, что надо рефакторить.
Вообще в таких ситуациях я делал обёртку для ФС или БД, которую инжектил в объект. Их легко мокать, а приватные методы тестировал косвенно, вызывая публичные и проверяя моки.
Люблю, не люблю, люблю, не люблю…
Хватит сопли на кулак наматывать, не нравится, не используйте!
Хватит сопли на кулак наматывать, не нравится, не используйте!
Как раз сегодня час пытался поставить xDebug (под виндой). В итоге плюнул и решил дебажить по-старинке, через print_r+exit. По сравнению с той же Java, отладки в PHP нет.
Есть прекрасная штука — FirePHP называется. (:
Если она есть, но никому не нужна, это не значит что ее нет. Любой ПХПист знает, что print_r вершина искусства дебага, а в Java она просто недостижима по причине строгой типизации, работы с потоками и прочими «бедами».
Всё нормально устанавливается. В том числе на винде. Не знаю как бы жил без отладки…
Странно. Сижу на линуксе. Поставился xdebug довольно просто и быстро. Все дебажит, трейсит, профилирует. Мало-того, есть GUI тулзы, которые выводят много интересной инфы с xdebug. Может все-таки прежде чем говорить что чего-то нет, нужно немного копнуть и разобраться?
xDebug можно по разному ставить xdebug.org/docs/install к примеру так xdebug.org/wizard.php
С чем у Вас возникла проблема при установке и настройке xDebug?
Кроме xDebug есть Zend Debugger который поставляется вместе с Zend Studio. xDebug (и Zend Debugger) интегрируется в Jetbrains PhpStorm. А так же xDebug интегрируется в NetBeans IDE. И еще есть отладчик DBG.
С чем у Вас возникла проблема при установке и настройке xDebug?
Кроме xDebug есть Zend Debugger который поставляется вместе с Zend Studio. xDebug (и Zend Debugger) интегрируется в Jetbrains PhpStorm. А так же xDebug интегрируется в NetBeans IDE. И еще есть отладчик DBG.
Скачайте zwamp.sourceforge.net/ отличный комлект под винду, кроме xDebug, в комплекте APC, MemCached, MongoDB. Всё добро удобно управляется, не требует установки, можно с флэшки запускать.
ставил xDebug минут 5-7. Не знаю на что вы час потратили, xDebug надо выбирать под ваш php.
НЛО прилетело и опубликовало эту надпись здесь
А что разве в трудовых пишут конкретный язык? У меня просто инженер-программист написано.
Вот, может Вы мне расскажите, что такого в том, что echo не функция?
введена спецконструкция там где можно было бы обойтись существующим понятием. В питоне до 3 такое тоже. Само по себе мелочь, но если такие вещи образуют систему, то достает. В абапе вон вообще спецконструкция для вывода отчета
А с практической стороны?
Если говорить, про такие конструкции, то их все можно заменить на функции…
Если говорить, про такие конструкции, то их все можно заменить на функции…
С практической всего ничего — выделить нейрон, для запоминания этой особенности, да писать врапперы, когда нужно передать куда-то функцию.
>>Если говорить, про такие конструкции, то их все можно заменить на функции…
И нужно. Вон в смолтоке всего 6 ключевых слов, даже if — это метод.
>>Если говорить, про такие конструкции, то их все можно заменить на функции…
И нужно. Вон в смолтоке всего 6 ключевых слов, даже if — это метод.
Ухудшается читаемость
echo "Hello" и echo("Hello"). Тогда уж надо допускать вызов функций без скобок и разбираться с неоднозначимостями типа вложенных вызовов.И ещё раз. Что такого в том, что echo не функция с практической стороны?
Писать плохой код можно на любом языке и любом фреймворке.
А зачем любить отстой?
Не понимаю этого сверх эмоционального отношения к ЯП. Это всего навсего инструменты.
Я, например, довольно долго писал на АС2, на objc — малопривлекательные ЯП. Но я их ни разу не любил, я просто понимал что для выполнения конкретной задачи ничего лучше в то время не было.
Если для определенной задачи ПХП является оптимальным решением — супер. Но для того чтоб его использовать совершенно не обязательно его любить.
Кроме того в такой «любви» кроется очень подлый подводный камень. Первый язык, на котором я писал серьезные проекты, был АС2. Там куча нюансов, мало- и не- документированных фич. И когда я знал все эти детали я думал, что эти знания чего-то стоят. Я думал, что это делает меня «специалистом!». Вот только когда перешел на другие ЯП пришлось это забыть и отбросить. Так как если вы даже очень виртуозно научились бегать на костылях, при беге на своих двоих эти навыки вам будут не нужны. И, кроме того, бегать без костылей удобнее и быстрее.
P.S. Сам на ПХП не пишу, но писал проекты на C#, Java, objc, C++, AS2,3 и знаю что такое хороший и плохой language design, и что такое его отсутствие.
Не понимаю этого сверх эмоционального отношения к ЯП. Это всего навсего инструменты.
Я, например, довольно долго писал на АС2, на objc — малопривлекательные ЯП. Но я их ни разу не любил, я просто понимал что для выполнения конкретной задачи ничего лучше в то время не было.
Если для определенной задачи ПХП является оптимальным решением — супер. Но для того чтоб его использовать совершенно не обязательно его любить.
Кроме того в такой «любви» кроется очень подлый подводный камень. Первый язык, на котором я писал серьезные проекты, был АС2. Там куча нюансов, мало- и не- документированных фич. И когда я знал все эти детали я думал, что эти знания чего-то стоят. Я думал, что это делает меня «специалистом!». Вот только когда перешел на другие ЯП пришлось это забыть и отбросить. Так как если вы даже очень виртуозно научились бегать на костылях, при беге на своих двоих эти навыки вам будут не нужны. И, кроме того, бегать без костылей удобнее и быстрее.
P.S. Сам на ПХП не пишу, но писал проекты на C#, Java, objc, C++, AS2,3 и знаю что такое хороший и плохой language design, и что такое его отсутствие.
Ладно, хорошо — удобство использования — это одно, а производительность…
Поделитесь пожалуйста ссылками на тесты производительности PHP в сравнении с другими скриптовыми языками программирования. Я сейчас стою перед выбором: на каком языке писать свой следующий веб-проект. Есть заведомые предположения в нужде масштабирования. Как бы сэкономить на железе?
На данный момент — использую php-fpm+apc+blitz+lua+mongodb+sphinx+nginx+memcached и подумываю об изучении Ruby. Стоит ли?
Поделитесь пожалуйста ссылками на тесты производительности PHP в сравнении с другими скриптовыми языками программирования. Я сейчас стою перед выбором: на каком языке писать свой следующий веб-проект. Есть заведомые предположения в нужде масштабирования. Как бы сэкономить на железе?
На данный момент — использую php-fpm+apc+blitz+lua+mongodb+sphinx+nginx+memcached и подумываю об изучении Ruby. Стоит ли?
Если вас так волнует производительность и хочется языка, синтаксически близкого к ПХП — учите тогда лучше джаву
Не спрашивайте про производительность в обсуждении интерпретируемых языков. Если ваша задача предполагает время исполнения сравнимое со временем доступа к ДБ плюс время на скачивание конечной страницы, то выбирайте Java или другой компилируемый язык. А PHP <> Ruby по моему шило на мыло, лучше грызите PHP дальше, до степени фанатизма, тогда мысль об переходе на Ruby отпадет сама.
Java компилируется в байт-код, в принципе, как и PHP. APC ему в этом помогает, не даёт перекомпилировать при каждом запросе. *посмотрел тесты сравнения php vs Java* И действительно — Java шустрее. Однако, не лежит у меня сердце к нему. Огромное потребление памяти и сложнейшая виртуальная машина — кажутся минусами…
Думаю, что стоит-таки попробовать C++ на G-WAN'е. Это конечно будет посложнее, времени чуть больше займёт. Но чего только стоит бесценный опыт!
Думаю, что стоит-таки попробовать C++ на G-WAN'е. Это конечно будет посложнее, времени чуть больше займёт. Но чего только стоит бесценный опыт!
В чистом виде компилятора PHP в природе не существует, коль скоро для вас не проблема осилить язык изначально ориентированный на вопрос быстродействия все остальные «но» просто не стоят обсуждения.
Про С++ спорить не буду, отсутствие хваленой платформонезависимости, на практике не всегда важно, хотя с другой стороны вы по моему недооцениваете Java, сравнивать ее быстродействие с PHP не стоит, сравнивайте тогда уже с С www.stefankrause.net/wp/?p=4 она ему не всегда уступит, а у С++ и вовсе выиграет.
Про С++ спорить не буду, отсутствие хваленой платформонезависимости, на практике не всегда важно, хотя с другой стороны вы по моему недооцениваете Java, сравнивать ее быстродействие с PHP не стоит, сравнивайте тогда уже с С www.stefankrause.net/wp/?p=4 она ему не всегда уступит, а у С++ и вовсе выиграет.
Ява байткодом существует первые несколько секунд (ну или минут, в зависимости от активности исполнения кода), а после уже нативный код: mov, push, cmp — одним словом как любит процессор. К примеру для серверной версии jvm порог по дефолту в 10к вызовов до компиляции.
Огромное потребление памяти, эм, ява конечно прожорлива (не буду вдаваться в подробности почему именно так, а никак иначе), хотя и прожорливость эту можно серьезно сократить^1, но вот сложная jvm вообще не должна являются останавливающим фактором, потому что для 90% веб разработки там уже работает все как надо. Для остальных десять, тут уже можно сменить какой-нибудь tomcat\glassfish\jetty на низкоуровневый netty и обрабатывать http-шные запросы десятками тысяч в секунду^2
1. кушать по 50 метров как один инстанс пхп она никогда не будет
2. 30к вполне себе нормальная цифра при подходе «энтерпрайз? не, не слышал».
Огромное потребление памяти, эм, ява конечно прожорлива (не буду вдаваться в подробности почему именно так, а никак иначе), хотя и прожорливость эту можно серьезно сократить^1, но вот сложная jvm вообще не должна являются останавливающим фактором, потому что для 90% веб разработки там уже работает все как надо. Для остальных десять, тут уже можно сменить какой-нибудь tomcat\glassfish\jetty на низкоуровневый netty и обрабатывать http-шные запросы десятками тысяч в секунду^2
1. кушать по 50 метров как один инстанс пхп она никогда не будет
2. 30к вполне себе нормальная цифра при подходе «энтерпрайз? не, не слышал».
Чтобы PHP отожрал 50 мб нужно очень сильно постараться :)
Если нет SPL и приходится оперировать большими массивами, то и 2Gb может сьесть. Но массивы это больна тема.
Да не так уж сильно и стараться надо. habrahabr.ru/post/141093
Да даже если в два раза меньше от этой цифры будут значения, то все равно слишком много на обработку одного запроса (мы говорим о каком то стандартом сайте, который отдает стандартную страницу). В Яве, без ентерпрайза, будет поменьше, сильно поменьше и сильно быстрее
Wordpress поставить, например? ;)
Ну так в WordPress и постарались. У меня к примеру все скрипты, легко работают с ограничением в 8 МБ, и функционал у них побольше, чем у WP. Мой Sypex Dumper перелопачивает многогиговые SQL-дампы, быстрее чем большинство виндовых MySQL клиентов, вплотную соперничая с консольным mysqldump по скорости.
Сейчас делаю бэкапилку файлов, она сжимает в zip быстрее WinRAR и 7zip. Хотя для этого и пришлось писать свою собственную реализацию zip, так как стандартные php-классы жутко тормозные.
Сейчас делаю бэкапилку файлов, она сжимает в zip быстрее WinRAR и 7zip. Хотя для этого и пришлось писать свою собственную реализацию zip, так как стандартные php-классы жутко тормозные.
Если вы используете описанный выше стек, то должны по идее о производительности знать все, что нужно:)
Все равно после определенного времени, проведенном на PHP, я думаю, стоит попробовать другие языки программирования. Сейчас буду пробовать Java либо Python.
Что-то вся эта кутерьма похожа на:
Неужели кто-то правда хочет и расчитывает найти истину и решить раз и навсегда что ПХП — умирающий (эволюционирующий) яп?
Я думаю это решит это только время и тенденции рынка web-приложений
Неужели кто-то правда хочет и расчитывает найти истину и решить раз и навсегда что ПХП — умирающий (эволюционирующий) яп?
Я думаю это решит это только время и тенденции рынка web-приложений
Лично по мне, так все эти дискуссии рекурсивно-безсмысленны, ибо Python-разработчик будет усираться — Python рулит, Java-программист — за Java, учитель русского языка — за русский. Все языки хороши. Есть задачи и есть пути его исполнения с минимальными затратами. В основном проблема не в языках, а в менеджерах/разработчиках/кодерах.
Есть ещё различные виды затрат. Навскидку для веб-приложения: собственно разработка, разворачивание среды выполнения и приложения, потребляемые ресурсы, поддержка приложения (собственно кода), поддержка среды выполнения (администрирование). То, что выгодно в долгсрочной перспективе может требовать больших затрат на старте, не говоря о том, что перспектив может и не оказаться. И то, что выберет разработчик по своим эстетическим техническим соображениям (или менеджер разработчика по своим экономическим) далеко не всегда может оказаться наиболее выгодным для бизнеса заказчика даже если он точно знает что ему выгодно.
Нет поддержки тредов — видимо вы не делали высоконагруженных проектов, где использование тредов и правильное манипулирование памятью дают выигрыш в десятки раз. Так что это порядочный недостаток.
Я, может, и не делал, но автор оригинальной статьи — разработчик PHP-PasswordLib и PHP-CryptLib, а также автор нескольких RFC языка. Я допускаю, что это спорный вопрос, но, полагаю, у него есть основания делать такие заявления.
От того, что человек, сделал что-то для развития языка еще ни о чем не говорит:-) Помню случай, с одним умником с php-club, который запорол релиз 5.2.0, убрав передачу параметров в функцию по ссылке, т.к. посчитал это лишним, а так как его комит пролез спокойно в релиз, говорит о многих разработчиках, кто это не увидел, патч на коленке был слеплен минут за 5.
А я просто занимаюсь разработкой хайлоад решений и знаю как многопоточность может увеличить производительность. К примеру переписал один сервис с cgi (300-400), fcgi (до 800), на многопоточный демон (5000-8000), в скобках кол-во обрабатываемых запросов в секунду на одном сервере. В данном случае узким местом стал сетевой интерфейс. Демон был написан на C++, а вот были бы нормальные потоки в PHP, скорее всего было бы сделано на нем, поддерживать все же его попроще.
А я просто занимаюсь разработкой хайлоад решений и знаю как многопоточность может увеличить производительность. К примеру переписал один сервис с cgi (300-400), fcgi (до 800), на многопоточный демон (5000-8000), в скобках кол-во обрабатываемых запросов в секунду на одном сервере. В данном случае узким местом стал сетевой интерфейс. Демон был написан на C++, а вот были бы нормальные потоки в PHP, скорее всего было бы сделано на нем, поддерживать все же его попроще.
Ну ведь по сути зачем треды «скрипту» который запустился-выполнился-умер?
Ну а кто сказал, что на PHP можно только простые скриптики делать? В чем проблема запустить его и пусть работает, слушает сокет (тут естественно захочется epoll, kqueue), держит пул потоков и обрабатывает в потоках запросы. Да, потоков нет, сейчас можно обойти несколькими процессами используя библиотеку pcntl, но это не то.
А если вы помимо отправки пользователю HTTP-ответа хотите сделать что-то еще? Например, уже после завершения отправки ответа, заняться отправкой почты для пользователя, сохранением каких-то статистических данных в БД или каким-то другим долгоживущим процессом?
С каких пор всё это стало задачей непосредственно интерпретатора, при том сугубо веб-ориентированного? Используйте фоновые процессы, cron скрипты и т.д.
Используйте фоновые процессы, cron скрипты и т.д.
… или Python, Ruby и т.д. Фоновые процессы — как раз то, что на PHP Не сделать удобным образом. cron — для периодических задач по расписанию, в общем случае он не является решением.
Есть вполне реальные задачи, которые нужно выполнять на сервере тесно взаимодействуя с веб-частью. Понятное дело, что и на PHP их можно как-то решать, но очень часто это будет делаться с помощью разного рода дополнительных средств, которые не имеют к исходной задаче прямого отношения.
<?
// готовим и отдаем пользователю http отчет
fastcgi_finish_request();
// отправка почты или другой долгоживущий процесс
Зря вы называете тот топик провокационным. Я с ним частично (как и вы согласен). То что он не по всем пунктам прав — это не провокационность, он просто в погоне за недочетами переборщил.
Но это как минимум справочник граблей, верно? :)
Но это как минимум справочник граблей, верно? :)
Там ещё была не точность о избыточности синтаксиса для IF (альтернативный синтаксис).
Понятней, чем
Я уже давно не пишу на PHP, но помню момент, когда спервые узнал о таком синтаксисе… он очень удобен. Возможно на коротком примере все не так ясно, но на большом макете хорошо ощущается.
<?php if($someting !== ''): ?>
<div class="info"><?php echo $someting ?></div>
<?php endif ?>
Понятней, чем
<?php if($someting !== ''){ ?>
<div class="info"><?php echo $someting ?></div>
<?php } ?>
Я уже давно не пишу на PHP, но помню момент, когда спервые узнал о таком синтаксисе… он очень удобен. Возможно на коротком примере все не так ясно, но на большом макете хорошо ощущается.
Вообще не понимаю к чему весь этот спор. Не нравится — не кушай. Сейчас выбор технологий\языков просто огромен. Выбирай любой.
Подобные статьи, как PHP: a fractal of bad design, очень полезны для того, чтобы выявить и показать недостатки.
Такие статьи, как эта — чтобы объяснить, что не всё так плохо и минусы есть у любого другого языка и инструмента, а так же, что не надо бросать всё и быстрее переходить на другой язык. Не факт, что завтра не появится подобная статья про тот же питон.
Такие статьи, как эта — чтобы объяснить, что не всё так плохо и минусы есть у любого другого языка и инструмента, а так же, что не надо бросать всё и быстрее переходить на другой язык. Не факт, что завтра не появится подобная статья про тот же питон.
НЛО прилетело и опубликовало эту надпись здесь
echo "4.2" == "4.20";Выводит 1… У меня нет комментариев просто
об этом уже не раз писалось.
Вас это тоже, наверное, удивит:
Используйте строгое сравнение.
Вас это тоже, наверное, удивит:
var_dump ("4.2" == true); // true
Используйте строгое сравнение.
var_dump ("4.2" === "4.20"); // false
Просто в данном случае явно две строки, зачем их в какие-то другие типы конвертировать?
Непонятна логика разработчиков :)
Непонятна логика разработчиков :)
в моем примере вообще разные типы сравниваются )))
Логика, конечно, тоже мне не понятна. Но всё-равно мне нравится PHP. И пусть пинают дальше ненавистники )))
Логика, конечно, тоже мне не понятна. Но всё-равно мне нравится PHP. И пусть пинают дальше ненавистники )))
не понимаю, кто постоянно минусует мои комменты. Что, правда глупости пишу? От своей точки зрения всё-равно не отступлюсь.
Я думаю, что основной вопрос, который интересует многих — пробовал ли вы Python или Ruby для тех же задач, что и PHP?
не понимаю, как это связано и почему именно питон и руби, но писал на нескольких языках и есть с чем сравнивать. Или кого-то интересует, не го%#окодер ли я?
НЛО прилетело и опубликовало эту надпись здесь
Я пробовал. Писать приложение (с фреймворками) приятнее (если забыть про недостатки ActiveRecord) и даже если решу писать свое приложение, то буду использовать, скорее всего, RoR или Sinatra. Но вот разработка на заказ несколько другое дело. Использую RoR максимум для прототипирования — рисую модельки, скаффолдю, гемы ставлю похожие к требованиям, деплою на heroku, показываю, заказчик утверждает прототип (после нескольких итераций обычно), я его переписываю на symfony, обычно без использования сторонних бандлов. Я тупо не могу заказчику объяснить как ему развернуть простейшее RoR-приложение из архива с исходниками на своем сервере, как обновлять те же рельсы, да и сам ruby. Даже с PECL расширениями проще, имхо, (под никсами) объяснить. Да и наличие инструкции не всегда спасает: вспоминаю свой опыт поднятия Redmine — вроде понятно в целом, но нюансы…
Имхо, RoR/Django годятся для больше всего для проектов типа интернет-стартапов или больших контор, которые могут держать в штате администраторов и разработчиков или аутсорс поддержки полного цикла. Для создания стандартных (по функциональности) представительств небольших или средних фирм в вебе, попутной онлайн-торговли в добавок к оффлайн и т. п. «под ключ», имхо, не лучший выбор. CMS на PHP с кастомными модулями обычно лучший выбор.
Имхо, RoR/Django годятся для больше всего для проектов типа интернет-стартапов или больших контор, которые могут держать в штате администраторов и разработчиков или аутсорс поддержки полного цикла. Для создания стандартных (по функциональности) представительств небольших или средних фирм в вебе, попутной онлайн-торговли в добавок к оффлайн и т. п. «под ключ», имхо, не лучший выбор. CMS на PHP с кастомными модулями обычно лучший выбор.
Есть куча гемов для деплоя, которые могут разворачивать полностью систему без вмещательства человека (Putty только запусить и ввести 1-2 команды).
Скажите название гема, который полностью развёрнёт приложение на рельсах на «голом» debian-mini с ssh. Bat cкрипт для заказчика я напишу для его запуска.
Chef и Capistrano не предлагать :) Я их использую для деплоя php-приложений, но это не то, это просто автоматизация рутинных действий.
Chef и Capistrano не предлагать :) Я их использую для деплоя php-приложений, но это не то, это просто автоматизация рутинных действий.
Пакет github.com/roundlake/nginxifier с личного зеркала + Capistrano ;)
> Chef и Capistrano не предлагать
> это просто автоматизация рутинных действий.
А разве гемы для деплоя… это не автоматизация рутинных действий? А гемов для деплоя довольно много, на любой вкус www.ruby-toolbox.com/categories/deployment_automation
Мне проще все сделать на Capistrano.
> это просто автоматизация рутинных действий.
А разве гемы для деплоя… это не автоматизация рутинных действий? А гемов для деплоя довольно много, на любой вкус www.ruby-toolbox.com/categories/deployment_automation
Мне проще все сделать на Capistrano.
А для нормального рабочего проекта версии Ruby и все гемов запекаются (rvm), чтобы через полгода кто-то случайно не обновил гемы и система не сломалась.
Redmine поднимается достаточно просто, буквально 10 строчек в терминале.
Redmine поднимается достаточно просто, буквально 10 строчек в терминале.
Странно, что же мешает написать bundle update rails или обновить руби одной строчкой через rvm…
Что нужны bundle и rvm, причём последний ставится из исходников (.deb пакет из Ubuntu просто выводит, что нужно ставить wget).
Ну sudo apt-get install php5 (или как там?) наверное проще, да. Но после разработки проекта для заказчика я не вижу препятствий уделить 15 минут времени, и поставить ему ruby и все гемы. Тем более, что rvm закачивается и устанавливается одной строчкой, благодаря curl.
Rvm ставится одной строчкой
Через него ставится нужная версия руби, с ней уже идет bundler, потом просто
$ curl -L get.rvm.io | bash -s stable
Через него ставится нужная версия руби, с ней уже идет bundler, потом просто
bundle install. Не надо никаких архивов, что-то качать, ставить руками и т.д. По сложности аналогично apt-get имхо. помойму, в PHP нет типов, а есть контекст. В момент вычисления выражения, в зависимости от контекста, юниту динамически выдается временный тип. То есть, в случае со строками не было никакой конвертации типов, было очень специфическое вычисление контекста.
//могу ошибаться
//могу ошибаться
PHP получает все входные данные в виде строк, и выдаёт так жн. А сравнение чисел обычно требуется. То есть под сравнением «4.2» == «4.20» чаще всего имеется в виду (float)«4.2» == (float)«4.20», а не «побитовое» сравнение. Да и вообще ЦА первых версий PHP были не программисты вроде как, им что такое строгая типизация или приведение типов не очень понятно и почему введенное пользователем «4.2» не равно полученному из базы «4.20» понять сложно (наверное). А потом груз совместимости…
Это не попытка оправдания, а попытка понять логику разработчиков.
Это не попытка оправдания, а попытка понять логику разработчиков.
А разве они не равны?
«4.2» — строка из 3х байт
«4.20» — строка из 4х байт
Как минимум это, уже говорит о том, что они не равны ) Хотя видимо во вселенной PHP действуют свои правила сравнения :)
«4.20» — строка из 4х байт
Как минимум это, уже говорит о том, что они не равны ) Хотя видимо во вселенной PHP действуют свои правила сравнения :)
Они приводятся к числам и сравниваются, об этом прямо написано в мануале.
Суровый русский парень такой русский
НЛО прилетело и опубликовало эту надпись здесь
> т.е для вас это не странно?
*даже если они странные и нелогичные* (чуть выше написано).
> Две разные строки парсятся и приводятся к числлу!
Это касается только числовых строк. («4.2a» == «4.20a») будет false
> Java
Забавный у вас подход — не очевидная особенность в java, это фича, а у php сразу косяк
(хотя и то и это задокументировано).
*даже если они странные и нелогичные* (чуть выше написано).
> Две разные строки парсятся и приводятся к числлу!
Это касается только числовых строк. («4.2a» == «4.20a») будет false
> Java
Забавный у вас подход — не очевидная особенность в java, это фича, а у php сразу косяк
(хотя и то и это задокументировано).
НЛО прилетело и опубликовало эту надпись здесь
Используйте "===" и ничего ни к чему не будет приводиться.
НЛО прилетело и опубликовало эту надпись здесь
Есть оператор "===", который ведет себя как в строго типизированных языках.
Есть оператор "==", который пытается приводить одни типы в другие и получает не строгое сравнение. Его поведение помимо документации описано и разжевано тысячами статей. По-моему, такая реализация вполне справляется со своей задачей.
Почему "==" работает именно так? Не знаю, а как по вашему он должен работать?
$a = 23
$a_request = (int) $_POST['a']
echo $a_request === $a // 1Есть оператор "==", который пытается приводить одни типы в другие и получает не строгое сравнение. Его поведение помимо документации описано и разжевано тысячами статей. По-моему, такая реализация вполне справляется со своей задачей.
$a = 23
$a_request = $_POST['a']
echo $a_request == $a // 1Почему "==" работает именно так? Не знаю, а как по вашему он должен работать?
НЛО прилетело и опубликовало эту надпись здесь
Я просто не понимаю зачем две строки приводить к float
Мы получили две переменные, одну прочитали из фала, то есть тип у нее строковый, вторую получили из input-формы с модным jQuery плагином, она, тоже, придет в строковом виде.
В файле она хранится в таком виде: «4.2»
А из input приходит в таком: «4.20»
Обе переменные string, хотя по логике работы нашей программы это цены в float-формате. Потому, они должны быть равны, что и делает "==".
И так бывает очень часто, значительно чаще, чем строки состоящие из таких символов. Хотя да, в некоторых случаях могут быть ошибки, именно на этом основывается критика динамической типизации.
PHP еще позволяет приводить к типам и все такое, есть довольно популярный язык, я бы даже сказал монополист, в котором и этого нет.
Если это цены, то они должны быть строками и конвертировать их во float недопустимо.
Что значит недопустимо? А как я узнаю, что стоимость товара совпадает с внесенной суммой?
В идеальной вселенной для денег должен быть отдельный формат, как во многих других языках.
В сложившихся реалиях, идеологи-теоретики, действительно, говорят о хранении в строках и обработкой специальными библиотеками.
Но это все не важно, если вам будет так легче обсуждать вопрос, пускай это будет вес или его, тоже, только в строке?
В идеальной вселенной для денег должен быть отдельный формат, как во многих других языках.
В сложившихся реалиях, идеологи-теоретики, действительно, говорят о хранении в строках и обработкой специальными библиотеками.
Но это все не важно, если вам будет так легче обсуждать вопрос, пускай это будет вес или его, тоже, только в строке?
> В идеальной вселенной для денег должен быть отдельный формат
Для некоторых (и меня в том числе) это как раз реальность…
> А как я узнаю, что стоимость товара совпадает с внесенной суммой?
Смотрите в сторону BCMath (http://ru.php.net/bcmath).
Для некоторых (и меня в том числе) это как раз реальность…
> А как я узнаю, что стоимость товара совпадает с внесенной суммой?
Смотрите в сторону BCMath (http://ru.php.net/bcmath).
Вы потролить меня решили?
Я понимаю риски использования float и всегда предупреждаю о них заказчиков, пока никто не говорил, что для него это критично и как следствие я никогда не занимался этим вопросом, не компетентен в этом обсуждении и не собирался/собираюсь в него вступать.
По первоначальной теме:
Отсутствие денежного формата — однозначно минус языка.
По сравнению вопрос исчерпан?
Я понимаю риски использования float и всегда предупреждаю о них заказчиков, пока никто не говорил, что для него это критично и как следствие я никогда не занимался этим вопросом, не компетентен в этом обсуждении и не собирался/собираюсь в него вступать.
По первоначальной теме:
Отсутствие денежного формата — однозначно минус языка.
По сравнению вопрос исчерпан?
> Я понимаю риски использования float и всегда предупреждаю о них заказчиков
Они и не могут ничего сказать, т.к. не понимают (и не должны понимать) и им все равно (у них задачи совсем другие и им некогда вникать во все это).
> Отсутствие денежного формата — однозначно минус языка.
Использовать несколько функций вместо операторов не настолько сложно чтобы забивать на это. Да и класс при желании можно найти/написать.
> Не поверите, можно привести к float и сравнить через "===".
Ага, отличная мина на будущее, кстати (в случае с ценами).
Они и не могут ничего сказать, т.к. не понимают (и не должны понимать) и им все равно (у них задачи совсем другие и им некогда вникать во все это).
> Отсутствие денежного формата — однозначно минус языка.
Использовать несколько функций вместо операторов не настолько сложно чтобы забивать на это. Да и класс при желании можно найти/написать.
> Не поверите, можно привести к float и сравнить через "===".
Ага, отличная мина на будущее, кстати (в случае с ценами).
1
НЛО прилетело и опубликовало эту надпись здесь
а самому явно нельзя их привести к float или к какому-нибудь другому денежнему типу данных? больше магии! Всякой разной!
Не поверите, можно привести к float и сравнить через "===". Как вам удобно. И так даже лучше — меньше вероятность непонятных ошибок.
Язык о нас заботится, не заставляет лишний раз писать
(float). Не нравится? Лениво изучать правила приведения типов при сравнении, которые кажутся очевидными любому человеку, который про «ваши» типы и не слышал ни разу? Пользуйтесь строго типизированными языками. А уж если решили воспользоваться слаботипизированными (да даже сильно), то будьте добры изучить нюансы типизации. По-моему это очевидно для любого, кто знает о существовании различных типов типизации.НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Может лично вам не писал, но в топике упоминал, что я не защищаю PHP как идеальный язык. Его недостатки я знаю достаточно хорошо (по крайней мере на уровне интуиции, изложить все без подготовки затруднюсь). Он меня начал бесить с момента первого знакомства, но Perl бесил больше, а о Ruby и Python в то время и не слышал. А компилировать на C, пытаясь подстроить окружение на винде под BSD, было мало привлекательно, да и PHP на простых запросах работал быстрее, чем CGI на C.
Вам напомнить как и для кого создавался PHP? А что такое обратная совместимость знаете? А сколько вайна вызвал переход от одного способа указания на конструкторы к другому между 4 и 5 не помните?
Насчёт разыменования массивов ничего не скажу. Почему так долго не вводилось непонятно, на код людей, не знающих о массивах-шмассивах это не влияло.
Насчёт разыменования массивов ничего не скажу. Почему так долго не вводилось непонятно, на код людей, не знающих о массивах-шмассивах это не влияло.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Я программирую много на чём. И вообще мне нравится идеология функциональных языков. но это я делаю для себя, а деньги зарабатываю PHP. Мне он не нравится по сравнению со многими другими (разве что VB6 больше отвращения вызывал), но лучшего для себя варианта зарабатывать программированием я не вижу. А программировать в принципе мне нравится больше, чем не нравятся недостатки PHP. Да ещё в вебе… Я б «за еду» на рельсах писал, но никто не соглашается взять на работу за 10к — предлагал не раз.
Кстати, есть еще один случай, о котором часто забывают :)
switch ('4.2') {
case '4.20':
echo 'true';
break;
default:
echo 'false';
break;
}
switch ('4.2') {
case '4.20':
echo 'true';
break;
default:
echo 'false';
break;
}
Лично я всегда опасаюсь оперировать понятиями «строка», «целое число», «вещественное число» в языках с нестрогой типизацией. Если я явно не указываю, что у меня переменная является строкой, то почему я должен ждать от интерпритатора, что он догадаеться и переменная всегда будет вести себя как строка?
Ведь основная идея нестрогой типизации, на мой взгляд, именно в возможности использования строки как числа без явного приведения, в зависимости от контекста операции.
Да в некоторых ситуацих такая типизация может доставить головняков, но ведь есть инструменты для обхода данной ситуации.
А для тех кому неявное приведение очень не нравиться есть куча языков со строгой типизацией и набором функций, типа atoi.
Ведь основная идея нестрогой типизации, на мой взгляд, именно в возможности использования строки как числа без явного приведения, в зависимости от контекста операции.
Да в некоторых ситуацих такая типизация может доставить головняков, но ведь есть инструменты для обхода данной ситуации.
А для тех кому неявное приведение очень не нравиться есть куча языков со строгой типизацией и набором функций, типа atoi.
Я бы сказал, что строго они не равны, а по здравому смыслу — похожи и в общем одинаковы. Думаю этим и руководствовались разработчики — удобством.
А разве они равны?
А смотря с какой точки зрения смотреть. С точки зрения человека, ничего не знающего о типах переменных, да и переменных вообще и воспринимающего слово «строка» как часть страницы в книге — вполне равны, не идентичны, но равны.
JAVA
Integer a = 120;
Integer b = 120;
Integer c = 130;
Integer d = 130;
System.out.println(a==b); // true
System.out.println(c==d); // false
У меня нет комментариев просто. Это я к тому что в каждом языке есть свои особенности. Проблема не в языке обычно, а в разработчике
Integer a = 120;
Integer b = 120;
Integer c = 130;
Integer d = 130;
System.out.println(a==b); // true
System.out.println(c==d); // false
У меня нет комментариев просто. Это я к тому что в каждом языке есть свои особенности. Проблема не в языке обычно, а в разработчике
НЛО прилетело и опубликовало эту надпись здесь
Что то, что другое «это невозможно понять — это нужно запомнить». Но приведение строки, содержащую число, к числу куда более логично с точки зрения простого человека, не отягощенного знаниями о типах.
В java имхо все понятно — сравниваются ссылки, которые могут быть разными для объектов в совпадающим содержимым, а могут быть и одинаковыми. В ехал сравнивать сроки этим оператором бессмыслено — либо нет гарантии, что они сравнятся правильно, либо мы точно знаем, что там числа и тогда не плохо бы сначала указать в каком формате. В java поведение предсказуемо логично и выводится из понятия boxing.
Ох, самая банальнейшая особенность, которая, при большом желании правиться на раз*, таким вот флагом -Djava.lang.Integer.IntegerCache.high=<любое значение, хоть 2^31>.
*минимальное значение кэша все так же жестко забито и равно -128
*минимальное значение кэша все так же жестко забито и равно -128
Потому что в java объекты надо сравнивать по equals и проблем не будет.
Про этот косяк в джаве ещё Гослинг писал, и это проблемы именно языка, а не разработчика.
Но в java, согласитесь, таких неожиданных пасхальных яиц на порядки меньше.
PHP мне представляется просто парсером текста — такие мы сами писали в школе и универе, с такими же проблемами — когда нет копмплексного подхода к языку. Если бы это был нормальный язык, то такие базовые вещи были бы решены с самого начала.
Просто это тулза, которая изначально предназначена для непрограммистов.
Но в java, согласитесь, таких неожиданных пасхальных яиц на порядки меньше.
PHP мне представляется просто парсером текста — такие мы сами писали в школе и универе, с такими же проблемами — когда нет копмплексного подхода к языку. Если бы это был нормальный язык, то такие базовые вещи были бы решены с самого начала.
Просто это тулза, которая изначально предназначена для непрограммистов.
Вы еще сравните '0xff' и '255'. Будет тру. При этом '0123' == 0123 будет фолс
Не знаю. Уже после нескольких недель общения с Питоном я решил отказаться от PHP, хотя до этого использовал его далеко не один год. Не буду утвержать, что тот или иной язык лучше PHP, но мне кажется, что разок попробовать, что-то вроде Питона (+Django) или Руби (+RoR) стоит.
НЛО прилетело и опубликовало эту надпись здесь
Ну, ноду я бы не стал предлагать. Да, это сейчас модно, «мейнстрим» и всё такое, но проблем тоже хватает. Имхо, нода сейчас где-то как Руби (+RoR) два-три года назад.
НЛО прилетело и опубликовало эту надпись здесь
Что интересно, ни один аргумент относительно php как языка (а не платформы) автор даже не попытался конраргументировать.
В общемслив не защитан достаточно аргументированного ответа не получилось даже близко.
P.S: «Кто прав» — меня мало волнует и своим комментарием я этот вопрос даже не затрагиваю
В общем
P.S: «Кто прав» — меня мало волнует и своим комментарием я этот вопрос даже не затрагиваю
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Да, про нее, родимую.
На самом деле полностью согласен, статья про фракталы написана в блоггерском стиле «белок-истеричек» («ааааа, в пэхэпэ нельзя использовать == !!!!111адын»).
Но ответ (а ведь он позиционировался как ответ, не правда ли?) получился полным жеванием соплей — «неее, ну не всё так плохо, на самом деле это вполне мощный язык, вы не представляете, сколько можно сделать молотком с раздвоенным бойком. да и пассатижей с ребристыми губками я не видел ни в одном фреймворке».
В статье про фракталы был конструктив. Хотя бы повод «всрепенуться» разработчкикам ядра. «Долго в цепях нас держали», ага. Мир стал чуточку лучше :)
А тут нет ничего. А хотелось. Ну не так же php плох, каким кажется (Доктор, что со мной? Кошмаркошмаркошмар? — Да нет, просто кошмар). После десятка лет разработки любой язык вызывает дикий батхёрт (мог бы точно так же долго истекать желчью на тему cpp/perl/python, но who cares?)
На самом деле полностью согласен, статья про фракталы написана в блоггерском стиле «белок-истеричек» («ааааа, в пэхэпэ нельзя использовать == !!!!111адын»).
Но ответ (а ведь он позиционировался как ответ, не правда ли?) получился полным жеванием соплей — «неее, ну не всё так плохо, на самом деле это вполне мощный язык, вы не представляете, сколько можно сделать молотком с раздвоенным бойком. да и пассатижей с ребристыми губками я не видел ни в одном фреймворке».
В статье про фракталы был конструктив. Хотя бы повод «всрепенуться» разработчкикам ядра. «Долго в цепях нас держали», ага. Мир стал чуточку лучше :)
А тут нет ничего. А хотелось. Ну не так же php плох, каким кажется (Доктор, что со мной? Кошмаркошмаркошмар? — Да нет, просто кошмар). После десятка лет разработки любой язык вызывает дикий батхёрт (мог бы точно так же долго истекать желчью на тему cpp/perl/python, но who cares?)
> Нет отладчика – в PHP есть xdebug, который великолепно работает
не знаю как сейчас, а когда-то мне пришлось писать свой фреймворк, чтобы Zend Studio могло отлаживать любые скрипты с любого места, а не только тот, что непосредственно запущен.
В частности, у отладчика ZS к чертям собачьим сносило относительные пути к файлам, в результате пришлось писать хитрый ресолвер, который в зависимости от способа запуска (продакшен или дебаг в ZS, определялся по какому-то багу дебаггера, лол) менял стратегию подгрузки ресурсов. Что честности отладке никак не добавляло.
> Проблемы видимости с глобальными переменными – он находит в этом нечто диковинное.
да, глобальные переменные просто не нужны. у отсутствующих глобальных переменных — проблемы отсутствуют.
> Статические переменные внутри методов экземпляра глобальны – это правда, потому что это именно то, для чего они предназначены.
еще одна попытка протолкнуть глобальные переменные, теперь статиками. Да выбросьте вы уже свои глобальные переменные! Чем больше вы нафигачите такого кода, тем сложнее будет писать тесты. TDDшники будут вас ненавидеть.
> PHP привязан к Apache – это откровенная чушь:
PHP привязан к веб-серверу, который нужно конфигурять. Ну нету у него by default своего собственного веб-сервера, чтобы не быть ни к чему привязанным. В Java, например, в приложение можно внедрить веб-сервер (Playframework использует Netty и отчаянно рекомендует запускать всё именно на нем, в любое другое обычное приложение можно запихнуть Jetty). В инфраструктуре Microsoft всё заточено на IIS, который просто работает и легко конфигуряется (в отличие от апача).
> Цикл жизни приложения от запроса к запросу… leads to infinite horizontal scalability in the language itself.
в C#/Java тоже можно сделать by-request и REST. Только там можно сделать и кое-что другое, а в PHP — нет. Придется писать воркеры на других языках — на том же C#/Java… но тогда зачем нужен PHP? :)
не знаю как сейчас, а когда-то мне пришлось писать свой фреймворк, чтобы Zend Studio могло отлаживать любые скрипты с любого места, а не только тот, что непосредственно запущен.
В частности, у отладчика ZS к чертям собачьим сносило относительные пути к файлам, в результате пришлось писать хитрый ресолвер, который в зависимости от способа запуска (продакшен или дебаг в ZS, определялся по какому-то багу дебаггера, лол) менял стратегию подгрузки ресурсов. Что честности отладке никак не добавляло.
> Проблемы видимости с глобальными переменными – он находит в этом нечто диковинное.
да, глобальные переменные просто не нужны. у отсутствующих глобальных переменных — проблемы отсутствуют.
> Статические переменные внутри методов экземпляра глобальны – это правда, потому что это именно то, для чего они предназначены.
еще одна попытка протолкнуть глобальные переменные, теперь статиками. Да выбросьте вы уже свои глобальные переменные! Чем больше вы нафигачите такого кода, тем сложнее будет писать тесты. TDDшники будут вас ненавидеть.
> PHP привязан к Apache – это откровенная чушь:
PHP привязан к веб-серверу, который нужно конфигурять. Ну нету у него by default своего собственного веб-сервера, чтобы не быть ни к чему привязанным. В Java, например, в приложение можно внедрить веб-сервер (Playframework использует Netty и отчаянно рекомендует запускать всё именно на нем, в любое другое обычное приложение можно запихнуть Jetty). В инфраструктуре Microsoft всё заточено на IIS, который просто работает и легко конфигуряется (в отличие от апача).
> Цикл жизни приложения от запроса к запросу… leads to infinite horizontal scalability in the language itself.
в C#/Java тоже можно сделать by-request и REST. Только там можно сделать и кое-что другое, а в PHP — нет. Придется писать воркеры на других языках — на том же C#/Java… но тогда зачем нужен PHP? :)
TDDшники будут вас ненавидеть.
Сам практикую TDD и вполне справляюсь со статиками. Плохой практикой считаю их по другому — сложность с IoC.
В инфраструктуре Microsoft всё заточено на IIS, который просто работает и легко конфигуряется (в отличие от апача)
IIS отлично конфигуряется? Через regedit? А Apachе чем плохо? Подробностей не помню, но вроде достаточно простой текстовый конфиг залить, даже не имея доступа по ssh. А то и вообще в строке запуска сконфигурять (наверное, не уверен).
Сам практикую TDD и вполне справляюсь со статиками. Плохой практикой считаю их по другому — сложность с IoC.
В инфраструктуре Microsoft всё заточено на IIS, который просто работает и легко конфигуряется (в отличие от апача)
IIS отлично конфигуряется? Через regedit? А Apachе чем плохо? Подробностей не помню, но вроде достаточно простой текстовый конфиг залить, даже не имея доступа по ssh. А то и вообще в строке запуска сконфигурять (наверное, не уверен).
«Мальцик спрашивает у робота:
— Что можно делать?
— Все можно.
— А это можно?
— Нельзя.
— А это?
— Нельзя.
— Ну а вот это?
— Нельзя.
— А что же тогда можно?
— Все можно...»
Вспомнил один советский фильм, названия, к сожалению не помню, но общение мальчика и робота, как по мне, прекрасно описывает «общение» PHP-иста и PHP-языка.
Язык действительно очень проблемный. Но его тоже можно использовать, для определенных задач. Вообще не думаю, что стоит сравнивать языки, все-равно все фломастеры на вкус и цвет разные, все мы люди и у всех нас разные вкусы, кому-то это нравится.
— Что можно делать?
— Все можно.
— А это можно?
— Нельзя.
— А это?
— Нельзя.
— Ну а вот это?
— Нельзя.
— А что же тогда можно?
— Все можно...»
Вспомнил один советский фильм, названия, к сожалению не помню, но общение мальчика и робота, как по мне, прекрасно описывает «общение» PHP-иста и PHP-языка.
Язык действительно очень проблемный. Но его тоже можно использовать, для определенных задач. Вообще не думаю, что стоит сравнивать языки, все-равно все фломастеры на вкус и цвет разные, все мы люди и у всех нас разные вкусы, кому-то это нравится.
Вообще-то под «объектами первого класса» подразумевают сущности, которыми можно оперировать как объектами: доступ к свойствам\методам, передача как аргумент функции, возврат как значение функции, присваивание переменным (если есть переменные).
HTTP объект первого класса?
да я ваш headers already посылал!
HTTP объект первого класса?
да я ваш headers already посылал!
Цикл жизни приложения от запроса к запросу.
Никто не слышал про True FastCGI для PHP? Короче, можно сделать по другому и приложение не будет завершатся, там что-то вроде событий — создание воркера, запрос, завершение работы воркера.
Хостеры не используют True FastCGI, потому, что сайт висит в памяти и это не целесообразно для сайтов с посещаемостью 10 человек/день.
С PHP может потягаться node.js со своей событийной моделью. А так PHP 5.4 современный полноценный интерпретируемый язык программирования. По количеству инструментов, в том числе и разных фич по масштабированию рвет всех конкурентов в сфере веба.
Потоки, кстати, тоже есть (не говоря уже о различных костылях) но, по опыту, в не юзабельном виде. Потоки — это сложно в отладке и разработке, потому они в этой сфере вообще мало где используются, даже если язык это позволяет. А в тех случаях, где это необходимо, обычно, уместнее на C++ дописать. Но, если вы собираетесь писать приложение, где во всю используются потоки, то действительно лучше выбрать другой язык.
Справедливости ради:
Большой минус — не согласованность. Запомнить имена функций очень сложно. Давно пора написать стандартные классы с методами и свойствами, которые будут адекватно и согласованно называться. Хотя можно просто использовать фреймворк.
Автор не осветил один, возможно самый главный на сегодня, фактор популярности PHP — этот язык программирования поддерживается на 99% хостингов. Поэтому если ты разработчик web-софта и хочешь, чтобы твое ПО запускалось на большинстве хостингов, у тебя просто не остается выбора — или PHP или Perl.
Я выбрал PHP. Мне нравится этот язык, но мне не нравится, что у меня нет выбора.
Drupal, Wordpress, Joomla, Drupal, vBulletin не смогли бы стать такими популярными, если бы были написаны НЕ на PHP, т.к. в этом случае большинство пользователей просто не смогло бы их установить на своем любимом хостинге.
Я выбрал PHP. Мне нравится этот язык, но мне не нравится, что у меня нет выбора.
Drupal, Wordpress, Joomla, Drupal, vBulletin не смогли бы стать такими популярными, если бы были написаны НЕ на PHP, т.к. в этом случае большинство пользователей просто не смогло бы их установить на своем любимом хостинге.
99% шаред хостингов за 5$ с жутким оверселом. Цены на VPS уже давно позволяют запускать все, что душе угодно.
> vBulletin, Wordpress
Первый это PHP-shell со встроенным форумный движком и коряво зануленый, а второй это PHP-shell со встроенным blog engine? Вы еще DLE сюда притяните. Кстати, все перечисленные движки не работают на хостингах за 5$.
> vBulletin, Wordpress
Первый это PHP-shell со встроенным форумный движком и коряво зануленый, а второй это PHP-shell со встроенным blog engine? Вы еще DLE сюда притяните. Кстати, все перечисленные движки не работают на хостингах за 5$.
Т.е. вы действительно считаете, что отсутствие поддержки, например, Python на большинстве виртуальных хостингов не влияет негативно на его популярность? Если да, то я с вами категорически не согласен.
Вот меня умиляют эти советчики с VPS.
Они почему-то всегда уверены, что люди которые даже бывает WordPress с первого раза поставить не могут, как только купят VPS так сразу с легкостью наставят туда Python и/или Ruby, и CMS-ки на них. Ах да CMS, на Python/Ruby еще попробуй найди. Ну ничего они быстренько напишут свою.
Они почему-то всегда уверены, что люди которые даже бывает WordPress с первого раза поставить не могут, как только купят VPS так сразу с легкостью наставят туда Python и/или Ruby, и CMS-ки на них. Ах да CMS, на Python/Ruby еще попробуй найди. Ну ничего они быстренько напишут свою.
> Они почему-то всегда уверены, что люди которые даже бывает WordPress с первого раза поставить не могут, как
Мы же сейчас про программистов говорим. Хотя стоп, они же на пыхе пишут!
> Ах да CMS, на Python/Ruby еще попробуй найди. Ну ничего они быстренько напишут свою.
Radiant, refinery. А так да, намного логичнее написать приложение конкретно под заказчика, чем тянуть всякое ненужное говно.
Мы же сейчас про программистов говорим. Хотя стоп, они же на пыхе пишут!
> Ах да CMS, на Python/Ruby еще попробуй найди. Ну ничего они быстренько напишут свою.
Radiant, refinery. А так да, намного логичнее написать приложение конкретно под заказчика, чем тянуть всякое ненужное говно.
Так уж исторически сложилось, что программисты не только для себя пишут. И большинство сайтов в web вполне себе типичны. И писать что-то под конкретного заказчика никто не будет, так как этого много времени и соответственно денег.
Radiant, refinery видел, как-то сильно примитивно выглядят.
Radiant, refinery видел, как-то сильно примитивно выглядят.
> Так уж исторически сложилось, что программисты не только для себя пишут. И большинство сайтов в web вполне себе типичны. И писать что-то под конкретного заказчика никто не будет, так как этого много времени и соответственно денег.
Большинство вэбсайтов вообще можно заменить генератором статических вэбсайтов.
> Radiant, refinery видел, как-то сильно примитивно выглядят.
Писать расширения под refinery очень просто, потому, что:
1) Код понятный
2) Код выполнен в одном стиле
3) Адекватный дизаин приложения в целом.
Большинство вэбсайтов вообще можно заменить генератором статических вэбсайтов.
> Radiant, refinery видел, как-то сильно примитивно выглядят.
Писать расширения под refinery очень просто, потому, что:
1) Код понятный
2) Код выполнен в одном стиле
3) Адекватный дизаин приложения в целом.
намного логичнее написать приложение конкретно под заказчика
где бы ещё всегда находить таких разумных заказчиков да с деньгами
Менять PHP-shell на root-shell?
поддерживаю. Кроме этого, какай еще язык может похвастать таким количеством фреймворков?
Просто завистники поливают грязью как обычно. Есть два подхода: первый — уличать баги, улучшать/совершенствовать, находить обходные пути, второй — называть отстоем и писать быдлокод на чём-либо.
Чем дальше, тем больше напоминает гоху. В любую тему приходит толпа пхпвовбоев, которые с радостным блеском в глазах начинают доказывать что %name% ничто по сравнению с The Ultimate Языком Игрой, побеждая в любом споре не аргументацией, а количеством.
Улыбает
Улыбает
habrahabr.ru/post/115689/ Вот этот код я переписал практически без изменений (не считая синтаксиса языка), при этом скорость работы алгоритма меня приятно удивила (ожидал увидеть черепашку).
PHP — мой любимый язык. На нем можно даже GUI писать (http://habrahabr.ru/post/19004/)
Так же в данный момент работают несколько многопоточных сокет-серверов на PHP.
PHP может все, но для каждой конкретной задачи нужно выбирать свой язык. Не говорите, что php медленный! Он просто вынужден быть таким.
Забыл про сладкое… на любой фриланс бирже для PHP программистов как медом намазано. Этот язык кормит меня и мою семью.
PHP — мой любимый язык. На нем можно даже GUI писать (http://habrahabr.ru/post/19004/)
Так же в данный момент работают несколько многопоточных сокет-серверов на PHP.
PHP может все, но для каждой конкретной задачи нужно выбирать свой язык. Не говорите, что php медленный! Он просто вынужден быть таким.
Забыл про сладкое… на любой фриланс бирже для PHP программистов как медом намазано. Этот язык кормит меня и мою семью.
Мне кажется — единственный недостаток PHP — это весь тот говнокод, который пишут новички и пытаются продать. Мечтаю об обязательном объявлении переменных и типов без автоматического приведения.
Итак, кого же мы имеем в качестве комментаторов в подобных темах?
Два типажа — пишут на других языках и при этом:
1. С PHP знаком только по приложениям вроде Wordpress (vBulliten и т.п.). Считает, что все PHP-приложения написаны так же, как и Wordpress.
2. Приходилось переписывать PHP-код, написанный кодерами, которых уволили (или сами сбежали). Естественно, этот код оказался ужасен, так как подобные истории происходят как раз в случае некачественной разработки (в нормальных проектах команда просто так не меняется).
Эти два типажа заявляются в подобных темах, и начинают критиковать в первую очередь не PHP (потому что на самом деле все недостатки PHP второстепенны), а PHP-программистов.
Они считают, что все PHP-программисты — неудачники, не умеющие работать, которых нанимают только потому что на нормальных людей не хватило денег (про состояние рынка труда они также имеют весьма слабое представление).
Если в комментариях появляется знающий человек и начинает с ними спорить, то они берут любой второстепенный недостаток и заявляют, что с этим работать невозможно и ни один нормальный разработчик добровольно с этим жить не будет.
Кстати, обсуждения типа Python vs Ruby vs Java и т.п. тоже весьма забавно происходят, цирк еще тот.
Два типажа — пишут на других языках и при этом:
1. С PHP знаком только по приложениям вроде Wordpress (vBulliten и т.п.). Считает, что все PHP-приложения написаны так же, как и Wordpress.
2. Приходилось переписывать PHP-код, написанный кодерами, которых уволили (или сами сбежали). Естественно, этот код оказался ужасен, так как подобные истории происходят как раз в случае некачественной разработки (в нормальных проектах команда просто так не меняется).
Эти два типажа заявляются в подобных темах, и начинают критиковать в первую очередь не PHP (потому что на самом деле все недостатки PHP второстепенны), а PHP-программистов.
Они считают, что все PHP-программисты — неудачники, не умеющие работать, которых нанимают только потому что на нормальных людей не хватило денег (про состояние рынка труда они также имеют весьма слабое представление).
Если в комментариях появляется знающий человек и начинает с ними спорить, то они берут любой второстепенный недостаток и заявляют, что с этим работать невозможно и ни один нормальный разработчик добровольно с этим жить не будет.
Кстати, обсуждения типа Python vs Ruby vs Java и т.п. тоже весьма забавно происходят, цирк еще тот.
«PHP — тысяча и один способ выстрелить в себе ногу за 5 минут».
себе в ногу *
Мое невежественное мнение: изучал c#(в т.ч. asp.net) — праздник каждый день, только и удивлялся — а оно еще и вот это умеет.
Изучаю сейчас php — море геморроя, ничего не работает и непонятно почему.
Заметки на полях:
1) Чтоб получить возможность дебажить надо долго колдовать с phpeclipse, все не получается никак, пока что приходится гадать на кофейной гуще и десятками разных вариантов методом тыка перебирать чтоб найти что где сломалось. Борюсь с языком а не с задачей.
Никак не могу преодолеть некий барьер, чтоб написать даже относительно простые вещи.
2)Еще одна претензия к языку, которую не увидел у автора этой и «фрактальной» статьи.
В джаве, в с#, да и вообще в ООП есть такое правило хорошего тона — классов должно быть много, каждый должен иметь минимальную ответственность. В студии в частности есть метрики, которые шибко портятся если класс большой и делает много всего.
А php же наоборот наказывает это поведение необходимостью делать десятки инклюдов, либо извращаться с автолоадерами, что тоже пока никак не могу заставить работать.
Изучаю сейчас php — море геморроя, ничего не работает и непонятно почему.
Заметки на полях:
1) Чтоб получить возможность дебажить надо долго колдовать с phpeclipse, все не получается никак, пока что приходится гадать на кофейной гуще и десятками разных вариантов методом тыка перебирать чтоб найти что где сломалось. Борюсь с языком а не с задачей.
Никак не могу преодолеть некий барьер, чтоб написать даже относительно простые вещи.
2)Еще одна претензия к языку, которую не увидел у автора этой и «фрактальной» статьи.
В джаве, в с#, да и вообще в ООП есть такое правило хорошего тона — классов должно быть много, каждый должен иметь минимальную ответственность. В студии в частности есть метрики, которые шибко портятся если класс большой и делает много всего.
А php же наоборот наказывает это поведение необходимостью делать десятки инклюдов, либо извращаться с автолоадерами, что тоже пока никак не могу заставить работать.
1. Пришло время использовать NetBeans и XDebug.
2. Пришло время использовать SPL.
2. Пришло время использовать SPL.
> возможность дебажить надо долго колдовать
Возможность дебажить в PHP есть с рождения — это print_r и error_log. Все остальное — пятое колесо.
> правило хорошего тона — классов должно быть много, каждый должен иметь минимальную ответственность.
Во-первых, autoloading классов делается элементарно (если не пытаться изобретать чего-нибудь заумного).
Во-вторых, много классов — это дурной тон. Может быть жависты любят плодить гроздь классов на каждый чих, в PHP такую практику нести не надо. Такой код плохо читается, и вообще преимущество PHP — в принципе kiss (keep it simple, stupid).
Если писать на PHP в жава-стиле, то конечно PHP проигрывает.
В результате получаются тормознутые извращения вроде Zend Framework.
Возможность дебажить в PHP есть с рождения — это print_r и error_log. Все остальное — пятое колесо.
> правило хорошего тона — классов должно быть много, каждый должен иметь минимальную ответственность.
Во-первых, autoloading классов делается элементарно (если не пытаться изобретать чего-нибудь заумного).
Во-вторых, много классов — это дурной тон. Может быть жависты любят плодить гроздь классов на каждый чих, в PHP такую практику нести не надо. Такой код плохо читается, и вообще преимущество PHP — в принципе kiss (keep it simple, stupid).
Если писать на PHP в жава-стиле, то конечно PHP проигрывает.
В результате получаются тормознутые извращения вроде Zend Framework.
принты и логи это не дебаг. это лишь его часть.
у меня уже есть на обслуживании продукт (на чистом си ) в котором нет возможности дебажить. ембеддед и все такое. а принты, точнее сислоги есть, пжалста.
по сравнению с нормальным человеческим дебагом(условные брейкпоинты, пошаговое выполнение, профайлер наконец) отлаживать такую систему — ад трудский.
у меня уже есть на обслуживании продукт (на чистом си ) в котором нет возможности дебажить. ембеддед и все такое. а принты, точнее сислоги есть, пжалста.
по сравнению с нормальным человеческим дебагом(условные брейкпоинты, пошаговое выполнение, профайлер наконец) отлаживать такую систему — ад трудский.
Я думал, что только я один такой с таким подходом легкости и нелюбовью к РНР-фреймворкам. А оказывается еще вы есть)
Eclipse — очень глючный. Сейчас использую PhpStorm, платный.
Для дебага я использую: xdebug.org/.
Дебаг в Eclipse у меня так и не получилось нормально использовать. В PhpStorm, тоже, что-то встроено, но я даже не пытался настроить.
Вы же, наверное, работали на ASP.NET MVC Framework? В PHP, тоже, есть фреймворки и без них никуда:
— Zend Framework (академически правильно написан, неплох)
— Kohana 3+ (не очень популярна, зато в Rails-стиле)
— Yii (популярный, но, на мой взгляд, слишком упрощена структура классов)
Много разных плюшек, в том числе автолоадер. Это норма.
Для дебага я использую: xdebug.org/.
Дебаг в Eclipse у меня так и не получилось нормально использовать. В PhpStorm, тоже, что-то встроено, но я даже не пытался настроить.
Вы же, наверное, работали на ASP.NET MVC Framework? В PHP, тоже, есть фреймворки и без них никуда:
— Zend Framework (академически правильно написан, неплох)
— Kohana 3+ (не очень популярна, зато в Rails-стиле)
— Yii (популярный, но, на мой взгляд, слишком упрощена структура классов)
Много разных плюшек, в том числе автолоадер. Это норма.
Про любой язык можно написать много нехорошего.
Просто у людей есть баг в мышлении. Все эти усложнения в словах и фразах-определениях, вроде «фрактал плохого дизайна» — это наследники от базовых суперклассов «Плохо» и «хорошо» (или «черное» и «белое»).
В то же время, все обладает спектральными характеристика. Как звезды :)
И нужно соизмерять спектры.
А если писать только негатив, да еще и если не знаешь, что зачем сделано и как писать «с использованием языка» (С) Макконнел — будет звучать бредово.
Возьмем для примера самые популярные языки.
1. Java
— как это, язык без прямой работы с памятью? и вообще, он не компилируется, он… эээ… интерпретируется? да нет. он компилируется под специальную виртуальную машину, которая запущена как интепретатор… в общем, черт ногу сломит. поэтому и тормоза такие
— written once, runs everywhere. хороший миф. запустите мобильное приложение под j2ee и поржем вместе
— суперсложность. никогда не искали ошибку в megaPooP полдня? — вас еще ждут эти приятные часы.
2. C++
— утечка памяти. прямая работа с памятью не важна — вот, на яве пишут же миллионы мух, которые не могут ошибаться.
— совместимость с сями. не, ребята, это серьезно? и кто-то там еще пишет, что в пхп сохранились анахронизмы
— очень легкий порог вхождения, три тома книжек спецификации.
— указатели. 1001 способ выстрелить себе в ногу, в помощь программисту, что называется
— для более-менее нормальной работы нужно знать кучу либ, over9000 способов сделать одно и то же (зато в php много функций на каждый чих — это плохо)
— все прелести компиляции, сборки больших приложений
3. питон
— вы серьезно? ооп в языке, где нет приватных методов. ну тогда и си — это объектно-ориентированных язык, за счет Code conventions я могу писать на нем в ООП стиле, хаха
— отступы. форматирование кода отступами это насилие.
4. javascript
— три варианта реализации наследования. дальше можно не продолжать.
5. руби.
смотрим презентацию
www.destroyallsoftware.com/talks/wat
6. Lisp,Hascell
— что это? покажите мне Amazon.com работающий на них
Просто у людей есть баг в мышлении. Все эти усложнения в словах и фразах-определениях, вроде «фрактал плохого дизайна» — это наследники от базовых суперклассов «Плохо» и «хорошо» (или «черное» и «белое»).
В то же время, все обладает спектральными характеристика. Как звезды :)
И нужно соизмерять спектры.
А если писать только негатив, да еще и если не знаешь, что зачем сделано и как писать «с использованием языка» (С) Макконнел — будет звучать бредово.
Возьмем для примера самые популярные языки.
1. Java
— как это, язык без прямой работы с памятью? и вообще, он не компилируется, он… эээ… интерпретируется? да нет. он компилируется под специальную виртуальную машину, которая запущена как интепретатор… в общем, черт ногу сломит. поэтому и тормоза такие
— written once, runs everywhere. хороший миф. запустите мобильное приложение под j2ee и поржем вместе
— суперсложность. никогда не искали ошибку в megaPooP полдня? — вас еще ждут эти приятные часы.
2. C++
— утечка памяти. прямая работа с памятью не важна — вот, на яве пишут же миллионы мух, которые не могут ошибаться.
— совместимость с сями. не, ребята, это серьезно? и кто-то там еще пишет, что в пхп сохранились анахронизмы
— очень легкий порог вхождения, три тома книжек спецификации.
— указатели. 1001 способ выстрелить себе в ногу, в помощь программисту, что называется
— для более-менее нормальной работы нужно знать кучу либ, over9000 способов сделать одно и то же (зато в php много функций на каждый чих — это плохо)
— все прелести компиляции, сборки больших приложений
3. питон
— вы серьезно? ооп в языке, где нет приватных методов. ну тогда и си — это объектно-ориентированных язык, за счет Code conventions я могу писать на нем в ООП стиле, хаха
— отступы. форматирование кода отступами это насилие.
4. javascript
— три варианта реализации наследования. дальше можно не продолжать.
5. руби.
смотрим презентацию
www.destroyallsoftware.com/talks/wat
6. Lisp,Hascell
— что это? покажите мне Amazon.com работающий на них
со всеми перечисленными (и во фрактальной статье) недостатками я легко мирюсь. немного сдвинул мировоззрение и глядишь — «заплатил за массаж почек новым айфоном»(с)
но вот все таки — берем asp.net — открываем студию, выбираем пункт меню — приложение а-ля хелловорлд создано. рисуем пробный класс, запускаем прям тут же, открывается браузер на локалхостный порт.
даже из рассчета что не знаем ни язык ни архитектуру — все ошибки подчеркнуты, при выполнении все рантайм ошибки проявятся — все сделано для того, чтобы все незнания языка были выявлены, чтобы поставить начинающего на ноги.
ruby on rails — тоже что то есть. только нет своей иде. но достаточно чуть ли не notepad++. чуть похуже ситуация, но тоже можно запустить локально, увидеть все ошибки.
что же делать с php начинающему? никакого «стартпака»(по крайней мере я не нашел), хостинг стоит денег, локально апач ставить хз сколько времени потрачу еще и на это. фигурные танцы с бубном чтобы хоть что то начать делать, хорошо еще вот чел пустил временно на свой хост. но вот борюсь с вещами, там где на с# даже не спотыкался, там где все должно интуитивно работать.
навевает мысли, почему хостинг на котором есть RoR или asp.net стоит дороже того где есть только php.
но вот все таки — берем asp.net — открываем студию, выбираем пункт меню — приложение а-ля хелловорлд создано. рисуем пробный класс, запускаем прям тут же, открывается браузер на локалхостный порт.
даже из рассчета что не знаем ни язык ни архитектуру — все ошибки подчеркнуты, при выполнении все рантайм ошибки проявятся — все сделано для того, чтобы все незнания языка были выявлены, чтобы поставить начинающего на ноги.
ruby on rails — тоже что то есть. только нет своей иде. но достаточно чуть ли не notepad++. чуть похуже ситуация, но тоже можно запустить локально, увидеть все ошибки.
что же делать с php начинающему? никакого «стартпака»(по крайней мере я не нашел), хостинг стоит денег, локально апач ставить хз сколько времени потрачу еще и на это. фигурные танцы с бубном чтобы хоть что то начать делать, хорошо еще вот чел пустил временно на свой хост. но вот борюсь с вещами, там где на с# даже не спотыкался, там где все должно интуитивно работать.
навевает мысли, почему хостинг на котором есть RoR или asp.net стоит дороже того где есть только php.
phpstorm))
вообще там вроде бы денвер.
а под линуксом php вообще ставится одной строкой.
знаете, честно, я не понимаю этих истерик. я писал на Паскале лет 10 назад, потом на дельфах, builder, visual basic/vba (в мсофисе очень удобно), затем под веб — 3 года на перле, пару лет на простом asp, затем PHP (много лет). по приколу делал проекты на яве, на джанге.
диплом писал на С++, робототехника обязывает — ассемблер и си там родные языки.
и вообще пофиг на чем писать, ну честно. автор поста про фрактал — просто эстет, если ему так жгут задницу нюансы языков. с таким подходом ВСЕ может бесить, даже клевый С++.
берете правильные подходы — SOLID, Kiss, Алгоритмы -и пишете на любом языке нормально. не знаете этого + матан — на любом будете писать говнокод, где god objects, неявные зависимости, ошибки переполнения буфера и другие косяки, которые можно сделать на языке.
ну честное слово. вместо холиваров лучше бы опен-сорс проект подняли.
вообще там вроде бы денвер.
а под линуксом php вообще ставится одной строкой.
знаете, честно, я не понимаю этих истерик. я писал на Паскале лет 10 назад, потом на дельфах, builder, visual basic/vba (в мсофисе очень удобно), затем под веб — 3 года на перле, пару лет на простом asp, затем PHP (много лет). по приколу делал проекты на яве, на джанге.
диплом писал на С++, робототехника обязывает — ассемблер и си там родные языки.
и вообще пофиг на чем писать, ну честно. автор поста про фрактал — просто эстет, если ему так жгут задницу нюансы языков. с таким подходом ВСЕ может бесить, даже клевый С++.
берете правильные подходы — SOLID, Kiss, Алгоритмы -и пишете на любом языке нормально. не знаете этого + матан — на любом будете писать говнокод, где god objects, неявные зависимости, ошибки переполнения буфера и другие косяки, которые можно сделать на языке.
ну честное слово. вместо холиваров лучше бы опен-сорс проект подняли.
Прикатились. Рисуем класс. Кликаем — страничка готова. Извините — тогда ПХП действительно не про Вас. Там программировать надо
На счет XSS-фильтров вы явно исказили контр-статью: там была указана библиотека из pypi, чтобы подчеркнуть преимущество системы пакетов в Python, а не конкретный фреймворк. Ведь это как раз в PHP ZF стал де-факто библиотекой(про SPL мне известно) и фреймворком одновременно. Так что непредвзятость, к сожалению, и в этой статье отсутствует.
А PHP отстояли хорошо!
А PHP отстояли хорошо!
Хорошо, дорогие мои, давайте покажите мне гибкость PHP, есть простейшая задача — отфильтровать ассоциативный массив по ключу, т.е. например чтобы ключ не начинался с '_' (array('_a' => 1, 'b' =>2, '_c' =>3', 'd' => 4), нужно получить array('b' => 2, 'd'=>4)).
Жду изящных решений, сам предоставлю вариант на Perl:
%result = map { $_ => $hash{$_} } grep !/^_/, keys %hash
Жду изящных решений, сам предоставлю вариант на Perl:
%result = map { $_ => $hash{$_} } grep !/^_/, keys %hash
кстати, задача навеяна знакомством с symfony 2.0, хехе
1. А зачем?
2. Вы действительно считаете решение на Пёрл изящным?
2. Вы действительно считаете решение на Пёрл изящным?
1. Знание этого поможет решению задачи?
2. Ну покажите мне более изящное решение на PHP и мы обсудим…
Пока что решение на Perl — достаточно краткое и с подсветкой синтаксиса (у меня кармы маловато) предельно понятное и что радует душу — выполнено в функциональном стиле, что, в принципе, не обязательно.
2. Ну покажите мне более изящное решение на PHP и мы обсудим…
Пока что решение на Perl — достаточно краткое и с подсветкой синтаксиса (у меня кармы маловато) предельно понятное и что радует душу — выполнено в функциональном стиле, что, в принципе, не обязательно.
Как-то так:
Не проверял — php сейчас даже не стоит.
Но вообще фильтр по ключам явление:
1. Редкое
2. Странное
Объясняю. Если ключ является идентифицирующим на столько, что яж необходим при фильтре, то лучше внести его внутрь объекта, чтобы не привязываться к структурам и способу хранения, а только к содержимому.
Как-то так:
Или на JS:
Или на Coffee (не пишу, потому могу ошибится)
Для тех же редких случаев, когда нужен именно фильтр по ключу можно и даже нужно воспользоваться тем методом, который я привёл в первом примере, чтобы не получилось такого brainfuck, как получился у вас.
Вывод: задача не имеет смысла.
protected function isAllowedKey ($key) {
return $key[0] != '_';
}
public function filterArray (array $array) {
$result = array();
foreach ($array as $key => $value) {
if ($this->isAllowedKey($key)) {
$result[$key] = $array[$key];
}
}
return $result;
}
Не проверял — php сейчас даже не стоит.
Но вообще фильтр по ключам явление:
1. Редкое
2. Странное
Объясняю. Если ключ является идентифицирующим на столько, что яж необходим при фильтре, то лучше внести его внутрь объекта, чтобы не привязываться к структурам и способу хранения, а только к содержимому.
Как-то так:
return array_filter( $array, function ($item) {
return !$item->is_hidden;
});
Или на JS:
return array.filter(function (item) {
return !item.isHidden;
});
Или на Coffee (не пишу, потому могу ошибится)
array.filter (item) -> !item.isHidden
Для тех же редких случаев, когда нужен именно фильтр по ключу можно и даже нужно воспользоваться тем методом, который я привёл в первом примере, чтобы не получилось такого brainfuck, как получился у вас.
Вывод: задача не имеет смысла.
В symfony атрибуты для конструирования маршрутов приватные от неприватных отличаются как раз первым символом _ в ключе, собственно у меня сейчас сайт со сложной маршрутизацией, понадобилось вот отфильтровать. Да и работая с чужими идеями и кодом, можно очень много невероятных задач встретить.
у меня получилось:
private static function filterPrivateKeys($attrs) {
return array_intersect_key(
$attrs,
array_flip(
array_filter(
array_keys($attrs),
function ($item) {
return substr($item, 0 ,1) !== '_';
}
)
)
);
}
подсветка не работает… но смысл несложный. Да и вполне декларативно. Меня совсем удручает что на любой элементарный чих надо писать портянки кода, в таком случае PHP можно совсем не использовать а писать на java, ибо там те же самые принципы и портянки, только работает быстрее.
На Perl получился совсем не brainfuck и в реальном коде это конечно же тоже будет вынесено в метод или функцию с комментарием. И с подсветкой всё отлично понятно (и не надо мне говорить что с PHP можно из notepad работать). Просто синтаксис Perl позволяет писать компактно и со смыслом.
у меня получилось:
private static function filterPrivateKeys($attrs) {
return array_intersect_key(
$attrs,
array_flip(
array_filter(
array_keys($attrs),
function ($item) {
return substr($item, 0 ,1) !== '_';
}
)
)
);
}
подсветка не работает… но смысл несложный. Да и вполне декларативно. Меня совсем удручает что на любой элементарный чих надо писать портянки кода, в таком случае PHP можно совсем не использовать а писать на java, ибо там те же самые принципы и портянки, только работает быстрее.
На Perl получился совсем не brainfuck и в реальном коде это конечно же тоже будет вынесено в метод или функцию с комментарием. И с подсветкой всё отлично понятно (и не надо мне говорить что с PHP можно из notepad работать). Просто синтаксис Perl позволяет писать компактно и со смыслом.
Если функция фильтра по ключу используется часто — почему бы её не добавить?
Всё — везде красивый, понятный и поддерживаемый код.
Если используется только в одном месте, то зачем она нужна в php-core, если даже у вас она используется только в одном месте?
И да, я бы не назвал этот код нормальным:
function array_filter_keys ($array, $callback) {
$result = array();
foreach ($array as $key => $value) {
if ($callback($key, $value) !== false) $result[$key] = $value;
}
return $result;
}
// result:
return array_filter_keys( $source, function ($item) {
return $item[0] !== '_';
});
Всё — везде красивый, понятный и поддерживаемый код.
Если используется только в одном месте, то зачем она нужна в php-core, если даже у вас она используется только в одном месте?
И да, я бы не назвал этот код нормальным:
private static function filterPrivateKeys($attrs) {
return array_intersect_key(
$attrs,
array_flip(
array_filter(
array_keys($attrs),
function ($item) {
return substr($item, 0 ,1) !== '_';
}
)
)
);
}
Да у вас понятнее PHP вариант, согласен, но опять же оверинжинирингом попахивает, для каждой чепуховины по паре функций/методов создавать, для чего?
Опять же у PHP есть куча функций, которые как мы выяснили не нужно использовать, ибо решения с ними получаются сложные (потому что они дублируют функционал друг друга, либо не дают сделать то что хочется), вот это и есть фиаско как языка.
Опять же у PHP есть куча функций, которые как мы выяснили не нужно использовать, ибо решения с ними получаются сложные (потому что они дублируют функционал друг друга, либо не дают сделать то что хочется), вот это и есть фиаско как языка.
Вам интересно проблемы самому себе на пустом месте выдумывать?
$res = array();
foreach ($arr as $key => $val)
if ('_' != $key[0])
$res[$key] = $val;
На написание этих строчек уйдет меньше времени, чем на ваш brainfuck, и читается на порядок проще.
$res = array();
foreach ($arr as $key => $val)
if ('_' != $key[0])
$res[$key] = $val;
На написание этих строчек уйдет меньше времени, чем на ваш brainfuck, и читается на порядок проще.
Фигурными скобками блоки всегда нужно выделять, ибо такой синтаксис — это основной источник багов при рефакторинге, потому +2 строчки к решению.
Решение на Perl я написал с 1го раза без дополнительного обдумывания, кто разбирается в Perl поймёт почему, там 2 функции стандартных и регулярка элементарная, не над чем думать вообще. Так что посчитав символы, скорость однозначно на моей стороне.
В общем, я наконец-то осознал почему в функциональном программировании некоторый застой — некоторые люди действительно верят что тонны кода это хорошо и понятно, что создавать вручную дополнительный массив для того чтобы получить часть данных текущего — это тоже очень хорошо. Императивность головного мозга… я сдаюсь, действительно адепты PHP заслужили его синтаксиса и всей этой кривизны его внутреннего устройства. Наслаждайтесь этим пожалуйста.
Решение на Perl я написал с 1го раза без дополнительного обдумывания, кто разбирается в Perl поймёт почему, там 2 функции стандартных и регулярка элементарная, не над чем думать вообще. Так что посчитав символы, скорость однозначно на моей стороне.
В общем, я наконец-то осознал почему в функциональном программировании некоторый застой — некоторые люди действительно верят что тонны кода это хорошо и понятно, что создавать вручную дополнительный массив для того чтобы получить часть данных текущего — это тоже очень хорошо. Императивность головного мозга… я сдаюсь, действительно адепты PHP заслужили его синтаксиса и всей этой кривизны его внутреннего устройства. Наслаждайтесь этим пожалуйста.
Вам написали код, который поймет 100% программистов за 10 секунд, и в этом его преимущество. Если вы не видите этого преимущества — это значит что-то у вас с головным мозгом, а не у меня.
Куда и чего выделять — идите лучше школьников учить в местную школу.
Мне нравятся хабра-эксперты тем, что они будут переходить на личности и указывать всем кому попало не зная с кем разговаривают.
В функциональном программировании застой потому что оно требует больше времени на освоение и мало кому нужно.
Люди дают другой ответ на вопрос «шашечки или ехать».
Куда и чего выделять — идите лучше школьников учить в местную школу.
Мне нравятся хабра-эксперты тем, что они будут переходить на личности и указывать всем кому попало не зная с кем разговаривают.
В функциональном программировании застой потому что оно требует больше времени на освоение и мало кому нужно.
Люди дают другой ответ на вопрос «шашечки или ехать».
Попросите человека не встречавшегося с PHP (или слабо знакомого) рассказать что делает ваш код, он не сможет этого сделать потому что там совсем не всё однозначно. То есть про 100% — это жуткая гипербола.
Почему вы всё ещё говорите на русском языке, если китайцев больше и если вы начнёте говорить на китайском, то большее количество людей вас поймёт… аа-ааа-а, вы же живёте не в Китае… Потому код не обязаны понимать 100% каких-то абстрактных программистов, в нём должны максимально быстро разобраться люди которые на этом ЯП программируют.
Про выделение блоков фигурными скобками всегда, это типичная рекомендация почти в любом фреймворке и появилась она не на пустом месте, рефакторить код где эта рекоммендация не используется дольше на порядок.
Языки программирования уже давно предлагают варианты там где и «шашечки» и «ехать» одновременно, но многие почему-то по старинке любят выбирать.
Почему вы всё ещё говорите на русском языке, если китайцев больше и если вы начнёте говорить на китайском, то большее количество людей вас поймёт… аа-ааа-а, вы же живёте не в Китае… Потому код не обязаны понимать 100% каких-то абстрактных программистов, в нём должны максимально быстро разобраться люди которые на этом ЯП программируют.
Про выделение блоков фигурными скобками всегда, это типичная рекомендация почти в любом фреймворке и появилась она не на пустом месте, рефакторить код где эта рекоммендация не используется дольше на порядок.
Языки программирования уже давно предлагают варианты там где и «шашечки» и «ехать» одновременно, но многие почему-то по старинке любят выбирать.
В общем, я наконец-то осознал почему в функциональном программировании некоторый застой — некоторые люди действительно верят что тонны кода это хорошо и понятно, что создавать вручную дополнительный массив для того чтобы получить часть данных текущего — это тоже очень хорошо. Императивность головного мозга…
А я вот не понимаю декларативность головного мозга. Особенно при разработке на PHP. Трижды подумаю прежде чем использовать array_map, array_reduce или array_filter даже там где они уместны, а особенно при работе с ключами. Хотя бы потому что foreach на порядок быстрее, а код читаемей, а с ключами поведение неочевидно. Сравните
и
Тело функции из доков к array_reduce(), возможно избыточно и достаточно
Плюс foreach сам по себе не вполне императивен, а имеет декларативную природу тоже, в частности порядок обхода объекта не определен. И зачем мне запоминать особенности трёх (вернее больше) функций array_*, если есть универсальный foreach и работает он быстрее в большинстве типичных случаев, а код понятнее и без введения новых сущностей.
А я вот не понимаю декларативность головного мозга. Особенно при разработке на PHP. Трижды подумаю прежде чем использовать array_map, array_reduce или array_filter даже там где они уместны, а особенно при работе с ключами. Хотя бы потому что foreach на порядок быстрее, а код читаемей, а с ключами поведение неочевидно. Сравните
$sum = 0;
foreach($array as $value) {
$sum += $value;
}
и
$sum = array_reduce($array, function($sum, $value) {
$sum += $value;
return $sum;
}, 0)
Тело функции из доков к array_reduce(), возможно избыточно и достаточно
return $sum + $value; — опять же неочевидность, достаточно ли там чистой функции, а может возвращаемое значение не нужно, а по документации не понятно. Плюс foreach сам по себе не вполне императивен, а имеет декларативную природу тоже, в частности порядок обхода объекта не определен. И зачем мне запоминать особенности трёх (вернее больше) функций array_*, если есть универсальный foreach и работает он быстрее в большинстве типичных случаев, а код понятнее и без введения новых сущностей.
Ну вот это и является проблемой PHP, как ни странно, и источником бессмысленных велосипедов. И это создаёт проблемы людям которые приходят из других ЯП. Ибо в них дополнительные модули и возможности языка — большое благо. Лично мне очень сложно после Erlang, Perl и JS писать бэйсикоподобные простыни кода.
Там, кстати, map/reduce выразительнее чем итеративный подход.
P.S. для вашего примера лучше и понятнее будет:
$sum = array_sum($array);
=)))
P.P.S. собственно из этой проблемы вытекает ещё один грустный для мира PHP факт — люди не хотят изучать все эти тонны встроенных функций, а убрать их не так просто, ибо поломается очень много готового кода. Да и новичкам эти встроенные функции мешают изучать язык, ибо — изучаешь изучаешь, а куда не ткнись — «их не используйте, лучше попробуйте мой чудо-велосипед».
Там, кстати, map/reduce выразительнее чем итеративный подход.
P.S. для вашего примера лучше и понятнее будет:
$sum = array_sum($array);
=)))
P.P.S. собственно из этой проблемы вытекает ещё один грустный для мира PHP факт — люди не хотят изучать все эти тонны встроенных функций, а убрать их не так просто, ибо поломается очень много готового кода. Да и новичкам эти встроенные функции мешают изучать язык, ибо — изучаешь изучаешь, а куда не ткнись — «их не используйте, лучше попробуйте мой чудо-велосипед».
Что в Erlang они выразительней меня не удивляет. Но в PHP что есть, то есть. Меня не напрягает особо, функции типа map/reduce/filter использую там, где возможна вариативность колбэка по алгоритму, а так проще и быстрее написать свой «велосипед». И понятнее он будет большинству программистов. А для фанатов ФП он позволяет писать в декларативном (почти) стиле — образец выше есть :)
А насчёт встроенных функций — да, есть такое. Но причина несколько другая, по-моему — большое количество функций с почти дублирующейся функциональностью, а разбираться в нюансах дольше чем написать свой велосипед.
А насчёт встроенных функций — да, есть такое. Но причина несколько другая, по-моему — большое количество функций с почти дублирующейся функциональностью, а разбираться в нюансах дольше чем написать свой велосипед.
Я не адепт пхп, но где-то так:
В 5.4 это можно было б сделать анонимной функцией, но он пока не очень распространен.
function filter_array($item, $key, &$arr){ if($key[0]==='_') unset($arr[$key]);}
array_walk(&$a,'filter_array', &$a);
В 5.4 это можно было б сделать анонимной функцией, но он пока не очень распространен.
И вот так будет на руби:
data.select { |k,v| !k.starts_with? '_' }
> Вывод: задача не имеет смысла.
Вы просто офигеть как не правы. Различные преобразования над коллециями данных — одна из краеугольных задач программирования, встречающая абсолютно везде, и особенно интенсивно в вебе.
Подходов к работе с коллекциями принято два:
1. Императивный. То как обычно делается в си-подобных языках — циклами. Получается многострочно, со внешними переменными для хранения результата/состояний и не очень легкочитабельно, особенно в ситуациях со сложными многоэтапными преобразованиями. Рефакторить такой код часто достаточно сложно.
2. Функциональный. Когда ты, грубо говоря, говоришь: «Эй, коллекция, сделай-ка мне такую-то операцию над собой и верни после этого результат, и вот на тебе лямбду, которая для каждого твоего элемента вернёт значение для операции». Наиболее часто используемые действия в таком подходе — map, inject и select.
Во втором подходе так же очень естественно получаются цепочки вызовов (method chaining — то, как делается к примеру в jQuery).
При поддержке языка и стандартной библиотекой второй подход так же позволяет применять ленивые вычисления(lazy evaluation). Иногда это критично.
Код выходит намного более компактным, понятным и чистым. Хотя порой и более медленным по сравнению с императивным подходом(что почти никогда не будет веским доводом — «premature optimization is the root of all evil» © Knuth, Donald)
И этот подход становится(или даже уже стал) мейнстримом. В ruby всё только так и делается, в javascript — библиотеки jQuery и underscore, в c# — linq, в java планируют добавить лямбды, в C++ 0x11 они уже появились, в пхп 5.4 тоже.
Принятие функционального подхода при работе с данными будет огромным левелапом к вашим программистским скилам, вопрос только в поддержке этого хозяйства в используемом вами языке программирования — в наличии синтаксиса лямбд с замыканиями и хорошой стандартной библиотекой.
data.select { |k,v| !k.starts_with? '_' }
> Вывод: задача не имеет смысла.
Вы просто офигеть как не правы. Различные преобразования над коллециями данных — одна из краеугольных задач программирования, встречающая абсолютно везде, и особенно интенсивно в вебе.
Подходов к работе с коллекциями принято два:
1. Императивный. То как обычно делается в си-подобных языках — циклами. Получается многострочно, со внешними переменными для хранения результата/состояний и не очень легкочитабельно, особенно в ситуациях со сложными многоэтапными преобразованиями. Рефакторить такой код часто достаточно сложно.
2. Функциональный. Когда ты, грубо говоря, говоришь: «Эй, коллекция, сделай-ка мне такую-то операцию над собой и верни после этого результат, и вот на тебе лямбду, которая для каждого твоего элемента вернёт значение для операции». Наиболее часто используемые действия в таком подходе — map, inject и select.
Во втором подходе так же очень естественно получаются цепочки вызовов (method chaining — то, как делается к примеру в jQuery).
При поддержке языка и стандартной библиотекой второй подход так же позволяет применять ленивые вычисления(lazy evaluation). Иногда это критично.
Код выходит намного более компактным, понятным и чистым. Хотя порой и более медленным по сравнению с императивным подходом(что почти никогда не будет веским доводом — «premature optimization is the root of all evil» © Knuth, Donald)
И этот подход становится(или даже уже стал) мейнстримом. В ruby всё только так и делается, в javascript — библиотеки jQuery и underscore, в c# — linq, в java планируют добавить лямбды, в C++ 0x11 они уже появились, в пхп 5.4 тоже.
Принятие функционального подхода при работе с данными будет огромным левелапом к вашим программистским скилам, вопрос только в поддержке этого хозяйства в используемом вами языке программирования — в наличии синтаксиса лямбд с замыканиями и хорошой стандартной библиотекой.
На досуге как-нибудь загляните в php.net/manual/en/ref.array.php
В php это все есть.
Наш герой просто выбрал задачу (фильтрация по ключу), которая практически не встречается, поэтому ее поддержку не добавили в php. Преподносит это как огромный недостаток и клянет всех php-шников, хотя фиксится все в несколько строчек.
На server-side работа с коллекциями все равно делается на уровне БД, очень часто кстати функциональным языком — SQL, поэтому чего тут открывать Америку с этим функциональным подходом — непонятно.
В php это все есть.
Наш герой просто выбрал задачу (фильтрация по ключу), которая практически не встречается, поэтому ее поддержку не добавили в php. Преподносит это как огромный недостаток и клянет всех php-шников, хотя фиксится все в несколько строчек.
На server-side работа с коллекциями все равно делается на уровне БД, очень часто кстати функциональным языком — SQL, поэтому чего тут открывать Америку с этим функциональным подходом — непонятно.
ага, знаю. 4 года пользовался. выше в комментариях показано, насколько это удобно.
глупый программист сам дурак, задумал сотворить какую-то ересь, не предусмотренную ни одной из пятидесяти функций стандартной библиотеки по работе с массивами. «фиксится»… ну да, пофиксим это и всё станет хорошо. в топике fractal of bad design как раз об этом и пишется, о костыле на костыле, каждый из которых ещё и сделан по-разному.
и ещё хорошо вам живётся, если всегда достаточно лишь выбрать данные из базы.
глупый программист сам дурак, задумал сотворить какую-то ересь, не предусмотренную ни одной из пятидесяти функций стандартной библиотеки по работе с массивами. «фиксится»… ну да, пофиксим это и всё станет хорошо. в топике fractal of bad design как раз об этом и пишется, о костыле на костыле, каждый из которых ещё и сделан по-разному.
и ещё хорошо вам живётся, если всегда достаточно лишь выбрать данные из базы.
Неудобно это только для тех, кто без синтаксического сахара жить не может.
Для кого вызвать $a = func1($a); $a = func2($a); вместо a.func1().func2() смерти подобно.
Таким могу только посочуствовать.
Прекрасно работается в php с коллекциями и с процедурным, и с функциональным подходом (для любителей).
Для тех, у кого совсем функционал головного мозга случился, давно придумали извращения вроде
$collection->select(..)->from(..)->where() и прочие selectByCol1andCol2()
Для кого вызвать $a = func1($a); $a = func2($a); вместо a.func1().func2() смерти подобно.
Таким могу только посочуствовать.
Прекрасно работается в php с коллекциями и с процедурным, и с функциональным подходом (для любителей).
Для тех, у кого совсем функционал головного мозга случился, давно придумали извращения вроде
$collection->select(..)->from(..)->where() и прочие selectByCol1andCol2()
ради интереса — решение на с#
Dictionary<string, string> dict = new Dictionary<string, string>();
/*
fill
*/
dict = dict.Where(a => a.Key[0] != '_').ToDictionary(a => a.Key, a=> a.Value);
На пхп можно тоже написать в одну строчку, только читаемость от этого будет такой же как и в perl.
На любителя это всё:
Кстати, по мне так на php выглядит это понятней.
На любителя это всё:
$result= array();
foreach($hash as $k => $v) if($k[0] == '_') $result[$k] = $v;
Кстати, по мне так на php выглядит это понятней.
Perl отлично читается, просто у него несколько непривычно выглядит код, но те блага что даёт этот несколько непривычный синтаксис, перевешивают всё что можно. Самая гениальная идея Perl — это переменная $_, в любых программах есть много данных которые обрабатываются итеративно и для этого в них создаются дополнительные переменные и надо либо постоянно их выдумывать, либо использовать короткие ничего не значащие $i, $c. Так вот даже ваш пример написанный в подобном стиле в Perl будет выглядеть вот так:
my %result;
for (keys %hash) {
$result{$_} = $hash{$_} if /^_/;
}
Есть отличный модуль для создания генераторов, List::Gen в котором можно итерировать разнообразные структуры данных, даже бесконечные наборы данных, тем же самым for. Верх лаконичности на мой взгляд. Минимум лишнего синтаксиса — максимум отдачи. Чтобы тоже самое сделать в PHP надо использовать кучу классов самописных (может быть даже и стандартные из SPL использовать, надо посмтотреть будет) и кода будет в разы больше и логика программы станет сильно сложнее, а зачем?
P.S. блин… катастрофически подсветка синтаксиса не работает… подмочил я карму этими рассуждениями «о прекрасном» =))) хехехе
my %result;
for (keys %hash) {
$result{$_} = $hash{$_} if /^_/;
}
Есть отличный модуль для создания генераторов, List::Gen в котором можно итерировать разнообразные структуры данных, даже бесконечные наборы данных, тем же самым for. Верх лаконичности на мой взгляд. Минимум лишнего синтаксиса — максимум отдачи. Чтобы тоже самое сделать в PHP надо использовать кучу классов самописных (может быть даже и стандартные из SPL использовать, надо посмтотреть будет) и кода будет в разы больше и логика программы станет сильно сложнее, а зачем?
P.S. блин… катастрофически подсветка синтаксиса не работает… подмочил я карму этими рассуждениями «о прекрасном» =))) хехехе
my %result;
for (keys %hash) {
$result{$_} = $hash{$_} if /^_/;
}
Пока есть возможность выложить в цвете воспользуюсь, спасибо тебе, о неизвестный %username%!
P.S. я забыл написать что делает $_:
эта переменная подставляется автоматически вместо текущего итерируемого элемента и при её изменении изменяется оригинальный элемент, т.е. по сути это аналог в PHP:
foreach($array as &$_) {
}
но используется не только в for в Perl, но в других функциях и конструкциях языка. А в регулярных выражениях её можно пропускать, то есть
... if /^_/;
обозначает — «если $_ подходит под регулярное выражение ^_», т.е. если первый символ — знак подчёркивания.
Спасибо, интересно :)
Теперь стало понятно что написано в вашем первом примере.
Действительно лаконично
А во вложенном цикле $_ куда будет ссылаться?
В php в целом всё не так уж и плохо, как выглядит со стороны — в spl есть рекурсивные итераторы :)
Я уже лет 10 пишу на пхп — разобрался во многих фреймворках и для задач использую свой набор классов. Минимально-необходимый набор. У меня довольно специфичные задачи (корпоративный софт). Тут в привычном понимании нет вьюх, контроллеров. Это всё на javascript (extjs4). А сервер представляет только direct.api.
Так вот — понимаю, что про пхп тяжело сказать что что-то сделано изящно и поглядываю в сторону других языков. Поверхностно разобрался с python и ruby. Но останавливает наличие большого опыта.
Не получается на других языках также быстро и эффективно решать задачи.
Теперь стало понятно что написано в вашем первом примере.
%result = map { $_ => $hash{$_} } grep !/^_/, keys %hash
Действительно лаконично
А во вложенном цикле $_ куда будет ссылаться?
В php в целом всё не так уж и плохо, как выглядит со стороны — в spl есть рекурсивные итераторы :)
Я уже лет 10 пишу на пхп — разобрался во многих фреймворках и для задач использую свой набор классов. Минимально-необходимый набор. У меня довольно специфичные задачи (корпоративный софт). Тут в привычном понимании нет вьюх, контроллеров. Это всё на javascript (extjs4). А сервер представляет только direct.api.
Так вот — понимаю, что про пхп тяжело сказать что что-то сделано изящно и поглядываю в сторону других языков. Поверхностно разобрался с python и ruby. Но останавливает наличие большого опыта.
Не получается на других языках также быстро и эффективно решать задачи.
А во вложенном цикле $_ куда будет ссылаться?
Она локализуется (в текущих стабильных ветках точно, раньше (мне кажется только в совсем старом 5.8) была глобальной и были проблемы), т.е. перед вложенным циклом надо будет переменную всё таки переназначать, если нужно внутри вложенного цикла использовать.
А уж какое в Perl OOP с помощью Moose, это фантастика, ничего такого гибкого и лаконичного я в других ЯП вообще не видел, если есть — кидайте ссылки, я погляжу, я люблю новое и интересное.
PHP — отстой! Но я люблю его!