Web Debugging with 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.

Below is the home screen for Fiddler:

Let's go through some of the most useful features of Fiddler quickly:

1. Web Sessions - On the left pane, all the traffic is captured. Using this session, we can compare the sessions by simply selecting two sessions, right clicking and choosing compare command.

1. Statistics - Statistics seen in the right pane shows the information for selected sessions in text and graphic format as seen below.

Inspectors

Inspectors allow you to visualize requests and responses in meaningful ways. When you double click on a session fiddler takes you to the Inspectors tab for that session. Below is a snapshot

QuickExec

There is a little textbox with black background color and green forecolor on the bottom of Fiddler form where you can run some very useful commands. To see a complete list of available commands type 'help' and enter. Its very handy in using some quick commands like setting and removing the breakpoints.

Breakpoints

We can put breakpoints on request or response using Web Session List. Breakpoints can be put using Rules menu>Auto Breakpoints or status bar or QuickExec. In the QuickExec box type in 'bp' and enter. This will show you a handy help popup dialog that lists the breakpoint commands.

When the breakpoint is set the next time you make a request or receive a response that fulfils the breakpoint's requirements the breakpoint is hit and you get the opportunity to change the traffic.

AutoResponder

AutoResponder is a very handy tool. It allows you to fake server's responses. If you think about it, Fiddler is sitting between you and the web server and nothing can stop it from returning the response locally without hitting the server, and that is basically what AutoResponder does. You can configure AutoResponder to respond to specific requests and let the others through, or you can ask it to only respond to the traffic you expect and block the rest. AutoResponder uses some rules to match the request. From Fiddler's reference

Request Composer

The Composer allows you to craft custom requests to send to a server. You can either create a new request manually, or you can drag and drop a session from the Web Sessions list to create a new request based on the existing request.

Filters

The Filters tab enables you to quickly filter out traffic that is not of interest.

Fiddler Extensions

There are some great Fiddler free to use extensions at http://www.fiddler2.com/fiddler2/extensions.asp

Fiddler Timeline

Fiddler's Timeline View allows you to visualize the HTTP(S) traffic on a "waterfall" diagram. Hovering over any entry will show more information about the entry. Double-clicking the entry will inspect that session.

Conclusion

I hope this gives a headstart for the ones who have not yet explored a web debugging tool powerful as Fiddler. If you want to dig deeper then Fiddler website and Fiddler Blog will be the place to look at.

References

http://www.fiddler2.com/Fiddler/help/

http://www.mehdi-khalili.com/fiddler-in-action/part-1

http://www.fiddlercap.com/FiddlerCap/

http://www.developer.com/lang/jscript/article.php/3631066/Fiddler-Can-Make-Debugging-Easy.htm

The S.O.L.I.D. Principles of Class Design explained with Posters

The S.O.L.I.D. principles seem to be the least common denominator of creating great classes; even before Design Patterns. In the early 2000s, Robert “ Uncle Bob ” Martin introduced a series of five principles for developing software with OOP that were designed to lead to higher - quality systems that were easier to maintain. These SOLID Principles became a sort of map for developers in both designing new applications and refactoring existing code bases.

Single Responsibility Principle

The “S” in SOLID is for Single Responsibility Principle, which states that every object should have a single responsibility and that all of its services should be aligned with that responsibility. “Responsibility” is defined as “a reason to change”, and Wikipedia does a pretty good job of explaining it:

As an example, consider a module that compiles and prints a report. Such a module can be changed for two reasons. First, the content of the report can change. Second, the format of the report can change. These two things change for very different causes; one substantive, and one cosmetic. The single responsibility principle says that these two aspects of the problem are really two separate responsibilities, and should therefore be in separate classes or modules. It would be a bad design to couple two things that change for different reasons at different times.

Open-Closed Principle

The “O” in SOLID is for Open-Closed Principle, which states that software entities – such as classes, modules, functions and so on – should be open for extension but closed for modification. The idea is that it’s often better to make changes to things like classes by adding to or building on top of them (using mechanisms like subclassing or polymorphism) rather than modifying their code.

Liskov Substitution Principle

The “L” in SOLID is for Liskov Substitution Principle, which states that subclases should be substitutable for the classes from which they were derived. For example, if MySubclass is a subclass of MyClass, you should be able to replace MyClass with MySubclass without bunging up the program.

Interface Segregation Principle

The “I” in SOLID is for Interface Segregation Principle, which states that clients should not be forced to depend on methods they don’t use. If a class exposes so many members that those members can be broken down into groups that serve different clients that don’t use members from the other groups, you should think about exposing those member groups as separate interfaces.
Dependency Inversion Principle

The “D” in SOLID is for Dependency Inversion Principle, which states that high-level modules shouldn’t depend on low-level modules, but both should depend on shared abstractions. In addition, abstractions should not depend on details – instead, details should depend on abstractions.

Courtesy - http://blogs.msdn.com/b/cdndevs/archive/2009/07/15/the-solid-principles-explained-with-motivational-posters.aspx

http://www.codeproject.com/Articles/60845/The-S-O-L-I-D-Object-Oriented-Programming-OOP-Prin

SOLID Motivational Posters, by Derick Bailey, is licensed under a Creative Commons Attribution-Share Alike 3.0 United States License.

Seven Habits of Highly Effective Programmers

This advice by Philip Chu is highly influenced from Steven Covey in his best-selling book, The 7 Habits of Highly Effective People, but is really a high quality read - peppered with illustrative real world programmer tales. I am just putting bullets points and brief description in the blog here; however you must read the complete article at http://drupal.technicat.com/writing/programming.html. Also other articles at Philip’s site is certainly worth a read.

1.     Understand Your Requirements

The first step in becoming an effective programmer is to ensure that you are spending your time wisely. And there is no greater waste of time than in working on something that is not useful or never shipped. 

Gets a demonstrable system working as early as possible? 

Once you have something working, don't just leave it as a "proof of concept". Let people play with it, see their reactions, and let this guide and prioritize your development.

2.     Keep It Real

Keep your software running in as close to a shipping state as possible. You never know when you'll have to demo the system, send out an evaluation copy, or even deliver ("OK, time to wrap things up!") 

If you just test with sample data, that big iceberg of real data out there is going to sink your program, hence use real data.

The development build on your machine is not the real build, hence use real build machine.

Don't procrastinate on merging your code with the main code base - the longer you wait, the harder it gets

3.     Understand Your Code

Life is full of wonderful mysteries, but your code is not the place for them. You don't have to know how your car works - if the engine starts making strange noises, you drop it off the mechanic. When it comes to your code, if you don't understand how it works, or doesn't work, no one will. 

The best writers and coders have an esthetic and their work features structure and style that can often be identified with the author. 

You should periodically inspect your code, sweep up accumulated hard-coded numbers, outdated comments, misleading function names, or you'll inevitably end up with uninhabitable code that's embarrassing to show anyone else. 

Document your code as if someone else might have to take it over at any moment and know what to do with it. 

Ignore compiler and runtime warnings at your own peril. They are called "warnings" for a reason.

4.     Optimal Programming

On the other extreme from cut-and-pasters are those who change code just to make it look prettier (at least to them). While it's laudable to have a programming esthetic, it's a waste of time (and a useless risk) to change code just so it looks better to you.

"Refactoring" is all the rage, now, but programmers often take it to mean any code cleanup or redesign. The trick is in reorganizing code for the better without breaking anything. 

If you do need to optimize for speed or space in you application, attacking anything other than the bottleneck is a waste of time.

5.     Manage Thyself

You probably have a lot of complaints about your boss being a lousy manager, and you're probably right. So you have to be your own manager. Even if you have a decent boss, he's not going to stand behind you telling you what to type and how fast

Programmers are notoriously inadequate at providing useful schedule estimates. I think this is a bad rap, since management, left to their own devices, often make even worse predictions, and unwelcome news from engineers is often ignored. (A common theme in any engineering disaster). But still, awareness of the schedule is critical to actually getting the project done on time. 

You wouldn't just hop into your car before deciding where you want to go, right? And probably you have a route in mind before you start driving, too. Similarly, before you sit down at our computer, you should know what you want to accomplish that day and have some idea how.

6.     Continuous Education

A corporate soccer team member once asked me, as we were lacing up our cleats, "what's the secret to C programming?" If there was such a secret, I'd be hawking it on late night TV along with ab machines and how to get rich in real estate. Sorry, there's no shortcut - you have to learn and practice and make some mistakes. And you don't necessarily have to rely on corporate training or going back to school - there are plenty of (inter)national and local professional groups, books, and of course, the Internet. 

It's called "computer science" for a reason. It's easy (maybe too easy) for anyone to to start programming, without a formal computer science education. In particular, those from other engineering and science disciplines can pick up programming quickly and make a good living. But to effectively tackle non-trivial tasks, you need to know the inherent capabilities and limitations of software and recognize prior work, so you don't waste time reinventing the wheel, badly. You don't have to know everything under the sun, but you should have at least a cursory familiarity with many areas and be prepared to do some additional research as necessary.

7.     R-E-S-P-E-C-T

One requirement for being an effective software engineer is to be taken seriously. You need to have the respect of your peers and managers, at least for your technical capabilities, to have control over your own work and influence over others. 

Engineers sometimes communicate more to show off their own knowledge rather than to inform (although, if you can do both, kudos to you). This is often inflicted in employment interviews, under the guise of "finding out how you think" the candidate is asked inane puzzle questions. This can backfire, though, if the candidate has any self-respect.