С полгода назад набрёл на великолепный буржуйский стартапчик www.forvo.com По какой-то причине на хабре о нём ещё во всеуслышание не писали, посему сделаю это я.

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

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

Так что советую присмотреться))

На протяжении уже 5-6 лет я использую только Firefox и никогда не думал, что захочу выбрать что-то другое. Firefox — отличный браузер, а делают его таковым все те тысячи расширений, которые каждый может скачать бесплатно. Можно найти расширение для чего угодно. Есть лишь один существенный недостаток — Firefox значительно медленнее, чем Chrome и сжирает больше ресурсов компьютера, чем остальные браузеры.

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

В этой статье я попытаюсь ответить на вопрос — могут ли дизайнеры, веб-разработчики, SMO-шники, SEO-оптимизаторы безболезненно перейти на Chrome. Есть ли расширения, которые могут послужить равноценной заменой на Хроме таким вещам как: Firebug, Webdeveloper, Color Picker, SEO для Firefox, Alexa Ranks, средства для отладки?

Я почему вредный был?
Потому что у меня велосипеда не было!
Мультфильм «Трое из Простоквашино»

Когда десять раз делаешь одно и то же, на одиннадцатый раз ты волей-неволей начинаешь задумываться о том, как бы процесс оптимизировать. Так и с версткой: после десятка сверстанных страниц хочется слегка упростить свою задачу. Тут на помощь, конечно же, приходят разнообразные фреймворки (чего только стоит oocss или наикрутейший CSS-фреймворк от Яндекса или целая куча других не менее интересных фреймворков). Пригодятся и системы сборки (Ant стоит на службе у студии Артемия Лебедева, да и я потихоньку постигаю его Дао). Не стоит забывать и различные хаки и шаблоны лейаутов, коих в интернете бесчисленное множество.

Однако как быть с сайтом, для которого надо сверстать пару-тройку типичных страниц? Нет смысла тащить с собой кучу лишнего CSS-кода. Кроме того, многим верстальщикам гораздо проще написать качественный код с нуля, чем перегружать кучу заранее объявленных бесполезных классов. Что делать?

Чтобы решить эту высосанную из пальца нетривиальную задачу я написал простейший шаблон для верстки, который сильно облегчил мне работу над проектами. Шаблон примитивен и прост (потому так и зовется), на звание фреймворка ни в коем случае не претендует (минус в карму тому, кто обзовет его фреймворком! ;) ). Он несет в себе заранее объявленные CSS-классы для работы с меню, списками, формами, ресеты основных тегов (вроде сброса отступов у форм и правильных отступов у <p>) и еще кое-какие полезные для меня вкусности.

Пусть расцветают сто цветов, пусть соперничают сто школ. Этим лозунгом первого китайского императора Цинь Ши Хуана хочется поднять волну народного негодования стремления к появлению как можно большего количества шрифтов с веб-лицензией, которые поддерживают кириллицу. Сто школ в данном случае — различные словолитни и сервисы, предоставляющие встраиваемые шрифты.

В настоящее время подобные сервисы активно развиваются. Крупнейший из них, Typekit, содержит на данный момент 376 шрифтов от более чем 30 производителей. Но вот незадача: Typekit пока поддерживает только подмножество Latin-1, хотя и работает над добавлением поддержки других подмножеств Unicode.

Что же прямо сейчас делать нам, пользователям кириллицы?

Оригинальное название статьи, «Designing for the switch» содержит игру слов и говорит а) о разработке дизайна в эпоху перемен — перехода к нормальной поддержке подгружаемых шрифтов у всех пользователей, и б) о нюансе «моргания», смены шрифта при его подгрузке с помощью @font-face. Вообще говоря, на русском языке достаточно мало информации об опыте и нюансах использования @font-face, поэтому этим переводом я предлагаю начать генерировать более-менее содержательное информационное поле на эту тему. Heath

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

Да, мы были избалованы. Чтобы использовать Вердану, Джорджию или Камбрию, нам не приходилось думать.

Однако дизайнерам долгое время казалось, что им нужно большего. Мы хотим использовать любой шрифт, который нужен нам для нашего дизайна. Мы много нехорошего натворили, пытаясь достигнуть этой цели — например, помещали текст в картинку. Люди поумнее придумали вспомогательные инструменты типа sIFR или Cufón. С совсем недавнего времени большинство браузеров поддерживает @font-face. Плотина открывается. Это рассвет новой эры веб-типографики, и мы обязаны ступать в неё с осторожностью.

1. Используйте DOCTYPE

Лучше всегда прописывать доктайп в заголовке каждой html-страницы, причем, строгий режим рекомендуется:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

для XHTML:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

от себя добавлю, что недопускайте никаких сторонних символов перед доктайпом. Ни пробелов, ни переносов строки — иначе появятся странные поля у body и html

Представляю вашему вниманию перевод очередного замечательного эссе Пола Грэма What Startups Are Really Like.

Октябрь 2009
(Это эссе основано на выступлении в Школе Стартапов в 2009г.)

Я не знал о чем говорить в Школе Стартапов, поэтому я решил спросить создателей стартапов, которые мы профинансировали. О чем я еще не написал?

Я нахожусь в необычной ситуации, имея возможность проверить те эссе, которые я написал о стартапах. Надеюсь, что эссе на другие темы тоже верны, но у меня нет возможности их проверить. Эссе о стартапах проверяются 70 разными людьми каждые 6 месяцев.

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

Я с гордостью могу сказать, что получил один ответ, который гласил:

Что больше всего меня удивило, так это то, что все действительно было довольно предсказуемо!

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

Приветствую всех! Я представляю вам свой Первый Пост На Хабре, он является объединяющим симбиозом нескольких постов моего личного блога [], и речь сейчас пойдёт о универсальной вещи, которая поможет увеличить продажи вашего товара, задержать на вашем сайте лишний десяток посетителей, и сделать из сложной многобуквенной статьи простой доходчивый рассказ. Также будут даны описания и адреса хранилищ этих вещей.

А вещь эта называется «Картинка».

В чём суть?

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

Эта статья написана Джоном Даггеттом(John Daggett) — сотрудником компании Mozilla, который много работал с дизайнерами шрифтов и web программистами чтобы улучшить положение шрифтов в web. Статья представляет из себя поверхностный обзор новых возможностей и содержит некоторые примеры применения WOFF(Web Open Font Format). Полный список других работающих в этой области организаций вы можете найти на официальном блоге Mozilla (архив).

В Firefox 3.5 мы включили поддержку (архив) подключения шрифтов формата TrueType и OpenType. В Firefox 3.6 мы включим поддержку нового формата шрифтов Web Open Font Format или WOFF, который имеет два основных преимущества перед сырыми TrueType и OpenType:

 — это сжатый формат, значит вы увидите намного меньший объем загружаемых данных, чем при использовании сырых TrueType или OpenType;

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

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

Может ли радиоприемник состоять менее чем из 10 деталей и работать без батареек?

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

Чем хорош детекторный радиоприемник?

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

• Сортировка на стороне сервера посредством SQL или backend'а;
• Сортировка на стороне клиента.

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

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

Решил рассмотреть понятие навигации применительно к информационной архитектуре сайта.

И вот, что получилось

Даже относительно ограниченный набор возможностей CSS дает нам много возможностей в типографике, которые можно реализовать, используя каскадные таблицы стилей. Антиква или гротеск? Большой или маленький шрифт? Интерлиньяж, апрош, размер шрифта и всевозможные отступы… Список можно продолжать до бесконечности.

Мы провели обширное исследование на 50 популярных сайтах, для которых типографика важна больше обычного, для того, чтобы выделить некие общие решения и найти ответы на известные проблемы в оформлении текстов. Для изучения были выбраны популярные газеты, журналы, блоги и другие ресурсы, так или иначе связанные с типографией. Мы тщательно проанализировали их типографику и таблицы стилей в поисках сходств и отличий. Также, мы построили сравнительную таблицу, в которой отображены различные параметры веб-сайтов (например, соотношение между интерлиньяжем и длиной строки).

В конечном счете, мы выделили 13 общих проблем и вопросов, имеющих отношение к типографическим проектам, и попробовали найти ответы на них в нашем исследовании:

1. Насколько популярны шрифты с засечками и без засечек в заголовках и основном тексте?
2. Какие шрифты используются наиболее часто?
3. Каков средний кегль для шрифта?
4. Каково, в среднем, соотношение между размером шрифта в заголовке и в основном тексте?
5. Чему равно среднее значение интерлиньяжа для основного текста?
6. Каково усредненное соотношение между значением интерлиньяжа и размером шрифта для основного текста?
7. Чему равно среднее значение соотношения между интерлиньяжем и длиной строки?
8. Каковы, в среднем, отступы между абзацами?
9. Каково усредненное соотношение значений отступа между абзацами и интерлиньяжем?
10. Как выделяются стилистически ссылки?
11. Сколько символов обычно используется в строке?
12. Как часто ссылки выделяются подчеркиванием?
13. Как часто используется замещение шрифтов (sIFR и прочие)?

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

Согласно сведениям, поступающим на TorrentFreak, и проведённым нами испытаниям, мы можем поведать, что Demonoid был недоступен российским пользователям в течение как минимум одного дня. Кажется, что для многих других стран он действует, как обычно — Demonoid работает просто прекрасно.

Demonoid, сегодня один из крупнейших существующих торрентовых сайтов, хостится к западу от России в соседствующей с нею Украине, хотя отношения между двумя странами сейчас не вполне добрососедские.

За последние 24 часа получает шквал сообщений о том, что пользователи Демоноида в России более не могут получить доступ к сайту. Сверившись с некоторыми из наших собственных российских знакомых и пробуя посредством сервера, расположенного в Санкт-Петербурге, мы сумели подтвердить, что, по меньшей мере до сих пор, доступ к Демоноиду из России невозможен. Докладывают, что проблема началася день тому назад.

Итоги команды traceroute, запущенной из разных мест по всей стране в направлении к IP Демоноида (62.149.24.66) показывают, что все они завершаются в ColoCall, крупнейшем центре данных на Украине, всего в одном шаге от серверов Демоноида.

Проверки TorrentFreak и с европейских, и с российских IP-адресов маршрутизировалися через ColoCallовский IP 62.149.2.108 — в этой точке российский тест был блокирован, в то время как европейский завершился безупречно. Проверки русского пользователя BitTorrent, совершённые по нашей просьбе, подтвердили, что потребовалося использовать прокси и для сайта, и для трекера, чтобы получить доступ.

Есть надежда, что блокировка — временная и техническая проблема; но, конечно, Demonoid и прежде блокировал целые страны. TorrentFreak связывался с ColoCall, но до сих пор мы не получили никакого отклика.

Мы обновим эту блогозапись, когда поступит дальнейшая информация.

Обновление: Поступают несколько сообщений о том, что украинские IP-адреса также могут быть заблокированы.

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

Задача

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

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

Это перевод статьи, написанной Jon Hobbs-Smith. Я счел ее довольно интересной и решил выложить в своем блоге, а также поделиться им с хабрапользователями, также как и я заинтересованными в библиотеке jQuery. Перед тем как начать хочу отметить, что написана она (как и переведена) далеко не экспертом в jQuery, поэтому если вы найдете в ней ошибку, пожалуйста, сообщите. Итак, начнем.

Навеяно постом http://habrahabr.ru/blogs/python/59236/.
Почитав вышеуказанный пост, предположил, что не каждый сможет использовать домашний комп для таких целей (например потому, что он включен не постоянно). Но зато многие из нас имеют php-хостинг, который так же поддерживает cron. Для разминки написал данный скрипт.

Несмотря на то, что необходимо минимизировать количество http-запросов, иногда (или часто, в зависимости от задачи) бывает полезно загружать часть «тяжелого» функционала только тогда, когда он действительно понадобится на странице.
У jQuery есть механизм, позволяющий осуществить это — $.getScript, однако, он обладает рядом недостатков:

• не запоминаются уже загруженные или загружаемые в данный момент скрипты, при повторном запросе опять идет их загрузка.
• нельзя указать сразу несколько скриптов
• выключен кэш (к каждому урлу насильно приписываются параметры типа ?_=1242843920520). Зачем это было так жестко сделано, для меня осталось загадкой.
• у коллбэка нельзя задать контекст (это вообще болезнь коллбэков jQuery).

Пришлось написать небольшой плагин, лишенный вышеперечисленных недостатков:

$.requireScript(url, callback, [context], [options])
Где:
url — урл загружаемого скрипта (может быть массивом урлов)
callback — коллбэк-функция, вызываемая после загрузки скриптов
context — контекст, в котором вызывается коллбэк-функция (опционален)
options — параметры; в данный момент поддерживается только один параметр — parallel, указывающий, нужно ли использовать параллельную загрузку для нескольких скриптов (по умолчанию — true)


Может кому-то пригодится. Скачать и попробовать можно с code.google.

UPDATE: согласно замечаниям в комментах, $.loadScript переименован в $.requireScript, и теперь можно указать несколько урлов сразу.