Многие вставали перед выбором той или иной библиотеки для работы с формами в ReactJS. Когда я выбирал подходящую мне, разные библиотеки казались идеальными НО: форма на конфигах или колбеки в onSubmit эвенте, или асинхронный submit. Почему формы для реакта не соответствуют принципам реакта, почему они выглядят как что-то особенное? Если эти вопросы приходили вам в голову, или вы любите формы, приглашаю к прочтению статьи.

Всем привет.

slowpoke это key/value хранилище данных, написанное на стандартной библиотеке golang. Slowpoke обладает минималистичным, удобным апи и подходит для решения довольно широкого круга задач.

Записать значение в slowpoke можно при помощи команды Set:

slowpoke.Set("db/some.db", []byte("foo"), []byte("bar"))

Единицей хранения данных в slowpoke является файл. В данном примере — будет создана директория «db», с файлом «some.db», в который будет помещено три байта («bar»).

Буквально вчера вышла 2-я версия молодого, но весьма многообещающего фреймворка SvelteJS. Версия мажорная, а значит содержит не только новые фичи и исправленные баги, но и соответствующие «breaking changes». Что новенького предлагает разработчикам новая версия и почему Svelte стал еще лучше, читайте под катом.

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



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

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


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

В соревновании MiniAICup#2 Почти Agar IO надо управлять амёбами, есть еду и других амёб.
Для реализации алгоритма управления амёбой напрашиваются потенциальные поля, но есть одно большое НО.

Привет, Хабр! Представляю вашему вниманию перевод статьи "Redesigning Redux" автора Shawn McKay.

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

• Вам действительно необходима библиотека для управления состоянием?
• Заслужил ли Redux свою популярность? Почему или почему нет?
• Можем ли мы придумать лучшее решение? Если да, то какое?

Необходима ли библиотека для управления состоянием?

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

Давайте рассмотрим возможности, которые предоставляет нам React:

Привет, меня зовут Билл «LtRandolph» Кларк. Я работаю техническим руководителем команды создания чемпионов LoL. За последние несколько лет я успел поработать в разных отделах разработки League, но единственное, чем я был постоянно одержим — это технический долг. Мне нужно найти его, понять его и, при возможности, устранить его.

Когда разработчики обсуждают любую существующую технологию, например патч 8.4 League of Legends, то часто упоминают технический долг. Я называю техническим долгом код или данные, за которые придётся расплачиваться будущим разработчикам. Этой печальной стороне разработки ПО посвящено бесчисленное количество постов, статей и определений. В своём посте я хочу обсудить виды технического долга, с которыми мне пришлось встретиться при работе в Riot, и рассказать о модели, которую мы начали использовать в компании. Если бы меня попросили выделить самый важный урок, который можно извлечь из этой статьи, то я сказал бы, что это описанная ниже метрика «инфицирования».

Метрики

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

В конце прошлого года компания Red Hat опубликовала доклад с описанием принципов, которым должны соответствовать контейнеризированные приложения, стремящиеся к тому, чтобы стать органичной частью «облачного» мира: «Следование этим принципам обеспечит готовность приложений к автоматизируемости на таких платформах для облачных приложений, как Kubernetes», — считают в Red Hat. И мы, изучив этот документ, с их выводами согласны, а посему решили поделиться ими с русскоязычным ИТ-сообществом.



Обратите внимание, что эта статья является не дословным переводом оригинального документа (PDF), подготовленного Bilgin Ibryam — архитектором из Red Hat, активным участником нескольких проектов Apache и автором книг «Camel Design Patterns» и «Kubernetes Patterns», — а представляет основные его тезисы в довольно свободном изложении.

Введение

В этой серии туториалов мы рассмотрим создание завершённой игры с помощью Lua и LÖVE. Туториал предназначен для программистов, имеющих некоторый опыт, но только начинающих осваивать разработку игр, или для разработчиков игр, уже имевших опыт работы с другими языками или фреймворками, но желающими лучше узнать Lua или LÖVE.

Создаваемая нами игра будет сочетанием Bit Blaster XL и дерева пассивных навыков Path of Exile. Она достаточно проста, чтобы можно было рассмотреть её в нескольких статьях, не очень больших по объёму, но содержащих слишком большой объём знаний для новичка.


Кроме того, туториал имеет уровень сложности, не раскрываемый в большинстве туториалов по созданию игр. Большинство проблем, возникающих у новичков в разработке игр, связано с масштабом проекта. Обычно советуют начинать с малого и постепенно расширять объём. Хотя это и неплохая идея, но если вас интересуют такие проекты, которые никак нельзя сделать меньше, то в Интернете довольно мало ресурсов, способных вам помочь в решении встречаемых задач.

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

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

24 февраля мы устроили Go 1.10 Release Party @ Badoo по случаю свежего релиза. Спасибо всем, кто был с нами! Если вы пропустили встречу сообщества, под катом — видео выступлений, слайды, немного отзывов и фотоотчет.

TL;DR: в этих сериях вы узнаете, как заставить React и Redux управлять SVG элементами для создания игры. Полученные в этой серии знания позволят вам создавать анимацию не только для игр. Вы можете найти окончательный вариант исходного кода, разработанного в этой части, на GitHub

(третья часть заключительная. В ней помимо завершения разработки непосредственно игры, рассмотрена авторизация с помощью Auth0 и простой realtime-сервер — прим.переводчика)

Сегодня поговорим об атрибуте key в React. Часто разработчики, которые только начинают использовать React, не придают большого значения атрибуту key. А зря…

Что говорит уточка, когда узнала, что ты не используешь key

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

1. Reconciliation
2. Реиспользование ключей и нормализация
3. Использование key при рендере одного элемента
4. Работа с ключами при передаче компоненту children

TL;DR В статье описывается процесс создания системы контроля доступа (СКУД), в которой в качестве идентификатора могут использоваться карты Тройка, любые бесконтактные банковские карты EMV, а также телефоны с Apple Pay и Android Pay. Управление системой происходит через Telegram-бота.

Основные задачи системы

• Избавиться от лишних карт — в качестве идентификатора используется то, что уже есть у пользователя: транспортная карта, телефон или банковская карта. Какой идентификатор использовать — каждый выбирает сам. Система работает со всеми типами идентификаторов одновременно.
• Избавиться от бюро пропусков и сложных программ управления — нам надоело выдавать и забирать карты у пользователей, держать отдельные компьютеры для управления пропусками, изучать переусложненные программы.
• Управление через Telegram — заведение и удаления пользователей происходит удаленно и не требует компьютера.

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

В этой статье мы с нуля разработаем React-приложение, обсудим домен и его сервисы, хранение, сервисы приложения и представление (view).

Есть три типа наследования.

1. Онтологическое наследование указывает на специализацию: вот эта штука — специфическая разновидность той штуки (футбольный мяч — это сфера и у неё такой-то радиус).
2. Наследование абстрактного типа данных указывает на замещение: у этой штуки такие же свойства, как у той штуки, и такое-то поведение (это принцип подстановки Барбары Лисков).
3. Наследование реализации связано с совместным использованием кода: эта штука принимает некоторые свойства той штуки и переопределяет или дополняет их таким-то образом. Наследование в моей статье «О наследовании» именно такого и только такого типа.

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

Часто для наследования в ООП приводят контрпример отношений между квадратом и прямоугольником. Геометрически квадрат — это специализация прямоугольника: все квадраты — прямоугольники, но не все прямоугольники — квадраты. Все s в классе «Квадрат» являются прямоугольниками s, у которых длина равна ширине. Но в иерархии типов это отношение обратное: вы можете использовать прямоугольник везде, где используется квадрат (указав прямоугольник с одинаковой шириной и высотой), но нельзя использовать квадрат везде, где используется прямоугольник (например, вы не можете изменить длину и ширину).

Представляем вашему вниманию очень эмоциональный рассказ Льва Николаева (@maniaque) о том, как надо настраивать DNS и особенно, как делать не надо. Вот прямо после каждого пункта можете мысленно добавлять: «Пожалуйста, не делайте этого!» В своем докладе Лев так и говорит.

Статья будет состоять из трех частей:

1. Как сделать резольвер (unbound, bind)

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

2. Как держать зоны (PowerDNS)

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

3. Как взболтать, но не смешивать (PowerDNS + unbound)

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

Предыдущие части:

• Heisenbug 2017 Moscow (Тестирование)
• JBreak 2017 (Java)
• JPoint 2017 (Java)

На этот раз объектом изысканий будет HolyJS 2017 Moscow — известная JavaScript-конференция, четвёртая по счёту. Более 600 JS-разработчиков собрались под одной крышей для того, чтобы обсудить настоящее и будущее JavaScript-сообщества с мировыми экспертами: Douglas Crockford, Lea Verou, Martin Splitt и так далее.

Осторожно, трафик! В этом посте присутствует огромное количество картинок — слайдов и скриншотов с видео в формате 720p.

Disclaimer: Все описания являются моим личным мнением. Всё написанное — плод моего больного воображения, а не искажённые цитаты докладчиков (это предостережение написано для того, чтобы докладчики меня не побили).

На Хабре уже есть очень много интересных статей про создание игры с нуля, но мало статей, описывающих что делать, чтобы своя любимая поделка не превратилась во Франкенштейна и дошла до вменяемого состояния. Автор оригинальной статьи рассказывает, как эволюционировал код игрового движка от кучи хлама в основном цикле к продуманной, расширяемой архитектуре, использующей Entity Component System. В статье много кода, который почти весь часто повторяется — но я не стал его выбрасывать, поскольку с ним будет понятнее, какие изменения вносит автор и как это отражается на всей структуре. Статья рассчитана на новичков, вроде меня, которые уже настрочили несколько «гениальных» прототипов, но теперь не знают, как разобраться в их коде.