Как избавиться от сообщения «Unresponsive script» в Firefox

Если вы часто работаете с сайтами, где используются интенсивные JavaScript вычисления, то вы навярняка сталкивались с таким сообщением «Unresponsive script». Оно выскакивает в Firefox, когда JavaScript использует под себя долгое время все процессорное время вашего компьютера. Firefox это замечает, скрипт приостанавливает, а вас спрашивает — продолжать выполнение скрипта или нет. Это, с одной стороны, хорошая фича Файрфокса, с другой — весьма надоедливая и неприятная, когда ваша работа требует каждодневного использования скриптов с такими вычислениями (например, массивные обработки крупной статистики).

Но это сообщение можно либо отключить совсем, либо увеличить лимит срабатывания. Для этого, наберите в строке броузера «about:config«, если будет предупреждение об осторожности смены настроек, согласитесь с ним. Там в строке фильтра неберите «dom.max_», Fire Fox отфильтрует вам настройки, в том числе такую — dom.max_script_run_time. Кликнете по ней и установите значение либо в ноль — отключить предупреждение, либо более 10 — это количество секунд, сколько максимум может использовать скрипт под себя процессорного времени — в таком случае, предупреждение будет появляться реже и только в крайних случаях.

Каков % пользователей с JavaScript?

На своих нескольких проектах уже замечал неоднократно такую статистику — по моим данным, только 70-73% рядовых пользователей интернета имеют включеную поддержку JavaScript. Сразу хочу заметить, что не Java, а JavaScript! Делаю эту поправку потому, что некоторые ошибочно думают, смотря в Google Analytics или в данные некоторых других счетчиков в  колонку Java (там, как правило, цифры за 90%). А ведь счетчики сами работают на JavaScript, и визит посетителя с отключенным JavaScript они просто не зафиксируют!

Как я посчитал эти цифры? Возьмем, к примеру логи Apache сервера. Они показывают сколько реально было загрузок какой либо страницы. Берем данные о загрузке страницы из этих логов -V1, затем смотрим, сколько нам посчитал счетчик, например Google Analytics — V2 (я обсчитывал статистику даже своими JavaScript счетчиками на основе Ajax). V1 — сколько всего смотрело людей, а V2 — у скольки включен скрипт. V2 всегда будет меньше V1, и если посчитать по формуле V2/V1*100%, то получится 70-73%. Проверьте сами! 🙂

Конечно, могут возразить — боты и все такое… Но я замерял на разных проектах — на известных и нет, и из разных источников. Цифры всегда были примерно одинаковые. Не верю, что везде процент ботов одинаковый!

Так что помните об этом, когда создаете страницу, работающую только на чистом JavaScript коде!

Как русифицировать англоязычные темы под WordPress

Захотелось мне избавиться от английских фраз в своей теме WordPress-а. Тема изначальна не работала для русского языка — автор ее не русифицировал, так как пока никто на возжелал в этом ему помочь (я ему отправил файлы переводя для этой темы, посмотрим, как оперативно он добавит).

Я, не зная изначально, как это делается, правил исходные коды темы на PHP. Все бы ничего, но меня это достало, и я решил разобраться, как же это делается цивилизованно. Итак, мои инструкции, скорее всего, помогут русифицировать любую тему, которую вы себе поставили («скорее всего» потому, что не знаю я всю кухню русификации пока)

Читать далее Как русифицировать англоязычные темы под WordPress

Самая мощная DDoS атака и офигенный Firewall…

  1. Одна человеческая клетка содержит 75Мб генетической информации
  2. Один сперматозоид содержит 37.5Мб.
  3. В одном миллилитре содержится около 100 млн сперматозоидов.
  4. В среднем, эякуляция длится 5 секунд и составляет 2.25 мл спермы.
  5. Таким образом, пропускная способность мужского члена будет равна:
  6. (37.5Мб x 100M x 2.25)/5 = (37 500 000 байт/сперматозоид x 100 000 000 сперматозоид/мл x 2.25 мл) / 5 секунд = 1 687 500 000 000 000 байт/секунду = 1 687.5 Терабайт/с
    Получается что женская яйцеклетка выдерживает эту DDoS-атаку на полтора терабайта в секунду, пропуская только один выбранный пакет данных и является самым офигенным в мире хардварным фаерволом…

Но тот один пакет, который она пропускает, валит систему на 9 месяцев…

View Cookies

Очень полезный плагинчик. Позволяет просматривать Cookies («куки», «кукис») сайта через «View Page Info». Без него вам бы пришлось каждый раз лезть глубоко в менюшки Firefox (Options -> Privacy -> Show Cookies -> указать домен), чтобы отыскать, какие же куки ставит данный сайт. А с помощью этого Addon вы легко увидите все куки сайта, как на ладони, посмотрев свойства страницы (он добавляет вкладку Cookies в это окно)

Пригодится вебмастерам, АВМам, Сиджеводам, программистам, и вообще всем, кто работает с сайтами на уровне кода 🙂

Чем редактировать XML?

Не знаю, как у вас, но для меня большой проблемой было найти приемлемый XML редактор, чтобы и XML проверял, и бесплатный, не слишком навороченный, но чтобы данные можно было вводить, не беспокоясь об ескейпе симолов &, <> и т.п..

Для простых задач, например, для таких, когда настройки к какой либо программе надо указать с помощью XML конфиг файла, подойдет редактор XML Notepad, который сделан ненавистной многими фирмой Micro$oft.

Лично я, пришел к выводу, что все редакторы XML либо слишком навороченные и платные, либо ненавороченные и не такие удобные, как XML Notepad. Не могу понять, почему такой популярный формат имеет такую низкую поддержку на уровне редактора… Наверное, может быть потому, что XML часто генерируется программами и ими же парсится, а редактировать ручками не так восстребованно. Но иногда очень надо, а пользоваться обычным текстовым редактором — глупо (постоянно следить за ескейпингом символов)

Из плюсов нашего героя можно перечислить: простота, и понятность.

Минусы: в нем можно настроить либо \r\n, либо \n символы концовки строки, миксовать он не умеет. Можно отключить Indent (имеет имя Auto Format в настройках, не мог сразу догадаться, что это именно Indent). Как то странно, IMHO. Еще один неприятный момент, но он лежит в нормальных рамках Unicode & UTF-8 — он вставляет всегда символ BOM вначале документа. Символ этот нужен для Unicode, для UTF-8 он бесполезен. Скорее всего, это издержки того, что внутри Windows такой документ храниться в Unicode, а для него BOM часто необходим (он указывает процессору Unicode в каком порядке идут старшие и младшие байты 16 разрядной кодировки). Но, многие программы спокойно работают с BOM, так как он аннулируется UTF-8.

Но плюсы перевешивают минусы. Если привыкнуть к этому редактору, то редактировать небольшие XML с ним очень просто.

Краткое пояснение: редактор представляет собой, в общем плане, два окна — левое и правое. В левом — идут названия элементов, аттрибутов и псевдо-нод (например, #text — текстовый child, #comment — комментарий и т.п..). В правом — значения этих элементов, напротив тех, что слева. Если вам надо отредактировать готовый XML, например, какие либо настройки, и не менять структуру XML, то редактирование сводится к изменению только значений в правом окне (перемещаемся курсом вверх-вниз, нажимая Enter — редактируем, Shift-Enter — вставка новой строки в значении). Это очень удобно! А чтобы в правом окне были все значения, как на ладоне, достаточно сделать из меню View -> Expand All, или Alt+V -> Enter или Alt + V -> E. После этого можно приступать к их редактированию.

Для удобства идеалогии редактирования, все строится на понятиях node и sibling (брат/сестра в переводе). Например, даже аттрибут елемента — это тоже node, у него есть parent — елемент, чьим аттрибутом он является. Из этого вытекает простое правило — для всех них существует две команды, через меню — вставка Before и After. Before — это вставить новый sibling перед текущим, выражаясь в понятиях DOM,  After — вставить после. Есть также третья команда — Child — вставить в текущую node.

Кратко об UTF-8

Просто об UTF-8

Этот пост для тех, кто не понимает, что такое UTF-8, но хочет это понять, а доступная документация часто очень обширно освещает этот вопрос. Я попробую здесь описать это так, как сам бы хотел, чтобы раньше мне кто-то так рассказал. Так как часто у меня по поводу UTF-8 была в голове каша.

Несколько простых правил

  1. Итак, UTF-8 — это «обертка» для Unicode. Это не отдельная кодировка символов, это «обертнутый» Unicode. Вы, наверное, знаете Base64 кодировку, или слышали о ней — она может обернуть бинарные данные в печатаемые символы. Дак вот, UTF-8 это такой же Base64 для Unicode, как Base64  для бинарных данных. Это раз. Если вы это поймете, то уже многое станет ясно. И она также, как Base64, признана решить проблему совместимости в символах (Base64 была придумана для email, чтобы передавать файлы почтой, в которой все символы — печатаемые)
  2. Далее, если код работает с UTF-8, то внутри он все равно работает с Unicode кодировками, то есть, где-то глубоко внутри есть таблицы символов именно Unicode символов. Правда, можно не иметь таблиц символов Unicode, если надо просто посчитать, сколько символов в строке, например (см. ниже)
  3. UTF-8 сделан с той целью, чтобы старые программы и сегодняшние компьютеры могли работать нормально с Unicode символами, как со старыми кодировками, типа KOI8, Windows-1251 и т.п.. В UTF-8 нет байтов с нулями, все байты — они либо от 0x01 — 0x7F, как обычный ASCII, либо 0x80 — 0xFF, что также работает под программами, написанными на Си, как и работало бы не с ASCII символами. Правда, для корректной работы с символами программа должна знать Unicode таблицы.
  4. Все, что имеет старший 7-ой бит в байте (если считать биты с нулевого) UTF-8 — часть кодированного потока Unicode.

UTF-8 изнутри

Если вы знаете битовую систему, то вот вам краткая памятка, как кодируется UTF-8:

Первый байт Unicode символа в UTF-8 начинается с байта, где 7-ой бит всегда единица, и 6-ой бит всегда также единица. При этом в первом байте, если смотреть на биты слева направо (7-ой, 6-ой и так до нулевого), идет столько единиц, сколько байтов, включая первый, идет на кодирование одного Unicode символа. Заканчивается последовательность единиц нулем. А после этого идут биты самого Unicode символа. Остальные биты Unicode символа попадают во второй, или даже в третий байты (максимум три, почему — смотрите чуть ниже). Остальные байты, кроме первого, всегда идут с началом ’10’ и потом 6 битов следующей части Unicode символа.

Пример

Например:  есть байты 11010000 и второй 10011110. Первый — начинается с ‘110’ — это значит, что раз две единицы — будет два байта UTF-8 потока, и второй байт, как и все остальные, начинается с ’10’. А кодируют эти два байта символ Unicode, который состоит из 10100 битов от первого куска + 101101 от второго, получается [10000][011110] ->  10000011110 -> 41E в 16-ричной системе, или U+041E в написании Unicode обозначений. Это символ большая русская О.

Сколько максимум байт на символ?

Также, давайте посмотрим, сколько максимум байт уходит в UTF-8, чтобы закодировать 16 бит кодировки Unicode. Вторые и далее байты всегда максимум могут вместить 6 бит. Значит, если начать с конечных байтов, то два байта уйдут точно (2-ой и третий), а первый должен начинаться с ‘1110’, чтобы закодировать три. Значит первый байт максимум в таком варианте может закодировать первые 4 бита символа Unicode. Получается 4 + 6 + 6 = 16 байт. Выходит, что UTF-8 может иметь либо 2, либо 3 байта на символ Unicode (один не может, так как нет надобности кодировать 6 бит (8 — 2 бита ’10’) — они будут ASCII символом. Именно поэтому первый байт UTF-8 никогда не может начинаться с ’10’).

Заключение

Кстати, благодаря такой кодировке, можно взять любой байт в потоке, и определить: является ли байт Unicode символом (если 7-ой бит — значит не ASCII), если да, то первый ли он в потоке UTF-8 или не первый (если ’10’, значит не первый), если не первый, то мы можем переместиться назад побайтово, чтобы найти первый код UTF-8 (у которого 6-ой бит будет 1), либо переместится вправо и пропустить все ’10’ байты, чтобы найти следующий символ. Благодаря такой кодировке, программы также могут, не зная Unicode, считать, сколько символов в строке (на основании первого байта UTF-8 вычислить длину символа в байтах). Вообщем, если подумать, кодировка UTF-8 придумана очень грамотно, и в то же время очень эффективно.

sed — некоторые тонкости regexp

До недавнего времени сколько бы я не делал попыток написать для sed хоть мало мальское регулярное выражение, оно у меня не работало. Я не мог понять в чем дело, ведь там синтаксис должен быть практически такой же, как в perl. Но для меня Sed оставался странной лошадкой, которую хотелось бы обуздать, но не получалось.

И вот, наконец, сегодня я прочел грамотную доку, а также в другом месте нашел объяснение моим проблемам. Оказывается, в sed есть очень мелкие, но важные отличия, поняв которые, вы сможете писать sed команды легко.

Итак, оказывается, по историческим причинам, чтобы не нарушать работу старых sed команд, в sed группировка (‘(‘, ‘)’) и некоторые другие спец. символы (‘+’ , ‘?’) были заменены на символы со слешем. Вот эти отличия:

В языке Perl В sed редакторе Пояснение
(…) \(…\) Группировка
{X,Y} \{X,Y\} Заданный множитель
+ \+ Повторитель — один и более раз
? \? Повторитель — один или ноль раз
\bfoo\b \<foo\> поиск ‘foo’ с границами слова
$1, $2 \1, \2 Подмена на группу

Самое главное, на чем я спотыкался всегда — я никак не мог додуматься, что ‘\’ должен ставиться перед ‘(‘, или перед ‘?’ и ‘+’ символами, например. Я видел иногда эти слеши в примерах, но я думал, что эти слеши относились к shell, но оказалось, что это тонкость sed-а.

P.S. Возникает вопрос, а как же тогда заменять сами символы: «?+{}()» в sed? А оказывается, их просто не надо ескейпить символом ‘\’. Получается как бы наоборот — эти символы сами по себе не ескейпяться, а когда нужно их специальное назначение, то перед ними ставим ‘\’. Типа все с ног на голову, если сравнивать с perl.

Чуть позже я выяснил, что у sed есть ключик запуска ‘-r’, который, собственно, переключает sed в тот режим, который работает со спецсимволами уже без слеша (то есть так, как привыкли perl программисты). Поэтому, есть второй вариант: просто добавить ключ -r в sed запуска, и усё будет работать по привычному 😉