Category: it

Верхний пост :)

Основной мой вид деятельности на данный момент - разработка ПО в области embedded. Опыт работы - с 2001 года. Сайт-визитка по этой теме: http://avl2.info/.

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

1. Естественные роды. Все - на основании собственного (почти :)) опыта рождения двух детей. Я оба раза присутствовал на родах, во второй раз мы вместе с женой составляли план родов, выбирали и общались с акушерками, ходили на курсы подготовки и многое-многое другое :) Опыт вылился в сайт http://ru.naravniporod.com/. Буду рад ответить на вопросы, если кого-то мой опыт заинтересует подробнее.

Если же кому-то предстоят роды в Словении и его будет страшить неизвестность и неопределенность - как, где, с кем и т.п., тоже буду рад помочь, пишите!

2. Фотография. Началось это увлечение еще с 1996 года, с фотоаппарата "Смена 8М" и черно-белой пленки, проявки ее в бачке и печати фотографий в ванной под увеличителем и красным фонарем. Кое-что из того, что получается сейчас, можно увидеть здесь по тегу "Фото". Коммерческое предложение с ценами и вариантами - на еще одном моем сайте http://www.lepitrenutki.com/, который, правда, на словенском языке - для целевой аудитории.

И если вы планируете поездку в Словению (или ближайшие ее окрестности) и хотите, чтобы у вас на память остались фотографии, на которых бы были запечатлены и вы тоже (или вы вдвоем с партнером, или вся ваша семья) - буду рад оказать такую услугу. По себе знаю, что тот, у кого в руках фотоаппарат, очень редко сам оказывается в кадре. К тому же, часто приходится выбирать: сфотографировать момент или прожить его. И не лучше ли будет выбрать "прожить", а для "сфотографировать" нанять фотографа? :) Особенно в поездке в такую красивую страну, как Словения :)

3. Гимнастика для новорожденных. С первым ребенком я открыл для себя динамическую гимнастику. Со вторым - познакомился с абсолютно другим подходом, автором которого является словенка Андрея Семолич, и который она назвала "Педокинетика". (Сайт тоже на словенском). Подход очень и очень интересный, отлично дополняет собой динамическую гимнастику, со вторым ребенком я прошел всю ее методику, начав с 6 недель и закончив моментом, когда малыш начал делать первые шаги. И очень доволен результатом. В мае 2013 года я получил сертификат инструктора "Педокинетики" первого уровня (после двух лет обучения, в том числе более 200 часов практики с реальными детьми и 6-часового экзамена на реальных и непростых группах). Впереди еще минимум три года обучения :) Так что в ближайшее время появится еще одно направление в моей деятельности :) По которому я тоже буду рад помочь тем, кого это заинтересует!

О наболевшем Атмеле

Оказалось, что я здесь не писал ничего о том, что же так наболело в связи с Атмелом (о чем упоминал в посте про Embedded World). Об этом рассказано вот тут: http://habrahabr.ru/post/147025/.

И да, пока так никто из Атмела не связался и ничего не прислал :)

Перевод "97 Things Every Programmer Should Know"

97 вещей, которые должен знать каждый программист.



Оригинал лежит вот тут.

Collapse )

Текст оригиналов выложен под лицензией Creative Commons Attribution 3. C переводами можете поступать так же :)

Переводы (к сожалению, только часть) серии "97 вещей, которые должен знать каждый архитектор ПО", можно прочитать тут

Еще о системах контроля версий

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

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

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

Если кому лень читать оригиналы на английском, то вкратце там вот что. Он утверждает, что Mercurial - это нереальный шаг вперед, новая модель контроля версий и новая модель мышления, и что стоит забыть все то, что было ранее, в частности, SVN. Мол, проблема SVN в том, что она хранит версии файлов, а Mercurial хранит отличия между версиями. И вроде как именно это позволяет Mercurial решать нерешаемые в SVN задачи одним кликом мыши и вообще нереально облегчать работу всей команде разработки. Только надо сначала изменить свое мышление и начать тоже мыслить не версиями файлов, а их изменениями. И вообще, вот прямо сейчас все, кто используют SVN, должны все бросить и перейти на Mercurial :)

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

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

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

Допускаю, конечно, что я чего-то не заметил, но пока картинка для меня выглядит именно так - все отличия Mercurial от SVN - это ее распределенность, и не более того.

67. Программист - профессионал

(В оригинале - The Professional Programmer)

Кто же это – программист-профессионал?

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

  • Если вы профессионал, вы ответственны за свою карьеру. Вы ответственны за обучение себя. Вы ответственны за то, чтобы идти в ногу со временем и технологиями. Слишком много программистов думают, что обучение – это забота работодателя. Увы, это совсем не так. Вы думаете, врачи так делают? Или адвокаты? Нет, они совершенствуются в свое личное время и за свои личные средства. Они тратят значительную часть своего личного времени на чтение тематических журналов. Они идут в ногу со временем. И вы должны делать также. Отношения между вами и вашем работодателем четко прописаны в контракте. Кратко – они вам платят, вы делаете свою работу хорошо.

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

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

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

  • Профессионалы не создают хаоса. Они гордятся своей квалификацией. Они поддерживают код чистым, хорошо структурированным и легко читаемым. Они следуют стандартам и общепринятым практикам. Они никогда не суетятся. Представьте, что вы в состоянии клинической смерти парите над своим телом, над которым работает кардиохирург. У хирурга очень жесткое ограничение времени – он должен успеть все сделать до того, как насос системы жизнеобеспечения не повредит вам слишком много клеток крови. Как бы вы хотели, чтобы он действовал? Хотели бы вы, чтобы он вел себя как типичный разработчик, суетясь и сея хаос? Хотели бы вы услышать «Я исправлю это в следующий раз»? Или бы вы хотели, чтобы он был сдержанным и спокойно делал свою работу как можно лучше? Вы предпочтете хаос или профессионализм?

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

Автор оригинала - Uncle Bob

66. Предотвращайте ошибки

(В оригинале - Prevent Errors)

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

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

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

Ошибки форматирования – еще одна общая проблема. Например, если пользователю предоставлено текстовое поле для ввода даты, и он вводит туда «29 июля 2012 года», то не очень хорошо не принимать этот ввод только потому, что он не в формате «дд\мм\гггг». А еще хуже отвергать «29 \ 03 \ 2012» из-за лишних пробелов – пользователю будет сложно понять, в чем причина, ведь дата вводится в запрашиваемом формате.

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

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

Подсказки отличаются от инструкций. Подсказки появляются в момент взаимодействия, инструкции – перед ним. Подсказки предоставляют контекст, инструкции диктуют поведение.

В большинстве случаев инструкции неэффективны в предотвращении ошибок. Пользователь ожидает, что интерфейс будет работать привычным для него образом (Ведь каждый знает, что значит «29 июля 2012 года», не так ли?). Поэтому инструкции никто не читает. А подсказки подталкивают пользователя к правильному варианту.

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

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

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

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

Автор оригинала - Giles Colborne

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

65. Используйте типы из вашей предметной области

(В оригинале - Prefer Domain-Specific Types to Primitive Types)

23-го сентября 1999 года орбитальный комплекс ценой в 327.6 миллиона долларов был потерян при выходе на орбиту Марса. Виной всему стала ошибка в программном обеспечении, позже получившая классификацию «перепутанная метрика». Наземная часть системы управления использовала британскую систему (где сила измерялась в фунтах силы), а компьютер аппарата – метрическую (в ньютонах), в результате мощность маневровых двигателей была занижена в 4.45 раза. (Подробнее об этом можно прочитать тут или более подробно и на английском тут )

Этот и множество других примеров ошибок могли бы быть предотвращены, если бы использовался более строгий механизм типов предметной области. Это также объясняет множество свойств языка Ада, одной из основных целей разработки которого была реализация встраиваемых систем высокой надежности (safety-critical). Язык Ада использует строгую типизацию с проверкой на этапе компиляции как встроенных типов, так и типов, определенных пользователем.


type Velocity_In_Knots is new Float range 0.0 .. 500.00;
type Distance_In_Nautical_Miles is new Float range 0.0 .. 3000.00;

Velocity: Velocity_In_Knots;
Distance: Distance_In_Nautical_Miles;
Some_Number: Float;

Some_Number:= Distance + Velocity; -- В этом месте компилятор выдаст ошибку типизации.

Разработка приложений в менее критичных областях тоже может воспользоваться этим преимуществом определяемых типов вместо использования встроенных вроде string или float. В Java, C++, Python и других языках абстрактный тип – это класс. Использование классов вроде Velocity_In_Knots и Distance_In_Nautical_Miles значительно повышает качество кода:

  • код становится более читаемым, поскольку явно указываются значения из предметной области в отличие от «общих» типов Float или String;
  • код становится более тестируемым;
  • код способствует повторному использованию.

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

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

Автор оригинала - Einar Landre

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

64. Состояние потока и парное программирование

(В оригинале - Pair Program and Feel the Flow)

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

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

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

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

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

  • Снижение «фактора грузовика». Немного цинично, но все же: скольких членов вашей команды должен переехать грузовик, чтобы команда не смогла успешно завершить проект? Другими словами, насколько вы зависите от конкретного разработчика? Знания распределены или сосредоточены? Если вы используете ротацию пар и задач, то всегда будет кто-то еще, обладающий такими же знаниями и способный завершить задачу. В результате поток команды менее подвержен «фактору грузовика».
  • Эффективное решение проблем. Если вы программируете в парах и сталкиваетесь с проблемой, то у вас всегда есть с кем ее обсудить. Подобные обсуждения наиболее вероятно приведут к результату, а в одиночку вы могли бы застрять. А из-за ротации задач ваше решение станет известно следующей паре, которая может его улучшить, если вы выбрали не самый оптимальный вариант.
  • Устойчивость к прерываниям. Если кому-то нужно будет задать вам срочный вопрос, или зазвонит телефон, или вам нужно будет ответить на срочный е-мейл, то ваш партнер в паре может продолжать двигаться вперед. Когда вы закончите свои дела и вернетесь к проекту, ваш партнер будет все еще в потоке и вы быстро присоединитесь к нему.
  • Быстрое включение новичков. В парном программировании, особенно при правильной ротации пар и задач, новички быстро входят в курс дела, узнают особенности кода и других членов команды.

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

Авторы оригинала - Gudny Hauknes, Ann Katrin Gagnat, and Kari Røssland

63. Сделайте процесс сборки своим

(В оригинале - Own (and Refactor) the Build)

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

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

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

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

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

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

Автор оригинала - Steve Berczuk

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

О винде - таки счастливый конец :)

Начало - тут

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

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

Заняло все "всего лишь" три часа :) За это время я ознакомился с дебаггером под винду (windows debugging tools) и узнал, что таблицы символов к винде можно бесплатно скачать с сайта микрософта :)

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

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

Еще через пару дней пришло очередное письмо, что они нашли настоящий код ошибки: 80040154, что означает REGDB_E_CLASSNOTREG, и в качестве решения набрать в командной строке "wscript –regserver"

Ага, было бы слишком просто :) Не помогло. Следующим шагом стала загрузка еще одного монитора: http://technet.microsoft.com/en-gb/sysinternals/bb896645.aspx (кстати, интересная тулзовина!) и запись лога возникновения ошибки.

На этот раз в 6 мегабайтном логе (сгенерированном менее чем за пару секунд!) был найден виновник!!! Wscript валился, не найдя вот такой вот ключ в реестре:

HKCU\Software\Classes\CLSID\{0D43FE01-F093-11CF-8940-00A0C9054228}

который со слов техсаппорта отвечал за сервис SCRRUN.DLL

Последняя рекомендация набрать в командной строке "regsvr32 scrrun.dll" решила проблему!

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

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

Но БЛИН насколько бы было все проще, если бы вместо "ActiveX component can't create object" винда выдавала бы "scrrun.dll not registered"! Ведь ВСЯ информация об ошибке была, но была спрятана в "недрах" операционки и без дополнительных инструментов недоступна "простым смертным"...