Category: медицина

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

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

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

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

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

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

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

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

Никон Д60 - продолжение

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

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

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

Но через еще кадров 400 сообщение об ошибке повторилось. Еще одна разборка - и до конца отпуска хватило.

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

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

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

Ибо невозможно поверить, что вся разница в цене между линейкой Д40-60-3000-5000 и Д90-7000 - лишь в механизме затвора, и что использовать один и тот же затвор (с гарантированными 100 тыс. срабатываний) во всех моделях было бы более затратным, чем разработка "с нуля" нового затвора с пониженной надежностью...

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

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

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

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

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

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

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

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

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

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

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

О родах в Голландии

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

И вот в этом исследовании взяли и сравнили две группы - плановые роды дома и плановые роды в больнице. И там, и там брались только "low risk" - те, у кого не было никаких осложнений и прочего ("high risk" у них рожают только в больнице).

Рассмотрели они 163 тысячи больничных родов и 321 тысячу домашних - выборка очень даже достаточная. И на этой выборке значимого различия в проценте смертности обнаружено не было! (0.05% для домашних и 0.04% для больничных родов).

По нашим роддомам статистики по "low risk" я не видел, общую же статистику сравнивать с голландской будет не очень корректно ("high risk" как раз и вносит самый основной вклад в эти проценты), однако цифра 2005 года - это около 1%!

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

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

37. Не работайте сверхурочно.

(В оригинале - Hard Work Does not Pay Off)

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

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

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

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

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

Автор оригинала - Olve Maudal

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

24. Не бойтесь что-нибудь сломать!

(В оригинале - Don't Be Afraid to Break Things)

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

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

Не бойтесь своего кода. Кого интересует то, что какие-то части не будут работать, пока вы будете вносить изменения? Страх изменений и привел проект к столь запущеному состоянию. Инвестиции в рефакторинг окупятся многократно в течении жизни проекта. Ваша команда, поработав с «больной» системой, получила ценный опыт с точки зрения того, как система должна была быть написана правильно. Так возьмите и примените эти знания. Работать с системой, которую вы ненавидите – это не то, на что стоит тратить свое время.

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

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

Автор оригинала - Mike Lewis

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