Всем привет. Технологии развиваются очень быстро, и очень приятно, что не только за рубежом.
Компания «Яндекс» представила свою разработку, а именно мультиплатформенную библотеку, которая даёт доступ разработчикам к собственной технологии распознавания речи — SpeechKit.
Более подробная информация далее…

Ранее я писал в паре постов о том как устроена открытость электронных петиций в разных странах, какие данные есть в России и как можно сделать APO для небезызвестной Российской общественной инициативы — www.roi.ru.

Прочитать всё это можно здесь:

• API для Российской общественной инициативы. Шаг 1: сбор и анализ данных
• API для Российской общественной инициативы. Шаг 2.1: опыт Великобритании в работе с данными электронных петиций

В этот раз мы рассмотрим то как устроены электронные петиции Белого Дома, в первую очередь, с точки зрения их открытости и пригодности к данных для использования.

Справка

Особенности петиций в США

1. Относятся именно к президенту и ответы дает его администрация.
2. Не требуют ничего кроме email'а для подписи — дополнительная авторизация ненужна.
3. Петиции должны пройти 2 порога — 150 подписей за 30 дней чтобы их можно было найти (по прямой ссылке они доступны) и 100 000 подписей за 30 дней чтобы получить официальный ответ — petitions.whitehouse.gov/how-why/terms-participation

В цифрах

• всего 2246 петиций
• даны ответы на 208 петиций
• в ожидании ответа 26 петиций
• закрыто 1972 петиций
• открыто для голосования 40 петиций

Цифры учитывают только те петиции что прошли 1-й порог в 150 подписей за 30 дней.

WhiteHouse.gov/developers

Одно из важных отличий сайта Белого Дома США от сайтов всех лидеров в мире — это ориентированность на разработчиков. На сайте даже есть специальный раздел /Developers где размещены данные, раскрыт исходный код проектов и описаны API многих из инициатив если не всех вообще.

Открытый код

Поскольку нас интересуют в первую очередь петиции, то рассмотрим их подробнее.

Во первых исходный код петиций полностью опубликован на Github — https://github.com/WhiteHouse/petitions

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

Открытое API

Другая сторона происходящего в том для разработчиков доступен не только исходный код, но и API и данные накопленные на сервисе.
Все API по петициям доступны по ссылке — https://petitions.whitehouse.gov/developers

API доступа к данным состоит из 3-х эндпоинтов:

Безопасность переписки уже стала широко обсуждаемой темой. Как вы знаете, в этой сфере широко известен написанный петербуржцами Telegram. Команда уверяет в 146% безопасности, но если вы уже пользовались этим мессенджером, знайте, как минимум названия ваших чатов уже скомпроментированы. На момент публикации уязвимость уже закрыта (что приятно, закрыли меньше чем за пятнадцать минут после репорта).

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

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

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

На примере небольшого приложения, авторизирующего пользователя и получающего его последние уведомления с данными профиля, мы рассмотрим, как пользоваться Stack Exchange API.

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

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

Jelastic Cloud API позволяет автоматизировать действия для обеспечения жизненного цикла приложений и расширить функциональность платформы, связывая Jelatic с другими сервисами. Используя API вы можете программно создавать окружения, разворачивать приложения и выполнять другие задачи, которые возможно сделать из панели управления Jelastic, но не ограничиваясь ими.



Jelastic API следует REST принципам. Взаимодействие происходит через HTTP протокол. Преимущество такого подхода — широкая расширяемость протокола HTTP. Вы можете использовать REST API практически с любым языком программирования.

В этой статье вы узнаете, как использовать Jelastic Cloud API и Jelastic Client Library (Java) на облачном хостинге Infobox. В конце статьи 300 рублей на счет Infobox Jelastic в подарок (получить можно только один раз).

Привет! Меня зовут Сергей Константинов, в Яндексе я руковожу разработкой API Карт. Недавно я поделился опытом поддержки обратной совместимости со своими коллегами. Мой доклад состоял из двух неравных частей. Первая, большая, посвящена тому, как правильно разрабатывать API, чтобы потом не было мучительно больно. Вторая же про то, что делать, если вам нужно что-то рефакторить и не сломать по дороге обратную совместимость.



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

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

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

Привет, хабравчане.

Публикация навеяна этой статьей — «eBay API: Первые шаги» и теоретически может стать её продолжением. Она пригодится тем, кто пытался начать работать с eBay API, не нашел где спросить, что делать и плюнул на это занятие. Или спросил, не дождался ответа и в итоге все равно плюнул.

На истину ни в какой инстанции не претендую и с радостью приму советы по преодолению багов, которые преодолеть так и не удалось.



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

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

Достижение начального успеха для Сервис-ориентированной Архитектуры (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 вместе будут укладываться в общую архитектурную картину.

Основная идея

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

Сама система позволяет легко подписываться и отписываться от тех или иных каналов. Что исключает возможность внезапного спама, как это происходит в случае с такими методами уведомлений как SMS и E-mail.

Как и обещал ранее, продолжаю свою серию статей про создание API на Symfony2. Сегодня я бы хотел рассказать о авторизации. Из популярных бандлов есть JWTAuthenticationBundle и FOSOAuthServerBundle, у каждого есть свои плюсы и минусы, но мне хотелось бы рассказать как сделать авторизацию самому, чтобы понимать как это работает.

Введение

Сервис создавался как система уведомлений для пользователей с любого сайта, который интегрировал PushAll API.
Однако не со всеми можно договориться, гиганты вообще не будут обращать долгое время внимание. При этом на данный момент большая часть пользователей, получает именно новостные уведомления с сайтов, а не личные. По этому поводу мне недавно посоветовали интегрировать RSS-рассылки. То есть по факту PushAll становится эдаким RSS-агрегатором, при этом на самом деле обычные пользователи чаще всего не нуждаются в привычных агрегаторах лент — они заходят на сайты самостоятельно и читают новости уже на них.



В этом плане PushAll пошел по своему пути — он не собирает все ленты в одну. Он лишь берет ленту, связывает её с каналов и делает рассылку с учетом фильтра. То есть пользователь заинтересованный в статьях и новостях определенных тематик получит сразу об этом уведомление. Менее полезную информацию он может прочесть потом самостоятельно.

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

Каким образом?

Google Chrome начиная с версии 42 поддерживает Push API через сервера Google, используя GCM Вы наверняка уже видели эти запросы для доступа к уведомлениям. Если разрешить доступ, сайт сможет отправлять вам уведомления. Эта функция совсем новая, и о ней мало кто знает, однако, по моему мнению, у нее уже есть большие недостатки:

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

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

Анализ отзывов пользователей ресторанов был частью задачи тестирования SentiRuEval-2015, прошедшего в рамках конференции Диалог-2015. В этой статье поговорим о том, что собственно делают такие анализаторы, зачем это нужно на практике, и как создать такое средство своими руками с помощью Meanotek NeuText API

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

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



Заинтересовало? Просим под кат.

Используя API переводчика написал для себя простую программу для перевода слов и фраз, и чтобы из любого места работало. Хотел использовать curl, но непонятно почему получал ошибку что такого языка нет.

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

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