Уже в нескольких проектах была необходимость показывать иконки для различных доменов (например, рядом с какой-нибудь ссылкой). Для этого был написан на PHP механизм, добывающий по требованию иконку со страницы по некоторому набору правил (так же, как её добывают браузеры), конвертирующий картинку в png и сохраняющий в специальном месте. Периодически эти иконки обновлялись.

После того, как я в третий раз скопировал этот механизм в очередной проект, я решил создать для себя (и других) сервис, который отдавал бы по запросу иконку в формате png для любого домена. Но ему не суждено было родиться, потому что я случайно наткнулся на аналогичную функциональность, реализованную гуглом. Достаточно набрать адрес www.google.com/s2/favicons?domain=habrahabr.ru и получишь сконверченую в PNG иконку этого домена. Решил, что многим это будет полезно — используйте :)

UPD: нашлись баги. конвертер не умеет работать с прозрачным фоном, а также грузит только те иконки, которые лежат в /favicon.ico, игнорируя мета-теги :( Так что мой сервис, видимо, появится :)

то ли китайцы, то ли индусы. :)
function is_utf($str){
if(iconv("UTF-8","UTF-8",$str)==$str)
return true;
else
return false;
}
UPDATE. Подсказывают что отличились Корейцы.

Примечание: ниже представлен официальный перевод статьи «On having Layout» на русский язык. Статья не является окончательной. Этот перевод отражает 9 версию от 23.10.2007.

UPD текст статьи полностью убран в связи с его неконтролируемыми изменениями с момента публикации. Перепечатка доступна здесь

Управлять потоком можно не только свойствами clear или overflow. Возможно, вы найдёте полезным для себя использование display:inline-block или display:table-cell, способных полностью заменить вам упомянутый overflow, избавляя вас от опасности указания размеров элемента, а также предоставляя дополнительные возможности.

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

Наверное каждый верстальщик, хотя бы раз в жизни сталкивался с версткой двух- или трех-колоночного макета. Хотя, сам макет сверстать несложно, если конечно колонки не различаются цветом фона, как например на хабре. А вот с разноцветными придется помучаться, потому что они имеют свойство тянуться по содержимому, а содержимое у соседних колонок, как правило, разной высоты.

Мне известны два способа решения этой проблемы:

— заключить обе колонки в контейнер, и поставить в фон двухцветную картинку;
— выставить колонкам одновременно вниз отрицательный марджин и положительный паддинг.

Оба способа имеют свои достоинства и недостатки, но сегодня я хочу рассказать выравнивании колонок с помощью плагина к JQuery — Flexify.

Примечание: ниже перевод очередной заметки «Image Optimization, Part 5: AlphaImageLoader» из блога YUI. Stoyan Stefanov на этот раз рассказывает о тонкостях применения фильтра AlphaImageLoader для IE. Мои комментарии далее курсивом.

Это пятая часть серии статей про оптимизацию изображений. С предыдущими частями можно ознакомиться по адресу:

• Image Optimization Part 1: The Importance of Images
• Image Optimization Part 2: Selecting the Right File Format
• 4 шага для уменьшения размера файлов
• Последовательные JPEG — Быть или не быть?

Данная статья из серии, посвященной оптимизации изображений, рассказывает о технике, доступной только в IE, — CSS-фильтре AlphaImageLoader, — который используется разработчиками для решения проблем с прозрачностью для полноцветных PNG-изображений в IE. Основная проблема с AlphaImageLoader заключается в том, что он влияет на производительность страницы, и тем самым ухудшает пользовательское восприятие. Я утверждаю, что стоит избегать использования AlphaImageLoader во всех возможных случаях.

Маленький экскурс

Как было сказано в одной из предыдущих статей, PNG могут быть нескольких видов, которые могут быть разделены на 2 основных:

• Индексированные (палитра), их также называют PNG8, можно использовать до 256 цветов.
• Полноцветные PNG, которые также называют PNG32 или PNG24.

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

За последние 3-4 года я не встречал ни одного задания на разработку сайта, в котором бы не было такой цели. Стоит отметить что наша специализация — разработка корпоративных сайтов. Каждая компания хочет чтобы их сайт стал инструментом привлечения клиентов, но ни одна компания до конца не верит в то что это возможно. Не верят, потому что не могут совместить эту цель с реальностью.

Легко сказать: «Мы хотим привлекать клиентов через сайт». Но кто эти потенциальные клиенты? Где они? Что для них важно? Почему они выберут именно вас? Что они делают в интернете? Как они попадут на сайт?

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

Сегодня в в своей RSS-ленте обнаружил ссылку на очередную статью о конфронтации .png и IE. Воспринял ее, пожалуй, как и бóльшая половина удививших заголовок выше — с предубеждением (мол, опять двадцать пять). Тем не менее, выяснилось много интересного. Например, теперь фоновые .png отлично подчиняются свойствам background-position и background-repeat.

ReadWriteWeb отобрал 10 проектов, сделанных за пределами США, которые, создают инновационные сервисы и поддерживают глобальные Web-стандарты. Составители чарта признают, что многие интересные проекты небыли упомянуты, но это произошло, потому что авторы небыли с ними знакомы. И они призывают рассказать об интересных проектах в комментариях к их статье, на сайте The New York Times. Я призываю вас в своих комментариях рассказать о российских проектах, способных конкурировать на глобальном рынке, на данный момент ни одной российской компании в чарте нет.

Многие программисты оптимизируют JavaScript и CSS-код, чтобы страница грузилась быстрее.
Но не все они делают прелоадеры, которые дают пользователю эффект субъективно более быстрой загрузки.

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

Чем хороша такая система? Пожалуй тем, что она прозрачна и незаметна: пользователь перемещается по страницам ничего для этого не делая, просто читая новости в своём rss ридере. Есть, конечно у такого подхода и недостатки, но заметка не об этом.

Итак, сегодня вечером я совершенно случайно наткнулся а плагин к firefox, который позволяет сделать аналогичную постраничную навигацию практически для любого сайта, более того, он изначально содержит настройки для множества известных сайтов: Digg, Google, Wikipedia и т.д.

Думаю у многих возникала необходимость хранить файлы, связанные с записью в таблице. Это может быть картинка к новости, аватар, загруженный пользователем файл — да все, что угодно. Обычно в этому случае поступают просто — файл ложится в файловую систему, а ссылка на него — в запись БД.
Но у такого классического похода множество недостатков:

• файлы не удаляются при удалении соответствующей записи БД
• проблемы при одновременной попытке обновления файла
• нарушение синхронизации между БД и файловой системой при откате транзакции
• при резервном копировании и восстановлении информации в БД может возникнуть рассинхронизация с файловой системой
• файлы не подчиняются ограничениям доступа, наложенным с помощью БД

Больше о проблемах, возникающих при хранении файлов отдельно от БД можно почитать в презентации SQL Antipatterns, раздел Phantom Files, страница 60. Кстати, автор презентации предлагает решение — хранить файлы прямо в БД, в поле типа BLOB. Правда следует замечание, что это должно быть взвешенное решение в каждом конкретном случае. Ведь при таком способе хранения файлов вебсервер должен при каждом запросе вызывать некий скрипт, который будет извлекать файл из БД и отдавать пользователю, что неминуемо отрицательно скажется на производительности.
Для поиска решения данной проблемы был проведен мозговой штурм и придумано несколько вариантов решения проблемы:

Бытует мнение, что связка LAMP (Linux+Apache+Mysql+PHP) не требует особой настройки и работает «из коробки». Это далеко не так. После того, как я долго убеждал товарища установить кеширующий акселератор PHP xcache, я решил провести небольшой эксперимент и попробовать выключить xcache на своём виртуальном сервере, находящемся под небольшой нагрузкой (около хита в секунду). В реальной жизни нагрузка на процессор мала, а вот память загружена сильно, т.к. её немного (256МБайт).

Результаты эксперимента превзошли все ожидания.

Многие из Вас наверняка стакивались с ситуацией — есть дело важное, интересное, прибыльное (нужное подчеркнуть;), есть время этим делом заняться. А душа к нему не лежит. Стоит только сесть за работу, как как будто черт дергает послушать музыку, побродить по интернету, початиться с друзьями. Один — другой раз, не куда ни шло, но это происходит постоянно, и часто под самыми благовидными предлогами (например: дабы узнать новую информацию необходимую для проекта). Не иначе как происки нечистого.

Думаю, что многим хорошо известна эта компания, но не все знают с чего всё начиналось. Я бы хотел выложить сюда небольшой кусочек истории этой, достойной уважения, компании. Кстати, случай с Qt в очередной раз подтверждает суждение, что всё начинается с малого, надо только быть уверенным в успехе и, конечно, что-нибудь делать хорошо :)

причины родились в том, что в топах посвященных обзорам конкретных шаблонизаторов спорят на обобщенную тему:
Обзор шаблонизатора Quicky: Производительность и Гибкость.
MACRO — гибкий PHP шаблонизатор, с человеческим «лицом»
раследование проведено на основе данных, полученных в топе:
HolyWar: Шаблонизаторы. Нужны ли они? состоятельны ли они? Форум.
результаты расследования под катом

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

Итак, получили письмо от клиента

обычно есть следующие варианты

1. клиент явно перспективный и обратился «выборочно» именно к нам — есть большая вероятность, что переговоры будут удачными — тогда лучше сразу набивать стрелку и устанавливать личный контакт и все выяснять на месте. Хотя, границы бюджета лучше выяснить в любом случае.
2. клиент интересный, но многое неясно из его письма ( нет ТЗ, нет бюджета, он написал в несколько студий, сайт потенциально сложный, сайт неинтересный и тд. ). Тут важно прислать ему БРИФ на заполнение, выяснить сроки и бюджет. Согласовать бюджет сроки — уже потом встречаться в случае, если все устраивает.
3. Письмо подозрительно короткое и не «пахнет интересом». Например, «нужен обувной интернет-магазин, сколько стоит? Как быстро сделаете? Виталий» — тут вряд-ли чтото выгорит + вероятно это пробивон по ценам от конкурентов.
   В этом случае — цену говорим в полтора раза дето дороже, интересуемся «укладываемся ли мы в их бюджет» в положительном случае — можно встречаться. Иначе — скорее всего трата времени.

Предыстория

Как известно, перед тем, как выложить сайт в нет, мы его разрабатываем. И делаем мы это, как ни странно, на машине разработчика. И давно замечено, что javascript, а в некоторых случаях и css удобнее при разработке держать в нескольких файлах.Проблема в том, что, согласно принципам, описанным в статье Best Practices for Speeding Up Your Web Site (перевод доступен на сайте webo.in), для ускорения загрузки сайта нам нужно произвести следующие манипуляции над javascript и css файлами:

1. Слить весь javascript в один файл, причем, желательно так, чтобы сохранился нужный порядок — т.е., скажем, библиотека jQuery — была ближе к началу, а функции и объекты, которые ее используют — после нее.
2. Слить весь css в один файл
3. Сжать эти большие файлы с помощью какой-нибудь утилиты вроде yui-compressor (за исключением css-файлов, название которых начинается, скажем, с префикса ie_, которые содержат data:URL, и поэтому критично относятся к переходам со строки на строку, так что их для собственного спокойствия лучше не сжимать)
4. Расположить их в таком порядке — css-файл как можно ближе к открывающему тэгу head, а js-файл — как можно ближе к закрывающему тэгу body.
5. Выставить HTTP-заголовок expires на подольше, чтобы браузер пользователя их закешировал. Ну а для того, чтобы при следующем билде у пользователя обновился js и css надо этим файлам дать какое-нибудь уникальное имя.
6. Перед отдачей файлов клиенту сжимать их с помощью gzip

К чему это я?

Пункты 5 и 6 уже подробно расписаны в других местах.
Я же хочу рассмотреть в этой статье вопрос автоматизации пунктов 1,2,3,4. А точнее, я хочу предложить инструмент, с помощью которого одним (ну, максимум — двумя-тремя :) нажатием кнопки можно выполнить пункты 1, 2, 3, 4 настоящего списка и получить готовые к заливке на сервер javascript и css файлы.

Некоторое время я занимался (и занимаюсь до сих пор) веб-проектом, где необходимо было добавить фичу для загрузки пользовательских видео-роликов. Собственно, какие могут быть пользовательские видео? Очень разного качества и разнообразных форматов. Начиная от обычных flash файлов, которые представляют наименьшую проблему, до различных записей с телефонов. Встала задача — сделать демона, который бы занимался обработкой очереди загруженных файлов и выполнял следующие функции:
— Конвертирование видео в flash формат (FLV), ипользуя VP6 кодек
— Обновление метаинформации видеофайла
— Создание thumbnails из видео
— Дальнейшии манипуляции с БД

Конкретно в этой статье я рассмотрю варианты обработки уже сконвертированного в формат flash видео-ролика. Итак приступим.

1. Что такое PNG?
2. PNG vs GIF.
3. PNG vs JPEG.
4. Жизнь после Photoshop'а или сжимаем дальше.
5. Adobe Fireworks или PNG-8 с альфа-каналом.
6. Вердикт.

Осторожно, много картинок! Все кликабельны.