Found a great writeup on abstract classes versus interfaces at the code project. While not every developer or project makes use of those OOP constructs, it's important to be familiar with OOP terms for a few reasons:

• So you can design better systems
• So you can expand your knowledge
• So you can better understand other developers' code
• So you don't look like a n00b at some developer gathering

I feel that developers using Microsoft platforms are sometimes at a disadvantage when it comes to practical experience with OOP concepts. Not all developers, but if people started out coding in ASP or VB, they may not have the years of OO development that someone starting with java/etc would. I place the blame solely on the earlier MS platform and the "build it quick & dirty" ability that RAD toolkits accommodated. I'm not bashing anyone...there are many great coders on all platforms. But do you know how kludgey it was doing OO with VB6, ASP 3? Yup...pretty goofy.

Anyhow, I like simple straightforward writeups that I can print out & read on the train, etc. Hence the above link. Plus a link to CodeBetter's Feb 2005 articles -- there are some articles in there on OO concepts (abstraction, encapsulation, inheritance, and polymorphism) that will help any budding OO buddy.

My Yahoo referrals went WAY down last week, and I realized that dasBlog doesn't direct-link to URLs in posts. Which normally is good. However, it means that when I linked to all my old blog content, spiders weren't able to see it. So Yahoo thinks all my blog posts went away, and so I have less content, and so I'm not worth sending traffic to as much. Which is a downer.

So for now the archive links are in the blogroll, which is a direct link. Eventually I'll rework the site design.

Slashdot has an interesting blurb on running Windows 2000 on old, crappy machines. The original information is very helpful for getting rid of any performance-draining services & effects. BlackViper is also a resource for stripping OS settings down to the bare minimum for optional performance.

One big reason for running Windows 2000 on old hardware is so you can make use of otherwise "junk" boxes. Use them as file servers, web servers, test machines, internet terminals, etc.

Scott Mitchell has a good post on database projects in Visual Studio. Helpful for those people still using Query Analyzer or SQL Server Enterprise Manager for all their database development.

Some of the benefits include better source control, using one tool for web dev & db dev, and a better editor. I don't know if I agree that deployment is significantly easier than in SQL Enterprise Manager -- DTS makes it pretty easy, too. Plus did you know that if you highlight a table/proc name in SQL Enterprise Manager and hit CTRL-C, the clipboard is filled with the T-SQL needed to create that entity? Go ahead, try it. Its cool, sortof.

One ohter benefit that Scott forgot to mention (at least in his blog summary) was stored procedure debugging. Without stored procedure debugging, you're stuck with extra PRINT & SELECT statements spread throughout your T-SQL. Being able to launch a proc & debug it using Visual Studio allows for much better development and troubleshooting.

So I've made the switch from Blogger to dasBlog for at least a few main reasons:

• dasBlog supports RSS feeds
• dasBlog has better monitoring and reporting features
• dasBlog will ping more RSS aggregators
• dasBlog supports CAPTCHA-protected comments (less comment spam)
• dasBlog has auto trackback
• dasBlog runs on my machine, so I can monkey with it if I want to
• dasBlog has categories, so I can group my posts for users' benefit. Useful for people who blog about a lot of different things.

However, I've noticed that dasBlog isn't as good as Blogger for search engines. For example:

• dasBlog's links aren't as spider friendly. They have some SEO-friendly (i..e no querystrings) URLs, but they delimit the words with spaces instead of dashes. And not all links are SEO-friendly.
• dasBlog does't have as many links to archived content. It seems like the only content a spider could get to is content from the current month. Older posts are seemingly only accessible via a javascript method call.
• dasBlog has a bunch of crap in the HTML. ASP.NET view state, inline CSS, inline javascript -- just a lot of stuff that is i nthe HTML (especially at the top) that has nothing to do with the content. I know that spiders will ignore a lot of that stuff, but it's still not cool.

I'll be fooling with the HTML in the next few weeks ... get the site all looking the same, improve the SEO aspect. Stay tuned for whether it's a success or dismal failure. ;)

Submitted my blog to a few different places, including popdex, technorati, bloguniverse, and yahoo. The trick with Yahoo is to create a MyYahoo page and add your own RSS feed to it. Then it'll get crawled.

Check out http://www.masternewmedia.org/rss/top55/ for a list of many (many) places to submit your RSS feeds. I made it to number 95 before I got tired. ;) Also, http://www.blog-connection.com/submit-blogs.htm is another smaller blog submission list.

So far I'm pretty happy with dasBlog, although it could use a few improvements. And obviously I need to update the design. But anyhow.

Some links to old posts so they stay alive until I can transfer them over:

 

September 2004   October 2004   November 2004   December 2004   January 2005   February 2005   March 2005   April 2005   May 2005  

Previously (like 5 minutes ago) I blogged about HTTPLook. That review was written a few months ago & copied over to my new blog (here).

So, recently I came across Fiddler, a free utility made by Microsoft (or an MS employee with some free time). It actually acts as an HTTP proxy that your browsers run through, and it displays all the HTTP calls in its main window as seen below:

Click for full image

One of the things I like about it is it's quite stable. We had problems with HTTPLook "corrupting" our network settings, requiring a reboot to fix. Fiddler runs cleanly, can save the traces to logs for later inspection, and has a host of other features that many people would never use. We usually use it for debugging missing HTML components (i.e. a javascript or image file might be missing from an HTML page, yet the error isn't visible by inspection), or debugging web service calls (i.e. from .NET winforms applications or Flash apps). But Fiddler also has an interesting guide to performance tuning using HTTP sniffers. Might be worth checking out.

So, if you need an HTTP sniffer on Windows and are cheap, check out Fiddler. You just might like it.

Application: HTTPLook
Vendor: BinaryAge Software
Home Page: www.httpsniffer.com
Price: $29.95
Rating: 9/10
Pros: Cheap, lots of features, easy to use, works with any browser or application that makes HTTP calls
Cons: Plain-looking, not free, missing a few higher-end features

If you're working on an application that makes a bunch of HTTP calls (a spider, a data-driven Flash application, a web browser, a browser plugin, etc.), there aren't a lot of easy ways to monitor the calls. Yes, you can step through the code in debug mode, but that's problematic when debugging production installs. Not to mention slow and overkill. You can also look at the web logs, but sometimes you don't have access to those, or you have to wade through thousands of lines. You could write a call-logging mechanism, but that takes time & might have bugs of its own. What you need is an easy way to log & view all the HTTP calls that a machine is making. Enter BinaryAge Software's HTTPLook.

We have a data-driven flash application on a number of our sites. It calls web services, retrieves XML, downloads images, and hits "pixels" for traffic reporting purposes. But sometimes it would hang, or fail to load an image, or fail to poke a pixel, & it would be a PITA to see what it was doing & which calls were broken. With HTTPLook, you simple load up the application, click "Start", and start surfing/using your app. HTTPLook records the HTTP calls as you make them. It lists the outbound requests & the returns. Status code, cookie settings, headers, bodies, all there. Plus you can filter results, save logs, etc. Here's a screenshot:


Click for bigger view

More screenshots are here.

Now when we have problems, we can quickly pinpoint the troubled URL. We can easily inspect the XML being returned from the web services to see if there's errant data. We can see if there are any missing images by looking for "404" return statuses. Our debugging time & troubleshooting time was cut down to less than 10% of what it was. But the best part is that it's under $30, compared to several hundred dollars for competing products I found. And there's a free trial, too.

I don't mean to pimp this app too hard. I don't get any kind of referral fee, nor do I have anything to do with the company. I was just happy to find an inexpensive app that filled a niche & saved us a ton of time, and I thought others might appreciate the tip, too.

Now, I should mention that if you have to have a free solution, you could use Ethereal, a free network analyzer. But installing it, setting it up, configuring the filters, etc. isn't nearly as easy as HTTPLook. If you have the time, enjoy jumping through hoops, and don't have thirty bucks to burn, try out Ethereal. But be sure to also install the trial version of HTTPLook, too -- after a little while you might decide $30 isn't too much to pay for a no-frills app that does exactly what it's meant to do.

While doing some research for a coding standards document, I found a big wiki discussion on the pros & cons of Hungarian Notation. I started out programming with Pascal, then C (LPC actually), then C++, then VBA, then javascript, then VB, then C# & VB.NET. Maybe there were some other languages in there, too.

So, I instinctively use Hungarian Notation, yet I'm reading that it's a bad idea. That it only handles basic types, not objects (most of my variables are objects anyhow), that it obfuscates code, that it's "yucky", etc. Seems like Microsoft has gotten away from it in their coding guidelines, too.

Seems like the traditionalists are largely in the pro-HN camp, which makes me think that in 10 years you won't see very much HN at all. Although who knows what code will be like then.

Lastly, I got a kick out of the CodeSmell article. It refers to an experienced coder's ability to look at code & somehow sense that something "could" be wrong with it, without exactly knowing what. Hence the "smell" aspect ... it smells like it could be bad, but you're not as certain as if you could see it, touch it, etc.

Testing out the new blog. http://www.dasblog.net is where you can get the code.