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

Сам по себе ORM, именно как maaping, в крупных проектах нужен как раз очень сильно. Опишу здесь свой опыт. Если понравится кому, может и статью потом.

Итак.
Представьте себе — у меня есть очень крупная система, и есть в ней таблица orders, в ней скажем, 50 колонок (на самом деле у нас 150, ну да ладно. Нормализаторы, молчать! Про нормальные формы я тоже знаю). И вот надо значит вам выбрать один ордер и показать его на экране. Допустим, вы пишете селект, неважно. Дальше что делать, в промежуточном слое? Вы не же вызываете хранимую процедуру (запрос) напрямую с, скажем, JSP страницы (я надеюсь), вам все равно надо получить данные и передать их как-то.
Так что, передавать их в виде массива, ArrayList-a, ассоциативного массива имя колонки/значения? Ну так дико громоздно, неудобно, и очень легко ошибиться. А если вам надо несколько ордеров, тогда что, создавать вложенные коллекции для конвертации результатов? Неудобно же.

Потому, очевидно, нам нужен объект Order, имеющий все нужные property, и нужен код, который умеет конвертировать результаты скл запрос в эти объекты (или коллекцию этих объектов).

Далее, очевидно, что писать руками _все_ запросы трудно и нудно, легко ошибиться, т.к. в Java они будут представляться в коде в виде строк (а значит, никакой статической типизации и compile-time проверок и прочее и прочее), и их надо держать либо в Java коде (если они мелкие), либо, если побольше, выносить в отдельные XML файлы.

В общем, ORM в больших проектах нужен для упрощения рутинной части. Без него — никуда :)

Безусловно, обойтись ТОЛЬКО ORM не получится. Есть у нас масса мест, где сложная логика написана в хранимых процедурах в 500-1000 строк на PL/SQL, написанная через ORM /Java она бы занимала в 10 раз больше и работала в 2 раза медленнее (при этом, она была бы еще и менее понятная, т.к. есть такая логика, которые в терминах реляционной алгебры описывается куда проще, чем в терминах ООП :), следовательно ложится на ORM со скрипом). Сколько нибудь сложные запросы с подзапросами, юнионами, хитрыми джойнами тоже писать через чистый ORM громоздко. Оптимизировать запросы, работающими в таблицах где, хотя бы, несколько сотен миллионов записей, без доступа к планам SQL оптимизатора и статистики/средствам мониторинга уровня СУБД тоже крайне сложно. Так что без SQL тоже — никуда :)

Зачем автору CMS?

Нужен простой сайт, в котором будет несколько страниц и столько же кнопок для перемещения между этими страницами.

Подойдет любой WYSIWYG-редактор. Самый простенький — Kompozer.

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

Под Java есть отличная библиотека которая подойдет для загрузки удаленных страниц — Apache Httpclient.
hc.apache.org/httpcomponents-client-ga/examples.html

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

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

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

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

А почему бы не воспользоваться какой-нибудь cms, где уже все написано?
Я свои магазины делаю на cmsmadesimple.org попутно дописывая нужные мне модули, или переписываю имеющиеся. Очень удобная, простая, легкая, изящная и сеодружественная cms на мой взгляд.

Если вы расчитываете на рост и развитие своего проекта то однозначно PHP.

Потому что если для PHP вы можете потом найти (само собой, за дорого) пару-тройку действительно опытных разработчиков у которых за плечами 5-10 лет реальной веб-разработки.

То насчет опытных разработчиков Python — вы много можете назвать действительно опытных? Т.е. не тех, кто позавчера прочел «Самоучитель Python для Чайников», а тех, у кого с десяток реальных проектов за плечами?
Может полтора таких супер-питониста найдется на всю Москву, но только эти супер-опытные питонисты сидят на таких теплых местах, что поверьте, у вас никаких денег не хватит их к себе переманить.

Кстати, в этом плане я бы не рекомендовал использовать всякие «красивости» типа Java и «модности» типа Ruby.

Rails
Высокая скорость разработки, куча готовых решений, большое и активное сообщество, ну и производительность куда выше чем у PHP.
Плюс Ruby с красивым ООП, в отличие опять же от PHP.

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

Вам нужен OEM образ, причем от конкретного производителя. Причем не все производители его предоставляют. При покупке к ноуту прилагается либо диск с дистрибутивом (для более ранних моделей), либо диск восстановления (установленной системы в заводском состоянии), либо установленная утилита для создания такого диска из скрытого раздела на харде (в последнее время самый частый случай). Техподдержка может (но не обязана) выслать вам такой диск, если вы ее уговорите. Добрые люди иногда выкладывают такие образы на трекеры, ftp и прочие места. Так что поищите на форумах, в темах, где обсуждается данная модель.

Что же касается легальности, то скачанный откуда-то образ, а значит и установка с него, к сожалению не будут полностью легальными с точки зрения законодательства РФ, несмотря на наличие ключа. Хотя претензий вам никто не предъявит, так как после установки уже невозможно определить, откуда был взят дистрибутив. (Если интересуют подробности, почитайте на iXBT, там эта тема разжевывалась неоднократно.)

Используйте систему контроля версий базы данных, например, liquibase. Скрипты diff дают очень ненадежный результат, так как они сравнивают разницу между конечным и начальным результатом и не имеют возможности узнать что было посередине. К примеру если вы переименовали таблицу, может быть сгенерирован код drop table + create table вместо rename.

Многие из нас, как известно, ненавидят вебмани, включая меня :)

Подростковая болезнь ненавидеть/любить WebMoney/PayPal, FaceBook/ВКонтакте, Windows/Linux, Java/C# и пр. Я люблю только свою жену, а это всего лишь инструменты: используйте когда вам выгодно/полезно, любить их вас никто не обязывает.

>Я хочу, что бы система обладала 100% функционалом ввод — вывод, в какой стране я бы не находился. Прием PayPal в России, как и в некоторых других странах — не доступен.

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

Согласен, Silverlight — умирающая технология, Flash — распространенная. Но есть еще JavaScript — присмотритесь серьезно, пощупайте Canvas, веб-сокеты, подумайте о концепции игры, если она принципиально подходит, то JavaScript — самый перспективный и кросс-платформенный вариант.

php+php_libevent — самый оптимальный вариант

если уж очень нужна происводительность демона, то С/С++
масса примеров в сети

Если хочется php — phpdaemon
А вообще node.js хорошее решение.

TortoiseGit довольно удобен.