Владимир Чернышев

cgiirc, например.
Хороших веб-интерфейсов для джаббер-конференций пока что маловато.

Думаю, Вам сюда.

возможно вам подойдет Single table inheritance
Вопрос на StackOverflow

Для друпала также придется писать кучу модулей, компонентов и т.д.

Битрикс — достатчно неплохая система, на мой взгляд. По крайней мере когда я работал над разработкой портала
www.komandirovka.ru/ — остался доволен. Возможно, мне просто повезло попасть в команду с хорошими программистами с большим опытом разработки под битрикс, поэтому никаких особых проблем и костылей я не увидел.

Зато очень понравились «Инфоблоки 2.0» — достаточно мощный и при этом простой инструмент для работы с информацией, в частности на командировке лично я делал модули фотогалерии и сувениров с использованием инфоблоков. Удобно, что не нужно парится с админкой — при использовании инфоблоков битрикс делает практически всю работу по админке за программиста.

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

Т.е. в вашем случае нужно не давать ему статьи и отзывы вида «друпал хорошая система, а битрикс — плохая», а скорее представить ему конкретные цифры, например:
— битрик стоит 100 000 рублей, друпал — бесплатная
— в случае с битриксом мы сможем приступить к работе сразу, с друпалом — через 2 недели обучения разработчиков (з/п одного разработчика в месяц предположим 100 000, 2 недели — 50 тысяч, умножаем на количество разработчиков)
— на друпале мы сможем разработать этот проект в полтора раза быстрее чем на битриксе, таким образом мы сэкономим, например, месяц работы команды разработчиков, умножаем на зарплату и количество разработчиков.

Потом подбиваем бабки (предположим, что у нас работает 3 программиста)
100 000 экономия на битриксе, 300 000 экономия за месяц разработки, 150 тысяч затрат на обучение. Итого — этот проект получится реализовать на 2 недели раньше и с экономией 250 000 рублей.

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

Если же вы не уверены в том, что переход на друпал принесет реальный эффект — то лучше ИМХО продолжать разработку на битриксе и совершенствовать знание битрикса, чтобы то, что «битрикс не может поддерживать все требуемые от портала задачи без написания своих модулей, компонетов» — не являлось проблемой.

Потому что врядли под друпал будут все необходимые модули и компоненты :) А если они уже 100% есть и не требуют модификаций — то нет проблем, я уже выше описывал как это аргументировать начальству.

Часто течет при утечках в экстеншнах.

Мне кажется больше будет смысла и эффекта (и кармы) если будет вы хотя бы примерно опишете свои мысли по этому. Как пример можно просто выложить часть топика — если это интересно — мне кажется карма будет.

>>ZF || YII || Рельсы ||?
Посмотрите в сторону Symfony2
для БД/XML маппинга Docrine 2.1
для тестинга PhpUnit/Bedhat/Mink

По идеологии очень близко к Rails. Все то, что вам понравилось в rails, возможно, вы найдете в Symfony.
Rails 3 — вообще красота. Очень советую.

ZF по сравнению с Symfony по хуже… Особенно если читать сорцы ZF. Не знаю, чего они курили, но местами просто жесть… ИХМО, не гибко, не удобно.

YII — касался косвенно пару раз, ИХМО, лучше чем ZF.

В ZF есть хорошие и удобные компоненты, например, Zend_Soap, которые сильно упрощают жизнь. Так что в сторону ZF смотреть можно, но Zend_Application, ИХМО, ужасен.

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

Джангу юзают например в том же Яндексе.
На субботнике в екб они делали доклад в котором раскрывается почему именно джанга

Обезописать себя никакими договорами\письмами\расписками не выйдет. Если вы установили и вас поймали за руку — вы виноваты, и точка. Ставьте им триальные версии.

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

Только благодаря вопросу заметил изменения.
И правда, интересно.

ИМХО учебники стОит писать на основе своего реального опыта, о наличии которого я сомневаюсь в твоем возрасте(без обид).

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

Я на ваш вопрос ответа не знаю, его знаете только вы (просто ещё не осознали). Просто подумайте:
1. Чем ваш учебник будет отличаться от существующих?
2. Готовы ли вы потратить кучу времени на его написание, вычитку, подготовку иллюстраций, вёрстку?
3. Вы уверены, что не забросите это? Недоделанная работа — нехорошая вещь: силы вложите, а результата нет.

А зачем?

Платежная система, список услуг, последняя активность, микроплатеж, список IP адресов, с которых клиент заходил (или, как начальная проверка — список провайдеров) — NAT не избавляет клиента от внешнего IP адреса, а вероятность того, что поломал-ломает его сосед — минимальна.
Социальные профили с совпадающей информацией, альтернативная почта. Если это игра — то содержимое инвентаря, последние личные сообщения и прочее.

С isset абсалютно верно. Но я бы не стал называть это «чтение», т.к. isset — это специальная конструкция языка. Если вы попытаетесь спросить индекс не-массива, то:

unset($a);
echo $a['a']['b']['c']; // будет warning
echo $a['a']; // тоже будет warning
isset($a['a']['b']['c']); // не будет warning'а

С записью тоже есть нюансы. Если переменная (даже если это элемент массива) не установлена, то её можно неявно использовать как массив. Но если она установлена и не является массивом, то могут быть проблемы:

<?php
unset($a);
$a['a'] = 'a'; // это ок
$a['b'] = 1; // это ок
$a['a'][0] = 'b'; // перезапишет первый символ строки!!!
$a['b'][0] = 'b'; // будет notice, про обращение к скаляру, как к массиву
unset($a);
$a['a']['b']['c']['d'] = 'str'; // тоже ок
$с = new SomeClass;
$с[0] = 'c'; // Если класс имплементил ArrayAccess интерфейс, то вызовется метод offsetGet,
             // иначе Fatal error

Так что если не уверены, что содержится в переменной или элементе массива, то лучше явно проинициализируйте массив.

Проблема заключается в следующем(для удобства я сокращу ваше длинное или до одного варианта):
^(?:(?!00).)*$
Проверка (?! ...) находится внутри группы со знаком *, то есть выполняется каждый раз когда reg Exp engine переходит к следующему символу. Для вашего случая данную проверку надо вынести за группу(а сами скобки группы вообще убрать — так как в ней останется только 1 элемент):
^(?!00).*$

Зависит от способа кражи — будь то XSS — виноват разработчик, а если пользователь вводит в адресную строку чудо-скрипты, то сам виноват.

не совсем понятно зачем нужен имено JSON POST если все параметры умещаются в URI, то есть обьектов нет или сериализация примитивная. Я бы просто сделал GET и POST.

Единообразие GET и POST делать через $_REQUEST, ежели все таки JSON POST то просто $_GET поэлементно запизиваем в обьект, как если бы он был из JSON POST, и дальше его парсим.

Похоже про кэширование не совсем корректно написано в вопросе. nginx отлично кэширует GET, надо просто ключом поставить что то типа
proxy_cache_key "$request_method|$http_if_modified_since|$http_if_none_match|$host|$request_uri";
а POST как раз некэшируется и вроде как и не надо. Так что проблема вроде как решается автоматом.

Очень нужны переводы полезных технических статей. Не тратьте время на чехлы для айпада.