Релиз Deno 2.4

Вышел Deno 2.4. Очень много работы над developer experience, а также часть фичей вышли из экспериментальных в стабильные

Восстановили deno bundle. Это команда, которая собирала приложение в 1 бандл. Работала как для серверных приложений, так и для браузерных. В какой-то момент ее задепрекейтили, теперь снова вернули с esbuild под капотом. В будущем обещают программное API для создания бандлов.

Добавили возможность импортировать не код.

Ранее картинки и другие файлы необходимо было считывать в рантайме

const image = Deno.readFileSync(import.meta.resolve("./image.png"));
const text = await Deno.readTextFile(import.meta.resolve("./log.txt"));

Теперь же можно использовать обычные импорты с атрибутами

import message from "./hello.txt" with { type: "text" };
import bytes from "./hello.txt" with { type: "bytes" };
import imageBytes from "./image.png" with { type: "bytes" };

console.log("Message:", message);
// Message: Hello, Deno!

console.log("Bytes:", bytes);
// Bytes: Uint8Array(12) [
//    72, 101, 108, 108, 111,
//    44,  32,  68, 101, 110,
//   111,  33
// ]

Deno.serve((_req) => {
  return new Response(imageBytes, {
    status: 200,
    headers: {
      "Content-Type": "image/png",
      "Content-Length": imageBytes.byteLength.toString(),
    },
  });
});
// Shows image.png at localhost:8000

Кроме того, можно импортировать и wasm-файлы

Поддержку OpenTelementry сделали стабильной. До этого релиза OpenTelemetry была экспериментальной фичей, включаемой флагом. Теперь дополнительный флаг не нужен - достаточно установить переменную окружения OTEL_DENO=1

Добавили флаг --preload для указания кода, который должен запуститься до запуска основного скрипта. Может быть полезно для задания каких-то глобальных настроек или создания глобальных сущностей.

Добавили явный флаг --coverage для сборки покрытия кода. Вывод coverage в консоли представлен в виде markdown-таблицы, которую легко вставить в любой markdown-документ. Также и benchmark таблицы теперь тоже в markdown формате. Забота о разработчиках, которой нам не хватало :)

Добавили DENO_COMPAT=1 - переменная окружения, которая устанавливает все флаги, сделанные для поддержки работы с package.json

Доработали систему разрешений. В --allow-net можно указывать вайлдкарты доменов и пространства сетей CIDR - --allow-net=*.foo.localhost, --allow-net=192.168.0.128/25. Также добавили флаг --allow-import и --deny-import для разрешения и запретов импортов из определенных источников --deny-import=cdn.jsdelivr.net

В Deno 2.3 ввели возможность использовать локальные нпм-пакеты через поле patch. Получили фидбек от сообщества, что patch может запутать т.к. в npm это используется по-другому. Поэтому локальные пакеты теперь надо указывать в секции links

Кроме этого:
- Улучшили совместимость с nodejs
- Добавили во встроенный линтер поддержку XML и SVG
- Улучшили поддержку tsconfig
- Улучшили свой LSP

https://deno.com/blog/v2.4

#development #javascript #deno #releaseNotes

Repomix: Pack your codebase into AI-friendly formats

Repomix - библиотека, которая запакует ваш репозиторий в формат, удобный для AI. Собранный документ затем можно кидать в любую LLM как проект, с которым можно работать.

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

https://repomix.com

#development #javascript #library #ai

Modern Node.js Patterns for 2025

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

Из банальных советов: используйте ESM, fetch, async await, воркеры для сложных вычислений, кастомные классы ошибок. Менее банальные стоит расписать подробнее.

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

В nodejs завезли test-runner, теперь можно запускать автотесты без внешних библиотек

В nodejs с самого начала была хорошая поддержка потоков (Streams). Теперь же потоки есть и в Web-стандартах, поэтому пора переходить на работу с ними, делая свой код кросс-платформенным.

Завезли новые удобные флаги для разработки - --watch, --env-file, которые убирают необходимость во внешних библиотеках типа dotenv и nodemon

Также в nodejs теперь есть возможность ограничивать возможность приложений как в deno. Правда, пока за экспериментальными флагами

# Run with restricted file system access
node --experimental-permission --allow-fs-read=./data --allow-fs-write=./logs app.js

# Network restrictions
node --experimental-permission --allow-net=api.example.com app.js

В nodejs теперь есть возможность мониторить перформанс, что, опять же, убирает необходимость во внешних библиотеках

import { PerformanceObserver, performance } from 'node:perf_hooks';

// Set up automatic performance monitoring
const obs = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    if (entry.duration > 100) { // Log slow operations
      console.log(`Slow operation detected: ${entry.name} took ${entry.duration}ms`);
    }
  }
});
obs.observe({ entryTypes: ['function', 'http', 'dns'] });

// Instrument your own operations
async function processLargeDataset(data) {
  performance.mark('processing-start');
  
  const result = await heavyProcessing(data);
  
  performance.mark('processing-end');
  performance.measure('data-processing', 'processing-start', 'processing-end');
  
  return result;
}

Если вам нужно доставлять nodejs-приложение единым файлом, то nodejs теперь умеет делать это сама (опять же - убирается зависимость от внешних тулов)

# Create a self-contained executable
node --experimental-sea-config sea-config.json

Также следует использовать новые возможности node:diagnostics_channel. Можно создать канал диагностики, куда можно публиковать события, которые можно затем передавать в специализированный тулинг

import diagnostics_channel from 'node:diagnostics_channel';

// Create custom diagnostic channels
const dbChannel = diagnostics_channel.channel('app:database');
const httpChannel = diagnostics_channel.channel('app:http');

// Subscribe to diagnostic events
dbChannel.subscribe((message) => {
  console.log('Database operation:', {
    operation: message.operation,
    duration: message.duration,
    query: message.query
  });
});

// Publish diagnostic information
async function queryDatabase(sql, params) {
  const start = performance.now();
  
  try {
    const result = await db.query(sql, params);
    
    dbChannel.publish({
      operation: 'query',
      sql,
      params,
      duration: performance.now() - start,
      success: true
    });
    
    return result;
  } catch (error) {
    dbChannel.publish({
      operation: 'query',
      sql,
      params,
      duration: performance.now() - start,
      success: false,
      error: error.message
    });
    throw error;
  }
}

https://kashw1n.com/blog/nodejs-2025/

#development #javascript #nodejs

Speculative Optimizations for WebAssembly using Deopts and Inlining

Статья в блоге V8 про ускорение WASM в недавнем релизе V8. В целом WASM ранее не нуждался в каких-то спекулятивных оптимизациях т.к. сгенерированный wasm-код уже был эффективный. Но вот мы дошли до создания WASM Garbage Collector, чтобы позволить языкам типа Java, Kotlin, Dart компилироваться в WASM. И вот в WasmGC уже можно заниматься спекулятивными оптимизациями.

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

https://v8.dev/blog/wasm-speculative-optimizations

#development #javascript #v8 #wasm #performance

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

Релиз Deno 2.4
Вышел Deno 2.4. Очень много работы над developer experience, а также часть фичей вышли из экспериментальных в стабильные

Восстановили deno bundle. Это команда, которая собирала приложение в 1 бандл. Работала как для серверных приложений, так и для браузерных. В какой-то момент ее задепрекейтили, теперь снова вернули с esbuild под капотом. В будущем обещают программное API для создания бандлов.

Repomix: Pack your codebase into AI-friendly formats
Repomix - библиотека, которая запакует ваш репозиторий в формат, удобный для AI. Собранный документ затем можно кидать в любую LLM как проект, с которым можно работать.

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

Modern Node.js Patterns for 2025
Список современных бест-практисов nodejs в частном блоге. Часть бест-практисов уже "старые", часть - достаточно интересные. В любом случае полезно ознакомиться, возможно найдете что-то для себя

Из банальных советов: используйте ESM, fetch, async await, воркеры для сложных вычислений, кастомные классы ошибок. Менее банальные стоит расписать подробнее.

Speculative Optimizations for WebAssembly using Deopts and Inlining
Статья в блоге V8 про ускорение WASM в недавнем релизе V8. В целом WASM ранее не нуждался в каких-то спекулятивных оптимизациях т.к. сгенерированный wasm-код уже был эффективный. Но вот мы дошли до создания WASM Garbage Collector, чтобы позволить языкам типа Java, Kotlin, Dart компилироваться в WASM. И вот в WasmGC уже можно заниматься спекулятивными оптимизациями.

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

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

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

Introducing the first alpha of Turso: The next evolution of SQLite

Не только JS-тулинг переписывают на Rust. Очередь дошла и до sqlite. Turso - новая СУБД на RUST, которая совместима с sqlite, но также имеет дополнительные фичи.

Собственно ради дополнительных фичей все и переписали. Технически, можно было бы доработать sqlite, но, как сообщают авторы Turso, сообщество sqlite достаточно консервативное и не принимает доработки от сторонних авторов.

Поэтому они решили сделать свое решение, которое было бы полностью совместимо с sqlite, но еще и обладает дополнительными фичами.

Что это за фичи:

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

Встроенный векторный поиск, что крайне полезно для ML и AI проектов

Пока проект в стадии альфа-тестирования. Что обещают в будущем:
- Индексы
- Многопоточность
- Тригеры
- Views
- Saveopoints

В общем ждем. Может быть в будущем будем читать как кто-то построил интересное веб-решение на основе Turso.

https://turso.tech/blog/turso-the-next-evolution-of-sqlite

#development #sqlite #rust

zshy - The no-bundler build tool for TypeScript libraries

Zshy - билд тул для typescript библиотек. Это инструментарий, который был создал для Zod, но теперь его адаптировали для широкого использования и выложили в опенсорс.

Под капотом используется tsc, сам zshy не пытается вам навязать правильный стиль написания кода, а просто собирает проект.

https://github.com/colinhacks/zshy

#development #javascript #typescript #library #github

jsonrepair

jsonrepair - библиотека для починки сломанного json. Библиотека умеет чинить типичные проблемы - копирование JS-объектов в JSON, пропущенные запятые или незакрытые скобки, учитываются особенности вставки JSON из разных источников.




https://github.com/josdejong/jsonrepair

#development #JSON #library

Поговорим про клавиатурки

Я пишу этот пост с раздельной эргономичной ортолинейной низкопрофильной механической сплит клавиатуры. Если вы нормальный человек, у вас должен появиться вопрос "а что это значит?". Если вы тоже в этой теме, то возможно вам интересно, как я дошел до такой жизни.

Давайте разберем, что значит каждый атрибут:
- Механическая - используются механические переключатели
- Сплит - клавиатура разделена на 2 независимых части
- Эргономичная - обычные клавиатуры неудобны для человеческих кистей. Поэтому все клавиатуры, которые как-то подстраиваются под человеческий организм называют эргономичными
- Программируемая - на клавиатуре около 60 клавиш и им можно назначать различные действия через прошивку или ПО. Так как 60 клавиш - мало для реальной работы, то используется концепция слоев - каждый слой содержит свой мапинг клавиш, а слои переключаются по определенным тригерам
- Ортолинейная - если вы посмотрите на свою клаву, вы увидите, что клавиши выстроены не в ровные колонки, а со смещением. Это сделано из-за особенностей строения старых печатных машинок - рычаги под клавишами не должны были задевать друг друга. Рычажков давно нету, а раскладка осталась. Но наши пальцы - они прямые, без сдвигов, поэтому сдвиги клавиш избыточны. Вот в ортолинейных клавиатурах все кнопки выстроены в ровные колонки. В сочетании со сплит это позвляет печатать двигая пальцы вперед-назад, не двигая их влево-вправо. Рука, в этом случае, печатает неподвижно.
- Низкопрофильные - клавиши с коротким ходом (низкие)

Когда-то я использовал обычные клавиатуры и все было хорошо. Я умел печатать в слепую (спасибо за это тысячам наигранных часов в World of Warcraft). Но мне стало неудобно использовать обычную клавиатуру, когда я стал писать много веб кода.

Я пишу код быстро. Ял знаю основные хоткеи, которые позволяют мне навигироваться по файлам и сущностям без использования мышки. Когда я парно программирую с людьми, которые так не умеют - я стараюсь их переучить, т.к. использование мышки настолько замедляет работу, что мне становится больно наблюдать за этим. Скролить Tree View мышкой для поиска файла (вместо jump to file или, на худой конец find in directory) или искать метод в файле через скрол (вместо jump to symbol) - это примерно как купить феррари и ездить со скоростью 20км\ч - в целом легально, но это какая-то мука.

Мои знакомые говорят, что прямая работа с кодом - не более 20% времени работы программиста, а печать кода - и того меньше. Поэтому нет смысла оптимизировать эту часть работы. Но это не матчится с моим опытом. Там, где я быстро проверяю десятки маленьких гипотез (например "можно ли решить задачу хуком в роутере?"), получая новые знания, люди с мышкой проверяют за то же время всего парочку.

Но даже знание хоткеев не спасает - иногда нужно использовать клавиши, которые требуют полной перестановки кистей на клавиатуре: <>, стрелочки, pgup и тд. 

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

Я пробовал разные варианты клавиатур, но последние несколько лет работаю с lilly 58pro. С этой клавиатуры и пишу пост. Навык печати на обычных клавиатурах еще не потерял, но переход с классической клавиатуры на сплит занимает где-то часик-два (обычно проблемы с клавишами на краю клавиатуры - win, cmd, f12, т.к. они могут по разному располагаться на клавиатурах). Я использую низкопрофильные свичи kailh choc, линейные и тактильные. Тактильные для обычных клавиш, а линейные для модификаторов и того, что надо зажимать.

Отдельный неожиданный прикол - каждый гость спрашивает, почему у меня "сломанная" клавиатура.

Давайте пофлексим - скидывайте в чат свои клавиатуры, а я скину свою.



#note #keyboards

How to test React Server Component

Удивительно, столько движа вокруг серверных компонентов React. Но при этом нет никаких официальных туториалов как тестировать эти компоненты (по крайней мере я не видел таких туториалов и в статье говорят что их нет)

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


https://www.nico.fyi/blog/how-to-test-react-server-component

#development #javascript #react #reactServerComponents #testing

Expert Generalists

Статья в блоге Мартина Фаулера про T-shaped специалистов. Точнее, все текущие термины (T-shape, П-shape, и другие) плохо подходят, поэтому в статье вводится термин Expert-Generalist, который означает, что человек одновременно является и экспертом (в противовес generalist) и использует свою экспертизу во многих областях (в противовес эксперту в одной области).

В данном случае имеется в виду, что человек является экспертом в фундаментальных понятиях, которые позволяют ему быть успешным в областях, которые построены на этих понятиях. Классический пример из IT, это когда человек имеет опыт написания ПО на 3-4 языка программирования и ему после этого уже не так важно, на каком именно другом языке писать код, пока этот язык следует общим парадигмам (основан на том же фундаменте). Условно, человек, который писал на JS, PHP, JAVA, C++ с легкостью может войти в Go, Rust, Kotlin. Но, вероятно, столкнется с некоторыми проблемами при входе в Haskell. Но, скорее всего, сможет это сделать в короткие сроки.

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

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

В чем сила таких специалистов:

Как правило, такие люди быстро обучаются - они изучат новый инструментарий, если он решает текущую задачу. Как следствие, они создадут более лучшее решение за счет подходящих инструментариев.

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

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

Ключевые качества экспертов-генералистов:
- Любознательность
- Умение сотрудничать
- Фокус на клиенте (бизнесовая направленность)
- Ставка на фундаментальные знания
- Широта знаний
- Способность понимать позицию смежных доменов (например, понимать проблемы SRE или DevOps)

Многие эксперты-генералисты вырастают в технических лидеров

Встает закономерны вопрос: "где брать таких специалистов?". Текущий найм устроен так, что мы скорее наймем ультра-эксперта в технологии, чем наймем человека, который любознателен и умеет погружаться в новые домены. В статье предлагается подход из двух решений:
- Перестать смотреть только на узкие хард-скилы. Вместо этого следует проверять человека на обучаемость, любознательность, создание условий для совместной работы
- Проводить внутренние тренинги и воркшопы, цель которых - погрузить специалистов в смежные области. В Thoughtworks есть 3 воркшопа, в которых специалисты делают решения из смежных областей. В рамках воркшопа они реализуют простые прототипы kafka, kubernetes, delta lake (штука для работы с данными). Создав прототип, люди начинают понимать базовые принципы, на которых основаны эти системы и начинают видеть рабочие ситуации с другой стороны

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

Для каждой ключевой компетенции в команде нужен 1-2 специалиста.

---

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



https://martinfowler.com/articles/expert-generalist.html

#managment #tshape #martinFowler

npq allows you to audit npm packages before you install them

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

Выглядит интересно, хотя само решение достаточно простое (т.к. audit уже в целом встроен в npm). Как будто такие штуки должны быть сделаны внутри менеджеров пакетов, а не поставляться как отдельный тул.

https://github.com/lirantal/npq

#development #javascript #security #audit

ts-regexp - a minimal, statically typed alternative to JavaScript's RegExp

ts-regexp - либа для типизированных RegExp.

Проще показать код, чем расписывать, что умеет либка


Это обычный RegExp (читать голосом из рекламы "это обычный порошок") - выводятся весьма абстрактные типы

const groups1 = new RegExp('^(?<year>\\d{4})-(?<month>\\d{2})-(?<day>\\d{2})$', 'g').exec('2000-10-24')!.groups;
//      ⤴ '{ [key: string]: string; } | undefined' 🤮

А это ts-regexp - выводятся захваченные группы

const groups2 = typedRegExp('^(?<year>\\d{4})-(?<month>\\d{2})-(?<day>\\d{2})$', 'g').exec('2000-10-24')!.groups;
//      ⤴ '{ year: string, month: string, day: string }' 🥰

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

https://github.com/codpro2005/ts-regexp

#development #javascript #typescript #regexp #library

What Improves Developer Productivity at Google? Code Quality

В 2022 году Google опубликовали внутреннее исследование по продуктивности разработчиков. Если коротко, то основной вывод: лучший способ повысить продуктивность - улучшить качество кода.

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

В Google периодически разработчикам рассылают опрос в стиле "насколько вы удовлетворены" - работой, инструментами, коллегами и тд. Отвечать на них нужно в спектре нет - скорее нет - не знаю - скорее да - да. Каждый разработчик проходит такой опрос раз в 9 месяцев. Также в Google собирают различные данные по работе разработчиков - время на code review, время на влитие изменений, количество написанных строчек кода и тд

В исследовании ищут связь между ответом на вопросом "насколько вы были продуктивны последние 3 месяца" и ответами на другие вопросы (субъективные метрики) и метриками (объективные цифры). Искали корреляцию между ответом на "вы продуктивны?" и 39 метриками. Важное отличие исследования - для выявления связи был выбран метод панельного анализа - это когда вывод делается на основе слежения за одним и тем же человеком какое-то время. Панельный анализ выявил причинно-следственную связь "качество кода" => "продуктивность"

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

Что больше всего влияет на ощущаемую продуктивность (расположено в порядке убывания влияния):
- Удовлетворенность качеством кода 📈(выше - лучше)
- Смена приоритетов 📉 (негативное влияние)
- Тех долг проекта 📉
- Использование новейших тулов и инфры 📈
- Удовлетворенность тулингом и инфрой 📈
- Медленное Code Review 📉
- Сложное изучение инструментария 📉
- Тех долг зависимостей 📉
- Скорость сборки приложения 📈
- Организационные изменения 📉

Также, популярные в среде разработчиков причины снижения продуктивности, связь с которыми не подтвердилась:
- Длительность встреч
- Качество документации
- Физическая или организационная дистанция до менеджера и ревьюеров

По результатам исследования Google решили заняться повышением качества кода:
- Провели несколько внутренних конференций по качеству кода
- Создали модель Technical Debt Maturity Model и фреймворк для управления техническим долгом
- Команды поставили цели в OKR по управлению техническим долгом
- Раздают награды за большой вклад в улучшение качества кода

Какие минусы у исследования:
- Это Google. Многие идеи актуальны только в контексте Google и не подходят другим контекстам
- Мало объективных метрик, но много субъективных. Многие метрики, имхо, странные (физическое расстояние до менеджера). В то же время, нет многих других метрик (ну например, количество, приемочных багов)
- Особенно странно, что целевая метрика - "ощущаемая человеком продуктивность" - тоже субъективная
- Замерялся индивидуальный перформанс, а не командный
- Выводы на основе 2х замеров каждого разработчика. 2х замеров, имхо, мало.

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

В документе есть много интересного - не поленитесь почитать сами.

https://storage.googleapis.com/gweb-research2023-media/pubtools/6862.pdf

#development #research #google #codequality #technicalDebt #productivity

Дайджест за 2025-07-28 - 2025-08-01

Expert Generalists
Статья в блоге Мартина Фаулера про T-shaped специалистов. Точнее, все текущие термины (T-shape, П-shape, и другие) плохо подходят, поэтому в статье вводится термин Expert-Generalist, который означает, что человек одновременно является и экспертом (в противовес generalist) и использует свою экспертизу во многих областях (в противовес эксперту в одной области).

В данном случае имеется в виду, что человек является экспертом в фундаментальных понятиях, которые позволяют ему быть успешным в областях, которые построены на этих понятиях. Классический пример из IT, это когда человек имеет опыт написания ПО на 3-4 языка программирования и ему после этого уже не так важно, на каком именно другом языке писать код, пока этот язык следует общим парадигмам (основан на том же фундаменте). Условно, человек, который писал на JS, PHP, JAVA, C++ с легкостью может войти в Go, Rust, Kotlin. Но, вероятно, столкнется с некоторыми проблемами при входе в Haskell. Но, скорее всего, сможет это сделать в короткие сроки.

npq allows you to audit npm packages before you install them
npq - исполняемый пакет в npm, который проверяет безопасность пакетов перед их установкой и выводит найденные уязвимости, после чего юзер может принять решение, устанавливать ему пакет или нет.

Выглядит интересно, хотя само решение достаточно простое (т.к. audit уже в целом встроен в npm). Как будто такие штуки должны быть сделаны внутри менеджеров пакетов, а не поставляться как отдельный тул.

ts-regexp - a minimal, statically typed alternative to JavaScript's RegExp
ts-regexp - либа для типизированных RegExp.


What Improves Developer Productivity at Google? Code Quality
В 2022 году Google опубликовали внутреннее исследование по продуктивности разработчиков. Если коротко, то основной вывод: лучший способ повысить продуктивность - улучшить качество кода.

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

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

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

How we made JSON.stringify more than twice as fast

Статья в блоге V8 про ускорение работы JSON.stringify в 2 раза в определенных кейсах. JSON.stringify наверное одна из самых часто-используемых функций, а поэтому её производительность очень важна. Удивительно, что спустя столько лет все еще находится возможность оптимизировать эту функцию

Что сделали: если вы вызываете JSON.stringify и передаете туда простой объект или массив, не используете 2 и 3 аргументы функции, не используете .toJSON и еще несколько ограничений, то V8 вместо обычного рекурсивного алгоритма будет использовать итеративный, который переведет объект в json в 2 раза быстрее.

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

https://v8.dev/blog/json-stringify

#development #javascript #v8 #JSON #performance

Отзыв на обучение в Стратоплане

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

Эта заметка про модуль "Развитие и оценка ключевых людей".

Какие модели есть в области развития людей

4 Уровня обучения (the four levels of teaching)
Модель от 1969 года за авторством Martin Broadwell говорит, что путь изучения чего-либо проходит через 4 этапа:
- Неосознанная некомпетентность
- Осознанная некомпетентность
- Осознанная компетентность
- Неосознанная компетентность

В чем особенность каждого этапа
Неосознанная некомпетентность - на этом этапе человек не знает, что он чего-то не знает. Бывает так, что человек знает про что-то, но на самом деле не представляет что там внутри. Типичное в IT "Почему дизайнеры/фронтендеры так долго красят кнопку?". Для перехода на следующий момент должен произойти какой-то момент, в котором человек осознает, что все сложнее, чем ему кажется (AHA! monent)

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

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

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

Самый популярный бытовой пример - катание на велике (я через этот путь прошел всего пару лет назад)
- Сначала кажется: да что там, садись, крути педали, делов то
- Потом наступает много моментов, когда что-то не получается - падаешь, не вписываешься в поворот, следишь за телом и тп
- Затем уже хорошо катаешься, но все еще следишь за тем, чтобы все было правильно
- Затем просто катаешься и уже не понимаешь, как у тебя могла быть проблема "крутить педали" - это же так просто!


---



Это, конечно, круто, но как понять кого развивать?
Есть несколько моделей

Модель TOP - Таланты, Возможности, Желания

По каждому человеку надо узнать
- Что человек умеет делать
- Что человек может делать
- Что человек хочет делать

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

В идеале вам надо находит те области, в которых собран сразу весь T, O, P. Если где-то собрано только 2 из 3, то надо подумать, можно ли подтянуть 3 фактор. Самый простой пример - человек хочет научиться настраивать CI/CD, но думает что на проекте нет возможности. Однако, если хорошо подумать (или поговорить с руководителем), окажется, что задачи на настройку CI/CD на самом деле есть.

Модель оценки потенциала 9 box grid
Также простая и эффективная модель.
Есть 2 оси:
- Перформанс человека
- Потенциал человека

Каждая ось делится на 3 отрезка:
- Хороший\высокий
- Средний
- Плохой\низкий

Получается 9 ячеек от "плохой перформанс, низкий потенциал" до "хороший перформанс\высокий потенциал"

Ну собственно по матрице, примерно понятно что надо делать

Левый нижний угол - либо ошибки найма либо зоны коррекции, правый верхний угол - люди, которым, нужны новые горизонты

---

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

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




#note #stratoplan

No, AI is not Making Engineers 10x as Productive

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

Одних это восхищает, других напрягает. Автора, вот, напрягает. Он столкнулся с ситуацией, когда все вокруг говорят о 10-кратном увеличении производительности с ИИ, а он к этому не прикоснулся.

Автор попробовал различные инструменты для разработки с ИИ и сделал следующий вывод: все разговоры про увеличение производительности в 10 раз - это очень сильное преувеличение. Да, можно добиться ускорения написания шаблонного кода или ускорить погружение в какой-то новый инструментарий (сам автор приводит в пример, что с ИИ написал eslint правило за пару минут, хотя сам потратил бы времени намного больше т.к. надо изучать eslint).

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

Кроме того, не возможно добиться 10-кратного увеличения производительности, если мы говорим о доставке фичей на прод. Можно на сколько ускорить кодинг, но сложно ускорить все остальные процессы:
- Код ревью (тут я с автором, конечно, не согласен, но код ревью и без ИИ можно ускорить в тысячу раз - достаточно перестать его делать на все изменения)
- Тестирование
- Общение с заказчиком и командой
- Формирование требований
- Проектирование решения

Настоящая работа намного шире, чем просто кодинг.

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

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

https://colton.dev/blog/curing-your-ai-10x-engineer-imposter-syndrome/

#development #ai

Express Slow Down

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

express-slow-down - библиотека, которая предоставляет express middleware, который вместо отбивания HTTP-ошибкой как бы приостанавливает обработку запроса, давая ту же гарантию (приложение не будет обрабатывать больше Х запросов в единицу времени), но не отбивая ошибкой, а подвешивая обработку запроса.

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

https://github.com/express-rate-limit/express-slow-down

#development #javascript #nodejs #express #github #library #middleware

Почему стоит использовать Tagged Unions при разработке на TypeScript

Хорошая статья про паттерн Tagged Union (который может называться по-разному, я до этого встречал его под названием discriminated union). В чем суть - если у вас в какую-то ветку кода попадает объект с типом A | B, то вам придется каким-то образом уточнять тип, чтобы быть уверенным в корректной работе кода (или убедить в этом typescript)

Очень удобно, когда такое поле уже есть. Например API отдает объекты A | B | C, но мы можем определить каждый объект по полю type. Но если такого поля нет - его можно заложить самим. В этом и есть суть паттерна.

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

type Response = {
   name: string;
   coordinates: [number, number] | [number, number][]
}

Во всем коде, который работает с такой структурой, придется писать логику проверки структуры объекта.

Вместо этого, мы можем сделать это 1 раз и сохранить в поле, а само поле использовать для определения типа

// не пинайте за код, это просто пример
type PointResponse = Response & { type: "point" }
type PolygonResponse = Response & { type: "polygon" }

function tagResponse(item: Response) {
    const type = Array.isArray(item.coordinates[0]) ? "polygon" : "point"
    return {
        type,
        ...item
    }
}

function handleResponse(item: Response) {
    const taggedItem = tagResponse(item)
    switch (taggedItem.type) {
        case "point":
            // point logic
            break;
  case "polygon":
         // polygon logic
         break;
    }
}

Код получился субъективно лучше, чем если бы мы воткнули проверкки на поля. Особенно, если бы пример был сложней т.к. текущий - очень утрированный.

Хотя, конечно, если это ваше API - лучше обсудить изменение контракта на более понятный. Напоминаю, что отсылать геообъекты без явного указания их типа - бесчеловечно.

В статье приводятся и другие примеры и примеры, когда паттерн используется в рамках других паттернов (например, Result-монада)

Хорошая статья, хоть и простая и для некоторых читателей не принесет ничего нового. В комментариях, как обычно, свидетели "ох уж этот JS/фронтендеры", но есть и интересные комментарии.

https://habr.com/ru/companies/megafon/articles/933752/

#development #javascript #typescript