Так как периодически сталкиваюсь с этой темой решил высказать свое мнение и заодно поспорить на тему “Насколько легко программисту выучить новый язык и писать на нем”.

Я неоднократно слышал утверждения о том, что хорошему программисту выучить новый язык и писать на нем качественный софт/код не составит труда. Со своей стороны, я уже второй раз поменял основной язык, на котором пишу/зарабатываю на хлеб с маслом. Сначала был C#/.NET, как правило, это был веб, ASP.NET/ASP.NET MVC. Часто приходилось писать на JavaScript, потом практически полностью ушел от серверной части и писал Front-end на JS. Переход на JavaScript был для меня безболезненным, даже не смотря на поддержку IE6 :). Тем временем познакомился с Python и через какое-то время перешел полностью на него. Исходя из такого, пусть и небольшого, программерского опыта утверждаю что переход на другой язык программирования - это почти всегда обучение с нуля, переход, грубо говоря, от Senior (которым я себя никогда не считал) к Junior.

Почему так? Почему нельзя “научиться писать на другом языке за две недели/месяц/два месяца”? Потому что не все так просто. Даже если взять похожие, на первый взгляд Java и C# то трудностей будет много. Да, синтаксис во много похожий, но знаний только его не достаточно для разработки ПО. Ведь если кто-то выучит 100-200-1000 слов другого языка нельзя же сказать, что человек теперь знает другой язык и может свободно писать/читать/говорить на нем? Почему тогда отношения к программистам и языкам программирования другое? Кроме синтаксиса, есть еще понимание платформы, фреймворков, технологического стека и т.д. Да, синтаксис похож, да, веб-фреймворки, реализующие, например, MVC паттерн чем-то похожи по своей структуре и принципам работы, но все-таки отличия есть. 

Смотря на свой код, который писал после прочтения книги что-то вроде “Django для чайников” мне хочется плакать, выкинуть его и никогда не вспоминать. А ведь код-то рабочий. И делает то, что от него нужно. Но... но стиль мышления у меня тогда был как у asp.net разработчика и многие вещи из python/django мне были не понятны. Тогда я знал синтаксис, но не знал python. IMHO, тут есть очень важный психологический барьер, который не всегда бывает просто преодолеть. Когда нужно признаться себе что ты снова ничего не знаешь и нужно учиться заново, проходить путь от “hello world” до каких-то сложных приложений. И только когда снова появятся знания и понимания того языка/платформы/фреймворка, на котором пишете, тогда можно будет сказать что вы что-то знаете, а не лезете каждый раз в документацию или ищете похожие примеры.

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

 


 

Небольшой список того, что хотелось бы сделать в этом году:

  • дочитать книги Learning Python & Prorgamming Python;
  • опрделиться до конца с форматом блога;
  • вывести со статуса beta notacash.com и доделать там всё, что планировал;
  • разобраться с CQRS и дописать брошенное django-cqrs;
  • ещё больше перейти на лицензионный контент (в первую очередь софт, книги, музыка);
  • прочитать всё из  http://www.etnogenez.ru/;
  • сделать регулярными встречи KharkivPy;
  • закончить начатое в 2011-м.
Как-то так.

С Новым годом!

 


 

Никогда не знаешь, где упадет 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

 


e0ne's comments

A Web Developer's Blog!