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

Преимущества дивной вёрстки, семантичной разметки и разделения содержимого и дизайна описаны десятки, сотни раз, но все-равно находятся люди, которые не понимают самой идеи html и css, пишут в коде такие ужасные вещи, как

<span style="color:blue">

, когда хотят расскасить текст в синий цвет и искренне считают, что эта запись чем-то лучше, чем

<font color="blue">

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

Возникла задача написание простенького расширения под все (по возможности) популярные браузеры. Деятельность расширения заключается во внедрении javascript`а в тело документа.

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

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

Этот материал продолжает серию ежемесячных обзоров свежих статей по теме интерфейсов, новых инструментов и коллекций паттернов, интересных кейсов и исторических рассказов. Из лент нескольких сотен тематических подписок отбирается примерно 5% стоящих публикаций, которыми интересно поделиться. Предыдущие материалы: апрель, май-июнь, июль, август.

            Речь идёт о текстовом редакторе nano в Linux.
Я не люблю nano и предпочитаю vim. Однако, в отсутствии vim, выбирая между vi и nano, я всё-таки предпочту nano, ибо как говорится в старой поговорке, «у vi есть два режима: бибикать и всё портить».

Кроме того, идёт активная замена vi на nano во многих дистрибутивах. Например, в новых версиях Debian и Ubuntu по-умолчанию vi устанавливается в самом куцем виде. А главное, его больше нет в busybox install/initrd этих ОС, что однозначно заставляет задуматься об изучении nano, не из любви к нему, а по необходимости.

Я понимаю, что сидеть и зубрить список комбинаций кнопок бесполезно, так что вместо этого я думаю сделать маленькие nano-уроки — по 8 комбинаций или фич за урок (я и сам их планирую изучать по мере публикации).

Nano не имеет «режима команд» как vim, и этим похож на oldschool-редакторы из консоли DOS/Windows (NC, Far Manager, DN, hiew/biew, внезапно втесавшегося в список mcedit и т.д.). Все команды отдаются нажатием комбинаций клавиш — функциональными кнопками или комбинацией Ctrl-буква, Alt-буква.

Важное отличие от 'generic editor' — это поддержка эмуляции Ctrl'а и Alt'а.

Разработчики W3C сделали box-shadow очень гибким свойством. Благодаря этому можно получать весьма интересные результаты, если использовать это свойство нетривиальным образом. В этой статье я напишу о некоторых эффектах, которые мне удалось получить при помощи «теневых технологий».

Пока я составлял примеры, я неожиданно обнаружил, что браузеры отображают их совсем неодинаково. В итоге, помимо простой демонстрации возможностей box-shadow, получился еще и маленький браузерный тест на поддержку CSS 3. Все примеры снабжены CSS-кодом и картинкой (общий объем всех PNG: 161 КБ). В статье я не стал прописывать свойства с вендорными префиксами -moz- и -webkit-, чтобы не ухудшать читабельность. В суммарной странице со всеми примерами эти префиксы есть (предупреждаю, что у Оперы есть баг с прорисовкой внешних box-shadow при прокрутке).

Несмотря на шумиху вокруг HTML 5, спецификации ещё не готовы для использования из-за проблем совместимости. Такова официальная позиция консорциума W3C, которую неделю назад высказал в интервью InfoWorld Филипп Ле Эгаре (Philippe Le Hégaret), руководитель направления W3C Interaction Domain. Эта группа занимается разработкой технологий для пользовательских интерфейсов: (X)HTML, CSS, MathML, SMIL, SVG, XForms.

«Прямо сейчас HTML 5 находится на разных стадиях реализации в различных веб-браузерах. Если посмотреть на них, то можно увидеть, что наиболее агрессивные реализации в бета-версиях, — сказал Ле Эгаре. — IE9, например, не планируется к финальному релизу до середины следующего года. Это момент, когда большинство предприятий начнут переходить на новое поколение браузеров».

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

Нас часто просят порекомендовать продукты eCommerce, которые могут интегрироваться с CMS или использоваться совместно с к.л. CMS. Ниже опубликован список ПО с открытым исходным кодом, пригодного для этих целей.
Примечание: русскоязычных пользователей, прежде всего, интересует наличие локализованных версий, поддержка отечественных платёжных систем и русское сообщество. В комментариях по тексту, выделенных курсивом, по-возможности указана эта информация.

Вот и вышел долгожданный релиз MooTools 1.3. Расскажу немного об изменениях в самом фреймворке, и в его «окружении». Между версиями 1.2 и 1.3 довольно много различий, но обо всем по порядку.

Отличительной особенностью полиграфического дизайна является повсеместное применение колоночной верстки. И тому есть веские основания.

Во-первых, глаз лучше воспринимает строки текста состоящие из 8 до 12 слов. Во-вторых, можно гораздо лучше организовать колонки и уменьшить количество пустого пространства на странице. Долгое время это являлось исключительным преимуществом полиграфии. В вебе же приходилось всячески извращаться. Но теперь CSS3 позволяет создавать колоночную верстку без использования JavaScript.

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

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

А как сайт выглядит в поиске? Захочет ли пользователь вообще на него перейти? Очевидно, что на решение пользователя может повлиять в том числе внешний вид сниппета.

Не прошло и десяти дней, как мы публикуем официальный отчёт о встрече Web Standards Days, прошедшей в Киеве 18-го сентября. Как это обычно случается, финальная программа сильно отличалась от заявленной ранее — но только в сторону её улучшения. На встрече прозвучало шесть докладов:

• Веб-стандарты в большом проекте: что помогает, а что мешает. Андрей Сумин, PDF 138 КБ;
• Про проектирование интерфейсов и немного про Adobe Fireworks. Вадим Пацев, PDF 1,2 МБ;
• Веб в кривых. Второе рождение SVG. Вадим Макеев, HTML 15,6 МБ;
• Введение в Web Performance: W3C, Webkit, IE9 и будущее. Николай Мациевский, PDF 4,1 МБ;
• Разработка веб-приложений. Обзорная экскурсия. Виталий Рыбалка;
• Обзор новых API JavaScript. HTML5 и самостоятельные черновики W3C. Антон Немцев, HTML 750 КБ.

…причём порядок их следования составлялся налету, по мере появления докладчиков, что добавило некоторой динамики и неожиданности в нашу и без того нескучную программу.

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

Под катом вас ждет много интересного, а сейчас дохабракатный мотивационный скриншот:

В наше время существует уже немалое количество таковых, не правда ли? Они даже неплохо справляются со своей работой, если надо, к примеру, сформировать HTML за сотые доли секунды – это довольно быстро, и пользователь не чувствует этой задержки. И почему же мы все не кидаемся вовсю использовать шаблонизацию на стороне клиента? Ну вот к примеру несколько пунктов:
– генерировать страницу (бОльшую её часть) становится таки уже накладно;
– если у вас используется смешанная шаблонизация (шаблоны и на javascript, и на вашем любимом скриптовом языке), то возникнет ситуация, когда они у вас дублируются;

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

С появлением jQuery, у веб-программистов появилась возможность создавать впечатляющие визуальные эффекты, не прибегая к использованию технологии flash. В данной статье представлено несколько ярких примеров того, каких потрясающих результатов можно достичь, используя стандартные средства браузера и свое воображение.

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

Удалить это куки практически невозможно! (Все возможно, конечно, но слишком много мороки)

Куки хранятся в:

• HTTP Cookies;
• Local Shared Objects (Flash);
• Сохранение куки в значениях RGB автосгенерированных и форсированно кэшированных PNG с использованием HTML5 canvas;
• Сохранение куки в Web History;
• HTML5 Session Storage;
• HTML5 Local Storage;
• HTML5 Global Storage;
• HTML5 Database Storage через SQLite.

При удалении из одного из этих мест кука автоматически восстанавливается из оставшихся. Работает даже если пользователь сменит браузер (через Local Shared Objects из Flash).

Описание (на английском) и демо: http://samy.pl/evercookie/.
Попробуйте удалить куки, почистить систему и зайти назад.



Как пользоваться?

Сегодня, во время утреннего разговора с коллегой о продуктивности работы и «способах входа в поток», мне рассказали о топике на сайте rsdn.ru. Там, в одном из комментариев, рассказывается об университетском эксперименте, который объясняет, когда полезно, а когда вредно слушать музыку на рабочем месте. Всё вроде бы и так понятно, и все об этом давно догадывались, но иметь ещё одно научное обоснование своим догадкам никому не повредит:

«В ответ на жалобы сотрудников по поводу шума можно попытаться вылечить симптомы или же устранить причину. Устранение причины потребует создания заграждений от шума — стен и дверей — и будет стоить денег. Лечить симптом гораздо дешевле. Установив «Мьюзек» или другой источник розового шума, вы малой кровью заглушаете шум, мешающий работе. Можно и ещё больше сэкономить — просто не обращать внимания на проблему; людям тогда придётся прибегнуть к помощи магнитофонов и наушников, чтобы защититься от шума. Избрав один из таких подходов, вы должны быть готовы понести невидимое наказание — пострадают творческие способности ваших сотрудников.

Часто в скриптах можно встретить что-то вроде foobar|awk '{print $1}' («часто» — это действительно часто).

Такой вызов awk всего лишь вывходит первую (n-ную) колонку из вывода предыдущей команды. Но это явный оверкилл! awk — довольно мощный язык потоковой обработки данных, и применение его как простого field-separator не есть хорошо.

Для вырезания из строки указанного поля лучше использовать команду cut. Она умеет меньше, а потому проще в использовании и быстрее.

В современном линуксе обработка вызова awk куда более сложна, чем вызов cut. В дебиане, например, awk — линк на /etc/alternatives/awk, который ведёт (чаще всего) на gawk. Который почти в 10 раз больше по размеру, чем cut. Разумееся, cut загружаеся быстрее.

cut умеет вырезать не только байты, но и нужные поля (опция -f). Поле — это текст между разделителями. По-умолчанию разделитель пробел/табуляция, но он легко меняется опцией -d.

Второй подход — использовать опцию -o у grep. Эта опция выводит не всю строку, а только совпадающее с критерием поиска grep. Очевидно бесполезно при поиске точной подстроки, но очень полезно при использовании регулярных выражений.

Например,
grep -v "#" /etc/inittab |cut -f 4 -d : -s
выведет список программ, запускающихся init'ом (четвёртое поле, поля разделяются двоеточием).

Или
grep http://\\S\\+ -o /var/log/apache2/error.log
выдаст список URL'ов из файла с ошибками (первый урл в строке).

… и никакого awk.

UPD: В комментариях подсказывают ещё более интересную конструкцию без запуска внешнего файла (команда read реализуеся средствами bash'а):
foobar | (read p1 p2; echo p1)

P.S. Речь не о единичном вызове (тут нет разницы awk, grep или даже python/perl). Речь о множестве вызовов в цикле в скрипте. Все примеры сравнивайте в цикле с сотнями (лучше тысячами) вызовов.