На Хабре уже упоминалась данная тулза, но как-то в контексте других тем.

What is Fiddler?
Fiddler is a Web Debugging Proxy which logs all HTTP(S) traffic between your computer and the Internet. Fiddler allows you to inspect traffic, set breakpoints, and «fiddle» with incoming or outgoing data. Fiddler includes a powerful event-based scripting subsystem, and can be extended using any .NET language.

Fiddler is freeware and can debug traffic from virtually any application that supports a proxy, including Internet Explorer, Google Chrome, Apple Safari, Mozilla Firefox, Opera, and thousands more. You can also debug traffic from popular devices like Windows Phone, iPod/iPad, and others.

To debug applications you've written in Java, .NET, or using WinHTTP, see this page.

Итак Fiddler — прокси, который работает с трафиком между вашим компьютером и удаленным сервером, и позволяет просматривать и менять его.

Однажды меня попросили разобраться с багом: при смене frameRate в произвольном количестве вложенных .swf начинал странно вести себя самописный «твинер» — класс, который интерполирует некоторое значение на заданное время. Вместо своей нормальной деятельности, твинер мог перескакивать значения, мог залипать на каком-то одном, а иногда просто в произвольный момент времени задавать переменной её конечное значение и отчитываться о завершении своей работы. Просящий связывал проблему именно с многоуровневой вложенностью и несовпадении собственного и родительского fps.

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

Новости

Grape
24 приёма в Ruby
Ruby 1.9.3-p125
MacRuby & MountainLion + what you can do to help the project
9 февраля зарелизился Spree 1.0.0
Полезные инструменты для Capistrano — capistrano-deploy
"MicroGems: five minute RubyGems"
22 февраля вышел JRuby 1.6.7
23 февраля вышел SimpleForm 2.0

Обсуждение

Версии Ruby

tinyrb, который неграммотные авторы обзывали то «тайни руби», то TinyRuby
JRuby
Rubinius
MagLev
MRI Ruby

Celluloid

Elixir — функциональный язык поверх Erlang VM
Celluloid
Nio4R — New IO for Ruby
Reel — web-сервер на Celluloid
DCell — распределенный Celluloid
ZooKeeper — высоконадежный сервер для распределенной координации

UPD: Продолжение статьи с примером техзадания

Не так давно на хабре были две статьи (Согласно техническому заданию и А зачем мне ТЗ? Я и так знаю!) посвященные техническим заданиям. У меня обе статьи вызвали, мягко говоря, недоумение, в особенности статья «Согласно техническому заданию». На мой взгляд, это вообще вредная статья, которая приводит к неверному понимаю сути ТЗ. В связи с этим хочу выразить свой взгляд на этот вопрос. Не буду говорить обо всех тех. заданиях, слишком широка тема, но думаю смогу рассказать о ТЗ на сайт.

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

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

1. Обоснование необходимости ТЗ

А зачем вообще нужно ТЗ на сайт? Заказчик говорит: «Нужен следующий сайт: каталог товаров, корзина, форма заказа, доставка, мы на карте, о нас, обратная связь». Что не ясно? Ничего необычного, всё обыденно и рутинно.

Разработчик отчетливо представляет, что нужно сделать, а сделать, в его понимании нужно вот так: