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

 

11:00. Пришел на работу. Нужно сделать кофе.

11:10. Хорошо, теперь можно пописать код.

11:11. Что за [IMPORTANT] письмо такое свалилось?

12:30. Разгреб почту, ответил начальству, поддержке и коллегам. Можно писать код.

12:45. Синк-ап.

13:00. Нужно написать недельный репорт чем занимался.

13:30. Обед - не сегодня, лучше попишу код.

13:35. Опять тесты на CI завалились.

15:30. Нашел проблему в другом компоненте и две у себя. Фикшу баги.

18.00. Чашечка кофе с печенькой будет не лишней.

18:15. Нужно занться планированием на следующую итерацию.

18:30. Как у кастомера ничего не работает???

20:00. Вот сейчас таки займусь этой фичей, которую все давно ждут.

20:30. Что значит что нам надо пофиксить все баги до понедельника?

21.00. Bug Fixed. Завтра утром попишу код и сделаю фичу. Там всего-то 2 часа делов и час на написание тестов...


Выбор версии языка программирования, фреймворка - сложный вопрос, который всегда бурно обсуждался и будет обсуждаться. В enterprise мире часто, но не всегда, используют старые и проверенные инструменты. В то время как Python 2.7 все еще нет из коробки в RedHat/CentOS/др дистрибутивах, в некоторых уже используется Python 3.3, пусть и не в качестве системного. В мире opensource - наоборот, часто используют только самое-самое новое. Но это правило не относится к разным фреймворкам. Представьте, что завтра, например, Django будет поддерживать только Python 3.4, который еще не зарелизился. Никто им пользоваться не будет. Вот и приходится поддерживать несколько версия языка программирования. Похожая ситуация с paramiko, nose и другими популярными проектами/инструментами/библиотеками.

Сегодня, пытаясь настроить Travis CI для небольшокго плагина для nose (https://github.com/mahmoudimus/nose-timer), столкнулся с проблемой немного удивился в отличии списка поддерживаемых версия питона nose, а в следствии и nose-timer, и Travis CI. Travis работает только с несколькими самыми используемыми версиями - 2.6, 2.7, 3.2 и 3.3 (http://about.travis-ci.org/docs/user/languages/python/). Для меня это показатель: раз такой популярный инструмент поддерживает эти версии, то следует задуматься какие версии python'а нужно поддерживать в своих библиотеках.

 

P.S. А тем временем стал доступен Python 3.4.0 beta 2.


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

По сути, всем все-равно в какой IDE пишете код, если он работает так, как надо и написан вовремя. Унификация средст разработки внутри компании/команды лишь облегчает жизть менеджерам, ИТ, новым членам команды и упрощает коммуникацию между разработчиками. Ведь на много легче один раз написать инструкцию по установки всего нужного для запуска проекта ПО, например, для Ubuntu 13.10 x64 и запуск проекта в PyCharm, чем каждый раз сталкиваться с проблемой как запустить X в окружении Y.

Но каждый разработчик в праве решать сам чем он будет пользоваться. Вот только к выбору инструментов нужно подходить “с умом”. Главное - хорошо знать инструменты, которыми вы пользуетесь. Иначе будет ситуация, когда используется Photoshop только для изменения размера картинки. Досконально знать OS, IDE, текстовый редактор, которым пользуетесь каждый день не только приятно, но и полезно. Это может экономить массу времени. Всем известно, что использования горячих клавиш, в некоторых условиях, в разы быстрее, чем совершать нужные действия мышкой. Аналогичная ситуация с разнообразными инструментами автоматизации. Если мне нужно выполнить действиее более 2-3х раз - я пишу небольшой скрипт на bash или python. Иногда скрипты получаются не очень и маленькими, иногда в помощь приходят fabric/chef/puppet. Готовые настройки для используемых редактором и систем (профайлы bash, zsh) - упрощают жизь и экономят время, которое можно потратить на более полезные и интересные вещи.

Все вышесказанное всем известно и описано в множестве книг и постов. Захотелось повторить, т.к. я в очередной раз наступил на эти грабли: потратил почти час на написание простого скрипта на bash’е, аналог которого на python мне удалось написать за 10 минут. Да, я узнал кое-что новое о bash, но это не мой основной язык программирования, и скрипт писался исключительно для себя (и не важно, что любой может скачать его с github и пользоваться), но я потратил массу времени из-за того, что выбрал не тот инструмент. Нельзя путать процесс обучения и процесс разаботки. Между ними очень тонкая грань, которую легко перейти и потерять время напрасно.


Как всегда, в рубрике “мысли в слух” звучит только исключительно мнение автора и может не соответствовать действительности.

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

Случай #1. Работает - не трожь!

Очень распространенный и нелюбимый мною случай. Проекту N лет, заказчика он устраивает, клиенты довольны. Но проект еще развивается, нужно не только фиксить баги, но и улучшать текущую, добавлять нувою функциональность. Но что бы добавить одну простую новую функцию, нужно написать “много” кода, который уже есть в новой версии фрреймворка X, который используется. А новая версия может быть несовместима со старой. А если и совместима - нет гарантии что все быстро и хорошо заработает. Часто бывает что проще и дешевле переписать с нуля. И вот тут должен выключаться режим разработчика и включаться режим владельца бизнеса. На основе естимейтов по переходу на новый фреймворк, можно посчитать что дешевле: дописать старое или написать, частично или полностью, новое. Наверняка, в каких-то правильных книжках по менеджменту (возможно, не только для ИТ) и/или економики уже есть готовые формулы для этого, но я не встречал такого. Самое сложное здесь то, что формула будет не такой простой, как может показаться изначально.

Например:

Функция А будет сделана(разработанна, протестированна, задеплоенная - вообщем, готова для использования) за 30 часов на старом фреймворке и за 20 на новом. Умножая кол-во часов на n денег легко посчитать как дешевле. Но тут нужно учитывать всевозможные риски с новым фреймворком - его баги, баги после миграции, стоимость изучения и т.д.

Пример выше сильно упрощен и я не сталкивался с таким в работе. Обычно, все выглядит так (цифры придуманы):

Функция А будет сделана(разработанна, протестированна, задеплоенная - вообщем, готова для использования) за 10 часов на старом фреймворке и за 50 на новом. Разница по деньгам и времени - в 5 раз. Тажело будет уговорить менеджера и/или заказчика. Но тут на решение должны влиять другие факторы, а именно:

 

  • каждая новая фича будет стоить дешевле из-за того, что разработчики уже выучат матчасть, набьют новые шишшки с новым фреймворком и т.д., в последствии чего - в идеальных условиях, время разработки будет стремится к времени на разработку этой же фичи на старом фремйворке - n часов.
  • во время миграции на новый фреймворк, пользователи продукта не будут видеть новых версий, что сильно влияет на time to market (TTM), может пказаться, что продукт больше не развивается.
  • на протяжении этого всего времени, нужно будет поддерживать старую/текущую версию продукта, что тоже стоит денег.
  • переписанный продукт на новый фреймворк X - часто является скорее новым продуктом, чем новой версией старого, со всемы вытикающими последствиями.

 

 

Случай #2. “Теперь мы используем фреймворк X версии Y” или “у нас новый проект на фреймворке X версии Y”.

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

 

Случай #3. Идеальный процесс разработки продукта.

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

 

  • продукт будет выпущен в оговоренные сроки
  • дена дальшейшей разработки будет снижаться
  • цена поддержки будет низкой

 

Допустим, дата релиза запланированна на весну (сейчас декабрь). К тому времени должна выйти новая версия хорошо известного фреймворка X, а сейчас доступна совсем не production ready alpha. Т.к. авторы этого фреймворка всегда выпускают релизы вовремя(у нас же идеальная ситуация:) ), то можно начать писать на нем. Но т.к. у нас в руках очень сырая и нестабильная alpha версия, то нам нужно обезопасить себя от всяческих рисков и проблем, связанных с багами и недоработками фреймворка. Я вижу только один действительно рабочий способ - внедрение continuous integration процесса в полной его мере: покрытие всяческими тестами и постоянный их запуск. Таким образом, особенно при хорошем покрытии кода unit-тестами, мы можем отделить ошибки которые связаны с нашим кодом, от тех, что зависят от фреймворка и/или сторонних библиотек.

Таким образом мы берем на себя технологический риски, связанные с “сырым” фреймворком и возможные потери денег как на разработку продукта, так и на возможную недополученную прибыль от его использования и/или продажи. Но если все будет хорошо, и проект успешно выйдет в production, то мы получим следующие плюсы от этого:

 

  • малое значение TTM - продукт выходит на рынок как только пояляется новая технология/фреймворк
  • вы становитесь early adopters выбранного вами фреймворка
  • качество продукта будет достаточно высоким (см. о continuous integration)
  • счастливые разработчики, использующие самые последние технологии и фрейморки
  • разработка следующей версии продукта стартует быстрее (есть наборы тестов, CI) и так же может быть на еще более новой версии фреймворка

 

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

 

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



Build succeeded, 156 warnings

Published 11/18/2013 by e0ne in Offtopic

Запустил “make build” и получил 156 ворнингов:(... Хотя, достаточно быстро получил более радужное число - 69, что тоже не мало. Нужно фиксить дальше, а пока - немного очень IMHO на эту тему.

Отключать или нет параметр “mark warnings as errors” (название может отличаться, но суть остается той же) - часто решают для конкретного проекта и/или команды. Иногда это не мешает работы продукта. Я бы сказал что в 98% случаев это не мешает, зато остаются 2%. И баги, попавшие в те самые 2%, часто являются самыми трудновоспроизводимимы и затратными по времени на исправления.

Итак, из-за чего появляются warnings? Самые частиы причины - это:

  • использование deprecated и/или недокументированного API.
  • несоответствие кода гайдлайнам (guidelines) и/или принятым стандартам языка программирования, фреймворка и т.д.
  • проблемы с настройкой окружения (environment).

Что плохого в использовании deprecated API? Ничего, если приложение будет удалено не посже, чем сразу после перговго запуска. В противном случае, рано или поздно, после очередного обновления используемой платформы и/или фреймворка что-то перестанет работать, т.к. deprecated код будет удален. Таким образом, ваш код, который использует устаревший API фреймворка, автоматически становится deprecated :). Готовы ли вы писать заведомо legacy код?

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

Код, который не соответствует стандартным гайдлайнам, как минимум, - странный. IMHO. Нет, я понимаю, что при использовании StyleCop (для C#) практически невозможно писать код, соответствующий всем его требованиям, но для того же Python’а, держать код в соответствии с PEP-8 достаточно просто. Трудности бывают только с 80-ю символами в строке. С PyLint все немного сложнее. Но никто не заставляет выполнять все требования. Главное - здравый смысл и правильная настройка инструментов, которые используются.

Проблемы с настройкой окружения. Тут не буду много писать, т.к. эта тема тянет на отдельный пост в блоге, который уже давно хочется написать. Скажу только то, что один и тот же код (id коммита, tag, и т.д.) должен, по возможности, собираться одинаково на всех используемых окружениях. Это, как правило, рабочий ПК разработчиков и тестировщиков и билд-серверы. Иначе где-то что-то пойдет не так.

Не попал в мой классификацию еще один случай - содержимое stderr. Бывает, что только туда пишуться какие-либо предупреждения, которые остаются непрочитанными. Давно уже руки тянуться помечать все билды как failed, если что-то есть в stderr, но пока это сделать не получается, т.к. “хороший продукт !== работающий и/или безбажный продукт”, а “хороший продукт == радующий пользователя/заказчика продукт”. Как-то так.



Суббота, вечер, пишу очень IMHO. Мнение атора может не совпадать с мнениями других и действительностью.

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

 

  • Outsourcing - вроде все понятно, самый популярный вид разработки в наших краях, но бывает разный
    • product development - когда вся разработка происходит тут, у нас, менеджмент тоже свой, но заказчик кто-то из вне. Собственно заказчик, со всемы вытикающими отсюда плюсами и минусами, единственное, что отличает этот пункт, от пункта "own product
    • "классический аутсорс" (не знаю как правильно называется) - когда заказчик возводится чуть ли не до уровня Бога, а мы для него становимся просто дешовой рабочей силой, которая должна молча, быстро и хорошо выполнять задачи, которые меняются по срокам, целям и приоритетам по неизвестной для нас причине.
  • Outstuffing - когда продают команду, фактически, команда тут становится равноправной командой заказчика, просто удаленной.
  • Own Product - разработка своего продукта. Не все так радужно и классно, как может показаться на первый взгляд. Если это первая версия - то да, драйв, код и рок-н-ролл: мы выбираем технологии, фичи, делаем эстимейты, никакого легаси кода. Но как только продукт может случиться такое: начинает использоваться, появляется легаси код, архитектура становится не такой классной и т.д.
  • Startup - модно, стильно, быстро. Иногда много денег, иногда - нет. Сложность и интересность проектов (с точки зрения разработчиков) зависит только от фантазии основателя и наличие энтузиазма/денег на еду у программистов. Риски тут 50/50 - или повезет, или нет.

 


Читая серию заметок Кости Данилова "Облака 'на коленке'" подумалось: велосипеды - это хорошо. Но, что б это было хорошо, они должны соответствовать таким требованиям (1 или более):

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

P.S. заметка на память:
решить что делать: избаиться от велосипедов в движке блога или таки напистаь свой на какой-то из новых и интересных для меня технологий.


В очередной раз чуть не наткнулся на давнюю проблему, но вовремя опомнился. При pylint “радостно” сообщил, что в некоторых модулях есть unused imports и их можно(нужно) удалить. Все было бы хорошо, если б не одно но: python очень даже динамический язык, а pylint ничего не знает о том, что будет происходить с кодом во время выполнения. Исходя из этого, уже можно представить какие проблемы могут быть. В моем случае, код был такой:

from quantum.openstack.common import cfg
...
from quantum.plugins.openvswitch.common import config

И pylint “ругался” на 2-й импорт, который нигде больше не использовался. Но если посмотреть на код этого модуля (https://github.com/openstack/quantum/blob/master/quantum/plugins/openvswitch/common/config.py) и вспомнить как работает механизм импорта в Python’е, то становится ясно, какие проблемы могут быть: при загрузке модуля config, он устанавливает значения по умолчанию настроек. А так, как со всемы настройками принято работать через общий интерфейс cfg, и не импортировать можуль config, то, с большой вероятностью, где-то в runtime у нас произойдет исключение. 

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

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

Вот интересно, если бы не unit-тесты и понимание работы import’ов, сколько бы времени потратил на фикс бага, после такого “улучшения” кода?


 

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

Я неоднократно слышал утверждения о том, что хорошему программисту выучить новый язык и писать на нем качественный софт/код не составит труда. Со своей стороны, я уже второй раз поменял основной язык, на котором пишу/зарабатываю на хлеб с маслом. Сначала был 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-м.
Как-то так.

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