Интересный момент - уменьшить число единиц в коде, но как мне кажется, это лишь ненужное усложнение.
Когда впервые увидел подобную задачу, там была немного другая формулировка, так что мои решения были такими:
колбы перемешать, взять по капле из 500-а колб в одну пробу, и из других 500-а - в другую. одним образцом напоить 5 мышей, другим - ещё пять. Плюсы: находим колбы без яда, которые можно отправить дальше клиентам (50% - тоже результат, снижаем финансовые риски неустойки), и пятикратное резервирование на случай ложноположительных и ложноотрицательных тестов (мышь не умерла от яда, мышь умерла, а яде не было).
уточнили задание, что нужно найти не какой-то процент чистых колб, а именно колу с ядом. Поднапрягся, прикинул сложность алгоритма для бинарного поиска (логарифм чего-то там). Берём идею из прошлого варианта, но поим только по одной мыши каждым образцом. Чистые колбы выбывают, для оставшихся алгоритм продолжается. Плюсы: выжившие мыши переиспользуются, но можно и непереиспользовать. Малое число шагов алгоритма (менее десяти). Минусы: алгоритм не параллелится, шаги зависят друг от друга. Общее время выполнения поиска - более 5 часов (на один шаг - час).
значит, ожидается решение с временной сложностью О(1). Подозрение вызвало число 1000, которое очень близко к 1024, что в свою очередь 2^10. А 10 - число доступных мышей. И тут уже родилось решение битового кодирования. Но есть и пограничный случай - думаю, плохая идея нумеровать первую колбу кодом 000000000 - тогда будет сложно сказать, был ли яд в первой колбе или яда не было ни в одно из них, если все мыши останутся в живых.
Ну так неинтересно: держать пустую БД с идентичной схемой, только ради compile-time проверок:
The DATABASE_URL environment variable must be set at build time to a database which it can prepare queries against; the database does not have to contain any data but must be the same kind (MySQL, Postgres, etc.) and have the same schema as the database you will be connecting to at runtime.
SQLx supports compile-time checked queries. It does not, however, do this by providing a Rust API or DSL (domain-specific language) for building queries. Instead, it provides macros that take regular SQL as input and ensure that it is valid for your database. The way this works is that SQLx connects to your development DB at compile time to have the database itself verify (and return some info on) your SQL queries.
Прям как в pl/sql - ранее связывание sql-кода и проверка валидности sql-запроса (и не много прав доступа) в compile-time.
Я тут раздумываю использовать LLM для генерации примеров кода для учебной литературы. Не вижу в этом ничего непозволительного, так как хватает знаний, чтобы оценить качество. У и конечно же всё протестировать и поддерживать единство стиля.
Сейчас посмотрел, что в движке, который мы используем, там так: system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen, Ubuntu, Cantarell, "Fira Sans", "Droid Sans", "Helvetica Neue", sans-serif;
Стоит добавить, что размер приведённых в статье типов-обёрток такой же, как и у примитивных типов. Нулевая стоимость абстракций и стирание типов во время компиляции:
Странно, что не упомянут суммарный размер занимаемого места для индексов. Встречал таблицы, где размер индексов больше, чем сами данные в таблице (но индексы нужны, так что увы и ах).
Потом: рефакторинг промптов, "так уже никто не пишет", "Ой, модель обновилась, теперь эти промты не нужны", "Не знаю зачем эта строка, но без неё модель генерирует красный фон"
Такая простая уязвимость в государственном приложении
Есть одна ГИС, данные из которой потом уходят на ЕПГУ (Госуслуги). Там можно было переключиться на другого пользователя, дёрнув api из браузера. На пользователя другой организации или даже учётки админа находили. Но это всё баловство, в этом году нашли дыру посерьёзнее - во время редактирования сущности по id перепутали боевой и тестовый контур и отредактировали ЧУЖИЕ данные.
Безопасность закладывается при написании кода либо сразу, либо как получилось, так получилось. Судя по багфиксу разработчики даже не поняли в чём проблема.
Интересный момент - уменьшить число единиц в коде, но как мне кажется, это лишь ненужное усложнение.
Когда впервые увидел подобную задачу, там была немного другая формулировка, так что мои решения были такими:
колбы перемешать, взять по капле из 500-а колб в одну пробу, и из других 500-а - в другую. одним образцом напоить 5 мышей, другим - ещё пять. Плюсы: находим колбы без яда, которые можно отправить дальше клиентам (50% - тоже результат, снижаем финансовые риски неустойки), и пятикратное резервирование на случай ложноположительных и ложноотрицательных тестов (мышь не умерла от яда, мышь умерла, а яде не было).
уточнили задание, что нужно найти не какой-то процент чистых колб, а именно колу с ядом. Поднапрягся, прикинул сложность алгоритма для бинарного поиска (логарифм чего-то там). Берём идею из прошлого варианта, но поим только по одной мыши каждым образцом. Чистые колбы выбывают, для оставшихся алгоритм продолжается. Плюсы: выжившие мыши переиспользуются, но можно и непереиспользовать. Малое число шагов алгоритма (менее десяти). Минусы: алгоритм не параллелится, шаги зависят друг от друга. Общее время выполнения поиска - более 5 часов (на один шаг - час).
значит, ожидается решение с временной сложностью О(1). Подозрение вызвало число 1000, которое очень близко к 1024, что в свою очередь 2^10. А 10 - число доступных мышей. И тут уже родилось решение битового кодирования. Но есть и пограничный случай - думаю, плохая идея нумеровать первую колбу кодом 000000000 - тогда будет сложно сказать, был ли яд в первой колбе или яда не было ни в одно из них, если все мыши останутся в живых.
Ну так неинтересно: держать пустую БД с идентичной схемой, только ради compile-time проверок:
Единственная польза от статьи:
Прям как в pl/sql - ранее связывание sql-кода и проверка валидности sql-запроса (и не много прав доступа) в compile-time.
Я тут раздумываю использовать LLM для генерации примеров кода для учебной литературы. Не вижу в этом ничего непозволительного, так как хватает знаний, чтобы оценить качество. У и конечно же всё протестировать и поддерживать единство стиля.
Сейчас посмотрел, что в движке, который мы используем, там так:
system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen, Ubuntu, Cantarell, "Fira Sans", "Droid Sans", "Helvetica Neue", sans-serif;
Тема котиков в электронном журнале не раскрыта.
Стоит добавить, что размер приведённых в статье типов-обёрток такой же, как и у примитивных типов. Нулевая стоимость абстракций и стирание типов во время компиляции:
https://habr.com/ru/articles/908032/#comment_28280730
Подобное правилами линтера отлавливается:
clippy::as_conversions
clippy::cast_lossless
clippy::cast_possible_truncation
clippy::cast_possible_wrap
clippy::cast_precision_loss
clippy::cast_sign_loss
clippy::char_lit_as_u8
clippy::fn_to_numeric_cast
clippy::fn_to_numeric_cast_with_truncation
clippy::ptr_as_ptr
clippy::unnecessary_cast
invalid_reference_casting
Хаба "Ненормальное программирование" не хватает.
Странно, что не упомянут суммарный размер занимаемого места для индексов. Встречал таблицы, где размер индексов больше, чем сами данные в таблице (но индексы нужны, так что увы и ах).
Наверняка хочется чего-то большего: https://habr.com/ru/articles/764462/ - например, чтобы подсказывало подкоманду
Потом: рефакторинг промптов, "так уже никто не пишет", "Ой, модель обновилась, теперь эти промты не нужны", "Не знаю зачем эта строка, но без неё модель генерирует красный фон"
Иронично, что буквально недавно была хорошая статья в этом же блоге про новшества в аннотациях питона: https://habr.com/ru/companies/ruvds/articles/905832/
Есть одна ГИС, данные из которой потом уходят на ЕПГУ (Госуслуги). Там можно было переключиться на другого пользователя, дёрнув api из браузера. На пользователя другой организации или даже учётки админа находили. Но это всё баловство, в этом году нашли дыру посерьёзнее - во время редактирования сущности по id перепутали боевой и тестовый контур и отредактировали ЧУЖИЕ данные.
Безопасность закладывается при написании кода либо сразу, либо как получилось, так получилось. Судя по багфиксу разработчики даже не поняли в чём проблема.
А где-то ещё стоит 1С седьмой версии… И даже успешно работает.
В примере уже используются
IntoPrimitive
.Оператор
as
довольно опасный: