Pat Gannon's blog

We have all written SQL scripts to create a table that has one or more column defaults, as follows:

create table MyTable
(
     myTableId int primary key identity(1,1),
     name varchar(100) not null,
     modifiedOn datetime default(getdate()),
     someOtherDate datetime
)

That works well, but in some cases, you want to add a default after the fact, and you don't want to drop and re-create the table with the new default (because there is data in the table).  I had this situation today so I decided to load up SQL Books Online and see if I could figure out how to write a SQL script to add a default to an existing table.  (I prefer to keep incremental schema change scripts rather than making schema changes in SQL Server Management Studio, or Enterprise Manager in this case, because it makes it easier to keep multiple environments/DBs in sync.)  I would have expected the syntax to be something like this:

alter table MyTable add default df_modifiedOn to someOtherDate 'getdate()'

...but it's nothing of the sort.  The syntax is a bit weird, IMO, and here it is:

create default df_someOtherDate AS 'getdate()'

GO

sp_bindefault df_someOtherDate, 'MyTable.someOtherDate'

GO

I'd be interested to know if there's other syntax out there for accomplishing the same goal in one SQL statement.  (Post a comment!)

That's all folks!

Update: As it turns out, the type of default created by using using "create default" is a different sort of default than the one you get by specifying "default" in a column definition, and the type created by "create default" is only maintained in SQL Server for backwards-compatibility.  (In other words, don't do it unless you absolutely have to.)

I removed the default I created using the above method (using sp_unbindefault and then 'drop default') and then I created a new default by dropping and re-adding the column (so I guess my initial instinct on how to do this was almost correct).

alter table MyTable drop column someOtherDate

GO

alter table MyTable add someOtherDate datetime not null default(getdate())

GO

As it turns out, the data in this particular column is not valuable to me at this point, so dropping and re-adding the column is an acceptable solution.  If you needed to preserve that data, you could dump it into a temporary table before dropping and re-adding, and then dump it back into your regular table from the temporary table.  Is there a simpler way to do this?

I recently listened to Technology Round Table Podcast #3 and one of the topics was 'Should Developers Learn C?'.  In it, Jon Galloway stated that there are much more important things developers could spend their time learning than C (such as learning their core platform in-depth - eg. .NET/SQL Server).  Another voice (perhaps it was Scott Koon?) said that it is necessary for developers to learn about how their code is working 'under the hood' (memory and registers, etc.), and he gave a metaphore that developers who don't know how things are working at that level can only paint your car rather than making more substantive changes.  Although all metaphores break down at some point, I think this is a particularly weak one.  If someone can totally overhaul a system (such as one written in VB or on top of .NET) by making major changes to the code, that amounts to a heck of a lot more (metaphorically speaking) than just re-painting a car, even if they don't know how to interpret assembly or inspect the heap manually if they wind up having an unhandled error in unmanaged code.  (I think a better analogy might be a mechanic who could replace your transmission versus a mechanic who could re-build your transmission.)  Heck, I've taken two classes in assembly (one for x86 chips and one for Motorolla chips) and I normally don't even bother to try to interpret that generated assembly if I somehow get such an error.  I probably could if I had too, but there's normally much more effective ways to debug a problem written in a higher level language than debugging the underlying assembly.  Although I can't say it's NEVER necessary, it hasn't been necessary for me in the 8+ years I've been developing software professionally in high-level languages.

My first reaction to this discussion was to think: Well it's really not enough to just learn C, you really should learn assembly language first to understand things at a REALLY low level (invoking hardware interrupts, etc.), and then learn C.  In reflecting on Jon's take on the issue, however, I realized that perhaps one size does not fit all.  I wonder if people's opinion on this issue really just reflects their own personal background.  I think I was certainly guilty of that in my first analysis of the question.  (I, after all, learned assembly language and C and C++...)  It seems to me now that this boils down to an issue of human nature.  People that attain some degree of success in life commonly are inclined to encourge people to follow in their foot-steps.  In other words, if I perceive myself as successful, then the path to success that I'm most familiar with is probably going to be my own.  So if one never really had to learn C, but one still perceives oneself as successful, then one is probably going to advocate that it's not really necessary for developers to learn C.  If one forged their software knowledge in the fires of assembly and C, however, one is likely to suggest that as much is necessary for developers to learn.

I think the more important question is: 'Who should learn C?' and furthermore 'Who should learn assembly?'  I think the answer lies in what type of software the developer works on, and what direction they would like to take in their career.  As I have previously blogged, I think there will be more distinct career paths within software development as the field matures.  Like in medicine, we will have the equivelent of doctors/MDs (framework developers, language creators, AI specialists, etc.) and the equivelent of nurses/RNs (developers who work on small line-of-business applications and small web apps) and the equivlent of nursing assistants (junior developers, QA testers, etc.).  Based on that belief, I think that the training necessary for a developer who works on embedded systems or large-scale web app frameworks is different than the training necessary for a developer who works on point-of-presence web sites, just as the training for an MD is entirely different than the training for RNs.  MDs need to be able to diagnose rare, mysterious diseases and come up with a customized plan of treatment for a patient who may have multiple conditions, whereas an RN just needs to know how to diagnose and treat common problems, administer medication, talk to families, etc.  Accordingly, MDs have to study the mechanics of the human body in a lot more detail, whereas RNs learn more about 'soft skills' and the like.

Should you learn C (or Erlang or Smalltalk)?  That depends on what you want to do.  If you want to work on massively scalable applications or complex embedded systems, then yes, you probably should learn C and also possibly assembly and/or IL.  If you just want to continue creating line of business applications in VB.NET (which is not to say that you're not improving), then you would probably be better off spending your time on something else that will make you a better developer.  (Do I even need to list the plethora of options?)

I have been reading "The Art of Agile Development" by James Shore and Shane Warden, and I just finished the first section (chapters 1-4).  It is a very lucid and pragmatic guide to practicing XP, and I am anxious to put some of these ideas into action.  I must admit that prior to reading this book, I thought that XP teams iteratively encapsulated requirements in stories, and I didn't really grasp the note card concept.  In actuality, each story is merely a brief representation of a bite-sized unit of functionality (used for release planning and tracking), and the detailed requirements are relayed in real time by the on-site customer, and are not written down.  This is an intriguing concept, but I have a lot of questions about how to apply this on the types of projects I tend to work on.  I am hoping the rest of the book will resolve some of these questions.  In this post I'll compare the advantages and disadvantages of an on-site customer versus a requirements document (iteratively developed or written up front).

There are a few really significant advantages of using an on-site customer (or two or three) on your project.  The first is that the requirements are never out of date.  In a world where businesses are growing and adapting constantly, it is critical that development teams understand and act on the changing requirements of their business with as little lag time as possible.  In short, technical agility enables business agility, and business agility is a big competitive advantage in a dynamic market place.  Furthermore, technical staff (eg. developers) don't waste time writing requirements documents, which are essentially depreciating assets because they become increasingly out-dated over time.  Arguably roughly the same amount of time is spent analyzing requirements over-all, but the time is spent by business stake-holders whose time may be less expensive (because they are employed directly by the client and/or because they are lower-level domain experts with less years of experience than developers in the case of teams large enough to warrant on-site clients in addition to the Product Manager), and whose investment of time analyzing requirements in-depth can be more easily capitalized on by the client organization outside the scope of the current project.  (In-house domain experts are in a good position to recommend process improvements and propose future projects.)  Finally, customers can manage the relative priority of specific features within a story in real-time (like whether or not it's more important to validate a particular piece of data or add a new field, for example), which further enables business agility.

There are some disadvantages of using on-site customers in liu of writing a requirements document, however.  One disadvantage of particular interest to projects on a tight budget is that offshoring is much less feasible.  Sending an on-site customer half-way around the world for an extended period of time is going to prove too difficult and costly for many organizations to consider.  Attempting to provide a virtual on-site customer over the internet is problematic as well due to the drastic time differences usually present between western clients and eastern development teams.  The situation would seem to prove even more complex for mixed project teams that have some developers on-shore and some developers off-shore.  This would seem to require two on-site customers (one for each site) who would probably spend as much time synchronizing with each other as relaying requirements to the development team.  Another disadvantage is that this method of analyzing requirements would seem to be incompatible with fixed bid projects.  Although I tend not to prefer working on fixed bid projects, they are often a fact of life because they reduce the monetary risk to the client, and they offer a "price tag" that is easy for clients to base a purchasing decision on.  When you do a fixed bid project, it is necessary to precisely define the functionality that will be developed for the price offered.  Fixed bid projects put clients and development teams at competing interests; it is in the client's best interest to squeeze every bit of valuable functionality that they can out of the fixed bid project, so in the common case that there is judgement call about what requirements are in-scope and what are not, clients will always strongly air on the side of in-scope.  As such, the more amguity there is in the scope definition, the more work the client will lump into the project they're paying a fixed amount for.  Therefore, a development team must define the scope very precisely in order to stand any chance of having a fixed bid project be profitable (in most situations).  A comprehensive requirements document, while it still may not define scope completely, serves that purpose much better than an on-site client from my perspective.  Finally, in my experience with requirements analysis, when asking business stakeholders about how a particular process should take place, they often realize their process is not as clearly defined as it ought to be, and they must circle the wagons internally in order to clarify the process.  Since that takes time, doing so in the middle of a development effort could cause unexpected delays and thus cause deadlines to be missed (or long hours to be put in at the end of an iteration since clients always seem to think they can provide the answers in the eleventh hour and you ought to be able to automate their process within minutes of their defining that process for you).

In addition to those disadvantages of on-site customers, there are some advantages to writing requirements documents.  First, it allows problem areas to be exposed up-front, so that related functionality can be implemented first and scheduling risks can be mitigated early on, which is benificial in managing client expectations and forecasting project cost/ROI accurately.  This is true of both iteratively developed requirements documents (developed at the beginning of each iteration) as well as requirements documents written entirely up front (but is more true of the latter).  Another related advantage for requirements documents written entirely up-front is that they enable more precise long-term resource allocation for the development of a strategic project by an important deadline like a trade show (because estimates can be made more accurately for a specific set of critical functionality).  Lastly, up-front requirements documents enable system architects to assess appropriate high-level technology choices prior to project inception.  Although emergent design is a great way to establish a flexible and clean architecture for code-based solutions, it seems less effective for leveraging pre-existing tools or frameworks within the application.  For example, if you define requirements iteratively (or even more so if they're defined continuously as with an on-site customer), you may decide to hand-code certain business logic in an early iteration, and then realize in a future iteration that utilizing BizTalk makes sense to enable the functionality in that iteration, so business logic relating to that functionality should be defined within BizTalk.  At that point, you must either have business logic scattered in multiple sources (some in BizTalk, some in "code"), or you need to spend time re-creating the existing business logic in BizTalk and removing it from code.  Similarly, you may send out some simple email notifications manually in an early iteration, and then realize in a later iteration that it makes sense to use the (.NET 3.0) Workflow Framework to conditionally send all notifications in the application, at which point you would need to retro-fit your existing notification functionality, which results in a greater total amount of time needed to implement the notification functionality in this fictional project (because requirements were defined iteratively).

Although I think a lot of projects can benefit from having an on-site customer, there are other project circumstances which demand a traditional requirements document.  Those projects include fixed bid projects, fixed deadline projects, projects utilizing offshore developers and solutions heavily leveraging pre-existing frameworks/middleware/etc.  On-site customers seem to work best in environments meeting the fairly extensive list of pre-requisites to practicing XP on a project: Management Support, Team Agreement, A Colocated Team, (On-Site Customers), The Right Team Size and Use All Practices (Shore: pages 44-49).  Although this list seems prohibitive, the Shore book offers advise about how to change your environment into one that meets the pre-requisites.  Additionally, "advanced XP" can still be applied to environments where one or two pre-requisitves may not be satisfied.  For many projects with a less compatible and flexible environment, writing a requirements document (sometimes even up-front) still makes sense.  I may post about this topic again if the rest of the book impacts my opinions on this topic significantly.

Tuesday, 4/15/2008, meeting at 7:00 PM

O'Reilly Media in Sebastopol

1003-1005 Gravenstein Highway North, Sebastopol
Tarsier Conference Room (between Building B and Building C)
(8 miles west of Santa Rosa)

This is the first post in a new blog post series I'm calling "Get started in 5 minutes".  In this post, I'm going to describe how you can get started using jsUnit to unit test your client-side Javascript code in 5 minutes.  jsUnit is a port of jUnit (a Java unit testing framework) and there is a lot more to jsUnit that I'm not going to get into (you can even test server-side code), but I think this will be enough for many of you to unit test your client-side code.  In doing so, you can pracice Test Driven Development without wincing when your Javascript grows in complexity.

"Either Karate: yes, or Karate: no.  No Karate: maybe so." -Karate Kid

Here are the steps to get started...

1. Download jsUnit (currently jsunit2.2alpha11.zip)

2. Extract the "jsunit" directory in the ZIP file into your web app folder.

3. Create a Javascript library containing the code to be tested.  In this case, call it MyLibrary.js, put it in your web app folder and paste in the following code:

function setName(name)
{
    document.all['name'].value = name;
}

4. Create a test page (similar to a test fixture in NUnit, etc.).  In this case, call it TestMyLibrary, put it in your web app folder and paste in the following code:

<html>
    <head>
        <title>jsUnit test</title>
        <script language="JavaScript" src="jsunit/app/jsUnitCore.js"></script>
        <script language="JavaScript" src="MyLibrary.js"></script>
        <script language="JavaScript">
           
        function testSetName()
        {
            setName('Pat Gannon');
            assert('name field set incorrectly', document.all['name'].value == 'Pat Gannon');
        }
       
        </script>
    </head>
    <body>
        <input name="name" type="text" />
    </body>
</html>

This test page includes the jsUnit library (jsUnitCore.js) which gives us testing functions like "assert".  As with other unit testing frameworks, there are a slew of assert-variants, listed here.

5. Navigate to http://<web app>/jsUnit/testRunner.html (type in the URL to your web app in place of <web app>).
 In the first text field, enter "<web app>/jsUnit_test.html"
 Click the "Run" button

The bar on the page shows green, indicating that the test passed.  (Note that tests are auto-discovered, so the function name must begin with "test".)

Architectural considerations

One thing that strikes me as sub-optimal about jsUnit is that your tests must be DIRECTLY inside your (HTML) test page.  It would be nice if you could specify your test page in one test box (on the test runner page) and specify a Javascript file (which contains the actual tests) in another text box.  The reason this would be handy is that you could specify the actual page that the Javascript will be used in (production code) as your test page without having to embed your Javascript tests in your production web page.  Since that's not possible, here are some potential work-arounds:

A. Maintain a seperate test page from your regular (production) page
The problem with this approach is that if your Javascript depends on certain fields being present (or other UI constraints), then you will wind up needing to repeatedly migrate those fields (etc.) from your regular (production) page to your test page (or vise-versa if you're practicing TDD).  The nice thing about this approach is that it forces you to think about the dependencies of your Javascript code on the HTML page that uses it.  This could be adventageous when you want to re-use that Javascript because the test page provides a minimal template describing the UI elements that must be present in a page for it to use your Javascript library.

B. Include the unit tests in the regular (production) page
This is the most low-maintenance, low-tech solution to the problem.  You don't have to migrate any UI fields or do anything fancy, but your pages will download slower because people that browse to your web page will be downloading your unit test code.  This also might look funny to savvy users who do a 'view source' on your web page (or other developers maintaining your code in the future).

C. Server-side include mechanism
One solution that seems fairly slick to me would be to conditionally include the unit testing code in your regular (production) page using a server-side include that only comes into play when a query string parameter is present, like so:

<% if (Request["UnitTest"] == "true") { %>
 <!-- #Include File="TestMyLibrary.js" -->
<% } %>

I have to admit that I haven't actually tried this approach so I'm not 100% sure it would work, but I'm confident that a solution along these lines would be possible through some mechanism.  This solution would keep maintenance (field migration) to a minimum without affecting download performance.

D. Manual Discovery of unit tests

Another solution that is a little klunky in my opinion would be to force the discovery of unit tests in a seperate Javascript file by declaring a Javascript function called "exposeTestFunctionNames" in your regular (production) page that returns a list of strings, which are the names of each of your test methods.  This solution would require you to include some test-related code (the aforementioned function) in your production code, but it would likely be far less than using solution B.

Decision time

Is there any better solutions that I haven't thought of?  In the application that I'm currently building, the test page has to be seperate from the production web page anyways (the production web pages that use the Javascript we're developing will not be under our control), so option A is a no-brainer for my current situation.  Since this is not a problem for me at the moment, I haven't actually tried to implement any of the aforementioned solutions, but I would be interested to hear how other people solve this problem (as I'm sure other people reading this blog post will be), so please post a comment!

Ooh... Where do we go now? (appologies to Guns N Roses)

Now that you have a basic unit test working with jsUnit, there are a number of resources that you may be interested in to help you kick it up a notch.  This site lists a number of different Javascript tools that relate to unit testing.  The most interesting thing I saw on there was jsmock, which is a mocking framework for Javascript.  There is also JSCoverage, which generates code coverage statistics and JSXUnit which apparently is for unit testing managed JScript code, including code that runs in Silverlight.  Last but certainly not least, you should go read the brief and to-the-point jsUnit documentation.

This is my new, re-hosted blog.  My old blog is at http://blogs.veloc-it.com/pat and you can view old posts there.  I may move that content over to this blog at some point, but there's no easy way to import content from an RSS feed in Subtext, so those posts will continue to live on veloc-it.com until I either decide to implement an RSS import for Subtext or just take the time to copy and paste everything.

Thanks for updating your RSS feed!