2007-12-30

Работать по-японски

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

В новой части знаменитого кладбища Окуно-ин — целые ряды корпоративных могил. Право покоиться здесь получили только лучшие из лучших, самые преданные и самые старательные. Корпоративная могила знаменитой фирмы UCC, производящей кофейные напитки, выполнена в форме огромной мраморной чашки, в которой перемешан прах всех верных сотрудников компании. А на могильном камне корпорации, производящей бытовую химию, выбита надпись: «Мы просим прощения у всех невинно убитых тараканов».

http://cldlune.livejournal.com/164511.html

2007-12-28

Data generator

Онлайн генератор небольших таблиц для тестов http://www.generatedata.com/. Весьма приятные оформление и функциональность
Вырезка из feature-list
  • Many data types available: names, phone numbers, email addresses, cities, states, provinces, counties, dates, street addresses, number ranges, alphanumeric strings, lorem ipsum text and more.
  • Option to generate data in XML, Excel, HTML, CSV or SQL.
  • Country specific data (state / province / county) for Canada, US, Netherlands and UK.

2007-12-25

Ok/Cancel vs Cancel/Ok

Долгое время не мог найти объяснения, почему мигрирующий с *nix-ов окошечный софт, как правило, имеет в диалогах кнопку "Ok" справа. Каюсь, поверхностно грешил на общую гуевую криворукость юниксоидов. Сегодня поработав с добротно сделанным kuler-ом, увидел в окошке логина такое же решение. Кулер не идеал с точки зрения юзабилити, но ляпы там немного другого порядка, поэтому стало очевидно, что решение поместить кнопку "Ok" было не случайным. Помозговав немного построил для себя (позже подтвердившееся) объяснение: большинство пользователей читают слева направо и сверху вниз. Таким образом после просмотра диалога, пользователи первым делом натыкаются на часто используемую кнопку "Ok" (по сравнению с "Cancel").
Объяснить для себя "правый Ok" я так и не смог, поэтому сломав голову полез в гугл. Пояснение нашлось сравнительно быстро - сторонники "правого Ok" аналогично, аппилируя к опыту большинства, утверждают, что левая сторона и расположенная слева кнопка ассоциируются с термином "Назад", а правая "Вперед" (как косвенный аргумент приводится расположение кнопок вперед/назад в браузерах). К счастью, мнение (от Holger Maassen) было сформулировано достаточно нейтрально, чтобы моментально прийти к выводу, о глобальной неразрешимости этой проблемы - у обоих решений всегда будут свои сторонники и противники.


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


Во время поисков наткнулся на любопытный пост в котором автор кратко описывает "историю жизни" кнопок Ok/Cancel или более грамотно, с точки зрения юзабилити Primary/Secondary action.


А еще чуть позже нашел подробное пояснение для самых маленьких о причинах такой эволюции. Если кратко, то основной аргумент - желание выделить "Primary Action" без особого ущерба для "Secondary Action" (в качестве тяжелой артиллерии для аргументации такого решения привлекается Закон Фиттса). Кроме того, автор заметки рекомендует использовать вместо Ok/Cancel что-то более domain specific (в его примере "Save title"/Cancel).

Далее нашел замечательную статью LukeW: Primary & Secondary Actions in Web Forms. Специалисты (Luke Wroblewski & Etre) сделали шесть дизайнов страницы с различным расположением (и дизайном) кнопок Submit (Primary Action) и Cancel (Secondary action) и попросили 23-х человек, заполнить формы фиксируя действия пользователей. В результате оказалось, что предпочтительным является размещение Primary Action слева, на одном уровне с input-ами формы. Кроме этого, авторы рекомендуют семь раз подумать, а сильно ли требуется тот самый Secondary Action и если не сильно - моментально выкинуть его :)

И наконец, встретилась добротная статья из MSDN - Command Buttons. Увы, т.к. гайдлайн должен содержать только тезисные рекомендации для девелоперов, из статьи полностью выкинута вся аргументация.

2007-12-20

"SetUnhandledExceptionFilter" and VC8

The are many situations in which your user-defined Unhandled-Exception-Filter will never be called. This is a major change to the previous versions of the CRT and IMHO not very well documented.

источник
Неприятно.

Что характерно, ссылка на одну из статей битая (Compiler Security Checks In Depth).

Тем не менее, статья существовала, т.к. ссылки на нее есть в других статьях, например здесь http://msdn2.microsoft.com/en-us/library/8dbf701c(VS.80).aspx

2007-12-19

RAMDisk для быстрой компиляции

Некоторое время назад решил попробовать сабж. Основная идея - размещать временные файлы проекта в оперативке, тогда время компиляции уменьшится (собранные объектники не будут гоняться на диск и обратно). Бесплатную программу для создания RAM диска можно взять здесь http://ramdisk.nm.ru/ramdiskent-rus (ссылку нашел на рсдн)
Устанавливается софтина весьма легко, единственная опция которая потребовала внимания - требуемый объем оперативки выделяемой под диск. Махнув рукой отдал 256 мб из гигабайта.
Для моих проектов (время ребилда меньше минуты) существенных изменений не заметил - время осталось таким же или стало чуть меньше.
Вывод - взять сфотинку на заметку, возможно окажется полезной в будущем, но сейчас смысла использовать нет.

2007-12-18

R.I.P. Numega

Оказывается полгода как закрылась Numega Lab
via

Crash Report

Crash report__После того, как с большим трудом удалось продиагностировать Unhandled exception у пользователя (юзер раздражителен, плохо читает инструкции, да и ему проще снести софтину, чем разбираться в ее проблемах), стало очевидно, что необходим простой способ для оповещения разработчиков об ошибках. В закромах давно лежала вкусная ссылка (то же самое на google code), с которой осталось разобраться и подключить к приложению.
Первые впечатление были как у Кусто нашедшего дельфина с тремя глазами - библиотечка (crashrpt) генерирует замечательный отчет: crash dump + красивое сообщение об ошибке, к которому можно подключить несколько пользовательских файлов (например конфиги и логи). Более того, потом crashrpt сохраняет все это добро одним zip файлом и создает письмо к которому аттачит отчет. Пользователю остается только нажать кнопку отправить.
Все было чудесно до тех пор, пока не начал подключать либу к проекту - библиотека потребовала WTL. У меня ее нет за ненадобностью и раньше интересовался ей только поскольку-постольку (реального опыта ноль целых ноль десятых). Скачал, поставил (если такое слово применимо - библиотека поставляется только в хидерах), после чего выяснилось, что WTL не способно жить без ATL. На этом месте радость закончилась - т.к. в состав Express-ов ATL не входит.
Поманили морковкой, дали пооблизывать, после чего жестко обломали.

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

Мимоходом попытался проверить всплывшую в памяти информацию, что ATL входит только в состав платных студий.
Поиск в "базе знаний" Майкрософт. Как они сами с такой помойкой работают?

PS В закромах остались ссылочки
"XCrashReport : Exception Handling and Crash Reporting" By Hans Dietrich. Буду разбираться.
http://www.codeproject.com/KB/debug/XCrashReportPt1.aspx
http://www.codeproject.com/KB/debug/XCrashReportPt2.aspx
http://www.codeproject.com/KB/debug/XCrashReportPt3.aspx
http://www.codeproject.com/KB/debug/XCrashReportPt4.aspx

PPS Когда апдейтил пост произошли ошибка на блогспоте, о чем пришел соответствующий репорт :)


При этом никакой ошибки, кроме сообщения о ней мне обнаружить не удалось, как ни искал :)

2007-12-04

Переименование папок в Thunderbird

Thunderbird только что учудил.
Решил я переименовать одну из папок с письмами из верхнего в нижний регистр. На что тут же получил предупреждение

:)
Правда позже, почтовик честно обновил все фильтры связанные с этой папкой за что ему большое спасибо.

const char* filename

На днях Александр Авраменко постил на рсдн список новых библиотек, которые войдут в свежую версию буста 1.35. Прочитав его, был сильно удивлен, т.к. не ожидал, что бустоводы (в большинстве своем) когда-нибудь повернутся лицом к ... хм... всяким реальным проблемам: планировались библиотеки для работы с изображениями, сетью, межпроцессного взаимодействия. Меня помимо вышеназванных, привлекла property_tree library.
property_tree - рекурсивное дерево с поддержкой загрузки/сохранения в форматах XML, INI, JSON и в реестр Windows.

Именно такая штука сейчас бы очень пригодилась для хранения опций в Spy - особенно порадовала возможность сохранять дерево в JSON.
Сегодня решил собрать пример. Первое, что бросилось в глаза
void read_json(const std::string &filename, ...)
void write_json(const std::string &filename, ...)

Тоска зеленая, 256 символов на все прихоти планеты - фарева.

Автор, очевидно, в курсе проблемы, т.к. в том же файле предусмотрены интерфейсы:
void read_json(std::basic_istream &stream, ...)
void write_json(std::basic_ostream &stream, ...)

Вместе с (очевидно MSVC-specific) конструктором basic_ofstream(const wchar_t *_Filename, ... ) становится возможным малой кровью обойти проблему.

Пост ни в коем случае не пинок автора property_tree, а скорее усталость от мелких проблем, которые почему-то не получается решить на уровне стандарта уже много лет.

2007-12-01

HTMLayoutSpy. Альфа.

Качать здесь http://htmlayoutlab.com/2007/11/30/spy-alpha/
Русская и английская демки
http://htmlayoutlab.com/2007/11/30/russian-flash-demo/
http://htmlayoutlab.com/2007/11/30/english-flash-demo/

Как ни странно, успел почти все, кроме сохранения опций. Доволен.