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

Помимо улучшения вашего приложения путем добавления в него всяких «завитушек», есть одна вещь, которую все хорошие разработчики должны сделать со своим кодом – обработать его утилитой Instruments!

Это руководство покажет вам, как использовать наиболее важные особенности утилиты под названием Instruments, которая поставляется вместе с Xcode. Она позволит вам проверить свой программный код на наличие проблем с производительностью, утечкой памяти и других проблем.

Игра Oil Rush

В данной статье, состоящей из двух частей, речь пойдёт об использовании возможностей процедурных генераторов при создании контента для компьютерной игры Oil Rush и бенчмарка Valley (выйдет в феврале), разработанных на нашем собственном движке Unigine.

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

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

Adobe Photoshop CS5 (Save For Web) — 53,8 КБ	Image Catalyst (Xtreme) — 46,0 КБ

Image Catalyst — программа для комплексной оптимизации/сжатии изображений формата PNG и JPEG без потери качества в рамках того же формата.

Прежде чем отправить в AppStore ваше приложение, вы долго тестируете его, чтобы убедиться, что ваше приложение работает безупречно. Оно отлично работает на вашем устройстве, но после того, как приложение попало в App Store, некоторые пользователи сообщают, что оно «вылетает»!

Если вы похожи на меня, то вы хотите, чтобы ваше приложение было на пять с плюсом. Значит, вы возвращаетесь в свой код, чтобы исправить сбой… а куда надо смотреть?

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

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

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

Great Appeal или девушка на миллион

Итак, в прошлой статье мы закончили на том, что разобрались с тем, как получить «показы» нашего приложения в AppStore.

Иногда ошибочно считается, что запуск – это самое сложное. Это, мягко скажем, не так. Настоящая работа начинается после запуска.

Команда, искренне уверенная в качестве своего проекта, ждет вертикального взлета продаж с асимптотой к бесконечности… Но обычно получается больше похоже на новогодний фейерверк – короткий взлет, стремительное падение и забытье.

Большинство приложений провальны. Эта жестокая реальность приводит многих разочарованных разработчиков к заключению, часто подсознательному, что преуспевание в App Store — всё равно, что разбогатеть на «золотой лихорадке»: нужно быть чертовски удачливым.



Идея «удачи» — опасное успокоительное средство, облегчающее боль неудачи. А боль — это хорошая вещь. Она показывает, что что-то идёт не так. Если моё приложение потерпело крах, я хочу знать почему. Вместо того, чтобы обвинять мироздание, почему бы не посмотреть, что ребята из tap tap tap и Tapbots делают для того, чтобы снова и снова достигать успеха.

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

Схема успеха

Джон, мы потеряли два листа математических выкладок! Что делать?
Как обычно, Билл… напиши: «отсюда с очевидностью следует…»



Чтобы прочитать некраткую сопроводительную записку к схеме – добро пожаловать под кат.

Много чего предстоит сделать, прежде чем мы дойдем до вот этой картинки:



Опуская росказни о том, как именно я пришел к мысли построить гексапода (это были тонны видео на ютубе), перейду сразу к процессу выбора деталек. Это был январь 2012-го. Я сразу знал, чего я хочу от своего робота, а чего — нет. Я хотел:

— каждая нога должна иметь 3 степени свободы — 3dof (3 dimensions of freedom). Потому что более простой вариант 2dof — не дает такого ощущения насекомого, а 4dof — излишне, 3dof и так позволяет свободно перемещать кончик ноги в 3д пространстве;
— 6 ног; снова-таки, это уже не 4 (тогда робот неуклюже скачет), но и еще и не 8, как у пауков и уже чрезмерно;
— небольшой;
— дешевый;
— минимум плат и соединений;

Пост большой.

Возможно ли сделать простенькую игру за один день на unity, не имея опыта в этом?
Вопрос был риторическим, пока мы не попробовали.
Есть такой проект — 2niversity. Появился этот проект недавно, но их цель мне очень понравилась — собирать молодежь и абсолютно бесплатно организовывать для нее однодневный интенсив с целью повышения навыков в какой-либо технологии

Когда мне позвонил менеджер этого проекта и предложил попробовать провести подобное мероприятие на unity, я задумался.
С одной стороны лично мне все казалось просто — 5-7 часов на простенькую игру и все готово, с другой стороны люди, которые участвуют в роли учеников, должны будут впервые использовать этот движок. Возможно им вообще впервые придется попробовать себя в роли создателя игр. Если интересно, чем закончился данный эксперимент, прошу под кат

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

Этой весной, Питер Тиль (Peter Thiel), один из основателей PayPal и первый инвестор FaceBook, провел курс в Стенфорде — «Стартап». Перед началом Тиль заявил: «Если я сделаю свою работу правильно, это будет последний предмет, который вам придется изучать».

Один из студентов лекции записывал и выложил транскипт. В данном хабратопике я делаю перевод второго занятия.

Занятие 1: Вызов будущего
Занятие 2: Снова как в 1999?
Занятие 3: Системы ценностей
Занятие 4: Преимущество последнего хода
Занятие 5: Механика мафии
Занятие 6: Закон Тиля
Занятие 7: Следуйте за деньгами
Занятие 8: Презентация идеи (питч)
Занятие 9: Все готово, а придут ли они?
Занятие 10: После Web 2.0
Занятие 11: Секреты
Занятие 12: Война и мир
Занятие 13: Вы — не лотерейный билет
Занятие 14: Экология как мировоззрение
Занятие 15: Назад в будущее
Занятие 16: Разбираясь в себе
Занятие 17: Глубокие мысли
Занятие 18: Основатель — жертва или бог
Занятие 19: Стагнация или сингулярность?

Компания MakerBot Industries представила новое поколение своего знаменитого 3D-принтера. Модель Replicator 2 гораздо лучше предыдущей: она обеспечивает разрешение 100 микрон вместо 270 микрон и может напечатать предмет объёмом 6,7 дм³ (+37% к прошлому).

Replicator 2 размером с большую микроволновку можно поставить на рабочем столе возле компьютера. Модель продаётся за $2199 в фирменном магазине компании на Манхэттене, а также на офсайте. Принтер работает из-под Windows XP и 7, Mac OS X и Ubuntu.

В последнее время я стал все больше и больше интересоваться функциональным программированием, и при выборе языка предо мною пал выбор среди двух очень понравившихся мне языков — Haskell и F#.
В F# меня соблазнило то, что его можно компилировать в MSIL сборки, что обеспечивает возможность использования библиотек классов F# в других языках Microsoft .Net, а также то, что он и сам может их использовать. Ко всему прочему, я ещё и начинающий разработчик Unity3D, и мне в голову пришла мысль: если компилируется в MSIL, то может можно использовать F# скрипты в Unity? Гугление дало ответ: по-человечески нельзя. Можно создать библиотеку классов, поставить в проекте ссылки на библиотеку UnityEngine.dll, компилировать и импортировать как ассет, после чего добавлять компоненты Mono-behaviour напрямую из библиотеки, но это не слишком удобно, согласитесь. Однако, пройдя гугл, Reflection и справку по Unity, мне все таки удалось приблизить(но не повторить в точности) работу с F# скриптами внутри редактора к тому виду, в котором производится работа со скриптами на встроенных языках. Подробности — под хабракатом.

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



ВНИМАНИЕ! Все ниженаписанное является де-юре нарушением законодательства РФ и Украины, и вообще выдумкой автора и плодом работы в фотошопе. Применяя описанное на практике, вы действуете на свой страх и риск, и ни автор, на администрация сайта не несет ответственности за ваши действия.

Вопрос о столах поднимался несколько раз (раз, два).

Однако, на чем же мы сидим перед столом?

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

Все мы работаем с компьютером и порой не замечаем, на чем же мы сидим.

Оказывается наши санитарные правила и нормы (СанПиН 2.2.2/2.4.1340-03) достаточно хорошо описывают удобный эргономичный стул для работы взрослых за компьютером!

А какой стул правильный?

Привет, хабровчане! Недавно мы выпустили игру Gemibears для айфона и айпада (специально никаких ссылок на игру, пост не про саморекламу) и за несколько дней добрались до топ-25 в платном чарте по Америке.

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

Введение

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

Microsoft предоставляет встроенное в Visual Studio средство, которое позволяет оценить код вашего проекта.



Получить оценку вашего кода можно нажав правой кнопкой на проекте и выбрав пункт “Calculate Code Metrics” (Эта функциональность доступна в Visual Studio 2008 Team System и Visual Studio 2010 начиная с Premium версии).

Некоторое время назад я попал в геймдев, где столкнулся с проектами по 2 млн. строк кода, которые пишут десятки программистов. При таких масштабах кодобазы возникают проблемы неведомого мне ранее характера. Об одной и них я хочу вам сейчас рассказать.

Итак, представьте себе следующую ситуацию. Так уж случилось, что вам надо отрефакторить очень большой кусок кода, целую подсистему. Строк, эдак, на 200К. Причем рефакторинг явно выглядит очень крупным, затрагивающим базовые концепции, по которым построена ваша подсистема. Фактически надо переписать всю архитектуру, сохранив бизнес логику. Такое бывает, если, например, вы сделали один проект и у вас впереди новый, и вы хотите в нём исправить все ошибки прошлого. Допустим, по первым прикидкам, на рефакторинг надо месяца 2, не меньше. В процессе рефакторинга всё должно работать, в том числе нельзя мешать другим программистам добавлять новые фичи и чинить баги в подсистеме. Часто такой рефакторинг бывает насколько сложен, что совершенно невозможно замерджить старый код в новый, а также невозможно выкатить результат по частям. Фактически вам надо заменить двигатель самолёта на лету.

Примеры из практики, как моей, так и моих коллег:

• Переделать всю работу с базой данных с чистого JDBC на Hibernate.
• Переделать архитектуру сервиса с отсылки-приёмки сообщений на удалённый вызов процедур (RPC).
• Полностью переписать подсистему трансляции XML файлов в рантайм объекты.

Что делать? С какой стороны подойти к проблеме? Ниже представлен набор советов и практик, которые нам помогают справиться с этой проблемой. Сначала более общие слова, а потом конкретные методики. В общем-то ничего сверхъествественного, но кому-то может помочь.