Introducing JavaScript support in MySQL

В MySQL вводят поддержку Javascript. Относительно недавно Redis сделал то же самое, теперь хранимки на JS можно будет писать и для MySQL. JS запускается на GraalVM.

Пример объявления функции

CREATE FUNCTION gcd_js (a INT, b INT) RETURNS INT 
LANGUAGE JAVASCRIPT AS $$

  let [x, y] = [Math.abs(a), Math.abs(b)];
  while(y) [x, y] = [y, x % y];
  return x;

$$;

Последующий вызов

SELECT col1, col2, gcd_js(col1,col2)
FROM my_table
WHERE gcd_js(col1, col2) > 1
ORDER BY gcd_js(col1, col2);

CREATE TABLE gcd_table 
AS SELECT gcd_js(col1,col2)
FROM my_table;

Отдельного внимания достойна реализации дебага JS. Допустим, есть функция, которая валидирует данные. Она выводит console.log и выкидывает строчку (не ошибку), если валидация проваливается

CREATE PROCEDURE division (IN a INT, IN b INT,
OUT result DOUBLE) LANGUAGE JAVASCRIPT AS $$
  function validate(num) {
    console.log("validating input value: ", num);
    if (num === 0) throw ("Division by Zero!");
  }
  validate(b);
  result = a / b;
$$

Теперь, при вызове функции с неверными данными мы увидим ошибку, а также сможем SELECT-ить то, что вывелось в консоль и stack-trace ошибки

CALL division( 5, 0, @res);
ERROR 6000 (HY000): JavaScript> Division by Zero!

SELECT mle_session_state("stdout");
validating input value:  0

SELECT mle_session_state("stack_trace");
<js> validate(division:9:187-214)
<js> division(division:11:222-232)
<js> :anonymous(division:15:256-265)
</js></js></js>

https://blogs.oracle.com/mysql/post/introducing-javascript-support-in-mysql

#development #javascript #mysql

Effection: Structured Concurrency and Effects for JavaScript

Наткнулся на анонс 3 версии библиотеки Effection. Анонс не очень интересный, а вот библиотека - очень даже интересная. Библиотека предоставляет удобное, хорошо структурированное и небольшое API, которое представляет легковесную альтернативу async/await подходу, но на основе генераторов и итераторов. Библиотека дает следующие плюшки и гарантии: отмена вызовов (за счет генераторов), легкая композиция, полный контроль за исполнением и отсутствие гонки. Выглядит интересно.

https://frontside.com/effection/

#development #javascript #concurrency #library

Let's Bring Back JavaScript's `with()` Statement

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

Если вы вдруг не знаете, что это за оператор, то вот вам ёмкое описание: оператор with позволяет переопределить скоуп поиска переменных.

Но лучше, конечно, показать кодом

const person = {
 name: 'Milton Friedman',
 wasRight: true
}

with(person) {
 console.log(name); // 'Milton Friedman'
 console.log(wasRight); // `true`
}

Обычно переменные ищутся сначала в лексическом скоупе (или что-то в этом роде), затем в глобальном (например в window). Оператор with позволяет добавить еще 1 приоритетный скоуп для поиска переменных. Если в нем не будет найдено переменной, JS пойдет искать дальше как обычно

Проблемы оператора with:
- Есть проблемы с читабельностью кода. Когда мы видим использование переменной name, как нам понять - это от скоупа with или откуда то еще?
- Если в скоупе with не окажется такой переменной, то она будет искаться в глобальном скоупе и может там найтись, что приведет к ошибкам. Например, мы прокидываем в with объект, у которого есть поле history. Но что, если мы ошиблись, и поле history есть не всегда? Тогда при попытке достать history JS его не найдет в with-скоупе, но найдет в window.
- Использование with замедляет код. Автор кстати пишет свой кастомный with, в котором пытается решить эту проблему. Интересно, что для реализации оптимизации он заиспользовал eval, в котором прописан нативный with. Решение интересное

function limitedWith(obj, cb) {
  const keys = Object.getOwnPropertyNames(obj);
  const scopedObj = new Proxy(obj, {
    has(_target, key) {
      return keys.includes(key);
    },
  });

  return eval(`
    with(scopedObj) {
      (${cb}.bind(this))();
    }
  `);
}

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

const person = {
 name: 'Milton Friedman',
 wasRight: true
}

// with вариант
with(person) {
 console.log(name); // 'Milton Friedman'
 console.log(wasRight); // `true`
}

// деструктуризация
const { name, wasRight } = person;
console.log(name); // 'Milton Friedman'
console.log(wasRight); // `true`

https://macarthur.me/posts/with

#development #javascript #with

Simulating Fluids, Fire, and Smoke in Real-Time

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

https://andrewkchan.dev/posts/fire.html

#development #javascript #animations

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

Legacy Seam
Небольшая заметка в блоге Мартина Фаулера про работу с легаси кодом. Данная заметка посвящена созданию швов в коде, которые позволили бы управлять поведением системы, не изменяя сам код системы. В статье на достаточном простом примере на JS показывается, как это можно реализовать и зачем это нужно.

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

Introducing JavaScript support in MySQL
В MySQL вводят поддержку Javascript. Относительно недавно Redis сделал то же самое, теперь хранимки на JS можно будет писать и для MySQL. JS запускается на GraalVM.


Effection: Structured Concurrency and Effects for JavaScript
Наткнулся на анонс 3 версии библиотеки Effection. Анонс не очень интересный, а вот библиотека - очень даже интересная. Библиотека предоставляет удобное, хорошо структурированное и небольшое API, которое представляет легковесную альтернативу async/await подходу, но на основе генераторов и итераторов. Библиотека дает следующие плюшки и гарантии: отмена вызовов (за счет генераторов), легкая композиция, полный контроль за исполнением и отсутствие гонки. Выглядит интересно.

В комментариях к посту много обсуждений на тему нужности и ненужности библиотеки и генераторов

Let's Bring Back JavaScript's `with()` Statement
Многие читатели канала возможно даже не знают про оператор with, а тут про него целая статья. Оператор with официально признан устаревшим и не рекомендованным к использованию, но в Kotlin такой оператор есть и он достаточно неплохо работает. В статье описывается, чем хорош оператор with и чем он плох.


Simulating Fluids, Fire, and Smoke in Real-Time
Статья про то, как реализовать анимацию огня. Много матана, много демок. Достаточно специфичный контент, но при этом вроде бы хороший. Демки очень интересные, но на моем рабочем ноуте достаточно тяжеловесные. мой Vivaldi подвисает просто от скролинга страницы.


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

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

More Than You Need to Know About ReactDOM.­flushSync

flushSync в React позволяет синхронизировать состояние компонента React с его представлением в DOM-дереве. Когда мы вызываем setState, React складывает обновления стейта в очередь, затем разбирает очередь, делает рендер, и чуть позже отображает компонент в DOM-дереве. Получается, что между установкой стейта и его отображением в DOM мы ожидаем как минимум двух шагов: рендера и коммита. Такая реализация позволяет избегать лишних ререндеров. flushSync позволяет нам сразу отобразить изменения в DOM-дереве т.к. этот метод форсит React синхронизировать состояние компонента и представления в DOM.

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

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

Рекомендуется к прочтению всем React-разработчикам.

https://julesblom.com/writing/flushsync

#development #javascript #react #flushSync #recommended

We invested 10% to pay back tech debt; Here's what happened

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

Технический долг опасен тем, что он увеличивает Lead Time, частоту появления ошибок, время на починку ошибок и восстановление, время на разработку. Автор статьи перешел в новый продукт, который оказался переполнен техническим долгом и задачи выполнялись заметно медленнее, чем он ожидал. Команда каждую ретроспективу поднимала тему исправления технического долга, но какого-то определенного плана не следовало. Пока однажды они все таки не договорились о том, что нужно уделять 20% времени исправлению технического долга. Продуктовый менеджер назвал эту цифру неприемлемой и в итоге команда сошлась на 10%.

Как организовать выделение 10% на исправление технического долга? Один из вариантов - дежурства, другой - пробовать оценивать работу. Команда же принимала решение на основе принципа, что вся команда должна вместе решать эту проблему, а не кто-то один. С одной стороны, вместе сделали - вместе исправляем. С другой стороны, это поощряет совместную работу. Таким образом родилась Пятница Технического Долга. Каждую пятницу команда делает не технические задачи, а выплачивает технический долг.

Вы можете заметить, что пятница в рабочей неделе - это 20% времени, а не 10%, но автор говорит что часть людей в пятницу берут day-off'ы, поэтому выходит близко к 10%. В целом, не суть сколько % времени на это выделяется, суть в самом подходе - вся команда имеет единое время, выделенное на исправление технического долга и при этом поощряется совместная работа.

Практика оказалась настолько удачной, что начала распространятся на другие команды.

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

https://blog.alexewerlof.com/p/tech-debt-day

#managment #technicalDebt #recommended

What should we ship?

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

https://rauno.me/craft/vercel

#development #javascript #vercel #html #css

How to make Storybook 2-4x faster

Команда Storybook рассказывает, как ускорить сборку storybook в проекте в 2-4 раза. Простые советы, которые могут улучшить вашу разработку:
- Используйте флаг --test для сборки storybook для визуальных и юнит-тестов. Это оптимизированная сборка storybook, в которой исключено все ненужно для автотестов. Возможно собранный storybook будет неплох и для разработки
- Генерация авто-доки к компонентам на основе TS медленная, за счет медленного TS. Генерируемая авто-дока - это фича Storybook, которая определяет, какие пропсы есть у компонента, какого они типа и отрисовывает панельку управления пропсами компонента. Лучших результатов можно достигнуть за счёт получения информации о типах от TS. Но это сильно замедляет сборку автодоки, поэтому, если вам эта фича не так важна - можно заменить docgen на тот, который получает инфу на основе AST кода, а не типов. Он работает в 2 раза быстрее
- Если вам не нужны все фичи storybook (например фича документации через mdx), то вы можете отключить эти фичи, передав опции в storybook/addon-essentials
- Перейдите на SWC, вместо webpack

https://storybook.js.org/blog/optimize-storybook-7-6/

#development #storybook #performance

Remote Mob Programming

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

Короткий список основных требований на пути к успешным сессиям моб-программирования в распределенном формате:
- Все должны работать удаленно. Если часть команды в офлайне друг с другом, а часть - через камеру, то возникает асиметричность информации, которая вредит коммуникации
- Камера всегда включена. Коммуникация намного более качественная, когда мы имеем возможность видеть друг друг
- Регулярные личные встречи. Чем лучше все друг друга знают, тем лучше все идет взаимодействие при удалённой работе. Поэтому периодически встречаться в офлайне для совместного времяпрепровождения и знакомства крайне положительно влияют на работу
- Маленькая команда. Во время удалённого моб-программирования случаются технические накладки, задержки, а говорить в 1 момент времени может только 1 человек. Как следствие, проводить сеанс удаленного моб-программирования неэффективно в большой команде.
- Единое рабочее время. У всех должен быть единый рабочий слот, в который люди готовы работать вместе в режиме моб-программирования. Не обязательно, и наверное даже вредно, выделять весь рабочий день как единое рабочее время. На сайте команда описывает свой опыт и они выделяют 6 часов, в которые все должны быть на связи
- Выделенная роль печатальщика (typist). Только 1 человек имеет контроль над клавиатурой. Этот человек следует инструкциям остальной команды, задает уточняющие вопросы. Человек не должен сам принимать какие-то решения и реализовывать их
- Шаринг экрана. Печатальщик шарит свой экран, а другие смотрят только на него. Есть IDE, которые созданы для совместной работы, но авторы статьи говорят, что им они не зашли т.к. люди начинают в них отвлекаться от общей сессии в пользу своих активностей.
- Короткие интервалы для смены ролей. Собственно ролей всего 2: печатальщик и остальные. Суть в том, чтобы меняться как можно чаще. Авторы используют 10 минутные интервалы, но в вашей команде возможно понадобятся другие. Ротация позволяет всем участвовать в процессе в обеих ролях.
- Передача кода через git. Для передачи кода от одного участника другому используется git. При этом можно упростить флоу до минимального: комитить месседжи "WIP" и работать во временной ветке. Перед вливанием кода в общую ветку code review не требуется т.к. код автоматически получается отсмотренным и проверенным в процессе моб-програмирования.
- Групповые решения. Групповые решения всегда лучше индивидуальных. Групповые решения - еще один автоматический плюс от моб-программирования. Однако, их все равно необходимо документировать, например через ADR.
- Постоянное движение. При работе в одиночку мы часто блокируемся: надо что-то погуглить, почитать документацию или подождать пока проведут code review. В моб-программировании блокировки исключаются т.к. все проблемы решаются тут же.
- Взаимное обучение. Шаринг знаний стоит в основе моб-программирования. Работая в едином окне, происходит взаимное опыление знаниями. Некоторые знания сложно получить другим способом. Например, ваш коллега настроил крутую фичу в IDE, про которую вы не в курсе, а он думает, что все про фичу знают. Также моб-программирование полностью решает проблему бас-фактора.
- Доверие. Экспресс-тест на доверие менеджмента к вам: скажите менеджеру, что с завтрашнего дня вы каждый день весь день будете работать вчетвером за 1 экраном. Если менеджмент вам доверяет, то не усомниться в верности вашей идеи. Чтобы внедрить моб-программирование в процесс разработки, необходимо обеспечить прозрачность коммуникаций и прогресса, а также построить доверительные отношения с менеджментом.

https://www.remotemobprogramming.org

#development #mobProgramming #pairProgramming #recommended

Дайджест за 2024-01-22 - 2024-01-26

⭐More Than You Need to Know About ReactDOM.­flushSync
flushSync в React позволяет синхронизировать состояние компонента React с его представлением в DOM-дереве. Когда мы вызываем setState, React складывает обновления стейта в очередь, затем разбирает очередь, делает рендер, и чуть позже отображает компонент в DOM-дереве. Получается, что между установкой стейта и его отображением в DOM мы ожидаем как минимум двух шагов: рендера и коммита. Такая реализация позволяет избегать лишних ререндеров. flushSync позволяет нам сразу отобразить изменения в DOM-дереве т.к. этот метод форсит React синхронизировать состояние компонента и представления в DOM.

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

⭐We invested 10% to pay back tech debt; Here's what happened
Во время разработки в системах неумолимо растёт технический долг. Есть много разных способов делить и определять технический долг, но в целом его можно поделить на созданный осознанно и не осознанно. Технический долг создается осознанно, когда нам необходимо успеть к релизу или срезать какие-то углы. Неосознанно технический долг создается, когда нам не хватает знаний, компетенций или культуры. Проблемы с техническим долгом нет, пока он выплачивается. Но как быть, если технический долг долгое время не выплачивался, а теперь надо начать? В статье предоставляется пример одной команды, которая нашла для себя ответ на этот вопрос.

Технический долг опасен тем, что он увеличивает Lead Time, частоту появления ошибок, время на починку ошибок и восстановление, время на разработку. Автор статьи перешел в новый продукт, который оказался переполнен техническим долгом и задачи выполнялись заметно медленнее, чем он ожидал. Команда каждую ретроспективу поднимала тему исправления технического долга, но какого-то определенного плана не следовало. Пока однажды они все таки не договорились о том, что нужно уделять 20% времени исправлению технического долга. Продуктовый менеджер назвал эту цифру неприемлемой и в итоге команда сошлась на 10%.

What should we ship?
Недавно у Vercel вышел новый лендинг. Статья же рассказывает, как разработчики реализовывали разные интересные решения для него - свою гибкую систему гридов, работу с иконками, удобные блоки кода, интерактивные визуализации и движения по орбитам. Выглядит красиво и интересно.

How to make Storybook 2-4x faster
Команда Storybook рассказывает, как ускорить сборку storybook в проекте в 2-4 раза. Простые советы, которые могут улучшить вашу разработку:\n- Используйте флаг --test для сборки storybook для визуальных и юнит-тестов. Это оптимизированная сборка storybook, в которой исключено все ненужно для автотестов. Возможно собранный storybook будет неплох и для разработки

⭐Remote Mob Programming
Mob-programming переводится буквально как программирование толпой (насколько я помню английский). Это как парное программирование, только вместо пары разработчиков за одним экраном и клавиатурой сидит вся команда. Сайт рассказывает про лучшие практики проведения моб-программирования в условиях распределенной разработки. Также там есть бесплатная книжка, где все описано подробнее.

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

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

Preventing and Debugging Memory Leaks in Node.js

Большая и обстоятельная статья про работу с утечками памяти в node.js. Статья буквально начинается с объяснения механизма выделения памяти в node.js, проходит через основные паттерны утечек памяти и заканчивается на примерах нахождения предотвращения утечек

Статью можно разделить на несколько разделов. Первый раздел: про то, что память выделяется на stack'е (переменные) и heap'е (все данные с динамичным размером) и механизм работы Garbage Collector

Далее статья рассказывает про основные источники утечек памяти:
- Глобальные объекты и переменные
- Замыкания
- Таймеры

После этого - исследование причин утечек памяти. Для начала автор показывает способ с получением дампа памяти через v8 через отправку процессу node.js специальный сигнал. Собираем дамп до нагрузки, собираем дамп после нагрузки, а затем анализируем разницу с помощью Chrome Dev Tools. В статье автор подробно показывает как собрать дампы и работать с дельтой двух снапшотов.

Но мало уметь писать хороший код и искать утечки с помощью современных инструментов. Необходимо также настроить автоматический мониторинг. Для этого можно использовать prometheus - один из популярнейших тулов для мониторинга состояния приложений.

В общем, очень хорошая статья про утечки памяти в node.js. Рекомендую к подробному изучению.

https://betterstack.com/community/guides/scaling-nodejs/high-performance-nodejs/nodejs-memory-leaks/

#development #recommended #nodejs #performance #memoryLeak

The Bun Shell

Каждый раз, когда необходимо написать код для какого-нибудь cli-скрипта, у нас есть 2 классических стула: писать скрипт на bash или писать скрипт на чистом node.js. Оба способа неудобны. Скрипты на bash (или powershell на windows) писать сложно т.к. там неудобный синтаксис, их сложно дебажить и поддерживать. Писать скрипты на чистом JS удобно, пока не приходится работать с окружением: вызывать существующие бинари (например ls) или работать с файловой системой. Очевидное решение - сделать инструмент на JS, который берет сильные стороны JS и bash. Один такой мы уже знает - zx от Google. Теперь же появился еще 1 инструмент от команды Bun - Bun Shell.

Bun Shell - это экспериментальный язык и интерпретатор в рамках Bun, который позволяет выполнять кросс-платформенные shell-скрипты на JavaScript и TypeScript. Он упрощает выполнение shell-команд и написание скриптов, делая их более доступными и легкими в использовании по сравнению с традиционными методами. Bun Shell хорошо интегрируется с shell системы.

Вместо тысячи слов, примеры использования Bun Shell

Использование бинарей из системы:

import { $ } from "bun";

// to stdout:
await $`ls *.js`;

// to string:
const text = await $`ls *.js`.text();

Использование переменных в командах. Обратите внимание, что filename содержит в себе преднамеренную ошибку - если вставить значение переменной в команду as is, можно нечаянно грохнуть всю файловую систему на unix-like системах. Однако bun делает безопасную вставку.

const filename = "foo.js; rm -rf /";

// This will run `ls 'foo.js; rm -rf /'`
const results = await $`ls ${filename}`;

console.log(results.exitCode); // 1
console.log(results.stderr.toString()); // ls: cannot access 'foo.js; rm -rf /': No such file or directory

Также весьма примечательно, что сделана интеграция с системой пайпов и потоков

import { $ } from "bun";

const buffer = new Response("bar
 foo
 bar
 foo
");

await $`grep foo < ${buffer}`;

Сам Bun не решается сравнивать свое решение с zx, но сравнение так и напрашивается. Я не очень хорошо помню все фишки zx, хотя использовать его приходилось. Но основная, на мой взгляд, фишка Bun Shell - это то, что он идет вместе с Bun из коробки. Никаких дополнительных пакетов, шагов установки - если у вас есть Bun, значит у вас есть и Bun Shell. И это круто.

https://bun.sh/blog/the-bun-shell

#development #bun #shell

Все оценки сроков разработки ПО — ложь

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

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

https://habr.com/ru/companies/ruvds/articles/787058/

#managment #estimation #noEstimates

Delicious Donut Components

Статья про композицию клиентских и серверных компонентов в React. Статья, в основном, фокусируется вокруг паттерна Donut Components (Пончиковые Компоненты). Серверные компоненты не могут импортироваться и использоваться в клиентских компонентах. Но можно прокидывать серверный компонент как child для клиентского. Это и есть паттерн пончика (извините, не могу удержаться от использования этого словосочетания на русском языке)

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

https://frontendatscale.com/blog/donut-components/

#development #react #reactServerComponents

TypeSpec

Команда TypeScript зарелизила инструмент для описания контрактов - TypeSpec. TypeSpec позволяет описывать контракты в удобном синтаксисе, очень похожем на TypeScript, а затем компилировать их в openapi-спеку, json schema и даже protobuf. Как я понял, можно написать свой компилятор, если вам нужно компилировать контракт во что-то еще (например в роуты nest.js)

Вот как описывается простой контроллер

import "@typespec/http";

using TypeSpec.Http;

model Pet {
  name: string;
  age: int32;
}

@route("/pets")
interface Pets {
  list(@query filter: string): Pet[];
  create(@body pet: Pet): Pet;
  read(@path id: string): Pet;
}

https://typespec.io

#development #typespec #openapi #typescript #swagger #protobuf #jsonSchema

Дайджест за 2024-01-29 - 2024-02-02

⭐Preventing and Debugging Memory Leaks in Node.js
Большая и обстоятельная статья про работу с утечками памяти в node.js. Статья буквально начинается с объяснения механизма выделения памяти в node.js, проходит через основные паттерны утечек памяти и заканчивается на примерах нахождения предотвращения утечек

Статью можно разделить на несколько разделов. Первый раздел: про то, что память выделяется на stack'е (переменные) и heap'е (все данные с динамичным размером) и механизм работы Garbage Collector

The Bun Shell
Каждый раз, когда необходимо написать код для какого-нибудь cli-скрипта, у нас есть 2 классических стула: писать скрипт на bash или писать скрипт на чистом node.js. Оба способа неудобны. Скрипты на bash (или powershell на windows) писать сложно т.к. там неудобный синтаксис, их сложно дебажить и поддерживать. Писать скрипты на чистом JS удобно, пока не приходится работать с окружением: вызывать существующие бинари (например ls) или работать с файловой системой. Очевидное решение - сделать инструмент на JS, который берет сильные стороны JS и bash. Один такой мы уже знает - zx от Google. Теперь же появился еще 1 инструмент от команды Bun - Bun Shell.

Bun Shell - это экспериментальный язык и интерпретатор в рамках Bun, который позволяет выполнять кросс-платформенные shell-скрипты на JavaScript и TypeScript. Он упрощает выполнение shell-команд и написание скриптов, делая их более доступными и легкими в использовании по сравнению с традиционными методами. Bun Shell хорошо интегрируется с shell системы.

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

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

Delicious Donut Components
Статья про композицию клиентских и серверных компонентов в React. Статья, в основном, фокусируется вокруг паттерна Donut Components (Пончиковые Компоненты). Серверные компоненты не могут импортироваться и использоваться в клиентских компонентах. Но можно прокидывать серверный компонент как child для клиентского. Это и есть паттерн пончика (извините, не могу удержаться от использования этого словосочетания на русском языке)

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

TypeSpec
Команда TypeScript зарелизила инструмент для описания контрактов - TypeSpec. TypeSpec позволяет описывать контракты в удобном синтаксисе, очень похожем на TypeScript, а затем компилировать их в openapi-спеку, json schema и даже protobuf. Как я понял, можно написать свой компилятор, если вам нужно компилировать контракт во что-то еще (например в роуты nest.js)

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

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

Knip v4

Вышла 4 версия инструмента knip. Я уже писал о нем в канале - это инструмент для нахождения в проекте неиспользуемого кода. Легко встраивается в CI и быстро начинает приносить пользу. В новой версии не особо много изменений, но самое важное из них - knip теперь работает на 80% быстрее (видимо, в том числе благодаря другому изменению - теперь knip по-дефолту не анализирует использование свойств класса т.к. это требует много ресурсов)

https://knip.dev/blog/knip-v4

#development #javascript #knip #releaseNotes

The AHA Stack

Большой сайт, посвященный AHA-стеку: Astro + htmx + alpine.js. Если коротко, то основная идея стека крутится вокруг старого доброго веба, где сайты были легки, не было кучи JS в браузере, а основную работу делали серверы. Но все это с новым удобным и современным тулингом.

https://ahastack.dev

#development #javascript #aha #astro #htmx #alpinejs

The Golden Rule of Assertions

Часто можно услышать правило "один тест - одна проверка". Проблема с этим утверждением, что его часто понимают слишком буквально, что приводит к проблемам. В статье предлагается еще 1 правило "A test must fail if, and only if, the intention behind the system is not met." (Тест должен упасть только тогда, когда намерение, заложенное в системе, не достигнуто).

Для понимания сути правила, автор приводит 2 примера его нарушения:
- Проверка внутренней имплементации, вместо внешнего поведения
- Нарушение границ теста

Пример проверки внутренней имплементации: parseCookieName использует внутри себя cookieUtils. Тест проверяет, что cookieUtils вызывается корректно, при вызове parseCookieName. Этот тест проверяет имплементацию, а поэтому упадет, когда имплементацию изменят. Например, cookieUtils будет заменен на библиотеку из npm

import { parseCookieName } from './parseCookieName'
import { cookieUtils } from './utils'

it('returns the cookie name from the given cookie', () => {
  const cookieName = parseCookieName('sessionId=abc-123')

  expect(cookieUtils.parse).toHaveBeenCalledWith(
  'sessionId=abc-123',
  { pick: ['name'] }
 )
  expect(cookieName).toBe('sessionId')
})

С границами теста пример не такой простой. Допустим, есть функция, делающая сетевой запрос

export async function fetchUser(id) {
  const response = await fetch(`https://example.com/user?id=${id}`)
  const user = await response.json()
  return user
}

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

import { fetchUser } from './fetchUser'

it('fetches the user by id', async () => {
  const user = await fetchUser('abc-123')
  expect(user).toEqual({ name: 'Cody' })
})

Эту проблему можно обойти разными способами. Например, замокировав сеть.

https://www.epicweb.dev/the-golden-rule-of-assertions

#development #javascript #testing #assertions