Мысли вслух, или не могу больше молчать

Отправили мое резюме в одну фирму. Фирма довольно долго думала и в результате выплюнула следующее:

"У нас командная работа (Scrum) и удалённая разработка из дома неприемлема. Только полный рабочий день и тесная работа в команде.

В остальном, кандидат конечно интересный."

Ай, как я люблю такие фирмочки. Сказать что над этим комментарием мы ржали в составе 35 человек из числа распределенной команды iDecide - ничего не сказать. Мы уже давно придерживаемся идеологически достаточно строгого agile и, хоть официально и не рекомендуется, работаем все удаленно (исключение составляет управление и маркетинг). И ничего, подчеркиваю, ничего не случилось плохого. Почему? Да потому что топы компании и среднее звено руководства - весьма и весьма грамотные люди, которые построили процесс, создали идеологию и (ВНЕЗАПНО!) все прекрасно работает и не разваливается.

Ребята, ну все же очевидно! Подобного рода утверждения обычно означают: "Нетнетнет! Нам нужен жесткий контроль над ВСЕМИ сотрудниками! Иначе никак!". Особенно прикрываться SCRUM-ом от удаленной работы - это как прикрываться веганством от жесткого, неистового секса. 

Потребность в строгом контроле и абсолютное неприятие удаленной работы свидетельствует только об одном - сюрприз-сюрприз - были прецеденты, когда без такого управления, команда шла вразнос, люди теряли фокус и тупо забивали на работу. Что, в свою очередь, недвусмысленно намекает что команда собрана из несамостоятельных и ленивых людей + руководство не знает что с ними делать. А тогда какой у вас, к херам собачьим, SCRUM?! Нет, это в лучшем случае корявый Waterfall. Потому что нельзя построить SCRUM на паноптикуме таких вот кадров. Ну не будет это работать - плавали уже, знаем. 

Тем не менее, представители надувают щеки и прикрываются умными словами. Господа, к чему надменность? Все мы вылезли из женской вагины. Вас никто не заставляет публично расписываться в своем (не)профессионализме (на минутку, что вы и делаете, говоря про SCRUM и удаленку в таком ключе). Можно просто сказать "мы не заинтересованы в удаленном сотрудничестве", или "сожалеем, но политика компании не подразумевает такого формата". Лучше честно сознаться что "не хотим, не будем", чем понапрасну умничать. Фу.

Тут можно было еще сказать что в нашем, академовском community любой мелкий аутсорсер, чуть только доросший до интегратора - мнит себя чуть ли не Газпромом и Microsoft-ом в одном лице. Но я не буду распинаться - это все итак понятно. Интересно только откуда эта надменность? Неужели НГУ так влияет?

SQL joins

Таблицу можно джойнить саму на себя.

Thread vs ThreadPool

Внимательно следите за этими двумя сущностями. ThreadPool удобнее и логичнее в ряде случаев, но иногда может подложить свинью. А именно - когда функциональность, которая должна выполняться в одном, но параллельном потоке ВНЕЗАПНО раскладывается на кучу потоков.

Это реально может послужить причиной многих багов. В общем - контролируйте потоки в своем приложении. Thread - для более тонкого планирования многопоточности. ThreadPool - быстрое, но потенциально грабельное решение.

О веб-разработке и верстальщиках

"Коней на переправе не меняют" 

Ни в коем случае нельзя в середине проекта менять верстальщика или дизайнера, или js-программиста, если нет достаточного запаса времени на введение оного в курс дела. 

Верстка - дело нехитрое, но поддерживать ее непросто. Новый верстальщик гарантировано сломает всю верстку без предварительного ознакомления. На хорошо выполненную первую задачу ему потребуется 2-3 дня.

Аналогичное касается дизайнера и верстальщика.

Внезапно, о дизайне интерфейсов

Если в интерфейсе у вас где-то появляется круговая диаграмма, в которой больше 10 значений, а под диаграмму выделяется маленькая площадь - меньше 300x300 пикселей (в 96dpi), то сразу же, не думая, во избежании проблем меняйте ее на bar chart. Иначе потеряете в информативности и выглядеть будет как из задницы. 

Тем не менее многим заказчикам или дизайнерам UI приходят в голову решения этой проблемы. Сразу обозначу к чему они приводят

• Скрытие некоторых пунктов уменьшает информативность и делает отображаемые данные недостоверными
• Объединение нескольких кусков диаграммы в один не помогает (если схлопнуть 20 кусков по 5% до 5, то вы получите не 5 кусков по 20%, а 4 куска по 5% и один по 80%, в противном случае теряется смысл диаграммы)
• Отдалить надпись/уменьшить диаграмму - не поможет. Маленькая круговая диаграмма неинформативна, отдаленные надписи неудобно смотреть

Extension-методы и разлом стереотипов

Сегодня сломались все мои представления о программировании на C# и extension-методах в частности, когда я увидел вот такой код:

1.Delay();
2.CreateThread();
3.WaitForUserInput();

А это оказались всего лишь extension-методы к int. Согласитесь, выглядит феерично.
Тут сразу же пришла на ум конструкция для более внятного кидания exception-ов:

"Access denied".InvalidOperation();
"File not found".FileAccess();
"Trying to instantiate incorrect type".FactoryError();
"Incorrect value: number expected".Validation<User>(u=>u.AgeString);

Полагаю, дальнейшие комментарии излишни.

Совет про Dictionary

var d = new Dictionary<string,int>() {
    {"NumberOne" /* ключ */,1 /* значение */},
    {"NumberTwo",2},
    {"NumberThree",3},
};

Как ни странно, можно и так.

RavenDB Embeddable - коротко и по существу

Сессии:

• Открытие сессии: дешевая, почти дармовая операция (65000 сессий за 300-500мс).
• Закрытие сессии: и того дешевле (65000 сессий за 0-3мс)
• По умолчанию количество запросов на сессию ограничивается 30 штуками. Устанавливается при в DocumentStore.Conventions.MaxNumberOfRequestsPerSession

Инициализация хранилища: 

• очень дорогая операция - от 7с до минуты и больше
• похоже, имеет место зависимость от размера хранилища

SaveChanges: 

• дорогая операция. Зависит от количества объектов (1000 объектов за 1-15мс). 
• В TransactionScope время выполнения не меняется.

Работа с Queryable: 

• Выполненные Queryable кэшируются. После добавления данных нужно взять новый .Query<>

Работа с транзакциями: 

• объекты оказываются в базе только после transaction.Complete(); или Dispose в using-блоке транзакции. Точно выяснить когда начинает работать .Count() после добавления объектов - не удалось
• Уровни изоляции, судя по всему, не реализованы. 
• Если SaveChanges прервертся во время выполнения без транзакции - умрет вся база! 

Перемещение/resize окна в WPF

Проблема: хочу сделать окно со своим дизайном на WPF, но при убирании бордюра (NoBorder) оно перестает ресайзиться и двигаться за заголовок

Решение: Специально для этого в 7 и Vista есть библиотечка с пространством имен Microsoft.Windows.Shell, физически лежащим в PresentationFramework.dll. Там есть класс WindowChrome. Это лучше понимать как "хром окна", но по факту не только окна, но и любого элемента. Он содержит в себе набор attached-пропертей для манипулирования неклиентской областью окна. Пример:

<Style TargetType="{x:Type Window}">
        <Setter Property="shell:WindowChrome.WindowChrome">
            <Setter.Value>
                <shell:WindowChrome 
                                    CaptionHeight="24"
                                    CornerRadius="0"
                                    GlassFrameThickness="0,0,0,-1"
                                    NonClientFrameEdges="None"
                                    ResizeBorderThickness="7"
                                    UseAeroCaptionButtons="False"/>
            </Setter.Value>
        </Setter>
</Style>

Тут можно задать высоту невидимого заголовка и толщину невидимых бордюров для изменения размеров. Невидимый заголовок в данном случае будет - полоска сверху окна высотой в 24px, за которую можно будет потянуть и перетащить окно. Если вам нужно разместить в этой зоне еще какие-нибудь элементы - не забудьте проставить им 

shell:WindowChrome.IsHitTestVisibleInChrome="True"

А для ResizeGrip (или за что у вас там тянется, чтобы изменить размер окна):

shell:WindowChrome.ResizeGripDirection="BottomRight"

И все проблемы с перемещением окна будут решены.

YouTrack

Если в YouTrack поставить на аватарку какую-нибудь яркую цветную иконку, то на agile board свои задачи будет видно куда лучше.

T4

Используйте T4, когда возникает необходимость генерировать текст или код.

Тут качается, а тут читается. В общем и целом - очень похоже на Razor/ASP.NET MVC. 

WPF и Windows 8

Проблема: хочу сделать интерфейс в своем WPF-приложении, как в Windows 8 или Office 2013

Решение: Microsoft не затрудняет себя, как правило, разработкой паков GUI-вещей после выхода каждого нового продукта. На этом зарабатывают многие компании. И эта беда не обошла Windows 8. К счастью, есть энтузиасты, сделавшие почти все элементы Windows 8 на WPF и подготовившие их к использованию. Найти их с исходниками можно вот тут: http://elysium.codeplex.com/. 

Да. Ни в коем случае не пытайтесь повторить их путь, особенно при сжатых сроках - потратите уйму времени и соберете дикое количество граблей.