команда Lufthansa извлекла и осмотрела повреждённый iPad.
Ключевое слово - "повреждённый". Походу, чел или стюарды пытались его достать, что могло привести к повреждениям устройства. После чего и могло быть принято решение "лететь на ближайшую базу". Уверен, что без попыток извлечь застрявший ipad не обошлось.
К сожалению, я не понимаю, что значат эти цифры, но признаю, что выглядит красиво. Поэтому я взял код из вашего теста, немного сократил его и попросил GPT-чат добавить в него измерения времени:
'use strict';
class Bar {
a = 1;
b = 2;
}
class Foo {
a = 1;
b = 2;
constructor() {
return Object.freeze(this);
}
}
const ITERATIONS = 1000000;
console.time('Bar');
for (let i = 0; i < ITERATIONS; i++) new Bar();
console.timeEnd('Bar');
console.time('Foo');
for (let i = 0; i < ITERATIONS; i++) new Foo();
console.timeEnd('Foo');
console.time('Freeze(Bar)');
for (let i = 0; i < ITERATIONS; i++) Object.freeze(new Bar());
console.timeEnd('Freeze(Bar)');
В таком виде код можно гонять в любом окружении (node или браузер). Он даёт некоторое понимание о "стоимости" использования freeze при создании объектов. Я, правда, увеличил кол-во итераций с 10К до 1М, чтобы чуть лучше заметно было различие в числах (на 10К особых различий и не было).
Вот результат, время в миллисекундах на 1 миллион итераций:
По моему очевидно, что создание объекта + его «заморозка», не может быть быстрее, или одинаково по скорости чем просто создание объекта.
Вы абсолютно правы и я не собираюсь спорить с очевидным - создание и "заморозка" объекта однозначно "дороже" по времени, чем просто создание. Примерно на порядок.
Но в абсолютных величинах это составляет меньше 200 миллисекунд на 1 миллион созданных объектов в Firefox'е (самом "тормозном" из трёх).
Может ли проект позволить себе "потерять" 200 миллисекунд на заморозку созданных в нём 1М объектов или нет - зависит от проекта. В моих проектах кол-во функциональных объектов значительно ниже 10К, не говоря уже об 1М. Я могу себе позволить потерять десяток миллисекунд при запуске приложения (хотя на практике деле это число будет ещё меньше - я просто беру с "запасом").
Кстати, а почему ваши тесты на сайте perf.js.hyoo.ru занимают настолько много времени (в секундах!) при кол-ве итераций всего 10К? Что измеряет этот стенд? Я - человек со стороны, мне, например, не понятно, что всё это значит и как настраивается:
Я ж говорю, зависит от проекта. В моём случае с заморозкой даже быстрее сервер стартовал, чем без. Первый запуск из статистики выкидывал, как разогревающий. Брал со второго по четвёртый. Может быть нагрузка на ноуте менялась. Но для моего случая заморозка Контейнером функциональных объектов при старте приложения вообще не существенна:
В общем, пока final внедрят, буду пользоваться freeze'ом, а потом посмотрим...
На всякий случай уточняю, что "морозятся" не все объекты в приложении, а только те, которые создаются Контейнером (функциональные). Например, фабрики DTO. А заморозка самих DTO - на усмотрение фабрик. В принципе, если вы создали DTO при помощи доверенной фабрики, провели его обработку через доверенные функции, а потом сериализовали, чтобы выплюнуть наружу, то нет смысла замораживать "расходники" (данные).
А про временные затраты лучше говорить с цифрами в руках. "Достаточное" и "существенное" - это из области балета.
Вы смотрели деградацию производительности после внедрения этого решения?
Да, разумеется. У меня сервер приложения без "заморозки" в Контейнере поднимался полторы-две секунды. С "заморозкой" - тоже полторы-две секунды. Значимой деградации не замечено.
Если серьёзно, то замораживаются объекты при их создании Контейнером. Я разделяю данные и обработчики. Контейнер создаёт обработчики (в том числе и фабрики DTO). Замораживаются как раз таки объекты-обработчики. Они написаны в функциональном стиле и на всё приложение нужны в одном-единственном экземпляре. Цена вопроса - 100-200-1000-... "заморозок" при старте приложения (зависит от кол-ва функциональных объектов в приложении).
Стоит ли платить эту цену, чтобы кто-то не сделал такой финт?
Если ваше приложение высоконагруженное и каждая микросекунда на учёте - то нет. А если вы работаете в недружественной среде (браузерное приложение - уже недружественная среда, кто его знает, чего в DOM натолкали и чего в globals переопределили), то "морозить" объекты - уже не такая плохая идея.
Я "вырос" из Magento, а там в одном приложении собирались плагины от полутора десятков разрабов. У меня профдеформация :)
А если бы вы в коде сделали так:
const foo = new Foo();
Object.freeze(foo);
то после:
Object.defineProperty(foo, 'bar', {...});
получили это:
Object.defineProperty(foo, 'bar', {
^
TypeError: Cannot define property bar, object is not extensible
at Function.defineProperty (<anonymous>)
...
Заморозка объекта на этапе его создания даёт некоторую гарантию, что вы имеете дело с вашим собственным кодом, а не с кодом других хороших людей.
Насколько это существенно для вашего проекта - зависит от вашего проекта.
"Могут ли машины быть сознательными?" - вопрос из области "Сколько ангелов может танцевать на булавочной головке?" Мы не можем дать определение ни "сознанию", ни "ангелу".
Если LLM обучали на книгах де Сада и Захера-Мазоха, то какое у неё будет "осознание благополучия" - отсутствие наказания или его наличие? Или каждый увидит в модели своё отражение? Будет ли модель вообще рефлексировать без стороннего наблюдателя?
С одной стороны, я согласен с Майком Куком и Стивеном Каспером, но с другой - аплодирую стоя Кайлу Фишу. Чел решительно и амбициозно стремится к финансовому благополучию в этом мире.
Я правильно понимаю, что не все SPA отлично индексируются? Что для успешной индексации в поисковиках им нужно соответствовать некоторым требованиям?
Так-то демка прекрасно работает в режиме SPA. Только не индексируется в Гугле дальше первой страницы.
Да, вы правы когда говорите, что у меня есть возможность сделать sitemap и использовать прочие трюки (типа явного добавления в DOM ссылок навигатора). Но развивая эту мысль дальше, мы можем вдруг обнаружить что при создании SPA мы руководствуемся ценностями SSR.
Электронный магазин есть смысл сразу делать SSR-ориентированным, пусть даже там каждая страница будет SPA и будет генерироваться на серверной стороне "на лету" из данных в базе. А вот банковское приложение можно делать как SPA без оглядки на поисковики.
Я когда-то, примерно в 23-м году, делал PWA (SPA на стероидах) - https://aid.demo.wiredgeese.com/ Там было несколько режимов работы ("страниц"), переход к которым осуществлялся через навигатор в правом верхнем углу:
Вот так выглядит это веб-приложение сейчас в Гугле:
Вы абсолютно правы, что SPA отлично индексируются. Но и моё предположение, что дальше первой страницы поисковики не копают, тоже неплохо подтверждается на практике.
Время - это ваш персональный, ограниченный ресурс. Всегда полезно знать, на что уходят ресурсы и как эффективно они расходуются. Вам лично полезно. И если вы сами трекаете своё время, то другим дать отчёт, на что уходит ваше время - проще простого.
Рендеринг без сохранения состояния: каждый рендеринг страницы происходит в новом сеансе браузера, без сохранения файлов cookie или состояния от предыдущих рендеров. Google обычно не нажимает на элементы на странице, такие как содержимое вкладок или баннеры cookie.
Смысл SPA как раз в состояниях - "переключение страниц" в одностраничном приложении это и есть смена состояния приложения. По сути, бот индексирует домашнюю страницу SPA и не видит другие страницы.
Не стоит использовать SPA, если от проекта требуется "прорасти в поисковиках". Используйте SSR. Используйте SPA там, где от проекта не требуется быть в поисковиках.
Про отношение Бога ко всем этим горьким катаклизмам, которые вы здесь наблюдаете (и я, кстати, тоже), Станислав Лем в своём произведении "Солярис" сформулировал одну очень многообъясняющую гипотезу: "У Него сознание 5 летнего ребёнка". Лем, правда, это про Разумный Океан написал, но к Богу это вообще идеально лепится. Ребёнок не видит ни добра, ни зла - это мы, взрослые, объясняем ему, что не нужно лезть в розетку. Ребёнок запросто обидит другого, потому что он эгоцентричен. Это мы, взрослые, взращиваем в детях эмпатию - им ещё жить среди себе подобных. А Бог бесподобен - Ему не с кем себя сравнить, Ему скучно, Он играет. Играет всем, что у него есть. Играет нами. Игрушки иногда ломаются. Но я помню из своего собственного детства, что самые задорные игры те, во время которых что-нибудь, да сломаешь.
Мне очень нравится гипотеза "Бог - пятилетний ребёнок". Очень хорошо натягивается на глобус. Если вы, конечно, не против, что Бог вообще существует. Если против - можете использовать любое другое объяснение для окружающего мира, хоть "результат стечения случайных событий на фоне теории больших чисел". Но гипотеза "Бог" практичнее - говоришь "так Богу угодно" и человек в теме сразу понимает, что произошедшее - это результат стечения случайных событий на фоне ну и т.д.
Бог - это не "человечек на облачке". Бог - это источник всего сущего. Только ради этого одного определения я и зашёл в статью. Было интересно, как в ней объясняется весь этот бардак вокруг. Но потом появилась рекурсия и я начал что-то вспоминать, а когда дошёл до "В этой статье мы ставим конкретные задачи для математиков, физиков и программистов", я очень быстро вспомнил, о чём там дальше будет. Не-не-не... я сюда за ответами пришёл, а не за вопросами.
Если они изобрели прорывную технологию, то к концу года у всех контекст будет по паре миллионов токенов. Если не будет, то значит те же яйца, только в профиль. Кстати, протестировать их утверждения достаточно просто - дать модели текста на 100К токенов и попросить заменить какой-нибудь термин на его синоним. Если текст разрушится - то и вот, а если таки заменит, то - моё почтение!
Вы хотите сделать мир лучше, я хочу, чтобы он не стал хуже. Мы две стороны одной медали. Я показал вам другую точку зрения и вы её увидели. Теперь, делая мир лучше, вы вольно или невольно будете думать, не сделаете ли его хуже.
... и наша с вами задача сделать так, чтобы нашим детям планета досталась в лучшем (ну, или хотя бы не в худшем) виде, чем она досталась нам. Вы и вправду считаете, что наши взгляды различаются кардинально?
Ключевое слово - "повреждённый". Походу, чел или стюарды пытались его достать, что могло привести к повреждениям устройства. После чего и могло быть принято решение "лететь на ближайшую базу". Уверен, что без попыток извлечь застрявший ipad не обошлось.
К сожалению, я не понимаю, что значат эти цифры, но признаю, что выглядит красиво. Поэтому я взял код из вашего теста, немного сократил его и попросил GPT-чат добавить в него измерения времени:
В таком виде код можно гонять в любом окружении (node или браузер). Он даёт некоторое понимание о "стоимости" использования
freezeпри создании объектов. Я, правда, увеличил кол-во итераций с 10К до 1М, чтобы чуть лучше заметно было различие в числах (на 10К особых различий и не было).Вот результат, время в миллисекундах на 1 миллион итераций:
Вы абсолютно правы и я не собираюсь спорить с очевидным - создание и "заморозка" объекта однозначно "дороже" по времени, чем просто создание. Примерно на порядок.
Но в абсолютных величинах это составляет меньше 200 миллисекунд на 1 миллион созданных объектов в Firefox'е (самом "тормозном" из трёх).
Может ли проект позволить себе "потерять" 200 миллисекунд на заморозку созданных в нём 1М объектов или нет - зависит от проекта. В моих проектах кол-во функциональных объектов значительно ниже 10К, не говоря уже об 1М. Я могу себе позволить потерять десяток миллисекунд при запуске приложения (хотя на практике деле это число будет ещё меньше - я просто беру с "запасом").
Кстати, а почему ваши тесты на сайте perf.js.hyoo.ru занимают настолько много времени (в секундах!) при кол-ве итераций всего 10К? Что измеряет этот стенд? Я - человек со стороны, мне, например, не понятно, что всё это значит и как настраивается:
Я ж говорю, зависит от проекта. В моём случае с заморозкой даже быстрее сервер стартовал, чем без. Первый запуск из статистики выкидывал, как разогревающий. Брал со второго по четвёртый. Может быть нагрузка на ноуте менялась. Но для моего случая заморозка Контейнером функциональных объектов при старте приложения вообще не существенна:
В общем, пока
finalвнедрят, буду пользоватьсяfreeze'ом, а потом посмотрим...На всякий случай уточняю, что "морозятся" не все объекты в приложении, а только те, которые создаются Контейнером (функциональные). Например, фабрики DTO. А заморозка самих DTO - на усмотрение фабрик. В принципе, если вы создали DTO при помощи доверенной фабрики, провели его обработку через доверенные функции, а потом сериализовали, чтобы выплюнуть наружу, то нет смысла замораживать "расходники" (данные).
А про временные затраты лучше говорить с цифрами в руках. "Достаточное" и "существенное" - это из области балета.
Насколько медленная?
Да, разумеется. У меня сервер приложения без "заморозки" в Контейнере поднимался полторы-две секунды. С "заморозкой" - тоже полторы-две секунды. Значимой деградации не замечено.
Если серьёзно, то замораживаются объекты при их создании Контейнером. Я разделяю данные и обработчики. Контейнер создаёт обработчики (в том числе и фабрики DTO). Замораживаются как раз таки объекты-обработчики. Они написаны в функциональном стиле и на всё приложение нужны в одном-единственном экземпляре. Цена вопроса - 100-200-1000-... "заморозок" при старте приложения (зависит от кол-ва функциональных объектов в приложении).
Стоит ли платить эту цену, чтобы кто-то не сделал такой финт?
Если ваше приложение высоконагруженное и каждая микросекунда на учёте - то нет. А если вы работаете в недружественной среде (браузерное приложение - уже недружественная среда, кто его знает, чего в DOM натолкали и чего в globals переопределили), то "морозить" объекты - уже не такая плохая идея.
Я "вырос" из Magento, а там в одном приложении собирались плагины от полутора десятков разрабов. У меня профдеформация :)
А если бы вы в коде сделали так:
то после:
получили это:
Заморозка объекта на этапе его создания даёт некоторую гарантию, что вы имеете дело с вашим собственным кодом, а не с кодом других хороших людей.
Насколько это существенно для вашего проекта - зависит от вашего проекта.
del
"Могут ли машины быть сознательными?" - вопрос из области "Сколько ангелов может танцевать на булавочной головке?" Мы не можем дать определение ни "сознанию", ни "ангелу".
Если LLM обучали на книгах де Сада и Захера-Мазоха, то какое у неё будет "осознание благополучия" - отсутствие наказания или его наличие? Или каждый увидит в модели своё отражение? Будет ли модель вообще рефлексировать без стороннего наблюдателя?
С одной стороны, я согласен с Майком Куком и Стивеном Каспером, но с другой - аплодирую стоя Кайлу Фишу. Чел решительно и амбициозно стремится к финансовому благополучию в этом мире.
Развитие движется по спирали. Не надо откатываться назад, лезьте вперёд и вверх. SPA & SSR вполне могут сосуществовать вместе. И даже в CDN.
Я правильно понимаю, что не все SPA отлично индексируются? Что для успешной индексации в поисковиках им нужно соответствовать некоторым требованиям?
Так-то демка прекрасно работает в режиме SPA. Только не индексируется в Гугле дальше первой страницы.
Да, вы правы когда говорите, что у меня есть возможность сделать sitemap и использовать прочие трюки (типа явного добавления в DOM ссылок навигатора). Но развивая эту мысль дальше, мы можем вдруг обнаружить что при создании SPA мы руководствуемся ценностями SSR.
Электронный магазин есть смысл сразу делать SSR-ориентированным, пусть даже там каждая страница будет SPA и будет генерироваться на серверной стороне "на лету" из данных в базе. А вот банковское приложение можно делать как SPA без оглядки на поисковики.
Именно эту мысль я и пытался донести изначально.
Я когда-то, примерно в 23-м году, делал PWA (SPA на стероидах) - https://aid.demo.wiredgeese.com/ Там было несколько режимов работы ("страниц"), переход к которым осуществлялся через навигатор в правом верхнем углу:
Вот так выглядит это веб-приложение сейчас в Гугле:
Вы абсолютно правы, что SPA отлично индексируются. Но и моё предположение, что дальше первой страницы поисковики не копают, тоже неплохо подтверждается на практике.
Математика умеет в такое:
Время - это ваш персональный, ограниченный ресурс. Всегда полезно знать, на что уходят ресурсы и как эффективно они расходуются. Вам лично полезно. И если вы сами трекаете своё время, то другим дать отчёт, на что уходит ваше время - проще простого.
Я привёл выдержку из этой же статьи.
Если вы утверждаете, что статья говорит об обратном, то это свидетельствует, что в статье содержатся противоречивые вещи.
Смысл SPA как раз в состояниях - "переключение страниц" в одностраничном приложении это и есть смена состояния приложения. По сути, бот индексирует домашнюю страницу SPA и не видит другие страницы.
Не стоит использовать SPA, если от проекта требуется "прорасти в поисковиках". Используйте SSR. Используйте SPA там, где от проекта не требуется быть в поисковиках.
Отсутствием транспиляции.
teqfw- это чистый JS, работает одинаково и в браузере, и в node.nestjs- это TypeScript и server-side only.del
Про отношение Бога ко всем этим горьким катаклизмам, которые вы здесь наблюдаете (и я, кстати, тоже), Станислав Лем в своём произведении "Солярис" сформулировал одну очень многообъясняющую гипотезу: "У Него сознание 5 летнего ребёнка". Лем, правда, это про Разумный Океан написал, но к Богу это вообще идеально лепится. Ребёнок не видит ни добра, ни зла - это мы, взрослые, объясняем ему, что не нужно лезть в розетку. Ребёнок запросто обидит другого, потому что он эгоцентричен. Это мы, взрослые, взращиваем в детях эмпатию - им ещё жить среди себе подобных. А Бог бесподобен - Ему не с кем себя сравнить, Ему скучно, Он играет. Играет всем, что у него есть. Играет нами. Игрушки иногда ломаются. Но я помню из своего собственного детства, что самые задорные игры те, во время которых что-нибудь, да сломаешь.
Мне очень нравится гипотеза "Бог - пятилетний ребёнок". Очень хорошо натягивается на глобус. Если вы, конечно, не против, что Бог вообще существует. Если против - можете использовать любое другое объяснение для окружающего мира, хоть "результат стечения случайных событий на фоне теории больших чисел". Но гипотеза "Бог" практичнее - говоришь "так Богу угодно" и человек в теме сразу понимает, что произошедшее - это результат стечения случайных событий на фоне ну и т.д.
Бог - это не "человечек на облачке". Бог - это источник всего сущего. Только ради этого одного определения я и зашёл в статью. Было интересно, как в ней объясняется весь этот бардак вокруг. Но потом появилась рекурсия и я начал что-то вспоминать, а когда дошёл до "В этой статье мы ставим конкретные задачи для математиков, физиков и программистов", я очень быстро вспомнил, о чём там дальше будет. Не-не-не... я сюда за ответами пришёл, а не за вопросами.
Если они изобрели прорывную технологию, то к концу года у всех контекст будет по паре миллионов токенов. Если не будет, то значит те же яйца, только в профиль. Кстати, протестировать их утверждения достаточно просто - дать модели текста на 100К токенов и попросить заменить какой-нибудь термин на его синоним. Если текст разрушится - то и вот, а если таки заменит, то - моё почтение!
Вы хотите сделать мир лучше, я хочу, чтобы он не стал хуже. Мы две стороны одной медали. Я показал вам другую точку зрения и вы её увидели. Теперь, делая мир лучше, вы вольно или невольно будете думать, не сделаете ли его хуже.
"Мы не наследуем Землю от наших предков, мы берем ее в долг у наших детей" (с)
... и наша с вами задача сделать так, чтобы нашим детям планета досталась в лучшем (ну, или хотя бы не в худшем) виде, чем она досталась нам. Вы и вправду считаете, что наши взгляды различаются кардинально?
Не нашёл источник. Кого вы сейчас процитировали?
Согласен. Но я не думаю, что это хорошо или плохо. Это просто как инструмент, типа молотка. Или лифта на голосовом управлении.