Это первый пост в блоге проекта Флоксим — российской open-source CMS, которую разрабатывает наша команда. Совсем скоро мы откроем бета-версию и расскажем о том, зачем миру нужна новая CMS, что мы можем предложить пользователям и разработчикам и какие у нас планы. А в этой статье я расскажу о нашем подходе к управлению контентом и постараюсь доказать, что это действительно важно.

Если вам когда-нибудь случалось перехватывать iPad из одной руки в другую, чтобы нажать кнопку в приложении, вы уже знаете, зачем мы затеяли исследование в нашей usability-лаборатории. Мы решили проанализировать интерфейс iPad-приложения с точки зрения физиологии. Насколько удобно юзерам пользоваться iPad в типичных позах — нажимать кнопки лежа, листать фото сидя, свайпать, набирать текст? В результате мы обнаружили целый ряд проблем чисто физиологического характера.

Хотя армия владельцев iPad насчитывает, например, 4 миллиона в России и 80 миллионов в США, нам не удалось найти упоминаний о подобных исследованиях. Видимо, раньше о физиологии при разработке приложений для iPad никто не задумывался — хотя для смартфонов такие исследования проводили.

Мы анализировали действия пользователей на примере приложения Почты Mail.Ru, однако наши находки можно и нужно использовать при проектировании любых iPad-приложений. Подробно о том, что мы обнаружили (с картами «мертвых зон» и рекомендациями), — ­ под катом.

Сегодня компания Appodeal представляет интервью с разработчиками, которые расскажут о своем опыте монетизации приложений. Соответственно, интервью разделено на три части, каждая из которых – это отдельный диалог. У всех – разные приложения, разное количество пользователей и различные доходы. Объединяет разработчиков одно – все они решили использовать наш сервис. Разговор поможет многим, особенно еще не вовлеченным в создание приложений, оглянуться по сторонам и посмотреть на чужой опыт.

Интервью построено в таком формате: «Q» – это вопросы основного интервьюера, а «I» – ответы собеседников. Надеемся, что этот материал пригодится нашим читателям в ежедневной работе.

Один технический специалист нашей компании PayOnline, которая занимается автоматизацией приема платежей, предложил перевести статью автора Pascal de Vink, который проработал тим-лидом уже 2 года. Когда Pascal только занял эту должность, оказалось, что ко многим вещам он был просто не готов. Эта статья поможет избежать многих ошибок на пути от разработчика к лидеру команды. Ниже идет непосредственно перевод.

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

Меньше заниматься разработкой

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

Как-то раз возник у меня диспут с хабраюзером ZimM по поводу безшейдерного 2D движка: я утверждал, что для простых 2D игр шейдеры не обязательны, почти все эффекты можно сделать спрайтами, его же позиция была обратной. Я не раз в уме возвращался к этому спору и придумывал задачи, не реализуемые на первый взгляд без шейдеров, и именно решение одной такой задачи и привело к созданию игры, где игрок управляет жидкостью наклоном телефона.

Введение в проблему

Здравствуйте, дорогие читатели!

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

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

Но пришла эра развлечений – я не буду упоминать с каким трудом делались первые игры, но прошли десятилетия, стали появляться платные игровые движки, через какое-то время они стали практически бесплатные (Unity, Unreal Engine4), причем не движки от Васи с соседнего подъезда в которых можно только сделать “грабеж корованов ”, а движки мастодонты который представляют из себя комплексные среды разработки, способные реализовать ваши проекты мечты. Однако есть и обратная сторона этих популярных технологий. А именно большое количество некачественных продуктов. Обленились придумывать что-то свое… “Лучше сделаю флеппи берд!” – подумал Вася.

В июле 2008 года корпорация Apple анонсировала появление Apple App Store — каталога приложений для iOS. Несколько позже появился и Google Play. Изначально в каталогах было минимум программ, но спустя некоторое время количество приложений увеличилось до сотен тысяч. Теперь в App Store около полутора миллионов программ, а в Google Play и того больше — около миллиона шестисот тысяч (1,6 млн).

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

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

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


Рис. 1 Бинарное дерево

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

Они не просто не используют вашу программу, нет, они ее удаляют! Но почему? Вы запускаете приложение и начинаете его тестировать, изучать снова и снова, выискивая возможную проблему. Но все работает отлично, явных причин нет. В чем же дело? Давайте попробуем разобраться.

Если вы регулярно используете Git, то вам могут быть полезны практические советы из этой статьи. Если вы в этом пока новичок, то для начала вам лучше ознакомиться с Git Cheat Sheet. Скажем так, данная статья предназначена для тех, у кого есть опыт использования Git от трёх месяцев. Осторожно: траффик, большие картинки!

Содержание:

1. Параметры для удобного просмотра лога
2. Вывод актуальных изменений в файл
3. Просмотр изменений в определённых строках файла
4. Просмотр ещё не влитых в родительскую ветку изменений
5. Извлечение файла из другой ветки
6. Пара слов о ребейзе
7. Сохранение структуры ветки после локального мержа
8. Исправление последнего коммита вместо создания нового
9. Три состояния в Git и переключение между ними
10. Мягкая отмена коммитов
11. Просмотр диффов для всего проекта (а не по одному файлу за раз) с помощью сторонних инструментов
12. Игнорирование пробелов
13. Добавление определённых изменений из файла
14. Поиск и удаление старых веток
15. Откладывание изменений определённых файлов
16. Хорошие примечания к коммиту
17. Автодополнения команд Git
18. Создание алиасов для часто используемых команд
19. Быстрый поиск плохого коммита

Я хочу поделится с вами моим опытом создания первой игры.

Предыстория

Так вышло, что я всегда хотел делать игры, но долго не мог выбрать идею и приступить к созданию. И после получения определенного опыта использования движка Unity, я решил, что настало время заняться своей игрой. Мне хотелось чего-то простого в плане разработки, но интересного с точки зрения геймплея. И уже тогда в моей голове начала зарождаться идея Layer Switch.

Это вторая статья цикла, посвященного разработке, управляемой моделями. Сегодня мы создадим метамодель, основанную на метаметамодели Ecore. Вскользь затронем моделирование данных, а именно Anchor, 6НФ и концептуальное моделирование.

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

Так же существует следующий уровень «безмышечного» опыта, когда вы стараетесь избежать труднодоступных клавиш, например Delete, Backspace, Escape или даже Enter.

Если вы держите руки в стандартной позиции для 10-пальцевой слепой печати, более удобно нажать Ctrl-m вместо того, чтобы тянуться мизинцем к энтеру.

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

Разработчики внутренней практики DataArt «Путешествия и гостиничный бизнес» представляют систему внутреннего позиционирования и рассказывают, чем она интересна для индустрии.

Что такое система позиционирования во внутренних помещениях?

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

Что на самом деле привлекает пользователей?

Развитие мобильного рынка идет полным ходом. В условиях постоянно нарастающей конкуренции привлечь пользователя становится все сложнее и сложнее. Исследователь из Venture Beat Джон Коэцер (John Koetsier) представил отчет, в котором составлен рейтинг каналов привлечения пользователей.

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

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

Когда речь идёт о программном обеспечении, термин «взлом» зачастую ассоциируют с пиратством и нарушением авторских прав. Данная статья не об этом; напротив, я решительно не одобряю любые действия, которые прямо или косвенно могут навредить другим разработчикам. Тем не менее, эта статья всё же является практическим руководством по взлому. Используя инструменты и методы о которых далее пойдёт речь, вы сможете проверить защиту собственной Unity игры и узнаете, как обезопасить её от взлома и кражи ресурсов.

Приветствую, коллеги. За последние несколько лет Stack Overflow стал полезнейшим инструментом для разработчиков. Множество вопросов, заданных Гуглу и Яндексу, в первых же ссылках ведут на понятные и исчерпывающие ответы на этом ресурсе. Большинство разработчиков используют сайт Stack Overflow именно как базу знаний программистов, возможность быстро получить нужный ответ. Под катом я расскажу про несколько интересных кейсов подводной части айсберга: спрятанные ответы, награды, прокачивание кармы и многое другое, скрытое от поверхностного взгляда.

Наверняка многим разработчикам, чьи приложения давно не попадали на высокие места в рейтингах App Store, будет интересно узнать, сколько же загрузок нужно получить, чтобы туда попасть. Постараюсь ответить на этот вопрос в меру своих возможностей. Недавно мне удалось продвинуть свою игру в ТОП-10 бесплатных игр российского App Store, и я хочу рассказать о том, сколько же инсталлов для этого понадобилось.

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



Как видно из скриншота выше, за первые 3 дня игра была получила 11000 инсталлов, но 6,5 тысяч из них пришлись на 3-й день. При этом игра попала на 7-е место в рейтинге бесплатных игр на iPhone в 17:00 1 августа. После этого никакого пиара уже не было, а учитывая, что приведенная статистика загрузок считается по тихоокеанскому времени, то как минимум половину, а скорее всего даже больше загрузок можно считать органическими. Также стоит учесть, что для 7-го места нужно больше инсталлов, чем для 10-го. С учетом всего этого можно сделать вывод, что в начале августа для ТОП-10 бесплатных игр нужно было порядка 6-7 тысяч загрузок за 3 дня.

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