Это перевод статьи из блога одного инди-разработчика, который уже несколько лет занимается созданием игр, набрался некоторого опыта, постиг разочарование, но продолжает свою работу. Полагаю, в основном его мнение об инди-разработке будет полезно только вставшим на этот путь людям. Итак, вот статья:

1. Никто ничего не знает

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

Примерно 30 процентов вашего времени будет потрачено собственно на создание игры. Остальное время вам потребуется тратить на другие дела. Вообще-то вам повезет, если вы будете тратить 4 месяца в году на, собственно, саму игру. Вы, наверное, не знаете многого о том как вести бизнес, о маркетинге и тому подобном, но вам придется этим заниматься. И, конечно, вы ничего не знаете о будущем, например, о том, какие платформы будут через 5 лет, как будут меняться технологии или аудитория.

Что же делать?

Ад визуализации 1.1:

• Книга 1: Обзор
• Книга 2: Проблемы
• Книга 3: Решения
• Книга 4: Заключение

Теперь самое интересное! Здесь я представлю вам некоторые решения, которые я нашел во время своего исследования. Надеюсь, они дадут вам общее представление о том, как оптимизировать игровые ресурсы с точки зрения процесса визуализации.

Среди задач мобильного разработчика, помимо самой частой (написания, собственно, приложений) периодически появляется и такая, как создание sdk.

Примерами такой задачи может быть создание sdk, использующего REST API какого-либо сервиса (реклама, аналитика, погода), библиотека реализаций алгоритмов, обработка изображений… Список практически неограничен.

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

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

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

Здравствуй, Хабр. И сразу к делу.
Задача:
Есть два целых числа: L и R. Нужно найти максимальное значение A xor B на промежутке [L; R], где L ≤ A ≤ B ≤ R.
Казалось бы ничего сложного. Сразу напрашивается решение простым перебором.
Сложность этого решения O(n²).
А что, если в интервале будет 1000000 чисел. Возьмем L = 1, а R = 1000001. Сколько времени понадобится cреднестатистическому компьютеру для того, чтобы посчитать максимальное значение xor на этом интервале? Моему ноутбуку потребовалось 1699914 миллисекунд.
Существует решение, которое работает значительно быстрее, именно о нем и пойдет речь в этой статье.

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

Директор департамента поддержки и развития мобильных приложений Redmadrobot Александр Алехин (@alekhinsasha) делится опытом организации процессов.


Здравствуйте!
Всего месяц назад в издательстве Addison-Wesley вышла книга Александра Степанова — русско-американского учёного в области IT — «From Mathematics to Generic Programming».



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

С тех пор как я начал свой челендж «одна игра в неделю» на lessmilk.com, я заметил, что самым распространенным вопросом, который я получал на свою почту был — «как Вы придумываете новые интересные идеи каждую неделю?». Поэтому я решил попробовать ответить здесь на этот вопрос.

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

Несмотря на то, что в Objective-C 2.0 присутствуют замыкания (известные как блоки), ранее эппловский API использовал их неохотно. Возможно, отчасти поэтому многие программисты под iOS с удовольствием эксплуатировали сторонние библиотеки, вроде AFNetworking, где блоки применяются повсеместно. С выходом Swift, а также добавлением новой функциональности в API, работать с замыканиями стало чрезвычайно удобно. Давайте рассмотрим, какими особенностями обладает их синтаксис в Swift, и какие трюки можно с ними «вытворять».



Продвигаться будем от простого к сложному, от скучного к веселому. Заранее приношу извинения за обильное использование мантр «функция», «параметр» и «Double», но из песни слов не выкинешь.

В Surfingbird мы используем пуш-уведомления, чтобы сообщать нашим пользователям срочные новости и просто информировать их об интересных материалах за день. Уже в первые недели тестов пуши показали свою огромную эффективность в плане увлечения ретеншена. Этому есть логичное объяснение – телефон у пользователя всегда с собой, в метро, в туалете, на совещаниях и т. д. Когда юзеру приходит пуш, все его внимание концентрируется на этом уведомлении.

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

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

В этой статье я расскажу о том, как мы автоматизируем тестирование наших приложений (ICQ и Агент Mail.Ru), поделюсь нашими наработками в этой области и упомяну о проблемах, с которыми мы сталкиваемся.

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

禁 — значит «запрещено»

Известно, что локализация интерфейса увеличивает популярность мобильного приложения в регионе и lifetime value пользователя. А перевод описания и ключевых слов на странице продукта в магазине позитивно влияет на количество загрузок и продаж приложения. Но насколько значимо это влияние?

Теперь мы знаем ответ: стоило нам перевести интерфейс и описание приложения “Домашняя Бухгалтерия” на испанский, французский и немецкий, как его позиции в топе Google Play Испании, Франции и Германии начали стремительно расти. Это был редкий случай, когда наш клиент не проводил параллельно никаких рекламных кампаний. Благодаря этому мы смогли увидеть, что рост позиций обусловлен только выходом локализованной версии приложения.

Цифры, подробности и предложение поучаствовать в крутом эксперименте — под катом.

Настал вторник, а значит мы выкладываем очередной доклад с конференции мобильных разработчиков #MBLTDev. Доклад посвящен фреймворку Core Data, работы с которым большинство iOS–разработчиков склоны избегать из-за его сложности.

Руслан Шевчук, iOS–разработчик компании Aviasales, не побоялся разобраться с Core Data и на конференции представил доклад о том, как можно использовать его в iCloud.


Презентация

Руслан рассказал про задачи, которые Core Data решает в приложении Aviasales, его особенности, многопоточность, версионность, синхронизацию, проверку нарушения целостности связей, определение и удаление дубликатов, а также про преимущества Private Queue над Confinement Concurrency.

И снова привет, хабаровчане!

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

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

Разработка ПО – нелинейный процесс

Разработка программного обеспечения — нелинейный процесс. Если на проект выделено 5 разработчиков, которые за 5 месяцев должны разработать продукт (25 чел./мес.), то 25 разработчиков не смогут сделать эту же работу за 1 месяц (те же 25 чел./мес.).

Русский перевод очень полезной статьи Natasha Murashev The Many Faces of Swift Functions.

Хотя у Objective-C синтаксис выглядит несколько странно, по сравнению с другими языками программирования, синтаксис метода — прост и понятен. Вот небольшой экскурс в прошлое:

+ (void)mySimpleMethod
{
    // метод "класса"
    // нет параметров
    // нет возвращаемых значений
}

- (NSString *)myMethodNameWithParameter1:(NSString *)param1 parameter2:(NSNumber *)param2
{
    // метод "экземпляра"
    // первый параметр - типа NSString указатель, 
    // второй параметр  - типа NSNumber указатель
    // должен вернуть значение типа NSString указатель
    return @"hello, world!";
}

В противоположность этому, синтаксис Swift выглядит в большинстве случаев также, как и в других языках программирования, но временами он может быть более сложным и запутанным, чем в Objective-C.

Прежде чем я продолжу, я хочу прояснить разницу между «методами» и «функциями» в Swift, так как я повсеместно буду использовать оба этих термина в этой статье. Вот определение «методов», данное в книге Apple «Swift Programming Language»:

Если издали видно общую картину, то вблизи можно понять суть. Концепции, которые казались мне далекими и, прямо скажем, странными во время экспериментов с Haskell и Scala, при программировании на Swift становятся ослепительно очевидными решениями для широкого спектра проблем.

Взять вот обработку ошибок. Конкретный пример – деление двух чисел, которое должно вызвать исключение если делитель равен нулю. В Objective C я бы решил проблему так:

NSError *err = nil;
CGFloat result = [NMArithmetic divide:2.5 by:3.0 error:&err];
if (err) {
    NSLog(@"%@", err)
} else {
    [NMArithmetic doSomethingWithResult:result]
}

Со временем это стало казаться самым привычным способом написания кода. Я не замечаю, какие загогулины приходится писать и как косвенно они связаны с тем, что я на самом деле хочу от программы:

Верни мне значение. Если не получится – то дай знать, чтобы ошибку можно было обработать.

Я передаю параметры, разыменовываю указатели, возвращаю значение в любом случае и в некоторых случаях потом игнорирую. Это неорганизованный код по следующим причинам:

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

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

Мне не нравится как организуется Черная Пятница в России.
В то время, как в США продают за бесценок массу интересных устройств, наши ритейлеры делают скидки на никому не нужные товары (вроде флешек), либо занимаются фиктивными распродажами (завышают цены до акции и делают незначительную скидку до обычной цены). К счастью, мы в силах сделать по-другому и показать другим ритейлерам как можно работать.

Каждый третий заказчик, приходящий к нам в Alconost за локализацией, задает один и тот же вопрос: “а на какие еще языки посоветуете сделать перевод моей игры/приложения/сайта?”.

Чтобы ответить на этот вопрос хотя бы для разработчиков мобильных игр, мы изучили объемы продаж мобильных игр в Google Play и App Store в разных странах. Результат нас так удивил, что вместо обычной статьи мы захотели сделать видеоролик:



Чуть больше информации про топ-10 языков для локализации мобильных игр — под катом.

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

Итак, когда я только начинал заниматься тестированием, прочитал доступную теорию, начальник начал второе собеседование с простого вопроса – в чём особенность мобильного тестирования по отношению к другим видам тестирования? Тогда я лишь приблизительно смог ответить на этот вопрос. Сейчас я выделяю для себя следующие принципы: