пятница, 26 апреля 2013 г.

[prog] Презентация Thrift vs Protobuf vs Avro

Нашел вот такую презентацию. Считаю ее весьма интересной для того, чтобы утащить к себе и показать интересующимся:

Речь идет о системах сериализации Apache Thrift, Google Protocol Buffers, Apache Avro.

Данная тема волнует меня из-за того, что в свое время я писал что-то подобное. Это был мой проект ObjESSty, который до сих пор активно используется в наших C++ных разработках. И недавно Николай Шмаков даже очень серьезно модернизировал эту разработку, так что она стала еще лучше ;)

Хотелось бы найти время и написать об особенностях ObjESSty по сравнению с Thrift/Protobuf. Но не знаю, когда это случится :( Пока же скажу о нескольких отличительных чертах, которые сразу бросаются в глаза.

Во-первых, двоичная сериализация крутится всего лишь вокруг двух принципиально разных подходов. Содержимое двоичного представления может либо помечаться тегами (т.е. каждому значению предшествует тег, который определяет смысл значения), либо же поля имеют жестко зафиксированный порядок следования. Поэтому о том, какой смысл имеет значение, нужно судить по порядковому номеру значения. Так вот Thrift/Protobuf, а так же их прадедушка ASN.1 BER (он же, в простонародье, TLV -- Tag, Length, Value), используют теговую идентификацию полей. Причем значения тегов у них нужно задавать явно. Тогда как ObjESSty и его прадедушка ASN.1 PER базируются на строгом порядке следования полей объекта. Соответственно, каждый подход имеет разные взгляды на то, как должна поддерживаться эволюция схемы сериализуемых данных. Но это уже совсем другая история... (если кому-то интересно, то можно оставить свой голос в комментариях и, если таковые будут, я постараюсь раскрыть эту тему подробнее)

Во-вторых, ObjESSty изначально затачивался на поддержку объектно-ориентированного подхода. Поэтому, например, в ObjESSty есть поддержка наследования сериализуемых типов. Это может казаться не очень полезным, но на практике бывает необходимо объявить, например, базовые классы Request или Response, или Failure, от которых будут произведены десятки/сотни конкретных или промежуточных классов.

В-третьих, в ObjESSty используется совсем другой подход к работе с языком описания данных, нежели в Thrift, Protobuf или ASN.1. В ObjESSty программист сначала сам описывает C++ класс, объекты которого он хочет сериализовать, а затем уже делает отображение полей этого класса в DDL-описание (Data Definition Language). Тогда как в Thrift/Protobuf/ASN.1 код C++ класса полностью генерируется из .thrift/.proto/.asn1-файла. Подход ObjESSty позволяет легко добавлять в сериализуемые классы любые несериализуемые поля и любые методы. Может это и звучит странно, но на практике такое бывает удобно и полезно.

В-четвертых, в ObjESSty "из коробки" делалась поддержка контейнеров из стандартной библиотеки C++98/03: string, vector, set, multiset, map, multimap, deque, list. А так же объектов, на которые идет ссылка через указатель (и здесь таки очень полезным оказывается поддержка наследования, т.к. можно иметь атрибут типа "указатель на базовый тип", но хранить в нем указатель на объект производного типа; именно этот объект и будет сериализован/десериализован). Ну и еще в качестве приятного бонуса в ObjESSty можно указывать для атрибутов условия, при которых атрибут имеет смысл сериализовать. А так же значение по умолчанию для атрибута, если он не был сериализован. Но это совсем уже мелочи... ;)

Ну, а если вернуться к упомянутой выше презентации, то очень жаль, что в ней не упомянуты ASN.1 BER и PER. Хоть это и вымирающие нонче динозавры, но это классика, которую очень полезно было бы знать, если уж берешься говорить о системах сериализации данных :( Хотя это, вероятно, уже старческое брюзжание...

[prog] Errare humanum est. Или почему ошибки будут в программах всегда...

...на простом жизненном примере.

Так уж получилось, что работаю я в российской компании, но являюсь налоговым резидентом Республики Беларусь. В связи с этим я налоги плачу один раз, сразу за весь предыдущий год. Как раз сегодня эту операцию в банке и проделал. Но.

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

Программирование -- это способ воплощения чьих-то замыслов в виде работающего программного кода. Ключевые слова в этом определении специально выделены. Код должен быть работающим, что означает, что в нем должны быть отражены все необходимые детали. Тогда как замысел в принципе не может содержать всех деталей. Хотя бы вот из-за таких провалов в памяти :) А отсутствие деталей на этапе разработки кода как раз и приводит к ошибкам, т.е. неправильному поведению программы, когда возникает ситуация, про которую забыли где-то по дороге.

понедельник, 22 апреля 2013 г.

[life] Еще цитата из "Колес" Артура Хейли. О процессе подготовки рекламы...

...но не только. Думаю, что те, кому приходилось делать что-нибудь для VIP заказчиков (будь то дизайн или большой программный продукт), увидят в этом фрагменте что-нибудь знакомое для себя:

На мольберте оставалось еще с десяток листов. Барбара прокомментировала их кратко, но добросовестно, зная, сколько сил и стараний вложили молодые сотрудники агентства в каждый из них… Вот так оно всегда бывает. Прославленные творцы, старые зубры вроде Тедди Оша, стоят в сторонке. “Пусть детишки выпотрошатся”, – словно говорят они, зная по опыту, что любые варианты, как бы они ни были хороши, на первоначальных стадиях всегда отвергаются.

Вот и сейчас предложенный вариант явно не проходил. То, как держался Ундервуд, не оставляло в этом сомнений, и все, кто здесь был, это понимали, как понимали это еще вчера, до начала просмотра. По наивности Барбара в свое время спросила, почему так происходит. Почему перечеркивается столько усилий и бракуется работа вполне качественная, порой даже отличная?

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

Барбару – да и не только ее, как она со временем выяснила, – крайне удручала эта пустая трата времени, денег, человеческих сил и таланта. Из разговоров с сотрудниками других рекламных агентств она знала, что так обстоит дело и у “Форда”, и у “Крайслера”, то есть во всех компаниях Большой тройки. Такое было впечатление, точно автомобильная промышленность, обычно столь заботящаяся о времени и возмущающаяся бюрократической волокитой, создала свой собственный бюрократический аппарат.

Барбара как-то спросила: а был такой случай, чтобы вернулись к первоначальной идее, если она оказывалась наилучшей? Ответ был: нет, нельзя же в июне принять то, что было отвергнуто еще в ноябре прошлого года. Это могло бы создать неприятности для сотрудников компании. Такая штука может стоить места человеку, притом доброму другу агентства.

воскресенье, 21 апреля 2013 г.

[life.photo] Снимки под настроение очень старым Zeiss-овским объективом

Настроение заставляет дегустировать купажированный шотландский виски из Бреста. Как-то разговор вырулил на то, как D700 подтверждает фокус при работе со старыми мануальными объективами. Для демонстрации были сделаны два снимка. Очень старым Zeiss-ом 3.5/135mm. Параметры обоих фотографий: ISO200, 1/60, f/3.5, встроенная вспышка (на втором снимке с усиленной до +1 мощностью), сняты с рук, оба без обработки, просто конвертация из RAW в JPG в лайтруме.