Выглядеть определение такой безразмерной функции может как-то так (три точки в списке формальных аргументов следует воспринимать буквально, то есть там именно три точки):

int myfunct(int arg1, double arg2, ...) { /* какой-то код */ }

Так как в языке C обычно придерживаются соглашения о вызовах cdecl, то аргументы, передаваемые функции, передаются через стек, причем кладутся туда, начиная с последнего (правого) аргумента и заканчивая первым. Вот вам примерный портрет стекового фрейма для вызова функции с N аргументами на процессоре x86:

Все наши знания о фрейме ограничены значениями регистров ESP и EBP. Та точка отсчета, от которой мы можем отталкиваться для доступа к аргументам — текущее значение регистра EBP. Например, первый аргумент лежит по адресу EBP+8, а второй — по адресу EBP+12. Ладно, а сколько нужно прибавить к EBP, чтобы получить адрес N-го аргумента в стеке? Для этого нужно знать:

• сколько всего передано аргументов;
• размеры аргументов (кто сказал, что они должны быть одинаковы?).

Ни то, ни другое в доступных нам ESP и EBP не хранится. Знаем мы только то, что именованные аргументы имеют меньшие адреса. Выходит, что размеры аргументов должны быть жестко определены в теле функции или же получены на основе значений именованных аргументов. Но как определить их количество? Рассчитывать на форматную строку, как в printf? Но кто гарантирует, что эта строка правильная?

Что, страшно уже? К счастью, всю низкоуровневую рутину с жоглированием указателями и размерами готов взять на себя компилятор, предоставляя нам удобный интерфейс в заголовочном файле stdarg.h. Правда, количество аргументов и их типы нам все-таки придется выяснять самостоятельно.

Правила нехитрые:

• функция должна иметь по крайней мере один именованный параметр (именованные идут в списке формальных параметров перед неименованными);
• перед доступом к аргументам нужно вызвать va_start, чтобы инициализировать объект контекста (va_list);
• используем va_arg для последовательного доступа к неименованным аргументам;
• по окончанию вызываем va_end в той же функции, что и va_start.

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

#include <stdio.h>
#include <stdarg.h>
int sum(int count, ...) {
    va_list args;
    int total = 0;
    va_start(args, count);
    while (count--)
        total += va_arg(args, int);
    va_end(args);
    return total;
}
int main() {
    printf("%d\n", sum(1, 33));
    printf("%d\n", sum(4, 1, 2, 3, 4));
    return 0;
}

Пояснения здесь излишни. Кстати, va_list можно передавать в качестве аргумента другой функции. Надо только не забыть вызвать для него va_end в той же функции (а точнее, в том же вызове функции), где был вызван va_start. Не знаю точно, что делает va_end, но если он манипулирует значением EBP, то лучше бы это значение было тем же, что и раньше.

Зачем может понадобиться передача va_list? Обычно для написания оберток для функций семейства printf, например, в каком-нибудь логгере:

int msgOut(enum msgLevel level, const char *fmt, ...) {
    va_list ap;
    int ret;
    va_start(ap, fmt);
    ret = msgOutL(level, fmt, ap);
    va_end(ap);
    return ret;
}
int msgOutL(enum msgLevel level, const char *fmt, va_list vl) {
    if (level >= s_level)
        return vfprintf(s_stream ? s_stream : stdout, fmt, vl);
    else
        return 0;
}

Напоследок хочется сказать вот что. Если вы пишете функцию с переменным числом аргументов не от нечего делать, а в реальном проекте, то использование stdarg.h — единственный вариант. Организация стека в x86, описанная выше, — это штука, на постоянство которой не стоит рассчитывать. Оптимизирующие компиляторы могут организовать передачу аргументов через регистры, а уж про перенос программы на другие платформы и говорить не приходится. Еще одна рекомендация — пишите такие функции только для форматирования текста. Другие применения обычно создают больше проблем, чем решают.

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

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

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

Не нравится пример с машиной? Те же соображения верны для игры на пианино, занятий виндсерфингом, боевых искусств…

Недавно я стал ощущать примерно то же самое при программировании, после того как полностью перешел на Emacs в качестве замены всех IDE. Да, непросто запомнить комбинацию из трех-четырех, а то и более клавиш. Часто для нужных действий нет сочетаний клавиш, а иногда нет даже и встроенной возможности выполнять эти действия. Тогда я трачу кучу времени, ищу в Сети дополнения, правлю их напильником, вешаю некоторые действия на клавиши, потом несколько дней к ним привыкаю — и все. Больше я об этих действиях не думаю. Они выполняются сами, без моего участия.

Например, чтобы увеличить ширину текущего окна на 20 символов, я нажимаю Ctrl-u 2 0 Ctrl-x Shift-]. В общей сложности 8 клавиш. Я их набираю одним движением, не задумываясь, что это такое там делают мои пальцы. Когда я писал этот абзац, мне даже пришлось потратить некоторое время, чтобы осознать, что же именно я при этом нажимаю. В общем, полнейший автоматизм.

А вот с мышью автоматизм не вырабатывается. Нельзя вслепую ткнуть куда-то курсором — в этом процессе всегда участвует сознание. Сначала нужно увидеть некий визуальный маркер (кнопку, пункт меню), затем подвести туда курсор, используя обратную связь через глаза для точного позиционирования, затем щелкнуть кнопкой. Одним кликом часто дело не ограничивается, поэтому повторяем все снова. Так как в этом процессе участвует сознание, из кратковременной памяти вытесняются важные сведения. Эффективность падает.

Конечно, я все это говорю не про мышь и не про клавиатуру. И не про Emacs. И я не хочу ни за что агитировать и ни к чему призывать. Я просто хочу сделать вывод — следствие из утверждения из начала поста:

Для повышения эффективности следует пользоваться инструментами, допускающими бессознательное их использование.

• C @ Interview Mantra — подборка задач на C, предлагаемых на собеседованиях.
• C Puzzles — набор сишных головоломок, неплохо прокачивает знание тонких моментов языка.
• C Extensions — описание того, что GCC привносит в C помимо требований стандарта.
• Coroutines in C — статья о реализации сопрограмм на C.
• How to Use the restrict Qualifier — что такое квалификатор restrict и когда его нужно использовать.
• Ampifying C — совершенно сносящая крышу статья, описывающая применение генерации C-кода из Lisp-кода.

У меня по этому поводу всплыла в памяти одна цитата:

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

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

Так вот bash (и я вслед за ним) исповедует как раз такую философию: затраченные однажды усилия не должны затрачиваться снова. Ниже я приведу несколько советов, которые в рамках этого подхода позволяют иногда сэкономить несколько секунд. Мелочь, но с миру по нитке…

CDPATH

Переменная окружения CDPATH является аналогом переменной PATH с той разницей, что вторая определяет пути поиска исполняемых файлов, а первая — пути поиска каталогов, задаваемых в команде cd.

Если CDPATH не установлена, то поиск происходит только в текущем каталоге.

Обычно соответствующая строка в ~/.bash_profile выглядит как-то так:

export CDPATH=.:~:~/Dropbox:~/dload:~/wspace

Теперь, например, если в каталоге ~/dload есть подкаталог bibl, то каким бы ни был текущий каталог, команда cd bibl приведет нас в ~/dload/bibl.

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

alias

Команда alias позволяет создать псевдоним — короткое имя для любой команды или их последовательности. Чтобы создать псевдоним, нужно выполнить:

alias name="command"

Где, понятное дело, name — имя псевдонима, а command — что нужно выполнить, когда мы набираем в консоли name. Например:

alias pa="ps -A | grep"

дает нам новую команду pa, с помощью которой удобно искать процессы по части их имени. Обычно все вызовы alias записываются в файле ~/.bashrc.

Команда unalias выполняет обратное действие, то есть уничтожает указанные псевдонимы. Ключ -a предписывает удалить все псевдонимы.

Если выполнить alias без параметров, она выведет список всех определенных псевдонимов, причем в виде команд, которыми они создаются.

Кстати, имя псевдонима вполне может совпадать с именем существующей команды. Более того, это часто используется для задания командам «параметров по умолчанию». Например, у меня есть такой псевдоним:

alias ls="ls --color=auto"

Теперь «команда» ls будет раскрашивать свой вывод, и это не придется указывать явно. Если же мы хотим обратиться к исходной команде (то есть, временно запретить раскрытие псевдонимов), нужно перед ее именем поставить символ «\» (\ls).

Повторение набранного

Существуют специальные комбинации символов, хранящие последнюю введенную команду и ее аргументы:

• !! — вся команда целиком;
• !* — все аргументы;
• !:2 — второй аргумент;
• !$ — последний аргумент.

Чаще всего нужно обратиться или ко всей команде, или к последнему аргументу. Например, можно создать псевдоним на основе последней команды:

alias foo="!!"

или повторно выполнить команду от имени root:

sudo !!

или что-нибудь сделать с только что созданным файлом:

touch longscriptname.sh
chmod +x !$

В общем, вариантов много, проявите фантазию.

Поиск по истории команд

Это, наверное, и так все знают, но все же. Жмем Ctrl-r, вводим часть команды, затем жмем Ctrl-r до тех пор, пока не отобразится нужная команда. Enter.

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

———> Постовой

Теперь все знают, что crystalbit ведёт delphi блог и обсуждает там аспекты программирования.

А если честно, я с ним согласен. И сам все больше и больше отхожу от IDE в пользу Emacs, причем без средств управления проектами (да, я иногда меняю свое мнение). Во-первых, я нахожу, что «управление проектом» в техническом смысле — штука несколько эфемерная, и, во-вторых, в Emacs оно сделано ужасно неудобно.

В результате я решил, что хороший текстовый редактор повышает мою производительность гораздо сильнее, чем хорошая IDE. А автоматизация сборки и тестирования вполне удовлетворяется Autotools или cmake (статьи про которые я все никак не допишу), а что не смогут они, смогут сценарии bash или Power Shell.

P.S. Ссылку на Петцольда стащил у Сергея Зефирова.

Для лентяев добрые люди сочинили установочный скрипт (внизу страницы).

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

Итак, задача:

1. Хотим переключаться везде по одной и той же клавише. Причем, чтобы если мы нажимаем эту клавишу в Emacs, использовался его внутренний механизм, в остальных случаях пусть этим занимается ОС.
2. Хотим, чтобы п. 1 работал и в Windows, и в Linux. И желательно чтобы сценарий загрузки был общим.

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

• убедить ОС не переключаться, пока активен Emacs;
• после одновременного переключения и в ОС, и в Emacs, переключить ОС обратно.

Оказывается, первый вариант реализуем в Linux, а второй в Windows. Дальнейшее изложение предполагает, что в качестве универсальной клавиши переключения выбран Caps Lock.

Для Linux палочкой-выручалочкой оказывается сочетание SCIM/iBus и xmodmap. С помощью xmodmap можно переназначить Caps Lock на какое-нибудь неиспользуемое действие, например, F13. Для этого в файл ~/.Xmodmap вписываем строку:

keycode 66 = F13

Число 66 — это код соответствующей клавиши. Скорее всего, у вас будет такой же, но лучше в этом убедиться с помощью утилиты xev.

Дальше убиваем системную переключалку раскладок (без особых зверств), и настраиваем SCIM/iBus на переключение по F13, а затем отключаем переключение для Emacs, вписывая в ~/.Xdefaults строку:

Emacs*useXIM:false

Теперь остается только подправить стартовый сценарий Emacs (.emacs или init.el), вставив туда:

(global-set-key [f13] 'toggle-input-method)

Выходим из сеанса, входим обратно, тратим еще пару часов на доработку напильником, и все заработает. Для Linux это все. Я намеренно опустил некоторые подробности про настройку SCIM/iBus, поскольку времена меняются, и старые инструкции становятся устаревшими. А тут я как бы не причем: «настройте iBus на переключение по F13» еще долго не устареет. В конце концов, гугл никто не отменял. Идея использовать SCIM и его аналоги не новая, об этом много где можно прочитать.

В Windows такой фокус не пройдет, но зато один вдумчивый камрад предложил очень изящное решение (ссылка не работает?..), которое упомянуто выше: после переключения вернуть системную раскладку обратно. (Для установки Caps Lock в качестве клавиши переключения системной раскладкой нужно воспользоваться чем-то вроде lswitch или лезть в реестр.)

Теперь остается только вооружиться переменной system-type, и получим сценарий, который кроссплатформенно решает нашу задачу:

(if (eq system-type 'windows-nt)
    ((defvar safe-language-change-flag nil)
     (defun safe-language-change ()
       (interactive)
       (setq safe-language-change-flag (not safe-language-change-flag))
       (when safe-language-change-flag
         (toggle-input-method)
         (w32-toggle-lock-key 'capslock)))
     (global-set-key (kbd "<language-change>") 'safe-language-change))
  (global-set-key [f13] 'toggle-input-method))

Правда, в случае запуска в натуральной консоли проблема все еще остается.

Настройка Emacs — это определенно то дело, которым стоит заниматься линуксоидам в Windows (после сборки чего-нибудь из исходников, разумеется). Замечательно успокаивает нервы и нормализует давление.

Что бы там ни говорили, а Emacs невыгодно отличается от своих аналогов долгим временем начальной загрузки, особенно если в процессе оной грузится пара десятков дополнительных модулей. Но если для открытия файлов, скажем, *.el, назначить файл runemacs.exe редактором по умолчанию, то попытка открыть несколько файлов приведет к открытию равного количества экземпляров Emacs, со всеми вытекающими задержками и издержками. Мы же хотим, чтобы было как в Notepad++: редактор запускается один раз, и дальше все файлы открываются в нем.

Как сказал один емаксер, «учитесь любить Emacs Server». Учимся:

1. типы файлов, которые хотим открывать Emacs’ом, ассоциируем с %EMACSDIR%\bin\emacsclientw.exe;
2. создаем переменную окружения ALTERNATE_EDITOR="%EMACSDIR%\bin\runemacs.exe";
3. в начало файла .emacs (или init.el, у кого что) вставляем:
   # run emacs server
(server-start)

Теперь когда мы открываем файл, emacsclientw пытается найти запущенный Emacs-сервер. Если не находит, обращается к альтернативному редактору (runemacs), который открывает файл и запускает сервер. Если же сервер уже запущен, то файл просто открывается в новом буфере.

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

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

1. договориться о формате кодирования;
2. встроить простенькую распознавалку в программы GPS-навигации.

Чем занимается линуксоид, обретя свежую винду? Конечно же, собирает что-нибудь из исходников! Вот я и решил собрать себе последнюю Qt, да не просто собрать (этак можно MinGW прикрутить и спать спокойно), а так, чтобы почти вся разработка происходила в Visual Studio, и компилятор использовался местный, а не портированный. И чтоб отладка тоже из IDE.

Ну что ж, дело нехитрое:

1. качаем Qt и устанавливаем ее, скажем, в C:\qt\2009.05;
2. на всякий случай копируем в C:\qt\4.6;
3. устанавливаем переменные окружения:
   QTDIR=C:\Qt\4.6\qt;
   QMAKESPEC=win32-msvc2008;
   добавляем C:\Qt\4.6\qt\bin в Path;
4. дистрибутив версии 4.6 содержит забытые авторами временные файлы, которые приводят к ошибкам при сборке (настоящий opensource не собирается с первого раза, но зато всегда можно найти ответ на официальном сайте), поэтому нужно удалить файлы:
   C:\Qt\4.6\qt\src\script\tmp\moc\debug_shared\mocinclude.tmp
   C:\Qt\4.6\qt\src\script\tmp\moc\release_shared\mocinclude.tmp
   C:\Qt\4.6\qt\src\3rdparty\webkit\WebCore\tmp\moc\debug_shared\mocinclude.tmp
   C:\Qt\4.6\qt\src\3rdparty\webkit\WebCore\tmp\moc\release_shared\mocinclude.tmp
   будем надеяться, что в следующих релизах эта ошибка будет исправлена;
5. запускаем Visual Studio, и из нее консоль (Tools → Visual Studio 2008 Command Prompt);
6. переходим в C:\Qt\4.6\qt;
7. запускаем configure, отвечаем на его вопросы; начнется подготовка к сборке, которая продлится минут 5-10;
8. запускаем nmake, начнется сборка, которая продлится несколько часов (есть смысл оставить на ночь); в ходе сборки будет куча предупреждений, но не стоит принимать это близко к сердцу, главное чтобы процесс сборки не завершился сообщением об ошибке;
9. закрываем Visual Studio, качаем и устанавливаем add-in;
10. запускаем Visual Studio, идем в Qt → Qt Options и указываем там версию вместе с путем к установленному Qt;
11. C:\Qt\2009.5 можно стирать;
12. все.

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

Если ставить LGPL-версию Qt, то Qt Designer не будет интегрирован в VS, а запустится отдельно при открытии UI-файла. Это, конечно, неудобство, но не критичное.

К сожалению, скриншот сделать не смог.

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

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

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

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

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

Примерно то же, но гораздо быстрее, происходит, когда мы ныряем под воду. Наверняка вы чувствовали это неприятное давление на уши, если ныряли с маской и ластами. Дайверам обычно приходится «продуваться» каждые 1-2 метра глубины, иначе можно остаться без ушей. Но даже не все дайверы знают, что не обязательно иметь баллон за спиной, чтобы уравнивать давление. Когда в следующий раз будете нырять в Черном море за крабами, попробуйте один из перечисленных выше способов, и вы удивитесь, насколько комфортнее будет под водой даже на глубине 2-3 м.

Истоки такого альтруизма программистов можно обнаружить в культуре хакеров, начавшейся аж в 60-х годах. Об этом можно почитать в замечательной книге Стивена Леви «Хакеры». В то время свободное ПО было практически единственным вариантом: рынка софта как такового не было — был рынок железа. Общей аппаратной архитектуры не было, цены были фантастически высокими, и компьютеры являлись штучным товаром, к которому софт поставлялся в виде бесплатного дополнения.

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

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

Но жизнь-то — штука изменчивая, и вот, подвинув бородатых хакеров, за терминалы уселись банковские служащие и бухгалтеры. Потом все нарастающая стандартизация аппаратуры, платформенная независимость языков программирования, и вдруг — хоп! Программисты остались в меньшинстве, железо стало дешевым, а одну и ту же программу можно, хвала Юниксам, если не запустить, то уж собрать почти на любой платформе. Собственно, исчезли основные предпосылки существования опенсорса, имевшие место в 60-е и 70-е.

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

1. Интерес. Людям просто нравится творить. Но так как большинство программистов — не бизнесмены, и не способны продать свои творения, они их просто раздают. Впрочем, есть и идейные, которые раздают из принципиальных соображений.
2. Известность. Open source очень демократичен. Напиши хорошую программу, которой будут пользоваться миллионы, — и интерес к тебе со стороны работодателей сразу повысится. Собственные разработки с открытыми исходниками служат отличной заменой традиционным резюме: просмотрев исходники программы и историю ее разработки, можно гораздо больше узнать о разработчике, чем в ходе получасового собеседования.
3. Работодатель за это платит.

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

1. Код с открытыми исходниками не является самодостаточной программой, а представляет собой некую библиотеку или фреймворк, являющиеся побочным продуктом при разработке чего-то большего. Исходники открываются, как правило, из рекламных соображений. Прибыль косвенная.
2. Компания активно использует свой же продукт с открытыми исходниками в своих разработках. Очевидно, что основная прибыль получается другими путями, а открытие исходников — просто жест доброй воли или, опять-таки, реклама. Прибыль снова косвенная.
3. Мифическая «техподдержка», о которой будет твердить не слишком подкованный апологет open source, объясняя, откуда у опенсорсников деньги берутся. Этот путь получения дохода имеет смысл разве что для крупных компаний вроде Rad Hat или Microsoft, которые могут поставлять настолько большие и сложные продукты, что для них может потребоваться обучение специалистов и поддержка (платные, разумеется).
4. Open source, вообще говоря, ничуть не противоречит коммерческому софту. Поэтому можно путем хитрого лицензирования требовать с клиентов денег, если продукт с открытыми исходниками используется в коммерческих разработках (вспомним Qt как хрестоматийный пример).
5. Научные гранты.
6. Всякие маргинальные способы вроде пожертвований или встраивания рекламы в пользовательский интерфейс (фуу).

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

Программистов, которые могут себе позволить и хотят заниматься разработкой открытого софта, подавляющее меньшинство. Качественный открытый софт убивает конкуренцию (и, в некотором смысле, прогресс) среди закрытого коммерческого софта. То есть, если разработана некоторая открытая программа, то вероятность появления успешной аналогичной (или даже чуть более функциональной) закрытой коммерческой программы исчезающе мала (пример — браузеры). Да и открытой, в общем-то, тоже. Выходит, что open source замедляет прогресс!

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

1. Я написал научную статью и выложил ее в открытый доступ. Это ускоряет развитие науки, так как другие ученые могут опираться на мои результаты.
2. Я написал библиотеку нечеткой логики и открыл ее исходники. Это ускоряет прогресс программирования, так как остальные разработчики могут сэкономить свое время, если им понадобятся такие функции. Если им нужно внести какие-то изменения, они берут и вносят. Здесь важно, чтобы лицензия открытого кода позволяла любое его использование, в том числе коммерческое.
3. Я написал редактор UML-диаграмм и раздаю его бесплатно. Это помогает другим разработчикам в их работе. Конечно, это убивает конкуренцию среди платных редакторов UML, но в целом служит прогрессу программирования.
4. У меня бессонница, поэтому я год ночами писал программу управления личными финансами, а так как мне лень заниматься продажами, то я раздаю эту программу бесплатно. Если программа удобная, то платные уже покупать никто не будет, даже если они немножко лучше. Конкуренцию теперь может составить только более функциональная бесплатная программа.

Итак, моя позиция по поводу всего вышеобозначенного:

• информация должна быть открытой;
• средства разработки и научные инструменты должны быть бесплатны и, возможно, открыты;
• остальные программы не должны быть бесплатными (но могут быть открытыми);
• тем не менее, если уже есть хороший открытый/бесплатный софт, то глупо было бы им не пользоваться.

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

Где купил — не скажу :)

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

Я так просто не сдался и продолжил эксперимент. Пошел на CiteSeerX и нашел там общедоступную статью, которую и залил на CiteULike (кстати, шикарнейшая фича — автоматический экспорт библиографических данных с CiteSeerX и других подобных сайтов). Теперь у копирастов не было повода. Но через час статья все равно исчезла.

Было особенно обидно, что исчезновение не сопровождалось никакими спецэффектами вроде клубов дыма, воя сирен или хотя бы надписи в профиле «статья такая-то удалена». Я согласен даже на отсутствие объяснения причин (это позволяет предположить, что я чего-то недопонял), но какое-то уведомление должно быть! Нет, раздел «Library» нагло врет: «You haven’t added any articles to your library yet».

Еще одна статья, закинутая в порыве последней надежды, сумела пережить ночь, после чего отправилась вслед за своими почившими товарищами. Черная дыра прям, даже заходить теперь туда страшно. Вдруг и меня засосет? И не останется от меня ничего, только надпись у жены в паспорте: «You haven’t married any man yet». Стивен Кинг отдыхает.

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

Другое преступление, не менее тяжелое, — молчание в экстренной ситуации. Большая удача, что стерлись первые же добавленные статьи. А что если бы я туда напихал 400 статей, а потом некоторые из них взяли бы и исчезли? Я мог не заметить потери важной информации. Замалчивание таких случаев исключает возможность доверия. Подвел сейчас — значит, может подвести и потом.

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

С одной стороны, в иерархической структуре вроде дерева каталогов расположить все мои источники просто невозможно. Например, гипотетическая статья о моделировании протокола TCP относится сразу к нескольким категориям, скажем, «моделирование» и «TCP». Это теговый подход, и возможность хранить такие пометки и осуществлять по ним поиск уже была бы большим подспорьем. Еще лучше, чтобы система категорий/тегов была иерархической, чтобы можно было пометить статью тегами «моделирование%имитационное моделирование» и «передача данных%сетевые протоколы%стек TCP/IP%TCP». В принципе, это реализуемо с помощью ссылок, но, во-первых, это муторно, а во-вторых, у ссылок предостаточно ограничений. В будущем этим должны будут заниматься теговые ФС, но сейчас этот вариант не подходит.

С другой стороны, помимо семантических меток, прикрепленных к источнику, хотелось бы еще хранить и некоторую дополнительную информацию:

• статус (прочитано/срочно прочитать/просмотреть и забыть);
• библиографические данные, желательно с возможностью автоматического экспорта в BibTeX;
• любая другая присоединенная информация, например, конспект, ссылка на сайт издательства или просто какие-то заметки.

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

• теги таки не иерархические;
• при экспорте в BibTeX добавляются мусорные поля вроде citeulike-article-id и priority, которые, впрочем, несложно вычистить;
• много всякой лишней ерунды, загромождающей интерфейс (явно не обошлось без feature creature);
• существующую локальную библиотеку статей переносить туда придется долго и с трудом; настольная программа могла бы большую часть работы сделать самостоятельно, пройдя по иерархии каталогов и индексируя файлы.

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

UPD: прежде чем пользоваться CiteULike, ознакомьтесь со следующим постом. Редакция изменила свое мнение.

С точки зрения пользователя:

• Windows неэффективен и негибок (хотя многие об этом не подозревают);
• Linux сложен в настройке и нестабилен (хотя многие это отрицают).

С точки зрения разработчика:

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

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

Вот что нужно принимать во внимание при выборе:

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

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

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

Например, я считаю неправильным курс Linux на доступность для «домохозяек». У него была своя замечательная ниша: ОС для бородатых гиков, да и еще неплохо подходил для серверных приложений. Были толпы высококвалифицированных фанатов. Теперь же эти толпы фанатов решили навязать свое мнение всему миру. В результате ядро распухло и мешает при ходьбе. Реинкарнация DLL Hell. Квалификация фанатов упала. Появилась куча клонов Windows-приложений, которые работают чуть-чуть не так, как надо. Зато опенсорс, да.

С Windows тоже беда, но обратная. Microsoft случайно сделал идеальную ОС для обычных пользователей: Windows XP. Дальнейшие дерганья только подтверждают неизбежное: все уже написано. Пользователи хотят чего-то нового, но новое от Microsoft подозрительно напоминает старое. Чем успешно пользуется Apple, который принципиально ничего нового не делает, но зато делает не так, как Microsoft, чем и привлекает уставших от пятнадцати лет унылого интерфейса пользователей. Зато уж средства разработки Microsoft как блины печет: уже вон .NET 4 выходит. Несчастные разработчики в мыле корпят днями и ночами над книгами и мануалами, чтобы потом, прочитав последнюю страницу, обнаружить, что за это время вышло еще два фреймворка и три языка, и что они теперь мейнстрим. Утрирую, конечно, но скорость превращения версий дотнетов в legacy многих пугает (и я среди них).

Короче, смотрите на свои потребности и думайте головой. Идеальной ОС нет. Linux ужасный. Windows отвратительный. MacOS дурацкий.

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

Сегодня прихожу на работу, открываю ту же презентацию, и… Иду пить чай. Отклика от интерфейса нет вообще. Смотрю в top — за звание самого прожорливого процесса борются simpress.bin и convert. Последний, очевидно, что-то делал со встроенными в презентацию картинками в формате EPS. Наверное, преобразовывал в какой-то свой внутренний формат. Ладно, минуты 4 попреобразовывал и перестал.

Но вот процесс simpress.bin после этого решил, что он теперь тут главный и ему все можно. Минут через пять интерфейс, наконец, начал неторопливо отвечать на мои действия. Все это время загрузка процессора одним этим процессом держалась на уровне 95%. Еще минут через пять тормоза почти окончательно пропали. Но стоит только просто поелозить колесиком мышки, как Impress тут же начинает жрать 20–40%. И основательно тормозит при любом редактировании. Xorg тоже хорош — глядя на Impress, выдает до 40% при прокрутке слайдов. Они что думают, я их за ушком чешу?.. Откуда такая гипервозбудимость?

Нет, правда, может кто-то знает? Уж очень не хочется для подготовки презентаций загружать винду.

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

1. личные психологические: поругался с собакой, увидел результаты выборов, вспомнил про кредит за квартиру;
2. физические: хочется есть, не выспался, текут сопли, оторваны конечности;
3. связанные с условиями работы: начальник идиот, зарплата маленькая, коллеги весь день отвлекают, сверхурочная работа;
4. связанные с самой работой: работа слишком простая или слишком сложная, закончен один проект и надо начинать другой, начальство навязывает пути решения, ваще неинтересная работа, нет идей;
5. ни с чем не связанные: просто тупо не хочется ничего делать.

Составляя этот список, я немного сжульничал. Поэтому, пользуясь подходом доктора Х., сразу должен заявить, что если ваш кризис подходит под пункт 5, то вы врете. Не бывает беспричинных кризисов. Состояние «просто не хочется работать» говорит о том, что вы просто боитесь копаться в себе достаточно глубоко, чтобы выяснить истинную причину.

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

Терапия, таким образом, заключается в следующем:

1. уменьшить количество и силу демотивирующих воздействий;
2. увеличить количество и силу мотивирующих воздействий.

Никакой rocket science, как нетрудно видеть. Теперь перейдем к конкретным рецептам.

Если у вас личные психологические причины, то искренне сочувствую. «Тяжелые думы» норовят постоянно занимать мыслительные ресурсы, да и настроение снижают. Мощный демотиватор. Однако если насильно погрузить себя на некоторое время в работу и пресекать попытки отвлекаться, то обычно через некоторое время весь негатив уходит: ему просто не хватает места в голове.

Физические причины нужно просто устранить. Тут и говорить не о чем.

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

1. начальник идиот;
2. начальник вас понимает, но не в силах помочь (денег нет, директор не разрешает);
3. вы занимаетесь не той работой, которой хотели бы заниматься.

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

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

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

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

• При малейших признаках состояния «влом работать» немедленно сменить занятие на другое, но имеющее отношение к работе — мозг должен продолжать находиться в рабочем режиме. Я обычно в таком случае начинаю читать какую-нибудь книжку по программированию. Через некоторое время надо попробовать вернуться к исходной деятельности.
• Интерес к работе можно подогреть искусственно. Например, сообщить начальнику, что вечером сдашь работу, на которую планировалась неделя. Или начать обсуждать рабочие вопросы с коллегами. Иными словами, своими силами создать окружение, которое потом начинает само тебя подталкивать.
• Если череда бессмысленных занятий таки сумела затянуть, нужно, как только это осознаешь, сразу же покинуть рабочее место. Походить по коридору, посмотреть в окно. В процессе этого выбрать следующее рабочее действие, после чего тигром броситься на свое место и начать выполнять задуманное. Мозг, пребывая в шоке от таких стремительных событий, соглашается работать.
• Убрать с рабочего места все, на что не относится к текущей работе. Просто диву даешься, насколько незначительные на первый взгляд вещи могут пожирать внимание и время. Например, у меня на столе лежала книга задней обложкой вверх; там была напечатана ее аннотация. Однажды я осознал, что помню эту аннотацию наизусть. Стал за собой следить и выяснил, что непроизвольно, в задумчивости, читаю ее несколько раз в день, причем после каждого прочтения взгляд соскальзывает в сторону, на другие книжки, потом на разбросанные статьи, потом на рукописные записи, а потом уже начинают всплывать какие-то воспоминания, обрывки старых идей… Если при этом я еще и не слишком хочу работать, то затягивает надолго.
• Заниматься посторонними делами нужно на мотивационном максимуме. Например, вам пришла в голову замечательная идея, и сразу зачесались руки ее воплотить. Вот это то самое время, когда можно пообедать, выпить чаю, сходить в туалет и т.д. Во-первых, в это время можно более тщательно обдумать идею. Во-вторых, вы вернетесь к работе с подъемом и желанием свернуть горы. Малозаметное, но важное следствие: не стоит стремиться доделать работу к концу дня. Лучше оставить небольшую и несложную часть на завтра, чтобы с утра недоделанная работа послужила «трамплином» для вхождения в поток.
• Стараться не составлять распорядок дня, как бы это парадоксально ни звучало. Назначенные на определенное время события (обед в 13:00, чай в 17:00, уход с работы в 19:00) создают перед собой кризисные зоны размером до полутора часов. Скажем, вы заканчиваете некоторый этап работы за 5 минут до обеда. Будете ли вы начинать следующий этап? Скорее всего, нет. А если закончите за 10 минут? За полчаса? Думаю, идея понятна.

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

Но сейчас хочу поделиться впечатлениями от языка m4, который я внезапно выучил. Поскольку я тут понемногу готовлю мегапост (а скорее даже статью) про Autotools, то неизбежно заинтересовался, что это за странный язык m4, на котором написан Autoconf. Оказалось, на сайте GNU есть вполне приличный мануал по этому поводу. Есть даже чуть менее приличный мануал на русском.

История m4 уходит в глубину веков. Сначала появился макроязык GPM, аж в 1965 году. Потом Деннис Ричи, основательно перекроив GPM под нужды реального мира, написал m3. Затем к Ричи присоединился Керниган. Но ведь все знают, что когда Керниган и Ричи собираются вместе, обязательно выходит какая-нибудь нетленка. И вот эти два достойных мужа в едином порыве создают в 1977 году язык m4 (имя расшифровывается по аналогии с i18n и l10n). А уже в 1990 году появилась GNUтая версия. С тех пор мало что изменилось, разве что скорость выполнения немного подросла.

Мое знакомство с макроязыками ограничивалось до сих пор соответствующими средствами MASM на втором курсе института, да препроцессором языка C (который макроязыком может назвать только большой оптимист). К сишному препроцессору у меня была только одна претензия: на нем нельзя написать цикл. Представляете, как мне мало нужно было для счастья? Поэтому осилив за 5 часов чистого времени мануал по m4, я впал в состояние прострации и глубочайшего культурного шока. Язык не был похож ни на что известное мне до этого.

По мере чтения мануала я проходил следующие стадии:

1. Ммм, интересно как!
2. Сложно, блин. Черт, как же этот пример работает?..
3. Определенно, язык писали идиоты для дебилов!
4. Аааа, у меня в мозгу кавычки! Вытащите их!!!
5. Понял! Да тут же все просто!
6. Пожалуй, напишу на m4 генерацию документации для нашего проекта, а потом еще напишу парсер файлов определения локалей, а еще напишу…

На последней стадии нахожусь до сих пор. Рациональных объяснений этому не нахожу. Зато понял, что автор мануала не шутил, написав в самом начале:

Some people find m4 to be fairly addictive. They first use m4 for simple problems, then take bigger and bigger challenges, learning how to write complex sets of m4 macros along the way. Once really addicted, users pursue writing of sophisticated m4 applications even to solve simple problems, devoting more time debugging their m4 scripts than doing real work. Beware that m4 may be dangerous for the health of compulsive programmers.

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

define(`quote', `ifelse(`$#', `0', `', ``$*'')')dnl
define(`foreach',
  `_args(`$0', `$#', 3)
   foreach1($1, $2, $3)'
)
define(`arg1', `$1')
define(`foreach1',
  `ifelse(
      quote($3), `',
      `',
      `define(`$1', `arg1($3)')$2`'$0(`$1', `$2', shift(shift(shift($@))))'
    )'
)

Ага, это именно то, о чем вы подумали. Цикл foreach, построенный на примитивах define, ifelse и рекурсии. Почти как в Lisp.

Да, синтаксис не блещет изяществом. Кроме того, программа не делится на строки; конец строки воспринимается буквально и попадает в порожденный текст (кроме определенных случаев). Но зато язык в действительности очень простой. В нем очень мало встроенных средств, дай бог наберется три десятка встроенных макросов. Но, как и любой язык с малым количеством базисных элементов, m4 требует определенной умственной акробатики при написании сложных конструкций. А свободное восприятие открывающих и закрывающих кавычек и нумерованных переменных a la Perl/bash/PHP — вопрос пары дней практики.

m4 на удивление непопулярен. В крупных проектах, за исключением Autoconf, замечен не был (UPD: еще sendmail, спасибо Юрию). Может быть, есть какие-то другие порождающие языки, намного красивее и удобнее? Пока же я вижу, что m4 очень простое и мощное средство, позволяющее сэкономить массу сил (масса сил… хм). Еще одно преимущество — m4 есть везде, где есть Autoconf, а это практически все *nix-системы.

Если интересно, могу развить тему и написать небольшое руководство.

Начал почитывать легендарный MIT-овский курс — Structure and Interpretation of Computer Programs. И, соответственно, понемногу делаю оттуда упражнения. Эти упражнения некоторым так нравятся, что они аж целый сайт забабахали с решениями. Не для неосиливших, ни в коем случае! Исключительно для самопроверки.

Пока терзаю первую главу и должен признаться, что если бы нас так учили на первом курсе (а в MIT эту книгу проходят как раз на первом курсе, хотя и не всю), то я бы сейчас был мегазвездой программирования. Хотя теперь уже я для себя в SICP новой информации почти не нахожу, но все же есть ощущение «в первый раз в первый класс». Примерно как у средневекового алхимика, попавшего на школьный урок химии: вроде бы он всю жизнь точно так же смешивал жидкости, но все-таки чего то не хватало для полного понимания того, что при этом происходит. Он, конечно, может начать вопить что-то вроде «Я тут самый умный, да вы жизни не видели, да я свинец в золото тоннами, да я…» (легкий такой намек на «гениальных русских программистов», которые «и так все знают»), но учительница подойдет, треснет указкой по макушке и ласково объяснит, как на самом деле все в жизни обстоит.

Вот и в SICP есть то самое «что-то». Без характерного для «чайниковских» книг сюсюканья, без излишнего усложнения (для первокурсников все же пишут), сложные вещи объясняются простыми словами. После прочтения неизменно наступает просветление. У меня даже возникло было неожиданное желание начать писать конспект. Но лень и здравый смысл победили.

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

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

Системы реального времени — вообще штука непростая, скажу вам как имеющий к этому делу отношение. А уж мобильное (portable) программирование СРВ — и вовсе высший пилотаж. Хотя бы потому, что мобильность приложений реального времени сродни Неуловимому Джо. Обычно, когда разрабатывается СРВ, софт пишется под конкретную железяку (или уж по меньшей мере под конкретную ОС), на ней же тестируется, и если работает, то его стараются больше не трогать. Переносить уже написанную управляющую программу на другое железо вряд ли кому-то придет в голову. Тем не менее, POSIX имеет определенные средства для написания программ реального времени, и даже позволяет относительно легко написанное потом переносить.

Посмотрим, что нам в этой книге предложено:

• потоки управления и средства их синхронизации;
• сигналы реального времени, часы, таймеры;
• очереди сообщений, семафоры, разделяемая память;
• файлы, отображаемые в память, типизированная память, удержание страниц в памяти;
• приоритетное планирование;
• асинхронный ввод-вывод;
• рекомендательные интерфейсы;
• трассировка приложений (не путать с пошаговой отладкой!);
• технологические (прикладные) интерфейсы.

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

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

Для общего развития вряд ли стоит читать такую книгу, но специалистам по POSIX-программированию однозначно must have. Правда, тираж совершенно мизерный, так что есть вероятность, что в продаже уже не найдешь. Читайте онлайновый курс, там то же самое.

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

UPD. Научился.

• чтобы из символа десятичной цифры получить ее численное значение, достаточно взять младшие 4 бита ASCII-кода этой цифры;
• чтобы получить порядковый номер буквы латинского алфавита (неважно, в верхнем или нижнем регистре), достаточно взять младшие 5 бит ASCII-кода этой буквы;
• чтобы перевести латинскую букву из нижнего регистра в верхний, достаточно установить 6-й бит (со смещением 5) ASCII-представления буквы в 1 (обратная операция выполняется по аналогии, сбросом этого бита).

Первые два факта я не знал.

На забывайте указывать вид лицензии, когда публикуете свое открытое ПО!

Итак, язык программирования — это инструмент, с помощью которого создаются программы (да, я сегодня за К.О.). Как и всякий инструмент, он характерен тем, что:

• предназначен для решения определенного круга задач;
• имеет некое соотношение «удобство — сложность освоения — производительность труда — качество продукта».

Круг задач, решаемых с помощью инструмента, не является четко очерченным. Штыковая лопата замечательно подходит для изготовления небольших ям. Еще ей можно недурственно раскроить чей-то череп. Можно косить ею траву. Саперную лопатку можно метать на небольшие расстояния. При достаточном желании можно даже лопатой играть в большой теннис. Но все же первичная область использования, в которой лопата раскрывает свои лучшие качества, — копание ям.

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

Ладно, хватит аналогий.

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

• время на изучение языка до определенного уровня = константа 0;
• удобство использования = (константа 1 для данного класса задач и языка)*sqrt(уровень владения);
• производительность труда = (константа 2 для данного класса задач и языка)*sqrt(уровень владения);
• качество результата = (константа 3 для данного класса задач и языка)*sqrt(уровень владения);
• прочие параметры по аналогии.

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

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

• системное программирование: ассемблеры, C, C++;
• высокопроизводительные вычисления: ассемблеры, C, C++;
• параллельные вычисления: C, C++, Erlang, C#, …;
• веб-приложения: PHP, Perl, Python, Java, Ruby, JavaScript;
• корпоративные приложения: C#, Java;
• массовые настольные приложения: C++, C#, Delphi;
• игры: С, С++, ActionScript, …;
• вспомогательные и встраиваемые сценарии: bash, Perl, Python, TCL, Lua, …

Этот список я брал более-менее из головы, но, думаю, недалеко ушел от истины.

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

Хорошим примером такой связки может быть Python+C. Они оба в плане синтаксиса несложные, но при этом первый имеет мощную библиотечную поддержку, но нетороплив, а второй позволяет выжать из компьютера все соки, но писать на нем большие программы — та еще радость (хотя опенсорсники придерживаются иного мнения). На таком тандеме можно написать почти все что угодно. На Python — GUI и основную логику, на C — низкоуровневую реализацию. Бхай-бхай.

Другой вариант — путь обобщения. Будут развиваться универсальные языки, которые обеспечит разумный компромисс между упомянутыми выше константами. Это может быть C++0x, ускоренный Python, упрощенный Perl или даже потихоньку всплывающий из пучин и обещающий всех порвать Haskell. C# — сомневаюсь. LINQ и вообще стремление к декларативщине — хорошее направление, но будет непросто преодолеть стереотип C# → Microsoft → отсутствие кроссплатформенности.

Этот вариант плох тем, что, как ни крути, специализированный язык в своей области эффективнее универсального.

Какой путь выбрать? А хрен его знает. Решайте сами.

• C Elements of Style — сокращенный вариант старой доброй книжки лохматого года; слегка устарела, но все равно содержит массу полезного;
• Learning GNU C — туториал про одноименный диалект C;
• An Introduction to GCC — руководство по gcc и g++;
• C FAQ — огромный FAQ по языку;
• Writing Bug-free C Code — оригинальная методология программирования на C с элементами ООП, позволяющая вроде бы упростить обнаружение ошибок; почитать интересно, но применять стремно;
• The GNU C Library — мануал по стандартной библиотеке C в исполнении GNU;
• Top 10 Ways to be Screwed by C — топ 10 сишных граблей; будет особенно полезно начинающим;
• (UPD) Programming in C — курс лекций по С с упором на UNIX-среду;
• (UPD) C Traps and Pitfalls — статья про скользкие места C;
• (UPD) Notes on Writing Portable Programs in C — статья про написание переносимых программ на C; категорически рекомендую;
• (UPD) Indian Hill: Recommended C Style and Coding Standards — рекомендации по стилю C-программ от ребят из одной лаборатории AT&T.

Интересные ссылки из комментов переносятся в основной пост, так что пишите.

1. Получает/захватывает/выделяет необходимые для работы ресурсы.
2. Выполняет содержательные действия.
3. Освобождает ресурсы.

На каждом из предыдущих этапов вдобавок должно выполняться обнаружение и обработка ошибок. И вот здесь-то и начинается самое интересное. Казалось бы, нет ничего сложного. Ну, обнаружили ошибку. Ну, обработали. В чем проблема-то? А проблема в деталях. Могут иметь место такие, например, случаи:

1. Функция получает не один ресурс, а N. Соответственно, все полученные ресурсы нужно освободить. А если при получении i-го ресурса произошла ошибка, то нужно освободить только ресурсы 0…i-1.
2. Если в содержательных действиях происходит ошибка, то перед освобождением ресурсов может понадобиться эту ошибку как-то обработать. Хорошо если такая ошибка может возникнуть только в одном месте — прямо там и обработаем. А что если в разных местах могут возникнуть ошибки, требующие одинаковой обработки? Еще после возникновения ошибки надо как-то покинуть содержательный код.
3. Если ошибка происходит в цикле со вложенностью 2 и более, то надо как-то все эти циклы покинуть.
4. Будем предполагать, что обработка ошибки не ограничивается возвратом кода ошибки, а включает какую-то более сложную обработку: запись в лог, выдача сообщений и т.п.

А еще мы хотим, чтобы наш код нормально читался, быстро работал и был пригоден для дальнейшего расширения. Такие вот мы противоречивые. Что делать будем? Есть несколько вариантов.

Вариант 0, «тупой»

Что думаю, то и пишу.

int function(...) {
    // ...здесь объявления переменных...
    if (get_res1(&res1))
        return ERROR1;
    if (get_res2(&res2)) {
        release_res1(&res1);
        return ERROR2;
    {
    // ...
    if (get_res25(&res25)) {
        release_res1(&res1);
        release_res2(&res2);
        // ...
        release_res24(&res24);
    }
    // ...какой-то содержательный код...
    // ...ошибка!
    if (error) {
        release_res1(&res1);
        release_res2(&res2);
        // ...
        release_res25(&res25);
        return SOME_ERROR;
    }
 
    release_res1(&res1);
    release_res2(&res2);
    // ...
    release_res25(&res25);
 
    return 0;
}

Плюсы: не обнаружены.

Минусы:

• массовое дублирование кода; чем больше ресурсов, тем больше дублирования;
• выход из функции в различных точках;
• ужасно читается;
• большие затраты на модификацию.

Вариант 1, «правильный»

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

int function(...) {
    struct data data;
    int r_code;
 
    r_code = get_resources(&data);
    if (!r_code) do_work(&data);
    if (r_code) handle_error(r_code, &data);
    release_resources(&data);
 
    return r_code;
}

Что там делают функции get_resources(), do_work(), handle_error() и release_resources() — нам неинтересно. Конечно, приведенный выше код — всего лишь демонстрация идеи. Очевидно, если все функции писать в таком духе, то до нижнего уровня, который, собственно, и делает фактическую работу, мы никогда не дойдем. Так и погрязнем в бесконечных слоях абстракций. Поэтому вместо do_work() обычно пишется компактный код, выполняющий требуемую работу, но без излишнего углубления в детали.

Плюсы:

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

Минусы:

• относительно низкая эффективность;
• наличие синтетической структуры данных (struct data), хранящей состояние ресурсов.

Вариант 2, «тру-хакерский»

Настоящие хакеры не боятся goto. Настоящие хакеры плевать хотели на предрассудки. Мнение о вредности goto было специально распространено ими среди начинающих; goto в коде хакера — как катана в руках самурая: новичок может покалечить себя, а мастер — всех остальных.

int function(...) {
    // ...здесь объявления переменных...
 
    if (get_res1(&res1)) {
        ret = ERROR1;
        goto exit;
    }
    if (get_res2(&res2)) {
        ret = ERROR2;
        goto exit1;
    }
    // ...
    if (get_res25(&res25)) {
        ret = ERROR25;
        goto exit24;
    }
    // ...какой-то содержательный код...
    // ...ошибка!
    if (error) {
        ret = SOME_ERROR;
        goto error;
    }
    // ...
    goto exitOK;
 
error:
    // ...
 
exitOK:
    release_res25(&res25);
exit24:
    release_res24(&res24);
// ...
exit2:
    release_res2(&res2);
exit1:
    release_res1(&res1);
exit:
    return ret;
}

Идея схожа с предыдущим вариантом: локализовать места обработки ошибок и освобождения ресурсов. За счет fallthrough-стиля освобождение происходит очень изящно. Главная проблема при использовании goto для обработки ошибок и освобождения ресурсов — соблюдать меру. Не зря ведь в моем примере 25 ресурсов: в случае использования варианта №1 размер кода не зависит от их количества, здесь же мы получаем спагетти. Использование goto позволяет сократить код по сравнению с вариантом №0, но таит в себе опасность бесконечного увеличения размера функции, так как возможности рефакторинга здесь ограничены.

Такой подход можно встретить, например, в ядрах Linux и FreeBSD.

Плюсы:

• неплохая читабельность при аккуратной реализации;
• высокая эффективность;
• одна точка выхода.

Минусы:

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

Вариант 3, «gotoфобский»

Еще один вариант, также часто встречающийся в реальном коде, — использование цикла в качестве конструкции, ограничивающей «зону безошибочного выполнения», и оператора break в качестве аналога goto из предыдущего варианта.

int function(...) {
    // ...здесь объявления переменных...
 
    do {
        if (get_res1(&res1)) {
            ret = ERROR1;
            break;
        }
        if (get_res2(&res2)) {
            ret = ERROR2;
            break;
        }
        // ...
        if (get_res25(&res25)) {
            ret = ERROR25;
            break;
        }
        // ...какой-то содержательный код...
        // ...ошибка!
        if (error) {
            ret = SOME_ERROR;
            break;
        }
        // ...
    } while(0);
 
    if (ret)
        ret = handle_error(ret, ...);
 
    if (res1_allocated(&res1))
        release_res1(&res1);
    if (res2_allocated(&res2))
        release_res2(&res2);
    // ...
    if (res25_allocated(&res25))
        release_res25(&res25);
 
    return ret;
}

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

Плюсы:

• отсутствует goto;
• слабая связность фрагментов функции, хорошо поддается рефакторингу;
• одна точка выхода.

Минусы:

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

Итого

Конечно, можно придумать еще мульён вариантов, один другого краше. Есть даже отдельная когорта любителей «метапрограммирования» (тыц, тыц). Я такие вещи не понимаю и не одобряю. Если уж есть такая тяга к синтаксису try-catch, то почему бы не пользоваться C++? В подавляющем большинстве случаев нет причины, которая позволяла бы пользоваться C, но исключала возможность использования C++ (хотя у меня именно такой редкий случай).

Чем же пользоваться? Мое мнение такое:

• всегда писать согласно варианту 1;
• если в результате работает слишком медленно, переписать отдельные функции (или даже модули) по варианту 2.

Жду гневные, но конструктивные комментарии.

Всем срочно sudo drink !

Давным-давно жили-были Программисты. Были они умные, знали дофига чего такого, что обычным людям ни в жисть не понять, и было их мало. Оттого спросом они пользовались необычайным, зарабатывали кучу денег и вообще считались уважаемыми людьми. Еще были Пользователи, которые тоже умели программировать. Даже больше того, в то время собственно пользование компьютером заключалось в написании для него программ. Каждому Пользователю приходилось учить Фортран или Бейсик, иначе компьютер превращался просто в бесполезный предмет интерьера. Конечно, до уровня Программистов Пользователям было как пешком до Луны, потому что для Пользователя программирование было лишь инструментом, подспорьем в проведении необходимых вычислений и анализа, тогда как Программист занимался написанием программ профессионально. Короче говоря, было такое счастливое время, и все были довольны. Но Программисты все же были круче.

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

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

Софт

Но это только одна сторона. Если посмотреть на рынок ПО, то несложно заметить, что ничего нового на нем фактически не появляется. Были эпохальные продукты вроде Windows, Office, 1C Что-То-Там и тому подобных монстров, которые закрыли собой гигантские ниши. Все! Нужно просто признать: эпоха разработки массового софта заканчивается. Все, что нужно среднестатистическому пользователю, уже написано. Зачем же тогда Microsoft год за годом печет новые Офисы и Винды? Что, старые чем-то плохи? Нет! Просто им хочется кушать. Поэтому они развешивают тонны маркетинговой лапши на нежные юзерские уши, лишь бы только кто-нибудь купил их новый Офис. Который от N предыдущих версий отличается только по-другому расположенными кнопками и приведенной в соответствие с веяниями моды цветовой гаммой. Без сомнения, за это стоит отдавать триста баксов!

Конечно, я преувеличиваю. В мире есть еще что разрабатывать.

• Веб-приложения. Сейчас «программист» уже в головах обывателей является синонимом «веб-программиста». Только вот беда — вердикт «уже написано» все чаще звучит и здесь. Народ уже не знает, что бы такое написать, поэтому пишет всякую ерунду, благо процесс ее создания упростился невероятно. Операционная система в браузере? Не смешите.
• Корпоративный софт. Опять-таки, загибающаяся область. Один универсальный инструмент (1С, SAP) и толпа низкоквалифицированных адептов (1С-«программист», хо-хо) легко заменяет большинство корпоративок. Остаются лишь только всякие банки, авиаперевозчики и т.п., которые поступили мудро, придумав настолько сложные бизнес-процессы, что хрен напишешь обобщенный инструмент. А если поднапрячься и все же написать, получится VisualStudio.
• Специфический софт. Драйверы, управляющий софт, firmware. Пожалуй, здесь пока еще все нормально. Появляются новые железки и комплексы — должен появиться и софт для них, никуда не денешься.

Итого

У вменяемого читателя должен на этом месте возникнуть в голове диссонанс. Как так — писать больше нечего, а программисты все работают (и неплохо зарабатывают). Ничего удивительного. Программисты работают по инерции.

С одной стороны, компании все еще думают, что стоит только нанять программиста, как все проблемы исчезнут. Видимо, сказываются смутные воспоминания о золотом веке софтостроения в 90-х годах. А поскольку у нас в стране бизнес основан на связях и откатах, а не на грамотном управлении, то никто и не позаботился посчитать, действительно ли найм программистов за большие деньги приносит прибыль. Конечно, к софтверным компаниям (которые в данном случае выступают в роли этаких метапрограммистов) это не относится.

С другой стороны, программисты все еще считают себя самыми востребованными специалистами на свете и всячески это мнение поддерживают. Вместе с тем их профессионализм стремительно падает (см. выше), а самооценка столь же стремительно растет. «Российских Программистов» это касается в первую очередь. Г-н Медведев вон считает, что «наши программисты — самые программистые». А на деле выходит, что они (мы) сливаем по всем статьям западным коллегам, а денег хотим много.

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

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

Приходите через пять лет, проверим.

А пока Марк Пилгрим закончил работу над своей новой книгой — Dive Into Python 3. Написана приятным языком, с юмором, читается легко, примеры программ адекватные. Приятно, что по целой главе уделено блочному тестированию и рефакторингу. Да и вообще, очень жизненно излагает. Внушает, как говорил один персонаж из нашего демократического прошлого по имени Х. М.

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

This site is optimized for Lynx just because fuck you.
I’m told it also looks good in graphical browsers.

На этой оптимистичной ноте разрешите откланяться.

Есть еще один минус Eclipse из репов: почему-то у меня не работает встроенный менеджер плагинов. Через yum ставится, а через Eclipse нет. А еще у нас на работе умельцы написали обалденный плагин для удаленной отладки на нашем процессоре, но ставится он только на 3.5.

В результате я снес все подчистую, скачал с eclipse.org самую свежую версию, воспользовался замечательным репозиторием дополнений CloudSmith и счастье пришло.

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

А вы как отмечали 0×100-ый день в году?

Я предполагаю, что вы знакомы с понятиями «файловый дескриптор», «поток ввода (вывода)», «конвейер» и т.д., но просто никак не можете запомнить, как всем этим пользоваться. На самом деле все просто. Смотрите.

Команда перенаправления вывода позволяет все, что записывается в один файловый дескриптор (откуда), записать вместо этого в другой файловый дескриптор (куда):

откуда > куда

Что может быть на месте откуда:

• ничего: перенаправление из дескриптора 1 (stdout);
• i: перенаправление из дескриптора i;
• &: перенаправляются сразу stdout и stderr.

Что может быть на месте куда:

• &j: перенаправление в дескриптор j;
• имя файла: файл открывается в режиме записи, и перенаправление осуществляется в него.

Если используется оператор перенаправления >> (дописать в конец) вместо > (очистить и писать сначала), то куда может быть только именем файла.

Указываемый дескриптор не обязательно должен быть открыт. Номера с 3 по 9 можно использовать как «перевалочные пункты»; открытые файлы получают дескрипторы, начиная с 10.

Перенаправление ввода работает очень похоже:

куда < откуда

Теперь при чтении из куда на самом деле чтение будет происходить из откуда. Тут по сравнению с перенаправлением вывода все наоборот. Куда может быть пустым (stdin) или номером дескриптора. Заметьте, что символ & здесь уже не годится — нельзя читать из двух потоков сразу. Откуда может быть или вида &i, или именем файла, который при этом открывается для чтения.

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

ps -aF > myfile 2>&1

Здесь сначала stdout перенаправляется в файл, а затем stderr перенаправляется в stdout. В результате и stdout, и stderr перенаправляются в файл. Замечу, что перенаправление выполняется по порядку. То есть, такая команда будет работать по-другому:

ps -aF 2>&1 > myfile

Здесь stderr будет выведет на консоль. Правило простое: перенаправление происходит в текущую конечную точку перенаправления дескриптора (если не поняли, прочитайте предложение еще раз).

Еще один тонкий момент: как быть с конвейерами? Распространяется ли действие перенаправления на весь конвейер? Правила просты:

• перенаправление действует только на ту команду в конвейере, где оно задано;
• команда выдает в конвейер данные, выведенные в дескриптор 1 (с учетом перенаправлений);
• команда берет из конвейера данные, полученные из дескриптора 0 (с учетом перенаправлений).

Например, вот так можно перенаправить поток ошибок в конвейер:

ps -aF 3>&1 1>&2 2>&3 | grep something

Здесь stderr и stdout фактически меняются местами.

Конечно, можно много чего еще сказать по поводу перенаправления: про одновременное перенаправление и ввода, и вывода, про перенаправление блока команд, про перенаправление с помощью exec, про закрытие дескрипторов и т.д. Но тогда пост получится слишком объемным, и им неудобно будет пользоваться как справкой. Если у вас есть какие-то вопросы, готов ответить в комментариях. За найденные ошибки также буду признателен.

int i = 10;
while (i --> 0) // "оператор -->"
    foo();

Хотя его пост был про C#, но такая штука сработает практически во всех C-подобных языках. Я сразу вспомнил еще пару подобных забавных конструкций. Например, интересное определение макросов TRUE и FALSE:

#define TRUE ('/'/'/')
#define FALSE ('-'-'-')

или «оператор приведения к bool»:

int a = 0, b = 123;
a = !!a; // 0
b = !!b; // 1

А еще вот — логический XOR:

!a != !b

Очень вас прошу, не пользуйтесь в своем коде чем-либо подобным… Я уж и не говорю про примеры из книги «Алгоритмические трюки для программистов».

В Windows шрифтовым стандартом де-факто является True Type. В Linux за отображение шрифтов отвечает пакет freetype, который поддерживает кучу стандартов шрифтов, но вот нормальное отображение True Type в нем обычно отключено по юридическим соображениям. Поэтому, если просто отключить антиалиасинг, то шрифты будут четкими, но фантастически уродливыми (даже если взять виндовые).

Чтобы таки получить шрифты «как в Windows», мне достаточно было выполнить нехитрые действия:

1. Отключить штатное сглаживание и поставить экранное разрешение 96 dpi.
2. Перекомпилировать freetype, взяв его с http://www.freetype.org/ (желательно версию, которая сейчас установлена). При этом прочитать docs/TRUETYPE, в котором описаны необходимые действия, которые нужны для корректной обработки True Type (нужно раскомментировать одну строку в одном заголовочнике). Не забыть указать префикс (у меня /usr) при вызове ./configure.
3. Перезагрузить иксы.
4. Enjoy!

Минус только один: при обновлении freetype придется проделать действия заново.

Подробнее об этом процессе можно почитать здесь. Шрифты True Type можно взять тут.

Будут вопросы — обращайтесь. Баг-репорты приветствуются.

UPD. Теперь в комментариях отображаются юзерпики ЖЖ и Gravatar’ы.

Название:

Книгу мне подарил лично Владимир Антонович, поэтому я посчитал себя обязанным ее всю прочитать и поделиться впечатлениями с «уважаемым all».

Книга является дословным бумажным воплощением одноименного курса на Интуите. Так что все сказанное в равной степени справедливо и для оного курса.

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

Лично я теперь пользуюсь этим курсом как прекрасно откомментированным и снабженным примерами man’ом. Программирую, например, что-то связанное со взаимодействием процессов — сразу лезу в соответствующий раздел (кстати, книга в плане поиска нужного места гораздо удобнее онлайн-версии), читаю все подряд и дальше уже с полнейшей уверенностью пишу все как надо. Что выгодно отличает книгу от man’а, так это комплексная подача материала: описываются не отдельные функции, а их работа в контексте общей проблемы. Да еще и примеры достаточно объемные.

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

Существует еще и вторая часть книги, в которой рассказывается о «продвинутых» возможностях: потоки, средства реального времени, асинхронный ввод-вывод, трассировка и т.д. Уже взялся ее читать, ждите обзор.

Минусы:

• код набран слишком крупным шрифтом, ширины страницы часто не хватает, да и по вертикали на странице помещается мало строк.

Плюсы:

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

send(to, from, count)
	register short *to, *from;
	register count;
	{
		register n=(count+7)/8;
		switch(count%8){
		case 0:	do{	*to = *from++;
		case 7:		*to = *from++;
		case 6:		*to = *from++;
		case 5:		*to = *from++;
		case 4:		*to = *from++;
		case 3:		*to = *from++;
		case 2:		*to = *from++;
		case 1:		*to = *from++;
			}while(--n>0);
		}
	}

Такая конструкция предназначалась для раскрутки цикла копирования фрагмента памяти в регистр пословно. Развертывание сокращает количество итераций цикла и, как следствие, количество операций сравнения (в данном случае в 8 раз), тем самым слегка повышая производительность.

Чтобы лучше понять, что происходит, предлагаю читателям запустить следующую программу (я немного изменил изначальный вариант):

#include 
 
int c = 0;
int a = 10;
 
void foo()
{
    printf("%d ", c++);
}
 
void bar()
{
    printf("%d\n", a);
}
 
int main()
{
    switch (a&3) {
    case 0: do { foo(); bar();
    case 3:      foo(); bar();
    case 2:      foo(); bar();
    case 1:      foo(); bar();
	       } while((a -= 4) >= 0);
    }
    return 0;
}

Самое удивительное в этом всем — вовсе не корявое «столбчатое» форматирование. Удивительно то, что язык позволяет размещать цикл внутри блока switch. Интуитивно нам кажется, что каждый case начинает новый блок, и что нельзя соорудить блок, заключающий в себя несколько case’ов. А приведенный выше пример вообще представляется надругательством над синтаксисом C и здравым смыслом. Но стоит задуматься о том, как именно реализована конструкция switch-case, как сразу все становится на свои места:

// исходный код
switch (a) {
    case 0:
        a++;
        break;
    case 1:
        a--;
}
 
// что происходит на самом деле (примерно)
case_0:
    if (a == 1) goto case_1;
    a++;
    goto end;
case_1:
    a--;
end:

Вот так! Теперь понятно, что внутри конструкции switch можно развернуться от души, чем и не преминул воспользоваться Дафф.

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

Жаждущих подробностей отправляю к оригинальному сообщению Даффа и статье в Википедии.

• http://scintific.narod.ru/literature.htm — каталог научно-технических электронных библиотек (как русских, так и иностранных);
• http://nehudlit.ru — нехудожественная библиотека;
• http://www.eknigu.com — научно-техническая библиотека;
• http://www.iakovlev.org/index.html — некоторое количество книг и статей по Linux и программированию;
• http://www.ebook3000.com — буржуйские книги, преимущественно компьютерной тематики;
• http://www.netbks.com — научные и компьютерные книги, на английском;
• http://www.freebookcentre.net — очень много книг, в основном по CS и программированию;
• http://www.mccme.ru/free-books — свободно распространяемые книги по математике.

А откуда вы берете книги?

Первое — использовать шелловский for:

build:
    for epsfile in `ls *.eps`;\
    do\
        epstopdf $$epsfile;\
    done

Здесь две хитрости: экранирование концов строк (потому что for — фактически одна команда) и использование $$ перед именем переменной (потому что иначе она будет считаться макросом Make).

Второй способ использует возможности самого Make:

%.pdf: %.eps
    epstopdf $?
 
build: $(patsubst %.eps, %.pdf, $(wildcard *.eps))

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

К сожалению, все это не удастся сократить до такого:

build: $(wildcard *.eps)
    epstopdf $?

Здесь макрос $? развернется в строку, содержащую имена сразу всех EPS-файлов, что противоречит условию.

Про vi тоже интересно.

Не сказать чтобы мне это самое растягивание позарез как нужно, но после очередного обновления (у меня Fedora 11) моя статья перестала собираться, мотивируя это примерно так:

ERROR: pdfTeX error (font expansion): auto expansion is only possible with scalable fonts

Это загнало меня в тупик на несколько часов. Конечно, Гугль знает о такой проблеме. И в инструкции к microtype все подробно написано. Ответ очевиден: использовать масштабируемый шрифт. Проблема только в том, что используемый по умолчанию шрифт cmr из пакета cm-super очень даже масштабируемый. Лог сборки по этому поводу тоже не особенно внятен.

Решение нашлось практически случайно. Некая загадочная редиска закомментировала в файле updmap.cfg строки, содержащие «cm-super». Мне достаточно было раскомментировать строку (я использую кодировку T2A):

MixedMap cm-super-t2a.map

и выполнить

sudo updmap

Все заработало. За помощь в поимке редиски объявлено вознаграждение.

Посему я решил так. Писать буду чаще, но меньше. Буду выкладывать интересные ссылки, делиться приходящими в голову мыслями, больше писать о жизни «и вообще», но иногда публиковать и большие серьезные статьи. Например, у меня в черновиках лежат и ждут своей участи незаконченные посты:

• про формат ELF, его устройство и способы работы с ним;
• краткое введение в Autotools;
• плотная справочная статья про lex/flex;
• философские задвиги по поводу обработки ошибок в C;
• введение в Python;
• и еще куча всякой мелочи.

Все это я со временем приведу в порядок, проверю и опубликую. Не переключайтесь!

Note: There is a rating embedded within this post, please visit this post to rate it.

Название:

Концентрированный программистский здравый смысл. Разбавлять водой по вкусу и употреблять ежедневно.

Жаль, что человеческий мозг устроен так, что не может сразу принять прочитанное на веру и закрепить на уровне рефлексов. Для подавляющего большинства начинающих программистов знания, изложенные в книге, являются абсолютно необходимыми. Это тот минимум, после которого человек имеет право называть себя программистом. Когда я учился программировать, таких книжек не было, поэтому все «золотые правила» приходилось открывать самостоятельно. Трудно сказать, какой путь лучше. В книге все разложено по полочками и проверено электроникой. С другой стороны, ничто так не способствует выработке правильных навыков, как хождение по граблям.

«Ремесло программиста» освещает почти все практические аспекты профессиональной разработки, и в этом здорово похожа на «Совершенный код» Макконнела. Но если последний претендует на некоторую всеобъемлющность (во словечко!), то Гудлиф пишет о более приземленных вещах, и делает это как-то более живенько. Читать интересно, местами даже забавно.

Минусы:

• картинки с обезьянами — дурацкие;
• опытным программистам будет скучновато читать (хотя, пожалуй, так и должно быть).

Плюсы:

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

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

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

1. Пройти следом за пассажиром с билетом, прижавшись к нему якобы в порыве человеколюбия. Особенно этой уязвимости подвержены турникеты с двумя парами дверок: они не закрываются, пока не сработает сенсор «человек прошел». Ограничения на продолжительность открытия турникета, похоже, нет. Наверное, разработчики посчитали, что люди бывают разные, с большими животами и сумками. Или вдруг человек посреди турникета остановится и захочет постоять. Возникает же иногда такое желание — постоять в турникете. Правда ведь?
   В результате, зафиксированный мной рекорд — четыре человека прошли по одному билету гуськом.
2. Перепрыгнуть. Тут все ясно, хотя в случае четырехдверчатых экземпляров не каждому это под силу. Видел всего несколько раз.

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

О да, они не позволяют пройти гуськом (разве что двоим очень тощим). Зато с перепрыгиванием дело стало обстоять гораздо проще: преодолеть нужно всего лишь одну горизонтальную трубу. Но и это еще не все! Под таким турникетом легко подлезть! Какой удар для конструктора!

Потратили, стало быть, кучу денег, а толку? Не беда — денег еще много! И у турникетов появились крепкие ребята в камуфляже. Народ насторожился. Не каждый теперь рискнет проскочить зайцем — шанс получить по почкам от правоохранителей перевешивал стоимость билета. Но хитрость скоро раскрылась. Крепкие ребята в камуфляже оказались просто крепкими ребятами в камуфляже. При попытке безбилетно преодолеть турникет они лишь устало бубнят: «По одному проходим, по одному». Все вернулось на круги своя. Средства потрачены, безработица среди крепких парней, тетенек и конструкторов турникетов стремительно упала, народ продолжает экономить. Все довольны.

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

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

Надеюсь, вы не подумали, что этот пост про электрички и турникеты.

Note: There is a rating embedded within this post, please visit this post to rate it.

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

Интерфейс приятно минималистичен, но функционален. Конечно, многого не хватает (например, двух цветов все же маловато), но Ворктрек быстро развивается и, что особенно приятно, с учетом мнения пользователей. Что еще нужно хорошему инструменту? Пользуйтесь!

1. работа выполняется с отдельными файлами, не объединенными в проект;
2. узким местом производительности является именно ввод или редактирование текста, а не мыслительный процесс.

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

С проектами в Emacs все ужасно. Особенно с программными проектами. Есть мощнейшие режимы и модули, призванные сделать из текстового редактора полноценную IDE — etags, semantic, ecb, cedet, ede… Масса возможностей, множество путей расширения и настройки, но… Довольно быстро понимаешь, что это напоминает попытку Linux пробиться на десктопы домохозяек. Разработчики пыжатся, пытаются реализовать функциональность «больших» IDE, «догнать и перегнать», но выходит, что все это не повышает производительность, а снижает ее.

Я честно больше двух месяцев пытался настроить cedet и ecb под свои нужды, писал свои функции, часами рылся на емаксовых сайтах. Единственный положительный эффект — относительно неплохо выучил elisp, хотя многие сочтут это сомнительным достижением. Короче говоря, для проектов Emacs непригоден.

Поэтому я вернулся в Eclipse. И вскоре обнаружил там вот такое:

И правда, привязка базовых операций как в Emacs! Но моя радость была недолгой: мозг решительно воспротивился использованию привычных, казалось бы, комбинаций, в «некошерной» IDE. Я постоянно нажимал не туда, портил исходники, плевался и ругался. Кроме того, все мои любовно написанные elisp-функции и нестандартные привязки, понятное дело, в Eclipse не перетащишь. Поэтому я вернул все на место.

Теперь работаю в Eclipse. Комфорт разработки заметно вырос.

Note: There is a rating embedded within this post, please visit this post to rate it.

Название: Научные исследования: концептуальные, теоретические и практические аспекты
Авторы: Тихонов В. А. и Ворона В. А.
Год выхода: 2009
Издательство: Горячая линия — телеком
Тираж: 1000
Объем: 296 стр.
Обложка: мягкая
Где покупал: books.ru
Цена: 271 р

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

Как отличить исследование от не-исследования? Является ли некоторое исследование научным? Что должно входить в исследование, в какой последовательности нужно его выполнять, как оформлять результаты работы? Какие разделы должны входить в диссертацию и что в этих разделах писать? Как придумать название темы? Чем отличаются тема, объект, предмет, задачи и цели исследования? На все эти вопросы в книге приводятся более или менее ясные ответы.

Книгу мне привез курьер в институт, и когда я поднимался на лифте, встретился с сотрудницей отдела аспирантуры. Углядела она у меня эту книжку, и тут же отобрала. Вечером, правда, вернула. Но с условием, чтобы я еще две книжки заказал для общественного пользования. Потом с подачи отдела аспирантуры еще два человека ко мне пришли и попросили заказать. В общем, пиар-акция удалась на славу. А тираж-то небольшой…

В целом книжка неплохая, рекомендую. Но если у вас есть знакомые-аспиранты, вполне хватит одной на всех — перечитывать ее несколько раз вряд ли стоит.

Минусы:

• похожа на лоскутное одеяло: фрагменты книги явно писались разными авторами и в разное время (в том числе советское); встречается куча архаизмов («кибернетика», «вскрыть зависимости»); есть даже ссылки на Маркса и Энгельса;
• некоторые части совершенно в духе «космических кораблей, бороздящих просторы вселенной»; много воды; сделать бы книгу раза в четыре меньше — цены бы ей не было;
• верстка так себе, шрифт не очень приятен для глаз; много опечаток, пропущенных слов и несогласованных падежей;
• непонятно, зачем нужен материал про докторские диссертации; докторанты все изложенное и так уже должны знать;
• в середине книги обнаружен рекламный лист, причем не вложенный, а переплетенный вместе с остальными (убило наповал).

Плюсы:

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

Тогда основной моей осью была Windows 2003 Server. Удобная и надежная система, под которую драйверы и серьезные программы отказывались ставиться буквально через одного. Мол, у вас серверная ОС, мы вас боимся. Вдруг к нам придет ваш бородатый админ и будет ругаться? И вообще, купите лучше серверную версию нашего продукта втрое дороже. Или поставьте XP. Или пойдите еще куда-нибудь. Запуск установщика в режиме эмуляции XP иногда помогал, но чаще — нет. Это несколько напрягало, но обычно нужным программам находились альтернативы. С драйверами сложнее.

Вот и когда я распаковал шедевр коробочного искусства и извлек оттуда пресловутый космический девайс, со всей остротой встал вопрос — как заставить работать все эти 11 кнопок и 1 колесико? Фирменный SetPoint, увидев серверную винду, прикинулся шлангом, и припарки не помогли. Альтернатив этому поделию не предусмотрено. Впрочем, со временем я эту проблему решил (если кому будет интересно, расскажу как).

Затем я перешел на Linux. Собственно, я и не ожидал, что моя MX Revo будет нормально там работать. Две кнопки и колесико — что еще нужно настоящему программисту? Но Fedora 10 далеко превзошла мои ожидания, автоматически и правильно опознав 8 кнопок из 11. Единственное, что меня расстраивало — невозможность использовать вместо нажатия на центральное колесико нажатие на боковое псевдо-колесико (нажатие на центральное колесико у меня меняет режим вращения). Удобно, знаете ли, ссылки в Firefox открывать и вкладки закрывать.

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

С помощью xbindkeys, действительно, можно сопоставить команде оболочки некоторые нажатия мышиных и клавиатурных кнопок. Осталась самая малость — соответствующей командой оболочки сэмулировать нажатие второй кнопки мыши. Если верить документации на xvkbd, то это можно сделать так:

#~/.xbindkeysrc
"/usr/bin/xvkbd -xsendevent -text "\m2""
b:17

Проблема в том, что xvkbd не желает эмулировать мышиные клики. Что ж, незаменимых у нас нет. После непродолжительных поисков нахожу xdotool. Проверяю вручную, набрав в консоли:

xdotool click 2

Действительно, нажатие второй кнопки происходит. Теперь меняем ~/.xbindkeysrc:

#~/.xbindkeysrc
"~/bin/xdotool click 2"
b:17

Запустив xbindkeys в режиме отладки (ключ -v), вижу, что при нажатии на 17-ю кнопку (то самое псевдоколесико) действительно происходит эмуляция нажатия на 2-ю. Но видимого эффекта почему-то нет. Мистика. Подумав немного, решаю, что xdotool конфликтует c xbindkeys. Решение очевидно: разнести их по времени.

#~/.xbindkeysrc
"sleep 0.15; ~/bin/xdotool click 2"
b:17

Работает! Величина задержки подбирается экспериментально. У меня при 0.1 все еще есть конфликт, а при 0.15 — работает. Такая маленькая задержка практически не заметна, и неудобств не доставляет.

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

Есть такие люди, которые идут-идут своей тропинкой, посматривают по сторонам, и вдруг — бац! Наступают на грабли. Другие заранее замечают разложенный на дороге коварный садовый инвентарь, и обходят опасное место кустиками. Мой случай более интересен — я наступил в метафорическую кучу дерьма. И вместо того, чтобы обтереть ботинок листиком, я поперся в бурелом на поиски крана с водой, и уже там наступил на свои грабли. Причем несколько раз.

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

Компьютер внезапно перестал грузиться. Проходит POST, появляется надпись о попытке загрузить с CD — и тишина. Ни сообщений, ни воплей спикера — ничего. Ну, думаю, первичный загрузчик накрылся. Мелькнула у меня мысль вроде «А с чего бы он вдруг вот так взял и накрылся?», но симптомы были слишком очевидны. Достал с дальней полки установочный диск древней Slackware, загрузился. Смотрю — диск целый, таблица разделов в сохранности, сами разделы монтируются, fsck не ругается. Мистика просто: кто-то взял, и аккуратно так испортил начало MBR.

Ладно, зря что ли я писал свой загрузчик? Нахожу GRUB, командую ему «фас», он послушно пишет первую ступень в MBR. Перезагрузка. Тишина. Повторяем с другими настройками. То же самое. Через 20 минут я начинаю тихо закипать. Скачал Live CD Fedora 10 с ноутбука, может дело в версии GRUB?.. То же самое.

Тут вспоминаю, что вроде бы я делал бэкап первого сектора. Лезу в недра домашнего каталога — вот он, голубчик! Вооружившись dd, лихим кавалерийским наскоком переписываю резервную копию на диск. И когда уже палец опускался на Enter, я вспоминаю, что бэкап-то был от другого диска… Но поздно. Таблица разделов безвозвратно утеряна. Диск превратился в груду бессмысленных секторов.

Но не все потеряно! Есть же gpart — моя последняя надежда! Запускаю его на полное сканирование, вижу как он успешно находит раздел NTFS и со спокойной душой иду спать — работать он будет (по опыту) долго. Утром gpart показывает кашу из незнакомых мне разделов. «Не шмогла». Иду гуглить. Оказывается, есть еще одна подобная утилита – testdisk. Ставлю ее, запускаю сканирование. От силы через две секунды (!) она мне выдает правильный список разделов. Фууф, гора с плеч. Save. GRUB. Перезагрузка. Опять тишина…

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

Вот такая история. А мораль простая — надо чаще думать головой.

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

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

Вопрос. Что характеризует успешность ученого?

Ответ. Ну очевидно же, успешность ученого характеризуется успешностью его работ. Если он опубликовал свою работу, и другие ученые сочли ее интересной и оригинальной, опираются на нее в своих исследованиях, то работу можно считать успешной. Вроде даже какой-то термин был… А, во, «индекс цитирования»!

Вопрос. А что насчет научной степени? Она является показателем успешности?

Ответ. Разумеется! Если человек получил степень, он ведь уже совершил какую-то серьезную научную работу, правильно? Хотя нет, постойте… При защите же нет требований к индексу цитирования, значит, успешность работы во внимание не принимается. А значит… Значит, оценивается просто способность человека написать хоть какую-нибудь научную работу. Выходит, процесс получения степени — это просто способ отфильтровать людей, в принципе не способных к науке!

Вопрос. Почему существют фирмы, пишущие диссертации за деньги?

Ответ. Потому что существует спрос на диссертации. Видимо, преимущества от получения степени достаточно велики, чтобы за них платить. Хотя это странно, конечно, — защищать диссертацию, если не можешь написать ее сам. Это ведь фильтр, а сама научная работа начинается только после защиты… Наверное, дело в самом по себе статусе научной степени. Но какой толк от такого статуса, если степень ничего не говорит об успешности?.. Брр, парадокс какой-то.

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

Ответ. Эээ. Не знаю. Видимо, никаких.

Вопрос. Зачем нужны ВАКовские журналы?

Ответ. Это журналы, публикации в которых означают признание работы официальным научным сообществом. А, нет, признание отражает индекс цитирования. Стало быть, ВАКовская публикация ничем не отличается от обычной, кроме официального статуса. Для получения степени необходимо иметь публикации в ВАКовских журналах. Я бы даже сказал, что таких публикаций в этих журналах большинство. Черт, выходит, что в ВАКовских журналах публикуются менее качественные работы. Что-то вы совсем мне голову задурили!

Вопрос. Есть ли у ученых мотивация делать качественные работы? Они находят свое применение?

Ответ. Сами знаете, в каком положении сейчас промышленность. Результаты практических исследований практически не внедряются — нет ни воли руководства, ни средств. Насчет фундаментальных и так понятно. Фактически, исследования ведутся или ради получения грантов, или просто из интереса. Что касается рядовых ученых, то до них и гранты редко доходят, остается только увлечение наукой.

Вопрос. Зачем нужна Академия наук? Какую роль играют академики и член-корреспонденты?

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

Вопрос. То есть любой ученый, даже самый молодой, может расчитывать на получение средств, если его исследование представляет ценность?

Ответ. Теоретически да, но на практике большую роль играют личные связи. В основном деньги получают крупные ученые и руководители институтов. Молодому ученому приходится или пробиваться «наверх», начиная с рядового сотрудника какого-нибудь НИИ, или же обзаводиться нужными связями как-то еще. Через политику, например.

Вопрос. Зачем аспиранты изучают философию науки?

Ответ. Нуу… Эээ… Нужно же преподавателям философии на что-то жить :)

Вопрос. А что вы лично сделали для науки?

Ответ. (в ужасе убегает)

Думаю, моя идея понятна. Список вопросов легко можно продолжать до бесконечности. В России главная, на мой взгляд, проблема — нежелание задавать себе вопросы и давать на них честные ответы. В результате получается, что власть вопит «Спасем молодых ученых! Спасем науку!», пилят под это дело астрономические бюджеты, а потом удивляются — как же так, почему все так плохо, мы же столько всего сделали! А «снизу» картина выглядит как непрекращающийся театр абсурда, в котором мы вынуждены принимать участие.

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

Ух, как я патетично завернул. Надо закончить более позитивно. Коллеги, я знаю что делать! Работать надо, а не делать вид! В науке есть только два принципа: самоценность истины и установка на создание нового знания. А звания, степени и прочая бюрократия — это все мишура.

Ссылки по теме:

Почему у нас такая наука (RSDN)
В чем заключались достоинства и недостатки советской науки
Зачем нам корова?
Бюллетень в защиту науки

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

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

Началось все с подкаста номер 38 на StackOverflow, в котором Джоэль и Джефф Этвуд диалогируют на разнообразные IT-темы. В частности, они затрагивают вопрос юнит-тестов и методологии TDD; это вызвало такую бурную дискуссию, что Джоэль аж написал целый пост, приведя там стенограмму оного фрагмента подкаста. Вкратце, ключевые мысли примерно такие:

1. TDD — бесполезная штука, потому что 100% покрытие кода тестами очень тяжело достичь, да и не нужно.
2. Модульные тесты не нужны, потому что на них тратится слишком много времени. Кроме того, если что-то нужно будет менять в коде, возможно придется изменить кучу тестов.
3. Писать тесты для унаследованного кода тяжело и ненужно (и поэтому модульные тесты вообще не нужны).

Я, конечно, несколько преувеличил. Но не одному мне это показалось ересью. Разгромный отзыв написал Uncle Bob (автор agile-подхода и принципов SOLID, по которым Джоэль тоже проехался), пожурив авторов с этакой отцовской грустью («Джоэль, ты неправ») и усомнившись в целесообразности использования разрабатываемых ими продуктов. Маленькую обиженную заметку «Джоэль неправ насчет моей работы» опубликовал Кент Бек (соавтор TDD и XP). Ну и понеслось. Нашлись как противники TDD и вообще тестов, так и сторонники (в том числе индийские). bishop3000 высказался против использования TDD и тестов для legacy code (справедливо, см. ниже).  Появилось даже интереснейшее обсуждение на Hacker News.

Любопытно, что большинство противников тестирования приводит аргументы из разряда «мне Петрович напел, не понравилось» или вообще делают чисто умозрительные заключения. Никто из них не смог сказать «Вот мы в нашем проекте фанатично поддерживали полное покрытие кода тестами, но так умаялись, что решили отказаться от тестов вообще. После этого мы выпустили продукт на месяц раньше срока, и теперь тратим половину рабочего дня на чтение благодарственных писем от пользователей». То есть, натурально, против TDD и тестов выступают люди, которые ни того, ни другого не пробовали — максимум прочитали пару статей, на основе которых и сформировали свое мнение. Джоэль, выходит, тоже пусть лучше пишет блог, чем код. Но Этвуд? Может, они его там в StackOverflow на наркотиках держат?

Мое мнение — и TDD, и навыками написания модульных тестов должен в полной мере овладеть каждый уважающий себя программист. Существуют случаи, когда ни то, ни другое применять нет смысла (например, при создании прототипов). Кроме того, 100% покрытия тестами (распространенное заблуждение насчет TDD, что «все должно быть покрыто тестами») — штука действительно сродни мифической, и мало где практикуемая. Хотя бы потому, что это никому не нужно. Зачем, в самом деле, тестировать геттеры/сеттеры? Или настолько тривиальный код, что вы готовы головой за него поручиться?

Модульный тест — это проверка публичного интерфейса. Это фундаментальный принцип, из непонимания которого проистекает множество бед. Например, некоторые думают, что если наш класс использует стороннюю библиотеку, то нужно сначала написать для этой библиотеки тесты. Неверно! Тесты писать нужно для нашего класса, и если поведение класса будет нарушено из-за ошибок библиотеки, тесты на это отреагируют. Та же логика применима и к пресловутому вопросу «как тестировать закрытые методы». Их не нужно тестировать! Если открытые методы протестированы и работают правильно, то закрытые никого не интересуют.

Ну, и наконец, заявление Спольски, что, мол, если понадобится что-то поменять, то придется править много тестов, очевидно вопиюще неверное. Модульные тесты на то и модульные, что… сможете сами догадаться? Вот-вот. И если в вашем коде изменение в одном месте обрушает все остальное — грош вам цена как программисту.

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

Теперь собственно случай. Понадобилось мне поменять кое-какой код в libc. Гляжу в заголовочный файл — а там некоторые функции и не функции вовсе, а макросы. Ну, думаю, непорядок. Заменил макросы на нормальные функции, подправил их как требовалось, тесты соответствующие написал — все замечательно работает.

Через пару дней прибегает представитель соседнего отдела и говорит, что у них все падает и плющится, и все по вине моих функций. Иду разбираться. Гляжу — компоновщик не может найти функции, которые вызывались в старых макросах. Ну делов-то, говорю, пересоберите проект, я там макросы на функции заменил. Какой тут крик начался… У них же софтина уже прошла испытания, и они ее в архив сдали, вместе с контрольной суммой. Пересобрать ее — значит заново кучу бумажной волокиты произвести. Ой…

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

Многие ВУЗы сейчас живут большей частью на деньги, которые стригут с сердобольных родителей. Более того, даже зарплаты преподавателей (по неподтвержденным данным) напрямую зависят от того, скольких они обучают платников. Сделать все образование бесплатным — значит обречь на вымирание добрую половину российских институтов, заодно с преподавателями. Разумеется, так не будет. Не то чтобы я верю в здравый смысл наших властей. Я верю в силу откатов. И поэтому платное образование никуда не денется.

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

Ну и теперь самое главное: в чем высший смысл платного образования? Ну например, приходят два студента — Вася и Петя — поступать в машиностроительный институт. Вася блестяще сдает экзамены, поступает на бюджетную форму обучения. Петя экзамены благополучно заваливает, но щедрый Петин родитель говорит: «Фигня вопрос, да неужто я позволю сыну в армию пойти?!» В результате Петя учится с Васей в одной группе, но если Вася старательно грызет гранит науки, и защищает красный диплом, то Петя на учебу кладет все что может, и в результате едва вытягивает на диплом, получив трояк с минусом. Платник ведь, нельзя заваливать. Вася затем едет в Штаты и работает в Chrysler, а Петя устраивается на ВАЗ. Дальнейшая импликация, думаю, понятна.

Ситуация становится еще более пикантной, если рассмотреть подруг Васи и Пети, которые поступали в медицинский по тому же сценарию…

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

Но самое главное: ни в коем случае нельзя к платникам относиться как к людям, покупающим диплом в рассрочку! К ним должны предъявляться те же требования на вступительных экзаменах, и их точно так же нужно гнать из ВУЗа, если завалят сессию. Иначе страна так и останется в том месте организма, в котором она обитает уже почти 20 лет. Жаль только, что в действительности все идет как раз по худшему сценарию, и с каждым годом мы углубляемся все выше в сторону желудка.

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

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

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

Затем нужно определить порядок, в котором будет прорабатываться информация. Я сделал это, распределив источники по трем группам:

1. фундаментальная и общая информация по основной теме;
2. частная информация по основной теме и общая информация по смежным темам;
3. все остальное.

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

Теперь для каждого очередного источника нужно сделать следующее:

1. распечатать, если он в электронном виде;
2. прочитать, подчеркивая ключевые фразы и делая пометки; не нужно подчеркивать все подряд — только основные идеи;
3. выбрать ключ, под которым будет фигурировать этот источник; я обычно комбинирую фамилию автора, год и один-два ключевых слова, например, «fidge2002schedtest»;
4. записать выходные данные и ключ в библиографическую базу (я пользуюсь BibTeX и ebib);
5. составить краткий конспект, переписав, по сути, все подчеркнутые фрагменты; при этом совсем не обязательно должен получиться связный текст; вы можете даже использовать mind maps, если вам так удобнее; я предпочитаю делать конспект, полностью отражающий структуру исходного текста (то есть, всю иерархию разделов), но некоторые разделы, не представляющие особого интереса, оставляю пустыми; все это делаю в LaTeX, чтобы можно было распечатать и почитать на досуге;
6. посмотреть, нет ли чего интересного в библиографии источника;
7. не забыть вписать в конспект путь к файлу источника;
8. на твердой копии или оригинале источника надписывается выбранный библиографический ключ.

Второй шаг можно отделить. Я, например, читаю и размечаю статьи, когда еду в метро. Обычно на 30-страничную статью уходит две-три поездки на работу и с работы. Конспектирование идет гораздо медленнее, в среднем от 2 до 6 часов на статью, в зависимости от раздела. Поэтому у меня всегда есть запас прочитанных, но не законспектированных статей.

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

Нет, конечно, с первого раза он мне не понравился. И со второго, и с третьего тоже. Но я был настойчив, потому что хотел убедиться, что все эти странные люди со Столлманом во главе ошибаются. Наивный… Майн готт, я даже нашел людей, которые пользуются emacs в Windows! Теперь я могу их понять. Чем дальше, тем меньше хочется переключаться в другое окно. Нужна оболочка — пожалуйста, M-x shell. Почту почитать — сколько угодно, rmail-mode. С файлами и каталогами поработать — вот, извольте, C-x d. Рисунок нарисовать, PDF посмотреть, по Интернету посерфить… Ах да, в нем еще можно редактировать текст (вот ведь приятная неожиданность)! В результате ловишь себя на мысли, что и Linux в общем-то не очень нужен, и только зря жрет ресурсы.

Но падаван вырос, и настало ему время заняться поддержкой многострадальной отечественной науки. Наука у нас в стране, говоря откровенно, каким-то парадоксальным образом существует отдельно от занимающихся ею ученых, в своеобразной параллельной реальности. Оцените: ВАКовский журнал требует предоставлять публикации в формате Word, и чтоб не более 5 страниц. Вместе с иллюстрациями и библиографией. Видели когда-нибудь нормальную научную статью из 5 страниц? Найдете — покажите мне. А уж статей, качественно сверстанных в Word, — днем с огнем; большинство просто не в курсе про такую вещь, как стили.  Но я на поводу у толпы не иду и как правильный апологет CS все пишу исключительно в (La)TeX. Потом как-нибудь через ODF и MathML сконвертирую, если припрет.

Но что-то меня сегодня понесло на отвлеченные темы болтать, пора бы перейти к делу. Так вот, поскольку emacs теперь мой дом родной, то AUCTeX — просто-таки домашние тапочки, основная работа происходит именно в нем. Но какой же научный текст без библиографии? Вот и пришлось искать некий редактор BibTeX-файлов, встроенный в emacs (кто не в курсе, про что вообще речь и зачем он нужен, почитайте обзор BibTeX от Дебианщика). Таковым редактором оказался ebib. Это не режим никакой, а полноценное elisp-приложение, вроде Gnus.

ebib прост, как пятак. Для начала в ~/.emacs записываем строчку:

(autoload 'ebib "ebib" "Ebib, a BibTeX database manager." t)

Теперь запускаем его по M-x ebib, видим два буфера: верхний (индексный, index buffer) и нижний (буфер записи, entry buffer). В индексном буфере отображается список ключей всех записей в bib-базе. При выборе одного из ключей в буфере записи отображаются поля, описывающие соответствующий библиографический источник.

Я не буду подробно и по шагам описывать, как именно пользоваться ebib — дело нехитрое. Лучше приведу небольшой набор наиболее полезных привязок:

• o —открыть (создать) bib-файл;
• q —выйти из ebib совсем (в индексном буфере) или завершить редактирование записи (в буфере записи);
• z — отправить ebib на задний план, без закрытия файла (вернуть обратно опять по M-x ebib);
• a — добавить запись;
• e — редактировать запись (в индексном буфере) или поле (в буфере записи);
• E —изменить ключ записи;
• C-x b —завершить редактирование многострочного поля;
• c, x, y —copy, cut, yank;
• s — сохранить файл;
• w — сохранить файл в другое место;
• / — поиск в базе по регулярному выражению;
• P — сформировать файл с таблицей всех записей в базе (мегаудобная штука!).

Теперь о самом главном — об интеграции с LaTeX-mode. Это происходит с двух сторон. Если мы редактируем tex-файл (то есть, находимся в LaTeX-mode), то в нашем распоряжении есть две замечательные функции:

• ebib-insert-bibtex-key — в позицию курсора вставляется ссылка на источник, ключ которого мы зададим в минибуфере (при этом работает автодополнение!);
• ebib-entry-summary — отобразить информацию о цитате, на которой находится курсор.

По умолчанию эти функции не закреплены за клавиатурными комбинациями, поэтому рекомундую сразу дописать в ~/.emacs следующее:

(add-hook 'LaTeX-mode-hook #'(lambda () (local-set-key "\C-cb" 'ebib-insert-bibtex-key)))
(add-hook 'LaTeX-mode-hook #'(lambda () (local-set-key "\C-cs" 'ebib-entry-summary)))

Разумеется, для корректной работы на заднем плане в это время должен работать ebib. Если же мы находимся в индексном буфере ebib’a, то можем выбрать ключ и нажать p (push), вставив тем самым цитату в некоторый другой буфер. Это хорошо тем, что перед глазами сразу вся база, и не нужно мучительно вспоминать имена ключей.

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

Подробнее можно посмотреть, например, у Лебедева или погуглить.

Реализовать висячую пунктуацию можно в разных типографских программах, таких как Adobe InDesign. Можно даже сделать в Web-страницах, и даже динамически. Но везде это сопряжено с известными трудностями: нельзя просто сказать «а сделай-ка мне висячую пунктуацию» и беззаботно топтать текст. Наиболее просто вариант предлагает LaTeX: нужно просто вставить следующие настройки в преамбулу:

\usepackage{microtype}
\SetProtrusion
{
encoding = T2A,
family = faq
}
{
« = {1000,     },
» = {    , 1000},
„ = {1000,     },
“ = {    , 1000},
( = {1000,     },
) = {    , 1000},
! = {    , 1000},
? = {    , 1000},
: = {    , 1000},
; = {    , 1000},
. = {    , 1000},
- = {    ,  500},
{,}= {    , 1000}
}
\DeclareMicrotypeSet{t2atext}{encoding=T2A}
\UseMicrotypeSet{t2atext}

Чтобы все это заработало, придется установить последнюю версию пакета microtype. Параметр faq в приведенном выше коде — это семейство шрифтов. Здесь я использую пакет шрифтов pscyr и семейство антиквенных шрифтов (aq).

Идея взята из поста Roman Odaisky на РСДН и ЖЖ-поста ogoldberg.

Не стоит сразу меня обвинять в мракобесии и развешивать ярлыки. Как ни удивительно, проблема склонности к программированию существует, и люди даже пишут по этому поводу серьезные статьи. В статье заявляется с известной долей недоумения, что, оказывается, существует способ сказать до начала обучения, сумеет ли человек осилить программирование или лучше сразу на рудники. Нехило так, а? Приходит студент поступать на программерскую кафедру, а его просят ответить на три простых вопроса, после чего (голосом магистра Йоды): «Тебя обучать не будем мы! Силы в тебе увидеть не можем!..»

Я бы, наверное, принял все это за шутку, если бы сам не столкнулся с живым подтверждением. Однажды я попробовал в порядке развлечения научить азам программирования двух людей. Один из них не смог понять, как работает присваивание значений переменным. То есть, натурально, пришлось минут 20 объяснять, что означает запись a = 1. Другой человек воспринял концепцию присваивания легко и непринужденно, хотя никогда до этого не программировал, да и желания такого не имел. Каково же было мое удивление, когда я наткнулся на пост Джеффа Этвуда, откуда и узнал про существование исследования в этой области. И вопрос на понимание присваивания у них первый в списке!

В общем, как ни крути, существует разница между людьми. Одни могут в уме строить и выполнять модели дискретных структур, а другие — не могут. Одни люди потенциально могут стать программистами, а другие — нет. Конечно, есть масса людей, зарабатывающих деньги программированием, но неспособные понять рекурсию, косвенную адресацию или функциональную парадигму. Но это другое — такие люди не строят ментальные модели программ, они просто действуют по аналогии или используют упрощенные способы формализации (строительство SQL-запросов мышкой в Access), и хакеров из них не получится ни при каком раскладе.

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

• присваивание;
• последовательное выполнение;
• циклы;
• рекурсию;
• косвенную адресацию (указатели);
• мультипрограммирование (многопоточность);
• «чувство правильной вещи».

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

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

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

void (*signal(int sig, void (*func)(int)) )(int);

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

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

Синтаксис typedef очень прост: мы пишем обычное объявление стековой переменной и добавляем перед этим определением ключевое слово typedef. При этом никакая переменная не создается, а имя «переменной» становится синонимом указанного типа. Например:

typedef const char* string; /* string - указатель на константный символ */
typedef void (*fptr)(int); /* fptr - указатель на функцию, возвращающую void и принимающую int */

Часто можно видеть, как с помощью typedef можно избавиться от необходимости писать struct при определении переменной типа структуры:

struct s_tag {
/* какие-то члены */
};
typedef struct s_tag mystruct;
/* ... */
mystruct s;

Можно создать синоним одновременно с определением структуры:

typedef struct s_tag {
/* какие-то члены */
} mystruct;

Можно даже создать синоним для безымянной структуры:

typedef struct {
/* какие-то члены */
} mystruct;

Начинающие программисты вместо typedef часто используют препроцессор:

#define mystruct struct s_tag

Хотя со структурами вроде бы никаких проблем не возникает, использование в общем случае препроцессора для создания псевдонима типа может привести к трудноуловимым ошибкам:

#define iptr int*
iptr ptr1, ptr2; /* какой тип у ptr2? */

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

Примеры использования кэширования:

• кэширование отображения виртуальных адресов в физические; медленная память — таблицы преобразования в оперативной памяти, быстрая — кэш TLB;
• кэширование обмена данными с жестким диском; медленная память — диск, быстрая — оперативная память;
• кэширование веб-страниц (кэш браузера); медленная память — соединение с Интернетом, быстрая — жесткий диск.

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

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

• временная неготовность устройства; при прожиге болванок наверняка все видели волшебный Progress Bar «Уровень буфера», это как раз то самое;
• невозможность принять поток данных с требуемой скоростью; например, для этих целей существует исходящая очередь сетевых пакетов — приложения могут клепать данные быстрее, чем сетевая карта успеет их передавать;
• гранулярность обмена; в этом случае буферизация служит средством группировки данных; яркий пример — жесткий диск, обмен с которым возможен только блоками размером с сектор (512 байт обычно), а лучше даже целыми дорожками (много секторов); это также пример того, как одна и та же структура данных может использоваться и для кэширования, и для буферизации (см. выше пример про кэширование жесткого диска).

Буферизация бывает прозрачной и непрозрачной. Прозрачная — когда обменивающиеся данными стороны в курсе, что буфер существует (clipboard, message queue). Непрозрачная буферизация — когда буферизация незаметна (сокеты).

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

Контрольный вопрос. Что такое буферный кэш?

Note: There is a rating embedded within this post, please visit this post to rate it.

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

#ifndef _UTEST_H_
#define _UTEST_H_
#include <stdio.h>
#define UT_ASSERT_EX(expr,fmt,...) \
    do { \
    if (!(expr)) { printf("ASSERT: file \"%s\", line %d, function \"%s\": ",\
            __FILE__, __LINE__, __FUNCTION__); \
            printf(fmt, __VA_ARGS__); \
            printf("\n"); \
            return 1; } \
    } while(0);
#define UT_ASSERT(expr,msg) UT_ASSERT_EX(expr, "%s", msg)
#define UT_TEST(test) \
    do { \
        printf("TEST: \"%s\" %s\n", #test, (_t_ ## test() ? "failed" : "OK")); \
    } while(0);
#define UT_TESTDEF(name, body) \
    static int _t_ ## name () { \
        do { \
            body \
        } while(0); \
        return 0; }
#endif /*_UTEST_H_*/

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

#include "utest.h"
 
int func1(int arg)
{
    return arg*arg;
}
 
UT_TESTDEF(func1,
    int ret;
    ret = func1(5);
    UT_ASSERT(ret == 25, "blah-blah");
    ret = func1(0);
    UT_ASSERT_EX(ret == 0, "ret is %d, must be 0", ret);
);
 
int main()
{
    UT_TEST(func1);
    return 0;
}

Задачу свою такой подход вполне решает, так что невеликие размеры «фреймворка» пусть вас не смущают. Желающие могут навертеть вокруг этого свои рюшечки, а по мне и этого достаточно.

О серьезных вещах сегодня писать — кощунство, поэтому буду писать о полусерьезных.

В далекие-далекие годы, когда еще только-только стали появляться компьютеры на полупроводниках, а в лесах можно было встретить динозавров, появился UNIX. Дорог он нам не только фактом своего существования, но главным образом сложившейся вокруг него культурой. Ну, знаете, там были такие волосатые очкарики, которые все свое время просиживали за терминалом (при наличии такового),  пили колу и разговаривали друг с другом на языке инопланетян. Эти ненормальные идентифицировали себя «хакерами», все время писали какой-то код и ни во что не ставили интеллектуальную собственность.  Кстати, все ли знают, что UNIX изначально создавался Томпсоном как средство запуска игры Space Travel на компьютере PDP-7?

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

typedef struct n{int a:3,
b:29;struct n*c;}t;t*
f();r(){}m(u)t*u;{t*w,*z;
z=u->c,q(z),u->b=z->b*10,
w=u->c=f(),w->a=1,w->c=z->
c;}t*k;g(u)t*u;{t*z,*v,*p,
*x;z=u->c,q(z),u->b=z->b,v
=z->c,z->a=2,x=z->c=f(),x
->a=3,x->b=2,p=x->c=f(),p
->c=f(),p->c->a=1,p->c->c=
v;}int i;h(u)t*u;{t*z,*v,*
w;int c,e;z=u->c,v=z->c,q(
v),c=u->b,e=v->b,u->b=z->b
,z->a=3,z->b=c+1,e+9>=c&&(
q(z),e=z->b,u->b+=e/c,w=f(
),w->b=e%c,w->c=z->c,u->c=
w);}int(*y[4])()={r,m,g,h};
char *sbrk();main(){t*e,*p,*o;
o=f(),o->c=o,o->b=1,e=f(),
e->a=2,p=e->c=f(),p->b=2,
p->c=o,q(e),e=e->c,(void)write
(1,"2.",2);for(;;e=e->c){q(e),
e->b=write(1,&e->b["0123456789"],
1);}}t*f(){return i||(i=1000,
k=(t*)sbrk(i*sizeof(t))),k+--i;
}q(p)t*p;{(*y[p->a])(p);}

Эта программа, например, вычисляет и выводит на stdout значение числа e с неограниченной точностью (точнее, ограниченной размером стека или терпением пользователя). Понятно, что нанимателям таких программистов очень не нравился подобный стиль. История умалчивает, сколько хакеров было уволено, пока, наконец, в 1984 году не был организован IOCCC, или, по-нашенски, Международный Конкурс На Самую Запутанную Программу На C. Это было настоящей отдушиной для недосамовыраженных профессионалов, и работодатели снова могли спать спокойно.

Среди победителей IOCCC оказалось немало известных в компьютерном мире людей. Например, Дэвид Корн (создатель оболочки ksh) в 1987 году стал одним из победителей с такой программой:

main() { printf(&unix["\021%six\012\0"],(unix)["have"]+"fun"-0x60);}

Основная интрига в том, что должно появиться на экране. Ничего сложно здесь нет, если помнить о том, что следующие две строки с точки зрения C идентичны:

a = b[1];
a = 1[b];

Плюс еще нужно знать, что unix — предопределенный символ, эквивалентный 1, если использовать gcc. В этом можно убедиться с помощью следующей команды:

$ touch foo.h; cpp -dM foo.h
...
#define unix 1
...

Если сложить два и два, получится, что программа выводит строку «unix».

Одна из моих любимых программ-чемпионов, написанная Марком Биггаром, выглядит так:

P;

Вот оно, настоящее Дао! Эта программа, в отличие от всех остальных победителей, умеет делать все. Ее нужно просто правильно скомпилировать. Например, можно заставить ее вывести «Hello, world»:

$ cc -DP="main() { printf(\"Hello, world\\n\"); }" -o beggar beggar.c
$ ./beggar
Hello, world

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

Кстати, на этом же соревновании засветился и Ларри Уолл, написавший некую линвистическую чуду-юду. Теперь понятно, откуда у Perl ноги растут. Оказывается, Уолл просто сделал язык, на котором непонятные программы писать гораздо проще, чем на C.

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

Note: There is a rating embedded within this post, please visit this post to rate it.

Долгое время я страдал от такой вредной привычки. Когда в работе наступал ступор, например, окончание небольшого этапа или просто необходимость крепко подумать, я машинально открывал почту, потом RSS-ленту, потом новости, потом еще какой-то сайт, потом находил какую-то интересную статью… А когда возвращался к работе, оказывалась, что можно, в общем-то, уже не начинать, потому что скоро обед / конец рабочего дня / whatever. Короче говоря, продуктивность моя сильно от этого дела страдала.

Общие методы тайм-менеджмента вроде GTD работают замечательно только в теории. На практике очень многое зависит от личных предпочтений и того, насколько человек может управлять своей волей. Тотальному лентяю не поможет никакая супер-система продуктивности или дорогущий софт для планирования времени, а волевому человеку не нужны никакие костыли, чтобы переть напролом к поставленным целям. Выходит, все методики и инструменты личной эффективности выполняют две  (основные) функции:

1. подзадпинательную — мотивация на выполнение нужных действий и невыполнение ненужных;
2. организационную — уже при наличии мотивации повысить эффективность выполняемых действий.

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

• Необходимо вести список дел, которые необходимо выполнить. Позволить себе обходиться без такого списка могут только те, кто долгое время им пользовался и поняли, что способны быть эффективными и без него. Я составляю список дел на каждый день, плюс отдельные списки отдаленных дел и дел вообще без временной привязки. Каждый вечер и каждое утро я просматриваю все эти списки и формирую план действий на предстоящий день. В списке делаю  пометки, показывающие особый статус дела (срочность, контекст и т.п.).
• Список дел должен быть в бумажном блокноте, а блокнот — всегда с собой. К этому я пришел спустя годы пользования всевозможными программами. Главное преимущество блокнота — постоянная видимость. Как только я прихожу на работу, домой или куда-либо еще, сразу выкладываю его на стол, и все задачи у меня перед глазами весь день. Даже КПК не обладает таким свойством. Кроме того, бумага обеспечивает исключительную гибкость визуального представления.
• Сюда же, в блокнот, я записываю все идеи, которые пришли в голову за день. Потом мысли, достойные сохранения, в обработанном виде переносятся в другой блокнот или, например, в блог.
• Каждая задача из списка запланированных на сегодня не должна занимать более часа (если быть точнее, то должна быть возможность выполнить задачу за один заход, без перерывов). Если задача большая, то я разделяю ее на несколько более мелких. Нет ничего хуже, чем постепенно выполняемое в течение нескольких дней дело, постоянно мозоляющее глаза своей незавершенностью.
• Не стоит расстраиваться, если какие-то дела, запланированные на день, остались невыполненными. Это нормально. Их можно просто перенести на следующий день. Если же одна и та же задача кочует по блокноту в течение недели или даже дольше, нужно задуматься, действительно ли эту задачу следует выполнять.
• Все действия, требующие менее 5 минут, должны выполняться немедленно.
• Каждое выполняемое действие должно иметь цель. Это не значит, конечно, что нужно над каждым чихом размышлять — «А соответствует ли этот чих моим Принципам? А приближает ли он меня к моей Цели?». До абсурда доходить не нужно, но стараться все же себя контролировать. Например, открывая браузер, надо четко представлять, что именно мы хотим найти или узнать. И если сумеем ответить на этот вопрос, определить еще, действительно ли нам нужно то, что мы хотим узнать. Неочевидное следствие из этого правила: дела из блокнота имеют преимущество над делами, там не перечисленными.
• Перед совершением любого действия спросить себя, оправдывает ли действие затрачиваемое на него время? Можно ли это време потратить с большей пользой?
• Не планировать на день больше, чем реально можно успеть сделать.

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

Что касается башорга (в нарицательном смысле), то я избавился от привычки посещения не относящихся к делу сайтов очень просто: каждый день дописывал себе в todo-list задачу «Не ходить на развлекательные сайты». Через неделю я избавился от этой привычки полностью.

Note: There is a rating embedded within this post, please visit this post to rate it.

int a[5] = { 1, 2, 3, 4, 5 };

Если же мы попробуем провернуть такой же фокус в дальнейшем:

15
16
17

int a[3] = { 1, 2, 3 };
int b[3] = { 3, 2, 1 };
a = b;

получим по сусалам от компилятора:

$ cc -o0 -g -o test test.c
test.c: In function 'main':
test.c:17: error: incompatible types in assignment

Казалось бы, типы одинаковые: int[3], но нет, не дают присвоить. Такой вот семантический парадокс.
Но это еще не самое интересное. Самое интересное — массивы таки можно присвоить (читай — скопировать), безо всяких memcpy. Вот глядите:

struct s_tag {int arr[100];} aa, bb;
int i;
for (i = 0; i < 100; i++)
    aa.arr[i] = i;
bb = aa;

Все прекрасно компилируется и работает, и именно так, как предполагалось: один массив копируется в другой, цикл копирования генерируется компилятором.

Стоит добавить к этому, что при передаче массива в качестве аргумента функции копирование не происходит — передается только адрес. Зато если массив обернуть в структуру и передать ее по значению функции — копируется.

Мораль: массивы — это не совсем указатели и не совсем массивы; во избежание недоразумений необходимо учить матчасть.

Выборочная инициализация массива (работает в C, но не в C++!):

int a[] = {
    [2] = 2,
    [7] = 7
};

Выборочная инициализация структуры:

struct {
    int a;
    int b;
    int c;
} s = { .a = 1, .c = 2 };

Нетрудно догадаться, что здесь происходит. В первом случае мы получаем массив из 8 элементов, два из которых инициализированы, а остальным присваивается 0. Со структурой еще проще: поля a и c получают значения, а поле b обнуляется. Рассмотрим примеры посложнее.

struct {
    int a;
    struct {
        char c;
        int  d;
    } b;
    int c;
} s = {
    .a = 2,
    .b.d = 3
};

static short grid[3] [4] = { [0][0]=8, [0][1]=6,
                             [0][2]=4, [0][3]=1,
                             [2][0]=9, [2][1]=3,
                             [2][2]=1, [2][3]=1 };

int a[] = {2, 4, [8]=9, 10}

Если первые два случая еще как-то интуитивно понятны, то последний поначалу заставляет задуматься. Здесь действует простое правило, такое же, как и при объявлении enum. По умолчанию индексы в инициализаторе начинаются с 0 и с каждым новым значением увеличиваются на единицу. Но если указать индекс явно, он становится новым значением по умолчанию. Приведенный выше пример раскрывается в следующее:

int a[] = {[0]=2, [1]=4, [8]=9, [9]=10}

Таким образом, получим массив из 10 элементов.

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

int a[] = {2, [3] = 3, [2] = 2, 5};

Могу сказать сразу, что синтаксически конструкция безупречна.

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

#define SIGNAME(s) [s] = #s
const char * const sigNames[] = {
    SIGNAME(SIGHUP),
    SIGNAME(SIGINT),
    SIGNAME(SIGQUIT),
    /* ... */
};
#undef SIGNAME

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

История возникновения блога настолько банальна, что я даже не буду об этом говорить. Придумайте что-нибудь сами.

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

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