Спорные, но актуальные принципы разработки

В нашей компании в процессе разработки принято придерживаться нескольких простых принципов. Возможно, кому-то они покажутся спорными, кому-то наивными, но, так же как и календарь, про который писал в прошлом году наш IT-директор (aka paulig), эти принципы — результат собственного опыта и ошибок. Кроме того, мы верим, что следование им даёт возможность решать задачи быстрее и эффективнее.

Зачем это было написано, если есть множество книжек по методологиям разработки (в том числе extreme programming, scrum, tdd), по программированию в целом и в частности, о том, «как пасти котов» и про «идеальный код»? Книг много, но разработчики, к несчастью их читать не любят. Ну, ладно, любят, но не все. У них, мол, своя специфика. Квинтэссенция нужна. И проще, ближе, понятнее. Вот поэтому. И в жизни чаще всего приходится вспоминать, вернее, не забывать, именно те, которые перечислены ниже.

Посмотрев на историю страницы в нашем корпоративном twiki, я обратил внимание, что этот небольшой список с пояснениями, на основе которого сделана эта публикация, начал своё существование в 2006 году и неспешно дополнялся до 2011 года. Потом почему-то заглохло. Может быть, у кого-нибудь из читателей появится желание что-то добавить?

Простота

Если решение задачи оказывается слишком сложным, то с вероятностью 99% способ решения неверен.

Unix-way

По возможности, программа должна выполнять одно действие, но зато делать это хорошо.

Бритва Оккама

Кроме того, что не нужно умножать сущности, всегда помним о тезисе «это нам никогда не понадобится». И, скорее всего, оно не понадобится на самом деле.

Велосипед уже существует

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

Повторы

Если действие повторяется больше шести раз, то пора это действие тем или иным способом автоматизировать. Варианты: написать скрипт, создать класс, записать макрос.

Почему именно шесть раз? Потому что до шести внимание на это обычно не обращают.

Тесты

Любую реализацию нужно начинать с реализации тестов.
То есть, прежде чем начать писать программу, надо продумать как эту программу тестировать. И начать тестировать. Даже если нет реализации того, что тестируется. Тесты помогут понять, что нужно делать и как, а что — нет.

Подкустовные выползни

«Подкустовные выползни появляются на свет сразу. как следует из названия, они выползают из-под куста.» © Квартет И, «День радио».

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

Время

Отработать больше часов не значит сделать больше. Продуктивность и отработка времени — совершенно противоположные понятия.

Очевидное

Вы думаете, что кто-то умеет читать ваши мысли? Это ошибочное суждение. Телепатов в нашем несовершенном мире можно встретить только в зеркале. Поэтому, прежде чем что-то сделать, основываясь на своём представлении об информированности окружающих, нужно убедиться, что окружающие «в курсе». Или «в теме».

То есть, всегда необходимо информировать коллег о своём видении проекта и своей роли в нём. А то сами они не догадаются.

Коротким списком

  1. Простота
  2. Unix-way
  3. Бритва Оккама
  4. Велосипед существует
  5. Повторы — автоматизировать
  6. Сначала тесты
  7. Подкустовных выползней нет
  8. Не нужно отрабатывать время
  9. Мысли читать никто не умеет

ссылка на оригинал статьи http://habrahabr.ru/post/261493/

Программный комплекс студентов MIT автоматически исправляет работу программ

image

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

Программисты-виртуозы назвали свою программу CodePhage (кодофаг). Разработчики поясняют, что их система «анализирует выполнение программы и характеризует типы проверок безопасности, которая та проводит». После чего кодофаг может взять такие же проверки у других программ-доноров, даже если те написаны на других языках программирования, и скормить их программе-реципиенту. Каким образом для этого выбираются программы-доноры, разработчики не уточнили.

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

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

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

«Технология заимствования кода у другой программы со схожей функциональностью и исправления с его помощью неправильно работающей программы — это, конечно, круто,- сказал, комментируя работу специалистов, Эмери Бергер, профессор информатики из другого Массачусетского университета, находящегося в городе Амхерст. — Честно говоря, я удивлён, что она вообще работает».

ссылка на оригинал статьи http://geektimes.ru/post/252808/

Постановка задач и расчет трудозатрат на разработку документации в IT компании

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

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

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

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

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

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

Допустим, в вашей компании два техписателя, их руководитель и несколько менеджеров, которые заказывают документацию.
Когда по какому-либо проекту возникает потребность в документации, руководитель отдела техписателей входит в систему Actionspace через браузер со своего компьютера, ноутбука, планшета или телефона. Нажатием одной кнопки он создает задачу на разработку комплекта документов, указывает срок его готовности, прикладывает необходимые файлы и добавляет ссылку на карточку с требованием в TFS или другой подобной системе управления проектами, которая используется в вашей компании. В поле «Кому» руководитель выбирает фамилию техписателя, ответственного за выполнение задачи, в поле «Копия» указывает менеджера, который заказал документацию, а в поле «планируемая трудоемкость» вводится количество часов, выделенных на данную работу.

Постановка задачи на разработку документации

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

Распределение задачи на нескольких исполнителей

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

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

Получение задачи техписателем

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

Ознакомление с планом работ

Если техписателей в компании несколько, их руководитель может постоянно контролировать процесс работы с документами, добавлять свои комментарии и файлы. Менеджер продукта также сможет отслеживать этот процесс.

Контроль руководителя за выполнением работ по документации

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

Уведомление руководителя о завершении работы над документами

Ну а теперь самое главное:

Когда придет время подсчета трудозатрат (например, для расчета премий), руководителю техписателей нужно будет зайти в систему Actionspace и подготовить отчет, где будут зафиксированы даты начала и окончания работ по всем проектам за указанный период, указаны планируемые и реальные сроки и трудозатраты всех техписателей его отдела. Используя фильтры, можно подготовить отчет о работе всех или конкретного сотрудника, по всем или конкретному проекту, за определенный период и по задачам в определенных состояниях.

Просмотр отчета о работе техписателей

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

Отчет по трудозатратам техписателей

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

Безусловно, предложенный мной вариант подсчета трудозатрат техписателей не идеален, но если своего решения вы еще не нашли, рекомендуем попробовать используемую нами систему Actionspace.
Установить эту систему вы можете самостоятельно ttps://cloud.actionspace.com/ActionspaceCloud/ActionspaceAccount/TenantCreate/, а за 14 дней бесплатного доступа сами сможете оценить ее простоту и функциональность.

ссылка на оригинал статьи http://habrahabr.ru/post/261521/

В Китае могут ввести временный запрет на процедуру первичного размещения ценных бумаг (IPO)

Китайский фондовый рынок, испытавший шокирующую коррекцию на прошлой неделе, продолжает лихорадить.
По итогам вчерашних торгов индекс Shanghai Composite упал на 3,3%, хотя во время торговой сессии опускался ниже, чем на 7,6% относительно закрытия предыдущей сессии. В пятницу, напомним, индекс потерял 7,4%.

Капитализация компаний, торгующихся на биржевых площадках в Шанхае и Шэньчжэне упала совокупно на $2,3 трлн – об этом пишут «Ведомости» со ссылкой на материал Financial Times.

Стремительное падение котировок на фондовом рынке вынудило Народный банк Китая снизить процентные ставки и нормы резервирования для части банков. Ставка по кредитам на код опустилась до 4,8%, депозитная ставка – до 2%.
Комиссия по регулирования рынка ценных бумаг Китая (CSRC) изучает возможность приостановки первичных размещений акций для стабилизации рынка – об этом сообщает Bloomberg. После консультации с крупнейшими брокерскими компаниями Китая комиссия действительно может пойти на такой шаг – ожидается, что приостановка IPO предотвратит переток денег инвесторов со вторичного рынка акций (непубличного) на первичный.

Панические настроения инвесторов аналитики связали с пузырем, образовавшимся на рынке из-за переизбытка ликвидности и масштабной спекулятивной торговли акциями на заемные средства. С начала 2015 года Народный банк Китая, кредитуя банки, влил в финансовую систему страны 770 млрд юаней, что примерно равно $124 млрд. Для сравнения – программа количественного смягчения ЕС, призванная простимулировать первую объединенную экономику мира, «стоит» $550 млрд и является масштабной акцией, способной потенциально изменить жизни многих людей во многих национальных экономиках внутри ЕС.

Китайский фондовый рынок начал бурно расти на фоне притока иностранных инвестиций, и с ноября 2014 по июнь 2015 года индекс Shanghai Composite вырос на 115%, достигнув своего максимума с января 2008 года. Эксперты UBS оценивают приток спекулятивного (то есть не рассчитанного на долгосрочные стратегические инвестиции) капитала в $1 трлн. с 2008 года.

Решения Народного банка призвано успокоить рынок, по-крайней мере на это надеются аналитики, опрошенные FT. Большинство из них так же сходятся на том, что бурный рост китайского фондового рынка завершается, но впереди, скорее всего, последует не коррекция, а настоящий обвал. В Morgan Stanley считают, что к середине 2016 года индекс Shanghai Composite просядет еще на 30%.

Скорее всего, мы больше не увидим «крупнейших по денежному объему» IPO на китайском рынке, подобных выходу на торги Alibaba и объемы/доли и стоимость будущих размещений акций компаний будут сильно скорректированы вниз по стоимости.

ссылка на оригинал статьи http://megamozg.ru/post/16978/

Отстой ли XMPP?

Я должен признаться, что написать эту статью я решил очень спонтанно, прочитав статью «XMPP отстой» и почувствовав некоторую близость к чувствам автора, так как также использую ХМРР в одном из наших продуктов. Тем не менее, сжав эмоции в кулак, я всё-таки решил просто изложить, почему я испытываю смешанные чувства к данному протоколу и разложить по полкам плюсы и минусы. Также расскажу, что мы выбрали для сервера и клиента. Это все, чтобы тебе, дорогой читатель, сделать правильный выбор и вырвать меньше волос в твоих будущих проектах.

Я работаю в компании Thirdlane, где мы делаем продукты для VoIP и унифицированных коммуникаций. В свое время мы выбирали протокол для коммуникаций в одном из наших продуктов. В момент выбора протокола, вопрос стоял просто: писать ли протокол самим, или использовать ХМРР. Других протоколов мы не рассматривали. После не долгих дискуссий мы выбрали ХМРР, полагаясь на то, что это стандартный открытый протокол, имеющий широкое использование, документацию, разные имплементации и расширения, которые на поверхности казались стопроцентно отвечающими нашим требованиям. Сейчас, после достаточно долгого времени роботы с ХМРР, я могу сказать, что я не уверен, что мы сделали правильный выбор. Тем не менее, я не знаю, какими были бы мои чувства, если мы бы пошли другим путем. Конечно сидя вечерами за чашкой чая, я иногда мечтаю вернуться в то время и написать свой закрытый протокол с блек джеком и node.js, но увы. Тут же вспоминаю слова Сократа:

«Женишься ты, или не женишься, ты все равно об этом пожалеешь.»

В момент выбора основные достоинства протокола нам казались следующими:

  • Это открытый протокол;
  • Существует огромное количество серверов, и клиентов для него;
  • Возможность интеграции конечного продукта с внешним миром;
  • Он используется в крутых продуктах: MS Lync, Cisco Jabber, Atlassian HipChat, etc..;
  • Огромное количество расширений в виде XEP-ов;
  • Возможность расширять протокол.

Использование XML как формата для данных, мы считали недостатком, но не критичным, так как нашли библиотеку stanza.io которая позволяет легко конвертировать XML в удобный для роботы JSON.

Клиентская сторона

Так как наш продукт ориентирован на веб-браузер, у нас в руках есть только JS, мы его любим, он классный, стильный, и ваще. Если посмотреть на JS-библиотеки для работы с XMPP, то мы увидим несколько поделок типа strophe, xmpp-ftw, JSJaC. Ни одна из них не пришлась мне по душе, в отличие от вышеупомянутой stanza.io, в которую я лично влюбился с первого взгляда. Библиотека очень хорошо продумана и очень чисто написана, поддерживает все жизненно-важные XEP-ы, с ней легко и приятно работать. Единственный ее минус — слабая документация, что частенько требовало чтения исходного кода. Но это было тоже полезно.

Серверная сторона

Тут мы также не долго парились с выбором, так как в Оpenfire на тот момент не было ни Stream Management, ни Web Socket транспорта. Ejabberd также отпал сразу, по причине Erlang. Кроме того, оба продукта, будучи Open Source, имеют тенденцию к коммерциализации, что не есть гуд. В конечном счете мы выбрали Prosody. Шустрый, легкий, написан на красивом языке Lua, отзывчивое комюнити, проект не мертв, каждый XEP — это отдельный модуль, который легко подключать\отключать, возможность легко писать свои модули, ну, в общем, няшка.

Протокол:

Здесь я буду перечислять, только то, что мне кажется важным, и с чем столкнулся лично.

XEP-0115: Entity Capabilities

Это, конечно, большой плюс. Эта штука позволяет нам узнать, какие из XEP-ов реализованы в клиенте нашего собеседника, слать ли ему чат стейт нотификейшнс или нет, ну или еще чего там.

XEP-0280: Message Carbons

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

XEP-0308: Last Message Correction

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

XEP-0184: Message Delivery Receipts

Это просто песня. Вкупе со стрим менеджментом позволяет дать пользователю знать, что сообщение отправлено и что сервер его получил, и позволяет знать, что сообщение доставлено до адресата. Очень полезно, но, к сожалению, эта информация не попадает в историю переписки — «XEP-0313: Message Archive Management».

XEP-0313: Message Archive Management

Это печалька… Данный ХЕР служит для хранения истории и ее получения. В первую очередь вы никогда не узнаете, было ли доставлено какое либо сообщение, если закрыли клиент. Во вторых, получение истории — это указание от какой даты хочешь и какой лимит. Как по мне, так пейджинг был бы здесь уместнее. Также нельзя организовать поиск сообщений по тексту на сервере, что тоже печалит. Но при наличии рук, это, конечно же, решается всякими костылями. Тут я полностью солидарен с автором вышеуказанной статьи. Непонятно, как в протоколе это было упущено.

XEP-0045: Multi-User Chat

Это худшее, что случилось с ХМРР. Это грусть и тоска, боль и страдания, уныние и отчаяние. Я так скажу: число сатаны — это не 666, это 0045. В первую очередь, это не групповые чаты, это имитация IRC. Всё. На этом можно было бы закончить про 0045, но давайте все-таки разберемся, кто виноват и что делать? Знаете, как войти в комнату? Послать запрос, чтобы войти в комнату. Знаете, как создать комнату? Послать запрос, чтобы войти в комнату. Если её не существует, она создастся. Уникальность имени комнаты сервера решают, кто как хочет. Нравится? Велком ту хелл. Тот, кто создавал комнату (ну или кто имеет право), задает количество последних сообщений, которые будут отправлены клиенту, который войдет в комнату. Только вошел, а тебе N сообщений с группы прилетело прямо в морду. Самое ужасное, что 0045 не предусматривает хранения оффлайн участников. А пользователь считается вышедшим из комнаты, как только закроет свой клиент. Для того чтоб вернуться потом в эту комнату, вам нужно или запомнить её имя, или воспользоваться «XEP-0048: Bookmarks». Представьте себе теперь ситуацию: вас пригласили в групповой чат, вы вошли, поговорили и добавили себе эту комнату в букмарки, да еще и указали, чтоб входить в эту комнату каждый раз при логине автоматически. Знаете, что будет, если эту комнату удалили, пока вы были оффлайн? При логине вы прочитаете букмарки и сделаете «вход в комнату», а как мы знаем, что создание не отличается от подключения, то правильно! Вы создадите новую комнату. Еще? У меня для вас будет. Если комнату не указать как «persistent», она будет удалена, как только последний пользователь закроет клиент или выйдет из нее. Вот такие дела, кто виноват — ясно, теперь вопрос: что делать?

Решили мы данную проблему так: все комнаты создаются и конфигурируются, как «member-only», и persistent. В нашем клиенте мы отрисовываем в списке участников всех тех, у кого есть право входить в комнату. Как оказалось, Prosody запрещает получать такой список всем участникам по умолчанию, хотя ХЕР говорит об обратном. Обсудили это с разработчиками Prosody, надеюсь, что договорятся и испрявят. Ну а пока у нас собственное изменение в коде Prosody. Также пришлось сделать изменение, чтобы пользователь мог сам себя исключить из этого списка (да, по умолчанию тоже нельзя), что означает его выход из комнаты. Еще написали кастомный модуль для Prosody, следящий за изменением списка пользователей комнаты (room affiliation) и сообщающий об этом всем участникам. Таким нехитрым способом у нас получились конференции «почти как в скайпе». Интересно, что в XMPP сообществе сейчас обсуждается подобная реализация MUC только используя Pub/Sub, что подтвердил мне один из участников рабочей группы.

XEP-0085: Chat State Notifications

Полезная штука, всегда хорошо знать, печатает ли пользователь или нет, просто приятный ХЕР.

XEP-0198: Stream Management

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

Вывод

После всего, я все равно затрудняюсь объяснить, почему мои чувства остались негативными. Ведь мы добились, чтобы все работало красиво. Быть может по тому, что мы ожидали, что будем пользоваться протоколом, в котором есть все и не нужно будет тратить время на решение очевидных проблем. Но «втянувшись в бой», мы наткнулись на кучу подводных камней и не продуманных реализаций. Все проблемы, в конце концов, решались, но как в том анекдоте «ложка нашлась, а осадок остался». Еще, наверное, потому, что мы потратил много времени на изучение спецификаций, чтения чужого исходного кода и приведение в порядок ХЕР-ов, которые нам не подходили, да еще, таким образом, чтобы они остались обратно совместимыми с нативными клиентами – что все вместе, есть весьма не благодарное занятие. Но, как я говорил, мы добились требуемого результата. Я думаю, вам самим решать, готовы ли вы изучать сложные спецификации, напарываться на баги их реализаций в клиентах и серверах. Если вы делаете большой сервис, да еще и с интеграциями, то написание собственных расширений вам гарантировано. Посмотрите на тот же HipChat, у него куча кастомных станз. Эти хоть описаны в документации, а что под капотом у Lync или Jabber вообще никому не известно. С другой стороны, если вам нужен базовый функционал, то ХМРР — именно то, что вам надо. Огромное количество всего из коробки, работает 99% случаев.

ссылка на оригинал статьи http://habrahabr.ru/post/261517/