Запрещенные слова для комментариев и имен

Мы договорились в команде, что слова "new", "now" и "old" являются запрещенными для употребления в комментариях, именах переменных окружения, описаниях коммитов, когда речь идет об изменении поведения чего-либо.

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

Вместо ссылок на прошлое или будущее надо описывать конкретное поведение, так как характеристики "new", "now" and "old" становятся неактуальными уже через неделю. А еще хуже, что они приводят к появлению таких имен как "OLD_2_KEY_ALGORITHM" или "NEW_2_KEY_ALGORITHM".

Языковые kernel и user space

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

Сложные, связанные с использованием почти всех ресурсов вычисления происходят в kernel space – читай: когда нужно максимально точное понимание действительности, или надо изложить запутанную мысль в каскаде таких же запутанных мыслей, то это однозначно происходит на родном языке, и только в самом конце результат уходит на вывод (читай: перевод на язык среды) в user space.

Простые, бытовые вещи могут обрабатываться без перевода (на неродном языке) и по мере увеличения знаний и опыта в нем, сложность возможной обработки в user space может увеличиваться, тем самым разгружая процессор.

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

Можно пойти немного дальше.

Если человек живет и работает в родной языковой среде – он работает в командном процессоре, когда входная и выходная обработка данных весьма простая. В неродной среде – это работа в сложном UI, когда данные проходят длинный путь окон, локализации и разнообразных преобразований, чтобы поспасть на обработку в kernel space и в конце быть доставленными обратно на экран (читай: во внеший мир).

Работа с правами администратора

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

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

Как говорил один мой знакомый администратор, матерый ораклоид и юниксист: "Я никогда лишний раз в root'ом не зайду, а то вдруг чего надует (ветром)".

Тут как в армии - переходишь в режим рута - встаешь смирно, одной рукой отдаешь честь (сам себе), а второй аккуратно делаешь работу. И как только все сделано, закрываешь рутовую консоль.

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

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

Если разобраться, в юниксе, если ты не рут, то обычно крайне сложно сделать что-то, ломающее систему, хотя работать это не мешает. И это классное чувство. Пока ты явно не сказал su или sudo, ты на 99% спокоен, так как изменить что-то за пределами домашнего каталога система не даст.

Увы, в Windows нереально работать, не будучи формально администратором, хотя в Windows 7 ситуация улучшилась. Когда я пересел с Windows XP на семерку, я стал регулярно отвечать на вопрос о том, что какая-то программа хочет сделать что-то с правами администратора (хотя мой пользователь есть администратор в понятии Windows), и лично мне это нравится. Есть какое-то минимальное ощущения контроля на тем, что кто-то больше не "размазывает" DLL'ки по системе без моего ведома, от которых ей скоро поплохеет.

Переписывать или не переписывать

Уже не помню, где я взял эту картинку, но храню ее уже давно. Это великолепная иллюстрация процесса создания программного обеспечения.

Как там у Шекспира: "переписывать или не переписывать - вот в чем вопрос". Можно приляпывать временные костыли там и сям, не давая зданию упасть, но придет время, когда законы физики возьмут свое, и здание таки нае*нется.

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

Блог на английском для носителя русского языка?

Вы пробовали вести блог на английском?

Я уже долгое время тщетно пытаюсь это делать. Но дело как-то не идет. Каждый пост занимает в разы больше времени, посты приходится укорачивать, упрощать язык ("эдак" уже не завернешь). А самое, что внутренне неприятно - я четко вижу разницу в качестве языка. Вместо более-менее живого и, надеюсь, интересного, способа выражения мыслей, что я себе могу позволить на русском (хех, все-таки 30 лет практики), на английском получается какое-то сухое школькое сочинение, часто с неочевидными ошибками. И уж точно выглядещее, как НЕклево..

Кстати, а вы знаете интересные блоги на английском (хотя бы технические), которые пишут носители русского? (конечно, если человек вырос в английской среде с 5-6 лет, то это не в счет).

Немного об алгоритмах

Небольшой перерыв в активности блога вызван чудным мегасобытием - рождением второго ребенка. К дочке прибавился сын!

Scheduling для двоих детей, особенно с небольшой разницей в возрасте, конкретно отличается от одного, и является гораздо более сложной оптимизационной задачей, ибо количество переменных увеличивается на порядок. Но в целом - переходный процесс уже начал стабилизироваться, и снова появляется время позависать на всяких сайтах с алгоритмическими задачками (успел даже поучавствовать в двух SRM'ах на TopCoder'е).

Например, сайт Красноярского Дворца пионеров и школьников. Он позиционируется как место для самоподготовки школьников, интересующихся программированием, для олимпиад. Но хвала тем школьникам, которые могут сходу решать задачи сложности 50% и выше с этого сайта. Не всякий, как пишут в резюме, "профессиональный программист с многолетним стажем" сможет "взять" некоторые из них.

Обнаружил просто мега-сайт - e-maxx.ru/algo. Справочник по алгоритмам и их реализациями на С++. Все на русском языке. Как мне тут сказали, что, в принципе, освоив большинство из них, можно показывать неплохие результаты на программистских соревнованиях.

В разделе книг там также отличная подборка.

Из категории, опять-таки, олимпиадного программирования, могу посоветовать:



и



Мне эти две понравились тем, что тут даются не просто сухие академические описания алгоритмов, как, например, у Седжвика, а примеры их применения и адаптации для реальных задач.

Кстати, заметил интересный факт. Лично я не люблю язык Паскаль. Мое субъективное мнение. Многословный и эстетически некрасивый синтаксис. Но Российская школа программирования уважает Паскаль и Дельфи (спасибо вечному Турбо Паскалю 7.0), и поэтому программы в этих книгах написаны на Паскале, а не на С++. И заставляя себя вчитываться в паскалевские куски кода, еще и изуродованные форматированием для печати в книге, получаешь более полное понимание алгоритма. Как говорят: умение читать код может быть даже важнее для программиста, чем писать его.

Далее. Нашел интересную страничну какого-то профессора из MIT, на которой лежат его мини видео лекции с разборами некоторых классических задач динамического программирования. Манера подачи материала очень интересна - видео представляет собой постепенную запись объяснения задачи от руки, сопровожаемую голосом. Например, задача о сдаче, или оба вида задачи о ранце - с повторами и без (0-1).

Алгоритмы - это очень интересно.

Посты по теме:

• Фундаментальные алгоритмы
• Судоку для программистов или олимпиадные задачи

Общий виртуальный десктоп

В крупных конторах с множеством UNIX-программистов, работающих в основном через telnet/ssh/xterm, разумно сделать общий NFS-раздел, который виден всем, и также монтируется сразу на много машин. Во-первых, все имеют доступ практически ко всему в development пространстве, и во-вторых, содержимое моего home каталога всегда одно и то же на всех машинах (не надо вручную копировать файлы с машины на машину).

Минуту назад я не смог залогиниться xterm'ом из-за каких-то временных проблем в сети и попросил коллегу проверить, все ли работает. У него получилось, и он типа сказал в шутку, что жаль не может передать мне его телнетное окно.

Так вот, только родилась мысль -- а что, если все разработчики будут также "шарить" общий огро-о-о-мный виртуальный десктоп? Захотел что-то передать/показать коллеге -- просто перебросил окно в его "зону видимости".

Идея, конечно, утопичная, но красивая.

Продуктивные программисты

Не секрет, в сфере программирования работает много особей мужского пола. И также не секрет, что настоящие программисты обожают померяться п… знаниями, а конкретно, в плане чья программа круче! Лично я не являюсь крутанским мега крутаном в плане алгоритмов, и мне далеко до бойцов высшей лиги TopCoder’а, Google Code Jam’а и т.д., но алгоритмы люблю и ими интересуюсь.

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

Далее есть спецы по различным API – например, им не надо глядеть в man каждый раз при вызове socket (7), чтобы вспомнить, как там правильно подавить появление сигнала SIGPIPE и т.д.

Дальше идут знатоки проектирования. Всякие темы типа ООП, например, когда именно лучше применять агрегирование, а когда композицию и т.д.

За ними шагают апологеты тестирования – они во всех изматывающих подробностях знают, как правильно, например, написать конструктор класса, что класс было просто тестировать.

Может, есть и еще категории (если кто знает, прошу делиться).

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

У нас контора весьма крупная. Количество программистов более нескольких сотен. Есть из кого выбирать для интервьюирования. Многие не любят учувствовать в этом, но лично я люблю. По нескольким причинам. Во-первых, постоянно есть возможность глядеть на себя со стороны, так как если человек по телефону как орехи разделал все твои вопросы или поставил тебя в тупик встречным вопросом, то может ты как-то уже профессионально «засахарился»? Или если большинство коллег дали совершенно противоположную твоей оценку, может ты спрашиваешь какую-то ерунду и думаешь, что это важно? А во-вторых, есть появляется возможность быть в курсе, что вообще сейчас на рынке труда.

Теперь совсем к теме. Интересно слушать, как люди проводят интервью по телефону. Что они спрашивают, на чем делают акценты. Тут сразу становится видно, кто какой категории принадлежит человек (алгоритмист, языковед, API’ист, теоретик и т.д.)

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

Code review

Code review бесспорно является одним из ключевых моментов правильно организованного процесса разработки и поддержки софта.

Из лично опыта могу сказать, что весьма часто вторая пара незамутненных многочасовым смотрением на данный исходник глаз моментально замечает лажу, и в очередной раз удается избежать ночной fuck up, когда начинают валить письма от системы ночного тестирования, что туча QА тестов сломана из-за глупого недосмотра.

Perforce - отличная система для работы с реально большимы объемами репозиториев и кодовой базы в целом, но в ней нет встроенного механизма для code review. Google решили эту проблему сами.

В данном видео небезызвестный Гвидо ван Россум рассказывает о системе Mondrian, построенной на основе Perforce, которая применяется в Google для процесса code review.

Также мельком упоминается идея организации работы с исходниками в Google в общем. Например, что практически каждый инженер работает с огромным общим для все остальных разделом NFS, что позволяет видеть сразу, что происходит в других проектах.

Закомментированные куски кода и TODO

Когда я вижу в production коде, в котором мне надо по какой-то причине разобраться, что-то типа:

...
int x = (i << 8) | (i >> 2) | ((i & 0x06) ^ 0xAA);

// if (x >= 0x12345)
//  x = x >> 3;

calc_something_complicated(x);
...

мне хочется рвать и метать. Расчехлить blame, найти автора и заглянуть ему в глаза.

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

На втором месте у меня стоит отладочная печать, навеки оставленная в коде:

...
int x = (i << 8) | (i >> 2) | ((i & 0x06) ^ 0xAA);

// std::cerr << "На этот раз x = " << x << std::endl;

calc_something_complicated(x);
...

Снова получается, что автор сомневался и так и не отладил все до конца.

Конечно, подобные куски могут появляться просто по невнимательности и забывчивости, но как может помочь это оправдание? Никак.

Ну на третьем месте нашего хит-парада - блоки TODO.

...
int x = (i << 8) | (i >> 2) | ((i & 0x06) ^ 0xAA);

// TODO: Заменить тип int на int64, так как на носу эра 64-разрядных машин.
// Программист Вася, 06.10.2009. Если что, вы знаете где меня искать.

calc_something_complicated(x);
...

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

Итак, вывод тут только один: в production коде никогда не должно быть закомментированных кусков. А если они есть, то они должны сопровождаться четкими комментариями, поясняющими их суть.

Обучение программированию на Лиспе

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

Например, в школе, когда юный мозг так податлив и нежен, ничто так не уродует его как Бейсик, Рапира, Фокал, Лого или что-то там еще есть из разряда "простых языков для начинающих". Лисп же совершенно без навязывания угловатых конструций типа циклов, условий, да вообще "программных строк" так таковых помогает сходу въехать в краеугольные темы типа рекурсии, списков, деревьев и т.д., которые так тяжело даются пониманию потом, когда в голове уже сидят классы, процедуры, функции с циклами впридачу. В Лиспе же можно без нудного прогружения в замыслование механизмы языке сходу переходить к делу - к структурам данных и алгоритмам. И получается, что их изучение идет параллельно с изучением языка программирования, а не с огромным запозданием. А это очень полезно для формирования правильного программерского мышления.

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

Табуляция

Символы табуляции в исходниках — это бесконечное зло. А зло в квадрате, когда табуляция используется не только для отступов слева, но как разделитель (например, между аргументами функций, в теле блоков комментариев и т.д.). Ничего, кроме криков из другого конца комнаты типа "какая б... опять дописала кусок в моем неприкосновенном исходнике на С в Эклипсе, используя пробелы вместо табов, так что у меня тут в vi съехали все отступы?". И тут оба неправы. Первый в том, что не использовал тип отступов, принятый уже в существующем документе, а второй — в том, что использовал табуляцию изначально. Все шоколадно и солнечно, когда все сидят в Студии, но когда один использует vi, другой Студию, третий - FAR и т.д. (а это, увы, реалии много-платформенной разработки), то невозможно, чтобы все следовали правилу. Никто не любит соблюдать неудобные правила.

Лично я очень спокоен на тему стиля в целом и длины отступов в частности (лишь бы выглядело читабельно и соответствовало принятому для проекта соглашению), но вот табуляция — это как красная тряпка.

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

Programming WTF

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

Потом можно для снятия умственного напряжения и для еще большого подняния самооценки полистать сообщество "Programming WTF".

Начав с известной нетленки для проверки условия i < 10:

uint i;
...
if (i.ToString().Length == 1)
{
  ...
}

можно постепенно усиливать ощущения...

std::string str1;
std::string str2;
...
if (!strcmp(str1.c_str(), str2.c_str()))
{
   ...
}

вставляя в код противопехотные мины...



различного радиуса поражения...

#define bool BOOL

и убойной силы.

<?
define( "FALSE", -1 );
define( "TRUE", 0 );
?>

А вот это для настоящих гурманов и знатоков своего дела:

#define sizeof(x) rand()

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

Теперь ваши коллеги тоже снимут стресс и напряжение.

Рецензирование кода

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

В процессе внесения мноего патча в Google Test Framework какой-то кореец просто извел меня своими придирками не только в фундаментальному качеству представленных мной unit-тестов, доказывающих правильность моих изменений, но и вплоть до знаков пунктуации в комментариях. Лишь раза с десятого, он сказал "поехали!", и махнул рукой, как говорится. Патч то был размером строк в 50-60. По первости я просто бесился, что какой-то хрен указывает мне на мнимые "недостатки" моего "гениального кода". Но когда в результате я оглянулся на то, что было изначально и на результат — я простил ему все.

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

Вступительное слово, или "Почему? собственно"

Прекрасно сказано:

Математик любит искать во всем логику, закономерности, разумность. Если ее не хватает в реальной жизни, то компьютер, операционная система, языки программирования дополняют этот дефицит, служат своего рода отдушиной, тем сказочным миром, который помогает легче переносить уродливость мира реального. Следовательно, чем более иррациональным будет повседневное бытие, тем больше будет тяга к компьютеру, к его удивительно логичному и разумному поведению, осмысленным действиям, внутренней логике, виртуальной действительности. Там нет тупых и невежественных генералов, очередей за мясом, совхозов и овощебаз, общественной работы и субботников, там только четкие и понятные критерии, TRUE и FALSE, единица и ноль. А специалист по компьютерам, хороший программист всегда будет востребован, при любом правителе, любой идеологии, любых начальниках. Отсюда уже недалеко и до свободы, до реальной свободы, когда пропадает этот инстинктивный трепет перед важными надутыми начальниками, не освоившими толком даже компьютерных игр.

Михаил Масленников
Криптография и свобода

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

Будет интересно. Следите за анонсами.