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

• Возможности 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 — про специфику реализации и некоторые подводные камни, читаем далее.

Госзатраты (clearspending.ru) — это новый общественный и некоммерческий проект которым мы занимались последние полгода в виде базы всех государственных и муниципальных контрактов.

Мы взяли всю базу контрактов с zakupki.gov.ru и, после некоторого количества усилий, превратили в веб-сайт с удобным поиском, навигацией, некоторым количеством аналитики и, что особенно важно, с API.


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

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

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

В первой части я рассказал, как создать RESTful API в облаке Windows Azure и как начать его использовать в своем мобильном приложении. Рекомендую ознакомиться с той статьей, поскольку данный текст и примеры во многом опираются на нее.

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

Windows Azure и Git

Как вы неверно уже слышали, компания Microsoft, к ее чести, в последнее время все чаще обращает свое внимание на Open Source технологии. Так, например, в последней версии Visual Studio 2013 была «из коробки» внедрена поддержка системы контроля версий Git. Облако Windows Azure тоже не осталось в стороне, и теперь позволяет работать с кодом не только через TFS, но и с помощью Git и прочих систем (SVN, Dropbox, Bitbucket).

В Windows Azure Mobile Services решили пойти дальше и оставить для работы только Git. Возможно это так только на время Preview-версии данного решения, но, учитывая тенденции корпорации, такой вариант может перекочевать в релиз.

Что же нам дает использование Git в своем проекте? Да все абсолютно то же, что и всегда. А именно — совместная работа над кодом, локальные репозитории у каждого участника команды, поддержка версионности. Но что еще важно, так это соблюдения принципа continuous integration — непрерывное развертывание решения при каждом новом чекине кода в репозиторий. Каждый раз, когда кто-то из участников команды отправляет свои изменения на сервер, происходит их деплой в облаке. Все это работает на Kudu (кстати, еще один open source проект), и довольно успешно.

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

Доброго времени суток всем хабражителям. Меня зовут Илья Шакитько и я работаю в LeaseWeb, в команде, работающей над облачными сервисами. Решая очередную задачу, связанную с исследованием той или области, мы стараемся поделиться полученными знаниями или мыслями с сообществом. Не так давно мы проводили DevOps встречу в нашем офисе, где одним из выступающих был мой коллега, Мауритс ван дер Скхи, который рассказывал об API First архитектуре. Немногим ранее в нашем блоге он опубликовал статью, переводом которой я хотел бы поделиться с вами.

Введение

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

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

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

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

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

Если вам когда-нибудь приходилось разрабатывать форму регистрации или оформления заказа, то вы знаете, что для получения из формы качественных данных нужно прикрутить множество проверок для ФИО, почтовых адресов, e-mail, телефонов. При этом так уж исторически сложилось, что разработчики пишут код валидации информации каждый раз заново. Ну а потом эти проверки приходится еще и поддерживать, а на поддержку, как известно, приходится 80% усилий.

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

Так не должно быть.

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