Coding Smackdown

Welcome, I’m Jim Lavin and this is Coding Smackdown, the netcast where we put a headlock on the coding lifestyle.

This episode is rated G for the insightful wisdom of the coding guru we are about to impart.

Once upon a time there was a mechanical engineer, an electrical engineer and a software engineer riding through the mountains and as they started to go down a steep incline the brakes gave out and they careened down the incline and crashed into the guard rail.

The three engineers got out of the car scratched their heads and looked at the car.

The Mechanical engineer said “We should look at all of the mechanical systems, test each one separately and determine which one is malfunctioning and fix it.”

The Electrical Engineer said “I got a better idea, lets hook my diagnostic scope to the on-board computer and it can tell us which system failed and we can then fix it.”

Then the Software Engineer said “I got an even better idea, lets just push the car back up the mountain and get in and see if it happens again!”

Over the past couple of years I have been a technical lead on a large global virtual team and I have spent hundreds of hours mentoring developers and one of the most important skills I see lacking is the ability to debug an application.

Developers too often waste their time rerunning an application and guessing why an error is happening instead of using the debugger to step through code and find out what is really happening inside their code.

Not only does the debugger help you find out what is happening inside your code it can be used as a valuable training tool when you are trying to learn a new framework or understand how a pattern executes.

Most any Development Environment provides an integrated debugger that allows you to single step through your code to see what is happening and where things are going wrong.

There are five things you need to get familiar with, in order to use the debugger effectively:

The Debugger Commands
Setting Breakpoints
Viewing Local Data
Setting Watches on Data
Viewing the Callstack

There are several commands that are common to all debuggers.

Those to start the debugging process and those to navigate with while debugging an application.

Usually your development environment will include a command to start the debugger. In Visual Studio this is normally the F5 key or you can select Debug | Start Debugging from the main menu.

If you are trying to debug a process that is already running, development environments usually provide a way for you to attach to an existing process. In Visual Studio you can do this by selecting Debug | Attach To Process from the main menu.

Once you’ve started the debugger you need to be able to control how the computer executes the code. There are usually several commands that allows you to step through the code or jump to a location in the code.

The most common commands are;

Single Step which allows you to execute a single line of code and stop.
Step Into which allows you to step into a function call and continue debugging.
Step Out which allows you to continue execution but stop once a function completes executing and returns.
Run To Cursor which allows you to set your cursor at a line of code and have the debugger run until it hits the line where the cursor is.

If you don’t want to walk through every line of code but stop when you reach a specific function or method within your code, then you want to use break points.

Breakpoints allow you to stop the execution of your code so you can step through it at a desired location.

There are several ways you can set a break point:

By Location – this is when execution reaches a specific function or line of code in a specific file.
By Condition – when a break point location is reached, an expression is evaluated and the break point is hit only if the expression is true.
By Hit count – when a break point location is reached and the hit counter has reached the number of hits to equal the expression. You can stop on a specific number of times, less than a specific number or when the hit counter is greater than a specific number.
By Filter – This is a way to restrict break points from happening based on Machine Name, Process Id, Process Name, Thread Name or Thread Id. This can be really great if you are trying to debug a single thread within a multi-thread application.
By setting a breakpoint you can run your application and every time the debugger hits the break point it will stop so you can single step through your code.

So now that you’ve set your break point and reach some code you want to debug what do you do next?

As you step through the code line by line, you’ll probably be interested in what the values of your variables are as you execute each line of code.

Most debuggers provide a Locals Window that allows you to inspect the values of the variables and object within your code as you step through it.

By using the Locals Window you can see exactly what affect each line of code has on your data. You can also inspect the variables passed into your methods to ensure the right data is getting to your code.

9 times out of 10 an application fails because of bad data. Using the Local Windows as you step through your code will help you catch those issues.

There might be times where you want to track the state of an object over time, the Watch Window provides a perfect place to do that.

The Watch Window allows you to keep track of the state objects as you execute your code that may be in different modules or objects.

The Watches Window allows you to inspect a global variable or object as you execute code. It works similar to the Locals Window but only shows those variables or objects you have set up watches for.

The nice thing about the Watches Window is that you can use it to filter out local variables that you are not interested in. This is really useful when you have a method or funtion with a lot of local variables.

So now, you are stepping through your code and you know how to inspect the data within your application as you step through it, next we’re going to show you how you got to your code by using the call stack.

The call stack is the best way to find out how your code got executed.

It gives you a list of each line of code that was called previously in order to get to where you are now.

If you want to see what line of code called your code, you can usually click on a line in the Call stack and you’ll be taken to the code.

Now you are armed with the enough knowledge to quickly find out what is going wrong in your application.

If you are new to a framework library or want to see how a piece of code works you can use the debugger if you have the source code.

Just set a couple of breakpoints in your code and step into the framework and walk the code step by step to get a good idea of what is going on under the covers.

For example if you want to step through the .Net Framework in Visual Studio select Tools | Options from the main menu and Go to the General Option under Debugging and select Enable .NET Framework source stepping. This will make changes to your debugging environment that will allow you to step into any .NET Framework code next time you are in the debugger.

One of the first things I do whenever I start using a new framework or library, is install the source code and step into the code in order to figure out how best to use the library.

Trust me this is one of the best uses of the debugger you’ll ever find and provides you with a quick and easy way to find out what other libraries are doing.

So there you have it, next time you need to figure out why your code is failing, instead of re-running the application and see if it happens again, set a couple of break points in the debugger and walk through your code step-by-step, you’ll find the reason your code is failing and be able to fix it faster.

If you have comments or questions leave us a comment on the show notes for this episode at http://codingsmackdown.tv

I’m Jim Lavin and we’ll see you next time on the Coding Smackdown!

So as it was with Twitter, I’ve now gotten the FriendFeed bug. I’m constantly checking a constant stream of data that my social networking friends are pumping into the ether. What I really like about FriendFeed is the way it aggregates a person’s various blogs and social networking statuses into a single stream of near-real time information.

As with Twitter, once you get addicted to having this data pumping through your veins on a daily basis, its hard to be without it. To address this craving the development team from FriendFeed has created fftogo, a mobile website which allows you take FriendFeed with you anywhere you want. Although fftogo doesn’t provide you with 100% of the functionality of the full website, it does let you check feeds, post messages and perform several other FriendFeed functions.

For me, having fftogo was not the neatest thing, it was that the FriendFeed team made public their FriendFeed API which allows you to build third party applications that consume the steady stream of data!

And, sure enough, not long after there was an app for the iPhone released. So, being the Windows Mobile neophyte that I am, I went looking for a Windows Mobile version so I could carry FriendFeed with me where ever I went. But alas! to my surprise no one had written one yet!

What was I going to do! Here I was faced with heading out of town and being away from my computers for a entire week with only my mobile browser to satisfy my cravings for senseless chatter and insane links from all my social networking buds! How could I survive! Where would I get my needs fulfilled!

Well, being the coding guru I am, I sat down the night before my flight and over four hours time I built a small Windows Mobile app that I could use to keep my cravings at bay. It worked great! I was able to see what everyone was chatting about, I could browse to the websites they were pointing out to me, I could even send simple posts if was so inclined. My needs has been met, my cravings held at bay and I was amenable to all those on the trip with me. I even had a great time!

After I returned, I decided to build that little app into a full fledge FriendFeed client with all the bells and whistles. So, I tore it down, I re-architected it a little bit here, I refactored it a little more over there and I’ve been able to add enough functionality, that I think will help to satisfy the cravings of the other FriendFeed junkies just like me.

To date, I’ve spent about 20 hours putting together what I’d call an Alpha quality application, which I’m ready to share with others for testing purposes and get feed back on how I can make it even better. Not all of the features are there yet, but there is enough that I think will be useful.

The current version is designed to run on Windows Mobile 6 Professional devices, such as the HTC Diamond and Touch, but I’d like to get a good cross section of devices to make sure everyone can run it. So, if you’re interested in being an early adopter and don’t mind things that go bump in the night, leave me a comment below that includes your Windows Mobile device type, carrier and why you think you’d be a good Alpha Tester and I’ll give 20 lucky people access to the bits.

Just to give everyone a quick tour of what FriendFeed for WinMo looks like, I’ve recorded a 15 minute demo that you can watch. I’d love to get you feedback!

Update: 6/1/2009

I’ve released a new Alpha Version of FriendFeed for WinMo.

New in this release:
1. Comments are now active.
2. You can post comments to an entry and it will show up at the end of the comment list.
3. You can refresh an entry while on the comments screen so you can keep up with discussions in real-time.
4. Media is now active. Still needs more work to correctly display images in the correct aspect ratio.
5. If you click on an image it will launch the browser so you can save it.
6. If you click on a friend name it will load their feed so you can go through their past posts.

Fixed in this release:
1. Network communications have been greatly improved, much, much fewer failures when retrieving feeds.
2. Moved retrieval of friend icon images to a background thread, so they are pulled down based on the subscription list instead of the post.
3. Branded the application with FriendFeed Logo.

Next Features for Implementation:
1. Ability to add images to posts.
2. Auto refresh of Entry after you press the refresh button for the first time. Hit it again and the auto refresh stops.
3. Auto refresh of a feed after you press the refresh button for the first time on the main screen. Hit it again and the auto refresh stops.