VMForce
27 апреля 2010
VMWare только что показали презентацию своего VMForce, платформу для приложений внутри SalesForce, на основе Spring Framework.
Презентация была, к сожалению, совсем не бизнесовая, а техническая. Зачем то показывали примеры кода и пр., но не рассказали зачем это. Но общую идею, конечно, можно понять. VMForce это PaaS для реализации своих приложений, интегрированных в инфраструктуру Salesforce, работающую на их серверах, с их базой данных и их клиентами. Видимо деньги за использование будут будут тоже как-то пилиться между вендорами и salesforce, но вот эту часть вообще мимо обошли, как и много другое.
А вообще вот презентация (это не то что было на официальном представлении, но суть передает):
Да, все идет к этому, к SaaS, PaaS, Enterpise 2.0, интеграции приложений под одним зонтом и пр. Мы собственно сейчас занимаемся тем же самым, посмотрим кто кого
VMForce что-то реальное собирается показать во второй половине года, мы надесь тоже.
P.S. Но суть презентации я не понимаю, хоть убей, что они хотели сказать то? Все сводилось к лозунгу что «Java может работать в облаке». И чо? Кто-то разве сомневался? Не объяснили ни зачем это нужно бизнесу, ни зачем это нужно вендорам, ни что вообще хотят сделать. И вообще трансляция была полуработающая
Такое ощущение что им срочно нужно было хоть что-то сказать, но времени на полноценную подготовку не было.
Swarm DPL
2 октября 2009
Нашел интересный прототип фреймворка для распределенных вычислений: Swarm-DPL
Основная идея в том что код выполняется как можно ближе к данным, и даже больше, он постоянно мигрирует между разными машинами, старясь быть ближе к ним, без остановки основного вычислительного алгоритма. В общем это continuations с переносом состояния между нодами. Это в пику подходу map-reduce когда у нас именно данные гоняются между нодами. Код все таки меньше места занимает, должно быть быстрее, это не гигабайты данных по сети гонять.
Рекомендую посмотреть презентацию:
Swarm: Distributed Computation in the Cloud from Ian Clarke on Vimeo.
Реализовано на Scala, хотя думаю что никто не мешает реализовать идею на другом языке, и тем более уж под JVM. Автор, правда, утверждает обратное, но причина в том что в Scala все уже есть для этого, уже сейчас, и для прототипа как раз подходит. Ну и насколько я понимаю подобную оптимизацию можно реализовать в GridGain и сейчас, указав ноды для MR, но тут идея более интересная.
Spring + VMWare
14 августа 2009
Наверное все в курсе произошедшей на этой недели покупки SpringSource компанией VMWare. Меня, например, это сильно удивило, совсем не ожидал. Судя по прессрелизу все ради того чтобы обосноваться в нише cloud computing. Ну в общем да, на уровне инфраструктуры виртуализации у VMWare все хорошо, даже очень, а вот в остальном видимо решили докупиться (к тому же виртуализацией как таковой сейчас занялись очень многие, надо идти дальше, предлагать платформу).
И я их наверное начинаю понимать, cloud computing это довольно специфичная область. Читать далее »»
Колоночные базы данных
17 февраля 2009
Меня, если честно, всегда смущал тот факт что Oracle пихают во все задачи, куда только можно, бытует мнение что «БД это Оракл». Я лично не думаю что это прям такая «серебряная пуля». MySQL занимает те же позиции немного на другом фронте. Да, Oracle в частности, MySQL, и реляционные БД в общем, это отличный инструмент, но для случая когда у нас реально востребована эта реляционность.
Но ведь Оракл используют независимо от того нужна ли нам реляционность, просто по привычке, и потому что «все так делают«. Я за все свое время редко встречал нормализованные структуры, и даже больше, часто встречал таблицы БД с колонками вида col_1, col_2, col_N и пр. нарушениями всех форм, когда также разрезали таблицы на отдельные, в том числе отдельные инстансы БД. Встречал также когда в Oracle складывали черт знает что, когда использовали как хранилище лога операций, десятки гигабайт логов, ну и т.д. И никакого серьезного положительного эффекта от реляционных возможностей во всех этих случаях не было.
Не знаю может это мне так всегда везло и в других проекта все всегда «красиво», не нарушается ни одной из «нормальных форм» и пр, но у меня опыт вот такой.
Под реляционностью в данном случае я подразумеваю не только то что данных хранятся в виде таблице (с заранее четко оговоренным списком атрибутов). Я имею ввиду все что вертится вокруг этого: нормальные формы, внешние ключи, связи и ограничения, acid, собственно реляционная алгебра и все прочее предназначенное для облегчения хранения и соблюдения целостности структурированных данных.
В общем я не сторонник использования реляционной БД всегда и везде, на любой чих. Это хорошая технология, спасающая в огромном множестве случаев, но RDBMS это совсем не серебряная пуля.
Поэтому хотел бы обратить внимание на другой тип баз, на колоночные БД.
Читать далее »»
GridGain
29 января 2009
GridGain – платформа для реализации cloud вычислений. На мой взгляд очень серьезная платформа, вполне стабильная (если это имеет значение то версия, например, уже 2.1.0) имеет открытый код, на java, интегрируется с огромным количеством внешний систем. В отличие от пока академического Apache Hadoop здесь уже все более практично. А разобраться и запустить можно за пару часов, в отличии от…
Самый известный, наверное, подход к cloud вычислениям это mapreduce, и он прекрасно здесь организован. А так как этот mapreduce не всем понятен, да и не всегда нужен полностью, то здесь помимо него предлагается своя реализация java.lang.concurency.ExecutorService который разбрасывает переданные вычисления по кластеру.
Читать далее »»
jar с винтом
25 ноября 2008
Java, как язык – ничего особо выдающегося. Да даже тот же C# внешне выглядит приятней, что уж говорить о многих динамических языках. Хотя, если насчет самого синтаксиса Java, то тут тоже наметилась тенденция, уже есть вполне неплохие JRuby, Groovy, Scala и Clojure, выбирай по вкусу.
Так вот, хоть как язык Java и проигрывает, но она имеет за плечами огромный набор библиотек, для решения почти всех востребованных задач. Я бы даже выразился так:
На каждую хитрую задачу найдется свой jar с винтом.
ну может не всегда именно jar, а скорее технология, протокол, спецификация, но суть в общем такая.
У всех остальных все хуже. Там или узкая заточенность под одни нужды (RoR), или единая линия партии (.Net), или просто полный хаос.
Главное – это все таки сколько у тебя за спиной готовых, зарекомендовавших себя и переиспользуемых решений. А что до производительности и требования к ресурсам, так с этим уже давно все хорошо, все работает достаточно быстро, если написать конечно как положено, а не как обычно. Да и в последнее время это уже неактуальная проблема, сейчас в цене не производительность, а масштабируемость.
Поэтому нравится java или нет, но… но чаще всего выбирать и не из чего.
P.S.: Хотя, если честно, есть тут один минус: это то что привыкнув к этому все стараются делать «через жаву», что не всегда верно, но это уже издержки производства.
Я не знаю EJB и JSF
6 августа 2008
Как то так сложилось что при моем примерно 7-летнем опыте коммерческой разработки на Java я почти не имею опыта в EJB. Хотя это первое что спрашивают на собеседовании, я ведь проверял не так давно. Самое интересное, кстати, в том что многие собеседователи после кучи вопросов по опыту в EJB/WebSphere/JMS/пр., о том как это все им важно и пр., рассказывая о своих проектах, говорят что на практике все их проекты разрабатываются без какого либо EJB и прекрасно работают по Tomcat, а WebSphere получается лишь для веса. Возможно и потому что не серьезно сейчас предлагать решение без WebSphere/WebLogic + Oracle.
А мне всегда как то хватало связки Spring + Hibernate + Tomcat/JBoss, что в сущности дает тоже самое, но удобнее. Список можно продолжить добавив еще как минимум Acegi, AspectJ, и прочие решения умеющие хорошо и удобно решать свою отдельную задачу, многие легко взаимозаменяемы и дают очень неплохой синергетический эффект.
Читать далее »»
Выбор лучшего алгоритма хэширования строк
8 мая 2008

Неоднократно слышал о том что метод вычисления хэша, реализованный по умолчанию, для строк в Java не совсем хороший. Якобы много коллизий и пр. На замену ему можно найти в интернете несколько иных алгоритмов, но тоже непонятно какой лучший.
Поэтому проведем экперимент, сравним алгоритм по умолчанию, и пару считающихся лучшими алгоритмов. Выберем, так сказать, the best of the best среди хэширования
Конкретно для меня, это равная вероятность состояний отдельных бит, в 32х битном целом. Т.е. чем ближе вероятность появления «1″ в каждой из позиций к вероятности 1/2 тем лучше.
Читать далее »»
Указываем редактируемые поля
21 февраля 2008
При редактировании объекта через форму есть потенциальная уязвимость в системе, т.е. даже если мы в самой форме не указали внутренние поля (id, role, и пр) то хакер всегда может передать их в запросе сам. Конечно ему нужно знать какие поля есть в объекте, что бы передать для них значения, но это отнюдь нас не защищает. Некоторые интересные поля можно найти перебором по словарю.
Так вот, я к тому что Spring предоставляет возможность указать какие поля позволено менять извне. И при формировании объекта, из переданных в POST значений, будут заполненны лишь определенные поля.
Указывается все очень просто:
protected void initBinder(HttpServletRequest request, ServletRequestDataBinder binder) throws Exception {
super.initBinder(request, binder);
binder.setAllowedFields(new String[] {"title", "content"});
}
По хорошему, в зависимости от ролей пользователя, нужно менять список доступных для редактирования полей. Админу разрешить менять вообще все (это по умолчанию), а остальным указать что можно.
Использование Struts Tiles + Spring Framework
18 июня 2007
Одной из фич Struts Framework, помимо MVC для веба, была библиотека тегов Tiles, идущая с ним. Тайлы много что могут, но главное что они помогают сделать наследования страниц. Да, так же как объекты, в корневом определяем базовые методы, а в предках что то переопределяем и добавляем новое.
При этом эта библиотека может использоваться и отдельно от Struts, она прекрасно интегрируется в Spring Framework.
Вот без тайлов как может выглядеть структура JSP страницы?
[инклюд хидера]
[тело страницы]
[инклюд футера]
Ну вроде так ничего сложного, типичный PHP стиль. А теперь допустим в хидере у нас что то меняется, например картинка раздела, подключается дополнительный css, JavaScript или еще что то. Вот тут все и начинается: в хидере пишется страшная логика охватывающая весь проект, которая, в зависимости от адреса, начинает что то включать/выключать, при инклюде передаются различные параметры, чтобы все это работало и т.д. Немного неудобно получается.
Читать далее »»
