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

Отлаживать однопоточное Java приложение просто. Отлаживать многопоточное Java приложение — чуть сложнее, но все равно просто. Отлаживать мультипроцессное Java приложение? С процессами, запущенными на разных машинах? Это определенно сложнее. Именно поэтому все руководства по Hadoop рекомендуют обращаться к отладке только и исключительно тогда, когда другие опции (читай: логгинг) исчерпаны и не помогли. Ситуация зачастую усложняется тем, что на больших кластерах у вас может и не быть доступа к конкретным map/reduce узлам (именно с этим вариантом я и столкнулся). Но давайте решать проблему по частям. Итак…

Сценарий первый: локальный Hadoop

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

Как же этого добиться? Мы идем в директорию, где у нас развернут наш локальных Hadoop (я полагаю, что вы умеете это делать или умеете прочитать соответствующую инструкцию и уже теперь с этим справитесь).

    $ cd ~/dev/hadoop
    $ cp bin/hadoop bin/hdebug
    $ vim bin/hdebug

Наша задача — добавить еще одну опцию JVM, где-то в районе 282-283 строки (в зависимости от версии, номер может и измениться), сразу после того, как скрипт закончил формировать $HADOOP_OPTS:

Дождались! Свершилось! Недели и месяцы спекуляций, слухов чуть ли не больше чем вокруг долгожданного «телефона от Apple», сотни фейков — и что же?

Честно, я ждал чего-то большего. Не вижу реального use-case для этого устройства и не уверен, что оно найдет своего покупателя (а если и найдет, то совсем не в таким масштабах как iPhone).



Для электронных книг 10 часов это совсем немного — e-ink дает в разы больше. Для веб-серфинга домашнего лаптоп лучше — я хочу не только читать статусы друзей на Фейсбуке, но и отвечать на них, а для этого лучше иметь аппаратную клавиатуру. Для просмотра фильмов… пожалуй. Но не для музыки — он слишком велик.

Четвертая часть статьи, и вероятно — не последняя. Напомню, что предыдущие три статьи (а так же все последующие) теперь можно будет увидеть по этому адресу — статей много и проставлять в них навигационные ссылки друг на друга мне надоело;-)

Напомню, что мы закончили на обзоре контроллера для нашего примера и обещании, что в следующей части все начнется, и, наконец-то, все станет интересно и захватывающе. Станет обязательно. Итак —

Представление

Как вы знаете, такие слова как MVC уже давно стали даже не модными, а прям-таки подразумевающимеся (другой вопрос что понимает их всяк по своему). Наш пример не стал исключением — и теперь нам нужно объединить достижения контроллера и модели воедино и показать их пользователю. В этом нам немало поможет тот факт, что GAE внутри использует Django, механизм шаблонов которого является одним из самых лучших среди тех, которые я знаю. Одним из самых интересных, на мой взгляд, свойств шаблонов Django является то, что они поддерживают наследование.

Действительно, зачастую дизайн двух функционально разных страниц веб-сайта отличается лишь незначительно и использует общие элементы — header, footer, меню и т.д. Обидно будет дублировать этот код — и в то же время, всяческие include-директивы это все-таки вчерашний день. В Django вы можете наследовать один шаблон от другого.

Рассмотрим наш базовый шаблон, который можно найти в дереве исходников как templates/basic.html. Поскольку HTML на Хабр красиво вставляться не желает (и никакой Хабраредактор с этим справится не может), а некрасиво его читать — голову сломать можно, посмотрите его уж в SVN по ссылке выше. Суть не в этом. Суть в том, что в каких-то местах мы объявляем «заглушки»:

1. <div id='content'>
2. {% block content %} {% endblock %}
3. </div>

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

Контроллер

Какое-то время назад мы уже определили несколько URL в app.yaml — пора разобраться, как заставить приложение правильно «реагировать» на них. Вот так выглядят наши маппинги:

# $Id: app.yaml 4 2010-01-25 12:14:48Z sigizmund $

application: helloworld
version: 1
runtime: python
api_version: 1

handlers:
- url: /(stats|login)
  script: main.py
  login: required

- url: .*
  script: main.py

Как мы видим, определены три типа URL — /stats, /login и «всё остальное». Все три, что характерно, будут обработаны одним и тем же скриптом main.py, однако настройки отличаются — /stats и /login требуют наличия активной пользовательской сессии, в то время как для остальных это не обязательно. Давайте рассмотрим содержимое скрипта main.py:

В предыдущей статье мы выяснили, что такое Google AppEngine, что с ним можно делать, и создали самое простое и примитивное приложение для GAE — helloworld с минимальной поддержкой аутентификации пользователей. Попробуем расширить это приложение, рассмотрев, попутно, возможности Google AppEngine.

Структура и архитектура

Наше предыдущее приложение было предельно простым, и, как таковое, ни в какой архитектуре не нуждалось. Теперь мы ставим перед собой более сложную и более реальную задачу — соответственно, нам следует подумать о том, что будет, когда приложение начнет расти. Разумеется, наша задача выдумана и для нее никакой архитектуры тоже не требуется, но для примера попробуем все сделать «по науке».

Недавно я задал вопрос — было бы интересно хабралюдям почитать о том, как писать под Google AppEngine? Хабралюди сказали что да, интересно — ну я и решил начать. В этой статье мы рассмотрим следующие вопросы:

1. Ультра-краткое введение в Google AppEngine (GAE), что это такое и с чем его едят
2. Возможности и ограничения GAE
3. Супер-краткий обзор архитектуры GAE-приложения
4. Разработка минимального приложения с аутентификацией
5. Разработка более сложного, реального приложения на основе MyTwiLinks

Начнем с самого начала, с самого простого — совсем для нубов (каковым я и являлся, когда начал разбираться с GAE), постепенно продвигаясь к более сложным концепциям, заканчивая грязными хаками на тему «как быть, если нельзя, но очень надо» (почти наверняка не успеем в рамках этого поста, но доберемся обязательно).

Есть мысль написать немного про разработку для AppEngine. На мой взгляд, в документации все написано хорошо и толково, но было бы идеально показать разработку более или менее реального приложения. Есть у меня два подопытных кролика — раз и два — я их пилю и допиливаю, когда есть свободное время. Было бы кому-нибудь интересно, как они написаны? (вообще-то они оба open source так что исходники можно и так посмотреть).

А если бы было интересно — с какого начать? По-моему интереснее было бы про MyTwiLinks написать — там и интеграция с Твиттером, и шаблоны Джанговские, и даже OAuth где-то сбоку, но зато в FanFiction Downloader — генерация zip-файлов в памяти (а так же почему мне пришлось это так делать) и работа с форматом EPub :-)

Господа, внезапно — сабж!? Вопрос вызван тем, что какое-то довольно продолжительное время я был вдалеке от Java-технологий, писал на C++ и Python (и продолжаю писать), но один из курсов университета (конкретнее — component based software development) будет требовать либо одного из JVM-based языков (Java отпадает за неинтересностью) либо .NET языков (отпадает по определению так как Windows у меня нет и не будет). Немного изучив вопрос, пришел к выводу что:

1. Преимущества в пользу Jython — по большому счету, это Python, который я хорошо знаю и люблю, с возможностью использовать Java классы. Но, если верить слухам, сейчас он почти не развивается. Хотя опять же, кому верить-то?
2. Преимущества Groovy — новый язык, активно развивающийся, комбинирующий в себе достоинства многих языков и парадигм (тот же Python и Ruby в них входят). Недостатки — новый язык, активно развивающийся ;-) Сравнительно мало документации и кода по сравнению с Python
3. Преимущества JRuby… я что-то весь в затруднениях, но все о нем говорят. Полная совместимость с Ruby, да. Но Руби я все равно не знаю, так что учить с нуля, так же как и Groovy.

А какие еще мнения есть? Я пока еще не совсем понял, что именно мне нужно для этого курса (хотя ясно, что это что-то должно поддерживать хорошую умную компонентную модель для работы в распределенных средах), но язык, в конце концов, вторичен — хочется чего-то интересного, нового и необычного (не сказать “странного”). Кто что думает? Вопрос довольно практический, потому что 18 января надо начинать писать курсовой проект на этом языке, который я выберу — а его надо еще и изучить хотя бы минимально до этого момента ;-)

Пока начал играться с Groovy и он мне, в принципе, нравится — но возможно, я упускаю что-то существенное, ограничивая себя этим языком?

Всем хабралюдям заранее спасибо за мнения!

Многие знают, что, скажем, на Windows можно набирать многие символы как Alt+xxxx, где xxxx — цифровой код символа. Однако если вы используете Мак, все это делается гораздо проще: например, комбинация клавиш ⌥⇧K позволяет набрать символ “яблочка” — , и таких символов очень много. Возникает только один вопрос: где же найти все эти “волшебные комбинации и как их запомнить?” На самом деле, все очень просто.

Ничего запоминать и не надо — достаточно воспользоваться маленьким апплетом Keyboard Viewer, встроенным в системы семейства Leopard:



Сам апплет выглядит вот так:



В изначальном виде пользы от него, пожалуй, немного — как выглядит ваша клавиатура, к этому моменту, вы уже, вероятно, успели выяснить. Однако стоит “понажимать” клавиши-модификаторы, и картина резко изменится:

Разреши мне, пожалуйста, создать блог Hadoop — уже две статьи есть и еще пишется, но вот их уже в Алгоритмы будет помещать совсем некошерно! Или создай, НЛО, пожалуйста, такой блог — и я наполню его смыслом и созерцанием.

Спасибо тебе за то, что ты о нас думаешь!

Продолжая статью “Использование Hadoop для решения реальных задач”, хочу напомнить, что в прошлой статье мы остановились на том, что посчитали такую характеристику как tf(t,d), и сказали, что в следующем посте мы будем считать idf(t) и завершим процесс вычисления значения TF-IDF для данного документа и термина. Поэтому предлагаю долго не откладывать и переходить к этой задаче.

Важно заметить, что idf(t) не зависит от документа, потому как считается на всем корпусе. Это нетрудно увидеть, посмотрев на формулу:



Вероятно, она нуждается в некоторых пояснениях. Итак, |D| это мощность корпуса документов — иными словами, просто количество документов. Мы знаем его, поэтому считать ничего не надо. Знаменатель же логарифма — это количество таких документов d которые содержат интересующий нас токен t_i.

Вчера я задал вопрос в своем ХабраБлоге — интересно ли людям узнать, что такое Hadoop с точки зрения его реального применения? Оказалось, интересно. Дело недолгое — статью я написал довольно быстро (по крайней мере, ее первую часть) — как минимум, потому, что уже давно знал, о чем собираюсь написать (потому как еще неплохо помню как я сам тыкался в поиске информации, когда начинал пользоваться Hadoop). В первой статье речь пойдет об основах — но совсем не о тех, про которые обычно рассказывают :-)

Перед прочтением статьи я настоятельно рекомендую изучить как минимум первый и последний источники из списка для чтения — их понимание или хотя бы прочтение практически гарантирует, что статья будет понята без проблем. Ну что, поехали?

Что такое Hadoop?

Ну скажите, какой смысл об этом писать? Уже не раз это проговаривалось, неоднократно начинали писаться посты на тему Hadoop, HDFS и прочая. К сожалению, обычно все заканчивалось на довольно пространном введении и фразе “Продолжение следует”. Так вот: это — продолжение. Кому-то тема, затрагиваемая в этой статье может показаться совершенно тривиальной и неинтересной, однако же лиха беда начало — любые сложные задачи надо решать по частям. Это утверждение, в частности, мы и реализуем в ходе статьи. Сразу замечу, что я постараюсь избежать написания кода в рамках этой конкретной статьи — это может подождать, а понять принципы построения программ, работающих с Map/Reduce можно и “на кошках” (к тому же с текущей частотой кардинального изменения API Hadoop любой код становится obsolete примерно через месяц).

Когда я начинал разбираться с Хадупом, очень большой сложностью лично для меня стало первоначальное понимание идеологии Map/Reduce (я предпочитаю писать это словосочетание именно так, чтобы подчеркнуть, что речь идет не о продукте, а о принципе). Суть и ценность метода станет понятна в самом конце — после того, как мы решим несложную задачу.

Привет вам, дорогие хабралюди (и просто люди, ибо различий я делать не стремлюсь). Возникла у меня тут мысль написать большую статью про Hadoop. Причем не просто статью, а статью, которая будет описывать реальную (ну или практически реальную) задачу, которая вполне может оказаться нужной и интересной уважаемым хабрапользователям — если быть точнее, статистический анализ очень большого объема данных, например, английской Википедии (дамп весит 24 Гб или около того).

Тут сразу несколько проблем. Во-первых, дамп Википедии — это XML. Работать с XML на Hadoop — это то еще удовольствие, однако если разобраться, то все не так плохо. Во-вторых, это еще не большой, но уже существенный объем данных — надо начинать думать о размере сплита, количестве map-тасков, и т.д. Третья проблема — скорее всего, я буду описывать разработку системы для «облачного» кластера, который где-то находится, но ни настраивать, ни администрировать ничего не надо — к сожалению, не у всех есть доступ к таким системам, поэтому неплохо было бы написать для начала как можно сконфигурировать простенький, но настоящий кластер.

Есть такой интерес у пользователей? Тема интересная, и я искренне верю, что в задачах, где требуется обработка очень больших объемов информации, грид-вычисления это вообще чуть ли не единственный разумный выход сразу по нескольким причинам. В свой блог я периодически кидаю всяческие гиковские наблюдения и мысли на тему Hadoop, но писать в личный блог и писать в Хабр — это, согласитесь, две большие разницы.

Ну так вот. Если интересно — отпишитесь, и я постепенно начну.

Update: в качестве задачи предлагается вычисление tf-idf — по-моему вполне нормальный пример (к тому же имеющий массу практических применений).

Update2: а статья уже готова :-) завтра отчитаю ее еще разок и выложу.

Update3: sigizmund.habrahabr.ru/blog/74792

Теперь, когда некоторые хабровчане освоили морковные деривативы, можно переходить к более сложным и куда более реальным деривативам погодным. Использование погодных форвардов может показаться невероятным, однако рынок этих инструментов не просто существует, его объем в США превышает 40 млрд долларов.

Внимание: пост написан хабраюзером doz — ему и адресуйте все плюсы в карму, которой не хватило, чтобы разместить пост в тематическим блоге.

Update: пост был прочитан моей женой, которая занимается финансами да еще и делает мастера по этой специальности. Сказала, что «погодные деривативы» — это всего лишь крайне частный случай, и если понимать как деривативы работают вообще, то их можно делать на что угодно, хоть на здоровье Ее Величества Королевы, хоть на уровень осадков в Рио-де-Жанейро, главное — чтобы это было кому-то нужно. Однажды я попробую заставить ее написать сюда пост… (ваш sigizmund).

Что такое погодные деривативы?

Даже в нашем высокотехнологичном обществе мы все еще сильно подвержены влиянию погоды. От нее зависит, в чем мы сегодня выйдем на улицу и поедем ли на пикник. Неудивительно, что погодные условия также имеют значительное влияние на прибыль компаний многих отраслей: строительство останавливают при низких температурах, энергетические компании терпят убытки в случае теплой зимы, а парки развлечений — в случае холодного лета. Американскими исследователями подсчитано, что доходы около 20% экономики США напрямую зависят от погодных условий. Чтобы компании как-то могли защитить прибыль от капризов природы, существуют страховки. Однако они могут обезопасить только от резкого и существенного изменения погодных условий, которые происходят крайне редко. Компаниям же необходим более гибкий механизм, который позволит покрыть убытки и в случае обычных изменений температуры. Механизмами такого типа и стали погодные деривативы.

Здравствуйте, дорогие мои!

Вы знаете, я неплохо отношусь к социальным сервисам — активно пользуюсь Facebook'ом, еще активнее — Твиттером, и даже зарегистрирован в Одноглазклассниках (многие мои совершенно некомпьютерные знакомые со старинных времен есть только там, ну так мне и не жалко). И еще я зарегистрирован в этом вашем ВКонтакте.

Вы, вероятно, знаете, про всю недавно раздутую Дуровым сотоварищи истерию с vk.com и приглашением иностранных пользователей. Так вот, дорогие мои — я хочу выразить свою НЕНАВИСТЬ!!!! — именно так, все капсом, болдом и с восклицательными знаками. Я, в общем-то, не скрываю того факта, что живу не совсем в России, и в профиле у меня это написано. В том числе и в профиле ICQ, который бы давно пора отключить, но опять же — есть люди, с которыми я хочу иметь контакт, а они как пользуются QIP'ом так и не знают о существовании ничего иного и знать не хотят (и я их даже где-то понимаю). Так вот за сегодня я получил в эту самую аську порядка сотни сообщений с приглашением зарегистрироваться. Да, у меня там есть бот, который задает вопросы. Однако это не спасает от школьников, которые жадно алчут эти несчастные айподы нано, и оттого шлют свои «пригласилки» всем, до кого могут дотянуться их жадные потные ручонки.

Прочитав вот этот топик, я сперва откомментировал а потом озверел… нет, сперва я все же озверел, и только потом — откомментировал его, а вот после этого я решил, что хочу написать об этом. Поэтому приведу здесь свой комментарий почти без купюр и правок. (для справки — в оригинальном топике автор со множеством ошибок, как орфографических, так и фактических, пишет о необязательности образования вообще и технического образования — в особенности).

Во-первых, сразу означу свою способность говорить о поднятой автором теме — мне 26 лет, я закончил университет в 2006 году, и сейчас работаю в крупной известной IT компании. Кому интересно — в профиле есть детали, но так или иначе — в теме я немного разбираюсь. Я закончил 6 факультет Самарского Государственного Аэрокосмического Университета, наверняка не лучшего в стране, но точно лучшего в Самаре, и, вероятно, во всем Поволжье технического учебного заведения.

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

1. Математика. Мать всех наук, без знания математики немыслимо понятие инженера, она является основной практически для всего, о чем только можно подумать применимо к computer science.

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

3. Физика. Не буду говорить о важности физики как таковой, но на мой взгляд, помимо своих собственных знаний, она дает студенту первый пример того, как можно применять математический аппарат к решению задач реального мира. Вероятность того, что физика пригодится будущему инженеру — весьма высока, я бы оценил ее в 15-20%

4. Группа «низкоуровневых» предметов — электротехника, схемотехника, интерфейсы, и кульминация — курс «Микропроцессоры». Извините, но инженер-программист обязан понимать, как это все работает — а лучше понимать как работает то, что он использует в данный момент и еще пара альтернатив. Если вы будете связаны с железом — это ваш хлеб насущный, в противном случае — вреда от этого знания точно не будет (мне пригождалось неоднократно).

Совсем недавно – 20 мая, компания Yahoo! объявила о выходе своего нового продукта, на данный момент не имеющего аналогов – Yahoo! Placemaker, сервисе гео-парсинга, основной целью которого является извлечение гео-релевантной информации из документов различного формата. Презентация прошла, как принято говорить, «при большом стечении народу» и закончилась «аплодисментами, переходящими в овацию» – задумка и реализация определенно понравилась, и какое-то время в Твиттере можно было наблюдать довольно-таки позитивный поток комментариев на эту тему. Но вот представление окончено, все расходятся по домам, и начинают задавать вопросы: так что же это такое?

Что такое Placemaker

Как уже было сказано, Placemaker – это веб-сервис, который позволяет извлечь гео-релевантную информацию из некоторого документа. Тут есть сразу несколько моментов, которые нуждаются в пояснении. Во-первых, что это за документы, из которых можно извлекать информацию? А во-вторых, что это за такая гео-релевантная информация, а самое главное – кому и зачем она нужна?

С документами все довольно просто. На данный момент Placemaker поддерживает текст (ну он и в Африке текст), HTML-документы (хотя здесь не все так просто), а так же XML-производные форматы аггрегации новостей — RSS и Atom. Кроме того, Placemaker «понимает» расширение RSS и Atom, известное как GeoRSS, а также способен извлекать дополнительную информацию из микроформатов, которые встраиваются в HTML документ. Про информацию-то и следует поговорить поподробнее.

Что Placemaker может

Если очень кратко, то все возможности PlaceMaker можно определить в три группы, а именно:

• Какие места (географические) упоминаются в документе и какова их важность?
• Среди всех мест, с одинаковым названием, о котором именно говорится в документе?
• О каком месте идет речь в документе вцелом?

С некоторых пор (не помню точно, но уже наверное с пол-года назад) на Хабре перестали отображаться оценки топиков, которые вы не оценили. С другой стороны, можно зайти в Хабр топ и увидеть там оценки этих топиков если они есть. По-моему это маленькое, но все же UI issue. Под катом — пример.

Подумалось — будет ли кому-либо интересно увидеть фотографии и рассказы с Yahoo! Open Hack Day London? Если да, то — пожалуй — в моих силах будет организовать и то, и другое ;) Там будет действительно интересно и необычно (чего стоит хотя бы факт, что когда Hack Day проводился в Лондоне в прошлый раз в 2007, в здание, где проводился Hack Day, дважды ударила молния, но хакеры и организаторы не испугались и доделали все, что собирались — достаточно сказать, что тогда был едва ли не самый продуктивный Hack Day за все время их проведения)

P.S. как минимум, в @sigizmund я буду писать много, а еще рекомендую мониторить #openhackday — сейчас там почти ничего нет, потому как ничего и не происходит, но будет и будет очень немало.

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

1. Просто указанием места на карте, например, как это делается на Flickr или при помощи плагина GeoPress для Wordpress
2. Извлечением координат из EXIF'а фотографии — если они там есть

Второй способ, естественно, куда «красивее» и правильнее — но несколько сложнее технически. Однако не буду рассматривать, как добавить координаты в EXIF — а расскажу о том, как их можно использовать.
Давно, очень давно мучала меня идея — не хочу показывать карту. То есть карта это хорошо, но не все. Хочу человеческим языком сказать посетителю: фотография снята в таком-то городе по такому-то адресу. Ну очень давно хотел я это сделать, и в конце концов собрался.