Итоги 2020 года для меня и блога

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

Далее

Поругайте (или похвалите) меня

Но лучше всё-таки поругайте. Похвалить я и сам могу ;-)

Бложику нужна обратная связь от читателей.

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

А, и самое главное — блог читают о_О Привет читатели!

Чтобы и мне и бложику развиваться дальше, необходимо исправлять слабые места и находить новые возможности. Некоторые вещи я вижу, но определённо не все и не в том свете, в котором видите вы.

Поэтому я буду очень благодарен за пару слов с критикой или советами от вас мне:

• как сделать бложик лучше;
• как не сделать хуже;
• о чём писать, о чём не писать;
• и так далее…

Пишите где вам удобно: в комментариях к посту, в телеграмме, в facebook, на почту, etc.

Заодно, принимаю заказы на посты. Пишите интересующие вас темы, постараюсь их раскрыть, если получится :-)

Пространство механик ММО

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

Идея в следующем.

Чтобы игра была долго интересна целевой аудитории, её механики должны закрывать некоторый набор потребностей игроков.

Самый простой пример — психотипы Бартла. Планируя механики для игры, необходимо позаботиться, чтобы они закрывали потребности каждого психотипа. В идеале. То есть нужны механики для achievers, killers, socializers и explorers. Не обязательно по одной на каждый тип. Можно по несколько, а можно и так, чтобы одна механика закрывала несколько типов.

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

Мне же интересно посмотреть на сами механики, динамику игры и именно в контексте ММО. Безотносительно свойств самих игроков.

Поэтому я попробовал представить игровые механики как объекты в многомерном пространстве (механик) и выделить в этом пространстве ортогональные оси.

Далее

Обновил конфиги Emacs

В конце ноября смотрел чего наворотили в актуальных текстовых редакторах, вроде Atom и VS Code, в итоге нажаловался на них в facebook. Дескать даже файл открыть без мышки не могут. А для меня, как емаксера, тягание мыши — стресс и выпадение из потока — чистые боль и страдание.

Поэтому, и не в первый раз кстати, я решил от добра добра не искать — обновить то, что и так работает. Тем более, в последний раз я радикально перерабатывал конфиг Emacs лет 5 назад.

Кстати, по поводу «не в первый раз». У меня сложилось стойкое ощущение, что Emacs и Vim стали своего рода глобальными локальными оптимумами в пространстве возможных текстовых редакторов. Отказаться от них тем сложнее, чем дольше и глубже с ними знакомишься. А я с Emacs уже лет 12, видимо слезть с него совсем шансов нет.

Так вот. На обновление конфигов у меня ушло примерно 7 рабочих дней :-D И ещё дней 5 на автоматизацию настройки системы с помощью ansible — давно хотел сделать, но всё руки не доходили, а тут за компанию само пошло.

Вот она — прелесть безработности творческого отпуска — можешь неделю настраивать Emacs и никто тебе слова поперёк не скажет.

Если вы начинающий емаксер или просто интересуетесь, не пугайтесь сроков. Emacs — сложная штука, но не на столько. Просто я упоротый и полез делать собственное окружение, а для нормальных людей есть готовые и проверенные сборки: Spacemacs, Doom Emacs и прочие, которые должны работать сразу после установки.

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

Итоговый конфиг лежит на github. Если его разместить в /home/<user_name>/.emacs, то при следующем запуске Emacs сам скачает и установит все нужные библиотеки. Будет работать всё, кроме некоторых фич в режиме редактирования Python — для их включения смотрите определение переменных python‑binaries, python‑interpreter, python‑pylint.

Далее

Математики добрались до нейронных сетей

На arxiv.org выложен интересный препринт: Every Model Learned by Gradient Descent Is Approximately a Kernel Machine.

Как видно из названия, исследователи утверждают, что нейронные сети, обученные методом градиентного спуска (один из самых распространённых вариантов обучения) близки такой штуке как kernel machines — одной из техник машинного обучения «предыдущего поколения».

У kernel machines есть несколько интересных особенностей:

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

Из этого может неслучиться несколько интересных вещей.

• «Готовая» математика упростит сети и/или улучшит их результат и/или ускорит/удешевит обучение.
• Область возможностей сетей очертится более чётко — окажется, что они не выделяют никакие новые признаки, а используют только «запутанные» данные из обучающей выборки.

Оба варианта выглядят довольно интересно.

Обсуждение на ycombinator.com