11. Если мы говорим о Java, то еще можно добавить избегание всяческих ORM фреймворков. ORM парадигма представляет граф объектов как если бы они лежали в памяти, автоматически запрашивая данные из базы. Соответственно пользователь пишет код, не задумываясь о том, как это реально выполняется. На настольной системе все работает и выглядит красиво. С реальными же объемами данных наступают проблемы.
P.S. Недавно открыл для себя jOOQ.
> 4. Использование JDBC для постраничной разбивки большой выборки
Как правило JDBC драйвер используют нативные средства разбивки предоставленные производителем, которые работают так же эффективно, как и SQL
Проапгрейдил Ubuntu до 13.10 и моя NVidia (240) перестала работать. Пробовал все драйверы — ядро глухо виснет. С 13.04 и предыдущими все работало на ура. Вот вам и полная поддержка Linux!
По-моему способ реализации MVCC в одной конкретной СУБД не так важен. Интуитивно, думаю, все понимают как он работает. Нужно больше заострить внимание на теории.
1. Есть три схемы обеспечения изоляции: блокировки, MVCC и их смесь. DB2 (до 9.7) честно построена на блокировках, Oracle использует MVCC, SQL Server использует обе схемы. MVCC на порядки проще в реализации, лучше подходит для распределенных систем и вцелом дает более высокую производительность.
2. Стандарт SQL-92 определяет 4 уровня изоляции, т.к. базировался только на схеме с блокировками, когда MVCC еще не использовался. С помощью только одного MVCC нельзя достичь уровня Serializable, поэтому многие СУБД с MVCC определяют дополнительный уровень изоляции snapshot isolation, который больше repeatable read, но меньше serializable. Ввиду этого честные производители (Postgres) заявляют об уровне поддержки repeatable read, а нечестные (Oracle) нагло утверждают, что поддерживают serializable*, при этом делая сноску мелким шрифтом, что serializable* — это в смысле Oracle.
3. При snapshot isolation не блокируются read-ы, поэтому возможна неприятная ситуация, называемая write skew. Допустим чувак имеет в банке два счета A и B. На обоих лежат по 50 баксов. По контракту его суммарный баланс в банке не может быть отрицательным, хотя на одном счетов может быть отрицательная сумма. Параллельно на оба счета приходят две транзакции по снятию 100 баксов. Поскольку транзакции изменяют разные ресурсы, а чтение не блокируется, то для обеих транзакций сумма A+B даст результат 100, и обе транзакции выполнятся.
Вообще мышь — самое неудобное устройство ввода информации после клавиатуры. Есть такой очень неудачный, но необходимый элемент интерфейса. Называется по-разному: viewport, scrollpane, etc. Нужен для того, чтобы уместить неумещаемое в ограниченный объем. Самое неудобное движение, которое делает человек за компом — скроллирование. Нужно мышкой попасть на скроллбар (если он не на правой границе экрана — юзабилити отдыхает), нажать и «отмотать» нужное. Со скроллированием вертикального контента как-то справились, проапгрейдив мышку колесиком (хотя в винде все-равно сначала приходится тыкнуть фокус на скроллируемый элемент).
Теперь нужно представить, что в офисах не только строчат код и документы, но также рисуют схемы, делают презентации, занимаются визуальным проектированием, инженерной разработкой, etc. Для представления такого контента нужно еще добавить опции зума: две кнопочки с лупой ± на скроллбаре, и спиннер xxx% в тулбаре. Подобные интерфейсы на таче увеличат в несколько раз производительность работы.
Не думаю, что компактные проекторы вытеснят экраны. Во-первых, проектору нужна поверхность на которую проектировать. Это уже не делает его мобильным: в место одной части нужно с собой таскать уже две. Во-вторых проектору нужна дистанция до поверхности. То есть все устройство уже будет занимать объем как старый CRT, хотя мы только осознали преимущество плоских экранов. В-третьих их технологически сложнее выполнить, нежели обычный LCD: нужна миниатюрная матрица с таким же разрешением, и миниатюрная, но более мощная лампа (не забываем, что отражается далеко не весь свет). При всем этом преимуществ перед LCD нет.
Я думаю, все будет с точностью до наоборот. Стоимость производства LCD матриц настолько упадет, что их можно будет клеить обоями на стены. Они даже вытеснят обычную бумагу.
Уйдет такая вещь как компьютер, будь то настольный или ноутбук. Их полностью заменят мобильные коммуникаторы (телефоны, планшетники, шпионские очки от гугла, etc.) и… телевизоры. В офисах вместо компьютеров с мониторами будут использоваться «десктопы»: большие плашнетники с тонким клиентом.
С телевидением согласен. Изменится также и бизнес-концепт от широкого вещания с рекламой к платной пакетной подписке. Цифровое вещание в ближайшее время не отомрет, но будет использоваться совместно с онлайн трансляцией. Появятся интерактивные сервисы: обратная связь, интегрированная прямо в телепрограмму, отсюда, новые концепты вещания: интерактивные шоу, голосования, etc…
С кинотеатрами не согласен. Основные сборы фильм получает именно с проката, после чего уже попадает в розницу, где успешно теряется среди десятков других. Кроме того, кинотеатр — это также и культурное явление, как поход в театр (ведь можно посмотреть спектакль по ТВ), или в ресторан (можно заказать еду домой). Могу предположить, что в будущем кинотеатры тоже добавят интерактива и превратятся в геймтеатры. ))
Телефон не только проводной, но и вообще как концепт будет полностью вытеснен мессенжерами.
Еще:
Коробочный софт уйдет в небытие (уже ушел).
Домашние игровые консоли будут заменены на мобильные, при желании подключающимися к телевизору.
Проводная связь между устройствами. Конец спагетти.
Зарядные устройства исчезнут. Видел где-то универсальный коврик, на который бросаешь девайс и он заряжается.
Изменится система оплаты. Наличные деньги практически исчезнут из оборота. Различные карты будь то кредитки или проездные документы будут заменены мобильными терминалами оплаты, встроенными в коммуникаторы и rfid.
Легковые автомобили с безниновым (дизельным) двигателем…
Лампы накаливания.
Помимо самой креативности необходимо и умение воплотить оную в реальное действие. А это умеет гораздо меньше людей, чем те, которые могут просто «креативить» на уровне идей. Беда в том, что в современном обществе заложен принцип сотрудничества и разделения обязанностей. Как правило идейный генератор и воплотитель — это как правило два разных человека, и практически всегда первый эксплуатирует второго. Некреативный «воплотитель» не испытывает по этому поводу особых неудобств, но и делает все посредственно и по-минимому, хотя и реализует минимально необходимый функционал. Креативный же воплотитель имеет собственные идеи для реализации, которые зачастую идут вразрез с навязываемыми ему свыше. Поэтому такому работнику всегда нужно давать свободу и пространство для маневра. Контролировать нужно лишь время выполнение задачи: взял на себя ответственность сделать по-своему — изволь гарантировать результат в срок.
Вспомнилась молодость. Лет этак 20 назад активно разбирался с TVision, писал тогда на Паскале. Уже в 2000 клиенту потребовалось написать фронтэнд к базе под текстовые терминалы на Unix-e. Как ни странно нашел билд TVision под юникс который без проблем компилился и работал. Юзеры хрюкали от счастья.
Помню к TVision кстати был то ли add-on то ли сторонняя разработка, которая добавляла полезных виджетов.
Так было в версии 5.3, с которой мы начинали. В 6.0 MQ Explorer переписали под Eclipse RCP, и наконец, добавили параметры коннекта, однако забыли про аутентификацию. Видимо только в 7.0 (по прошествии ) гениальная инженерная мысль сэволюционировала до завершенного диалога со всеми необходимыми параметрами — не знаю. Последнее, чем я пользовался это 6.0. И тем не менее, уверен, что до сих пор отсутствует нормальная возможность просмотреть содержимое сообщения (payload), ввиде человеческого текста (или XML), а не шестнадцатеричного дампа, который по крайней мере бы можно было скопипастить. В 6.0 также напрочь отсутствует возможность сохранить сообщение на диск. А окно Put Test Message имеет строку ввода Message Data, куда можно ввести полтора слова, без header-ов.
Может в 7.0 все гораздо лучше (не прошло и 10 лет), но сильно сомневаюсь. Стиль IBM сырого недописанного барахла соблюдается во всем.
> GUI инструмент, который называется WebSphere MQ Explorer
А Вы им пользовались? Это тулза под виндовс при помощи которой при желании можно сконфигурировать локальный QM. Сконфигурировать удаленный коннекшн нереально сложно, если вобще возможно. У меня не получилось, потому что все сделано как всегда через одно место, в стиле IBM. Вместо простой формочки, которую ожидает любой нормальный пользователь с полями: QM name, host/port, user, password, там только два поля: QM name и connection name. После получаса искания в документации оказалось, что connection name нужно писать в формате host(port), а не как привыкло 99% людей в мире: host:port. В итоге все-равно ничего не заработало, т.к. на сервере был выключен remote administration. Не понимаю, нахрен что-то там еще включать, чтобы чисто посмотреть очереди и их содержимое, если ни WMQTool, ни любой клиент этого не требует. Ну да ладно. Ввели на сервере магическую команду включения remote administration. И теперь благополучно выскакивает ошибка аутентификации. Даже при том, что аутентификация в QM выключена вообще. Посмотрев логи MQ (а это тоже надо уметь делать, ибо это вам не syslog) становится понятно, что MQ Explorer пытается залогиниться с локальным (windows!) пользователем!!! И что такой же пользователь должен существовать на машине с QM (это юникс) и быть членом группы mqm даже при выключенной аутентификации. В MQ Explorer отсутствует напрочь человеческая возможность ввести user credentials. Ладно, сознаем виндового пользователя «Administrator» на юникс машине и добавляем в группу mqm. Как несложно догадаться, опять ничего не заработало. И порывшись в интернетах находим официальное объяснение от IBm, что Websphere MQ не любит имена пользователей больше 11 символов (Administrator=13). Об этом официально написано.
И вот подобная хрень практически с любым продуктом IBM. В итоге просто сдают нервы.
> Много ли продуктов дают возможность принимать информацию практически из любого источника
Да полно Вам!!! Полно opensource и коммерческих решений как полномасштабные ESB: Mule, Fuse/Apache ServiceMix, OpenESB, Oracle ESB; так и отдельные message-серверы: ActiveMQ, HornetQ, SonicMQ… Большинство продуктов в минимальной конфигурации вообще представляют собой lightweight библиотеку. Active MQ+Apache Camel решает те же задачи, что и Websphere MQ+Broker. Поэтому думать, что IBM здесь делает что-то уникальное, вкорне неверно. Просто в один момент заняли рынок MoM как Oracle в свое время занял рынок баз данных.
> Разрабатывать для WAS очень желательно и весьма удобно в Rational Application Developer.
Ну разве что недавно допилили. До этого приходилось постоянно делать publish, который передеплоил все приложение. Remote debug безбожно тормозил, а иногда и подвисал. Сервер после нескольких дебагов работал все медленнее.
> При разворачивании новых версий приложения я знаю следующую практику
Да, нам тоже IBM советовали это. Но таким образом теряются сессии пользователей. Если я поменял одну страничку или пару классов, мне не хочется всех напрягать перелогиниваться.
> Эти два продукта, особенно MQ, это (ИМХО) одни из лучших, как внутри IBM, так и каждый в своем классе.
Если под качеством IBM подразумевает исключительно стабильное поведение в продакшне, то может быть. Вообще MQ Series было приобретение IBM, которое не имеет никакого отношения в Websphere. Собственное, ни с чем не совместимое и не следующее никакому стандарту с жуткой внутренней архитектурой, конфигурацией и интерфейсом. IBM кое-как прикрутила к нему джаву и JMS. Есть некое подобие графического интерфейса под винду rfhutil, которое требует для подключения переменные окружения. Благо есть поделка школьника под названием WMQTools, ей и пользуемся. JMS к MQ идет отдельным модулем, опять же конфигурируется через зад (там даже своя программка есть с коммандами для создания jndi контекста). А ведь визуальный мониторинг очередей и сбор статистики — это первоочередная задача любого саппорта. Как же это делать, если для этого нет нормальной графической тулзы?
Broker вообще рудиментарная вещь. Сегодня полтора человека знают ESQL. Еще меньше пытяются использовать его для трансформаций сообщений, которые на сей день идут в формате XML. Остальные 99.(9)% привыкли юзать для трансформаций XPath, XSLT, и наконец Java. Держать в штате экзотический вид программиста, знакомого с ESQL, когда с той же задачей справится любой другой стандартными на сегодняшний день средствами, накладно и нерационально.
Так что как я уже сказал выше, есть твердое впечатление от продуктов IBM, что они сделаны не для живых людей.
> WebSphere Application Server позиционируется как серверный продукт, а сервера часто перегружать не принято.
А как Вы себе представляете процесс разработки под такой сервер? Ждать порядка пяти минут, чтобы сделать один единственый тест — это накладно и неправильно. Если часть логики еще более-менее можно юнитами оттестировать локально без деплоя (отсюда кстати лихорадка по поводу TDD), а если я разрабатываю веб например на JSF, мне хочется видеть любое изменение сразу же… Так что спросите у любого как они выкручиваются, и вам ответят, что веб они строчат на легком Tomcat-е и уже потом в продакшн деплоят на WAS. Когда же логика сложная, и такая фишка не проходит, то этот тяжелый серверный продукт пускают локально на девелоперской машине, чтобы можно было более-менее дебагить нормально. Так что с этой точки зрения облегченный профайл — правильный шаг в этом направлении.
> Если нужна 100% доступность — нужно разворачивать кластер
Это теоретически. На практике при штатно работающем сервере перезапускать узлы никогда не требуется. А вот когда требуется задеплоить новую версию приложения на все ноды, от этого никакой кластер не спасает. У WAS типа есть фича, что-то вроде инкрементального деплоя (Update), но реально это никогда не работало, и очень геморно юзалось. Поэтому деполют всегда по-старинке: undeploy-deploy в пять часов утра. Можно конечно вручную деплоить поотдельности на оба узла, и настроить для этого балансер, но лень возиться.
> В сервер встроено много всякого добра, для обеспечения защиты/шифрования, отказоустойчивости,
В том-то и дело, что это реально не нужно. Если ваше приложение требует что-нибудь больше, чем Tomcat+Spring — это неправильное приложение, которое делает неправильный мед. Хотя это уже тема не столько Websphere сколько вообще инфраструктуры JEE. Сегодня никому нафиг эти тяжелые сервера не нужны с кучей непонятного и неудобоваримого API. Все это можно использовать при необходимости и вне JEE контейнера.
Так что IBM нужно менять стратегию и ориентироваться на живых людей. То что до этого делалось — это тихий ужас: Websphere Portal, Websphere Business Integration Platform, Websphere Process Server, Websphere Message Broker, Websphere MQ. Одно приятное исключение — DB2. Сорри за субъективизм.
Все плохо. От административной консоли, конфигурации, мониторинга, до средств и методологии разработки и тестирования. Любое неосторожное (да и осторожное тоже) действие может положить весь профайл. Я уж не говорю про тормознутость и прожорливость этого всего, а до последних версий еще и багнутость. Еще хуже, когда приходится работать с продуктами IBM, которые построены на WAS, например Websphere Process Server, Portal, etc. Разработка и тестирование превращается в сущий ад. Программисты стонут: «ради бога, давайте мы на чем-нибудь другом напишем». И если клиент особо упертый, то сам же потом и страдает. Вот Oracle правильно сделал: не смог поднять свой JEE профайл — взял и купил с потрохами BEA. И обзавелся удобоваримым сервером для своих решений. Redhat тоже пошла на встречу разработчикам — шестерку переписали практически с нуля, так, что стартует за три секунды, а Arquillian облегчил разработку и тестирование. А что есть у WAS? Такое впечатление, что весь сервер писали инопланетяне — там нет ни одного человеческого решения.
Я имел ввиду не столько сам Maven, сколько всю архитектуру проекта: технологии, тулзы, фреймворки, библиотеки. У джавелоперов любой проект начинается с горячего обсуждения что из этого будет использоваться. Кто-то за Maven, кто-то за Gradle. Кто-то за Spring, кто-то за Guice. Кое-кто предлагает webservice, а другой ему отвечает, что restful моднее. Кто-то хочет apache-commons, кто-то привык к guava, etc… Тем не менее, любой уважающий себя джавелопер должен их знать и уметь пользоваться некоторыми из них. То есть джава — это уже не только язык+API, но масштабируемая платформа с готовыми технологическими решениями.
Если говорить именно о главных причинах длительного доминирования Java, их три: простота языка, кроссплатформенность и стардартизация. То, что нужно для серьезного восприятия технологии.
1. Никто не будет спорить, что по меркам того времени после C++, Delphi и подобных простота и лаконичность Java вкупе с GC давала огромную фору. Кроме того, достаточно полный и продвинутый API позволял легко сделать нетривиальные вещи. Достаточно низкий порог вхождения, сишный синтаксис и ориентированность на то, чтобы «не выстрелить себе в ногу» (напр. checked exceptions) в разы упрощала разработку.
2. Кросплатформенность. Удивительно, но код, работающий одинаково без сборки и перкомпиляции работает одинаково на чем угодно, где есть JVM. По тем временам это был настоящий прорыв. Идеология SUN (write onсe run everywhere) дала свои результаты. Это позволило легко разрабатывать и запускать даже для ни с чем не совместимых монстров. Однако, с GUI дела обстояли не так гладко. Ввиду неоднородности виджетов на разных платформах было выбрано минимальное их множество, включенное в AWT. Когда же поняли, что этого не хватает, сделали Swing, с полностью джавовским рендерингом. Но проблемы не исчезли: виджетов все-равно не хватало (по сравнению с MFC или VCL), приходилось поддерживать look-and-feel разных платформ, нельзя встраивать нативные компоненты, etc. Однако возможность писать игрушки для статичных в то время вебстраниц привлекло к Java кучу разрабочиков. И поспособствовала этому именно Microsoft, включив свою Java 1.1 в Windows. После иска Sun к Microsoft те потихоньку выпилили Java из Windows и вместе с этим прошел бум на аплеты: реально в то время мало юзеров с диалапом хотели тащить многотонную JVM от сан. К тому же MS JVM работала с графикой в разы быстрее, быстрее пускалась и отжирала меньше памяти. («Приложеньице запущено» — для тех, кто помнит ;)
3. В SUN быстро поняли, что кроссплатформенность может быть полезной штукой и в разы упрощала написание серверных приложений (опять же по тем временам). И тут ребята подошли со всем размахом и серьезностью. Они начили активно пиарить Java как серверную платформу. Заручились поддержкой других компаний (IBM, Oracle,...) и создали JCP. Типа теперь в рамках всеобщей совместимости мы будем вместе заключать стандарты, а каждый производитель уже будет сам дописывать имплементации. В JCP родилось такое жуткое чудовище как Java ынтерпрайз ыдишн. Писать на нем что-то удобоваримое (а именно простые веб странички) до самого последнего времени было жутко дорого, долго, и глючно. Однако провайдеры быстро поняли, что чем дороже и сложнее делается проект, тем больше бабла можно срубить на саппорте, обучении и задвигании дорогих и объективно ненужных решений. Они резко подключились к активному пиару Java среди компаний-клиентов: семинары, проспекты, статьи, работа с клиентами, ВУЗами, девелоперами… На фоне растущего пузыря доткомов и всеобщей информатизации задвинули Java практически в любую контору. В итоге когда выдрессированному клиенту презентуешь план проекта, он спрашивает: «а какой сервер апликаций вы будете использовать»? Плюс паралельно САН пыталась запилить Java в каждую стиральную машину и чайник, что естественно добавляло понтов. После развала доткомов сразу же открылась такая профитная область как недотелефоны, куда стараниями ребят из JCP и SUN, можно было залить недоигрушку и даже немного поиграть в нее.
Тем не менее, JCP на всем протяжении пеклось об обратной совместимости. Именно поэтому многие выбирают Java как технологический стандарт для своей компании. Код, написанный для самой первой JVM будет точно также работать и компилироваться в последней (естественно, теоретически).
4. Это уже второстепенная причина. Понимая, что Java — мощное орудие, но меркнущее, будучи загнанным в рамки JSR-ов и J2EE, разработчики-энтузиасты мало по малу начали писать свои библиотеки и фреймворки. По началу для себя. Потом это вылилось в разные communities, одно из них была организована самой Sun (java.net). Все это росло как снежный ком, кодовая база увеличивалась, и вот уже communities диктуют архитектуру и технологические решения (Maven, Spring, Hibernate, Struts, etc...) основная идея их всех — сделать как можно проще повседневные вещи (однако получается не всегда). Сейчас на Java, наверное, самая мощная база решений после C на все случаи жизни. Сейчас разработчик Java — это не только тот, который знает язык, но и хорошо плавает в бульоне различных околотехнологичных решений. Как это программист Java и не знает Maven/Ant?
5. Тоже второстепенное, но серьезно добавило ништяков. Это Eclipse. Долгое время SUN не могла выпустить удобоваримую IDE. По сравнению с существовавшим в то время Visual C/Basic от MS и богатством Delphi мало кому хотелось задиться за Notepad. Eclipse в то время был босяцким подгончиком для всех Java-девелоперов. Открытая архитектура позволяла дописывать плагины на все случаи жизни. Позже САН допилила свою IDE до Netbeans, но паровоз уже был угнан.
А половина причин, описанных в статье — десятые производные от этих. Как говорится, надо смотреть в корень!
Меня интересует больше как выполняются пересекающиеся запросы, типа: for $p in doc('company')/Persons/Person[@name='Vasya']
for $d in doc('company')/Departments/Department where $d/Stuff/personRef=$p/@id
return <department>$d/@name</department>
То есть все отделы, где работает хотя бы один Вася.
Внутренний и внешний циклы можно поменять местами: внешний лучше поставить тот, где больше записей. Как это будет выполнять XBase непонятно. Например, если в RDBMS поля personRef и id проиндексированы, она вообще убирает внутренний цикл, заменяя параллельным сканом обеих таблиц. Если же XBase каждый раз выполняет внутренний скан, то на больших объемах данных это будет еле ворочаться.
Как-то исследовал различные NoSQL технологии, и пробовал BaseX.
Во-первых, складывается впечатление, что XML базы данных рассчитаны в основном на чтение, а не на обновление. Для чтения используются стандарт XPath/XQuery, тогда как запись ведется при помощи собственного API. Все попытки стандартизировать API (xqj, xml:db) недоработаны. Отсутствие клиентских транзакций приводит к тому, что всю логику нужно выполнять в одном вызове (запроса либо скрипта).
Непонятно как себя ведут сложные «пересекающиеся» запросы (по типу JOINs и подзапросов в RDBMS) на больших объемах данных, может ли BaseX сам оптимизировать плохие запросы и каким образом использует индексы в данных запросах.
Поэтому основное применение — standalone приложения, которые ищут по большому числу xml документов.
P.S. У BaseX есть два других open-source конкурента: eXist и Sedna. Первый достаточно навороченный, а второй написан на C. Здесь преимущество BaseX — легковесность и возможность запускаться в embedded режиме.
Идеальная система имеет древовидную структуру компонентов. Если есть возможность сделать ее такой, такой ее и нужно делать. Событийная модель может быть полезна:
— когда компоненты достаточно независимы и слабо связаны функционально
— при асинхронном взаимодейтвии компонентов
— когда нужно связать две несовместимые модели, например модель данных приложения и GUI
— в качестве локальных callback-ов от компонентов низкого уровня к более высоким, если нельзя обойтись без них
Потенциальные проблемы, за которыми нужно будет следить, если испльзовать события:
— регистрация/дерегистрация хендлеров. Как правило 80% всех ошибок в свинге, связанных с memory-leaking. Спасает EventBus с weak хендлерами.
— когда в процессе обработки события одини из хендлеров генерирует новое. Логика подсказывает, что оно должно обработаться после текущего, однако реально оно обрабатывается синхронно прямо в момент выкидывания. Частично спасает EventBus с асинхронной очередью, ибо в очереди уже могут стоять другие события, которые к моменту обработки данного делают состояние системы несовместимым. Например, кнопка окна выкинула, что она нажалась, а следующим в очереди уже стояло закрытие окна. В итоге обработчик получил нажатие кнопки, которая уже не существует, что могло бы спровоцировать трудноотлавливаемую ошибку.
— запутанные зависимости и дилема: в какой последовательности правильно останавливать компоненты?
— ну и классика при использовании в multithreaded environment: дедлоки всех возможных видов.
Именно так мы и поступили. Сначала долго писали на свинге. Потом тыркнулись в JavaFX 1.3 для написания игр. Это было ошибкой — Oracle оставила эту ветку без поддержки и выпилила JFX Script, не дав даже элементарного конвертера. JFX 2.x позиционировался как Swing 2.0 и новое поколение UI для java. Прикрутили новый графический композитный toolkit (prism), который долго пиарили: типа акселерация и все дела. Реально же скроллы ворочаются также медленно как и раньше. Плюс совершенно уродский лукандфил у контролов.
Вобщем, мы радикально поменяли стратегию и попробовали Embedded Jetty + GWT + SmartGWT + IE ActiveX. Результаты превзошли ожидания! Сейчас пробуем Jetty + Vaadin + Chromium Embedded.
P.S. я реально не вижу преимуществ у JavaFX перед уже существующими веб-технологиями. Кроме того, вполне возможно, что при низкой востребованности Oracle примет очередное решение, выпилив его обратно из Java, как это произошло с 1.3.
— разобщает логику и делает запутанным код системы
— сильно затрудняет нахождение ошибок и отладку
— не гарантирует и не контролирует последовательность обработки событий и соответственно делает непредсказуемым поведение системы
Я раньше много писал на свинге и знаю что такое. И в самой библиотеке были баги и практически все приложения подглючивали.
Поэтому если можно обойтись без событийной модели — оно всегда предпочтительней.
P.S. Недавно открыл для себя jOOQ.
> 4. Использование JDBC для постраничной разбивки большой выборки
Как правило JDBC драйвер используют нативные средства разбивки предоставленные производителем, которые работают так же эффективно, как и SQL
1. Есть три схемы обеспечения изоляции: блокировки, MVCC и их смесь. DB2 (до 9.7) честно построена на блокировках, Oracle использует MVCC, SQL Server использует обе схемы. MVCC на порядки проще в реализации, лучше подходит для распределенных систем и вцелом дает более высокую производительность.
2. Стандарт SQL-92 определяет 4 уровня изоляции, т.к. базировался только на схеме с блокировками, когда MVCC еще не использовался. С помощью только одного MVCC нельзя достичь уровня Serializable, поэтому многие СУБД с MVCC определяют дополнительный уровень изоляции snapshot isolation, который больше repeatable read, но меньше serializable. Ввиду этого честные производители (Postgres) заявляют об уровне поддержки repeatable read, а нечестные (Oracle) нагло утверждают, что поддерживают serializable*, при этом делая сноску мелким шрифтом, что serializable* — это в смысле Oracle.
3. При snapshot isolation не блокируются read-ы, поэтому возможна неприятная ситуация, называемая write skew. Допустим чувак имеет в банке два счета A и B. На обоих лежат по 50 баксов. По контракту его суммарный баланс в банке не может быть отрицательным, хотя на одном счетов может быть отрицательная сумма. Параллельно на оба счета приходят две транзакции по снятию 100 баксов. Поскольку транзакции изменяют разные ресурсы, а чтение не блокируется, то для обеих транзакций сумма A+B даст результат 100, и обе транзакции выполнятся.
Теперь нужно представить, что в офисах не только строчат код и документы, но также рисуют схемы, делают презентации, занимаются визуальным проектированием, инженерной разработкой, etc. Для представления такого контента нужно еще добавить опции зума: две кнопочки с лупой ± на скроллбаре, и спиннер xxx% в тулбаре. Подобные интерфейсы на таче увеличат в несколько раз производительность работы.
Не думаю, что компактные проекторы вытеснят экраны. Во-первых, проектору нужна поверхность на которую проектировать. Это уже не делает его мобильным: в место одной части нужно с собой таскать уже две. Во-вторых проектору нужна дистанция до поверхности. То есть все устройство уже будет занимать объем как старый CRT, хотя мы только осознали преимущество плоских экранов. В-третьих их технологически сложнее выполнить, нежели обычный LCD: нужна миниатюрная матрица с таким же разрешением, и миниатюрная, но более мощная лампа (не забываем, что отражается далеко не весь свет). При всем этом преимуществ перед LCD нет.
Я думаю, все будет с точностью до наоборот. Стоимость производства LCD матриц настолько упадет, что их можно будет клеить обоями на стены. Они даже вытеснят обычную бумагу.
С телевидением согласен. Изменится также и бизнес-концепт от широкого вещания с рекламой к платной пакетной подписке. Цифровое вещание в ближайшее время не отомрет, но будет использоваться совместно с онлайн трансляцией. Появятся интерактивные сервисы: обратная связь, интегрированная прямо в телепрограмму, отсюда, новые концепты вещания: интерактивные шоу, голосования, etc…
С кинотеатрами не согласен. Основные сборы фильм получает именно с проката, после чего уже попадает в розницу, где успешно теряется среди десятков других. Кроме того, кинотеатр — это также и культурное явление, как поход в театр (ведь можно посмотреть спектакль по ТВ), или в ресторан (можно заказать еду домой). Могу предположить, что в будущем кинотеатры тоже добавят интерактива и превратятся в геймтеатры. ))
Телефон не только проводной, но и вообще как концепт будет полностью вытеснен мессенжерами.
Еще:
Коробочный софт уйдет в небытие (уже ушел).
Домашние игровые консоли будут заменены на мобильные, при желании подключающимися к телевизору.
Проводная связь между устройствами. Конец спагетти.
Зарядные устройства исчезнут. Видел где-то универсальный коврик, на который бросаешь девайс и он заряжается.
Изменится система оплаты. Наличные деньги практически исчезнут из оборота. Различные карты будь то кредитки или проездные документы будут заменены мобильными терминалами оплаты, встроенными в коммуникаторы и rfid.
Легковые автомобили с безниновым (дизельным) двигателем…
Лампы накаливания.
Помню к TVision кстати был то ли add-on то ли сторонняя разработка, которая добавляла полезных виджетов.
Может в 7.0 все гораздо лучше (не прошло и 10 лет), но сильно сомневаюсь. Стиль IBM сырого недописанного барахла соблюдается во всем.
А Вы им пользовались? Это тулза под виндовс при помощи которой при желании можно сконфигурировать локальный QM. Сконфигурировать удаленный коннекшн нереально сложно, если вобще возможно. У меня не получилось, потому что все сделано как всегда через одно место, в стиле IBM. Вместо простой формочки, которую ожидает любой нормальный пользователь с полями: QM name, host/port, user, password, там только два поля: QM name и connection name. После получаса искания в документации оказалось, что connection name нужно писать в формате host(port), а не как привыкло 99% людей в мире: host:port. В итоге все-равно ничего не заработало, т.к. на сервере был выключен remote administration. Не понимаю, нахрен что-то там еще включать, чтобы чисто посмотреть очереди и их содержимое, если ни WMQTool, ни любой клиент этого не требует. Ну да ладно. Ввели на сервере магическую команду включения remote administration. И теперь благополучно выскакивает ошибка аутентификации. Даже при том, что аутентификация в QM выключена вообще. Посмотрев логи MQ (а это тоже надо уметь делать, ибо это вам не syslog) становится понятно, что MQ Explorer пытается залогиниться с локальным (windows!) пользователем!!! И что такой же пользователь должен существовать на машине с QM (это юникс) и быть членом группы mqm даже при выключенной аутентификации. В MQ Explorer отсутствует напрочь человеческая возможность ввести user credentials. Ладно, сознаем виндового пользователя «Administrator» на юникс машине и добавляем в группу mqm. Как несложно догадаться, опять ничего не заработало. И порывшись в интернетах находим официальное объяснение от IBm, что Websphere MQ не любит имена пользователей больше 11 символов (Administrator=13). Об этом официально написано.
И вот подобная хрень практически с любым продуктом IBM. В итоге просто сдают нервы.
> Много ли продуктов дают возможность принимать информацию практически из любого источника
Да полно Вам!!! Полно opensource и коммерческих решений как полномасштабные ESB: Mule, Fuse/Apache ServiceMix, OpenESB, Oracle ESB; так и отдельные message-серверы: ActiveMQ, HornetQ, SonicMQ… Большинство продуктов в минимальной конфигурации вообще представляют собой lightweight библиотеку. Active MQ+Apache Camel решает те же задачи, что и Websphere MQ+Broker. Поэтому думать, что IBM здесь делает что-то уникальное, вкорне неверно. Просто в один момент заняли рынок MoM как Oracle в свое время занял рынок баз данных.
Ну разве что недавно допилили. До этого приходилось постоянно делать publish, который передеплоил все приложение. Remote debug безбожно тормозил, а иногда и подвисал. Сервер после нескольких дебагов работал все медленнее.
> При разворачивании новых версий приложения я знаю следующую практику
Да, нам тоже IBM советовали это. Но таким образом теряются сессии пользователей. Если я поменял одну страничку или пару классов, мне не хочется всех напрягать перелогиниваться.
> Эти два продукта, особенно MQ, это (ИМХО) одни из лучших, как внутри IBM, так и каждый в своем классе.
Если под качеством IBM подразумевает исключительно стабильное поведение в продакшне, то может быть. Вообще MQ Series было приобретение IBM, которое не имеет никакого отношения в Websphere. Собственное, ни с чем не совместимое и не следующее никакому стандарту с жуткой внутренней архитектурой, конфигурацией и интерфейсом. IBM кое-как прикрутила к нему джаву и JMS. Есть некое подобие графического интерфейса под винду rfhutil, которое требует для подключения переменные окружения. Благо есть поделка школьника под названием WMQTools, ей и пользуемся. JMS к MQ идет отдельным модулем, опять же конфигурируется через зад (там даже своя программка есть с коммандами для создания jndi контекста). А ведь визуальный мониторинг очередей и сбор статистики — это первоочередная задача любого саппорта. Как же это делать, если для этого нет нормальной графической тулзы?
Broker вообще рудиментарная вещь. Сегодня полтора человека знают ESQL. Еще меньше пытяются использовать его для трансформаций сообщений, которые на сей день идут в формате XML. Остальные 99.(9)% привыкли юзать для трансформаций XPath, XSLT, и наконец Java. Держать в штате экзотический вид программиста, знакомого с ESQL, когда с той же задачей справится любой другой стандартными на сегодняшний день средствами, накладно и нерационально.
Так что как я уже сказал выше, есть твердое впечатление от продуктов IBM, что они сделаны не для живых людей.
А как Вы себе представляете процесс разработки под такой сервер? Ждать порядка пяти минут, чтобы сделать один единственый тест — это накладно и неправильно. Если часть логики еще более-менее можно юнитами оттестировать локально без деплоя (отсюда кстати лихорадка по поводу TDD), а если я разрабатываю веб например на JSF, мне хочется видеть любое изменение сразу же… Так что спросите у любого как они выкручиваются, и вам ответят, что веб они строчат на легком Tomcat-е и уже потом в продакшн деплоят на WAS. Когда же логика сложная, и такая фишка не проходит, то этот тяжелый серверный продукт пускают локально на девелоперской машине, чтобы можно было более-менее дебагить нормально. Так что с этой точки зрения облегченный профайл — правильный шаг в этом направлении.
> Если нужна 100% доступность — нужно разворачивать кластер
Это теоретически. На практике при штатно работающем сервере перезапускать узлы никогда не требуется. А вот когда требуется задеплоить новую версию приложения на все ноды, от этого никакой кластер не спасает. У WAS типа есть фича, что-то вроде инкрементального деплоя (Update), но реально это никогда не работало, и очень геморно юзалось. Поэтому деполют всегда по-старинке: undeploy-deploy в пять часов утра. Можно конечно вручную деплоить поотдельности на оба узла, и настроить для этого балансер, но лень возиться.
> В сервер встроено много всякого добра, для обеспечения защиты/шифрования, отказоустойчивости,
В том-то и дело, что это реально не нужно. Если ваше приложение требует что-нибудь больше, чем Tomcat+Spring — это неправильное приложение, которое делает неправильный мед. Хотя это уже тема не столько Websphere сколько вообще инфраструктуры JEE. Сегодня никому нафиг эти тяжелые сервера не нужны с кучей непонятного и неудобоваримого API. Все это можно использовать при необходимости и вне JEE контейнера.
Так что IBM нужно менять стратегию и ориентироваться на живых людей. То что до этого делалось — это тихий ужас: Websphere Portal, Websphere Business Integration Platform, Websphere Process Server, Websphere Message Broker, Websphere MQ. Одно приятное исключение — DB2. Сорри за субъективизм.
1. Никто не будет спорить, что по меркам того времени после C++, Delphi и подобных простота и лаконичность Java вкупе с GC давала огромную фору. Кроме того, достаточно полный и продвинутый API позволял легко сделать нетривиальные вещи. Достаточно низкий порог вхождения, сишный синтаксис и ориентированность на то, чтобы «не выстрелить себе в ногу» (напр. checked exceptions) в разы упрощала разработку.
2. Кросплатформенность. Удивительно, но код, работающий одинаково без сборки и перкомпиляции работает одинаково на чем угодно, где есть JVM. По тем временам это был настоящий прорыв. Идеология SUN (write onсe run everywhere) дала свои результаты. Это позволило легко разрабатывать и запускать даже для ни с чем не совместимых монстров. Однако, с GUI дела обстояли не так гладко. Ввиду неоднородности виджетов на разных платформах было выбрано минимальное их множество, включенное в AWT. Когда же поняли, что этого не хватает, сделали Swing, с полностью джавовским рендерингом. Но проблемы не исчезли: виджетов все-равно не хватало (по сравнению с MFC или VCL), приходилось поддерживать look-and-feel разных платформ, нельзя встраивать нативные компоненты, etc. Однако возможность писать игрушки для статичных в то время вебстраниц привлекло к Java кучу разрабочиков. И поспособствовала этому именно Microsoft, включив свою Java 1.1 в Windows. После иска Sun к Microsoft те потихоньку выпилили Java из Windows и вместе с этим прошел бум на аплеты: реально в то время мало юзеров с диалапом хотели тащить многотонную JVM от сан. К тому же MS JVM работала с графикой в разы быстрее, быстрее пускалась и отжирала меньше памяти. («Приложеньице запущено» — для тех, кто помнит ;)
3. В SUN быстро поняли, что кроссплатформенность может быть полезной штукой и в разы упрощала написание серверных приложений (опять же по тем временам). И тут ребята подошли со всем размахом и серьезностью. Они начили активно пиарить Java как серверную платформу. Заручились поддержкой других компаний (IBM, Oracle,...) и создали JCP. Типа теперь в рамках всеобщей совместимости мы будем вместе заключать стандарты, а каждый производитель уже будет сам дописывать имплементации. В JCP родилось такое жуткое чудовище как Java ынтерпрайз ыдишн. Писать на нем что-то удобоваримое (а именно простые веб странички) до самого последнего времени было жутко дорого, долго, и глючно. Однако провайдеры быстро поняли, что чем дороже и сложнее делается проект, тем больше бабла можно срубить на саппорте, обучении и задвигании дорогих и объективно ненужных решений. Они резко подключились к активному пиару Java среди компаний-клиентов: семинары, проспекты, статьи, работа с клиентами, ВУЗами, девелоперами… На фоне растущего пузыря доткомов и всеобщей информатизации задвинули Java практически в любую контору. В итоге когда выдрессированному клиенту презентуешь план проекта, он спрашивает: «а какой сервер апликаций вы будете использовать»? Плюс паралельно САН пыталась запилить Java в каждую стиральную машину и чайник, что естественно добавляло понтов. После развала доткомов сразу же открылась такая профитная область как недотелефоны, куда стараниями ребят из JCP и SUN, можно было залить недоигрушку и даже немного поиграть в нее.
Тем не менее, JCP на всем протяжении пеклось об обратной совместимости. Именно поэтому многие выбирают Java как технологический стандарт для своей компании. Код, написанный для самой первой JVM будет точно также работать и компилироваться в последней (естественно, теоретически).
4. Это уже второстепенная причина. Понимая, что Java — мощное орудие, но меркнущее, будучи загнанным в рамки JSR-ов и J2EE, разработчики-энтузиасты мало по малу начали писать свои библиотеки и фреймворки. По началу для себя. Потом это вылилось в разные communities, одно из них была организована самой Sun (java.net). Все это росло как снежный ком, кодовая база увеличивалась, и вот уже communities диктуют архитектуру и технологические решения (Maven, Spring, Hibernate, Struts, etc...) основная идея их всех — сделать как можно проще повседневные вещи (однако получается не всегда). Сейчас на Java, наверное, самая мощная база решений после C на все случаи жизни. Сейчас разработчик Java — это не только тот, который знает язык, но и хорошо плавает в бульоне различных околотехнологичных решений. Как это программист Java и не знает Maven/Ant?
5. Тоже второстепенное, но серьезно добавило ништяков. Это Eclipse. Долгое время SUN не могла выпустить удобоваримую IDE. По сравнению с существовавшим в то время Visual C/Basic от MS и богатством Delphi мало кому хотелось задиться за Notepad. Eclipse в то время был босяцким подгончиком для всех Java-девелоперов. Открытая архитектура позволяла дописывать плагины на все случаи жизни. Позже САН допилила свою IDE до Netbeans, но паровоз уже был угнан.
А половина причин, описанных в статье — десятые производные от этих. Как говорится, надо смотреть в корень!
for $p in doc('company')/Persons/Person[@name='Vasya'] for $d in doc('company')/Departments/Department where $d/Stuff/personRef=$p/@id return <department>$d/@name</department>То есть все отделы, где работает хотя бы один Вася.
Внутренний и внешний циклы можно поменять местами: внешний лучше поставить тот, где больше записей. Как это будет выполнять XBase непонятно. Например, если в RDBMS поля personRef и id проиндексированы, она вообще убирает внутренний цикл, заменяя параллельным сканом обеих таблиц. Если же XBase каждый раз выполняет внутренний скан, то на больших объемах данных это будет еле ворочаться.
Во-первых, складывается впечатление, что XML базы данных рассчитаны в основном на чтение, а не на обновление. Для чтения используются стандарт XPath/XQuery, тогда как запись ведется при помощи собственного API. Все попытки стандартизировать API (xqj, xml:db) недоработаны. Отсутствие клиентских транзакций приводит к тому, что всю логику нужно выполнять в одном вызове (запроса либо скрипта).
Непонятно как себя ведут сложные «пересекающиеся» запросы (по типу JOINs и подзапросов в RDBMS) на больших объемах данных, может ли BaseX сам оптимизировать плохие запросы и каким образом использует индексы в данных запросах.
Поэтому основное применение — standalone приложения, которые ищут по большому числу xml документов.
P.S. У BaseX есть два других open-source конкурента: eXist и Sedna. Первый достаточно навороченный, а второй написан на C. Здесь преимущество BaseX — легковесность и возможность запускаться в embedded режиме.
— когда компоненты достаточно независимы и слабо связаны функционально
— при асинхронном взаимодейтвии компонентов
— когда нужно связать две несовместимые модели, например модель данных приложения и GUI
— в качестве локальных callback-ов от компонентов низкого уровня к более высоким, если нельзя обойтись без них
Потенциальные проблемы, за которыми нужно будет следить, если испльзовать события:
— регистрация/дерегистрация хендлеров. Как правило 80% всех ошибок в свинге, связанных с memory-leaking. Спасает EventBus с weak хендлерами.
— когда в процессе обработки события одини из хендлеров генерирует новое. Логика подсказывает, что оно должно обработаться после текущего, однако реально оно обрабатывается синхронно прямо в момент выкидывания. Частично спасает EventBus с асинхронной очередью, ибо в очереди уже могут стоять другие события, которые к моменту обработки данного делают состояние системы несовместимым. Например, кнопка окна выкинула, что она нажалась, а следующим в очереди уже стояло закрытие окна. В итоге обработчик получил нажатие кнопки, которая уже не существует, что могло бы спровоцировать трудноотлавливаемую ошибку.
— запутанные зависимости и дилема: в какой последовательности правильно останавливать компоненты?
— ну и классика при использовании в multithreaded environment: дедлоки всех возможных видов.
Вобщем, мы радикально поменяли стратегию и попробовали Embedded Jetty + GWT + SmartGWT + IE ActiveX. Результаты превзошли ожидания! Сейчас пробуем Jetty + Vaadin + Chromium Embedded.
P.S. я реально не вижу преимуществ у JavaFX перед уже существующими веб-технологиями. Кроме того, вполне возможно, что при низкой востребованности Oracle примет очередное решение, выпилив его обратно из Java, как это произошло с 1.3.
— сильно затрудняет нахождение ошибок и отладку
— не гарантирует и не контролирует последовательность обработки событий и соответственно делает непредсказуемым поведение системы
Я раньше много писал на свинге и знаю что такое. И в самой библиотеке были баги и практически все приложения подглючивали.
Поэтому если можно обойтись без событийной модели — оно всегда предпочтительней.