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

За последнее время появилось много инструментов для издателей и рекламодателей, которые позволяют эффективно управлять множеством параметров таргетинга рекламных кампаний, что за частую является ключевым фактором, гарантирующим ожидаемый результат. А вот для площадок по-прежнему всё очень грустно.

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

Долгое время я изучал паттерн MVC. Больше полутора лет прошло с тех пор, как я впервые с ним познакомился и в течение всего этого времени я никак не мог упорядочить в своей голове зоны ответственности трех составляющих паттерн компонентов.

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

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

Я решил собрать всю недостающую информацию в одном месте. Это и стало причиной для написания статьи.

tl;dr: читаем итог. Остальных прошу устроиться поудобнее.

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

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

Как-то раз я спросил у своей жены:
— У нас же нет планов на выходные?
— Вроде нет, — ответила она.
— Тогда я еще разок поковыряю этот Swift.
— Поковыряй.

И вот я поставил перед собой задачу, написать очень простую игрушку для iOS на Swift'е, не прибегая к какому-либо ^.*C.*$ (прошлый мой опыт ознакомления со Swift'ом закончился тем, что 80% проекта были написаны на Objective-C (который из-за моего С++'ного мышления, сократился до ближайшего известного мне (Objective-C)+2C-Objective = C)).

Задача

Дано: Одна картинка, какие-то соображения в голове.
Надо: Игра написанная до звонка будильника в понедельник.

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

Чтобы направить всю энергию системы в необходимом направлении, нужно эту систему ограничить правилами.

Привет, Хабр! Продолжаем серию статей об архитектурном дизайне мобильных приложений. Под катом поговорим о проектировании слоёв UI. Добро пожаловать!

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

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

• С чего начать обучение программированию?
• У вас есть курс по Java для новичков, но я слышал, что нужно изучать Python, правда ли это?
• На других сайтах все просто и понятно, а у вас какие-то компиляции и тесты!
• Непонятно зачем нужен этот ваш курс по алгоритмам, в реальной жизни все алгоритмы уже реализованы в стандартных библиотеках

Но сложнее всего объяснить новичку, грубо говоря, во что он ввязывается. Благодаря очень простым, игровым образовательным проектам многие считают, что программирование это очень легко, а наши виртуальные машины, где нужно запускать тесты и компилировать код – это надуманная сложность. Давно хотелось найти такой материал, который бы подготовил новичка к длинному и сложному пути к карьере программиста. И недавно наши коллеги из Viking Code School такой материал написали! А мы его перевели для вас.



Квинси Ларсон был просто “офисным парнем в костюме”. Он решил научиться программировать. Начал спрашивать людей вокруг. Изучил немного Руби, потом быстренько посмотрел на другие языки вроде Scala, Clojure и Go. Он изучил Emacs, а потом Vim, а потом раскладку Dvorak. Он втыкал в Линукс, копался с Лиспом и кодил на Питоне, и жил при этом в командной строке больше полутора лет.

Его швыряло туда-сюда как листочек в торнадо. Каждый совет, который он слышал, тащил его то в одну, то в другую сторону, до тех пор пока он не прошел “каждый онлайн-курс по программированию во вселенной”. В конце концов, не смотря на то, что он получил работу разработчика ПО, Квинси:

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

Ох. Звучит знакомо?

Предлагаю читателям «Хабрахабра» перевод статьи «16 Months of Functional Programming». Все мои замечания будут выделены курсивом.

В этой статье я хочу поделиться с вами моим опытом в функциональном программировании. Я чувствую, что в целом за прошедшие 16 месяцев стал лучше разбираться в информатике и компьютерах, чем за предыдущие 10 лет и всё это благодаря моему погружению в Scala и мир функционального программирования. Причина по которой функциональное программирование побуждает вас к постоянному развитию заключается в том, что каждую задачу необходимо переосмысливать заново. Порой невозможно поверить в то, что большинство стандартных задач могут быть решены иным путём и — бум! — функциональный подход предлагает лучшее решение и это шокирует.

Здравствуйте!

Издательство «Питер» рассматривает возможность выпустить книгу по системе управления версиями Git.

Хотим посоветоваться с будущими читателями: какое издание вам будет наиболее интересно в русском переводе?
Мы сразу исключили книги ознакомительного уровня и выбрали три кандидатуры:

1. Новое издание (декабря 2014) книги Скотта Шакона



(Хотим сразу предупредить, что данная книга получится самой дорогой — розничная цена может достигать 1500 руб. Необходимо учесть это при принятии решения).

2. Классику от O'Reilly



3. Более краткое, но не сильно уступающее в информативности издание от Manning



Просьба голосовать:

Я уже делился советами по разработке кастомной клавиатуры, а также опытом продвижения приложения до и сразу после релиза — статья. На этот раз хочу рассказать о процессе разработки и дать пару подсказок о том, что делать после загрузки приложения в App Store.

При первом знакомстве с Objective C он произвёл на меня впечатление уродливого и нелогичного языка. На тот момент я уже имел достаточно сильную базу в C/C++ и ассемблере x86, а так же был знаком с другими высокоуровневыми языками. В документации писалось, что Objective C это расширение языка C. Но, как бы я ни старался, мне всё же не удавалось применить свой опыт в разработке приложений для iOS.

Сегодня он всё так же кажется мне уродливым. Но однажды окунувшись в глубины Objective-C Runtime я влюбился в него. Изучение Objective-C Runtime позволило мне найти те тонкие ниточки, которые связывают Objective C с его «отцом» — великолепным и непревзойдённым языком C. Это тот самый случай, когда любовь превращает недостатки в достоинства.

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

Раньше я работал над созданием мобильных игр как гейм-дизайнер или продюсер, но сам еще никогда профессионально не писал код. Несколько месяцев назад мне захотелось это исправить и сделать игру своими руками. Так, спустя два месяца работы, силами трех человек в App Store и Google Play появились «Котики». В своей истории я хочу поделиться приобретенным опытом и рассказать о средствах разработки, которые позволили нам быстро сделать эту игру.

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

Наименование: Dead End (тупик)
Другое наименование: Kevorkian Component (мертвый компонент)

Суть проблемы

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

Вступление

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

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

Система оценки: сервисы оцениваются по 10-балльной шкале по каждому из разделов (Регистрация и интеграция, Основной функционал, Дополнительный функционал, Continuous Integration). Суммарная оценка позволит определить победителя (итоговое заключение войдет в последнюю часть обзора).

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

Хорошо Декарту, или, тем более, всяким древнегреческим математикам, доказывать простенькие теоремки и вписывать свое имя в историю. Сейчас далеко не каждый (да что там, единицы на тысячи человек) физически способны добраться до переднего края науки, не выбросившись из окна главного корпуса МГУ по пути.

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

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

Короче, слишком сложно нынче пробиться. Очень высокая конкуренция, куда ни плюнь.

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

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

Исследование, проведенное Software Engineering Institute, показывает, что программисты делают 15-20 распространенных ошибок. Добавив такие ошибки в чеклист, вы можете быть уверены, что заметите их в момент появления и поможете от них избавиться надолго.

Чтобы вам было от чего отталкиваться, вот вам список типичных пунктов:

Я знал теорию. Ревью кода помогает:

• Находить баги
• Обеспечивать читаемость и поддерживаемость кода
• Распространять знания кода на всю команду
• Быстрее входить в работу новым членам команды
• Показывать всем новые подходы к решению задач

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

Сегодня мы продолжаем цикл публикаций лекций Технопарка (кстати, недавно проекту исполнилось 3 года). В этой лекции Кирилл Маркин, студент МГТУ им. Баумана, поделится своим опытом по созданию небольшой компании «Диафентис», которая занимается внедрением различных программных комплексов. Конспект лекции смотрите под катом.



Подписывайтесь на наш youtube-канал, там будет еще много интересного!

До сотни осталось всего десять выпусков и мы продолжаем обсуждать работу Яндекс.Метро, разрабатываем на SpriteKit и HomeKit, смотрим как кодят люди, ищем лучшее применение iBeacon. Все это и много другого в еженедельном дайджесте!

Ваши программы – это ваше наследие. Решайте сами, как долго оно будет существовать.

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

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

Что можно получить, выдавая хороший код? Разве не имеет права на жизнь подход в обучении под названием «двигайся быстрее, ломая всё на своём пути?» Нет. Обучиться писать код – это навык, это доступно каждому. Обучиться писать хороший код – это искусство. Это требует усилий, времени и целеустремлённости.

Все началось с того, что я огляделся по сторонам и, не увидев автомобиля своей мечты, решил сконструировать его сам
Фердинанд Порше

Привет, Хабр. Хочу рассказать, как создал свое первое iOS приложение и что из этого получилось.