Category: архитектура

Category was added automatically. Read all entries about "архитектура".

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

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

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

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

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

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

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

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

Семейные расстановки

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

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

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

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

Посмотрим, что будет дальше.

Тем, кто в Харькове - могу дать контакт ведущего. Думаю, от ведущего эффективность техники тоже зависит. Остальным могу рекомендовать попробовать - техника распространена практически везде. Ключевое слово - Хеллингер.

Термы Тополшица и окрестности

Много раз по пути из Любляны в Грац и назад я замечал на автобане указатель "Термы Тополшица. Мозирский гай". Мозирский гай, к примеру, упоминается среди сотни мест Словении, которые стоит посетить. И вот однажды на скидочном сайте появилось предложение "Две ночи в термах на двоих с завтраком, за 86 евро". И конечно же, я не мог этим не воспользоваться :)

Collapse )

97 вещей, которые должен знать архитектор ПО

Давно начатый проект перевода серии из 97 заметок наконец-то закончен!

Теперь ищу новую идею, чего бы еще интересного и непереведенного, перевести :) Если кто-нибудь знает что-то, буду рад!

97 вещей для архитектора ПО

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

Анонсов здесь не будет, кому интересно - следите непосредственно на сайте (там, кстати, тоже можно подписаться на рассылку новостей) или же в рассылке.

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

97 вещей, которые должен знать каждый архитектор ПО



Оригинал лежит вот тут: 97 Things Every Software Architect Should Know

К сожалению, near-time решило чего-то непонятное замутить с переименованием себя в strategy nets, в результате чего доступа к оригиналам этой серии не стало. Пока переводы приостанавливаются (вдруг оригиналы таки где-то еще появятся).

Переведено: 56 из 97.

И да, ссылки на оригиналы, конечно же, работать перестали.

Collapse )

Они же на моем сайте avl2.info

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

Перевод 97 Things Every Programmer Should Know - старт

С 1 января 2010 года стали недоступны оригиналы переводимой мной серии заметок "97 Things Every Software Architect Should Know". А поскольку процесс перевода мне понравился, я начал искать еще что-нибудь подобное. Довольно быстро нашлась следующая тема :)

Итак, взамен "изчезнувшей" серии "97 Things Every Software Architect Should Know" начинаю перевод аналогичной серии, но про программистов. Которая, хоть и называется "97 Things", содержит уже 165 записей :)

Думаю, будет не менее интересно.

ЗЫ. И да, на этот раз копию оригиналов предусмотрительно сделал себе на комп :)

56. Будьте осторожны с метафорами

(В оригинале - Don't Stretch The Architecture Metaphors)

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

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

На самом деле в этот момент метафоры становятся опасными. Вот как это может повернуться против архитектора.


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

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

  • Команда разработки начинает думать, что метафора более важна, чем реальная бизнес-задача. Вы начинаете отстаивать странные решения из-за привязанности к метафоре.

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

  • Разработанная система содержит следы имен, унаследованные от старых и уже неактуальных метафор и давно переработанных концепций.

    Пример: Почему объект Billing Factory создает канал для системы гребных шлюпок? Действительно ли он должен возвращать отображение граната для автовокзала? Говорите, вы тут недавно работаете?

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

Автор оригинала - David Ing

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

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

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

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

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

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

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

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

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

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