j2ee vs Delphi vs C++

Расскажи про переносимость и вообще про энтерпрайзность. Можешь всякий маркетоидный бред от сана^Wоракла скопипастить.

кресты на сервере - сборка мусора вжых ( долго думать, долго тестировать, нафиг

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

то, что у тебя больше опыта в java - весомый аргумент


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

Часть для создания и обработки документов на Perl'е, часть для сетевого взаимодействия на Эрланге.

Лучше сразу начинать с j2ee (именно для таких целей оно и задумывалось).

Delphi - умерло
C++ -слишком банально
.net - не нужно
java - терпимо
lisp - наш вариант

j2ee это не язык, это инфраструктура, епт. Расскажи заказчику во что ему обойдется трехзвенка на плюсах и сколько человеколет на это понадобится.
Тупо купить сервер в 2 раза мощнее обойдется во много раз дешевле. а если не юзать гибернейты-топлинки, а jdbc то и сервер мощнее не нужен будет.
Ну и про безопасность можно рассказать. Что будет стоить дырка в сервере приложений, утечки и тд...
Вообще, по-моему, заказчик хочет «толстого клиента» если уж на плюсах. Не представляю сколько времени и усилий понадобится свой сервер приложений забабахать. Либо он нифига не соображает. Тогда остается самое легкое - 2-Tier vs 3-Tier разницу показать

Delphi - умерло

не умерло оно еще

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

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

это точно

У Вас попаболь, что Вам-таки не удалось устроиться на приличный оклад жабакодера?

А что Вы имеете против Java 6 SE + Spring Framework?

>> Delphi - умерло

не умерло оно еще

Это точно.

Среди народных умельцев, не знающих ни одного шаблона проектирования, кроме «волшебной кнопки», не померло.

Вам хочется писать весь стек java ee самому?) Он у вас в любом случае получится)

>а если не юзать гибернейты-топлинки, а jdbс
это Вы мощно загнули)

то что delphi мертв мне как бы понятно и так, но если будут разумные доводы против него, то я тока за

А мужики то из Emacadero и не знают... :)

Нет, за меня напишет Род Джонсон.

EE нужно только для распределённых транзакций.

И даже бины EE я тестирую в Spring - просто удобно.

Я тоже не знаю, что такое «Emacadero».

Я знаю компашку Embarcadero aka Embarcadero Technologies.

К логопеду!

К логопеду!

Смойся в унитазе^W^W из треда, клоун.

Вы о чем? Я вообще-то в поддержку Явы выступил.

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

> А что Вы имеете против Java 6 SE + Spring Framework?
это мой выбор

Ужас! Столько слов, и все льются, как нескончаемый поток дерьма...

Я знаю компашку Embarcadero aka Embarcadero Technologies.

не удивлюсь если это аутсорсники работающие в каком-нибудь подвале в Туле как и DevExpress

Ну так и расскажи заказчику про то, что жаба в данном случае позволяет на изобретать кучу велосипедов и предоставляет кучу готовых, бесплатных и оттестированных компонентов в отличие от плюсов с дельфями. Ну и про переносимость в отличии от дотнета расскажи (хотя если подразумевается rich client, то я бы не парил себе мозг переносимостью и взял нет).

И, кстати, еще маленький совет: не бери j2ee. Возьми spring + нужные библиотеки для messaging, connection pooling etc + сборку мэйвеном всего этого и будет тебе счастье.

Если кто-то не осилил расшифровку пары аббревиатур, то это его личные половые трудности.

Я не про расшифровку, я про то, что в одном топике употреблено такое количество дерьма: ява, делфи, мастдай, .нафигненужно. Ужас!

альтернативы перечисленному дерьму (ну кроме разве что дельфей, которые давно сдохли) в студию плз.

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

1 - на чем писать веб морду? 2 - куда девать серверную логику, всякие там интеграции и остальную ботву? 3 - как из веб морды на клиенте работать с эцп? 4 - что делать с заказчиком, если он готов платить деньги за формочки? 5 - если ты не программист, то откуда взялось желание влить половник дерьма в сугубо специфичную беседу?

1 - на html'е, естественно (с привлечением яваскриптов); 2 - языков полно (С, плюсы, лисп тот же...); 3 - а как с SSL-ключами работают?; 4 - goto winfaq; 5 - тролль же.

1 - и чем этот html генерировать? а яваскрипт с чем будет общаться?
2 - на голом С система будет писаться лет 10. Лисп говно. Плюсы вообще феерическое говно.
3 - как ты документ (.doc конкретный) подпишешь из браузера?
4 - и бабло туда уйдет вместе с заказчиком.
5 - оно и видно

Дык, talks же. Этот раздел как раз для флейма всякого (и офтопика вроде вашего) :)

а кто-то против флейма и оффтопика?

Вдарим флеймом по офтопику! :)

Дык! правда тут как-то тухло, даже на вброс про фееричную говнистость плюсов и лиспа никто особо не отвечает.

> Встал вопрос о разработке системы электронного документооборота. С ЭЦП (сертифицированную естественно)

Платформа определится наличием инструментальных средств для работы с гостовыми эцп. Как с этим обстоит в openssl? Какие переносимые sdk предлагает криптопро? А дальше, хоть на баше...

Какой вброс - такие и ответы.

Перечисли список подсистем Java EE. Потом обьясни зачем они нужны, а они таки нужны. А потом скажи что такого на С++ нет и не предвидится. На .NET нет, но предвидится, но тут можно долго распространяться о vendor lock in в стиле «А что вы будете делать если посреди разработки столкнетесь с багом/ступором? В Java поищете другую реализацию спецификации. В .NET такого нет, или от МС или вдоль»

И да, Delphi - антипаттерн

Документооборот с ЭЦП я бы забацал на GWT + ActiveX. На сервере Hibernate, GWT собственно.

Отвечая сразу всем

Гуя у системы практически не будет...
В качестве клиента будет выступать модифицированный почтовый клиент.
По сети это будет работать через smtp + pop3.

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

exim --- потому-что есть и под винду (но еще не пробовал)

Гуй только для админских нужд: CRUD пользователей и еще кой каких настроек.

Расскажи про переносимость и вообще про энтерпрайзность.

Насколько я понял чела не очень то заботит переносимость.
А вот насчет энтерпрайзности... Хотелось бы озвучить список широко известных продуктов сделанных на j2ee (и от которых народ не плюется)

Ну так и расскажи заказчику про то, что жаба в данном случае >позволяет на изобретать кучу велосипедов и предоставляет кучу готовых, бесплатных и оттестированных компонентов в отличие от плюсов с дельфями. Ну и про переносимость в отличии от дотнета расскажи (хотя если подразумевается rich client, то я бы не парил себе мозг переносимостью и взял нет).

Ну вот и хотелось бы получить от сообщества ссылок на вменяемые и не устаревшие обзорные статьи и комментарии...

То что находится в гугле либо старое либо просто неадекватное...

И, кстати, еще маленький совет: не бери j2ee. Возьми spring + нужные библиотеки для messaging, connection pooling etc + сборку мэйвеном всего этого и будет тебе счастье.

Про spring почитаю, спасибо

Платформа определится наличием инструментальных средств для работы с >гостовыми эцп. Как с этим обстоит в openssl? Какие переносимые sdk >предлагает криптопро? А дальше, хоть на баше...

С этим в java как раз все хорошо. Есть как минимум два уже проверенных мной провайдера: КриптоПРО JCA и LirJCE
Еще под виндой можно заюзать SunMSCAPI или SunPKCS11. Но последние два придется допиливать (из коробки они не знают о ГОСТе)

В java кстати, кривлекает легкая смена криптоядра.
Буквально парой строчек в конфиге...

>Документооборот с ЭЦП я бы забацал на GWT + ActiveX. На сервере Hibernate, GWT собственно.

Ну какбы CAPICOM MS объявил мертвым.
Да и не нужен он учитывая наличие нормальных библиотек.
ну а GWT не в тему, так как гуя почти не будет...

Кстати еще один вопрос:
Приходилось ли кому-то здесь работать с ЭЦП сертифицированными средствами?
Читал что не достаточно просто использовать «правильные» криптоядра (тот же КриптоПРО), но еще нужно пройти проверку в ФСБ на корректность их встраивания...

>Приходилось ли кому-то здесь работать с ЭЦП сертифицированными средствами?
да

Читал что не достаточно просто использовать «правильные» криптоядра (тот же КриптоПРО), но еще нужно пройти проверку в ФСБ на корректность их встраивания...

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

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

Цитата: Круг российских разработчиков, занимающихся кодированием алгоритмов ГОСТ, невелик – крупных производителей не более десятка. В то же время потребность в защите данных имеется практически в любом приложении, поэтому разработчики пошли путем разделения обязанностей: созданием библиотек шифрования занимаются лицензиаты ФСБ, а встроить эти проверенные спецслужбой библиотеки в свои продукты могут практически любые производители ПО. Однако даже в этом случае не избежать процедуры проверки на корректность встраивания защиты. Иначе говоря, рекомендация Стефена Фаррелла о использовании только проверенных библиотек в России закреплена на законодательном уровне.

Источник: http://www.osp.ru/os/2010/05/13003058/

>Это для разработки криптографического софта нужна лицензия.

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

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

В общем то единственный реальный аналог - .NET.

Вообще говоря J2EE устарело ещё лет 10 назад, сейчас актуально JEE, а многие считают, что всякие спринги да хибернейты ещё лучше.

Саныч, ты?

А если серьезно, то J2EE - это кроссплатформенность, сопровождаемость и безопасность написанного кода «искаропки».

Lotus Notes/Domino. Зато нескучно будет :)

> Дык! правда тут как-то тухло, даже на вброс про фееричную говнистость плюсов и лиспа никто особо не отвечает.

так забанят же. Меня тут недавно на -40 скора жахнули, матерился потом целый месяц, на всякую шнягу в general отвечал...

FreePascal+Lazarus