пятница, 21 декабря 2012 г.

Plimus – конец света

Сегодня с Плимуса свалился ордер. Вместо имени “квадратики” – то бишь недопустимые символы. Вместо адреса аналогично. Заказ из Тайваня. Славу богу, хоть емейл-адрес клиента нормальными английскими буквами. После длительных трепыханий с кодировкой в админке Плимуса удалось показать информацию в Тайской кодировке.

Plimus Order

Вот и скажите, пожалуйста,  и как мне обрабатывать этот заказ? Как мне на эти кракозябры сгенерить регистрационный ключ?

Связался днем с клиентом по емейл на предмет его имени по английски. Но похоже, спит клиент в своем Тайване – благо разница в поясах часов в 8 будет точно. Ждем-с…

Первый раз такое вижу, чтобы Плимус пропускал азиатские имена. Похоже, конец света все-таки наступил…

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

Рубиновый вторник – мой лучший день

Интересная мысль  у Пастухова, что рекламные акции нужно запускать во вторник. И никогда ни в понедельник, ни в пятницу.

Буду краток (ц ВВП). Полностью согласен. Сколько ни пиарился на BitsDuJour или GOTD – понедельник это жопа! Наиболее тостое это явление (жопы) толще бывает только в воскресенье.

То же самое с релизами новых версий. Иногда я их релизю и в выходные, и уж тем более в понедельник или пятницу. Но вот анонсы вывешивать имеет смысл именно во вторник или четверг. Проще говоря, всю техническую работу делаем загодя, в тот же понедельник, или в выходные. Если есть поклонники проекта, они как раз успеют еще в “мертвые” дни сообщить о проблемах. А проблемы бывают. Редко, конечно, но все же – то не ту версию выложили, то забыли важный компонент включить, то еще что-то. Вот подобные, технического плана проблемы спокойно успеваем исправить.

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

Вот и получается, прямо по Григоряну: “Рубиновый вторник, в мой лучший день”.

PS: а еще по понедельникам иногда голова сильно болит после выходных… Тут уж не до публичной деятельности :)

суббота, 24 ноября 2012 г.

Библиотека автообновления программ

Предложение работадателя на КЫВТ разработать библиотеку для автоматического обновления программ вызвало небывалое бурление говен…

Еще бы! Только заявленных требований: проверить новую версию, скачать, отправить логи, обновить файлы, забекапить установленные, возможность откатить, режим транзакций, всё кроссплатформенно. И за всё это… 6000 рублёв. По слогам “шесть ты-сяч руб-лей” :). А за это заказчик так и быть выложит всё это в OpenSource да под своим именем. Ага, щаз! Впрочем, я как-то уже писал про авто-обновление.

Только недавно закончил автоматическое обновление для Aml Maple. Большая часть перечисленного выше там есть. Не всё.  Но и то вылизывал почти пару недель. Дьявол он в деталях. Что должно быть в информации о версии? Говорить ли пользователю про доступность обновлений? Показывать ли эту инфу прямо сейчас? А вдруг пользователь порнуху кино смотрит, или в блог строчит и не желает отвлекаться? Как проверять обновления в фоне, а показывать информацию несколько позже? Какую крутить рекламу? Добавлять ли новости проекта?

Вот где вся загвоздка, исключительно ориентированная на конкретный проект. А всякая фигня, вроде скачать файл и накатить обновление автоматически – это вообще дописывается за 5 минут. Там-то как раз все просто.

четверг, 15 ноября 2012 г.

воскресенье, 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 г.

вторник, 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 версией, или наоборот. Есть там нюансы, и именно в них весь дьявол. Но о них как-нибудь в другом посте.

среда, 1 февраля 2012 г.

Google Code Prettifier : Проверка связи

Попробуем-ка новую подсветку синтаксиса онлайл. Руководство здесь

Ну, а теперь код двухплюсовый.

#include «stdio.h»

bool condition=true;
while (condition) {//вечно, нах!
printf(“Hello, Code Prettifier”);//здарова, млин!
}


Сработало?

четверг, 26 января 2012 г.

Юзабилити. Про трей

Эх, давненько я не брал в руки шашки… Но лучше поздно, чем в штаны!

Напишу-ка я про не очень-то очевидную фичу в работе с треем. Для закваски пронзительная история, она же быль. Повадился у меня последнее время падать Проводник Windows. Падает как заведенный, впрочем при определенных обстоятельствах, но ни о них речь. Проводник после креша  сам перезапускается, но по ходу его перезапуска некоторые софтины в трее не восстанавливаются. Если с каким-нить TypeAndRun это пофиг — убил, и запустил заново, то софт с пользовательскими данными убивать через менеджер процессов уже не хочется. "Че-то я ачкую…" ©. Скажем, к примеру, рухнувшая база данных какого-нибудь The Bat может весьма и весьма попортить крови.

Способов решения проблем с упавшим Проводником, и как следствие, пересоздающейся на лету панели задач есть. Как вариант, ловить сообщение TaskBarCreated и восстанавливаться в трее, есть и другие.
Но есть способ элегантнее, надежнее, а главное комфортнее для пользователя. Приложение, свернутое в трей показывается в списке окон по Alt+Tab.

Это решение зарекомендовало себя просто великолепно.

  • Даже после пересозданной панели задач приложение в любом случае показывается в Alt+Tab списке.
  • В штатном режиме – безо всяких падений Проводника – пользователь в любой момент имеет возможность поднять приложение из трея клавиатурой, а не только мышкой. Выбираем окно из списка  Alt+Tab – приложение поднимается из трея. Для законченных гиков, которые при работе касаются мыша разве что чашкой кофе, это весьма и весьма немаловажный нюанс.

Как показал опыт, для приложений оперирующих пользовательскими данными, возможность подняться из трея с помощью клавиатуры почти обязательна для реализации. Сделал такое в Aml Pages. И ох сколько раз оно меня выручало. Нет слов! Про удобство молчу — у меня самого мышь все больше "для комплекту".

PS: кода вставки в список Alt+tab пока не дам. Потому как  жмот я. Потому как, пока доводил до ума добавление окон в список Alt+Tab, такой херни наворотил, что сам уже с превеликой тоской зрю в свой код. Ревьюить его, ревьюить и еще раз ревьюить.

Если в двух словах. Для окон верхнего уровня задача решается элементарно: нужно при прятке окна создать для него дочернее WS_OVERLAPPED-окошко, и задвинуть его за края экрана. А по активизации последнего из Alt+Tab-списка уже поднять из трея основное скрытое окно.

Но заморочки начинаются, когда необходимо добавить в Alt+Tab тул-окно (окно со стилем WS_EX_TOOLWINDOW).Вот пока реализовывал эту возможность и наворотил говно-коду. Теперь сначала причесать код нужно, а уж только потом "в народ". Так что сорсы как-нибудь позже. А уж если кому невмоготу да срочно — стучите в комменты.