Category: технологии

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

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

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

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

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

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

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

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

Елочные гирлянды... ностальгия :)

В детстве у родилелей для елки на новый год была единственная гирлянда - с довольно крупными патрончиками, с 4.5 вольтными лампочками внутри, а в патрончики вставлялись цветные ампулы в виде свечек с водой и каким-то веществом на дне, которое при нагреве начинало пузырьки активно выделять. С подсветкой снизу смотрелось красиво :) Помню, как включал и ждал, когда же они булькать начнут - требовалось 5-15 минут, чтобы вещество нагрелось.

Потом я увлекся электроникой, освоил паяльник. И однажды собрал гирлянду из микро-лампочек. Которые для пущего эффекта красились лаком для ногтей в разные цвета :)

Потом пришло время добавить анимации - и была собрана схема из журнала "Юный техник", делающая "бегущие огни" из четырех гирлянд (тех самых, собственной сборки). На тиристорах, конденсаторах на 250 вольт и двухваттных резисторах. Грелось это все очень ощутимо, но - работало :) И до сих пор живет :)

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

Пара зарисовок.

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

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

Въезд в самый большой в Любляне торговый центр. На въезде висит большая реклама новой кафешки, извещающая о том, что "мы открылись" - не заметить рекламу невозможно, смотрю на нее каждый раз, когда въезжаю. Уже раз десять, идя на обед, испытываю желание зайти к ним, попробовать чего-нибудь нового. Но не могу. Потому что я не знаю, где именно они открылись! В рекламе не посчитали нужным об этом сообщить, а торговый центр реально очень большой.

52. Дайте проекту голос

(В оригинале - Let Your Project Speak for Itself)

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

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

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

Идея ЭОС – в управлении каким-либо реальным физическим устройством: лампой, фонтанчиком, игрушечным роботом или даже запускателем ракеты, основанном на результате автоматического анализа. Как только ваши лимиты будут нарушены, устройство сработает. Например, загорится лампочка. Не заметить подобное срабатывание будет очень сложно.

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

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

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

Автор оригинала - Daniel Lindner

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

6. Перед началом рефакторинга

(В оригинале - Before You Refactor)

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


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

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

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

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

  • Личные предпочтения и эго не должны быть ведущим фактором. Если что-то работает, зачем это исправлять? То, что стиль или структура не соответствует вашим персональным предпочтениям, недостаточно для начала реструктуризации. Мысль о том, что вы можете написать лучше, чем ваш предшественник, тоже не является достаточной причиной.

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

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


Автор оригинала - Rajith Attapattu

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

53. Давайте разработчикам больше полномочий

(В оригинале - Empower developers)

Говорить гораздо проще, чем делать, и архитекторы ПО печально известны как раз первым. Чтобы ваши слова были не пустым сотрясением воздуха (что однако часто используется для создания vaporware*), вам нужна довольная команда разработчиков. Роль архитектора обычно заключается в установке ограничений, но архитектор может быть и тем, кто разрешает. Для этого вам нужно давать все возможные полномочия вашим разработчикам.

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

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

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

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

Автор оригинала - Timothy High

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

51. Проверяйте предположения, особенно собственные.

(В оригинале - Challenge assumptions - especially your own)

"Предположение – причина большинства неудач", или более популярно: "Don’t assume – it makes an 'ass' of 'u' and 'me', что в дословном переводе звучит как «Предположения делают из нас ослов», увы, не передавая замечательную игру слов оригинала. И когда речь заходит о предположениях, за которыми стоят тысячи или даже миллионы долларов, то вышеприведенная фраза – уже не просто смешная шутка.

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

Эта практика хороша тем, что когда эти факторы перечислены, то это может помочь выделить те предположения, которые были у архитектора, ответственного за разработку ПО. И часто эти предположения основаны лишь на «исторических причинах», традициях разработки, FUD-е или же даже на «Я где-то что-то об этом слышал»:

  • Open source проекты недостаточно надежны
  • Bitmap индексы приносят больше проблем, чем пользы
  • Заказчик никогда не согласится, что страница грузится пять секунд
  • Директор согласится только на продукцию крупного вендора

Важно сделать эти предположения видимыми ради потомков и для будущего анализа. Однако еще более важно убедиться, что все предположения, не имеющие адекватного эмпирического подтверждения, проверяются перед тем, как решение окончательно принято. Что, если заказчик не будет возражать против пятисекундной загрузки страницы, если добавить на нее прогресс-бар? Какой именно open-source проект ненадежен и как именно ненадежен? Тестировали вы bitmap-индекс на ваших данных?

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

Факты и предположения – основа, на которой строится ваше ПО. Какими бы они ни были, будьте уверены в том, что они согласованные.

Автор оригинала - Timothy High

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

3. Скорее всего, ваша главная пробема - не техническая

(В оригинале Chances are your biggest problem isn't technical)

Прямо сейчас чей-то проект стремительно катится к полному провалу. Возможно даже, что и не один.

А почему? Может быть, потому что кто-то выбрал Ruby вместо Java? Или может быть Python вместо SmallTalk? Или же потому, что было принято решение использовать Postgres вместо Oracle? Или же вместо Windows надо было выбирать Linux? Все мы так или иначе сталкивались с технологиями, якобы приведшими проект к провалу. Но каковы на самом деле шансы того, что задача реально будет столь сложной, что ее невозможно будет решить, используя Java?

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

С высокой долей вероятности на вашем проекте найдется кто-то, кто, как вам кажется, «делает все не так» и тем самым расшатывает весь проект. И если это так, то технология, необходимая вам для решения, на самом деле стара как мир. Возможно, эта технология – самая главная инновация во всей истории человечества. Эта технология называется "ведение переговоров".

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

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

1. Переговоры не должны быть противостоянием

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

2. Начинайте переговоры лишь когда вы в хорошем настроении.

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

3. Используйте это как возможность достигнуть взаимных договоренностей на пути к цели.

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

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

Автор оригинала: Mark Ramm

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

1. Ваше резюме не должно быть на первом месте.

(В оригинале Don't put your resume ahead of the requirements)

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

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

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

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

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

Автор оригинала: Nitin Borwankar

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