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

Technology Radar | October 2024

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

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

Что нового и интересного я увидел там для себя

Очень много про AI и LLM:
- Using GenAI to understand legacy codebases
- Small language models
- Synthetic data for testing and training models
- LLM as a judge
- Function calling with LLMs
- Dynamic few-shot prompting
- On-device LLM inference
- Structured output from LLMs
- FastChat
- Software engineering agents (например Copilot Workspace)

Все эти штуки либо в зоне бест-практисов, либо в зоне перспективных
Однако одна штука уехала в зону "надо выбрасывать", а именно "Replacing pair programming with AI". Чтож, теперь есть и вердикт от thoughtworks, что copilot не может заменить человека для парного программирования

Про практики:
- Domain storytelling - практика для фасилитации старта построения домена для DDD
- Observability 2.0 - переход к единому подходу к обсервабилити, вместо использования кучи разных
- Continuous deployment и 1% canary перешли в бест-практисы

Из того, что более менее связано с вебом:
- Component testing - сразу попало в бест-практисы. Под компонентными тестами имеются в виду тесты компонентов в jsdom. Использование реального браузера слишком медленное и нестабильное.
- GraphQL for data products - GraphQL в радаре с 2019 года, но вот оказалось что GraphQL весьма неплох для получения данных из больших хранилищ данных. Более того, graphQL удобен для нейронок т.к. есть схемы и понятное апи для доставания данных
- Spinkube - опен-сорс серверлесс рантайм для WASM в k8s
- PGLite - wasm реализация PostgreSQL
- Rspack - добавлен как перспективный сборщик фронтенд проектов
- tsoa - это проект, который предлагает использовать TS как единую точку правды о контрактах API и генерировать swagger на основе ts. Плюсы использования TS: это ЯП, в котором удобно работать со структурами и типами, и в который легко войти. Также можно использовать все практики для кода (бранчевание, версионирование, линтинг и тд)



Инструменты:
- Zed - редактор на Rust от создателей Atom. Поддерживает много языков программирования, AI и совместную работу. Но пока рано говорить что Zed может заменить vscode.
- Warp - терминал для macos и linux. Я уже писал о нем в канале - это очень удобный терминал. Использую его уже давно и пока нравится. Основная фича, на мой взгляд, это просто крутой DX - это терминал в котором удобно работать. Но еще есть AI, сниппеты и еще куча всякого вокруг, но я это не использовал
- Raycast - ланчер для macOS, который умете запускать программы, искать файлы, запускать автоматизированныеп задачи
- Mockoon- опен-сорсный тул для мокирования. Умеет работать с OpenAPI
- GitButler - простой и удобный git client
- Difftastic - тула для показа diff, которая учитывает контекст. Например, когда вы смотрите обычный дифф (например в том же гите) кода как дифф текста, то вы наверняка сталкивались с тем, что дифф неправильно понял, например, рефакторинг. Или просто показывает много шума (вы добавили точку с запятой - это супер безопасное изменение, но показывается ровно также как обычное изменение). Diffstatic учитывает контекст и убирает весь шум. Я пока не пробовал, но звучит круто (если еще и рефакторинги в TS будет понимать - будет ваще пушка) и мой коллега уже юзает и пока хвалит (пользуясь случаем - привет Серёга 👋)


https://www.thoughtworks.com/radar

#development #thoughtworks #techradar

Дайджест за 2024-12-02 - 2024-12-05

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

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

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

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

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

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

Technology Radar | October 2024
Вышел новый выпуск радара технологий от thoughtworks. Напомню, что это такое: периодически компания thoughtworks выпускает радар, который показывает, какие технологии и инструменты они используют, какие тестируют, от каких отказываются. К каждой практике есть подробное описание про практику и причины попадания в определенную зону радара

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

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

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

proposal-import-sync

Пришел апдейт по пропозалам в EcmaScript. Внезапно для себя увидел там динамический синхронный импорт :О . Пока еще в stage 1, т.е. все еще может сильно поменяться.

Кейсы использования из пропозала

Синхронная загрузка кода, который уже должен быть загружен

import 'app';

// this will always work if 'app' has been loaded previously
const app = import.sync('app');

Если модуль еще не загружен (или код не выполняется в top-level await), то такой вызов синхронного импорта кинет исключение.

Условная загрузка

let fs;
try {
  fs = import.sync('node:fs');
} catch {}

if (fs) {
  // Use node:fs, only if it is available
}

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

https://github.com/tc39/proposal-import-sync

#development #javascript #proposal

React 19 is now stable!

React 19 можно использовать в проде. С момента публикации бетки доки про 19 реакт в доке появилось 2 изменения: улучшения в Suspense и новое статичное API в React Dom

Улучшения Suspense заключаются в том, что теперь, если необходимо отрендерить фолбек, то фолбек будет рендерится сразу, а не дожидаться рендера соседей по дом-дереву. Это улучшает user experience (и, как я помню, на это многие жаловались в github-ишуях react'а).

Новое статичное API для React DOM представляет собой методы для статической генерации сайтов prerender и prerenderToNodeStream. Это версия рендера, которая дожидается загрузки данных и только потом отдает разметку. Обычный же рендер серверных компонентов может сначала отдать разметку с фолбеками, а только потом дослать апдейт разметки когда данные загрузятся.

Кто уже обновился?

https://react.dev/blog/2024/12/05/react-19

#development #javascript #react #react19

State of Node.js Performance 2024

Новый бенчмарк по производительности новой версии Node.js по сравнению с предыдущими. В целом все как обычно: часть операций ускорилась, часть немного замедлилась. В основном, конечно, все стало быстрее

Если вы пишете высоконагруженные приложения на node.js, то вам точно стоит посмотреть. Можете, например, выяснить, что именно ваш код замедлится на 50% (например, если вы декодируете latin1) и надо подождать, пока команда node.js исправит это. Или наоборот, значительно ускорится и лучше быстрее обновляться.



https://nodesource.com/blog/State-of-Nodejs-Performance-2024

#development #javascript #nodejs #performance #benchmark

React Anti-Pattern: Stop Passing Setters Down the Components Tree

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

Ну я слишком широко взял, автор сетует на прокидывание set-функции из useState в компоненты.

function Form() { 
    const [formData, setFormData] = useState({ name: '' }); 
    return (
        <div>
            {/* прокидываем в инпут колбек, который сетит ВСЮ форму*/}
            <Input name={formData.name} setFormData={setFormData} />
        </div> 
    ); 
};


function Input({ name, setFormData }) { 

    const handleInputChange = (event) => { 
     // обновляем только одно поле
        setFormData((prevData) => ({ ...prevData, name: event.target.value })); 
    }; 
    
    return <input type="text" value={name} onChange={handleInputChange} />;
};

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

Как должно быть в упрощенном примере:

function Form() { 
    const [formData, setFormData] = useState({ name: '' }); 
    const setName = (name) => setFormData({...formData, name})
    return (
        <div>
            <Input name={formData.name} onChangeName={setName} />
        </div> 
    ); 
};


function Input({ name, onChangeName }) { 

    const handleInputChange = (event) => {
     onChangeName(event.target.value) 
    }; 
    
    return <input type="text" value={name} onChange={handleInputChange} />;
};

Можно пойти еще дальше - вынести все в хук или контекст, но суть не в этом. Суть текущего поста не в том, как делать "правильно", а как не делать "неправильно" - не кидайте в компоненты "лишние" данные и функции.

https://matanbobi.dev/posts/stop-passing-setter-functions-to-components

#development #javascript #react #antiPatterns