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

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

Ни в коем случае нельзя в середине проекта менять верстальщика или дизайнера, или 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 прервертся во время выполнения без транзакции - умрет вся база!