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

Условия

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

Переходим по ссылке и жмем в расширенный поиск

UPD: Автор информации — Андрей Денисюк

Web Optimizator: проверка скорости загрузки сайтов

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

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

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



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

Сейчас уже много где написано и упомянуто про технику CSS sprites (aka CSS Image Maps). Я не буду открывать Америку и рассказывать о ней дотошно еще раз, а просто хочу привести несколько примеров и полезных ссылок. И пару советов из собственной практики.

Сама техника заключается в том, что мы создаем комбинированное изображение, из которого затем «вырезаем» с помощью свойств background-position нужный нам в данном случае кусок. На текущем уровне поддержки браузерами (я полагаю, что 99,9%) оно является просто must-have для любого уважающего себя интернет-ресурса (ибо позволяет сократить число запросов к серверу, отделить поведение от представления, возложить труд по анимации на CSS-движок браузера, а не на JS-движок, т.е. это будет работать даже с выключенными скриптами, и много-много прочих «вкусностей»). Но обо всем по порядку. Поехали.

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

Примечание: ниже частичный перевод статьи «Compress JavaScript and CSS without touching your application code», в которой описывается статичное сжатие CSS- и JS-файлов на сервере и корректная выдача их затем клиенту. Далее даны мои комментарии с более комплексным решением. Приношу извинения, если для кого-то тема будет слишком знакома или неинтересна: в Рунете нормальной статьи на данную конкретную тематику обнаружить не удалось.

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

• Проверить, умеет ли клиент принимать файлы в формате gzip-encoded.
• Обеспечить соответствующий вывод на стороне сервера через gzip-функции, либо уповать на то, что всем этим займется непосредственно Apache.
• Поиграться с .htaccess, чтобы обеспечить корректный content type.

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

Примечание: ниже находится перевод статьи The future of web standards, в которой автор рассматривает текущее состояние организаций, связанных с разработкой веб-стандартов, и возможное будущее как организаций, так и самих веб-стандартов вообще. Мои комментарии далее даны курсивом.

Индустрию веб-дизайна и веб-разработок, основанных на применении стандартов, в последнее время достаточно сильно будоражит. Статья Andy Clarke «CSS Unworking Group», по видимому, открыла дорогу обсуждению текущего неудовлетворительного состояния подхода (или отсутствия оного) по стандартизации новых возможностей для веб-разработчиков и дизайнеров. Статья Alex'а Russell «The W3C Cannot Save Us» и моего друга и бывшего коллеги Jeff'a Croft «Do we need a return to the browser wars?» продолжила эту дискуссию, как и Stuart Langridge c «Reigniting the browser wars», которая появилась уже после того, как я закончил первый черновой вариант этой своей заметки.

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

Первая, не слишком лицеприятная, заключается в том, что текущий прогресс разработки новых стандартов, в лучшем случае, заморожен. HTML был создан из первоначальной задумки до версии 4.01 менее чем за десятилетие. Но текущая версия 4.01 не изменялась еще с конца прошлого тысячелетия (XHTML не сильно лучше: версия 1.0 была, практически, идентична HTML 4.01, за исключением XML-синтаксиса, а XHTML 1.1 не сильно изменил ситуацию, так как все новшества фокусировались на реорганизации и разделении стандартов на модули). Совершенно аналогично, CSS застыл на спецификации версии 2 с 1998, а CSS 2.1 по-прежнему всего лишь «Candidate Recommendation».

Второй проблемой является то, что все основные нововведения в интернете появляются из проприетарных технологий: Flash выскакивает везде, где только можно, Microsoft и Adobe раздельно работают над следующим поколением RIA (rich internet application), а наиболее модное слово — «AJAX» — изначально произошло из исключительно Microsoft'овской технологии (XMLHttpRequest), которая тем или иным образом была включена в другие браузеры.

Примечание: ниже находится перевод статьи «Getting those first 10 Clients», в которой автор рассуждает о способах привлечения первых клиентов для начинающего интернет-бизнеса.

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

Ниже располагается перевод заметки CSS — A Recipe for Success, в которой рассматривается создание средствами HTML/CSS в браузере некоторого образца меню. В статье освещены довольно интересные случаи, и подробно описано их решение.

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


Рисунок 1

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

123

123

123

Ниже перевод статьи «There's No Money In The Long Tail of the Blogosphere», которая посвящена рассмотрению механизмов и критике существующих представлений о доходности «длинного хвоста»

В 2004 Chris Anderson написал важную книгу «Длинный хвост» (The Long Tail). В ней он утверждал, что будущее бизнеса будет так или иначе представлять собой продажи. Основной его предпосылкой было то, что вещи, спрос на которые достаточно низок, вместе могут давать значительный объем. Это происходит потому, что в «длинном хвосте» находится огромное количество людей, которые покрывают большой спектр возможных потребностей.

Классическим примером успешной политики «длинного хвоста» является Amazon. Существенная часть от их продаж приходится на малоизвестные книги. Amazon как самостоятельно складирует редкие книги, так и распространяет их через многочисленных онлайн-партнеров. Сетевой эффект заключается в большом размере продаж, приходящихся на «длинный хвост». Это явление лучше всего описывается цитатой одного из сотрудников: «Сегодня мы продали больше книг, которые не купили вчера, чем книг, которые и вчера покупали» (We sold more books today that didn't sell at all yesterday than we sold today of all the books that did sell yesterday).

В последней статье мы выясняли причины, почему люди любят вести блоги. Из нее самой и ее комментариев можно установить, что люди очень редко заводят блоги, чтобы заработать денег. Блоги, которые они начинают, живут в «длинном хвосте» блогосферы, однако, правда заключается в том, что заработать деньги в «длинном хвосте» довольно сложно. По мнению Anderson, деньги зарабатываются на продажах этому «длинному хвосту», а не на существовании в нем. В этой заметке мы рассмотрим, почему так происходит, а также взглянем на другие аспекты экономики «длинного хвоста».

Примечание: ниже находится перевод тезисов доклада «Learning to Love Forms» с конференции «WebVisions 2007» (автор Aaron Gustafson). Докладчик рассказывает о верстке форм, используя корректный и эффективный XHTML/CSS-код.

• Формы — это необходимое зло. Людям свойственно усложнять формы, хотя они могут быть представлены весьма просто.
• Рассматривайте верстку форм как создание обычного XHTML-кода. Но будьте готовы к несоответствиям со стороны браузеров и применению хаков.
• Разбивайте сложные формы на несколько простых частей.
• Старайтесь обеспечивать максимальную семантическую ценность кода.
• Не усложняйте дизайн форм.

XHTML & CSS приемы

1. Элемент FORM создает форму.
2. Единственным обязательным его атрибутом является ACTION, и он всегда должен быть URI.
3. По умолчанию METHOD выставляется в GET.
4. Атрибут NAME устарел, используйте вместо него ID.
5. Элемент FIELDSET используется для группировки связанных полей формы. Может быть вложенным.

Примечание: ниже находится перевод статьи «Client Side Load Balancing for Web 2.0 Applications», в которой затрагиваются вопросы балансировки нагрузки между несколькими серверами и рассматривается решение, обеспечивающее балансировку такой нагрузки прямо на компьютере клиента.

Сервер обрабатывает HTTP (HyperText Transfer Protocol) запросы со стороны браузеров. Если вы введете в адресной строке URL, например, www.digital-web.com, то ваш компьютер отправит поисковый запрос для определения, какие именно сервера будут обрабатывать ваш запрос и пересылать данные. Техника обработки таких запросов для кластера веб-серверов называется балансировкой нагрузки.

Балансировка нагрузки для веб-приложений

Балансировка нагрузки повышает надежность веб-сайта путем распределения запросов между несколькими (кластером) серверами, если один из них перегружен или отказал. Существует много методов по обеспечению такого поведения, но все они должны удовлетворять следующим требованиям:

• Распределять нагрузку внутри кластера рабочих серверов.
• Корректно обрабатывать отказ одного из рабочих серверов.
• Весь кластер должен существовать для конечного пользователя как одна-единственная машина.

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

Примечание: ниже перевод заметки «Visualizing Science & Tech Activity in Wikipedia».


Жёлтым цветом обозначены статьи на технологические темы, зелёным — на научные, синим (голубым) — на математические.

Осторожно! PNG: 3753x2775, 14 Мб


Для тех, кто еще не видел первоначальную Визуализацию Активности в Википедии, с ней можно ознакомиться здесь (там же располагается детальное описание). Здесь также выложена масштабируемая версия в стиле Google maps.

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

Примечание: ниже расположен перевод статьи «KHTML vs. Gecko vs. Trident vs. Presto: Behind the Browser», в которой рассматриваются основные движки браузеров, история их возникновения и развития, а также некоторые философские вопросы, с ними связанные. В основном, речь идет о KHTML, WebKit и Gecko.

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

В любом случае, пользователей гораздо больше беспокоит, насколько их браузер безопаснее. Возможно, их тревожит, были ли старые версии браузера от Apple более безопасными, потому что использовали KHTML? Или, может быть, безопасность и удобство использования гораздо выше у Firefox от Mozilla Foundation, ибо он использует Gecko? Является ли Internet Explorer 7 (IE7) от Microsoft лучшим браузером на сегодняшний день, потому что использует движок Trident? Отчего так много возможных альтернатив?

«Почему мы используем не единственный браузерный движок? Это помогает замедлить инновационное развитие и предупредить появление ошибок, которые не обнаружатся во всех браузерах одновременно. В любом случае, несколько реализаций одного и того же лучше, чем одна», — комментирует Gene Spafford, профессор информатики в Purdue University, специально для LinuxInsider.

Примечание: ниже расположен перевод академического исследования «Social Networks And Group Formation», рассматривающего некоторые аспекты выделения групп и формирования связей в социальных сетях.

«Принцип рычага» в действии

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

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

Эта область знаний находится на пересечении таких наук, как информатика, социология и математика. Ее исследователи изучают использование социальных сетей в общественных и деловых целях при помощи информационных и коммуникационных технологий (information communication technologies (ICTs)), в том числе, интернета. В этот статье рассматривается, как социальные сети, используя преимущества таких технологий — особенно, интернет-технологий, — создаются, развиваются и приносят пользу.

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

Примечание: ниже перевод статьи «Setting a Web Design Budget», посвященной вопросам создания веб-сайтов с финансовой стороны.

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

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

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

Примечание: ниже расположен перевод статьи «jQuery for JavaScript programmers», в которой автор высказывает свое мнение об этой библиотеке, ориентируясь, в первую очередь, на продвинутых программистов, и приводит несколько десятков примеров ее использования.

Когда jQuery увидела свет в январе 2006, я подумал: «очередная красивая игрушка». Выбор CSS-селекторов в качестве базиса было, конечно, изящной идеей (подробнее о ней в моей заметке getElementsBySelector), но использование цепочек преобразований выглядело немного замысловато, и сама библиотека, по-видимому, не покрывала всех возможных случаев. Я расценивал тогда jQuery только как временное и проходящее решение.

Только несколько месяцев спустя понял я, насколько же ошибался по отношению к ней. jQuery является просто произведением инженерного искусства. Она умело покрывает достаточно широкой диапазон повседневных функций и предоставляет при этом удобный API для расширений, с помощью которых можно добавить любую другую функциональность. Абстрактность в ней заложена на уровне ядра — речь идет о выборе DOM-элементов — и она извлекает из него максимум пользы. И что важнее всего, использование этой библиотеки подразумевает следование хорошему стилю в программировании и хорошо сочетается с другими частями JavaScript-кода.

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

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

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