API over ActiveMQ

Открываю цикл постов про MQ и API. Прежде всего стоит определиться с терминологией: RMI или RPC. Method Invocation подразумевает за собой объекты и состояние, мы же будем рассматривать stateless вызовы, поэтому логичней это называть RPC. Лет пять назад Umputun рассказывал в одном из своих подкастов про то, как он спрашивал своих бойцов как бы они сделали RMI и для них это была вещь в себе, но ведь не "боги горшки обжигают".

Что общего у шансона и олимпийской эстафеты

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

- Ну а чо йоба, я хочу музыку слушать
- А я мы не хотим, нам не нравится твоя музыка
- У нас свободная страна, че хочу то и делаю
- Вот одень наушники и слушай

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

Возвращаясь к сабжу, казалось бы, что общего? А общего то, что the right to swing my fist ends where the other man's nose begins.

P.S. сюда же: такое событие можно и потерпеть чуток, терпи пожалуйста, но не вынуждай терпеть тех, кто не хочет. Даже если их меньшинство, не говоря уж про случай большинства.

Паттерны и поиск гармонии

Сначала ты не знаешь, что нельзя делать то-то
Потом знаешь, что нельзя делать то-то
Потом ты понимаешь, что иногда таки можно делать то-то
Ну а потом ты понимаешь, что помимо того-то существует еще шестьдесять шесть способов добиться желаемого, и все из них практически равноправны.
Когда тебя спрашивают "как мне добиться желаемого", ты быстро перебираешь в уме эти шестьдесять шесть способов, прикидываешь то общее, что в них есть, вздыхаешь и говоришь: "вообще-то, главное — гармония."
На вопрос обиженных учеников: "а как ее добиться?", ты говоришь: "никогда не делайте то-то".

Классика Кунг-Фу

Инсайты и нормализация данных

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

Между седьмым и восьмым классом два наших информатика написали систему тестирования на VB, вопросы же хранились в базе Access. В то время мы с другом активно увлекались программированием, собирая диски с бейсиками и коллекции OCX компонентов. Access я ковырял, даже подключался из бейсика, рассматривал Борей, понимал что есть таблицы, представления, формы, отчеты, скрипты же были магией. SQL не трогал - хватало построителя запросов.

Так вот, та самая база хранилась на Самом Главном Компе, желтом от сигаретного дыма. Комп назывался GOUROU. Мы мечтали на него попась, но шара с базой подключалась только на время тестирования либо забивания вопросов, поскольку Access был файловой базой. В один прекрасный момент, возможно на перемене между тестированием групп, мы увидели, что база доступна. Дискету с базой я нес домой прижав дрожащими руками к груди, как самую большую ценность.

Так повезло, что пароля на базе не было. Я быстро распечатал таблицы с говорящими именами test, question, answer. Распечатал аксесную ER-диаграмму. И долго пытался понять, как же они между собой связаны. Нашел вопрос, нашел варианты ответов, нашел правильный и то, чем он отличался от неправильных - булеву пометку. Увидел внешние ключи и в этот момент все стало на свои места - паззл сложился. Быстро накидал отчет с правильными ответами и отдал распечатки подружке.

Ближе к выпуску, я заметил, что со всех компов был удален Access - видимо просекли эту фишку. Проблема была в том, что на всех компах был установлен VB 6.0, с которым поставлялся DataViz, в котором можно было быстро накидать SQL запросец с ответами на нужный тест. Замуровали дверь, но оставили открытым окно.

В итоге, все же инорматики смогли перехитрить нас. Директор перед экзаменом сказал: мы тут придумали супер защиту и особо хитрожопые, не будем показывать пальцем, могут не напрягаться с утаскиванием базы вопросов. Естественно, мы опять сперли базу, но, вместо вопросов и ответов, в полях находились ссылки на RTF файлы - тысячи их. Тесты по английскому и русскому легко вмещались в текстовые поля, но физика и математика требовали формул и рисунков. Писать прогу не было времени (тем более, что все файлы весили какие-то дикие мегабайты и утащить все это дискетами не было никакой возможности). Пришлось сдавать самостоятельно.

З.Ы. Еще один момент из того же времени. Олимпиада по физике, задача, для лобового решения которой не хватит математического аппарата восьмиклассника. Это последняя задача, мы сидим и тупим. Видя, что дела плохи нам всем озвучивается подсказка (аналогия между объемом тонкостенного полого шара и объемом крышки стола). Пара человек говорит АГА!!!111, дичаеше начинает дичайше строчить и считать на калькуляторе. Остальные негодуют. Учительница по физике говорит: вы в равных условиях, поскольку слышали подсказку все, но семена понимания не взойдут без почвы знания.

Хроники сноубордиста-новичка в Шерегеше

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

Статистика владения кодом

Давно была идея визуализировать impact человека на продукт. Мощные визуализаторы типа codeswarm (активность и совместная работа) и gource (процесс работы) показывали не совсем то, что хотелось - текущее состояние. При помощи hg log -u username -p | grep "^+" | wc -l  можно посчитать добавления и удаления, но опять же в динамике не увидеть. Хотелось увидеть как росла доля пришедшего человека, насколько быстро она затухала с уходом и какое наследие осталось.

Сначала я полез курить физические движки типа box2d, но какой-то он был скучный и неинтересный - хотелось получить результат за один день. Пришлось отказаться от физического моделирования и вывести данные для простой временноОй диаграммы с накоплением.

Полез курить Mercurial API, заодно накидал ссылок в вики-статью и скачал бесплатный PyCharm. На проект не тянет, поэтому сохранил в gist (derived work требует назначить лицензию GPL). Программа последовательно в каждой ревизии аннотирует текстовые файлы и считает, количество строк для каждого коммитера. Тестировал на маленьком репозитории, и не заметил нескольких улучшений. Пока работал на нашем основном - успел внести несколько правок.

Процесс запуска

1. Запускаем первый раз python participation.py - у нас появится шаблон конфига

2. Отключаем подсчет calculate=false и прописываем репозиторий repo=~/path/to/repo

3. Запускам еще раз и получаем на выходе пользователей

4. Прописываем им алиасы в разделе [Alias] - часто один пользователь попадает под разными именами, а мы не хотим портить статистику
5. Наконец включаем подсчет и запускаем
6. Ждем результат, открываем в Excel и рисуем график

Статистика

На серьезных репозиториях работает ОЧЕНЬ долго.
Проанализировано 164.564.370 строк в 1135 коммитах (только ветка default) за 8 часов на Atom N550, потребление памяти в пике 75мб, диск был SSD, но IO был неизмеримо мал.

График очень резкий, поскольку разработка зачастую ведется в отдельных ветках, а мощный рефакторинг не сохранял исходного владльца файлов март 2012 (хехе, прямо война правок).

Решение проблемы N+1 в Hibernate

Введение

В нашем проекте для большинства сущностей их количество не превышает сотни, а там где начинаются проблемы, хватает индексов - поэтому можно не заморачиваться. Но тут внезапно появилась дичайшая просадка производительности - клиент отваливался по таймауту на старте при попытке запросить один справочник. Быстро выяснилось, что справочник содержал 1000+ сущностей, на каждую из которых приходилось по пятку дочерних на трех уровнях (да, это всё нужно было), в итоге это давало несколько тысяч запросов при попытке сериализовать все это добро. Спойлер: в общем проблему за несколько часов удалось решить сократив количество запросов меньше чем до десяти.

Если специально не заниматься оптимизацией, то ORM зачастую приводит к проблеме, называющейся "N+1": у нас имеются две связанные сущности (не важно 1-*, *-1 или 1-1) и дочерняя загружается лениво, то, при итерации по родительским сущностям и обращении к дочерним, будет в сумме N+1 обращений к базе, чтобы инициализировать ленивые прокси. Главное препятствие для лобового решения (вытянуть всё в один запрос) - то, что из-за пустых коллекций и null-ов некоторые или все джойны должны быть внешними, а разложить после этого результат по сущностям не получится. При маппинге мы разово указываем поведение коллекции LAZY или EAGER и тонко тюнинговать не получается. Разухабистая глава в документации Hibernate про оптимизацию не очень помогает. Вообще, проблема крайне распространенная, может еще еще одно проявление impendace mismatch. Давно уже писал про ORM, ничего не поменялось, хотя уже почти не напрягает, за исключением отдельных случаев типа N+1.

Наивный тайм-менеджмент

Пост наблюдения и рефлексии

У меня никогда не приживались todo-листы, GTD Аллена мгновенно вырубал меня в глубочайший сон, гугло-календарь использовался только для самых важных событий. Да и зачем все это? Все рабочие задачи остаются на работе в корпоративной JIRA - не стоит их нести домой.

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

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

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

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

Столько хочется написать, попробовать и сделать (более того, беклог пополняется гораздо быстрее, чем опустошается), но на все не хватает энергии. Хуже всего то, что большие выходные или отпуск не приносят желаемого удовлетворения: сложно заставить себя заниматься чем-то полезным, а не зависать в местных барах.

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