Eugene Usachev

Скорее этот вопрос задан с целю, понять как правильно делать подобные простые счетчики.

Правильно - это выполнение операции в одном запросе. В вашем случае это будет

UPDATE warehouse 
SET balance = balance - 1 
WHERE product_id = 5
  AND balance > 0;

Такая одиночная форма запроса, во-первых, гарантирует, что при обновлении будет использовано строго то значение, которое прочитано (т.е. никто не влезет между чтением старого значения и записью нового), во-вторых, не даст "уйти в минус".

Если процедура не укладывается в один запрос, то выполняющие операцию запросы должны оформляться в транзакцию. С подбором правильного уровня изоляции, который исключит нежелательные интерференции и искажение данных. Есть и упрощённый способ - это использование блокировок. Но там слишком много сложностей, и слишком много надо учитывать, да и на производительности сказывается совсем не лучшим образом.

Можно (хоть и нежелательно) это делать и "на ручной тяге". Например, если вы хотите всё же использовать трёхзапросную форму, как в вопросе, то (схематично) будет что-то вроде

SET @balance = (SELECT balance FROM warehouse WHERE product_id = 5);
SET @new_balance = @balance - 1;
UPDATE warehouse 
    SET balance = @new_balance  
    WHERE product_id = 5
      AND balance = @balance;

Обратите внимание на дополнительное условие в последнем запросе. Оно проверяет, что с момента запроса старого значения и до попытки записать новое никто не внёс изменений в данные. Если же кто-то подсуетился и успел, то последний запрос обновит ноль записей, что и будет маркером, что операция корректировки баланса неудачна и надо повторить попытку (впрочем, ноль получится и в случае, если кто-то удалит запись для этого продукта - тогда никакие повторения не помогут).

Можно использовать оптимистичную блокировку вида

UPDATE items SET amount = :new_amount WHERE amount = :expected_amount AND id = :item_id

И проверять, что в результате обновилась одна строка и повторять в случае если не обновилась.
Либо делать SELECT * from items where id = :item_id FOR UPDATE в рамках транзакции, чтобы заблокировать конкретную строку.

Либо можно попробовать что-то типа

UPDATE items SET amount = amount - 1 WHERE id = :item_id

чтобы вычисление нового количества произошло также атомарно.

Либо использовать схему с event sourcing, как предложил constantinesx и хранить только события "такой-то пользователь просканировал такой-то товар" и потом уже отдельно считать агрегированное значение (есть разные способы)

Либо можно упороться и хранить каждый экземпляр товара как отдельную строку в таблице, но это вырастет в очевидную проблему, если на складе хранится очень много одинаковых товаров.

Чтобы выбрать наилучший вариант - надо смотреть на систему полностью, а не на один маленький кусочек в рамках вопроса.

В карьерных решениях более продуктивно уходить не от чего-то, а к чему-то. Можете найти работу с условиями лучше - уходите. Не можете - не уходите.

Элементарно же, когда пользователь начинает опрос, сохранять в БД запись, содержащую идентификатор опроса, идентификатор пользователя и время начала опроса.

index. А вообще, индексы элементов массива пришли из математики - i, j, k для первых трех измерений.
Просто, первыми компухтеры оседлали математики, отсюда и традиция в циклах использовать эти буквы.

При превышении capacity адрес может измениться.
Довольно банальная оптимизация - если впереди необходимая память свободна, расширение происходит на месте, без переноса.

Проверить можно так

fn main() {
    let mut vec = Vec::with_capacity(2);
    let initial_ptr = vec.as_ptr();

    let (new_ptr, new_capacity) = std::iter::repeat(())
        .enumerate()
        .find_map(|(i, _)| {
            vec.push(i as i32 + 3);
            (vec.as_ptr() != initial_ptr).then(|| (vec.as_ptr(), vec.capacity()))
        })
        .unwrap();
    println!("Initial ptr: {:?}", initial_ptr);
    println!("New ptr: {:?}", new_ptr);
    println!("New capacity: {}", new_capacity);
}

При перемещении адрес на стеке изменится, а адрес памяти выделенной на куче - нет.
Тут очень тонкий момент, который нужно понимать, данные которые мы помещаем в Box или Vec будут размещены на куче, но сами Box и Vec - это такие же структуры, как и любые другие, просто на них есть некоторая логика для управления памятью на куче, в случае 64 битной архитектуры и T: Sized, Box<T> будет занимать 8 байт на стеке и размер T на куче, а Vec<T> - 24 байта на стеке (указатель на начало, длина и фактически выделенная память) и размер T умноженный на capacity на куче.

fn main() {
    let a = Box::new(42);
    println!("Stack address of a: {:p}", &a);
    println!("Heap address of a: {:p}", &*a);
    
    let b = a;
    println!("Stack address of b: {:p}", &b);
    println!("Heap address of b: {:p}", &*b);
}

Stack address of a: 0x7fff59586010
Heap address of a: 0x58cf76717b10
Stack address of b: 0x7fff59586018
Heap address of b: 0x58cf76717b10

Паузы во времени между пакетами для передачи пакетов из других потоков или те же самые ограничения на пропускную способность. А так же между отдельными сигналами кодирующими биты во время передачи. Поток состоит из времени передачи пакетов и пауз между пакетами. Соответственно пропускная способность - это объём данных переданных за определённое время. Пакет и байты в нём передаются всегда с максимальной скоростью, которую может выдать оборудование, поэтому и получается, что для отдельного пакета доступна вся скорость канала. А вот уже потоки делят канал друг с другом.

когда тебе говорят выполнить ТЗ, которое не является для тебя вызовом и занимает всего час времени, а потом не отвечают вообще - это довольно грустно

Это действительно грустно, позор этим компаниям. Но боюсь, что сделать с этим вряд ли что-то можно. Разве что пытаться вежливо, но настойчиво переспрашивать фидбек.

Стоит ли пытаться "удивить" проверяющего? Есть ли прок от того, что в задании, где просят написать коротенький код, я его дополняю, подключая celery, меняя базу данных с локальной на более релевантную, засовывая приложение в докер образ?

Можно написать базовую версию, а потом сделать ветку и навертеть в неё сверху всякого, что показывает глубокое знание языка, владение абстракциями и шаблонами, знание тонкостей фреймворка, умение писать масштабируемые системы и т.д. и т.п.

Стоит все эти техзадания публиковать и добавить ссылку на github в резюме, если она ещё не там.

У вас не создан файл go.mod в корне проекта. Выполните команду
go mod init github.com/yourname/yourproject
в корне проекта. Адрес может быть любой, принято указывать адрес вашего репозитория, но можете указать и несуществующий урл. Будет работать если указать не урл, а просто goproject, но так не принято и форматтеры кода будут путать ваш пакет со стандартной библиотекой.

У нас в файле shapes.go почему-то package goproject, хотя должен быть package utils

Потом замените ваш импорт на
import github.com/yourname/yourproject/utils""

Да, стоит, это великолепное издание проведёт тебя так гладко и приятно по языку, что после ты не захочешь смотреть на другие)

Вдобавок многие популярные библиотеки пишут обучалки в формате Rust Book.

Какой пакетный менеджер лучше взять?

Conan или vcpkg, чё тут думать. Рекомендую Conan, но vcpkg тоже уже созревшее решение, сейчас они оба захватывают рынок.

Или "взрослое" решение пишется без пакетного менеджера?

А вы пилите библиотеку или законченное приложение? Опишите подробнее что у вас за программное средство. Требования сильно разные. Например:

• если это C++ библиотека - то я бы выбрал один из пакетных менеджеров и подготовил бы библиотеку для работы с ним. Например в случае Conan это значит написать conan-рецепт (который conanfile.py), который и будет "точкой входа" в вашу библиотеку: с помощью рецепта Conan узнаёт, как собирать библиотеку, какие у неё зависимости, как упаковывать в бинарный пакет, какие архитектуры и ОС поддерживаются и ещё кучу полезной информации, которую без ПМ обычно описывают ручками в README
  
• если это сетевой-сервис, например HTTP-бэкенд для чего-либо - ну тут стандартом индустрии является Docker/OCI-образ. Собираете образ под нужные комбинации архитектуры и ОС (см. multiplatform builds), заливаете в registry, и любой желающий запустит контейнер из вашего образа в своей инфраструктуре, или использует ваш образ как базовый для сборки своего
  
• если это десктопное приложение, неважно GUI или CLI - ну тогда обычно ожидается инсталляционный пакет под поддерживаемую ОС. Для Линуха это deb/rpm/flatpak/snap, для Венды - msix или exe, для Мака - dmg. Далее либо выкладываете для скачивания где-то на сайте, либо публикуетесь в магазинах типа Microsoft Store или Snapcraft
  

Опишите точнее ваш случай, я лучше посоветую что вам взять.

Самому заниматься установкой зависимостей есть смысл только для статически линкуемых библиотек. В этом случае самый простой вариант такие библиотеки оформить например как субмодуль git. Тогда при клонировании вашего репозитория скачаются исходники библиотеки. В cmake просто собираете ее как отдельный таргет и используете по назначению. Хорошо если библиотека уже поддерживает сборку через cmake - будет меньше возни. Если нет, то придется написать самому для нее CMakeLists.txt.

Для динамических библиотек стоит оставить удовлетворение зависимостей пользователю, потому что вариантов пакетных менеджеров много (вы хотите их все поддерживать?). В вашем CMakeLists.txt нужно только сделать тем или иным способом поиск установленного пакета и если его нет - выдачу ошибки и завершение сборки. Такие механизмы в cmake есть. Можно использовать выше приведенный find_package или например pkg_check_modules (который в свою очередь использует утилиту pkg-config).
Почти все более-менее серьезные приложения не пытаются установить самостоятельно свои зависимости при сборке. Можете проверить. Например: https://github.com/nginx/nginx?tab=readme-ov-file#...

Вы можете дополнительно к сборке приложения добавить и создание пакета для пакетного менеджера (или для нескольких пакетных менеджеров). Вот тут то вы и укажите необходимые приложению зависимости (в разных дистрибутивах линукс пакеты с зависимостями могут называться по разному). И тогда, когда пользователь будет устанавливать ваш пакет через пакетный менеджер все зависимости установятся автоматически.
В cmake есть механизм для создания пакетов для разных пакетных менеджеров: https://cmake.org/cmake/help/book/mastering-cmake/...

Постепенно я дополняю её патчами.

Непонятно какую схему вы планируете для разных unstable-версий. major.new_minor.patch-unstable.1, major.new_minor.patch-unstable.2. Кстати, рекомендую выбрать какой-то более привычный prerelease-идентификатор вместо unstable, например alpha и beta.

Также рекомендую подглядеть схему версионирования у какого-нибудь популярного крейта, например actix-web. Они используют предрелизные версии перед мажорными релизами.

Тут кстати встаёт вопрос, а так ли вам нужны предрелизы для ПАТЧ-версий библиотеки? Выглядит как чрезмерно детальное версионирование. Обычно когда публикуется патч-апдейт, и в нём обнаруживается баг, то просто выпускается новая версия с фиксом и со следующим patch-числом (т.е. была 2.5.2, потом вышла 2.5.3 с багом, для фикса которого выпустили 2.5.4).

Возможно я неправильно вас понял, и вы предполагали использовать предрелизы для новых минорных и мажорных версий - тогда это более разумное решение.

Собственно предрелизы на то и меньше релизов при операциях сравнения, что для этого и придуманы. Т.е. например:

1.2.5 < 1.3.0-alpha.1 < 1.3.0-alpha.2 < 1.3.0-beta.1 < 1.3.0

Чтобы пользоваться предрелизами правильно и потом не кусать локти из-за неудачно выбранной схемы, почитайте внимательно правила сравнения в спеке semver для предрелизов и подсмотрите в популярные пакеты как кто делает. Лично мы используем схему c alpha/beta плюс через точку номер предрелизного билда.

Схема именования предрелизов должна быть устроена так, чтобы решать задачу "приближения" к релизной версии. Если обычные 3.5.7 нужно читать как "3-я версия API + 5-й набор фичей для этого API + 7-я версия патчей для этого набора фичей", то 4.0.0-beta.6 нужно читать как «вроде бы уже почти 4.0.0, но ещё непонятно сколько ещё косяков надо перепрыгнуть, чтобы добраться до 4.0.0. На глаз вроде бы уже немного осталось (beta), но это уже 6-я бета, а до неё ещё несколько альф было, поглядим сколько ещё багов нам заведут»