Помнится, в некоторых фильмах про хакеров или военных изображение с дисплея проектировалось аж на лицо и руки. Там выглядело высокохудожественно и смешно, но на этом видео выглядит просто стремно, когда мощный проектор светит прямо в лоб — так и ослепнуть недолго…
Может, как-то в пол светить, или в потолок?
Да, речь про регулярки, конечно. Лично мне не нравится php-шная имплементация. Если Вы знакомы с перловой реализацией, то должны понимать, что я имею ввиду. На всякий случай все же уточню — в перле регулярки сделаны гораздо елегантнее, чем в php, и пользоваться ими в перле — одно сплошное удовольствие.
Что касается site-perf — Вы должны помнить, что firebug 2008-го года и сегодняшний — это две большие разницы. В то время даже waterfall диаграммы загрузки не было. Сайт был создан исключительно по причине кривости существовавших на тот момент альтернатив, типа pingdom, результаты которых часто давали ложную картину (pingdom все грузил в один поток, как можно было адекватно оценить производительность загрузки страницы ?).
И многих, кстати, как раз и интересует, как оценивается производительность НЕ ТОЛЬКО со стороны «их любимых», firebug тут мало чем может помочь.
Ну и попытаюсь ответить на последний Ваш вопрос. Лично я совершенно ничего не имею против mod_php (всяко лучше, чем php-cgi). Данный режим часто предпочтительнее даже хваленого php-fpm, т.к. есть полный доступ к окружению апача (т.е. к GeoIP и прочим переменным), а также .htaccess и прочие вкусности. Хотя при очень больших нагрузках php-fpm все же предпочтительнее, апачу сложнее принять и обработать тысячи запросов в секунду к php, из-за оверхеда на блокировки.
Так вот, то, что Вы восприняли как стеб, это попытка показать другим людям, что есть множетсво и других инструментов, альтернативных PHP, которые, пусть и выглядят более страшными для изучения, но и возможности предлагают соответствующие. Затраты на борьбу с глюками неизбежны: и для Postgresql у меня есть пару неласковых слов, и в форум nginx отписано несколько злых багов… Но для PHP эти затраты просто неимоверны, по сравнению с другими языками.
Немного напоминает противостояние пользователей vim и notepad, не находите?
О, спасибо за репорт, давно не пользовался им уже просто, делал когда-то для себя.
Пофиксил, кто бы мог подумать, оказывается во фре есть ограничение в кол-во хардлинков на один файл, 32к всего…
php таки да, действительно в апаче присутствует, даже не знаю, что теперь делать… Идеология вроде требует срочно снести, но здравый смысл и отсутствие фанатизма крутят пальцем у виска, пожалуй, соглашусь с последними и оставлю, каши пока не просит.
Спасибо за напутствие, пригодится, сотни Гбит/c действительно не шутки (я не про wap-go и не про site-perf ;) ).
И Вам взаимно желаю всяческих благ.
P.S. а php я, кстати, использую, очень добротный cli-шаблонизатор, знаете ли. Поддерживает циклы и прочие вкусности, рекомендую. А wap-go и site-perf работают оба на перле, хотя кому какая разница ;)
Чтобы начать писать программы на перле, мне было достаточно 2-х часового чтения доки по нему (на русском, правда, иначе понадобилось бы немного больше времени).
В то время набирал популярность php 3.x, я как-то взялся изучать и его, но забросил, поняв, что это недоделанная калька с перла, заточенная на выполнение внутри апача, которая ничего принципиально нового предложить мне не может, и в то же время заберет кучу времени и сил на борьбу с php-шными непоследовательными особенности (каша в наименовании функций и анекдоты про разницу '==' и '===' существовали уже тогда). А мрачный и у"№щный RE в php и вспоминать страшно…
Хотя против ветра по маленькому и не ходят (как свидетельствуют только что полученные минусы), но повторюсь — у php-шников карма такая — регулярно набивать шишки на обильно разбросанные повсюду грабли.
Ниша ror недалеко отстоит от php. Никто в здравом уме трейд-ботов или анализаторов для данных с коллайдера на этих языках писать не будет )
И ruby язык сравнительно молодой, ему простительно, добавят как нибудь.
Вот в golang сразу же в интерфейс DB заложили Prepare() — системный язык все-таки.
Про старичка perl уже и не упоминаю, там prepare испокон веков работает как положено.
Вспоминается пословица про ежиков и кактус… ))
Не, ничего личного, но ей богу, забавно наблюдать, сколько велосипедов изобретено и сколько костылей настрогано вследствии принятия одного-единственного решения: «С чего бы начать изучать программирование? Наверное с PHP, не зря ж он такой популярный...»
Как бы там ни было, за статью автору респект. Prepared statements рулят. Ускорения sql там, в среднем, кот наплакал, но безопастность и надежность повышает сильно, поэтому их стоит использовать даже для единичных запросов.
Гораздо-гораздо больше, воздуху то под днище придется пробираться через узкую щель, в то время как для правого стакана никаких преград нет. В то время как вода выкипает без преград. В целом, чем шире стакан — тем меньше он успеет подпрыгнуть.
И ещё аргумент проти выбивания дна — к моменту, пока вода и дно встретятся, образуется довольно много пара. Поэтому непосредственно резкой встречи как таковой не будет — будет происходить сжатие этого пара с постепенным нарастанием давления, которое будет замедлять встречное движение дна и воды.
Вакуум вообще-то никуда ничего не давит, по определению )
Атмосферное давление под днищем стакана присутствует (иначе тяжело было бы оторвать стакан от стола).Но как только стакан приподымется над столом на расстояние, сравнимое со средним расстоянием между стаканом и столом, пока он стоит (т.е. на доли милиметра), как это давление пропорционально уменьшится — воздуху надо время чтобы пробрать под дно стакана и опять поднять давление до атмосферного. Это время будет сравнимо с временем выкипания воды в нижней части и заполнения пустоты паром (хотя и быстрее), так что стакан вверх навряд ли подымется слишком быстро и высоко, чтобы выбило дно.
Верно, прошу прощения, на выходе получается больше бит чем на входе, иначе Ваш подход не работал бы: для любого m при заданном key можно найти значение msg длиной порядка 40 бит, что результат хеширования с обрезанием на 40 бит будет равен заданному X.
Хотя нет, 100% гарантии того что это блочный шифр нет, т.к. для md5 есть только гарантия того, что для разных 40-битных строк будет отличаться полный хеш, а для первых 40 бит хеша такой гарантии нет.
Так что для некоторых ключей возможно встретится коллизия.
Что ж, не могу не согласиться, что PHP5.4 действительно сильно отличается от PHP3.
Делает ли это его таким же заслуживающим внимания как PHP3 — сомнительно.
Изначальная фишка php в том что он был действительно прост до опупения, и это позволило ему завоевать популярность. Но обвешивание языка шаблонизации (это отдельный разговор), поддержкой всего и вся, увы, не делает его самым крутым языком ;(
У php своя ниша, он идеально хорош для добавления несложной динамики в статический html, тут не поспоришь.
Но современные реалии таковы, что сайты уже не состоят из набора html-ек, это сложные движки, которые должны работать эффективно и надежно, а также удобно сопровождаться. У php проблемы и с первым, и с другим, и с третьим.
По пунктам:
Производительности perl-а php достиг с третьей версии, и фактически остановился (как и перл, но это другой разговор). Интерпретируемый язык не догонит C никогда, как кукурузник не догонит боинг, сколько реактивных двигателей на него не вешай. pecl-APC (или другие opcode кешеры) ещё помогает не сдохнуть php проектам под нагрузкой, hiphop сильно капризный и специфичный…
Надежность php обсуждать даже не смешно. Каждый релиз сопровождается тоннами исправленных багов, читаешь relnotes и радуешься «хорошо что меня это не касается и касаться не будет». Несовместимость самых версий, проблемы компиляции модулей на новых версиях… Не будем о плохом.
Ну и вернемся к самому языку как таковому. Честно признаюсь, не рассматривал подробно новшества php 5.4, не в курсе насколько елегантно они введены. Но учитывая, какой бардак происходит в именовании функций, в передаче параметров эти функциям, как реализованы RE и прочее… Что-то сомнительно что с версией 5.4 php заблистал утонченностью и элегантностью
В общем, IMHO и ещё раз IMHO, PHP — это как максимум начальный этап карьеры программиста, и чем быстрее его проскочить, тем лучше. Есть куча других языков и технологий, заслуживающих внимания.
PHP используется как основной язык на 77,9% среди всех сайтов
windows используется на ещё большем проценте комп«ютеров, так что теперь, на basic-е программировать?
PHP все еще является наипростейшим языком для изучения не-техническими людьми
Спорный момент, хотя в части именно веб-программирования пожалуй соглашусь. Результат — мы имеем кучу технически не сильно образованных людей, которые считают себя веб-программистами, и клепают „сайты“.
Экосистема — ну, каждый кулик свое болото хвалит, я вот слыхал что на C можно написать вообще все-все, что можно написать на другом языке, куча либ на все случаи жизни, IDE такие что сами код могут писать… Мечта, а не язык.
Ну и главное замечание к статье — чем же так PHP гораздо лучше, чем мы думаем, автор так и не обьяснил…
Интересно было бы посмотреть на список наиболее влиятельных женщин-программисток (а не менеджеров и соотновательниц). Первая позиция — Йоанна Рутковская, есть ещё профи подобного уровня?
Не могу с Вами согласиться, разница в звуке таки есть. Для заметных искажений достаточно изменить аудио-сигнал на считанные проценты. Человеческое ухо весьма чуствительный инструмент. Учитывая наводки (не столько внешние, сколько внутренние), отражения и затухание сигнала, особенно на высоких частотах…
Собственно, поскольку для межблочников применять что-то кроме цифры особого смысла нет (исходный сигнал то все равно цифровой), а про бесполезность золотых кабелей питания я уже упоминал — интерес вызывает как раз выходной кабель.
В частности — поскольку жирность обеспечивается многожильностью — какое влияние на индуктивность/емкость оказывает тип переплетения жил? Есть ли смысл плести косички, или разнонаправленные свивки для разных пар жил, другие варианты..? Насколько оправданно применение медной фольги, высококачественной меди, проводов раздельного типа для bi-amp подключения, как совмещать эти разные провода для bi-amp в одной оболочке…?
Ну, вот в статье выше были разобраны особенности прохождения сигнала, источники искажения и методы борьбы с ними. Просто сигнал рассматривался цифровой, а с аудио-сигналом все немного по другому происходит (другие частоты и токи, да и оборудование) и требования тоже немного отличаются… Собственно, интересует как заиметь качественный аудио-кабель в разумную цену.
Увы, но даже недешевые кабеля известных фирм вовсе не обеспечивают гарантию отсутствия слышимого искажения аудио-сигнала, очень много продукции среднего пошиба, что продвигается исключительно маркетингом с расчетом «авось найдется лох который купится на рекламные обещания, все равно осцилографом мерять не будет». Вспомнить хотя бы позолоченные безкислородные бла-бла кабели питания для подсоединения к алюминиевой электропроводке ;)
Может, как-то в пол светить, или в потолок?
Что касается site-perf — Вы должны помнить, что firebug 2008-го года и сегодняшний — это две большие разницы. В то время даже waterfall диаграммы загрузки не было. Сайт был создан исключительно по причине кривости существовавших на тот момент альтернатив, типа pingdom, результаты которых часто давали ложную картину (pingdom все грузил в один поток, как можно было адекватно оценить производительность загрузки страницы ?).
И многих, кстати, как раз и интересует, как оценивается производительность НЕ ТОЛЬКО со стороны «их любимых», firebug тут мало чем может помочь.
Ну и попытаюсь ответить на последний Ваш вопрос. Лично я совершенно ничего не имею против mod_php (всяко лучше, чем php-cgi). Данный режим часто предпочтительнее даже хваленого php-fpm, т.к. есть полный доступ к окружению апача (т.е. к GeoIP и прочим переменным), а также .htaccess и прочие вкусности. Хотя при очень больших нагрузках php-fpm все же предпочтительнее, апачу сложнее принять и обработать тысячи запросов в секунду к php, из-за оверхеда на блокировки.
Так вот, то, что Вы восприняли как стеб, это попытка показать другим людям, что есть множетсво и других инструментов, альтернативных PHP, которые, пусть и выглядят более страшными для изучения, но и возможности предлагают соответствующие. Затраты на борьбу с глюками неизбежны: и для Postgresql у меня есть пару неласковых слов, и в форум nginx отписано несколько злых багов… Но для PHP эти затраты просто неимоверны, по сравнению с другими языками.
Немного напоминает противостояние пользователей vim и notepad, не находите?
Пофиксил, кто бы мог подумать, оказывается во фре есть ограничение в кол-во хардлинков на один файл, 32к всего…
php таки да, действительно в апаче присутствует, даже не знаю, что теперь делать… Идеология вроде требует срочно снести, но здравый смысл и отсутствие фанатизма крутят пальцем у виска, пожалуй, соглашусь с последними и оставлю, каши пока не просит.
Спасибо за напутствие, пригодится, сотни Гбит/c действительно не шутки (я не про wap-go и не про site-perf ;) ).
И Вам взаимно желаю всяческих благ.
P.S. а php я, кстати, использую, очень добротный cli-шаблонизатор, знаете ли. Поддерживает циклы и прочие вкусности, рекомендую. А wap-go и site-perf работают оба на перле, хотя кому какая разница ;)
В то время набирал популярность php 3.x, я как-то взялся изучать и его, но забросил, поняв, что это недоделанная калька с перла, заточенная на выполнение внутри апача, которая ничего принципиально нового предложить мне не может, и в то же время заберет кучу времени и сил на борьбу с php-шными непоследовательными особенности (каша в наименовании функций и анекдоты про разницу '==' и '===' существовали уже тогда). А мрачный и у"№щный RE в php и вспоминать страшно…
Хотя против ветра по маленькому и не ходят (как свидетельствуют только что полученные минусы), но повторюсь — у php-шников карма такая — регулярно набивать шишки на обильно разбросанные повсюду грабли.
И ruby язык сравнительно молодой, ему простительно, добавят как нибудь.
Вот в golang сразу же в интерфейс DB заложили Prepare() — системный язык все-таки.
Про старичка perl уже и не упоминаю, там prepare испокон веков работает как положено.
Не, ничего личного, но ей богу, забавно наблюдать, сколько велосипедов изобретено и сколько костылей настрогано вследствии принятия одного-единственного решения: «С чего бы начать изучать программирование? Наверное с PHP, не зря ж он такой популярный...»
Как бы там ни было, за статью автору респект. Prepared statements рулят. Ускорения sql там, в среднем, кот наплакал, но безопастность и надежность повышает сильно, поэтому их стоит использовать даже для единичных запросов.
И ещё аргумент проти выбивания дна — к моменту, пока вода и дно встретятся, образуется довольно много пара. Поэтому непосредственно резкой встречи как таковой не будет — будет происходить сжатие этого пара с постепенным нарастанием давления, которое будет замедлять встречное движение дна и воды.
Атмосферное давление под днищем стакана присутствует (иначе тяжело было бы оторвать стакан от стола).Но как только стакан приподымется над столом на расстояние, сравнимое со средним расстоянием между стаканом и столом, пока он стоит (т.е. на доли милиметра), как это давление пропорционально уменьшится — воздуху надо время чтобы пробрать под дно стакана и опять поднять давление до атмосферного. Это время будет сравнимо с временем выкипания воды в нижней части и заполнения пустоты паром (хотя и быстрее), так что стакан вверх навряд ли подымется слишком быстро и высоко, чтобы выбило дно.
Так что для некоторых ключей возможно встретится коллизия.
Делает ли это его таким же заслуживающим внимания как PHP3 — сомнительно.
Изначальная фишка php в том что он был действительно прост до опупения, и это позволило ему завоевать популярность. Но обвешивание языка шаблонизации (это отдельный разговор), поддержкой всего и вся, увы, не делает его самым крутым языком ;(
У php своя ниша, он идеально хорош для добавления несложной динамики в статический html, тут не поспоришь.
Но современные реалии таковы, что сайты уже не состоят из набора html-ек, это сложные движки, которые должны работать эффективно и надежно, а также удобно сопровождаться. У php проблемы и с первым, и с другим, и с третьим.
По пунктам:
Производительности perl-а php достиг с третьей версии, и фактически остановился (как и перл, но это другой разговор). Интерпретируемый язык не догонит C никогда, как кукурузник не догонит боинг, сколько реактивных двигателей на него не вешай. pecl-APC (или другие opcode кешеры) ещё помогает не сдохнуть php проектам под нагрузкой, hiphop сильно капризный и специфичный…
Надежность php обсуждать даже не смешно. Каждый релиз сопровождается тоннами исправленных багов, читаешь relnotes и радуешься «хорошо что меня это не касается и касаться не будет». Несовместимость самых версий, проблемы компиляции модулей на новых версиях… Не будем о плохом.
Ну и вернемся к самому языку как таковому. Честно признаюсь, не рассматривал подробно новшества php 5.4, не в курсе насколько елегантно они введены. Но учитывая, какой бардак происходит в именовании функций, в передаче параметров эти функциям, как реализованы RE и прочее… Что-то сомнительно что с версией 5.4 php заблистал утонченностью и элегантностью
В общем, IMHO и ещё раз IMHO, PHP — это как максимум начальный этап карьеры программиста, и чем быстрее его проскочить, тем лучше. Есть куча других языков и технологий, заслуживающих внимания.
windows используется на ещё большем проценте комп«ютеров, так что теперь, на basic-е программировать?
PHP все еще является наипростейшим языком для изучения не-техническими людьми
Спорный момент, хотя в части именно веб-программирования пожалуй соглашусь. Результат — мы имеем кучу технически не сильно образованных людей, которые считают себя веб-программистами, и клепают „сайты“.
Экосистема — ну, каждый кулик свое болото хвалит, я вот слыхал что на C можно написать вообще все-все, что можно написать на другом языке, куча либ на все случаи жизни, IDE такие что сами код могут писать… Мечта, а не язык.
Ну и главное замечание к статье — чем же так PHP гораздо лучше, чем мы думаем, автор так и не обьяснил…
В частности — поскольку жирность обеспечивается многожильностью — какое влияние на индуктивность/емкость оказывает тип переплетения жил? Есть ли смысл плести косички, или разнонаправленные свивки для разных пар жил, другие варианты..? Насколько оправданно применение медной фольги, высококачественной меди, проводов раздельного типа для bi-amp подключения, как совмещать эти разные провода для bi-amp в одной оболочке…?
Увы, но даже недешевые кабеля известных фирм вовсе не обеспечивают гарантию отсутствия слышимого искажения аудио-сигнала, очень много продукции среднего пошиба, что продвигается исключительно маркетингом с расчетом «авось найдется лох который купится на рекламные обещания, все равно осцилографом мерять не будет». Вспомнить хотя бы позолоченные безкислородные бла-бла кабели питания для подсоединения к алюминиевой электропроводке ;)