Игорь Артамонов

Несколько лет назад появился Google Webtoolkit, для меня в тот момент это казалось прорывной технологий. Главная идея была в том чтобы писать код web приложения, или его части, на Java, который потом компилируется в HTML + JavaScript. В чем было преимущество? В том что для java в то время уже была создана очень мощная система поддержки разработки: интеллектуальная среда разработки, средства рефакторинга, юнит тестирование с кучей дополнений, автоматический анализ кода и code coverage, документирование и пр. и пр. Да до сих пор тут нет ей равных. Ну и сам язык, с понятным синтаксисом, типизированный (в данном случае это было плюсом) и пр.

А вот в JavaScript тогда не было ничего. FireBug только появлялся, jQuery не было. Отладка была лишь за счет alert'ов. Серьезный процесс разработки на этом не построишь.

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

А в прошлом году происходил какой-то фантастический рост использования JavaScript. Появились тысячи библиотек. Благодаря jQuery код писать становится на порядок проще, появились средства разработки (IDEA стала ничуть не хуже работать с HTML/JavaScript/CSS), firebug вырос, и пр. Теперь все совсем наоборот, разработка на JavaScript стала гораздо проще чем на GWT, разрабатывать действительно быстрее и результат получается качественней. Есть, конечно, еще куча вещей которые нужно сделать, но уже вполне неплохо. И как минимум позволило ему стать лидером прошлого года, помимо возросшей востребованности.

Я в данном случае не эксперт, но похоже как-то так. А вы что скажете? Вырос ли javascript до уровня серьезной разработки? Какие полезные инструменты порекомендуете? И в каких случаях есть смысл использовать gwt?

Вчера беседовал с Марком Полаком из SpringSource и узнал что они сейчас занимаются, помимо прочего, проектом Spring Data. Это будет некий ORM. Так что, во-первых, все недовольные Hibernate и пр. могут иметь ввиду. А во-вторых эта штука делается и для NoSQL решений, что для моих проектов очень интересно.

Стабильное решение будет не скоро, проект в самом начале пути, нет ни плана, ни майлстоунов, ни объявлений, но есть надежда что выкатят летом-осенью следующего года. Ну а сейчас, говорит, уже работает для Neo4J и MongoDB.

Там, кстати, Gitorius. Так что можете поучаствовать, если хочется использовать пораньше, ну или можно найти что-нибудь другое, интересное вам: http://git.springsource.org/

VMWare только что показали презентацию своего VMForce, платформу для приложений внутри SalesForce, на основе Spring Framework.

Презентация была, к сожалению, совсем не бизнесовая, а техническая. Зачем то показывали примеры кода и пр., но не рассказали зачем это. Но общую идею, конечно, можно понять. VMForce это PaaS для реализации своих приложений, интегрированных в инфраструктуру Salesforce, работающую на их серверах, с их базой данных и их клиентами. Видимо деньги за использование будут будут тоже как-то пилиться между вендорами и salesforce, но вот эту часть вообще мимо обошли, как и много другое.

А вообще вот презентация (это не то что было на официальном представлении, но суть передает):

Да, все идет к этому, к SaaS, PaaS, Enterpise 2.0, интеграции приложений под одним зонтом и пр. Мы собственно сейчас занимаемся тем же самым, посмотрим кто кого VMForce что-то реальное собирается показать во второй половине года, мы надесь тоже.

P.S. Но суть презентации я не понимаю, хоть убей, что они хотели сказать то? Все сводилось к лозунгу что «Java может работать в облаке». И чо? Кто-то разве сомневался? Не объяснили ни зачем это нужно бизнесу, ни зачем это нужно вендорам, ни что вообще хотят сделать. И вообще трансляция была полуработающая Такое ощущение что им срочно нужно было хоть что-то сказать, но времени на полноценную подготовку не было.

Нашел интересный прототип фреймворка для распределенных вычислений: Swarm-DPL

Основная идея в том что код выполняется как можно ближе к данным, и даже больше, он постоянно мигрирует между разными машинами, старясь быть ближе к ним, без остановки основного вычислительного алгоритма. В общем это continuations с переносом состояния между нодами. Это в пику подходу map-reduce когда у нас именно данные гоняются между нодами. Код все таки меньше места занимает, должно быть быстрее, это не гигабайты данных по сети гонять.

Рекомендую посмотреть презентацию:

Swarm: Distributed Computation in the Cloud from Ian Clarke on Vimeo.

Реализовано на Scala, хотя думаю что никто не мешает реализовать идею на другом языке, и тем более уж под JVM. Автор, правда, утверждает обратное, но причина в том что в Scala все уже есть для этого, уже сейчас, и для прототипа как раз подходит. Ну и насколько я понимаю подобную оптимизацию можно реализовать в GridGain и сейчас, указав ноды для MR, но тут идея более интересная.

Наверное все в курсе произошедшей на этой недели покупки SpringSource компанией VMWare. Меня, например, это сильно удивило, совсем не ожидал. Судя по прессрелизу все ради того чтобы обосноваться в нише cloud computing. Ну в общем да, на уровне инфраструктуры виртуализации у VMWare все хорошо, даже очень, а вот в остальном видимо решили докупиться (к тому же виртуализацией как таковой сейчас занялись очень многие, надо идти дальше, предлагать платформу).

И я их наверное начинаю понимать, cloud computing это довольно специфичная область. Читать далее »»

Меня, если честно, всегда смущал тот факт что Oracle пихают во все задачи, куда только можно, бытует мнение что «БД это Оракл». Я лично не думаю что это прям такая «серебряная пуля». MySQL занимает те же позиции немного на другом фронте. Да, Oracle в частности, MySQL, и реляционные БД в общем, это отличный инструмент, но для случая когда у нас реально востребована эта реляционность.

Но ведь Оракл используют независимо от того нужна ли нам реляционность, просто по привычке, и потому что «все так делают». Я за все свое время редко встречал нормализованные структуры, и даже больше, часто встречал таблицы БД с колонками вида col_1, col_2, col_N и пр. нарушениями всех форм, когда также разрезали таблицы на отдельные, в том числе отдельные инстансы БД. Встречал также когда в Oracle складывали черт знает что, когда использовали как хранилище лога операций, десятки гигабайт логов, ну и т.д. И никакого серьезного положительного эффекта от реляционных возможностей во всех этих случаях не было.

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

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

В общем я не сторонник использования реляционной БД всегда и везде, на любой чих. Это хорошая технология, спасающая в огромном множестве случаев, но RDBMS это совсем не серебряная пуля.

Поэтому хотел бы обратить внимание на другой тип баз, на колоночные БД.
Читать далее »»

GridGain — платформа для реализации cloud вычислений. На мой взгляд очень серьезная платформа, вполне стабильная (если это имеет значение то версия, например, уже 2.1.0) имеет открытый код, на java, интегрируется с огромным количеством внешний систем. В отличие от пока академического Apache Hadoop здесь уже все более практично. А разобраться и запустить можно за пару часов, в отличии от...

Самый известный, наверное, подход к cloud вычислениям это mapreduce, и он прекрасно здесь организован. А так как этот mapreduce не всем понятен, да и не всегда нужен полностью, то здесь помимо него предлагается своя реализация java.lang.concurency.ExecutorService который разбрасывает переданные вычисления по кластеру.
Читать далее »»

Java, как язык — ничего особо выдающегося. Да даже тот же C# внешне выглядит приятней, что уж говорить о многих динамических языках. Хотя, если насчет самого синтаксиса Java, то тут тоже наметилась тенденция, уже есть вполне неплохие JRuby, Groovy, Scala и Clojure, выбирай по вкусу.

Так вот, хоть как язык Java и проигрывает, но она имеет за плечами огромный набор библиотек, для решения почти всех востребованных задач. Я бы даже выразился так:

На каждую хитрую задачу найдется свой jar с винтом.

ну может не всегда именно jar, а скорее технология, протокол, спецификация, но суть в общем такая.

У всех остальных все хуже. Там или узкая заточенность под одни нужды (RoR), или единая линия партии (.Net), или просто полный хаос.

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

Поэтому нравится java или нет, но... но чаще всего выбирать и не из чего.

P.S.: Хотя, если честно, есть тут один минус: это то что привыкнув к этому все стараются делать «через жаву», что не всегда верно, но это уже издержки производства.

Как то так сложилось что при моем примерно 7-летнем опыте коммерческой разработки на Java я почти не имею опыта в EJB. Хотя это первое что спрашивают на собеседовании, я ведь проверял не так давно. Самое интересное, кстати, в том что многие собеседователи после кучи вопросов по опыту в EJB/WebSphere/JMS/пр., о том как это все им важно и пр., рассказывая о своих проектах, говорят что на практике все их проекты разрабатываются без какого либо EJB и прекрасно работают по Tomcat, а WebSphere получается лишь для веса. Возможно и потому что не серьезно сейчас предлагать решение без WebSphere/WebLogic + Oracle.

А мне всегда как то хватало связки Spring + Hibernate + Tomcat/JBoss, что в сущности дает тоже самое, но удобнее. Список можно продолжить добавив еще как минимум Acegi, AspectJ, и прочие решения умеющие хорошо и удобно решать свою отдельную задачу, многие легко взаимозаменяемы и дают очень неплохой синергетический эффект.
Читать далее »»

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

Поэтому проведем экперимент, сравним алгоритм по умолчанию, и пару считающихся лучшими алгоритмов. Выберем, так сказать, the best of the best среди хэширования Конкретно для меня, это равная вероятность состояний отдельных бит, в 32х битном целом. Т.е. чем ближе вероятность появления «1» в каждой из позиций к вероятности ½ тем лучше.
Читать далее »»