Спасибо за статью! На мой взгляд, было бы лучше, если бы сразу использовалась автоматическая десериализация из JSON вместо затратного преобразования из строки в каждой функции‑обработчике.
С сериализацией результирующего стрима чуть сложнее — можно использовать sealed class из Java 17. Не знаю точно, как в Java, но в Kotlin у меня это получилось без проблем, потому что это поддерживается kotlinx.serialization за счёт того, что в итоговый JSON дописывается поле type. Для этого мне пришлось дописать mapValues в обоих стримах после разделения, чтобы конвертировать объекты к базовому классу.
Ещё было бы полезно упомянуть про streams.setUncaughtExceptionHandler, потому что пока я о нём не узнал, моя программа завершалась молча в случаях, когда я указывал не тот класс для (де‑)сериализации или когда я опечатался в теле JSON.
А как доказать, что нуль-система существует? Потому что в статье это постулируется, но я не могу себя убедить, что декомпозиция обязательно будет конечна или хотя бы иметь предел
Большой вычислительной сложностью обладает операция факторизации n. Так как это число было получено в результате произведение двух простых чисел p и q, то существует единственная нетривиальная (то есть p != 1 и q != 1) пара целых чисел, произведение которых равно n. В этом и заключена сложность взлома RSA грубой силой.
То есть факторизуется составное число n. А задачи факторизации «больших простых чисел» не существует по определению — у простых чисел всегда только два делителя: 1 и само число.
Объединить несколько каналов в один можно без дополнительных горутин, но с помощью рефлексии: https://pkg.go.dev/reflect#Select. Полезно посмотреть на оба подхода и посравнивать.
Согласен с комментатором выше, в статье действительно много ошибок или упущенных тонкостей.
O(m log m) значит, что с ростом размера входных данных количество затраченных операций будет расти пропорционально m log m. Комментатор выше говорит о том, что размер алфавита фиксирован — с увеличением длины входных строк, сортировка массива длиной с размер алфавита всегда будет занимать одинаковое количество операций (26 * log(26) * const), поэтому это не влияет на общую оценку временной сложности алгоритма.
Спасибо Вам за статью! Хочу поделиться двумя предложениями, которые могли бы улучшить читаемость пары строк кода.
Вместо `signal.Notify(stop, syscall.SIGTERM, syscall.SIGINT)` мне на практике оказалось гораздо удобнее использовать `signal.NotifyContext(ctx, syscall.SIGTERM, syscall.SIGINT)`. Он не заставляет создавать лишние каналы снаружи) Он не сразу в пакете signal появился, поэтому про него часто не знают.
Для проверки диапазона времени можно использовать `require.WithinDuration(loginTime.Add(s.Config.TokenTTL), claims.ExpiresAt.Time, 1*time.Second)`. Должно выглядеть "прозрачнее" для читателя.
Теперь отчетливо видны границы переходов от "нормальных" транзисторов …
Подскажите, пожалуйста, как вы это определили? Я смотрю на фотографию, и не могу понять, чем отмеченные на следующем фото транзисторы отличаются от неотмеченных.
Подскажите, пожалуйста, один момент на Вашем опыте. Я для себя открыл helm, когда столкнулся с необходимостью параметризовать манифесты в CI/CD. Конкретнее, в случае, когда я хотел деплоить приложения на dev и prod окружения. Я использовал values.yaml, чтобы указать там имя секрета, доменное имя для ingress и прочие вещи, которые могут различаться в разных окружениях.
Я согласен с вашим мнением про добавленную сложность, но как тогда решить проблему, когда тебе действительно нужна параметризация?
С моей точки зрения, доказательство того, почему работает алгоритм — это одна из самых интересных вещей, достойных упоминания в статье (зависит от темы статьи, конечно). Например, почему алгоритм Дейкстры получает корректный результат и чем ему «мешают» рёбра с отрицательным весом.
По содержанию статьи: по-моему, Вы перепутали, какой из алгоритмов найдёт кратчайший путь в лабиринте. Это должен быть BFS. DFS найдёт путь, но не обязательно кратчайший.
Спасибо за статью! На мой взгляд, было бы лучше, если бы сразу использовалась автоматическая десериализация из JSON вместо затратного преобразования из строки в каждой функции‑обработчике.
С сериализацией результирующего стрима чуть сложнее — можно использовать sealed class из Java 17. Не знаю точно, как в Java, но в Kotlin у меня это получилось без проблем, потому что это поддерживается
kotlinx.serializationза счёт того, что в итоговый JSON дописывается полеtype. Для этого мне пришлось дописатьmapValuesв обоих стримах после разделения, чтобы конвертировать объекты к базовому классу.Ещё было бы полезно упомянуть про
streams.setUncaughtExceptionHandler, потому что пока я о нём не узнал, моя программа завершалась молча в случаях, когда я указывал не тот класс для (де‑)сериализации или когда я опечатался в теле JSON.А как доказать, что нуль-система существует? Потому что в статье это постулируется, но я не могу себя убедить, что декомпозиция обязательно будет конечна или хотя бы иметь предел
Большой вычислительной сложностью обладает операция факторизации
n. Так как это число было получено в результате произведение двух простых чиселpиq, то существует единственная нетривиальная (то естьp != 1иq != 1) пара целых чисел, произведение которых равноn. В этом и заключена сложность взлома RSA грубой силой.То есть факторизуется составное число
n. А задачи факторизации «больших простых чисел» не существует по определению — у простых чисел всегда только два делителя: 1 и само число.Если я не ошибаюсь, то фронтенд GitHub написан на чистом JavaScript, чем они гордятся. Вот ссылка, где они говорят о том, что больше не используют фронтенд-фреймворки (до этого у них был jQuery): https://github.blog/2018-09-06-removing-jquery-from-github-frontend/
Про то, используют ли они JS или TS пруф найти не смог, тут могу быть не прав
Объединить несколько каналов в один можно без дополнительных горутин, но с помощью рефлексии: https://pkg.go.dev/reflect#Select. Полезно посмотреть на оба подхода и посравнивать.
Согласен с комментатором выше, в статье действительно много ошибок или упущенных тонкостей.
O(m log m) значит, что с ростом размера входных данных количество затраченных операций будет расти пропорционально m log m. Комментатор выше говорит о том, что размер алфавита фиксирован — с увеличением длины входных строк, сортировка массива длиной с размер алфавита всегда будет занимать одинаковое количество операций (26 * log(26) * const), поэтому это не влияет на общую оценку временной сложности алгоритма.
Спасибо Вам за статью! Хочу поделиться двумя предложениями, которые могли бы улучшить читаемость пары строк кода.
Вместо `signal.Notify(stop, syscall.SIGTERM, syscall.SIGINT)` мне на практике оказалось гораздо удобнее использовать `signal.NotifyContext(ctx, syscall.SIGTERM, syscall.SIGINT)`. Он не заставляет создавать лишние каналы снаружи) Он не сразу в пакете
signalпоявился, поэтому про него часто не знают.Для проверки диапазона времени можно использовать `require.WithinDuration(loginTime.Add(s.Config.TokenTTL), claims.ExpiresAt.Time, 1*time.Second)`. Должно выглядеть "прозрачнее" для читателя.
В https://www.ietf.org/rfc/rfc2109.txt §6.3 говорит, что должно храниться хотя бы 4096 байт. Есть сайт со статистикой (на 2013 год, можно запустить проверку для своего браузера), где показано, что все браузеры примерно так и ограничивают максимальный размер Cookie. http://browsercookielimits.iain.guru/#limits
Вообще, мне казалось, что чтобы JWT разросся до 4Кб, туда нужно слишком много информации положить.
Подскажите, пожалуйста, как вы это определили? Я смотрю на фотографию, и не могу понять, чем отмеченные на следующем фото транзисторы отличаются от неотмеченных.
Спасибо за ответ) Я как раз так и делал.
Я хотел поинтересоваться у автора комментария, как он в случае с Kustomize решает такую же проблему, если вообще с ней сталкивается
Подскажите, пожалуйста, один момент на Вашем опыте. Я для себя открыл helm, когда столкнулся с необходимостью параметризовать манифесты в CI/CD. Конкретнее, в случае, когда я хотел деплоить приложения на dev и prod окружения. Я использовал
values.yaml, чтобы указать там имя секрета, доменное имя для ingress и прочие вещи, которые могут различаться в разных окружениях.Я согласен с вашим мнением про добавленную сложность, но как тогда решить проблему, когда тебе действительно нужна параметризация?
С моей точки зрения, доказательство того, почему работает алгоритм — это одна из самых интересных вещей, достойных упоминания в статье (зависит от темы статьи, конечно). Например, почему алгоритм Дейкстры получает корректный результат и чем ему «мешают» рёбра с отрицательным весом.
По содержанию статьи: по-моему, Вы перепутали, какой из алгоритмов найдёт кратчайший путь в лабиринте. Это должен быть BFS. DFS найдёт путь, но не обязательно кратчайший.
А как YDB позиционирует себя относительно ClickHouse? Это "более современная" замена ему? Или у них принципиально разные сферы применимости?