Сергей Соловьев

Если предполагается в перспективе использование вне РФ - то лучше использование tin вместо inn, и прочие по возможности таким образом заменять.
Ну а если сугубо для внутреннего пользователя - то можно использовать русские транслитерированные аббревиатуры.

Скомпилирует любой компилятор с++. Может выдать ворнинги, если включена опция реагировать на предупреждения, как на ошибки, то тогда не скомпилирует, но только потому что его конкретно об этом попросили. Это не ошибка компиляции.

В этом главная проблема Undefined Behavior: компилятор его почти всегда не видит, и программа с ним может даже работать в каких-то случаях так, как программист задумывал. А в других совершенно необъяснимо падает или выдает бред.

У ОС защита от такой наглости с памятью, конечно, есть. Такая программа рано или поздно упадет с access violation, segmentation fault или еще чем-то подобным, когда цикл дойдет до не вашей памяти.

По определению деления. Школа 3 класс.
Когда мы делим - мы отвечаем на вопрос "сколько раз от делимого нужно отнять делитель, чтобы получился 0". Остаток - это то что лишнее остаётся, что уже отнять мы не можем, не уйдя в минус.
Остаток всегда больше нуля.
При делении отрицательного числа на целое - мы наоборот прибавляем делитель к делимому, пока мы не получим 0 или положительное число.

Более формально это выглядит так:

Для любых целых чисел a и b, причём b != 0, найдётся единственная пара целых чисел q и r, таких что a = q * b + r, где 0 <= r < |b|.

a - делимое
b - делитель
q - частное (целое)
r - остаток

Вот и получается
1 = 0 * 5 + 1
-1 = -1 * 5 + 4

UPD: в python это не совсем так. На самом деле в Python действительно релизован mod, как говорит Rsa97, но у этой операции нет чёткого определения, по тому в разных языках оно реализовано по разному:
https://en.wikipedia.org/wiki/Modulo
q = floor(a/b)
r = a - b*q

В первом случае: q=0, r=1
Во втором: q=-1,r=4
(в принципе то же самое)
Интересное начинается, если делитель отрицательный:
Если взять a=1, b=-5, то тогда r=-1, q=-4
А вот при обычном делении с остатком: r=0, q=1

В линуксе:

rename 's/(\d+)(\..*)$/sprintf("%d-%d%s", ($1+1)>>1, ($1-1)%2+1, $2)/e' *

В виндовсе bat-файлом:

@echo off
setlocal enabledelayedexpansion
for %%f in (*.jpg) do (
  set name=%%~nf
  set ext=%%~xf
  set /a n1="(%name+1)/2"
  set /a n2="((%name-1)&1)+1"
  rename %%f !n1!-!n2!!ext!
)
endlocal

https://www.raspberrypi.com/products/raspberry-pi-5/
Стявят VPN прокси сервер (выходную TOR-ноду)
Чтобы потом "товарищи" приходили к Вам, а не к ним или их клиентам

Кто то счетает это хорошей идеей, как возможность связать все сервисы

Тем временем центральная идея микросервисов в том, чтобы связанность максимально снизить.

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

1. Составляется краткое ТЗ
   
2. Максимально подробно описывается проект в виде более детального ТЗ
   
3. Нанимаете опытного IT менеджера
   
4. Менеджер собирает команду для разработки частного ТЗ полностью со всеми деталями проекта
   
5. На основе ЧТЗ формируются требования к командам для реализации проекта
   
6. Подготавливается план разработки проекта
   
7. Нанимается команда или команды сопровождения и поддержки - системные администраторы, менеджеры, аналитики, консультанты, бухгалтеры, юристы и прочие
   
8. Организовывается рабочее пространство для команд разработки
   
9. Нанимаются и организовываются команды разработки в соответствии с планом
   
10. Ну и далее начинается основная работа - поэтапная реализация проекта
    

Я полагаю, что такие магазины сохраняют всё, например в postgres или greenplum, а затем передают в аналитические базы (или пишут параллельно), типа в кликхаус или oracle?

XX век прошел под флагом реляционных СУБД. Вокруг них строились все системы.
Для любой банковской системы БД - абсолютная царица дизайна. Именно от нее шло
техническое задание. От базы а не от Хибернейта и синтетических таблиц как щас.
Таблицы любили. Вокруг них строили красивые теории. Модели. EAV. Подгоняли
аппарат алгебры (Эдгар Кодд со своими формочками).

В появлением NoSQL и стриминговых систем - пришлось всем признать что реляционка
исчерпала возможность линейного роста. У Майкла Стоунбрейкера есть статья где
он меряет БД под нагрузкой и доказывает что треть ресурсов CPU просто сгорает
в блокировках и защелках и прочих механизмах синхронизации.

Какой софт использует розничная торговля - сложно сказать. Там будет десяток систем которые
работают просто всместе как Grid. Например сообщения от кассовых аппаратов и платежных
систем могут в первую очередь падать в JMS/MQ систему. А уже потом процесситься и ложиться в
БД операционного дня. И по проишествии периода - сливаться Warehouse и в BigData
Есть еще вариант что в аналитику сразу попадают данные со стриминга. Я такое видел.
И это не последняя часть стека. Аналитика в свою очередь является источником для всяких
BI, витрин данных. ОЛАП-кубиков и прочее что любят смотреть и показывать на презентациях.
С красивой инфографикой.

Что использует Магнит - чорт его знает. Это можно поискать по всяким конференциям. Но само
знание или название продуктов вам ни о чем не скажет. Если они используют допустим
Kafka+Clickhouse - из этого не следует что вам это пригодится.

Были странные архитектурные решения. Uber например пытался выжать максимальные мощности
из Postgres и не смог. Перешел на MySQL. Видимо им было достаточно MyISAM и брали лишь
только те фичи что надо.

Facebook строил Rocksdb (Key-Value) с очень сильной оптимизацией по диску. Там уже было
не R+Tree а другой тип дерева. Тоже видимо у конторы так "пригорело" что им надо было
штучную NoSQL делать.

СБЕР по слухам строил на Apache Ignite прослойку между Ораклом и клиентами потому что Оракл
не справлялся с нагрузками. Впрочем я не могу это нигде доказать. Просто слышал в разговорах
архитекторов. И это очень штучное и очень деликатоное решение. Другим оно может вообще не подойдет.
Нужно много думать о механике инвалидации кешей.

Хедж фонд BridgeWater строит свои хранилища ассетов на базе Amazon S3. Реально эти ребята пихают
в С3 все что можно. И в этом есть своя стратегия. S3 стоит дешево. И масштабируется. Дешевле чем DBMS.

Также, я думаю, что множество магазинов могут быть обслуживаться отдельными кластерами, чтобы работа всей сети не остановилась, если какая та БД выйдет из строя?

Эту задачу тоже можно решать на разных уровнях. Мне нравится решение от Cassandra. Там все
таблицы имеют 1-2 реплики. И убить всю систему в целом в принципе невозможно пока последний
датацентр стоит. Но Кассандра платит за это отказом от consistency и вообще она считается не-реляционкой.
Хотя базовый диалект SQL поддерживает. Фактически она - умный NoSQL c хорошим сетевым протоколом
обхода сбоев и конфликтов. Кажется Netflix ее активно использует.

Вобщем можно дизайнить системы по разному усиливая одни части и ослабляя другие.
Это как тот треугольник дешево-медленно-дорого но в углах стоят разные качества. Например
CAP-свойства систем. Или приоритеты. Тебе что важно. Быстро записать в БД платеж? Но при этом
чтение оперативных данных потребует лагов. Или наоборот писать медленно зато чтоб все по ящичкам
и по коробочкам лежало да и еще в разных копиях и вариациях.

Ну сборка - это то что в dll-файле, да.

Где ты прочитал о статических и динамических я не знаю, по тому загуглил сам.

Статическая сборка - это такая, сборка, которая сохранена как dll-файл.
Динамическая - которая создана при помощи System.Reflection.Emit и существует только в рантайме.

Чтоб не было путаницы и тавтологий. Сборкой также можно называть процесс билда (build).
Но скорее всего автор спрашивает что такое ассебли (assembly).

Очень подробное описание с примерами уже есть на сайте learn.microsoft и нам имеет смысл
просто прочитать и перевести.

https://learn.microsoft.com/en-us/dotnet/standard/...