September 2008 Blog Posts

Фокус

29 September 2008 |

Все нервничают... видите работа в прямом эфире не обходится без неожиданностей.

TechDays.ru

19 September 2008 |

Новый подход к проведению семинаров Дни разработчика и TechNet представила компания Microsoft. Теперь кроме стандартного способа (заплатил, зарегистрировался, пришёл), появился новый (прошёл тесты, зарегистрировался, пришёл). Создан специальный сайт TechDays.ru на котором размещены обучающие материалы в виде веб-трансляций, и через который доступны тесты. Параллельно с этим проводится активная пиар компания всего этого дела.

Надо отдать должное всё вместе это привлекает внимание и повышает интерес к мероприятиям. Возникают вопросы: будет ли такой подход эффективен в долгосрочной перспективе и насколько выгодна такая форма продвижения продуктов/технологий/бренда.

Семинары всегда были не столько источником получения информации, а скорее direct + вирусный Marketing для Microsoft, и тусовка/клуб по интересам для участников. Если смотреть на семинары с этой точки зрения, то действия Microsoft становятся понятны, и оправданы. Вопрос в реализации, мне показалось, что порог прохождения через тесты слишком низок, а версификация участников должна быть больше.

На рынке software да и IT в целом происходят перемены: появились сильные конкурирующие компании (Google, Apple), новые технологии, ослабли или исчезли былые конкуренты плюс управленческие проблемы в Microsoft. В этом контексте действия бронтозавра против стаи шустрых млекопитающих, для постороннего наблюдателя должны представлять интерес.

EF: Many To Many

17 September 2008 |

Поддерживает ли Entity Framework связь многие ко многим? Да конечно, это же ORM нового поколения, и говорить здесь не о чем. И ведь действительно поддерживает, только для полноты картины не плохо бы добавить, что для этого база должна быть спроектирована совершенно определённым образом:

Your database link (or junction) table should have foreign keys to the two related tables and it should have a primary key which is a composite of the foreign keys.
http://forums.microsoft.com/msdn/ShowPost.aspx?PostID=2561831&SiteID=1

А что делать если таблица связи выглядит так:

EF_ManyToMany1

Таблица IntermediateTable больше не содержит никаких полей, кроме этих трёх. И эта схема не взята с потолка, лет 6 назад, я читал достаточно авторитетное (кажется даже Microsoft) и аргументированное обоснование именно такой схемы. Сейчас попытался найти и не нашел аргументацию. Но то, что такая схема имеет права на жизнь подтверждается самой жизнью.

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

P.S. Опыт знакомых, которые активно используют EF и мой не слишком большой личный опыт говорит, что EF это некоторый concept и нужно подождать пока он будет доведён до вменяемого состояния.

Not Lean

11 September 2008 |

Метро, будний день, утро 8:00, вагоны набиты людьми, стою рядом с противоположной от входа дверью, с силой вдавлен в неё. То ли от сильного давления, то ли по причине желания уйти от действительности, читаю на двери надпись: "Не прислоняться".

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

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

WCF: MaxReceivedMessageSize And Message Logging

10 September 2008 |

В WCF для WSHttpBinding есть ограничение на размер сообщения (MaxReceivedMessageSize), очень вероятно, что в работе Вы столкнётесь с этом ограничением. По умолчанию ограничение на размер сообщения 65,536, сделано это для того, чтобы затруднить DoS атаки.

Это всё хорошо, и замечательно, но столкнувшись с этим ограничением у Вас сразу возникнет вопрос: на сколько увеличить допустимый размер сообщения? Чтобы разумно ответить на него, необходимо сначала понять, какого размера сообщения у Вас реально ходят. Наилучший способ, который я обнаружил это использовать механизм Message Logging.

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

Intermediator In Application Development

09 September 2008 |

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

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

Почему посредник выделен здесь в отдельное звено, почему нельзя считать посредника просто заказчиком? Потому что, посредник, как правилоЮ берёт на себя часть работ связанных с постановкой требований, управлением проектом, мониторингом качества и рисков иногда даже проектированием и решением некоторых архитектурных вопросов. В таких условиях стандартные схемы организации разработки ПО отличаются от случая Заказчик — Исполнитель.

Представьте, что Вы руководитель такой компании - посредник и перед Вами стоит задача, принять решение о том как будет организована работа, какие схемы бывают, какую выбрать?

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

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

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

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

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

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

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

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

Когда сталкиваются с разработкой ПО, часто забывают такой нюанс: что Вы покупаете, а именно Вы покупаете продукт или Вы покупаете исходный код. Код - результат работы разработчика. В связи с выше сказанным, Вам необходимо принять решение, что Вы покупаете, покупаете ли Вы исходный код. Только недостаточно сказать: «Пожалуй я куплю исходный код», надо ещё уметь его купить, не каждый на это способен. Помимо текста, вам необходимо получить понимание этого кода (архитектуру, концепцию). Во первых это понимание исполнитель должен быть готов предоставить, а во вторых Вы его должны быть готовы получить и сохранить. Архитектуру и концепцию можно фиксировать в виде документов, так же существует понятие - документирование кода, но к сожалению все эти документы могут зафиксировать только 20-40% от «понимания» системы. На текущий момент лучшем инструментом для понимания системы и хранения этого понимания является человеческий мозг, поэтому Вам нужно минимум два таких лояльных хранилища, если Вы вдруг решите покупать исходный код, и эти люди должны развиваться вместе с развитием системы, а следовательно стать частью проекта.

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

PropertyGrid

08 September 2008 |

PropertyGrid — приятно выглядящий элемент управления. Но для использования всей своей мощи требует изучения. Если с его использованием у Вас возникли проблемы, то существует сайт посвящённый ему: Microsoft PropertyGrid. На русском языке можно почитать: PropertyGrid FAQ и Редактирование объекта с псевдо - свойствами в PropertyGrid.

Bad & Good

05 September 2008 |

Да ведь это идиотство - делить на праведников и грешников,
никогда не было ни тех, ни других...

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

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

God of HR

04 September 2008 |

Если бы греки продолжали придумывать мифы, то покровителем хрюш (Human Resources (HR)), был бы бог с тремя руками, в первой руке кнут с надписью Деньги, во второй с надписью Тщеславие и третий Власть. Три греха жажда денег, жажда власти и гордыня (тщеславие) составляют базис мотивации работника.

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

Очевидно, что в этой модели пространство мотивации представляет собой куб, если считать, что существует максимальная мотивация для 3 осей, и масштаб условных единиц так выбран, чтобы получался куб. Длинна вектора от точки (0, 0, 0), до точки соответствующей конкретному человеку (x, y, z) показывает максимальную силу мотивации для данного человека. Чем больше эта величина, тем проще человека мотивировать и тем сильнее он будет добиваться (Власти, Денег, Славы). А конкретные значения по различным осям показывают, как его лучше мотивировать. Одному надо дать власти и денег, другому власти будет достаточно если побольше, третьему власти и чтобы значит все им восхищались, ну и так далее...

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

P.S. Куда ведёт прогресс если его движущая сила это три греха...

Mushroom Season

01 September 2008 |

- А у Вас в Дании грибные леса есть?
- Нет, в Дании грибных лесов нет.
- Ээ... грибные леса везде есть.

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

mushroom1

mushroom2