Если честно, статья выглядит плохо прикрытой рекламой. Все ссылки в ней ведут на сайт одной и той же компании, которая как раз занимается, в том числе, рассылками на смс и мессенджеры. У ее директора инициалы подозрительно похожи на никнейм автора статьи - который, к тому же, нигде не гуглится, как будто его изобрели специально и недавно. А кроме этой статьи у него ещё только одна, написанная пару дней назад - чтобы пройти песочницу, возможно?
Мне казалось, на личный сайтах как раз в начале-середине 2000х были популярны свистелки и перделки. Яркие фоны, гифки, все такое. И JS для них тоже применялся. Не говорите, что не помните на сайтах "падающие снежинки", которые безбожно тормозили :)
Я, правда, скорее года с 2005 сайты застал. В 1999, может, и не использовали.
Как тут уже указывали, браузер хранит кэш раздельно для каждого origin (схема://домен:порт).
Не учел, спасибо. Правда, утверждается, что это, в первую очередь, защита от трекинга - по тому, насколько быстро загрузился ресурс, можно понять, был ли он уже в кеше, и использовать это как маркер. Как эта проблема будет решаться в случае с единым репозиторием? По набору пакетов и их версий в кеше, подозреваю, можно неплохой такой fingerprint составить.
Не совсем понял, чем это будет принципиально отличается от использования unpkg/jsdelivr. Если хочется именно в одном отдельном файле это хранить, можно сделать себе vendor.js, в котором импортировать их с cdn и ре-экспортировать.
Эта неоднозначность разрешается первым же примером входных-выходных данных в условии задачи. Решение от этого, кстати, принципиально не меняется. И в целом, условие - это компромисс.
Грубо говоря, да - уничтожаются тоже в обратном порядке при выходе из скоупа, включая выход по исключению. Вот здесь есть подробнее о семантике.
Главное отличие, кажется, в том, что происходит, если dispose выбросил исключение - здесь вызов деструкторов продолжается, а все выброшенные исключения комбинируются в одно и выбрасываются после.
Плюс, там же написана ещё одна важная вещь: TypeScript не будет автоматически полифиллить сами Symbol.dispose, Symbol.asyncDispose, DisposableStack, AsyncDisposableStack. Полифиллы нужно подключать самому. Если стеки не нужны, а нужен только using, можно сделать просто:
Symbol.dispose ??= new Symbol("Symbol.dispose");
Symbol.asyncDispose ??= new Symbol("Symbol.asyncDispose");
И работает это все пока только с таргетом es2022 или ниже, и esnext или esnext.disposable в lib.
Если сходить не в какую-то статью, а в блог самого TypeScript, то можно найти там вторую - и очень важную часть нововведения: DisposableStack и AsyncDisposableStack. С их помощью можно подчищать ресурсы, у которых ещё нет своего метода @@dispose/@@asyncDispose.
function doSomeWork() {
const path = ".some_temp_file";
const file = fs.openSync(path, "w+");
using cleanup = new DisposableStack();
cleanup.defer(() => {
fs.closeSync(file);
fs.unlinkSync(path);
});
// use file...
if (someCondition()) {
// do some more work...
return;
}
// ...
}
Я не спорю, у меня тоже есть настройки под меня в линуксовой раскладке. Однако линуксовая раскладка не может, например, подсветить мне белым цветом функциональные клавиши, когда я переключил их из слоя F1-F12 в слой F13-F24. Да и, к тому же, я иногда ношу клавиатуру между несколькими компами, и очень удобно, когда настройки вроде "перенести ctrl на место caps lock" хранятся в самой клавиатуре.
Да и конкретно для линукса - я, например, не уверен, как в одном и том же месте настраивать ее и для текстовых сессий, и для графических, и в display manager. Ecли подскажете, кстати, буду очень рад.
В мою защиту, уважаемый, из вашего коммента это не очень хорошо понятно. Особенно учитывая, что очень популярно мнение "ваша оверпрайснутая механика никому не нужна".
А если бы вы читали мой комментарий, вы бы заметили, что я говорил, что такие клавиатуры — в том числе те, что в посте — покупают не только из-за удобства. Кастомизируемость и ощущения печати — это прям очень важные критерии; посмотрите, сколько людей на reddit.com/r/MechanicalKeyboards воздыхают на идеальный звук клавиатуры.
А по конкретным клавиатурам из поста:
Keychron Q1 V2: нужно привыкать к расположению Home/End/etc. Очень кастомизируемая, и физически (хотсвап свичей, сменные кейкапы), и программно (VIA/QMK). Эстетически приятная (хотсвап позволяет поставить свичи под себя, алюминий).
ASUS TUF Gaming K3 Red: не мой тип клавиатур, ничего хорошего про "геймерские RGB" клавиатуры сказать не могу.
Drop Signature Series TKL: субъективно более удобная раскладка (я один из тех людей, кто ооочень редко использует numpad). Очень кастомизируемая (хотсвап, QMK). Эстетически приятная (хотсвап, алюминий).
ErgoDox EZ: нужно очень привыкать, но намного более естественная биологически для кистей раскладка (сплит, ортолинейная). Кастомизируемая (хотсвап, QMK). Приятная по ощущениям (не болят запястья, хотсвап).
Nuphy Air75: не фанат такой раскладки и низкого профиля. Хотсвап, но, кажется, не перепрошить. По ощущениям - не уверен, не фанат низкого профиля. Но очень радует комплектный чехол.
Итого: за редким исключением, в подборке как раз те клавиатуры, которыми интересуются энтузиасты механических клавиатур.
Обычно "не-геймерские" механические клавиатуры берут не за надежность или отношение цена-долговечность, а удобство, кастомизируемость и ощущения при печати.
Мне, к примеру, очень нравится, что я могу перепрошить на моей раскладку как я захочу, и таскать ее с собой в самой клавиатуре, вне зависимости от того, к чему я ее подключаю.
У ActionScript 3 было много своего синтаксиса поверх ECMAScript: статическая типизация, классы, геттеры-сеттеры и события как свойства классов. Что-то из этого потом появилось в самом ECMAScript, но далеко не все.
Если честно, статья выглядит плохо прикрытой рекламой. Все ссылки в ней ведут на сайт одной и той же компании, которая как раз занимается, в том числе, рассылками на смс и мессенджеры. У ее директора инициалы подозрительно похожи на никнейм автора статьи - который, к тому же, нигде не гуглится, как будто его изобрели специально и недавно. А кроме этой статьи у него ещё только одна, написанная пару дней назад - чтобы пройти песочницу, возможно?
Я в целом с вами не спорю про вред излишних копирований :) Просто немного удивился, что в первую очередь вспомнили про пямять, а не про время.
Я вот кстати не уверен, что GC просто не вклинится в середину итерации эвент-лупа. Но утверждать не буду.
В любых современных JS-движках поколенческий GC, который соберёт такие короткоживущие массивы почти забесплатно.
Например, Faster sorting algorithms discovered using deep reinforcement learning.
Мне казалось, на личный сайтах как раз в начале-середине 2000х были популярны свистелки и перделки. Яркие фоны, гифки, все такое. И JS для них тоже применялся. Не говорите, что не помните на сайтах "падающие снежинки", которые безбожно тормозили :)
Я, правда, скорее года с 2005 сайты застал. В 1999, может, и не использовали.
Кстати, если вас волнует размер профиля, то разделение кешей можно полностью или частично отключить на уровне браузера. Как минимум в Firefox: https://developer.mozilla.org/en-US/docs/Web/Privacy/State_Partitioning#exempt_specific_origins_from_partitioning. Но, понятное дело, это влечет те самые потенциальные проблемы с трекингом.
Не учел, спасибо. Правда, утверждается, что это, в первую очередь, защита от трекинга - по тому, насколько быстро загрузился ресурс, можно понять, был ли он уже в кеше, и использовать это как маркер. Как эта проблема будет решаться в случае с единым репозиторием? По набору пакетов и их версий в кеше, подозреваю, можно неплохой такой fingerprint составить.
Не совсем понял, чем это будет принципиально отличается от использования unpkg/jsdelivr. Если хочется именно в одном отдельном файле это хранить, можно сделать себе vendor.js, в котором импортировать их с cdn и ре-экспортировать.
Эта неоднозначность разрешается первым же примером входных-выходных данных в условии задачи. Решение от этого, кстати, принципиально не меняется. И в целом, условие - это компромисс.
Возможно, автор следил за разработкой фичи в ишью на гитхабе, и писал ее, ориентируясь на информацию оттуда.
Грубо говоря, да - уничтожаются тоже в обратном порядке при выходе из скоупа, включая выход по исключению. Вот здесь есть подробнее о семантике.
Главное отличие, кажется, в том, что происходит, если
disposeвыбросил исключение - здесь вызов деструкторов продолжается, а все выброшенные исключения комбинируются в одно и выбрасываются после.Плюс, там же написана ещё одна важная вещь: TypeScript не будет автоматически полифиллить сами
Symbol.dispose,Symbol.asyncDispose,DisposableStack,AsyncDisposableStack. Полифиллы нужно подключать самому. Если стеки не нужны, а нужен толькоusing, можно сделать просто:И работает это все пока только с таргетом
es2022или ниже, иesnextилиesnext.disposableв lib.Если сходить не в какую-то статью, а в блог самого TypeScript, то можно найти там вторую - и очень важную часть нововведения:
DisposableStackиAsyncDisposableStack. С их помощью можно подчищать ресурсы, у которых ещё нет своего метода@@dispose/@@asyncDispose.Точнее будет сказать, RAII. Реализация скорее похожа не на деструкторы C++, а на
withв Python иusingв C#.Там и модельку вполне скачать можно; URL есть в
window.site3dWidget_1249.model.path.Я не спорю, у меня тоже есть настройки под меня в линуксовой раскладке. Однако линуксовая раскладка не может, например, подсветить мне белым цветом функциональные клавиши, когда я переключил их из слоя F1-F12 в слой F13-F24. Да и, к тому же, я иногда ношу клавиатуру между несколькими компами, и очень удобно, когда настройки вроде "перенести ctrl на место caps lock" хранятся в самой клавиатуре.
Да и конкретно для линукса - я, например, не уверен, как в одном и том же месте настраивать ее и для текстовых сессий, и для графических, и в display manager. Ecли подскажете, кстати, буду очень рад.
В мою защиту, уважаемый, из вашего коммента это не очень хорошо понятно. Особенно учитывая, что очень популярно мнение "ваша оверпрайснутая механика никому не нужна".
А если бы вы читали мой комментарий, вы бы заметили, что я говорил, что такие клавиатуры — в том числе те, что в посте — покупают не только из-за удобства. Кастомизируемость и ощущения печати — это прям очень важные критерии; посмотрите, сколько людей на reddit.com/r/MechanicalKeyboards воздыхают на идеальный звук клавиатуры.
А по конкретным клавиатурам из поста:
Keychron Q1 V2: нужно привыкать к расположению Home/End/etc. Очень кастомизируемая, и физически (хотсвап свичей, сменные кейкапы), и программно (VIA/QMK). Эстетически приятная (хотсвап позволяет поставить свичи под себя, алюминий).
ASUS TUF Gaming K3 Red: не мой тип клавиатур, ничего хорошего про "геймерские RGB" клавиатуры сказать не могу.
Drop Signature Series TKL: субъективно более удобная раскладка (я один из тех людей, кто ооочень редко использует numpad). Очень кастомизируемая (хотсвап, QMK). Эстетически приятная (хотсвап, алюминий).
ErgoDox EZ: нужно очень привыкать, но намного более естественная биологически для кистей раскладка (сплит, ортолинейная). Кастомизируемая (хотсвап, QMK). Приятная по ощущениям (не болят запястья, хотсвап).
Nuphy Air75: не фанат такой раскладки и низкого профиля. Хотсвап, но, кажется, не перепрошить. По ощущениям - не уверен, не фанат низкого профиля. Но очень радует комплектный чехол.
Итого: за редким исключением, в подборке как раз те клавиатуры, которыми интересуются энтузиасты механических клавиатур.
Обычно "не-геймерские" механические клавиатуры берут не за надежность или отношение цена-долговечность, а удобство, кастомизируемость и ощущения при печати.
Мне, к примеру, очень нравится, что я могу перепрошить на моей раскладку как я захочу, и таскать ее с собой в самой клавиатуре, вне зависимости от того, к чему я ее подключаю.
На вкус и цвет. У тех же Keychron есть и полноразмерные, и tenkeyless-варианты. Печатаю этот коммент на Keychron Q3, как раз TKL.
У ActionScript 3 было много своего синтаксиса поверх ECMAScript: статическая типизация, классы, геттеры-сеттеры и события как свойства классов. Что-то из этого потом появилось в самом ECMAScript, но далеко не все.