iceB-9.0

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

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

> E/AS не сдох, он в коме

и вообще, хотя бы спам из вики почистите. Смотрю в вашу вику E/AS изменения за 2008 год -- спам, спам, спам, лавли спам...

> надо же, а по сайту не скажешь.

Мой косяк: тяжело и проектировать и кодить и поддерживать веб-инфраструктуру в одиночку.

> пеара явно не хватает этим проектам.

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

> Хотя бы в здоровой форме [жж]-бложика

sibskull.livejournal.com

> С GTK на Qt 4? а почему Qt?

В рассылку я выкладывал архитектуру. Там это описано. Основная причина: развитость платформы.

> У вас хоть "сервер приложений" есть.

Да. Qt сейчас разделён на разные библиотеки. И для сервера приложений GUI не нужен.

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

Потому что это затратно при наработанной базе кода. Вспомните KDE. Я же пишу с нуля и потому таких проблем не возникает.

> и вообще, хотя бы спам из вики почистите.

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

>> Хотя бы в здоровой форме [жж]-бложика

>sibskull.livejournal.com

туда бы тегов "E/AS" навесить. И статей написать :)

> Мой косяк: тяжело и проектировать и кодить и поддерживать веб-инфраструктуру в одиночку.

поэтому "веб-инфраструктура" должна быть простой как тот же бложик, чтобы обновляться часто и просто

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

>Потому что это затратно при наработанной базе кода.

point был в том, что если проект на Qt-4, который сам по себе активно дорабатывается, то Qt для этого проекта -- ССЗБ и через какое-то время при отутствии всяких усилий и регулярных работ по портированию на Qt-current версии проекта и Qt могут разойтись достаточно далеко "сами собой".

>Вспомните KDE.

кстати, вот у KDE кодовая база -- всем базам база. И то осилили допортировать за разумное время. А то что я вижу с портом Ананаса с Qt-3 на Qt-4 кроме уныния ничего не вызывает.

> Вообще, самое главное, чтобы пользователи не забывали пинать разработчиков.

угу. А то вот потенциальный юзер Sudoer (бубунтоид?) только сунулся и получил отлуп "это жастфофан, здесь никто никому ничего не должен".

А у вас типа лаба тестирования качества, которая по идее такие проблемы "тети Оли бухгалтера" должна собирать и прислушиваться. Может на базе тесной интеграции качества дистра + качества проекта + проблем рядовой тёти Оли что-то и вырастет. Потому что как рядовая тетя Оля вообще узнает об этой новой бухгалтерии. Она конечно не будет "вступать и компелировать" а возьмёт "сразу из коробки", помучается и если не получится, сразу бросит.

> All-in-one — лозунг для доверчивых потребителей.

1C из коробки не годится для всех. Как-то мне бухгалтеры жаловались, что там по умолчанию какое-то поле было 50 символов, и длинное название фирмы туда не помещалось :-) All-in-one типа :-)

И вообще -- если 1С работает из коробки, то чем кормятся орды 1С программеров?

Skull, цитирую вас:

1. Язык и элементы реализации слоёв.
Предлагается использовать CLIP (http://www.itk.ru), так как он удовлетворяет следующим критериям:
* простой синтаксис
* байт-код
* ООП
* готовая реализация некоторых слоёв (транспорт, ОБД, СП, UI)
* OpenSource



Не находите что сюда лучше всего подходит .... да-да - Жаба! :)
Прямо по каждому пункту!

Тем более далее вы пишите:

Недостатки:
* мало разработчиков
* слабая документация
* мало продуктов на нём

Жаба этих недостатков лишена. У нее есть другие - впрочем сейчас LOR'овцы вам объяснят :)

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

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

А пока этого нет, никто и не подтянется помогать.

> Не находите что сюда лучше всего подходит .... да-да - Жаба! :) Прямо по каждому пункту!

Хотя я жабу не люблю, я это тоже нахожу. Че-то мне сдается, что свой интерпретируемый язык выдумывать не надо, а надо написать классы на той же жабе, а прикладному программеру их экстендить. У жабы приличная заточенность под ГУИ.

> 1C из коробки не годится для всех<..> по умолчанию какое-то поле было 50 символов,

вспоминается анекдот про парикмахерскую машинку для точки карандашей ^W^W автоматической стрижки. One size fits all, ага.

>И вообще -- если 1С работает из коробки, то чем кормятся орды 1С программеров?

"В теории всё работает, но мы не знаем почему. На практике ничего не работает, но мы понимаем, почему. Здесь мы соединяем теорию и практику -- ничего не работает, и не знаем почему" :)

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

> Жаба этих недостатков лишена. У нее есть другие - впрочем сейчас LOR'овцы вам объяснят :)

ну я солидарен с этим анамнезом: http://eas.lrn.ru/wiki/EnterpriseDevelopment?v=1ff

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

и вместо БухУчёт.Проводки(Счет_41,Счет_60).Выбрать писать AWT-подобный код с анонимными классами и EventListener'ами? Бррр..
DSL удобнее - функционал нагляднее и язык проще. Плюс DSL можно придумать декларативный, а в "чистой" жабе как -- шаблонами вокруг AspectJ ?

1С по-моему показал, что идея "Языка программирования для бухгалтеров" провалилась. Ну не хотят главбухи программировать в терминах бейсик-подобного языка с проводками и регистрами, это типа сложно и пусть у программера голова болит. Так с чего бы им хотеть программировать на жабе, если и на своём интерпретируемом -- слишком сложно?

Если нет своего DSL-я доступного для понимания консультантам, бухам и "прикладным" программистам, то это автоматически повышает порог вхождения и снижает скорость разработки "типовых" конфигураций раза в 2 или больше. Следовательно, "отчётность и формы будут редко обновляться, ну и кому оно нужно" ?

LOR - как всегда на высоте :)
Я предлагал Черепу _систему_ программировать на Жабе, а вы плавно перевели это в язык программирования системы ... палитесь дельфятники :) Кстати - тоже выдумывать не надо - есть уже готовы е скриптовые Scala и Groovy которые Жаба-классы понимают ...


PS: Жаль что я не жабист - я бы попробовал!


PPS: Я - Сишник + змеевод. Но Skull всё это время от такой связки упорно отбивается :(

Кстате - этих краях водится некто "r" - вроде как конценный жабшик ... - r что вы думаете про связку жаба для системы + ну к примеру груви для программешки бусинес логики?

> поэтому "веб-инфраструктура" должна быть простой как тот же бложик, чтобы обновляться часто и просто

Угу. Или Wiki. Но официальный сайт+форум+Wiki всё же лучше.

> через какое-то время при отутствии всяких усилий и регулярных работ по портированию на Qt-current версии проекта и Qt могут разойтись достаточно далеко "сами собой".

Зависит от заточенности разработчика на те или иные модные фичи и тонкости реализации. Мне и надо-то деление на модули, XML, Model/View, .ui и поддержку скриптов.

> А то что я вижу с портом Ананаса с Qt-3 на Qt-4 кроме уныния ничего не вызывает.

Так у Ананаса разработчиков порядка на два меньше. При том не такой квалификации, как в KDE.

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

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

Второй: писать клиент-серверное приложение на нативных виджетах (a la Ананас). При этом прикладная конфигурация должна быть максимальна отделена от платформы, о чём я и говорил на конференции свободных разработчиков в Обнинске в этом году. Тезисы доступны в Интернете.

Если конфигурация будет отделена, то сегментированность по проектам будет снижена. Да и поддерживать её можно будет за деньги государства (в рамках того же школьного проекта).

> И вообще -- если 1С работает из коробки, то чем кормятся орды 1С программеров?

1С из коробки не покрывает потребностей ни одной фирмы. Заточка неизбежна. А вот запутанность и кривость платформы породили высокооплачиваемых обладающих сакральным знанием «программистов на 1С».

Бррр! Как вспомню, что отчёт по ответственному хранению на 1С:Предприятие 7.7 получился на 6 тысяч (!) строк. Вот такая чудная платформа 1С!

> Не находите что сюда лучше всего подходит .... да-да - Жаба! :)

Для Java нужно много высокооплачиваемых разработчиков. Хтя бы один такой разработчик согласится? Делали в своё время jCash на Java, потом забросили. Такова реальность: разработчики на Java могут хорошо делать заказные решения, но не свободную платформу.

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

> PPS: Я - Сишник + змеевод. Но Skull всё это время от такой связки упорно отбивается :(

В части Python я всё же согласен. А на C можно писать, когда будет прототипирована платформа.

>> PPS: Я - Сишник + змеевод. Но Skull всё это время от такой связки упорно отбивается :(

> В части Python я всё же согласен. А на C можно писать, когда будет прототипирована платформа.

А почему бы тогда не всё на питоне, с последующим переписыванием критических по скорости участков в виде модулей на С? (другой ананимус, даже не питонщик)

> А почему бы тогда не всё на питоне, с последующим переписыванием критических по скорости участков в виде модулей на С?

Python отлично встраивается. Но stand-alone приложения на нём жрут какое-то неимоверное количество памяти и очень тормознутые. Да и реализации ORM там нормальной я пока не видел.

>> А почему бы тогда не всё на питоне, с последующим переписыванием критических по скорости участков в виде модулей на С?

> Python отлично встраивается. Но stand-alone приложения на нём жрут какое-то неимоверное количество памяти и очень тормознутые. Да и реализации ORM там нормальной я пока не видел.

Я похоже не совсем понятно написал. Выше говорилось "А на C можно писать, когда будет прототипирована платформа." Вот и пишем прототип на питоне, для этого он тоже неплохо подходит, а дальше, см. предыдущий пост. И на питоне оставляем только встраиваемую часть. Между прочим, тормозные и жрущие память - это когда прототип программы выдают за релиз. Кстати, пользовался когда-то PyBookReader (python + pyGtk), не сказал бы, что он сильно отличался по качеству работы от скомпилированных программ.

> водится некто "r" - вроде как конценный жабшик ..

да, его запросы на AspectJ зачётно торкают..

> о чём я и говорил на конференции свободных разработчиков в Обнинске в этом году. Тезисы доступны в Интернете.

о, сенькс, тезисы и конференции -- это интересно. На конференции в Переславле-Залесском в 2007 были интересные тезисы про КЛА Бусленко и DSL-и из единой модели. http://heap.altlinux.org/pereslavl2007/kotegov/abstract.html

> Да и реализации ORM там нормальной я пока не видел.

через Зопу?

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

на месте питона тут может быть и QtScript, и Lua , и кошернейший Лисп. Главное, чтобы не С++, а то "прототипы" на С++ так из фазы прототипов никогда и не выйдут.

> к примеру груви для программешки бусинес логики?

можно будет сразу вешаться. Руби он и сам по себе не быстр, а ещё и в жабьей среде, так особенно тормоз

> Заточка неизбежна. А вот запутанность и кривость платформы породили высокооплачиваемых обладающих сакральным знанием «программистов на 1С».
>Вот такая чудная платформа 1С!

этот быдлокод УЖЕ один раз написан. А изобретатели велосипедов будут обречены его повторять заново.
Вот если бы взять "транслятор" 1С-ного языка в язык прототипа, и чтобы все эти мегабайты императивного быдлокода в унылой недообъектной модели сразу бы заработали в новой среде прототипа, а потом их ещё и отрефакторить и заменить быдлокод скриптовый на быструю реализацию на С, то это было бы интересно.

> высокооплачиваемых обладающих сакральным знанием «программистов на 1С».

им просто приплачивают за вредность молоком, как немного ранее "девелоперам на MFC". Зубрить MSDN наизусть и с выражением -- такого и врагу не пожелаешь.

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

И подложить что-то из списка работающего под жвм и интероперабельного с жавой:

AWK BeanShell ejs FreeMarker Groovy Jaskell Java JavaScript Jelly JEP Jexl jst JudoScript JUEL OGNL Pnuts Python Ruby Scheme Sleep Tcl Velocity XPath XSLT JavaFX AppleScript Bex OCamlScripting PHP Python(Jepp) Smalltalk/athena CajuScript MathEclipse

https://scripting.dev.java.net/

Самое простое и доступное - жабаскрипт. Так же способствует созданию армии интеграторов.

>ну я солидарен с этим анамнезом: http://eas.lrn.ru/wiki/EnterpriseDevelopment?v=1ff

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

Бред как по сути так и по мотивам. По сути - я тех страшных слов что там написаны - 90% не знаю - что не мешает мне заниматся энтерпрайзом. Если хочет делфи на жабе с формами - пусть берет тот самый делфи на жабе который назывался жбилдер - все то же самое токо на жабе.

PS: Если быстрая разработка обозначает генерация кода из UML - то это диагноз - таки да.

> Если нет своего DSL-я доступного для понимания консультантам, бухам и "прикладным" программистам, то это автоматически повышает порог вхождения и снижает скорость разработки "типовых" конфигураций раза в 2 или больше. Следовательно, "отчётность и формы будут редко обновляться, ну и кому оно нужно" ?

Читай по буквам - _не будут бухи программировать_. И не важно на каком DSL какого качества. Для того чтобы DSLи пошли конечным пользователем не имеющими за спиной пяток лет технического вуза необходимо чтобы они в жизни начали это делать в обиходе. А пока они дома возят мышкой - на работе они тоже будут возить мышкой.

>r что вы думаете про связку жаба для системы + ну к примеру груви для программешки бусинес логики?

Лучше жабаскрипт. a) просто b) знакомо всем вплоть до HTML выерстальщиков - интеграторы будут плакать от удовольствия в смысле дешевизны кадров и неприхотливости в быту.

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

Да ладно - а тот же compiere? А наличествующий тут Runa?

>При этом сделанное будет, мягко говоря, притормаживать.

А что такого быстрого в 1С запуска по сравнению с жабьим решением?

К стати есть такая замечательная вещь называемая XUL. Файрофокс проникает в мир а в мир бухгалтерии проникнуть не может?

Я как концептный жабщик предложил бы для такого проекта связку:

Java (сервер core, сервисы), Web морды простые генеренные по принципу мутации phpmyadmin и InfoPath, и скриптование на жабаскрипте, а десктопморду - mozilla XUL runner (тот же самый жабаскрипт - интегрированная возможность скриптования как серверсайда так и клиентсайда, на одном языке) - тут возможно создание единого фреймворка для веба и морды посредством подмножествка xul на вебе.

> Хочу трехзвенную архитектуру и чтобы веб и не веб и сервера и транзакции, при этом не хочу ничего писать на трехзвенной архитектуре не хочу ничего знать про транзакции и вообще что либо делать - хочу как в дельфи, но чтобы не форма со списком из бде, а мегаsap мышей генерить."

s/не хочу ничего писать на трехзвенной архитектуре/не хочу писать трехзвёнку на жабе/

В том же дельфи есть менее развесистые, чем жабьи сервера приложений.
Я какбе молчу про MIDAS, но байконур и т.п. или фреймворки вроде ISCRA не такие толстые, как эта жаба.

90% кода из жабьего сервера приложений в том же MBSA (там JBOSS используется) -- один толстый оверхед. Приложения "на дельфи" целиком меньше чем один только JBOSS сам по себе. Плюс деплоинг сложнее чем в той же самодостаточной дельфе. Плюс языка предметной области нет, пишите всё на жабе.

вот почему на лиспе есть PicoLisp -- сервер приложений в 400 кб в tgz (хотя это и встраиваемый интерпретатор.. впрочем, многопоточный и можно методы на компилируемые на Си заменять), E/AS тот же поменьше будет, а на великой жабе "сервера приложений" меньше 10 Мб толком не найдёшь?

Может, что-то в консерватории подкрутить надо?

> Если хочет делфи на жабе с формами - пусть берет тот самый делфи на жабе который назывался жбилдер - все то же самое токо на жабе.

только в 2-3 раза толще и тормознее, ога..

> PS: Если быстрая разработка обозначает генерация кода из UML - то это диагноз - таки да.

"быстрая разработка" -- это разработка в терминах предметной области. Жаба же как С++ обворачивает всё паттернами, и предлагает большой ворох технологий, которые сами по себе становятся слишком тяжелы.

"В случае J2EE: РСУБД, сервер приложений с DataSource, настроенном на эту РСУБД, 6 классов на серверной стороне+xml файл, 2 класса на клиентской стороне, а если это WEB-приложение – нужен еще контейнер сервлетов, сам сервлет (приложение на Java), HTML страница с включенными тегами Struts – и ВСЕ это, чтобы показать ОДНУ СТРОКУ из ОДНОЙ ТАБЛИЦЫ БД!!! Как вам, а ;) "

по-моему, такой ынтерпрайс -- это диагноз.

> _не будут бухи программировать_

я это тоже и написал. Речь о том, что не на DSL а на "великой жабе" или развесистых скриптах с паттернами и "прикладные" проги прогать не будут. "Системные программисты платформы" -- пускай их возятся с архитектурой, прикладным разработчикам конечных решений это не удобно

> Для того чтобы DSLи пошли конечным пользователем не имеющими за спиной пяток лет технического вуза необходимо чтобы они в жизни начали это делать в обиходе

Допустим, есть DSL. И "возя мышкой", параллельно строится программа на таком DSL. Например, как макросы в Office: нажал кнопку, повозил мышкой, отжал кнопку. Опа -- тоже программа написалась, и сама, без программиста. Можно и в исходник залезть и что-то поправить, если исходник понятен не только компилятору и программисту, а и "конечному пользователю".

>Лучше жабаскрипт.

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

> интеграторы будут плакать

будут. Но не от удовольствия, а от ужаса. КИС на похапе, бугога. Кодеры-индусы и "архитектурные астронавты".

Чтобы не плакали и кололись, с этим кактусом нужно что-то поближе к предметной области. Например, вот такой туториал:
http://www.prodevtips.com/2008/03/28/pico-lisp/
http://www.prodevtips.com/2008/04/28/advanced-oodb-in-pico-lisp/

Интересно сравнить у какого-нибудь "жабаскрипткодера", за сколько времени он налабает похожее приложение на рельсах, например. Или на JSP с фреймворками. Потом заметить, что ORM там практический готовый, да и GUI строится по этому ORM, по связям. Потом посмотреть запросы посложнее, и как они будут реализовываться на рельсах (хотя в том примере как раз всё просто).

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

> А что такого быстрого в 1С запуска по сравнению с жабьим решением?

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

>Да ладно - а тот же compiere? А наличествующий тут Runa?

ну Руна как бы workflow/bpm а не класса MES/MRP/ERP. А компьер и тот же MBSA -- наглядный пример толстой жабы, 90+ мегабайт в архиве (и 200+ установленного) с пустой базой. Один сервер приложений там 30 метров весит, что раз в 10 больше альтернативных "свободных платформ".

>К стати есть такая замечательная вещь называемая XUL

разве он не тормозит?

> скриптование на жабаскрипте, а десктопморду - mozilla XUL runner

поздравляю, твоя концептуальная жабья архитектура повторяет мозиллу с XUL-ом. А зачем нам два тормознутых XUL'а на двух разных уровнях?

Все проблемы, которые мы наблюдаем в миниатюре в мозилле с его XUL-ом повторятся в такой системе уже по-крупному.

вот InstantRails например, ~70 мб. TrailsFramework на жабе правда небольшой, что компенсируется тяжёлостью самой жабы и остальных фреймворков: hibernate, tomcat/jboss, и т.п.

>В том же дельфи есть менее развесистые, чем жабьи сервера приложений.

"Развесистые" - очень технический термин. Вебсервис в жабе делается в десять строк без всяких xml. Что там развесистого в сервелтах и жсп - непонятно - сервлет - надо реализовать один метод который получает апрос отдает HTML. JSP тоже самое только инвертировано - шаблонный движок. Туториалы по этим штукам в пяток страниц помещаются.

>Приложения "на дельфи" целиком меньше чем один только JBOSS сам по себе.

Один жбосс сам по себе умеет чуть больше чем дохрена и пишется не специально для тех кому из всего набора технологий что он поддерживает нужно 3. Есть те кому надо многие. Никто не заставляет учить или использовать все. 30 лишних мегабайтов на серваке жалко? Сотри 10 фотографий.

>Плюс языка предметной области нет, пишите всё на жабе.

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

>вот почему на лиспе есть PicoLisp -- сервер приложений в 400 кб в tgz

А X/Open DTS он умеет? А поговорить по RMI/IIOP/WS-*(тут десятка три спек OASIS)/CORBA/.... умеет? ТАк в чем собственно суть претензий к жбоссу - все уже сделано до вас? Сильно много умеет?

>Может, что-то в консерватории подкрутить надо?

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

>только в 2-3 раза толще и тормознее, ога..

Ага - на 1С смотрим - летающий продукт - звездолет.. Вам видео конвертировать или штуку на которую тормознутая бабушка на кнопки мышей такать будет?

>"В случае J2EE: РСУБД, сервер приложений с DataSource, настроенном на эту РСУБД, 6 классов на серверной стороне+xml файл, 2 класса на клиентской стороне, а если это WEB-приложение – нужен еще контейнер сервлетов, сам сервлет (приложение на Java), HTML страница с включенными тегами Struts – и ВСЕ это, чтобы показать ОДНУ СТРОКУ из ОДНОЙ ТАБЛИЦЫ БД!!! Как вам, а ;) "

Повторяю - это бред собачий.

>И сколько под него существует "бизнес-схем"

Существенно больше чем под самописную экзотику которую вообще никто не знает. Как минимум >0.

>А что там с многопоточностью, опять будет как в файрфоксе, одна страничка грузится, остальные курят?

Все в порядке там с многопоточностью. Бровзеры тут не при чем.

>Но не от удовольствия, а от ужаса. КИС на похапе, бугога. Кодеры-индусы и "архитектурные астронавты".

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

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

>Интересно сравнить у какого-нибудь "жабаскрипткодера", за сколько времени он налабает похожее приложение на рельсах, например

>Интересно сравнить у какого-нибудь "жабаскрипткодера", за сколько 
времени он налабает похожее приложение на рельсах, например

К хренам рельсы - вот тебе пример:

Это кусок описания схемы данных. Схема описуется внешним к программе образом и ее изхменения не требуют ни перегрузки ни вообще каких либо телодвижений.

<doxy:schema xmlns:doxy="/ns/doxy">
        <doxy:document type="sale" title="Sale" category="Main" order="0" show-metadata="true">
                <doxy:attribute name="id" title="ID" type="saleid" required="true" primary="true" wrap="false"/>
                <doxy:reference name="country" title="Country" type="country" required="true" display="name"/>
                <doxy:reference name="company" title="Company" type="company" required="true" display="name"/>
                <doxy:reference name="purchased_via" title="Purchased via" type="company" required="true" display="name"/>
                <doxy:reference name="product" title="Product" type="product" required="true" display="name"/>
                <doxy:attribute name="status" title="Status" type="status" required="true"/>
                <doxy:attribute name="type" title="Type" type="type" required="true"/>
                <doxy:attribute name="eta" title="ETA" type="doxy:date" required="true"/>
                <doxy:attribute name="probability" title="Probability" type="probability" required="true"/>
                <doxy:attribute name="first_approached" title="First Approached" type="doxy:date"/>
                <doxy:attribute name="call_back" title="Call Back" type="doxy:date"/>
                <doxy:attribute name="date" title="Purchased on" type="doxy:date"/>
                <doxy:attribute name="value" title="Value" type="doxy:string" />
                <doxy:reference name="contact1" title="Contact1" type="contact" display="name surname ( company )" in-list="false"/>
                <doxy:reference name="contact2" title="Contact2" type="contact" display="name surname ( company )" in-list="false"/>
                <doxy:attribute name="brochure" title="Brochure" type="brochure"/>
                <doxy:attribute name="brochure_sent_on" title="Brochure Sent on" type="doxy:date"/>
                <doxy:attribute name="followed_up" title="Followed Up" type="doxy:date"/>
                <doxy:attribute name="comment" title="Comment" type="doxy:string" in-list="false"/>
        </doxy:document>
        <doxy:sequence name="saleid" pattern="SALE-#########-UA"/>
        <doxy:enumeration name="type">
                <doxy:element value="lead"/>
                <doxy:element value="purchase"/>
                <doxy:element value="other"/>
        </doxy:enumeration>
        <doxy:enumeration name="status">
                <doxy:element value="none"/>                                                    
                <doxy:element value="on hold"/>
                <doxy:element value="trial"/>
                <doxy:element value="lost"/>
        </doxy:enumeration>
        <doxy:enumeration name="probability">
                <doxy:element value="0%"/>
                <doxy:element value="25%"/>
                <doxy:element value="50%"/>
                <doxy:element value="75%"/>
                <doxy:element value="100%"/>
        </doxy:enumeration>
        <doxy:enumeration name="brochure">
                <doxy:element value="to send"/>
                <doxy:element value="sent"/>
        </doxy:enumeration>
</doxy:schema>

Это веб система всего сервлетов - 1. Размер - строк 50 наверное. 
JSPшек стратсов и тд - 0. Отображение - XSLT - 8 скриптов для 
отображения любых данных определенных в схеме.

Многопользователская система потому разграничение доступа по обектам и полям кусок access.conf:

doxy = country, product, platform, contact
doxy.platform = name
doxy.country = name
doxy.product = name, type
doxy.contact = *

admin = *
admin.* = *

Хранится все в посгресе. (всякие членовредительские базы данных типа 
xmlных и ял-обектных были посланы вследствии огранниченности и 
тормознутости на связях и объемах). Но структуры данных внешние и 
потому напишшем как мы язычеч запросов который красивые зхапросы 
транслирует в мрачняк который исполняется и выглядит он так:

  assertEquals( "SELECT * FROM documents WHERE TRUE AND 
(ddb_type='user' OR ddb_type='notuser' OR ddb_type='other')  ORDER BY ddb_id DESC ",
 SqlGenerator.generate( "select all user, notuser, other" ) );

 Типа SQL да?: select all user where (name ~ 'aaa') order by name ascending offset 5 limit 6.

 Лексер, парсер и tree-like кодогенератор на ANTLR - 183 строки.

 Вебсистема - отчеты в CSV и из него же импор в систему. 

Теперь пойдем к скриптингу: подключим mozilla rhyno в качестве 
реализации жабаскрипта - напишем HostObject для жабаскрипта (строчек 
20) представлящий постоянные метаданные о записе и отвечающий за 
представление обекта в жабаскрипте с красивыми полями и ленивыми 
ссылками. И обана - сисадмин ваяет плугины:

var licences = database.select("select licence where (status = 'Active')");
var calendar = new java.util.GregorianCalendar();
calendar.roll(java.util.Calendar.DATE, 1);
var tomorrow = calendar.getTime();

log.info("Tomorrow: " + tomorrow );

var selected = [];
for(var i=0; i< licences.length; i++)
{
    var end_date = licences[i].end_date;
    if (end_date && end_date != '')
    {
        var year = end_date.substring(0,4);
        var mon = end_date.substring(5,7);
        var day = end_date.substring(8);
        var end = new java.util.Date(parseInt(year) - 1900, parseInt(mon) -1, parseInt(day));
        if (end.equals(tomorrow))
        {
            log.info('licence ' + licences[i].key + ' is about to be expired.');
            selected[selected.length] = licences[i];
        }
    }
}

if (selected.length > 0)
{
    var bindings = new java.util.HashMap();
    bindings.put('licences', selected);
    mailman.send('"Doxy Licence Watch" <whocares@nowhere.com>',
        ['whocares@nowhere.com', 'whocares@nowhere.com'],
        'licence.expiration.mail', bindings);
}

Обана  - а как это он из жабаскрипта работающего по крону:

#policy time plugin-class arguments
at 17:21 plugin.javascript.Run $SCHEMA/plugins/cron/licence_expired.js
at 16:37 plugin.javascript.Run $SCHEMA/plugins/cron/licence_expiration_mail.js

запустил емай?: Конечно черехз жабамайл и шаблоны на apache velocity:

--subject--
[doxy] Some licences are about to be expired.
--body--
Hi,

Doxy detected that some licences are about to be expired tomorrow:

Company / Product / Key
------------------------------------------------------------
#foreach($licence in $licences)
$licence.sale.company / $licence.sale.product / $licence.key
#end

--
Doxy

Конечно пришлось изобрести ще один хостобжект для велосити строк 15 
наверное - жуть просто.

И вся эта хрень работает по крону перезхватывает модификации объектов:

create activity doxy.plugin.mail.SendMail $SCHEMA/plugins/mail/create.activity.mailconf
modify activity doxy.plugin.mail.SendMail $SCHEMA/plugins/mail/modify.activity.mailconf

Вывод - вылизанная версия этого продукта с момента задумки до финального пива заняла у одного человека аж 3 недели.

>90+ мегабайт в архиве (и 200+ установленного

Какой ужос. Мелкий бизнес разориться на винчестерах. Один порнофилм сотрут - обеспечат себе место на всю жизнь.

>разве он не тормозит?

А что такое тормозит? ЗАпускается не мгновенно? НУ так и хрен с ним - вам работающая система кромсплатформенная и чтобы была, или быстрая но не работающаю и никогда? Файрфоксом сколько процентов населения планеты польхзвется? Если бухгалтерской системой будет пользоваться хоть один процент от указанного или даже от давнлоадеров третего фокса в первый день - то это 80 000 клиентов - нереально грандиозный успех. Для всех этих людей - не тормозит. Гоним тараканов из головы и все будет в порядке.

>Все проблемы, которые мы наблюдаем в миниатюре в мозилле с его XUL-ом повторятся в такой системе уже по-крупному.

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

> Вебсервис в жабе делается в десять строк без всяких xml. <..>. Туториалы по этим штукам в пяток страниц помещаются.

а ты статически не пытался линковать программы, только динамически? И посчитать накладные расходы на "всю инфраструктуру" целиком, а не вынести за скобки некоторой универсальной платформы, которая уже есть? То что туториалы хелловордов занимают 5 строк не важно, важен размер libc, рантайма в static варианте.

> Нужно ли изобретать еще один 1с скрипт - вопрос большой.

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

> А X/Open DTS он умеет? А поговорить по RMI/IIOP/WS-*(тут десятка три спек OASIS)/CORBA/.... умеет?

а должен? или должна быть поддержка просто "транзакций", "удалённого вызова методов"?
"поговорить по RMI/.." -- в том бложике, например, показывается как завернуть запросы в JSON. С учётом того, что можно передавать продолжения и замыкания, это аналогично удалённому вызову методов.

> ТАк в чем собственно суть претензий к жбоссу - все уже сделано до вас? Сильно много умеет?

сильно много умеет *не нужного мне*. Мне нафиг не нужна CORBA, нужен "удалённый вызов методов" и пофиг как именно он реализован, Java/RMI или Лисп/замыкания/продложения. Мне не нужен конкретно WS-*, нужны просто "вебсервисы". Не нужен X/Open DTS, нужен просто "менеджер транзакций" (в функциональщине продолжение=транзакция).
Не нужен конкретный стек технологий, нужна возможность промоделировать другие варианты реализации.

> И умеет например обеспечивать распределенные транзакции по гетерогенным источникам.

это всё замечательно, я рад за энтерпрайз. Но в этом конкретном приложении с одним сервером приложений с одной СУБД -- это зачем?
Понадобятся именно распределённые транзакции -- можно будет добавить объектный брокер попроще в сервер(а) приложений.

> Ага - на 1С смотрим - летающий продукт - звездолет..

здесь должен был быть смайлик? можно много рассуждать почему этот звездолёт летает низенько-низенько.. например, толстые транзакции на скриптовом языке. Это всё неэффективная реализация платформы и отсутствие адекватного языка описания транзакций. Там ещё много в чем можно критиковать платформу, но для начала хватит. И сдаётся, что чем больше bloat, тем больше неэффективность.

>Повторяю - это бред собачий.

что "бред собачий"? Что стек Ява-технологий сам по себе слишком тяжел для простых проектов? Что за деревьями этих технологий не видно леса? Что надо принимать во внимание эффективность реализации "платформы", а не успокоиться на том, что есть отдельный сервер, на котором "не жалко лишние 30 Мб на то, ещё 60 Мб на сё, ещё 30% cpu на вот это?"

Посмотри на тот же Compiere или MBSA. В MBSA например отчеты рисуются через BIRT. Там именно такой зоопарк со стеком технологий. Чтобы просто "реализовать новый отчёт в КИС" нужно написать сам код, создать дескриптор, задеплоить его на сервере приложений, зарегестрировать в "платформе", перегрузить кеш сервера приложений или сам сервер. При этом при запуске "отчёта" периодически вылетают exception'ы то ли в Hibernate, то ли в самой платформе генератора отчётов, при всяких странных граничных условиях (нету документов, отбор другой, и т.п.), писать сам отчет предполагается в терминах ява-объектов платформы и словаря метаданных платформы, а не объектов предметной области.
Собственно, проблема не в том, что для создания простого отчета нужно несколько технологий, а скорее в реализации: нету оснастки которая автоматизирует *все* шаги, и получается шаманство с ручной сборкой хуже autoconf/automake.
По сравнению с той же 1С это не сильно сложнее, но нуднее на порядок.