ESLint now officially supports linting of CSS

Eslint продолжает развиваться. Теперь он умеет линтить CSS, используя парсер CSSTree. Сделали хорошее базовое решение: пока есть малое количество встроенных правил, но при этом есть удобное АПИ для создания кастомных правил + есть АПИ для расширения синтаксиса CSS (например, есть готовый пресет для расширения синтаксиса для tailwind)

import css from "@eslint/css";

export default [
    {
        files: ["**/*.css"],
        plugins: {
            css,
        },
        language: "css/css",
        rules: {
            "css/no-empty-blocks": "error",
        },
    },
];

https://eslint.org/blog/2025/02/eslint-css-support/

#development #javascript #eslint #css

Дайджест за 2025-03-03 - 2025-03-07

Introducing RushDB: Zero-Config Instant Database for Modern Apps & AI Era
Ссылка от подписчика про разрабатываемый им продукт - RushDB. RushDB - это база данных, которая легко развернуть и начать использовать. Основная фишка - это то что БД забирает на себя организацию данных - нормализацию, лейблинг, организацию связей между сущностями. И это очень подходит для AI-решений - вы закидываете данные, БД сама все структурирует, а структуру и связи уже может использовать AI

Также все сделано для того, чтобы работа с БД была простой: есть SDK на typescript и pythin, можно селф-хостить, можно хостить в клауде, есть гарантии транзакций, возможность работать ничего не настраивая.

The TypeScript Agent Framework
Mastra - фреймворк на Typescript для создания ИИ-агентов. Выглядит достаточно хорошо - поддерживает много разного: кастомные тулы, воркфлоу (и контроль их исполнения), RAG, память.

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

Deno 2.2: OpenTelemetry, Lint Plugins, node:sqlite
Вышел Deno 2.2. Заехали прикольные фичи: поддержка из коробки sqlite и OpenTelemtry, улучшения линтера, поддержка QUIC (http3), улучшение совместимости с Nodejs API, а также различные работы по перформансу.

Я бы хотел отдельно выделить поддержку Open Telemetry в Deno. Open Telemetry - это крайне важна штука, для обеспечения observability ваших систем. Open Telemetry - это набор соглашений о том, как следует логировать операции в IT-системах. Обычно OT встраивается в фреймворки, либо вы сами подключаете ОТ и инструментируете свой код. Deno же сам инструментирует основные методы (console.log, fetch, Deno.serve), а все что надо инструментировать сверх - остается на вас.

Bundling Dependencies
Статья разбирает, стоит или не стоит бандлить зависимости в свои библиотеки.

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

ESLint now officially supports linting of CSS
Eslint продолжает развиваться. Теперь он умеет линтить CSS, используя парсер CSSTree. Сделали хорошее базовое решение: пока есть малое количество встроенных правил, но при этом есть удобное АПИ для создания кастомных правил + есть АПИ для расширения синтаксиса CSS (например, есть готовый пресет для расширения синтаксиса для tailwind)



——————————————

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

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

Встреча потенциальных докладчиков с программным комитетом FrontendConf 2025

13 марта в 19:00 пройдет встреча с потенциальными докладчиками, на которой мы обсудим:
- на какие темы мы хотим говорить на конференции в этом году,
- как проходят отбор заявок,
- как готовить доклад с Программным комитетом.

Приходите! Я уже восьмой год подряд провожу эту встречу (как же быстро растут чужие дети), расскажу, какой видим программу, и обсудим ваши идеи докладов.

Регистрация: https://conf.ontico.ru/event/join/open_fc2025-online.html

Подробнее про программу и форма подачи докладов: https://cfp.frontendconf.ru

TypeScript: the satisfies operator

Большой пост про satisfies оператор в TypeScript. Объясняется что такое satisfies оператор и какие основные юзкейсы у него есть

satisfies проверяет, что значение соответствует какому-то типу, не меняя тип значения.

Чтобы понять разницу между satisfies и as достаточно взглянуть на 1 пример, где as сделает тайпкаст, а satisfies укажет на ошибку

type Point = { x: number, y: number };
const point5 = { x: 2 } as const as Point; // OK
const point6 = { x: 2 } as const satisfies Point; // ERROR

В статье показываются юзкейсы, когда применение satisfies очень полезно для проверки на соответствие какому-то типу, но при этом тип переменной не меняется

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

type TTextStyle = {
  html: string,
  latex: string,
};

const TextStyle  = {
  Bold: {
    html: 'b',
    latex: 'textbf',
  },
}

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

type TTextStyle = {
  html: string,
  latex: string,
};

const TextStyle: Record<string, TTextStyle>  = {
  Bold: {
    html: 'b',
    latex: 'textbf',
  },
}
TextStyle.KEK // OK

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

Оператор satisfies тут как нельзя кстати

type TTextStyle = {
  html: string,
  latex: string,
};

const TextStyle  = {
  Bold: {
    html: 'b',
    latex: 'textbf',
  },
} satisfies Record<string, TTextStyle>
TextStyle.KEK // ERROR

В статье есть еще разные примеры использования оператора - рекомендую ознакомиться самостоятельно.

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

Например, satisfies может уточнить тип

type Robin = {
  name: 'Robin',
};

const robin1 = { name: 'Robin' };
// robin1.name имеет тип string
const robin2 = { name: 'Robin' } satisfies Robin;
// robin2.name имеет тип 'Robin'

https://2ality.com/2025/02/satisfies-operator.html

#development #typescript #satisfies

import-in-the-middle

import-in-the-middle - библиотека для патчинга экспортов ESM-библиотек. Достаточно интересная штука, которая должна использоваться с умом. Для работы библиотеки необходимо регистрировать её как загрузчик в node.js

node --loader=import-in-the-middle/hook.mjs my-app.mjs

Пример

import { Hook } from 'import-in-the-middle'
import { foo } from 'package-i-want-to-modify'

console.log(foo) // whatever that module exported

Hook(['package-i-want-to-modify'], (exported, name, baseDir) => {
  // `exported` is effectively `import * as exported from ${url}`
  exported.foo += 1
})

console.log(foo) // 1 more than whatever that module exported

Ограничения:
- Нельзя расширить экспорт библиотек новыми полями
- Модули, импортированные через require, не меняются
- Нельзя заафектить на модули, которые уже были зарезолвены через динамические импорты.

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

https://github.com/nodejs/import-in-the-middle

#development #javascript #library #esmodules

Запускаем Pong в 240 вкладках браузера

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

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

Если совсем коротко описывать решение то оно следующее:
- Отрываются 8 окон по 30 вкладок с помощью AppleScript
- Есть мастер-вкладка, есть вкладки-воркеры
- Коммуникация между вкладками построена на BroadcastChannel
- Мастер вкладка запускает игру когда дождалась загрузки всех вкладок-воркеров
- Затем мастер-вкладка отправляет воркерам, как им следует обновить фавиконку
- Рассчет того, какой вкладке нобходимо обновить фавиконку идет на основе хардкода размеров окон, фавиконок и всех отступов в Google Chrome




https://habr.com/ru/articles/884564/

#development #javascript #pingPong

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



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

Что мне понравилось:
Разобрали реально много моделей

---

Например, Модель Менеджмента по Адизесу. Модель предполагает что есть 4 основных стиля управления:
- P - Producer (производитель)
- A - Администратор
- E - Entepreneur (предприниматель)
- I - Интегратор

И на разных стадиях развития организации нужны руководители с разными стилями управления, которые кодируются так: pAeI - сильный администратор и интегратор.
Причем также Адизес интересно описал цикл развития организации - там 10 стадий, переходящих от старта к зрелости, после которой организация переходит к концу через аристократизм и бюрократизм.

---

Модель DISC - выделяет 4 ключевых психотипа личности, на основе того, как люди реагируют на события. В целом, недалеко ушло от 4 типов людей у Пифагора.

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

---

Модель Белбина - говорит о том, что в командах есть разные роли: исполнитель, аналитик, генератор идей, душа команды, координатор и другие. В разных командах нужен разный состав ролей. Если реальный состав команды отличается от необходимого - то неизбежны конфликты или неэффективность. Например, плохо, когда у вас слишком мало или слишком много координаторов.


---

Модель Такмана - каждая команда проходит через 4 стадии:
- Формирование - все только начали работать вместе
- Шторминг - первые трения и конфликты, эффективность снижается, возможен роспуск команды
- Нормализация - группа пережила шторминг и выходит на производительность
- Эффективная команда

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

---

Были еще разные, но в рамки поста уже не влезет.

Кроме моделей рассматривали, как провести анализ организации и на чем следует фокусироваться:
- Цели
- Стратегия
- Процессы
- Команды
- Сотрудники
- Ожидания
- Смежные команды
- И многое другое

Тоже было весьма полезно. О чем-то уже знал, о чем-то не задумывался. Информацию дали структурировано.

Единственный минус обучения - большой фокус на командную работу в группах. Благо обучение идет среди IT-менеджеров т.е. все в одном контексте + у всех есть минимальные софт-скиллы. Но я такой формат не особо люблю - спонтанная 20-минутная групповая активность не заменяет нормальное обучение.

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


---

Если вас зацепил пост, то скоро (с 17 по 28 марта) Стратоплан будет проводить Антимарафон «Вредные привычки, мешающие вашей карьере». Название странное, но это 10 лекций скорее про хорошие привычки. Судя по описанию поговорят про обратную связь, про лидерство, про планирование работ. Среди спикеров есть крутые чуваки, которые всегда несут пользу в своих публичных выступлениях. Я их читаю и могу рекомендовать вам: Дима Болдырев, Роман Ивлев

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





#note #stratoplan

Migrating 160,000 Lines of Production Banking JavaScript to TypeScript with Zero Downtime

Статья про миграцию 160к строк кода с JS на TypeScript. Статья достаточно поверхностная и моментами странная.

Есть компания, это стартап про деньги на какой-то там ранней стадии (в оригинале seed-stage startup). Код запускается в двух рамтаймах: лямбды в AWS и GraphQL API в ECS. Т.к. стартап в сфере финансов, то необходимо перейти на TS (чтобы избегать глупых ошибок, которые будут дорого стоит) и сделать это без даунтайма

Я не понимаю как в рамках одной статьи уживаются "мы стартап на ранней фазе", "мы работаем с деньгами" и "мы тут написали все на JS", но да ладно.

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

Все это продолжалось 6 недель, после чего приступили к 2-3 дневному тестингу на стейдж-окружении. Причем тестировали на реальных кейсах. Т.к. приложение связано с деньгами - то переводили $1 между счетами

Из интересного - сделали поддержку запуска и JS и TS кода в скриптах запуска. Удобно для раскатки и отката


https://benhowdle.im/migrating-js-to-ts-zero-downtime.html

#development #javascript #typescript #migration

Дайджест за 2025-03-10 - 2025-03-14

TypeScript: the satisfies operator
Большой пост про satisfies оператор в TypeScript. Объясняется что такое satisfies оператор и какие основные юзкейсы у него есть

satisfies проверяет, что значение соответствует какому-то типу, не меняя тип значения.

import-in-the-middle
import-in-the-middle - библиотека для патчинга экспортов ESM-библиотек. Достаточно интересная штука, которая должна использоваться с умом. Для работы библиотеки необходимо регистрировать её как загрузчик в node.js

node --loader=import-in-the-middle/hook.mjs my-app.mjs

Запускаем Pong в 240 вкладках браузера
Вы видели челлендж "сделай игру, помещающуюся в 13кб", вы видели реализацию DOOM на всем чем можно. Но видели ли вы реализацию игры ping pong на фавиконках вкладок? Вот, можете посмотреть по ссылке

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

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


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

Migrating 160,000 Lines of Production Banking JavaScript to TypeScript with Zero Downtime
Статья про миграцию 160к строк кода с JS на TypeScript. Статья достаточно поверхностная и моментами странная.

Есть компания, это стартап про деньги на какой-то там ранней стадии (в оригинале seed-stage startup). Код запускается в двух рамтаймах: лямбды в AWS и GraphQL API в ECS. Т.к. стартап в сфере финансов, то необходимо перейти на TS (чтобы избегать глупых ошибок, которые будут дорого стоит) и сделать это без даунтайма

——————————————

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

upfetch - advanced fetch client builder

upfetch - библиотека для удобной работы с fetch. В целом API максимально похоже на fetch, но добавлены всякие фишечки для удобства работы: таймауты, хуки, валидация, удобная передача body и query и тому подобное

Проще всего сравнить код на fetch с кодом на upfetch

Ниже примеры из ридми проекта

Отправка query-параметров
fetch:

fetch(
   `https://api.example.com/todos?search=${search}&skip=${skip}&take=${take}`,
)

upfetch:

upfetch('/todos', {
   params: { search, skip, take },
})

Отправка body
fetch:

fetch('https://api.example.com/todos', {
   method: 'POST',
   headers: { 'Content-Type': 'application/json' },
   body: JSON.stringify({ title: 'New Todo' }),
})

upfetch:

upfetch('/todos', {
   method: 'POST',
   body: { title: 'New Todo' },
})

Валидация по схеме

import { z } from 'zod'

const posts = await upfetch('/posts/1', {
   schema: z.object({
      id: z.number(),
      title: z.string(),
   }),
})

Хуки

const upfetch = up(fetch, () => ({
   onRequest: (options) => {
      // Called before the request is made, options might be mutated here
   },
   onSuccess: (data, options) => {
      // Called when the request successfully completes
   },
   onError: (error, options) => {
      // Called when the request fails
   },
}))

Настройка таймаута для всех запросов

const upfetch = up(fetch, () => ({
   timeout: 5000,
}))

Из интересного, возможность использовать другие fetch-compatible api

import { fetch, Agent } from 'undici'

const upfetch = up(fetch)

const data = await upfetch('https://a.b.c', {
   dispatcher: new Agent({
      keepAliveTimeout: 10,
      keepAliveMaxTimeout: 10,
   }),
})

https://github.com/L-Blondy/up-fetch

#development #javascript #library #github #fetch

React Scan

React Scan - инструмент, который находит проблемы в производительности React-приложений. Я не пробовал, но обещают сумасшедший DX - просто добавляете скрипт или устанавливаете браузерное расширение или запускаете cli, а инструмент вам скажет, какие конкретно компоненты требуют исправления перформанса.

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

Гифка в ридмихе вполне себе вдохновляющая, рекомендую попробовать.

Осталось докрутить интеграцию с LLM и исходным кодом, чтоб инструмент сразу предлагал как исправить проблему

https://github.com/aidenybai/react-scan

#development #javascript #react #library #github #performance

Speeding up the JavaScript ecosystem - Rust and JavaScript Plugins

Достаточно необычная статья в серии про ускорение JS-тулинга. Если помните, есть чувак, который заходит в разный опенсорс, находит там проблемы перформанса и ускоряет инструменты в сотни раз. Тем самым доказывания, что надо иметь прямые руки, а не переписывать все на Rust или Go

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

В чем суть. Автор работает в Deno и в Deno есть свой линтер, который написан на Rust. Но никто не будет писать кастомные правила для фронтенд-проектов на Rust: фронтендеры не смогут, а растовикам это не интересно.

Если же реализовывать мостик между JS и Rust, то затраты на коммуникацию съедят все профиты от введения Rust. Например, если передавать AST-дерево файла checker.ts из исходников TS размеом в 610к AST-нод между Rust и JS в json-формате, то это займет почти 3 секунды. Достаточно много.

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

Хороший пример задачи, где знание алгоритмов весьма кстати.

https://marvinh.dev/blog/speeding-up-javascript-ecosystem-part-11/

#development #javascript #rust

Michigan TypeScript Founder Successfully Runs Doom Inside TypeScript's Type System

Не знаю зачем вам эта информация, но система типов в TS - Тьюринг полная. Если утрировать, это значит, что на ней можно написать любую программу. Ну вот чел и переписал DOOM на системе типов. Пара триллионов строк кода, эмуляция ОЗУ, процессора и другого железа, 100 гигов оперативки чтобы это запустить - и вот DOOM уже запустился у вас в vscode с 0.000001 FPS.

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

https://socket.dev/blog/typescript-types-running-doom

#development #javascript #typescript

Think JavaScript Is Slow? Here's How JIT (Just In Time) Compilation Makes It 100x Faster Instantly

Статья, показывающая на простых примерах, как работает JIT-компиляция и как она ускоряет скорость работы JS. В данной статье разбирается, какой байткод генерируется в разных ситуациях и как один и тот же код может быть представлен разным байткодом.

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

https://www.royalbhati.com/posts/why-js-is-fast

#development #javascript #performance #v8

Дайджест за 2025-03-17 - 2025-03-21

upfetch - advanced fetch client builder
upfetch - библиотека для удобной работы с fetch. В целом API максимально похоже на fetch, но добавлены всякие фишечки для удобства работы: таймауты, хуки, валидация, удобная передача body и query и тому подобное

Проще всего сравнить код на fetch с кодом на upfetch

React Scan
React Scan - инструмент, который находит проблемы в производительности React-приложений. Я не пробовал, но обещают сумасшедший DX - просто добавляете скрипт или устанавливаете браузерное расширение или запускаете cli, а инструмент вам скажет, какие конкретно компоненты требуют исправления перформанса.

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

Speeding up the JavaScript ecosystem - Rust and JavaScript Plugins
Достаточно необычная статья в серии про ускорение JS-тулинга. Если помните, есть чувак, который заходит в разный опенсорс, находит там проблемы перформанса и ускоряет инструменты в сотни раз. Тем самым доказывания, что надо иметь прямые руки, а не переписывать все на Rust или Go

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

Michigan TypeScript Founder Successfully Runs Doom Inside TypeScript's Type System
Не знаю зачем вам эта информация, но система типов в TS - Тьюринг полная. Если утрировать, это значит, что на ней можно написать любую программу. Ну вот чел и переписал DOOM на системе типов. Пара триллионов строк кода, эмуляция ОЗУ, процессора и другого железа, 100 гигов оперативки чтобы это запустить - и вот DOOM уже запустился у вас в vscode с 0.000001 FPS.

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

Think JavaScript Is Slow? Here's How JIT (Just In Time) Compilation Makes It 100x Faster Instantly
Статья, показывающая на простых примерах, как работает JIT-компиляция и как она ускоряет скорость работы JS. В данной статье разбирается, какой байткод генерируется в разных ситуациях и как один и тот же код может быть представлен разным байткодом.

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

——————————————

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

Writable Streams in Node.js: A Practical Guide

В NodeJS есть классная абстракция - stream. Она позволяет удобно работать с потоками и делать приложения, которые лучше работают под высокой нагрузкой. В данной статье разбирается, как создать свой кастомный Writable Stream, т.е. поток в который вы можете писать и интегрировать его во все потоковые-АПИ

К сожалению, имплементацию кода потока записи на S3 в статье не показывают, но показывают какое API верхнеуровнево необходимо поддержать, чтобы заиметь все преимущества стримов.

https://pavel-romanov.com/writable-streams-in-nodejs-a-practical-guide

#development #javascript #nodejs #stream

Я в небольшом отпуске, поэтому с постами на этой неделе туго. Думал, что прочту все дайджесты и наберу ссылок, но между прогулками я полносью поглащен игрой Eden Crafters. Про нее и расскажу. Не сильно вяжется с тематикой канала, поэтому #offtop

Eden Crafters - это игра, в которой вас высаживают на безжизненной планете и которую нужно терраформирмировать, т.е. сделать пригодной к жизни. Делать это надо при помощи создания производственных цепочек: добыть руду, переплавить, получить детали А Б В, из деталей А Б сделать деталь Г, из деталей В и Г получить деталь Д. Необходимо также добывать электричество и воду. И из всего этого строить разные механизмы, которые:
- Меняют температуру
- Поглощают радиацию
- Озеленяют местность
- Меняют состав атмосферы
- Отчищают озера

Игра сыровата (и, если правильно помню, в альфа доступе в стиме), но играть можно (хотя некоторые вещи на стимдеке делать не очень удобно). По механике это лайт версия satisfactory (в которую я еще не играл, но наслышан).

Но я хотел рассказать не о самой игре (хотя могу рекомнедовать в нее поиграть), а о том как я вчера в игре  реализовывал enterprise service bus pattern.

ESB - если очень сильно утрировать, это когда у вас есть сервисы, но они общаются не напрямую, а через какую-то шину событий. Например, в реальности это реализуется с помощью RabbitMQ и Kafka - одни сервисы отсылают туда события, другие эти события считывают. В JS-мире близко по духу находится Event Bus pattern - это когда у нас есть виджеты\модули, но они общаются через шину событий (которую в браузере можно реализовать через DOM-API - через postMessage или createEvent).

Как я пришел к этому паттерну в игре. Я уже говорил, что в игре необходимо создавать цепочки производства. Например:
- Есть бур, который извлекает 240 золотой руды в минуту
- Есть кузница, которая может превращать 60 руды в 30 слитков в минуту
- Это значит, что оптимально будет разместить 4 кузницы
- Для этого надо поставить разветвители конвейеров. Бур => разветвитель 1 в 3 (из 1 конвеера получается 3) => Кузница, Кузница, разветвитель 1 в 3 (Кузница, Кузница) => 2 соединителя 3 в 1 => на выходе получаем единый конвеер с 120 золотых слитков в минуту
- Дальше по аналогии делаем медные слитки, из них медные пластины (тоже может понадобится не 1 сборщик и потребуются разветвители), из пластин катушку с медной нитью
- Из нити + слитков получаем что-то еще

И таких цепочек - МНОГО. И они открываются по мере развития в игре.

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

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

Вышло чуть лучше, но все равно с какого-то момента начиналось спагетти из конвейеров.

И тут у меня открылась железная дорога. ЖД в игре устроена так, что есть:
- Дорога
- Вокзалы - там можно погрузить что-то одно в какой-то конкретный грузовой вагон, а еще можно выгрузить какой-то конкретный грузовой вагон. На примере: на вокзале можно сгружать золотые слитки в вагон №4 и забирать груз из вагона №3 (куда мы можем загружать на другом вокзале медную нить)
- Собственно поезд, который везет вагоны
- Вагоны

Я сначала не понимал зачем это вообще нужно, когда есть конвейеры. Но потом я понял, что можно реализовать ESB:
- Строим круговую железную дорогу вокруг огромной производственной площадки
- Когда мы хотим что-то сделать доступным на нашей ЖД (шине), необходимо поставить вокзал, поставить рядом с ним производство нужного ресурса, добавить к поезду вагон и сгружать в него поставляемый ресурс
- Когда мы хотим что-то получить из ЖД, необходимо поставить вокзал и сгружать необходимое

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

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

Я вчера потратил на это около 3-4 часов, но в конце был доволен просто как слон :) Получил и гибкое производство и научился еще связывать несколько ЖД путей (в аналогии с ESB - научился переопубликовывать сообщение из одного инстанса кафки в другой) - это понадобилось для доставки отдаленных ресурсов на основной производственный сектор.

Вот такая небольшая история про то, как я нашел применение архитектурному паттерну из разработки ПО в игре про производство (хотя могу предположить что в реальном мире есть что-то подобное на реальных производствах).

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

#note #offtop #edenCrafters

Всем привет! Со следующей недели возобновляется постинг интересных ссылок. А пока еще немного #offtop :)

Давайте расскажу, как проходит отбор в спикеры на конференцию

Обычно люди предполагают, что для того, чтобы податься с докладом на конференцию нужны:
- Идея
- Тезисы
- Флоу доклада
- Слайды
- Возможно запись готового выступления внутри компании

Иметь все это - крайне полезно и значительно повышает шансы пройти отбор, но по-факту необходимы только 2 вещи:
- Идея доклада
- О чем конкретно вы можете рассказать

Как правило, у многих есть о чем рассказать, но т.к. они думают, что податься на конференцию сложно, то не подаются.

Например, если я захочу податься на конференцию с докладом про скриншот-тестирование, то для заявки будет достаточно:
- Идея: скриншот-тестирование позволяет легко покрывать авто-тестами все новые UI фичи, но есть грабли, на которые лучше не наступать
- О чем могу рассказать: как сравнивать скриншоты без боли, как менеджить загрузку ассетов и шрифтов, как работать с анимациями, как "мокать" стейт и почему  надо научиться это делать, какие готовые инструменты есть, как их применять и почему у нас выбран именно такой инструмент, практический опыт

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

Когда я посылаю заявки на выступление, я обычно в свободном режиме в течение пары вечером думаю, о чем я вообще могу рассказать, а затем формирую вот такие простые заявки (обычно 2-4 штуки на конференцию)

Далее идет встреча с программным комитетом, где ПК расспросит про идею, ваш опыт и даст рекомендации (например, было бы интересно послушать не просто про скриншот-тестирование, но скриншот+ui-тестирование). Ребята из программного комитета реально помогают изменить основу доклада так, чтобы и слушателям было интереснее, и ваш доклад был лучше

Далее программный комитет либо принимает доклад, либо отклоняет

Если доклад принимается, то:
- Назначается стартовый синк, где обсуждается, какой флоу может быть у доклада и что стоит рассказать
- Назначаются регулярные прогоны, на которых программный комитет дает обратную связь по контенту: что надо раскрыть, что слишком сильно раскрыто и надо меньше, что следует поменять, что следует еще происследовать
- На первых прогонах не обязательно должны быть готовы слайды. Вполне можно позволить себе шарить экран с каким-нибудь гугл доком
- С каждым следующим прогоном доклад все больше должен быть готов на итоговый. Т.е. эволюция примерно такая: идея => тезисы + флоу => заглушка контента => слайды-заглушки => рабочие слайды (контент есть, но оформление на уровне джуна) => pre production ready слайды

Программный комитет состоит из крутых инженеров и опытных спикер-коучей, поэтому они дают крутую обратную связь по флоу. Бывало и так, что мне приходилось разворачивать флоу доклада несколько раз во время подготовки (т.к. например углублялся в дебри, которые интересны только мне, но не широкому кругу людей), поэтому черновые варианты долкада должны быть easy to edit & refactor

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

Вот как-то так проходит путь от идеи к докладу. Готовить доклад, конечно, не просто, но намного проще чем кажется.

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

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

Конференция проходит в Новосибирске и очень ламповая по своей атмосфере. Приезжайте как слушатель или как спикер - развиртуализируемся!


#codefest #note