RSS

Друг, я в тебя верю, ты хоть в Книге отзывов мыло оставь для связи, или аську.

18 апреля 2014.  О датах в новостях

Правило:
Даты в новостях должны быть всегда.

Самый клёвый вариант - дублировать дату ещё и в ЧПУ (как например в этом блоге). Если в чпу по каким-то причинам нельзя, то хотя бы краткую надпись внизу или вверху новости. Временной контекст - важная штука. Даже неитральные новости типа "Скоро мы откроем новый филиал..." или "В будущем я бы хотела изучить ..." привязаны ко времени, если смотреть на них через год или два.

В новости обязательно писать год, даже если вы думаете что новость актуальна только сейчас. Я просто десятки раз сталкивалась с ситуацией когда публикуют только день и месяц. Это особенно раздражает в новостях о веб-технологиях, типа "вышла новая  версия PHP4" или "СSS свойства которые поддерживают современные браузеры (FF3.6, Chrome 10, Opera 11)" - напишите блин год! Напоминает старый анекдот "Где я? К чёрту подробности в каком я городе?".

Отдельных лучей недоброты служат даты в виде "суббота", или "5 недель назад" - я ещё доверяю датам типа "Вчера" или "Сегодня" - но лучше пишите рядом дату в правильном формате.

Ещё, пользуясь случаем, хочу напомнить про статью Лебедева § 129. Новости на неновостных сайтах - она также актуальна и поныне.

P.S. Жалко, но cghub.com прикрыли.

13 апреля 2014.  Sorting files numeric in Midnight Commander via MC__USE_STR_UTF8_CREATE_KEY_FOR_FILENAME variable

Attention: For whose who doesn't speak russian, please use google translate of this page, or just find some english words in keypoints.

Сегодня небольшая заметка о linux. Название статьи по английски, т.к. мало ли кто из гугла будет искать, я лично ничего похожего не нашла.

Задача, у вас есть файлы, вида

  • 1.jpg
  • 2.jpg
  • 20.jpg
  • 3.jpg
  • 30.jpg

и т.п. (в моём случае файлы пользовательской базы данных онлайн-игры, но не важно). Гораздо проще с ними работать когда они в правильном порядке

  • 1.jpg
  • 2.jpg
  • 3.jpg
  • 20.jpg
  • 30.jpg

Самое смешное что эта возможность была в MC изначально, но по чьей-то глупой просьбе её выпилили. Выпилили, как водится, не совсем кошерно:

                #if 0 
 	1350	    /* case insensitive sort files in "a1 a2 a10" order */ 
 	1351	    result.create_key_for_filename = str_utf8_create_key_for_filename; 
 	1352	#else 
 	1353	    /* case insensitive sort files in "a1 a10 a2" order */ 
 	1354	    result.create_key_for_filename = str_utf8_create_key; 
 	1355	#endif 

Я не сильна в программировании на C, но думается мне что это условие if(false){ do somehting} =)

Ну что ж, я скачала сырцы MC отсюда - Sources of Midnight commander - http://ftp.midnight-commander.org/

и в файле mc-4.8.12/lib/strutil/strutilutf8.c нашла уже более годный кусок:

#ifdef MC__USE_STR_UTF8_CREATE_KEY_FOR_FILENAME
    /* case insensitive sort files in "a1 a2 a10" order */
    result.create_key_for_filename = str_utf8_create_key_for_filename;
#else
    /* case insensitive sort files in "a1 a10 a2" order */
    result.create_key_for_filename = str_utf8_create_key;
#endif

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

In the file config.h I've just added:
#define MC__USE_STR_UTF8_CREATE_KEY_FOR_FILENAME 1

Для компиляции мне пришлось установить пакеты

yum install glibc2-devel slang-devel

далее

./configure
make
make install

В Fedora пакет установится в /usr/local/bin/mc

Чтобы файлы сортировались как положено - вы должны выключить флажок Учёт регистра в  настройках сортировки.

For using good numeric sorting you should uncheck "Use sensitive sort" (so it became insensitive) in the sort dialog.

Всем чмоки!

P.S. Кто там пытался блог хакать - отпишись в гостевую, интересно ж. Ругаться не буду. Я целый час следила за твоими попытками =)

Метки данной записи: Linux

1 сентября 2013.  Автодополнение адреса для сайта

Сегодня я в очередной раз просматривала "уютненький хабрахабрик" и наткнулась на статью "Автодополнение адреса для сайта / Хабрахабр".

"Блин... а мужики-то не знают" - подумала я, и вспомнила, что действительно не писала о том как я сделала автодополнение адреса средствами карт Яндекса!

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

 В отличии от системы Кладр - у Яндекса есть несколько преимуществ:

  • Он абсолютно совместим (по написанию имён улиц и т.п) с системой Яндекс.Карт =) - чего нельзя сказать про Кладр.
  • Поиск сразу ранжируется по близости к нужному региону. (параметр ll в скрипте).
  • Он ощутимо быстрее.
  • Не нужны никакие api-key, им можно пользоваться бесплатно (что не запрещено - то разрешено).

В качестве источника данных я использую адрес:

http://suggest-maps.yandex.ru/suggest-geo?callback=show_suggestion&_=1302005670080&lang=ru-RU&ll=37.617671%2C55.755768&spn=2.399139%2C0.624969&highlight=1&fullpath=1&sep=1&search_type=all&part=часть адреса

Его знает любой, кто догадается поснифить траффик яндекс.карт. Я уже больше трёх лет жду когда же они сделают этот API открытым. То, что когда-нибудь так и будет я не сомневаюсь. Параметр callback я использую свой, так что в яндексе давно знают как и на каких сайтах их сервис используется. Пользуясь случаем передаю им спасибо за прекрасный сервис.

Готовый (почти) яваскрипт - тут http://kolomenka.ru/js/suggest_map_adress.js - пример действия в корзине этого сайта http://kolomenka.ru/cart/ - только сперва что-нибудь положить в корзину нужно.

Напомню что в код также нужно добавить некоторые стили:

/* opensearch js*/
#opensearch_input {font:11px Tahoma,sans-serif;/*padding-left:5px;*/}
#search_suggestion {z-index: 10; border: 1px solid gray; margin:0;list-style:none;padding:0; border-radius:3px;background:#fffffa;background:-moz-linear-gradient(top, #fffffa 0%,#f8f8f0 100%);}
#search_suggestion li {/*position:relative; */margin:0; padding:3px 90px 3px 7px; font:11px Tahoma,sans-serif;}
#search_suggestion i {position:absolute; right:0px;padding:1px 7px;}
#search_suggestion li.active {background:#fff0e8;text-decoration:underline;}
#search_suggestion li a {color: black; text-decoration:none;}
#search_suggestion li a:hover {color: #ff4000;text-decoration:underline;}
.item_price {background:transparent;border:none;}
/* opensearch js*/

Буду рада если кому-то поможет. На Хабре у меня аккаунта нет - но буду рада если вы перепишете эту статью там от своего имени и более подробно.

Метки данной записи:

14 июня 2013.  MariaDB vs MySQL

MariaDB в RedHat, CentOS и Fedora

Странно, что на Хабре я не нашла этой новости. Сегодня компания RedHat официально объявила о замене пакета MySQL на MariaDB в качестве пакета стандартной СУБД для веб-разработчиков:

А годом ранее, использовать MariaDB начал community проект Fedora. Пока использовали в качестве теста, оставляя приоритетным пакет mysql, однако в 19й версии главным будет именно пакет mariadb, а mysql будет выкладываться под названием community-mysql:

MariaDB в Википедии

Фонд Викимедия пару месяцев назад так же заявил о переходе на использование Марии в качестве бд. Пока для английской и немецкой версии википедии и ряда связанных проектов:

MariaDB в Мозилле

Три недели назад обновляли сайт поддержки мозиллы с mysql 5.1 на mariadb 5.5, правда не без косяков, но они были связаны с переходом с 5.1 на 5.5.

MySQL, MariaDB - в чем разница?

Многие из вас наверное в курсе что пять лет назад компанию MySQL купила компания Sun, а два года назад компанию Sun купила компания Oracle. Они как-то плохо её развивали, и делали всякие enterprise версии. Главный разработчик Michael Widenius (Monty) создатель MySQL, движка MyISAM и кучи всего - взял всех главных разработчиков и свалил в опенсорс. И они начали переписывать код так чтобы всё было в несколько раз быстрее и оптимизированней. Поэтому-то Фёдора с 17го релиза включала mariadb как альтернативную бд. В 19й версии они совсем заменят миску на марию. Мы с коллегами поглядели тесты, прониклись и решили попробовать уже сейчас.

Структура самих баз полностью идентична (читай совместима) - разные только сами программы. Подробнее можете почитать на офицальном сайте - https://mariadb.org. Мария должна (как и грядущая mysql 5.6) совсем не снижать производительности при большой нагрузке.

Для Fedora (и в будущем redhat и centos) система установки через yum очень простая - просто останавливаете Apache и Mysql, удаляете миску (php_mysql тоже удаляется по зависимостям), и ставите марию (и снова php_mysql).


Для фёдоры она есть в официальном репозитории начиная с 17й версии: http://mirror.yandex.ru/fedora/linux/updates/17/i386/, есть также и "родные" сборки для неё
http://mirror.timeweb.ru/mariadb/mariadb-5.5.31/yum/fedora17-x86/rpms/
https://downloads.mariadb.org/mariadb/repositories/ - собственно у них для всего есть свои сборки.

Новшества

Совместимость и быстродействие

Интересные факты

Создатель этих СУБД (Monty) называл их так в честь своих детей. MySQL - он так назвал в честь дочери My, MariaDB - в честь соответственно Maria и ещё он сделал движок MaxDB назвав соответственно в честь сына. Компания Oracle название mysql оставило себе, так что проект пришлось переименовать. Вместо MyISAM (который тоже в честь My) - он сделал новый движок Aria - который вроде будет очень быстрый. Сначала назвал Maria - но потом подумал что будет много путанницы. В общем объявил конкурс на название и победило Aria 

Вот уже пару недель как наш сервер использует MariaDB 5.5.31 в качестве основной СУБД. Да, да, и этот блог тоже =). (Кстати мы используем фёдору и центос на наших серверах). Полёт отличный. По грубым прикидкам скорость исполнения "медленных" запросов возрасла в 5-10 раз, быстрых запросов в 7-9 раз. Я уже предварительно договорилась с крупным хостинг-провайдером, чтобы они сообщили о результатах внедрения.

Метки данной записи: о бложике, Linux

30 мая 2013.  Placeholder, и юзабилити текстовых полей ввода.

Эпиграф

Здравствуйте дорогие читатели, жаль что почти полгода не писала никаких статей, а эту статью нужно было написать год назад, я всё не знала как за неё сесть. Наверное статья так бы никогда и не увидела свет, если бы мой друг и коллега mr.troll, не написал её за меня.Тема для меня является одной из самых важных. Речь пойдёт о текстовых полях ввода, а вы знаете как трепетно я отношусь к всевозможным формам, например: «Мастерство авторизации», «Основные ошибки проектирования процесса авторизации», «Пользователь важен для вас? Просто дайте ему зарегистрироваться», «Комментарии open_id». Статью можно считать гостевым постом, поскольку я давно приглашаю кого-нибудь написать свою статью в моём блоге. Надеюсь вам понравится. Итак, слово автору.

ваша Moony.

История проблемы

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

Здравствуйте читатели милого блога Usabili.ru,
Вы наверное знаете а таком атрибуте тега <input> как placeholder. Это такая небольшая подсказочка к текстовому полю ввода (включая пароли и textarea), которая  отображается там до тех пор, пока пользователь не активировал этот input. Такую же штуку, но по старинке на яваскриптах и label'ах ребята из Яндекса делают в своих интерфейсах, например yandex.ruhttp://mail.yandex.com/ и т.п. Сейчас у двух браузеров: Оперы (пока не перешла на вебкит) и IE (9-10) абсолютно правильная реализация данного атрибута, т.е. текст подсказки необходимо сразу прятать, как только пользователь передал фокус в поле ввода (кликнул на него например). Так вот, нынешняя тенденция поведения браузеров — не является удобным для пользователя, уже почти год вебкит не убирает текстовую подсказку по клику, т.е она убирается только тогда когда пользователь начал печатать текст. Я считаю что это поведение смущает пользователя, поскольку  естественным является печать в поле в котором нет текста. Печать в поле в котором текст уже есть, и который не удаляется (через delete или backspace) — очень негативно сказывается на UX.

Данное поведение вебкита — изначально противоречило спецификации, однако из-за него Хикси (Ян Хигсон, единоличный и ответственный редактор html5) разрешил оба варианта — см http://lists.w3.org/Archives/Public/public-html-diffs/2011Oct/0174.html . Я связывался с ним по поводу его решения, увы он сказал что спецификация лишь отражает поведение браузеров, и это все вопросы юзабилити должны решать вендоры браузеров. Правильное поведение сейчас есть у Оперы (Presto) и MSIE 9 и даже в новом IE10.
Не правильное поведение сейчас у Хрома (и многих вебкитовых браузеров) и Файрфокса, который так же не предупреждая изменил его в 16й версии.

Плюсы и минусы нового поведения placeholder

- Пользователь не может отличить placeholder и предустановленное value. Цвет placeholder - наследуется напрямую от input. Поэтому если вы изменили цвет текста для input цвет value и placeholder будут одинаковый. По умолчанию в некоторых браузерах placeholder светлее, однако нельзя сделать его всегда светлее, ибо при другом цвете фона лучше использовать тот цвет который задал пользователь для input.
- Пользователь не уверен, кликнул ли он в поле ввода. Что особенно трудно сказать на тач-устройствах.
- Пользователь может попытаться удалить текст в поле ввода - и это не получится ни клавишу delete ни через backspace

+ Пользователь знает какой плейсхолдер используется в поле ввода, даже кликнув на него (но перед тем как начать печатать). На мой взгляд это сомнительный плюс, только если у пользователя после клика наступил склероз и он реально забыл что же было в поле ввода. Хотя многие видные люди не хотят ориентироваться на "достаточно умных" пользователей, я полагаю что распространённым поведением пользователя - является смотреть куда он тыкает мышкой. Для пользователей которые не смотрят куда они тыкают - априори не возможно сделать качественный интерфейс.
+ Пользователь знает какой плейсхолдер используется, если поле ввода имеет автофокус (пример mail.yandex.com ). Это тоже очень сомнительный плюс. Поскольку по правилам юзабилити - плейсхолдер конечно должен использоваться для описания поле ввода, но не должен использоваться как единственное описание. Так же в случае со связкой логин/пароль - автофокус на поле логина (скрывающий подсказку что первое поле логин) - может быть очевидным для пользователей которые привыкли что на сайтах авторизация через поля логин/пароль, а так же абсолютно очевидна для пользователей которые уже использовали эту форму входа. Вообще автофокус - это единственный и редкий случай где не скрывание текста подсказки хоть как-то оправдано.

Подробнее

О том почему критически важно чтобы подсказка убиралась по клику, а не при вводе текста я подробно писал в трекере мозиллы https://bugzilla.mozilla.org/show_bug.cgi?id=673873#c57 — тут несколько моих комментариев, ну и https://bugzilla.mozilla.org/show_bug.cgi?id=758996 тоже можно глянуть. Если кратко, основная проблема такая: Когда пользователь кликает на поле ввода и placeholder пропадает, он думает: "О. Тут был placeholder". Когда пользователь кликает на поле и placeholder остаётся видимым, он думает: "Что это? Это placeholder или value? Могу ли я печатать текст или сначала нужно удалить то что в поле ввода?". и т.п. Пока я добился от мозиллы настройки dom.placeholder.show_on_focus однако это лишь частичное решение. Как вебмастер мне приходится использовать такую конструкцию:

input:focus:-moz-placeholder {color:transparent;}
input:focus::-webkit-input-placeholder {color:transparent;}
input:-moz-placeholder {font-style:italic;color:#ccc;}
input::-webkit-input-placeholder {font-style:italic;color:#ccc;}
/*  Замечу — свойства вебкита и мозиллы не группируются между собой! */

А в будущем вместо псевдокласса :-moz-placeholder (для старых версий фф) нужно будет писать ещё и псевдоэлемент ::-moz-placeholder. и т.п.

Далее небольшой перевод моих комментариев из багзиллы фф:

Hixie изменил "И" на "И/ИЛИ", и браузер-вендоры стали бездумно реализовывать такое поведение. Разве так можно? часть "И" никто не отменял.

По мне, так у нового поведения серьезная проблема с UX. Быть такого не может, чтобы кому-либо было удобно начинать печатать в поле, уже содержащем текст! Разве я могу предвидеть, что текст магическим образом исчезнет, стоит начать печатать? Замещаемый текст нельзя удалить ни клавишей Delete, ни сочетанием Ctrl+A, Backspace. От него вообще нельзя избавить никоим образом, кроме как начать печатать.

Хотите пример поля с текстом в фокусе, который замещается при начале ввода? Это mcedit (linux Midnight Commander). При открытии поискового диалога, в поле запроса уже находится последнее использованное ключевое слово. И если начнете вводить в это поле текст, это слово поведет себя, как замещающийся текст. Но если не начнете, — оно произведет поиск по ключевому слову, а не по пустой строке! Поэтому это не placeholder - это предопределённое значение (predefined value).

Хотите ещё? Далеко ходить не надо, в Windows просто нажмите Win+R, и вы получите диалоговое окно Run, в котором отображена последняя выбранная в нем команда – если вы начнете печатать, она, ясное дело, удалится, потому что это был выделенный текст, но если не начнете печатать ­­– выполнена будет последняя команда.

Как пользователю различить, то ли это замещаемый текст, то ли предопределённое значение? Единственный метод – поставить курсор!

Таким образом, разве может пользователь при работе с браузером ожидать, что поле, которое ведет себя как с предопределенным значением при установке курсора, будет обработана как пустая строка?  Раньше всё было просто: если после установки курсора строка становится пустой – то в форму отправится пустая строка.

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

По мне, так вы сломали всю функциональность замещаемого текста. Единственный способ – имитировать его java-скриптом, как мы делали лет десять назад. И как http://mail.yandex.com/ делает ныне.

И ради чего? Ради пользователей, которые могут забыть замещаемый текст сразу после того, как кликнули на поле для ввода? Так, что ли?

Сайт, над которым я сейчас работаю включает светло-серый цвет  вводимого текста (#a0a4ad), и если вы сможете выбрать цвет, вы  увидете, что замещаемый текст, в моем случае, использует цвет вводимого текста. И при наведении фокуса ничего не изменяется (кроме текстового курсора), вот в чем соль.

Если у поля ввода с замещаемым текстом есть автофокус – замечательно. Если нет – веб-мастеру следует поместить пометку вне поля ввода. Опять же смотрите http://mail.yandex.com/, там автофокус на поле ввода. Если пользователь недостаточно сообразителен, чтобы понять, что это поле для логина, он уберет курсор и прочитает, и в следующий раз уже будет в курсе, для чего это поле. Но текст в поле с курсором будет напрягать его при каждом посещении! И ничего с этим не поделать. Почему бы не показывать замещаемый текст только для автоматически наводящегося курсора, раз уж так необходимо?

Примените следующий код и попытайтесь ввести значение поля:

<form><input type="text" required placeholder="Something"></form>

Это может заставить понервничать даже меня! Оно заявляет мне, что поле пусто – но, эй! – в нем установлен курсор и, я могу поклясться Мозилле, что вижу в нем текст!

Почему не делают никаких UX ревью? Старое доброе правило юзабилити гласит: «Когда достаточно места, и метка для поля ввода важна – используй <label> вне поля ввода вместо placeholder; используй <label>, когда много полей для ввода. Но если есть только одиночная форма поиска, или пара полей логин/пароль, или что-либо столь же очевидное для пользователя – можешь использовать замещаемый текст.» Таким образом,  я полагаю, что атрибут замещаемого текста используется только в том случае, если пользователь может догадаться о его содержании (ie8 вообще не способен его отображать). Получается,  программисты мозиллы считают, что замещаемый текст всегда настолько важен, что должен пользователь должен видеть его даже после клика?! Я не верю, что пользователь может забыть его сразу после клика.

Вот мой основной вопрос: если у вас есть работающий код, зачем его менять? Если у вас есть код, работающий ХОРОШО и всех устраивающий, то зачем его менять?

Может кто-нибудь будет любезен и выскажет личное недовольство старым поведением?  И тем самым дать мне причину?

Славно, что этот баг не будет подтвержден в Gnome по причинам, которые я описал выше.

https://bugzilla.gnome.org/show_bug.cgi?id=667502 - Хорошо для Gnome.

 
Пользователя гораздо больше смущает ситуация, когда он попал курсором в поле и больше не видит подсказки, которая была в поле. Когда он увидит её, прочтёт и поймёт, что писать — она изсчезнет. Это поведение, к примеру, идёт сквозь все интерфейсы системы Mac OS X.

Я считаю это очень правильным решением. Это не баг, это хорошая идея.

Если вы с этим не согласны, вы вольны сделать тот самый фикс в CSS ваших проектов. Но на мой взгляд, вы только запутаете его. А пока обратите на плейсхолдер в адресном и поисковом полях интерфейса Оперы — подсказки в них не исчезают при установке курсора.

Пруф того что в IE10 плейсхолдер специально убирается по клику можно посмотреть тут:

везде пишут "Placeholder text is visible until focus is placed in the element." и т.п.

А вот список связанных багов в FF:

P.S. Moony: Статья была написана вообще-то полгода назад. Но перечитать несколько раз и выложить её руки дошли только сегодня. Сорри. Надеюсь вам интересна проблема с placeholder.

Под катом вы можете также посмотреть переписку с Хикси:

27 марта 2013.   Как белорусские веб-студии отвечают на запросы клиентов

Здравствуйте дорогие читатели. Я уже говорила, что с удовольствием размещу гостевые статьи в своём блоге. На этот призыв недавно откликнулся товарищ Игорь, из нового белорусского digital ресурса wedigital.by, представив прекрасную статью-исследование по работе веб студий в Беларусии. Оригинал статьи, также размещён тут: Как белорусские веб-студии отвечают на запросы клиентов. Я надеюсь вам будет интересно.

Как белорусские веб-студии отвечают на запросы клиентов

Мы устроили небольшую проверочку самочувствия  обычного клиента, который собирается заказать разработку самого обычного сайта. Оказалось не таким уж  простым делом выбрать подходящую веб-студию и получить добросовестный и адекватный  ответ на письмо. Нами взяты  44 компании из топа Яндекса по запросу “создание сайта” в регионе “Минск” и из рейтинга marketing.by на 2011 год:

Метки данной записи: cтатистика

8 марта 2013.  С 8 марта!

Поздравляю всех девушек с 8 марта! Мужчин, с прошедшим 23 февраля (извините, болела, не поздравила вовремя).

В честь дня рождения блога - завтра статья про плейсхолдеры!

Метки данной записи:

14 сентября 2012.  Приглашаются авторы

Поскольку я давно не писала (отдыхала, болела, и т.п.), я думаю что самое время дать слово гостям моего бложика. Если вы IT-специалист и вы хотите донести до мира какую-то важную информацию — Welcome! Либо если хотите попиарить свой блог — это тоже хороший способ. Перевод иностранных статей также приветствуется, обязательно со ссылкой на орининал.

Так же в списке статей — и на самой странице статьи везде будет указано имя автора. (и предположительно аватар).

Я обещаю что вернусь к написанию статей в ближайшее время.

Метки данной записи:

22 июля 2012.  Короткие заметки

Хочу написать пару интересный вещей, на случай если кому-то пригодится.

1) В файрфоксе вкладки можно прикреплять, тогда вкладка будет считаться "App tab", будет всегда прикреплена слева иметь приоритет выполнения скриптов такой же как активная вкладка. (В неактивных вкладках различные анимации и т.п. будут приостанавливаться). Но главную интересную фишку, я нашла недавно. Прикреплённые вкладки, например gmail могут мигать, оповещая пользователя об изменениях на странице. Мигает вкладка в том случае — если у данной страницы меняется title. Это легко проверить следующим кодом:

<script>
    // for firefox glowing pinned tab
    // window.setInterval  (function  (){document.title=Math.random  ();},500);
</script>

2) В случае с <input type="number">, если вы сами хотите оформить стрелочки инпута — движки webkit позволяют их отключать. Используйте вот такой код:

input::-webkit-outer-spin-button,
input::-webkit-inner-spin-button {
    /* display: none; <- Crashes Chrome on hover */
    -webkit-appearance: none;
    margin: 0; /* <-- Apparently some margin are still there even though it's hidden */
}

Хочу специально заметить что в случае полей ввода для цифр — не желательно использовать input type="text", так как на мобильных устройствах для этих полей будет показываться текстовая клавиатура, вместо числовой.

3) Firefox в 17й версии будет поддерживать крупные иконки сайтов в адресной строке, что не удивительно с появлением ретины. https://wiki.mozilla.org/Improve_display_of_location_bar_results. По ссылке есть макет концепта
 

Пока этого нет в nightly, но надеюсь скоро появится. Так что можете заранее начать переделывать иконки своих сайтов, если хочется =). Будьте первыми. Надеюсь другие браузеры так же будут использовать большие иконки в своём UI.

Замечу что это касается только favicon.ico. Для айпадика например вы можете задавать большие иконки, но для совершенно других целей.

With Apple's formatting (rounded corners, reflective shine)
<link rel="apple-touch-icon" href="somepath/image.png" />
Without reflective shine
<link rel="apple-touch-icon-precomposed" href="somepath/image.png" />

Ещё интересное про иконки:

4) Ни для кого не секрет какой тормозной плагин скайпа к браузерам, который подсвечивает телефоны на странице. Он перехватывает все изменения DOM в поисках номера, чем заметно тормозит скрипты, и портит дизайн страницы. В Firefox этот плагин в чёрном списке (надеюсь что приложила к этому руку). Тем не менее, где-то мелькала новость что плагин на конкретном сайте вебмастер может отключить добавив следующий метатег.: (подробнее тут)

<meta name="SKYPE_TOOLBAR" content="SKYPE_TOOLBAR_PARSER_COMPATIBLE" />
<meta content="telephone=no" name="format-detection">

 

Метки данной записи: вёрстка, браузеры

27 июня 2012.  Как сделать, чтобы письма не попадали в спам 2. DKIM

Пару лет назад, я написала статью «Как сделать, чтобы письма не попадали в спам ящик».

Вчера мы с коллегами настроили ещё один метод подтверждения писем, под названием DKIM. Его можно использовать вместе с SPF.

Authentication-Results: mxfront7.mail.yandex.net; spf=pass (mxfront7.mail.yandex.net: domain of usabili.ru designates 209.85.212.180 as permitted sender) smtp.mail=askme@usabili.ru; dkim=pass header.i=@usabili.ru

Разница в том, что SPF - подтверждает IP адрес отправителя. DKIM же ip-адрес не учитывает, но подтверждает факт того, что конкретно отправитель имеет секретный ключ, который можно проверить публичным ключом, указанным в днс-записи.

Яндекс, судя по всему, считает DKIM более приоритетным средством борьбы со спамом. См. статью  «Цифровая подпись — Яндекс.Помощь: Почта». По этой причине, только письма проверенные через DKIM получают красивенькую медальку рядом с адресом отправителя.

Проверка DKIM для получателя гораздо проще, чем SPF. Так как для проверки DKIM требуется запросить всего одну днс запись, например для моего домена default._domainkey.usabili.ru, и получить оттуда публичный ключ домена, которым можно проверить хеш заголовков, т.е. цифровую подпись (что докажет что я владелец секретного ключа).

В случае же с SPF, процедура проверки сложнее, т.к. надо взять днс запись, из неё взять список разрешённых ip, и ссылки на другие spf записи, которые тоже надо рекурсивно обработать и т.п. Затем сверить ip отправителя с данным списком. В случае, когда письмо проходит через несколько серверов, желательно подписать их все.

А вот отправителю, наоборот, настроить у себя поддержку SPF на порядок проще, чем настроить DKIM. Как я уже писала, для настройки SPF достаточно создать запись:

usabili.ru. IN TXT "v=spf1 a include:_spf.google.com ~all"

Эта строчка разрешает слать почту только с ip указанного в A-записи домена, и с серверов гугл.

Как настроить DKIM в службах для домена от Google

Всё подробно написано вот в этом мануале:
http://support.google.com/a/bin/answer.py?hl=ru&answer=174124
если вкратце, то

  1. Зайти на нужную страницу в панели владельца домена гугл
  2. Выбрать домен и получить код для вставки в днс
  3. Вставить нужный код в TXT запись поддомена. Например, у меня google2._domainkey.usabili.ru
  4. Активировать
  5. ...
  6. Profit. Ваши письма, посланные из Gmail, теперь подписываются ключом домена.

Как настроить подпись писем с сервера, при отправке через PHP

Если вы отправляете письма в PHP через SMTP сервера гугла, то всё уже сделано. Гугл использует подпись при отправке через SMTP.

Если же вы отправляете почту функцией mail, то в системе необходимо установить пакет dkim-filter.

yum install dkim-filter

Или

aptitude install dkim-filter

Затем сгенерировать ключ через dkim-genkey. Лентяи вроде нас, могут использовать его для всех доменов на сервере. Сгенерированный в файле .txt публичный ключ нужно добавить в днс записи доменов.

Далее читаем статьи

 Личные комментарии по настройке sendmail.

  • Для sendmail нужно редактировать файл /etc/mail/sendmail.mc, не submit.mc.
  • Для компиляции конфига удобно вместо m4 использовать прилагающийся make (он сам запустит m4).

Как проверить записи DKIM

Для этого можно воспользоваться онлайн сервисом http://dkimcore.org/c/keycheck, либо послать письмо на указанный тут адрес http://appmaildev.com/en/dkim/.

Пользователи линукса могут набрать команду # dig google2._domainkey.usabili.ru TXT

Либо послать письмо на ящик в гугле или яндексе.

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

от:  BoughCMS Notify noreply@usabili.ru
кому:  ***
дата:  28 июня 2012 г., 15:08
тема:  Usabili.ru: Письмо с сайта
отправлено через:  ***.ru
подписан:  usabili.ru

Заключение

Хочу обратить внимание на ещё несколько пунктов.

Если вы используете возможность гмайла "Отправлять письма как:", т.е. не отправлять их напрямую со своего ящика. То гмайл будет подписывать DKIM оригинальным ящиком отправителя, а не вашим доменом.

Если вы абсолютно уверены, что успешно настроили DKIM, то можете запретить другим серверам принимать письма с вашим доменом, но без подписи, добавив ADSP запись:

_adsp._domainkey IN TXT "dkim=all"

Update

Я совсем забыла рассказать про то как присваивать доменные подписи конкретным email адресам. Дело в том что вы можете отправить почту с домена X, через почтовый сервер домена Y, а подписать его ключом домена Z. И это даже будет работать =). Настройка ключей происходит в файле /etc/mail/dkim-milter/keys/keypath. Здесь стоит обратить внимание на часть строк, задающую sender-pattern, она может содержать звёздочку, как часть или весь домен. В случае указания просто звёздочки, данным ключом и доменом будут подписываться все письма.

# sender-pattern:signing-domain:keypath
# *:example.com:selector
*@usabili.ru:usabili.ru:/etc/mail/dkim-milter/keys/default
# тут всякие остальные домены, а ниже домен для подписи по-умолчанию.
*:verytec.ru:/etc/mail/dkim-milter/keys/default

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

Всего вам доброго =)

Метки данной записи: советы

Предыдущие записи, смотрите в архиве новостей »

Подпишитесь на статьи через RSS

15 самых популярных статей: