P.S. «Не нужно оно никому, оно даже не загрузится.» означает, что если модуль не нужен, он не будет грузиться. А не то, что эти модули вообще никому не нужны и никогда не загрузятся. ;]
Нереально крутой плюс Yii — адекватный автор. После первого же указания на небольшую потерю производительности в ActiveRecord, он пошел и запатчил его в новой ветке лично. Хотя я обещал прислать патч. А еще мы скоро туда им зашлем поддержку Шардинга для того же ORM и View на Dwoo с хелперами под рельсы. И все это в виде дополнений. Не нужно оно никому, оно даже не загрузится.
Им бы распиариться чуть-чуть и выдержать наплыв пионэров, которые при такой социальности автора могут быстро там дров наломать. И все будет тип-топ.
Не надо грязи: абстрактно тестировать фреймворки — это все равно, что гоняться на лошадках-скакалках, корректно. Но в объяснительной, непосредственно перед описанием теста по этой самый ссылочке русским английским написано, что это всего-лишь тест bootstrap'а. И вот то, как эффективно фреймворк способен не загружать лишнего протестировать можно. Там же видно какое влияние это оказывает при наличии кэшера.
Акселераторы решают эту проблему без моего участия. Если проблему можно одинаково решить прозрачно для меня и непрозрачно для меня, прозрачное решение всегда лучше.
Ну и я уже молчу что «хоть и какой ценой» может положить конец большинству современных практик, а код без тестов не работает. Никогда.
Опять же, я не писал, что вы плохой. Я писал, что не надо вас поощрять. Такие эксперименты — это прикольно. Только не надо их показывать общественности. Тут сейчас набежит дровосеков, которые так и будут впредь писать свой код. Вы то может и не проанализировали существующие решения достаточно. Но думать явно умеете. И создание правильных решений — просто вопрос опыта и развития. А дровосеки тупо копируют. И это скопируют. А потом появляются всякие NetCat'ы.
Мой любимый язык — ruby. При этом я понимаю где и почему он лучше чем другие. А где хуже. А вы просто мартышка, которая прыгает и кидается какашками. Беспощадно и бессмысленно. Кыш с ветки!
Вы не понимаете почему monkey patching в ruby — это не только хорошо, но и плохо. Читайте кучи тредов про это. А заодно про множественное наследование в C++. Это раз.
Сходите посмотрите сравнение скорости Ruby (а также JRuby и IronRuby) с PHP. Это два.
Почитайте про историю развития языков программирования. Это три.
Самое страшное качество для программиста, который пытается играть роль архитектора — недостаточный анализ поставленных задач. И, как следствие, недостаточный анализ альтернативных решений. Идеи хорошие, верные. Направление категорически безумное. APC, ZO и __autoload решают эти проблемы стандартными способами — это раз.
Файлы хороши еще тем, что они — стандартная входная сущность для миллиона утилит. Кроме того, что человеку пришлось писать свой фреймворк для такого подхода, ему пришлось писать свой редактор кода на JS! Я бы стрелялся не от идеи хранить код в БД, а от идеи писать код в браузере. Реальные пацаны не используют отладчики и консоль? Вы понимаете, что сэкономив микросекунды работы компилятора PHP (забудем про APC на секунду), вы будете писать код, который невозможно будет удобно оптимизировать? И нам этом вы потеряете куда больше производительности.
А еще, загрузка дисковой подсистемы на обработке кода ОЧЕНЬ легко масштабируется и ОЧЕНЬ дешево. А вот СУБД на порядки сложнее. И я говорю не про отдельную систему, а про идею с «универсальным репозиторием кусков кода».
И алаверды, не надо поощрять людей, которые де «мыслят нестандартно». Когда люди выдумывали колесо, наверняка были и треугольные варианты. То, что в 2009 году пришел человек и сказал: «я сделал треугольное колесо!» безумие ровно до тех пор, пока треугольное колесо хотя бы отдаленно не приблизится по качеству к круглому. И вот _тогда и только тогда_ его можно хвалить за нестандартное мышление. А до тех пор — учим матчасть.
Поэтому я не минусую вам карму и не говорю, что ваша статья сливает. Вы всё верно говорите. Я лишь соглашаюсь с одним из ораторов в том, что в ней не только польза. Я считаю, что её и в простой форме можно было сделать лучше. Но вы всё равно проделали хорошую работу ;].
Мил человек, зачем чайникам проектировать базы? Их задача воду на печке кипятить. Мой комментарий не о том, что ваш пост неверно назван. А о том, что такая подача материала в принципе обычно до добра не доводит. Если вы считаете, что прочитав это они начнут читать дальше, вы ошибаетесь. Как минимум нет ссылок.
Если вы про SELECT *, то нужно же головой думать. Я про SELECT foo_id, bar_id, bar_field FROM foo, bar USING (foo_id). Это не грабли, а инструмент, который надо уметь использовать. А вот сервер, неожиданно меняющий своё отношение к обработке SQL мне представить сложно.
На самом деле тут много чего нет. Я бы ещё бил по голове сковородой за такое описание дерева. Деревья они же кучей способов реализуются, хранение parent_id самый простой, но не всегда тот способ, который поможет решить проблему. Поэтому это пошаговая инструкция, которая бы очень подошла к книге "Для Чайников". А пошаговая инструкция там, где нужен полёт мысли (как в любой архитектурной работе) _недопустима_. Это всегда приводит к непробиваемому автоматизму и полному отсутствию мышления о применении результата.
Я бы советовал первичный ключ называть как object_id по аналогии с теми внешними, что будут на него ссылаться. Во-первых существенно мене вероятны разночтения, во-вторых часто удобнее JOIN'ить (часто можно обойтись без алиасов и использовать USING). Есть ещё много мелких удобств при дальнейше работе с этими полями в приложениях.
А за кого мне ещё вас держать? Сверху дали полную раскладку того, _что_ вирус делает. И его полный исходник. Проверяется инпут или нет спросите у чёрного властелина ;]. Уже неделю на хабре буча о проблемах с XSS, а тут вы, герой на белом коне. Пацан, он и есть.
Штуку написал человек, который знает две вещи. JS и HTML. Статей по тому как этого не допустить море. Почитал бы их сначала _ты_, потом сам потестировал. И только следом, если бы решил, что есть что добавить, написал бы статью. Ни ума, ни фантазии, а туда же...
Им бы распиариться чуть-чуть и выдержать наплыв пионэров, которые при такой социальности автора могут быстро там дров наломать. И все будет тип-топ.
Ну и я уже молчу что «хоть и какой ценой» может положить конец большинству современных практик, а код без тестов не работает. Никогда.
Опять же, я не писал, что вы плохой. Я писал, что не надо вас поощрять. Такие эксперименты — это прикольно. Только не надо их показывать общественности. Тут сейчас набежит дровосеков, которые так и будут впредь писать свой код. Вы то может и не проанализировали существующие решения достаточно. Но думать явно умеете. И создание правильных решений — просто вопрос опыта и развития. А дровосеки тупо копируют. И это скопируют. А потом появляются всякие NetCat'ы.
Сходите посмотрите сравнение скорости Ruby (а также JRuby и IronRuby) с PHP. Это два.
Почитайте про историю развития языков программирования. Это три.
Тогда с вами можно будет о чем-то говорить.
Файлы хороши еще тем, что они — стандартная входная сущность для миллиона утилит. Кроме того, что человеку пришлось писать свой фреймворк для такого подхода, ему пришлось писать свой редактор кода на JS! Я бы стрелялся не от идеи хранить код в БД, а от идеи писать код в браузере. Реальные пацаны не используют отладчики и консоль? Вы понимаете, что сэкономив микросекунды работы компилятора PHP (забудем про APC на секунду), вы будете писать код, который невозможно будет удобно оптимизировать? И нам этом вы потеряете куда больше производительности.
А еще, загрузка дисковой подсистемы на обработке кода ОЧЕНЬ легко масштабируется и ОЧЕНЬ дешево. А вот СУБД на порядки сложнее. И я говорю не про отдельную систему, а про идею с «универсальным репозиторием кусков кода».
И алаверды, не надо поощрять людей, которые де «мыслят нестандартно». Когда люди выдумывали колесо, наверняка были и треугольные варианты. То, что в 2009 году пришел человек и сказал: «я сделал треугольное колесо!» безумие ровно до тех пор, пока треугольное колесо хотя бы отдаленно не приблизится по качеству к круглому. И вот _тогда и только тогда_ его можно хвалить за нестандартное мышление. А до тех пор — учим матчасть.