Хотелось бы дополнить, что это нужно в Fx и Opera, а Chrome и без того даёт качественные сообщения и ссылки на строку ошибки.
С учётом Fx лучше писать такую обёртку:
(function(){
var u ='undefined'
, win = typeof unsafeWindow !=u ? unsafeWindow: window;
//... далее, код, не требующий контроля ошибок
try{
//...код с контролем ошибок
}catch(er){
win.console.log("~~ER_global: "+ er +' (line '+(er.lineNumber||'')+')')}; //для оповещения об ошибках в Fx
})()
Совет 2-й: раз уж пишем функцию-обёртку, почему бы не использовать её:
Совет 3-й: используйте метаданные не только в одном месте:
(function(){var alienFrame = /(plusone\.google\.com|userscripts\.org)/.test(location.host)
, currMetaTx = !alienFrame && function(s){return(s=
//если Firefox+GreaseMonkey, требуется удалить "/*" перед "<!", чтобы читались многострочные данные!
/*<![CDATA[*//*
// ==UserScript==
// @name HabrAjax
// @version 0.82_2012-03-27
// @namespace spmbt.kodingen.com/index.htm
// @author spmbt0
// @description Cumulative script with over 20 functions for Fx-Opera-Chrome-Safari
// @include http://habrahabr.ru/*
// @include https://plusone.google.com/*
// @include http://userscripts.org/scripts/source/*
// @exclude http://habrahabr.ru/api/*
// @resource meta 121690.meta.js
// @update 0.82 механизм плагинов и модулей через CustomEvent (Fx6+, Chrome, Safari)
// @update 0.815 совместимость со скриптом переключателя режимов "Все блоги - Избранные" (HabrAllHub)
// @icon data:image/gif;base64,R0lGODlhIAAgAMMBAG6Wyv///2+NtIucstfY2b/FzpSmvY+QkM3Nzunp6fLy8qGwweDg4MbFxa2trrm6uiwAAAAAIAAgAAAE/xDISau9OM/AOe2edoHBBwqiRZodmrKhRLqXYFfrdmLCQBQGWk62swgOiERAQQgChs9iRZBMKDgEFGn...
// ==/UserScript==
*/s//]]>
)} //-вернёт false, если не продолжать; 'false' (строку) - если Fx; иначе - строки метаданных
, u ='undefined'
, isUsfW = typeof unsafeWindow !=u
, win = isUsfW ? unsafeWindow: window
, isFxGmS = win !==window
, isFxScr = typeof GM_getMetadata !=u
, readMeta = function(s, isFxScr){ //парсинг многострочного текста по мета-директивам
if(typeof s !='string') //очистка оболочки функций, выделение мн-стр-комментария
s = typeof s=='function'
? ((/\*/.test(function(){/**/}+1) ? s : s(!1) )+'')
.replace(/(^[\s\S]*\*\/\/\*\r?\n?|\r?\n?\*\/s[\s\S]*$)/gm,'')
: (typeof s !=u && s!==null && s.toString ? s.toString() :''); //здесь же- 'xml'
var metaD ={}, j =0;
if(s==='false' && isFxScr){ //isFxScr - получать ли данные средствами Scriptish
metaD = GM_getMetadata();
for(var i in metaD){ //приведение к нормальному виду
if(metaD[i].length ==1)
metaD[i] = metaD[i][0];
j++;
}
}else{
var meta = s.split('\n'), aa, a2;
for(var i=0, mL = meta.length; i < mL; i++){
if(( aa = /^.*?\/\/\s*@([\S]+)\s(\s*)(.*)/g.exec(meta[i]) )){
a2 = aa[3] !==undefined && aa[3] || aa[2];
if(metaD[aa[1]]===undefined)
metaD[aa[1]] = a2;
else{
if(! (metaD[aa[1]] instanceof Array))
metaD[aa[1]] = [metaD[aa[1]]];
metaD[aa[1]].push(a2);
}
j++;
}else
if(!/^.*?\/\/\s*[\-=]*\s*\/?\s*UserScript\s*[\-=]*\s*$/i.test(meta[i]))
metaD[j++] = meta[i];
}
}
metaD._length = j; //число ключей хеша
return j >1 && metaD || undefined; //хеш директив + нум.список простых строк + _length -чис.простых строк или und., если не найдено
},
metaD = readMeta(currMetaTx, isFxScr); //теперь можно читать метаданные в этом хеше (кроссбраузерно!)
простите, если «многобукв». В общем, по коду заголовка вы догадались где искать пример этой фичи.
Совет 4-й. Советует использовать в связке с советом 3 не GreaseMonkey (ещё раз, НЕ GreaseMonkey!) а Scriptish. Потому что для GreaseMonkey в этой фиче — принципиально неустранимая некроссбраузерность (я, кажется, об этом писал в статье, но не уверен, может быть лежит в черновиках).
Совет 5-й. Получайте кроссбраузерно внешние метаданные — от самого скрипта, от других скриптов, от анонсов скриптов на ваших серверах. Пример кода смотрите там же, откуда он взят для совета 3, ибо было бы ещё почти столько же.
Совет 6-й. Если в коде вы сделали синтаксическую ошибку, легко обнаружить её поможет только Хром. Запустите неработающий скрипт в Хроме, это путь к спасению, он укажет путь к просветл пропущенной запятой.
Совет 7-й. Метаться в Хром иногда лениво, поэтому озаботьтесь хорошим механизмом трассировки, она очень-очень пригодится. Уже имеется win.console.log, но это длинно и не очень удобно. Делаем так:
var wcl = function(){ //консоль как метод строки или функция, с отключением по noConsole ==1
if(win.console && !noConsole)
win.console.log.apply(console, this instanceof String
? ["'=="+this+"'"].concat([].slice.call(arguments)) : arguments);
};
String.prototype.wcl = wcl;
(впрочем, это полезно и в простых скриптах).
Что получили? Можем писать
'myVar'.wcl(myWar);
Почему так? Потому что их будет много, без меток трассировочные значения будут все на одно лицо. ЗАчем там '=='+...? Чтобы лучше видеть. Зачем в апострофах? Чтобы лучше находить в коде по ctrl-F. (И теперь видно, зачем здесь константа noConsole из совета 2?)
Совет 8-й. Содержите кроссбраузерную функцию кроссдоменного обмена по postMessage, она отличается от функции для простых скриптов. (А в Хроме она и для внутридоменного понадобится.) Я об этом обещал написать, скоро напишу, статья готова, а реализацию можно увидеть опять же, в том же источнике примеров.
Совет 9-й. (Думаю, ещё не сучно.) Используйте легковесную библиотеку, не поддерживающую IE, если не собираетесь (с большой вероятностью, думается, это так) поддерживать юзерскрипты там. Zepto, AtomJs, Backbone или что-то небольшое своё — оно всегда пригодится — работа с DOM, с событиями, массивами, хешами. Впрочем, примеров и образцов нет. В моих примерах есть, но очень примитивное ядро на 2-3 К, не советовал бы брать за основу.
Совет 10-й (продожение 9-го). Среди полезных исполльзуемых функцих, кроме работы с DOM, будут и:
подгрузка стилей:
,
подгрузка сторонних скриптов (кода многовато на все случаи, приводить не буду),
специфическое ожидание целевого условия по таймеру (очень частая функция), для примера ищите execCallback в HabrAjax,
генерация User Event и CustomEvent — полезная техника,
показ подсказок по наведению мыши (примеров нет),
открывание ссылок в фрейме, если нужно для задачи,
группа функций работы с настройками вашего скрипта.
Вот это — я понимаю, полезные советы, вполне достаточные для работы с юзерскриптами…
В принципе, все довольно тривиально. Копать нужно в сторону того, что Гугл и Яндекс авторизированным пользователям лепит определенные куки и, если успешно вводится капча, тоже присоединяет нечто.
Через АПИ хрома ищи «полезные» печенья и прикрепляем к запросу.
Насколько я помню для Яндекса это «fuid01» / «spravka», для Гугла — «S».
Никакого.
Макросы. Только макросы.
Шапка — папка с именем и description. Копируется лапами. Тут я взял «Projects», хотя это ни разу не проекты, а задачи, надо было другую скопировать.
ЛОЛчто?!
Читаем внимательно про Custom Domains в описании Github Pages.
Нужно просто в корне репозитория создать файлик CNAME, а в нем написать домен. Если это под-домен, то нужно прописать CNAME-запись, которая будет указывать на username.github.com. А если это домен верхнего уровня — A-запись, указывающую на 207.97.227.245 (CNAME для доменов верхнего уровня лучше не использовать...). А теперь подождите, пока обновятся DNS и voilà.
Все это возможно как на платных аккаунтах, так и на бесплатных. Как для личной страницы (репозитория вида username.github.com), так и для Pages любого проекта!
Горазда проще купить пленку oracal 641, и наклеить на всю стену, так сделал яндекс (во многих кабинатах у них заклеены стены пленкой). Также можно купить краску IdeaPaint, правда выйдет дороже.
Неплохой обзор, спасибо.
Сам сижу на WordPress и после установки связки Pure PHP Localization + WPLANG Lite + DB Cache — монстр стал шевелиться быстрее и эффективнее.
зы: пробелы после точек всё-таки необходимы.
Многие не понимаю разницы, поэтому попробую объяснить технические премудрости.
Пункты определяют абсолютные физические размеры и с другими физическими размерами определена такая связь: 72 pt = 1 in = 2.54 cm = 25.4 mm = 12 pc, т.е. если бы все браузеры соблюдали правила CSS, то размер в 72 pt занимал бы ровно один дюйм на любом устройстве. Это очень удобно, если вы хотите показать пользователю прямоугольник с высотой в один дюйм, но не всегда удобно для отображения шрифтов. Например, размер шрифта в 14 pt будет легко читаться с экрана ноутбука или мобильного телефона, но, чтобы прочитать тот же шрифт на телевизоре, вам придётся сидеть рядом с телевизором впритык. Если вы попробуете прочитать те же самые буквы сидя на диване далеко от телевизора, то буквы сольются в одну линию.
Ещё замутнее обстоит дело с пикселями. Пиксель в CSS — это по определению тонкая, острая линия, которую может показать устройство, но он не имеет ничего общего с настоящими пикселями устройства. Точнее, имел, но в CSS2 это убрали. В CSS1 пиксель равнялся пикселям устройства. Представьте себе какая бы разница была в картинках на экране и на бумаге. Если на экране с разрешением 96 px на дюйм картинка в 960 px занимала бы 10 дюймов, то на бумаге у принтера с разрешением 600 px на дюйм — в 6 раз меньше! Технически это правильно, но для пользователей это часто контринтуитивно. Поэтому в CSS2 ввели два понятия: во-первых, связали пиксель CSS с абсолютным значением в 0.75 pt, а во-вторых ввели понятие референтного пикселя — он рассчитывается через визуальный угол, который занимает пиксель в 0.75 pt на экране устройства с разрешением в 96 px на дюйм c расстояния вытянутой руки. В этой ситуации пиксель занимает 0.26 mm. Теперь, используя этот угл, можно отойти от телевизора и сказать, что пиксель телевизора будет иметь размер 1.3 mm.
Так как теперь у нас возникла связь между физическими размерами в пунктах и нашим новым, выдуманным пикселем, то теперь можно смело писать сайты используя эти абсолютные единицы и не бояться, что куда-то что-то поедет. Между ними теперь есть чётко заданная связь. Теперь все проблемы с масштабированием свалили на браузеры и на пользователей.
Единицы CSS em и ex определяют относительные размеры и берут их из размеров шрифта. em — это просто размер шрифта. ex — размер маленькой буквы «x» этого шрифта, либо «x-height» свойство шрифта, либо 0.5 em. Если пользователь установил в настройках браузера, что ему нравится смотреть на сайт со шрифтом в 10 pt — то em будет пересчитан в эти 10 pt. Если 16, то в 16. Для дизайнеров засада состоит в том, что em пересчитывается для каждого элемента и за основу em берётся размер родительского элемента. Т.е. если у body установлено 2 em, а у дочернего элемента тоже 2 em, и размер базового шрифта = 10 pt, то размер дочернего элемента будет не 20 pt, а 40 pt.
В CSS есть ещё такая величина размеров как %. Там всё ещё запущеннее :) Когда указываются проценты, то для каждого свойства в документации есть описание откуда считать эти проценты. Если вы указываете высоту строки в 150% — это откуда считать? А если 150% высота рисунка? А если шрифта? А что делать, если проценты указаны для свойства, у которого нет родителя, с которого эти проценты считать? Расписывать долго, но могу сказать, что почти всегда это интуитивно понятно, и если возникают проблемы, то читайте документацию.
Сейчас разрабатываются ещё одни размеры для CSS: «rem» — считает как em, но только берёт размер от корневого элемента документа, а не от родителя; «vw» и «vh» — 1/100 часть ширины и 1/100 часть высоты экрана соответственно.
жаль только что эти цифры никак не связаны с реально занимаемой памятью. если в task manager смотреть не на бесполезный(по крайней мере под winxp) mem usage, а на VM size, то можно заметить что миранда как занимала 15-20 мб, так и занимает, вне зависимости от состояния окна.
event loops & parallel programming — AE (AnyEvent), Coro + EV, fork, threads
number crunching — PDL
c/c++ extenstion — Inline::C, Inline::CPP
gui — Prima, Wx, Gtk2
video&graphics: OpenGL, GStreamer, SDL
images — Imager, ImageMagick
Хотелось бы дополнить, что это нужно в Fx и Opera, а Chrome и без того даёт качественные сообщения и ссылки на строку ошибки.
С учётом Fx лучше писать такую обёртку:
Совет 2-й: раз уж пишем функцию-обёртку, почему бы не использовать её:
Совет 3-й: используйте метаданные не только в одном месте:
простите, если «многобукв». В общем, по коду заголовка вы догадались где искать пример этой фичи.
Совет 4-й. Советует использовать в связке с советом 3 не GreaseMonkey (ещё раз, НЕ GreaseMonkey!) а Scriptish. Потому что для GreaseMonkey в этой фиче — принципиально неустранимая некроссбраузерность (я, кажется, об этом писал в статье, но не уверен, может быть лежит в черновиках).
Совет 5-й. Получайте кроссбраузерно внешние метаданные — от самого скрипта, от других скриптов, от анонсов скриптов на ваших серверах. Пример кода смотрите там же, откуда он взят для совета 3, ибо было бы ещё почти столько же.
Совет 6-й. Если в коде вы сделали синтаксическую ошибку, легко обнаружить её поможет только Хром. Запустите неработающий скрипт в Хроме, это путь к спасению, он укажет путь к
просветлпропущенной запятой.Совет 7-й. Метаться в Хром иногда лениво, поэтому озаботьтесь хорошим механизмом трассировки, она очень-очень пригодится. Уже имеется win.console.log, но это длинно и не очень удобно. Делаем так:
(впрочем, это полезно и в простых скриптах).
Что получили? Можем писать
Почему так? Потому что их будет много, без меток трассировочные значения будут все на одно лицо. ЗАчем там '=='+...? Чтобы лучше видеть. Зачем в апострофах? Чтобы лучше находить в коде по ctrl-F. (И теперь видно, зачем здесь константа noConsole из совета 2?)
Совет 8-й. Содержите кроссбраузерную функцию кроссдоменного обмена по postMessage, она отличается от функции для простых скриптов. (А в Хроме она и для внутридоменного понадобится.) Я об этом обещал написать, скоро напишу, статья готова, а реализацию можно увидеть опять же, в том же источнике примеров.
Совет 9-й. (Думаю, ещё не сучно.) Используйте легковесную библиотеку, не поддерживающую IE, если не собираетесь (с большой вероятностью, думается, это так) поддерживать юзерскрипты там. Zepto, AtomJs, Backbone или что-то небольшое своё — оно всегда пригодится — работа с DOM, с событиями, массивами, хешами. Впрочем, примеров и образцов нет. В моих примерах есть, но очень примитивное ядро на 2-3 К, не советовал бы брать за основу.
Совет 10-й (продожение 9-го). Среди полезных исполльзуемых функцих, кроме работы с DOM, будут и:
подгрузка стилей:
,
подгрузка сторонних скриптов (кода многовато на все случаи, приводить не буду),
специфическое ожидание целевого условия по таймеру (очень частая функция), для примера ищите execCallback в HabrAjax,
генерация User Event и CustomEvent — полезная техника,
показ подсказок по наведению мыши (примеров нет),
открывание ссылок в фрейме, если нужно для задачи,
группа функций работы с настройками вашего скрипта.
Вот это — я понимаю, полезные советы, вполне достаточные для работы с юзерскриптами…
www.imagemagick.org/Usage/fourier/fft_math/
В общем, всё можно делать, так сказать, «штатными» средствами :).
Через АПИ хрома ищи «полезные» печенья и прикрепляем к запросу.
Насколько я помню для Яндекса это «fuid01» / «spravka», для Гугла — «S».
Макросы. Только макросы.
Шапка — папка с именем и description. Копируется лапами. Тут я взял «Projects», хотя это ни разу не проекты, а задачи, надо было другую скопировать.
Вот пример макроса на заведение нового таска:
Аналогичные индокреативы работают на Complete, Update,…
Об иерархии или программном разделении на проекты/задачи речь пока не идет, хотя это допилибельно.
Читаем внимательно про Custom Domains в описании Github Pages.
Нужно просто в корне репозитория создать файлик
CNAME, а в нем написать домен. Если это под-домен, то нужно прописать CNAME-запись, которая будет указывать наusername.github.com. А если это домен верхнего уровня — A-запись, указывающую на207.97.227.245(CNAME для доменов верхнего уровня лучше не использовать...). А теперь подождите, пока обновятся DNS и voilà.Все это возможно как на платных аккаунтах, так и на бесплатных. Как для личной страницы (репозитория вида
username.github.com), так и для Pages любого проекта!Сам сижу на WordPress и после установки связки Pure PHP Localization + WPLANG Lite + DB Cache — монстр стал шевелиться быстрее и эффективнее.
зы: пробелы после точек всё-таки необходимы.
Пункты определяют абсолютные физические размеры и с другими физическими размерами определена такая связь: 72 pt = 1 in = 2.54 cm = 25.4 mm = 12 pc, т.е. если бы все браузеры соблюдали правила CSS, то размер в 72 pt занимал бы ровно один дюйм на любом устройстве. Это очень удобно, если вы хотите показать пользователю прямоугольник с высотой в один дюйм, но не всегда удобно для отображения шрифтов. Например, размер шрифта в 14 pt будет легко читаться с экрана ноутбука или мобильного телефона, но, чтобы прочитать тот же шрифт на телевизоре, вам придётся сидеть рядом с телевизором впритык. Если вы попробуете прочитать те же самые буквы сидя на диване далеко от телевизора, то буквы сольются в одну линию.
Ещё замутнее обстоит дело с пикселями. Пиксель в CSS — это по определению тонкая, острая линия, которую может показать устройство, но он не имеет ничего общего с настоящими пикселями устройства. Точнее, имел, но в CSS2 это убрали. В CSS1 пиксель равнялся пикселям устройства. Представьте себе какая бы разница была в картинках на экране и на бумаге. Если на экране с разрешением 96 px на дюйм картинка в 960 px занимала бы 10 дюймов, то на бумаге у принтера с разрешением 600 px на дюйм — в 6 раз меньше! Технически это правильно, но для пользователей это часто контринтуитивно. Поэтому в CSS2 ввели два понятия: во-первых, связали пиксель CSS с абсолютным значением в 0.75 pt, а во-вторых ввели понятие референтного пикселя — он рассчитывается через визуальный угол, который занимает пиксель в 0.75 pt на экране устройства с разрешением в 96 px на дюйм c расстояния вытянутой руки. В этой ситуации пиксель занимает 0.26 mm. Теперь, используя этот угл, можно отойти от телевизора и сказать, что пиксель телевизора будет иметь размер 1.3 mm.
Так как теперь у нас возникла связь между физическими размерами в пунктах и нашим новым, выдуманным пикселем, то теперь можно смело писать сайты используя эти абсолютные единицы и не бояться, что куда-то что-то поедет. Между ними теперь есть чётко заданная связь. Теперь все проблемы с масштабированием свалили на браузеры и на пользователей.
Единицы CSS em и ex определяют относительные размеры и берут их из размеров шрифта. em — это просто размер шрифта. ex — размер маленькой буквы «x» этого шрифта, либо «x-height» свойство шрифта, либо 0.5 em. Если пользователь установил в настройках браузера, что ему нравится смотреть на сайт со шрифтом в 10 pt — то em будет пересчитан в эти 10 pt. Если 16, то в 16. Для дизайнеров засада состоит в том, что em пересчитывается для каждого элемента и за основу em берётся размер родительского элемента. Т.е. если у body установлено 2 em, а у дочернего элемента тоже 2 em, и размер базового шрифта = 10 pt, то размер дочернего элемента будет не 20 pt, а 40 pt.
В CSS есть ещё такая величина размеров как %. Там всё ещё запущеннее :) Когда указываются проценты, то для каждого свойства в документации есть описание откуда считать эти проценты. Если вы указываете высоту строки в 150% — это откуда считать? А если 150% высота рисунка? А если шрифта? А что делать, если проценты указаны для свойства, у которого нет родителя, с которого эти проценты считать? Расписывать долго, но могу сказать, что почти всегда это интуитивно понятно, и если возникают проблемы, то читайте документацию.
Сейчас разрабатываются ещё одни размеры для CSS: «rem» — считает как em, но только берёт размер от корневого элемента документа, а не от родителя; «vw» и «vh» — 1/100 часть ширины и 1/100 часть высоты экрана соответственно.
blogs.msdn.com/tess/archive/2006/09/06/742568.aspx — тут довольно интересная статья, в последней части в том числе и про волшебное «освобождение» памяти про сворачивании апликухи.