Что бы вы могли понять, что нужен вектор из 3-ёх элементов, а не любой, существует система типов. Через неё можно указать чего ждёт функция на вход. Например сделать тип Vec3, который в своих конструкторах выполняет все нужные проверки. В итоге у вас появляется возможность доп. оптимизаций, если одни и те же данные используются несколько раз. Например сразу хранить все нужные данные в виде Vec3, что бы, обрабатывая их повторно, не выполнять лишние проверки.
А статистику собирали, как часто вы это делаете? Лично я для себя понял, что такая идея для меня - это самообман. Если я не прочитал вкладку за 2-3 дня, значит я её никогда не прочитаю. Поэтому постоянно открытыми держу только рабочие вкладки (почта, тикеты, документация и т.п.). Всё остальное в топку - проще найти в гугле, чем искать среди 500 открытых вкладок. И даже в гугле искать не буду "старьё", т.к. каждый день в интернете появляется новая информация, искать и читать старую нет причин.
Насколько знаю, другие браузеры используют облачные сервисы перевода (как правило "от производителя"). В FF используется локальный движок перевода. Завезли это недавно и число поддерживаемых языков пока не велико.
Обычно это BTree. Даа, поиск в нём - это O(log(n)) в отличии от hash-table. Но с отдельным "кэшем" с HashMap проблема в том как надёжно поддерживать её актуальность и не выдавать ложно-положительных результатов. Особенно в предложенных условиях с миллионами записей и скорее всего с несколькими экземплярами бекенда.
если фильтр "сказал", что имя занято - лезем в базу, что бы перепроверить;
если "сказал", что свободно - лезем в базу что бы добавить пользователя.
Зачем тогда этот блюм, если в любом случае лезем в базу? Проще сразу в базу посылать insert и обрабатывать ошибку уникальности, которую в любом случае надо делать.
Про сомнительность использования кеша уже в целом написали, что выигрыш не стоит затраченых усилий. Индекс в базе данных, в случае частого использования, тоже будет хранится в оперативе и будет работать быстрее, чем линейный поиск в редисе. А если собеседуемый забыл про индекс, то он годится только на роль стажёра.
Из-за такой мотивации кучу библиотек десятилетиями не вылазят из версии 0.х. Всё думают про Васю, который может очень расстроится если через год после версии 1.0 выйдет версия 2.0. Лучше уж дождаться момента, когда просто не захочется или не будет возможности вносить улучшения в библиотеку. Тогда и выпустить 1.0.
Это слишком радикально. Правильнее вот так: Если автор сломал обратную совместимость - это его дело, вероятно так будет лучше. Но если он при этом не продолжает исправлять критические ошибки в прошлой версии - место ему в мусорном ведре :-)
Как правило такой способ используется для приложений, которые не создают ни какие артефакты или формат этих артефактов не зависит от версии приложения. Например формат odt, 7-zip и др. определяется отдельной спецификацией, которую не может изменить автор(ы) приложения.
В случае с библиотеками это скорее исключение. Надо быть очень уверенным в том, что API библиотеки не поменяется никогда в будущем. Чаще такое можно сказать про "заброшенные" библиотеки, в которых только исправляют ошибки и поддерживают "на плаву".
Да, согласен, это не очень приятно если ты выпустил релиз и понял, что немного облажался и можно было сделать лучше. Но ведь тут главное что бы выпущенный релиз был рабочим, даже если он и имеет не совсем идеальное API.
А насчёт того, что пользователи тратят время на обновление, так с мажорками ситуация точно такая же как с минорками в ZeroVer. Но почему-то выпустить версию 0.22 через пару дней после версии 0.21 как будто не считается чем-то зазорным и малоприятным. Хотя пользователи точно также два дня потратили на обновление и потом узнают, что им надо опять что-то проверять и обновлять. Хотя тут слово "надо" опять притянуто за уши. Ничего им не надо срочно обновлять, если у них сейчас нормально всё работает.
Проблема как раз в том как понять, что API стало стабильным. И что значит "я не собираюсь его ломать"? Это какой-то официальный договор, может закон, который запретит мне что-то ломать если я решу, что так будет лучше? У меня уже было так, что я выпускал мажорный релиз либы и на следующий день вспоминал, что забыл сделать одно ломающее изменение, которое я как раз откладывал до мажорки. И такое может случится в любой момент, особенно в большом проекте, где за всем не уследить. Поэтому нет какой-то настоящей стабильности кроме стагнации.
По моему это всё не более чем пожелания, которые к тому же может быть сложно соблюдать. API станет по настоящему стабильным, когда библиотеку перестанут развивать.
Конкретные числа в версии не имеют большого значения. То что либа имеет версию 10.0, не означает что она в 10 раз лучше чем версия 1.0. Это даже не означает, что 10-ая версия лучше чем первая. Это означает только то, что она не совместима с версией 1. Значение имеет только само изменение этих чисел в номере версии. И три числа удобнее использовать, чем два.
выпустить релиз 0.22 после 0.21.x, потому что "сломал" API;
выпустить релиз 2.0 после 1.x, потому что "сломал" API;
Сидение годами на 0-ой мажорке - это сродни суеверным страхам и бесполезным надеждам на то, что можно будет сделать что-то более правильно к своему 70-и летнему юбилею. Например упомянутому в статье крейту base64 уже 9 лет. Я, как и автор статьи, тоже без понятия, чего там можно так долго "мариновать".
У меня исключительно практический и алгоритмический подход к определению момента, для перехода на версию 1.0. Когда мне надо срочно выпустить хот-фикс, т.к. его очень ждут пользователи моей библиотеки, то значит уже пора делать версию 1.0, т.к. в этом случае я могу нормально использовать третье число для нумерации исправлений без добавления функционала. А на ZeroVer третье число совмещает в себе информацию об фиксах и новом, не ломающем совместимость, функционале.
Про брать обязательства - это очень странные мысли. Разработчики что ли кровью договор с дьяволом подписывают, когда выпускают релиз 1.0.0? Я думаю что это больше ментальная проблема у разработчиков. Они сами себе выдумывают какие-то причины, что бы не делать релиз 1.0.0 для библиотеки, которой уже несколько лет пользуются много людей. Никто их не найдёт по IP-адресу и не побьёт, если они выпустят версию 2.0.0 в случае слома обратной совместимости. Кому надо - обновятся, точно так же как обновлялись с 0.21 на 0.22. А кому не надо - будут сидеть на версии 1.0.
Одно из главных преимуществ Helm CEL — понятные сообщения об ошибках
И один из главных недостатков, т.к. текст ошибки должен полностью написать человек самостоятельно. И поддерживать его актуальность в будущем, что может быть не совсем просто из-за человеческого фактора.
А что насчёт переводов текстов ошибок на разные языки?
Может там есть режим автоматической генерации описания ошибки, на основе выражения?
Ну да, сам wasm это скорее спецификация. Виртульной машиной наверное можно назвать какой-то wasmtime. Но в общем-то смысл же тот же, что и в jvm - компилим один раз в байткод и запускаем везде. Даже ограничения похожие - нет прямого доступа к окружению, только через интерфейсы "рантайма"
Кому просто обнаружить? Банки может и имеют такие возможности, и то не уверен что это проверяется через отправку SMS. Может мобильное приложение как-то может узнать ID симки или ещё как-то (на это маловероятно). А вот простые бизнесмены скорее всего пойдут лесом и не получат такой возможности. Кроме того мы ведь говорим не про авторизацию по ID симки, а про ввод кода, который послали на номер телефона. Ничего кроме этого кода веб-сервис от пользователя не получит. А от сотовых операторов он получит только счёт на оплату SMS. Поэтому без двухфакторной авторизации, только с одним OTP, полученном через SMS, лучше не рассчитывать на безопасность своих данных в сервисе. И про это скорее всего написано в оферте сервиса. Что-то вроде: "Если вы не удалили свой аккаунт перед тем как протерять свой номер телефона, то вы сам себе буратино, мы ни чего вам не гарантируем."
Бинго! И это прям красный флаг, который лучше не игнорить. Если сервис использует только проверку по SMS, поддерживает номера любых операторов и хранит что-то личное, то лучше его не использовать. Если сервис обслуживает клиентов только конкретного оператора, то у него есть возможность узнать о смене владельца номера. В этом случае чуть более надёжно получается. Если забыть про то, что sms в приципе не надёжны.
Если сервис просто показывает киношки и музыку, то эта проблема с авторизацией не так важна.
В этом контексте телега даже лучше получается. Можно получить user_id без необходимости договариваться с пачкой сотовых операторов, которые даже разговаривать с тобой не будут о такой интегарции.
Что бы вы могли понять, что нужен вектор из 3-ёх элементов, а не любой, существует система типов. Через неё можно указать чего ждёт функция на вход.
Например сделать тип Vec3, который в своих конструкторах выполняет все нужные проверки.
В итоге у вас появляется возможность доп. оптимизаций, если одни и те же данные используются несколько раз. Например сразу хранить все нужные данные в виде Vec3, что бы, обрабатывая их повторно, не выполнять лишние проверки.
А статистику собирали, как часто вы это делаете? Лично я для себя понял, что такая идея для меня - это самообман. Если я не прочитал вкладку за 2-3 дня, значит я её никогда не прочитаю.
Поэтому постоянно открытыми держу только рабочие вкладки (почта, тикеты, документация и т.п.). Всё остальное в топку - проще найти в гугле, чем искать среди 500 открытых вкладок. И даже в гугле искать не буду "старьё", т.к. каждый день в интернете появляется новая информация, искать и читать старую нет причин.
Насколько знаю, другие браузеры используют облачные сервисы перевода (как правило "от производителя").
В FF используется локальный движок перевода. Завезли это недавно и число поддерживаемых языков пока не велико.
Обычно это BTree.
Даа, поиск в нём - это
O(log(n))в отличии от hash-table. Но с отдельным "кэшем" с HashMap проблема в том как надёжно поддерживать её актуальность и не выдавать ложно-положительных результатов. Особенно в предложенных условиях с миллионами записей и скорее всего с несколькими экземплярами бекенда.Такая структура уже есть в базе данных - индекс. При этом базы данных стараются держать "горячие" индексы в оперативе.
С фильтром блюма прям "отличное" решение:
если фильтр "сказал", что имя занято - лезем в базу, что бы перепроверить;
если "сказал", что свободно - лезем в базу что бы добавить пользователя.
Зачем тогда этот блюм, если в любом случае лезем в базу? Проще сразу в базу посылать insert и обрабатывать ошибку уникальности, которую в любом случае надо делать.
Про сомнительность использования кеша уже в целом написали, что выигрыш не стоит затраченых усилий. Индекс в базе данных, в случае частого использования, тоже будет хранится в оперативе и будет работать быстрее, чем линейный поиск в редисе. А если собеседуемый забыл про индекс, то он годится только на роль стажёра.
Из-за такой мотивации кучу библиотек десятилетиями не вылазят из версии 0.х. Всё думают про Васю, который может очень расстроится если через год после версии 1.0 выйдет версия 2.0. Лучше уж дождаться момента, когда просто не захочется или не будет возможности вносить улучшения в библиотеку. Тогда и выпустить 1.0.
Это слишком радикально.
Правильнее вот так: Если автор сломал обратную совместимость - это его дело, вероятно так будет лучше. Но если он при этом не продолжает исправлять критические ошибки в прошлой версии - место ему в мусорном ведре :-)
Как правило такой способ используется для приложений, которые не создают ни какие артефакты или формат этих артефактов не зависит от версии приложения. Например формат odt, 7-zip и др. определяется отдельной спецификацией, которую не может изменить автор(ы) приложения.
В случае с библиотеками это скорее исключение. Надо быть очень уверенным в том, что API библиотеки не поменяется никогда в будущем. Чаще такое можно сказать про "заброшенные" библиотеки, в которых только исправляют ошибки и поддерживают "на плаву".
Да, согласен, это не очень приятно если ты выпустил релиз и понял, что немного облажался и можно было сделать лучше. Но ведь тут главное что бы выпущенный релиз был рабочим, даже если он и имеет не совсем идеальное API.
А насчёт того, что пользователи тратят время на обновление, так с мажорками ситуация точно такая же как с минорками в ZeroVer. Но почему-то выпустить версию 0.22 через пару дней после версии 0.21 как будто не считается чем-то зазорным и малоприятным. Хотя пользователи точно также два дня потратили на обновление и потом узнают, что им надо опять что-то проверять и обновлять. Хотя тут слово "надо" опять притянуто за уши. Ничего им не надо срочно обновлять, если у них сейчас нормально всё работает.
Проблема как раз в том как понять, что API стало стабильным. И что значит "я не собираюсь его ломать"? Это какой-то официальный договор, может закон, который запретит мне что-то ломать если я решу, что так будет лучше? У меня уже было так, что я выпускал мажорный релиз либы и на следующий день вспоминал, что забыл сделать одно ломающее изменение, которое я как раз откладывал до мажорки. И такое может случится в любой момент, особенно в большом проекте, где за всем не уследить. Поэтому нет какой-то настоящей стабильности кроме стагнации.
По моему это всё не более чем пожелания, которые к тому же может быть сложно соблюдать. API станет по настоящему стабильным, когда библиотеку перестанут развивать.
Конкретные числа в версии не имеют большого значения. То что либа имеет версию 10.0, не означает что она в 10 раз лучше чем версия 1.0. Это даже не означает, что 10-ая версия лучше чем первая. Это означает только то, что она не совместима с версией 1.
Значение имеет только само изменение этих чисел в номере версии. И три числа удобнее использовать, чем два.
Не вижу особой разницы между вариантами:
выпустить релиз 0.22 после 0.21.x, потому что "сломал" API;
выпустить релиз 2.0 после 1.x, потому что "сломал" API;
Сидение годами на 0-ой мажорке - это сродни суеверным страхам и бесполезным надеждам на то, что можно будет сделать что-то более правильно к своему 70-и летнему юбилею. Например упомянутому в статье крейту base64 уже 9 лет. Я, как и автор статьи, тоже без понятия, чего там можно так долго "мариновать".
У меня исключительно практический и алгоритмический подход к определению момента, для перехода на версию 1.0. Когда мне надо срочно выпустить хот-фикс, т.к. его очень ждут пользователи моей библиотеки, то значит уже пора делать версию 1.0, т.к. в этом случае я могу нормально использовать третье число для нумерации исправлений без добавления функционала. А на ZeroVer третье число совмещает в себе информацию об фиксах и новом, не ломающем совместимость, функционале.
Про брать обязательства - это очень странные мысли. Разработчики что ли кровью договор с дьяволом подписывают, когда выпускают релиз 1.0.0?
Я думаю что это больше ментальная проблема у разработчиков. Они сами себе выдумывают какие-то причины, что бы не делать релиз 1.0.0 для библиотеки, которой уже несколько лет пользуются много людей. Никто их не найдёт по IP-адресу и не побьёт, если они выпустят версию 2.0.0 в случае слома обратной совместимости. Кому надо - обновятся, точно так же как обновлялись с 0.21 на 0.22. А кому не надо - будут сидеть на версии 1.0.
И один из главных недостатков, т.к. текст ошибки должен полностью написать человек самостоятельно. И поддерживать его актуальность в будущем, что может быть не совсем просто из-за человеческого фактора.
А что насчёт переводов текстов ошибок на разные языки?
Может там есть режим автоматической генерации описания ошибки, на основе выражения?
Ну да, сам wasm это скорее спецификация. Виртульной машиной наверное можно назвать какой-то wasmtime. Но в общем-то смысл же тот же, что и в jvm - компилим один раз в байткод и запускаем везде.
Даже ограничения похожие - нет прямого доступа к окружению, только через интерфейсы "рантайма"
Почему не подойдёт? Вроде тоже виртуальная машина с байткодом, как и WASM.
Так ведь есть уже для этого "взлетевшее" решение, JVM называется.
А вы пробовали для wasm делать вычисления в
f32вместоf64. Полагаю точности первого должно хватить для использования шума в играх.Кому просто обнаружить? Банки может и имеют такие возможности, и то не уверен что это проверяется через отправку SMS. Может мобильное приложение как-то может узнать ID симки или ещё как-то (на это маловероятно). А вот простые бизнесмены скорее всего пойдут лесом и не получат такой возможности.
Кроме того мы ведь говорим не про авторизацию по ID симки, а про ввод кода, который послали на номер телефона. Ничего кроме этого кода веб-сервис от пользователя не получит. А от сотовых операторов он получит только счёт на оплату SMS.
Поэтому без двухфакторной авторизации, только с одним OTP, полученном через SMS, лучше не рассчитывать на безопасность своих данных в сервисе. И про это скорее всего написано в оферте сервиса. Что-то вроде: "Если вы не удалили свой аккаунт перед тем как протерять свой номер телефона, то вы сам себе буратино, мы ни чего вам не гарантируем."
Бинго! И это прям красный флаг, который лучше не игнорить.
Если сервис использует только проверку по SMS, поддерживает номера любых операторов и хранит что-то личное, то лучше его не использовать.
Если сервис обслуживает клиентов только конкретного оператора, то у него есть возможность узнать о смене владельца номера. В этом случае чуть более надёжно получается. Если забыть про то, что sms в приципе не надёжны.
Если сервис просто показывает киношки и музыку, то эта проблема с авторизацией не так важна.
В этом контексте телега даже лучше получается. Можно получить user_id без необходимости договариваться с пачкой сотовых операторов, которые даже разговаривать с тобой не будут о такой интегарции.