Привет, Хабрахабр!

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

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

В целом, весь процесс можно разделить на два этапа — регистрация шаблона рекуррентного платежа и повторное списание регулярного платежа. Покажем на примере использования Payler Gate API:

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

Для взаимодействия сервиса Mandrill с приложением, существует API с довольно широким спектром возможностей, с основными из них нам и предстоит, познакомиться. К тому же имеется возможность использования базового (бесплатного аккаунта) позволяющего производить рассылку до 12000 писем в месяц.

Детальный взгляд на логирование переключение контекста с помощью Event Tracing API для Windows.

В ответ на пост прошлой недели, я получил следущее электронное письмо:

Может быть, я немножко опоздал с вопросом по поводу Вашего недавнего поста, но, на всякий случай, спрошу: Вы имеете какие-либо методы (стратегии) работы с внешней библиотекой, от которой Вы не можете избавиться, и которая нарушает некоторые (или все) принципы написания дизайна API (скорее всего, имеются в виду принципы, рекомендации, которые описаны в предыдущей статье автора. Прим. перев.)? Может, есть какие-то истории? Это расплывчатый вопрос, но я просто спрашиваю о любом опыте (как пользователя) использования API, который действительно запомнился.

— Michael Bartnett

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

Наверное, это была бы неплохая статья в цикле еженедельного разбора плохих API. Но, поскольку у меня нет времени на что-то подобное и есть возможность разобрать только один API, то возникает наиболее ВАЖНЫЙ вопрос — какой именно API я должен выбрать?

Event Tracing API для Windows

Разработка веб API это нечто большее чем просто URL, HTTP статус-коды, заголовки и содержимое запроса. Процесс проектирования – то, как будет выглядеть и восприниматься ваш API – очень важен и является хорошей инвестицией в успех вашего дела. Эта статья кратко описывает методологию для проектирования API с опорой на преимущества веба и протокола HTTP, в частности. Но не стоит думать, что это применимо только для HTTP. Если по какой-то причине вам необходимо реализовать работу ваших сервисов используя WebSockets, XMPP, MQTT и так далее – применяя большую часть всех рекомендаций вы получите практически тот же API, который будет хорошо работать. К тому же полученный API позволит легче разработать и поддерживать работу поверх нескольких протоколов.

Хороший дизайн затрагивает URL, статус-коды, заголовки и содержимое запроса

Обычно руководства по проектированию Web API фокусируются на общих концепциях: как проектировать URL, как правильно использовать HTTP статус-коды, методы, что передавать в заголовках и как спроектировать дизайн содержимого, которое представлено сериализованными данными или графом объектов. Это всё очень важные детали реализации, но не настолько в смысле общего проектирования API. Проектирование API – это то, как сама суть сервиса будет описана и представлена, то что вносит значительный вклад в успех и удобность использования Web API.

Хороший процесс проектирования или методология предоставляют набор согласованных и воспроизводимых шагов для создания компонентов сервисов, которые будут доступны в виде Web API. Это значит, что такая прозрачная методология может быть использована разработчиками, дизайнерами и архитекторами для координации своих действий по реализации ПО. Использованная методология так же может уточнятся со временем по мере того, как улучшается и автоматизируется процесс без ущерба для деталей методологии. На самом деле, детали реализации могут меняться (например, платформа, ОС, фреймворки и стиль UI) независимо от процесса проектировки, когда эти две активности полностью разделены и задокументированы.

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

Комментарии. Jsonnet принимает комментарии в стиле С ( /* … */ ) и С++ ( // )

Ссылки. Ключевое слово self может быть использовано для ссылки на текущий объект. Оператор $ позволяет использовать корневой объект.

Арифметические и условные операторы. Оператор + может складывать числа, строки, массивы и объекты. Операторы == и != возвращают true или false. Оператор if работает как тернарный оператор ?: в С. Далее несколько примеров с операторами языка и результат. Примеры взяты со страницы проекта.

// bar_menu.3.jsonnet
{
    foo: 3,     
    bar: 2 * self.foo,  // Multiplication.
    baz: "The value " + self.bar + " is "
         + (if self.bar > 5 then "large" else "small") + ".",
    array: [1, 2, 3] + [4],
    obj: {a: 1, b: 2} + {b: 3, c: 4},
    equality: 1 == "1",
}

Всем привет!



Вниманию хабрасообщества хочу представить интересную презентацию Стефана Тилькова, со основателя и главного консультанта в innoQ. Стефан рассказывает об идее разделения больших систем на небольшие приложения, которые отвечают за разные аспекты системы. Сама идея не нова, но автор упирает на то, что основной причиной такого разделения должна быть изоляция. Благодаря границам приложений полученных таким образом, сложнее получить связанные модули, которые на самом деле должны быть независимыми. Тут еще можно вспомнить подход «domains boundary», для разделения доменных сущностей по областям применения, вместо того, чтобы создавать единую модель данных на всю большую организацию/процесс.

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

Достижение начального успеха для Сервис-ориентированной Архитектуры (Service Oriented Architecture, SOA) определяется:

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

Множество команд разработчиков создают и используют сервисы, но до сих пор идет мучительный подбор архитектуры, при которой сервисы будут широко использованы, с потенциалом для повторного использования внутренними командами разработки. Вместо создания согласованной сервисной архитектуры и демонстрации множественного использования одних и тех же сервисов, разработчики вновь и вновь не нарочно создают «Просто Набор Веб Сервисов» (Just a Bunch of Web Services (JBOWS)) или «Просто Набор REST Сервисов» (Just a Bunch of REST Services (JBORS)).

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

Управление SOA, API, и приложением может стать мостом между этими концепциями и улучшить архитектурную согласованность всего решения.

Сервисы, API и архитектура

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

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

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

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

UPDATE (12 мая 2015):

Вынужден сообщить, что с 1 мая 2015 года данные устарели. Youtube поменял правила работы API: теперь невозможно осуществлять анонимные запросы. Для получения данных необходим Authorization API-key.

---

Предыстория

Совсем недавно у нас случилась ситуация, когда «потерялись» все YouTube и Vimeo ссылки на ролики, количество просмотров которых нам необходимо выводить на сайте. Это нужно, чтобы потенциальные инвесторы и партнеры видели, какие текущие показатели у наших сериальных проектов. Скрипт обновляет данные раз в сутки, хотя я неоднократно просил сделать обновление показателей в реальном времени. Я много лет не программирую, ушел в совершенно иной вид деятельности и в настоящий момент возглавляю анимационную студию. Конечно же, я был обескуражен возникшей ситуацией с потерей данных, устроил разнос и прочее, но это к делу отношения не имеет.

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

Хорошо в плане поддержки JSON живётся программистам на Javascript — по какому-то невероятному стечению обстоятельств там JSON входит в спецификацию самого языка: есть JSON — есть объект. Удобно. Неплохо дело обстоит и в языках, где JSON не входит в сам язык, но поддерживается стандартной библиотекой (Python, Ruby): импортируешь модуль — и готово.

Жизнь программистов на С++ никогда не была особо простой — поддержки JSON у нас нет ни на уровне языка, ни в стандартной библиотеке. И не будет, возможно, никогда. «Тоже мне проблему нашел!» — скажут мне опытные коллеги — «Её там и не должно быть, С++ поставляется без „батареек“. Для решения этой задачи мы...» и вот здесь они разделятся на два лагеря:

1. «Мы используем большой фреймворк (boost, Qt, POCO, другой), который применяется во всех наших проектах и умеет 150 000 разных вещей, в том числе и JSON.»
2. «Мы придерживаемся подхода в котором для каждой задачи применяется своя легковесная библиотека. В частности, для JSON мы уже 150 000 лет назад выбрали отличную библиотеку %JSON_LIB%, которая прекрасно работает.»

Да, всё так и есть. Вот только…





Давайте немного помечтаем.

А что, если бы JSON вошел в стандартную библиотеку нового стандарта С++? Что, если бы он был написан в терминах С++11\14 и без требований обратной совместимости со старыми стандартами языка? Что, если бы синтаксис этого модуля попытались бы сделать максимально приближенным к родному для JSON использованию «а-ля Javascript», но в том же время сохранить дух С++ (эффективность, минимальное потребление памяти, совместимость с STL)? Что, если бы его можно было включить в проект одним инклюдом и не беспокоиться о его сборке и линковке? Как бы это всё выглядело и работало?

И у нас есть ответ на этот вопрос! Давайте посмотрим на JSON-библиотеку для С++ написанную в соответствии со всеми этими принципами, ну и вообще написанной людьми для людей, а не чужими для хищников, как это обычно бывает.

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

Предыстория

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

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

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

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


Кадр из фильма Леонида Гайдая «Кавказская пленница, или Новые приключения Шурика»

С этими и другими сложностями мы в Alconost справляемся благодаря одному-единственному инструменту, который решает сразу десяток проблем. Медики назвали бы такую штуку панацеей. А мы, локализаторы, зовем ее облачной платформой Crowdin. Именно Crowdin позволил нам делать локализации приложений, сайтов и игр на 40 с лишним языков для десятков разных клиентов одновременно.

Итак, мы выделили шесть основных сложностей локализации, от которых избавляет Crowdin:

Совсем недавно на хабре была статья от AirBnb — «Создавая карту мира». Хорошая и красивая статья про административное деление мира. Один минус — у статьи один комментарий, и то мой.

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

А то она у меня есть:



Вы наверное замечали, что Google.Карты умеют подсвечивать контура городов. С недавнего времени такое есть и на Яндекс.Картах. Мало кто знает, что геометрия есть и на eSosedi.

А вот когда такая возможность появится на вашем сайте — теперь зависит только от тебя %username%.

Для достижения эффекта достаточно зайти на data.esosedi.org или GitHub, ознакомиться с документацией библиотеки osmeRegions и начать использовать.

P.S.: 3 признака того, что год минувший все сделал красиво: 1. Районы 2. Кварталы. 3. Детализация до «Жилые массивы» доступна для некоторых городов.

Нашей главной задачей было дать адреса каждому месту на планете, и сегодня эта задача выполнена. Сетка квадратов what3words покрывает весь земной шар, и у каждого квадрата есть уникальный адрес. Самое время дать возможность каждому использовать адреса из трех слов, и сделать это удобным. Удобно будет, когда каждая карта, навигационное приложение и другие геолокационные сервисы будут поддерживать what3words. Для этого и был создан наш API, о котором мы хотим рассказать подробно.

Со времён систематизации методов объекта console прошло достаточно много времени, некоторые браузеры получили поддержку недостающих ранее методов. Таблица вызывает естественный интерес у разработчиков, поэтому — почему бы её не обновить, дополнив в одной статье описаниями? Github.

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

В этом туториале я покажу, как можно сделать простейший клиент коба на Ruby on Rails. Приложение позволяет залогиниться через коб и сгенерить такой коб с любым текстом:



Рабочая версия этого приложения лежит по адресу fantozzi.dev2.workisfun.ru, код приложения из этого туториала можно посмотреть на Гитхабе: github.com/igorgladkoborodov/memegenerator

DaData.ru — сервис автоматической проверки и исправления контактных данных (ФИО, адресов, телефонов, email). Плюс javascript-виджет и API подсказок при вводе адреса, ФИО и организации.

С предыдущего выпуска Дадата научилась:

• подсказывать email при вводе,
• определять город по IP-адресу,
• распознавать модели автомобилей.

Фичи доступны через пользовательский интерфейс и HTTP API.

Взаимодействие различных сервисов с использованием АPI, из новаторства превращается в обыденность. Количество бесплатных и платных API уже исчисляется тысячами, и с каждым днем их число активно растет. А почему бы и нет? Продажа удаленных запросов к своему новаторскому сервису может принести больше прибыли, чем распространение услуг через свою площадку. И пусть, в таком случае, уже ваши клиенты ломают голову и тратят деньги на привлечение аудитории. Используя свой опыт работы, я предлагаю краткий обзор лучших решений по реализации API на сегодняшний день.