Топик удален в связи с обилием рекламы сайта автора.

Оригинальный пост — в блоге автора.

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

Далее перевод :-)

Интроспективной называется программа, которая на вывод подает свой же исходный текст. Но я наткнулся на более интересный вариант: программа на Haskell, которая выводит программу на Python, которая выводит программу на Ruby, которая выводит исходную программу на Haskell.

Мы привыкли к виджетам-плагинам браузера Opera, привыкаем к виджетам-утилитам Windows Vista. Quintura же предлагает не просто фенечку, а полезное веб-приложение для сайта/блога. Итак, встречайте: первый веб-виджет Рунета. Визуальный и лёгкий в установке, как Flash-видеоролик, на главной странице Хабрахабра.
Прогнозы на 2007 год обещали огромный рост популярности разнообразных виджетов. Сомневающиеся могут отправиться сюда или поискать материалы на эту тему самостоятельно.

В моем проекте очень много классов взаимодействуют на клиентской части. Каждый класс лежит в отдельном файле для удобства разработки. Хорошей практикой для увеличения скорости загрузки страницы, является уменьшение количества запросов к серверу. Поэтому чем меньше файлов и рисунков включать в страницу тем быстрее она загрузится. В случае с рисунками – СSS спрайты помогут уменьшить количество запросов. А в случае с js и css файлами – это конкатенация файлов и сжатие. Об этом и поговорим.

Очень удобный инструмент с открытым исходным кодом js-builder



Отличный инструмент для того чтоб сформировать в правильном порядке конкатенацию файлов. Работает с любыми расширениями, которые задаешь. Также сжимает js.
В моем проекте я использую библиотеку prototype.js. Билдер при сжатии прототайпа выдает эксепшн. Поэтому я скачал исходники и перебилдил так чтоб билдер занимался только конкатенацией без сжатия. Пересобранную длл, можно скачать тут
Билдер также содержит консольное приложение. А это то что нужно для билда.
Далее необходимо сделать компрессию файлов которые сгенерирует билдер.
Для этой цели я использовал YUI Compressor. Отличная библиотека с высокой степенью сжатия.
Осталось только как то автоматизировать процесс сборки. Для этого я написал batch файл (я в виндовс работаю).
Выглядит он (build.bat) примерно так
set path1=D:\Projects \build\

%path1%JSBuilder\JSBuildConsole.exe /path=%path1%MyHeritageBuild.jsb

java -jar %path1%yuicompressor-2.3.1\build\yuicompressor-2.3.1.jar
%path1%build\output_file_from_js_builder.js -o %path1%target-min.js

java -jar %path1%yuicompressor-2.3.1\build\yuicompressor-2.3.1.jar
%path1%build\style-all.css -o %path1%style-all-min.css


В моем случае джс билдер на выходе дает 2 файла — css и js, а компрессор их сжимает.
Надеюсь это поможет вам создать удобный процесс сборки файлов.

Эту статью я взял из своего техноблога на сайте www.kigorw.com

Примечание: ниже выложен перевод статьи «CSS Layouts: The Fixed. The Fluid. The Elastic.», в качестве русского аналога термина layout используется макет. В статье рассматриваются два вида «резинового» макета, поэтому один из них для различия обозначен как «эластичный» (elastic, спасибо MTonly за ценный комментарий). Автор резюмирует основные плюсы и минусы каждого из рассматриваемых макетов (способов верстки).

Какой макет верстки (с использованием Каскадных Таблиц Стилей, CSS) можно считать наилучшим? Каждый из них имеет свои хаки (quirks) и свои уникальные плюсы и минусы. Будет ли один из них более удобен для пользователя, чем все остальные? Насколько просто им будет пользоваться? Какие есть у каждого из них проблемы, и как их обходить? Верстается ли один из них проще всех остальных? Есть ли среди них какой-либо ущербный, совершенно непригодный? Скорее всего, многие однозначно ответят на эти вопросы, но я не буду так торопиться. Каждый из этих макетов мне нравится, и каждый применим в том или ином случае, если делать это с умом и внимательно проверять простоту использования и одинаковую доступность для всех категорий пользователей. Все они являются частью уровня представления (presentational layer) для вебсайта, поэтому большинство вопросов по доступности вытекают из корректного использования семантики и общих правил верстки. Далее я опишу свой взгляд на жестко фиксированный (rigid fixed), адаптивный резиновый (adaptable fluid) и расширяемый эластичный (expandable elastic) макеты.

Примечание: ниже перевод статьи «How JavaScript is Slowing Down the Web (And What To Do About It)», посвященной, в основном, работе с виджетами: характерные проблемы и методы их решения.

Одна строка JavаScript является основой большинства текущих технологий, которые используют авторы блогов. Виджеты, средства (фото-/видео-)обмена, отслеживание посетителей, рекламные объявления. Во многих случаях единственная строка JavaScript — это все, что нужно автору, чтобы добавить в своей блог что-то новенькое. Проблемы начинаются тогда, когда много-много этих самых строчек собирается вместе...

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

Примечание: статья посвящена обзору проблемы неработающей кнопки «назад» в браузере при использовании AJAX-методов для передачи содержания страниц от сервера к клиенту. В статье рассматриваются основные принципы работы AJAX и возможные пути решения заявленной проблемы. Курсивом даны мои комментарии.

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

Примечание: ниже перевод статьи «Fixing The Web — Part 1», в которой поднимаются наиболее актуальные вопросы, касающиеся текущего положения вещей в Вебе.

Нуждается ли Веб в исправлениях?

История Веба насчитывает уже 16 лет. В первые 10 лет Веб-технологии развивались ошеломляюще быстро, но в последние 6 лет серьзных изменений в них не последовало. Насколько это хорошо или плохо? Существует ряд вполне понятных преимуществ существования стабильной среды разработки для любой технологии, но является ли Веб стабильным, или же он находится в застое? Постигнет ли Веб без инноваций такая же участь, как и любую другую технологию, что перестает следить за изменением пользовательских предпочтений и становится устаревшей?

Естественно, Веб играет роль, прежде всего, глобального информационного источника, но насколько хорошо при этом функционируют сами Веб-технологии? Чтобы ответить на этот вопрос, мы должны рассмотреть ряд проблем, которые существуют в Вебе:

Примечание: ниже перевод статьи «Reporting bugs — a how-to guide», в которой приводится ряд нехитрых действий, которые могут помочь как пользователю, так и разработчику справиться с ошибками на сайте или в веб-приложении. В свете постоянного появления в Рунете проектов со статусом «бета», статья может быть особенно полезна.

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

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

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

Примечание: ниже находится перевод двух близких статей («Delay loading your print CSS» и «JS includes — the saga continues…») по оптимизации загрузки страницы при наличии нескольких файлов стилей или скриптов.

У вас есть два вызова CSS-файлов на странице, например:

<link type="text/css" rel="stylesheet" href="screen.css"
      media="screen" />
<link type="text/css" rel="stylesheet" href="print.css"
      media="print" />

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

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

Примечание: ниже перевод статьи «Presentation Layer Performance Tuning», в которой затрагиваются основные аспекты оптимизации загрузки веб-приложений и предлагаются некоторые практические советы.

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

Эти процессы, однако, только частично затрагивают то время, которое клиент тратит на ожидание загрузки страницы в окне своего браузера. Большая часть времени тратится на загрузку, кеширование и отображение JavaScript, CSS и картинок (прим.: не-HTML файлов). Оптимизация производительности уровня представления (presentation layer) веб-приложений, на самом деле, сводится к двум простых условиям:

• Меньше данных
• Меньше запросов

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

Примечание: ниже перевод статьи 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.

Примечание: ниже перевод статьи «Event delegation without a JavaScript library», посвященной обзору методов по назначению обработчиков событий в JavaScript и их возможной оптимизации, она дополнена моими комментариями и практической частью.

Большинство статей и примеров, которые я видел в последнее время по переопределению событий, основывались на какой-либо распространенной библиотеке. Например, в своей хорошо известной статье Chris Heilmann применяет YUI-библиотеку, а в прошлом месяце Dan Webb в своей презентации на media использовал prototype.

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

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

Примечание: ниже перевод обзорной статьи «JSON vs XML», посвященной JSON и его сравнению с XML по ряду критериев. Публикуется в целях популяризации JSON среди читателей Хабрахабра.

JSON (англ. JavaScript Object Notation) — формат обмена данными, легко читаем людьми, легко обрабатывается и генерируется программами.

Основан на подмножестве языка JavaScript, Standard ECMA-262 3rd Edition — декабрь 1999.

JSON — Википедия

Что является правильным форматом ответа на XMLHttpRequest в AJAX-приложениях? Для большинства приложений, основанных на разметке, ответ будет простым — (X)HTML. Для информационно-ориентированных приложений выбор будет лежать между XML и JSON. До недавнего времени я не сильно задавался вопросом, что лучше использовать, XML или JSON. Я просто предполагал, что в каждом конкретном случае стоит выбирать наиболее подходящий формат, и все. Но недавно мне довелось проверить на практике этот подход. В этой заметке я опишу критерии, по которым проводил сравнение между XML и JSON, и собственные умозаключения.

Итак, критерии следующие.

• Удобочитаемость кода.
• Простота создания объекта данных на стороне сервера.
• Простота обработки данных на стороне клиента.
• Простота расширения.
• Отладка и исправление ошибок.
• Безопасность.

Примечание: ниже представлен перевод двух последовательных статей «The window.onload Problem — Solved!» и «window.onload (again)», посвященных оптимизации исполнению скриптов при загрузке страницы, эта проблема была предварительно затронута в статье: «Как JavaScript тормозит Веб (и что с этим делать)?»

Для начала определимся с самой проблемой. Событие window.onload используется программистами для старта их веб-приложения. Это может быть что-то довольно простое, например, выпадающее меню, а может быть и совсем сложное, как пример, запуск почтового приложения. Суть проблемы заключается в том, что событие onload срабатывает только после того, как загрузится вся страница (включая все картинки и другое бинарное содержимое). Если на странице много картинок, то можно заметить некоторую задержку между загрузкой страницы и тем моментом, когда она начнет фактически работать. На самом деле, нам нужно только узнать способ определить, когда DOM полностью загрузится, а не ждать еще и загрузку картинок.

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

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

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

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

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