Хабрахабр:
Совсем недавно начал продаваться Nexus 7, и продается вполне актуально. Но в YouTube уже во всю ходит видео, сколько хлопот доставляет он людям только лишь с распаковкой. Jean-Louis Nguyen решил собрать воедино нарезку распаковки нового планшета из встретившихся ему видеообзоров, и, надо признать, ситуация выглядит неутешительно. Но можно признать, что видео вышло довольно весёлым. Вывод таков: Google надо внимательней, или с серьезностью ставиться к запаковке своих продуктов. К примеру, в некоторых продуктах Apple, надо дернуть за специальную плёночку, чтобы достать свой планшет, или любой иной продукт. Но пускай Google также возьмут эту ?плёнку? на заметку.
disclaimer Так получилось, что последний месяц я разбираюсь с ZooKeeper, и у меня возникло желание систематизировать то, что я узнал, собственно пост об этом, а не о сервисе блокировок, как можно было подумать исходя из названия. Поехали! При переходе от многопоточного программирования к программированию распределенных систем многие стандартные техники перестают работать. Одной из таких техник являются блокировки (synchronized), так как область их действия ограничена одним процессом, следовательно, они не только не работают на разных узлах распределенной системы, но так же не между разными экземплярами приложения на одной машине; получается, что нужен отдельный механизм для блокировок. От распределенного сервиса блокировок разумно требовать: работоспособность в условиях моргания сети (первое правило распределенных систем ? никому не говорить о распределенных системах сеть ненадежна) отсутствие единой точки отказа Создать подобный сервис нам поможет ZooKeeper В википедии написано, что ZooKeeper ? распределенный сервис конфигурирования и синхронизации, не знаю как вам, но мне данное определение мало что раскрывает. Оглядываясь на свой опыт, могу дать альтернативное определение ZooKeeper, это распределенное key/value хранилище со следующими свойствами: пространство ключей образует дерево (иерархию подобную файловой системе) значения могут содержаться в любом узле иерархии, а не только в листьях (как если бы файлы одновременно были бы и каталогами), узел иерархии называется znode между клиентом и сервером двунаправленная связь, следовательно, клиент может подписываться как изменение конкретного значения или части иерархии возможно создать временную пару ключ/значение, которая существует, пока клиент её создавший подключен к кластеру все данные должны помещаться в память устойчивость к смерти некритического кол-ва узлов кластера Под катом код, данные по производительности и куча wtf-ов
Наручники, копии 3D-печатью и лазерной резкой Как показал отчет немецкого энтузиаста на конференции ?Хакеры на планете Земля? (Hackers On Planet Earth, сокр. HOPE) в Нью-Йорке, технология 3D-печати может найти применения не только в нескольких отдаленных от обычной жизни средах, как то копии окаменевших остатков вымерших животных или создание подробных моделей кровеносной системы. Отныне полагаться на форму какого-то объекта как на ключ будет ошибочным решением: консультант компьютерной безопасности из Германии Рэй, как он сам себя назвал, продемонстрировал дешевые копии пластиковых ключей, способные открыть наручники компаний Bonowi и Chubb. Как известно, обе фирмы делают всё возможное, чтобы ограничить попадание своих ключей только в руки собственных клиентов, как правило, правоохранительных служб. Рэй рассказал о проблеме некоторых производителей наручников, чьи устройства имеют одну форму ключа, что позволяет одному человеку заковать подозреваемого, а другому освободить его, не задумываясь над уникальностью своих комплектов ключей. До того, как у каждого комплекта наручников не будет собственный ключ, безопасность такой системы можно поставить под сомнение. Читать дальше →
О софистике (софизмах) в дискуссиях и об ООП Поскольку писать комментарии в режиме ?read-only? не положено, снова рискну написать в песочницу. Вступление Читая хабр, споткнулся об один из комментариев. Вернее сказать, споткнулся о цитату в этом комментарии: ?Я уверен, что ООП методологически неверна. Она начинает с построения классов. Это как если бы математики начинали бы с аксиом. Но реально никто не начинает с аксиом, все начинают с доказательств. Только когда найден набор подходящих доказательств, лишь тогда на этой основе выводится аксиома. Т.е. в математике вы заканчиваете аксиомой. Тоже самое и с программированием: сначала вы должны начинать развивать алгоритмы, и только в конце этой работы приходите к тому, что вы в состоянии сформулировать четкие и непротиворечивые интерфейсы. Именно из-за этой неразберихи в ООП так популярен рефакторинг ? из-за ущербности парадигмы вы просто обречены на переписывание программы, уже в тот самый момент, когда только задумали её спроектировать в ООП-стиле?. (с) Александр Степанов, со-автор C++, автор STL Перед тем, как перейти к сути этой заметки (а точнее ? к анализу приведенной цитаты Степанова), также хочу вспомнить небольшую статью с провокационным анонсом (?софистика ? это математика для жуликов?), которая как-то попалась мне на глаза в глянцевом журнале (что само по себе уже странно; нечасто удается в таких журналах на что-то обратить внимание). Электронная версия здесь. Далее я буду ссылаться на термины из этой статьи, поэтому рекомендую ознакомиться. Читать дальше →
В текущем проекте стала часто возникать необходимость конструирования множеств разнообразных объектов по каким-то идентификаторам. Была написана одна фабрика для какого-то множества, другая. Потом пришло понимание, что мы делаем одно и то же и нужно какое-то повторяемое решение. Проект базируется на Qt, который, как известно, имеет развитые механизмы работы с метаданными. Тем не менее конструирование объектов через QMetaObject нас не удовлетворяло по двум причинам: во-первых конструируемые объекты должны быть QObject'ами, а во-вторых при конструировании мы получаем указатель на QObject, который так или иначе придется преобразовывать, что чисто эстетически некрасиво. Проанализировав круг задач пришли к выводу, что мы хотим иметь статическую фабрику в базовых классах некоторых множеств наследников. Т.е. писать что-то в таком духе: BaseClass * instance = BaseClass::factory()->build("derived_name"); При этом, мы не хотим писать каждый раз много однообразного служебного кода. Да, мы ленивые. И конечно же мы не хотим чтобы фабрика или базовый класс знали о всех наследниках. Как нам это удалось...
За время работы администратором баз данных я выработал для себя одно правило, которого придерживаются многие DBA. Это ?золотое? правило всех администраторов баз данных ? не делай ничего серьезного с базой данных, если у тебя нет бэкапа. Если ты собрался серьезно изменить параметры базы данных, провести операции по техническому обслуживанию базы данных и т.п. ? то всегда перед этим надо выполнить операцию резервного копирования. Этот принцип достаточно долго работал и оправдывал себя, и даже в нескольких случаях помогал восстановить базу данных на определенный момент времени. Недавно перед нами была поставлена задача ? разработать процедуру резервного копирования хранилища данных размером в 20 Терабайт. Используя наработанные практики резервного копирования, я попытался разработать такую процедуру и уложиться в то же время в рамки RPO (recovery point objective) и RTO (recovery time objective). Обе эти характеристики измеряются во времени и представляют собой следующее: RPO ? допустимый объем возможных потерь данных, RTO ? допустимое время простоя или за какое время база данных должна восстановиться. Вот тут-то и началось самое интересное ? как бы я не прикидывал и не рассчитывал, но разработанная процедура резервного копирования никак не желала укладываться в эти рамки ? слишком большой объем данных надо было забэкапить. В самом лучшем случае, с многочисленными оговорками и условиями база данных восстанавливалась за несколько часов, а такого бизнес себе позволить не мог. Хотя, у Сбербанка на этот счет несколько иное мнение и они считают, что клиенты могут и подождать. Но тут был не Сбербанк. В обычной же ситуации, когда на базу данных не налагались серьезные ограничения и условия, восстановление заняло бы несколько дней. Это усугублялось тем, что невозможно ?снять? бэкап за приемлемое время ? это также занимало несколько дней и создавало большую нагрузку на базу данных. Сразу оговорюсь, что эта база данных не поддерживает инкрементальный бэкап в текущей версии. Возможно, если бы мы могли получить инкрементальность, то игра и стоила бы свеч, и традиционная процедура резервного копирования имела бы право на жизнь в этом случае. Поняв, что процедура резервного копирования здесь нежизнеспособна, я начал поиск уже существующих решений этой проблемы. Довольно быстро обнаружилось, что такие объемы информации никто не бэкапит ?в лоб?. Существуют несколько подходов, которые позволяют иметь резервную копию базы данных такого объема, более или менее актуальную во времени. Читать дальше →
Отписаться от этой рассылки