Архитектор-кун снова в треде, всем в машину! Не скучали без меня?

Ну и да - анонимус, что скажешь про этот доклад?

В трёх словах — клоунада, неосиляторство и баттхёрт.

При виде abstract'a «ESB, EJB, MQ, rule engines, да всё это нинужно» я призадумался. После слов «я не архитектор, зато с архитекторами конфликтовал, и вообще я клёвый чувак» — я стал недоумевать. После слова «говно», произнесённого с трибуны в присутствии аудитории, желание слушать отпало окончательно.

Вообще, я давно заметил, насколько чётко разработчики делятся на две категории. У очень многих (составляющих низшую касту) вызывает попоболь одна мысль о том, что придётся осваивать какую-то крупную новую технологию (например, ORM или MQ). Они предпочтут убить кучу времени со старым добрым SQL через JDBC, а асинхронный обмен навелосипедить через сокеты.

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

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

Еще раз, я не признаю религию осиляторства. Если задачу можно решить без осиляторства чего-то, то ее нужно решать без этого.

Так ты и лес валить пойдёшь двуручной пилой? Ведь задачу можно решить без осиляторства бензопилы!!!111

Сдаётся мне, мой юный друг, по вышеозначенной классификации ты наглухо принадлежишь к первой категории. И предпочтёшь фигачить SQL руками, в то время как конкуренты, быстренько освоив ORM, опередят тебя, перехватят заказчиков и разбогатеют. Потому что смогут разработать систему быстрее, она будет более качественной, производительной (за счёт кеширования) и поддерживаемой.

Но тебе на это наплевать, правда ведь? Главное, что «если задачу можно решить без осиляторства ORM, её надо решать на голом SQL».

даже не знаю что сказать

Мой совет — лучше ничего не говорить.

Особенно когда абсолютно некомпетентен в теме дискуссии.

YOBA SQL DSL

Итак, рассмотрим, что же такое SQLKorma и насколько корректно сравнение его с Java ORM. Мы будем рассматривать технологии Java Persistence Architecture (JPA) и Java Data Objects (JDO).

1. Отображение таблиц реляционной СУБД на сущности языка.
Реализация в JPA/JDO: аннотации, XML-маппинг, программная (JDO 3.0).
Реализация в SQLKorma: программная (defentity).

2. Язык запросов (ориентированный на сущности) и его трансляция в SQL.
JPA/JDO: JPQL/JDOQL, Criteria API (программное конструирование запросов)²
SQLKorma: eDSL (подмножество host-языка)

(Собственно, на этом сходства и кончаются, начинаются различия.)

3. Кэш.

Немного комментариев. Кэш в Java ORM работает он следующим образом. Сущности, к которым недавно происходило обращение, кэшируются в памяти. Например, одна нить загрузила набор сущностей. Вторая нить делает запрос на загрузку одной из тех сущностей, и получает кэшированный объект. Если вторая нить модифицирует сущность, то первая нить увидит изменение без перезагрузки объекта из базы. В SQLKorma нет ни намёка на кэширование. Я уже не говорю о том, что для Java ORM существует стандартное API для подобных кэшей и несколько pluggable реализаций, в том числе распределённых: удалённая копия приложения получит обновление кеша, не дожидаясь, пока завершится репликация СУБД, и не перезагружая объекты из БД.

JPA/JDO: кэш 1-го уровня (грубо говоря — кэш уровня транзакции), кэш 2-го уровня (грубо говоря — кэш уровня приложения), распределённый кэш (Oracle Coherence, Cacheonix, EHCache, SwarmCache).
SQLKorma: (не поддерживается)

4. Объектные транзакции.

...или, точнее, транзакции в семантике языка (в противоположность SQL-транзакциям). В Java ORM это действует следующим образом. Если вы в рамках транзакции загружаете набор сущностей, вызываете бизнес-метод, который произвольным образом меняет (или не меняет) сущности, то при commit'е система автоматически отслеживает изменившиеся сущности и обновляет их в хранилище. Пример:

@PersistenceContext EntityManager em;
em.begin();
// Здесь происходит загрузка сущности и всех связанных с ней сущностей
MyEntity obj = em.find(MyEntity.class, id);
// Бизнес-метод модифицирует как саму сущность, так и часть связанных с ней
obj.businessMethod();
// Транзакция записывает в хранилище изменившиеся сущности
em.commit();

В SQLKorma нет ничего, что хоть отдалённо напоминало бы подобное поведение.

JPA/JDO: поддерживается
SQLKorma: не поддерживается

5. Non-SQL источники данных.
JDO (DataNucleus): Excel, OOXML, ODF, XML, HBase, MongoDB, AppEngine/DataStore, Neo4j, JSON, Amazon S3, GoogleStorage, LDAP, NeoDatis
SQLKorma: (не поддерживается)

6. Типы отношений.
JPA/JDO: uni- and bidirectional; one-to-one, one-to-many, many-to-one, many-to-many, embedded entity
SQLKorma: one-to-one, one-to-many

А теперь то же самое в виде таблички:

+---------------------+----------+--------------+
|                     | SQLKorma | JPA/JDO      |
+---------------------+----------+--------------+
|Entity mapping       | Yes      | Yes          |
|Query language       | Yes      | Yes          |
|Local Caching        | No       | Yes; 2-level |
|Distributed Caching  | No       | Yes          |
|Transactions         | No       | Yes          |
|Non-SQL support      | No       | Yes          |
+---------------------+----------+--------------+

Выводы.

SQLKorma — студенческое поделие. С натяжкой можно считать инструментом, слегка упрощающим жизнь при разработке двухзвенных решений. Напомню, «двухзвенка» — архитектура, при которой приложение соединяется напрямую с СУБД и работает в реляционной семантике (таблицы/строки/поля). Таково, например, большинство веб-сайтов на PHP¹. Двухзвенная технология способствует довольно низкой производительности разработчика (работа в семантике БД вместо семантики объектов языка), плохо масштабируется, не реализует security restrictions, требует костылей (напр., memcached) для приемлемой работы, но проще для понимания новичками.

Для создания трёхзвенных архитектур SQLKorma не пригодна, так как не реализует необходимых механизмов. Поэтому сравнение SQLKorma с Java ORM является некорректным и доказывает, что сравнивающий абсолютно некомпетентен в области программных систем уровня предприятия, а также не имел дела с крупными распределёнными гетерогенными проектами. Скорее всего, является школьником, наслушавшимся ЛОРовских троллей и решившим, что небыдлоязык (Clojure в данном случае) автоматически произведёт его в сан элитариев, лобковые волосы станут мягкими и шелковистыми, и все девушки ЛОРа тут же падут к его тощим ногам.

Но маргинальный язык не делает из школьника-девственника «элитария». Маргинальный язык делает из школьника-девственика школьника-девственика-задрота.

¹ формально, для PHP есть слой абстракций БД (PDO) и даже ORM разной степени годности. Но PHP-кодеры традиционно используют «проверенный» метод: использование mysql_* функций и склеивание SQL-запроса из кусков строк.
² «Вражеские технологии» (C# с ADO.NET или NHibernate) в дополнение к query language и criteria API поддерживают ещё и подмножество языка (LINQ).

Цитата: «Я хаскелист, это так п*здато, что меня хотят во всех банках, но это выше меня, поэтому я их посылаю.»

(исправлено во имя справедливости)

Но ведь ничто не мешает мне заявлять то же самое, верно? Утверждение неверифицируемо. Пруфов нет. А против — то, что Haskell маргинальный язык с очень узкой нишей применения, и эта ниша к банкам никакого отношения не имеет.

Ну понятно, что теперь что не скажи - в ответ «божья роса» услышишь. Вот и поговорили.

Правда, гуй вообще в принципе не нужен, но это уже другая история.

Уж снёс из системы иксы и выпилил фреймбуфер?

а чем объекты заменяются?

Функциональным программированием.

Ну это просто царь-пушка!

Знаешь ли ты основное предназначение ООП? Открою секрет. Это — information hiding, separation of concerns, low coupling. Перевожу: в ООП бизнес-логика чётко концентрируется в соответствующих модулях и легко локализуется. Модули (классы, пакеты) максимально независимы друг от друга (за счёт использования интерфейсов и паттернов проектирования), и каждый модуль отвечает только за свою задачу. Парадигма устроена так, что при грамотном проектировании изменения в одном модуле в принципе не могут поломать поведение других.

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

Впрочем, я могу ошибаться.

В таком случае объясни мне, каким образом функции высшего порядка, отсутствие сайд-эффектов и каррирование (а ведь это как раз то, что отличает функциональное программирование от процедурного, ты ведь знаешь это, не так ли?) призваны решить задачи information hiding, separation of concerns и low coupling. Спасибо.

Думаешь я идиот? Решить задачу я естественно подразумваю в минимальный срок. С ормами осиляторство возникает только в сложных случаях. В простых оно годно. А для сложных я предпочитаю raw sql, но таких запросов мало. А есть любители писать по пять этажей дополнительных аннотаций, зато все через hql, осиляторы, блин.

Думаешь я идиот?

Я оптимист и проповедую презумпцию неидиотизма. Но ты своими утверждениями иногда будишь во мне пессимиста...

Решить задачу я естественно подразумваю в минимальный срок.

В этом твоё слабое место. Тебя интересует только текущий момент. Но если бы ты был более опытен и дальновиден, то сказал бы себе: «Ага! Здесь клиент 100% захочет гибкую кастомизацию на лету. Поэтому мне стоит потратить сегодня NN часов на освоение и прикручивание rules engine (вариант: scripting language), чем потом на каждый клиентский чих хардкодить новое правило, перекомпилировать и передеплоить систему».

Собственно, подобная дальновидность, прозорливость, стратегическое мышление — это то, что отличает Архитектора от рядового разработчика.

Собственно то, о чем ты говоришь есть бич индустрии. Святая уверенность, что ты можешь предсказать плохо предсказуемые требования. Отсюда растет излишняя сложность. Лид-архитекторы у нас как раз занимаются тем, что не дают пионэрам навроде тебя вкручивать излишне обобщенные решения и заставляют следовать YAGNI. Это и отличает архитектора от пионэра.

А конкретно с прикручиванием rules engine когда его явно не просил заказчик, без обид, боюсь ты бы вылетел с испыталки, если бы тебя вовремя архитектор не тормознул бы.

Преимущества:

Запрос является обычной функцией (select).
Позволяет в выражении использовать коллекции языка (client-ids - может быть вектором или списком).
Контроль над структурой запроса (строки в named query в джаве это просто ппц)
Автодополнение имен таблиц и полей (table-client, client-id, client-phone, client-email) и проверка их на этапе компиляции, что удобно, предотвращает очепятки и является защитой от расхождения с именами в БД.

У eDSL в который запихивают другой DSL (в данном случае SQL) есть принципиальная проблема. Вообще _правильный_ DSL это способ короткой (очищенной от несущественных деталей) записи для сложной предметной области, предназначенный для профессионалов в этой области.

Когда один DSL(первый) упаковывают во второй, значит либо признают, что используют первый DSL как стрельбу из пушки по воробьям, либо вешают на пользователя второго DSL _все_ проблемы, ради решения которых создавался первый, при этом специалиста по проблемам первого DSL могут отморозить проблемы второго (а если их нет - то зачем было второй DSL создавать?).

В любом из этих случаев сложность не прячется, а накапливается. Это с натяжкой допустимо, если разработчиков мало и особенной специализации у них нет. Но если потом потребуются высококвалицированный узкий специалист, то от одного из этих DSL придется срочно отказываться. А если два разных специалиста - то переписывать все с нуля.

Есть SQL, есть HTML, есть CLIPS, но нафига все-все-все eDSL'ить в кложуру (другой супер-пупер мета-язык)? Чтоб при удачном стартапе раз'eDSL'ивать обратно? Или чтобы разработчик на гусенечном велосипеде на подводных крыльях с прямоточным РД утонул в деталях?

А конкретно с прикручиванием rules engine когда его явно не просил заказчик

Заказчик может не знать (и, следовательно, не просить) об ORM, SQL, XML и еще куче всего. Но их ты почему-то прикручиваешь.

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

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

По крайней мере я его понял именно так.

Выгребание из хэшмапа — O(log(n)) (в нормальных языках, разумеется, не знаю насчет кожуры).

В clojure доступ к значению хэшмапа - O(log32 n)

Спор двух пионэров-недоучек. А ну марш оба на пары.

Чтобы совсем добить функциональную сволоту, спроси их про юнит-тесты. Обычно на этом месте они сдуваются со свистом.

Уж снёс из системы иксы и выпилил фреймбуфер?

Их там и не было никогда.

А что не так с юнит-тестами и функциональными языками?

Не вешай лапшу на уши, в интерпрайз мире функциональную декомпозицию используют почти всегда. Ну там сервисы + тупые модели без логики. Объектный дизайн домена (сейчас это называют DDD) нынче экзотика. И ничего, все жрут и улыбаются.

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

Уверенность не «святая». Она диктуется не Боженькой, а многолетним опытом.

плохо предсказуемые требования

Тебе требования кажутся «плохо предсказуемыми» в силу твоего скудного опыта. Впрочем, это не девелоперская задача — предсказывать требования (и вообще делать что-либо с требованиями, кроме как «реализовывать» или «объяснять, почему они не могут быть реализованы»).

Собирать требования, систематизировать, предсказывать и т.п. — задача бизнес-аналитика. Ты им не являешься.

Отсюда растет излишняя сложность.

Опять-таки, ты специалист малоопытный (и, давай смотреть правде в глаза, слабоватый). Поэтому ты не можешь адекватно оценить сложность системы (и не должен этим заниматься, так как ты — исполнитель).

Но квалифицированный специалист понял бы, что сложность — оправданная.

Лид-архитекторы у нас как раз занимаются тем, что не дают пионэрам навроде тебя вкручивать излишне обобщенные решения

Следовательно, ваши «лид-архитекторы» — свежие выпускники заборостроительного, или же вы штампуете типовые примитивные проекты (ну, либо и то, и другое вместе). Кстати, «у вас» — это где? Если не секрет, конечно.

заставляют следовать YAGNI

Этот и другие принципы XP позволяют небольшой команде программистов кое-как клепать проекты в отсутствии квалифицированного архитектора. Таким образом, либо ваши архитекторы действительно ни на что не годны, либо project management некомпетентен, т.к. нахватался модных баззвордов («eXtreme Programming») и неверно интерпретировал их.

А конкретно с прикручиванием rules engine когда его явно не просил заказчик...

Преподаю тебе бесплатный урок project management'а.

Заказчик не просит rules engine. Если заказчик просит rules engine — как минимум, нужно вежливо покивать ему, как максимум — взять на карандаш.

Решение об использовании rules engine (как и других механизмов) принимают архитектор и технолог, на основе данных, собранных аналитиком. Если бы ты был руководителем проекта, то было бы непростительной ошибкой слепо реализовывать то, что требует заказчик (в отношении заказчиков, увы, «презумпция неидиотизма» не действует). Но поскольку ты — не руководитель, то это никакая не ошибка.

А просто глупость, ляпнутая на форуме.

Если задачу можно решить без осиляторства чего-то, то ее нужно решать без этого.

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

Врать не буду, всё видео целиком я не осилил (так что всё вышесказанное — IMHO на основе abstract'а и нескольких минут видео).

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

Спор двух пионэров-недоучек.

Что не так? Можешь аргументированно опровергнуть какое-то из высказываний? Или так, вонюче бзднул и убежал.

Цитата: «Я хаскелист, это так п*здато, что меня хотят во всех банках, но это выше меня, поэтому я их посылаю.»

Цитата была вырвана из какого-то обсуждения не для доставления Вам батхерта, извините :)

Пруфов нет. А против — то, что Haskell маргинальный язык с очень узкой нишей применения, и эта ниша к банкам никакого отношения не имеет.

А у Вас пруфы, стало быть, есть? Приводите.

Их там и не было никогда.

Ого! И как живётся благородному дону? Vim, Emacs, lynx, pine, finch, видео через libcaca? :)

Не вешай лапшу на уши, в интерпрайз мире функциональную декомпозицию используют почти всегда.

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

Объектный дизайн домена (сейчас это называют DDD) нынче экзотика.

Ты снова спутал OOD с DDD. Это разные понятия. Но, в связи с общей некомпетентностью, даже не знаю, следует ли тебе засчитывать слив.

Чтобы совсем добить функциональную сволоту, спроси их про юнит-тесты. Обычно на этом месте они сдуваются со свистом.

А ну-ка, надуйтесь посильнее, что там с юнит-тестами?

А у Вас пруфы, стало быть, есть? Приводите.

Пожалуйста.

Пожалуйста.

wtf? Какой-то хомяк Васи Пупкина и он на нем что-то написал? Написанное на заборе и то убедительно. Доказательства давай.

http://www.haskell.org/communities/12-2007/html/report.html#sect7.1.2

wtf? Какой-то хомяк Васи Пупкина и он на нем что-то написал?

Если для Вас статистика крупнейшего в России и СНГ employment сайта — «какой-то хомяк Васи Пупкина», то я за Вас начинаю беспокоиться.

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

2007
2013
2007
2013
2007
2013

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

Перепутана причина со следствием. Стрелка импликации должна указывать в обратную сторону.

http://stackoverflow.com/questions/107464/is-javascript-object-oriented

ответ с галочкой, последний абзац.

То, что в Barclays нужны были хацкелисты, означает лишь одно.

Что в своё время в Barclays на ведущую техническую должность взяли чьего-то зятька (а вы что думали — только у нас блатота процветает при эмплойменте в банки?) Типа, «о, зятёк, да ты ж у нас по информатике, да? Айда к нам, IT-отдел возглавлять!» А зятёк оказался яйцеголовый сцаентист, который до этого просиживал штаны в институте и задрачивал зигохистоморфные препроморфизмы, а нормальных ЯП в глаза не видел.

Только и всего.

ответ с галочкой, последний абзац.

Гм... а ведь верно. Значит, тут не импликация, а эквиваленция.

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

Если заказчик разбирается в домейне? // К.О.

1) тогда всё становится существенно хуже :)

Почему, если не секрет?

потому что чаще всего в таком случае возникает неконструктивная дискуссия, обусловленная тем, что заказчик порулить хочет - ничего страшного, но времени и нервов и совещаний в 2 раза больше уходит

конструктивные заказчики мне сильно редко попадались

PS note the smiley!

ко-ко-ко-ко ITT, ко-ко-ко-ко ПМ, кря-кря!

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

Загляни в трекер, бро. ;)

А я знаю - те кто в основном «носятся с баблом и не знают куда вложить» на самом деле либо носятся с копейками, до 200К (обычно последними или с проданных хат), либо ищет высокорисковые проекты с потенциально огромной прибылью (венчурное инвестирование), с первыми все ясно, а у вторых проблема: они всегда предлагают маленькие доли основным разрабам, позже ужимая и их. [..]

ну во-первых - это жизнь, никто не говорил что будет легко, а во-вторых Вы сильно упрощаете насчёт альтернатив - их гораздо больше

Мой совет — лучше ничего не говорить.

Ваше мнение очень важно для нас, оставайтесь на линии