“Инфокультура” проводит исследование востребованности открытых данных о государственных и муниципальных финансах. Важную часть этого исследования составляет опрос среди пользователей (в том числе потенциальных) этих данных. Мы просим вас принять в нем участие и поделиться своими впечатлениями, опытом и потребностями. Теперь немного подробнее о том, к чему это всё.

Конкурс проектов, использующих открытый Skyeng API, подошел к концу; сегодня мы представляем победителей и призеров. Это, впрочем, лишь подготовительный этап к созданию «внешнего контура» нашей экосистемы. Мы планируем активно помогать нашим конкурсантам довести свои проекты до состояния полноценных продуктов. Зачем нам это нужно, а также кого и почему мы выбрали – в нашей статье.

Многие знакомы с gRPC — открытым RPC-фреймворком от Google, который поддерживает 10 языков и активно используется внутри Google, Netflix, Kubernetes, Docker и многими другими. Если вы пишете микросервисы, gRPC предоставляет массу преимуществ перед традиционным подходом REST+JSON, но на существующих проектах часто переход не так просто осуществить из-за наличия уже использующихся REST-клиентов, которые невозможно обновить за раз. Нередко общаясь на тему gRPC можно услышать "да, мы у нас в компании тоже смотрим на gRPC, но всё никак не попробуем".

Что ж, этой проблеме есть хорошее решение под названием grpc-rest-gateway, которое занимается именно этим — автогенерацией REST-gRPC прокси с поддержкой всех основных преимуществ gRPC плюс поддержка Swagger. В этой статье я покажу на примере как это выглядит и работает, и, надеюсь, это поможет и вам перейти на gRPC, не теряя существующие REST-клиенты.

Unity, C#, Steamworks.NET и Facepunch.Steamworks

Введение

Как и большинству разработчиков игр, мне очень хочется выложить мою игру в Steam.

Как и большинству инди-разработчиков игр, мне не хватает доступа к ресурсам/знаниям, которые дали бы мне чётко понять, что же действительно значит «быть в Steam».

Сложно заполнить этот пробел в знаниях, потому что, несмотря на подробную документацию возможностей Steam, трудно понять, с чего начать в этом огромном хранилище документов и как связаны между собой его отдельные части. Кроме того, основные обсуждения платформы Steam проходят в закрытом форуме, доступном только для подтверждённых платформой через Steam Direct или реферальную ссылку Valve разработчиков. То есть для начинающих поиск ответов на простые вопросы может оказаться сложной задачей.

Поэтому я решил написать высокоуровневый обзор для людей, которые только начинают разбираться в том, как заставить Steam работать с их играми. В частности, я подробно рассмотрю Steamworks SDK, программную библиотеку Valve, предоставляющую доступ к таким аспектам, как мастерская (Workshop), таблицы лидеров (Leaderboards), достижения (Achievements) и так далее.

Steamworks хорошо задокументирована компанией Valve, но документация написана с точки зрения человека, использующего нативную библиотеку C++ и уже имеющего представление о том, как все эти функции пересекаются. Если это не ваш случай, то так даже лучше! Ниже представлено объяснение для другого человека, который пишет игру на языке более высокого уровня и просто хочет обеспечить простую интеграцию со Steamworks (а это возможно, я гарантирую!). Конкретнее, этот пост предназначен для людей, использующих в той или иной форме C#, а в идеале — работающих в игровом движке Unity.

Компания Mail.Ru предложила интересный чемпионат для backend-разработчиков: HighLoad Cup. Который позволяет не только получить хорошие призы, но и поднять свой скилл backend-разработчика. Об опыте разработки и настройки окружения будет рассказано под катом.

Часть 1. Сервер
Часть 2. Клиент
Часть 3. Мутации
Часть 4. Валидация. Выводы

Порой при разработке API случается так, что необходимо не только лишь получать данные, но и вносить определенные изменения. Именно для этой цели существует то, что в GraphQL называется странным словом "мутация".

Часть 1. Сервер
Часть 2. Клиент
Часть 3. Мутации
Часть 4. Валидация. Выводы

Для реализации UI рассмотрим пример написания веб-клиента для нашего GraphQL-сервера. И коли уж мы решили не следовать старым добрым традициям, то и в UI этого делать, конечно же, не будем и напишем его на кастомных веб-компонентах с использованием замечательной библиотеки Polymer.

Почему для подключения к GraphQL-серверу была выбрана библиотека Apollo сказать сложно, так как аналогов для работы с GraphQL я не встречал. Изначально библиотека, как и вся ее документация заточена под React, а вся информация об интеграции с Polymer ограничивается лишь ссылкой на компонент в разделе Integrations. Таким образом, если вы работаете с React, вам и карты в руки. Все примеры, твики и хуки именно для него.

В первой части статьи мы рассказали о геометрических ядрах в общем и объяснили, в чём их отличие от игровых графических движков. Далее представляем наше собственное 3D-ядро для работы с точной геометрией и тот программный продукт, который в итоге получился.

История российского геометрического ядра C3D

Началом работ над геометрическим моделированием в КОМПАС-3D официально считается 1995 год, именно тогда Николай Николаевич Голованов с группой коллег из коломенского офиса АСКОН заложили первые математические основы будущего ядра. Потребовалось четыре года, чтобы превратить математические алгоритмы в первый жизнеспособный продукт. С тех пор геометрическое ядро постоянно эволюционирует, обеспечивая функциональное развитие КОМПАС-3D и целого ряда других программных решений в России и за рубежом.



Велосипед Scott Voltage FR20, спроектированный в КОМПАС-3D с использованием геометрии C3D (автор модели: Алексей Богданов, г. Полтава)

Класс XYZ представляет координаты в RevitAPI. А раз мы имеем дело с координатами, то следует рассмотреть азы векторной геометрии. Всего два действия: сложение и вычитание векторов, позволят сделать кучу полезной работы.

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



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

В 1994 году была издана книга «Настольное пособие Unix-ненавистника» (Unix-Haters Handbook), в которой затрагивался целый список самых разных острых тем, от имен оптимизированных под телетайпы команд с совершенно непонятной историей происхождения до необратимого удаления данных, непонятных интуитивно программ с избытком опций. Более 20 лет спустя, подавляющее большинство этих жалоб по-прежнему актуальны несмотря на все многообразие доступные сегодня систем-наследников и ответвлений. Unix стал настолько широко популярен, что изменение его поведения может привести к далеко идущим последствиям. Хорошо это или плохо, но между ним и его пользователями уже сложились определенные договоренности, определяющие поведение Unix-интерфейсов.

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

Часть 1. Сервер
Часть 2. Клиент
Часть 3. Мутации
Часть 4. Валидация. Выводы

Статья рассчитана на широкий круг читателей и требует лишь базовых знаний PHP и Javascript. Если вы занимались программированием и вам знакома аббревиатура API, то вы по адресу.

Изначально статья предполагала лишь описание отличительных особенностей GraphQL и RESTful API, с которыми мы столкнулись на практике, но в итоге она вылилась в объемный туториал на несколько частей.

Чат боты — довольно интересная тема, которой интересуются как гики-энтузиасты, так и компании, которые хотят организовать взаимодействие со своими клиентами наиболее удобным для них способом

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

Что же такое декларативное программирование? Википедия подскажет нам:

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

Далее в статье пойдет речь о том, как использовать данную парадигму в современном web-программировании. В частности, я хотел бы затронуть вопрос о валидации/верификации входных данных для веб сервисов. Примеры будут на php, так как это язык мне наиболее близок в профессиональном плане.

Прошлой ночью Taylor Otwell наконец представил что может стать началом замены Fractal при разработке API на фреймворке Laravel 5.5. Это моя пробная версия статьи, поехали.

Привет, Хабр! Представляю вашему вниманию перевод руководства RESTful JSON API using Eliom.

В этом руководстве рассказывается, как создать простой, но полный REST API с использованием JSON в качестве формата сериализации.

Привет Хабр! Предлагаю вашему вниманию свободный перевод статьи «Schedule tasks and jobs intelligently in Android» от Ankit Sinhal.

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

Привет Хабр! При реализации Angular проекта, остро встал вопрос о безопасности graphql запросов в Angular 4. Выбор пал на JSON Web Tokens. Это открытый стандарт по RFC 7519.

Работает JWT по следующей схеме:

Всем привет! На недавно прошедшем Superjob IT Meetup я рассказывал о том, как мы в Superjob разрабатываем свой API для проекта с миллионной аудиторией и кучей различных платформ.

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

Вообще мы в Voximplant занимаемся голосовой автоматикой. Принять звонок с сотового телефона, запустить JavaScript сценарий клиента – там пара тысяч строк логики что с этим звонком делать, включая исходящие на веб-браузеры и мобильные приложения – вот эта вся история. Отдельная история – видео. Образование, телемедицина, совещания. Тот же SIP, те же кодеки, только данных передается в сотню раз больше. При этом браузеры любят зависать и падать, когда им не нравится полученный с другой стороны WebRTC SDP пакет, а мы их от этого отучаем.

Но, как оказалось, голоса и видео клиентам мало: “Мы не хотим сами писать чатик, уже два раза все переписывали и три питониста уволилось. Дайте нам стек unified communications, чтобы всё было на одной платформе, и мы не парились”. И на прошлой неделе мы стали этим самым “Unified Communications”. Теперь на нас можно собрать “Skype for Web” целиком: не только голосовые и видеозвонки, но и обмен сообщениями. Под катом я хочу показать как работает сделанный нами мессаджинг и, надеюсь, получить от вас фидбек – насколько хорошим получилось API и все ли с помощью него можно сделать?

Трудно поспорить, что ландшафт — неотъемлемая часть большинства компьютерных игр на открытых пространствах. Традиционный метод реализации изменения рельефа окружающей игрока поверхности следующий — берем сетку (Mesh), представляющую из себя плоскость и для каждого примитива в этой сетке производим смещение по нормали к этой плоскости на значение, конкретное для данного примитива. Говоря простыми словами, у нас есть одноканальная текстура размером 256 на 256 пикселей и сетка плоскости. Для каждого примитива по его координатам на плоскости берем значение из текстуры. Теперь просто смещаем по нормали к плоскости координаты примитива на полученное значение(рис.1)


Рис.1 карта высот + плоскость = ландшафт

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