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

Погоняв Google App Engine пару месяцев расскажу о впечатлениях от него.
Платформа несомненно интересная, и будет очень полезна startup’ам, т.к. позволяет сосредоточится на решении своих конкретных задач, отдав все что не является конкурентым преимущество на откуп платформе и её сервисам.

К сожалению прям вот взять любой сайт и запустить его на GAE не получится, нужно делать именно под него, на Python или JVM, и нужно хорошо понимать как это работает. Я смотрел лишь связку Python + Django. Многие преимущества Django тут отсутствуют (например знаменитая админка django), но тем не менее результат получается очень быстро и вполне качественно. Для JVM есть многообещающий Gaelyk, ну и куча прочих framework’ов.
Читать далее »»

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

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

Допустим у нас стоит задача: нужно собирать неструктурированные html данные и извлекать из них структуру, или, точнее, информацию, т.е. система Text Mining/Information Extraction.

Вcе элементы этого процесса, конечно, должны где то хранится. И если конечную информацию можно структурировать, завести с десяток таблиц в БД, настроить связи и складывать туда, то входная информация по определению у нас не структурирована, ну или, как минимум, слабо структурированная. Если делать сложную структуру то из-за специфики нашей задачи нам будет очень сложно отследить целостность данных. К слову о сложности работы с такой структурированностью замечу что я попытался было нарисовать это подход, но не смог сделать чтобы это было внятно, без всего лишнего.

Поэтому нужно придумывать какое то простое и универсальное решения для этой задачи. Одна из них это структура когда у нас для всего выделена одна таблица, в первые колонки которой заливается начальная структура. Далее они обрабатываются нашей программой для структурирования, и результат складывается рядом, в следующие колонки. Причем если результат мы получаем не за один шаг, что чаще и бывает, то в таком случае мы последовательно выполняем все шаги, складывая новые данные правее от текущих.
Читать далее »»

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

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

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

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

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

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

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

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

Подход mapreduce сейчас, с ростом объемов вычислений, стал очень популярен, но все упоминания какие то туманные, надо разложить все по полочкам. Начну с того что напомню о такой штуке как «закон Амдала». Он описывает ограничение роста производительности вычислительной системы с увеличением количества вычислителей, т.е. как мы можем ускорить вычисление увеличивая количество компьютеров в кластере. В общем то тут все интуитивно понятно. Читать далее »»

Как то так сложилось что при моем примерно 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″ в каждой из позиций к вероятности 1/2 тем лучше.
Читать далее »»

Кто там говорит что perl-код не читабелен? Вот вам реализация soundex на языке K:

sdx:"bfpvcgjkqsxzdtlmnr"!(4#1),(8#2),(3 3 4 5 5 6)
nn:{d2:x where x > 0;r:d2 where d1:0w<>':d2}
soundex:{(x[0],(nn (sdx@1 _ x)),l:4#0)[til 4]}

угу, именно так… Похоже что клавиатуру протирали.
Теперь запускаем: Читать далее »»

Приведу небольшой список правил, на которые можно разумно ориентироваться при проектировании новой XML структуры. Это конечно не «истина в последней инстанции», и есть куча случаев когда некоторые из них совсем не подойдут, но в общем виде, как ориентир, ознакомится следует, чтобы не плодить xml документы с которыми невозможно работать.

1. Используйте атрибуты для одной группы

Выносите короткие значения из одной группы в атрибуты.
Лучше

<user name="John" sname="Smith"/>

чем

<user>
 <name>John</name>
 <sname>Smith</sname>
</user>

Читать далее »»