Мы говорим о дефейсе как о явлении или о проблеме пиратства и РИАА конкретно? :) Если о первом - Бог с ним, если со вторым - устал читать уже в рсс лентах и на блогах об основании очередной партии за пиратство, о том, что какой-то политик пояснил, что есть кражи, а есть копирование и РИАА не права, о том, что РИАА уже якобы ликвидируют в связи с сокращением ЕМИ...Надоело порядком :)
Здесь разговор о проблеме в целом, а не о конкретном взломе :) Дефейсы майкрософта, признания в том, что у них фрибсд стоял и т.п. не мешали юзать бедным людям пиратскую винду. А безголовое (в значении отсутсвия лидера) опенсорс-сообщество могло только кричать. Реально никто никому не мешал. А здесь все по-другому...
В этом плане я не часть мейнстрима, у меня другие взгляды, другое образование. А "ок" будет когда работать вообще не придется, все будут делать нанятые менеджеры, а состояние при этом будет расти :) Дауншифтинг в моем понимании (может конечно и не совсем так) будет тогда, когда я буду распределять прибыль в другие сферы, заниматься чем-то другим, пока основные без вмешательноства приносят доход :)
В общем, толку, что мы тут рассуждаем как тривиальные вещи делать через одно место? Меня не очень устраивает вариант как минимум поиска решения по тому вопросу, который вообще не требует задумываться.
У меня была проблема следующего плана:
preg_replace/str_ireplace/mb_eregi_replace использовал, чтобы произвести замену "ПрИмЕрНо ВоТ тАкОгО тЕксТа" на "примерно вот такой" с тегами, все в utf, не получилось.
Эм, Вы понимаете какая тут штука, mbstring - расширение, это раз.
Я недавно закончил проект, разрабатывался он полностью и везде на utf8, именно по этому поводу есть ряд замечаний. Начну с того, что проект был небольшой, но столкнулся я со следующими проблемами:
- preg_match (это не mbstring), поддерживает utf, но не полностью, и я как раз попал в этот вот кусочек "неподдерживаемости".
- само расширение не позволяет работать с регулярками, кроме как с posix-совместимыми, которые жутко как медленны.
- есть строковые функции (нативные), которые utf не поддерживают вообще, и в mbstring их, соответственно нет. (точно не скажу, но по-моему strstr/stristr).
Нормальная поддержка - дефолтный utf8 для всего, что делается на этом языке + нехилое расширение для работы со всеми возможными кодировками (не какая-то перезагрузка в существующем расширении, а что-то более удобное).
Бывает и так, здесь всего-лишь контекст, и он соблюден.
Уже сейчас людям не нравится тот факт, что при получении почты они смотрят контекстную рекламу со слов полученного письма. К чему я веду - чтобы не было таких вот недоразумений придется прикрутить АИ модули, а это легко может быть воспринято как какая-то попытка слежки. Да и то, до конца мы не знаем что там и как с контекстом...
Это уже от каждого отдельного товарища зависит.
Мне достаточно prototype, чтобы сделать
function validateLogin(login) {
new Ajax.Updater(...)
}
или сделать вообще validate, а скрипт-обработчик будет определять по пришедшему к нему значению что требуется...Всего одной оберткой.
Просто mootools мне больше понравился, это js-фреймворк, а грузить сторону пользователя глупыми вещами, вроде валиадации там - бред, юзер отключит жс и поломает вам нафиг сайт...по-другому только реализовать логику валидации 2 раза, в жс для удобства юзера и в скрипте, для спокойного сна кодера.
И никто не говорит о том, чтобы фреймворк позволял делать
$obj = new Site();
Зенд - бред, мне нафиг не нужен их Ajax реализация, нафиг не нужна их авторизация банальная, если я могу то же самое сделать в .htaccess, нафиг не нужен переписанный PEAR::DB, есть вещи, которые можно сделать ВНЕ PHP, а это значит, что в нем они совершенно не нужны, к тому же в таком количестве, к тому же такие беспомощные. Остальное я смотрел и мне не понравилось.
Для новичков это ОЧЕНЬ полезно, а то мастеров, пишущих "говнокод" сейчас достаточно, сам иногда велосипеды писал, пока к паттернам не приучили, это поможет и в планировании, конструировании будущего приложения.
Зенд ОЧЕНЬ туп, там фактический тот же PEAR подход, многие вещи просто переписаны под логику этого фреймворка, куча ненужных вещей. Шаблонные движки по моему мнению вообще не нужны, особенно такие, как пресловутый смарти, язык в языке, по-другому не скажешь. Фреймворк должен оптимизировать рутину, типа обработки форм, их вывода, ошибок и т.п., с чем каждый раз приходится сталкиваться. Для асинхронных запросов я использую в данный момент prototype, но думаю перейти на mootools, т.к. функционал в разы выше и круче.
Ну а причем здесь index.php?
Ты каждый раз будешь его инклудить?
Есть какой-либо config.php, в котором хранятся настройки, но require_once 'config.php', в котором будет написано ваше dirname(__FILE__); повлечет за собой то, что рут патом будет считаться текущий каталог...а это конец :)
Поэтому я знаю что пишу, т.к. неоднократно сталкивался с такой фигней :)
В общем, толку, что мы тут рассуждаем как тривиальные вещи делать через одно место? Меня не очень устраивает вариант как минимум поиска решения по тому вопросу, который вообще не требует задумываться.
preg_replace/str_ireplace/mb_eregi_replace использовал, чтобы произвести замену "ПрИмЕрНо ВоТ тАкОгО тЕксТа" на "примерно вот такой" с тегами, все в utf, не получилось.
Я недавно закончил проект, разрабатывался он полностью и везде на utf8, именно по этому поводу есть ряд замечаний. Начну с того, что проект был небольшой, но столкнулся я со следующими проблемами:
- preg_match (это не mbstring), поддерживает utf, но не полностью, и я как раз попал в этот вот кусочек "неподдерживаемости".
- само расширение не позволяет работать с регулярками, кроме как с posix-совместимыми, которые жутко как медленны.
- есть строковые функции (нативные), которые utf не поддерживают вообще, и в mbstring их, соответственно нет. (точно не скажу, но по-моему strstr/stristr).
Нормальная поддержка - дефолтный utf8 для всего, что делается на этом языке + нехилое расширение для работы со всеми возможными кодировками (не какая-то перезагрузка в существующем расширении, а что-то более удобное).
НО: хрен я буду использовать кириллицу, пока в том же php не будет нормальной поддержки юникода (пока она не будет native, как планируется в php6).
Уже сейчас людям не нравится тот факт, что при получении почты они смотрят контекстную рекламу со слов полученного письма. К чему я веду - чтобы не было таких вот недоразумений придется прикрутить АИ модули, а это легко может быть воспринято как какая-то попытка слежки. Да и то, до конца мы не знаем что там и как с контекстом...
дальше не читал :)
Мне достаточно prototype, чтобы сделать
function validateLogin(login) {
new Ajax.Updater(...)
}
или сделать вообще validate, а скрипт-обработчик будет определять по пришедшему к нему значению что требуется...Всего одной оберткой.
Просто mootools мне больше понравился, это js-фреймворк, а грузить сторону пользователя глупыми вещами, вроде валиадации там - бред, юзер отключит жс и поломает вам нафиг сайт...по-другому только реализовать логику валидации 2 раза, в жс для удобства юзера и в скрипте, для спокойного сна кодера.
И никто не говорит о том, чтобы фреймворк позволял делать
$obj = new Site();
Зенд - бред, мне нафиг не нужен их Ajax реализация, нафиг не нужна их авторизация банальная, если я могу то же самое сделать в .htaccess, нафиг не нужен переписанный PEAR::DB, есть вещи, которые можно сделать ВНЕ PHP, а это значит, что в нем они совершенно не нужны, к тому же в таком количестве, к тому же такие беспомощные. Остальное я смотрел и мне не понравилось.
И питон мне не нравится :)
Ты каждый раз будешь его инклудить?
Есть какой-либо config.php, в котором хранятся настройки, но require_once 'config.php', в котором будет написано ваше dirname(__FILE__); повлечет за собой то, что рут патом будет считаться текущий каталог...а это конец :)
Поэтому я знаю что пишу, т.к. неоднократно сталкивался с такой фигней :)