Ретроспектива (от лат. retrospectare, «взгляд назад») — взгляд в прошлое, обозрение того, что было в прошлом.

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

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

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

Я собираюсь сделать смелый прогноз. Еще долго после вас и меня HTML будет вокруг. Не только в миллиардах архивных страниц нашей эры, а как живые дыхательные органы. Слишком много сил, энергии и инвестиций пошло на разработку web-инструментов, протоколов и платформ, что бы все это было легко брошено.

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

Примечание: ниже перевод очередной заметки «Image Optimization, Part 5: AlphaImageLoader» из блога YUI. Stoyan Stefanov на этот раз рассказывает о тонкостях применения фильтра AlphaImageLoader для IE. Мои комментарии далее курсивом.

Это пятая часть серии статей про оптимизацию изображений. С предыдущими частями можно ознакомиться по адресу:

• Image Optimization Part 1: The Importance of Images
• Image Optimization Part 2: Selecting the Right File Format
• 4 шага для уменьшения размера файлов
• Последовательные JPEG — Быть или не быть?

Данная статья из серии, посвященной оптимизации изображений, рассказывает о технике, доступной только в IE, — CSS-фильтре AlphaImageLoader, — который используется разработчиками для решения проблем с прозрачностью для полноцветных PNG-изображений в IE. Основная проблема с AlphaImageLoader заключается в том, что он влияет на производительность страницы, и тем самым ухудшает пользовательское восприятие. Я утверждаю, что стоит избегать использования AlphaImageLoader во всех возможных случаях.

Маленький экскурс

Как было сказано в одной из предыдущих статей, PNG могут быть нескольких видов, которые могут быть разделены на 2 основных:

• Индексированные (палитра), их также называют PNG8, можно использовать до 256 цветов.
• Полноцветные PNG, которые также называют PNG32 или PNG24.

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

HTML 5 — это грядущее обновление гипертекстового языка разметки, основного способа создания контента для размещения его во всемирной паутине. Разработка HTML остановилась в 1999 году, на версии HTML 4.01 и с тех пор web-содержимое изменилось так, что текущие спецификации HTML перестали соответствовать сегодняшним требованиям.

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

Это статья нашего гостя Jacob Gube, web-разработчика и дизайнера, автора Six Revisions — блога о web-разработке и дизайне.

Мучения со стандартным подходом применения CSS спрайтов, а именно трудности модернизации и в некоторых случаях сложности оптимальной компоновки заставили искать альтернативный вариант оптимизации загрузки изображений. Очередной раз почитывая хабра-статьи, наткнулся на интересный подход реализации спрайтов с применением data:URI. В ходе дискуссий и умозаключений были определены слабые и сильные стороны данного подхода. Одним из значительных недостатков нового подхода является сложность сборки конечного CSS. Однако, при использовании data:URI имеет место возможность автоматизации процесса.

Примечание: ниже расположен перевод заметки Image Optimization, Part 3: Four Steps to File Size Reduction от Stoyan Stefanov. В ней рассматриваются наиболее популярные консольные утилиты для минимизации изображений. Мои комментарии далее курсивом.
Об авторе: Stoyan Stefanov работает веб-разработчиком в команде Yahoo! по исключительной производительности и руководит разработкой инструмента для анализа производительности — YSlow. Он также внес значительный вклад в программы, разрабатываемые с открытым исходным кодом, выступает на конференциях и является техническим писателем: его последняя книга озаглавлена Объектно-ориентированный JavaScript.

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

• Оптимизация изображений, часть 1: важность картинок
• Оптимизация изображений, часть 2: выбираем нужный формат файлов

Текущая заметка посвящена некоторым наиболее часто используемым инструментам, которые можно применить для уменьшения размера изображений. Идея заключается в следующем: мы можем получать все изображения от дизайнера, но не оставлять их в исходном виде, а немного уменьшать в размере, используя указанные ниже инструменты. Это позволит автоматизировать процесс без необходимости глубокого анализа структуры изображения.
Читать дальше на webo.in →

Итак, каким же образом обеспечивается безопасность на нынешних веб-ресурсах? Хешированием паролей алгоритмом md5. Вроде бы всё здорово и замечательно — md5 есть функция необратимая и пароли, хранимые в виде таких хэшей, взломать нельзя, даже если злоумышленник получил доступ к базе. Ан нет! Вспоминаем про Rainbow-таблицы и прощаемся с мыслью о полной безопасности хранения паролей в таком виде. Та как же их тогда шифровать? Алгоритмы востановимого шифрования с ключами тоже не панацея, да и системных ресурсов сии функции кушают немало...
Вопрос: Так как же, не в ущерб производительности, обезопасить md5 хэши от Rainbow-таблиц?
Ответ: соль.

Серия постов про “Web, кэширование и memcached” продолжается. Начало здесь: 1, 2, 3, 4 и 5.
В этих постах мы поговорили о memcached, его архитектуре, возможном применении, выборе ключа кэширования, кластеризации, атомарных операциях и реализации счетчиков в memcached, а также о проблеме одновременного перестроения кэшей и тэгировании кэшей.

Сегодняшний пост завершает эту серию, в нём обзорно мы поговорим о технических “мелочах”:

• анализ статистики memcached;
• отладка memcached;
• “RPC” с помощью memcached.

Полный текст всех разделов в виде одной большой PDF-ки можно скачать и посмотреть здесь (в разделе “Материалы”).

Серия постов про “Web, кэширование и memcached” продолжается. Начало здесь: 1, 2, 3 и 4.
В этих постах мы поговорили о memcached, его архитектуре, возможном применении, выборе ключа кэширования, кластеризации, атомарных операциях и реализации счетчиков в memcached, а также о проблеме одновременного перестроения кэшей.

Сегодня мы поговорим о тэгировании кэшей и о возможности сброса сразу группы кэшей в memcached.



Последний, шестой пост, будет посвящен различным техническим вопросам работы с memcached: анализу статистике, отладке и т.п.

Серия постов про “Web, кэширование и memcached” продолжается. Начало здесь: 1, 2 и 3.
В этих постах мы поговорили о memcached, его архитектуре, возможном применении, выборе ключа кэширования, кластеризации, атомарных операциях и реализации счетчиков в memcached.

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

Следующий пост будет посвящен тэгированию кэшей.

В этом посте я постарался собрать все известные мне хаки для css. Многие могут усомниться в их надобности для нормальных современных браузеров, потому как большинство хаков всегда применялись только для IE, но этот пост скорее для любознательных :), в верстке хаки вообще лучше не использовать. Но так или иначе, раз они есть, грех о них не знать.

В отличие от многих хаков для той же Opera, которые также будут обработаны и Safari, я немного изменил код и Opera 9.2, Opera 9.5 и Safari 3 увидят каждый свой css.

Серия постов под общим заглавием “Web, кэширование и memcached” продолжается. В первом мы поговорили о memcached, его архитектуре и возможном применении.

Сегодня речь пойдет о:

• выборе ключа кэширования;
• кластеризации memcached и алгоритмах распределения ключей.

Следующий пост будет посвящен атомарности операций и счетчикам в memcached.

Этим постом хочу открыть небольшую серию постов по материалам доклада на HighLoad++-2008. Впоследствии весь текст будет опубликован в виде одной большой PDF-ки.

Введение

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

Cегодня мы поговорим о компонентах для высокопроизводительной и масштабируемой архитектуре на основе сервера memcached, а именно — распределённой базе для хранения данных MemcacheDB и системы очередей сообщений MemcacheQ.



Сначала рассмотрим, а что у нас есть в распоряжении для создания распределённой инфраструктуры хранения данных для веб-приложения. Ну, первое, что приходит в голову — кластеризация базы данных, это теперь поддерживается во всех распространённых системах, а также различные технологии репликации. Например, самая популярная СУБД для веб-проектов, MySQL поддерживает как репликации так и кластеризацию. Ещё можно обратится к традиционным файловым система и хранить данные в файловой системе, к примеру, Apache Hadoop. Но часто это слишком высокоуровневое решение, обычно же требуется гораздо проще варианты — когда нужно хранить и оперировать просто парами ключ-значение. Если серьёзно посмотреть, такая функциональность позволит покрыть потребности 90% веб-приложений. А если мы прибавим к этому возможность очень и очень быстро оперировать данными, хранить их в виде распределённой многосерверной системе и возможность постоянного хранения, устойчивого к сбоям — получим очень привлекательную платформу.