В статье «Медовый месяц менеджера: как его провести с пользой» мы начали говорить о первых шагах инженера, которому не повезло посчастливилось стать менеджером команды. О том, что рождается в головах окружающих в это момент, и как строить разговоры с предыдущим менеджером, HR’ом и своим новым начальником.

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

«Специалист подобен флюсу: полнота его одностороння». (Козьма Прутков)

Как в нашей отрасли происходит назначение на позицию менеджера? Берем в команде лучшего программиста и тут же назначаем вначале проясняем ситуацию:

— Хочешь быть менеджером?
— А чего нужно делать?
— Ну, там колбаски в MS Project двигать и получать плюс 300 баксов?
— Конечно, буду!

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

Результаты нашего недавнего исследования еще раз ткнули в эту нашу отраслевую специфику:

• Более 50% людей считают, что их руководитель не умеет работать с людьми

Что и побудило написать эту статью.

Общий эффект от перехода в менеджеры усиливается еще тем, что наш брат-айтишник обычно вначале включает электроприбор («если я мультипоточность на Java реализую, чего — я со стиральной машиной не разберусь?»), а в случае неполадок начинает читать инструкцию. То бишь, начинает изучать науку работы с людьми, когда первые шишки не просто набиты, а поверх них набиты еще два слоя шишек.

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

Доброго времени суток %username%. Не давно наткнулся на хороший туториал по созданию клона игры Flappy Bird используя LibGDX и этот туториал мне понравился своей простотой и детализацией.

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

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

Это перевод публикации «Les Forges Pixel Art Course».

Часть 1: Правильные инструменты
Часть 2: Линии и кривые
Часть 3: Перспективы
Часть 4: Тень и свет
Часть 5: Палитры цветов
Часть 6: Сглаживание
Часть 7: Текстуры и размытие
Часть 8: Мир тайлов

Часть 3: Перспективы

Проблема перспективы в 2D играх, это вопрос который возникает часто, и это возможно то, почему так много любительских игр имеют множество противоречивостей в этой области. В частности эта часть адресуется к типичным перспективам в RPG, так что если вы ищете информацию о виде сбоку или от первого лица, вам следует поискать где-нибудь ещё. Это важно, помнить что перспектива — это «искусство представления трёхмерных объектов на плоской поверхности (в данном случае это ваш экран) как их увидел бы наблюдатель.»

Любой предприниматель, будь то владелец стартапа или корифей рынка, нуждается в рекламе. Для IT-кампаний очевиден сдвиг рекламных площадок в Интернет. Стоит начать поиск возможностей размещения, как на начинающего рекламодателя валится несусветное количество опять-таки рекламы агентств, агрегаторов, площадок. И многие сбиваются, подписывают договора, ведутся на бесплатные предложения и заманчивые тестовые периоды. Как правило, это приводит к разрастанию рекламных затрат при небольшом или нулевом результате. При этом основных (и эффективных) способов размещения поисковой и контекстной-медийной рекламы мало. В России это Яндекс.Директ и Google AdWords, для тех, кому интересна реклама за рубежом, добавляются сети Bing и Yahoo.



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

Мне периодически приходится объяснять разным людям некоторые аспекты архитектуры Intel® IA-32, в том числе замысловатость системы адресации данных в памяти, которая, похоже, реализовала почти все когда-то придуманные идеи. Я решил оформить развёрнутый ответ в этой статье. Надеюсь, что он будет полезен ещё кому-нибудь.
При исполнении машинных инструкций считываются и записываются данные, которые могут находиться в нескольких местах: в регистрах самого процессора, в виде констант, закодированных в инструкции, а также в оперативной памяти. Если данные находятся в памяти, то их положение определяется некоторым числом — адресом. По ряду причин, которые, я надеюсь, станут понятными в процессе чтения этой статьи, исходный адрес, закодированный в инструкции, проходит через несколько преобразований.



На рисунке — сегментация и страничное преобразование адреса, как они выглядели 27 лет назад. Иллюстрация из Intel 80386 Programmers's Reference Manual 1986 года. Забавно, что в описании рисунка есть аж две опечатки: «80306 Addressing Machanism». В наше время адрес подвергается более сложным преобразованиям, а иллюстрации больше не делают в псевдографике.

Умей говорить «нет»

Старший разработчик Валера работает в роли тимлида на большом и важном проекте для большого и важного заказчика. За окном шумит жаркое лето, по пыльным улицам бегут по своим делам прохожие, голуби крутят пируэты в необъятном казахстанском небе. Жизнь прекрасна – пилотный запуск намечен на конец ноября, команда набрала хороший темп и идет по графику. И тут Валера боковым зрением замечает, как на иконке Скайпа появилась желтая точка – кто-то о нем вспомнил и написал сообщение. Это руководитель проекта: «Зайди ко мне…»

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

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

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

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



Обратите внимание, насколько экран 8" с соотношением сторон 4:3 визуально больше широкого экрана 7". А широкий экран 10.1" на сантиметр меньше экрана 9.7" по высоте.

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



Текст на экранах с низким PPI (количеством точек на дюйм) читается не комфортно. Я бы не стал покупать планшет с экраном, имеющим PPI ниже 150. Даже 164 PPI экрана iPad mini многим кажутся недостаточными. Отлично воспринимаются экраны с PPI больше 200.

Для меня было большим открытием, что экран 9.7" 1024x768 имеет даже меньшее PPI, чем экран 7" 800x480.

С тех пор, как в институте появился предмет маркетинг, я прочёл несколько десятков книг, полезных для проект-менеджеров, стартаперов и руководителей компаний. Лучшие я собрал в небольшую библиотеку и хочу рассказать о них вам. Все эти книги заслуживают внимания и будут вам полезны. О многих вы уже слышали, часть упоминалась на Хабре, но, надеюсь, вы откроете для себя нечто новое из тех 22-х книг, о которых хочу рассказать.

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

Хотелось бы поделиться личными впечатлениями о разработке мобильных игр на основе Unity3d. Изначально думал уместить в одном посте все мелкие «Tip&Trick» с которыми столкнулся при работе с Unity3d за последнее время. Но их оказалось черезчур много. Так что в этом посте будут только те, которые касаются непосредственно написания кода.

Главная тема поста — разделение классов по «слоям», связывание их через события и чуть-чуть о том, как наладить взаимодействие объектов на сцене.
Кому интересно — добро пожаловать под кат!

Более трех лет назад я написал пост о выборе платежной системы для приема платежей на своем прошлом проекте. С тех пор прошло довольно много времени и многое в способах приема платежей изменилось. Теперь я расскажу как делал прием платежей на сайте poiskvps.ru.

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

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

Все уже знают что 17 сентября 2013 года при помощи PayPal можно выводить поступившие на него деньги, на счета в отечественных банках. Но по этому вопросу возникает много споров. На практике оказалось всё очень просто.
Мы рассмотрим вариант как выводить деньги в России для частного (физического) лица.

Для начала Вам нужно указать счет в Российсом банке и указать кто его владелец — Частное или Юридическое лицо.

Если вы пишете не казуалку под веб и не беспощадный суровый рогалик, без сохранения данных на диск не обойтись.
Как это делается в Unity? Вариантов тут достаточно — есть класс PlayerPrefs в библиотеке, можно сериализовать объекты в XML или бинарники, сохранить в *SQL*, можно, в конце-концов, разработать собственный парсер и формат сохранения.
Рассмотрим поподробнее с первые два варианта, и заодно попробуем сделать меню загрузки-сохранения со скриншотами.

Будем считать, что читающий дальше базовыми навыками обращения с этим движком владеет. Но при этом можно не подозревать о сущестовании в его библиотеке PlayerPrefs, GUI, и ещё в принципе не знать о сериализации. С этим всем и разберёмся.
А чтобы эта заметка не стала слишком уж увлекательной и полезной, ориентирована она самый неактуальный в мобильно/планшетно/онлайновый век вариант — сборку под винду (хотя, конечно, более общих моментов достаточно).

• Кстати, пару недель назад на Хабре была статья, где автор упомянул, что Unity3D проходят в курсе компьютерной графики на кафедре информатики питерского матмеха. Занятный факт, немало говорящий о популярности движка.
  Хотя насколько это в целом хорошая идея — на мой взгляд, тема для дискуссии. Может быть, обсудить это было бы даже интереснее вопросов сериализации =)

Это первая наша статья на Хабре (и, надеюсь, не последняя) и хочется максимально честно и открыто рассказать про наш опыт запуска бизнеса в Питере по разработке мобильных приложений «с нуля», какие ошибки мы совершали, какие продолжаем совершать (ну куда же без этого) и про то, как мы пытаемся построить что-то действительно масштабное и «изменить этот мир» — а именно наш проект мобильного товарного агрегатора tapki (название смешное конечно, родилось как производное от английского слова «tap»). Оглядываясь на статью, после ее написания, вижу, что получилось не мало текста (около 18-ти страниц в word’е), но надеюсь, что сказанное будет полезно. Коллеги советовали разбить документ на части, но как мне кажется, цельное повествование, затрагивающее период чуть больше года, позволит дать более полную картину развития компании. В статье читатель найдет экономику (управленческий баланс), который «тянется» с самого начала, с разбивкой по статьям затрат. Мы ничего не добавляли-убавляли и все цифры приводим «как есть».

Я расскажу про запуск бизнеса с самого начала: поиск помещений, поиск инвестиций, про основную (изначальную) идею бизнеса и как она менялась в течении года, про удачи и неудачи. Поскольку мы зарегистрировали юр.лицо в июне 2013 года (а точнее 29 мая), нам, можно считать, исполняется 1 год «с хвостиком» и какие-то нюансы уже не вспомнить, но основные вехи с фотографиями — сохранились. Важно — если где-то в тексте я делаю для себя (и читателей) вывод или даю совет (прямо или косвенно) — прошу расценивать его исключительно как мое личное мнение, которое с вероятностью 50% может быть в корне не верным. И еще — некоторые моменты я не могу вспомнить в деталях, поэтому могут встречаться небольшие неточности в части объяснения тех или иных цифр — это не попытка утаить информацию, а просто элементарная забывчивость, т.к. дневник я не вел (к сожалению — исправляюсь) и пишу по памяти.

Недавно наша студия завершила разработку большого обновления — Captain Antarctica: Endless Run — для устройств на iOs. Кропотливая работа над обновлением затронула производительность, которая оказалась очень низкой на слабых устройствах. Я боролся с этим целую неделю и добился как минимум 30 FPS, а также значительного сокращения размера приложения. Хочу рассказать, как я это сделал, ну и как делать не стоит.
Статья пригодится любым разработчикам на Unity (причем не только менеджерам проектов и техническим специалистам, но и просто программистам, художникам и дизайнерам), потому что она затрагивает как оптимизацию на Unity в целом, так и конкретно оптимизацию 2d-приложений для мобильных устройств.

Разработка игр в целом – очень увлекательный и интересный процесс. Особенно он интересен тогда, когда ты занимаешься этим один, независимо ни от кого, имея за плечами небольшой опыт во всем, что позволит создать полноценный продукт для индустрии развлечений. Казалось бы, если для этого есть время и возможности, то почему бы не переодеться в шкуру инди-разработчика и создать нечто интересное, что сможет понравиться людям и принесет прибыль? Конечно да, но только помимо множества явных подводных камней существуют и едва заметные грабли, которые лежат на последней ступени процесса создания игры и больно лупят по голове. После чего остается мысль — «Ведь я же старался, потратил много времени, но ничего не получил взамен», а следом — «Ничего, в следующий раз я сделаю лучше!». Под катом история о том, как на эти грабли мне пришлось наступить трижды.

Билд для IOS всегда стоял особняком в Unity3D. Если все остальные можно было компилировать на Windows машинах, то для IOS обязательно нужен был Мак. Я как и все столкнулся с этой проблемой при попытке выпустить свой первый проект на IOS, которая казалась мне трудно преодолимой. Однако, совсем недавно произошло два события которые делают эту проблему практически неактуальной, и которые прошли на Хабре незамеченными.

О чём телега

Я бы хотел описать возможности, ну и частично особенности которые присутствуют при разработке на данном движке. С Unity3D работаю уже около трёх лет, так что мыслей накопилось достаточно для средненькой такой статьи. Местами буду через чур мудрить, и рассказывать о том что вам вряд ли пригодится, но по большой части рассказ будет о очень простых и часто используемых вещах (если знать о них конечно).

Как-то при подготовке своего проекта в Unity3d у меня возникла необходимость использовать Bitmap font (он же растровый шрифт). Я очень обрадовался, когда обнаружил в Unity инструменты для создания такого шрифта. Но спустя некоторое время понял, что процедура эта отнюдь нетривиальна из-за отсутствия какой-либо документации на этот счёт.

Эта статья о том, как собрать в Unity готовый к использованию Custom Bitmap Font. Урок довольно подробный и затрагивает работу в Photoshop. Заинтересовавшихся прошу под кат.