Joseph Bulger IV

I’ve discovered a product that I really enjoy using and thought I would share it.  It’s called Balsamiq Mockups and it’s a tool that you can use online or on your computer for drawing up quick ideas on software systems.  They use a sketchy kind of font to give you that “drawing out a spec” feel.  What really makes the product so appealing is how fast you can build up a simple mock to show to your team.  I’m literally able to sit down at my computer and within 5 minutes have a meaningful mockup of some kind of feature I want to convey.  Really powerful stuff.

Here’s an example of the kind of thing you can build with it.

Balsamiq Demo

I’ve been unexpectedly suprised by the longevity of my BlackBerry Curve.  I’m coming up on my 2 year mark, and it’s still operating the same as it was when I bought it.  I think that’s the first phone I’ve had that I can say that of.  That’s also not for lack of use, either.  I’ve really beat the heck out of this phone.  The only issue I’ve come across is the ball will get sticky every now and then and it won’t respond to movement.  There’s a simple remedy, though.  All you have to do is move around the ball with a damp cloth.  After you’ve done that for a bit, let it dry and you should be able to use the ball again.  I’ve had to do this about 4 times, because my son, Isaac, get’s a hold of the thing and get’s some funk on it.

All in all, very pleased with my BlackBerry.

I’ve been having a lot of problems with my coding lately. I primarily program in C#, but I originally came from a C++ world. When I first learned Java, and was introduced to the idea of Single Inheritance, the sales pitch made a lot of sense to me. How can any class really derive from multiple classes? I drank the kool-aid, and I’ve been living in a Single Inheritance world ever since.

Now, the caveat to all of this was that you had this thing called an interface that actually allowed you to define declarations of behavior that could later be implemented. This could be done any number of times. This also made a lot of sense, and they would do some simplistic model that illustrates the concept. I imagine for purposes of this article we should probably illustrate something as well just to drive home the point. Let’s say you have a Coin. A Coin is a kind of Currency. So the simple inheritance chain would dictate that Coin inherits from Currency, and everything is fine. Of course, in order for this to matter at all, there needs to be some benefit to having Coin inherit from Currency. So let’s say that Currency has some behavior called CalculateBuyingPower that actually figures out what kind of buying power that particular Currency has. Ok, so now we have an inheritance chain, and we have a direct benefit, figuring out the buying power of the Coin.

If that’s as far as you take it, then everything’s all fine and dandy, and Single Inheritance is great. The problem is, that in the Real World, what we call Objects can legitimately “be” multiple things. This is equally true in the Software World. So, going back to the Coin, not only is the Coin a Currency, but the Coin is also a MetalConstruct. A MetalConstruct is just my way of saying something that is made of metal. Why do I care? Simple. At some point during the life of a Coin, it is entirely possible that the buying power of the Coin will reach a point that it would actually be better to melt down the Coin because the value of the Metal in the coin is much higher (look at what a penny is made of nowadays and you’ll see what I mean). Now, a lot of you are going to say, “That’s fine, just define a MetalConstruct interface and you should be good to go.” In a lot of cases that might be true, but in this example we fine a very big problem. The point of the MetalConstruct is to normalize the behavior of melting down the Coin. No matter what kind of MetalConstruct you have, the melting process for it is always going to be the same. Sure there are variations in melting temperature and what not, but the overall process is the same. The point being, that an interface can only declare that behavior MeltDown should exist, but not define the implementation of it. This is the problem with Single Inheritance. I now need a way for the Coin to be both a Currency and MetalConstruct, which provides the Coin with behaviors CalculateBuyingPower and MeltDown. Coin shouldn’t have to define how to do either of those behaviors, because that’s not it’s responsibility.

During software development, when you’re working on defining your domain, this can come up quite often, actually. With the advent of extension methods in .NET, you’re able to ease the pain a bit in C#, but the fundamental problem is really still there. What I would like to see would be one of two things. It would be nice if you could inherit from multiple abstract classes, which would allow you to define Contracts at the abstract class level. Another idea would be to bring forward the construct of a contract as a first-class citizen, it would be similar to an abstract class and an interface in the sense that you could not create one directly, but would allow for definition of behavior while still being able to have a class implement numerous contracts. It would be a totally new way of defining an object, apart from class, struct, or interface entirely perhaps.

So now I’m looking back at C++ and I’m thinking it would be really nice if I had Multiple Inheritance so I can just get past this ridiculous wall I’m having to climb. Possibly with .NET 4.0, Microsoft is bringing forth the idea of Code Contracts , which might help when you’re trying to get around Single Inheritance issues when dealing with Design by Contract, but for real domain model issues, I think the problem still remains.

Food for thought.

I’ve come across this many times when building sites for clients.  ASP.NET is really great for building dynamic content pages, but not so great when you’re trying to expose those dynamic pages to a crawler or bot used by search engines.  Usually I’ve found myself having to index the crawler or bot to go find specific pages if I wanted something to show up explicitly.  For instance, you might have a product that you really want to showcase and have searchable.  The product’s URL, however might be parameter based, something like http://www.yourstore.com/productdetails.aspx?productid=5.

 Here are 5 common mistakes you should avoid when building sites that need to be Search Engine Optimized (SEO).

1. Overuse of Button Controls

The Button and LinkButton controls are handy for running server-side logic when a link or push button is clicked, but keep in mind that search engines can’t follow these links. These controls cause a postback via Javascript code that search engines are unable to execute.  I’ve seen more than one developer who’s standard method of linking from one page to another was to drag a LinkButton control onto the page and then place a Response.Redirect in the event handler, making the entire site completely uncrawlable by search engines.

2. Duplicate Page Titles

With any dynamically generated site, it can be difficult to generate unique page titles for each and every page, but it really is important.  If you have a quality site, then the search engines are working hard to drive traffic to your site.  After all, that is their core business – to provide links to the best resources on whatever the searcher is looking for. 

So you need to make it easy for the search engines to figure out exactly what your pages are about, and the page title is an important part of that.  Not only that, but once the search engine does rank your page highly, the title is the primary text that searchers will be seeing and using to determine whether to click on your listing or not!  

3. Duplicate Meta Descriptions

Much like the duplicate page title issue, the meta description tag should not be duplicated across your pages either.  Like the page title, this text is used (although to a lesser extent) by the search engines to determine the content of your page and also appears underneath your title in the search engine listing.  Depending on the number of pages of dynamic content on your site, it might not be practical to add multi-sentence descriptions for every single page.  In this case, simply remove the meta description tag altogether.  The major search engines are pretty good at improvising when the description tag is missing by displaying portions of the page body that match the user’s search keywords instead.

4. State-Dependent Pages

Search engines rely heavily on the idea that every unique page has it’s own unique URL.  That means that if you are basing a page’s content on session variables or viewstate parameters, you are probably going to have problems getting that content indexed.  Once a search engine finds a URL, Google will continue spidering that page, but you can bet that the search engine robot will not navigate through your site again to get there.  So you need to make sure that any content you want indexed by search engines can be accessed by simply opening your browser and typing in the URL of that content.  That means unique URLs for every product in your ecommerce store, ever category in your directory, etc. 

5. Duplicate Content When Rewriting URLs With ASP.NET

When you rewrite a URL, the browser is displaying a keyword-rich URL, but internally the URL of the page being displayed is still the ugly URL with the querystring parameters.  In technical terms, the Request.RawURL value might be something like:

1. http://www.store.com/products/coffee-cup.aspx

but the Request.Url value would still be something like:

1. http://www.store.com/products.aspx?productID=15  

All of that is just fine, but a problem can arise if you have a Button or LinkButton control that posts back on that page.  By default, the button control will post back to the Request.URL value. causing the URL to change after postback.  This can be a problem if some users end up linking to your ‘ugly’ URLs, because the search engines will find that link and spider it.  To the search engine the two different URLs signify two different pages and both will be indexed seperately, causing a pretty ugly duplicate content problem.  

 The original article that I read this from was on this blog