Chris Cyvas

Jeff Atwood has stated “Nobody Cares What Your Code Looks Like“. If you read through the post and the comments you see a trend in the responses that appears to assume elegant / well written code and code that serves the end users are exclusive of one another. This really isn’t true at all, but more importantly, posts like this give the impression that they are. People find what they are looking for, but more often than not, we look for what supports what we already know or what we already feel. So, if I am an architect who believes that elegant code is a must, and part of my craft, then I will disagree with Jeff’s point. If I am a manager type who disagrees with my team’s constant demand to refactor, then I will happily reference Jeff’s point. But the challenge is not in picking a side – the real challenge is recognizing that you and your clients deserve both.

I find that the major hurdle in writing good code is not programmer knowledge or detailed specifications or a clearly understood end user -  it’s discipline. As a matter of fact, if you look at a lot of the software engineering initiatives making a lot of noise in the programming world, you’ll notice a trend. RoR and their “Convention over Configuration” mantra, Microsoft’s Guidance Automation Toolkit and Extensions, even Unit Testing to a degree (pick your poison here) – they all strive to enforce (or give you the tools to enforce) an approach to writing code. Coding standards, code reviews – they do it to. They are all attempts at discipline surrogacy.

And there is a reason for this – discipline in programming is hard work. It’s not fun, glamorous, or even remotely engaging. It’s definitely not going to make you a blog superstar.

As a programmer / architect, all of these initiatives should tell us a lot about our craft and where it is currently falling short. Intuit has done a lot of work on PSP/TSP, and I was on one of the architectural teams that went through the program. While it is no silver bullet, it does give you great insight into how you program, what mistakes you make and, most interestingly, that you make the same mistakes over and over again. It was this process that made me realize how important discipline is in coding, and that the most dangerous attitude to have in programming is one of the creative genius. Don’t get me wrong, there is a ton of creativity in programming, especially at the architectural level. The danger lies in falling in love with your creativity and sacrificing your code or user satisfaction to the whims of your ego.

So don’t listen to Jeff, and don’t listen to the creative genius types – focus on discipline.

Hungarian notation is the practice of naming a variable such that it’s name indicates it’s type. For example, intRows tells you that the Rows variable is expected to be an integer. This was very useful for NotePad coder’s, but nowadays, the sophistication of programming IDE’s has made the practice largely obsolete. But I can tell you one area where Hungarian Notation still makes a ton of sense, and that is in the UI. Especially when dealing with the ASP.NET web controls. Frequently, you will end up with 3+ controls associated with a particular data point. For example, you are collecting First Name in a web form and it is a required field. In this case, you will end up with a minimum of 3 controls associated with that data point. A Label control, a TextbBox control, and a RequiredFieldValidator control. Now, if you follow the advice advocated by the FxCop folks and some other popular books, without correctly identifying the intended audience, you will blindly accept this and then go on your merry way creating cool names for your controls. But what makes perfect sense is to use Hungarian Notation in these scenario’s, which will result in lblFirstName, txtFirstName, and rfvFirstName. In this way, you will always know what to look for and you will have a consistent naming pattern that will follow throughout your application.

Oh, and if anyone ever says “I’m an architect, so the UI doesn’t concern me.” or some approximation thereof, then they aren’t an architect, they’re a glorified component developer swallowing whatever they read. Architects must keep the whole application in mind when designing the application and that includes the UI.

Last time I mentioned the new provider model that will allow for separate assemblies to be used for payment, shipping, and tax providers. While I’m fully involved in writing 3.0, I figured I’d try to go over some of the other changes that are going to make their way into dashCommerce 3.0 and specifically address them relative to community expressed issues and / or bug reports, so here goes . . .

My hosting provider won’t allow me write access to my web.config / How do I grant write access to my web.config?

Most of the configuration – at least all the configuration you would want to change at runtime – has been moved to the database. That means the configuration for the Payment, Tax, and Shipping Services has all been moved to the database. These are nothing more than persisted serialized objects. In addition, Site Settings are also kept in the database.

Why can’t I run dashCommerce in Medium Trust? / My hosting provider only allows for Medium Trust.

I’ve posted in the forums about this, but in case you missed it, while 3.0 goes a long way in getting closer to Medium Trust, the stick in our back is the whole WebPermission issue. When I originally reviewed this I assumed there would be some way to make an HTTP Post in .NET that would not require the WebPermission security demand. Oh, my oh my was I woefully wrong. But that doesn’t mean I wanted to get sloppy with Medium Trust. I wanted to keep as close as possible to it so that should the WebPermission eventually make it into Medium Trust, we would be right there ready to take advantage of it. So, that means the Enterprise Library stuff is also gone. I have a lot of experience with the EL so I really hmmmed and haawed over this, but in the end, I decided that the cost / benefit was too great. So, logging is being handled by log4net.

Why does dashCommerce have such a US slant? / Why isn’t dashCommerce localizable?

dashCommerce 3.0 will be localizable. The community has been great in stepping forward and offering translations. I’ll be pumping those files out to the voluteers when they are ready. This is no small effort for an application like dashCommerce – it’s been tedious and slow going, but I’m trying to be a good citizen of the world.

When are you going to upgrade Assembly X to the current version?

All of the assemblies are being updated to the latest version that works with .NET 2.0. This includes upgrades to SubSonic 2.0.3, ASP.NET Ajax and the Ajax Control Toolkit, and the previously mentioned log4net.

Please use FCKEditor!

Done. It’s everywhere and anywhere you edit good sized amounts of text.

Please upgrade the project to a Web Application.

Done, and I know I am much happier for it.

I’d like to see better skinning support.

Yep, me to! So, right now, part of your Site Settings configuration is to select the skin used for your dashCommerc installation. This is driven from the App_Themes directory, so just drop a theme in there and the admin side of the application will pick it up and let you apply it. The adminstration side of the application has minimal styling (it’s a very clean look and has been blessed by Brad). You’ll see more of that in the coming screencasts.

Why doesn’t dashCommerce have an upgrade path?

Suffice it to say we were paying for the sins of the past, but 3.0 will release us from those chains significantly, so we will have upgrade packages after 3.0.

There is a ton more, and I’ll be covering more as I go along here, but you should know that dashCommerce 3.0 is a complete re-write of the application. Much of the flow of the application is the same, but the code is different, so there is going to be a learning curve there for everyone. To mitigate that learning curve, I have tried to stay very consistent in the code – meaning I try to handle similar situations similarly. Also, there is, to this point, no inline-coding in the aspx pages, and this is for 2 reasons: 1.) It will should make the VB.NET conversion go a little smoother and 2.) in-line code that contains logic is just another place to go looking for stuff and I hate having to dig.

That’s it for now – I am going to try to crack the nut on screencasts soon – so there’ll be more there for you as well. If there is anything else you think I should be doing to steward this project forward, please let me know.

I use SVNRepository for my Subversion hosting. As a micro-ISV / contractor, I need access to my code wherever I go, so I needed it hosted and I needed it easy. I have an office downtown and I have an office in my house, and being able to periodically work from home or on the road without having my rhythm disrupted was important.  And here is where SVNRepository hits it. They set me up, sent me 1 or 2 emails and that’s it. I never heard from them again. And it’s been lovely. 

I’ve been a fan of passive software for a long time . . . you don’t always have to press a button to do something . . . but I don’t know that I’ve ever experienced a sublime service like SVNRepository before. But it got me thinking about dashCommerce and how to make the software easier to use. I’ve mentioned in the forums that the primary focus of the next release, 3.0, is on removing obstacles. And obstacles take many forms. There are the obvious ones – like requiring write/modify access to the web.config file in order to run the software. People have a hard time with that – either figuring it out, or getting their hosting provider to let them do it. And that, well, that’s an obstacle. So it’s gone.

There are also less obvious obstacles. Control is an obstacle. Coming from a proprietary software background, control is deeply embedded in thought processes around building software. And it’s difficult to let go of those thoughts as you build and develop an open source software package like dashCommerce. But control is, in fact, hurting dashCommerce, so I’ve been taking a hard look at where control can be given up and I think I have come up with something that will benefit everyone.

dashCommerce has 2 primary audiences. The most obvious are developers that use the package to satisfy the requirements of their clients and there are the store owners themselves. In either of these cases, what is most important is getting the site up and running in the fastest possible way. So as I looked at the forum posts, issues list, and my own experience with the product it became pretty clear that control of certain parts of the product may be hurting the product, or, more specifically, may be hurting the users of the product as they try to get their stores up. I receive a lot of requests for different payment providers, shipping providers, and tax providers. The problem I have in writing any of them is that as soon as I add them in to the code base, they immediately come under my control and my responsibility. And when there are issues, bugs or any number of changes that can occur when dealing with third party integrations, they become an obstacle to the successful use of the product.

So how do I propose to fix this? dashCommerce 3.0 will have a plug-in model for payment providers, shipping providers, and tax providers that will not require them to be in the code base. dashCommerce 3.0 is a full Web Application solution, so the payment providers, shipping providers, and tax providers all operate based on their implementation of interfaces, which are subsequently used by the Payment Service, Shipping Service and Tax Service. So, if you are a component developer and you wish to develop particular providers, then you’ll definitely want to check out the provider interfaces. From a developer or store owner perspective, the benefit should come in the form of widely available payment, shipping, and tax providers that will allow you to create the store you or your client want. Obviously, there will be a little ramp up time on getting the providers created, but once the train starts rolling, it should add a lot of flexibility to the product and it should get us out of your way. Removing obstacles . . . adding the dash to dashCommerce