Статистика - telemetr.me | tgstat.ru
Условия:
1. Топ не менее 4 часов / 4 дня в ленте - 7500 рублей
2. Топ не менее 4 часов / неделю в ленте - 8500 рублей

Data Science [ru]

Статистика - telemetr.me
Условия - Топ не менее 4 часов, в ленте 7 дней
Стоимость - 2000 рублей

В рекламном посту не должно быть нецензурной лексики.

Реквизиты:

1. Тинькоф: 5536 9137 7308 3254
2. Yandex: 410013454525609

Возможна оплата через счет самозанятого

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

Сидеть — вредно

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

Для программистов это почти приговор, ведь писать код (а это наша работа и наша страсть) — значит сидеть за компьютером. Но последствий сидячей работы можно избежать: достаточно каждый час делать пятиминутный перерыв на физическую активность. Чтобы улучшить обмен веществ, достаточно просто пройтись до уборной.

Нам нравится неправильно питаться

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

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

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

диабет 2-го типа

. Снизьте потребление жирной пищи, которая повышает уровень холестерина и

триглицеридов

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

Ой! Спина болит!

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

Проверить силу спинных мышц можно с помощью упражнения из теста

Крауса — Вебера

.

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

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

Боль в запястьях

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

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

регулярным деформационным травмам

. Чтобы избавиться от боли в запястьях, достаточно ежедневно выполнять простые упражнения. Подробнее —

здесь

.

Упражнения на запястье. Источник изображения — sequencewiz.org.

Головная боль и напряжение глаз

Программирование — это во многом творчество, а головные боли — одна из основных причин снижения эффективности работы. В большинстве своем головные боли напрямую связаны со зрением. Самое распространенное заболевание (им страдают более 80 % людей, ежедневно проводящих за компьютером более 3 часов) —

синдром компьютерного зрения

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

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

Следующий список поможет проверить, достаточно ли вы заботитесь о своем зрении:

• Насколько близко к экрану вы сидите? Монитор должен находиться на расстоянии 0,5–1 м от глаз — это примерно длина вытянутой руки, так что здесь проверить довольно легко.
• Насколько экран компьютера ярче, чем освещение в комнате? Большая разница между яркостью экрана и освещенностью помещения быстро утомляет глаза. Если в кабинете естественное освещение, яркость дисплея должна в течение дня регулироваться. Для этого можно установить f.lux — это приложение будет автоматически изменять яркость экрана и температуру цвета в течение д��я (достаточно указать свои географические координаты).
  

f.lux в действии

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

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

• Моргайте глазами чаще. При работе за компьютером мы обычно моргаем реже и даже можем так сосредотачиваться, что забываем моргать. Моргание не дает глазам пересыхать. Подробнее можно прочитать в этом исследовании.
  
• Если надолго сфокусироваться на чем-то одном, глаза устают. Размять мышцы глаз можно, отведя на некоторое время взгляд в сторону. Здесь отлично работает следующая рекомендация: после 20 минут работы отведите взгляд от компьютера и в течение 20 секунд смотрите на удаленный предмет на расстоянии не менее 6 метров.
  
• Чтобы уменьшить блики и снизить напряжение глаз, носите антибликовые поляризованные линзы: они эффективно снимают раздражение, снижают сухость и утомляемость.
  

Чтобы избежать головной боли, потребляйте меньше кофеина и

ферментированных продуктов

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

Заключение

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

Стоимость и правила рекламного поста на канале Frontender’s notes

Топ не менее 20 часов, с ленты не удаляется – 2500 рублей

В канале не размещается: рекламные посты порно, казино, пирамид и МЛМ.

В рекламном посту не должно быть нецензурной лексики.

Отзывы о рекламе: https://t.me/frontfeeds

Контакты:

1. Администратор - @g_abashkin
2. Менеджер - @my_little_trump
3. Email:      frontender-notes@mail.ru
4. VK:          https://vk.com/abaha91

Реквизиты:

1. Сбербанк: 4276 5500 9783 5196
2. Тинькоф:   5536 9137 7308 3254
3. Yandex:      410013454525609
4. Qiwi: По запросу
5. Webmoney: R208459710782

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

Меня зовут Костя, и я работаю в QIWI почти 4 года. Сегодня расскажу вам, как успешно перешел из frontend-разработки в backend.

Frontend

В QIWI я с конца 2014 года, начинал работать как разработчик iOS–приложений, и, в принципе, пару лет занимался разработкой QIWI-кошелька. При этом не могу сказать, что было скучно – задачи были довольно разные и в рамках одного приложения: мы занимались интеграцией кошелька с другими нашими сервисами, чинили баги, подтягивали анимацию. Кроме этого, был занятный опыт по созданию приложения для Apple Watch. Потом немного расширил фокус и поработал еще и над iOS-приложением для «Совести».

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

Но в бэкенде на то время было слишком мало разработчиков и слишком здоровенный бэклог, так что в итоге я все же переключился на бэкенд полностью. То, что я делаю сейчас, это классические задачи бэкендера – пишу код в наших микросервисах, чиню баги, занимаюсь рефакторингом, постигаю Kotlin. Есть возможность работать и над свежим продуктом компании – QIWI Инвестор.

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

Так что тут сложилась win-win ситуация – я хотел помочь команде и продукту (перевес в разработке был сильно не в сторону бэкендеров) и набраться новых знаний. Тимлиды все поняли и отпустили меня без каких-то претензий, продакт тоже.

Кроме этого, знания хотелось именно диверсифицировать, чтобы не привязываться к одной платформе (Android мне немного не по душе, но и Apple все же сдает позиции). Ну и было желание в случае чего уметь взять и сделать себе приложение самому (и фронт, и бэк), если вдруг появится какая-то клевая идея. Пока вот не пригодилось, правда.

Backend

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

Никого не раздражало, что первое время я явно работал не так эффективно, потому что во многое надо было въезжать (но в долгосрочной перспективе команда-то все равно в выигрыше).

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

Впечатления от бэкенда после фронтенда

Нет работы с UI. Вообще. Раньше приходилось убивать время на исправление багов в UI, сейчас – нет. Минусы такого положения – конечный пользователь не видит результатов конкретно моей работы, как это было с фронтом. Я пытался определить, что же сложнее – бэк или фронт, и понял, что (лично для меня) тяжелее всегда было работать с многопоточностью и сетевым стеком. И тут уже не так важно – за фронт ты или за бэк. На фронте я просто столкнулся с такими задачами впервые, без подготовки, а на бэкенде уже с каким-никаким опытом.

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

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

Что в итоге

Backend-разработка стала для меня еще одним хорошим опытом – я научился писать код и проводить ревью, продумывать архитектуру. Это на самом деле интересно.

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

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

1. Помни о целях своего приложения

На любых стадиях разработки помни о цели приложения, которая заключается в помощи людям.

Цель приложения – это не хвастовство своими знаниями.

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

Принимай решения о приложении с вопросом: как мы можем помочь? Этим же вопросом легко расставлять приоритеты.

2. Выбирай технологии правильно

Не опирайся на внешние технологии или уменьшай зависимость от них.

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

Вот несколько факторов, которые помогут определиться:

• Технология находится в активной разработке?
• Поддерживается разработчиками?
• Сложно ли отказаться от неё?
• Что говорит сообщество?

Найдёшь правильные ответы – снизишь риск выбора неподходящей технологии.

3. Не изобретай… сам знаешь что

Услышав советы вроде «Давай сделаем собственный сборщик мусора вместо встроенного по умолчанию?!», знай, что это трата времени впустую. Вместо этого займись непосредственно программой.

Вот единственные причины, оправдывающие «изобретение велосипеда»:

• Тебе нужно что-то, чего ещё не существует.
• Все существующие «велосипеды» плохи, и не покрывают твои нужды.
• Существующие «велосипеды» не поддерживаются разработчиками.

Простое правило:

Не изобретай велосипед.

4. Будь последовательным

Последовательность упрощает проект. Придерживайся одного способа реализации во всех местах. Назвал переменную thisIsVariable? Тогда называй таким образом все переменные (otherVariable, anAnotherVariable, и не other_variable).

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

Этот практический совет помогает мыслить как программист – упорядочено.

5. Автоматизируй

Не трать своё время на рутину. Настрой и забудь. Повторяющиеся задачи могут выполняться в фоне, пока ты спишь. Когда понимаешь, что делаешь что-то снова и снова, вспомни правило:

Автоматизируй то, что можешь.

Читай книгу «Автоматизация рутинных задач с помощью Python». С ней ты заставишь компьютер выполнять за тебя поиск определённого текста в файлах, обновление и форматирование данных в электронных таблицах и прочие рутинные задачи.

6. Контролируй сложность

«Управление сложностью – это сущность компьютерного программирования» – Брайан Керниган.

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

Это ещё не конец.

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

Переписывание кода с нуля.

Неважно, как ты попал в этот кошмар. Главное – как его предотвратить?

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

Сопротивление – нормальная реакция разработчика на требования внести (необязательные) изменения. Защищай свой код и требуй убедить тебя в необходимости изменений прежде, чем вносить их.

И это не единственные причины роста сложности. Скажем проще:

Контролируй сложность, не создавай.

7. Умей просить о помощи

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

Не можешь ничего придумать? Ищи! Проверь найденные ответы и адаптируй под свой код. Пойми, почему они работают.

А главное, ищи совета.

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

8. Довольствуйся просто хорошим

«Совершенное – враг хорошего» – Вольтер.

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

Напоминаем тебе:

• Ты будешь писать ненужный код
• Ты усложнишь систему необязательным кодом
• У тебя не будет дедлайнов
• Ты будешь встречать баги из-за сложности

Не очень заманчиво? Тогда разберёмся, что делать.

Начинай с малого, улучшай, расширяй.

Итеративная разработка – это твой гайд. Рассмотрим на примере с калькулятором:

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

9. Практикуйся

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

Начни со своего круга общения. Люди, связанные с разработкой, помогут увлечь твоё сознание. Можно сказать, что сообщество программистов «делает» программистов.

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

10. Тестируй

Добавляй логирование и обработку ошибок на ранних этапах. Это облегчит поиск проблем и сэкономит время.

В тестах тоже допускают ошибки. Давай рассмотрим пример с простым условием if-else. Разработчики подают входные данные в блок if, затем тестируют и коммитят. Сделано! А что насчёт блока else? Когда код дошёл до продакшена, это вызвало много проблем. Запускай все новые строки и тестируй частями прежде, чем перейти ко всему коду.

Видишь баг – воспроизведи его. Не нужно строить догадки о причине бага и фиксить исходя из своих предположений. Увидишь причину бага – не ошибёшься.

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

Не тестированный код = неработающий код.

11. Документируй, комментируй

Неправильное представление о комментариях в коде приводит к тому, что разработчик начинает объяснять в них то, что делает код. Работа кода должна быть очевидна при чтении. Не очевидна? Значит, код или фрагмент нечитаемы и должны быть упрощены.

Не можешь упростить? Тогда объясняй эту сложность в комментариях.

Не пиши комменты о том, что делает код, объясняй для чего он это делает.

Ещё одна важная вещь – документирование. Важно иметь документацию, которая объясняет архитектуру твоего приложения, каждый модуль и компонент. Это необходимо для высокоуровневого видения программы.

Мыслить как программист – это также уметь объяснять.

12. Поддерживай код

Быстрый код и запуск выглядят важнее поддержки и обслуживания кода. И это ошибка, которая сказывается в будущем.

Реализация будет меняться всегда. Мало вносить изменения, их нужно поддерживать со временем.

Все изменения требуют обслуживания

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

Важнее снизить сложность поддержки, чем сложность реализации.

Ответственность за свой код научит тебя мыслить как программист.

13. Изучай математику чтобы мыслить как программист

Математика нужна программисту не меньше, чем кассиру.

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

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

Полезные книги:

• The Art of Computer Programming: Volume 1: Fundamental Algorithms – несмотря на упоминания алгоритмов, книга содержит необходимый математический минимум для программиста.
• Конкретная математика – практическая книга математики для программистов.
• Удовольствие от X – книга для широкого круга читателей, которые упустили математику в своё время.
• Апология математики – ещё одна книга из серии «математика для нематематиков».
• Линейная алгебра и аналитическая геометрия – эта книга для тех, кто не хочет читать всё вышеперечисленное, а хочет ограничиться исключительно «боевыми» знаниями.

14. Найди свой подход

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

Хочешь пойти традиционным путём? Изучай объектно-ориентированное программирование и меняй своё мышление книгой Объектно-ориентированное мышление.

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

Источник

При детальном рассмотрении можно выявить предоставляемые движками дополнительные возможности: упрощение некоторых часто встречающихся задач или подгрузка ресурсов, оформленный ввод, физика, звук, bitmap’ы (таких, конечно же, немного). Есть и довольно слабо оформленные движки, а есть и те, которые предоставляют в пользование разработчику редактор 2D уровней и инструменты отладки.

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

Итак, вот, собственно, сами движки.

Crafty

Легкий модульный игровой движок, включающий множество функций: анимацию, управление событиями, перерисовку регионов, отслеживание пересечений и столкновений, спрайтовую графику и многое другое. Поддерживает все браузеры, в т.ч. IE9. Никаких дополнительных усилий прилагать не требуется.

Quintus

Quintus – игровой HTML5-движок, разработанный, чтобы быть модульным и легковесным, с четким JavaScript-подобным интерфейсом. Для того, чтобы реализовать основные особенности ООП-игрового движка в HTML5-движке, в Quintus в некотором отношении схож с jQuery, а также поддерживает плагины, управление событиями и гибкую модель наследования, чтобы упростить повторное использование реализованных функций.

gameQuery

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

GMP

Идеально подойдет для реализации 2D спрайтовых аркад в ретро-стиле и головоломок вроде Судоку. Он имеет готовый к использованию самозапускающийся игровой цикл. Поддерживаются мышь и клавиатура. Отлично документирован, и главным недостатком можно считать только отсутствие поддержки звуков.

lycheeJS

Игровая библиотека JavaScript, которая предлагает готовое решение для проектирования и реализации HTML5 Canvas и WebGL или нативных OpenGL игр внутри браузера или стационарных платформ. Оптимизирован для Google Chrome.

Enchant.js

Фреймворк Enchant.js для HTML5+JavaScript игр был разработан в 2011 году, распространяется с открытым исходным кодом (MIT лицензия) и потому бесплатен.

The Render Engine

Кросс-браузерный опенсорсный движок, написанный полностью на JavаScript. Созданный с нуля для того, чтобы быть максимально гибким, он имеет обширный API и использует самые новые фичи современных браузеров. Этот фреймворк предназначен, чтобы делать все за вас: ваша идея – его реализация с помощью самых часто используемых инструментов.

GameJS

Большая библиотека на верхнем уровне HTML Canvas. В добавок к функциям рисования в ней имеется растущий ассортимент полезных для разработки игр модулей. Большинство имеющегося API основан на популярной PyGame.

CSS Game Engine

Для формирования страницы используются JavaScript и CSS. Вместе они работают достаточно уверенно и слаженно. Разработан для новичков, обучающихся азам программирования видеоигр. Вам будет проще, если у вас уже есть какие-то навыки работы с CSS.

ClanFX

clanfx основан на JavaScript и CSS и использует плиточную графику. Работает на данный момент в Firefox, Epiphany и Opera. Среди реализованных фич: анимированные спрайты, эффекты заклинаний, постройки, плитки/текстуры и базовый искусственный интеллект.

gTile

Браузерный движок на чистом JavaScript и DHTML. В gTile плиточная графика была выбрана за ее простоту и доступность. Упор в реализации был сделан на высокий уровень интерактивности и поведении игровых объектов. Меньшее внимание было уделено графике. А потому движок подойдет больше для создания текстовых РПГ, а графических возможностей должно хватить для изображения локаций.

J5g3

Графический JS движок с открытым исходным кодом (GPLv3). Легкий в использовании синтаксис предназначен для того, чтобы сделать фреймворк быстрым и расширяемым.

Jaws

2D игровая библиотека, основанная на HTML5. Использует и Canvas, и средства DOM.

Cocos2D

Портированный с iPhone графический 2D HTML5-движок на JavaScript. Позволяет быстро создавать 2D игры и графические приложения, которые могут работать на всех современных устройствах без установки дополнительных плагинов.

CopperLicht

WebGL библиотека и JavaScript 3D движок для создания браузерных игр и 3D приложений. Использует WebGL Canvas, поддерживаемый современными браузерами и способный поддерживать рендеринг 3D моделей, используя аппаратное ускорение без плагинов.

Aves

Этот HTML/JavaScript движок – реинкарнация набора инструментов для разработки олдскульных RPG (но с более привлека��ельной графикой). И все только с помощью HTML и JS. Никаких плагинов. Никакого Flash.

LimeJS

HTML5 движок для разработки игр с поддержкой сенсорного ввода. LimeJS создан с использованием Closure Library, созданной Google, и в нем уже реализованы классы и функции для отслеживания времени, событий, обработки форм и анимации. Также фреймворк поддерживает спрайтовые листы (т.е. все используемые изображения могут быть помещены в один файл).

Phaser

Ещё один фреймворк для создания мобильных и десктопных игр на HTML5 с применением Canvas и WebGL. Бесплатный и с открытым исходным кодом. Есть быстрые гайды для старта на JavaScript и TypeScript.