Кто-то тупой, или я или гвозди

[metaclass]

Сижу изучаю различные варианты реализации middle-tier, который планируется использовать в будущем для нескольких проектов. Решил пересилить свой страх и взглянуть на J2EE. А надо сказать, что для неподготовленного ума ентерпрайз жаба выглядит совершенно ирреально бредовой: миллиарды фреймворков, утилит, серверов, сотни страниц документации, проекты на ней содержат over 9000 папок и мелких исходников и xml-конфигов и вообще я не уверен, что в здравом уме и имея некую начальную свободу выбора инструментов, с этим стоит вообще связываться.

Начал искать что-нибудь вроде "J2EE для начинающих с пошаговыми инструкциями". Нашел AppFuse. Вроде все описано понятно, есть QuickStart, написано откуда качать зависимости, итд, итп. Но таки вы будете смеятся - но я не могу найти, где качать исходники этого дела. Ссылки "Download" на сайте нету.

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

Вообще говоря, у меня уже есть почти полностью готовая основа для этого миддл-тиера, на которой я бы проект сделал очень быстро: Firebird+Delphi+ASP.NET RESTful веб-сервис. Но проблема в том, что это означает полную и окончательную привязку проектов к виндам, отказ от любых потенциальных работ с юниксами в будущем и сгнаивание мозга до состояния "сеньор-фокспро-девелопер в ВЦ НИИ Говна и Торфа, 50 лет, 30 лет опыта рисования формочек в дизайнере".

Кроме того, если дать объявление "требуется разработчик на дельфи" - приходят такие долбаные мышевозы с паттернами "magic button" что рыдать хочется, соответственно шансов на то, что хотя бы когда-нибудь я займусь только архитектурой и управлением проектами, вместо того, чтобы самостоятельно писать код, внедрять и обслуживать - не останется никаких.


PS: Есть кстати, еще одна, еще более неадекватная альтернатива: сойти с ума и ударится в нетривиальщину вроде ерланга и хаскеля, начать писать самодельный миддл-тиер на чистом С и изобретать прочие велосипеды. То, что это гарантированно будет легче для нервной системы, чем J2EE и ASP.NET, я уверен. Там комьюнити меньше и не будет такого, что половина интернетов забита разнообразными фреймворками, каждый из которых настолько наворочен, что позволяет не писать код, а всего лишь парой сотен xml-конфигов сделать любое приложение.
Я вспоминаю 90-е годы, когда никаких интернетов не было, проекты были более мелкие и выбора "на чем писать" особо не было, можно было велосипеды изобретать хоть годами.

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

Вот, к примеру: я считаю, что любой, кто сталкивался с статической типизацией и выводом типов, резко перестанет делать проекты "мегапереконфигурируемыми" с помощью сотен xml-конфигов, т.к. это выносит проверку правильности с времени сборки на время деплоймента и запуска. Ошибся в xml-файле в одной букве и вешайся, читай 100-строчные стеки вызовов и это еще хорошо, если у тебя доступ к продакшен-серверу есть.

Comments

[bopm.livejournal.com]

Т.е. не человек полез в яву в поисках решения для 600 запросов в секунду (sic!), а ява обязывает.
Чисто прикидочный тест, это да. Измерение длинны пениса у сферического коня в вакууме. Пользы столько же.
Думать, к вопросу о примерах, вообще полезно. Я вот сходу не могу назвать ни одной сферы, где дешево и с наскоку нужно обеспечивать 600 запросов в секунду. Зато помню как первый год работал ticket.rzd.ru написанный на вашей хваленой яве.
Ваши объяснения хорошо сопряжены с прошлыми частями беседы. Сразу видно, как вы владеете ситуацией в современной разработке. Могу например посоветовать вам ознакомиться с такой новой и нигде еще не используемой технологией как FastCGI.
Про многопоточность, это имеет свою роль несомненно, но увы не является чем то для явы уникальным. Более того, сам факт наличия потоков создает кучу дополнительных проблем как для разработчиков платформы, так и для тех, кто пишет для нее код.
А про ваше понимание про интерпретатор, тем хуже, если вы понимаете, но продолжаете использовать его в качестве аргумента. В этом случае вы либо идиот, либо пиздюк пытающийся отбрехаться первым придуманным аргументом в расчете на то, что оппонент не владеет обсуждаемым вопросом.

[norguhtar.livejournal.com]

Т.е. не человек полез в яву в поисках решения для 600 запросов в секунду (sic!), а ява обязывает.

Я счетаю, что лезть в java просто так черевато для головного мозга. Там шибко много заебов и лезть туда лучше если или вам ее действительно это надо.


Я вот сходу не могу назвать ни одной сферы, где дешево и с наскоку нужно обеспечивать 600 запросов в секунду. Зато помню как первый год работал ticket.rzd.ru написанный на вашей хваленой яве.

В яве тоже далеко не все гладко. И налажать в ней из-за того что писал автор (дофига-дофига всего) тоже можно легко.


Могу например посоветовать вам ознакомиться с такой новой и нигде еще не используемой технологией как FastCGI.

Про FastCGI я знаю. Но вопрос тогда стоял php или таки java (товарища которого это интересовало пишет на java), а вот от FastCGI в php толку ноль. Он эту модель в чистом виде не подддерживает.


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

Не является.


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

Конечно. И это не всегда надо.


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

В качестве какого аргумента? Что Ruby на данный момент не сильно быстро работает?

[bopm.livejournal.com]

То, что вы не знаете, как подружить php с fastcgi не значит, что их нельзя подружить. Сайтов которые этим пользуются до жопы.
А про аргумент я все тот же — интерпретатор.

[norguhtar.livejournal.com]

То, что вы не знаете, как подружить php с fastcgi не значит, что их нельзя подружить. Сайтов которые этим пользуются до жопы.

FastCGI подразумевает наличие демона который ожидает соединения и обрабатывает его. В случае php fastCGI это не так. Используется враппер который через FastCGI запускает обычные php скрипты. Т.е. любой сайт который запускается при помощи php-cgi или mod_php можно запустить и там. Причем без модификации. Я помню только одну единственную реализацию которая реально изображает FastCGI.

[alexclear.livejournal.com]

FastCGI подразумевает наличие демона который ожидает соединения и обрабатывает его. В случае php fastCGI это не так.

Эти два утверждения логически противоречивы.
Если подразумевает, значит, демон есть.
Видимо, в случае с PHP он тоже есть.

Используется враппер который через FastCGI запускает обычные php скрипты.

Нет, это не так.
То есть, PHP-скрипты обычные, а демон все равно есть.
Что как бы говорит нам, что нет никакой особой нужды в использовании PHP под FastCGI, он и под Apache работает ровно точно так же.

[norguhtar.livejournal.com]

Видимо, в случае с PHP он тоже есть.

Не ввиде приложение, а в виде самого php.


Что как бы говорит нам, что нет никакой особой нужды в использовании PHP под FastCGI, он и под Apache работает ровно точно так же.

Дык я на это и намекаю. Что модель то та же остается. То что у нас есть демон который конвертит FastCGI в CGI мало что меняет.

[alexclear.livejournal.com]

Не ввиде приложение, а в виде самого php.

Ну, может оно и к лучшему.

Дык я на это и намекаю. Что модель то та же остается. То что у нас есть демон который конвертит FastCGI в CGI мало что меняет.

Я все равно не понимаю, при чем здесь CGI.
CGI здесь совсем не при чем.
mod_php никакого отношения к CGI не имеет.

[norguhtar.livejournal.com]

Ну, может оно и к лучшему.

Вот в случае PHP это точно.


Я все равно не понимаю, при чем здесь CGI.

CGI подразумевает, что при приходе запроса активируется скрипт и ему кормятся параметры в формате CGI после того как он отдает ответ он умирает. В mod_php если нет акселератора даже код не сейвится скомпилированный, т.е. да мы имеем php в памяти что позволяет не запускать его каждый раз, но скрипт то запускается каждый раз заново, как это делается при CGI.

[bopm.livejournal.com]

Правильно, вам просто нужно в сочетании с php-fastcgi использовать eaccelerator. В этом случае второй решит проблему однократной генерации байт-кода, а второй проблему демонизации.
Однако мы отклонились от темы. В случае с рельсами это работает из коробки на стандартном mongrel_cluster.

[norguhtar.livejournal.com]

yep. Только FastCGI в чистом даже php-fastcgi с акселератором не дает. Сугубо говоря если я в скрипте открою соединение, то в конце скрипта оно закроется.

В случае рельсво действительно так.