Сегодня мы представляем вашему вниманию адаптированную подборку инструментов (в том числе облачных) для разработчиков, которые позволяют создавать по-настоящему качественные проекты. Здесь представлены исключительно SaaS, PaaS и IaaS сервисы, предоставляющие бесплатные пакеты для разработчиков инфраструктурного ПО.

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

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

На протяжении 4-х лет у нас выработался следующий формат команды разработки:

• 1 Project Manager, он же Product Manager, он же Delivery Manager.
• 4-5 программистов
• 1 Team lead
• 3-4 QA
• 1 Аналитик
• 1 Техпис (иногда он же и аналитик в одном лице).

В итоге команда размером около 10-11 человек. Таких команд (ячеек) у нас несколько.

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

Начинал в этой системе я как программист, потом Team lead, ну а теперь PM (DM). Т.е. руковожу, полностью участвую в проектировании и иногда даже пописываю. Во времена моего программирования у меня был замечательный ПМ (выходец из тестировщиков), которая поддерживала все мои идеи по автоматизации workflow. Даже более того, концептуально этот процесс придуман ей, а я уже смог его технически реализовать и в некоторых местах усовершенствовать.

Итак, после долгих трудов и размышлений, чтения статей, может быть даже моей предыдущей, после анализа опыта конкурентов, общения с коллегами-геймдизайнерами за чашечкой кофе (или кружкой пива?), прототипов и итераций — дизайн-документ небольшой фичи или целой игры готов. Победа?! Как бы не так.

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

После моего грандиозного тестирования батареек многие просили провести такие же основательные тесты NiMh-аккумуляторов. За четыре месяца я протестировал 198 аккумуляторов (44 модели AA и 35 моделей AAA).

Привет, Хабр! Я Андрей Фролов, ведущий программист, работаю в Mail.Ru над Next-Gen MMORPG Skyforge. Вы могли читать мою статью про архитектуру баз данных в онлайн-играх. Сегодня я буду раскрывать секреты, касающиеся устройства сервера Skyforge. Постараюсь рассказать максимально подробно, с примерами, а также объясню, почему было принято то или иное архитектурное решение. По нашему серверу без преувеличения можно написать целую книгу, поэтому для того, чтобы уложиться в статью, мне придется пройтись только по основным моментам.

“Толстые” стрелочные функции (=>), так же известные, как arrow функции – абсолютно новая функциональность в ECMAScript 2015 (ранее известном под именем ES6). Если верить слухам, то в ECMAScript 2015 => синтаксис стал использоваться вместо –> синтаксиса под влиянием CoffeeScript. Так же, не последнюю роль сыграла похожесть передачи контекста this.

У стрелочных функций есть две главные задачи: обеспечить более лаконичный синтаксис; обеспечить передачу лексического this с родительским scope. Давайте детально рассмотрим каждую из них!

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

Мы в Хекслете используем JavaScript не только для очевидных задач во фронтэнде, но и, например, для реализации браузерной среды разработки (наш опен-сорсный hexlet-ide) на React'е. У нас есть практический курс по JavaScript, и один из уроков там посвящен замыканиям. Это важная тема не столько в рамках JS, сколько в программировании вообще. Мы освещаем ее и в других курсах.

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

Я использую замыкания уже достаточно давно. Я научился их использовать, но не до конца понимал как они на самом деле работают, что происходит «под капотом». Что это вообще такое? Википедия не очень помогает. Когда замыкание создается и уничтожается? Как выглядит реализация?

"use strict";
 
var myClosure = (function outerFunction() {
 
  var hidden = 1;
 
  return {
    inc: function innerFunction() {
      return hidden++;
    }
  };
 
}());
 
myClosure.inc();  // возвращает 1
myClosure.inc();  // возвращает 2
myClosure.inc();  // возвращает 3
 
// Ага, круто. А как это реализовано?
// И что происходит под капотом?

Давным-давно я имел радость играть в замечательнейшую RTS под названием «Периметр: Геометрия Воины» от отечественного разработчика K-D Labs. Это игра о том, как огромные летающие города под названием «Фреймы» бороздят просторы «Спанджа» — цепи соединенных между собой миров. Сюжет достаточно странный и абстрактный, но гораздо более интересной и инновационной составляющей игры была одна из ее технических особенностей, а не сюжет. В отличие от большинства RTS, где сражения происходят на статической местности, в «Периметре», одной из ключевых игровых механик был терраформинг. У игрока были средства манипулировать ландшафтом с целью возведения на нем своих сооружений а также целый арсенал боевых единиц, способных этот ландшафт превратить в потрескавшийся, поплывший и изрыгающий раскаленные камни/противных насекомых ужас.

Как известно, мир RTS нынче переживает некоторый упадок. Инди-разработчики слишком заняты тем, что клепают ретро-платформеры и rouge-like игры зубодробительной сложности, и поэтому, переиграв в «Периметр» некоторое время назад я решил, что должен и сам попробовать реализовать что-то подобное — идея была интересной и с технической и с геймплейной точек зрения. Обладая некоторым практическим опытом в разработке игр (ранее я совершал попытки сделать кое-что на XNA), я подумал, что чтобы добиться хоть какого-то успеха в одиночку мне придется воспользоваться чем нибудь более высокоуровневым и простым. Выбор мой пал на Unity 3D, чья пятая версия только-только вышла из под пресса.

Вооруженный вагоном энтузиазма, вдохновением от только что пройденного «Периметра» и просмотренной серией видеотуториалов по Unity, я начал делать наброски и знакомиться с инструментарием, который мне предложил Unity Editor.

Общие принципы

1. Задания создаются и пишутся для удобства исполнителей.
2. Результатом работы геймдизанеров являются полные и понятные даже новичкам задания.
3. Исполнители читают задания и меняют их статус. (они пишут код, а не задания)
4. Долго висящие задачи — удаляются (надо будет — еще раз заведем)

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

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

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

• Интересной.
• С простым порогом входа.
• Реалистичной для задач погружения.

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

Внимание, ниже немного спойлеров и много скриншотов (трафик).

В приложениях Windows Store жизненный цикл довольно похож на картинку. Он довольно простой и содержит всего 3 состояния: NotRunning – Running – Suspended

Для себя я мысленно отождествляю его с «Не копать – Копать – Перекур». Опытные работяги знают, что с перекура к работе можно уже не вернуться. Опытные разработчики сохраняют состояние приложения при событии Suspending и возвращают его впоследствии в исходное состояние при возобновлении работы приложения.

В приложениях Windows UWP (Windows 10) все точно так же, но появились новые фичи.

Привет, представляю твоему вниманию перевод статьи Моники Динкулеску '<input> I ♡ you, but you're bringing me down'. Художественный перевод с английского не является моей основной специализацией, поэтому в тексте возможны неточности. Правки призываю отправлять личным сообщением, а если есть что сказать, велкам в комментарии. Отдельное спасибо @Kt за редакторские правки. Приятного чтения.


Некоторые люди делают мебель. Некоторые люди вяжут. Некоторые люди имеют хобби, которые никак не пересекаются с HTML спецификациям из 90-х. Но я не из таких. И, вот история о том, как <input> стал той хренью, которой он является, и почему его надо сжечь

Ранние годы

1995 был клевым годом. Друзья, Скорая Помощь, Зена по телеку. TLC занимали верхушки чартов с хитом "Waterfalls". С браузерами было нормуль, потому что HTML было все очень нормуль. У нас были Mosaic, Netscape и IE1, а при утверждении спеков HTML 2, наконец, выкроили время для стандартизации форм. Девяносто пятый был годом рождения <input>, и теперь, когда он достаточно взрослый, чтобы покупать в магазине алкоголь, нам нужно поговорить.

Разрешите представить вам перевод статьи Нолана Лоусона «У нас проблемы с промисами», одной из лучших по теме из тех, что мне доводилось читать.

У нас проблемы с промисами

Дорогие JavaScript разработчики, настал момент признать это — у нас проблемы с промисами.

Нет, не с самими промисами. Их реализация по спецификации A+ превосходна. Основная проблема, которая сама предстала передо мной за годы наблюдений за тем, как многие программисты борются с богатыми на промисы API, заключается в следующем:

— Многие из нас используют промисы без действительного их понимания.

Если вы мне не верите, решите такую задачку:

Вопрос: В чем разница между этими четырьмя вариантами использования промисов?

doSomething().then(function () {
  return doSomethingElse();
});

doSomething().then(function () {
  doSomethingElse();
});

doSomething().then(doSomethingElse());

doSomething().then(doSomethingElse);

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

В качестве вступления

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

Идея создания космической игры родилась довольно давно. Почему космической? Отчасти потому, что космическая тема всегда вызывала мой личный интерес, а отчасти, по причине ностальгических воспоминаний от приятного времяпрепровождения за «Космическими рейнджерами», когда-то в далеком прошлом…

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



Ты ведь любишь игры, не так ли? То, что ты видишь на КДПВ, называется FAR7. Чтобы было немного понятнее, скажу, что молодежь сравнивает её с Космическими Рейнджерами, те кто постарше, вспоминают StarControl2, а совсем уже хардкорные геймеры постоянно твердят об Elite. Сойдемся на том, что это браузерный космосим. В игре вы можете путешествовать между звездными системами, торговать, воевать и выполнять различные миссии.

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

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

Вычеркиваем

После непродолжительного подбора различных способов реализации, сразу были исключены варианты:

• с gif-анимацией (из-за низкого качества изображения);
• с Flash (по договоренности, Flash-технологии решили в проекте не использовать);
• с анимацией с помощью JQuery посредством функции $().animate (по причине ее прожорливости).

CANVAS в помощь!

Итак, остановились мы на использовании Canvas и JavaScript, посчитав этот вариант оптимальным для реализации нашей задачи.

Один технический специалист нашей компании PayOnline, которая занимается автоматизацией приема платежей, предложил перевести статью автора Pascal de Vink, который проработал тим-лидом уже 2 года. Когда Pascal только занял эту должность, оказалось, что ко многим вещам он был просто не готов. Эта статья поможет избежать многих ошибок на пути от разработчика к лидеру команды. Ниже идет непосредственно перевод.

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

Меньше заниматься разработкой

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

Если ты доделал свою первую игру, значит с тобой что-то не так.

Именно эта фраза, прочитанная в одном из постов, впечаталась в мою память 2 или 3 года назад. И автор был прав. Начав делать свой первый прототип, большинство разработчиков бросают его на пол пути и берутся за следующий по разным причинам.

Tabris.js — еще один кросс-платформенный (Android, IOS) мобильный фреймворк. От подавляющего большинства подобных инструментов он отличается тем, что это не обертка над стандартным или Chrome-based WebView. Tabris предоставляет собой набор нативных компонентов, доступный из javascript. Ближайшие аналоги из мне известных это: Telerik Native Script, Appcelerator и React Native.

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


^{На картинке — Scythe Susanoо, самый страшный из кулеров, что я видел. Соотношение эффективности и шума, к слову, так себе.}

Сколько производительности можно выжать, собираться ли в «полный пассив», или обойтись малошумящими вентиляторами, сколько стоит бесшумный системный блок построить и всё остальное — под катом.