Как подружить Oracle Geospatial Data и Google Maps

http://www.oraclebi.ru/2007/07/24/google/

Антипаттерн: Менеджер - пересылальщик писем

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

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

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

История одной "примадонны" на RSDN

Читаю сейчас тред на форуме RSDN (http://www.rsdn.ru/forum/message/2883756.1.aspx) и это какой-то детектив.

Начинается все с классического менеджерского вопроса "что делать с примадонной"

"На проекте присутствует сотрудник с таким
паттерном. Подскажите, что делать?"

...

"Тут какая проблема: из команды разработчиков (три человека) в начале проекта на него приходилось 70-80% работ, сейчас (спустя время) объем работы возлагаемого на него стал примерно 30%-40% (плавное снижение его степени участия в работе над проектом со стороны руководства), сейчас получается что уменьшение степени участия этого сотрудника влияет на сроки сдачи в худшую сторону."

Затем какое-то кол-во постов занимают стандартные советы, поперемешанные с флудом, народ предлагает сделать примадонну лидом, предлагает потихоньку выводить из проекта и все такое.

А вот затем начинается интересности, когда автора поста начинают расспрашивать о подробностях:

0rc>>Он сам просит выделить какой-нибудь проект, где он в чистую
может показать только свою работу. Как быть?

ГВ>Зачем это ему обязательно "показывать только свою работу"? Похоже на
оборонительную позицию. С чего бы это?Потому что паттерн "примадонна" применен исключительно к талантам + он не может работать со многими.

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

Пока выглядит как обычный конфликт, типа "толковый спец, который начинал проект, но не может работать в команде" + некоторое непонимание менеджером сути конфликта в подотчетной команде - больно уж странным выглядит его объяснение.

Смотрим дальше... А дальше автора поста спрашивают, а почему бы не отдать проект одному этому человеку, раз он суперэффективен. А вот почему:

0rc> Начальство решило, не спрашивайте почему, просто решило и ему
веднее, что лучшим мерилом денег будет — строчки кода. Но он пишет слишком компактный код, из-за этого все проблемы.

http://www.rsdn.ru/forum/message/2886396.1.aspx

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

Я всегда считал, что человек - такое существо, которое может само себя загнать в мир полного абсурда, и даже этого не заметить.

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

Я буду эту историю долго помнить. Надеюсь, я ее вообще никогда не забуду.

TFS при разработке Rosario

А мы все не спим.. :)

На channel 9 интересное видео про то, как команда MS Visual Studio использует Team Foundation Server при разработке следующей версии VS codename Rosario

http://channel9.msdn.com/ShowPost.aspx?PostID=391362#391362

Антипаттерны Test Driven Development

Сергей Розовик перевел интересную статью TDD Antipatterns. Крайне советую прочитать всем, кто как-то связан с созданием юнит-тестов.

"Лжец (The Liar). Тест, который успешно проходит во всех случаях. Однако при ближайшем рассмотрении оказывается, что фактически ничего не тестирует

.Попробуй запусти! (Excessive Setup). Тест, который требует сложной и длительной настройки тестового окружения перед запуском. Иногда тест содержит сотни строк кода, подготавливающие необходимые условия для запуска одного теста. В результате очень сложно разобраться действительно тест не прошел, либо что-то случилось с настройками...."

http://stump-workshop.blogspot.com/2008/01/tdd-anti-patterns.html

100% of requirements in spec?

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

http://stump-workshop.blogspot.com/2008/03/100.html

FormsAuthentication - мелочь, а неприятно

Искал я искал, почему у меня в ASP.NET при использовании forms authentication не работает "remember me" - а оказывается, по умолчанию этот самый permanent login ни фига не перманент, а 30 минут. Чтобы это исправить, нужно было поменять значение authentication/forms/@timeout в web.config-е


<system.web>
...
<authentication mode="Forms">
<forms timeout="50000000">
</authentication>

Пейджинг это зло. Кликните на страницу #447252639

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

А я вот про пейджинг имею сказать следующее - пейджинг сосет.

Если у меня есть список A..Z на 200 страниц - откуда я знаю, на какой странице расположены, например, слова на S?
мне кажется разумным либо делать рубрикатор или (и) поиск. А страничный пейджер годится лишь там, где не очень важно - что ты найдешь, кликнув на 125 слева страницу. Ну, например, на bash.org.ru :-)