Продолжаю рассказывать об интересных/полезных вещах из мира XAML/C# приложений UWP. OneDrive API является частью Microsoft Graph. Для работы с OneDrive можно использовать OneDrive REST API, которое использует протокол HTTP и в частности его методы GET, POST, DELETE, PUT…
Кроме того, в соответствии с новыми принципами работы Microsoft, была создана библиотека обертка OneDrive SDK for CSharp, которая облегчает работу и использование сервиса из кода ваших приложений.
Читать полностью »
Сегодня мы расскажем о том, как решить, пожалуй, самую актуальную проблему современной телефонии – интеграцию со сторонними информационными системами, прежде всего, CRM системами. Необходимо отметить, что сейчас существует много облачных сервисов телефонии, предлагающих, также, базовый функционал CRM. С другой стороны, многие производители CRM пытаются интегрировать базовые функции телефонии непосредственно в интерфейс пользователя. Также существуют готовые системы “два-в-одном”, в которых уже при проектировании закладывались коммуникационные возможности.
Одним словом, производители этих решений услышали требования пользователей и двигаются в правильном направлении. В целом, так оно и есть. Однако подход “два-в-одном” имеет ряд недостатков, самый главный из которых – неудовлетворительная гибкость. Согласитесь, создание функциональной системы объединенных коммуникаций и первоклассной CRM требует совершенно разных компетенций. В результате пользователь сталкивается либо с ограниченными коммуникационными возможностями, либо с бесполезной “обрезанной” CRM с неясными перспективами развития.
В системах, где CRM изначально объединена с телефонией, также существует ряд недостатков:Читать полностью »
Наша платформа VoxImplant состоит из нескольких частей: облако, API, SDK для разных платформ. SDK для браузера подключается к облаку по WebSocket и позволяет звонить (и принимать звонки) как другим пользователям VoxImplant, так и на обычные телефоны. Раньше это работало с помощью flash, но в современных браузерах используется специально созданная для работы с голосом и видео технология WebRTC. Штука хорошая, но довольно сложная в использовании: возможность peer-to-peer коммуникаций, одна из ключевых «фишек» технологии, управляется полностью вручную. Чтобы два браузера могли организовать голосовой или видеочат друг с другом, разработчику нужно собрать информация об IP-адресах компьютеров, как-то передать эту информацию между браузерами, запустить NAT Traversal и скормить это все WebRTC. А если обойти NAT не получилось, то еще и предоставить Relay-сервер для передачи данных.
Недавно мы нашли на просторах интернета интересную статью, которая рассказывает технические подробности «передачи информации» между браузерами. Адаптированный для Хабра перевод – под катом.Читать полностью »
Одна из команд разработчиков Microsoft уже использует в работе анализатор PVS-Studio. Это хорошо, но недостаточно. Поэтому я продолжаю демонстрировать, какую пользу может приносить статический анализ кода на примере проектов Microsoft. Три года назад мы проверяли проект Casablanca и не смогли в нём ничего обнаружить. За это проект был отмечен медалью «безбажный код». Прошло время, проект развивался и рос. В свою очередь, анализатор PVS-Studio существенно продвинулся в возможностях анализа кода. И наконец я могу написать статью об ошибках, которые анализатор выявляет в проекте Casablanca (C++ REST SDK). Ошибок мало, но то, что теперь их достаточно для написания статьи, говорит о эффективности PVS-Studio.
Читать полностью »
Полагаю, некоторые из вас знают, что у hh.ru есть открытый API (мы рассказывали о нем тут и тут), который используем не только мы, но и сторонние разработчики. С его помощью, например, можно очень детально анализировать рынок на больших объемах актуальных данных.
Я задумал серию из двух статей: в этой покажу, как можно быстро и просто начать использовать API, а в следующей сделаю небольшой проект, рекомендующий актуальные вакансии по вашему резюме.
Читать полностью »
Мы в Perfect Solutions на прошлой неделе написали сотое по счету API. За все это время, ценой граблей, костылей, велосипедов и рефакторинга, мы поняли, что выработали отличную стратегию «как писать API и прекратить боль и страдание».
Этот пост о версировании, поддержке, багфиксинге и полном цикле жизни API.
Под катом нет фото с большим трафиком, нет серебрянных пуль, тут даже нет картинки для привлечения внимания — только полезная выжимка нашего опыта. Под катом методология, выработанная на реальном опыте разработки, набитых шишках и сломанных грабляхъ.
Читать полностью »
Большинству iOS разработчиков рано или поздно становится тесно в мире iOS SDK. И причина, отнюдь, не в том, что у IOS недостаточно возможностей для серьезной разработки, а в том, что большинство современных серьезных приложений имеет клиент -серверную архитектуру, но разработчикам iOS оказывается доступен только Клиентский мир. Серверная разработка отдана на откуп серверным оленям программистам, которые, весьма ревностно относятся к требованиям мобильных разработчиков что-то изменить в API. Не добавляет оптимизма тот факт, что для реализации простейшего API приходится изучать другой язык программирования, со своими парадигмами и нюансами. Даже для того чтоб обкатать какую-нибудь пилотную идею приходится либо привлекать людей со стороны, либо погружаться в мир чужеродных грез (PHP, Pyton, Ruby, C#). Все ли так плохо в стане Objectove-C / Swift? Оказалось, что совсем нет. Немного погуглив на предмет серверной разработки я наткнулся на довольно любопытное начинание, претендующее на то, чтоб стать реальным кросс-платформенным решением — т. е. работающим одинаково хорошо как в среде OSX, так и *nix систем (про Windows не говорю, там С# вряд ли кто подвинет — слишком много вкусностей).
Perfect — как заявляют создатели проекта — Идеальный веб-сервер и инструментарий для разработчиков, использующих Swift язык программирования для создания приложений и других служб REST. Понятно, что «Идеальный» — это не более чем игра слов, но вместе с тем, после знакомства с предлагаемым решеним начинаешь склоняться к тому, что толика правды в этом утверждении есть.
В «прессе» пробегали статьи о том, что на подходе новый язык программирования, который может стать промышленным стандартом с легкой подачи Apple. Язык, который базируется на продвигаемом в массы Swift. Как правило, статьи об этом вызывали больше вопросов, и еще больше раздражения у тех, кому надоело все переучивать (Swift сам по себе довольно быстро меняется). Однако, углубившись в изучение вопроса, становится понятным, что все намного лучше чем, кажется.
Perfect — это не новый язык, серверной разработки. Perfect это серверное окружение, которое позволяет создавать REST API сервисы используя исключительно Swift последней реализации (на момент написания статьи Swift 2.2) Там нет ничего, выходящего за рамки того, что приходится делать ежедневно клиентским разработчикам.
Читать полностью »
Meteor привлекает простотой использования и возможностью очень быстро создать работающее приложение с минимальным набором функций. У Meteor — хорошо развитое сообщество. Есть множество полезных дополнительных модулей, которые не требуют сложной настройки, и могут быть использованы сразу после установки. Есть хорошая документация, примеры и большое количество постов на форумах, вроде StackOverflow. Meteor — это full-stack фреймворк, который предлагает удобную и многофункциональную интеграцию сервера с клиентом. Так зачем же выходить за рамки этого взаимодействия, и создавать RESTful сервис?
Клиент-серверное приложение, по-сути, состоит из 2 независимых частей, которые которые взаимодействуют посредством определенного интерфейса. При этом каждая из частей клиент-серверного приложения может создаваться разными людьми или командами. Разработчики клиенсткой части вовсе не ограничены использованием Meteor, они могут использовать любой другой JS фреймворк, клиент даже не обязательно должен быть написан на JS, это может быть к примеру приложение Android, написанное на Java, или iOS, написанное на Objective C.
Именно эти причины заставили меня выбрать Meteor для построения back end в моем проекте, и искать пути для создания RESTful сервиса на Meteor.
Читать полностью »
В данной статье рассматривается вопрос о том, как реализовать обмен типизированными сообщениями между Back-End на основе ASP.NET Web API и Front-End, созданного с использованием TypeScript. Это приобретает особенное значение при работе над объёмными проектами, и тем-более важно, если команда является распределенной. Например, когда Back-End и Front-End разработчики работают из разных мест, в разных часовых поясах, и не всегда имеют возможность проконтактировать и обсудить что-либо. В этом случае отслеживание изменений представляет кропотливую работу, которая может быть чревата множеством трудноуловимых ошибок.
Для автора статьи, как для человека, который пришел к разработке Front-End со стороны WPF и Silverlight, большой проблемой, стало отсутствие статической типизации. Сколько раз вместо того чтобы сложить “2” и “2” складывал “2” и “Функцию возвращающую 2”, или передавал DOM объект вместо его jQuery обертки. Появление статических анализаторов кода, таких как JSLint, несколько облегчило проблему, но настоящим прорывом, особенно в командной разработке, для нас стал TypeScript.
Сегодня мы хотим поговорить о сокровенном — у нас есть API.
Мы писали, а затем переписывали его заново на протяжении четырех лет. И за это время прошли почти все классические стадии “принятия неизбежного”. Кроме одной — четвертой. И хотим поделиться нажитыми непосильным трудом выводами, что делать и не делать, если вы решите делать свой “мощный эпиай”.
Процесс создания API uCoz иногда напоминал сюжет сериала The Knick («Больница Никербокер») — с неудачными операциями, кишками и экспериментами на живых людях.
