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

Удобные и простые решения проблем при интеграции с серверными мощностями — что делать, если возникает задача сделать два продукта, которые бы идеально стыковались, предоставляли бы друг другу консистентные данные и сами по себе работали без сбоев.

С подробностями Егор Тафланиди, Redmadrobot.

Введение

Очень часто, нам разработчикам необходимо измерить время выполнения своего (и не только своего) кода. Когда я только начал программировать, я использовал структуру DateTime для этих целей. Прошло время, и я узнал о классе Stopwatch и начал его активно использовать. Думаю аналогичная ситуация была и у вас. Не то, чтобы я раньше не задавался вопросом о том, как работает Stopwatch, просто на тот момент знаний о том, что он позволяет измерять затраченное время точнее, чем DateTime мне хватало. Пришло время разъяснить себе, а так же читателям то, как на самом деле работает класс Stopwatch, а так же выяснить его преимущества и недостатки по сравнению с использованием DateTime.

Всем привет!
В предыдущей главе мы познакомились с основами бибилиотекиThree.js. Увидели несколько примеров и создали свою первую полноценную Three.js сцену. В этой главе мы немного глубже углубимся в эту библиотеку и попробуем более подробно объяснить основные компоненты, составляющие Three.js сцену. В этой главе вы узнаете о следующем:

1. какие компоненты используются в Three.js сцене
2. что можно делать с объектом THREE.Scene()
3. какая разница между ортогональной и перспективной камерами

Начнем мы с того, что посмотрим, как же можно создать сцену и добавить на нее объекты.

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

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

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

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

   GET: /api/authitems/?type=0 - получение списка операций
GET: /api/authitems/?type=1 - получение списка задач
GET: /api/authitems/?type=2 - получение списка ролей

   
   а такого:
   

   GET: /api/operations - получение списка операций
GET: /api/tasks - получение списка задач
GET: /api/roles - получение списка ролей
   

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

   SELECT * FROM users WHERE (age>25 AND first_name LIKE '%alex%') OR (last_name='shepard');
   

   
   
3. Порой не хватает возможности создания, обновления, удаления коллекций. Т.е. изменение n-ого количества записей одним запросом опять же используя поиск и фильтрацию. Например, зачастую требуется удалить или обновить все записи, попадающие под какое-либо условие, а использовать отдельные запросы слишком накладно.
   
4. Еще одним важным моментом была возможность получать связанные данные. Например: получить данные роли вместе со всеми её задачами и операциями.
   
5. Конечно невозможно хоть сколько-нибудь комфортно работать с API не имея возможности ограничить количество получаемых записей (limit), сместить начало выборки (offset), и указать порядок сортировки записей (order by). Так же не плохо бы иметь возможность группировки (group by).
   
6. Важно иметь возможность для каждой из операций проверять права пользователя (метод checkAccess все в том же RBAC).
   
7. Ну и наконец, все это дело нужно как-то тестировать.
   

В результате анализа примерно такого списка «хотелок» и появился на свет мой вариант реализации API на этом замечательном фреймворке!

2013 был ознаменован впечатляющими достижениями в развитии технологии API, а также в ее популяризации и инвестициях в эту сферу. Количество API, отмеченных в ProgrammableWeb, впервые перевалило за 10 000, произошли серьезные денежные вливания и поглощения, связанные с этой технологией, было организовано множество новых конференций, включая нашу собственную конференцию API Strategy and Practice, проведенную совместно с API Evangelist. 2013 отметился и новыми инициативами, такими как API Commons, в рамках которой участники пытаются решить долгосрочные задачи различных отраслей экономики.

Количество действующих пользовательских API, которые мы поддерживаем в рамках нашей платформы по управлению API, возросло за прошедший год в 2 раза – и точно так же вырос API-траффик. Поэтому после такого впечатляющего 2013-го мы задались вопросом: что готовит нам новый 2014-й? И вот наши прогнозы!

 
В данной статье мы познакомимся с программированием DECT модуля SC14CVMDECT, обязательно помигаем светодиодом, а также поделимся опытом разработки решения для SIP-телефонии на базе этого модуля.

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

Если гонится за вами
Слишком много человек,
Расспросите их подробно
Чем они огорчены?
Постарайтесь всех утешить.
Дайте каждому совет,
Но снижать при этом скорость
Совершенно ни к чему.
Г. Остер

Сегодня чудесный весенний день. И не только потому что он весенний и очень скоро кому-то придется ехать на дачу копать картошку. А потому что сегодня версия 2.1 API Яндекс.Карт перестает быть beta-версией и становится основной.

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

Разработка API – очень специфичная область программирования. На любую задумку дизайнера и разработчика накладываются потребности и умения пользователей API. Основной фидбек, который мы получаем – это сообщения пользователей в нашем клубе. Туда присылают примеры сайтов с Яндекс.Картами, багрепорты и рекомендации по улучшению нашего продукта. Мы видим, как API смотрится в боевых условиях, и мотаем на ус.

Некоторые вещи часто делают неправильно. Сегодня я хочу о них рассказать. Все советы, которые вы прочтете — вредные. Если вы поймете, что соблюдаете некоторые из рекомендаций этой статьи, ничего страшного – никогда не поздно сделать ваш проект немного лучше. Итак, Irony mode ON.

Резюме поста в нескольких предложениях

• Возможности Excel в части удаленного доступа и совместной работы с документами на сегодняшний день по меньшей мере сопоставимы с Google Docs;
• Excel-документ может быть интегрирован в html-страницы с сохранением значительной части функциональности, т.е. формулы и pivot tables будут работать;
  
• Я, равно как и любой другой человек, могу опубликовать свой Excel-документ таким образом, что ваше, равно как и чье-либо еще, веб-приложение сможет:
  
  1. отрисовать и открыть его для ручного ввода значений в ячейки,
  2. напрямую взаимодействовать с ним через JavaScript;
     
• У Microsoft есть сайт, посвященный интеграции Excel-документов в веб-приложения; также в природе существуют jQuery плагины, позволяющие сделать эту интеграцию быстрой и безболезненной;
  
• С практической точки зрения пользователь получает следующие плюшки:
  
  1. JavaScript представляет широкие возможности для визуализации и анимации Excel-таблиц, а также создания на их базе интерактивных приложений и дэшбордов;
  2. Возможность работы с Excel-документами на планшетах и мобильных устройствах;
  3. Удобный инструмент для создания рабочих прототипов систем управленческой отчетности.

При создании пользовательских объектов на традиционном C++ API (NRX в nanoCAD, ObjectARX в AutoCAD) для обеспечения сохранения объектов и чтения их из файла чертежа необходимо в явном виде описывать запись (сериализацию) и чтение (десериализацию) каждого поля. В MultiCAD.NET API применён более привычный .NET разработчикам описательный подход, в основе которого лежит стандартная .NET сериализация.

Применение сериализации, нечувствительной к версии объектов (Version Tolerance Serialization), предоставляет разработчикам более гибкий механизм управления совместимостью объектов разных версий, чем существующий в традиционном C++ API, где предусмотрено чтение предыдущих версий, но чтение файлов «из будущего» невозможно.

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

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

Еще не стих хабраэффект с нашей предыдущей статьи, а мы уже спешим поделиться с вами еще одной, не менее радостной новостью: онлайн редакторы документов Teamlab Office теперь можно развернуть на своем сервере и встроить в вебсайт или приложение. Бесплатно.

Это был спойлер, ну а подробности, как водится, под катом.

Открытые инновации могут устойчиво поддерживаться Интерфейсами Программирования Приложений (Application Programming Interface, API) и пользоваться преимуществами, которые это «сотрудничество» дает. API не только стимулирует развитие инноваций, но также образует новые потоки дохода, укрепляет ваши маркетинговые кампании и расширяет область влияния применяемой бизнес-модели. Самое время понять, что API необходим для вашего бизнеса.

Введение

С помощью LinkedIn Company Lookup API можно получить информацию о компании зарегистрированной на LinkedIn. Искать можно по ключевым словам, а можно и с помощью ID. Например, GET запрос

http://api.linkedin.com/v1/companies::(1337)

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

В январе 2014 года к нам с Хабра пришёл запрос на локализацию с вопросом, есть ли у нас API. К сожалению, API у нас нет (и у наших переводчиков тоже, мы спрашивали), но мы давно думали о разработке сервиса, который бы позволял разработчикам безболезненно локализовать свои приложения на несколько языков без пересылки файлов по почте и т. п. Кроме того, сейчас мы находимся в процессе внедрения ERP, планируем переделать сайт, а ещё пользуемся серверной TM-программой. Наверняка сейчас удачный момент для объединения этих усилий и создания сервиса, полезного нашим клиентам.

После пары лет поисков, мы в Alconost наконец-то нашли инструмент безболезненного управления задачами: Trello. Инструмент простой и не перегруженный лишним функционалом, по сути — это доски со стикерами-тикетами, перемещающимися от колонки “Идеи” или “Предложения” к колонке “Сделано”.

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

О том, как ребятам из Fog Creek Software удалось сделать такой удивительно простой и одновременно функциональный продукт — в посте Боби Грэйса (Bobby Grace) “How We Make Trello”

Переведено в Alconost.

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

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

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

Всем привет!
Продолжаю вольный перевод книги «ZeroMQ.Use ZeroMQ and learn how to apply different message patterns». Заранее прошу прощения, что так долго не публиковал продолжение, но как говорится: «Лень вперед нас родилась...». Ну что же, лирику в сторону, продолжим.

Содержание

• Глава 1: Приступая к работе
• Глава 2: Знакомство с сокетами
• Глава 3: Использование топологии сокетов
• Глава 4: Дополнительные паттерны

После того, как мы рассмотрели основные структуры ZeroMQ в предыдущей главе, в этой мы рассмотрим сокеты, а именно:

• паттерн клиент-сервер(publish-subscribe)
• паттерн pipeline

На прошлой неделе мы отметили одну круглую дату — в базе данных Likeastore скопилось, ни много, ни мало — один миллион пользовательских «лайков».

Мы используем JavaScript, все текущие сервисы написаны на JavaScript/Node.js. В общем и целом, я не жалею о использовании Node.js в нашем проекте, он отлично зарекомендовал себя как лучшее средство реализации HTTP API. Но для сбора «лайков», это должен быть daemon, который работает постоянно. Наверно, не самая типичная задача для Node.js — про специфику реализации и некоторые подводные камни, читаем далее.