пятница, 14 августа 2009 г.

[comp.humour] Пародийные отказы на публикации знаменитых статей

Бертранд Мейер (известный как автор языка Eiffel) поделился в своем блоге ссылкой на статью “We Are Sorry to Inform You”. В ней в пародийной форме показывается, как могли бы выглядеть отказы в публикации очень важных и знаменитых статей, если бы они попали к некомпетентным и/или недальновидным рецензентам. Как то:
E.W. DIJKSTRA "Goto Statement Considered Harmful."
E.F. CODD "A Relational Model of Data for Large Shared Data Banks."
A. TURING "On Computable Numbers, with an Application to the Entscheidungsproblem."
C.E. SHANNON "A Mathematical Theory of Communication."
C.A.R. HOARE "An Axiomatic Basis for Computer Programming."
R.L. RIVEST, A. SHAMIR, AND L. ADELMAN "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems."

Как известно, в каждой шутке есть только доля шутки. Поэтому некоторые моменты в пародиях хотелось бы отметить.

Про Дейкстру и goto:

The author is a proponent of the socalled "structured programming" style, in which, if I get it right, gotos are replaced by indentation. Structured programming is a nice academic exercise, which works well for small examples, but I doubt that any real-world program will ever be written in such a style. More than 10 years of industrial experience with Fortran have proved conclusively to everybody concerned that, in the real world, the goto is useful and necessary: its presence might cause some inconveniences in debugging, but it is a de facto standard and we must live with it. It will take more than the academic elucubrations of a purist to remove it from our languages.

Что-то это мне напоминает… А еще и вот это из рецензии из Кодда:

The formalism is needlessly complex and mathematical, using concepts and notation with which the average data bank practitioner is unfamiliar.

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

Еще из Кодда:

…at first sight I doubt that anything complex enough to be of practical interest can be modeled using relations. The simplicity of the model prevents one from, for instance, representing hierarchies directly and forces their replacement with complicated systems of "foreign keys." In this situation, any realistic model might end up requiring dozens of interconnected tables-hardly a practical solution given that, probably, we can represent the same model using two or three properly formatted files.

Пробабахавшись последние несколько месяцев с проектом, который активно использует РСУБД, мне кажется, что воображаемый автор рецензии был не таким уж недальновидным :) Если, конечно, заменить properly formatted files на object oriented database ;)

А вот “замечательные” слова из рецензии на статью изобретателей RSA:

It is unlikely that any method that runs counter to this standard will be adopted in any significant degree. True, the IBM method presents the problem of distributing the encryption key, but their method is a standard and we must live with it. Instead of creating nonstandard methods that will soon be dead for lack of users, the authors should try to extend the standard and devise ways to distribute the encryption keys securely.

Имхо, эти слова нужно обязательно адресовать всем, кто бросается снисходительно-высокомерными характеристиками “велосипед” или верит в то, что существует “один правильный и стандартный” способ делать что-либо.

[comp.prog.cpp] Замечения Кодт-а к идее проверки аргументов

В комментариях к моему маленькому изобретению уважаемый Кодт высказал несколько важных замечаний, которые, на мой взгляд, обязательно должны быть представлены широкой аудитории.

Я двойственно отношусь к выносу валидаторов в объявления.
С одной стороны, это бьёт по пальцам на как можно более ранней стадии.
С другой стороны - загромождает объявление, добавляет к нему новые
зависимости.

Совершенно верно. Если не ошибаюсь, на RSDN-не несколько лет назад обсуждалась идея шаблонов-валидаторов. Например, шаблонный класс checked_value<T, min, max>, который бы проверял попадание аргумента в диапазон [min, max] (да и сам Кодт является автором в чем-то похожей идеи auto_value<>). Я тогда покурил эту тему и решил в работе подобные вещи не использовать. Поскольку код программы засоряется валидаторами, но эффект от них оказывается не очень существенным (на практике они ловили ошибки даже реже, чем assert-ы). При более сложных проверках (например, число должно не просто попадать в диапазон, но и быть, например, четным) объявления валидаторов становились еще более суровыми. Что, в итоге, снижало гибкость программы при изменении требований к ней.

Еще одну проблему с валидаторами озвучил Кодт:

Также возникают заморочки, связанные с неявным кастингом.
Т.е. если у нас есть
checked_value<int,0,23> m_hour;
то придётся тщательно следить за его использованием в перегруженных
функциях (а особенно - в шаблонных).
А если у нас есть
foo::foo(checked_value<int,0,23> hour, .....)
то это предмет для спотыкания при передаче туда не int непосредственно,
а приводимых к int типов.

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

some_class_t::some_class_t( some_type_t & arg )
  : m_attr() // Инициализация атрибута по умолчанию.
      // Может быть слишком дорогой при выделении
      // памяти, обращении к системным ресурсам и пр.
  {
    // Валидация аргумента.
    if( !is_valid( arg ) )
      throw std::domain_error( ... );
    // Вот теперь правильная инициализация аргумента.
    // Переинициализация еще и потребует освобождения
    // ресурсов, захваченных в конструкторе по умолчанию,
    // что так же скажется на производительности.
    m_attr = arg;
  }

или же когда у атрибута вообще нет конструктора по умолчанию, то описанные мной валидаторы вполне могут помочь.

Но и здесь нужно учесть хорошее замечание Кодт-а:

Ещё одна проблема - это невозможность вводить сложные проверки.
Поскольку каждая проверка относится только к своему аргументу, а друг
про друга они не знают.
 
Можно, кстати, вот такой фокус делать:
 
#define CHECK_N_GO(cond, value) \
((cond) ? (value) : (throw std::shit_happened))
 
foo::foo(int x, int y, int z) :
m_x( CHECK_N_GO(x+y+z==0, x) ),
m_y(y),
m_z(z)
{}
 
Для нелюбителей макросов - пишем аналогичный шаблон
template<class T>
T const& check_n_go(bool cond, T const& value)
{ return CHECK_N_GO(cond,value); }
Только помним, что вызов функции жадный, в отличие от тернарного
оператора, и мы рискуем зазря вычислить value.
 
Конечно, проверку надо вешать на самый первый конструируемый член (не
забываем, что в списке конструирования они могут идти не в том порядке).

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

void do_something_with_name(
  const std::string & name,
  const std::list< std::string > & aliases );

мне кажется неудачной. Глядя на нее невозможно догадаться о связи аргументов name и aliases. Лучше их объединить в структуру, и передавать в do_something_with_name ссылку на ее экземпляр:

struct name_and_aliases_t {
  const std::string & m_name;
  const std::list< std::string > & m_aliases;
  ...
};
void do_something_with_name( const name_and_aliases_t & name );

Конструктор name_and_aliases_t может проверять нужное нам условие. А если в release-версии программы эту проверку нужно будет исключить, то сделать это можно будет при помощи #if-ов в теле конструктора.

Итак, что в сухом остатке? Валидаторы аргументов могут помочь в некоторых ситуациях (когда доминирующим стилем является defensive programming). Но при этом у валидаторов имеются недостатки, которые могут быть весьма серьезными в иных ситуациях и при изменении требований к программе в процессе ее сопровождения. Так что, если вы решитесь на их применение (особенно при декларации типов аргументов функций/методов), то делайте это с осторожностью и без фанатизма.

вторник, 11 августа 2009 г.

[comp.prog.bugs] Брошу еще один камень в огород ACE: сюрприз от UUID_Generator

Уже несколько лет активно пользуюсь библиотекой ACE. И чем больше пользуюсь, тем больше об этом жалею. Поскольку временами натыкаюсь в ней на неприятные сюрпризы и косяки. Вот и сегодня наступил на очередные грабли. На этот раз с генерацией UUID-ов посредством класса UUID_Generator (версии 5.6.*).

Оказалось, что если с очень коротким промежутком времени сгенерировать два UUID-а, то они окажутся одинаковыми! Два глобально уникальных идентификатора и одинаковых! Афигеть!

В Wikipedia указано, что существует пять версий алгоритма генерации UUID. И у класса UUID_Generator в методе generate_UUID есть аргумент version. По умолчанию он имеет значение 0x01. Т.е. первая версия, в которой для генерации UUID-а используется MAC-адрес и временная метка (со 100-наносекундной точностью). В принципе, в первой версии возможно создание дубликатов, если разница во времени между генерациями UUID-ов меньше 100-наносекунд. На современных компьютерах это запросто.

Но пакость в том, что ACE не поддерживает никаких других версий! И нигде в документации не пишет, что параметр version вовсе не определяет версию алгоритма. Поэтому очень неприятно было на тестах важного компонента вдруг получить два одинаковых UUID-а :( Хотя у меня в коде стоял вызов generate_UUID с параметром version раным 0x04. По наивности я думал, что ACE задействует четвертую версию алгоритма генерации UUID…

Простой тест показывает, что какую бы версию не задавали в параметре version, generate_UUID всегда будет генерировать два одинаковых UUID-а, если время между генерациями очень мало. Тогда как в библиотеке POCO класс UUIDGenerator запросто создает миллион уникальных UUID-ов при использовании четвертой версии алгоритма (UUIDGenerator::createRandom).

Такие дела. Еще раз убеждаюсь, что от ACE нужно отказываться. Поэтому, если вы собираетесь выбирать себе базовую C++ библиотеку, то обратите внимание в первую очередь на POCO, Qt или Boost. И только потом уже на ACE.

[life] Распрощаюсь с RSDN-ом, буду больше успевать.

Моя активная жизнь на RSDN-е подошла к своему логическому завершению вот с таким итогом:

Пользователь eao197 отправлен в бан с 10.08.2009 22:28:41+04 по 08.02.2010 22:28:41+03.
Причина: за неоднократную храбрость
Отправил: VladD2

Поводом к этому бану стало то, что сначала я посоветовал отправиться вышеупомянутому VladD2 в задницу, а потом еще и обозвал мудозвоном (данные ветки из форума уже удалены, к сожалению). О содеянном не раскаиваюсь и сделал бы это еще раз при случае.

Почему я это сделал и почему я об этом не жалею? Обзывать людей плохими словами, как и бить их по лицу (шее, почкам, яйцам и другим чувствительным местам) – не есть правильно и нормально. Но, временами, очень нужно. Если к вашей жене на улице пристает какой-то обкурившийся отморозок, можно попытаться решить проблему без насилия. Но шансов на успех будет ничтожно мало. Гораздо действеннее и эффективнее провести майя-гири в пах, а потом тяжелым тупым предметом по шее.

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

Как бы то ни было, в течении полугода я не смогу писать на RSDN и расставлять оценки. Поэтому приношу извинения всем, кто задавал мне вопросы и ждет моих ответов – я не смогу этого сделать.

Надеюсь, что полугода мне хватит, чтобы отойти от привычки встревать в RSDN-новские разборки. И тем самым, слезть с RSDN-новской иглы.

А посему можно подвести некоторые итоги моего почти пятилетнего участия на RSDN. Было очень интересно и, временами, познавательно. На RSDN классная система древовидных обсуждений. И прикольная система оценок и рейтингов, которая изрядно добавляет азарта. В обсуждениях на RSDN участвуют очень сильные проффи. Это и есть самое ценное.

Но не все так ладно в датском королевстве. Меня в конце-концов доканала “Генеральная линия партии”:

* существует только Windows и .NET, все остальное требуется рассматривать в микроскоп;
* опубликованные результаты наблюдений в микроскоп по определению являются абсурдом;
* попытки оспорить любой из приведенных выше постулатов должны быть объявлены демагогией.

Именно так. RSDN – это очень сильно Windows-ориентированный ресурс. Более того, это сильно ориентированный .NET ресурс. Что создает серьезные неудобства, когда пытаешься объяснить, что это еще не весь мир. Особенно, когда тебя через слово обвиняют в демагогии. В чем видные RSDN-новские деятели очень сильно поднаторели – чуть что и “Ты демагог, это демагогия…” А еще неуёмная пропаганда Nermele… Писал бы я “генеральную линию партии” сейчас, обязательно включил бы туда еще один пункт.

Ну а теперь суммарно. Является ли RSDN лучшим русскоязычным ресурсом по программированию? Сильно сомневаюсь. Имею возможность сравнивать RSDN и linux.org.ru. По количеству ссылок на интересные материалы они оба, на мой субъективный взгляд, приблизительно одинаковы. Многое из того, что анонсируется или обсуждается на LOR-е, мне никогда не попадалось на RSDN.

На первый взгляд, может показаться, что RSDN и LOR нацелены на разного уровня аудиторию. На RSDN-е все интеллигЭнтно, с Windows и .NET-ом. На LOR-е по простому, с матами, блэк-джекомLinux-ом и шлюхамианонимусами. Однако, разница лишь в форме. Поскольку в больших форумных баталиях все тоже самое – попытки опустить оппонента и показать себя как самого умного и эрудированного. Разница только в форме: цензурной или нецензурной. Итог одинаков – скука и почти автоматическая “фильтрация базара”, вне зависимости от его формы. В сухом остатке остаются только технические аргументы и интересные ссылки. Коих и там, и там практически одинаково. Думаю, так же, что слухи о том, что RSDN – это от 80% до 90% русскоязычных программистов, очень сильно преувеличены :)

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

понедельник, 10 августа 2009 г.

[life] Отличная оценка тайм-менеджементу от Дмитрия Давыдова

Один мой хороший знакомый пытается использовать тайм-менеджемент. С его подачи и я познакомился с этим понятием, через одну из книг Глеба Архангельского. Но у меня все попытки упорядочить свою жизнь и деятельность завершаются полной неудачей практически сразу же. К этому я уже привык, хотя иногда и возникает шальная мысль “может я уже перебесился с возрастом?”, после чего следует очередная неудачная попытка “Do it now” или “съесть лягушку”. Года полтора назад я окончательно забил на это дело, и выразил свое отношение к тайм-менеджементу следующим образом:

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

Для чего и придумывает разные методики. И пишет подобные посты, в которых факты представляются в определенном свете. Какие-нибудь приверженцы сыроедения или вегеторианства ведут себя, я полагаю, аналогичным образом.

Вчера наткнулся на замечательное высказывание на эту тему Дмитрия Давыдова: Веруешь ли ты в тайм-менеджмент, сын мой?

Мне понравилось.

[life] Сейчас буду рекламировать текстовый порносайт

Именно так. Как бы дико это не звучало :)

Хороший и умный человек, Виктор Шепелев (ранее известный в узких RSDN-новских кругах как мега-автор “Зверек Харьковский”), открыл ресурс humaneporn.info. Вот как он объясняет, зачем и почему:

humaneporn.info — журнал для публикации хороших порно-историй. Писать их может кто угодно, публикация определяется исключительно вкусами редакции.

Зачем это нужно? Затем, что порно — штука важная и нужная, а как раз в области порно-текстов существующие в русскоязычном Интернете сайты спсобны обслуживать только самые непритязательные вкусы — и, кажется, это просто ещё одно проявление нашего мира, где почти в любом месте — одинаково никак. Поэтому и возникла идея сделать журнал-сервис, которые интересно было бы писать (и читать) мне самому и людям, которые мне интересны (да, милые френды, к вам всем это относится).

Основные принципы, из которых я исходил:
* чёткий формат (ограниченный предельными размерами порно-истории — от 2,5 до 6 тыс.знаков, грубо говоря, «страница чтения», и, как уже было сказано, личными вкусами редакции)
* анонимность авторов (точнее, автор может подписать историю как угодно, но нет ни регистрации, ни привязки к существующей identity)
* удобство чтения (собственно, дизайнера у нас нет, поэтому что выросло, то выросло, но я тешу себя надеждой, что и то, что выросло — удобно).

Собственно, на данный момент журнал практически пуст — те несколько историй «для зачина», которые написаны по моей просьбе хорошими людьми. Я надеюсь, что у нас появятся хорошие авторы и хорошие тексты, и прошу мне в этом посодействовать — путём всевозможного пиара и полезных советов (ну и конечно же, написания собственных историй). К текущему проекту в его виде «бедненько, но чистенько» у меня есть ещё куча идей, но все они начнут работать после хотя бы нескольких десятков страниц.

Следует заметить, что проект делается исключительно из соображений «чтобы было весело», а не в расчёте на какие-либо мифические будущие прибыли. Да, я понимаю, что глупо заниматься этим в нынешней нетекстовой Сети, да ещё и через целых шесть лет после последней «Нейротики» Линор Горалик. Но я всё же попробую.

К эротике и порнографии я отношусь более чем спокойно. Бывает, на просторах eDonkey-сети попадаются образцы сего жанра, замаскированные под какое-нибудь популярное название. После нескольких первых минут просмотра подобного творения меня начинает одолевать скука и, в лучшем случае, я досматриваю окончание на 2x-3x кратном ускорении, возвращая нормальную скорость только на каких-то неведомых мне ранее трюках. Что до текстовой порнографии, то мне хватило прочитанной в конце 80-х “Эммануэли”. Но ханжой я тоже никогда не был, поэтому не вижу ничего странного и вредного в существовании нормального порно вообще, и сайта с порно-рассказами в частности. Тем более, что занимается этим мой знакомый и мне интересно, что из всего этого выйдет. Поэтому читать этот сайт я вряд ли буду, но размещу объяву, хотя мопед и не мой :)