@Inori10 июл 2012 в 16:37

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

1 мин

12K

PHP *

+51

Комментарии 74

@SamDark 10 июл 2012 в 17:42

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

@masterx 10 июл 2012 в 17:55

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

@JiLiZART 10 июл 2012 в 19:21

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

@Flam 11 июл 2012 в 23:28

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

@SamDark 11 июл 2012 в 23:58

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

@Karen 12 июл 2012 в 09:12

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

@VolCh 10 июл 2012 в 18:58

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

@Davert 10 июл 2012 в 22:33

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

@VolCh 10 июл 2012 в 23:06

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

@Deffe 10 июл 2012 в 19:02

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

@frentsel 10 июл 2012 в 19:35

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

@nikosid 10 июл 2012 в 19:40

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

@zim32 10 июл 2012 в 20:26

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

@LayneBuchyn 10 июл 2012 в 21:02

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

@LayneBuchyn 10 июл 2012 в 21:10

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

@jrip 10 июл 2012 в 21:27

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

@MaksSlesarenko 10 июл 2012 в 21:26

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

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

@VolCh 10 июл 2012 в 23:09

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

@cachealot 10 июл 2012 в 22:04

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

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

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

@jrip 10 июл 2012 в 22:46

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

@Fortop 11 июл 2012 в 06:52

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

@cachealot 11 июл 2012 в 21:14

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

@Fortop 11 июл 2012 в 21:31

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

@cachealot 11 июл 2012 в 22:01

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

@Fortop 11 июл 2012 в 22: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 12 июл 2012 в 19:10

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

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

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

@Fortop 13 июл 2012 в 02:12

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

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

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

@LayneBuchyn 11 июл 2012 в 07:36

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

@cachealot 11 июл 2012 в 21:13

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

@esc 10 июл 2012 в 23:23

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

@VolCh 10 июл 2012 в 23:56

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

@esc 11 июл 2012 в 00:10

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

@VolCh 11 июл 2012 в 00:35

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

@esc 11 июл 2012 в 00:36

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

@VolCh 11 июл 2012 в 00:52

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

@esc 11 июл 2012 в 01:15

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

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

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

@nooze 11 июл 2012 в 07:55

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

@esc 11 июл 2012 в 07:56

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

@nooze 11 июл 2012 в 07:57

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

@esc 11 июл 2012 в 07:58

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

@nooze 11 июл 2012 в 08:09

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

@mirrr 11 июл 2012 в 17:53

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

@nooze 11 июл 2012 в 18:16

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

@esc 11 июл 2012 в 19:32

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

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

@So1 11 июл 2012 в 01:27

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

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

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

@nightstalker 11 июл 2012 в 13:09

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

@VolCh 10 июл 2012 в 23:09

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

@alekciy 12 июл 2012 в 15:28

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

@varnav 13 июл 2012 в 18:18

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

@LayneBuchyn 10 июл 2012 в 20:38

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

@Amadeusck 10 июл 2012 в 21:52

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

@spacediver 10 июл 2012 в 22:18

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

НЛО прилетело и опубликовало эту надпись здесь

@nmike 11 июл 2012 в 05: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 12 июл 2012 в 00:02

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

@softm 12 июл 2012 в 14:32

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

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

@nmike 13 июл 2012 в 09:00

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

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

@VolCh 13 июл 2012 в 09:30

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

@VolCh 13 июл 2012 в 09:29

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

@miraage 11 июл 2012 в 07:13

github codeguy
Josh Lockhart

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

@diamant 11 июл 2012 в 07:16

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

@softm 11 июл 2012 в 12:03

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

@diamant 11 июл 2012 в 12:05

Safari@iOS 5.1.1

@weiss 11 июл 2012 в 12:06

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

@stevebest 11 июл 2012 в 08:21

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

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

@Inori 11 июл 2012 в 08:36

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

@stevebest 11 июл 2012 в 08:55

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

d23d74af6d760a8db5f76dac9ba5a690

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

@truezemez 11 июл 2012 в 09:02

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

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

@stevebest 11 июл 2012 в 09:14

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

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