qizz

Извлекаю из фотоаппарата вот такие картинки:

без участия фотошопа, гг

Блоггеры со мнением(с) бьются в истерике: "нам запретили порнографию!", "хотят ввести контроль за интернетами!". Между тем, в Украине запрещено появляться в пьяном виде в общественных местах (пруфлинк), но эта часть закона не мешает ни пьяному быдлу, ни нормальным людям. Между законом и исполнением таки немалое расстояние, и не всегда это плохо.

Выводы из опыта:
– Обычно конфигурация NHibernate и SessionFactory создаются статически. Если так это дело и используются в тестах, то обязательно нужно запускать тесты в одном AppDomain – иначе инициализация может происходить по разу на каждый test fixture, а это очень долго. Можно настроить test runner от NUnit 2.5, но лучше всего прописать в конфиге как написано в посте – тогда решарпер, например, это тоже подхватывает.
– SchemaExport занимает много времени. Если есть желание устроить в тестах всегда актуальную базу посредством экспорта схемы из маппинга, то UpdateSchema будет выполняться ощутимое время, даже если ничего не менять не нужно. Можно либо зарезервировать только один тест для создания базы, либо хешировать метаданные и обновлять только при необходимости (я сделал так). Кстати, значение автоинкремента входит в SHOW CREATE TABLE, так что перед хешированием лучше установить их в начало.
– Если нужно очистить все таблицы, не стоит выстраивать их в хитром порядке в соответствии с зависимостями. Дело в том, что при наличии внешних ключей даже TRUNCATE TABLE не очистит таблицу с самозависимостью а-ля parent_id. Проще сделать "SET foreign_key_checks = 0" и удалять в произвольном порядке.
– Не нужно обвинять во всех смертных грехах базу данных. Я понял это, наигравшись с движками, параметрами логгирования и перенеся базу на RAM-диск. На самом деле для пустой базы с небольшим количеством тестовых данных это не имеет почти никакого значения.
– Сессия NHibernate не предназначена для вставки большого количества данных. Даже при не очень разлапистом дереве объектов десяток тестов способен сгенерировать уйму объектов, которые сильно подорвут скорость выполнения. А ведь оказывается, что тысяча объектов в сессии наносит весьма ощутимый удар по производительности запросов¹.
– И вообще пачку объектов лучше добавлять в StatelessSession одной транзакцией. Особенно это касается всяческих настроечных данных.

P.S. Эти рекомендации уменьшили у нас время прогона тестов с базой где-то на порядок.


¹[Это может показаться странным с учетом того, что в классике сессия открывается чуть ли не на каждый чих, однако у нас web, и open session in view вполне устраивает...но в результате текущая сессия инкапсулирована в DAO, что не вполне удобно в тестах]

Вот интересует вопрос корней LINQ. Идея в разумных пределах транслировать выражения самого языка в SQL мне очень нравится, но вряд ли она появилась на пустом месте (в функциональных языках она кажется едва ли не очевидной). Чем же вдохновлялись в MS и есть ли в популярных языках аналоги?

В просторах сети нашел вот такое утверждение:
"Steve Yegge said...
an event equivalent to Gregory Chaitin stepping in and correcting the math in an XKCD comic."
Кто-нибудь знает, о чем речь? Если это правда, то это ужасно забавно!

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

"– К нам приходят дворники без высшего образования.
– А что, просто дворники не подойдут?
– Нет, у нас сложные задачи, вы не понимаете."

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

Вот такие строчки надолго ставят меня в тупик, например:
//Checks whether there is a current date in an interval Start - End
... FirstOrDefault(it => it.Start <= now && it.End >= now)
Приходится убеждать себя, что написанное верно.

Краткое содержание предыдущих серий: есть некий функционал (получение списка зарезервированных слов), который должен реализовываться всеми провайдерами данных. История такова:
– В MySQL Connector/NET реализуют фичу с неправильным именем поля в таблице зарезервированных слов.
– 07.06.2009. В NHibernate 2.1.0 Beta1 добавляют фичу автоквотирования, которая полагается на список зарезервированных слов. В ней используется стандартное имя поля, так что с MySQL эта версия падает.
– 10.06.2009. В NHibernate исправляют проблему путем использования нестандартного имени поля для MySQL. Исправление входит в 2.1.0 Beta2. Все работает нормально.
– 13.07.2009. Тем временем в MySQL тоже замечают проблему и исправляют ее в версиях Connector 5.2.7 и 6.1.0 (ветки 5.2 и 6.1 разрабатывались параллельно, исправление внесли в обе). Таким образом, с новой версией коннектора NHibernate падает (т.к. полагается на неправильное поведение).
– 19.07.2009 выходит стабильная версия NHibernate 2.1.0 GA с фиксом для MySQL, но из-за параллельного исправления в MySQL Connector ничего не работает (я этого боялся!).
– 16.10.2009. Проблему исправляют в NHibernate путем приведения к старой версии. Исправление должно войти в стабильный релиз 2.1.1.GA, который скоро должен выйти. Тем не менее, в данный момент последняя версия NHibernate с последней версией MySQL Connector/NET все-таки не работает.

Кто виноват? В MySQL родили проблемы, поставив не то имя поля. В NHibernate исправили конкретный баг, не подумав о будущем фиксе в MySQL (можно было бы, например, сделать настройку "имя поля для зарезервированных слов"). И те, и другие плевать хотели на совместимость с предыдущими версиями.

В результате будут проблемы, если:
- NHibernate версии 2.1.0 Beta1 используется с MySQL Connector/NET семейства 5.2 младше версии 5.2.7 или семейства 6.x младше 6.1.0
- NHibernate версий 2.1.0 Beta2, GA используется с MySQL Connector/NET семейства 5.2 от 5.2.7 или семейства 6.x от версии 6.1.0.
Для решения можно либо изменить версии на сочетаемые, либо перекомпилировать какую-нибудь из библиотек (с NHibernate это получается нормально, с MySql.Data есть нюансы), либо отключить экранирование зарезервированных символов в NHibernate, используя <property name="hbm2ddl.keywords">none</property> в настройках.

Неожиданно понял, что у виски и кофе много общего: основой являются ярко выраженные сорта, произведенные в одном месте, но большинство рынка занимают смеси (бленды); цены на одиночные сорта (моносорта кофе/односолодовый виски) кусаются. Односолодовых виски я уже касался, но для Jamaica Blue Mountain или Kopi Luwak придется преодолеть какой-то психологический барьер.

Кстати, Дом Кофе – вполне хорошо, рекомендую.

ЗЫ: А вот еще, если кто не знал:
"Процесс производства зёрен кофе «Копи Лювак» состоит в том, что пальмовые циветты поедают спелые плоды кофейного дерева (кофейные вишни), переваривают окружающую кофейные зёрна мякоть и в ходе дефекации экскретируют зёрнышки кофе, которые затем собираются людьми, моются и сушатся на солнце." Что самое странное, это меня не останавливает :)

Черты идеального программиста в моем понимании:
1. Понимает, что программы пишутся для людей.
2. Понимает, что код пишется для людей.
3. Понимает разницу между требованиями и решениями.
4. Может самостоятельно в чем-то разобраться.
5. Знает необходимые технологии и типовые решения.
6. Старается сделать решение оптимальным.

Чуть более развернуто:
1. Пытается пользоваться тем, что делает. Не забывает проверить, что все работает.
2. Называет объекты емко и ясно. Пишет код предсказуемо и понятно. Не забывает о комментариях.
3. Не отклоняется произвольно от требований, сознательно проверяет результат своей работы на соответствие им. Вместе с тем может предложить иной вариант решения, лучшую реализацию.
4. Способен сам продумать реализацию небольшой задачи, не дергая поминутно старшего. Умеет пользоваться google и stackoverflow.
5. Знает хотя бы в общих чертах о широком круге средств решения задач, связанных со своей специализацией. Имеет представления о типовых решениях, в идеале – опыт их применения.
6. Видит разницу между надежной и хрупкой реализацией, простым и сложным для изменения решением, красивым и ужасным кодом, быстрым и медленным алгоритмом. В идеале сразу выбирает лучшее. Думает об возможных ошибках, которые могут возникнуть в ходе работы программы.

Удивительно, но с чертой 5, которая обычно считается определяющей, проблем чаще всего не возникает, а самые большие трудности вызывает 1 и 2 (самые важные, на мой взгляд). Пункты 4-6 очень, очень приятны, но без них работать, на самом деле, вполне реально, а вот работа без 1-3 превращается в эпическую битву. Вещи достаточно очевидные, но я только сейчас смог их четко для себя сформулировать.

ЗЫ: Между тем, со времен старого поста ненависти стало как-то лучше. С одной стороны, люди под давлением стали работать несколько лучше (хоть и не без рецидивов), с другой стороны, лучше осознались мои собственные ошибки.
ЗЗЫ: На самом деле работа в ДонНУ при всей ее ущербности с точки зрения технологий и процесса разработки, дала мне очень много для понимания важности всех этих моментов – сказывается полный цикл, от раннего сбора требований до поддержки проекта спустя семь лет после старта. Правда, после этого больно видеть людей, которые этого не понимают.

Волшебные вывески...

я не знаю, как это определить, но оно мне нравится.

Или даже так:

Я сейчас очень мало новой музыки слушаю, хотя когда-то казалось, что этого не может быть.
С одной стороны, нет достойного доверия источника чего-то принципиально нового и хорошего.
С другой стороны, все меньше возможностей с удовольствием слушать.
А еще старого переслушивать хватит, казалось бы, на сто лет (на самом деле, 14 недель, как говорит объективный фубар), и оно гарантированно доставляет.

Между прочим, тоже Львов:

Я не знаю, у меня какие-то неправильные фотки из Львова, не?

Официально: "коньяки України - міцні алкогольні напої з характерним букетом і смаком, виготовлені шляхом купажу спиртів коньячних, отриманих методом дистиляції коньячних виноматеріалів на спеціальних мідних апаратах з фракціонуванням, витриманих не менше трьох років у дубовій тарі або нержавіючих чи емальованих ємностях з дубовою клепкою"

Дубовая клепка! То есть официально можно "выдерживать" такой коньяк в кастрюле с дубовыми дощечками. Об огромном количестве карамели тоже умалчивают.

Присутствует также замечательная методика обозначения возраста: "из спиртов среднего возраста x лет". Общепринято классифицировать напитки по минимальному возрасту, но, видимо, не хочется. Еще хорошо, если средний возраст в пять, например, лет получается из 13% 25-летнего коньяка и 87% двухлетнего, а не из 1% восьмилетнего и 99% двухлетнего (ну а что, среднее из восьми и двух это пять...).

Поэтому "коньяки Украины" я не очень люблю. Хотя, надо признать, дегустация коктебельских коньяков порадовала – начиная с семи-десяти лет получаются весьма неплохие напитки, но ведь и ценовой диапазон здесь совсем другой – цена уже сравнима с ценой бюджетного виски, например. За "Кутузова" вообще просят немалые деньги – не то, чтобы он был плох, но чтобы настолько хорош – как по мне, вряд ли.

ЗЫ: Решил попробовать "Ориану" – не могу определиться. Свои деньги (по цене Ашана) отрабатывает 100%, но радости, радости нет!

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