Никогда не знаешь, где упадет OpenStack(c) 
Я, в процессе очередного дебагга.

Те, кто читает мой твиттер (@e0ne), должны знать, что в последнее время я работаю с OpenStack’ом, а именно занимаюсь(конечно, не один я) попытками его запуска на Red Hat Enterprise Linux (RHEL), CentOS, Scientific Linux, etc. Т.к. все это построено на базе полной и непросветной enterpise в виде RHEL, то сборка нового дистрибутива, как правило, у меня начинается со сборки именно под эту ОС. 

Вот я и хочу поделиться своими впечатлениями от сборки последней версии OpenStack’а под RHEL. Началось все с попытки запустить чуть менее чем полностью поломанную версию essex-1. Потом все продолжилось с версией essex-2. Основные моменты, которые мешали мне радоваться жизни - переделки в glance, связанные и security, которые на время поломали работоспособность EC2 API. 

Проект Glance - это услуги по отбору, регистрации и поиску виртуальных «machine images» (VMI). В рамках Glance используется RESTful API, что позволяет делать запрос метаданных VMI и выполнять поиск фактического образа (VMI). (http://openstack.ru/openstack_glance.html)

И тут я решил попробовать запустить все из последней версии исходников, с master’а...

После небольших усилий инстансы (виртуалки) начали запускаться, но были проблемы с сетью. Команда “killall dnsmasq”, подсказанная моим коллегой, решила часть проблем, а именно - выдачу IP адреса виртуальной машине. Далее в логах при загрузке неворуженым глазом были замечены такие проблемы:

 

Что означало, что запущенный инстанс не может получить данный от Metadata Server’а. Т.к. Metadata Server нормально работал в Diablo, то сразу вспомнились 2 вещи:

 

 

Далее по аналогии с Nova API был создан файл /etc/init.d/openstack-nova-api-metadata, который предназначался для запуске сервиса Metadata Server’а. Metadata Server, на первый взгляд, успешно запустился, то я попытался запустить снова инстанс, что мне привело к предыдущей ошибке. Логи Metadata Server’а немного испугали:

 

Мозг сразу начал представлять кошмары, связанные с выводом strace, linux kernel debugger’ом и так далее. Вовремя опомнившись, я полез в Google. Поиск по “exit code 134” ничего полезного не дал. А вот поиск по “iptables-restore buffer overflow” дал нужный результат в виде двух багов iptables: http://bugzilla.netfilter.org/show_bug.cgi?id=641 иhttps://bugzilla.redhat.com/show_bug.cgi?id=545600. Довольно-таки стандартное, на сколько мне известно, переполнение буфера, вызванное функцией strcpy, которую, к слову, не очень-то и рекомендуют использовать. Подробности в этом комментарии: https://bugzilla.redhat.com/show_bug.cgi?id=545600#c6

 

 

Т.к. обновление iptables в RHEL 6.1 - не самая приоритетная для меня задача, то я решил зайти с другой стороны - посмотреть что же делает OpenStack для получения такого результата.

 

 

https://github.com/openstack/nova/blob/master/bin/nova-api-metadata

Metadata Server запускается таким же способом, как и другие REST-сервисы Nova, поэтому проблему нужно было искать где-то дальше. Об этом же говорили и логи, и ошибка, связанная с iptables.

https://github.com/openstack/nova/blob/master/nova/network/linux_net.py

 

Метод metadata_accept() отрабатывает без ошибок и падает все в iptables_manager.apply().

 

Т.к. данный метод используется далеко не в одном месте

 

 

то ошибка где-то в передаваемых параметрах. В качестве параметров к iptables-restore у меня передавалось такое:

 ip-restore-full.jpg

 

 

Зная о баге в iptables и то, что падало все только при запуске Metadata Server’а, то получилось быстро найти нужную команду, которая все ломала:

iptables-restore <<EOF
*nat
:nova-api-metadata-POSTROUTING - [0:0]
-A POSTROUTING -j nova-api-metadata-POSTROUTING
COMMIT
EOF

len(‘nova-api-metadata-POSTROUTING’)==29, что вместе с символом конца строки в языке С давало нам 30 символов и при копировании их в массив из 29 символов давало нам переполнение буффера (см. ссылки на баги выше). Хорошо, проблема найдена, теперь нужно ее устранить. Для этого находим код, где у нас генерируется имя chain’а:

chain1.jpg, chain2.jpg

 

где:

binary_name = os.path.basename(inspect.stack()[-1][1])

Таким образом проблема была в имени исполняемого файла. Переименовав “/usr/bin/nova-api-metadata” в “/usr/bin/nova-metadata ” все заработало. Вопрос лишь в том, насколько долго оно будет работать с таким “фиксом”? 

Более правильное решение нужно делать исправляя код OpenStack’а и/или обновляя iptables. Также интересно как это себя ведет на других RHEL-based дистрибутивах(версия iptables) и ubuntu, но это уже проверю завтра, а пока поставил качаться нужные образы дистрибутивов...

[Update]

Баг с iptables проверен после установки чистой ОС после установки всех апдейтов с помощью команды "yum update" на следующих ОС:

  • RHEL 6.1 x86_64 - iptables v1.4.7, buffer overflow detected
  • RHEL 6.2 x86_64 - iptables v1.4.7, buffer overflow detected
  • CentOS 6.1 x86_64 - iptables v1.4.7 buffer overflow detected
  • CentOS 6.2 x86_64 - iptables v1.4.7 buffer overflow detected
  • Scientific Linux 6.1 x86_64 - iptables v1.4.7 buffer overflow detected
  • Fedora 15 x86_64 - testing in process
  • Fedora 16 x86_64 - testing in process

 


Качество кода

Published 12/12/2011 by e0ne in Offtopic

Качественного кода нельзя добиться в случае:

  • нет code review;
  • code review проводит один и только один человек;
  • нету guidelines;
  • проверка кода не происходит на Continius Integration сервере;
  • хотя бы один из членов команды не заинтересован в качественном коде;
  • время на уменьшение технического долга не закладывается при планировании следующей итерации.


День программиста, 256-й день в году на этот раз выпал на 13-е сентября. Хотя, если верить википедии, день программиста можно также праздновать и 10 декабря и 22 апреля, а так же в 404-й день в году, т.е. 4-е апреля (http://ru.wikipedia.org/wiki/День_программиста). Хотя, 404-й - это все-таки больше праздник веб-разработчиков, дизайнером верстальщиков и всех причастных к сайтостроению. Странно еще что не отмечают 200-й день - должен быть какой-то позитивный праздник.

 

P.S. Всех с прошедшим в пятницу днем QA.


На последнем IT Talk в Харькове один из докладчиков поднял интересную тему. Он сказал что документация в проектах, которые разрабатываются по методологии Agile всё-таки нужна. Тема интересная и достойна отдельного неблоьшого холливара. Ведь все вокруг говорят, что один из достоинств Agile - это отсутствие документации на проекте. Но так ли это на самом деле? По моему мнению, врядли существует хоть один проект сложнее чем “hello world”, в котором полностью отсутствует документация.

Да, по сравнению с, например, каскадной моделью разработки, в Agile, можно сказать, документации нет. Но чаще всего, под этой фразой скрывается отсутствие спецификации и нежелание команды хоть что-то документировать. А веть документация по проекту может быть разная. Это может быть ТЗ, выполненное по какому-то стандарту ISO, какие-то технические особенности приложения (например, список поддерживаемых браузеров для сайта) или что-то ещё.

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

Банально, но комментарии в коде - это тоже своеобразная документация. У кого-то она есть, у кого-то её нет. Иногда, лучше бы её не было :).

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

Ну и не могу не сказать про всевозможные skype-, jabber и другие IM-чаты. Часто в их истории остаётся очень много важных для проекта “документов”.

Подводя итог вышесказанного - документация в Agile есть, просто она немного трансформировалась, стала менее формальной, местами приобрела многий либимый в agile fun - ведь прикольно же в рабочем чате среди обсуждения очередной фичи/бага прочитать/написать несколько свежих шуток и/или ссылок. Отсутствие документации и её необходимости - это самообман. Главное, выбрать правильных формат и тогда это уже будет не так напряжно, да и актуальность будет значительно выше.

 


О стартапах пока не написал только ленивый. Говорят о них много, громко, красиво. Если раньше говорили только об успешных, то сейчас, кроме success stories все чаще слышно и об обратной стороны медали - провалах. Как маленьких, так и настоящих epic fail’ах.

Если верить википедии, то стартап - это:

Стартап или стартап-компания (от англ. start-up — запускать) — компания с короткой историей операционной деятельности. Как правило, такие компании созданы недавно, находятся в стадии развития или исследования перспективных рынков. Термин стартап стал популярным во времена пузыря доткомов, когда было создано большое количество доткомов. Новые проекты в отраслях высоких технологий часто называют хайтек стартап. Также нужно отметить что хотя этот термин можно применять ко всем сферам деятельности, однако преимущественно он получил распространение в сфере IT и интернет проектов.
http://ru.wikipedia.org/wiki/Стартап

Если коротко и без цензуры - быстро что-то сделали, продали/заработали кучу денег и радуемся жизни.

Слово “стартапер” в некоторых кругах стало модным, в некоторых (Стартапер vs Предприниматель) - ругательством. Но я хотел высказать свои мысли немного о другом. А именно:

Стартап с точки зрения разработчика: стоит ли работать в таком? делать свой?

Так как на объективность я не претендую, то можно писать то, что думаю.

Часть 1. Работа в стартапе

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

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

Часть 2. Я сделаю свой стартап!

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

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

Тут я хочу сразу ответить на возможные вопросы на счёт моего маленьго проектика notacash.com, у котором я уже писал раньше. Я НЕ считаю это стартапом. Пока это просто небольшая сайтик, который помогает некоторым людям и делает их жизнь лучше и/или интереснее. Что будет с ним дальше - сложно сказать, поживём - увидем, но пусть пока работает, разговор о другом...

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

Ведь теперь перед разработчиком не стоит задача в выпуске той или иной фичи. Задача стоит так: нужно выпустить готовый продук.

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

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

Да, можно работать без четких эстимейтов и сроков, но рано или поздно в голову подкрадывается мысль: надо же показать это кому-то! И тут начинается предрелизная стадия. Это может быть выпуск beta- или alfa-версии, запуск рабочего прототипа или ещё что-то. Но, если в этот момент появляется желание выпустить этот продукт в мир, то забываются такие вещи, как:

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

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

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


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

  • аааа! это мой голос так звучит?
  • блин, как я могу так разговаривать?
  • USB гарнитура Logitech H360 под Mac OS работает отвратительно.
  • веселая фоновая музыка
Первая запись получилась не очень, но я старался как можно меньше ее редактировать, только поубирал лишние звуки и некоторые, слишком большие, паузы.

О чем говорил:

Субъективные мысли вслух о JavaScript:

  • Недостатки JavaScript (куда же без них?)
  • Немного слов о RIA
  • Попытки избавиться от JavaScript 
  • Разработка под Android и iPhone
  • JavaScript - самый низкоуровневый язык программирования для веб
Titanium Appselerator - http://www.appcelerator.com/ 


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

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

Возможно это было в книге  С. Макконнелла “Совершенный код”, возможно в другой, сейчас книги нет под рукой и я точно не помню, была высказана отличная, на мой взгляд, идея прототипирования. Основная идея создания прототипа - быстро написать какой-то прототип будущего программного продукта для того, чтобы понять что вообще хотят пользователи/заказчики и как всё должно взаимодействовать и работать. При использовании такого подхода в прототипировании необходимо придерживаться следующих правил:

  • время создания прототипа должно быть минимальным;
  • желательно, весь код прототипа выкинуть и не использовать в готовом продукте;
  • для достижения предыдущего пункта прототип можно писать на другом языке программирования (например, вы пишете на C#, а прототип - на Java или Python).

Исходя из вышесказанного принципа, становится понятно,что в таком прототипе просто не может быть “качественного кода”, но такой код/подход всё-равно будет очень полезным. Главное, не забыть избавится от кода прототипа в финальном варианте.

Посмотри теперь что нам предлагает методология XP: постоянный рефакторинг, постоянное написание тестов перед написанием кода (TDD - Test Driven Develepment), быстрое создание архитектуры. При таком на первых стадиях/итерациях проекта невозможно добиться качественного кода. Код будет рабочим (привет TDD), но будет ли он качественным? Не всегда. А постоянный рефакторинг? Это ещё один признак того, что код не идеален. Только не сделайте вывод, что если применять XP - не получится писать качественный код. Просто надо понимать, что это самое качество будет всегда повышаться благодаря рефакторингу и unit-тестам.

Всё вышесказанное больше похоже на теорию. А как у нас обстоят дела на практике?

А практика нам показывает, что писать так хорошо, как нам хочется, не всегда можно. Сразу оговорюсь, я имею в виду написание кода на работе: мы пишем код (делаем свою работа), нам платят за это деньги. Программирование, в большей степени - это бизнес. А как известно в бизнесе: время - деньги. У кого не было ситуации, когда прибегает Project Manager или заказчик и требует что сделать эту фичу / пофиксить этот баг нужно было ещё вчера. В лучшем случае - не вчера, но через два часа всё должно быть готово. И кто в таком случае будет думать об архитектуре и качестве кода? Нужно смотреть правде в глаза: в таких случаях всем ясно, что главное выполнить требование, а качество уходит на задний план. Мы поставим комментария вида “TODO: refactor it after …” и отправим код в репозитарий. А что будет дальше с этим кодом - это уже отдельная история.

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

Подводя итог скажу следующее:

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


Те, кто фолловит меня в твиттере, уже знают о существовании сайта notacash.com. Сейчас я хочу немного рассказать о нем.

Более чем 3.5 года моя работа связана с технологиями Microsoft, в частности - .NET framework и платформа ASP.NET. Но  так, как кроме языка программирования C# существует ещё большое количество других - я решил попробовать что-то другой. Выбор пал на скриптовые языки,а именно - python. По мере приобретения теоретических знаний о python, появлялась необходимость в их практическом применении. Приложения уровня "Hello World!" быстро надоели и хотелось чего-то большего. Сначала хотел написать движок для блога, но лень взяла своё. Ближе к середине лета у меня появилась идея о создании сайта, которая в последствии переросла в сайт notacash.com. Что это за сайт и для чего он нужен - писать тут не буду, всё это уже написано на странице About.

За обновлениями можно слежить в твиттере @notacash и по RSS.

Используемые технологии:

  • язык программирования (на сервере / на клиенте) - python/javascript;
  • веб-фреймворк (на сервере / на клиенте) - django/jquery;
  • СУБД - PostgreSQL

 


Устанавливая новое SDK для Google App Engine подумал о кроссплатформенности. Для себя решил что кроссплатформенность это:

 

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

 


Первая попытка установить PostgreSQL на MacOS X потерпела крах. Пошел читать readme:

 

Вспомнились танцы с бубном в MS Dos, чтоб тот увидел больше 640К оперативной памяти, работа с extension memory (привет Паскалю). А чего стоит знаменитая фраза одного известного всем человека, о том, что нам таки хватит 640К ОЗУ. А ностальгия скорее не о ДОСе, а о том, как раньше писал код (некоторые и сейчас так пишут): оптимизировали память так, чтоб лишнего байта не занимало. А как доставалось тогда Windows'у? Лишние лишние файлы, процессы, записи в реестре дезжалостно удалялись для прибавления 1-2 мегабайт свободной оперативной памяти и нескольких десятков мег на винте. А сейчас словил OutOfMemoryException, когда процесс IIS'а в виртуалке начал есть более одного гига... Завтра буду искать memory leaks...

 

P.S. Интересный пост в тему DOS & .NET http://www.codeproject.com/KB/cs/ExpressionCompiler86.aspx