Жаба и понты

Быть может, в той нише был труъ-энтерпрайз кобол.

жабакодеры обычно получают бабок в среднем больше прочих => ЧСВ

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

Понтуются все. Но на самом деле единственный Ъ-язык это Perl, а остальное всё УГ.

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

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

Оо! Это я видел собственными глазами в исполнении одного итальянца-макинтоида. Маки явно что-то модифицируют в ДНК. Был человеком - и вдруг "раз" ни с того ни с сего и уже макинтоид.

>и уже макинтоид.

вы сделали 9 ошибок в слове гей

Это присуще любой группе людей. Самовлюблённые идиоты есть везде.

> Понтуются все. Но на самом деле единственный Ъ-язык это Perl, а остальное всё УГ

может ты хотел сказать LISP? если уж one true - то это LISP.

кстати изучать начал только недавно, но ЯП однозначно хороший.

Перл то Ъ? Да в нем газзилион библиотек и большинство - кривые недоделки.

Это он просто понтуется.

Ну пускай понтуется, а правда такая что у нас в конторе всю обработку CSV и XML переписали на яве. Хотя PERL де-факто стандарт от самого основания. А почему? А потому, что в яве есть продакшн библиотеки, которые "делают хорошо", а в перле сплошные недоделки. Перл потихоньку уходит в нишу скриптов.

На самом деле феномен имеет место быть. Почитайте педивикию - статьи по C++, PHP, Perl, даже галимому дотнету состоят из конкретных примеров и понятной терминологии, а по Жабе, особенно EE - сплошной маркетинговый понос (транзакциираспределённыекомпонентысерверприложениймасштабируемость) и швыряние непонятными аббревиатурами. Сама-то эта Java EE - не разбери-поймёшь, что туда входит, тогда как для ME и SE всё чётко и понятно.

Когда мне надо было парсить XML на яве, я за 5 минут нашол море вменяемой документации, примеров, готовых решений и т.п.

>Сама-то эта Java EE - не разбери-поймёшь, что туда входит

Всё. Вообще всё.

>может ты хотел сказать LISP? если уж one true - то это LISP.

Говорил же - понтуются.

Это - да.

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

А когда есть какая-то "технология, предназначенная для того, чтобы всё было зашибись", тут-то и начинается фрустрация...

> Я, например, в своё время одних только ORM нашла с десяток

чтоб привести из к общему знаменателю, сановцы и пишут спеку.

> Когда мне надо было парсить XML на яве, я за 5 минут нашол море вменяемой документации, примеров, готовых решений и т.п.

Шаман, это не показать. По парсингу XML в инете я нашел наверно 2 или 3 различных библиотеки с отличным описанием, все это для питона. Это же не показатель того, что язык хорош.

Да, парсер отжирает около 1 Гб памяти, но(!!!) он дампит в gzip архив приблизительно 200-400 Мб данных. А представь что бы было, если бы это была Джава. Уже страшно ? :)

> Да, парсер отжирает около 1 Гб памяти, но(!!!) он дампит в gzip архив приблизительно 200-400 Мб данных

он че, целиком ее хавает? SAX не в моде уже?

Вот и пример, только что найденный в педивикии: http://en.wikipedia.org/wiki/Java_Metadata_Interface (вообще-то искала Java Message Interface, про который краем уха слышала от понтоватого жабщика, что он вроде как в сотовых компаниях применяется для обработки SMS).

Вся статья целиком:

> Java Metadata Interface (JMI) is a platform-neutral specification that defines the creation, access, lookup and exchange of metadata in the Java programming language. The JMI specification was developed under the Java Community Process and is defined by JSR 40.

> JMI is based on the MOF specification from OMG, and supports exchanging metadata through XMI. The MOF/XMI specifications are used for the exchange of UML models. Essentially, JMI can be used to write tools in Java for manipulating UML models, which can be used in Model Driven Architecture and/or Model Driven Development.

Ведь это же тёмный лес, товарищи!

Что такое метаданные, я, слава богу, представляю. Но зачем потребовалось городить отдельный стандарт представления метаданных именно для Жабы вместо открытого языконезависимого стандарта? Что такое JSR? Что такое MOF? Что такое OMG? Что такое XMI? Для кого городится это всё? Какое отношение к метаданным имеет UML? Что скрывается за вумными, веющими ынтырпрайзом словами "Model Driven Architecture"? Где реально применяется это всё - в сферических закрыто-жабовых средах в вакууме?

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

> он че, целиком ее хавает? SAX не в моде уже?

а зачем он тут ? скрипт линейно проходит все поля и добавляет данные в СУБД или дампит.

> скрипт линейно проходит все поля

и жрет гиг памяти? а пару строк xml-ки покажешь?

> Что такое JSR?

вообще-то это известная вещь: Java Specification Requests. гуглится тут же. по твоим вопросам видно, что ты немного не в теме ЕЕ. стоит ее поизучать, и все вопросы отпадут.

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

> и жрет гиг памяти? а пару строк xml-ки покажешь?

гиг памяти это вместе с MySQL :)

<node>
 <id/>
 <name/>
 <pictures>
   <image name=param />
 </pictures>
</node>

вообщем там еще куда полей ... 

не, ну ява гиг на такой xml не отъест. если саксом написать. если домом, то легко.

> не, ну ява гиг на такой xml не отъест. если саксом написать. если домом, то легко.

она умеет ражимать gzip без использования памяти и не будет нагружать MySQL сервер ?)

> она умеет ражимать gzip

пробовать надо. вообще работа с архивами (тем же зипом, например) сделана через потоки, читаются они последовательно, то есть в память не срут. как конкретно работает gzip - я хз, не пробовал. Но с зипом все нормально

> я за 5 минут нашол море вменяемой документации, примеров, готовых решений и т.п.

Андрюш. Свои домашние проблемы с exifом оставь дома! Когда в жизни на жабе парсишь говнище вроде XML и просишь под это дело еще две нетры (у нас резервирование как отче наш), тебя спрашивают "Дима, а ты не слишком ох..ел, или ты думаешь что бюджет резиновый ?"

Сакс не в моде... куда привычней для ООП дом структурой поиграть :)

Неа, не представляешь.

OMG members voted to establish the MDA as the base architecture for our organization's standards in late 2001. Software development in the MDA starts with a Platform-Independent Model (PIM) of an application's business functionality and behavior, constructed using a modeling language based on OMG's MetaObject Facility (MOF). This model remains stable as technology evolves, extending and thereby maximizing software ROI. MDA development tools, available now from many vendors, convert the PIM first to a Platform-Specific Model (PSM) and then to a working implementation on virtually any middleware platform: Web Services, XML/SOAP, EJB, C#/.Net, OMG's own CORBA, or others. Portability and interoperability are built into the architecture. OMG's industry-standard modeling specifications support the MDA: The MOF; UML, now at Version 2.0; the Common Warehouse Metamodel (CWM); and XML Metadata Interchange (XMI). OMG Task Forces organized around industries including Finance, Manufacturing, Biotechnology, Space technology, and others use the MDA to standardize facilities in their domains.

> Сакс не в моде... куда привычней для ООП дом структурой поиграть :)

прочитал как секс. задумался

> пробовать надо. вообще работа с архивами (тем же зипом, например) сделана через потоки, читаются они последовательно, то есть в память не срут. как конкретно работает gzip - я хз, не пробовал. Но с зипом все нормально

и что с потоками ? все равно нужно разжать архив, пусть 200 Мб данных, парситься это все дело около 1-2х секунд и вставляется в MySQL. Весь расход памяти идет на хранение данных и на вставку данных :) Конечно на сервере жаловаться на минимум 1 Гб оперативы - бред, ибо там 16 ГБ, но все же.

Короче, все можешь не читать. Ключевые слова такие maximizing software ROI. Это своего рода Грааль для разработки очень крупных бизнес-проектов.

Я никогда не использовала SAX. Ну не подходит событийно-проталкивающая модель для древовидных документов XML. Если уж и использовать XML-парсер типа "по элементу зараз", то StAX.

Я использую DOM даже для простых документов, потому что так привычнее для веб-быдлоко^Wразработчиков. Если клиент JavaScript обменивается XML-данными с сервлетом, то и там и там проще сделать одни и те же getElementById() и прочая. В конце концов, браузер-то использует DOM, и никто на оверхед не жалуется.

Да я не "немного" не в теме, я вообще не в теме! Как тут быть в теме, если я из двух книг (одна из которых так и называлась "J2EE") и кучи сайтов не смогла понять, что такое EJB, где их используют и для чего, чем они такие ынтырпрайзные и как они соотносятся с "обычными" JavaBeans, которые не ынтырпрайзные?

При этом, пока в этих книгах речь идёт про сервлеты, JSP, JDBC и т.д., всё достаточно стройно и понятно. Как переходят к EJB, так хоть вешайся.

переделал все на lxml, сейчас вот дампится - 400 Мб памяти использует ... сам дамп уже 1.9 Гб весит :)

не те книги читаешь. я например читал о'релли, сразу все понял

O'RLY?

O'Reilly

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

Можете объяснить мне, тупой и недалёкой, что такое EJB и зачем они нужны?

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

> Можете объяснить мне, тупой и недалёкой, что такое EJB и зачем они нужны?

Вкратце, это такие распределённые компоненты, которые деплоятся на сервер приложений, содержащие так называемую "бизнес-логику". Имеют свою тредовую модель, возможность автоматического управления транзакциями и массу ограничений (google://ejb restrictions). Хороши только в случае, когда действительно нужна распределённость. В целом - не нужны. Спринг заменяет их в 99% случаев.

Да, забыл добавить, самая лучшая книга по EJB наз-ся "J2EE Programming without EJB" by Rod Johnson. :)

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

А может, мне просто не приходилось сталкиваться с проектами такой сложности - тогда мне эти EJB тем более ни к чему. Хотя видела я студентов, которые умудрились применить EJB в велосипедистом веб-форуме на JSP, потому что им препод за это оценки повышал.

И таки какое отношение они имеют к "неынтырпрайзным" JavaBeans?

> И таки какое отношение они имеют к "неынтырпрайзным" JavaBeans?

в ejb3 entity - это обычные POJO

Ещё один яркий пример реплики ынтырпрайзного жабщика.

Хорошо хоть я ранее прочитала, что такое POJO, а то бы продолжала орать про птичий язык.

ппц, POJO, MOJO, EJDKLMN, ухожу в монастырь. Точка.

POJO - это значит Plain Old Java Object. То есть самый обычный Java-объект, в противоположность объектам, подчиняющимся определённым соглашениям (вроде реализации определённых интерфейсов, наследования определённых классов, наличия определённых аннотаций и т.д.).

В .NET есть аналогичный термин POCO (Plain Old CLR Object), правда, он употребляется скорее в шутку - это намёк на видимую сложность жаботехнологий.

> И таки какое отношение они имеют к "неынтырпрайзным" JavaBeans?

Ни-ка-ко-го.