Первое мое знакомство с Mobx началось с удивления. Я не понимал всю магию библиотеки и задавал себе вопрос: “А как это возможно?”. Кажется, в ней используются какие-то подкапотные возможности JS или Mobx вообще написан на другом языке. 

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

В этой статье мы создадим свой Mobx с нуля, а так же свяжем его с React, через собственно написанный HOC observer. В конце у вас будет общее понимание реактивности, которое поможет в самостоятельном осмыслении не только Mobx, но и других реактивных библиотек и фреймворков.

Привет, друзья!

Radash — это современная альтернатива Lodash, библиотека, предоставляющая набор часто используемых утилит (вспомогательных функций), реализованных на TypeScript. В данной статье мы вместе с вами разберем исходный код нескольких наиболее интересных утилит.

Репозиторий с кодом библиотеки находится здесь.

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

Для тех, кому интересно, вот большая коллекция сниппетов JavaScript.

Начнем с чего-нибудь попроще.

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

Как я уже писал ранее, на FPS в Flame в основном влияют операции, производимые на CPU. Если в вашей игре достаточно много взаимодействующих объектов, то одной из самых дорогих операций будет определение столкновений. Настолько дорогой, что на экране performance-метрики она закроет собой любые другие неоптимизированные участки.

Сами авторы Flame отлично осознают, что их алгоритм – не идеальный, а просто «дающий достаточную производительность». Достаточна она, видимо, для случаев, когда у вас всего объектов 10, не более. Если же у вас что-то более сложное – тогда приятного чтения!

Заблуждение 1. Форма Земли — это просто

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

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

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

Урок Серия уроков будет посвящена созданию простой RPG в 1bit пиксель-арт стиле, где я постараюсь рассмотреть всю ту боль и страдания, с которыми обычно встречаются новички - джиттер, расплывающиеся пиксели, борьба с разрешением и прочее.

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

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

О том как устроен прототип arpg Spheramyd и практиках использования игрового движка.

В предыдущей статье я разбирал проблемы Bonfire и причины, по которым он не очень подходит для сложных игр. Несмотря на то, что чистый Flame намного легче, там тоже не всё так гладко. В этой статье я поделюсь своими рецептами увеличения производительности игры и распишу причины, почему это работает. Хочу сразу заметить, что среди этих рецептов нет серебряных пуль, и маловероятно получить существенный буст, применив только что-то одно. Однако в комплексе они достаточно эффективно работают – проверено часами медитации над CPU-профайлером.

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

Вся логика будет разбита на слои. Основной смысл слоев тот, что классы одного слоя максимально независимы от классов с соседних слоев и абсолютно независимы от остальных. Все это уже относится не к основному фреймворку (Core Framework), а к фреймворкам для разных групп жанров (Base Game Frameworks) и для каждого отдельного жанра (Game Frameworks).

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

То, что начиналось как: «Окей, гугл, какой парсер выбрать?», – вылилось в полноценное исследование существующих реализаций парсеров.

О том, какие открытия меня ждали на этом пути, и будет данная статья.

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

По ссылке "Когда нужно MVC, как сделать Binding визуальных контроллов с методом (UNITY, C#, Разработка игр)" вы можете послушать меня, а кто хочет почитать прошу подкат.

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

Statoscope — это инструмент для анализа webpack-бандлов, а я его автор и мейнтейнер. Он зародился в далеком 2016 году как эксперимент, а теперь это полноценный тулкит для просмотра, анализа и валидации сборки.

В ноябре на конференции HolyJS я выступил с докладом о Statoscope и провёл воркшоп по его использованию. Зрителям понравилось, так что мы с организаторами HolyJS решили, что доклад может пригодиться и читателям Хабра — поэтому сделали текстовую версию. Видеозапись тоже прилагаем.

Содержание

• Новая парадигма объектно-реляционного отображения
• Готовность к эксплуатации в критически важных приложениях
• Prisma может быть использовано в любом стеке
• Открытый исходный код и не только
• Как мы можем вам помочь?
• Начало работы с Prisma
• Приходите ради ORM, оставайтесь ради сообщества ?

Новая парадигма для объектно-реляционного отображения

• Prisma Client: Автогенерируемый и типобезопасный клиент базы данных
• Prisma Migrate: Декларативное моделирование данных и миграции с возможностью пользовательского редактирования
• Prisma Studio: Современный пользовательский интерфейс для просмотра и редактирования данных

продолжение TypeScript Native (AOT) Compiler

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

Наиболее успешным результатом подобной работы оказался Backbone.js — объектно-ориентированный MVC-фреймворк, который в свое время использовался в BitBucket, Basecamp, Stripe, Airbnb и Trello. Со временем он был полностью вытеснен следующим поколением фреймворков, но...

Что если бы этого не случилось? Как бы тогда выглядела современная разработка веб-интерфейсов?