>И который соотвественно вследствие этого является стандартом на хостинге. И в свою очередь породил массу кода которая уже делает все что надо и которой можно спокойно писать экстеншины.

Блажен кто верует. Сейчас вот предстоит гемор по переводу быдлоподелий написанных на пыхе4 на пых5, сами знаете почему, а масса кода которую породила связка быдлокодеров/пыхпых очень сильно избыточна и не нужна, нормальных поделий очень мало (и полагаю их сильно меньше будет, т/е в плане роста пик был пройден и с него сваливают). Давайте просто похороним его, как ошибку эволюции, и водрузим монумент (это для того что бы не забывать как НЕ НАДО делать). Будет правильнее, имхо.

> На чем писать, определяет заказчик.

Может вы никогда и не работали, но обычно заказчику нужен сайт, а не сайт на похапэ. Про похапэ он от силы что-то слышал от Одной Бабки, но что это такое он не знает. Хотя есть, разумеется, и исключения.

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

>PHP это типичный "растущий" язык, не знаю как это по научному.

Зато я знаю, куда он растет. К стене.

>И в настоящий момент PHP нужен не потому что это "настоящщий язык с хвостовой рекурсией в лямбда замыканиях"

Вот-вот, пока не будет хвостовой рекурсии, говорить не о чем :)

>язык написаный под задачу+платформу+среднего_программера.

s/среднего_программера/быдлокодера/

>И который соотвественно вследствие этого является стандартом на хостинге.

VDS рулят, ага.

>И в свою очередь породил массу кода которая уже делает все что надо и которой можно спокойно писать экстеншины.

Эмм... Мсье пробовал найти _рабочий_ (не говорю уже красивый) код среди той кучи де%%ма, написанного на PHP? Почему-то на djangosnippets.org первая-вторая найденная вещь мне подходит, а на phpclasses.net (или как там их, забыл уже) нужно рыться в поделках индусов, чтобы найти календарь, который хоть как-то работает. И потом все равно писать свой велосипед.

>И вот те кто для "быдлостраниц с гастевухой" предлагает жабу с гибернейтом

Чем python не угодил?

Что именно передавать в скрытом поле - решаем мы сами. ViewState - лишь средство автоматической сериализации и десериализации данных в это поле. Надо просто понимать, как это работает, и исопльзовать так как надо. Вас послешвать - так hidden поля вообще не нужны.

>Или вы тоже никогда в коммерческой конторе не работали? :)

Ну если у вас на чем писать - определяет заказчик... Я не знаю даже что ответить, может тогда пусть заказчик и пишет, раз он такой умный ? Пункт два - простите, так я вообще как то ничего кроме дедиков не рассматривал (наверное по глупости), т/е под проект собирается сервак, а то и несколько, никаких шаред.. Пункт пятый плохо совместим с пунктом вторым и первым. В общем что подразумевается под комм. конторой - шарашка по написанию хоумпейджей за 200баксов ?

аналог use strict появился? нет? ф топку!

> А какой будет срок жизни сессии, что делать с открытием страницы в другом окне и как будет работать back никого не волнует.

Ровным счётом никаких проблем с этим нет.

некоторые вещи в PHP6 несомненно радуют:

> opcode cache included in core distribution

а особенно это:

> register_globals will be gone. > magic_quotes will also disappear.

- перестанет работать куча кода написанного быдлокодерами-(обычно)индусами, что есть большой гуд и куча новой работы :)

> ViewState делает запросы контекстно-независимым

Аштойта?

>> ViewState делает запросы контекстно-независимым

>Аштойта?

Наверняка делает запросы независимыми от их создателей-индусов. Этакий искусственный интеллект на .НЕТ :)

> Вас послешвать - так hidden поля вообще не нужны.

Нужны, конечно - они используются для реальной передачи данных в самодельных JS-виджетах. А вот вьюстейт СОВЕРШЕННО не нужен.

>> Ну если у вас на чем писать - определяет заказчик...

Приходит заказ на сайт. Контора рассматривает, эстимэйтит и выдает предварительный vision-документ по реализации данного заказа. Естественно, МЫ определяем, какая технология наиболее подходит для данного проекта, но выдаем также варианты других технологий. И вот из этих вариантов зарубежный (с другими мы не работаем почти) заказчик, как правило, выбирает ПХП-реализацию (или реализацию .NET, если она в данном случае объективно лучше подходит).

>> Пункт два - простите, так я вообще как то ничего кроме дедиков не рассматривал (наверное по глупости), т/е под проект собирается сервак, а то и несколько, никаких шаред..

Естественно, окончательная сдача проекта предусматривает депроймент проекта на дедик заказчика, однако на промежуточных этапах (milestones) многие заказчики требуют (помимо возможности потестить на нашем внешнем серваке) засунуть проект на их тестовый сервак (а часто это - шаред и переубедить заказчика - себе дороже).

>> Пункт пятый плохо совместим с пунктом вторым и первым. В общем что подразумевается под комм. конторой - шарашка по написанию хоумпейджей за 200баксов ?

Подразумевается контора по написанию средних и крупных веб-проектов, средний объем которых от 1500 до 15000 часов. Так что, не надо опускаться до обвинения в быдлокодерстве.

А вот со спецами по RoR высокого уровня действительно трабла. По .NET и PHP не проблема найти не только сеньоров и мидлов, но и людей с сертификатом ZCE (PHP) и соответствующими бумагами от мелкософта, а вот по RoR... Ну, по крайней мере, у нас в Харькове и даже в Киеве (уже пытались). В основном, на собеседование приходят люди, для которых Ruby - не профессия, а Just for Fun.

И вообще, может хватит кричать, что что-то из языков и технологий есть кал, а что-то труЪ. Веб-разработка (как и любая другая) - это бизнес, который создан, чтобы приносить прибыль. И если RoR позволит мне на нем регулярно и прилично зарабатывать (как помогает PHP - 1000-1500 убитых для Харькова и даже Киева это не так уж плохо) - я на него перейду. Даже перебегу (я его попробовал и он мне тоже очень понравился).

Но пока есть только три технологии для Веб, на которых можно рубить бабло: Java (JSP, etc.), .NET (C#, etc.) и PHP.

Так что, выйдет PHP6 - буду рад. Тем более, что несколько действительно быдляцких решений оттуда наконец-то упразднят.

PHP - SUXX

До когда ж сдохнет этот грёбаный PHP.... ууу, шестая версия, а список фич как для багфикс релиза, ну не жесть, а ? Интересно авторам самим не стыдно таким чудом начинать новую ветку ? А теперь по пунктам.

*Улучшена поддержка юникода - покажите мне _нормальный_ язык, где её уже нету.

*Упразднены register_globals, magic_quotes и $HTTP_*_VARS костыли снесли молодцы, а сразу моск не дошёл, чтобы сделать прямо и умно, лучше б с Перла спёрли.

*Выброшена поддержка библиотек GD1 и FreeType1 - избавляемся от багажа, ну что ж очень полезно такое указывать в Changelog.

*safe_mode больше не используется - ищщо одна "фича" от лишнего кол-ва серого вещества.

*Добавлена поддержка 64 битной целой арифметики - ну есть же биндинг для GMP, там multi precision до сколь угодна знаков есть.

*Фигурные скобки больше не используются для доступа к строке по индексу - угу вы ещё операторные скобки на begin end замените, будет суть красноглазая гавнодельфа (хотя заметьте, виновата в оном не дельфа, а те, кто на нём пишут уже сформировали такое впечатление).

> В этой ситуации языки типа пыха рулят немеряно

Совершенно верно, накатал по-бырому, снял бабло и сбежал подальше, чтобы не замочили потом, да :)

>Так что, выйдет PHP6 - буду рад. Тем более, что несколько действительно быдляцких решений оттуда наконец-то упразднят.

Есть такой всемирный закон, это ЗАКОН СОХРАНЕНИЯ ГАВНА.

Вобщем суть такая:

Если в стакан меду добавить ложку гавна то получаем стакан гавна. Если в бочку меда добавить ложку гавна то получим бочку гавна. Если в цестерну меда добавить ложку гавна то получится цестерна гавна.

И так далее. Гавно всегда стремится к бесконечности.

stateless/statefull вам что-нить говорит? Это означает, что HTTP запросы независимы. Это очень удобно. Особенно для AJAX приложений.

VIEWSTATE - это и есть хидден-поле, просто вместо ручного разгребания этих полей при чтении/записи, ASP.NET выполняет автоматическую сериализацию/десериализиацию данных. Не нравится - не используй. Ещё есть такой момент. Объёкты сессии можно хранить на серверной стороне по-разному: в файлах, в БД, в памяти. В памяти, понятно, быстрее всего, но возникают проблемы на многопроцессорных системах. Поэтому приходится переносить хранение сессий, например, в БД. Поэтому активное использование сессий на каждый чих не очень хорошо.

Ещё притензии есть? А теперь с другой стороны: 1. Удобная система серверных контролов (кстати, не нравится - не используй, можно работать на ASP.NET как с PHP и пр. - через теги <% %>) 2. мастер-пейджи 3. Мощный и современный язык разработки 4. Простые в использовании средства разработки AJAX 5. Встроенная role-based система авторизации 6. Стандартные и удобные средства конфигурирования 7. Распространённый хостинг 8. Распространённые средства разработки

Есть что противопоставить?

>По .NET и PHP не проблема найти не только сеньоров и мидлов, но и людей с сертификатом ZCE (PHP) и соответствующими бумагами от мелкософта, а вот по RoR...

Мухаха я плачу. Думал что подтирки от МС нужны только быдлоэникеям, чтоб получить прибавку в 100$ к зарплате... Про сертификаты Zend могу только спросить: кому они вобще нужны?

>> Ещё притензии есть? А теперь с другой стороны:

Никаких претензий. Вот и разработчики феймверка PRADO для PHP 5 того же мнения: там есть серверные контроллы (событийно-управляемые), VIEWSTATE, ролевая авторизация, удобные средства конфигурирования и прочее (сдается мне, что эти челы очень многое сперли из ASP.NET).

В результате получился вполне адекватный фреймверк для разработки крупных и средних проектов. Очень удобный для разработчика, кстати.
А если учесть уже готовую инфраструктуру для написания тест-кейсов и прочие фичи для QA, то можно говорить о фреймверке промышленного уровня (когда до конца допилят - есть там еще неприятные моменты, которые надо самому обходить).

Кстати, о VIEWSTATE. В PRADO на нем построена работа ActiveControls (AJAX-using). Если его выключить - никакого AJAX-а не будет. Пока не решил, хорошо это или плохо, так как работает вполне прилично.

>Ещё притензии есть? А теперь с другой стороны: 1. Удобная система серверных контролов (кстати, не нравится - не используй, можно работать на ASP.NET как с PHP и пр. - через теги <% %>) 2. мастер-пейджи 3. Мощный и современный язык разработки 4. Простые в использовании средства разработки AJAX 5. Встроенная role-based система авторизации 6. Стандартные и удобные средства конфигурирования 7. Распространённый хостинг 8. Распространённые средства разработки

Ты случайно не маркетолог мелкософта? Столько слов, а смысла в них - 0. Все это "стадартно" и "удобно" для кого? Про "соременный" язык, который представляет из себя то, чем Жаба(нет, я не фан Жабы) была 5 лет назад я промолчу...

Он - жертва маркетологов.

Ажаксы, Фижаксы ... кто-нить этим серьзно загружает страницу ?)

Лучший PHP6 - это Python 2.5 ))

>> По .NET и PHP не проблема найти не только сеньоров и мидлов, но и людей с сертификатом ZCE (PHP) и соответствующими бумагами от мелкософта, а вот по RoR...
>> Мухаха я плачу. Думал что подтирки от МС нужны только быдлоэникеям, чтоб получить прибавку в 100$ к зарплате... Про сертификаты Zend могу только спросить: кому они вобще нужны?

Ну, вообще-то, сертификаты от мелких - это прибавка не 100, а 200-400$ к зарплате (зависит от сертификата и общего опыта работы и портфолио выполненных проектов). С сертификатами Zend - та же фигня, только $100-200. Это во-первых.
Во-вторых, если в проектной команде есть certified-разработчики, то заказчик с удовольствием заплатит по большему рейту :). К тому же, как правило, заказчики больших проектов приезжают к нам знакомиться с командами, т. с., "на месте" и сертификаты на стенах их впечатляют и обнадеживают.
Ну, и в-третьих, конечно же, никто не будет слепо доверять человеку с сертификатом. Когда ты приходишь устраиваться на работу или тебя представляют очередному заказчику, твой самый железный аргумент - опыт работы и портфолио проектов.

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

Для разработчиков, очевидно.

Кстати, в жабе 5 лет наза были полноценные дженерики? Вот уж не знал...

>PHP обречён. Чем сложнее и объёмнее сайт (веб приложение), тем меньше смысла в использовании PHP. Реально ASP.NET 2 сейчас - самый мощный инструмент разработки серьёзных веб-приложений.

Ну зачем же такие опечатки допускать, правильно было:

PHP обречён. Чем сложнее и объёмнее сайт (веб приложение), тем меньше смысла в использовании PHP. Реально RoR сейчас - самый мощный инструмент разработки серьёзных веб-приложений.

>Лучший PHP6 - это Python 2.5 ))

4.2

Лучший PHP6 - это Perl 6

>Аргементы будут? Что касается ViewState, какие альтернативы? Какие есть варианты передавать данные между страницами? Через сессию?

Вьюстейт посылает обычный POST запрос, соответственно работает он только при сабмите формы. В результате имеет ограниченное применение (не используется в навигации например). То что ссылки обычные его передают - это вас майкрософт обманывает - там простейший скрипт (кстати, в его исходном коде вместо нормального реплейса зачем-то сплит-джоин используется, индусы видимо так о себе память решили оставить...). Следовательно - все описанное легко и непринужденно заменяется AJAX-ом.

Учите матчасть. Хотя дотнетчикам это сложно дается... Они лучше купять кучу дорогого софта и будут создавать блевотные сайты где каждая ссылка делает перезагрузку страницы с отправкой 10килобайтного вьюстейта.

Если бы меня для внутрикорпоративных вебморд к апликухам пересадили с Oracle HTMLDB на PHP, я бы уволился.

>1. RoR мало распространен и почти не известен реальному заказчику.

В европе уже не так.

>2. RoR не предоставляется хостерами даже на VIP-тарифных планах - только на выделенных серверах.

Что за сферические хостеры в ваакуме? Даже в России есть множество shared хостингов для RoR. А в европе и США у каждого второго.

>3. На чем писать, определяет заказчик.

Если заказчик даже не знает какие есть варианты, пусть лучше не выбирает - для этого есть специальные люди, которые неплохие деньги зарабатывают и в курсе всех событий. А если заказчик с утра по быдлящику увидит рекламу VasyaPupkin.Framework.NET то сразу на него переписывать заставит? :))

>4. Попробуй найти специалистов уровня Senior Developer или хотя бы Middle Developer для RoR.

>5. Попробуй найди QA-инженеров (а не дымных тестеров-студентов), которые будут работать с RoR (писать тест-кейсы, проводить автоматизированное тестирование).

Для PHP таких даже не существует -- там одни быдлокодеры.

PS. Не видел ни одного человека кто с RoR ушел на дотнет. А обратная тенденция наблюдается. http://scobleizer.com/2005/11/01/ross-doesnt-trust-microsofts-approach-to-web/ (боян)

>Вы дебил. Незнакомы с технологией, так молчите.

Ну давай, дотнетодебилушка, расскажи, чем обоснован здесь split-join (вместо replace), и что мешает на RoR написать фильтр для контроллера, который будет кодировать/раскодировать вьюстейты, если нужно такое поведение (повторюсь, с AJAX это все _НЕ_НУЖНО_)

	function __doPostBack(eventTarget, eventArgument) {
		var theform;
		if (window.navigator.appName.toLowerCase().indexOf("microsoft") > -1) {
			theform = document.Form;
		}
		else {
			theform = document.forms["Form"];
		}
		theform.__EVENTTARGET.value = eventTarget.split("$").join(":");
		theform.__EVENTARGUMENT.value = eventArgument;
		theform.submit();
	}

function __doPostBack(eventTarget, eventArgument) { if (!theForm.onsubmit || (theForm.onsubmit() != false)) { theForm.__EVENTTARGET.value = eventTarget; theForm.__EVENTARGUMENT.value = eventArgument; theForm.submit(); } }

Хм, где здесь split, если вы про этот скрипт?

Суть в том, что у страницы есть состояние, его можно хранить на сервере, а можно передавать клиенту. Сессии используют первый вариант, ViewState - второй. У каждого из подходов есть плюсы и минусы и свои применения.

Что касается дорогого софта - SQLEXPRESS более чем достаточно для большинства сайтов, Web Developer Studio Express беслатен.

Каждая ссылка делает перезагрузку всей страницы везде (где не использован аякс), независими от средств разработки, это особенность HTTP.

ViewState уже уменьшился с 20К до 10К, это радует :)

Эээ а дженерики в .нет-жаба это просто сахар. Никакой реальной пользы, в отличиет от темплейтов, в них нет, но вот зачем-то кривой синтаксис из цпп спиздили. Нах это все(да, я в курсе, что без них была куча кастов из Object, но это не повод тащить каждую кривую херь из цпп)? Перестань быть жертвой маркетологов и пойми, что добавление джненериков в .НЕТ2 - это признание того, что 'то быдлоподелие - defective by design, а не повод для гордости.

>и как будет работать back никого не волнует.

О, да. "Отправить данные формы повторно? ДА/НЕТ", к черту такой back.. Обычный юзер голову сломает и убежит в панике с такого сайта. И выработается рефлекс - ".aspx, Back button - не нажимать"

>20К - чего ж вы туда напихали, датасет?

Я не он но в быдлоконторе где работал было также. Никаких датасетов, просто формы большие. В несколько степов.

>Естественно, МЫ определяем, какая технология наиболее подходит для данного проекта, но выдаем также варианты других технологий. И вот из этих вариантов зарубежный (с другими мы не работаем почти) заказчик, как правило, выбирает ПХП-реализацию (или реализацию .NET, если она в данном случае объективно лучше подходит)

Если бы вы правильно указали цену и сроки то заказчик выбирал бы Django или RoR. Проблема скорее в том что вы ему даете только список из php,.net,java.

>Естественно, окончательная сдача проекта предусматривает депроймент проекта на дедик заказчика, однако на промежуточных этапах (milestones) многие заказчики требуют (помимо возможности потестить на нашем внешнем серваке) засунуть проект на их тестовый сервак (а часто это - шаред и переубедить заказчика - себе дороже).

У себя поднять рука не поднимается? Опять же есть МНОЖЕСТВО RoR хостингов за 15$ в месяц.

>, но и людей с сертификатом ZCE (PHP) и соответствующими бумагами от мелкософта,

Видели таких, не дай бог с ними работать. За пределами visual studio ничего не знают, не говоря уже о javascript и firebug...

Далее вообще унылый бред, не надо списывать свои проблемы и проблемы своей страны/города на фреймворк. Поглядите на мир и нормальных заказчиков.

> theform.__EVENTTARGET.value = eventTarget.split("$").join(":");

я так полагаю - это для наглядности, плюс возможно стоимость одного запуска регексп обработчика (replace) больше стоимости связки split/join. Хотя в данном примере это не критично.

>Ещё притензии есть? А теперь с другой стороны: 1. Удобная система серверных контролов (кстати, не нравится - не используй, можно работать на ASP.NET как с PHP и пр. - через теги <% %>)

Под RoR много систем шаблонов, все возможности есть. Когда надо - используются сильно, когда не сильно надо то используются слабо.

>2. мастер-пейджи

RoR: layouts, появились раньше чем мастер пейджи, суть аналогична.

>3. Мощный и современный язык разработки

Ruby мощнее и современнее. Хотя тенденция в C# - копирование всего с Ruby. C# в роли догоняющего.

>4. Простые в использовании средства разработки AJAX

Ну тут RoR был первым и больше всех это пиарил, только ленивый не слышал. Работал только с ASP.NET1.1 - никаких там простых средств нет, использовал prototype.js, подобное видел на множестве ASP.NET-овых сайтах. Стандарт де-факто уже )

>5. Встроенная role-based система авторизации

acts_as_authenticated

>6. Стандартные и удобные средства конфигурирования

./config, с возможностью программирования в конфиге. Роуты, которые в Rails были изначально, в ASP.NET появятся только в MVC-Framework.NET, который очень уж на Rails похож, но это другая история..

> 7. Распространённый хостинг

На PHP более распространенный. Нормальные хостинги поддерживают и Rails, хотя на чтобы дотнет нормально работал обычно покупают VPS или DPS, на таких условиях и Rails можно поставить

>8. Распространённые средства разработки

Одна штука, дорогая, тормозная, не кроссплатформенная. Под Rails больше, и в сумме они более распространены (Eclipse, Netbeans) и много легких, например любимый многими TextMate и Emacs.

А это распространенное средство разработки работает только под OS без нормального эмулятора терминала, да и вообще под которой невозможно нормально разрабатывать, в виду ее убогости и ущербности. И svn там не поддерживается, или вы убогий VSS используете, который при коммите более 150 файлов говорит "Возможно некоторые данные будут утеряны"??

>> 4. Попробуй найти специалистов уровня Senior Developer или хотя бы Middle Developer для RoR.
>> 5. Попробуй найди QA-инженеров (а не дымных тестеров-студентов), которые будут работать с RoR (писать тест-кейсы, проводить автоматизированное тестирование).

>> Для PHP таких даже не существует -- там одни быдлокодеры.

Ну зачем говорить заведомую чушь?
Да, вы правы, быдлокодеров - море, к сожалению. Чтобы найти одного крепкого профессионала для PHP, нужно провести примерно 50 или более собеседований, при которых просеять кучу всяких личностей, из которых примерно будут 5 вполне адекватных джуниоров, которым надо еще набрать опыта, а остальные, конечно, халявщики или вообще талпаёпы (иногда такое видишь и слышишь на собеседовании - еле сдерживаешься, чтобы не заржать).
Однако, это совсем не значит, что грамотных профессионалов для ПХП нет в природе. Приложив достаточные усилия, можно собрать хорошую команду или несколько.

Для Питона и RoR ситуация тяжелее. И не потому, что язык или технология хуже. Просто людей, профессионально ими владеющих, объективно меньше. Мы, например, нашли всего двух. Для проектной команды это маловато. Поручать всего двум людям проект в 5000-10000 часов с жестко фиксированными сроками - это самоубийство. В таких ситуациях всегда нужно думать не о программировании, а о бизнесе. А для бизнеса вреден неоправданный или слишком высокий риск.

>> 3. На чем писать, определяет заказчик.
>>Если заказчик даже не знает какие есть варианты, пусть лучше не выбирает - для этого есть специальные люди, которые неплохие деньги зарабатывают и в курсе всех событий.

Абсолютно верно. И у нас такие люди работают - они готовят вижны и эстимэйты, в которых и дают варианты. Но заказчики, как правило (особенно англикосы с амерами), нанимают сторонних экспертов или привлекают собственных, которые и выбирают один из наших вариантов или предлагают (иногда - почти безоговорочно) свой.

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

К тому же, успех или провал проекта зависит от правильности проектного менеджмента и профессионализма и сплоченности команды разработчиков в гораздо большей степени, чем от используемой технологии. Исключения составляют случаи, когда выбранная технология СОВЕРШЕННО не подходит для данного случая.

>scores[killer] = scores.get('killer',0) + 1

Спасибо, всё ещё громоздко, но уже лучше :)

>Хм, где здесь split, если вы про этот скрипт?

Офигеть, уже поправили, всего лишь за 3 года.

>Суть в том, что у страницы есть состояние, его можно хранить на сервере, а можно передавать клиенту. Сессии используют первый вариант, ViewState - второй. У каждого из подходов есть плюсы и минусы и свои применения.

Как неотрендеренные контролы перенести в сессию _СТАНДАРТНЫМИ_ средствами дотнета? Оно насильно пихает их во вьюстейт.

>Что касается дорогого софта - SQLEXPRESS более чем достаточно для большинства сайтов, Web Developer Studio Express беслатен.

Не для коммерческого использования ведь..

>Каждая ссылка делает перезагрузку всей страницы везде (где не использован аякс), независими от средств разработки, это особенность HTTP.

Чтобы выжил вьюстейт надо делать POST запрос. Обычно это делают в формах. Т.е. вьюстейт используется для сохранения состояния в пределах одной последовательности POST запросов. Обычно эта последовательность хорошо заменяема на последовательность AJAX запросов без перезагрузки страницы, при этом данные копятся на клиенте (в javascript переменных), или в сессии на сервере. Последнее лучше тем что при возвращении на страницу не придется заполнять уже заполненные шаги формы, в то время как вьюстейт благополучно скончается в кеше браузера.

Вобщем вьюстейт нужен только там, где эффективен AJAX, но поскольку проще ввести AJAX то вьюстейт не нужен. Или вы можете объяснить, зачем мне Hidden поле на 20кб, если я не буду сабмитить форму? Это просто бесполезная трата трафика и памяти браузера.

>я так полагаю - это для наглядности, плюс возможно стоимость одного запуска регексп обработчика (replace) больше стоимости связки split/join. Хотя в данном примере это не критично.

Да что ты говоришь? реплейс можно делать не по регекспу, а по строкам. Сплит-джоин используют в 2 раза больше памяти(или даже в 3, если учесть ссылки в массивах). Читается это ничуть не лучше чем .replace("$",":",'g').

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

>Если в цестерну меда добавить ложку гавна то

... то ты ничего не заметишь.

>Абсолютно верно. И у нас такие люди работают - они готовят вижны и эстимэйты, в которых и дают варианты. Но заказчики, как правило (особенно англикосы с амерами), нанимают сторонних экспертов или привлекают собственных, которые и выбирают один из наших вариантов или предлагают (иногда - почти безоговорочно) свой.

Как я уже сказал, ваш заказчик наверняка выбирает только из php, java, .net, как вы уже сказали питон вы ему предложить не можете. Так что выбор заказчика не аргумент. Насчет людей в руби и питоне соглашусь, сейчас их не хватает, и это еще один повод изучить эти языки и сопутствующие им web-фреймворки.

>1. RoR мало распространен и почти не известен реальному заказчику.

Заказчика такие вещи перестают волновать, когда срок разработки уменьшается раза в 2-3. (headhunter.ru -> search -> rails)


>2. RoR не предоставляется хостерами даже на VIP-тарифных планах -
только на выделенных серверах.

Сейчас VPS хостинг начинается от 500р в месяц. Это не дорого.


>3. На чем писать, определяет заказчик.

У кого как ,-) В случае с профессиональными заказчиком и разработчиком такие вопросы встают только в случае интеграции в существующую инфраструктуру клиента.


>4. Попробуй найти специалистов уровня Senior Developer или хотя бы
Middle Developer для RoR.

http://groups.google.com/group/ror2ru -- почти 700 чел, в working with rails меньше, но тоже есть (http://workingwithrails.com/browse/people/country/Russia)

>5. Попробуй найди QA-инженеров (а не дымных тестеров-студентов),
которые будут работать с RoR (писать тест-кейсы, проводить
автоматизированное тестирование).

Тесты в рор пишет программист, их потом просто надо проверить.

И вот такой ещё момент... Как сделать аналог

@$counts[$killer][$victim]++;

?

Вариант

counts[killer][victim] = counts.setdefault(killer, {}).get(victim, 0) + 1

очень уж громоздкий :)

Может стоит понять что в питоне просто более строгий контроль типов? Наверное это лучше чем написать @$counts[$killer][$vctim]++; и долго искать ошибку?

>Реально ASP.NET 2 сейчас - самый мощный инструмент разработки серьёзных веб-приложений.

Не знаю не знаю. В конторе появилось сейчас дофига больших дотнетовски проектов. Наняли профессионалов. Открыл для себя класс ошибок которых в природе встречатся не может но я так понимаю под MS они типичны. Звучат они приблизительно: "значения поля не передается при сабмите", "вставляем так - работает, так - на работает". Это о данных на страницу. Такого рода проблемы _в вебе_ говорит мне о том что у ASP.NET в консерватории что-то не так.

> Да что ты говоришь? реплейс можно делать не по регекспу, а по строкам. Сплит-джоин используют в 2 раза больше памяти(или даже в 3, если учесть ссылки в массивах). Читается это ничуть не лучше чем .replace("$",":",'g').

не стоит так волноватся и кричать. Вы настолько знакомы с принципам функционирования регексп-обработчика, что можете утверждать что простой split/join будет менее эффективен ? Моя практика показывает обратное. Даже просто компиляция регулярного выражения довольно затратная часть.

P.S. В синтаксисе .replace первый аргумент - регулярное выражение, а не строка. Впрочем, мы о каком языке программирования говорим ?

>Спасибо, всё ещё громоздко, но уже лучше :)

громоздко только в том случае, если нас не волнует - есть ли ключ вообще и соответствует ли тип возвращаемого значения по умолчанию ожидаемому типу.

>обычно заказчику нужен сайт, а не сайт на похапэ

Ерунда. Язык исполнения, используемая БД, веб-сервер, обязательно указываются в техзадании. И это вполне оправдано.

>скажем дружно, на**й такую контору

В указанном направлении обычно идёт гламурный программер. Вы по-видимому имели мало опыта работы с серьёзными заказчиками, со "взрослым" циклом разработки.

> Вы по-видимому имели мало опыта работы с серьёзными заказчиками, со "взрослым" циклом разработки.

Взрослые заказчики сайтов на пыхе не заказывают.