The world of personal finance software is one of my least favorite. Anyone developing in this market has a tough job. People are idiots, and personal finance itself is especially designed to cleverly imitate real accounting yet completely fail to make any logical sense at all.
So I am never surprised at the crazy junk I see in personal finance software. The system it targets is moronic in the extreme, and the target user is assumed to equal that standard.
But I'm a special idiot... one that uses Microsoft Money. I have tried Quicken, but I find their junk just a tad more annoying than MS Money but for different reasons. I also detest Qicken's license terms and marketing strategies. In contrast, Microsoft's lack of strategy in the personal finance market is quite refreshing. So I keep using MS Money even though I hate it.
The most annoying thing about MS Money is that they somehow makes it mandatory to upgrade to the new version every year. Somehow the old version just ends up "breaking" over time until you eventually get pissed enough to upgrade. I have no idea how they manage this, but eventually my old copy just sorta stops working right. Last time it was the fact that it wouldn't work after a patch for IE came out (and no fix available for the old version naturally). This time it just stopped being able to talk to my bank one day.
Every time I upgrade, I end up being amazed at how little was actually improved, or even changed from the previous version and equally amazed at just how many annoying "features" are still exactly as annoying as before. There always seem to be a couple of things I really like that manage to disappear from each version, and one or two new features show up that I don't care about at all. So each time I curse myself for forking over yet another $50 instead of just taking the time to put together my own spreadsheet in Excel... but I still I upgrade anyway.
Among my biggest complaints is the default "basic" checking account register. It completely lacks seriously important features, features I'd consider quite "basic"... like the fact that it is missing the entire right-click menu and has no obvious alternatives for useful things like creating a reoccurring bill from an entry in the register, or marking transaction as reconciled, etc. It is also not obvious that you are even in a "basic" mode, nor that there an "advanced" mode that you could be using instead. Sure, there is a "Basic Register" icon, complete with text label at the top of the page, but it blends in so well that I never even noticed it until someone pointed it out to me. The "basic" mode just make the application feel like a piece of crap that doesn't do much of anything.
Fortunately, I do know about advanced mode, despite not having noticed the icon. I know this because I had used older versions where the advanced features were enabled by default. When I first upgraded to a version with the "basic" register and saw that those features had gone missing, I located how to enable them again via the online help. But the "advanced" register isn't exactly "advanced". It just adds a few minor details to the list of transactions, turns on the right-click menu, and that's about it. But getting advanced mode enabled sure does requires an hell of an advanced level of skill. That icon at the top of the page isn't even clickable to toggle the mode! Instead, enabling the advanced register remains something that I have to look up in the online "help" feature each time because it is cleverly hidden deep within the not-so-fun "options" section of the program. Fortunately the online "help" is one of the few really well done parts of the application, and provides clear instructions for how to enable the missing functionality.
Then MS Money has the "basic" bills tracking system as the default too. In a misguided fit of "simplification", the developers of the default bills tracker helpfully allow you to choose to pay a bill using automatic payment (a.k.a. Bill Pay), electronic payment (e-pay), or by writing a check... But they thought that a "direct draft" bill was just too fucking complicated for the "basic" user, so that option isn't available unless you turn on the advanced bill tracking system. It's almost like they missed the fact that nearly every utility company on the planet pushes direct draft payment options like it was high-grade cocaine... Even people like me that prefer a push payment system over a pull payment system often end up with one or two drafts each month. In my case, some of my utilities actually give a discount if you agree to let them draft your payment. But, according to the crack MS Money development team I now know that only "advanced" users would need direct draft as a bill payment option. Thanks guys.
Then you have odd shit. Like the fact that, even in basic mode, MS Money encourages you to track your gross pay, taxes, withholdings, etc. from your paycheck. Most average joe home-users are obviously people that need to track the exact amount of their 401K deductions, but they would never need anything as advanced as fucking direct draft!
Anyway..
I find this "basic" vs. "advanced" thing to be a very obvious sign of poor UI design. After-all, it isn't as if there are THAT many "advanced" things you can do. Seems to be there should be just one account register, and just one bill tracking system. Then, by using good UI design, the software can helpfully arrange commands in a way that isn't confusing. The saddest thing is, the "advanced" register and bill tracking systems are actually quite easy to use once you figure out how to enable them. But most average joe home-users will never even learn that there is an advanced mode at all, much less get it turned on. Instead, most people would just think MS Money sucks and would not bother to use it... and, after asking around, this seems to be exactly what most people really do think.
Monday, November 5, 2007
Thursday, November 1, 2007
asp.net - Web Site vs. Web Application
For more info, see my follow-up article: ASP.NET: web site vs. web application project - Part 2
A few years ago, when I first got a look at asp.net 2.0, it was clear to me that there must have been some serious changes inside the development team at Microsoft. ASP.NET 1.x was a huge leap forward in server side web application frameworks, but it was also geared to an object oriented audience. While it did support direct data access from web pages and everything-in-one-file styles, Visual Studio's use of asp.net encouraged a more tiered design with clean separation of presentation, business, and data access. It also encouraged OO design by making inheritance, namespaces, and assemblies all obvious, simple, and the default way of things.
By the time asp.net 2.0 was coming out, more agile languages were getting all the buzz. PHP was still relevant and Ruby on Rails was shaping up to be the next big contender. By that time Java's JSP, the only other heavy OO platform that still mattered, had fallen flat on its face. So it wasn't exactly a surprise that there was a focus within asp.net 2.0 towards the "less is more" philosophy of quick, dirty, do-what-I-mean design. Codeless databinding, master pages, skins, themes, and configuration driven providers for common stuff like membership, profiles, personalization, etc. were all expected.
But what make several of us step back was the new compilation model and the "project-less" web site... er... project. Aside from being one of the most impossible to name mechanisms, it was also a breaking change in how asp.net was done. The new compilation model threw out the visual studio project file itself, took asp.net back to the "compile-on-the-fly" concept, all but eliminated the use of namespaces within a web site, and radically altered the way UI template and the associated code-behind were arranged.
But for those of us doing serious web frameworks in large or complex environments, the web site model had some serious drawbacks. The biggest for me was having to manually deal with namespaces, which the UI and code designers would fight every step of the way (until you finally gave up and just let it pile up in one big default namespace). The loss of the visual studio project files was also painful, and it lead to an awkward "exclude from project" mechanism where the only way to get Visual Studio to ignore a file was to physically rename it. Large web sites with lots of code suffered horribly in performance because so many helpful visual studio features, like refactoring and the verification compiler had to sift through every file in the project with no guidance from project configuration.
Microsoft seemed to notice the problem, and resurrected the old project model in what they called the "Web Application" Project. This was essentially a retro-fitted clone of the old project model complete with designer generated code files (updated to take advantage of partial classes though). The new project type brought back namespaces, and once again encouraged clean OO design patterns. It also became apparent over a very short time that Microsoft itself would consider the web application model the new "enterprise" project type while the web site project type was more for the beginner and casual developers. For example, Team system's testing, build, and deployment work great with the web application project, but work poorly if at all with web site projects. But the new project type also brought with it the need to compile everything in advance, and used a different mechanism to associate UI and code-behind files that was incompatible with dynamic compilation.
With Visual Studio 2008 Microsoft is keeping both project types. But I think they are missing an opportunity. While the web application project and web site projects both have advantages and disadvantages, there doesn't seem to be a compelling reason for some of the features to be mutually exclusive.
I for one would love to see a hybrid project type. Keep the project file to organize the site and give us a place to put visual studio specific settings. But switch it use the dynamic compilation model from web site projects. Dynamic compilation and xcopy deployment were powerful ideas, and I can't see any reason they can't be used still. The verification compiler can be optimized quite a lot by having access to a project file... exclusions can be dealt with elegantly, and the whole thing can be sped up. For other code though, you could choose to continue to compile to an assembly in advance, or leverage the app_code folder for dynamic compilation, or a combination of both. And of course, keep the namespaces and configurable compiler options.
I'd love to see a web project type that keeps the best of web site and web application projects both. Give me control over the project's structure, namespaces, and compilation but also give me xcopy deployment, dynamic compilation (using my settings), and keep a consistent way of associating an asp.net UI file to its code-behind without requiring the designer generated code file and full compilation.
Oh well, maybe in the next release.
A few years ago, when I first got a look at asp.net 2.0, it was clear to me that there must have been some serious changes inside the development team at Microsoft. ASP.NET 1.x was a huge leap forward in server side web application frameworks, but it was also geared to an object oriented audience. While it did support direct data access from web pages and everything-in-one-file styles, Visual Studio's use of asp.net encouraged a more tiered design with clean separation of presentation, business, and data access. It also encouraged OO design by making inheritance, namespaces, and assemblies all obvious, simple, and the default way of things.
By the time asp.net 2.0 was coming out, more agile languages were getting all the buzz. PHP was still relevant and Ruby on Rails was shaping up to be the next big contender. By that time Java's JSP, the only other heavy OO platform that still mattered, had fallen flat on its face. So it wasn't exactly a surprise that there was a focus within asp.net 2.0 towards the "less is more" philosophy of quick, dirty, do-what-I-mean design. Codeless databinding, master pages, skins, themes, and configuration driven providers for common stuff like membership, profiles, personalization, etc. were all expected.
But what make several of us step back was the new compilation model and the "project-less" web site... er... project. Aside from being one of the most impossible to name mechanisms, it was also a breaking change in how asp.net was done. The new compilation model threw out the visual studio project file itself, took asp.net back to the "compile-on-the-fly" concept, all but eliminated the use of namespaces within a web site, and radically altered the way UI template and the associated code-behind were arranged.
But for those of us doing serious web frameworks in large or complex environments, the web site model had some serious drawbacks. The biggest for me was having to manually deal with namespaces, which the UI and code designers would fight every step of the way (until you finally gave up and just let it pile up in one big default namespace). The loss of the visual studio project files was also painful, and it lead to an awkward "exclude from project" mechanism where the only way to get Visual Studio to ignore a file was to physically rename it. Large web sites with lots of code suffered horribly in performance because so many helpful visual studio features, like refactoring and the verification compiler had to sift through every file in the project with no guidance from project configuration.
Microsoft seemed to notice the problem, and resurrected the old project model in what they called the "Web Application" Project. This was essentially a retro-fitted clone of the old project model complete with designer generated code files (updated to take advantage of partial classes though). The new project type brought back namespaces, and once again encouraged clean OO design patterns. It also became apparent over a very short time that Microsoft itself would consider the web application model the new "enterprise" project type while the web site project type was more for the beginner and casual developers. For example, Team system's testing, build, and deployment work great with the web application project, but work poorly if at all with web site projects. But the new project type also brought with it the need to compile everything in advance, and used a different mechanism to associate UI and code-behind files that was incompatible with dynamic compilation.
With Visual Studio 2008 Microsoft is keeping both project types. But I think they are missing an opportunity. While the web application project and web site projects both have advantages and disadvantages, there doesn't seem to be a compelling reason for some of the features to be mutually exclusive.
I for one would love to see a hybrid project type. Keep the project file to organize the site and give us a place to put visual studio specific settings. But switch it use the dynamic compilation model from web site projects. Dynamic compilation and xcopy deployment were powerful ideas, and I can't see any reason they can't be used still. The verification compiler can be optimized quite a lot by having access to a project file... exclusions can be dealt with elegantly, and the whole thing can be sped up. For other code though, you could choose to continue to compile to an assembly in advance, or leverage the app_code folder for dynamic compilation, or a combination of both. And of course, keep the namespaces and configurable compiler options.
I'd love to see a web project type that keeps the best of web site and web application projects both. Give me control over the project's structure, namespaces, and compilation but also give me xcopy deployment, dynamic compilation (using my settings), and keep a consistent way of associating an asp.net UI file to its code-behind without requiring the designer generated code file and full compilation.
Oh well, maybe in the next release.
Monday, October 29, 2007
Weighted Obsolescence: Phone book season
Few things annoy me quite like having phone books delivered to my house. There was a time when the phone book was pretty important --a time when taking a decent sized ad out in the yellow pages was the difference between a successful small business and a fire-sale. But between the internet and 411, phone books are obsolete now.
There are still a small number of people, mostly older ones, that consider this whole internet thing to be a fad. They would still prefer a printed phone book... old habits. But for most people the phone book is just a huge waste of paper. And they must be terribly expensive. Someone has to spend large amounts of time composing the contents, doing the layouts, and overseeing a massive printing and distributing operation. The books have to be printed, and that's a LOT of printing. Then they have to be physically delivered, which must represent a truly staggering cost since each one is bulky, heavy, and has to be shipped individually to a different location. Massive costs, and massive waste. Wouldn't it be better to just charge a nominal fee to people that WANT a printed phone book, and just not bother the rest of us?Despite the irrelevance of phone books though, there is an active war in the business between several different companies. Each of them has, for reasons that still elude me, decided that the phone company isn't qualified to maintain and distribute the directory of phone numbers. Instead, these motards decided that they could do a better job and that it is their moral imperative to bring competition to the phone book market!
So every year, I get two or three huge bricks of useless paper delivered to my door. Well, more precisely, delivered to some random part of my yard that I probably won't go into for at least four or five months after the phone book has been delivered to it... not actually delivered to the door you know. For reasons even more screwed up than the basic business plan, all of these companies decided that they had to deliver their brand of awesomeness at the same time of year.
So last week I got three massive, but irrelevant phone books littering my yard. Of course, by the time I noticed two of them, they had been sitting there collecting water and bugs for a few days making them even more massive. The water and bugs don't make the book any more useless though, that would be an impossibility given their very nature.
Its bad enough that I have to dispose of these relics of hate, but what REALLY chaps my ass is this... I don't have a phone line. In fact, there is not and NEVER has been a phone line at my address. So WHY do I get three damned phone directories that I wouldn't need even if I did have a phone?
You guys seriously need to talk to Maxxum. At least they put half-naked girls on the cover of the unsolicited, irrelevant crap they drop off at my house.
Saturday, October 13, 2007
Review - BlogEngine 1.2
I’ve put off reviewing BlogEngine until their development team finished up the 1.2 release. Up until now, I've been using incremental versions between the 1.1 and 1.2 release, but those were unstable at best. But now that 1.2 is out, and I’ve deployed two sites on it, I think its time for that review.
BlogEngine is an asp.net 2.0 application. As the name suggests it is for people that want a blog site.
As a blog, BlogEngine is quite good. It provides the expected features: content postings (duh), comments, RSS/ATOM feed(s), archives, tagging, categorization, etc. It has a slew of extras like “gravatars”, content ratings, support for coComment, DZone, KickIt, and del.icio.us. And of course, BlogEngine takes care of pingbacks, trackbacks, custom tracking, endorsement (bLink), etc too. The new version also has multi-author support, comment moderation, and several other nice touches.
In short, it does what a blog should do, and it does most of that very well.
Despite the name though, this is not really an “engine” in the classic software definition of the word. Part of the application could be described as an “engine” but it isn’t well designed for use within other applications. There are two source assemblies, one for the web site itself and the other is a class library. But the class library has some tight coupling and a reliance on the hosting asp.net web context.
The class-library contains the HttpHandlers and HttpModules that the web site uses to process the incoming requests. These don’t seem to really belong in the class library since they have questionable value to other web applications that might want to use the class library and would have no value at all in a non-web application. The class library also contains server controls that provide UI for the web site. Again, these have limited usefulness to other apps that might use the class library, and no use if the app isn’t a web application.
The most useful part of the engine would be the actual blog providers. These are responsible for building entity classes that represent the content of the blog, and persisting the content within a permanent data store. BlogEngine ships with an XML provider and a SQL Server provider. The providers could be useful to a wide variety of applications, but unfortunately there is still a heavy assumption of a web site context within the providers and the entity classes. So, if you wanted to write a windows application to manage content within your blog, these providers and the entity classes will probably not work out too well for you without re-architecting to eliminate the reliance on web context.
Architecturally, I always have reservations when I see the provider design pattern being applied to an entire tier like this. Providers work great when applied to a specific and narrowly defined “service”, but providers used as whole tiers don’t scale very well, they overcomplicate things, and they can make maintenance or later extension much too difficult and cumbersome. Fortnatly BlogEngine's DAL is fairly small, so it doesn't suffer too much from these problems yet.
Having criticized the code, please let me say that the programmers that wrote this code are VERY good. This is not the work of armatures or idiots. The code is clean, neat, and organized. While I dislike how the code was architected, I have to acknowledge the development team’s skill and professionalism too. The code is very well written.
As for the web site itself, it follows a simplistic approach to skinning. The UI code is a mix of asp.net pages, master pages, user controls, and server controls. Quite a lot of the content displayed on the UI is generated by direct method calls with the output directly injected into the HTML. You’ll see a LOT more <%= GetSomeHtmlOutputAndPutItHere() %> type things within the pages than is typical in most asp.net apps. This simplicity gives a lot of freedom in skinning the application, but it also tends to get a little chaotic. The skins resembles php or classic asp apps a little more than I personally like. You’ll have to use existing skins as a guide to build your own skins, and you wont get as much use from Visual Studio designers either.
On the plus side, the skinning is usually a matter of just editing a master page and two user controls within the theme folder. I’ve implemented two sites on BlogEngine now, and with both I found several things that required editing code outside the theme though. And some of those changes were in code within server controls from the class library assembly too. While this is fine with me, it does mean that the site ends of being hard-coded to the one theme I created. This isn't a problem, but it does indicate that the skinning appraoch could still use some work.
Another issue that I’ve not investigated is performance and scalability, but I suspect that this app would have trouble with large amounts of content. I suspect that the XML provider would suffer performance issues much sooner and more severely than the SQL provider would. But performance will be great for most blogs since they don't tend to get that large.
The verdict:
BlogEngine is an asp.net 2.0 application. As the name suggests it is for people that want a blog site.
As a blog, BlogEngine is quite good. It provides the expected features: content postings (duh), comments, RSS/ATOM feed(s), archives, tagging, categorization, etc. It has a slew of extras like “gravatars”, content ratings, support for coComment, DZone, KickIt, and del.icio.us. And of course, BlogEngine takes care of pingbacks, trackbacks, custom tracking, endorsement (bLink), etc too. The new version also has multi-author support, comment moderation, and several other nice touches.
In short, it does what a blog should do, and it does most of that very well.
Despite the name though, this is not really an “engine” in the classic software definition of the word. Part of the application could be described as an “engine” but it isn’t well designed for use within other applications. There are two source assemblies, one for the web site itself and the other is a class library. But the class library has some tight coupling and a reliance on the hosting asp.net web context.
The class-library contains the HttpHandlers and HttpModules that the web site uses to process the incoming requests. These don’t seem to really belong in the class library since they have questionable value to other web applications that might want to use the class library and would have no value at all in a non-web application. The class library also contains server controls that provide UI for the web site. Again, these have limited usefulness to other apps that might use the class library, and no use if the app isn’t a web application.
The most useful part of the engine would be the actual blog providers. These are responsible for building entity classes that represent the content of the blog, and persisting the content within a permanent data store. BlogEngine ships with an XML provider and a SQL Server provider. The providers could be useful to a wide variety of applications, but unfortunately there is still a heavy assumption of a web site context within the providers and the entity classes. So, if you wanted to write a windows application to manage content within your blog, these providers and the entity classes will probably not work out too well for you without re-architecting to eliminate the reliance on web context.
Architecturally, I always have reservations when I see the provider design pattern being applied to an entire tier like this. Providers work great when applied to a specific and narrowly defined “service”, but providers used as whole tiers don’t scale very well, they overcomplicate things, and they can make maintenance or later extension much too difficult and cumbersome. Fortnatly BlogEngine's DAL is fairly small, so it doesn't suffer too much from these problems yet.
Having criticized the code, please let me say that the programmers that wrote this code are VERY good. This is not the work of armatures or idiots. The code is clean, neat, and organized. While I dislike how the code was architected, I have to acknowledge the development team’s skill and professionalism too. The code is very well written.
As for the web site itself, it follows a simplistic approach to skinning. The UI code is a mix of asp.net pages, master pages, user controls, and server controls. Quite a lot of the content displayed on the UI is generated by direct method calls with the output directly injected into the HTML. You’ll see a LOT more <%= GetSomeHtmlOutputAndPutItHere() %> type things within the pages than is typical in most asp.net apps. This simplicity gives a lot of freedom in skinning the application, but it also tends to get a little chaotic. The skins resembles php or classic asp apps a little more than I personally like. You’ll have to use existing skins as a guide to build your own skins, and you wont get as much use from Visual Studio designers either.
On the plus side, the skinning is usually a matter of just editing a master page and two user controls within the theme folder. I’ve implemented two sites on BlogEngine now, and with both I found several things that required editing code outside the theme though. And some of those changes were in code within server controls from the class library assembly too. While this is fine with me, it does mean that the site ends of being hard-coded to the one theme I created. This isn't a problem, but it does indicate that the skinning appraoch could still use some work.
Another issue that I’ve not investigated is performance and scalability, but I suspect that this app would have trouble with large amounts of content. I suspect that the XML provider would suffer performance issues much sooner and more severely than the SQL provider would. But performance will be great for most blogs since they don't tend to get that large.
The verdict:
- If you want a good personal blog, and want to host it on your own server or web hosting account, then BlogEngine is a good choice. It will provides all the functionality you’d need and a few good extras too. It will not be too difficult to create a custom theme for your site as long as you are good with HTML/CSS and are somewhat familiar with asp.net.
- If you want code that you can use in your own application to help you with blog or blog-like functionality, then move along. Also, if you need multiple blogs hosted within one web site or have a high-volume blog, then BlogEngine is probably not for you.
Friday, August 17, 2007
Stupid Crusade - Block Firefox to protect your revenue!
Seems someone out there really thinks that a browser that blocks ads is theft. So they've outright blocked all Mozilla Firefox browsers and are advocating others do the same.
http://whyfirefoxisblocked.com/
Never mind that ad-blocking is available for just about any browser, and most Mozilla users are savvy enough to work around being blocked... what boggles my mind is how these people think that blocking an entire browser will increase their ad revenue?
Of course, it seems clear that message is intended to drag the users into the politics of the issue, and is not an honest attempt to increase ad revenue. Sadly for them though, most users that see this message are going to be solidly on the other side of the argument... and pissed for being blocked!
Way to gain sympathy there guys!
Software that blocks all advertisement is an infringement of the rights of web site owners and developers. Numerous web sites exist in order to provide quality content in exchange for displaying ads. Accessing the content while blocking the ads, therefore would be no less than stealing.Their message gets richer too... so check out the entire thing:
http://whyfirefoxisblocked.com/
Never mind that ad-blocking is available for just about any browser, and most Mozilla users are savvy enough to work around being blocked... what boggles my mind is how these people think that blocking an entire browser will increase their ad revenue?
Of course, it seems clear that message is intended to drag the users into the politics of the issue, and is not an honest attempt to increase ad revenue. Sadly for them though, most users that see this message are going to be solidly on the other side of the argument... and pissed for being blocked!
Way to gain sympathy there guys!
GetOffMyCase!
One of those tired old arguments you see crop up again and again among programmers is that of case sensitivity in programming languages. The general trend currently seems to be that most are advocating a move towards case insensitive languages. These people tend to call case sensitivity a legacy of the “old” days. They then go on to cite that modern compilers have long been able to save us from the case sensitive buggy-man. Perversely the popularity of case sensitive languages seems to be rising while popularity of case insensitive ones is falling... and no, I have no empirical evidence of this, just something that seems true based on my own observations over many years in the field.
The arguments against case sensitivity range a bit, but one common complaint is that mistakes in case cause hard to detect errors or lead to having two different functions whose name differs only in capitalization. Another common complaint is that comparing strings or working with things that are strings in case sensitive languages often leads to bad behavior, especially when dealing with file paths or URLs where the underlying platform is not case sensitive but the language itself is.
Look, I’ll grant a couple of things:
Once you understand the conventions of the language you can usually tell a LOT about what is going on in code just by observing which case is being used.
For example, Identifiers in C# are camel cased when they are local variables, private fields or method parameters. Pascal case is used for public members, class names, etc. The use of Case to distinguish meaning in C# is generally very consistent from one developer to another. The adherence to good naming conventions is partially due to the case sensitivity of the language itself, and is not a work around in spite of case sensitivity.
When I see something called myName in C# I KNOW I’m dealing with a local variable or private member. When I see MyName I know I’m dealing with a public member.
This is NOT confusing to me or most C# developers. On the contrary, it is quite elegant and we get used to noticing the case of identifiers, and the case used tells us instantly something useful about the code.
But when I deal with VB code, I have to play guessing games when I see myName1 and myName2. Sure, conventions help some there too, but the conventions always feel like sloppy workarounds where the sole purpose is to support case insensitivity.
Of course, most of this relies on a decent understanding of the conventions of the language and the programmer being competent enough to follow those conventions. I’ve been working in C# for many years and I’ve never had serious problems with case induced errors. Sure, occasionally I have made a case related error, but I can’t say that this happens more often than the mistakes I’ve made in VB due to inconsistent and awkward naming. In both languages those kinds of mistakes usually get caught by the compiler or the IDE quickly.
Case sensitive languages have another side effect though, and in my mind this is THE most important thing. Case sensitivity makes programmers pay attention to detail. This may seem like a very simple thing, but attention to details is THE skill that I’ve discovered marks the difference between a decent programmer and a great one.
The arguments against case sensitivity range a bit, but one common complaint is that mistakes in case cause hard to detect errors or lead to having two different functions whose name differs only in capitalization. Another common complaint is that comparing strings or working with things that are strings in case sensitive languages often leads to bad behavior, especially when dealing with file paths or URLs where the underlying platform is not case sensitive but the language itself is.
Look, I’ll grant a couple of things:
- Scripting languages or any language that makes heavy use of late binding should avoid being case sensitive. JavaScript in particular would be a LOT better if it were not case sensitive. In fact, JavaScript is what I like to call a case-destructive language.
- String comparisons in ANY language should, by default, use case insensitive comparisons unless explicitly told otherwise. Most languages provide a mechanism to perform case sensitive or insensitive comparisons, but most C based languages default to doing a case sensitive match. Even C# (my language of choice) is guilty of this.
Once you understand the conventions of the language you can usually tell a LOT about what is going on in code just by observing which case is being used.
For example, Identifiers in C# are camel cased when they are local variables, private fields or method parameters. Pascal case is used for public members, class names, etc. The use of Case to distinguish meaning in C# is generally very consistent from one developer to another. The adherence to good naming conventions is partially due to the case sensitivity of the language itself, and is not a work around in spite of case sensitivity.
When I see something called myName in C# I KNOW I’m dealing with a local variable or private member. When I see MyName I know I’m dealing with a public member.
This is NOT confusing to me or most C# developers. On the contrary, it is quite elegant and we get used to noticing the case of identifiers, and the case used tells us instantly something useful about the code.
But when I deal with VB code, I have to play guessing games when I see myName1 and myName2. Sure, conventions help some there too, but the conventions always feel like sloppy workarounds where the sole purpose is to support case insensitivity.
Of course, most of this relies on a decent understanding of the conventions of the language and the programmer being competent enough to follow those conventions. I’ve been working in C# for many years and I’ve never had serious problems with case induced errors. Sure, occasionally I have made a case related error, but I can’t say that this happens more often than the mistakes I’ve made in VB due to inconsistent and awkward naming. In both languages those kinds of mistakes usually get caught by the compiler or the IDE quickly.
Case sensitive languages have another side effect though, and in my mind this is THE most important thing. Case sensitivity makes programmers pay attention to detail. This may seem like a very simple thing, but attention to details is THE skill that I’ve discovered marks the difference between a decent programmer and a great one.
Wednesday, August 15, 2007
Local Coffee Shops Suck - Go Starbucks!
I have many friends and acquaintances that "hate Starbucks". Hating Starbucks might even be more popular than hating Paris Hilton.
They all have their pet complains, usually about some isolated unfair trade practices or injustice carried out by some mid-level area manager or something. The argument always trends to wrap up with how local coffee shops suffer when Starbucks comes to town (the Wal-Mart argument).
But the sad fact of it is that any company that size will have ass-hats that occasionally do bad things. I try not to hold that against a company unless that kind of behavior becomes the executive policy of the company as a whole (which is why I don't hate Wal-Mart or Starbucks but do hate Disney and Apple).
Anyway...
Let me tell you why Starbucks kicks ass... aside from the fact that they actually serve a decent enough cup of coffee.
The reason Starbucks kicks ass is because they understand this that you can't stir a 20oz cup of hot liquid with a fucking 4 inch tall plastic stick!
Starbucks has big sticks that fit down into the cup all the way to the bottom without burning your fingers! Out of dozens of local shops I've been to in dozens of towns, maybe one or two have had sticks that are appropriate for their larger size cups.
You'd think that if your fucking business IS coffee, then you'd take the time to notice that 4 inches of stick does NOT-the-fuck fit into 10 inches of cup!
How god-damned hard is it to understand ?!?!
See, Starbucks pays attention to those little details.
They provide this level of service in EVERY store.
So... I don't have to wonder if I'll have a way to stir my shit when I get to Starbucks because ALL of their shops have good sticks.
I don't have to wonder if I'll be stuck trying to open half a dozen tiny little packets of sugar (which is always messy) because Starbucks has both packets AND a free-pour canister of sugar on the counter (I know... almost unbelievable!)
That is why Starbucks is killing your local coffee shop.
They all have their pet complains, usually about some isolated unfair trade practices or injustice carried out by some mid-level area manager or something. The argument always trends to wrap up with how local coffee shops suffer when Starbucks comes to town (the Wal-Mart argument).
But the sad fact of it is that any company that size will have ass-hats that occasionally do bad things. I try not to hold that against a company unless that kind of behavior becomes the executive policy of the company as a whole (which is why I don't hate Wal-Mart or Starbucks but do hate Disney and Apple).
Anyway...
Let me tell you why Starbucks kicks ass... aside from the fact that they actually serve a decent enough cup of coffee.
The reason Starbucks kicks ass is because they understand this that you can't stir a 20oz cup of hot liquid with a fucking 4 inch tall plastic stick!
Starbucks has big sticks that fit down into the cup all the way to the bottom without burning your fingers! Out of dozens of local shops I've been to in dozens of towns, maybe one or two have had sticks that are appropriate for their larger size cups.
You'd think that if your fucking business IS coffee, then you'd take the time to notice that 4 inches of stick does NOT-the-fuck fit into 10 inches of cup!
How god-damned hard is it to understand ?!?!
See, Starbucks pays attention to those little details.
They provide this level of service in EVERY store.
So... I don't have to wonder if I'll have a way to stir my shit when I get to Starbucks because ALL of their shops have good sticks.
I don't have to wonder if I'll be stuck trying to open half a dozen tiny little packets of sugar (which is always messy) because Starbucks has both packets AND a free-pour canister of sugar on the counter (I know... almost unbelievable!)
That is why Starbucks is killing your local coffee shop.
Subscribe to:
Posts (Atom)