День добрый, уважаемые хабражители.
Писать игры хотел ещё с того момента, когда только начал программировать. И вот, решил всё-таки попробовать себя в написании игр на Android.
Игру осенью сделал ещё и выложил в маркет. Правда её удалили, так как права на Bomberman'а у Konami. Но статья, естественно, не об этом.

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

Почитать описание других паттернов.

GRASP (General Responsibility Assignment Software Patterns) — шаблоны проектирования, используемые для решения общих задач по назначению обязанностей классам и объектам.

Известно девять GRAPS шаблонов, изначально описанных в книге Крейга Лармана «Применение UML и шаблонов проектирования». В отличие от привычных читателю паттернов из Банды Четырех, GRAPS паттерны не имеют выраженной структуры, четкой области применения и конкретной решаемой проблемы, а лишь представляют собой обобщенные подходы/рекомендации/принципы, используемые при проектировании дизайна системы.

Рассмотрим характеристики основных GRASP шаблонов.

Дисклеймер: у меня за спиной более десяти лет разработки на PHP. Я начал использовать его, когда PHP4 был совсем малышом, а PHP5 — только мечтой компании Zend. С помощью него я сделал многое, я любил его, проклинал и не без стыда наблюдал за тем, как он растёт и развивается. Я всё ещё использую его в некоторых доставшихся по наследству проектах, но предпочитаю больше его не применять. Также хочу отметить, что я не сотрудничаю с создателями фреймворков или инструментов, упомянутых в статье.

TL;DR (англ. too long; didn't read. Так, в частности, говорят, когда лень читать статью целиком — прим. пер.): если ваш проект основан на функциях фоновых процессов (фоновых служб, демонов — прим. пер.), избегайте PHP.

По-моему, в большинстве случаев ненавистники PHP упускают один весьма важный момент: PHP создан, чтобы умирать. Это не значит, что довольно способный (в какой-то степени) язык программирования исчезнет в никуда; это всего лишь означает, что ваш PHP код не может выполняться вечно. В настоящее время, спустя 13 лет после первого официального релиза в 2000 году, эта мысль до сих пор кажется мне вполне обоснованной.

Недавнее исследование показало то, что и так не является секретом для большинства разработчиков: написание кода занимает лишь часть рабочего времени.
Например, помимо разработки, они пьют кофе :)

Недавнее исследование на тему того, как разработчики тратят свое рабочее время, показало, что программисты проводят большую часть времени НЕ занимаясь написанием кода. Компания Eric Cloud опросила 443 разработчика ПО и выяснила, что в среднем, они расходуют менее половины рабочего времени на «разработку и кодирование». Большая же часть времени расходуется на такие вещи, как: брейнcторминг, административные задачи, управление окружением и тестирование.

Ко мне обратился один руководитель стартапа социальной игры с просьбой увеличить производительность своего проекта. На этом этапе был сделан и запущен прототип проекта. И надо отдать должное разработчикам, что проект работал и даже приносил какую-то прибыль. Но, запускать рекламную компанию не имело смысло, так как проект не выдерживал ни каких нагрузок. Валился MySQL (35% ошибок).

Код проекта… В общем у меня осталось впечатление, что писал его недоученный студент… И это, немотря на то, что уже был сделан частичный рефакторинг другим программистом. Единственное, что радовало, то это то, что не использовался какой-либо фреймворк. Конечно, это вечно флеймовый вопрос: Иисус или Магомед? Быть или не Быть? Unix или Windows? Использовать или не Использовать? ИМХО, Моё мнение: фреймворки заточены под узкий круг типовых задач. Социальный проект — задача, как правило, не типовая… Но, в целом, мне проект показался интересным и я решил взяться за улучшение. На этом вступление можно закончить…

Наверно, про повышение производительности и тему highload не писал только ленивый WEB разработчик, знающий хоть что-то в этой области. Принципиально, что-то нового, в данной статье вы не найдёте. Основные идеи разработки highload проектов, были мною изложены в цикле статей HighLoad. Три кита.. Если вам интересно, как я увеличил производительность PHP проекта, используя NoSQL хранилище tarantool, то Добро пожаловать под кат.

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

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

Здравствуйте, уважаемые хабрачитатели. В этой статье я хотел бы поделиться знаниями об одном небольшом и простом, но полезном шаблоне, про который обычно не пишут в книжках (возможно, потому, что он является частным случаем шаблона «Команда»). Это шаблон «Правила» (Rules Pattern). Вероятно, для многих он будет очень знакомым, но кому-то будет интересно с ним познакомиться.

В данном посте я хочу обратиться к теме, о которой многие начинающие iPhone-разработчики часто имеют смутное представление: Objective-C Runtime. Многие знают, что он существует, но каковы его возможности и как его использовать на практике?
Попробуем разобраться в базовых функциях этой библиотеки. Материал основан на лекциях, которые мы в Coalla используем для обучения сотрудников.

Это перевод новой статьи с TechCrunch от Джеймса Альтушера (James Altucher) — инвестора, программиста, автора статей и немного предпринимателя. Его последние книги: Я был слеп, но теперь я вижу и 40 альтернатив колледжу.

Несколько недель назад я опубликовал пост 10 причин, по которым вы бросите свою работу в 2013 году. Там я приводил некоторые доводы. И это не была статья в стиле «Эй, вы должны стать предпринимателем». Скорее рассказ был на тему: недобрая срань творится (bad shit is happening) в корпоративном мире и рано или поздно вам захочется его покинуть.

Конечно же, много людей задавали вопрос: Что дальше? Что мне делать?

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

Но каждый день выходят новые приложения с дизайном из iOS, темами из 2.3, не адаптированные для планшетов и с размытыми картинками на HD-экранах. И в этом виноват не Google, а разработчики. Кто-то не пытается спорить, когда заказчик присылает макеты от iOS версии, кто-то пытается, но сдается. Кто-то разрабатывает приложение ради опыта, откладывая «неважное» на потом, и так оно и остается. Стартапы делают приложения «за день», а потом лихорадочно фиксят баги, создавая снежный ком, который уже никто не перепишет с нуля. Крупные социальные сети, имея деньги и время, каким-то образом умудряются выпускать ужасные клиенты…

Здравствуй, хабр! Во второй части статьи я продолжу рассказ о том, как я писал клон игры Pacman. Первую часть можно почитать здесь.
С момента, когда я последний раз работал над пакманом прошло порядка трех недель. Прошла большая часть сессии, стало немного больше времени и я решил продолжить. В этот момент появилось желание доделать игру до состояния, когда ее можно будет выложить в Google Play Market, хотя в самом начале разработки я об этом даже не помышлял. Кроме того, доделывание до играбельного состояния – неплохая тренировка. Где-то я слышал, что игры (да и вообще приложения) стоит доделывать.
Напомню, что разработка игры велась с использованием Android NDK (С++) и OpenGL ES 2.0.

0. Вступление

Здравствуйте, дорогие читатели Хабра!
Этот топик является прямым продолжением предыдущих двух моих статей.

На дворе апрель, а я уже закончил свой первый курс бакалавриата в канадском университете University of British Columbia. Честно скажу, произошло огромное количество вещей: как хороших, так и не очень. Канада хоть и является для меня неким подобием «Параллельной вселенной», но и не обходится без специфических для нее минусов. Я расскажу про некоторые мелочи, трудности ежедневной рутины, курсы департамента Computer Science, жилье, отдых, работу, отношение канадцев друг к другу и еще про тонну интересностей!

Внимание! Под катом много картинок, фотографий, текста, впечатлений и, конечно же, мое субъективное мнение.

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


А ты записался добровольцем прошел собеседование?

Интервью состоит из трех частей, занимает 30-60 минут.
1. Рассказ программиста о себе.
2. Короткие вопросы на кругозор.
3. Решение задач

Рассказ программиста о себе.

В первую очередь прошу человек рассказать, как пришел к web-программированию. Когда начал, когда подсел на программирование :)
Очень спрашиваю про последнее место-два работы, что человек делал, за что отвечал, что в техническом и организационном плане там делал.

Нужно, чтобы человек расслабился.
Когда-то на этом этапе спрашивал про пять вариантов, почему люки круглые и прочие вопросы, но это давно отмерло, потому что не дает ничего :)

Как только становится понятно, что движет человеком и какой у него опыт, переходим к технической части.

Здравствуйте, уважаемые хабралюди!
Последние несколько месяцев, в свободное время, я занимался разработкой клона знаменитой игры Pacman для ОС Android. Как это было, и что из этого вышло я хочу рассказать.

Как-то раз передо мной встала задача сделать в приложении на Android поддержку тем оформления. Что хотелось получить:

1. Возможность переключить оформление — изменить некоторые цвета и графику
2. Смена должна происходить “на лету”, для пользователя должно измениться только оформление, все остальное (содержание полей ввода, позиция элементов в списке и т.п.) меняться не должно
3. В перспективе хотелось бы, чтобы тема могла изменяться и без участия пользователя, например по времени суток
4. Не хотелось бы в значительной степени изменять уже существующий код или разметку. В идеале хотелось бы просто как-то пометить элементы в разметке
5. Было бы здорово уметь подгружать новые темы без обновления приложения.

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

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

Как, узнали ситуацию?

Так вот — чушь всё это. Сфера ИТ — бесконечна, как вселенная, куча работы будет всегда. Можно или начать писать тесты прямо сейчас, или не сделать этого никогда. Я тут набросал короткий план, как начать это делать за 10 шагов, по шагу в день, по 10 минут на шаг. И когда я говорю «10 минут» я имею в виду не «3 с половиной часа» и не «ну сколько-то времени, лучше побольше», а именно 600 секунд. Если у вас нету в день 600 секунд свободного времени — срочно меняйте проект, работу, профессию, страну проживания (нужное подчеркнуть), потому что это не жизнь, а каторга какая-то. Поехали.

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

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

Сегодня обнаружил достойный внимания всех разработчиков, пишущих под iOS/Mac OS и использующих XCode, проект – менеджер плагинов для XCode. Имя этому проекту – Alcatraz. Увидев это чудо, я незамедлительно захотел его протестировать, благо установка выполняется тремя действиями:
1. Запустить терминал
2. Вставить следующий код в окно терминала:

mkdir -p ~/Library/Application\ Support/Developer/Shared/Xcode/Plug-ins;
curl -L http://goo.gl/xfmmt | tar xv -C ~/Library/Application\ Support/Developer/Shared/Xcode/Plug-ins -

3. Нажать Enter.

В 2010 году Apache Hadoop, MapReduce и ассоциированные с ними технологии привели к распространению нового явления в сфере информационных технологий, названного «большими данными» или «Big Data». Понимание того, что из себя представляет платформа Apache Hadoop, зачем она нужна и для чего её можно использовать потихоньку проникает в умы специалистов по всему миру. Зарожденный, как идея одного человека, и быстро выросший до промышленных масштабов, Apache Hadoop стал одной из самых широко обсуждаемых платформ для распределенных вычислений, а также платформой для хранения неструктурированной или слабо структурированной информации. В этой статье я хотел бы подробнее остановиться на самой платформе Apache Hadoop и рассмотреть коммерческие реализации, предоставляемые сторонними компаниями, и их отличия от свободно распространяемой версии Apache Hadoop.