В сети доступно масса документации по языку XSL. Данный раздел не претендует на роль документации по языку, а лишь кратко, по шагам объясняет, как создать свой XSLT-шаблон.

Описанная ниже схема успешно мною используется уже более 3 лет. По началу я к XSLT относился с большой опаской (особенно, когда разбирал чужие исходники), однако однажды поняв, что к чему, уже не представляю, как без него можно работать.

Передо мною встала задача — «объединить» несколько типов объектов с разными свойствами в одной таблице для «глобального» поиска. Я перепробовал несколько решений такой задачи. Возможно, вы предложите что-то новое, чего я не смог разглядеть в потенциале SQL.

Рассмотрим задачу более конкретно:

Заголовок как никогда точно описывает то о чём пойдёт речь в посте :)

UPD. Цена вопроса 8 сингапурских центов за смс сообщение.
UPD. Цена вопроса будет падать!

Что это такое и Как Начать?

1. Этот сервис позволяет отправлять СМС с вашего Google Talk IM клиента, Gmail клиента или других Jabber клиентов, к примеру Gajim.

Этот пост меня сподвигли написать две вещи. Автокадабра и некто под ником napisal, кто активно не соглашался с моим постом…

Дело было так: я зашёл в карту клубов Автокадабры и понял что она мне ни о чём не говорит. Создавалось впечатление, что пишут всего в трёх клубах. После изучения облака я пришёл к выводу что линейная зависимость размера тега (в данном случае блога) от количества публикаций совершенно не информативна. Клубы с одной публикацией выглядят так же как и с 15-ю.

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

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

Вы когда-то видели этот лоадер:

Или вот этот:


Они служат для показания процента аплоада на сервер файла который вы заливаете через форму. К сожалению, на самом простом уровне показать процент аплоада нельзя, а хотелось бы. Согласитесь видеть процент загрузки всегда приятней чем скучный «Loading...» в строке-статуса браузера, поэтому я расскажу как сделать такой аплоад-показатель для ваших форм загрузок.

Почему компьютерный софт стал нас раздражать? Было ведь время, когда новый релиз популярной программы был настолько восхитителен и полезен, что мы не могли удержаться, чтобы не установить и не попробовать его в деле. А сейчас возникает такое ощущение, что софт специально создаётся таким, чтобы выводить нас из себя: начиная от постоянных автоматических обновлений и запросов на регистрацию, и заканчивая истечением «срока годности», что портит удовольствие даже от самого хорошего приложения. Маркетологи победили разработчиков, а программы от этого стали только хуже.

Я поговорила с другими редакторами PC World и составила этот список наиболее раздражающих факторов в софте. Будем надеяться, что издатели ПО обратят на него внимание.

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

JavaScript — удивительный язык, с которым порой удаётся вытворять неожиданно классные вещи. Хочу познакомить вас с немножко нестандартным решением одной проблемы быстродействия, с которой я недавно столкнулся. Предупреждение: не для новичков.

Исходные данные: ресурсоёмкая функция, обновляющая определённые элементы на экране по наступлению определённых событий (движение мышки, например).
Проблема: когда события, вызывающие функцию, происходят слишком часто за короткий промежуток времени, интерфейс может начать серьёзно тормозить. Скажем, если событие произойдёт 1000 раз за несколько секунд, то и обновление — столько же. Для интерфейса молниеносная скорость отрисовки изменений может быть не так важна, а вот общее быстродействие, которое в данном случае страдает — очень даже.
Задача: ограничить функцию таким образом, чтобы она исполнялась не чаще, чем раз за определённый промежуток времени. При достаточном малом таком промежутке визуально задержки не будут заметны, зато кол-во вызовов может сократиться в несколько раз, что в свою очередь очень сущесвенно сократит нагрузку и поможет избавиться от торможения.

Behold, people. Свершилось. Язык программирования D — очередная попытка сделать из любимого C нормальный объектно-ориентированный язык — окончательно перестал быть частной инициативой его автора, Волтера Брайта (Walter Bright), и компании Digital Mars. Теперь и GNU предлагает собственную реализацию. Работы, начатые GNU в прошлом году, наконец привели к созданию компилятора, который способен пройти все тесты в The Computer Language Benchmarks Game.

D — это, если можно так выразиться, причёсанный вариант C++, который многое наследует от Java и Eiffel, но при этом остаётся полностью компилируемым в машинный код и хорошо оптимизируемым языком. О производительности и эффективности можно судить по тестам The Computer Language Benchmarks Game. И выглядит он при этом довольно симпатично, примеры программ можно посмотреть в статье на wikipedia — D (programming language).

Весьма недурно, если учесть, что кодировать на D проще и приятнее, чем на C++, а потенциал для оптимизации, скорее всего, не исчерпан. Посмотрим, что сделают ребята из GNU с этим языком.

Вот. Happy coding.

P.S. Прямые ссылки, к сожалению, указать не удаётся. Хабру глючит, но чрезе Google они быстро находятся.

 

Сегодняшняя заметка будет о сервисе отслеживания активности пользователя — CrazyEgg. Я не знаю кому обязан сервис таким говорящим именем, но оно работает, и хорошо. Запоминается? Отлично!

Что это такое?

Как уже сказано выше это сервис для отслеживания перемещения пользователей по сайту — кто куда кликнул, какие ссылки наиболее популярные и тому подобная, разнородная информация для юзабилистов.
Сервис позволяет отслеживать активность определенных пользователей, и выводить эти данные в различных формах: «инфракрасная» — где чем активнее область, тем она «теплее», салюты (чем активнее область, тем больше конфети), простой список с сортировкой по активности, колбы (чем заполненнее колба, тем активнее область), облака (на мой взгляд наиболее удобный вариант — совмещает в себе все остальные вместе взятые).

Посмотрите на эту страницу. Синим цветом выделены 4 плавающих блока с шириной равной 25% у каждого, которые находятся в контейнере с шириной 50px. Теперь вопрос: Какова ширина каждого блока?

Ширина эта должна быть равна 12.5px, но т.к. мы можем использовать только целые значения, то приходится округлять значения. И тут же возникает вопрос: В какую сторону округлять? В большую, в меньшую или в обе? Результаты думаю вас удивят, как и меня.


В итоге мы имеем три абсолютно разных лагеря.

— Округление в меньшую сторону — И Opera и Safari округлили значение ширины до 12px. В результате чего образовался 2-x пиксельный пробел (помечен зеленым цветом) справа от блоков. Если вы когда-либо озадачивались, почему ваша красивая навигация не заполняет все пространство контейнера, теперь вы знаете ответ.
— Округление в большую сторону — 6-й и 7-й Internet Explorer увеличивают ширину до 13px, что приводит к «поломке» структуры сайта.
— Округление в обе стороны — Firefox 2 и 3 сочетают оба подхода, округляя ширину одних блоков в меньшую сторону, а других в большую. Побочный эффект заключается в том, что ширина блоков теперь имеет разное значение, несмотря на то, что в CSS задано одно значение. К тому же, если получить значение ширины с помощью Javascript, то оно будет равно 12.5px, не давая понять в какую сторону было произведено округление. Есть и еще один неприятный момент. В Firefox 3 меняется порядок округления.

David Baron, один из разработчиков Mozilla, разъяснил ситуацию:

— Мы стараемся соблюдать все нижеописанные правила, которые, однако же, не могут быть удовлетворены одновременно:

1. 4 смежных объекта шириной/высотой 25% (например), начинающиеся у одного края внешнего контейнера, должны заканчиваться у другого. Не должно появляться никаких свободных или лишних пикселей.
2. Объекты, которые являются логически смежными, всегда должны визуально касаться друг друга. Не должно быть никаких пустых пробелов или наложений, возникающих из-за ошибки округления.
3. Объекты с одинаковой шириной должны занимать такое количество пикселей, которое было задано.
4. Границы объектов не должны быть размыты.

Эти правила могут быть полезными, но придется пожертвовать по меньшей мере одним из них, для того чтобы удовлетворить остальным.

Примечание: ниже дан перевод статьи «Cross-browser underlining / the difficulty of drawing a line», в которой обращается внимание на подчеркивание ссылок в различных браузерах и обсуждается, насколько это корректно с различны точек зрения.

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

Несоответствия браузеров. Как веб-разработчики вы сталкивается с ними каждый божий день. Они стали неотъемливой частью нашей работы и очень часто влияют на то, каким именно образом мы решаем некоторые проблемы. Но что важнее всего, все эти правки отнимают огромное количество бесценного времени, даже при наличии таких замечательных средств для разработки как Firebug. Люди, которые не работают каждый день с html и css, с трудом смогут осознать все эти тонкости и суть несоответствий.



Слева направо: Firefox, Opera, Safari, IE7 и IE6

Только сейчас наткнулся на новость о том, что Sun Microsystems купила MySQL AB за 1 миллиард долларов. Наверное это будет серьезным толчком в развитии этой СУБД. А вы как считаете, что за этим последует?

Наткнулся на днях на новость о конкурсе, в котором предлагают создать минимальный JavaScript-код, который будет сам себя копировать дальше. Автор конкурса — Robert Hansen aka RSnake, достаточно крупный специалист по информационной безопасности.

Условия

По условиям конкурса от кода требовалось следующее:

Как можно понять из недвусмысленного заголовка выше — речь пойдет о том, чем мы пользуемся в глобальной сети всё больше и больше — комментированием уникальных (и не очень) материалов на разнообразных социальных (и опять же не очень) сервисах, сайтах, блогах, социальных сетях (социальные социальные сети — как звучит! Наверное есть где-то антисоциальные).

Почему так происходит? Потому, что каждый сайт считает своим долгом предоставить возможность пользователю оставлять свое мнение к какому-либо материалу (будь то статьи, программы или что-либо другое). Не могу сказать, что это плохо, или хорошо. Я считаю, что каждый функционал должен создаваться под аудиторию, а не подгонять аудиторию под определенный функционал. Хотя опять же обе ситуации сосуществуют вместе и довольно мирно — зависит от типа пользователя, и его инициативности.
По всей видимости меня явно не туда понесло, пожалуй закруглюсь с предисловием, скажу только, что дальше в статье пойдет речь о том, что же нужно людям от комментариев, и непосредственно от формы комментирования, с помощью которой мы и имеем возможность оставить свое мнение. Приступим.

После публикации статьи на тему архивирования JS/CSS-файлов для последующей выдачи клиенту, я задумался на тему, какой же метод минимизации (minify) следует использовать. В докладе на конференции ClientSide'2007 не удалось установить четкого критерия, чем и как лучше всего сжимать JavaScript-файлы. Данная заметка посвящена рассмотрению как раз этой проблемы.

Задача

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

• Имеет ли смысл пользоваться каким-либо минимизатором JS-кода?
• Есть ли среди них универсальное средство, показывающее лучшие результаты в подавляющем большинстве случаев?
• Если такого средства нет, то каковы критерии использования набора инструментов?

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

читать дальше на webo.in →

Навеяно этим.

Для тех, кто, возможно, не знает как сделать так, чтоб всё было хорошо.
Сайт должен тянуться только до определённой величины, и сужаться тоже только до некоторого значения. Я обычно беру 1500 и 980 пикселей соответственно.

Как сделать? min-width и min-height.

#site {
  margin: 0 auto; /*это чтоб центрировать контент при превышении max-width*/
  min-width: 980px;
  max-width: 1500px;
}

Но ведь IE их не поодерживает. А expression слишком нагружает браузер… Спокойно, други! Я выведу вас к свету из тьмы!
Пишем далее.



А в ie.js помещаем

window.attachEvent('onload', mkwidth);
window.attachEvent('onresize', mkwidth);

var minwidth = document.getElementById("site").currentStyle['min-width'].replace('px', '');
var maxwidth = document.getElementById("site").currentStyle['max-width'].replace('px', '');
function mkwidth(){
    document.getElementById("site").style.width = document.documentElement.clientWidth < minwidth ? minwidth+"px" : (document.documentElement.clientWidth > maxwidth ? maxwidth+"px" : "100%");
};

В чём особенная вкусность приведённого метода? А в том, что минимальное и максимальное значение нужно задавать только в одном месте, ну и вообще.

Пользуйтесь, короче, на здоровье!

Когда верстаешь (X)HTML, порой не знаешь или забываешь о многих фичах, которые стоит использовать. Перечислю те, о которых вечно забываю сам, а зря :)

Долгое время работал за обычной 17-кой Sumsung SynsMaster. Сталкивался с множеством проблем: невозможно протестировать сайт на большом разрешении, при работе в Photoshop нужно постоянно двигать инструменты, постоянное переключение между браузерами, HomeSite и Photoshop (как минимум). Все это очень затрудняло работу и занимало много времени. А некоторые вещи в таких условиях и вовсе невозможно было сделать. Я понял, надо что то менять!