Thursday, November 18, 2010

Development Database Setup

Hello Everyone,

If you're working on an application of any significant complexity, one of the tasks developers must deal with are database set up scripts.  One trend that I've noticed over the years is that projects where developers maintain a set of scripts that setup the databases from scratch tend to go more smoothly.  To be clear, this process includes tearing down any existing database, rebuilding the database to the most recent release version, loading good test data, and finally running all change scripts for the next release.  Though those last two steps can be reversible depending on the project.

Example the first.  I have a system.  Yaay!  I need to make a change to the database.  It's a relatively complex change involving creating a new table including keys and indexes, copying data from an existing table to the new one, and removing columns on the old table. Booo!  After I make all these changes and have the scripts in place, I need to test that I did everything correctly.  On the plus side, I have a thorough rebuild process in place.  I can click a button and the whole system is rebuilt, I find problems and fix them myself and I know without bothering any other developers that the scripts are good.  Yaay!

Example the second.  I have a system.  Yaay!  I need to make a change to the database.  It's a relatively complex... yada yada yada... I need to test that I did everything correctly  Booo! Unfortunately, databases are not torn down and rebuilt as part of the setup process, they are only modified.  What do I do to easily test my script.  I can undo the changes by hand and rerun the scripts to make sure, or I can check in the changes, hope for the best and let the next developer find any problems and repeat the cycle with yet another developer.  Which one do you think ends up happening more often?  Booo!

This may not be a huge issue that comes up a lot, but when I see emails going out a few times a month with issues lasting a couple of days because things are done the latter, it reminds me of how many things that developers already need to keep track of and this is just another disturbance.  In the end the amount of work to make the changes is the same, but having a complete rebuild is a way to minimize disturbances and keep developers developing.  

If starting a new project, I highly recommend the complete rebuild approach because the hardest possible task would be overcoming momentum and switching from one process to the other.

Saturday, August 28, 2010

Time to Leave Sprint?

Not many people are fans of their cell phone companies lately. Most people I know are getting upset at AT&T. Their phones, mostly iPhones, are dropping their calls left and right. Verizon's customer service doesn't seem to be up to par. And Sprint, that's the one I get to complain about, I'm getting more and more upset with their phones.

I just picked up an EVO 4G. On the surface, this is a great phone. Easy to set up and use every app I've tried so far. I then noticed that there's a bunch of apps that come prepackaged on the phone that I just have no interest in. NASCAR? What's that? Voice mail? I want to use Google Voice thanks much. Uninstall prepackaged apps? Good luck.

Yes there are people on the web that say they have done it. I tend to believe them as there are videos documenting the process. But it is a process that is not for the computer illiterate; sometimes consisting of multiple updates, flashes, backups and recoveries. And in my case, while I'm not afraid of linux or ADB, all of the instructions I have found simply end with my phone displaying a disheartening message of "Update Fail!"

One post on the web asked the question, "Whose phone is this?" We probably all agreed that the phones weren't ours when we signed those contracts to indicate that we had read said contracts even though in my case the sheaf of papers was barely on the counter long enough for me to dot the 'i' in my last name. Even if that is the case, shouldn't the phone feel like it belongs to me? If it doesn't, why would I want to use it? Meh, I'll probably forget about it eventually... until I go looking to use a nearby app... and remember all the folks that were able to remove that app... and then their phones got faster... and had longer battery life... grumble grumble... damn Sprint...

I suppose all the phone companies are being forced, at gun point of course, to cut corners somewhere to be competitive. In the case of Sprint, apparently that means selling those corner seats out to advertisers. I suppose it did get me talking about NASCAR... Ah well, might as well get in the spirit. "Make that telco your bitch Ricky Bobby!"

Thursday, June 17, 2010

IQueryable and Repositories

One approach for coding repositories that I have seen a couple of times recently is that of exposing IQueryable collections through the repository interfaces. On the one hand this allows an extremely convenient way of exposing a flexible data source to your business layer or controllers. However, it also breaks the Single Responsibility Principle thus creating less reusable and testable solutions.

By allowing your business layer to define queries within its own methods, those methods are taking on two responsibilities, performing data access and performing logic on the results of that data operation. It's all well and good to complain about not hitting some high ideal, but what affect does this have in the real world?

First, if you happen to reuse the same data query in multiple parts of your application, you would have multiple places that you would then need to make changes and test. DRY this isn't.

Second is the testability of this code. In the terms of this afore mentioned white paper, you would need to write your tests for your business layer or controller in such a way that the state is correct as well as the interactions, for each method. As the paper says, testing the state aspect requires a larger set of data. Why would you want to write that extra code for every method in your business layer / controller that uses the same query? If you don't test each one, how do you know they work? How do you know when they break?

The simple solution is to keep your queries in the repositories behind the repository interfaces. Test the state of each one thoroughly and then you only need to test the interactions in your business layer. Yes it requires an extra function call in your business layer, another method in your repository interface and another function declaration in the repository. And while that might be a lot of words, it's only four or five more lines of code for each query (including brackets on their own line in C#.) And if you reuse your queries, you get those extra lines back anyway.

I will certainly concede that no one paradigm fits all of the software problems out there. Maybe what I suggest is overkill. Maybe it's another example of a programmer too set in his ways. But by exposing IQueryable collections through the repository interface, we're ignoring a number of the principles of coding that have been making our lives easier and our code better for a while now.

After a second read through of the article, K. specifically states that enumerables could be returned instead of queryables. Not that this is the only publication I have read where queryables were suggested. Let's just say that now all four of my regular readers know where I stand on the subject.


This white paper by K. Scott Allen is a great read and was my formal introduction to the Unit-Of-Work concept.

For a while, the recommended approach for providing data contexts was to create the context and store it in a session of some sort. Each call to your server would provide a single data context for all of the logic needed to render a new page or perform some sort of data operation.

UnitOfWork might not be a name that explains exactly what the object is (a data context container). But, it does describe what the object does. It frames a the data context within a single logical unit of work. The distinction being that it may take many logical routines to render a single web page.

One advantage to the technique is that you are committing data changes at the end of each logical routine. This means that many of the data changes for that routine can all be committed at once using fewer network and database resources over a shorter period of time.

Another advantage is that you are holding the data necessary for each operation in memory for only as long as it is needed. When the operation is done and the data is likely no longer needed, the memory is flushed and reused for other operations.

Lastly (that I'll mention anyway), it separates your data context scope from session scope. The session will likely be different in web, windows and service applications. This means that your session across different applications may comprise a different number of business methods which can have unforeseen affects on performance and functionality. Instead, you can tie the scope of your data context to each business method as those make good candidates for a unit of work. This in turn means that your routines will perform more predictably across different types of applications.

Thursday, June 10, 2010

Backgrounds, Google? Really?

If you got to this post, you're probably wondering how to turn off Google backgrounds. I for one am pretty sure that if there isn't already a setting, there will be one shortly. I can't be the only person that want's my plain white, pleasant and unobtrusive background back. I'm also far too lazy to go look for that setting given that a link to it doesn't exist on the front page.

That being the case, I created some 800 x 600 solid color backgrounds and uploaded them to Picasa. 800 x 600 by the way is the minimum resolution that can be used. Yes, I do like the fact that Google is hosting my solution to my Google problem.
Download early, download often. Here's the links:
I recommend the dark gray though the white does give a good 'White Album' feel. Obviously, you can also easily create your own image using MS Paint or any simple image editor if you prefer, say, color. Click on the 'Change background image' link in the lower left hand of the Google front page and upload the file from your computer.

Fine, this didn't take much imagination or skill. But I was so dumbstruck when I saw the page, it was all I could do to listen to various suggestions from coworkers.

In retrospect, this may have just been really good marketing. Google did seem to have a fix in place fairly quickly. I'm sure ours wasn't the only office where the new background had everyone talking for a few minutes. And who knows how many bloggers out there were duped into creating buzz about it.