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

Меня всегда интересовал геймдев. Несколько лет назад я сделал шаг и окунулся в этот мир. Меня поражал успех Энгри Бердс (Angry Birds), взлёт и падение Зинги (Zynga), и одна мысль мне не давала спать — «Как же они сделали такие классные игры?».

Прошло немало времени, накопился ящик опыта, в закромах образовались какие-то отрывочные записи и комментарии. Я решил все структурировать и систематизировать, стараясь ответить на один из краеугольных вопросов — «Почему же пользователь вернётся в игру?».

Предположим, это ваша цепочка поставок. Сейчас экспертная система будет её оптимизировать.

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

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

Есть три проблемы:

• Логистика у нас настолько сложная и разветвлённая, что сейчас над ней работают десятки людей: кто-то занимается распределением майфунов, кто-то раскидывает по магазинам обложки, а производственники просчитывают оптимальные пути сбора комплектующих на заводах со всего мира.
• При этом хочется сэкономить на логистической схеме: вы подозреваете, что умный анализ всех потоков позволит принять решения, например, о месте открытия нового производства или организации дополнительного склада, что в итоге даст вам выгоду.
• И при этом ваши люди постоянно ошибаются с отправлениями – а хочется сделать так, чтобы ничего и нигде не забывалось, всё работало как часы и товары приходили на точки вовремя. Это тоже экономия, но уже за счёт своевременности поставок и отсутствия ошибок.

Ключ к успеху при разработке free-to-play игр — анализ поведения игроков и постоянный тюнинг игрового функционала на основе статистики. Собрать статистику — это пол дела. Но как превратить гору сырых данных в информацию?

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

Не беспокойтесь о людях, ворующих ваши идеи. Если ваши идеи хоть сколько-нибудь хороши, вам придется проталкивать их через людские глотки. Говард Эйкен.



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

“Как только Парижская выставка закроется, электрический свет закроется вместе с ней, и больше о нем никто не услышит” Эразмус Уилсон, профессор Оксфордского университета, 1878 год.

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

Под катом я расскажу о том, как мы решали эту задачу в Ivideon и что для нас дало отличный результат, а что нет.

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

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

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

Основная проблема – это то, что маркетинг у нас или обывательский («мне кажется, что должно быть так») или книжный («а вот у Котлера написано, что…».). В первом варианте советы представляют из себя смесь банальностей со стереотипами, во втором — знание устаревшее на полвека. Делать маркетинг по книжкам, это все равно, что работать на PCX86 – вроде можно, но смысл?



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

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

Это продолжение первой части статьи о том, какие существуют инструменты влияния на ретенцию (retention) игры. Напомню также, что понятие «ретенция» в большей мере применимо к активной фазе работы и развития социальной или мобильной игры. Вряд ли эти же механизмы применимы к случаям, когда мы перепроходим игры, в которые играли 5 лет назад.

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

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

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

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

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

В отечественном IT я часто наблюдаю следующую картину: тимлидом часто становился лучший (?) разработчик из команды (aka 23-летний сеньор). А чтобы стать руководителем проекта (project manager) иногда достаточно просто знать английский и «павэрпойнт» на уровне пользователя. Это реалии отечественного аутсорсинга и с этим нужно как-то жить.

В итоге часто получается как-то так:

Потому что на десять сеньоров по статистике девять тупят.

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

Полезные советы от британского миллиардера под катом.

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

Итак, я просил ответить на вопрос какие книги из статьи вы читали?

Результаты опроса:

Название книги	Количество голосов	Процент
Том ДеМарко. Deadline. Роман об управлении проектами	247	54%
Фредерик Брукс. Мифический человеко-месяц, или Как создаются программные системы	174	38%
Джоэл Спольски. Джоэл о программировании	165	36%
Том Демарко и Тимоти Листер. Человеческий фактор. Успешные проекты и команды	148	32%
Джейсон Фрайд, Дэвид Хайнемайер Хенссон. Rework. Бизнес без предрассудков	108	24%
Джеффри Янг и Уильям Саймон. iКона. Стив Джобс	94	21%
Том ДеМарко, Тимоти Листер. Вальсируя с Медведями: управление рисками в проектах по разработке программного обеспечения	70	15%
Том Демарко, Тимоти Листер. Балдеющие от адреналина и зомбированные шаблонами. Паттерны поведения проектных команд	51	11%
Кармин Галло. iПрезентация. Уроки убеждения от лидера Apple Стива Джобса	48	11%
Патрик Ленсиони. Смерть от совещаний	21	5%
Патрик Ленсиони. Пять пороков команды. Притчи о лидерстве	19	4%
Патрик Ленсиони. Пять искушений руководителя: притчи о лидерстве	16	4%
Патрик Ленсиони. Три признака унылой работы. История со смыслом для менеджеров (и их подчиненных)	11	2%

А теперь еще один бонус — список книг по заданной тематике, которые прислали нам читатели:

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

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

Плюс традиционно – небольшой подарок хабражителям.

Так как приходиться уже не первый раз объяснять как это делается, решил оформить в виде How-To в картинках
Скачиваем архив putty отсюда putty.zip
1. Распаковываем и запускаем ssh-keygen

Выбираем ключ ssh-rsa и длину 2048 бит. Жмем «Generate».

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

В предыдущей статье, мы познакомились с настройкой связки nginx + apache в режиме хостинга и репозиториями dotdeb.
В этой статье мы познакомимся с настройкой backend: PHP, MySQL.

В части PHP мы познакомимся со следующими темами:
— общая настройка PHP
— правильная настройка PHP + Postfix для отправки писем через внутренний SMTP сервер посредством функции mail(),
— настройка кеширования кода и/или данных на основе APC.

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

Кто заинтересовался, добро пожаловать под кат

 

Навеяно очередной прочитанной книгой по управлению проектами. Это «Scrum и XP: заметки с передовой» Хенрика Книберга.

Скрам – это круто и красиво. Особенно красиво (и, на мой взгляд, реально применимо только в этом случае), когда решены все инфраструктурные проблемы, когда усилия всей компании (а не только скрам-команды) направлены на выпуск качественного продукта вовремя и когда задача программистов – именно разрабатывать ПО (т. е. никто не будет выдёргивать разработчика «из потока» для выполнения фантастически несвойственных ему задач).

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

В другой книге («Человеческий фактор…» Тома Демарко и Тимоти Листера) написано, что в идеальном рабочем помещении для программиста должно быть по окну на каждого сотрудника (чтобы он мог более вдохновенно заниматься разработкой и потому, что мы работаем, чтобы жить, а вовсе не наоборот). А как насчёт комнат на 10-20 человек с двумя окнами каждая (выходящими на промпейзаж, куда и смотреть-то лишний раз не захочется)?

Обсудим отечественные реалии, которые убивают теорию уважаемых Демарко и Листера и практику не менее уважаемого Книберга на корню. Начнем с соцпакета.

Недавно разговаривал с коллегой – руководителем PMO из соседней программерской фирмы (PMO – это Project Management Office, само его наличие говорит о том, что фирма придерживается современных взглядов на управление проектами; у нас вот – классическая функциональная структура, в лучшем случае – слабая матрица, нам PMO не светит). Так вот, они в ближайшее время будут завозить в офис и давать сотрудникам неограниченно потреблять всякие перекусы и питьё: чипсы/орешки, печенье/булки, соки и т. п. Как сказал коллега: «Предположим, нашему программисту ближе к вечеру захотелось перекусить. И у него возникает сложная дилемма: уйти поесть или поработать всё-таки еще пару часов. Плюшки в офисе склонят его в пользу поработать». А действительно, рассмотрим дилемму повнимательнее. Итак, таблица (цифры взяты «с потолка», но я в них почти уверен):

Книги, которые должен прочитать Java программист: от новичка до профессионала

[Примечание переводчика: термины градации «профессионализма» оставлены англоязычные в связи с трудностью их адекватного перевода на русский и несовпадением с привычными Junior-Middle-Senior-Lead. Перевод достаточно вольный — если знаний языка хватает, то лучше читать оригинал, как и советует автор. Оба языка для меня не родные, так что про ошибки сообщайте в личку — исправим. Здесь и далее в квадратных скобках примечания переводчика]

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

Все доброго времени суток!
Хочу рассказать об одной интересной проблеме и ее решении, которое я применил в одном из своих проектов.
Суть проблемы такова:
Есть несколько детекторов сигнала (допустим, базовые станции GSM). И эти детекторы присылают на сервер уровень сигнала для некоего источника. Необходимо вычислить и отобразить на карте координаты источника
Если вам интересно, как это сделать, добро пожаловать под кат.

Мне было интересно, какие коллекции сколько съедают дополнительной памяти при хранении объектов. Я провёл замеры накладных расходов для популярных коллекций, предполагающих хранение однотипных элементов (то есть списки и множества) и свёл результаты на общий график. Вот картинка для 64-битной Hotspot JVM (Java 1.6):

Да-да, это та самая библиотека padeg.dll, но работающая везде где есть java. Авторы Sergey V. Plahov aka Seer and Gennady Pokatashkin
Собственно, история простая. Началась она в 2007 году, когда мне срочно понадобилось склонять ФИО и должности для одного корпоративного проекта. В принципе, данный функционал не стоял в требованиях заказчика, но нужны были «плюшки», и автоматические склонения — это как раз одна из плюшек.
Довольно быстро удалось связаться с одним из авторов библиотеки, и после перечисления небольшой суммы были получены исходники на Delphi, которые затем портировались в JAVA. По первоначальной задумке java и delphi исходники должны были максимально совпадать, чтобы впоследствии можно было вносить параллельные правки. Делалось так: брались исходники на delphi, менялись расширения pas→java, и добавлялись в проект. Дальше шла правка синтаксиса. Но фактически delphi — код пришлось сильно рефакторизовать, поскольку он состоял в основном из многоэтажных if-ов и внутренних процедур, содержал глобальные переменные и не был приспособлен для многопоточной работы.
Как бы там ни было, библиотека портирована. На вопрос о копирайте мне было разрешено делать с результатом что угодно, но поскольку delphi-библиотека распространялась на условиях shareware, я не стал публиковать java-порт.
С тех пор прошло 5 лет, и я думаю, хватит одному пользоваться инструментом, которой найдется применение в хозяйстве отечественного java — разработчика. К тому же праздник на носу. Поэтому загружайте