Не спорю, что DO-DTO правильная связка. Однако:
— связка имеет смысл только в случае remote interface, особенно если он публичный. Локальные бизнес процессы неплохо работают напрямую с DO.
— структура DTO, мепящего один и тот же DO, может меняться для разных операций. Приходится писать разные мепперы для одного и того же DO.
— в некоторых случаях приходится писать обратный меппер DTO->DO
— в 90% случаев структура DO и DTO практически идентична (не считая ссылок), а количество полей запросто может достигать нескольких десятков.
— писать и поддерживать меппинги — достаточно нудная и ресурсозатратная задача, если в проекте нет отдельной специально обученной обезьяны, пишущей и тестирующей меппинги. При использовании различных ухищрений и библиотек как правило теряется typesafe, и в разы усложняется поддержка (модификации DO, анализ изменений, тестирование, etc...)
Поэтому в большинстве случаев обходятся одними DO. Обычно любая ORM проксирует ссылки, а при сериализации они не резольвятся. Таким образом можно вручную контролировать возвращаемый подграф. Некоторые ORM позволяют въявную ограничивать список полей для запрашиваемого объекта (остальные либо проксируются для ленивой инициализации, либо тупо устанавливаются в null).
Можно также использовать смешанную схему: DTO, содержащие DO.
P.S. DO не должно иметь бизнес логику, это противоречит идее DO. DO — это такие же структуры, только с connected state.
Внимательно посмотрел я этот Nim. Это фактически Паскаль с питоньим синтаксисом и модными плюшками. У меня ощущение не особо приятное. Синтаксическое core языка достаточно громоздко. Вместо элегантного расширения при помощи API и типов, функционал зашит в синтаксис. Система типов посредственная. Когда одни языки используют концепты immutability, null-safety, value types, Nim пытается заставить нас вспомнить как правильно работать со сцылками. Одни zero-terminated mutable strings чего стоят! Язык прямо из коробки идет с кучей прикладной магии ввиде pragmas, шаблонов и макросов.
Вобщем, этакий невзрачный язык технического уровня наряду с D, Vala, etc…
Если под продуктивностью понимать способность решить задачу за минимальное время при помощи данной технологии, то не следует забывать, что решение задачи состоит из следующих фаз:
Архитектура
Прототипирование
Написание кода
Тестирование
Поддержка
Язык как таковой может оптимизировать фазу написания кода, однако не факт, что сопутствующая технология проявит себя так же хорошо в остальных фазах.
Автор упомянул экосистему. Это как раз решающий фактор производительности, когда кусок кода можно заменить одним вызовом сторонней библиотеки. Библиотеки и фреймворки расширяют язык новым функционалом. Экосистема Java одна из самых развитых, и пробовать что-либо вне ее достаточно рискованно, если это не очень узкоспециализированная задача.
На сегодняшний день проблема Java как языка в отсутствии возможности семантического расширения, иначе говоря создания DSLей. Стандартное решение ввиде аннотированного кода плохо: из одних аннотаций невозможно создать семантически связанную струтуру. Альтернатива не лучше: использовать сторонний дескриптор XML, который хоть и связан семантически (XSD), но никак не связан с аннотируемым кодом.
Есть такое. Сильное потрясение выбивает из привычной среды (тунеля реальности, если хотите), и, буквально, начинаешь ощущать себя другим человеком. На многие проблемы смотришь уже под другим углом. Новое окружение хоть и непривычно, но уже не давит своей безвыходностью. Тем не менее после нормализации ситуации потихоньку скатываешься обратно.
Вот не факт что опаснее. Колеса, конечно, имеют свои побочные действия, и их лучше принимать дозированно под контролем врача. Зато в медитации, йоге и подобных практиках очень часто практикуется религиозная составляющая, которая может засесть достаточно глубоко, и на которую можно подсесть не хуже наркотика. Человек теряет критичность мышления и адекватность восприятия многих вещей, замыкается в кругу единомышленников. Вывести его оттуда фактически невозможно, т.к. он не осознает проблемы и всячески отрицает ее.
А колеса, они с каждым поколением все безопаснее, механизмы лучше изучены, а действие более сфокусировано. К сожалению, политика многих государств резко против использования психоактивных препаратов, даже в лечебных целях.
У химии нет конкуренции. Любые практики на порядок менее эффективны и более трудоемки и времязатратны. Обычно при СДВ назначают метилфенидат (Риталин), даже детям. Скорей всего автор его и принимал. Он не оказывает эйфорического действия, однако снимает тревоги и стресс, индуцированные страхом принятия решения и неуверенностью, проясняет мышление, увеличивает концентрацию и активирует желание действовать.
Кстати, в США прописывание психотропов — обычная практика, в отличие от других стран, где это строго лимитируется. Там очень много людей сидят на таблетках. Этой темы касается фильм «Побочный эффект».
Причина негативного впечатления от Java в том, что она была испорчена всевозможными фреймворками. Это началось с J2EE и продолжается по сей день. Естественно, когда после каждого изменения требуется перекомпилировать код, перепаковать приложение и передеплоить на удаленный сервер (а иногда и перезагрузить сам сервер), то время разработки увеличивается в десятки раз. Но надо понимать, что это не единственный способ. Если в мире JS для сервера существует только node.js, то для Java для любой задачи всегда есть десятки альтернатив.
Я вместо удаленного Tomcat использую Embedded Jetty, который может конфигурироваться программно (в обход web.xml) и пускаться как отдельное приложение за миллисекунды, «подцепляя» ваше веб приложение из classpath. Для быстрого прототипирования я использую обычный JSP+JSTL без всяких фреймворков. Благо JSP plugin для Eclipse есть и позволяет дебаггить. Для ускорения писанины часть использую Groovy, там, где это разрешается клиентом.
Тот же com.sun.net.httpserver.HttpServer вкупе с Jersey уже дает полноценный restful-сервер.
Со Spring-ом не сраслось. Есть полезные вещи, но многие концепты просто рудиментарны и только усложняют разработку, особенно где нужно выйти за рамки позволенного. Стараюсь его избегать, где только возможно, однако всегда приходится иметь с ним дело (желание клиента — закон).
Еще хвалят Play framework, но лично я не пробовал. Отвращают темплейты, писанные на Scala.
По спецзаказу приходится пользовать JEE стек. Однако, есть отличный контейнер OpenEJB, позволяющий за секунду пускать себя в Embedded режиме и подцеплять EJB из classpath, а также легко писать модульные тесты. Бонусом большое число примеров на каждую технологию стека.
Так что на Java вполне можно быстро и эффективно разрабатывать. Сегодня Java — это огромный набор технологий, зачастую дублирующих друг друга. Эффективность разработки зависит от выбора и от уровня владения технологией.
Обычно коментарий ставят, чтобы пояснить, что делает нижестоящий кусок кода. Однако, как советуют многие, коментарии в коде должны отвечать на вопрос ЗАЧЕМ, а не на вопрос КАК. Последнее должно всегда быть понятно из кода.
Поэтому если кусок кода нетривиален, лучше его вынести в отдельную функцию и дать ей имя, поясняющее это действие. Таким образом в вышестоящей функции остаются только простые конструкции со смысловыми идентификаторами. Нужны детали — спускайтесь ниже.
На Java я иногда вместо создания новой функции отделяю рутину областью видимости, а результат записываю в переменную с поясняющим именем:
P.S. Что бы ни говорил автор, в реальной разработке со сжатыми сроками и ограниченным бюджетом очень сложно быть «святым». Впрочем, как и в реальном мире :)
У меня ещё свежо в памяти, сколько правильно сформированных файликов нужно было разложить по нужным папочкам, чтобы завелось простейшее веб-приложение на Tomcat, при этом и Java, и Tomcat
Это проблема не Java, а выбранной вами конкретной технологии — servlet, которая является частью стека JEE, довольно тяжелого и неудобоваримого. Более того, это проблема вообще всех фреймворков, где что-нибудь не так сконфигуришь или не следуешь соглашением, и в результате либо тупо не работает, либо выбрасывает ни о чем не говорящую ошибку. Но Java не лимитирована сервлетами и томкетом. Существуют десятки других библиотек и фреймворков для веб разработки разной степени сложности и функционала. Запустить простейший сервер можно вообще одной строчкой без единого дополнительного jar-а.
Благодаря этой практике Java-программисты тратят уйму времени на моделирование всего, что движется
Без этого код быстро зарастет заплатками и наспех склепаным дерьмом, и интегрировать новый функционал станет с каждым разом все труднее. И в один прекрасный момент придется все переписывать с нуля, вместо того, чтобы делать своевременный рефакторинг. Тем более, если представить, чтоб вы пишите код не один…
Адекватная система модульности в лучшем случае появится в Java только в следующем году, спустя 21 (!) год после её создания.
Вроде как OSGI уже давно есть и используется всеми, кому не лень…
Любая технология делается для решения конкретных задач
Для решения каких конкретных задач был придуман Unix? Или язык C? Вот JavaScript был изначально задуман как чисто клиентская технология для выполнения простой логики в браузере, и, собственно, таковой и остается и по сей день. Популярность он приобрел во многом благодаря стараниям и усердию Sun Microsystems по убийству клиентской Java. Node.js — это экспансия технологии в область, для которой он не был изначально предназначен.
Java, на которой одинаково медленно и неуклюже пишется всё, зато в стабильно долгие сроки
Да с чего Вы это взяли? Да, на Java код в целом получается длиннее, но ведь программист не стенографистка! Благодаря статической типизации вкупе с поддержкой IDE код пишется в несколько раз быстрее, чем на языках с динамической типизацией. Отладка занимает гораздо меньше времени, а любые ошибки легко локализуемы. Есть еще такие фазы как моделирование, прототипирование, тестирование и отладка, и поддержка. Как можно на динамическом языке вообще что-то смоделировать? Поэтому уже написание проекта средней сложности на динамических языках доставляет большой геморрой. Даже компании Google и Microsoft понимают, что нужна замена JS на что-нибудь со статической типизацией (Dart, TypeScript).
технология, которая писалась авторами для решения вот этой конкретной проблемы, всегда будет для неё лучше
В большинстве реальных задач конкретных проблем как правило много. Использование единой универсальной технологии, покрывающей их всех, пусть даже не самым оптимальным способом, в итоге будет эффективней, нежели использование N различных технологий и решения проблем с интеграцией.
Я не согласен по поводу утверждения, что та или иная технология больше или меньше подходит под конкретную задачу. Я все время и везде слышу эту мантру, но она существует лишь чтобы успокоить холиварщиков. Есть узкоспециализированные технологии для очень ограниченного круга задач, но которые не претендуют ни на что глобальное. Есть хорошие универсальные технологии, проверенные временем, подходящие сразу для большого круга задач. А есть технологии, претендующие на универсальность, в большинстве случаев слишком зеленые, с помощью которых тоже типа можно решить ту или иную задачу. И что странно, и те и другие технологии развиваются и используются. Почему? Просто так сложилось. Кому-то понравилось, кто-то купился на рекламу, кто-то что-то неосилил, кто-то решил извратнуться, кому-то просто стало интересно. Пользователь никогда не делает выбор технологии на основе скурпулезного анализа: для этого он должен в совершенстве владеть всеми сразу, чтобы знать и понимать где есть какие подводные камни.
Я бы хотел перевести разговор в иную плоскость: какой RAD больше подходит для разработки в условиях очень кратких, практически одно- и двухдневных итераций с условием перехода в условный продакшн на финишной прямой такой разработки.
Ответ простой: та технология, которой Вы наиболее владеете на данный момент. Если это Java с фреймворком — отлично. Если это node.js — ради бога! Если это pyton или perl — флаг Вам в руки!
Вот если у меня проект «для души», где никуда не спешу, и есть время и интерес попробовать на вкус другие технологии, тогда почему нет?
Тоже когда-то блуждал в поисках идеального языка, но работа заставляет возвращаться в Java. По экосистеме и количеству проектов у Java нынче нет конкурентов, и близко не предвидится. Поэтому приходится выбирать что-то JVM-совместимое, желательно как можно ближе к Java. Свой быдлокод часто пишу на Groovy, чтобы было меньше мусора. Посматриваю в сторону Kotlin-а, но тот не вылезает из вечной альфы. Пробовал Xtend, но выигрыш сомнительный. Fantom не имеет и никогда не будет иметь generics. Ceylon имеет несколько интересных концепций, но на кой-то черт создатели переименовали все привычные ключевые слова на свой лад. К Scala сразу появилось отвращение: это ужасный неэстетичный монстр, напичканный нечитабельными значками. Как показал человек выше: «Вам не надо шарить в кишках, мы вам дадим сборник рецептов и магических заклинаний как это можно использовать».
И тем не менее, все современные языки похожи. Каждый последующий пытается вписать в себя все предыдущие концепции плюс добавить еще какую-то модную вещицу. И практически никто не пытается переосмыслить многие вещи и выкинуть лишнее. Похоже основной целью у всех является, чтобы можно короче написать. Для меня в первую очередь самое необходимое в языке — это возможность моделировать данные и интерфейсы и организовывать их соответствующим образом. Java Beans — худшее, что можно представить для моделирования данных.
в аэропорту солнечной Испании у вас на 10 минут попросили досмотреть ноутбук с зашифрованным жестким диском
Ну уж Вы загнули! В Европе весь досмотр сводится к просьбе открыть ноут, чтобы убедиться, что это не муляж для провоза контрабанды, и то не всегда. Да и по законодательству любой досмотр должен проводиться строго в присутствии владельца. Так что никаких «дайте на 10 минут» быть не может. Не говоря уж о том, чтобы подсадить какой-нибудь вирус…
Вот Израиль — более вероятный кандидат. Там теоретически и ноут могут попросить и вернуть его вам по винтикам, если заподозрят что-нибудь. Но вроде бы ни с кем не приключалось.
В Британии любая, даже самая совершенная система шифрования тупо скомпроментирована законодательством. Вас вежливо попросят ввести пароль или ключ для досмотра содержимого. При отказе или невозможности проделать оную операцию вас проводят в КПЗ для дальнейшего разбирательства.
В России также при пересечении границы могут потребовать средства хранения данных для досмотра. Хотя на счет обязательного предоставления ключа для расшифровки не уверен. Последний и единственный раз у меня проверяли дискеты лет этак N-дцать назад.
Собственно я его и посадил писать интеграционные тесты, где надо придумать большое количество данных, заполнять формы и сообщения. При всем при том, что вся инфраструктура тестинга разработана, чел не понимает даже какие случаи надо оттестировать. Весь отчет: «я попробовал запустить тест, высылаю тебе лог системы». К сожалению, решение о его присутствии в команде зависит не от меня. Он был приведен, чтобы «набираться опыта», но челу это как бы не нужно.
Перфекционист-экспериментатор. Такое возможно? :)
У меня в проекте есть копипейстер. Фраза «понятия не имеет, что он делает» просто в яблочко! К сожалению, он не проводит дни на StackOverflow. Для любой даже самой простой задачи он задаст пятьдесят вопросов, до тех пор, когда ему не объяснишь даже не как делать, а как это написать. А после этого добьет еще пятьюдесятью вопросами типа «я написал как ты сказал, а у меня вылез этот эксепшн», и копипейст стектрейса…
Он самый :) Называл Оберон лучшим языком программирования. На лекции по основам методов трансляции, которые он вел, писали парсер к Оберону. А на лабах каждый делал компилятор Оберона во что-то. Как академический язык он действительно был хорош, но не более.
У меня препод в универе был фанат Оберона, даже написал его компилятор в JVM. В то время мне Оберон показался несколько ограниченной копией Паскаля, к тому же без x86 рантайма. В любом случае, что бы ни говорили, Оберон — это академический язык и всегда таким останется. Чтобы сделать индустриальный язык, нужно «завлечь» пользователя возможностями, сладостями и спецэффектами: поменьше писанины, меньше ограничений и идеологий, вместить в себя все моднючие фичи и парадигмы, цепляться. Также точно глубокий фильм со смыслом никогда не станет кассовым.
Сорри! Действительно! Пару лет назад делал похожие тесты, и вторая транзакция реально откатывалась! Попробовал сейчас повторить — обе коммитаются! Более того, даже если в H2 поставить serializable уровень, обе транзакции прокатывают! Надо будет найти те исходники и посмотреть в чем дело.
Вы не правы. В Вашем примере вторая транзакция откатится даже на минимальном уровне (READ_UNCOMMITED). От потерянного обновления защищают все уровни. Говоря иначе, транзакция устанавливает «write-locks» на измененные ею данные, которые также проверяются при записи в других параллельных транзакциях. Проблема как раз с «read-locks»: т.к. 90% операций — чтение, то для быстродействия на разных уровнях ими пренебрегают для быстродействия. Для полностью Serializable уровня необходимы read-блокировки, который каждый реализует как может: кто блокирует таблицу целиком (H2, Derby), Mysql, кажется, просто добавляет в каждый SELECT… FOR UPDATE..., но в целом всегда очень неэффективно.
В современных базах на смену write-блокоровкам пришел более эффективный контроль версий (MVCC), на основе которого очень просто и сразу реализуется т.н. Snapshot-изоляция, которая лежит между Serializable и Repeatable read. Многие производители (Oracle) тупо называют ее Serializable, тогда как другие (MsSQL, Postgres, DB2) имеют специально отдельный уровень для Serializable.
А вот пример, который не выполнится при Serializable, но прокатит при Snapshot (т.н. write skew). У клиента в банке два счета. По контракту его суммарный баланс на всех счетах не должен быть отрицательным, тогда как на любом из счетов он может быть негативный. Пусть на обоих счетах лежат по 50 енотов (A=50, B=50). И на оба счета приходят одновременно две транзакции на 100 енотов (X=100, Y=100):
T1:
select A, B
if (A+B-X < 0) fail
else update A = A-X
T2:
select B, A
if (A+B-Y < 0) fail
else update B = B-Y
Поскольку для параллельных T1 и T2 A+B=100, и записываемые данные не пересекаются, то в результате на обоих счетах у клиента будет по -50 енотов. Эта проблема и многие схожие легко решаются при помощи ручной блокировки (pessimistic lock). Поэтому в большинстве приложений хватает READ_COMMITED уровня, установленного по умолчанию плюс ручное отслеживание схожих ситуаций.
— связка имеет смысл только в случае remote interface, особенно если он публичный. Локальные бизнес процессы неплохо работают напрямую с DO.
— структура DTO, мепящего один и тот же DO, может меняться для разных операций. Приходится писать разные мепперы для одного и того же DO.
— в некоторых случаях приходится писать обратный меппер DTO->DO
— в 90% случаев структура DO и DTO практически идентична (не считая ссылок), а количество полей запросто может достигать нескольких десятков.
— писать и поддерживать меппинги — достаточно нудная и ресурсозатратная задача, если в проекте нет отдельной специально обученной обезьяны, пишущей и тестирующей меппинги. При использовании различных ухищрений и библиотек как правило теряется typesafe, и в разы усложняется поддержка (модификации DO, анализ изменений, тестирование, etc...)
Поэтому в большинстве случаев обходятся одними DO. Обычно любая ORM проксирует ссылки, а при сериализации они не резольвятся. Таким образом можно вручную контролировать возвращаемый подграф. Некоторые ORM позволяют въявную ограничивать список полей для запрашиваемого объекта (остальные либо проксируются для ленивой инициализации, либо тупо устанавливаются в null).
Можно также использовать смешанную схему: DTO, содержащие DO.
P.S. DO не должно иметь бизнес логику, это противоречит идее DO. DO — это такие же структуры, только с connected state.
Вобщем, этакий невзрачный язык технического уровня наряду с D, Vala, etc…
Архитектура
Прототипирование
Написание кода
Тестирование
Поддержка
Язык как таковой может оптимизировать фазу написания кода, однако не факт, что сопутствующая технология проявит себя так же хорошо в остальных фазах.
Автор упомянул экосистему. Это как раз решающий фактор производительности, когда кусок кода можно заменить одним вызовом сторонней библиотеки. Библиотеки и фреймворки расширяют язык новым функционалом. Экосистема Java одна из самых развитых, и пробовать что-либо вне ее достаточно рискованно, если это не очень узкоспециализированная задача.
На сегодняшний день проблема Java как языка в отсутствии возможности семантического расширения, иначе говоря создания DSLей. Стандартное решение ввиде аннотированного кода плохо: из одних аннотаций невозможно создать семантически связанную струтуру. Альтернатива не лучше: использовать сторонний дескриптор XML, который хоть и связан семантически (XSD), но никак не связан с аннотируемым кодом.
А колеса, они с каждым поколением все безопаснее, механизмы лучше изучены, а действие более сфокусировано. К сожалению, политика многих государств резко против использования психоактивных препаратов, даже в лечебных целях.
Кстати, в США прописывание психотропов — обычная практика, в отличие от других стран, где это строго лимитируется. Там очень много людей сидят на таблетках. Этой темы касается фильм «Побочный эффект».
Я вместо удаленного Tomcat использую Embedded Jetty, который может конфигурироваться программно (в обход web.xml) и пускаться как отдельное приложение за миллисекунды, «подцепляя» ваше веб приложение из classpath. Для быстрого прототипирования я использую обычный JSP+JSTL без всяких фреймворков. Благо JSP plugin для Eclipse есть и позволяет дебаггить. Для ускорения писанины часть использую Groovy, там, где это разрешается клиентом.
Тот же com.sun.net.httpserver.HttpServer вкупе с Jersey уже дает полноценный restful-сервер.
Со Spring-ом не сраслось. Есть полезные вещи, но многие концепты просто рудиментарны и только усложняют разработку, особенно где нужно выйти за рамки позволенного. Стараюсь его избегать, где только возможно, однако всегда приходится иметь с ним дело (желание клиента — закон).
Еще хвалят Play framework, но лично я не пробовал. Отвращают темплейты, писанные на Scala.
По спецзаказу приходится пользовать JEE стек. Однако, есть отличный контейнер OpenEJB, позволяющий за секунду пускать себя в Embedded режиме и подцеплять EJB из classpath, а также легко писать модульные тесты. Бонусом большое число примеров на каждую технологию стека.
Так что на Java вполне можно быстро и эффективно разрабатывать. Сегодня Java — это огромный набор технологий, зачастую дублирующих друг друга. Эффективность разработки зависит от выбора и от уровня владения технологией.
Поэтому если кусок кода нетривиален, лучше его вынести в отдельную функцию и дать ей имя, поясняющее это действие. Таким образом в вышестоящей функции остаются только простые конструкции со смысловыми идентификаторами. Нужны детали — спускайтесь ниже.
На Java я иногда вместо создания новой функции отделяю рутину областью видимости, а результат записываю в переменную с поясняющим именем:
P.S. Что бы ни говорил автор, в реальной разработке со сжатыми сроками и ограниченным бюджетом очень сложно быть «святым». Впрочем, как и в реальном мире :)
Это проблема не Java, а выбранной вами конкретной технологии — servlet, которая является частью стека JEE, довольно тяжелого и неудобоваримого. Более того, это проблема вообще всех фреймворков, где что-нибудь не так сконфигуришь или не следуешь соглашением, и в результате либо тупо не работает, либо выбрасывает ни о чем не говорящую ошибку. Но Java не лимитирована сервлетами и томкетом. Существуют десятки других библиотек и фреймворков для веб разработки разной степени сложности и функционала. Запустить простейший сервер можно вообще одной строчкой без единого дополнительного jar-а.
Без этого код быстро зарастет заплатками и наспех склепаным дерьмом, и интегрировать новый функционал станет с каждым разом все труднее. И в один прекрасный момент придется все переписывать с нуля, вместо того, чтобы делать своевременный рефакторинг. Тем более, если представить, чтоб вы пишите код не один…
Вроде как OSGI уже давно есть и используется всеми, кому не лень…
Для решения каких конкретных задач был придуман Unix? Или язык C? Вот JavaScript был изначально задуман как чисто клиентская технология для выполнения простой логики в браузере, и, собственно, таковой и остается и по сей день. Популярность он приобрел во многом благодаря стараниям и усердию Sun Microsystems по убийству клиентской Java. Node.js — это экспансия технологии в область, для которой он не был изначально предназначен.
Да с чего Вы это взяли? Да, на Java код в целом получается длиннее, но ведь программист не стенографистка! Благодаря статической типизации вкупе с поддержкой IDE код пишется в несколько раз быстрее, чем на языках с динамической типизацией. Отладка занимает гораздо меньше времени, а любые ошибки легко локализуемы. Есть еще такие фазы как моделирование, прототипирование, тестирование и отладка, и поддержка. Как можно на динамическом языке вообще что-то смоделировать? Поэтому уже написание проекта средней сложности на динамических языках доставляет большой геморрой. Даже компании Google и Microsoft понимают, что нужна замена JS на что-нибудь со статической типизацией (Dart, TypeScript).
В большинстве реальных задач конкретных проблем как правило много. Использование единой универсальной технологии, покрывающей их всех, пусть даже не самым оптимальным способом, в итоге будет эффективней, нежели использование N различных технологий и решения проблем с интеграцией.
Ответ простой: та технология, которой Вы наиболее владеете на данный момент. Если это Java с фреймворком — отлично. Если это node.js — ради бога! Если это pyton или perl — флаг Вам в руки!
Вот если у меня проект «для души», где никуда не спешу, и есть время и интерес попробовать на вкус другие технологии, тогда почему нет?
Тоже когда-то блуждал в поисках идеального языка, но работа заставляет возвращаться в Java. По экосистеме и количеству проектов у Java нынче нет конкурентов, и близко не предвидится. Поэтому приходится выбирать что-то JVM-совместимое, желательно как можно ближе к Java. Свой быдлокод часто пишу на Groovy, чтобы было меньше мусора. Посматриваю в сторону Kotlin-а, но тот не вылезает из вечной альфы. Пробовал Xtend, но выигрыш сомнительный. Fantom не имеет и никогда не будет иметь generics. Ceylon имеет несколько интересных концепций, но на кой-то черт создатели переименовали все привычные ключевые слова на свой лад. К Scala сразу появилось отвращение: это ужасный неэстетичный монстр, напичканный нечитабельными значками. Как показал человек выше: «Вам не надо шарить в кишках, мы вам дадим сборник рецептов и магических заклинаний как это можно использовать».
И тем не менее, все современные языки похожи. Каждый последующий пытается вписать в себя все предыдущие концепции плюс добавить еще какую-то модную вещицу. И практически никто не пытается переосмыслить многие вещи и выкинуть лишнее. Похоже основной целью у всех является, чтобы можно короче написать. Для меня в первую очередь самое необходимое в языке — это возможность моделировать данные и интерфейсы и организовывать их соответствующим образом. Java Beans — худшее, что можно представить для моделирования данных.
Ну уж Вы загнули! В Европе весь досмотр сводится к просьбе открыть ноут, чтобы убедиться, что это не муляж для провоза контрабанды, и то не всегда. Да и по законодательству любой досмотр должен проводиться строго в присутствии владельца. Так что никаких «дайте на 10 минут» быть не может. Не говоря уж о том, чтобы подсадить какой-нибудь вирус…
Вот Израиль — более вероятный кандидат. Там теоретически и ноут могут попросить и вернуть его вам по винтикам, если заподозрят что-нибудь. Но вроде бы ни с кем не приключалось.
В Британии любая, даже самая совершенная система шифрования тупо скомпроментирована законодательством. Вас вежливо попросят ввести пароль или ключ для досмотра содержимого. При отказе или невозможности проделать оную операцию вас проводят в КПЗ для дальнейшего разбирательства.
В России также при пересечении границы могут потребовать средства хранения данных для досмотра. Хотя на счет обязательного предоставления ключа для расшифровки не уверен. Последний и единственный раз у меня проверяли дискеты лет этак N-дцать назад.
У меня в проекте есть копипейстер. Фраза «понятия не имеет, что он делает» просто в яблочко! К сожалению, он не проводит дни на StackOverflow. Для любой даже самой простой задачи он задаст пятьдесят вопросов, до тех пор, когда ему не объяснишь даже не как делать, а как это написать. А после этого добьет еще пятьюдесятью вопросами типа «я написал как ты сказал, а у меня вылез этот эксепшн», и копипейст стектрейса…
В современных базах на смену write-блокоровкам пришел более эффективный контроль версий (MVCC), на основе которого очень просто и сразу реализуется т.н. Snapshot-изоляция, которая лежит между Serializable и Repeatable read. Многие производители (Oracle) тупо называют ее Serializable, тогда как другие (MsSQL, Postgres, DB2) имеют специально отдельный уровень для Serializable.
А вот пример, который не выполнится при Serializable, но прокатит при Snapshot (т.н. write skew). У клиента в банке два счета. По контракту его суммарный баланс на всех счетах не должен быть отрицательным, тогда как на любом из счетов он может быть негативный. Пусть на обоих счетах лежат по 50 енотов (A=50, B=50). И на оба счета приходят одновременно две транзакции на 100 енотов (X=100, Y=100):
T1:
select A, B
if (A+B-X < 0) fail
else update A = A-X
T2:
select B, A
if (A+B-Y < 0) fail
else update B = B-Y
Поскольку для параллельных T1 и T2 A+B=100, и записываемые данные не пересекаются, то в результате на обоих счетах у клиента будет по -50 енотов. Эта проблема и многие схожие легко решаются при помощи ручной блокировки (pessimistic lock). Поэтому в большинстве приложений хватает READ_COMMITED уровня, установленного по умолчанию плюс ручное отслеживание схожих ситуаций.