Команда проекта GeeksLab 12 апреля 2014 года в Одессе провела конференцию «Al&BigData Lab», которая была посвящена большим данным и искусственному интеллекту.

Презентации и видеозаписи докладов под катом.

В последнее время мы успели разобраться со множеством аналитических систем, построить экономическую модель и провести несколько экспериментов по оптимизации конверсий в регистрацию и активацию. Благодаря Илье Красинскому(ex. LinguaLeo product chief) мы научились правильной настройке и анализу данных Google Analytics, узнали как строить экономические модели интернет проектов. Далее мы стали разбираться с event based аналитикой и настройкой mixpanel. Теперь мы решили поделиться этими знаниями с хабросообществом.


В этой статье мы рассмотрим:

• Построение экономики продукта с помощью Google таблиц
• Формирование отчета Google Analytics по когортам и каналам
• Создание таблицы анализа эффективности платных каналов

Пару недель назад в Питере прошла юзабилити-конференция ProfsoUX-2014, своим «профсоюзным» названием обозначающую именно индустриальность проблем, заслушанных на собрании ленинградских трудящихся в области Usability и UX. Как бы прикол, хотя реальность развивается в таком направлении, что скоро действительно появятся «профсоюзы работников человеко-ориентированного проектирования интерактивных систем для электронно-вычислительных машин ГОСМИНЭРГО».

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

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

Вот, в качестве иллюстрирующей видеокартинки — трехминутный обзорный ролик обо всех докладах конференции.


А теперь, под катом, предлагаю краткий обзор-классификацию с ссылками на видео, так, чтобы вы могли посмотреть именно то, что вас потенциально интересует.

Парадигмы программирования

В современном мире IT-разработки существует довольно большое множество различных подходов к написанию программ. Так, например, кому-то нравиться представлять программу в виде последовательности действий, а кто-то считает, что программа должна представлять собой множество объектов, общающихся друг с другом. Совокупности этих идей и понятий образуют своего рода стиль написания программы, который принято назвать – парадигма программирования.

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

• инструкция (императивное программирование, FORTRAN/C/PHP),
• функция (функциональное программирование, Haskell/Lisp/F#/Scala),
• прототип (прототипное программирование, JavaScript),
• объект (объектно-ориентированное программирование, С++/Java),
• факт (логическое программирование, PROLOG).

Стоит заметить, что в общем случае язык программирования однозначно не определяет используемую парадигму: на том же PHP можно писать как императивные, так и объектно-ориентированные программы.

В этой статье я хочу рассказать о сравнительно молодой, но крайне, на мой взгляд, полезной парадигме программирования – аспектно-ориентированном программировании.

Уже не помню, каким образом я натолкнулся на Door Kickers — двумерный тактический симулятор команды спецназа со свободной паузой (дада, можно нарисовать пути атаки, в любой момент поставить игру на паузу и переделать их. Никаких ходов и гексагонов, никакого жёсткого реалтайма). Факт в том, что купив её, я сел поиграть «пару миссий», и очнулся под утро, когда пытался пройти все уровни с максимальным количеством звёзд. Дальше больше, и в итоге я начал узнавать про фирму издателя (вдруг у них есть ещё подобные проекты?). Оказалось, что игру делает маленькая фирма из Румынии — KillHouse Games, которой меньше двух лет от роду, но у разработчиков уже был ощутимый багаж знаний для разработки собственной игры
TL;DR — трейлер игры (на текущий момент графика в игре выглядит немного по другому):



А дальше идёт интервью с ними:

Введение

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

Подготовка данных рубрикатора

Для начала определимся с тем, в каком виде мы будем готовить данные для рубрикатора.

• 1. Рубрикатор – это граф, а не дерево
• 2. Текст, тематика которого определяется, может быть отнесен к нескольким рубрикам одновременно
• 3. Для каждого соотнесения с рубрикой указывается коэффициент точности определения рубрики
• 4. Тематика текста определяется для каждого текста отдельно, и не зависит от того как были определены рубрики других текстов ранее

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

Алгоритм определения тематики текста, кратко

Описываем рубрикатор. Извлекаем из исследуемого текста ключевые слова, описанные в рубрикаторе. В результате извлечения получаем кусочки разорванного и чаще всего несвязного графа. Используем волновой (или любой другой, по желанию) алгоритм для «дотягивания» извлеченных кусочков графа до вершины «всё». Анализируем и выводим результаты.

Всем привет,

Недавно мы в Alconost сделали несколько видеороликов для игр и во время работы над ними столкнулись с повторяющимися вопросами клиентов: что показывать в ролике, делать ли ролик с голосом диктора или без, как недорого перевести ролик на несколько языков, какие исходные материалы нужны, как сделать видеозахват экрана мобильного девайса… Чтобы ответить на эти животрепещущие вопросы раз и навсегда, мы хотим рассказать и на конкретных примерах показать, как мы делаем видеоролики для игр.

Наш опыт будет полезен как тем, кто пробует делать видео самостоятельно, так и тем, кто собирается аутсорсить создание видеоролика для своей игры.

Итак, чтобы сделать видео для игры, надо пройти следующий путь:

Выбор типа ролика

Первое, о чем мы спрашиваем клиента — “зачем вам видеоролик?” В зависимости от ответа предлагаем один из типов видео:

- Ролик-тизер. Не показывает геймплей, не говорит ничего конкретного про игру, но создает интерес к игре, дразнит зрителя.

Тизер для мрачной и чертовски захватывающей игрушки Darklings 2 от Mildmania:

Вы связаны с разработкой игр? Маркетингом игр? Сколько статей о монетизации игр вы прочли в последнее время? Лично я – очень много. Статьи, видео, слайды, аналитические обзоры и т.д. Конечно, понятно и очевидно, что никто не скажет вам супер-секрета успешной монетизации. Просто потому, что его нет и не может быть. Просто потому что, во-первых, плохую игру не спасет ни одна монетизация, а во-вторых, все игры разные.
Статья ниже – это список всевозможных монетизационных механик, которые встречались мне в играх, статьях и других источниках. Вместо того чтобы разбирать конкретные игры, я хочу перечислить как можно больше способов монетизации с небольшими комментариями.
Статья не предназначена для людей, считающих, что все это промыслы жадных разработчиков, а вся индустрия мобильных игр – это алчные корпоративные сволочи, закапывающие некогда прекрасные идеалы игрового мира не знавшего F2P.

Современный капитализм обусловил одни простой житейский «закон» — богатые становятся богаче, бедные — еще беднее. Так как больше денег -> больше возможностей заработать -> больше денег. Нам, работникам IT, немного повезло. Благодаря спросу на наш труд, который нам, чего уж скрывать, нравится, мы застряли где-то посередине — средств хватает на удовлетворение большего числа основных потребностей и еще остается небольшой излишек.

И вот тут многих начинает волновать вопрос — «что с ним делать?». Многие сделав вывод что «хранить нельзя» в решении вопроса идут дальше и задаются следующим вопросом: «во что инвестировать?». Возникает еще один попутный вопрос: «как обеспечить себе старость?».

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

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

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

Когда говорят про разработку игр, обычно речь идет о шейдерах, графике, AI и т.д. Крайне редко затрагивается серверная часть игровых проектов, а ещё реже — базы данных. Исправим это досадное недоразумение: сегодня я расскажу о нашем опыте работы с базами данных, который мы приобрели в ходе разработки Аллодов Онлайн и нашего нового проекта Skyforge. Обе эти игры — клиентские MMORPG. В первой зарегистрировано несколько миллионов игроков. Вторая разрабатывается студией в строжайшей секретности в недрах Allods Team.

Меня зовут Андрей Фролов. Я ведущий программист Allods Team и работаю в команде сервера. Мой опыт разработки — почти 10 лет, но в игры я попал только в октябре 2009. В коллективе я уже больше трёх лет, с марта 2010. Начинал работу на Аллодах Онлайн, а сейчас на Skyforge. Занимаюсь всем, что так или иначе связано с сервером Skyforge и базами данных. В этой статье я расскажу о базах данных в онлайн-играх на примере Аллодов и Skyforge.

Привет, Хабр! Я Андрей Фролов, ведущий программист, работаю в Mail.Ru над Next-Gen MMORPG Skyforge. Вы могли читать мою статью про архитектуру баз данных в онлайн-играх. Сегодня я буду раскрывать секреты, касающиеся устройства сервера Skyforge. Постараюсь рассказать максимально подробно, с примерами, а также объясню, почему было принято то или иное архитектурное решение. По нашему серверу без преувеличения можно написать целую книгу, поэтому для того, чтобы уложиться в статью, мне придется пройтись только по основным моментам.

Эта тема была поднята в ходе нескольких (3+) собеседований который я прошёл за последние полтора месяца — в разных вариациях но примерно об одном. Казалось бы, известные вещи — но собрав все ответы и объяснения какие я давал (и кое-что что нашёл позже в гугле), решил сохранить их не у себя в гугл-драйве, а написать краткий обзор.

Речь шла о небольших и типовых приложениях Enterprise / Web на Java, каких пишется множество (ну такие, на 10-100 тысяч клиентов, миллион посещений и т.п.). Пусть это будет обобщённый диалог в виде вопросов и ответов.

 

В: Допустим, у вас есть приложение (самое обычное — JSP, Spring, Hibernate например) развернутое на томкате (Apache Tomcat) и вы однажды замечаете что сервер с томкатом загружен на 80% в среднем. Что делать?

В тот момент, когда начиналась разработка HTML Academy, мы достаточно серьёзно играли в WOW, да и, вообще, были поклонниками игр Blizzard со стажем. Поэтому с игровыми механиками были знакомы достаточно хорошо, хотя сами этого не подозревали. Многие интересные механизмы появились в академии, как нам казалось, сами по себе. Но позже выяснилось, что на самом деле они называются «игровыми механиками», а мы их неосознанно взяли из игровой практики.

Привет, Хабр!

Месяц назад на Google Play вышла моя новая игра — Crystalux. Будучи до сих пор обрадованным этим знаменательным событием, я поделюсь с вами кое-какими техническими и маркетинговыми тонкостями, которые узнал в ходе разработки. Ну и заодно немного попиарю мое творение, конечно.

Вкратце об игре.

Crystalux — головоломка с цепочкой уровней. Игровой процесс не претендует на уникальность, но вполне неплох и способен затянуть. Вам необходимо собирать узор из кристаллов, расположенных на шестиугольных фишках так, чтобы кристаллы соединялись по цветам. Более подробно описывать нет смысла, проще посмотреть ролик или попробовать.

Началось всё с желания делать свои игры вместо того, чтобы делать чужие.
Полгода назад я (программист) и мой товарищ (художник) уволились с работы и решили начать делать проект мечты — раллийный симулятор.
Этот проект мы задумывали очень давно, но не хватало опыта и знаний, чтобы начать и закончить.
За несколько последних лет мы оба набрались опыта и созрели для того, чтобы наконец сделать этот проект.
Но за те 10 лет, что мы пробовали свои силы, наши наработки полностью устарели. Кодовая база оказалась сложно портируемой на мобильные устройства. Контент не соответствовал современным требованиям.
Пару месяцев мы ковыряли то, что у нас уже было в надежде понять, что же делать…
И пришли к выводу:
Надо прощупать почву

Нам надо было понять, каким образом ведётся разработка кроссплатформенного движка, способного адекватно работать как на ПК, так и на мобильных ОС. Как публикуется игра? Как ведут себя отдельные площадки и на каких условиях работают?
Нам нельзя на проекте мечты совершать детские ошибки. Проект должен разрабатываться и публиковаться с чётким пониманием: как, что и для чего делается.
И для этого мы взялись реализовать тестовый проект. Небольшую казуальную игру.
Эта статья о том, как мы публиковались на Google Play, как провалили публикацию на Greenlight и какие сюрпризы нас ждали в AppStore.

Привет! Меня зовут Андрей Саенко, я живу в Воронеже, работаю в Allods Team и создаю астральные острова для игры «Аллоды Онлайн». Астральные острова — это приключения для 6 игроков, наш аналог общеизвестных данжей. Обычно концепции своих приключений я придумываю самостоятельно, но в моей практике был очень необычный опыт — мне довелось воплотить в игре астральный остров, придуманный одним игроком. На его примере я хочу рассказать о своей работе.

«А давайте запустим конкурс астральных островов?», — предложил нам однажды комьюнити-менеджер. Я согласился, подумав, что речь идёт о каком-то художественном конкурсе: я не раз сталкивался с тем, что фанаты нашей игры рисуют просто превосходно. Но объём взятых на себя обязательств я осознал лишь после того, как мне показали черновик новости о начале конкурса. Участникам не просто предлагалось придумать общую концепцию, они должны были продумать каждую деталь. И все это я должен был реализовать в игре!

Всем привет, хочу поведать хабру об одном необычном сетевом сервисе и процессе его разработки. Но сперва пару слов непосредственно обо мне — я прикладной программист MAXScript (это встроенный в 3ds max скриптовый язык), а 3ds max это один из популярнейших пакетов для создания разнообразной 3d-графики и в нем, естественно, есть такая штука как рендеринг, из-за которой собственно все ниженаписанное и делалось.

Идея

Начался процесс с одной идеи, которая пришла мне в голову совершенно внезапно поздней ночью 30 ноября 2010 года и вылилась на следующий день вот в такой пост на форуме 3dcenter.ru:

01/12/2010, 12:49
Пришла эта мысль в голову и не вылазит. Хочу обсудить с сообществом полезность и целесообразность. Основную часть технических подробностей пока опускаю, но сделать сие вполне реально либо в качестве плагина (SDK), либо даже скрипта (MAXScript).
Итак, смысл в том, чтобы бесплатно (или не очень) использовать чужие компы для рендера своих сцен. Есть система рейтинга, т.е. нельзя долго рендерить свое («качать»), но не рендерить чужое («раздавать»). Для тех, кто боится, что его сцены или текстуры будут использовать чужие нехорошие люди, предусмотрена защита — координаты всех объектов сцены изначально обнуляются, правильные координаты шифруются и передаются на рендер отдельным файлом, текстуры бьются на маленькие квадратики и собираются в одну тоже только перед рендером. Показ самой визуализации (VFB) можно отключить, т.е. человек даже не видит, что он рендерит. Аналогичные действия происходят и после рендера — изображение автоматически разбивается на кусочки (либо просто перемешиваются пиксели по какому-то закону) и собрать его правильно можно только на стороне автора сцены. Для альтруистов есть возможность отключения защиты, т.е. сцена с барахлом передается в свободном доступе. Защита может быть и другая, и вообще все что я пишу еще до конца не обдумано — только варианты.
…
Ну вот в общем как-то так, прошу не кидаться помидорами, и, если велосипед я не изобрел, то обсудим, насколько вообще жизнеспособна эта идея.

Рядовые программисты обычно всё это прекрасно знают. А вот менеджерский состав нередко считает, что совершенно не обязательно разбираться в игровой экономике, клиент-серверной архитектуре и психологии игрового комьюнити. Ведь есть же крутая команда спецов, которые обо всём позаботятся.
Итог очевиден: трудно вспомнить хотя бы один крупный MMO-проект, выпущенный за последние два года, который избежал бы стандартного набора граблей. Такое ощущение, что MMO-индустрия не способна учиться на своих ошибках.
Итак, список вопросов, ответы на которые должен знать каждый, от топ-менеджера до работника техподдержки крупного MMO-проекта.

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

• отложенная обработка пользовательских данных;
• передача статистики;
• сглаживание нагрузки на относительно медленные системы;
• выполнение периодических задач.

Существует несколько подходов к организации очередей:

• использовать реляционные базы данных;
• применить существующие решения (RabbitMQ и т.п.);
• написать свой велосипед.

«Мой Мир» какое-то время использовал очереди в реляционной базе, но с ростом проекта начались проблемы с производительностью. Мы встали перед выбором: применить существующие решения или разработать свою систему.

В каталоге бесплатных тем для Bootstrap есть симпатичная тема Lumen, в ней используется шрифт Source Sans Pro, в котором «из коробки» отсутствует кириллица. Эту проблему можно частично решить самостоятельно, скомпилировав шрифт из исходников. Почему частично — см. заключение.