egorinsk

Не верю в чудеса и неожиданности.

Зато верю в то, что чем строже и больше различных проверок ввести, тем больше ошибок выскочит. Для этого:

1) ставлю error_reporting в -1 (показывать абсолютно все ошибки, включая всякие deprecated и strict standarts)
2) Иногда делаю код, преобразующий любую малейшую ошибку в исключение, валящее всю программу (в не-PHP языках это часто по умолчанию так и есть, и это правильно)
3) указываю type hints — если в функцию должен придти массив или объект определенного класса, то так и пишу
4) Ставлю assert() массово. Если переданный в функцию массив не должен быть пуст, а другая переменная не может быть отрицательной, проверяю это
5) Не использую @ и не исправляю ошибки, пока не пойму причину (так как реальная ошибка может быть в вызывающем коде)
6) В штуках, которые принимают плейсхолдеры, всегда проверяю соответствие числа плейсхолдеров и переданных данных
7) Жалею, что в PHP нет (или уже есть?) type hints для скалярных типов

> При правильном проектировании на самом деле часто бывает, что оно работает, и ты не понимаешь почему, и это нормально…

Нет, не бывает. Вы просто плохо разбираетесь в коде или особенностях языка.

Самый слабый и медленный, с самым маленьким количеством памяти.

Внимание, правильный ответ.

Вместо скачивания файлов вручную и, тем более, написания своих файловых систем, необходимо написать скрипт (на любом нравящемся вам языке, я бы выбрал bash), который будет соединяться с сервером по ssh, делать дамп БД, и коммитить все нужные файлы в SVN. Сам будет делать всю работу, а не вручную. Тогда проблема «забыл закоммитить файл» исчезает автоматически.

Может, потому, что через SSL провайдеру неудобно читать ваши пароли и письма, вот он и блокирует?

А вообще, я что-то слышал на тему того, что браузеры иногда используют IPv6 (который никто нормально не поддерживает, и который абсолютно неудачно спроектирован) вместо IPv4. Может, в этом причина?

Во-первых, точный ответ дадут только тесты. Набросайте по-быстрому подобие того, что вы хотите сделать, и проверьте, сколько времени уйдет, например, на создание 100 000 объектов.

Во-вторых, по моим наблюдениям, проблема не столько в времени создания объектов, сколько в вызовах фукнций, они в PHP не очень быстрые. При создании объекта вызывается как минимум конструктор, и создание 20 свойств выльется в вызов 20 функций.

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

Вообще, сложные объектные конструкции лучше реализовывать на языках выроде .NET/Java, а не на скриптовых — там все это будет работать гораздо быстрее.

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

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

Невидимое поле «email» защищает отлично. Еще ожно попробовать проверять наличие яваскрипта. Также можно добавить кнопочку «пожаловаться на спам» для того, что пролезет.

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

Я бы советовал разработчикам вместо этого треша сделать нормальный каталог статей, чтобы большинство статей было доступно в 3-4 клика.

На низком уровне программа, например, на языке Си, компилируется в ассемблерный код, у каждого процессора он свой. Самый популярный процессор — Intel x86, потому советую книги по работе процессора и ассемблеру Intel x86, регистры там, команды, и все такое. Правда, какую именно книгу посоветовать, не знаю.

chunked encoding используется, чтобы сервер мог отдавать ответ по кускам. Если его отключить, то сервер должен сохранить ответ от бекенда в буфер в памяти или на диске и отдавать одним куском. Это менее выгодно в плане производительности.

> Иногда бывают «too many connections».

Так это из-за того, что у вас в конфиге MySQL стоит ограничение, а не из-за каких-то проблем.

Лучше сохранять IP, откуда приходят странные запросы, и банить их.

Волшебные методы — зло. Человек, которому придется отлаживать ваш код, потом вас заживо на кладбище закопает.

Стоит ли кешировать простые выборки (по id) — спорный вопрос, для ненагруженных проектов — не стоит. Кешировать стоит сложные выборки, и в некоторых случаях, куски HTML.

У страниц на разных языках должны быть разные УРЛ

Как вариант — можно создать на месте екзешников гварда и dll плагинов пустые файлы, которые нельзя ни прочесть, ни удалить. Сменить права у инсталлятора вряд ли хватит ума.

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

Надо все же что-то поменять, чтобы HTML не весил 80 мегабайт и там не было 18 000 строк. Человек все равно не станет читать все эти тысячи строк.

Написать демона на Си/Ява/.NET с точки зрения производительности выгоднее, чем мучать БД.

Теоретически можно еще исходники смотреть (но это скучно), в плане того, как обрабатываются входные данные. Можно использовать сканеры SQL inj/XSS. Еще есть тулза от Гугла, skipfish.

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