пятница, 23 декабря 2011 г.

[life.politic] Попытался было понять слова нашего президента

Избегаю писать у себя в блоге о политике. Тому есть три причины:

- во-первых, в футболе, медицине и политике не разбираюсь совершенно;
- во-вторых, о политике нужно писать только, если есть в этом какой-то интерес – сам рвешься во власть или же помогаешь кому-нибудь туда попасть (корыстно или бескорыстно). Если такой цели нет (как в моем случае), то праздные разговоры о политике – это такой же бесполезный треп, какой был на советских кухнях;
- в-третьих, тупо сцыкотно. Спустят местному отделению КГБ разнарядку по количеству отловленных оппозиционеров и загремишь под фанфары. Так что незачем играть с государством в азартные игры, тем более что у тебя-то в этом никакого интереса нет (см. предыдущий пункт).

Тем не менее, иногда переклинивает. Сегодня с утра в КП-Беларусь (“толстушка”) обнаружил текст интервью Александра Лукашенко Сергею Доренко. Взгляд зацепился за пару вопросов вокруг митинга на Болотной площади в Москве:

ДОРЕНКО: А вы бы приехали на Болотную?

ЛУКАШЕНКО: Если это нужно было, конечно.

ДОРЕНКО: А то, что эта сакральная власть русских царей разрушается от общения с народом? Понимаете? В России есть концепция, что говорить с народом, реагировать на такие проявления — это разрушает сакральную власть русских царей, некую харизму трон Вы не печетесь о харизме трона?

ЛУКАШЕНКО: У меня другая политик Я окунаюсь в гущу. Я сразу же иду в гущу. Взорвали в метро — через час я был там, в метро. Меня там держали за руки, потому что была вероятность второго взрыв Я говорю «нет, даже если второй взрыв». Моя судьба в этой ситуации, человека, допустившего это, — моя судьба пойти. И что уже там будет… Но если есть Господь, наверное, только от него зависит. И я пошел. И не один.

ДОРЕНКО: И на Болотную пошли бы.

ЛУКАШЕНКО: Нет, я не говорю, что я бы пошел. Но если бы… правильно вы говорите: царь и власть должна действовать должно и не бегать по всем этим… она должна пойти только туда и тогда, когда это надо. Если на Болотной сложилась ситуация, что там должен быть глава государства, я бы не раздумывая пошел туд Но я не знаю, я не вовлечен, должен быть там кто-то… Не это главное, Сергей. Или ты прямо придешь и скажешь, или через ящик, Интернет или что — у тебя должно быть право. И у тебя должно быть то, что ты должен положить на стол людям и сказать. И они разведут руками. У вас есть такое право? Вы можете прийти открыто к людям, исходя из их требований?

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

ИМХО, в последнее время никто так сильно не дискредитирует Президента РБ как он сам своими собственными высказываниями.

четверг, 22 декабря 2011 г.

[life] Happy Birthday My Blog – 3!

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

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

За сим торжественную часть считаю законченной, пора вновь окунуться в работу :)

среда, 21 декабря 2011 г.

[life.photo.nature.wow] Просто офигительная подборка 50 best photos from The Natural World

Здесь. С большим удовольствием рекомендую.

Two 3-month-old crowned lemurs lay on their mother's back at the zoo in Mulhouse, France. Every year there are about 250 to 350 births at the Mulhouse zoo. (Sebastien Bozon/AFP/Getty Images)

Kamchatka brown bear Mascha and one of her two 3-month-old cubs nuzzle in Hagenbecks Zoo in Hamburg, Germany. (Fabian Bimmer/Reuters)

Marine life is rich in the Indonesian waters of Raja Ampat between the Pacific and Indian oceans. (Ebram Harimurti/AFP/Getty Images)

A polar bear jumps into the water at the St.-Felicien Wildlife Zoo in Quebec. (Mathieu Belanger/Reuters)

[blog] Вставка раскрашенных фрагментов кода в блог

В комментарии к предыдущей заметке ув.тов.Eugeniy спросил о том, как я вставляю раскрашенные фрагменты кода в блог. Решил ответить в виде отдельной заметки на случай, если кому-то еще это пригодится.

Для написания заметок я использую Windows Live Writer. Когда мне нужно вставить фрагмент кода, то использую редактор vim + следующий заготовленный фрагмент HTML:

<table width="100%" bgcolor="#000040"><tbody>
    <tr>
      <td><font color="#c0c0c0" face="monospace">
          </font>
      </td>
    </tr>
  </tbody></table>

Этот фрагмент я добавляю в HTML-код заметки. После чего набираю в vim-е фрагмент исходного кода и даю vim-у команду TOhtml:

Далее выделяю нужный мне кусок сгенерированного vim-ом HTML-я и вставляю его в заранее заготовленный HTML-ный фрагмент в тексте заметки. Получается что-то вроде:

<table width="100%" bgcolor="#000040"><tbody>
    <tr>
      <td><font color="#c0c0c0" face="monospace">
<font color="#ff80ff">#include&nbsp;</font><font color="#ffa0a0">&lt;iostream&gt;</font><br>
<br>
<font color="#60ff60">int</font>&nbsp;main() {<br>
&nbsp;&nbsp; std::cout &lt;&lt;&nbsp;<font color="#ffa0a0">&quot;Hello, colorfull World!&quot;</font>&nbsp;&lt;&lt; std::endl;<br>
}          </font>
      </td>
    </tr>
  </tbody></table>

И это все в результирующем виде будет выглядеть так:

#include <iostream>

int main() {
   std::cout << "Hello, colorfull World!" << std::endl;
}

Цветовая гамма, в которой vim генерирует HTML, соответствует обычной цветовой гамме, которую я vim-у задал для себя (т.е. именно такие цвета я использую в повседневной работе).

Теперь о том, почему я остановился именно на таком способе оформления фрагментов кода. Когда озадачился этой темой, то погуглил по Интернету. И нашел, что самые красиво выглядящие способы требуют изменения CSS-ов и подключения каких-то JavaScript-овых инструментов. Чего мне совсем не хотелось, т.к. лень было разбираться с правкой CSS в blogger-е, да и не хотелось, чтобы вместе с моими заметками к пользователю грузились еще какие-то JavaScript-ы. Мне показалось, что сделать раскрашенный фрагмент вручную намного проще и дешевле ;)

воскресенье, 18 декабря 2011 г.

[prog.memories] О том, как я от CamelCase к lower_case пришел

Когда я только начинал программировать – а это был 1990-й год – особых заморочек по поводу оформления кода не было. Да и смысла это не имело, поскольку сначала был какой-то Basic на БК1001, затем Turbo Pascal 3.0 на Robotron 1715. Насколько я помню, Basic сам все приводил к верхнему регистру. А на Robotron-е, кажется из-за шаманства с добавлением русских символов в кодовую таблицу, строчных латинских букв не было вообще. Поэтому первые программы писались только в UPPERCASE и других вариантов не было вообще.

Чуть позже с Robotron-ов пересел на IBM PC, на Turbo Pascal 5.0. И хоть Pascal не был чувствителен к регистру, программы хотелось оформлять красиво (т.е. так как в книжках и фирменных Borland-овских примерах), поэтому как-то само собой произошел переход к CamelCase. Деталей уже не помню, но вряд ли я писал If, Begin и End. Скорее if, begin и end. А вот функции и переменные точно писал в CamelCase. Даже одно время стандартные функции писал так WriteLn, ReadLn. Но не долго, намного проще было по старинке – writeln, readln.

Там же, на IBM PC к концу первого курса (а это была середина 1991) довелось познакомиться с языком C. После привычного, быстрого и безопасного Pascal язык C казался чем-то жутко сложным, да и изрядно тормознутым (в смысле скорости компиляции и линковки). Да и принятый в нем стиль lower_case вызывал двойственные чувства. Но C – это было намного круче Pascal (просто круче, без подробностей), поэтому изучал я его старательно.

В итоге, когда в самом начале второго курса я написал свою самую большую программу на Pascal (объемом в несколько тысяч строк), то я использовал уже lower_case. Т.е. в Pascal-евской программе все структуры, функции и переменные именовались строчными буквами, а разделителями в именах были подчеркивания. И таким стилем я пользовался затем около года, программируя уже на C, ассемблере x86 и потихоньку изучая C++.

Но где-то в 1992-м мне в руки попал двухтомник по программированию под Windows 3.0 за авторством А.В.Фролова и А.Г. Фролова. Оттуда я узнал по венгерскую нотацию :)

Венгерская нотация произвела на меня очень сильное впечатление. На тот момент она казалась очень логичной, удобной и полезной. Плюс к тому, практически все, что тогда касалось программирования под Windows, использовало именно венгерскую нотацию. Поэтому естественным образом я стал использовать венгерскую нотацию и делал это очень долго. Года где-то до 1998, если не позже.

Основными причинами, которые побудили меня отказаться от венгерки, были:

  • неудобство сопровождения кода. Со временем типы переменных менялись. Если раньше nPercentage была целочисленной, то со временем ее требовалось сделать вещественной и приходилось переименовывать ее в fPercentage. Соответственно, изменяя все места ее использования. Сейчас, при наличии IDE с мощными средствами рефакторинга в это сложно поверить, но тогда переименовать какую-то сущность в большом количестве исходников было не просто :)
  • маразм, до которого стали доходить в формировании префиксов. Когда венгерка ограничивалась префиксами i, n, f, l, p, pc, sz и еще парочкой таких же простых сочетаний, это было вполне удобно. Но когда приходилось писать что-то вроде ppcsz, pppi и пр., закрадывались сомнения в разумности происходящего :) Апогеем же стала как-то попавшая ко мне в руки книжка по Visual Basic-у, в которой перечислению “стандартных” префиксов была посвящена здоровенная таблица на десяток страниц.

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

Тут нужно чуть подробнее остановиться на особенностях CamelCase применительно к объектно-ориентированным языкам. В процедурных языках, вроде C или Pascal, все довольно просто. Но в том же C++ добавляются еще и классы, их атрибуты и методы. Как-то само собой получалось, что нужно уметь их выделять визуально среди остальных сущностей. Поэтому были разные варианты CamelCase, в которых существовали более-менее серьезные различия.

Нужно сказать, что упомянутая мной книга Фроловых о Windows 3.0 кроме приобщения к венгерской нотации, донесла до меня (и моих коллег) очень важную вещь – в отдельно взятом коллективе все должны использовать один и тот же стиль оформления кода. До этого я об этом даже не задумывался, а затем стал твердым приверженцем этой точки зрения, хотя и без фанатизма.

Так вот, для того, чтобы поддерживать единообразие кода в тех коллективах, где я работал в 1994-1996 годах, был выработан некий вариант стиля CamelCase, которым я пользовался до 2001 (и который, возможно, живет там до сих пор). Основными его чертами были:

  • префикс T для имен типов. Т.е. TFile, TByteStream и т.д.;
  • префикс m для имен атрибутов. Т.е. TFile::mHandle, TByteStream::mSize, TByteStream::mCapacity и т.д.;
  • именование методов со строчной буквы: TFile::open(), TByteStream::writeBlock() и т.д.;
  • именование свободных функций с прописной буквы: OpenFile, CreateByteStream и т.д.

Уже не помню, почему нам казалось, что имена методов и имена свободных функций в обязательном порядке должны различаться. Вероятно, где-то это имело смысл, где-то нет. В любом случае после перехода на lower_case я от такого деления отказался.

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

file file(…);

Поскольку компилятор даст по рукам. А вот так запросто:

TFile file(…);

Еще больше эта лень дает о себе знать с именами атрибутов. Ведь если у класса есть инициализирующий конструктор (а часто он есть), то имена аргументов конструктора часто совпадают с именами атрибутов. Поэтому, если у атрибутов нет никаких префиксов (суффиксов), то вот так просто уже не напишешь:

TPoint(int x, int y) : x(x), y(y) {}

нужно придумывать какие-то новые имена для параметров конструктора. Причем чем проще ситуация (как в примере с TPoint) тем сложнее выдумать что-то отличное от x и y. А вот с префиксами для атрибутов нет никаких заморочек:

TPoint(int x, int y) : m_x(x), m_y(y) {}

С атрибутами есть еще одна штука. В теле метода очень хочется видеть где ты изменяешь атрибут, а где локальную переменную. И префиксы для атрибутов в этом так же помогают. Я знаю, что многие для этих целей используют конструкции вида this->x или this.x, но я ленивый. Мне проще набрать m_x, чем this->x ;) Кроме того, если придется запрограммировать какое-нибудь математическое выражение, то с именами m_x, m_y оно еще будет читаться, а вот с this->x и this->y уже вряд ли.

В общем, CamelCase я использовал до 2001. Но в тот год решительно и бесповоротно (надеюсь) перешел на lower_case. Причина банальна – работая с кодом в lower_case у меня глаза устают намного меньше, чем с CamelCase. Видимо, начал сказываться возраст и многие часы, проведенные за не самыми хорошими мониторами. Как бы то ни было, в один прекрасный момент я понял, что illegal_indirection пишется и читается намного удобнее, чем IllegalIndirection. Причем вне зависимости от шрифта.

Поскольку я стал пользоваться lower_case, то претерпели изменения четыре упомянутых выше принципа:

  • типы имеют суффикс _t вместо префикса T;
  • атрибуты имеют префикс m_ вместо m (поскольку если раньше mX читалось нормально, то сейчас mx уже совсем не то, в отличие от m_x);
  • имена методов и свободных функций записываются строчными буквами и не отличаются.

Нужно сказать, что поначалу я еще пытался делать разные правила для разных ситуаций. Например, пытался применять подчеркивание в конце имени свободной функции (т.е. create_file_ вместо create_file), но это оказалась нежизнеспособная идея. Так же использовал разные префиксы для разных сущностей: m_ для атрибутов, g_ для глобальных переменных, c_ для констант, e_ для перечислений. Но со временем выжили только m_ для атрибутов и g_ для глобальных переменных (да и то не всегда).

Вообще говоря, идеальных нотаций (по крайней мере для C++) я пока не встречал. Везде что-нибудь, как-нибудь, но мешает. Поэтому я стал намного более спокойно относиться к разным вариациям. Скажем, обзывать имена констант, элементов перечисления и параметров шаблонов прописными буквами. Ничего страшного в мелких экспериментах со стилями я не вижу. Мы с возрастом меняемся, опыта прибывает, интересные идеи у других подсматриваем. Все течет, все изменяется, наши привычки, наши вкусы и наш код в том числе.

Главное при этом выдерживать единый стиль. Можно легко разобраться в коде, где человек именует классы, например, SMTP_session_t или SMPP_parser_t (вместо более привычного тебе smtp_session_t или smpp_parser_t). И придерживается этого стиля во всем своем коде. Но вот когда в начале заголовочного файла дается имя SMPP_paser_t, а следом за ним идет smpp_parser_state_t – вот это уже плохо. Т.к. заставляет искать разумную причину разных подходов к именам. Даже если ее нет :)

Напоследок еще несколько лирических отступлений. Самые удобные стандартные стили кодирования я видел в Eiffel и Ruby. Но, если говорить об Eiffel, то там язык не столь богат на возможности, как C++ – в нем есть только классы, методы и атрибуты. А вот в Ruby используется зашитая в синтаксис языка система префиксов для глобальных переменных, атрибутов классов и статических атрибутов классов (если пользоваться терминологией С++). Что мне представляется пока и разумным, и удобным. Понятное дело, что поскольку мне не нравится Java, то мне не нравится и ее стиль оформления кода. Ну а C# – это та же Java, но немного другая ;)

Если же говорить об отступах и фигурных скобках, то я перепробовал разные их сочетания:

if(...)
{
}

if(...) {

}

if(...)
  {
  }

Все они работают. Я могу свободно читать и писать код в любом из этих стилей. Но для меня самым удобным оказался последний вариант. Поскольку лично мне вот такой код разбирать много проще:

if(...)
  {
  }
else
  {
  }

чем вот такой:

if(...)
{
}
else
{
}

Но, полагаю, это дело личных предпочтений.

А вот чего я не люблю, так это экономии на пробелах и переносах строк. И никогда не мог понять, как люди умудряются писать и читать вот такой код:

if(0==Hf&&0==Mf)return 24;

если можно записать его вот так:

if( 0 == Hf && 0 == Mf )
   return 24;

В заключении пару ссылок на самого себя: