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

Вариант 1:
header ("Location: www.sitename.dom/page");
exit();

Вариант 2:
echo '';
die ("Redirecting to this page…");

Лично я раньше считал, что вариант 2 — однозначно правильнее, так как браузер пользователя может не поддерживать автоматическую переадресацию. Теперь я уже сильно в этом сомневаюсь, потому что таких браузеров практически не осталось — может, ими просто пренебречь? Минусы второго варианта очевидны: чтобы пользователь успел что-то прочитать, нужно хотя бы секунды три подождать, а это — время. Если сделать переадресацию через 0 секунд, перед пользователем промелькнут какие-то слова — меня лично такой шум раздражает.

Как вы считаете? По собственному или чужому опыту.

Иван Сагалаев реализовал интереснейшую штуку. Я не могу не рассказать о ней хотя бы и вкратце. Итак, в чём суть дела:

Обычно обладатели OpenID действуют в следующих условиях:

1. У них есть свой OpenID — это по сути некий персональный URL (например http://username.livejournal.com или http://username.moikrug.ru, или какая-то другая страница).
2. Они залогиниваются на сайтах, поддерживающих OpenID, указав заветный URL (см. выше)
3. Залогинившись, люди могут совершать некие действия на сайте (чаще всего оставлять комментарии и т.п.), причём система, не зная их имени, будет именовать их в соответствии с OpenID.

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

Уже сейчас можно всё опробовать, указав в качестве OpenID страницу вашего профиля в «Моём Круге» — она содержит hCard.

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

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

Как показали результаты опроса, больше всего люди-х хотели бы раскрыть секрет НЛО. Заранее хочу извиниться за то, что открыть его я не смогу, иначе мой логин просто самоуничтожится :(

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

Благодаря добрым людям-х, эта запись появилась именно здесь. Надеюсь, так будет и дальше :)

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

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

Данное рассуждение явилось разросшимся комментом на публикацию dezmasterdezmaster, опубликовавшему сегодня статью под заголовком "Ссылки при наведении курсора: нужна ли реакция?". Честно говоря, меня давно мучают схожие вопросы (= И вот, наконец, удалось немного понаводить порядок в своей голове.

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

В итоге, контекст, в который помещена ссылка, определяет ту степень контрастности состояний ссылки, которую нам следует применять. Выделяются следующие контексты: ссылка среди картинок, в тексте, среди ссылок, в меню, в повторе, в публиковании.

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

Продолжение...

Эта статья является продолжением Части1:
Работа HTML кодера.

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

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

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

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

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

Прочитав в этом блоге о балансировке на стороне клиента, решил опубликовать свою статью, в которой описаны основные принципы масштабирования для web-проектов. Надеюсь, хабралюдям будет интересно почитать.

Основы масштабирования

Масштабируемость — способность устройства увеличивать свои
возможности
путем наращивания числа функциональных блоков,
выполняющих одни и
те же задачи.
Глоссарий.ru

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

Ateve Commercial представляет новый проект — Teamer.ru. С его помощью организация командной работы станет намного проще — как для компаний, так и для команд фрилансеров.

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

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

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

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

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

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

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

Буквально сегодня официально объявлено о запуске сетевого сервиса «Optimus», позволяющего брать микроформатированный контент с любого URL, и преобразовывать его в XML или JSON.

Optimus позволяет извлекать данные в форматах hCalendar, hCard, hAtom, hResume, hReview, xFolkentry, adr, geo, xfn, votelinks, rel-nofollow, rel-tag, rel-license.

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

P.S. Сервис разработан с участием Дмитрия Барановского (DmitryBaranovskiy) — хорошего парня и талантливого разработчика, ныне живущего в Австралии.
P.P.S. Клавиатура Лебедева не служила прототипом для названия сервиса. Optimus — персонаж из аниме (со слов разработчиков).
P.P.P.S. Замечены проблемы с кириллическими кодировками. Их решают.

Примечание: мини-статья написана для новичков

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

Примечание: ниже находится перевод статьи «Bring on the tables», в которой рассматривается использование таблиц по прямому назначению и некоторые методы по увеличению их доступности.

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

Единственное, что имеет значение

Предыдущие части: Первая часть, Вторая часть, Третья часть

В этой статье рассказывается о той единственной вещи, которая важна для молодого стартапа.

Но для начала немного теории.

Если вы посмотрите на огромное количество стартапов, скажем, 30 или 40 или больше; этого будет достаточно, чтобы не замечать те, которым по чистой случайности повезло и найти совпадения — два очевидных факта предстанут перед вами.

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

Второй очевидный факт: существует огромное различие в трех главенствующих частях стартапов — командах, продуктах и рынке.

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

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

Примечание: ниже перевод статьи Jeffrey Zeldman «E-mail is not a platform for design». В ней рассматривается текущая поддержка со стороны email-клиентов HTML-разметки писем. Статья во многом спорная и неоднозначная.

После стольких лет процветания интернета HTML-письма по-прежнему вызывают сильное отвращение (still sucks). Вы можете подумать, что я имею в виду «HTML-письма не отображатся корректно в некоторых email-клиентах» Однако, это лишь часть истины. Компании тратят сотни часов простых верстальщиков для создания HTML-разметок, которые могут не работать в Eudora или в Gmail или прекратить отображаться в Outlook.

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

Примечание: ниже перевод статьи «Boost Your Hyperlink Power». В ней освещается использование атрибутов rel и rev, а также некоторые микроформаты.

Часть HTML-тегов и атрибуты мы используем каждый день в свой работе. Заголовки, параграфы, списки и картинки являются основой разметки каждого веб-разработчика. Но наиболее распространенным элементом, наверное, будет ссылка — простой тег, который связывает воедино все страницы, создавая ту самую беспорядочную структуру, которую мы называем Всемирная Сеть Интернет (WWW).

Ссылка как она есть

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

   <a href="http://allinthehead.com/">

Атрибут href находится в открывающем теге a, между открывающим и закрывающим тегами находится текст для описания ссылки:

   <a href="http://allinthehead.com/">Drew McLellan</a>

«Ну и что», — скажите вы. — «Это я все и так знаю», — и будете абсолютно правы! Но у ссылки есть еще кое-что, кроме атрибута href.

Примечание: ниже перевод статьи «Ajax Best Practices: Don't Break Bookmarks», посвященной решениям, позволяющим пользователям корректно добавлять в закладки страницы сайта, сделанного при помощи AJAX-методов. Я постарался дополнить ее по мере сил, опираясь на обсуждение предыдущей статьи из серии.

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