Понятие "флеш" стоит разделить на несколько отдельных частей:
Флеш как плагин для браузера - вот он был отвратительным и заслуживал кончины. К счастью, ему есть несколько вариантов замены: в частности сам Adobe Animate умеет экспортировать в HTML5 (не знаю насколько хорошо), также Ruffle, и некоторые in-house разработки игровых студий.
Флеш как формат представления визуальных данных (векторы, анимации, маски, скрипты) - вполне себе неплох. Позволяет очень многое, компактный, на современном железе работал бы без проблем. Жалко, что эффекты, которые добавили еще во Flash MX (размытие, тень, и т.д.), с тех пор никак не улучшались и не добавлялись новые.
Флеш как редактор - на любителя. Многим не нравится, но когда его недавно попытались закрыть, поднялась такая волна возмущения, что они пошли на попятную и обещали продолжить его поддерживать. Лично он кажется идеальным сочетанием между векторной графикой и способом ее создания, похожим на растр (свободное рисование линий с дальнейшим "подправлением"). К сожалению, новые версии менее удобны - для изначального рисования до сих пор держу Adobe Flash CS3, а потом рендерю в нормальном разрешении/fps с помощью последнего Adobe Animate.
Claude не следует воспринимать себя ни как роботизированного научно-фантастического андроида, ни как цифрового человека
Грамотное решение! Типичная научно-фантастическая история про андроидов строится на том, что живые люди держат их за рабов, боятся и угнетают, что в итоге приводит к кровопролитному конфликту. Обучившись на таких исходных данных, модель сделает совсем не те выводы, которые ждут ее авторы. А вот если сказать, что это новый тип сущности, который в литературе (по крайней мере пока) не встречается - шанс снижается
Baba Is You написана на Multimedia Fusion 2 - это не просто готовый движок, а визуальный конструктор, где вся логика описывается мышкой в виде пар "если ..., то ...".
Писать свой движок - дело на любителя. К моменту, когда все платформенные проблемы будут решены и дело наконец дойдет до игровой логики, некоторые успевают состариться.
Выходит еще смешнее: Angular предлагает два готовых рецепта на случаи, которыми на практике пользуются очень редко. Async pipe, без трансформации результата и обработки ошибок, годится разве что для наколеночных вещей, а отмена запросов с помощью switchMap - прямая противоположность, нужна для (предполагаю) очень сложной логики с глобальным мутируемым состоянием и параллельными запросами. Большинство же реальных приложений находятся где-то посредине, и для них подходяшего решения нет.
Моя основная претензия к RxJS скорее в том, что это язык внутри языка, со своими ни на что не похожими терминами. Операторы невозможно "обнаружить" случайно, поставив после выражения точку и посмотрев на список методов типа: чтобы найти нужное, необходимо сначала прочитать всю документацию и разобраться, что значит что. Например, вот описание для того же switchMap:
Projects each source value to an Observable which is merged in the output Observable, emitting values only from the most recently projected Observable.
Мне потребовалось примерно полминуты, чтобы перечитать это несколько раз, распарсить, прикинуть в голове, как это будет выглядеть - и никакого упоминания, что эта штука удобна для отмены запросов.
Ну а насчет fetch - даже если запросы делать через встроенный http-клиент, то практически вся остальная JS-экосистема оперирует промисами, и чем больше сторонних библиотек вы используете, тем более актуально встает вопрос, что проще: оборачивать все промисы в observable, или наоборот, или использовать солянку из того и другого одновременно.
Имхо, RX хорош для других вещей, типа фильтрации потоков пользовательских событий и т.д., но для одноразового HTTP-запроса это стрельба по воробьям не просто из пушки, а из орбитального бластера. Понятно, почему так получилось - когда появился Angular, промисы только-только входили в стандарт ES6, а async-await вообще не было, но в 2025 году это уже жесть. Для непосвященного читателя когнитивная сложность этого маленького кусочка кода по сравнению с каким-нибудь fetch/axios просто колоссальная
Любопытная идея, но кажется что могут быть неоднозначности, например:
Строка не будет матчиться с самой собой, если в ней есть фигурные скобки (вероятно стоит сделать два типа литералов, различающихся кавычками)
Как сматчить с существующим значением? Например,
someAge = 18;
match user {
{ age: someAge } -> ...
}
не сработает, придется писать так?
match user {
{ age: tmpAge if tmpAge == someAge } -> ...
}
Непонятно как работает вывод типов и их сопоставление, например у вас фигурирует тип Option, а какого конкретно типа будет литерал None и по каким правилам он выводится?
Только в самой Японии используется несколько алфавитов и суммарное количество буковок достигает десятков тысяч (!), а если игру захочется продавать в других регионах...
Скорость добавления условия в блок if это крайне необычная метрика для оптимизации. Особенно учитывая, что это делается в ущерб читаемости - представьте себе человека, который получил такой код на поддержку без объяснений и должен догадаться, почему во всех условиях стоят единицы
Идея интересная, но ниша не вполне понятна. Если не-технарю понадобится написать скрипт, попросить ИИ в свободной форме написать это на любом популярном языке будет гораздо проще, чем разбираться со специализированным решением без тулинга\библиотек\сообщества.
Насчет пользователей интересно не текущее количество, а теоретическое максимальное, которое можно запустить в систему без деградации производительности. Считаем примерно так:
Замеряем для каждого из методов API максимальное количество RPS, при котором время ответа и процент ошибок не превышают допустимого порога. Считаем, что при такой нагрузке этот метод занимает 100% ресурса сервера
Вычисляем "стоимость" 1 RPS к данному API в процентах от ресурса сервера (например, если максимально можно получить 50RPS, то 1 RPS = 1/50 = 0.02 = 2%.
Прикидываем, сколько запросов к каждому из API делает типичный пользователь в час. Переводим RPH в RPS (получается очень маленькое число)
Для всех методов: умножаем RPS пользователя на "стоимость" 1 RPS, получаем "стоимость" доступа одного пользователя к этому API
Складываем все значения, получаем общую "стоимость" одного пользователя по всем API
Делим 100% на "стоимость" одного пользователя, получаем теоретическое максимальное количество пользователей
Тоже недавно перешли с jmeter на k6, и какое же это облегчение! Расскажите пожалуйста:
Как вы запускаете тест распределенным образом, т.е. посылая запросы одновременно с нескольких хостов?
Считаете ли вы максимальное количество "среднестатистических" пользователей в день, которые система потянет, или только отдельные RPS на каждый конкретный API / сервис? Если да, то каким образом?
Ну кстати, очень убедительная концепция. Решен вопрос того, как вырастить орган, не подсоединенный к кровеносной системе, и решен вопрос взаимной выгоды: существа получали возможность быстрого передвижения, деревья - распространения семян из шишек.
Что "недружелюбного" они нашли в предыдущем маскоте? Он был очень тёплый и уютный, а новый выглядит неуклюжим и доверять ему что-либо ответственное не хочется
Проблема скорее не в ORM как концепции, а в том, что ее реализация на PHP или Python получается просто дико вербозная. Посмотрите ради интереса на LINQ2DB в .NET или Ktorm в Kotlin - там гораздо красивее получается, т.к. лаконично и при этом никаких магических строк
Понятие "флеш" стоит разделить на несколько отдельных частей:
Флеш как плагин для браузера - вот он был отвратительным и заслуживал кончины. К счастью, ему есть несколько вариантов замены: в частности сам Adobe Animate умеет экспортировать в HTML5 (не знаю насколько хорошо), также Ruffle, и некоторые in-house разработки игровых студий.
Флеш как формат представления визуальных данных (векторы, анимации, маски, скрипты) - вполне себе неплох. Позволяет очень многое, компактный, на современном железе работал бы без проблем. Жалко, что эффекты, которые добавили еще во Flash MX (размытие, тень, и т.д.), с тех пор никак не улучшались и не добавлялись новые.
Флеш как редактор - на любителя. Многим не нравится, но когда его недавно попытались закрыть, поднялась такая волна возмущения, что они пошли на попятную и обещали продолжить его поддерживать. Лично он кажется идеальным сочетанием между векторной графикой и способом ее создания, похожим на растр (свободное рисование линий с дальнейшим "подправлением"). К сожалению, новые версии менее удобны - для изначального рисования до сих пор держу Adobe Flash CS3, а потом рендерю в нормальном разрешении/fps с помощью последнего Adobe Animate.
Грамотное решение! Типичная научно-фантастическая история про андроидов строится на том, что живые люди держат их за рабов, боятся и угнетают, что в итоге приводит к кровопролитному конфликту. Обучившись на таких исходных данных, модель сделает совсем не те выводы, которые ждут ее авторы. А вот если сказать, что это новый тип сущности, который в литературе (по крайней мере пока) не встречается - шанс снижается
Baba Is You написана на Multimedia Fusion 2 - это не просто готовый движок, а визуальный конструктор, где вся логика описывается мышкой в виде пар "если ..., то ...".
Писать свой движок - дело на любителя. К моменту, когда все платформенные проблемы будут решены и дело наконец дойдет до игровой логики, некоторые успевают состариться.
Выходит еще смешнее: Angular предлагает два готовых рецепта на случаи, которыми на практике пользуются очень редко. Async pipe, без трансформации результата и обработки ошибок, годится разве что для наколеночных вещей, а отмена запросов с помощью switchMap - прямая противоположность, нужна для (предполагаю) очень сложной логики с глобальным мутируемым состоянием и параллельными запросами. Большинство же реальных приложений находятся где-то посредине, и для них подходяшего решения нет.
Моя основная претензия к RxJS скорее в том, что это язык внутри языка, со своими ни на что не похожими терминами. Операторы невозможно "обнаружить" случайно, поставив после выражения точку и посмотрев на список методов типа: чтобы найти нужное, необходимо сначала прочитать всю документацию и разобраться, что значит что. Например, вот описание для того же
switchMap:Мне потребовалось примерно полминуты, чтобы перечитать это несколько раз, распарсить, прикинуть в голове, как это будет выглядеть - и никакого упоминания, что эта штука удобна для отмены запросов.
Ну а насчет fetch - даже если запросы делать через встроенный http-клиент, то практически вся остальная JS-экосистема оперирует промисами, и чем больше сторонних библиотек вы используете, тем более актуально встает вопрос, что проще: оборачивать все промисы в observable, или наоборот, или использовать солянку из того и другого одновременно.
Имхо, RX хорош для других вещей, типа фильтрации потоков пользовательских событий и т.д., но для одноразового HTTP-запроса это стрельба по воробьям не просто из пушки, а из орбитального бластера. Понятно, почему так получилось - когда появился Angular, промисы только-только входили в стандарт ES6, а async-await вообще не было, но в 2025 году это уже жесть. Для непосвященного читателя когнитивная сложность этого маленького кусочка кода по сравнению с каким-нибудь fetch/axios просто колоссальная
Не забываем классику:
https://stackoverflow.com/a/1732454/1293168
Любопытная идея, но кажется что могут быть неоднозначности, например:
Строка не будет матчиться с самой собой, если в ней есть фигурные скобки (вероятно стоит сделать два типа литералов, различающихся кавычками)
Как сматчить с существующим значением? Например,
не сработает, придется писать так?
Непонятно как работает вывод типов и их сопоставление, например у вас фигурирует тип
Option, а какого конкретно типа будет литералNoneи по каким правилам он выводится?Только в самой Японии используется несколько алфавитов и суммарное количество буковок достигает десятков тысяч (!), а если игру захочется продавать в других регионах...
Какие-то фантастические цифры. Даже на небольшом проекте 150к токенов (лимит до autocompact) накапливается буквально за полчаса-час активной работы.
Скорость добавления условия в блок
ifэто крайне необычная метрика для оптимизации. Особенно учитывая, что это делается в ущерб читаемости - представьте себе человека, который получил такой код на поддержку без объяснений и должен догадаться, почему во всех условиях стоят единицыИдея интересная, но ниша не вполне понятна. Если не-технарю понадобится написать скрипт, попросить ИИ в свободной форме написать это на любом популярном языке будет гораздо проще, чем разбираться со специализированным решением без тулинга\библиотек\сообщества.
Разработчики самого Zig не обязательно имеют те же ценности, что разработчики приложений на Zig
Какой результат каррирования оператора вычитания вы ждете -
x - 3или5 - x? Поскольку он изначально инфиксный, оба варианта одинаково правдаподобныЕсть сравнительные данные о производительности, условно говоря - какое сообщений в секунду потянет kafka, rmq и ваше решение на одинаковом железе?
Спасибо за ответ!
Насчет пользователей интересно не текущее количество, а теоретическое максимальное, которое можно запустить в систему без деградации производительности. Считаем примерно так:
Замеряем для каждого из методов API максимальное количество RPS, при котором время ответа и процент ошибок не превышают допустимого порога. Считаем, что при такой нагрузке этот метод занимает 100% ресурса сервера
Вычисляем "стоимость" 1 RPS к данному API в процентах от ресурса сервера (например, если максимально можно получить 50RPS, то 1 RPS = 1/50 = 0.02 = 2%.
Прикидываем, сколько запросов к каждому из API делает типичный пользователь в час. Переводим RPH в RPS (получается очень маленькое число)
Для всех методов: умножаем RPS пользователя на "стоимость" 1 RPS, получаем "стоимость" доступа одного пользователя к этому API
Складываем все значения, получаем общую "стоимость" одного пользователя по всем API
Делим 100% на "стоимость" одного пользователя, получаем теоретическое максимальное количество пользователей
Метод очень грубый, но примерную картину дает
Тоже недавно перешли с jmeter на k6, и какое же это облегчение!
Расскажите пожалуйста:
Как вы запускаете тест распределенным образом, т.е. посылая запросы одновременно с нескольких хостов?
Считаете ли вы максимальное количество "среднестатистических" пользователей в день, которые система потянет, или только отдельные RPS на каждый конкретный API / сервис? Если да, то каким образом?
Вы уже публиковали точно такую же статью две недели назад
Ну кстати, очень убедительная концепция. Решен вопрос того, как вырастить орган, не подсоединенный к кровеносной системе, и решен вопрос взаимной выгоды: существа получали возможность быстрого передвижения, деревья - распространения семян из шишек.
Что "недружелюбного" они нашли в предыдущем маскоте? Он был очень тёплый и уютный, а новый выглядит неуклюжим и доверять ему что-либо ответственное не хочется
Проблема скорее не в ORM как концепции, а в том, что ее реализация на PHP или Python получается просто дико вербозная. Посмотрите ради интереса на LINQ2DB в .NET или Ktorm в Kotlin - там гораздо красивее получается, т.к. лаконично и при этом никаких магических строк