2014-03-23

О DUMP-2014

14 марта в Екатеринбурге состоялся очередной DUMP (Development Usability Management Practice) — «конференция уральских разработчиков». Т.к. в прошлые годы DUMP оказался весьма популярен и в солнечной Сибири, я решил рвануть в Ебург на денек.


В поезде удалось досмотреть четвертый сезон «Вавилона-5», чего не мог сделать уже года два :) Также два года не был в Екатеринбурге. Город по-прежнему радует широкими улицами и архитектурными изысками. Рано утречком прошелся через полгорода пешком, по пути хакая и захватывая порталы Ingress. Прокачался и посадил батарейку телефона, пришлось заряжаться от спящего в рюкзаке ноутбука.

DUMP проходил в Екатеринбург-Экспо — чудовищно громадном выставочном центре, как всегда на полпути до аэропорта. Этот экспоцентр сильно громаднее новосибирского экспоцентра, в котором проходит CodeFest. Он настолько громадный, что на конференцию выделили лишь кусочек четвертого корпуса, и все там поместились. Он настолько громадный, что я не пошел полтора километра в обход других корпусов до портала у главного входа, испугавшись охраны.

Кроме докладов, конференция порадовала вкусными плюшками и слойками с сыром и кофе, электросамокатом, дженгой реаллайфового размера с метровыми блоками и стремянками, парочкой 3D принтеров, где можно было заказать 3D портрет себя любимого. В общем, было совсем не скучно.


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

В секции «FrontTalks» Максим Пономарев из Яндекса рассказал о том, как они делали и запускали сервис Яндекса для Олимпиады 2014 в Сочи. Да, тот самый великолепный o14.ya.ru. Оказалось, что вполне стадартными средствами, такими как Django и Python для админки и сбора данных из разных источников, MySQL как основной БД, MongoDB как БД для фронтенда и 18 узлов в Node.js как фронтенда, можно держать все эти десятки тысяч запросов в секунду. Кстати, FrontTalks — это совсем даже отдельное сообщество.


Большую часть остального дня я провел на секции «Serverside».

Андрей Тыцкий из Абак-пресс рассказал, как они готовили отказоустойчивый кластер Sphinx. Пожалуй, все эти откровения будут наиболее полезны другим несчастным пользователям Сфинкса. Впрочем, представленные решения вполне ожидаемы: маленький быстрый индекс для свежих данных, большой перестраиваемый индекс для всех данных, горячая реплика на подхвате. Да, местами они используют keepalived — очень интересную универсальную штуку на Линуксе для балансировки и прозрачного переключения бэкендов.

Ребята из AlternativePlatform рассказали про Tanki Online. На старой доброй Яве с NIO и хитрой работой с потоками у них собран годный мощный специализированный велосипед для параллельного выполнения задач. С прямыми руками можно сделать все, что угодно.


Александр Коковин из СКБ Контура провел глубоко теоретический доклад по алгоритмам распределенного консенсуса. Это те самые протоколы и алгоритмы по которым наши любимые кластеры о чем-либо договариваются. Самый известный из них — Paxos. Это те самые выборы, определение большинства и т.п. В том или ином виде эти протоколы встречаются почти в любой распределенной системе и, соответственно, наших любимых NoSQL. А вот в качестве «чистой» реализации распределенного консенсуса Александр упомянул только ZooKeeper. Я обязан добавить сюда Serf.

Armin Ronacher провел единственный англоязычный доклад (и честно говоря, я рад, что DUMP, в отличие от все большего числа конференций в других городах, сохраняет этот теплый уютный местечковый русскоязычный колорит). Посыл доклада интересный: как мы перешли с крутой MongoDB на крутой PostgreSQL потому что он круче. В начале доклада все было правильно. Постгрес лучше справляется с большим числом операций записи благодаря своей версионной природе, что конечно лучше дурацких тупых блокировок в Монге. Армин также честно упомянул, что Постгрес все же не Монга и поддержка JSON там не очень. Это совпадает с моими тыканиями. С нетерпением жду доклад про Постгрес на CodeFest. А вот остальная часть доклада была посвящена перечислению вкусных плюшек Постгрес, в основном административного характера. К сожалению, я не понял, каков был мотив перехода с Монги на Постгрес и случился ли профит (кроме того, что получили более привычную и знакомую БД).


В секции «Управление разработкой» послушал доклад про GitHub Flow Александра Бирюкова из 2ГИС. Оказывается, Git Flow и GitHub Flow — это две большие разницы. Если в первом предлагается создавать ветку на каждый чих: фичу, исправление бага, релиз и т.п., то во втором все просто: фича == ветка, а потом делаете пул-реквест обратно в master. Ключевым моментом является пул-реквест. Он должен быть просмотрен и одобрен. Здесь вам и кодоревью, и решение о включении фичи в релиз (релизится master) и все остальное. Только вот механизм пул-реквестов сделан только в Гитхабе. В результате ребята из 2ГИС слегка скрестили Гитхаб и Джиру: на каждый пул-реквест создается соответствующий таск в Джире. Все хорошо. Вот только в меня закрались два вопроса. Почему механизм пул-реквестов ортогонален системам контроля версий вообще и есть ли свободная (он Гитхаба) реализация пул-реквестов? И риторический холиварный вопрос: почему не Меркуриал?

Послушал про «Проектирование интерфейсов», а точнее про анимацию в интерфейсах, доклад Александра Кудымова из Яндекса. Тема немного не моя. Но доклад стоило посмотреть хотя бы из-за потрясающих слайдов. С анимацией :)

Ну и последней в моей программе оказалась секция «Rocket Science», где я послушал Евгения Макарова из Айдеко про VoIP. Кажется, доклад попал в эту секцию просто потому, что больше нигде не нашлось места. Идея доклада: когда ребятам стало не хватать Астериска, они не стали использовать всякие другие более мощные решения (типа OpenSIPS или FreeSWITCH), а взяли мощный фреймворк Yate (на C++), который умеет все, что нужно, и слепили из него свой мощный велосипед. Мысль интересная: что проще, сконфигурировать незнакомый продукт под свои нужды, без гарантии, что этот продукт действительно поддерживает все, что вам нужно, или взять свободный фреймворк и сделать из него сразу то, что нужно? Потратить время сисадмина или программиста? :)


В конце был афтерпарти. На него я не остался, ибо до поезда оставалось чуть больше двух часов и 0.33 Миллера за 200 рублей мне показалось сильно дорого.

Встретился с екатеринбуржскими энлайтами (привет!), обменялись ключами, прокатился в метро, сходил в Макдональдс, погрузился в поезд, уехал в Омск. Надо, надо как-нибудь задержаться в Екатеринбурге и побродить пару дней по этому замечательному городу.


2014-03-09

О коммунальных платежах

Терпеть не могу платить за квартиру. Потому что за одну квартиру аж пять квитанций: «единая», за воду, за отопление, за электричество, за домофон. А уж если надо платить и за квартиру родителей, то вообще получается ад. И это несмотря на то, что я уже много лет не стою в очередях, а пользуюсь интернет банком.


Что нам предлагают эти самые интернет банки или специализированные сервисы? Первое и обязательное — это интеграция с получателями платежей: всеми этими водоканалами и энергосбытовыми компаниями. В обмен на номер лицевого счета (у каждой квитанции — свой собственный и неповторимый), вы получаете почти те же графы и цифры, что и в бумажной квитанции. Почти. Встречаются тут и ошибки, самой частой из которых, по моим наблюдениям, является указание данных за текущий месяц, а не за месяц оплаты. Я всегда плачу после первого числа месяца, соответственно, за предыдущий месяц, и мне показывают не те цифры.
Понятно, что сам платеж должен уйти не одной цифрой, а быть связан как с лицевым счетом, так и расписан по графам, как в квитанции. Некоторые не сильно изысканные получатели, вроде домофонных компаний, вообще не предоставляют никаких данных, и вся тяжесть запоминания номеров счетов и сумм платежей ложится на пользователя.


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


Встречаются еще и шаблоны. Для коммунальных платежей использование шаблонов почти не отличается от повторения платежей из истории. Разве что имена шаблонам можно дать человекопонятные. И в списке шаблонов разобраться проще, чем в истории, просто потому, что шаблонов меньше. Не очень великий профит.

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

Бывают еще выставляемые счета. Это особенно удобно, когда вы не хотите светить номер своей карты и оплачиваете через интернет банк. Получатель платежа выставляет при этом счет, который виден в интернет банке. Вы спокойно заходите в интернет банк, просматриваете счет и жмете кнопку «Оплатить». Или не жмете, если не хотите. Ни разу не видел, чтобы коммунальные компании выставляли счета таким образом. Да и механизм не предусматривает правки суммы платежа, что в данном случае необходимо.


Я хочу платить за квартиру так. В начале месяца мне приходит уведомление о том, что пора платить с предварительной суммой платежа всем коммунальным компаниям (за эту квартиру). Я захожу в интернет банк когда мне удобно (мобильный интерфейс тут не к чему, хватит десктопного браузерного). И вижу некую сводную таблицу: кому, сколько, за что нужно заплатить. С итоговой суммой. Система уже опросила всех получателей платежей для формирования этой таблицы. Вооружившись бумажными квитанциями, я просматриваю эту таблицу и вношу правки: где-то я не хочу платить пени, где-то я не буду оплачивать долг, где-то еще что-то. Можно даже сделать выбор: снять галочки с пунктов, которые оплачивать не буду (ну бывает такое). Также я указываю текущие показания счетчиков, и сумма платежа по счетчику формируется автоматически. После всех этих манипуляций (на одном экране!) я соглашаюсь с итоговой суммой и жму (одну!) кнопку «Оплатить». После этого можно запросить код подтверждения, ввести номер карты, и провести прочие процедуры безопасности/авторизации. Акт оплаты всех коммунальных платежей за квартиру является одним платежным действием! Понятно, что в первый раз придется все это дело настроить: ввести те же лицевые счета и связать их с квартирой. Но эта предварительная настройка того стоит.


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