среда, 22 декабря 2010 г.

Не вся информация одинаково полезна

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

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

четверг, 16 декабря 2010 г.

Изгоняющий демонов

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

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

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

среда, 8 декабря 2010 г.

Есть ли жизнь с systemd?

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

среда, 1 декабря 2010 г.

Кодинг стайл - 3 пробела...

Не понимаю, откуда в программистском сообществе такая нелюбовь к табуляциям?

Взять к примеру GNU coding style. Вертикальное пространство они никак не экономят, скобки пишут на новых строчках. Зато в горизонтальном плане почему-то экономят.

Или вот Python Style Guide вообще не рекомендует использовать табы, хотя и не запрещает как некоторые.

понедельник, 8 ноября 2010 г.

Про гибкое планирование...

Хотелось блеснуть интеллектом, процитировав классиков. Но небольшое углубление в тему показало что классиков перевирают... :)

пятница, 8 октября 2010 г.

Coding style battle

Стандарт кодирования у нас в команде отсутствует.

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

четверг, 30 сентября 2010 г.

Использование юниттестов

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

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

пятница, 17 сентября 2010 г.

Есть ли в Google суппорт?

- Доктор, меня никто не замечает
- Следующий!


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

Заодно у меня сменился адрес электронной почты. Вместо привычного мне dron@infosec.ru, которым я пользовался 10 лет, у меня появился новый @securitycode.ru

И решил я значит завести себе новый аккаунт в Google...

понедельник, 6 сентября 2010 г.

Ветвления в бранче

Все-таки это зло.

Mercurial позволяет двум разработчикам независимо сделать push, что приведет к тому что в бранче на сервере получится ветвление. Но что делать третьему разработчику, который это вытягивает? Заниматься слиянием? Да он вообще не в курсе что там куда.

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

четверг, 26 августа 2010 г.

Допустимая публичность

В C++ традиционным считается использование public методов в начале описания. И сразу слайды:
class foo {
public:
        foo();
        void doSomething();
private:
        ...
};
И это логично. При чтении кода первое, что мы видим, это доступные нам рычаги для воздействия на класс, его интерфейс. Для тех, кто дочитал до private, становятся известны некоторые подробности реализации. Но речь не о том...

среда, 18 августа 2010 г.

Назад, в будущее...

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

hg rollback можно делать только один раз и только до того как ты сделал push, при этом ревизия совершенно исчезает.

hg backout позволяет сделать откат, при этом добавляя еще одну ревизию.

Записал в дневнике: Достаточно переместить хед на одну ревизию назад и дальше пойти уже от нее. Тот хед - пусть болтается как тупиковая ветвь. Вполне естественно. Хотя может быть я что-то не понимаю.

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

Из песни слова не выкинешь

... Но их можно легко забыть.

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

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

среда, 28 июля 2010 г.

Человеческое лицо subversion - 2

Git очень плохо дружит с proxy. Его можно заставить работать с прокси, но после этого git-svn все равно валится по сигналам после каждой ревизии.

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

Итак, продолжение эксперимента...

пятница, 2 июля 2010 г.

Человеческое лицо Subversion

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

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

Тащить стабильные ветки - совершенно неинформативно, Весь чейнджлог содержит только собщения о мердже. Следовательно надо тащить к себе транк, который в репозитории FreeBSD традиционно по cvs'овски называется HEAD.

Проблема в том что история FreeBSD - богатая, 200 тысяч ревизий. И как выяснилось, не всякая DVCS долетит до середины репозитория FreeBSD. Решил немного сравнить mercurial и git в этом плане.

пятница, 25 июня 2010 г.

Операторные скобки, египетские и не очень

У нас в проекте не существует Coding Style. Это конечно плохо, но тут вопрос программистского самосознания о том, что считать правильным, а что никогда не применять, потому что плохо.

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

В коде я предпочитаю использовать египетские скобки, потому что они экономят размер кода по вертикали. Это ведь не справедливо, что стандартный экран имеет 80 символов в ширину и только 25 строк по высоте. :) 80 символов мне хватает почти всегда.

среда, 23 июня 2010 г.

Фитнесс для питона

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

Чтобы добавить функцию в эту систему необходимо было расширить транспортный уровень, доработать swig интерфейс, доточить perl враппер, отладиить все это (что порою превращалось в весьма нетривиальную операцию)..

Я уже знал в то время про FitNesse, и мне думалось, что неплохо было бы через wiki интерфейс управлять системой. Но связать все это вместе было достаточно нетривиально. Сам я на FreeBSD не сижу, а тестовое приложение не сидит на моей системе... А на той фре, на которой сидит тестовое приложение нет в помине никакой java, так нужной фитнессу.

Это все была присказка, переходим к сказке...

пятница, 28 мая 2010 г.

Boost data-driven test

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

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

Итак поехали...

понедельник, 17 мая 2010 г.

Раскладка для телефона

Прочитал статью "Улучшенная раскладка для телефона", задумался...

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

И тут меня осенило...

вторник, 27 апреля 2010 г.

libpthread-stubs.so.0 not found

Недавно, после очередного обновления, случилась поломка Exherbo. После обновления libpthread-stubs с версии 0.2 на версию 0.3 перестали загружаться в частности иксы. Ну я знал на что иду, когда ставил Exherbo, нас такими вещами не удивишь.

Гораздо хуже было, когда, в 2006 в Gentoo сломался expat. Там ни одно приложение вообще не работало, в том числе и python, без которого житть не может emerge.

Здесь - так, цветочки. Хотя reconcilio почему-то не хочет лечить ситуацию и спотыкается на первом же пакете.

четверг, 22 апреля 2010 г.

Более-менее...

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

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

вторник, 13 апреля 2010 г.

Больше предупреждений, хороший и разных

Хорошая практика программирования рекомендует включать максимум предупреждений компилятора и добиваться того, чтобы их не возникало в процессе компиляции. Заставить один C++ проект компилироваться без предупреждений достаточно легко. Но если в рамках одного проекта используются модули на C/C++ - все становится значительно интереснее.

Есть предупреждения, применимые только для C++ (например: -Weffc++, -Woverloaded-virtual, -Wold-style-cast). Я не пробовал включать их для си, могу предположить, что последует ругань и правильно. А поскольку для C они не имеют смысла - в данном контексте они не интересны.

Для обоих языков в первом приближении я отобрал три варнинга: -Wsign-conversion -Wconversion -pedantic. Остановимся на них поподробнее.

Начать стоит с того, что в си enum - всегда int.
enum {
 TEST1 = 0x100000000ULL,
 TEST2 = 0xffffffffU,
 TEST3 = 0x7fffffff
};
$ gcc -c -std=c99 -pedantic test.c
test.c:2: предупреждение: в ISO C значения перечислимого типа ограничены диапазоном типа ‘int’
test.c:3: предупреждение: в ISO C значения перечислимого типа ограничены диапазоном типа ‘int’
Причем это справедливо и для amd64, в этом легко убедиться например так:
BOOST_STATIC_ASSERT(sizeof(int) == 4);
В то же время в C++ с enum не возникает никаких проблем. В C++ тип enum есть собственно enum, даже знаковость которого определяется позже. Единственный возникающий в данной ситуации момент - стандарт C++ 99 года не любит определений ULL, считая их C99 long long integer constant, Для C++ даже U писать не обязательно, главное, чтобы значение могло уместиться в long, то есть быть не больше 32-64 бит в зависимости от типа платформы.

Это наводит на мысль, что переносимое приложение не должно использовать в enum значения больше 32 бит длиной.

Значение sizeof(TEST1) в С++ варьируется в зависимости от наполнения enum от 4 до 8.

Другой интересный момент, справедливый для обоих языков:
const unsigned int t1 = TEST1;
const unsigned int t2 = 0;
const unsigned int t3 = argc > 1 ? TEST1 : 0;
$ gcc -m64 -o test -std=c99 -Wsign-conversion test.c
test.c:3: предупреждение: conversion to ‘unsigned int’ from ‘int’ may change the sign of the result
Ошибка возникает в третьей строке фрагмента, и лечится заменой 0, на 0U... Хотя тот же 0 во второй строке не вызывает проблем.

И напоследок - ошибочная ситуация в gcc:
При попытке присвоить битовому полю значение какой-то переменной практически всегда происходит ошибка, и обойти ее практически не представляется возможным.
unsigned int x = 0x7f;
struct {
 unsigned int a:7;
} t = { .a = x };
$ gcc -std=c99 -Wconversion test.c
test.c:4: предупреждение: conversion to ‘unsigned char:7’ from ‘unsigned int’ may alter its value
Не существует способа привести переменную к битовому полю.

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

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

Можно предложить борцам на чистоту кода периодически устраивать параноидальные проверки с большим количеством опций, которые, возможно, не удастся расчистить целиком. А в обычные дни обходится более скромным подмножеством опций, но при этом обязательно используя -Werror. :)

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

пятница, 5 февраля 2010 г.

Mercurial сервер

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

Залил туда Gentoo, поставил вебсервер, mediawiki, ejabberd... Хотел поставить Google Wave, но в то время он был еще сырой, и не работал. Да и java на спарк не встает, во всяком случае у Gentoo не встает.

И тут, недавно, меня посетила еще одна мысль. Подниму ка я там scm сервер. Это позволит хранить отдельно всякие вне проектные рабочие разработки. Лишняя копия, как говорится, никогда не бывает лишней. Эта, пусть слабенькая, машинка прекрасно с справится с этой задачей.

Пусть простят меня поклонники Линуса Торвальдса - git мне никогда не нравился, хотя мне приходилось им пользоваться. На данный момент мне нравится Mercurial.

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

Борьба с вебмордой неожиданно затянулась. Хоть для меня скорость и не является решающим фактором - я старательно следовал инструкциям по настройке fastcgi, но добился лишь того, что я могу ходить на сервер от корня (от http://.../hg), но попытка ввести что нибудь после /hg неизменно приводит к проблемам. Сервер перенаправляет /hg на /hg.fcgi и других запросов упорно не хочет принимать. Ну не писать же везде /hg.fcgi/blablabla... лишнее.

А поскольку скорость не является для меня решающим фактором - я в конце концов нашел официальную инструкцию по настройке cgi под lighttpd. Она попроще и после нее все работает почти сразу.

Для коммитоов https не нужен, настроим авторизацию на пуш согласно той же официальной инструкции.

Но возникла проблема. htpasswd - является частью апача и в комплект lighttpd не входит. Ну не ставить же апач ради такой фигни? Значит можно выбрать другой метод авторизации. Меня бы устроила встроенная авторизация на основе /etc/passwd, но так lighttpd кажется не умеет. Здесь описаны возможность mod_auth. Генерируем /home/scm/.htdigest с его помощью.
$HTTP["querystring"] =~ "cmd=unbundle" {
        auth.require = (   "" => (
                "method"  => "digest",
                "realm"   => "Mercurial repo",
                "require" => "valid-user"
        ))
}

auth.backend = "htdigest"
auth.backend.htdigest.userfile = "/home/scm/.htdigest"
Но этого недостаточно. Нужно еще в конкретном репозитории разрешить не-ssl пушинг, и прописать юзеров, которые могут это делать.
scm@sparc ~/hg/xap/.hg $ cat hgrc
[web]
push_ssl = false
allow_push = dron

Теперь можно проверить... (я конечно и в процессе неоднократно проверял, сейчас финальный тест)
$ hg clone http://10.4.2.91/hg/xap
...
10 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ cd xap
$ echo "Ридми я до сих пор не написал" > readme.txt
$ hg add readme.txt
$ hg commit -m "Тестовый коммит"
$ hg push
pushing to http://10.4.2.91/hg/xap
searching for changes
http authorization required
realm: Mercurial repo
user: dron@infosec.ru
password:
abort: authorization failed
Тудыть ее... А, забыл lighttpd перезагрузить...
...
user: dron
password:
abort: HTTP Error 500: Internal Server Error
Доступа чтоль не хватает?
$ cd /home/scm/hg; chmod -R g+w *
(Пользователь lighttpd у нас включен в группу scm). А вот и нет... недостаточно... только
$ cd /home/scm/hg; chown -R lighttpd:lighttpd *
спас сервер. Не понятно. Везде для групп стоит rw, для каталогов - rwx. Но установка одной группы в lighttpd не спасает положение.

Теперь мне совсем не ясно - зачем я заводил юзера scm? Хотя может быть для fcgi (с отдельной службой, вероятно работающей от имени scm) это и было нужно. Но пусть пока будет так.

Остались несколько проблем, и https не самая большая из них. Вот самая большая:
$ hg push
...
user: dron@infosec.ru
password:
abort: authorization failed
$ hg push
...
user: dron
password:
adding changesets
add changeset a63be34dcf21
adding manifests
adding file changes
adding readme.txt revisions
added 1 changesets with 1 changes to 1 files
updating the branch cache
Вот так, dron в качестве имени - воспринимает, а dron@infosec.ru - нет. Вероятно проблема где-то mod_auth, потому что не сходится авторизация. И что с этим делать?..

четверг, 21 января 2010 г.

Сбербанк жжет

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


Тогда у меня еще промелькнула мысль, что где-то я это уже видел. Вспомнил! То же самое я наблюдал, когда распечатывал дампы в программе в %u формате, передавая char...

То есть на самом деле сертификат чека должен выглядеть как: 2bdc2fa0ffc1fef883c699b758e9ff45ba43a672.

Только какой же это, нафиг, сертификат?!?

PS: какой-то у меня микроблоггинг пошел. :)

суббота, 16 января 2010 г.

На гребне волны...

Дочка Убунту прибежала к Дебиану и, весело смеясь,
поцеловала его в лоб: "С днём рождения, папа!"
Затем она окинула радостным взглядом сидящих за
столом гостей и спросила своим звонким голосом:
— Папа, а где Gentoo, разве он ещё не пришёл?
— Нет, он ещё только собирается.


Я человек, уже, наверное, окончательно потерянный для традиционных систем. Народ мигрирует со скучного debian-stable на "веселую" OpenSuse. В чем счастье, Роман? В Gentoo я могу настроить едва ли не каждую опцию каждого пакетика. И я напрочь лишен этого в пребилденных системах. Мне тесно в их жестких рамках, Я даже не могу заоптимизировать пакетик так как захочу - я должен жить так, как хотят другие... Не хочу я так жить, не хочу.

Я люблю Gentoo. Но последнее время мне кажется, что Gentoo законсервативилось. Стабильная версия не создает почти никаких проблем, не смотря на то, что я ее каждую неделю обновляю. Скучно.

Куда же податься старому linux-экстремалу?

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

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

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

Как сказал один из наших сотрудников, когда мы заговорили о линуксах о всяких: "Если человеку скучно в Gentoo - то это уже не лечится..."

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

Держать две одинаковых системы как-то бессмысленно. Но и достойных альтернатив Gentoo я не вижу, кроме разве что Exherbo.

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

И самое экстремальное то, что система еще на стадии раннего бета тестирования. Стабильных пакетов в Exherbo нету вообще. Пакеты не просто помечены как нестабильные - они действительно самые свежие. Система для настоящих джедаев. Эти программы в debian stable появятся едва ли не через год...

Но сообщество Exherbo значительно меньше Gentoo'шного, развитие системы хотя и идет быстро, но многих программ пока просто нету. Но мы не привыкли отступать, будем писать ебилды, которые здесь называются эксересами. Больше эксересов хороших и разных.