ИМХО введение goto в PHP 5.3. — тщательно продуманный и, как вы все видите, весьма успешный маркетинговый ход. Посмотрите, сколько уже написано комментариев и статей вокруг того, «какой плохой goto в PHP». Сколько человеко-часов лишилось человечество, потратив их на обсасывание этого вопроса. В итоге PHP станет еще более известным (пусть это черный пиар, но он работает).
Кстати, хранить номер телефона на сервере вовсе не обязательно. Можно хранить хэши вида salt + md5(salt + phone), где salt выбирается случайным образом. Обычно так с паролями поступают. Возможно, Гугл так и поступает, все-таки от краж базы никто не застрахован…
Кажется, что SMS-авторизация включается не в зависимости от региона, а по принципу превышения кол-ва регистраций в единицу времени с одного ip-адреса (а может быть, адреса + браузера даже?). Сегодня ради любопытства завел еще 2 ящика, первый зарегался сразу, а для второго потребовалась SMS-активация (регал его спустя несколько часов).
> Всё, чего мы в жизни достигаем действительно стоящего –
> достигается только «через не могу»
Не согласен категорически. Нельзя добиться успеха в деле, которое не нравится, когда приходится заставлять себя что-то сделать. И наоборот: если любимым делом заниматься достаточно долго, то рано или поздно добьешься в нем успехов.
Во всем остальном я с автором согласен (особенно если не придираться к мелочам в статье, не скатываться на «да это робот», а уловить общую идею). С глубоким уважением к нему.
Насколько я понимаю, операция создания снапшота в него ничего не записывает. Это просто указание системе «начиная с этого момента все данные записывай, пожалуйста, не на основной диск, а в снапшот». Поэтому создается снапшот очень быстро. Ну а flush выполняется быстро потому, что он идет почти сразу после первого (долгого) flush-а.
Бэкап при помощи LVM занимает считанные секунды (а иногда и считанные миллисекунды). По сравнению с репликацией он имеет то преимущество, что не ломается без конца (а репликация — конструкция достаточно шаткая) и не требует отдельной машины (и почти не требует ресурсов). Вот примерная последовательность команд:
mysql: flush (5-10 секунд, не блокирует ничего, так что не считается)
— mysql: lock (мгновенно)
mysql: flush (меньше секунды)
lvm: сделать snapshot (меньше секунды)
mysql: unlock (мгновенно)
lvm: отпустить snapshot
Поправьте меня, если я что-то не так понял. Но в соответствии с Tip #1, если у Вас все страницы полностью кэшируются «кронами» и отдаются, фактически, как статика, то число 300 запросов в секунду (да и 3000 тоже) не выглядит таким уж большим. В этой связи вопрос: какой же плюс тогда в использовании App Engine, если ту же самую задачу может выполнить даже один сервер в ДЦ с хорошим каналом?
Такое ощущение, что выборка очень нерепрезентативная: в ролике Опера идет наравне с IE, что согласно статистике по Рунету несколько расходится с действительностью. Складывается впечатление, что опрашивали больше «гиков», чем среднюю аудиторию.
Поддержу Андрея. Мне приходилось работать с тремя полнотекстовыми движками: MySQL (ИМХО — ад кромешный: словоформ нет, работает медленно, в innodb не поддерживается), PostgreSQL (ИМХО — довольно хорош, однако сильно тормозит, в частности — при ранжировании, т.к. вначале делает всю выборку, а потом ее сортирует) и Sphinx. Последний лично мне больше всего нравится (особенно shebang-конфиги, это сказка), но у него есть большой недостаток: «без пол-литра не разберешься». В смысле, порог на вход очень высокий. Мне думается, что продукт можно значительно улучшить малой кровью, просто упростив работу с ним: добавить «коробочные» словоформы (всего-то в дистрибутив положить словарь и сделать в конфиге возможность указания относительного пути к файлам словаря), а также написать обертку для упрощения процесса инкрементного индексирования.
1. А почему Вы поставили Сфинкс в корень, а не в /usr/local/sphinx, как это принято в Денвере? Есть ли какие-нибудь аргументы?
2. Hstart — судя по всему, неплохая штука. В Денвере же есть специальное средство-враппер для «оборачивания» вызова exe-шников и отправки их в трей (оно применяется в sendmail-сервере и в Apache). Правда, в нем есть недостаток (который в некоторой степени достоинство — например, когда нельзя менять командную строку): путь к исполняемому файлу нужно прописывать прямо внутри exe-шника враппера в текстовом виде (там для этого есть соответствующее задокументированное место).
Речь, насколько я понял, была не об этом. А о том, что безумно криво устроено, например, в том же Propel: невозможность в СТАТИЧЕСКОМ методе базового класса определить, для какого из производных классов он вызван. Например:
class Base {
public static function f() { echo что-то-что-дает-имя-класса; }
public function r() {… }
public function call() { self::r(); }
}
class Derive extends Base {
public function r() {… }
}
Base::f(); // хочется увидеть «Base»
Derive::f(); // хочется увидеть «Derive»
Derive::call(); // хочется, чтобы была вызвана Derive::r(), а не Base::r()
Так вот, из-за того, что в 5.2 не существует способа реализовать функцию f(), чтобы она работала, как описано, они создают громадные генераторы кода, которые в основном только и делают, что создают бесконечные статические методы. Более того, делать у себя в программе производные классы почти невозможно — именно из-за отсутствия полиморфности у статических методов как таковой.
В Perl, например, можно писать
$a = $b || 10;
А теперь и в PHP можно будет:
$a = $b :? 10;
Правда, в Perl можно еще и
$a ||= 10;
а вот в PHP
$a :?= 10 — вроде пока нельзя (а жаль).
Удобен ?: тем, что не нужно дважды повторять одно и то же rvalue (особенно когда это rvalue длинное или представляет, например, вызов функции — вот тут-то в 5.2 без временной переменной вообще не обойтись было).
Ну это будет ИМХО еще больший изврат — 2 синтаксиса для абсолютно одного и того же. Так что я бы лично не рассчитывал на то, что мы в ближайшие 5-10 лет увидим :: вместо \…
> достигается только «через не могу»
Не согласен категорически. Нельзя добиться успеха в деле, которое не нравится, когда приходится заставлять себя что-то сделать. И наоборот: если любимым делом заниматься достаточно долго, то рано или поздно добьешься в нем успехов.
Во всем остальном я с автором согласен (особенно если не придираться к мелочам в статье, не скатываться на «да это робот», а уловить общую идею). С глубоким уважением к нему.
rdiff-backup.nongnu.org не спасет ли?
mysql: flush (5-10 секунд, не блокирует ничего, так что не считается)
— mysql: lock (мгновенно)
mysql: flush (меньше секунды)
lvm: сделать snapshot (меньше секунды)
mysql: unlock (мгновенно)
lvm: отпустить snapshot
Мудрые учатся на чужих ошибках.
Умные учатся на своих ошибках.
А дураки вообще ни на чьих ошибках не учатся.
В общем, Андрей, — спасибо за отличную штуку!
2. Hstart — судя по всему, неплохая штука. В Денвере же есть специальное средство-враппер для «оборачивания» вызова exe-шников и отправки их в трей (оно применяется в sendmail-сервере и в Apache). Правда, в нем есть недостаток (который в некоторой степени достоинство — например, когда нельзя менять командную строку): путь к исполняемому файлу нужно прописывать прямо внутри exe-шника враппера в текстовом виде (там для этого есть соответствующее задокументированное место).
class Base {
public static function f() { echo что-то-что-дает-имя-класса; }
public function r() {… }
public function call() { self::r(); }
}
class Derive extends Base {
public function r() {… }
}
Base::f(); // хочется увидеть «Base»
Derive::f(); // хочется увидеть «Derive»
Derive::call(); // хочется, чтобы была вызвана Derive::r(), а не Base::r()
Так вот, из-за того, что в 5.2 не существует способа реализовать функцию f(), чтобы она работала, как описано, они создают громадные генераторы кода, которые в основном только и делают, что создают бесконечные статические методы. Более того, делать у себя в программе производные классы почти невозможно — именно из-за отсутствия полиморфности у статических методов как таковой.
В Perl, например, можно писать
$a = $b || 10;
А теперь и в PHP можно будет:
$a = $b :? 10;
Правда, в Perl можно еще и
$a ||= 10;
а вот в PHP
$a :?= 10 — вроде пока нельзя (а жаль).
Удобен ?: тем, что не нужно дважды повторять одно и то же rvalue (особенно когда это rvalue длинное или представляет, например, вызов функции — вот тут-то в 5.2 без временной переменной вообще не обойтись было).