Статья будет о создании второй по счету моей игры под Android, на кроссплатформенном движке Cocos2D-x (v3.1). Код преимущественно на С++, местами Java и Lua. Попытаюсь вкратце рассказать про основные моменты разработки.

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

Собственно с задачей прямого и обратного преобразования JSON из текстового представления в объектную модель отлично справляется стандартный Foundation API – NSJSONSerialization. В Apple проделали серьезную работу для обеспечения прямого и обратного взаимодействия Swift и Objective-C кода (Using Swift with Cocoa and Objective-C), поэтому использование привычных Cocoa API не только возможно на практике, но и удобно и не выглядит неестественно:

let jsonString = "{\"name\":\"John\",\"age\":32,\"phoneNumbers\":[{\"type\":\"home\",\"number\":\"212 555-1234\"}]}"
let jsonData = jsonString.dataUsingEncoding(NSUTF8StringEncoding, allowLossyConversion: true)
let jsonObject: AnyObject! = NSJSONSerialization.JSONObjectWithData(jsonData, options: NSJSONReadingOptions(0), error: nil)

Но работать с полученным результатом в статически типизированном Swift неудобно – требуется цепочка проверок и приведений типов для получения любого значения. Далее я рассмотрю варианты решения этой проблемы, а заодно мы познакомимся с некоторыми особенностями Swift.

Возьмём за основу статью Знакомьтесь, Swift!, где показано как сделать простое приложение на Swift, и добавим туда такие известные и полезные штуки как pull to refresh и infinite scrolling используя встроенные возможности языка. Чтобы было еще интереснее, добавим немного асинхронности, иначе приложение будет каждый раз замирать на время обновления.

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

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

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

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

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

Сегодня мы проведем экскурс в историю развития Graphical User Interface (GUI) в игре World of Tanks.

Игра прошла длинный путь к успеху, и ее GUI менялся и полностью переделывался несколько раз в погоне за повышающимися требованиями армии танкистов, которая неуклонно росла.

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

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

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

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

(lldb) po [[self view] recursiveDescription]
<UIView: 0x6a107c0; frame = (0 20; 320 460); autoresize = W+H; layer = […]
   | <UIRoundedRectButton: 0x6a103e0; frame = (124 196; 72 37); opaque = NO; […]
   |    | <UIButtonLabel: 0x6a117b0; frame = (19 8; 34 21); text = 'Test'; […]
   .....

Еще многие знают, что при помощи рантайма, можно получить список переменных/методов/свойств/протоколов/… класса. И обычно для этих целей пишут вспомогательный код. Но оказывается, все уже давно написано сотрудниками Apple. В UIKit.framework реализована категория с именем IvarDescription.

@interface NSObject (IvarDescription)
- (id)_shortMethodDescription;
- (id)_methodDescription;
- (id)__methodDescriptionForClass:(Class)arg1;
- (id)_ivarDescription;
- (id)__ivarDescriptionForClass:(Class)arg1;
@end

Названия метдов говорят за себя. Но давайте посмотрим, что же они возвращают.

Всем привет!
Полгода мы работали над новым изданием книги “ iOS 7 Programming Cookbook” и вот наконец-то книга вышла в свет. Как обычно для хабра-сообщества действует скидка 30% на электронное издание. Код купона — 9963c7ab, акция действует до 7 июля.

Второго июня 2014 года в мире Apple случилось то, чего не ожидал никто. Apple представила новый объектно-ориентированный язык программирования — Swift.

Чем может привлечь Swift?
В отличие от Objective-C, в котором для каждого класса необходимо создавать файлы *.h и *.m с интерфейсом и реализацией соответственно, в Swift нужно создать лишь один файл *.swift, в котором содержатся и интерфейс, и реализация. Это значит, что исходных файлов в проекте будет в 2 раза меньше, что является плюсом. Однако возникает вопрос — как же разделить свойства класса и методы на публичные и приватные? В Objective-C мы привыкли «прятать» приватные свойства и методы в *.m файлы. Сделать это в Swift на данный момент невозможно.

Перевод поста Джона Маклуна (Jon Mcloone, директор департамента международного бизнеса и стратегического развития Wolfram Research). Оригинал поста: How to Win at Rock-Paper-Scissors
Скачать пост в виде документа Mathematica

С точки зрения математики игра камень-ножницы-бумага (см. Дополнение 1 в конце) не является особо интересной. Стратегия равновесия Нэша очень проста: случайно и с одинаковой вероятностью выбирайте из трех вариантов, и при условии проведения большого числа игр ни вы, ни ваш соперник не сможете одержать победу. Хотя, при обсчитывании стратегии при помощи компьютера всё ещё возможно выиграть у человека после большого числа игр.

Работая над одним проектом, я столкнулся с необходимостью интегрирования PayPal Here в приложения. PayPal вообще никогда не шел на встречу разработчикам, интегрироваться было достаточно сложно, но с PayPal Here дело обстоит несколько иначе (есть целый пример на gitHub’е). Одним словом, если вы владелец интернет-магазина, интернет-аукциона или вообще хотите проводить оплату в своем приложении, то вам будет интересно почитать о том, как можно интегрировать PayPal Here в iOS.



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

Комбинаторика в старших классах школы, как правило, ограничивается текстовыми задачами, в которых нужно применить одну из трёх известных формул — для числа сочетаний, перестановок или размещений. В институтских курсах по дискретной математике рассказывают и о более сложных комбинаторных объектах — скобочных последовательностях, деревьях, графах… При этом, как правило, ставят задачу вычислить количество объектов данного типа для некоторого параметра n, например количество деревьев на n вершинах. Узнав количество объектов для фиксированного n, можно задаться и более сложным вопросом: как все эти объекты за разумное время предъявить? Алгоритмы, решающие подобного рода задачи, называются алгоритмами комбинаторной генерации. Таким алгоритмам, например, посвящена первая глава четвёртого тома «Искусства программирования» Дональда Кнута. Кнут очень подробно рассматривает алгоритмы генерации всех кортежей, разбиений числа, деревьев и других структур. Придумать какой-нибудь алгоритм, работающий умеренно быстро, для каждой из этих задач несложно, но с дальнейшей оптимизацией могут возникнуть серьёзные проблемы.

В процессе написания магистерской диссертации, защищённой в Академическом университете, мне потребовалось изучить и применить один из алгоритмов комбинаторной генерации, подходящий для особого класса задач. Это генерация структур, на которых дополнительно введено некоторое отношение эквивалентности. Чтобы было понятно, о чём идёт речь, я приведу простой пример. Давайте попробуем сгенерировать все триангуляции шестиугольника. Получится что-нибудь такое:



Написать алгоритм, который вернёт все такие триангуляции, довольно несложно. Например, сгодится такая процедура: фиксируем какое-нибудь ребро (пусть это будет ребро 1-6), после чего в цикле перебираем вершины, не являющиеся его концами. На текущей вершине и фиксированном ребре строим треугольник, а оставшиеся после этого две области триангулируем рекурсивно. Если присмотреться к получающимся в результате работы этого алгоритма триангуляциям, то можно заметить, что многие из них почти одинаковы и отличаются лишь тем, как расставлены пометки (номера) вершин. Поэтому, полезно было бы придумать алгоритм, который будет генерировать так называемые непомеченные триангуляции — те, что изображены на следующем рисунке:

Некоторе время назад я задумался о том, чтобы выложить часть своих библиотек в общий доступ. И вот наконец дошли руки все подравнять и выложить на GitHub:

• RObject — интроспеция с помощью describeTypeJSON
• JsonMapper — типизированный JSON парсер
• As3Query — DSL и ORM для Sqlite
• FlexXB Mobile — оптимизированный xml-парсер FlexXB
• air-hid-usb — расширение для работы с HID устройствами

Статья является своеобразным продолжением статьи «Знакомьтесь, Swift!» за авторством Helecta, а также вольным переводом статьи Developing iOS Apps Using Swift Tutorial Part 2.



Итак, в первой статье мы написали простое Single View приложение, включающее таблицу с несколькими ячейками.
На этот раз мы немного углубимся и сделаем несколько более амбициозных вещей. Мы будем обращаться к API поиска iTunes, парсить ответ, полученный в JSON и отображать результаты в Table View.
На первый взгляд может показаться, что все это довольно сложно и предстоит много работы, но на самом деле это не так. Все описанное выше является достаточно простым функционалом для iOS приложений и каждый уважающий себя iOS разработчик должен это уметь.

Зачесались у меня тут руки узнать, что это за зверь такой Swift и с чем его собственно едят. Как и ожидалось проблем и подводных камней пока оказалось много, ну либо я совсем не умею этот Swift готовить. Самая большая проблема ожидала меня при попытке подружить этот самый Swift с CoreData — штука принципиально отказывалась работать. Обильное гугление не приводило к хоть каким-либо хорошим результатам — информация была либо крайне обрывочной, либо попахивала костылями. Посему в первый вечер терзаний я капитулировал и решил использовать самое тупое решение в работе с CoreData по-старинке — хранить весь код в старом добром Objective-C и уже к нему обращаться из Swift (например в интерфейсах). Однако, перфекционизм в душе не давал покоя и требовалось реализовать чистое одноязычное решение, что я собственно и смог сделать, хотя признаться и не без костылей тоже. Кому интересен процесс прошу под кат. Также попутно предлагаю собирать баги и не самые на мой взгляд удобные вещи, которые пришли вместе с новым языком. Возможно, что-то я сделал криво — буду благодарен комментариям и поправкам, а также обсуждению лучших практик.

В третий день WWDC были более технические и менее «интригующие» сессии (Integrating Swift with Objective-C, What's New in LLVM, Cross Platform Nearby Networking, Creating Custom iOS User Interfaces и т.д.), прошли мастер-классы по использованию компонентов и погружению в Swift.

Отчет Артура mc_murphy Сахарова, Redmadrobot

2 июня на конференции WWDC 2014 Apple представила новый объектно-ориентированный язык программирования — Swift. Я думаю, многие уже успели посмотреть, что из себя представляет этот язык (Swift — нововведения), поэтому я не буду останавливаться на нововведениях. Я предлагаю создать простенький проект на языке Swift, чтобы понять на деле основные отличия от привычного Obj-C.

Состоялся долгожданный релиз, содержащий достаточно много обновлений, нововведений и багфиксов.

Одним из самых главных изменений является поведение команды git push. Теперь по умолчанию (если не указана ветка) push будет осуществлен только в текущую ветку. Git 1.* по умолчанию делал push во все ветки, которые были изменены локально. Конечно же можно вернуться к прежнему поведению, для этого служит опция push.default.

Поведение Git 1.*:

git config --global push.default matching

Новое поведение по умолчанию в Git 2.0:

git config --global push.default simple

Другие изменения:

Здравствуй, Хабр!

Мы сделали видео-уроки по языку Swift на основе бесплатной книги The Swift Programming Language от Эппл.



Все 32 урока доступны на нашем сайте. Несколько уроков – под катом.

Каждый программист — проектировщик API. Хорошие программы состоят из модулей, а протокол взаимодействия модулей — это тоже API. Хорошие модули используются повторно.

API — это большая сила и большая ответственность. У хорошего API будут благодарные пользователи; поддержка плохого превратится в кошмар.

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

API должно быть легко использовать, но сложно использовать неправильно. Сделать что-то простое с помощью такого API должно быть просто; сложное — возможно; сделать что-то неправильно должно быть невозможно, или, по крайней мере, трудно.

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

Перед разработкой API собери требования с долей здорового скептицизма. Осознай общие задачи и реши их.

Оформляй требования как шаблоны использования API. Сверяйся с ними в процессе проектирования.