Извиняюсь за заголовок в стиле «for Dummies», но это именно то, о чем я хочу сегодня поговорить — о монетизации. В двух словах о себе: занимаюсь инди-геймдевом с 2010 года, на данный момент у меня около десятка изданных игр на Play Store с общим количеством загрузок чуть-чуть не дотягивающим до 20 млн. Я не люблю распространяться о финансовой стороне, но понимаю что в теме о деньгах, без этого никак. На КДПВ вы можете видеть мою статистику за несколько последних дней (на момент написания статьи). В общем, бывало хуже, но бывало и лучше! Цифры не из тех, что поражают воображение, но, согласитесь, довольно неплохие. Особенно, учитывая что я всего лишь любитель, клепающий игры по вечерам.



В этом топике, я попробую поделиться выводами и наработками, которые сделал за это время. На всякий случай disclaimer: мое мнение не претендует на истину и основано лишь на моем субъективном опыте. Я всегда готов поучиться у более опытных коллег, так что если я в чем-то ошибаюсь — прошу в комменты. И второе: это взгляд на геймдев с точки зрения бизнеса, если вы не разработчик, вам может не понравиться то что я скажу.

Мы знаем, что Земля – это одна из 8 планет, которые вращаются вокруг Солнца. Солнце – это всего лишь звезда среди порядка 200 миллиардов звезд в галактике Млечный Путь. Очень тяжело осознать это число. Зная это, можно сделать предположение о количестве звезд во вселенной – приблизительно 4X10^22. Мы можем видеть около миллиона звезд на небе, хотя это всего лишь малая часть от всего фактического количества звезд. Итак, у нас появилось два вопроса:

1. Что такое галактика?
2. И какая связь между галактиками и темой статьи (кластерный анализ)

В нашем отделе веб-разработки есть хорошая традиция. Каждые 2 недели у нас проходят «голые пятницы» — это мини-конференции, на которых мы делимся интересными и полезными знаниями, накопенными в процессе работы. Сегодня таких знаний у нас накопилось довольно много, и мы решили начать постепенно делиться ими с общественностью в лице Хабрасообщества.

Итак, представляем вашему вниманию сборку интересных и (надеемся) малоизвестных HTML и CSS-рецептов. Будем рады, если каждый из вас узнает что-то новое!

Господа, рад представить вам свой новый проект — Refactoring.guru.

Сайт представляет собой каталог запахов грязного кода и, собственно, самих приёмов рефакторинга. В двух словах — это как книга Мартина Фаулера, но лучше. А именно:

• Весь контент доступен на русском языке. Я старался делать описания как можно более живыми, чтобы избавиться от чувства унылости и скуки, которое возникает при чтении любой переводной книги о рефакторинге.
• Все примеры подаются на Java и PHP. Другие языки обязательно будут добавляться со временем, но я пока затрудняюсь решить, каким будет следующий, можете предлагать в комментах.
• Всё везде перелинковано. Рефакторинги сгруппированы по предназначениям и связям.

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

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

Буду рад всем отзывам и пожеланиям! (а также лайкам и твитам)

Задумывались ли вы когда-нибудь, найдя аккуратную публичную базу данных, как хорошо было бы включить её в своё приложение, чтобы оптимизировать какую-нибудь функциональность, пусть даже незначительно? Конечно же да! Этот пост расскажет как, использовать Logstash для превращения внешнего набора данных в желаемый формат, проверить результат в Kibana и убедиться что данные правильно индексированы в Elasticsearch так, что могут быть использованы при больших нагрузках на живых серверах.

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

Доброго времени суток, друзья!

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

Но сам пост не об этом. Сегодня я хотел бы поделиться с вами маленькими подсказками по поводу пользовательского интерфейса. О том, чего стоит избежать уже в самом начале разработки, и что потом делать. К сожалению, мой «скилл» недостаточно высок, чтобы писать о чем-то действительно новом и неизведанном в этой области, так что пост будет больше посвящен новичкам в гейм-деве (и в первую очередь тем, кто пока еще боится NGUI), да и пост будет субъективен на все 146%.

Доброго времени суток!

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

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

Еще раз напомнюсь, эта статья — лишь ощущения от знакомства с игростроем, и рассказ о своем небольшом опыте.

Главное меню — один из основных инструментов для взаимодействия пользователя с приложением. В Android 2.3.x и раньше оно было «спрятано» на аппаратной кнопке Menu, и разработчики рисовали меню кто как умел. Но начиная с Android 3.0 недоработка была исправлена, меню стало стандартным компонентом на Action Bar, и получило ряд новых возможностей. При этом процесс разработки меню практически не претерпел изменений. Меню в Android — это не просто набор кнопок, на которые можно вешать OnClickListener. В Android с меню можно сделать куда больше, чем кажется на первый взгляд.

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

DDMS (Dalvik Debug Monitor Server) — безумно полезный инструмент для отладки приложений, который идет в комплекте с Android SDK, о котором почему-то особо и не сказано на хабре, впрочем как и в примерах google он представлен в очень скромном виде. Я бы хотел раскрыть его возможности и показать на что он способен. Вкратце:

• изучать информацию о работающих потоках;
• анализировать heap на количество свободной и занятой памяти;
• анализировать какие объекты чаще создаются, их размер и другое (Allocation tracker);
• находить проблемные участки кода, которые долго работают и требуют оптимизации (Method profiling). Это я советую знать всем.

Об этих вещах будет рассказано в рамках данной статьи. И для справки, менее интересное, что довольно тривиально и о чем НЕ будет рассказано в рамках данной статьи:

• работать с файловой системой эмулятора или устройства;
• находить информацию об ошибках (привет LogCat);
• эмулировать звонки/смс/местоположение;
• использовать инструмент Network Statistics.

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

• Android Annotations
• Groundy
• Retrofit
• AnnotatedSQL
• Android db-commons

Если заинтересованны прошу под кат.

“А что это вы тут делаете?”

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

<div data-role="header">
    <a href="#" class="ui-btn-left ui-btn ui-btn-inline ui-mini ui-corner-all ui-btn-icon-left ui-icon-delete">Cancel</a>
<h1>My App</h1>
    <button class="ui-btn-right ui-btn ui-btn-b ui-btn-inline ui-mini ui-corner-all ui-btn-icon-right ui-icon-check">Save
</button></div>

Этот пример создает кнопки Cancel и Save. Для поклонников фреймворков, например, популярного в последние пару лет Bootstrap, данный код выглядит нормально. Для меня же это выглядит адом и вот почему.

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

Событие автоподстановки в инпут поля

Проблема: узнать, что пользователь воспользовался функцией автоподстановки. Задача была в том, чтобы подсвечивать кнопку Login, если в полях e-mail и password введено что-либо. Проблема в том, что если эти поля заполняются автоподстановкой из ключницы браузера, то событие change на инпутах не выстреливает.

Решение: использовать псевдокласс :valid. Он срабатывает у инпута, если в нем есть контент, который удовлетворяет типу инпута (text, e-mail) и если у этого инпута стоит атрибут required. Правда решение не работает в IE, но нам не требуется поддержка этого браузера.

<input required="required" class="email-input" type="email" />
<input required="required" class="password-input" type="password"/>
<div class="go">Login</div>

.email-input:valid ~  .password-input:valid ~ .go {
	//стили для активной кнопки Login
}

Когда я начинал изучать андроид, мне очень хотелось добавить красивое перелистывание экранов — как в популярных приложениях. Хотелось просто некоторое подобие LinearLayout, содержимое которого можно будет прокручивать. Однако для того, чтобы написать простейший слайдер с использованием ViewPager, мне потребовалось несколько часов на разбор, а также целая страница кода. К тому же, присутствовали некоторые ограничения — добавление объекта внутрь тега <ViewPager> не добавляло его в список виджетов.

Разобравшись, решил написать свой класс ScreenPager, который наследуется от ViewPager и работает очень просто. Причём работает как в xml, так и в чистом коде.

Знакомьтесь, это обычный «литровый» пакет молока:

• Проверка на внимательность: там 900 грамм. Рядом несколько по 950. Но пакет может быть воспринят как литровый.
• Проверка на знание физики. Рядом лежит похожий кефир. Объём измеряется в миллилитрах, масса — в граммах. Плотность кефира трагически выше плотности воды. То есть 900 грамм кефира 3,2% жирности — это примерно 874,5 миллилитров.

Второй пациент:



25 лет гарантии. Круто, правда? Есть одна проблема. Надо сохранять чек. Проверка, опять же, на знание физики. Чек у них печатается на обычной кассовой термоленте (я проверил на месте). У меня в офисе лежит много чеков. Мы их ксерокопируем, потому что через год-два они полностью выцветают. Самый старый чек, который видел коллега, держался 3 года в папке в архиве. UPD: смотрите самый низ топика, Икея ответила.

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

Осторожно, трафик: под катом много находок с фотографиями.

На хабре в прошлом месяце была опубликована статья Конкурс ВК: Мессенджер для Android. Как это было!, в которой автор поделился своими мыслями о конкурсе и опубликовал список ресурсов и статей, которые помогли ему в создании приложения. Так как в последнее время я начал изучать разработку под iOS, то у меня скопилось некоторое количество ссылок, которые могут быть полезны для начинающих. Поэтому я последую его примеру и сделаю то же самое, только для своей платформы. Надеюсь, кому-нибудь они окажутся полезны и сэкономят немного времени.

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

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

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

1. Вычисления не должны блокировать взаимодействие с интерфейсом и его рендеринг — пользователь всегда должен иметь возможность указать на фокус своих интересов.
2. Страница объекта, к которому обратился пользователь, должна отображаться мгновенно, не дожидаясь загрузки данных, в которых нуждается объект.
3. Запросы в сеть не должны уходить одной большой группой, не должны отправляться сразу; должны откладываться на небольшое время, складываться и приоритезироваться в случае необходимости.

Изложенная в этой заметке информация — это мой практический опыт проектирования и разработки интерфейса моего приложения для поиска и прослушивания музыки seesu.me. Приложения, в котором гармонично комбинируются огромные пласты данных из разрозненных сервисов, таких как last.fm, вконтакте, ex.fm, hypem.com, soundcloud.com, discogs.com, youtube.com

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

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

Статья не претендует на подробный анализ потенциальных проблем, это просто рассказ из жизни одно реального Android приложения.

Сегодня я хочу поделиться с вами моим вольным переводом статьи, написанной Сергеем Повзнером (Sergey Povzner). Сергей ведёт блог bongizmo.com и занимается разработкой туристических гидов под общим названием Citybot.

В то время как Android продолжает свой невероятный рост, всё больше и больше программистов начинают разрабатывать приложения на этой платформе. Если ты начинаешь свой путь сегодня, то ты определенно — счастливчик. За последние годы Android значительно повзрослел и избавился от множества детских болезней. Информации по платформе более чем достаточно. Я же расскажу о самых важных ресурсах.

Статья будет полезна как новичкам, так и опытным разработчикам. Это гид по миру Android-разработки.

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

Спустя время я выделил несколько неочевидных вещей, на которые старался обращать внимание, и в большинстве случаев находил ошибки. Получился небольшой чеклист. Очень полезный как для самопроверки, так и для проверки чужого дизайна. Им с вами и спешу поделиться: