О, то есть читерство через консоль, получается, неограничено? :)
Валидация на сервере, на самом деле, крайне важная часть архитектуры. В идеале это должно выглядеть как «игрок посылает своё действие, сервер его обрабатывает и рассылает диффы игрокам», причём доступные действия выглядят как «иду налево» или «атакую вверх», самой своей формулировкой отсекая заранее читерские варианты (иду на такую-то клетку, например). Понятно что у вас проект ни на что особое (пока) не претендует, но если вы хотите чтобы в него играли массово, озаботиться валидацией придётся, потому как по закону подлости всегда найдётся какая-нибудь злобная редиска, которая будет портить игру другим.

У вас один игрок может изменять состояние второго игрока?.. А как вы это всё на сервере валидируете?

Раз у вас всё завязано на почте, лучше использовать почтовые сервисы, как упомянутый мною gmail. В таком случае никаких особых проблем тут не наблюдается — нажал на кнопку, подтвердил у гугла, если это первый вход — ввёл свой ник (с существующей уже валидацией) иначе просто сразу входишь. Со стороны сервера нужно только на каждый вход через кнопку сделать один запрос к гугл апи вида «у пользователя с вот таким токеном действительно вот такая почта?».

losfer, рекомендую прикрутить социальный логин, хотя бы по тому же гмейлу.

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

Слак просто лучше, вот и всё. Жаббер, скайп — одна знакомая группа креативных товарищей для коммуникации пользовалась сначала тем, потом другим; но после перехода на слак даже сама мысль перейти на что-нибудь другое кажется абсолютно глупой, настолько хорошо он закрывает все потребности. Одни только кастомные смайлы чего стоят :)

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

Больше, больше Грэма! Что его, что Спольски читать — одно удовольствие.

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

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

Асинхронность-то ладно, с async/await жить прекрасно.
Самые основные, коренные ошибки в JS — это undefined и «всё — словарь». Это те вещи, которые невозможно исправить, родовые травмы, ошибки в самой концепции. Из-за них весь язык перекошен похуже квазимодо и вынужден подпирать себя костылями для сохранения дееспособности.
Чрезвычайно слабая типизация — это косяк чуть меньший, но тоже достаточно эпичный. Впрочем, с ней можно практически не сталкиваться, даже если третье равно не ставить ;)
Про всякие мелочи я говорить не буду, хотя должен заметить что ситуация с this меня весьма печалит.

По-моему тут куда лучше было бы условие написать честно, i%3 == 0. Читаемость значительно повысится, а символов печатать всего на два пробела больше.

Всегда к вашим услугам )

Мне кажется, одна из основных причин тут — та самая демократия. Самый лучший дизайн что я видел в сфере IT — это Python и nginx и они оба имеют своих диктаторов. Я считаю что в сфере проектирования крайне важно найти человека с хорошим дизайнерским чутьём, за которым всегда будет последнее слово; возможно, это несколько замедлит развитие, но конечный продукт будет целостен и логичен. Как антипример можно привести, допустим, Javascript или PHP, где никого подобного не было; в результате получились плохо спроектированные языки, которые до сих пор борются сами с собой.

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

В самом конце есть:

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

Стоило бы наверно написать предупреждение о регэксах? Ну, то самое, которое «если у вас есть проблема».

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

Вот правильная ссылка, ваша ведёт на главную, https://github.com/VirgilSecurity

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

Вообще, мне интересно: возможен ли перенос концепции реактивности на уровень железа? Впрочем, понятно что возможно всё; правильней сказать, имеет ли это практический смысл, ускорит это программы и упростит ли жизнь программистам?