Category: история

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

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

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

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

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

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

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

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

Те, кому бы это стоило прочитать, вряд ли это читать станут, к сожалению :(

Originally posted by lantaris at Дора Насс
Мне кажется это важным

Оригинал взят у oberega в Дора Насс
Обычно не делаю репостов в журнале, но в этот раз отступлю от своего правила.

Оригинал взят у az в Дора Насс


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

Источники:
http://www.newtimes.ru/articles/detail/64032
http://www.exberliner.com/features/the-women-who-raised-the-rubble/



Я родилась в 1926 году недалеко от Потсдамерплац, а жила на Кенигетцерштрассе. Эта улица находится рядом с Вильгельмштрассе, где были все министерства Третьего рейха и резиденция самого Гитлера. Я часто прихожу туда и вспоминаю, как все начиналось и чем все закончилось. И мне кажется, что это было не вчера и даже не пять минут назад, а происходит прямо сейчас. У меня очень плохие зрение и слух, но все, что случилось со мной, с нами, когда к власти пришел Гитлер, и во время войны, и в последние ее месяцы — я прекрасно вижу и слышу. А вот ваше лицо не могу ясно видеть, только отдельные фрагменты… Но ум мой пока работает. Надеюсь (смеется).

Collapse )


41. Взаимодействие между процессами влияет на время отклика

(В оригинале - Inter-Process Communication Affects Application Response Time)

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

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

Характерный пример – ripple loading в приложениях, строящих граф отношений между объектами. Ripple loading – это последовательное выполнение большого количества запросов к базе данных для выборки данных, необходимых для построения такого графа (см. Lazy Load в книге «Паттерны архитектуры корпоративных приложений Мартина Фаулера). Если клиент базы данных – это сервер приложений промежуточного уровня, строящий веб-страницу, то запросы к базе данных выполняются последовательно в одном потоке. Их задержки суммируются, повышая общее время отклика. Даже если один запрос к базе данных занимает всего лишь 10 миллисекунд, для страницы, требующей 10 тысяч запросов (что не так уж и редко), задержка отклика составит уже 10 секунд. Другие примеры включают HTTP-запросы от веб-браузера, вызов распределенного объекта, сообщения типа «запрос-ответ» и другие подобные взаимодействия. Чем больше взаимодействий между процессами требуется для получения ответа на воздействие, тем большим будет время задержки.

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

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

Автор оригинала - Randy Stafford

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

28. Вид с высоты 300 метров

(В оригинале Get the 1000ft view)

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

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

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

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

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

Автор оригинала - Erik Doernenburg

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

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

(В оригинале - Communication is King; Clarity and Leadership its humble servants)

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

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

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

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

И если коммуникация – это король, то ясность и лидерство – его покорные слуги.

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

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