воскресенье, 30 сентября 2012 г.

Новые технологии

Этот пост всё больше для себя, да и что-то давненько я ни черта не писал и вовсе.

Как-то между делом потихоньку уже больше года разбираюсь с HTMLayout. Презанятнейшая штука! Потихонечку уже два проекта вышли на публику: Mouse Hunter и RSSme.

С Mouse Hunter`ом как раз все просто. Все ж это тулза для мыша, а HTMLayout там только для пробы сил был и применен. На нем написан только интерфейс пользовательских настроек: галки, кнопки, все дела. В самой работе HTMLayout ну никак не используется. Правда, проект тут же ушел в народ: нашлись “умельцы”, которые его локализовали, да и по всей сети самописных статеек про “хантер” начеркано. У самого до локализации руки не доходят, не всё еще продумано.

Ох ну куда ж без этих-то? ?) Конечно же, тут же нарисовались халявщики партнеры. Сраный mail.ru впереди планеты всей! Тут же сперли дистрибутив, подтерлись лицензией и впендюрили в него своих засранных тулбаров. Переписка с мейлрушниками, на предмет “а кто разрешал” как всегда, ничего не дает – переливание из пустого в порожнее. А и ладно! Цыгане – они и в мейл.ру цыгане.

А вот второй проект – RSSme – уже поинтереснее будет. Надоело мне RSS ручками править. А коль так, изваял для себя свой собственный WYSYWYG-редактор. Это уже совершенно другая песня. В RSSme весь редактор постов  и управление данными полностью и только реализовано на HTMLayout. Здесь уже не ляпоты ради, а вполне реальные и насущные требования. Но пока проект находится в стадии сугубой альфы. Только создание, редактирование и мимимум возможностей. Но удобство прежде всего. Именно из-за него и начал создавать RSSme. Обшарил всю сеть - абсолютно все RSS-врайтеры просто убили своей убогостью: сплошные модальные диалоги, подтверждения, поля ввода. Больше думаешь, не что писать, а как да куда кликнуть. Больше на заполнение формуляров смахивает. Какое уж тут состояние потока?!? Какой-же это софт для писания хоть и RSS?!?

пятница, 3 августа 2012 г.

Google Translation

Сегодня свалился в почту дивный uninstall feedback: “…The main reason I deleted it, however, is that i am out of space on my system drive…”.

Но куда как дивнее, что выдал в переводе Google Translate: “…Основная причина, я удалил его, однако, что я из космоса на моем системном диске…

Я чуть со стула не упал! :) Это ж надо так “out of space” озвучить. Хотя, конечно если тупо и в лоб – то почему бы и нет!?!

PS: пользователь, автор фидбека, безусловно должен быть оключеван бесплатно. Как собрат… По разуму… Все ж из космоса… Я тоже сегодня с утра после дачно-пляжных роздыхов последних дней ощущал себя несколько из космоса :)

суббота, 21 июля 2012 г.

Регистрация за стихи

Как-то давненько, в изрядном подпитии хорошем настроении учредил бесплатную регистрацию Aml Pages за стихи… Дык “вононакак” (©) Работает! Аж цельную оду написали… :)

вторник, 17 июля 2012 г.

Дизайн иконок или не стоит так делать

Давненько, я ничего сюда не писал, всё бухал работал, дачи, лето – все дела. Ну пора чего-нить и черкнуть. Сегодня еще разок про иконки.  Ниже скриншот как выглядят иконки панели инструментов The Bat.

The Bat - панель инструментов

Это ж ахиреть просто можно. Каждая кнопка отвечает за свои действия. А тем не менее выглядят они практически одинаково. Сплошные емейлики с дополнительной миниатюрой вроде стрелок, перьев и прочия. Это приводит к тому, что все иконки попросту сливаются, и визуально очень мало отличаются. Зачем? Ну зачем везде рисовать почтовый конвертик? Ну понятно, что The Bat это почтовый клиент. Ну ясен пень что “отправка” это отправка письма, и приемка это тоже приемка писем… Ведь ясно как божий день, что отправка ни чемодана в аэропорт, и ни приемка экзаменов. Письма, письма, и только письма. Главная идиома – это действие с письмом. С какого же хера главное (действие) показано мелко, а второстепенное и очевидное (предмет, письмо то есть) – показано крупно.

Все напрочь сливается, пользоваться нереально. Сколько лет пользуюсь The Bat`ом, а не могу привыкнуть!!! Важное на такой иконке – должно выделяться максимально: цветом и размером.

А теперь фокус-покус. Уменьшим глубину цвета скриншота до 16 бит. Смотрите что получилось.

The Bat - панель инструментов со специально пониженной цветностью

Ну и как отличаются чем-то иконки друг от друга? А нихера! Это кстати элементарнейший тест на восприятие: уменьшить цветность и посмотреть сливаются в одно или нет. Даже фотошопить для таких тестов не обязательно. Достаточно просто чуть отодвинуться от экрана и прищурить глаза, и посмотреть. Эффект будет близким.

Никогда так не делайте!

PS: а если учесть, что при  наведении мыша на кнопку панели инструментов всплывающей подсказки хер дождешься, то вышеописанная ересь и вовсе достает.

четверг, 22 марта 2012 г.

Гугл-маркет : корпорация добра vs зла?

Любопытный пост про гугл-маркет. Вот вам батенька и юрьев день гугл маркет. Как только гугл начал активно работать с конечными вендорами, вся корпорация добра сразу как-то и закончилась резко. Полезли проблемы, неотзывчивый саппорт и банальное "сделано через зопу". А мы всё — “майкрософт маст-дай”, “плимус=кушать_кактус”, “PPG+охота на ведьм”…

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

Ибо сказок не бывает. Множество клиентов — это всегда большее число юз-кейзов, вариантов, предпочтений. А на каждый роток, не накинешь платок. Вернее, не накинешь "бесплатно", беспроблемно. Это требует ресурсов и многих: времени, аналитики, решений, реализаций, тестов – чего угодно. А они так запросто из ниоткуда не берутся. Сказок не бывает, как впрочем и серебрянных пуль.

PS: такая же картина вспоминается с браузером Google Chrome. От первых версий был просто в восторге! “Ты помнишь, как все начиналось…” ©. А теперь с каждой версией преотличнейший браузер все более и более вырождается в УГ. А жаль :(

суббота, 4 февраля 2012 г.

2012… Год тихой смерти?

И чего же я на Озоне аж 6 лет не появлялся!?! На картинке слева отображена история моих заказов на Озоне… Славный путь, не правда, ли? Только где это я был с 2006-го по 2012-ый?!?

А был я в Books.ru. Как-то случилось, что в далеком 2006-ом мне пришлось заказать книгу именно на books.ru. Уж не помню почему, но какие-то геморройки вышли с Озоном. Ну пришлось, и пришлось. Суть не в этом. В Books.ru я влюбился с первого взгляда. Мне катило абсолютно всё: отличнейший рубрикатор по книгам, возможность полистать книжку перед покупкой, явно “живые” отзывы, гутно работающая служба доставки и много чего другого. Чего только стоила новостная рассылка, это просто слов нет. Можно подписаться не просто на книги, не просто по разделам “детективы”, “про баб-с” и “профессиональная литература” – а выбрать более чем конкретизированные разделы в computer science: что-то вроде “операционные системы” и “языки программирования”, а вот самоучители по Ворду нафиг. Удобно не правда, ли?

Верните кнопку, всё прощу! Но недавно books.ru учинили редизайн сайта. Много чего работало криво, многое и не работало. Ну да ладно, один переезд стоит трех пожаров. Дело-то житейское. И баг-репорты админам писал, и мнения высказывал, в общем помогал любимому магазину как мог.

Но отчасти воз и поныне там. Товар есть – кнопка “В корзину”. Товара нет – картинка “Нет в продаже”. Где нафиг блин епрст полгода прошло кнопка “Сообщить о поступлении” рядом с товаром?  Ведь раньше на старом сайте была же? Так сложно сделать? Робяты! Books.ru! Вы теряете не просто клиентов, вы начинаете терять уже фан-клуб, а это о чем-то да говорит. Ну прям хоть сам иди прикручивай кнопку к вам на сайт. Верните кнопку, черти!!! Нужна помощь? Нивапрос ©! Все что в силах: код, UX-тестирование, UC-анализ. Просто так. Из симпатии к вам.

PS: а попробуйте угадать, откуда на Озоне появился вдруг заказ в 2012-ом? Ага. Точно, вот у них кнопка “Сообщить о поступлении” была. Они  и сообщили. Поэтому заказ и у них же, а не у books.ru. И это при том, что я с-о-о-овсем, мягко говоря, не в восторге от Озона. Ибо где француз прошел, цыг… всем остальным делать нечего!

пятница, 3 февраля 2012 г.

Про сериализацию в MFC

Сегодня про сериализацию, в частности в библиотеке MFC. Описанные ниже приемы — мой личный, опробованный на собственной шкуре опыт. О таком в MSDN, да в книгах не пишут. А зря, мль, зря… Почти все приемы выстраданы в конкретном проекте — в частности в Aml Pages. И большая их часть в ней и реализована. А некоторые нет, и я искренне весьма дюже сожалею о тяом, что допер до них слишком поздно.

На КЫВТ.ру поднимался вопрос о сериализации. Отвечал. А теперь рискну оформить наломанные мною копья в виде поста. Основной посыл этого поста, что человеку свойственно ошибаться. Ошибались, ошибаемся и ошибаться будем. И главное, всего в развитии проекта мы предвидеть не можем. Ну и собственно как можно всевозможные грабли обходить с сериализуемыми объектами.

Итак, MFC поддерживает класс CArchive для сериализации, который позволяет писать-читать из файла (хотя и не только), практически любые типы данных. Все стандартные классы MFC легко читаются\пишутся конструкциями вида CArchive<< и CArchive>>. Грабли начинаются уже потом, при развитии проекта. Именно когда объекты абстрактной софтины получают новые сериализуемые поля, или строковые данные могут быть в разных кодировках, или еще как.

1. Используйте номер версии архива

Используйте версионность CArchive. Смотреть на макрос IMLEMENT_SERIAL+VERSIONABLE_SHEMA. Суть проста: записывайте в CArchive сначала номер формата архива, а только потом сами данные. В дальнейшем это позволит сделать чтение архивов совместимым снизу вверх. Если в первой версии архива (файла), у нас записывались int+CString, а во второй int+CString+еще_int, то сериализация будет выглядеть так:

… Serialize(CArchive& ar)
{
if (CArchive::IsStoring()) {//запись архива
ar<<2;//записали номер формата — в данном случае вторая версия архива
ar<<My_int;//понеслась запись данных
ar<<myString1;
ar<<My_Int2;
}
else {//чтение
int nArchiveFormat;
ar>>nArchiveFormat;//читаем номер архива
ar>>My_int;//первый int
ar>>myString1;//первый CString
if (nArchiveFormat >=2)//если мы читаем архив второй версии, то считываем второй инт. Если архив второй или старше  версии, то читаем второй int — иначе пропускаем.
ar>>My_Int2;
}
}

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

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

2. Сериализуйте BOOL-переменные как битовую маску

Если в сериализуемом объекте у Вас есть набор булевых (BOOL)переменных, некоторых флагов, описывающих какое-то состояние, то не стоит их писать в архив последовательно. Не стоит писать нечто вроде CArchive<<boolFlag1<<boolFlag2<<boolFlag3; И дело тут вовсе не в экономии байтов.

Представьте себе, что в следующих версиях какие-то булевые переменные исчезнут из объекта, а какие-то добавятся. Соответственно, должен и измениться формат архива.  Вот блин, досада. И только из-за этой мелочи, как советовал выше, придется городить новый формат архива? Который не прочтут старые версии? Ан фиг! Эту проблему можно обойти. Решение простое: записывайте все флаги единой битовой маской. Нечто вроде такого:

DWORD dwBitMask=0;
enum {FLAG1=1, FLAG2=2… и.т.д.};
if (boolFlag1)
dwBitMask|=FLAG1;
if (boolFlag2)
  dwBitMask|=FLAG2;

и уже именно битовую маску dwBitMask записываем в архив. Какие плюсы? Обратите внимание, что во первых мы обошли проблему версий архивов. Появление или добавление нового флага BOOL не влияет на версию архива — все равно у нас пишется и читается DWORD.

Во-вторых, есть и еще весьма приятный бонус! Старая версия программы, которая не поддерживает каких-либо флагов из новой версии, не только корректно прочтет архив новой версии, но и запишет его обратно неизменным. Для этого необходимо, чтобы битовые маски не создавались и парсились на этапе записи\чтения, а именно в виде подобной маски и хранились в объекте. Тогда старая версия всегда одинаково прочтет битовую маску. Но булевый флаг, который появился у нас в новой версии она оставит неизменным. Как считает, так и запишет.

Согласитесь, движение в сторону совместимости сверху вниз это уже неплохо. У этого приема есть пара деталей, но это уже подробности и если нужно опишу их в другом посте. Как использовать битовую маску для хранения в объекте в runtime писать не буду — не об том пост.

3. Не сериализуйте строки как есть

Не реализуйте сериализацию строк, как предлагает в примерах по MFC. Не используйте в лоб запись и чтение вида CArchive<<myString и CArchive>>myString. Поясню почему. CString в MFC инкапусулирует или Unicode-строку, или ANSI-строку — в зависимости от настроек компиляции (MBCS|Unicode). Поэтому стандартная сериализация полностью полагается на внутренности CString. А оно нам надо? Всё, робяты! 90-ые давно прошли — на дворе 21-век. Нет просто строк, есть последовательности с завершающим нулем. Но вот в какой кодировке могут быть конкретные строки — выбирай на вкус. Хотите ANSI, хотите UTF8, хотите Unicode.

Простой случай: а допустим в CString у нас хранится HTML-код… HTML-код… Он такой… Он вообще может быть в какой угодно кодировке. Так что имеет смысл делать сериализацию CString ручками, записывать и кодировку, и длину, и только потом непосредственно поток байтов. Зато потом прочтете без проблем, в любой версии софтины. Поверьте на слово, то что кажется неважным в начале проекта, потом в развитии может вызвать очень большую головную боль.

Ну вот, собственно, некоторые несложные приемы сериализации. Есть конечно и еще детали, и еще подробности. А деталей хватает. Начиная от корректной реакции софта на попытку прочтения новой версии архива, и заканчивая, ситуцией, когда MFC-программа, скомпилированная как MBCS читает архив записанной UNICODE версией, или наоборот. Есть там нюансы, и именно в них весь дьявол. Но о них как-нибудь в другом посте.