Выделение новых блоков памяти - это не тоже самое что и выделение новой памяти. Здесь нельзя просто взять и занулить целую область. В ext режиме ordered сначала может обновиться длина, а что в выделенной области - неизвестно, т.к. предполагается что запись будет успешной.
Про накопители говорить не буду, но из предоставленной таблицы ясно что приложения не преполагают полную атомарность и PSOW. Поэтому их можно использовать в различной инфраструктуре и не покупать специальное оборудование
Да, но тут уже важен порядок этих операций.
Встречается, но как уже писал, на это лучше не полагаться
Какой алгоритм? Накопитель исправляет ошибки, а мы - только обнаруживаем
Не совсем. Да, может только увеличиться размер файла успеть, но:
Никто не гарантирует, что там будут 0 - скорее будет случайный мусор
Если 4Кб имеется ввиду сектор, то тут больше про атомарность и PSOW - записаться может только часть. Например, корректно инициализируется заголовок, но остальное будет мусором. Без чек-сумм тут не обойтись
Писать независимые порции данных - дозапись или перезапись? Перезапись может быть атомарной (в исследовании все были атомарны), но не гарантируется. Дозапись - уже вряд-ли атомарна
Дополнительно, необходимо понимать размер сектора - где-то это 512 байт, а где-то 4096. Причем, некоторые диски могут работать в эмулируемом режиме (512e), что затруднит работу
Ко всему прочему, в процессе хранения целостность может быть нарушена и без чек-сумм тут не обойтись (накопитель может не справиться с исправлением)
Насчет NtFlushBuffersFileEx - в черновике оставил это замечание и забыл перепроверить: скорее всего где-то прочитал, но найти заново не смог. Удалил на всякий случай, чтобы не дезинформировать
Мне это тоже показалось странным, но потом пришел к выводу, что, в общем, это логично:
База данных, как и пользовательский интерфейс, - это плохой внешний мир. Функциональщики такое называют side effect, даже оборачивают в монады (привет IO из haskell)
Можно сделать логическое разграничение на 2 множества:
Веб, UI - это взаимодействие С нами
БД, внешние сервисы, устройства - это уже МЫ взаимодействуем
И эти множества расположены близко друг к други на противоположных краях слоя, как бы вход и выход.
Такое разграничение явно не проговаривалось, но лично я это так интерпретирую.
restrict - единственное ключевое слово из C, которое не поддерживается в C++
Есть заголовок <setjmp.h>, который (добавляет функции, возволяющие) позволяет делать нелокальные переходы. Т.е. можно вернуться вверх по стеку через несколько функций без явного return. В C++ она хоть есть, но если использовать, то можно забыть о всех деструкторах - они вызваны не будут.
Первое. На каждый запрос открывается транзакция. Кто первый закоммитил - тот и будет смотреть. Поймали ConcurrencyException - говорим Васе, что в кино не пойдет.
Второе. Да, код не оптимален. Его основная задача не решение бизнес-задач, а существование в качестве примера. DBA не придет, можно спать спокойно.
Как по мне этот пример больше про 3-слойное приложение:
Все модели наследуются от BaseModel, который нужен для правильной сериализации и работы с БД - и только для этого
Модели анемичные. По факту, выполняют роль DTO
На диаграмме бизнес-логика зависит от БД
В данном классе должна быть заключена вся бизнес-логика приложения (BookBookService) - я увидел лишь простое делегирование вызовов, без какой либо бизнес-логики
Вывод - это 3 слойное приложение, которое называют чистой архитектурой
Расстояние Хэмминга 2 - это же 2 ошибки, разве нет?
В данном случае, расстояние хэмминга - это количество изменений битов, начиная с которых может произойти коллизия и ошибки не будут заметны. На сколько понял, определялось эмпирически.
И второй вопрос - почему для разных расстояний разные полиномы? То есть, полином, ловящий 5 ошибок, может не поймать 2, так, что ли?
Как уже сказано выше - HD = 6, означает, что такой полином может отловить до 5 ошибок включительно
В книге Внедрение зависимостей на платформе .NET автор делает буквально то же самое: в начале книги реализует внедрение зависимостей через аргументы конструктора, а потом, понимая, что могут возникнуть циклические зависимости, предложил ввести для каждого метода отдельный класс - тот самый универсалий.
История с криптовалютой сильно схожа с бумом доткомов: все хотят себе сайт (биткон), потому что он сделает их богатыми. Только как именно - хороший вопрос.
Алгоритм интересный, но я бы использовал MD5 вместо SHA - меньше вероятность коллизий
"Выделение нового участка файла", вместо "Выделение новых блоков памяти" в 1
Выделение новых блоков памяти - это не тоже самое что и выделение новой памяти. Здесь нельзя просто взять и занулить целую область. В ext режиме ordered сначала может обновиться длина, а что в выделенной области - неизвестно, т.к. предполагается что запись будет успешной.
Про накопители говорить не буду, но из предоставленной таблицы ясно что приложения не преполагают полную атомарность и PSOW. Поэтому их можно использовать в различной инфраструктуре и не покупать специальное оборудование
Да, но тут уже важен порядок этих операций.
Встречается, но как уже писал, на это лучше не полагаться
Какой алгоритм? Накопитель исправляет ошибки, а мы - только обнаруживаем
Не совсем. Да, может только увеличиться размер файла успеть, но:
Никто не гарантирует, что там будут 0 - скорее будет случайный мусор
Если 4Кб имеется ввиду сектор, то тут больше про атомарность и PSOW - записаться может только часть. Например, корректно инициализируется заголовок, но остальное будет мусором. Без чек-сумм тут не обойтись
Писать независимые порции данных - дозапись или перезапись? Перезапись может быть атомарной (в исследовании все были атомарны), но не гарантируется. Дозапись - уже вряд-ли атомарна
Дополнительно, необходимо понимать размер сектора - где-то это 512 байт, а где-то 4096. Причем, некоторые диски могут работать в эмулируемом режиме (512e), что затруднит работу
Ко всему прочему, в процессе хранения целостность может быть нарушена и без чек-сумм тут не обойтись (накопитель может не справиться с исправлением)
Спасибо за замечание, исправил.
Насчет
NtFlushBuffersFileEx- в черновике оставил это замечание и забыл перепроверить: скорее всего где-то прочитал, но найти заново не смог. Удалил на всякий случай, чтобы не дезинформироватьМне это тоже показалось странным, но потом пришел к выводу, что, в общем, это логично:
База данных, как и пользовательский интерфейс, - это плохой внешний мир. Функциональщики такое называют side effect, даже оборачивают в монады (привет IO из haskell)
Можно сделать логическое разграничение на 2 множества:
Веб, UI - это взаимодействие С нами
БД, внешние сервисы, устройства - это уже МЫ взаимодействуем
И эти множества расположены близко друг к други на противоположных краях слоя, как бы вход и выход.
Такое разграничение явно не проговаривалось, но лично я это так интерпретирую.
Вставлю свои 2 копейки
restrict - единственное ключевое слово из C, которое не поддерживается в C++
Есть заголовок <setjmp.h>, который (добавляет функции, возволяющие) позволяет делать нелокальные переходы. Т.е. можно вернуться вверх по стеку через несколько функций без явного
return. В C++ она хоть есть, но если использовать, то можно забыть о всех деструкторах - они вызваны не будут.Решения из жизни.
Первое. На каждый запрос открывается транзакция. Кто первый закоммитил - тот и будет смотреть. Поймали ConcurrencyException - говорим Васе, что в кино не пойдет.
Второе. Да, код не оптимален. Его основная задача не решение бизнес-задач, а существование в качестве примера. DBA не придет, можно спать спокойно.
Действительно, грубая ошибка.
Как по мне этот пример больше про 3-слойное приложение:
Все модели наследуются от BaseModel, который нужен для правильной сериализации и работы с БД - и только для этого
Модели анемичные. По факту, выполняют роль DTO
На диаграмме бизнес-логика зависит от БД
В данном классе должна быть заключена вся бизнес-логика приложения(BookBookService) - я увидел лишь простое делегирование вызовов, без какой либо бизнес-логикиВывод - это 3 слойное приложение, которое называют чистой архитектурой
Можно и так было написать. Но без последних нулей проще понять, что работаем с полубайтами
Можете сами посмотреть
В данном случае, расстояние хэмминга - это количество изменений битов, начиная с которых может произойти коллизия и ошибки не будут заметны. На сколько понял, определялось эмпирически.
Как уже сказано выше - HD = 6, означает, что такой полином может отловить до 5 ошибок включительно
P.S. добавил это в статью, спасибо
пост
модернпродакшнНу все. Скоро PHP будет мертв
Нет, я ее понял.
Я сейчас не о том как правильно внедрять зависимости, а о том как книга написана:
Автор сначала приводит пример без зависимостей, потом добавляет внедрение через конструктор
Потом добавляет интерфейсы (на этом моменте он и рассказывает про эти 4 вида)
После выделяет каждый метод интерфейса в отдельный интерфейс
В конце говорит "а зачем нам куча интерфейсов, давайте медиатор запилим" - появляется медиатр, как цель всей нашей жизни
В книге Внедрение зависимостей на платформе .NET автор делает буквально то же самое: в начале книги реализует внедрение зависимостей через аргументы конструктора, а потом, понимая, что могут возникнуть циклические зависимости, предложил ввести для каждого метода отдельный класс - тот самый универсалий.
Только он пошел дальше, и дошел до медиатора
Так же как и из Омска - никак
Скорее не от властей, а от того чем поддерживается.
У гос-ва - власть/влияние
У криптовалюты - только доверие пользователей
Последнее, кстати, теряется быстро
История с криптовалютой сильно схожа с бумом доткомов: все хотят себе сайт (биткон), потому что он сделает их богатыми. Только как именно - хороший вопрос.