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

Наступил обеденный перерыв. Вы идете в ближайший ресторан и заказываете себе бизнес-ланч: салат, суп, горячее и обязательно компот. Возвращаетесь на работу, заканчиваете рабочий день и идёте в спортзал, у вас, разумеется, годовой абонемент, он ведь выгоднее, чем месячный. Оптом всегда дешевле. В данной статье мы хотим рассказать о том, как мы применяем механику комплектов (бандлов) в игре “Танки Онлайн”: на какие KPI ориентируемся, какими принципами руководствуемся и с какими трудностями столкнулись.

Бандлы — очень удачная вещь с любой точки зрения. Помню, на своем первом месте работы я предпочитал обед всегда брать с собой. Так выгоднее, да еще и мамина кухня — самая вкусная и здоровая на свете. Ситуация изменилась, когда коллеги предложили мне сходить на бизнес-ланч. За двести рублей я вволю наедался небольшими порциями разных блюд. Вскоре отказался от маминой кухни и стал питаться только бизнес-ланчами. “Так выгоднее”, — вновь заключил я. Говоря языком геймдева, я конвертнулся в донатора. Первое преимущество бандлов — повышение конвертации в платящего пользователя. Несколько лет спустя моей первой покупкой в Steam тоже стал бандл.



Кстати о Steam. Вы ведь наверняка когда-либо покупали бандлы в Steam?

Не мог пройти мимо топика "Вопросы на собеседование middle/senior iOS Developer" и статьи "Собеседование разработчика". Хочу предложить альтернативный или дополнительный подход к собеседованию разработчиков.

Разбор говнокода или сотня разношерстных вопросов на листочке — это, конечно, прекрасно, но если это единственный этап собеседования, то это вызывает желание спросить что-то вроде: «Вы серьезно?»

Вы не устали от того, что на собеседованиях на конкретную позицию разработчика вас спрашивают достаточно сильно оторванную от жизни фигню, которую хочется поскорее забыть после такого собеседования (режим nightmare — это тест на 150+ вопросов и психолог в конце)? Я не отрицаю, что оценивать качество кода — это очень важно, но оценивать качество какого-то конкретного куска и делать по нему большие выводы — это точно неправильно.

К тому же, слишком много так называемых разработчиков не имеют никакого понятия о том, как строить архитектуру приложения, как грамотно разделить компоненты на модули, как внести гибкость для последующих изменений проекта. А вопросы подобные вопросам из топика "Вопросы на собеседование middle/senior iOS Developer" не дадут вам понять, насколько человек хорошо применяет свои знания при реализации проекта.

Что ты предлагаешь, чувак?

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

Что я предлагаю: берем популярное, большое (в плане функционала) и сложное (в плане реализации) приложение и беседуем насчет того, как кандидат бы его сделал!

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

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

Для примера, возьмем приложение Вконтакте для android (оно большое, сложное и многим знакомое).

Все мы ходили/ходим на собеседования. Каждый раз при подготовке к очередному собеседованию просматриваем основные темы, вспоминаем вопросы, которые нам задавали в предыдущие разы, или вопросы, которые сами задавали. Ниже хочу представить основные вопросы, которые часто (основано на личном опыте) можно получить на собеседовании на должность middle/senior iOS Developer. Так сказать, шпаргалка. Заодно можно проверить свой уровень знания платформы.

Если не знаешь, надо не бояться, а узнавать.
Айн Рэнд “Атлант расправил плечи”



Добрый день, меня зовут Игорь Томич и я лектор курсов iOS-разработки и сооснователь онлайн курсов Master Up. Это мой первый пост в наш корпоративный блог, в котором я решил поделиться советами для начинающих iOS-разработчиков. Свое первое приложение для iOS я начал писать в начале 2009 года, а в мае 2012 году провел первый курс обучения по рарзработке под эту же платформу и к этому времени у меня скопилось достаточно “часто повторяемых ошибок” и путей их решения.

Современный мир не перестает радовать нас достижениями технологий, кому как не хабражителям это известно. Я до сих пор отношу всякие шлемы виртуальной реальности к чему-то скорее научно-фантастическому, нежели реальному, несмотря на то, что они уже вполне существуют (достаточно поискать по хабру Oculus Rift). Помимо, если так можно выразится, “чистой” виртуальной реальности все более интересными кажутся проекты по дополнению реальности нашей (Augmented Reality). Нашумевший на Kickstarter проект castAR тому живое доказательство, да и Google Glass хоть и не совсем то, но вполне умещается в термин augmentation.

Одно только НО, Oculus Rift – на сегодня это версия для разработчиков, castAR – вообще только концепт, ну а Google Glass достался только счастливчикам и возможности его сильно ограничены. В общем об охвате широкой аудитории пока говорить не приходится. Зато смартфоны всех сортов поселились в нашей жизни уже повсеместно. Они все замечательные, имеют камеру и достаточно умны, чтобы стать тем самым окошком в реальность дополненную.

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

Для всех, кому прохладного дождя за окном в эти дни мало, Marek Brodziak сделал забавное демо на js + canvas (демо #1, демо #2 — и сразу предупреждаю, что заработать может не во всех браузерах), которое имитирует капли дождя на стекле. Своей целью разработчик ставил добиться лучшей плавности анимации капель.

Для достижения наилучшего эффекта погружения смотреть демо рекомендуется предварительно открыв в соседней вкладке raining.fm.

Продолжение истории Скотта Миллера и компании Apogee (3D Realms), начало здесь.

Ключевая идея

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

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

«Как жаль, что у меня не сохранились эти письма… Сейчас они, наверное, стоят целое состояние!» — шутит сегодня Миллер.

В конце 1980-ых в Техасе молодой человек двадцати с небольшим лет от роду по имени Скотт Миллер создал бизнес-модель, которая изменила способ покупки и продажи цифровых продуктов по всему миру. Сам Миллер называл свой шедевр «Apogee model» — «моделью апогея», всем остальным же она сегодня известна под названием «shareware», или «условно-бесплатное ПО». Эта модель сделала цифровые продажи через интернет колоссально прибыльными, а самого Миллера — миллионером. Модели и ее автору предстояло произвести революцию относительно способа, которым используется интернет — причем еще до того, как большая часть мира узнала об его существовании.

Нерды на полную ставку

В юности Скотт Миллер был лентяем.

В старших классах школы в начале 1980-ых он, замкнутый подросток, спасался от жаркого солнца Техаса, скрываясь в кампусе компьютерной лаборатории, проводя все свое время за программированием длинных текстовых квестов-приключений. Здесь он повстречал Джорджа Бруссарда — другого подростка, который на тот момент выделялся лишь своей любовью к постоянному ношению шортов. Как часто случалось в то время, ребят сплотило между собой дружное восхищение местным компьютером Apple II.

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

Для нашего проекта, как учетной системы, характерно производить изменения в других объектах после сохранения текущего, например, проведение документа по регистрам после сохранения. Суть в том, что после сохранения объекта в транзакции ActiveRecord будет считать, что все изменения прошли успешно, хотя это не гарантировано, ведь последующие изменения могут вызвать Exception, а он в свою очередь к откату транзакции. В нашем случае, это грозит тем, что при ошибочном создании записи, экземпляр ActiveRecord уже будет иметь статус существующей записи (флаг isNewRecord == false) или для новой записи уже будет присвоен primaryKey. Если вы при рендере опирались на эти атрибуты (как мы в нашем проекте), то в результате получите ошибочное представление.

На Хабре уже есть очень много интересных статей про создание игры с нуля, но мало статей, описывающих что делать, чтобы своя любимая поделка не превратилась во Франкенштейна и дошла до вменяемого состояния. Автор оригинальной статьи рассказывает, как эволюционировал код игрового движка от кучи хлама в основном цикле к продуманной, расширяемой архитектуре, использующей Entity Component System. В статье много кода, который почти весь часто повторяется — но я не стал его выбрасывать, поскольку с ним будет понятнее, какие изменения вносит автор и как это отражается на всей структуре. Статья рассчитана на новичков, вроде меня, которые уже настрочили несколько «гениальных» прототипов, но теперь не знают, как разобраться в их коде.

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

Вот тут-то и понеслось…

Apple Review Guidelines достаточно подробны, но приложения проверяют живые люди и часто трактуют правила по разному.

Предлагаю в комментариях рассказать о ваших реджектах приложений и как вы их решили.
Под катом несколько примеров.

Я хотел бы начать с истории:

Учитель керамического дела объявил в день открытия, что разобьет класс на две группы. «Те, кто сидят слева» — сказал он: «будут оцениваться только по количеству проделанной работы, те, кто справа — только по её качеству». Его методика была проста, в последний день он принесет весы и взвесит работу группы «количество»: 50 фунтов горшков это «5», сорок фунтов горшков это «4» и так далее. Те, кто оцениваются по «качеству», однако, должны сделать один, пусть и совершенный, горшок, чтобы получить «5». Время сдачи пришло, и обнаружился любопытный факт: работы лучшего качества были сделаны в группе, оцениваемой по количеству. Похоже, в то время, как группа «количество» упорно штамповала свои работы и училась на своих ошибках, группа «качество» теоретизировали об идеале и, в конце концов, только и могла показать свои старания и грандиозные теории об идеале, а также кучу бесполезной глины.

Вместо предисловия

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

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

Привет, Хабр!
Аккурат к инициативе поддержки стартапов, озвученной deniskin, мы в ФРИИ продолжаем знакомить сообщество с темой бизнес-инкубаторов и акселераторов. В прошлой статье мы детально разобрали, в чём различие между бизнес-инкубаторами и акселераторами. Сегодня — расскажем о том, куда же, собственно, идти.

Нас взломали! Нас взломали!

— не отличалась оригинальностью моя реакция на взлом In-App Purchase моего приложения “Hideninja VPN” под Android. Но об этом я написал только в предпоследнем абзаце. А до него есть еще несколько строк о том, что за проект такой этот «Hideninja VPN». Также я расскажу о том, как был пройден путь от первого прототипа, как проект вышел в top-5 по запросу “vpn” англоязычного Google Play, как редизайн повлиял на восприятие приложения пользователями, сбор граблей и, наконец, про взлом In-App Purchase. Конечно, я разделил этот материал на несколько частей, иначе читать его было бы абсолютно утомительно. Итак, Часть 1.



Вот она, взломанная “Версия 3.3 PRO”.

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

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



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

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