Инициатива Interop

📌 Для тех, кто не слышал, что это.
Это совместная работа крупнейших команд разработчиков браузеров (Google Chrome, Mozilla Firefox, Microsoft Edge и Apple Safari) для согласованной разработки фич, чтобы стандарты быстрее распространялись и получали стабильную кроссбраузерную поддержку.

Например, одним из предыдущих достижений является обеспечение поддержки современных спецификаций CSS и HTML. Одна из целей инициативы состояла в улучшении совместимости CSS-свойства gap для Flexbox и Grid Layout, которое теперь корректно работает.

📌 В феврале были анонсированы фичи для проработки в этом году. Вот некоторые из них: новые методы для WASM, Storage Access API, URLPattern, Anchor positioning.

📌 Для Storage Access API планируют добавить document.requestStorageAccess(), который повзоляет содержимому iframe запрашивать разрешение на хранение и чтение файлов cookie и других данных сайта. И document.hasStorageAccess(), который, соответсвенно, проверяет, предоставлено ли разрешение.

📌 Что касается WASM, то упоминаются два улучшения:
- Resizable Buffers (позволяют динамически изменять размер памяти, выделенной для модуля WebAssembly, прямо во время выполнения программы, что полезно для оптимизации использования памяти и повышения производительности приложений, работающих с большими объемами данных).
- JS String Built-ins (помогают преобразовывать данные между форматом WASM и привычными строковыми типами JS).

📌 Кроме того, продолжают работу над улучшением совместимости обработки MouseEvent в Safari. Да, наконец-то!!! Стоит сказать, что в прошлом году Safari значительно улучшил поддержку.

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

В 2025 основными направлениями инициативы являются обеспечение одинакового поведения CSS, улучшение конфиденциальности с помощью Storage Access API (но, пока отсутствует хорошая автоматизированная система тестирования для проверки конфиденциальности в разных браузерах) и улучшение доступности(a11y).

Подписывайся / Чат

Все наверняка слышали о портировании компилятора Typescript на Go. В результате чего планируется ускорение сборки проекта в 10 раз. Считаю важным тоже об этом написать и собрать источники в одном посте.

Почувствовать столь существенный прирост возможно будет в 7 версии.

Что необходимо мигрировать?

📌 CLI компилятора
📌 Language server (причем новый будет поддерживать LSP для упрощения работы редакторов кода)
📌 Тулинг, необходимый для работы TS.

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

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

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

Очень многообещающий анонс с далеко идущими перспективами.

Репозиторий с обсуждением.
Статья

#typescript

NgStream / Чат

Изменения в 20 версии

📌 Планируется добавить поддержку two-way-binding для динамически-создаваемых компонентов. Пример из МР:

createComponent(MyCheckbox, {
  bindings: [
    twoWayBinding('value', value),
  ],
});

📌 Команда Angular опубликовала МР, где привычные директивы *ngFor, *ngIf помечены deprecated. Ожидаемый переход в сторону более гибкого control flow, анонсированного в 17 версии.
Автоматическая миграция будет произведена при обновлении через ng update.

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

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

#angular

NgStream / Чат

В предстоящем обновлении на 20 версию в Angular CLI будет удален тип из имен файлов и имен классов (суффикс) для компонентов, директив и сервисов.
Теперь, добавленные при помощи CLI компоненты, будут выглядеть так:

ng generate component user

user.css
user.ts
user.ng.html

Это будет сделано, согласно обновленному style guide. Как пишут сами разработчики:

«Со временем мы заметили, что такое соглашение об именах может сделать инфраструктуру громоздкой и шаблонной, особенно для новых разработчиков, не привыкших к такой практике». И об изменении имен классов: "…имя класса должно отражать поведение и обязанности класса, а не то, как он используется. Термин «сервис», в частности, не добавляет какой-либо значимой информации для объяснения того, что делает класс".

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

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

ng generate component user --type=Component
ng generate service user --type=Service
ng generate directive user --type=Directive

"@schematics/angular:component": {
  "type": "Component"
  "ngHtml": false
}

В этом случае, тип сущности останется так, как это выглядит сейчас.

#angular

NgStream / Чат

Angular code style 2025

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

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

Также отмечается, что гайд не затрагивает часть с TS. Для этого есть ссылка на Google code style.

Из основного:

📌 Обновленное именование. Отказ от использования component, directive и тд.
📌 One concept per file. Для каждого элемента отдельный файл. Однако, если они небольшие и связаны одной идеей, то нормально написать это в одном.
📌 Рекомендация property injection over class injection. Более читаемый вариант и лучше типизация.
📌 Группировать Angular-specific сущности (inputs, outputs, queries, и injected deps) перед остальными методами.
📌 Избегать сложной логики в шаблонах, т.к. это не всегда очевидно и, определенно усложняет чтение кода и рефакторинг. Однозначно топ рекомендация! Теперь удобнее будет аргументировать на code review:)
📌 Используйте protected модификатор доступа, если свойство вызывается только в шаблоне.
📌 Рекомендация использовать class and style, а не ngClass and ngStyle.

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

Ссылка на обновленный style guide.

#angular

NgStream / Чат

В репозитории Anguar заинтересовал один МР об оптимизации конструкции let.

📌 Суть в том, что для корректной работы DI требуется узел дерева (TNode), создаваемый вызовом declareLet. Поскольку необходимость наличия узла возникает тогда, когда используются pipes, теперь выражения без пайпов оптимизируются путём удаления соответствующих операций declareLet. Но здесь не столько оптимизации интересны, а дополнение существующего control flow.

📌 Если что, @let не директива. Как и @if синтаксис, это часть движка шаблонизатора, поэтому он не требует импорта и сразу доступен в шаблоне.

📌 Сама конструкция полезна и давно ожидаема сообществом. Коротко: если требуется переменная в шаблоне, приходится импортировать *ngIf, что выглядит излишне и отличается по семантике. Основное отличие с *ngIf в том, что let не проверяет falsy values, а просто объявляет переменную в шаблоне.

Дело в том, что из-за привязки к control flow реализация отличается от того, что есть, например, в TaigaUI, где это отдельная директива. Как результат, есть вероятность получить такой существенный минус, как размывание логики. Поскольку нет ограничений по использованию, которые накладывает директива, многие станут неоправданно активно применять в шаблоне и получим перегруженный JSX. На мой взгляд, это неправильно. Все же шаблоны это про отображение данных, для написания логики есть контроллеры. Ниже я привел пример чрезмерного использования конструкции, о котором говорю.

@let foo = something$ | async

<div></div>
...
<!-- много верстки -->

@let store = notificationsStore$ | async

📌 Из плюсов, конечно, стоит отметить только улучшенную типизацию. Возможно, есть еще плюсы?

#angular

NgStream / Чат

Нововведения и ожидания Angular 20

Уже на 29 мая (четверг) в 19:00 MSK анонсирован Angular Developer Event.

🌵 Следующие фичи изменили статус на stable: linkedSignal, withI18nSupport, PendingTasks, afterEveryRender*, afterNextRender, toSignal, toObservable, withIncrementalHydration.

🛠 Помечены как deprecated: ngIf, ngFor, ngSwitch, HammerJS integration, platformServerTesting, ServerTestingModule.

*afterRender переименован в afterEveryRender. Предназначен для выполнения кода после рендеринга всех компонентов на странице.

Добавлена поддержка оператора in в шаблонах. Его работа аналогична in в TS. Проверка, что свойство есть в объекте (не значение свойства).

{{ 'name' in user }}

@if ('name' in user) {}

[disabled]="'name' in user"

Интересно, что в 19 версии была добавлена поддержка typeof в шаблоне, в 20 оператор in. Получается, что команда решила постепенно сокращать расстояние между TS и Angular.

И в конце ссылка на Angular CanIUse. А чего ждете вы от предстоящего релиза?

#angular

NgStream / Чат

В 20 версии linkedSignal() станет stable. Поэтому сегодня посмотрим его отличия от computed().

📌 computed - сигнал, который рассчитывает своё значение на основе зависимых сигналов. Представьте себе реактивную формулу, которая всегда синхронизирована со своими зависимостями.

Основные особенности:
- Readonly: Вы не можете изменить значение.
- Lazily evaluated: Срабатывает при обращении к нему.
- Memoized: Значение закэшировано, пока зависимость не изменится.
- Dynamic dependencies: Отслеживает только то, что необходимо для выполнения.

📌 linkedSignal - writable сигнал, связывает сигналы, обновляет состояние, в зависимости от значений, но сохраняет возможность ручных изменений.

listOfItems = signal(['item1', 'item2', 'item3']);
countOfItems = linkedSignal(() => this.listOfItems().length);

- Writable. Может быть обновлён вручную .set() или .update().
- Reactive. Автоматически обновляется на основе переданных сигналов
- Access to previous values. Доступ к предыдущему значению, полезно для продвинутых механизмов синхронизации состояния.
- No memoization. Всегда рассчитывается повторно, кеш отсутствует.

// Можем сделать вот так
changeTheCountOfItems() {
    this.countOfItems.set(0);
}
// Есть еще одна форма записи
const countOfItems = linkedSignal({
    source: this.listOfItems,
    computation: (items) => items.length,
});

Здесь linkedSignal принимает ссылку на сигнал, и, когда значение изменится, вызовется computation функция. Пример, где пригодилась бы эта функция, есть здесь, можно ознакомиться подробнее. Покажу более простой.

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

const search = signal('');
const page = linkedSignal({
  source: search,
  computation: () => 1,
});

linkedSignal хорошо использовать для синхронных обновлений состояния.

И коротко добавлю еще:

📌 effect - выполняется асинхронно, планируется и разрешается фреймворком, поэтому конкретное время для выполнения не определено. Предназначен для side-effects, например, для логирования, выполнения API запросов. Не для обновления других сигналов, это может привести с цикличным перерасчетам.

📌 untracked - позволяет сделать сигнал неотслеживаемым внутри определённого контекста выполнения. То есть даже если сигнал меняется, контекст всё равно не будет уведомляться, однако будет иметь доступ к актуальному значению. Может быть использован для изменения состояния сигнала внутри effect(), но делать это не рекомендуется.

#angular

NgStream / Чат

Microsoft анонсировала TypeScript Native Previews. Это история, которую они сообщили в марте о портировании компилятора на Go.

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

Попробовать можно уже сейчас:

npm install -D @typescript/native-preview

// Включить нативный режим в VS Code "typescript.tsserver.useNativeWatcher": true

npx tsgo --project ./src/tsconfig.json

Позже планируют заменить tsgo на tsc и эта реализация станет стандартом, заменяя текущую Node.js-реализацию.

Мне кажется, что VS Code получит самый большой буст, особенно с автокомплитом, потому что идет работа над улучшением language server, переходу с TSServer на LSP. Обещают в этом году показать более полную версию, включая улучшенную работу в редакторах. Первые сборки будут после релиза 7 версии.

#typescript

NgStream / Чат

Как замерить developer experience для разработчиков

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

Опросы и обратная связь для получения объективной картины?🤔 Может быть весьма сомнительно. Вопросы касательно удобства инструментов, документации, скорости развертывания, на мой взгляд, не покажут картину целиком, ну или составить будет весьма сложно.

Команда DevOps Research and Assessment (DORA) из Google Cloud придумали 4 главные метрики разработки. Если коротко, это термометр, который показывает, где всё 🔥, а где ещё можно подкрутить.

📌 Lead Time for Changes (LTFC): Время от внесения изменения в код до релиза.
📌 Deployment Frequency (DF): Как часто релизим.
📌 Mean Time to Restore (MTTR): Среднее время восстановления системы после сбоя.
📌 Change Failure Rate (CFR): Количество багов на релиз.

Эти метрики помогают оценить зрелость и эффективность DevOps практик в команде. Недавно добавили еще одну Reliability, но это лежит в плоскости operational excellence.

Так в чем связь?

1. Улучшение LTFC. При работе в среде с отличным DX, можно быстрее внедрять изменения, благодаря настроенным инструментам и процессам. Это сокращает LTFC, т.к. вы разработатываете приложение, а не тратите время на настройку окружения и борьбу с инфраструктурой.
2. Частота развертываний (DF). Если мы уверены в способности быстро и надежно релизить, частота развертываний увеличивается (кэп). Автотесты, стабильный CI/CD и понятная дока уменьшают страх перед изменениями и позволяют команде/компании чаще выпускать новые фичи. Если еще и работаете по TBD, с фича-флагами, то вообще песня:)
3. Быстрое восстановление (MTTR). Для этого необходимо наличие инструментов мониторинга и диагностики, чтобы быстрее выявлять и устранять инциденты. Описанные процессы по устранению и реагированию тоже дадут плюс. Но это можно отнести к пункту про хорошую документацию.
4. Низкий CFR. Автотесты, тщательная проверка кода и ясность процессов минимизируют риски ошибок.

Метрики подобраны таким образом, чтобы их было сложно накрутить, т.е., по сути, каждая команда вынуждена искать какое-то оптимальное значение для себя. Например, если без изменения процессов просто начать релизить каждый коммит в продакшен, то deployment frequency увеличится. Супер, мы улучшили метрику! Но без хорошо построенных процессов тестирования, скорее всего, сильно просядет change fail rate.

У ребят много интересных материалов:
- Тест, насколько команда перформит круче других.
- Подробнее о метриках
- Как влиять на каждую из метрик.

#нетехзаметки

NgStream / Чат

На прошлой неделе представили Angular 20

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

📌 На презентации много говорили об httpResource. Это, по сути, обертка над httpClient, но с сигналами. Еще в experimental, поэтому пока не рекомендуется к использованию.

📌 SSR. Incremental Hydration в статусе stable. Очень мощный инструмент, позволяющий через Control flow задавать логику для гидрации элемента на странице. Ниже пример с defer, а в разделе на сайте написано подробнее.

@defer (hydrate on <<trigger>>) {
  <deferred-component />
} 

📌 Динамическое создание компонентов. Функция createComponent позволяет делать это с меньшим количеством действий. В параметрах указывается сам компонент, привычные input/output, даже директивы.

createComponent(MyDialog, {
  bindings: [
    // Bind a signal to the `canClose` input.
    inputBinding('canClose', canClose),
    outputBinding<Result>('onClose', result => {}),
    twoWayBinding('title', title),
  ],
  directives: [
    FocusTrap,
    {
      type: HasColor,
      bindings: [inputBinding('color', () => 'red')]
    }
  ]
});

📌 Добавлена возможность использовать:
- оператор in в шаблоне
- untagged template literals. Что особенно удобно для кастомизации и работы с классами.

<div [class]="`layout col-${colWidth}`"></div>

📌 Помечены как deprecated: ngIf, ngFor, ngSwitch, HammerJS integration, platformServerTesting, ServerTestingModule.

📌 Обновили генерацию элементов через CLI после изменений в style guide. Теперь при создании нового проекта не будут добавляться суффиксы для компонентов, директив, pipes и сервисов. Для существующих проектов генерация будет включена в angular.json.

📌 Добавили инструменты и примеры для интеграции AI. Теперь можно легко подключать LLM, такие как Gemini, OpenAI, Anthropic и другие для создания функций вроде чата, генерации текстов, анализа изображений, рекомендаций и т.д.

📌 Также добавили, что стоит двигаться в сторону zoneless приложений. Через пару версий, мне кажется, сделают stable. А пока стоит провести предварительную работу, если еще не сделали. А именно, перевести компоненты на OnPush, уходить от модулей (по крайней мере, новые части кода писать на standalone). Кто не знал, zone.js довольная тяжеловесная библиотека и отказ от нее положительно повлияет на бандл приложения.

📌 Кроме того, проверка производительности будет доступна в chrome dev tools, не нужно скачивать дополнительные расширения! Достаточно обновиться на 20 версию и Chrome 136, вызвать в консоли ng.enableProfiling().

Ну, и на десерт, говорилось о выборе маскотов, показали немного упоротые варианты.😆 В официальном анонсе по ссылке посмотрите, если еще не видели:)

#angular

NgStream / Чат

В недавнем обновлении Angular были представлены async redirects. И я пропустил этот пункт мимо ушей. Поэтому сегодня коротко о том, что этот апдейт нам дает. Возможно, многие, как и я, тоже пропустили строку в changelogs...

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

export const routes: Routes = [
  {
    path: 'user',
    // redirectTo: '/cock',
    redirectTo: () => '/cock',
    pathMatch: 'full'
  }
];

Теперь редирект может происходить позже, как только Promise/Observable вернет значение.

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

#angular

NgStream / Чат

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

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

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

Почему их путают? Потому что и в том, и в другом случае человек требует, критикует, проявляет строгость. Присутствует субъективность восприятия. Требовательный человек может казаться «токсичным», если его слова звучат резко или если у твоего собеседника травматичный опыт.

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

#нетехзаметки

NgStream / Чат

Недавно Selectel Team поделился популярными постами/темами из моего канала, а теперь — я делюсь интересным контентом из канала нашей компании

В канале много полезного контента. Особенно я бы порекомендовал ознакомиться с лекцией Вячеслава Дубынина, нейробиолога, преподавателя МГУ о стрессе и работе с ним. Мне пригодились знания о том, как возникает стресс, какой вообще бывает и как с ним работать! Выступление очень познавательное и все рассказано простым языком!

А также в канале можно встретить анонсы митапов по тимлидству, как внутренние, так и внешние. Из последнего, крайне рекомендую посмотреть о ZBP(Zero Bug Policy), бирюзовых компаниях(это где не нужны менеджеры, а решает самоуправление команд. О реальности же происходящего было выступление). И на десерт, о том, должны ли разработчики погружаться в продуктовый контекст.

Как вы видите, контент весьма разнообразен. В общем подписывайтесь, кто хочет быть в курсе митапов и новостей!)

В дополнение к посту об уже добавленных async redirects. Команда планирует добавить пару довольно полезных фичей в Angular Router 🎉.

Первое это добавление поддержки canDeactivateChild, о котором просили лет 9 назад. MR с ссылкой на issue.

И второе добавление injection context для loadComponent/loadChildren callback, что является решением архитектурных ограничений. На практике означает, что мы сможем инжектить сервисы напрямую в функцию загрузки, динамически подгружать необходимые компоненты, опираясь, например, на состояние в сервисе, на работу с фича флагами/на основе ролевой модели приложения. В общем, возможность реализовать кастомную логику загрузки и не писать велосипеды. Да, подчеркну это и здесь!
На данный момент некоторые разработчики используют workaround по обращению к injection context в loadChildren, который был предложен Игорем Кацубой. И ссылка на feature request, с которым можно ознакомиться более детально.

Существенное улучшение DX на подходе!🎉

#angular

NgStream / Чат

Небольшая новость. Со следующей версии Angular в тестах можно будет использовать input bindings. Пару недель назад влили МР, добавляющий данную функциональность для TestBed.

Теперь при вызове TestBed.createComponent можно указать input, который хотели протестировать. Это избавляет от необходимости фигачить wrappers для каждого компонента. Кроме того, сохраняется консистентность между тестами.

Честно говоря, я думал, что такое уже есть. Дело в том, что уже длительное время пользуюсь spectator, где этот вопрос решается через spectator.setInput().

it('should...', () => {
  spectator.setInput('className', 'link');
  ...
});

Метод изменяет значение @Input() и вызывает хук ngOnChanges().
Очень удобно. Есть и минусы с тем, что получаем разные подходы при написании, одни делают через TestBed, другие с Spectator. Вызовы перемешиваются и выглядит не очень. Еще и не всегда могут корректно взаимодействовать друг с другом. Но это другая история.

А какие инструменты для написания тестов используете вы? Если пишете, конечно;) Как решаете вопрос с тестированием input, output?

#angular

NgStream / Чат

Премия Тьюринга

В этом году Andrew Barto и Richard Sutton получили премию за вклад в развитие обучения с подкреплением(RL). Эти ученые заложили основы технологии, используемой в Google DeepMind, системах для обнаружения мошенничества, разработке алгоритмов для автономных машин. Их исследования позволили создать модели, которые обучаются на основе проб и ошибок.

Премия Тьюринга - это аналог Нобелевской премии в нашей индустрии. Награду вручает АСМ за фундаментальные открытия в Computer Science. Спонсирует Google. Считаю важным рассказать о некоторых открытиях и именах, изменивших индустрию!

1966 Алан Перлис - награжден за подходы к разработке компиляторов. Благодаря ему мы делаем платформонезависимые языки, описывая их формальными грамматиками. "Языки должны быть понятны и людям, и ЭВМ, хороший язык - не только инструмент, но и средство общения."

1968, Ричард Хэмминг - за способ кодирования, который позволяет исправлять ошибки при передаче данных. Сеть, hdd, ram используют коды Хэмминга по сей день.

1972, Эдсгер Дейкстра - за фундаментальный вклад в разработку структурного программирования. Критика использования оператора GOTO, популяризация концепции "слабого связывания". Заложил основы написания чистого и поддерживаемого кода.

1973, Чарльз Бахман - за разработку концепции сетевых баз данных и создание Integrated Data Store (IDS), первой промышленной СУБД в истории. Его мысли приведут нас к sql и orm, но позже.

1974, Дональд Кнут. Его труд "Искусство программирования" знают многие. Изощряй ум алгоритмами, но помни: "Преждевременная оптимизация ‐ корень всех зол".

1976, Майкл Рабин и Дана Скотт. Введение концепции недетерминированных конечных автоматов (NFA) и доказательство его эквивалентности детерминированному. Основа для современных регулярных выражений, алгоритмов поиска и верификации ПО.

1977, Джон Бэкус. Введение BNF-нотации для описания синтаксиса языков. Автор языка Фортран – первый массовый ЯП высокого уровня, используется до сих пор, а очередная версия вышла в 2023.
Данные работы заложили фундамент всей современной computer science — от компиляторов до искусственного интеллекта. Без этих открытий не существовало бы Google, блокчейна, OpenAI или даже обычных мобильных приложений.

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

#людиЦелиДостижения

NgStream / Чат

Обновления инструментов разработчика

🛠 В 20 версии было заявлено об улучшении DevTools и внутреннем партнерстве с Chrome. И, как результат, добавили Angular - Custom track в разделе Performance. С ним проще отслеживать рендеринг компонентов, CD, обработку событий. Раньше приходилось переключаться между DevTools и браузерными инструментами, что усложняло анализ.
Для включения надо обновиться и вызвать в консоли ng.enableProfiling();

В Angular - Custom track (performance) показываются данные, которых нет в Angular DevTools (Это немного разное, не путаться!). Например, создание провайдеров. В доку в раздел best-practices также добавили раздел c пояснениями.

🛠 А в 20.1 дополнят DevTools инструментом Signal graph. Он будет доступен в experimental режиме. Для работы с ним переходим в Angular DevTools, Settings, выбираем компонент в дереве и справа "Show Signal Graph".

Какие улучшения сможем увидеть? В первую очередь, взаимосвязь между сигналами, разновидности используемых в компоненте сигналов (signal(), computed(), linkedSignal(), effect()). По клику на каждый можно перейти в код, просмотреть имя, значение, тип и epoch - сколько раз было изменено значение.

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

#angular

NgStream / Чат