Внимание! Несмотря на то, что для работы над этой статьей я потратил не один десяток часов, но ты все еще можешь в ней поучаствовать.

Если у тебя чешутся руки — попробуй осилить этот текст.

История больше похожа на комикс, так как содержит более 50 изображений, поэтому аккуратнее, если ты с мобильного. А ещё — тут скорее всего нарушается 152-ФЗ, поэтому я не удивлюсь, если её удалят, так что читай быстрее. Эта история пока не имеет конца, но у нее есть начало…

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

Традиционно, для тех кто не любит много буков, краткие (более-менее) тезисы:

• Будучи долгое время лидером на рынке, Нокиа сильно расслабилась и загадила свою внутреннюю инфраструктуру бюрократией, чрезмерным аутсорсингом и огромным количеством бесполезной «менеджерской прослойки».
• Будучи долгое время лидером, Нокиа просрала потратила много денег на ненужные операционные расходы, поглощения никому не нужных фирм и на невменяемую модель аутсорсинга.
• Полностью оторвавшись от реальности с уходом Йормы Оллилла, Нокиа, под управлением гениального юриста CEO Олли-Пекки Каласвуо, потратила кучу денег и усилий на создание бесполезной и неконкурентоспособной сервисной инфраструктуры Ovi. В результате этого, помимо денег, Нокиа потеряла уйму полезного времени, которое можно и нужно было потратить на развитие основного бизнеса — телефонов, софта и т.д.
• Бюрократия и непотопляемая менеджерская прослойка в Нокиа, последовательно мигрировала из одного передового проекта в другой, в составе одних и тех же групп лиц, самореплицируясь в виде кучи формальных дебилопроцессов комитетов и управленческих групп, немного перетасовываемых с учетом специфики. В итоге именно эта бюрократия убила и Symbian, и Ovi, и MeeGo и остальные попытки догнать уходящий поезд своими силами.
• Борьба с бюрократией и прослойкой в Нокиа зашла в полный тупик.
• У великого CEO Элопа просто не было другого выхода кроме как прибить всю старую, неповоротливую и прогнившую организацию, путем создания альянса с Майкрософтом и переходом на Windows Phone. Тем самым все старые процессы, компетенции, технологии и самое главное — люди резко стали, что называется, «не в тему». И следовательно тем самым можно было под благовидным предлогом прибить этот табун менеджеров, бесконечно рисующих фэнтезийные роадмапы с единорогами и перекладывающих бумаги с левого края стола на правый.
• Новая Нокиа, после 2011 года и старая Нокиа до 2011 года – это две РАЗНЫЕ организации. Их объединяет только общее название и операционка S40 для телефонов Asha.
• Горящая платформа, это не Symbian и не MeeGo. Горящая платформа, это то состояние в которое Нокиа загнали годы расслабленного лидерства и тупоголовые амбиции предыдущего CEO – Олли-Пекки Каласвуо с кликой подкаркивающих вице-президентов.
• С бюрократией и бизнес процессами, имеющимися на 2010 год, Нокиа не спас бы ни Андроид, ни половина населения Бангалора, пишущих на Qt под MeeGo. Даже если бы Apple бесплатно передал Нокиа iOS и все сервисы, то они бы выродились руками всяких Requirement Managerов в типичные Нокийские дизайн-химеры и в итоге загнулись через какое-то время.
• То, что сделал великий CEO Элоп – было единственно возможным разумным решением, дающим хоть какие-то шансы на выживание. Вопрос «каким образом он это сделал?», остается открытым, равно как и вопрос «поможет ли это Нокиа?» в итоге. Не следует забывать, что нынешняя Нокиа — это совершенно новая организация, поэтому глупо предполагать, что она разом вернет себе лидерство. Как и всем новым организациям ей придется за это лидерство долго бороться.
• Без ошибок и побед Нокиа никогда не было бы ни Андроида, ни Айфона. И Google и Apple тщательно проанализировали достоинства и недостатки более старших конкурентов перед тем как шагнуть вперед.

Все это в деталях — под катом. Предупреждаю что клевых картинок там нет. Сплошное графоманство и ёрничанье.

Привычный хаос в названиях коммитов. Знакомая картина?

Наверняка вы знаете git-flow. Это отличный набор соглашений по упорядочиванию работы с ветками в Git. Он хорошо документирован и широко распространен. Обычно мы знакомы с правильным ветвлением и много говорим об этом, но, к сожалению, уделяем слишком мало внимания вопросу наименования коммитов, поэтому часто сообщения в Git пишутся бессистемно.

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

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

На web-проектах Альфа-Банка используется фреймворк для автоматизации тестирования Akita, который использует для BDD-сценарии. К настоящему моменту фреймворк набрал большую популярность благодаря низкому порогу входа, удобству использования и возможности тестировать верстку. Но мы решили пойти дальше — на основе описанных тестовых сценариев формировать документацию, тем самым сильно сокращая время которое аналитики тратят на на извечную проблему актуализации документации.

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

• скриншоты;
• значения переменных (config File, учетные записи пользователей и т.д.);
• статусы и параметры запросов.

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

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



И здесь самое забавное — это кривая обучения и интерфейсы. Давайте пройдёмся по этим моментам, благо есть отличные находки.

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

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

OpenGL

Знакомство с OpenGL нужно начать с того, что OpenGL — это спецификация. Т.е. OpenGL лишь определяет набор обязательных возможностей. Реализация же зависит от конкретной платформы.
OpenGL является кроссплатформенным, независимым от языка программирования API для работы с графикой. OpenGL — низкоуровневый API, поэтому для работы с ним неплохо иметь некоторое представление о графике в целом и знать основы линейной алгебры.

Давным-давно, когда звезда флеша только начала гаснуть, я обратил внимание на молодую еще технологию WebGL. Юная и нестабильная, она привлекала взгляды своими неординарными возможностями. Масса копий было сломано в полемиках, а пользователи разделились на противоборствующие стороны лагеря. Однако время шло и WebGL «взрослела»…

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

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

[Публикую собственный перевод статьи за авторством TitanSlayer, автора музыки для видео игр, фильмов и ТВ]

Мне всегда нравились видеоигры. С самого детства я был очарован, загипнотизирован такими играми как Quake, Hexen, Heroes of Might & Magic.

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

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

Когда мне было 11 лет, наша семья купила первый компьютер: AST «Advantage!» с процессором 486 (66 МГц), 4 МБ ОЗУ и жёстким диском на 32 МБ. Это не был самый мощный компьютер, даже в те времена, но на нём был QBasic. Я всегда хотел делать игры, поэтому немедленно погрузился в программирование.

Всем привет! Меня зовут Олег и сегодня я хочу поделиться своим опытом переезда в Германию.
Я общаюсь до сих пор с многими IT-специалистами из России и очень часто, на мои предложения попробовать себя и поработать в европейской компании с переездом, люди отвечают: «Мой английский не так хорош» или «Как же я буду жить без родственников рядом» или «Мне нужно много денег на переезд». Это всё очень важные и действительно сложные моменты. Но, как я хочу постараться показать на собственном опыте, вполне преодолимые.

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

Меня зовут Артём Титов, я lead gameplay programmer в Larian Studios.
Мы очень давно хотели поделиться с вами нашим опытом создания и разработки компьютерных игр, но долго не могли решить, с чего бы начать. Долго размышляя, мы пришли к выводу, что первая статья должна быть не технической, а скорее личной — и для этого я перевёл вам запись в блоге одного из наших сотрудников, сделанную около года назад. Его история даёт очень хорошее представление не только о нашей студии со стороны игр, что мы создаём, но и детально показывает личный аспект жизни рядового сотрудника студии, проходящей через падения и взлёты. Я постарался сделать наиболее точный перевод, но тем не менее полностью от англицизмов и слэнга избавиться не смог.

Итак под катом история моего коллеги длиной в 10 лет.

Разработка мобильных игр — отрасль с очень высокой конкуренцией. Миллионы игр в Google Play и Apple Store, позабытые пользователями сразу после запуска, и редкие истории успеха тому свидетельство. В очередном посте блога «Менеджмент игровых интернет-проектов» мы перевели статью разработчика игр Росса Пшибыльски (Ross Przybylski) о расчёте потенциального дохода мобильных игр F2P. За свою десятилетнюю карьеру Росс успел набраться опыта и в инди-студиях (D20Studios), и в крупных AAA-компаниях (EA).

Когортный анализ — метод анализа эффективности бизнеса. Суть состоит в том, чтобы анализировать поведение групп людей, объединенных по какому-либо признаку во времени.

Оценка продукта происходит не по итоговой метрике, а по каждой отдельной когорте этой метрики. Когорта — группа людей, которые сделали одно и то же действие в определенный период времени.

16 сентября 2007 года японский ютубер под ником Computing Aesthetic загрузил 48-секундное видео с громким названием «ULTRA MEGA SUPER LUCKY SHOT» («УЛЬТРАМЕГАСУПЕРУДАЧНЫЙ ВЫСТРЕЛ»). В видео показан сверхрезультативный выстрел в популярной игре Peggle, частично основанной на принципе японских автоматов для пачинко. В этой игре шарик летает по экрану, зарабатывая очки при ударах об разноцветные штырьки, которые после удара почти сразу исчезают; чем больше ударов, тем больше очков. Хотя в Peggle и требуется мастерство — перед выстрелом игрок должен точно прицелиться — принципиально игра зависит от удачности отскоков шарика. В видео Computing Aesthetic игрок зарабатывает огромное количество очков благодаря удачным отскокам между штырьками. Чтобы подчеркнуть кажущуюся удачность выстрела, игра до последних кадров видео проигрывает эйфорическую «Оду к радости» Бетховена, после чего шарик падает в лунку внизу игрового поля и на экране появляется мерцающая надпись «FEVER SCORE». В описании к видео, просмотренному почти четверть миллиона раз, написано «I couldn’t balieve this when it happened!!!!!!!!!» («Не могу паверить, что это случилось!!!»)

Создание игры с нуля за 48 часов… что может быть утомительней, но в тоже время это прекрасный способ встряхнуть свой творческий потенциал. Вы можете создать что-то поистине новое, чего бы никогда не достигли в ходе обычного процесса разработки. Некоторые из этих не огранённых алмазов дошли до полноценного релиза (оригинальная статья 2015 года, на данный момент почти все игры поступили в продажу, – прим. переводчика). В статье будет рассмотрена парочка таких проектов.

Из каждой истории вы может извлечь что-то новое в плане маркетинга, дизайн и т.д.

На Хабре можно почитать статьи от участников подобных джемов:

• Статья от V0odo0 об участии в Ludum Dare #37.
• От mr_sw публикация об участии в Global Game Jam 2015.
• От Wargaming статья о Global Game Jam 2015 в Минске.
• От PatientZero перевод статьи о Gen Jam 2016 (геймджем по процедурной генерации). У этого автора так же много переводов других статей о геймдеве. Советую подписаться.

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

Алексей Еремихин ( alexxz )

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

Структура доклада следующая. Я расскажу:

• какие задачи я предлагаю решать с помощью Hadoop на начальных этапах,
  
• что такое Hadoop,
  
• как он устроен внутри,
  
• что есть вокруг него,
  
• как Hadoop применяется в Badoo в рамках решения задач с первого пункта.
  

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

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

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

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

Будем рассматривать стандартные встроенные коллекционные типы данных в Python: список (list), кортеж (tuple), строку (string), множества (set, frozenset), словарь (dict). Коллекции из модуля collections рассматриваться не будут, хотя многое из статьи должно быть применимым и при работе с ними.

ОГЛАВЛЕНИЕ:

1. Классификация коллекций;
2. Общие подходы к работе с коллекциями;
3. Общие методы для части коллекций;
4. Конвертирование коллекций.

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