Вот это я и хотел услышать. Действительно, с распределенными транзакциями я не работал, и те фреймворки, которые я использую, их не поддерживают (насколько я знаю).
А вот насчет кластерных решений не понял. Точнее, я понимаю, что это звучит круто, но без уточнения непонятно о чем речь. Кластер чего? Серверов приложений? Чем обычный load balancer мешает это организовать?
Гы, быстрее выучить django и потом быстренько сделать. Пример из жизни — мне надо было написать одно сетевое приложение. Я очень хорошо знал дотнет, и мог быстро на нем все слабать (скажем за месяц). Но я решил сделать приложение кроссплатформенным, поэтому скрипя сердце взялся за Python. В итоге я за две недели (первые 3-4 дня на изучение питона) написал это приложение. Почему? Потому что на нем писать быстрее, проще, и есть удобные и легкие в использовании библиотеки.
Думаю, аналогия понятна — лучше день потратить, а потом долететь. На J2EE ну реально все очень долго разрабатывать (если конечно, это не однотипные проекты с наработками, которые просто перекидываются из проекта в проект). Хотя саму джаву я уважаю, но веб-разработка под ней — это тихий ужас (если, конечно, не использовать легковесные фреймворки).
Не хочу поднимать флейм, но зачем все это? Неужели кто-то в здравом уме будет все это использовать, писать многокилометровые XML-и только ради того, чтобы прикоснуться к миру J2EE? Какая экономическая целесообразность? Ведь намного проще и быстрее (а значит и выгоднее) использовать легковесные фреймворки — тот же Grails (если уж так хочется джаву), RoR, Django и т.п.
Мне просто реально интересно. Знаю, что люди используют, но не понимаю, почему. Скажу сразу — Spring пытался использовать, но дальше того примера, который был приведен, особо и не ушел — мне мое время жалко, и я понял, что это не мое.
Сейчас намечается один проект — чистый peer-to-peer groupware. Там все хранится на пирах — документы, сырцы, багтрекинг и т.п., и пиры просто обмениваются инфой без участия серверов. Соответственно, ограничения, обозначенные в сабже, идут лесом. Думаю, в современном мире, когда закручивают все гайки, это будет реально полезно.
А для начала советую перейти на DVCS типа Git-а или Mercurial. Как минимум, даже если сервера прикроют, вся история изменений останется локально, и можно будет легко склонировать проект на другие сервера. У меня тут есть даже небольшая статья на эту тему: nuald.blogspot.com/2009/06/git-vs-mercurial.html
Правда статья писалась давно, и сейчас я все больше склоняюсь в сторону Mercurial, ибо в Git-е обнаружились не особо приятные моменты, мешающие полноценной работе.
Не отмечен еще один краеугольный камень безопасности — транзакционность запросов. Все взаимодействие должно происходить в рамках транзакций, с возможностью отката, если на каком-то этапе произошел сбой. Это тоже вектор атаки, и он используется злоумышленниками. Естественно, должен проводиться аудит транзакций, особенно тех, которые не завершены. Также из-за особенностей работы в вебе, зависшие транзакции (когда не получен ответ от второй стороны), должны как-то обрабатываться, например откатываться по таймауту.
Позвольте добавить свои пять копеек:
1. Писать собственный Logger непрактично. Лучше использовать встроенные возможности Qt (qDebug) или Python (logging). И для того и для другого можно определить обработчики сообщений (Qt — qInstallMsgHandler, Python — logging.handlers).
2. Для потоков лучше написать декоратор, который будет производить всю работу по инициализации и очищению ресурсов. Это вам сильно упростит жизнь — фактически, вы сможете превращать функции из однопоточных в многопоточные, просто приписав к ним этот декоратор. Конечно, при этом они станут асинхронными, но для GUI-приложений зачастую это именно то, что нужно.
Правда тесты довольно-таки староваты, по-хорошему надо бы их прогнать на современных версиях ЯП. Ну и ради справедливости надо добавить что есть JPython (для JVM) и IronPython (для .NET), которые в некоторых случаях могут работать весьма шустро. Я не говорю уже про всякие расширения типа psyco.
По себе скажу, что я вообще уже давно забил на сравнение производительности, т.к. в основном узкие места — это взаимодействия со внешней средой (БД, файловой системой, сетью и т.п.) Есть, конечно, области, где скорость важна — мультимедиа приложения, или реально высоконагруженные сайты. И здесь уже не до религиозных споров — выбираются технологии по возможностям. Но замечу, что YouTube все-таки написан на Python.
С точки зрения скриптовости С# не так уж хорош, прежде всего, потому что он компилируется. И хотя практически все скриптовые языки компилируются в промежуточный байт-код, процесс компиляции C#-проектов намного дольше. Я помню на своей практике, когда не такой уж тяжеловесный ASP.NET-сайт запускался по несколько минут из-за компиляции ASPX-страниц.
И не надо умалчивать другие не особо приятные вещи про ASP.NET — громоздкие ViewState-ы на страницах, которые любят забивать трафик, кошмарные автогенерируемые имена для контролов, и вообще любовь этой платформы к памяти и процессору. Естественно, все это решается, однако для простенького сайта слишком уж много чести, чтобы еще разбираться с такого рода проблемами. У ASP.NET есть своя ниша, но простые сайты на этой технологии точно писать не стоит. Я помню в свое время как мы ковыряли движок DNN, и сколько там понаходили кода только для оптимизации проекта, чтобы он крутился более или менее адекватно, хотя проект по сути достаточно простой.
И про СУБД. Oracle и PostgreSQL позволяют писать хранимые процедуры на Java, причем очень давно, и все уже к этому привыкли. Это так, для общего развития, хотя возможно, вы это и знаете.
Twitter moved to the Java JVM for their server infrastructure (long lived processes) and moved to Scala to program against it (high level language, static typing, functional). Ruby is used on the front-end but wasn't performant or reliable enough for the back-end.
Eclipse+PyDev — практически идеально решение. Возможно, в винде у этой связки и есть какие-то проблемы, у себя и у моих сотрудников в линуксе их вообще ни разу не наблюдал. Отладка тоже работает на ура, хотя некоторые придирки к отладчику все-таки есть, но это мелочевка.
MySQL мы вообще перестали использовать в своих проектах. При интенсивной работы с фикчами он очень существенно тормозит, а они у нас очень много используются в юнит-тестах. Сейчас используем исключительно PostgreSQL.
Вы сами перечислили причины, почему Python ускоряет разработку — на нем проще проектировать грамотную архитектуру, проще ловить баги, проще тестировать. Ну и с разработчиками тоже особо проблем нет из-за низкого порога вхождения, т.е. любой грамотный разработчик сможет писать на Python-е через неделю после его изучения с нуля.
Единственное, хочу отметить про баги. Python — динамически-типизируемый язык, и соотвественно, можно ловить много багов из-за несоответствия типов. Мы для себя эту проблему решили жестким требованием соблюдать 100%-ое покрытие кода.
К сожалению, я тоже не изучал. Естественно, у него есть своя ниша, и думаю, что он больше применим для CGI-скриптов, что подтверждается «Who uses web.py?» секцией на заглавной странице проекта.
Вообще, я не воспринимаю выбор фреймворка как некий религиозный вопрос. Разнообразие проектов существует не просто так, и у каждого есть своя уникальность. Но при этом возникают другие вопросы — времени, денег и усилий. Для кого-то они не важны, например, для студентов или людей, у кого излишек времени и/или денег. Я себе такие растраты позволить не могу и не хочу, поэтому зачастую выбираю именно Django как оптимальный вариант с точки зрения траты ресурсов.
Спасибо, я в курсе. Оптимизация Django-приложений — это отдельная тема, для которой необходимо упоминать такие страшные слова, как memcached, nginx, load balancer, database cluster, replication и т.п. В принципе, все это сказано в презентации Django Con High Performance Django.
Автоматическая админка — это не только автогенерация форм и списков. Это еще и права доступа, аудит, отслеживание целостности, всяческого рода фильтры и поиски. Я не сомневаюсь, что есть готовые решения для любой платформы, но в Django это идет из коробки, и не приходится что-то искать и пробовать.
Не хочу поднимать холивар, а просто выскажу, почему я не использую RoR в своих проектах:
— слабая документация, приходится ковырять кучу ресурсов и смотреть тяжелые скринкасты;
— неинтуитивно понятный ЯП, без привычки иногда читать тяжеловато, особенно если злоупотребляют mixin-ами и другими техниками;
— явные тормоза, даже со свежей версией (по-крайней мере, под линуксом);
— кривой rcov, что в итоге не позволяет мне считать code coverage (сейчас может исправили, но последний раз, когда я смотрел летом, он не работал со свежей версией Ruby);
— нет единообразности в процедурах локализации. То, что предлагается по умолчанию, не столь удобно в использовании.
Я это косвенно упоминал. Фактически, все упомянутые пункты влияют на скорость разработки. С другой стороны, это очень шаткий аргумент, т.к. в некоторых случаях разработка на Django не столь быстра, как на специализированных фреймворках. Например, в том же RoR некоторые вещи можно писать намного быстрее, если сайт полностью совпадает с паттернами проектирования, заложенными в рельсы изначально.
Да, я в свое рассматривал Pylons. В целом, это система, которая связывает другие библиотеки — SQLAlchemy, Genshi и т.п., и в чем-то она напоминает Java Spring. Бесспорно, у Pylons есть свои плюсы, но они перекрываются другими недостатками (по крайней мере в моих глазах): недостаточная зрелость проекта, небогатая документация (это касается не только самого Pylons, но и библиотек, которые он предлагает использовать), отсутствие автоматической админки. Все это повышает порог вхождения, и понижает скорость разработки. А это — потерянные бабки, это трата времени на его изучение молодыми специалистами, это трудноопределимые баги, когда непонятно кто виноват — тот же Genshi, SQLAlchemy или сам Pylons.
А вот насчет кластерных решений не понял. Точнее, я понимаю, что это звучит круто, но без уточнения непонятно о чем речь. Кластер чего? Серверов приложений? Чем обычный load balancer мешает это организовать?
Думаю, аналогия понятна — лучше день потратить, а потом долететь. На J2EE ну реально все очень долго разрабатывать (если конечно, это не однотипные проекты с наработками, которые просто перекидываются из проекта в проект). Хотя саму джаву я уважаю, но веб-разработка под ней — это тихий ужас (если, конечно, не использовать легковесные фреймворки).
Мне просто реально интересно. Знаю, что люди используют, но не понимаю, почему. Скажу сразу — Spring пытался использовать, но дальше того примера, который был приведен, особо и не ушел — мне мое время жалко, и я понял, что это не мое.
А для начала советую перейти на DVCS типа Git-а или Mercurial. Как минимум, даже если сервера прикроют, вся история изменений останется локально, и можно будет легко склонировать проект на другие сервера. У меня тут есть даже небольшая статья на эту тему: nuald.blogspot.com/2009/06/git-vs-mercurial.html
Правда статья писалась давно, и сейчас я все больше склоняюсь в сторону Mercurial, ибо в Git-е обнаружились не особо приятные моменты, мешающие полноценной работе.
1. Писать собственный Logger непрактично. Лучше использовать встроенные возможности Qt (qDebug) или Python (logging). И для того и для другого можно определить обработчики сообщений (Qt — qInstallMsgHandler, Python — logging.handlers).
2. Для потоков лучше написать декоратор, который будет производить всю работу по инициализации и очищению ресурсов. Это вам сильно упростит жизнь — фактически, вы сможете превращать функции из однопоточных в многопоточные, просто приписав к ним этот декоратор. Конечно, при этом они станут асинхронными, но для GUI-приложений зачастую это именно то, что нужно.
www.timestretch.com/FractalBenchmark.html
Правда тесты довольно-таки староваты, по-хорошему надо бы их прогнать на современных версиях ЯП. Ну и ради справедливости надо добавить что есть JPython (для JVM) и IronPython (для .NET), которые в некоторых случаях могут работать весьма шустро. Я не говорю уже про всякие расширения типа psyco.
По себе скажу, что я вообще уже давно забил на сравнение производительности, т.к. в основном узкие места — это взаимодействия со внешней средой (БД, файловой системой, сетью и т.п.) Есть, конечно, области, где скорость важна — мультимедиа приложения, или реально высоконагруженные сайты. И здесь уже не до религиозных споров — выбираются технологии по возможностям. Но замечу, что YouTube все-таки написан на Python.
И не надо умалчивать другие не особо приятные вещи про ASP.NET — громоздкие ViewState-ы на страницах, которые любят забивать трафик, кошмарные автогенерируемые имена для контролов, и вообще любовь этой платформы к памяти и процессору. Естественно, все это решается, однако для простенького сайта слишком уж много чести, чтобы еще разбираться с такого рода проблемами. У ASP.NET есть своя ниша, но простые сайты на этой технологии точно писать не стоит. Я помню в свое время как мы ковыряли движок DNN, и сколько там понаходили кода только для оптимизации проекта, чтобы он крутился более или менее адекватно, хотя проект по сути достаточно простой.
И про СУБД. Oracle и PostgreSQL позволяют писать хранимые процедуры на Java, причем очень давно, и все уже к этому привыкли. Это так, для общего развития, хотя возможно, вы это и знаете.
Позволю себе процитировать:
MySQL мы вообще перестали использовать в своих проектах. При интенсивной работы с фикчами он очень существенно тормозит, а они у нас очень много используются в юнит-тестах. Сейчас используем исключительно PostgreSQL.
Единственное, хочу отметить про баги. Python — динамически-типизируемый язык, и соотвественно, можно ловить много багов из-за несоответствия типов. Мы для себя эту проблему решили жестким требованием соблюдать 100%-ое покрытие кода.
Вообще, я не воспринимаю выбор фреймворка как некий религиозный вопрос. Разнообразие проектов существует не просто так, и у каждого есть своя уникальность. Но при этом возникают другие вопросы — времени, денег и усилий. Для кого-то они не важны, например, для студентов или людей, у кого излишек времени и/или денег. Я себе такие растраты позволить не могу и не хочу, поэтому зачастую выбираю именно Django как оптимальный вариант с точки зрения траты ресурсов.
— слабая документация, приходится ковырять кучу ресурсов и смотреть тяжелые скринкасты;
— неинтуитивно понятный ЯП, без привычки иногда читать тяжеловато, особенно если злоупотребляют mixin-ами и другими техниками;
— явные тормоза, даже со свежей версией (по-крайней мере, под линуксом);
— кривой rcov, что в итоге не позволяет мне считать code coverage (сейчас может исправили, но последний раз, когда я смотрел летом, он не работал со свежей версией Ruby);
— нет единообразности в процедурах локализации. То, что предлагается по умолчанию, не столь удобно в использовании.