Web растет

• на десктопе перестали появляться значимые приложения (за исключением игр)
• люди проводят все больше и больше времени в интернет. Телевидение, радио и газеты сдают свои позиции

Приходит HTML5

• к концу года будет поддерживаться всеми современными (= новыми) браузерами
• открыли WebM (web media) – видео кодек vp8, его поддержали opera и mozilla.
• я не специалист, и зрение у меня не очень, поэтому не заметил особых проблем по сравнению с h264, но некоторые утверждают что качество хуже.
• Adobe встроит VP8 в Flash Player -> он появится и в устаревших браузерах -> получается единый кодек для видео в инете

Chrome Web Store

• продажа web приложений как «коробок»
• Еще один шаг к Google OS

Google Wave

• открыт для всех
• ускорен, расширен API и т.д.
• использовался для обсуждения на всех секциях Google IO, получилось очень удобно

Сотрудничество с VMWare

• Spring Roo научился генерить GWT интерфейс
• за несколько минут, на наших глазах, было написано полноценное приложение на Spring Roo для GAE + GWT

GWT 2.1

• работа на разных устройствах
• встроен MVP
• новые компоненты для отображения больших объемов данных
• Speed Tracer учитывает серверный код

App Engine

• для бизнеса
• поддержка OAuth и OpenId
• инструментарий загрузки и выгрузки данных
• планы на Comet и длительную обработку данных (mapreduce я так понимаю)

Fonts API

• набор [нестандартных] шрифтов подключаемых через CSS + Javascript

Android 2.2

• очень хорошо ускорена виртуальная машина (уже имеющиеся приложения начинают работать в 2-5 раз быстрее)
• перевод текста
• голосовые команды
• очень хорошо стебались над iPad, iPhone
• раздарили HTC Evo всем участникам конференции
• поддержка flash 10.1
• и много прочего

Google TV

• как приставка к имеющемуся телевизору, или как телевизор с встроенным Google TV
• поиск по TV каналам, с возможностью записи и т.д.
  выход в web, просмотр видео в инете, покупки фильмов онлайн (amazon, netflix, пр.)
• на него можно будет ставить приложения android
• получается интересный медиацентр для дома
• толком не работал, постоянно ломался «пульт управления»
• будет в продакшне к следующему лету

Ну и вывод: интернет меняется, и с огромной скоростью

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

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

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

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

Кто нибудь занимается datamining, textmining, ir и прочими делами с большими массивами данных? Вот запустил небольшой сервис: datasetpublisher.com – торрент трекер для коллекций данных. Т.е. чтобы не качать очередные 5G дампа википедии со скоростью 70Kb/s (докачается как раз к моменту когда выложат новый дамп), а скачать с нормальной скоростью через торрент.

Только запустил, поэтому там пока пусто, но будем наполнять. Если есть желание и есть что – то выкладывайте. Я, в свою очередь, постараюсь донести об этом сервисе до всех заинтересованных лиц.

Проект запущен на Google App Engine, что собственно и послужило причиной его появления. Уж очень я в последнее время заинтересовался этой платформой, и решил поэксперементировать. А так как я очень не люблю что-то делать «в корзину», и считаю что подобные эксперименты, помимо исследовательской цели, должны принести конкретный применимый сейчас результат. И вспомнил разговор с Иваном Бегтиным, незадолго до этого, о том что неплохо бы иметь подобный ресурс. Теперь он есть. И с GAE разобрался, на него еще посмотрю как вести себя будет, и напишу свое мнение.

В корпоративном секторе упомянутые подходы давно опробованы, и есть куча внедрений, ну правда в Россию это пришло сравнительно недавно, но западный опыт довольно обширный. Так вот, хочу поразмышлять по поводу приложения этих методик в web приложения. Как я уже описал, это применимо для социальных сетей и вообще сайтов содержащих большой объем пользовательской информации. В последнее время это становится очень даже популярным, появляются различные инициативы по интеграции сервисов друг с другом, по передачи пользовательской информации. Упомянул я и протоколы, которыми кто то уже начал пользоваться, а кто-то присматривается.

Первый этап, «с основой на CRM», в данном случае выражает наличие монстров типа Одноклассники и ВКонтакте. Так как помимо них есть куча мелких сетей, то и виртуальные модели тоже появляются. Из российских это нашумевший в определенных кругах bestpersons. С некоторыми косяками, но он первопроходец, ему положено первому наступать на все эти грабли, и пока даже можно простить тот самый косяк. Ну а дальше все идет к тому что мы переключимся на центр персональных данных, не привязанных к определенному сайту. Будет некие информационные хабы, может их предоставят и упомянутые социальные сети.

Есть даже мнение, которое я поддерживаю, что вся эта взаимная интеграция сайтов есть немаловажная часть будущего web 3.0, возможно даже самая главная часть.

Идея что для web’а что для enterprise одинакова, но в случае бизнеса уже множество раз опробованная, а в web лишь только зарождается. В случае социальных сетей нет такого желания объединиться, по крайней мере со стороны сервисов, это удобно лишь конечному пользователю. Крупные социальные сети пока считают что тем самым они могут потерять своих пользователей, и судя по всему они слишком жадные до данных, скорее всего они будут сильно сопротивляться этим инновациям, пока окончательно не умрут. Те же одноклассники сейчас ценятся лишь огромной базой пользователей, а не теми услугами которые они предоставляют для них. Ну на самом деле, разместить фото и отписать «как дела?» можно и без них, но показывать это фото обычно некому, нужно в начале найти этого человека И ведь ничего суперсовременного тут нет, нужна лишь база по которой можно найти своих одноклассников, а дальше уже мелочи.

Пользователю же подобный хаб дает большие возможности. Как минимум имея единый профайл, содержащий всю нужную и, что очень важно, всегда актуальную информацию о себе, о связях с другими людьми, к тому же сгруппированную по типам (друзья, деловые знакомые и пр.) а также медиаданные, такие как фото, видео и тесты, можно использовать внешние сервисы именно как индивидуальные услуги. Предоставляя каждому сервису определенный срез своих данных. На одном сервисе напишет другу как дела и покажет фотку «у машины» или «на курорте», на другом сервисе красивое «фото для души» и «я купил мыльницу с макросьемкой», а на третьем серию фоток с очередного праздника. Идея думаю понятна. Технически это конечно не обязательно будет именно физически единый центр/сайт/сервис. Опыт CDI показывает что наиболее вероятно распределенное хранение, как несколько связанных БД, т.е. распределенная работа с данными, но единая точка связи всех данных.

Закончим с философией и мечтами о светлом будущем, в данном случае растекаться мыслью по древу можно очень и очень долго. Основная мысль которую я хотел донести это то что идея единого центра пользовательских данных во-первых не нова, во-вторых опробована и есть свои методики, в-третьих что еще много что можно сделать, и самое главное, еще больше от этого получить, и в-четвертых: сейчас будет волна подобных разработок А сейчас не паханое поле для всевозможных стартапов, мэшапов и прочих мейкапов.

Т.к. вся архитектура обработки состоит из небольших функций, то обработку можно легко распараллелить на кластере. К тому же облегчает разбивка на отдельные куски и восстановление после сбоя. Используя распределенную ФС мы разбиваем данные на небольшие кусочки, с каждым из которых и работает отдельный элемент кластера.

Так же эту идею можно встретить под названием Split/Aggregate. Т.е. суть в том что входные данные (неважно какого размера) разбиваются на отдельные элементы (этап split), к примеру построчно, каждая строка как отдельное значение для обработки. Эти блоки строк раcпределяются по кластеру для обработки, где для каждой строки вызывается функция обработки (map). Результат выполнения опять объединяется (reduce/aggregate) в выходной файл. Если нужно, то данные сохраняются отсортироваными в определенном порядке, к примеру по внешнему ключу.

Область применения

Сам подход очень хорошо подходит для длительной обработки больших объемов данных, причем когда нам не требуется определенная последовательность процесса или получение результата по мере поступления новых данных. Т.е. если у нас в наличии пару гигабайт данных для обработки и нам нужен конечный результат обработки, то это отличный вариант, но если у нас тот же гигабайт постоянно поступает небольшими кусочками, и мы должны их тут же отправлять на обработку, ожидая результат как можно скорее, то удобней иной подход, нежели чем MapReduce и Hadoop в частности.

Например это очень подходит когда нам нужно обработать стопку csv файлов. Ну или один, но большой. В каждой строке несколько колонок с данными, на основе этого получаем результат, тоже в csv. Так вот обработку такого файла легко распаралелить на нескольких машинах, построчно, или блоками, скажем по 100 строк, равномерно раскидать по серверам, обработать, а потом результирующие строки склеить в выходной файл. Если надо можно еще отсортировать чтобы было в том же порядке что и во входящих данных. Все это требует гораздо меньше ресурсов чем сама обработка данных.

Есть мнение что при обработке данные не стоит перегонять в текстовые файлы, пусть все хранится в БД, и читать оттуда поблочно, тут же складывая полученные результаты. В этом тоже есть свои плюсы и минусы, тут каждый решает сам, в зависимости от задач. Распределенная ФС, кстати, очень хорошо заменяет БД как центральное хранилище данных, а привести в структурный вид, удобный для БД можно уже и отдельным этапом (например отдельной задачей mapreduce). Хотя загрузку и средствами БД можно легко и быстро сделать.

Пример алгоритма

Приведу один простой пример, может понятней будет.

mapNumbers(«1, 4 and 3″)

Пусть он выделит все цифры в тексте, например регэкспом \d+, не суть важно. В нашем случае выдаст пары {num:1, num:4, num:3}, где num – имя ключа, а 1,4 и 3 – его значения

reduceSum(num[])

На вход придет список пар с одинаковым ключем, в нашем случае ключ num. Пусть метод выполняет суммирование всех цифр для переданного списка пар. Т.е. в нашем случае ему на вход придут те три пары num:#, и он произведет суммирование 1 + 4 + 3, выдав 8

На самом деле функции иногда в сотни раз сложнее, но суть та же.

Реализации MapReduce кластера под java

Apache Hadoop

Apache Hadoop – одна из основных реализаций системы для такой обработки. Поддерживает как MapReduce так и распределенную файловую систему (HDFS). Подпроектом еще идет как минимум реализация BigTable. map/reduce могут быть написаны не обязательно на Java, вполне подойдет все что может запускаться под этой ОС. Кстати, базовой ОС является Unix, хотя как я понимаю под Windows тоже работает, через cygwin.

Недавно Yahoo! сообщил что они успешно используют Hadoop для обработки объемов порядка 300 терабайт на кластере из 10 000 серверов. Из чего можно сделать вывод что для повседневных задач по обработки текущих данных Hadoop хватит с лихвой.

GridGain

GridGain скорее рассчитан(но не ограничивается этим) не на обработку терабайтов данных, а разбиение на кучу задач, не важно каких. Больше подходит название SplitAggregate. Т.е. мы задаем объем задач, GridGain раскидывает это по кластеру, и далее передает нам результат. И здесь уже хоть сразу все через БД делай, хоть используй поверх распределенной ФС (от того же Hadoop даже), не суть важно. Авторы к примеру предлагают так юнит тесты запускать, т.е. разбиваем по методам на кластер, и все они параллельно тестируются. Надо это попробовать, если окажется десяток лишних компов под рукой

А еще эти товарищи очень не любят писать лишний код сами, а предпочитают интегрировать готовые, зарекомендовавшие себя решения. Что я считаю очень правильно, зачем лишний раз изобретать велосипед? Так вот, я к тому что система получается очень гибкая, красиво написанная, настраиваемая в спринге и интегрируется с кучей прочих около grid решений.

Cloud Computing

В свете последнего расцвета cloud computing, сервисов типа Amazon S3 и EC2 все это становится довольно интересным. Сейчас можно не ждать несколько часов для обработки, когда можно запустить все это на кластере из сотен серверов, получить результат через несколько минут заплатив за аренду этого кластера совсем небольшую сумму.

• замена в определённом поле
• удаление по определённому регекспу
• сортировка
• удаление пробелов

Получаем вот такой вот файлик:

--- !replace
from: __UNKNOWN__
to: Computer
atField: author
--- !remove
regex: [^\\d]+
atFields:
  - year
  - phone
--- !sort
withComparator: !defaultComparator
  direction: desc
--- !transform
withTransformer: !trim{}

Этакий Domain Specific Language получается. Может на первый взгляд не так все просто, но если написать небольшое описание синтаксиса нашего языка, или знакомство с документацией по yaml, все встанет на свои места, и редактирование подобного списка команд становится несложной задачей, с которой может справится продвинутый пользователь. В общем я сейчас сильно в синтаксис не буду вдаваться, кому надо глянут на yaml.org и jyaml.sourceforge.net
Второй момент как это прочитать, т.е. как построить их этого файла наши объекты. Делается все просто, через упомянутый JYaml:

List<Command> list = new ArrayList<Command>();
YamlDecoder dec = new YamlDecoder(in);
try {
    while (true) {
        Command command = (Command) dec.readObject();
        list.add(command);
    }
} catch (EOFException e) {
    log.debug("Finished reading stream.");
} finally {
    dec.close();
}

ну и т.к. в файле мы использовали не полный имена классов, то надо настроить связь между именем и самим классом, это нужно сделать до чтения самих объектов, следующим образом:

BiDirectionalMap<String, String> classes = new BiDirectionalMap<String, String>();
classes.put("replace", ReplaceCmd.class.getName());
classes.put("remove", RemoveCmd.class.getName());
classes.put("trim", Trim.class.getName());
classes.put("sort", SortCmd.class.getName());
classes.put("defaultComparator", DefaultComparatorCmd.class.getName());
classes.put("transform", TransformCmd.class.getName());
YamlConfig.getDefaultConfig().setTransfers(classes);

На самом деле можно такой мини язык делать не только для списка команд, в общем то почти любой класс так можно описать и десериализовать после в объект, а текущая задача она применима к моим условиям. Правда тут возникла проблема: хотелось бы чтобы эти объекты помимо описания в этом файле имели настройки в Spring. Т.е. все связи с другими объектами настроить в Spring контексте, а саму очерёдность и дополнительные настройки брать уже из этого файла. Так вот это я не знаю как реализовать, не расширяя YamlDecoder. Хотя, т.к. jyaml проект open source’ный, это тоже вполне реализуемо.

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

Так вот такое же насыщение сейчас пришло в Web. Сейчас пошли все эти новые технологиий RSS, RDF, SOAP, Semantic Web и пр. Т.е. переход от «сайт как единое целое» к «сайт как участник связанной системы». Сайт начинает связывать/использовать для своей работы некоторые другие сайты/сервисы, а также сам может отдавать другим какие либо свои услуги/информацию. Остается только договорится о стандартизации обмена, об API доступа к сайту. Это уже не сайты, а сервисы.

И вполне вероятным может быть создание сайта лишь на основе иных сервисов. Это несомненно дает множество плюсов, в плане качества сайта. К примеру я могу прикрутить к определенному сайту карту местности, если делать буду ее своими силами. Но сколько денег это мне будет стоить? Есть у меня один знакомый, который занимался много времени ГИС-софтом, он мне примерно рассказал сколько ресурсов это потребует, в общем дорого это… Но есть путь проще: к сайту прекрасно прикручивается Google Maps. Еще из подобных сервисов у нас уже есть различные чаты, календари (GCal), хранилище данных (Amazon S3), фиды по кучи разных тем… еще много чего, но на самом деле еще мало

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

Вот это уже и есть Web 2.0. А все эти закругленные углы, большие шрифты, css, ajax, и пр. это просто обычный процесс улучшения, просто попавший на этоже время.