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-часового экзамена на реальных и непростых группах). Впереди еще минимум три года обучения :) Так что в ближайшее время появится еще одно направление в моей деятельности :) По которому я тоже буду рад помочь тем, кого это заинтересует!

11. Программируйте на языке предметной области

(В оригинале - Code in the Language of the Domain)

Представьте себе два исходных кода. В первом вы видите что-то подобное:

if (portfolioIdsByTraderId.get(trader.getId()).containsKey(portfolio.getId())) {...}

Вы чешете затылок, пытаясь догадаться, что может делать этот код. Выглядит как взятие ID из объекта trader и использование его для получения другого ID, после чего – поиск еще одного ID из объекта portfolio… Почесывание затылка почему-то не помогает. Вы ищете определение portfolioIdsByTraderId и находите следующее:

Map< int, Map< int, int>> portfolioIdsByTraderId;

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

А в другом исходном коде вы находите вот такую строчку:

if (trader.canView(portfolio)) {...}

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

А теперь скажите, с каким кодом вы бы предпочли работать?

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

Потом появились типы, определенные пользователем! Это серьезно изменило правила игры. Если в вашей области есть сущности «трейдер» и «портфолио», то вы можете смоделировать их при помощи типов данных с именами Trader и Portfolio. Но еще более важно то, что вы можете моделировать отношения между ними, тоже используя термины из предметной области.

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

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

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

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

Автор оригинала - Dan North

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

9. Вы участвуете в переговорах чаще, чем вы думаете

(В оригинале You're negotiating more often than you think.)

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

«Нам действительно нужна функциональность Х?» - задает вопрос инвестор.

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

Правильный ответ на подобный вопрос: «Да, действительно нужна». Ответ, который дается крайне редко.

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

Все это может быть правдой, но к сожалению дать такой ответ будет в корне неправильно. Инвестор перестанет вас слушать сразу после слова «Ну...».

Проблема в том, что вы по-прежнему видите себя в роли инженера, в то время как инвестор на 100% уверен, что он обсуждает условия. Вы ищете решение, которое бы всех устроило, а он ищет выигрышный вариант для себя (и скорее всего, проигрышный для вас), или же, говоря простым языком, торгуется. А в обсуждении условий ни в коем случае нельзя соглашаться на первый предложенный вариант. На самом деле, правильный ответ на «А нам действительно это надо?» должен быть примерно вот таким.

«Без резервного сервера вся система будет падать минимум трижды в день, практически всегда в моменты максимальной нагрузки, или же когда вы будете что-то демонстрировать совету директоров. На самом деле нам даже нужно четыре сервера, тогда мы сможем сделать две резервных пары и гарантировать работоспособность системы в полном объеме, даже если выйдут из строя сразу два сервера».

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

Автор оригинала: Michael Nygard

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