Ждет подтверждения от диска наверное же при коммите, что вполне обычно в таких случаях. Коммит должен гарантировать ту D из ACID. Все так делают.
А вот на счет полноценности не стоит ругать. Их транзакции довольно просты и понятны, изолированы друг от друга и не оставляют много пространства для ошибок, в отличии от того ада, который вы увидите в базах данных с MVCC, типа InnoDB или PostgreSQL, где среднестатистический программист даже и не знает о разных уровнях изоляции и отсутствии 100% гарантий на consistency (по ACID).
Противоположными будут какие-то такие советы: Постоянно обсуждайте и требуйте повышений, минимум раз в пол года. Добудьте оффер и приходите на обсуждение с оффером от конкурентов. Если не продвигаетесь в карьере быстрее остальных, значит делаете слишком мало для этого. Постоянно сообщайте о своих успехах, даже мелких, видимость работы важнее самой работы. Заведите (или скажите, что завели) домашнего питомца, огромного, чтобы в офис невозможно было брать с собой, будет хорошим поводом отпрашиваться с работы каждый день пораньше, прогуливать тим билдинги и позволит в целом уменьшить напряжение. Никогда не давайте точные сроки менеджерам, всегда давайте промежуток с минимум пятикратной разницей по времени, позволит работать не спеша и меньше волноваться за сорванные «дедлайны», т.к. сразу предупреждали. Заведите отдельный телефон для работы, отключайте его по приходу домой, позволит подстраховаться от лишнего стресса дома.
Попробую на пальцах объяснить. Смотрите, они пишут, что вложили заработанные деньги, значит там реально нет 41 долларов в минимальной сумме аренды, а 0 вместо них и минимальная сумма аренды на самом деле 51 доллар. Дальше им достаточно работать чуть-чуть в плюс от этой суммы, чтобы зарабатывать больше, чем зарабатывали раньше. Это они потом опять вложат и опять и сколько-то уже останется и себе.
Ну да, они свое пиарят. В тексте вообще много маркетинга, решили меряться по latency, которая из бенчмарков настолько не настоящая, что никакой роли не играет на реальных нагрузках. А реальная tail latency из реальной жизни, которая заставляет юзеров ждать, у таких решений все равно проблемная, сеть и ОС и много чего еще ее угробят. И достижение каких-то реальных гарантий по tail latency — это уже совсем о другом уровне, где медленный, но распределенный Riak с этим справится, потому что учитывает возможные проблемы на сети и нодах, а тарантулы с редисами — нет.
Этот «прогресс» был еще 15 лет назад, если не раньше, DHTML назывался. Были еще одностраничные сайты целиком на флэш, жалкое зрелище.
Сейчас прогресс скорее в юзабилити, A/B тестах, аналитике, быстрых чистеньких легковесных сайтах нацеленных на результат. Раньше об этом вообще не думали.
Наверное потому не понимаете, что считаете прогрессом рендерить страничку текста тонной js кода. Нет, не прогресс это, не забивайте голову.
На самом деле хвост разных «непрогрессивных» браузеров и девайсов очень огромен и только растет, не говоря уже о тех, у кого для каких попало сайтов js отключен. Давно пора рассматривать примитивную страничку без js как просто еще один media query, причем дефолтный.
А вот рынок дизайна не очень соответсвует описанному в статье. Он как раз о заметном дизайне. Заказчики в основном хотят красивые картинки, круче чем у конкурентов, а решать проблемы они не хотят. И это задает, какие навыки стремятся развивать дизайнеры. И никакой пиар, направлленый на дизайнеров, не поможет это изменить.
Обычный человек боится использовать лексеры и парсеры, а вместо них пишет велосипед на регулярных выражения.
На самом деле обычный человек очень правильно делает, что избегает сложно понимаемые LR парсеры, lex, yacc и подобные пережитки прошлого. Гораздо проще, легче и важнее начинать с самописных recursive descent парсеров. Потом может посмотреть на PEG, которые такие парсеры генерируют.
К теории по компиляторам вообще стоет очень скептически относиться, слишком много там наследия прошлого.
Да, тогда уже можно взять и LRU/LFU по размеру словаря и даже в несколько ступеней по префиксам разной длинны, например. Будет быстрее стремиться к 100%. И у кого быстрее, тот и выиграет.
Это получается один блум фильтр на все? А по пути perfect hashing алгоритмов не пробовали, т.е. поделить все на бакеты, в каждом поменьше хэш функций и легче брутфорсить?
Можно еще набрутфорсить такие seed значения хэш функций, чтобы было больше коллизий на том же наборе данных. В полтора-два раза размер фильтров может уменьшить.
Я, правда, не успел попробовать блум фильтры. Тут уже кому повезло с чего начать.
А вот на счет полноценности не стоит ругать. Их транзакции довольно просты и понятны, изолированы друг от друга и не оставляют много пространства для ошибок, в отличии от того ада, который вы увидите в базах данных с MVCC, типа InnoDB или PostgreSQL, где среднестатистический программист даже и не знает о разных уровнях изоляции и отсутствии 100% гарантий на consistency (по ACID).
Сейчас прогресс скорее в юзабилити, A/B тестах, аналитике, быстрых чистеньких легковесных сайтах нацеленных на результат. Раньше об этом вообще не думали.
На самом деле хвост разных «непрогрессивных» браузеров и девайсов очень огромен и только растет, не говоря уже о тех, у кого для каких попало сайтов js отключен. Давно пора рассматривать примитивную страничку без js как просто еще один media query, причем дефолтный.
На самом деле обычный человек очень правильно делает, что избегает сложно понимаемые LR парсеры, lex, yacc и подобные пережитки прошлого. Гораздо проще, легче и важнее начинать с самописных recursive descent парсеров. Потом может посмотреть на PEG, которые такие парсеры генерируют.
К теории по компиляторам вообще стоет очень скептически относиться, слишком много там наследия прошлого.
Я, правда, не успел попробовать блум фильтры. Тут уже кому повезло с чего начать.