Inori Jul 10 2012 at 20:37

Используем PHP правильно

1 min

12K

PHP*

+51

Comments 74

SamDark Jul 10 2012 at 21:42

Я собираюсь перевести как только пыль чуть поуляжется.

masterx Jul 10 2012 at 21:55

С удовольствием помогу тебе в этом деле, если потребуется помощь. Обращайся.

JiLiZART Jul 10 2012 at 23:21

Учитывая твой опыт, будет намного лучше, если это сделаешь ты )

Flam Jul 12 2012 at 03:28

Пользуясь случаем, хочу поинтересоваться…
А как продвигается (продвигается ли вообще) перевод книги по Yii?

SamDark Jul 12 2012 at 03:58

Завершён. Редактируется.

Karen Jul 12 2012 at 13:12

И в итоге это добро да и в pdf одним файлом, было бы очень здорово.

VolCh Jul 10 2012 at 22:58

Задумка хорошая, но что-то использование github pages/Jekyll/блог-движка/линейной структуры не воодушевляет. Или я плохо представляю их возможности и возможно создавать, скажем, таксономии типа как в Drupal, позволяющие классифицировать один объект контента по многим измерениям? Да и возможности коллобрации, имхо, не самые лучшие у github pages. Есть же вики.

Davert Jul 11 2012 at 02:33

Чем git от вики отличается в данном моменте?

VolCh Jul 11 2012 at 03:06

Не git, а github pages: нет истории правок, нет возможности редактировать «по живому»

Deffe Jul 10 2012 at 23:02

Капитан PHP тут как тут! Всегда настороже.
itmages.ru/image/view/585443/11cf38f0

frentsel Jul 10 2012 at 23:35

верной дорогой идете, товарищи! :)

nikosid Jul 10 2012 at 23:40

Сайт не открывается. Хабраэффект?

zim32 Jul 11 2012 at 00:26

Хороший язык PHP, особенно 5.4. Сам на нем пишу. Проблема у него в основном с производительностью. Конечно на микро скриптах и минисайах это не так заметно, а вот в больших проектах уже реальная проблема. Выезжает это все пока на внедрении кеширования везде где это только возможно — парсинг аннотаций, маршрутизация, кеширование классов, конфигов, шаблонов на всех уровнях построения системы

LayneBuchyn Jul 11 2012 at 01:02

Вы серьезно? А мне всегда казалось, что в больших проектах основное время работы приложения тратится на операции с БД. Что касается производительности, то в PHP с ней все очень даже неплохо — быстрее чем Perl, Python или большинство Java-веб-приложений. Пруфлинк не запрашивайте — это известный факт.

LayneBuchyn Jul 11 2012 at 01:10

Уточнение: хорошо оптимизированному и написанному прямыми руками Java-приложению сложно составить конкуренцию в производительности, но большинство Java-приложений не могут этим похвастаться.

jrip Jul 11 2012 at 01:27

Ну так на PHP тоже никто не мешает написать прямыми руками и хорошо оптимизировать. :)
А вообще, есть еще обработка больших объемов данных, приложения с постоянными соединениями где Java скорее всего будет уже намного более продуктивней.

MaksSlesarenko Jul 11 2012 at 01:26

> А мне всегда казалось, что в больших проектах основное время работы приложения тратится на операции с БД.

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

VolCh Jul 11 2012 at 03:09

А это от языка зависит?

cachealot Jul 11 2012 at 02:04

www.gotsulyak.com/wp-content/uploads/2010/08/groovy-php-python-ruby-performance-comparison.png вот не запрашиваемый пруф.

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

да и как сказали в соседнем комментарии — все зависит от конкретного разработчика.

-3

jrip Jul 11 2012 at 02:46

На самом деле нормальных сравнительных тестов так похоже никто и не проводил на реальных задачах.
Ну т.е. написать одинаково хорошо один и тот же высоконагруженный проект на двух языках и посмотреть что будет.
А так конечно глупо сравнивать ROR к примеру c ORM и т.д. и т.п. с native PHP и чистыми sql запросами.
Мое чисто субъективное мнение, что PHP все-таки немного быстрее, чем к примеру Perl, но это вполне возможно связано с тем, что особенности PHP я знаю на порядок лучше.

Fortop Jul 11 2012 at 10:52

shootout.alioth.debian.org/u64/benchmark.php?test=all&lang=php&lang2=python3
немного другой пруф

cachealot Jul 12 2012 at 01:14

Вы сравнимаете 3й питон, хотя в веб разработке сейчас все используют 2й.
Что самое интересное — второго питона я в этом списке не вижу.

Fortop Jul 12 2012 at 01:31

Во-первых, сравниваю не я.
Во-вторых, 2й питон медленнее 3го, равно как и php 5.2 медленнее чем php 5.4

-1

cachealot Jul 12 2012 at 02:01

вы мне даете ссылку.
вы не верно рассуждаете, и судя по всем кроме php ничего не видели, к сожалению

Fortop Jul 12 2012 at 02:55

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

А вот тот факт, что вы его не знаете, говорит о том, сколько всего видели вы.
Ну и тесты на которые вы ссылаетесь…
danvk.org/josephus.html

Говорят о вас больше, чем вы того сами быть может желали бы.

Что касается «рассуждений», то это не рассуждения. Вы можете установить все 4ре версии и проверить самостоятельно.

php 5.2.13 420 microseconds per iteration
php 5.2.17 429 microseconds per iteration
php 5.4.4 172 microseconds per iteration
python 2.6.6 83 microseconds per iteration
python 3.2.3 90 microseconds per iteration
python 3.3.0 70 microseconds per iteration

Я доступно для вас излагаю?

cachealot Jul 12 2012 at 23:10

Вполне доступно.

я не знаю где вы взяли эти тесты, я пологаюсь на свой опыт. Но даже по текстам ним видно что питон быстрей пхп.
B второе — в продакшене найти питон 3.3.0 на данный момент довольно сложно, если вы конечно пишите на питоне, то вам это должно быть известно. Плюс ко всему если эти тесты верны — то разница скорости работы питона по сравниную с разницой пхп — не существенна.

PS к сожалению дальше спор продолжать не вижу смысла :)

Fortop Jul 13 2012 at 06:12

Я не утверждал что пхп быстрее питона (что именно я утверждал, вы можете попытаться осилить прочитать несколькими комментариями выше habrahabr.ru/post/147535/#comment_4977472 )

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

Прискорбно… для вас.

LayneBuchyn Jul 11 2012 at 11:36

«Пруф», на котором просто картинка без единого слова и хоть какого-то описания, не воспринимается как-то серьезно.

cachealot Jul 12 2012 at 01:13

www.gotsulyak.com/2010/08/post404 Вот пруф.
Кстати вы можете просто в гугле вбить скорость работы пхп, питон, перл и почитать статьи на эти темы, если вы мне не верите.

esc Jul 11 2012 at 03:23

БД обычно неплохо кэшируется, основная нагрузка таки падает на php (ну или не php) бэки, а не базу.

VolCh Jul 11 2012 at 03:56

Обычно (встроенными средствами СУБД), имхо, плохо, приходится принимать специальные меры (кэширование на уровне приложения, а не СУБД).

esc Jul 11 2012 at 04:10

Ну да, на уровне приложения, конечно. Кеширование популярных выборок в мемекеше (а то и вообще на уровне nginx proxy cache) очень сильно снижает нагрузку на базу, этим очень глупо не пользоваться.

VolCh Jul 11 2012 at 04:35

Не помню: инвалидация кэша — это первая или вторая по значимости проблем программирования вкупе с именованием сущностей языка? :)

esc Jul 11 2012 at 04:36

Есть очень много задач, где эта проблема решается встроенным в memcache таймаутом;)

VolCh Jul 11 2012 at 04:52

Очень редко встречаю на практике задачи, где инвалидации по TTL хватает. Обычно нужна оперативная: отправил POST запрос с комментом и он должен появиться у всех кто отправил GET на пост после окончания обработки этого POST. Заказчики на вопрос «допустимо ли что после того как коммент появился в базе была задержка перед его отображением в том или ином виде у посетителей?» отвечают однозначно — «нет!».

esc Jul 11 2012 at 05:15

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

Во-вторых, для многих видов обновлений данных, кэш можно прогреть при обновлении.

В третих, задержка 1-10с при отображении данных у других пользователей, в 99.99% случаев некритична, если заказчик требует обратного и не слушает доводы против, пусть покупает сервера, вряд ли, другуй язык с самодуром справится лучше.

nooze Jul 11 2012 at 11:55

Иии вот опять любой пост про PHP скатился к обсуждению насколько php быстрый/кривой/медленный/правильный VS любой_другой_язык ))

esc Jul 11 2012 at 11:56

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

nooze Jul 11 2012 at 11:57

Это да, но почему-то любой пост о php в итоге к этому приходит (:
Хотя это логично в принципе

esc Jul 11 2012 at 11:58

Ну давайте об автомобилях поговорим. Мне вот только ручная коробка по душе…

nooze Jul 11 2012 at 12:09

А я два года проездил на ручной, а потом год на хорошем автомате и по моему мнению оба варианта имеют плюсы и минусы, но для этого у нас есть автокадабра )

mirrr Jul 11 2012 at 21:53

DSG обходит и первую и вторую. Пруфлинк не запрашивайте — это известный факт.

nooze Jul 11 2012 at 22:16

А у меня автомат тоже от VAG — типтроник 6ст )) Так что про dsg я и сам в курсе, следующая моя машина будет скорее всего на ней

esc Jul 11 2012 at 23:32

Холивар;) Не обходит, ездил на множестве машин с разными коробками, был большего мнения о роботе до того, как поездил на нем. Резвее получается ручка, но я соглашусь с тем, что, в целом, она для энтузиастов.

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

So1 Jul 11 2012 at 05:27

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

> быстрее чем Perl, Python или большинство Java-веб-приложений. Пруфлинк не запрашивайте — это известный факт

Это неизвестный нефакт. Пруфлинк обязателен, ИМХО.

nightstalker Jul 11 2012 at 17:09

Мне нравятся люди, которые требуют пруфов, хотя сами бросают голословные утверждения.

VolCh Jul 11 2012 at 03:09

Имхо, производительность на уровне других интерпретируемых языков с динамической типизацией. Где-то выше, где-то ниже, но порядок один.

alekciy Jul 12 2012 at 19:28

И в чем конкретно заключается это проблема?
Что понимается под «большой проект»?

varnav Jul 13 2012 at 22:18

Я по воле судьбы админю проект на asp.net
До этого работал с проектами на PHP.
asp.net после PHP очень тормозной. ОЧЕНЬ. Чисто субъективно для меня как для админа.

LayneBuchyn Jul 11 2012 at 00:38

Просто крутатенюшка, чего уж тут!

Amadeusck Jul 11 2012 at 01:52

Ждем перевода. Удачи вам :)

spacediver Jul 11 2012 at 02:18

Отличный ресурс — много полезных ссылок собрано.

dxArtem Jul 11 2012 at 07:19

Знал про filter_var, но в силу загруженности и усталости на работе не знал про остальные http://us.php.net/manual/en/ref.filter.php, особенно понравилось filter_input_array. Но стоит все таки сделать перфоманс тесты на днях и глянуть, что быстрее, старый или новый метод санитарии.

Вообще поддерживаю ресурсы с подобными выдержками.

nmike Jul 11 2012 at 09:28

а вот тут интересно написано:

<?php
$pdo = new PDO('sqlite:users.db');
$stmt = $pdo->prepare('SELECT name FROM users WHERE id = :id');
$stmt->bindParam(':id', filter_input(INPUT_GET, 'id', FILTER_SANITIZE_NUMBER_INT), PDO::PARAM_INT);
$stmt->execute();

не, ну я понимаю что данные надо фильтровать, но зачем фильтровать фильтровать?

а вот если уж «быдлокодить»:

<?php
$pdo = new PDO('sqlite:users.db');
$pdo->query("SELECT name FROM users WHERE id = " . $_GET['id']); // <-- NO!

то хотя бы так:

<?php
$pdo->query("SELECT name FROM users WHERE id = " . ($_GET['id'] * 1)); // intval($_GET['id'])

зачем лукавить и сразу смещать фокус:

This is terrible code. You are inserting a raw query parameter into a SQL query. This will get you hacked in a heartbeat.

Плохо, если человек не будет понимать, почему его инжектнули в случае «быдлокода».

SamDark Jul 12 2012 at 04:02

Дельно. Пулл-реквестните чтоли…

softm Jul 12 2012 at 18:32

Последние 7-мь лет применяю полное преобразование всех пост/гет переменных в get_* post_* массив. С обработкой mysql real escape и с проверкой на sql комманды get_sql_* post_sql_* массивы. Таким образом можно и хайджекинг проверить, и собрать ай-пи «взломщиков» (в купе с првоеркой заголовков, ну это конечно для «начинающих взломщиков»).

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

nmike Jul 13 2012 at 13:00

полное преобразование всех пост/гет переменных в get_* post_* массив. С обработкой mysql real escape

простите, но это получается маджик квотс прям.

VolCh Jul 13 2012 at 13:30

Не совсем, к сырым данным же всегда можно обратиться.

VolCh Jul 13 2012 at 13:29

Имхо, неоправданный оверхед. Я экранирую данные перед выводом и именно тем способом, который для вывода нужен. Под выводом понимаю и вызовы любого внешнего сервиса типа mysql.

miraage Jul 11 2012 at 11:13

github codeguy
Josh Lockhart

знакомые личности :)

diamant Jul 11 2012 at 11:16

Может он и гуру пехапе, но в html/css ему много нужно ещё наверстать:

-9

softm Jul 11 2012 at 16:03

Хм, а что это за браузер такой? Айпад-ный чтоли? Как его на ПС посмотреть?

diamant Jul 11 2012 at 16:05

Safari@iOS 5.1.1

weiss Jul 11 2012 at 16:06

У iPad разрешение больше. iPhone'ами не пользовался никогда, но, очевидно, там тоже можно делать снимок экрана, как в Android.

stevebest Jul 11 2012 at 12:21

Правильный PHP: пароли надо хешировать.

Нет, тут уже никто не поможет.

-3

Inori Jul 11 2012 at 12:36

Можно поподробнее?
Вообще, здесь ведется обсуждение Bcrypt vs PBKDF2, можете присоединиться.

stevebest Jul 11 2012 at 12:55

Если кому-то, пусть даже начинающему разработчику, нужно объяснять необходимость хеширования паролей, то я на это могу сказать только одно:

d23d74af6d760a8db5f76dac9ba5a690

Это MD5 без соли, чтобы не так сложно было догадаться.

-4

truezemez Jul 11 2012 at 13:02

Если кому-то, пусть даже начинающему разработчику, нужно объяснять необходимость хеширования паролей...

Вы родились с этим знанием?

stevebest Jul 11 2012 at 13:14

Рад, что вы спросили.

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

-4