Crafting a 13KB Game: The Story of Space Huggers

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

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

Хорошее чтиво на вечер

https://frankforce.com/space-huggers-how-i-made-a-game-in-13-kilobytes/

#development #javascript #game

Announcing Official Puppeteer Support for Firefox

Наконец-то появилась официальная поддержка firefox в puppeteer. Теперь можно использовать puppeteer для работы с firefox.

Из интересных технических деталей в статье: было два основных варианта для реализации интеграции с puppeteer:
- Использовать WebDriver BiDi протокол. Это штука, которая была стандартизирована еще w3c и поверх нее, как я помню, работает selenium
- Использовать CDP (chrome dev-tools protocol), по которому puppeteer работает с хромом, т.е. по сути надо имплементировать CDP в firefox; Или сделать интеграцию puppeteer с RDP - это аналог CDP но для firefox

Сначала попробовали сделать экспериментальную и ограниченную поддержку CDP в firefox. Но решили что лучше идти в сторону Webdriver BiDi, как более стандартизированная и кросс-браузерная штука.

https://hacks.mozilla.org/2024/08/puppeteer-support-for-firefox/

#development #javascript #puppeteer #firefox

Common Causes of Memory Leaks in JavaScript

Хорошая статья про утечки памяти.

Статья начинается с разбора типов памяти в V8.

Есть:
- RSS (Resident Set Size) - все используемая память
- Heap Total - Память выделенная под JS-объекты
- Heap Used - Память, используемая JS-объектами
- External - Память под С++ объекты, прилинкованные к JS объектам
- Array Buffers - Память выделенная под ArrayBuffer. Используется для хранения бинарных данных

Получить текущее использования можно так

console.log('Initial Memory Usage:', process.memoryUsage());

Initial Memory Usage: {
  rss: 38502400,
  heapTotal: 4702208,
  heapUsed: 2559000,
  external: 1089863,
  arrayBuffers: 10515
}

Основные причины утечки памяти:
- Плохая работа с данными. Например, когда данные уже не нужны, а мы все еще их храним (в глобальной переменной или в замыкании)
- Плохая работа с event listeners. Если их не удалять, после того как они стали не нужны, они будут также держать объекты и защищать их от сборки
- Замыкания
- Некорректной использование bind. Например, мы забиндили метод к this, но в методе this не используется. В этом случае из-за bind GC не сможет собрать то, на что забинжена функция (this).
- Циклические зависимости (пример в статье интересный - this.reference = this;

Третья часть статьи описывает, как же профилировать использование памяти в ноде.

Сначала надо запустить процесс с записью лога node --prof server.js
Затем необходимо прочитать лог node --prof-process isolate-0x140008000-42065-v8.log > processed-profile.txt

Что выдаст в файл человеко-читаемый профайлинг, где описано, какие функции запускались, сколько времени заняли, какие объекты аллоцированы

https://www.trevorlasn.com/blog/common-causes-of-memory-leaks-in-javascript

#development #javascript #performance #memoryLeak

How we shrunk our Javascript monorepo git size by 94%

У статьи очень кликбейтное название. Я сначала подумал, что чуваки комитили node_modules и теперь решили его удалить или что-то в этом роде. Но все оказалось куда интереснее.

Есть команда в Microsoft, которая разрабатываем в большом монорепо на JS. Называется это 1JS, в нем около 20 миллионов строк кода, 2500 пакетов, а клонирование требует 178 гигабайт дискового пространства и некоторые коллеги из Европы (странное уточнение от автора, ну да ладно) не могли его склонировать.

История про клонирование 178 гигабайт звучит очень странно т.к. я точно помню, что microsoft делала свою файловую систему для работы с огромными гит-репозиториями, которая решает проблему клонирования "лишних" файлов. Ну, видимо в репозитории 1JS это не так.

В репозитории есть 2 основных ветки - mainи versioned. В первой ведется разработка, во второй ведутся релизы. По сути ветка versioned хранит в себе изменения CHANGELOG.md и CHANGELOG.json. На удивление, обнаружилось, что именно эти файлы приводят к тому, что в дереве гита приходится хранить дополнительные 125 гигабайт данных.

Почему так? По умолчанию, алгоритм запаковки изменений и снапшотов в git для идентификации файла использует только последние 16 символов названия файла. Поэтому, если изменить repo/packages/foo/CHANGELOG.json, то git будет собирать diff и к repo/packages/bar/CHANGELOG.json (пересчитал символы, у меня получилось что 15 совпадают, а 16 отличается. Либо я не так считаю, либо что-то не так понял). Т.к. это монорепо с 2500 пакетов, то ченджлогов много и git считает дифф каждый к каждому (опять же, если я правильно понял).

Это можно поправить, увеличив окно для сравнения. Для этого ребята добавили возможность регулировать это окно в git for windows. После перепаковки репозитория, размер уменьшился с 178ГБ до 5ГБ.

Очень интересная история с неожиданной развязкой. Никогда бы не подумал что ведение ченджлога может привести к 94% затрат на размер репозитория.

https://www.jonathancreamer.com/how-we-shrunk-our-git-repo-size-by-94-percent/

#development #javascript #performance #monorepo #git #microsoft

Самые тяжелые NPM пакеты

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

Рассчет трафика достаточно простой: берем вес tar.gz пакета, берем количество загрузок в неделю, перемножаем, получаем трафик в неделю

Самый большой трафик создают swc, typescript, next, esbuild, aws-sdk, pnpm, prettier, date-fns

Jquery на 178 месте по трафика. React-dom - 28, сам React - 275.

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



https://docs.google.com/spreadsheets/d/1oYJxQgMA7lQ6-wNaBKNNDz6vr3Yaa1EDsI_Hakr4ROg/edit?gid=1891857584#gid=1891857584

#development #javascript #npm

Дайджест за 2024-11-11 - 2024-11-15

Crafting a 13KB Game: The Story of Space Huggers
Периодически проходит интересный челлендж - необходимо создать игру на JS, которая поместится в 13кб. Всегда интересно почитать, как люди делают полноценные игры и умещают их в такой крохотный размер.

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

Announcing Official Puppeteer Support for Firefox
Наконец-то появилась официальная поддержка firefox в puppeteer. Теперь можно использовать puppeteer для работы с firefox.

Из интересных технических деталей в статье: было два основных варианта для реализации интеграции с puppeteer:

Common Causes of Memory Leaks in JavaScript
Хорошая статья про утечки памяти.

How we shrunk our Javascript monorepo git size by 94%
У статьи очень кликбейтное название. Я сначала подумал, что чуваки комитили node_modules и теперь решили его удалить или что-то в этом роде. Но все оказалось куда интереснее.

Есть команда в Microsoft, которая разрабатываем в большом монорепо на JS. Называется это 1JS, в нем около 20 миллионов строк кода, 2500 пакетов, а клонирование требует 178 гигабайт дискового пространства и некоторые коллеги из Европы (странное уточнение от автора, ну да ладно) не могли его склонировать.

Самые тяжелые NPM пакеты
Одновременно интересная и практически бесполезная таблица с самыми тяжелыми npm пакетами и тем, сколько мирового интернет траффика они потребляют.

Рассчет трафика достаточно простой: берем вес tar.gz пакета, берем количество загрузок в неделю, перемножаем, получаем трафик в неделю

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

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

setImmediate() vs setTimeout() in JavaScript

Хороший разбор того, как в NodeJS работает event-loop на примере разбора порядка вызовов setTimeout и setImmediate.

Посмотрите на этот код

setImmediate(() => {
  console.log("setImmediate 1");
});

setTimeout(() => {
  console.log("setTimeout 1");
}, 0);

setTimeout(() => {
  console.log("setTimeout 2");
}, 0);

setImmediate(() => {
  console.log("setImmediate 2");
});

Предположите, в каком порядке пойдет вывод в консоль?

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

setTimeout 1
setImmediate 1
setImmediate 2
setTimeout 2

Почему так происходит? Потому что event loop в NodeJS работает следующим образом:
- Таймеры
- Колбеки IO
- Хендлинг IO
- Check

Когда мы вызываем setTimeout(cb, 0) мы складываем задачу в ивент луп. Задачи берутся по одной и колбек таймаута разберется в фазе таймеров. Затем выполняются IO-фазы, а затем фаза Check. setImmediate как раз выполняется в фазе Check, причем с гарантией, что все задачи этой фазы разберутся сразу после IO.

Поэтому получается так, что
- Из ивентлупа забирается первый таймер
- Исполняется
- Проходит IO
- Выполняется Check, в рамках которого выполняются все setImmediate
- Goto start

При этом, если мы поставим таймер и immediate в рамках колбека IO, то можно получить другой результат

const fs = require('fs');

fs.readFile('example.txt', () => {
  setTimeout(() => {
    console.log("setTimeout after I/O");
  }, 0);

  setImmediate(() => {
    console.log("setImmediate after I/O");
  });
});

setImmediate after I/O
setTimeout after I/O

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

https://www.trevorlasn.com/blog/setimmediate-vs-settimeout-in-javascript

#development #javascript #setImmediate #setTimeout

Организация базы знаний в obsidian

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

Что я имею в виду под знаниями:
- Шпаргалки по использованию инструментов
- Полезные ссылки
- Конспекты и интересные идеи
- MN-ки
- Заметки по проекту или разным областям

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

Самый необычный инструмент для хранения знаний, который я видел, это Trello. Чел (привет Костя) заводил карточку на trello-доске под каждую тему и в ее контенте и комментариях скидывал всякое интересное.

Самые популярные, из тех что я вижу у своих коллег, это notion и встроенные в ОС заметки.

Лично мне оба инструмента не нравятся:
- Notion чисто онлайн-инструмент - не очень отзывчивый, не очень быстрый. Зато, конечно, удобный, позволяет сделать красиво и позволяет настроить совместную работу. Но главный минус, для меня, это vendor-lock. Сложно перейти из Notion куда-то, сложно делать офлайн-бекапы. В случае если Notion решит вас заблокировать, то можно потерять все свои заметки
- Встроенные в ОС заметки как правило плохо шарятся между устройствами. В целом это очередной vendor-lock

В какой-то момент я перешел на работу с markdown-файлами. Почему так:
- Полный контроль над контентом. Это просто файлы - храню где хочу, легко бекапить, легко синхронизировать, можно открыть на любом тостере
- Markdown легко конвертировать в другие форматы. Например, посты в канал я пишу в markdown и телега их принимает. Заметки по работе я тоже пишу в markdown и в confluence есть конвертер из markdown в confluence формат
Конечно же есть и минусы:
- markdown формат весьма ограничен. Приходится, как минимум, отказаться от работы с таблицами
- Тяжело найти инструмент, который оставит полный контроль над файлами и позволит легко шарить эти файлы и работать с ними в режиме совместной работы

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

Obsidian - это приложение, которое создано вокруг идеи Zettelkasten. Сам метод Zettelkasten я не использую т.к. имхо, проблемы, которую решал Zettelkasten уже нет. Obsidian из коробки позволяет работать с папкой с markdown файлами как с базой знаний: можно линковать файлы друг с другом, организовывать вокруг тэгов, быстро рефакторить их (например, вынести часть заметки в другую и тут же оставить ссылку в текущем документе на новую заметку). Также obsidian очень мощный благодаря плагинам от сообщества: их много, они часто немного сыроваты, но в целом хорошо расширяют возможности Obsidian.

Используемые мной плагины:
- Outliner - позволяет удобно работать со списками
- Dataview - позволяет строить запросы по заметкам
- Excalidraw - позволяет рисовать диаграммы прямо в obsidian, используя excalidraw
- Whisper - позволяет наговаривать аудио, которое потом распознается в текст с помощью whisper
- Templater - позволяет создавать заметки по шаблону
- Tasks - добавляет работу с задачами - можно делать запросы в Dataview, ставить дедлайны, связывать задачи
- Meta Bind - позволяет создать удобные кнопки с кастомной логикой
- Advanced Slides - позволяет делать слайды на основе reveal.js. Использую для простых презентаций

С этими плагинами (и еще парочкой мелких) я веду 3 базы знаний:
- По каналу. Вот прям щас пишу в ней пост
- По работе. Там все задачи, заметки, MN-ки, ведение больших проектов, 1:1, слайды
- Личный. Там все общие заметки как по разработке, так и просто житейские. Также там конспекты по книжкам.

База знаний для канала синхронизируется через гит
База знаний по работе только на рабочем ноуте
Личная база знаний синхронизируется по гугл диску

А как вы организуете свою базу знаний?



#note #obsidian #knowledgeManagement

Legacy Modernization meets GenAI

Статья в блоге Мартина Фаулера про то, как они в ThoughtWorks используются нейронки для модернизации всякого легаси.

Как только нейронки стали публично доступными и удобными, в ThoughtWorks начали с ними экспериментировать. Один из очевидных юзкейсов для нейронок - это работа с кодом: документирование, переписывание, построение модели системы по коду. Для легаси систем это супер актуальная задача.

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

В ThoughtWorks придумали сделать систему, которая ускорит этот процесс - CodeConcise. Берется код, преобразуется в AST, анализируются связи между разными файлами на уровне кода (например, модуль А зависит от модуля Б, но только при использовании метода Х). По этой инфе уже работает CodeConcise, внутри которого нейронка

Использование CodeConcise ускоряет разбор легаси модуля с 6 недель до двух.

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

https://martinfowler.com/articles/legacy-modernization-gen-ai.html

#development #martinFowler #chatgpt #ai #refactoring

Destroy on Friday: The Big Day 🧨 A Chaos Engineering Experiment – Part 2

Вы когда-нибудь задумывались, что будет, если отключить часть ваших серверов? Скорее всего - нет. А есть целая область знаний, которая посвящена этому - chaos engineering. Chaos engineering - это методика повышения отказоустойчивости систем через искусственное создание крупных сбоев.

Данная статья от honeycomb рассказывает, как ребята решили сложить 1 из 3х кластеров своих серверов и как отреагировала система. В целом, инфраструктура honeycomb справилась - трафик перераспределился и все работало.

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

https://www.honeycomb.io/blog/destroy-on-friday-chaos-engineering-pt2

#development #chaosEngineering

Дайджест за 2024-11-18 - 2024-11-22

setImmediate() vs setTimeout() in JavaScript
Хороший разбор того, как в NodeJS работает event-loop на примере разбора порядка вызовов setTimeout и setImmediate.

В коментариях к посту указали, что статья не совсем точная. Поэтому если решите почитать статью - почитайте и комментарии

Организация базы знаний в obsidian
Наконец-то я настроил пайплайн выпуска постов так, что могу вставлять сюда контент без ссылок :) Поисследуем, насколько интересны авторские посты.

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

Legacy Modernization meets GenAI
Статья в блоге Мартина Фаулера про то, как они в ThoughtWorks используются нейронки для модернизации всякого легаси.

Как только нейронки стали публично доступными и удобными, в ThoughtWorks начали с ними экспериментировать. Один из очевидных юзкейсов для нейронок - это работа с кодом: документирование, переписывание, построение модели системы по коду. Для легаси систем это супер актуальная задача.

Destroy on Friday: The Big Day 🧨 A Chaos Engineering Experiment – Part 2
Вы когда-нибудь задумывались, что будет, если отключить часть ваших серверов? Скорее всего - нет. А есть целая область знаний, которая посвящена этому - chaos engineering. Chaos engineering - это методика повышения отказоустойчивости систем через искусственное создание крупных сбоев.

Данная статья от honeycomb рассказывает, как ребята решили сложить 1 из 3х кластеров своих серверов и как отреагировала система. В целом, инфраструктура honeycomb справилась - трафик перераспределился и все работало.

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

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

Uncontrolled or controlled: A matter of perspective

Статья, разбирающая смысл термином Controlled Component и Uncontrolled Component. В целом, ничего нового, но разбор короткий и понятный

Давайте разберем на небольшом примере

Пример uncontrolled компонента

function Page() {
  return <input name="search" />;
}

Пример controlled компонента

function Page() {
  const [search, setSearch] = useState('');

  return (
   <> 
    <input
      value={search}
      onChange={(e) => setSearch(e.target.value)}
      name="search"
    />
    
    <button onClick={() => setSearch('')}>Clear</button>
   </>
  );
}

В первом примере input, с точки зрения Page, является uncontrolled компонентом т.к. Page не контролирует состояние и работу input'а - input работает сам. Во втором примере и значение и обработка работы input'а контролируется компонентом Page

Это достаточно тривиальный пример

Давайте возьмем Counter вместо нативного инпута

function Counter() {
  const [count, setCount] = useState(0);

  return (
    <>
      <button onClick={() => setCount(count - 1)}>-</button>
      <div>{count}</div>
      <button onClick={() => setCount(count + 1)}>+</button>
    </>
  );
}

Это controlled или uncontrolled компонент? Чтобы понять это, надо посмотреть на компонент с точки зрения того, кто его использует

function App() {
  return <Counter />;
}

С точки зрения App такой Counter - uncontrolled, т.к. он работает сам по себе и на его работу нельзя повлиять

Но Counter можно реализовать и как controlled компонент. В этом случае с точки зрения App код должен получиться примерно такой

function App() {
  const [count, setCount] = useState(0);

  return (
    <>
      <Counter value={count} onChange={setCount} />

      <p>App state: {count}</p>

      <button onClick={() => setCount(0)}>Reset</button>
    </>
  );
}

А можно пойти еще дальше и сделать так, чтобы Counter мог работать и как controlled компонент и как uncontrolled компонент. Если ему прокинули пропсы - значит будет работать как controlled, иначе - uncontrolled.

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

https://buildui.com/posts/uncontrolled-vs-controlled-a-matter-of-perspective

#development #javascript #react #controlledComponents

Adopting the compiler in Sanity Studio

Sanity Studio - приложение для создания и редактирования контента (не до конца понял каокго) с режимом совместной работы и постоянной синхронизацией. Приложение реализовано на React и команда решила попробовать подключить react compiler в свой проект.

Если совсем коротко: Sanity Studio подключили react compiler и он обнаружил проблемы в коде и ускорил рендер приложения.

Я сразу признаюсь, что не до конца вкурил про что там челы пишут (т.к. до сих пор не до конца понимаю что такое react compiler). Но основные поинты такие:
- eslint-plugin-react-compiler хорошо работает как детектор багов. Он находит места, которые работают неправильно
- babel-plugin-react-compiler вскрывает проблемы react-кода приложения

Когда ребята включили компайлер в коде своего редактора, куча e2e тестов попадала. Во время расследования, почему так случилось, выяснилось, что раньше тесты проходили, но это были ложно-положительные прохождения. Т.е. код изначально плохо работал в некоторых случаях, а react compiler сделал так, что эти случаи стали заметны.

Также ребята инженерно подошли к включению компайлера в код и замерили, насколько ускорился рендер приложения. Для тестов перформанса они используют свои юзкейсы - скорость редактирования контента. Разные кейсы ускорились по разному, но в целом ускорение составило от 5% до 33%, что весьма внушительно.

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

В общем, звучит круто. Какие советы дает автор:
- Подключайте eslint-plugin-react-compiler и фиксите баги
- Подключайте babel-plugin-react-compiler на тестовых стендах чтоб убедиться, что приложение стало работать лучше и нет багов
- Используйте react-compiler-runtime чтобы ускорить приложение
- Инкрементально рефакторите код, который компилятор пропускает


https://github.com/reactwg/react-compiler/discussions/33

#development #javascript #react #reactCompiler #react18

Storybook 8.4

Вышел Storybook 8.4. Основные фичи: улучшения компонентных тестов, уменьшение размера бандла, поддержка svelte 5, поддержка React Native, поддержка тэгов в историях

Теперь давайте разберем по-подробнее

Самый крутой апдейт релиза, на мой взгляд, называется Component Test in 1 click. Storybook много усилий вкладывает в использование инструмента в целях тестирования. В данном релизе добавили удобные кнопки в UI-сторибука для запуска разных видов тестов прямо из интерфейса (ui-тесты (chromatic), компонентные тесты, тесты доступности). Лучше, конечно, посмотреть гифку в блоге, чтоб посмотреть на то, как работает эта фича. Выглядит хорошо.

Следующий большой поинт - оптимизация бандла. Теперь storybook весит на 50% меньше, по сравнению с 8.0. Эта работа делалась итеративно и каждый следующий релиз становился все меньше. В посте также есть картинка, которая показывает изменение графа модулей по релизам - выглядит внушительно.

За счет чего удалось достичь таких результатов:
- Удалили fs-extra, handlebars, file-system-cache
- Заменили lodash ⇒ es-toolkit, express ⇒ polka,  chalk ⇒ picocolors, qs ⇒ picoquery
- Оптимизации: включение продакшн-мода для react, опциональный prettier
- Бандлинг: Vite builder , React renderer , Addon-docs 

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

Перейдем далее: React Native поддерживался в storybook 7, но поддержку для storybook 8 добавили только сейчас. Собираются и далее поддерживать совместимость с React Native

Другая полезная фича: тегирование историй. Если у вас большой сторибук, то бывает сложно там навигироваться. Да, там есть поиск по названию истории, но бывает так, что мы хотим выделить все истории, которые связаны с чем-то определенным, а сделать это невозможно. Теперь в Storybook появилась возможность указывать теги у истории и фильтровать истории по ним. Также можно визуализировать теги в виде беджей. Как юзкейсы, которые предлагает сам Storybook в посте: выделение новых компонентов (бейдж New! рядом с историей в навигации) и ведение версий (бейдж v1.0.0 рядом с историей в навигации)

https://storybook.js.org/blog/storybook-8-4/

#development #javascript #storybook #release #componentTests #svelte5

Will we care about frameworks in the future?

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

Нужны ли нам фреймворки, если большинство кода будут писать нейронки, а они спокойно пишут код и без фреймворков ? Фреймворки решают разные проблемы, но многие из них связаны в первую очередь с когнитивными ограничениями человека. У нейронок нет таких ограничений (есть правда другие, но не об этом разговор). Нейронке норм копипастить код, или напрямую работать с DOM, вместо инициализации кучи обвязки из фреймворков. Нейронка не боится писать бойлерплейт. Мы - люди, так не делаем - мы стараемся не дублировать логику и использовать высокоуровневые абстракции, чтобы снизить когнитивную нагрузку.

Я думаю, что в ближайшие несколько лет индустрия разработки претерпит значительные изменения. Мое имхо: работа "кодера" уже не будет так цениться, будут цениться способности проектировать системы, а 80% кода будут писать нейронки. Я бы сказал, что под риском сейчас все те, кто считают что в задаче должно быть все четко описано: что делать, как делать, какие таблицы в БД нужны, какие контракты надо реализовать, должны быть все макеты, а разработчик лишь пишет код, т.е. работает как преобразователь ТЗ в код. Такое скоро будет заменено нейронками.

https://paul.kinlan.me/will-we-care-about-frameworks-in-the-future/

#development #llm #thoughts

LLMs as a tool for thought

Еще одна статья о нейронках. На этот раз еще менее техническая, чем предыдущая.

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

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

И вы это, скорее всего, делаете не сфокусировано. Т.е. это все распределено во времени и вам постоянно надо возвращаться в контекст этой задачи. У кого то хватает дисциплины и навыков оформлять живую документацию и постоянно ее пополнять, а кто-то держит все в чатах или в голове.

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

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

https://wattenberger.com/thoughts/llms-as-a-tool-for-thought

#development #llm #thoughts

Дайджест за 2024-11-25 - 2024-11-29

Uncontrolled or controlled: A matter of perspective
Статья, разбирающая смысл термином Controlled Component и Uncontrolled Component. В целом, ничего нового, но разбор короткий и понятный

Давайте разберем на небольшом примере

Adopting the compiler in Sanity Studio
Sanity Studio - приложение для создания и редактирования контента (не до конца понял каокго) с режимом совместной работы и постоянной синхронизацией. Приложение реализовано на React и команда решила попробовать подключить react compiler в свой проект.

Если совсем коротко: Sanity Studio подключили react compiler и он обнаружил проблемы в коде и ускорил рендер приложения.

Storybook 8.4
Вышел Storybook 8.4. Основные фичи: улучшения компонентных тестов, уменьшение размера бандла, поддержка svelte 5, поддержка React Native, поддержка тэгов в историях

Теперь давайте разберем по-подробнее

Will we care about frameworks in the future?
Заметка об использовании AI в разработке и о том как это может повлиять на индустрию. Здесь только мысли, без примеров кода или каких-то серьезных аргументов. Но мысли, подобные описанным в статье, в последнее время посещают и меня.

Нужны ли нам фреймворки, если большинство кода будут писать нейронки, а они спокойно пишут код и без фреймворков ? Фреймворки решают разные проблемы, но многие из них связаны в первую очередь с когнитивными ограничениями человека. У нейронок нет таких ограничений (есть правда другие, но не об этом разговор). Нейронке норм копипастить код, или напрямую работать с DOM, вместо инициализации кучи обвязки из фреймворков. Нейронка не боится писать бойлерплейт. Мы - люди, так не делаем - мы стараемся не дублировать логику и использовать высокоуровневые абстракции, чтобы снизить когнитивную нагрузку.

LLMs as a tool for thought
Еще одна статья о нейронках. На этот раз еще менее техническая, чем предыдущая.

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

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

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

Conditional Props in React Using Type Discrimination

Хорошая вводная статья про Type Discrimination в Union в typescript. Это паттерн, который позволяет выделять разные типы объектов по какому-либо полю

Например, у вас есть объект юзера, но у него разные свойства в зависимости от его роли - админ или простой чел

Вот самый утрированный пример:

type User = {
    type: 'user' | 'admin';
    commonField: any;
    adminField?: any;
    userField?: any;
}

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

const user: User = {
   type: 'user',
   commonField: 1,
   adminField: 2,
   userField: 3
}

По бизнес-логике не может юзер содержать админские поля, но по типам тайпскрипта - может. Как это решить? Автор сначала рассматривает Generic, но я это даже приводить не буду, т.к. для решения этой проблемы в TS есть механика discriminate types.

В чем суть механики: если мы заведем union, типы которого можно различать по какому-то ключу, то typescript будет корректно уточнять тип после проверок

В данном случае нам следует явно выделить тип юзера и тип админа и скрестить их в тип абстрактного юзера через объединение. При этом в типы юзера и админа мы будем различать по полю type

type Admin = {
 type: 'admin';
    commonField: any;
    adminField: any;
}
type User = {
 type: 'user';
    commonField: any;
    userField: any
}
type AbstractUser = User | Admin

Теперь typescript будет корректно уточнять тип по проверке user.type

function procerssUser(user: AbstractUser) {
 if (user.type === 'admin') {
  console.log(user.adminField)
 }
 if (user.type === 'user') {
  console.log(user.userField)
 }
}

В статье все это описано более подробно и с примерами из React (хотя React тут скорее просто как пример использования)

https://elanmed.dev/blog/conditional-props-using-type-discrimination

#development #javascript #typescript #discrimination #react

Overflow Clip

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

В данной статье представлены крутые интерактивые примеры использования overflow: clip, которые позволяют сделать то, что сложно (или невозможно) сделать с помощью overflow: hidden.

https://ishadeed.com/article/overflow-clip/

#development #css #overflow

typescript advent и adventofcode

Снова декабрь. Снова адвенты. Выделяю 2 адвента, о которых знаю: адвент по typescript и advent of code.

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

Advent of code - это адвент с алгоритмическими задачками. Я не любитель подобного, но знаю, что многим нравится

Если вы знаете еще какие-то адвенты - кидайте в тред.

https://www.adventofts.com
https://adventofcode.com/2024

#development #advent #typescript