Приветствую, Хабр! Хотел бы познакомить вас с относительно небольшим проектом, который я сделал c нуля примерно за 150 часов (50 заходов ~3 часа каждый) на Unreal Engine 4. Проект я делал в прямом эфире только на стримах раз в неделю (в общей сложности ушел год), попутно отвечая на вопросы пользователей.

Сам проект не предназначался как коммерческий. Целью я ставил на практике показать всю сложность разработки игр, а именно такие проблемы, как:

• Планирование и прототипирование проекта
• Продумывание и реализация архитектуры проекта и отдельных его компонентов
• Реализация интерфейса пользователя
• Отладка и исправление ошибок
• Работа с ассетами и графикой

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

Если вам интересны подробности проекта, записи стримов, исходники и прочее, читайте далее.

Через 2 недели, 13 мая в Одессе, команда FlyElephant будет проводить конференцию Data Science Lab. Это будет наша 4-я конференция, которая посвящена искусственному интеллекту, большим данным и науке о данных.

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

• Плейлист AI&BigDataLab 2014
• Плейлист AI&BigDataLab 2015
• Плейлист AI&BigDataLab 2016

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

1. быть независимыми друг от друга
2. взаимодействовать с приложением через API ядра

В этой части я расскажу о структуре ядра, подходящей для разработки data-driven систем.

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

(Заранее извиняюсь за обилие английских слов, какие-то из них я не знаю как перевести, а какие-то мне переводить не хочется.)

Finite State Entropy (FSE) – алгоритм энтропийного кодирования, чем-то похожий и на алгоритм Хаффмана, и на арифметическое кодирование. При этом он взял лучшее от них обоих: работает так же быстро, как хаффмановский, и со степенью сжатия как у арифметического кодирования.

FSE принадлежит семейству кодеков ANS (Asymmetric Numeral Systems),  изобретённых Яреком Ду́дой. На основе его исследований Ян Колле разработал оптимизированный вариант алгоритма, впоследствии названный FSE.

В заметках Яна Колле непросто разобраться, поэтому я изложу объяснение в несколько ином порядке, более удобном для понимания, на мой взгляд.

Допустим, вы хотите создать IO-игру. Что-то похожее на agar.io, slither.io и тысячи их.


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

Сейчас я так не думаю.

Александр Лебедев выражает всю нетривиальность дизайна REST API. Это — расшифровка доклада Highload++ 2016.

Всем здравствуйте!

Поднимите руку те, кто фронтенд разработчик в этом зале? Кто мобильный разработчик? Кто бэкенд разработчик?

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

Пару слов о себе

Кто я такой? Чем занимаюсь?

Я фронтенд team lead компании «Новые Облачные Технологии». Последние 5 лет я писал веб фронтенд, который работает с REST API и который должен для пользователя работать быстро. Я хочу поделиться опытом о том, какие API должны быть, которые позволяют этого добиться.

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

2ГИС давно хотел поделиться с пользователями айфонов своими знаниями о телефонных номерах компаний из справочника. Android-платформа давала такую возможность, а вот под iOS подходящего инструмента долго не было.

В июне мы ездили на WWDC 2016, и на одной из сессий ребята из Apple обмолвились, что наконец-то можно делать «gorgeous astonishment» — определитель номеров под iOS 10. Радости нашей не было предела, но до поры до времени: как Apple любит, фичу она предоставила с рядом ограничений.

Открытый курс машинного обучения mlcourse.ai сообщества OpenDataScience – это сбалансированный по теории и практике курс, дающий как знания, так и навыки (необходимые, но не достаточные) машинного обучения уровня Junior Data Scientist. Нечасто встретите и подробное описание математики, стоящей за используемыми алгоритмами, и соревнования Kaggle Inclass, и примеры бизнес-применения машинного обучения в одном курсе. С 2017 по 2019 годы Юрий Кашницкий yorko и большая команда ODS проводили живые запуски курса дважды в год – с домашними заданиями, соревнованиями и общим рейтингом учаcтников (имена героев запечатлены тут). Сейчас курс в режиме самостоятельного прохождения.

Речь пойдёт о программах и библиотеках для UNIX-подобных систем, распространяемых в виде исходного кода (в том числе в виде тарболлов), написанных обычно на C и C++ (хотя этот же порядок работы может применяться к софту на любом языке). Многие вещи в этой статье написаны применительно конкретно к GNU/Linux, хотя многое из статьи может быть обобщено и на другие UNIX-подобные ОС.

Под словом «пакет» я понимаю в этой статье пакет с исходными текстами, причём не пакет конкретного дистрибутива GNU/Linux, а просто пакет, исходящий от оригинальных авторов софта (UPD от 2017-02-09: кроме тех случаев, где из контекста ясно, что слово «пакет» употреблено в другом смысле).

В этой статье я разберу следующие вопросы:

• Вот скачал программу или библиотеку. Как её собрать и установить? Как воспользоваться библиотекой?
• Что такое префикс (prefix) установки? В чём разница между сборкой и установкой? Куда обычно устанавливают программы?

Я разберу только совсем базовые вещи. Те, которые типичные участники сообщества свободного ПО, программирующие на C и C++ под UNIX-подобные системы, обычно уже знают. Как создавать тарболлы (на примере «голого» make) и как устанавливать чужие тарболлы. Advanced советы по созданию «хороших» пакетов я не дам. «Продвинутые» вещи читайте в документации систем сборки, в замечательной статье «Upstream guide» от Debian (в её конце есть ещё куча ссылок о создании «хороших» пакетов). Многое в этой статье можно было сделать по-другому, моя цель: дать хотя бы один способ, не пытаться объять необъятное.

В процессе разработки приложения на фрейворке Sencha Touch для платформы iOS потребовалось реализовать воспроизведение локальных видео и аудио файлов, которые должны быть зашифрованы на сервере перед скачиванием в память мобильного устройства. Дополнительным условием был запрет на создание дешифрованной версии файла на диске, таким образом появилась необходимость делать расшифровку и чтение данных в оперативной памяти. Поэтому стандартный плагин от Cordova для воспроизведения локальных медиа файлов не подходил, хотя опыта разработки на Objective C у меня не было, я решил создать свой, обладающий требуемым функционалом.

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

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

Я размышлял, в основном с точки зрения преподавателя, о том, как научить отлаживать модели машинного обучения. Лично мне кажется полезным рассмотреть модель с точки зрения ошибок разного рода: байесовская ошибка (насколько ошибочен лучший из возможных классификаторов), ошибка аппроксимации (что мы потеряем из-за ограничения класса гипотезы), ошибка оценки (связанная с ограниченной длиной выборки), ошибка оптимизации (что случится, если не найти глобальный оптимум для задачи оптимизации). Я понял, что полезно попытаться отнести ошибку к определенной области, а потом устранять недостатки в этой конкретной области.

Привет, Хабр! Мы открыли для всех-всех-всех доступ к видеозаписям докладов Международной конференции мобильных разработчиков MBLTdev 16:

• доклады по iOS- и Android-разработке,
• воркшоп по Firebase от Google,
• трек по UX/UI от преподавателей Британской высшей школы дизайна.

Сценарии (часть 2)

Git tag: Step06

Теперь, когда мы реализовали объекты запроса и ответа, добавляем их. Помещаем в файл tests/use_cases/test_storageroom_list_use_case.py следующий код:

Однажды мне стало интересно, отличается ли британская и американская литература с точки зрения выбора слов, и если отличается, удастся ли мне обучить классификатор, который бы различал литературные тексты с точки зрения частоты использованных слов. Различать тексты, написанные на разных языках, довольно легко, мощность пересечения множества слов небольшая относительно множества слов в выборке. Классификация текста по категориям «наука», «христианство», «компьютерная графика», «атеизм», — всем известный hello world среди задач по работе с частотностью текста. Передо мной стояла более сложная задача, так как я сравнивала два диалекта одного языка, а тексты не имели общей смысловой направленности.

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

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

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

На хабре уже писали про Docker swarm mode (режим роя), который является новой фичей версии 1.12. Данная опция внесла небольшую путаницу в головы тех, кто знаком с отдельно стоящей реализацией Docker Swarm имевшей распространение ранее и не отличавшейся удобством настройки и использования. Однако, после добавления Swarm в коробку с Docker все стало намного проще, очевиднее и функциональнее.

Подробнее о том, как устроен новый кластер Docker контейнеров с точки зрения пользователя, а также о простом и удобном способе разворачивания сервисов Docker на произвольной инфраструктуре далее под катом.