[PHP] Развитие

> Самый лучший язык для этих целей — PHP, правильно понимаю?

Если сайт будет хоститься на своей машине, то что угодно, хоть qbasic@cgi. А самые нищебродские хостинги идут с php.

>а теперь тот же фокус с DOMDocument ;)

Вот так, раз за разом, и придумываются новые отмазки :)

ты о чем? Я тебе даже пример дал. А date тут как раз исключение.
Самое позорное - в доках не описано, какие именно из встроенных объектов не сериализуются, и никаких предупреждений интерпретатор не выдает.

>Самое позорное - в доках не описано

Ну, лично у меня пока даже мысли не возникало стандартные PHP-объекты сериализовать. Не могу придумать, зачем такое нужно :) Вот собственные — это да, это постоянно…

Ага. Есть такое слово, «родина» :) .

Язык сам по себе не самый плохой, но как-то все в нем грустно, по современным меркам. Юникода нормального нет, асинхронности нет. Криокамера повышенной надежности, мля.

GAE идет на педоне и жабе. Есть еще на руби и жабаскрипте. Все нищебродское. Но это ж думать надо :)

Похапе повторяет судьбе бейсика - когда-то было клево, а потом все сдулось.

>Не могу придумать, зачем такое нужно
сохранить в сессии например. Или в БД засунуть. В чем собственно принципиальное отличие от собственных объектов?

>сохранить в сессии например

Но зачем тебе Dom в сессии сохранять? Или в БД?

В чем собственно принципиальное отличие от собственных объектов?

Вообще, если подумать, то соврамши я. Сериализованные объекты почти никогда не храню, чаще, таки, имя класса и ID.

То есть когда-то, много лет назад, сериализацию интенсивно использовал, потому машинально и написал, что «часто». Но в последние годы — навскидку не могу вспомнить случаи сериализации объектов.

>Но зачем тебе Dom в сессии сохранять? Или в БД?
лично у меня в виде xml хранилась некая иерархическая структура, которую я активно использовал. Правда сейчас я от этого ушел, переделав логику работы. Но был вполне рабочий вариант.
Ну и кроме DOM в пхп еще много всяких полезных объектов. Зачем ограничивать людей?

чаще, таки, имя класса и ID.

а информация в объектах откуда берется? Каждый раз БД дергаешь?

>а информация в объектах откуда берется?

Из бэкенда.

Каждый раз БД дергаешь?

Пока работа в рамках одного процесса — в кэше. А при межпроцессной работе — только так. А как иначе ещё синхронность объектов соблюдать? Да и «дёргание» БД — это копеечные затраты в рамках PHP.

>Да и «дёргание» БД — это копеечные затраты в рамках PHP.
Это только на маленьких проектах. На больших, когда сервера бд расположены отдельно на это накладывается еще оверхед передачи по сети. Ну и база почти всегда является самым узким местом, а не скорость PHP.

Потому что не нужен?

>На больших, когда сервера бд расположены отдельно на это накладывается еще оверхед передачи по сети

Там уже кеширование нужно.

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

Увы, нет. В большом проекте PHP будет всё также лимитировать :)

Проблемы с производительностью PHP легко решаются покупкой нового сервера для бэкэнда, на том же хетзнере простейший сервер стоит 40-50$ в месяц без установочной платы. Для большого проекта такие траты вообще несущественны. Проблемы же с БД гарантируют много веселья и так просто не решаются.

>Проблемы с производительностью PHP легко решаются покупкой нового сервера для бэкэнда

Ну так и в чём тогда вопрос с БД? На сбалансированном железе всё равно лимитирует PHP.

Проблемы же с БД гарантируют много веселья и так просто не решаются.

Шардинг, кеширование, репликация и много других умных слов. Не вижу особых проблем :)

Да не лимитирует ничего он. Издержки можно снизить - да. Но масштабируется он горизонтально вообще без никаких умных слов и проблем. То, что легко горизонтально масштабируется, лимитрующим не считается.
А вот для того, чтобы масштабировать БД требуются определенные умные телодвижения и зачастую переписывание куска приложения.
П.С.
Facebook не лимитирует(hiphop создан в основном для снижения издержек), Вконтакте не лимитирует, Wikimedia не лимитирует, Digg не лимитирует, Flickr не лимитирует, а вас лимитирует, что у вас там за такой сложный проект?

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

Ради интереса однажды с помощью php получилось посылать через браузер команды на микроконтроллер.

Для примера насчет масштабируемости.
Первый случай, PHP тормозит, у меня 1 сервер:
Я иду допустим на hetzner.de, беру там еще один самый простой сервер http://www.hetzner.de/en/hosting/produkte_rootserver/x2 , с вычетом НДС он выйдет 30$(чуть больше стоимости моего часа в виде фриланса или около 3 рабочих часов). Подключаю его, записываю строку в балансировщик. И вуаля, пхп ускорился в 2 раза.
Второй случай, база тормозит, у меня 1 сервер:
Запасаюсь вазелином и предвижу трату нескольких рабочих дней минимум, что выльется в гораздо более значительную сумму.

«На больших проектах» и «с вычетом НДС он выйдет 30$» + «PHP» — это, всё же, немного оксюморон :)

По моей же практике, тормоза PHP — вещь достаточно частая. Тормоза БД при грамотном дизайне — исключительная. Но если у меня начнёт тормозить PHP и кеширование не поможет, то я не стану «покупать ещё один сервер за два чатла», а переведу проект на Java или хотя бы Python. При чём заранее, до того, как он начнёт тормозить.

>«На больших проектах» и «с вычетом НДС он выйдет 30$» + «PHP» — это, всё же, немного оксюморон :)
Я это к тому, что увеличить скорость работы части за которую отвечает php можно за копейки.

При существенной нагрузке на базу на отдельном сервере, очень маловероятно, что у вас запросы к БД будут занимать времени сильно меньше, чем выполнение кода на php.
А насчет тормозов php, то тут рецепт стандартный, кэшер опкода + грамотные шаблоны + компиляция библиотек фреймворка в один файл.
У меня почему-то возникает смутное чувство, что вы не работали с проектами с существенной нагрузкой.

>У меня почему-то возникает смутное чувство, что вы не работали с проектами с существенной нагрузкой.

Понятие «существенной загрузки» — довольно субъективно.

Безусловно, я не работал с проектами, уровня Википедии. Но что-то мне подсказывает, что и Вы — тоже.

Мой опыт в Web'е завершается на нагрузках под 1,5-2 тыс. MySQL-запросов в секунду и на пиковом онлайне до 2-3 тыс. клиентов. Что-то под 3 млн. хитов в сутки.

В области специализированных серверов — на 1000-1500 активных коннектов, взаимодействующих с 50-70 тыс. взаимодействующих в реальном времени объектов.

Не знаю, на сколько Ваш опыт круче, но что-то мне подсказывает, что имеющийся свой опыт я могу достаточно уверенно экстраполировать ещё в несколько раз.

У меня примерно такой же опыт. Пиковый онлайн побольше правда, но суточная нагрузка поменьше.
Насчет экстраполирования. Примерно как вы представляете работы по подготовке одного из проектов с которыми вы работали и у которых онлайн 2-3 тыс. пользователя в секунду к онлайну 20-30 тыс. пользователей, с пропорционально выросшей базой? И где вы видите основной геморрой(господам гусарам прошу воздержаться)?

Можно свой высер добавлю?

Много ли ЛОРовцев разрабатывают настолько серьезные веб-проекты (например, вроде php-bb), что им нужен PHP?

ИМХО, вряд ли хотя бы 5 человек наберется...

Не знаю много ли, но я думаю хватает, это не самый сложный и неприятный способ заработать деньги.
Я подозреваю, что вы хотите предложить использовать для разработки Си через CGI, поэтому я сразу выскажу свой довод против.
На пхп очень просто работать с бизнес-логикой. Вообще не надо напрягаться, просто пишешь и всё. С тем же json работа намного проще чем в Си, с Cookies, с базой. Много готового кода в виде библиотек.

Нет, я не про С, я про баш, перл, питон и что там еще...

Php гораздо проще. Его освоит может даже школьник. И при этом он Достаточно хорош.

Его освоит может даже школьник.

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

Не вижу в этом ничего плохого. Кривой сайт с нужной информацией лучше несуществующего. Заодно падают цены на хостинг и формируется экосистема из которой выходят более-менее адекватные сайты.

Пых мой основной язык по сути, остальное лишь для опыта и галочки.
Печалят по сути те же самые вещи, когда для написания асинхронного скрипта приходится сочетать все виды костылей: multicurl, pcntl, асинхронные сокеты.
В итоге рождаются мутанты вроде PHP-Daemon и classkit.

Ну и что печалит больше всего: в язык периодически вводят функции которые по сути полезны и круты, но на деле оказывается что реализация очень кривая и не оправдывает потраченные ресурсы.
shm_* например.

>На пхп очень просто работать с бизнес-логикой.

На пхп

с Cookies

Я бы вас на месте расстрелял, вместе с остальными неасиляторами сессий в PHP.

>Но если у меня начнёт тормозить PHP и кеширование не поможет, то я не стану «покупать ещё один сервер за два чатла», а переведу проект на Java или хотя бы Python.
Эм.
Я пока на опыте не видел ни одного крупного проекта, где бы перевод всего кода на другую платформу стоил бы дешевле чем докупка пары серверов.

Есть еще такая вещь, как яваскрипт, которая почему-то не умеет работать с сессиями.

Это как? Сессия представляет собой совокупность ключа, хранящегося на сервере, и куки, хранящейся у клиента. С каких это пор JS разучился работать с куками?

> Как считают аналитики ЛОР'а, почему столь популярный продукт начал загибаться?

Потому что пошли в массы достойные альтернативы этому недоразумению.

Наоборот. Ключ хранится в куках, а данные хранятся на сервере. Поэтому клиентом нельзя считать данные из сессии.
Я понимаю, что хотел сказать winddos. Он имел в виду то, что не стоит хранить в куках то, что можно хранить в сессии, потому как куки генерируют трафик при каждом HTTP запросе, но он естественно не учел, что этим не сделать даже такую элементарную вещь, как галочку Remember me и что есть очень много мест, где одними сессиями не обойтись.
Просто ему нужно научится говорить повежливее.

Он имел в виду то, что не стоит хранить в куках то, что можно хранить в сессии

А как сервер будет определять подлинность клиента? Все-таки, без кук не получится. И еще: я не видел ни одного сайта с авторизацией без кук.

> GAE идет на педоне и жабе.

Но даже там некоторые используют php интерпретатор на java.

При авторизации как раз данные записываются в сессию и туда же записывается ip. Поэтому злоумышленник сможет угнать куки, который поставить себе и получить ту же сессию, но ip у него будет другой и это не пройдет. Куки тоже годятся для этого, но сессии более удобны.
А куки тут нужны, чтобы хранить идентификатор сессии.
Просто если нужно например передать между страницами штук 5-6 переменных, то лучше делать это в сессии, так как то, что в куках оно будет и в заголовке запроса от пользователя и в заголовке ответа от браузера, что увеличивает трафик, а при сессии оно будет в файле или в memcache или еще где, смотря как настроено.

А вот в другой теме мне советовали к IP сессию не привязывать.

И кому верить?

Дальше. То, что вы называете сессиями, я так понимаю, является сохранением в БД UA и IP клиента. Т.е. при следующем подключении или смене UA клиенту придется заново проходить аутентификацию => «запомнить» мы его не сможем.

А вот в другой теме мне советовали к IP сессию не привязывать.

Это опять таки вопрос безопасности <-> удобства.

>что этим не сделать даже такую элементарную вещь, как галочку Remember me
Вы вообще о чем, какая такая галочка?
Никто не мешает вам через JS (!!!) залить в куки всю нужную информацию при авторизации клиента.

Т.е:
1 - Клиент авторизуется.
2 - PHP отдает клиенту в хидерах ТОЛЬКО идентификатор сессии.
3 - При этом нужные кукисы можно передать как в HTTP заголовке, так и в виде json, чтобы уже клиентский скрипт их залил.

и что есть очень много мест, где одними сессиями не обойтись.

Перечислите.

Просто ему нужно научится говорить повежливее.

Я очень вежлив, но считать «удобную работу Cookies» одним из плюсов ЯП, это очень печально.

Никто не мешает вам через JS (!!!) залить в куки всю нужную информацию при авторизации клиента.

А что, сгенерировать куку можно как-то иначе?

Протухший вопрос и к топику не относящийся.
А уровень безопасности естественно одинаковый, т.к сессии используют куки.
Никто не мешает сбацать привязку к ip в куках.
Заливать в куки пароль в виде:
md5(pass.md5(ip))

Это вопрос компромисса между безопасностью и удобством. Насчет частой смены IP из-за NAS ничего сказать не могу. В принципе если авторизация идет через SSL то можно и не привязывать, безопасность останется на достаточном уровне, так как перехватить их сниффингом будет нельзя.
А сессия - это лишь механизм поверх кукисов для того, чтобы все данные не таскать постоянно к пользователю и обратно. Там сохраняется в БД не UA и IP клиента, а запись по PHPSESSID, а PHPSESSID хранится в куках. При следующем сеансе потребуется начинать новую сессию, поэтому запоминание делают обычно через куки.

Протухший вопрос и к топику не относящийся.

Вопрос был не о том как привязывать ip в куках. Читай внимательнее.

Есть 2 варианта передачи кукисов клиенту:
1 - Запись в _COOKIE, с последующим попаданием ответный HTTP хедер.
2 - Передача в теле страницы JS кода, который устанавливает нужные приложению куки.
Либо можно передавать только json который далее будет обрабатываться так же клиентом.

Ну а вообще я категорически против записи в куки чего либо кроме идентификатора сессии.
С тем же успехом можно сбацать в вашем приложении урлы вида:
http://myapp/#name=Vasya;postcode=301247;
В таким случае вся муть которая там храниться, хотя бы не будет долбать сервер с каждым HTTP запросом.

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

>При следующем сеансе потребуется начинать новую сессию
Зачем?
Что вам мешает хранить сессии годами, и удалять их при отсутствии активности пользователя?

Мне проще передавать то, что вы называете json.

Ну а вообще я категорически против записи в куки чего либо кроме идентификатора сессии.

А я и не думал, что туда еще что-нибудь можно записывать (точнее: для чего туда что-то иное записывать?)...

Благо сейчас в браузерах наконец появляются годных технологии для локального хранения данных

Это да, можно будет настройки сохранять на стороне клиента, а не париться с БД...

«удобную работу С Cookies» - я писал. В том же js работа с ними, а конкретно чтение, реализована менее удобна например.

Никто не мешает вам через JS (!!!) залить в куки всю нужную информацию при авторизации клиента.

Т.е:

1 - Клиент авторизуется.

2 - PHP отдает клиенту в хидерах ТОЛЬКО идентификатор сессии.

3 - При этом нужные кукисы можно передать как в HTTP заголовке, так и в >виде json, чтобы уже клиентский скрипт их залил.

Зачем заливать в куки через яваскрипт? Они ведь также будут каждый раз отправляться на сервер в заголовке, как и отправлялись. Не вижу в этом никаких плюсов перед стандартной передачей Set-Cookie в http заголовке от сервера клиенту.

Перечислите.

Запоминание пользователя на сайте, сохранение данных между сессиями о том, показывать ли окошки с хелпом, для анонимных пользователей, сохранение токенов для API когда работа с ним идет и через php, и через js, реализация той же корзины на стороне клиента.

А я и не думал, что туда еще что-нибудь можно записывать

C тобой и не спорю, ты видимо меня не правильно понял.
Ответил я о том, что можно устанавливать куки двумя разными методами:
- В HTTP хедере ответа.
- JS скриптом, на стороне клиента.
Если уж их и передавать, то я предпочитаю на стороне клиента.

Вообще отвечаю конкретно на идею Tark*а. Именно он считает, что существуют приложения где нужно хранить в куках что то кроме идентификатора сессий.