Snow Leopard: Days 1-2

Thanks to a pre-order from Amazon on August 3, a copy of Snow Leopard arrived on my doorstep August 28. The install was uneventful–typical of Mac OS X installs. I put in the DVD, clicked through a few dialog boxes, went to run a couple of errands. When I got back, I logged in as usual.

So far, I haven’t noticed many differences between Leopard and Snow Leopard.  The few of note:

  • Hard drive space.  Before installing Snow Leopard, I had around 14GB of free space.  After installing Snow Leopard (and the latest version of XCode) I have 27GB of free space.  It’s quite a bit more freed space than the 7GB Apple advertised
  • Printing.  I have a HP LaserJet 1022.  I had to re-install it after upgrading to Snow Leopard and use an Apple driver.  It still works just fine.
  • Battery Status.  Apple added information on battery health.  Since my MacBook Pro is closing in on 3 years old, the “Service Battery” message is most likely correct.  Apple Support already has a thread about it.  Another thing I’ve noticed which may also be new to Snow Leopard is that I’m getting battery life percentages for my Bluetooth keyboard and mouse as well.
  • Character/Keyboard Viewer.  A new widget in the upper-right of the screen.  I haven’t found any particular use for it yet.
  • Mail.  When I first started it, the app prompted me for some sort of upgrade.  Once it was done, the notes from my iPhone showed up under a Reminders item.
  • Quicken.  I’m still using Quicken 2007 for Mac, so I saw a little prompt about Rosetta when I first launched it.  What I really need to do is get out of Quicken 2007 into something else, but that’s a subject for another post.

I can’t say I’ve noticed any speed differences one way or the other so far–but it’s only been a couple of days.

Random SQL Tricks (Part 2)

In my previous random SQL tricks post, I discussed how to generate random alphanumeric strings of any length.  A slight variation on that idea that also proved useful in generating test data is the following stored procedure (which generates a varchar consisting entirely of numbers):

CREATE PROCEDURE [dbo].[SpGenerateRandomNumberString]
@randomString varchar(15) OUTPUT
AS
BEGIN
SET NOCOUNT ON
DECLARE @counter tinyint
DECLARE @nextChar char(1)
SET @counter = 1
SET @randomString = ”

WHILE @counter <= 15
BEGIN
SELECT @nextChar = CHAR(48 + CONVERT(INT, (57-48+1)*RAND()))

SELECT @randomString = @randomString + @nextChar
SET @counter = @counter + 1
END
END
GO

The range in the select for @nextChar maps to ASCII values for the digits 0-9.  Unlike the stored procedure from my first post, there’s no if statement to determine whether or not the random value retrieved is allowed because the ASCII range for digits is contiguous.  The needs of my application restricted the length of this numeric string to 15 characters.  For more general use, the first refactoring would probably add string length as a second parameter, so the numeric string could be a variable length.

A long overdue upgrade

I’m finally running the latest version of WordPress (I’ve been way behind on upgrading).  I’d be curious to hear from those of you who visit regularly what you think of the new look.  I’d considered a couple others:

I ultimately chose this one for the random post feature that appears in the upper-right of the page.

Build Server Debugging

Early in June, I posted about inheriting a continuous integration setup from a former colleague.  Since then, I’ve replaced CruiseControl.NET and MSTest with TeamCity and NUnit 2.5.1, added FxCop, NCover, and documentation generation (with Doxygen).  This system had been running pretty smoothly, with the exception of an occasional build failure due to SQL execution error.  Initially, I thought the problem was due to the build restoring a database for use by some of our integration tests.  But when replacing the restore command with a script for database creation didn’t fix the problem, I had to look deeper.

A look at the error logs for SQL Server Express 2005 revealed a number of messages that looked like:

SQL Server has encountered <x> occurrence(s) of cachestore flush …

Most of what I found in my initial searches indicated that these could be ignored.  But a bit more googling brought me to this thread of an MSDN SQL Server database forum.  The answer by Tom Huleatt that recommended turning off the Auto-Close property seemed the most appropriate.  After checking in database script changes that included the following:

ALTER DATABASE <database name> SET AUTO_CLOSE OFF

GO

none of the builds have failed due to SQL execution errors.  We’ll see if these results continue.

Random SQL Tricks (Part 1)

One of my most recent tasks at work has been generating test data for integration tests of a new application.  We don’t have the version of Visual Studio which does it for you, and rather than write an app that did it, I spent the past week hunting for examples that just used Transact-SQL.  The initial post that I found the most useful is this one, in which the author provides five different ways of generating random numbers.  I use his third method quite often, as you’ll see in this post (and any others I write on this topic).

One of our needs for random test data was alphanumeric strings of varying lengths.  Because the content of the text mattered less than the need for text, it didn’t have to resemble actual names (or anything recognizable).  The first example I found of a T-SQL stored procedure for generating a random string was in this blog post by XSQL Software.  The script does generate random strings, but they include non-alphanumeric characters.  To get the sort of random strings I wanted, I took the random number generation method from the first post and the stored procedure mentioned earlier and adapted them to this:

CREATE PROCEDURE [dbo].[SpGenerateRandomString]
@sLength tinyint = 10,
@randomString varchar(50) OUTPUT
AS
BEGIN
SET NOCOUNT ON
DECLARE @counter tinyint
DECLARE @nextChar char(1)
SET @counter = 1
SET @randomString = ”

WHILE @counter <= @sLength
BEGIN
SELECT @nextChar = CHAR(48 + CONVERT(INT, (122-48+1)*RAND()))

IF ASCII(@nextChar) not in (58,59,60,61,62,63,64,91,92,93,94,95,96)
BEGIN
SELECT @randomString = @randomString + @nextChar
SET @counter = @counter + 1
END
END
END

The range in the select for @nextChar is the set of ASCII table values that map to digits, upper-case letters, and lower-case letters (among other things).  The “if” branch values in the set are those ASCII table values that map to punctuation, brackets, and other non-alphanumeric characters.  Only alphanumeric characters are added to @randomString as a result.  Having a stored procedure like this one available makes it much easier to generate test data, especially since it can be called from other stored procedures.

Introducing Doxygen

Last Wednesday evening, I gave a presentation on Doxygen at RockNUG.  I didn’t actually bother with slides in order to give as much time as possible to actually demonstrating how the tool worked, so this blog post will fill in some of those gaps.

Doxygen is just one of a number of tools that generate documentation from the comments in source code.  In addition to C# “triple-slash” comments, Doxygen can generate documentation from Java, Python, and PHP source.  In addition to HTML, Doxygen can provide documentation in XML, LaTeX, and RTF formats.

Getting up to speed quickly is pretty easy with Doxywizard.  It will walk you through configuring all the necessary values in wizard or expert mode.  When you save the configuration file it generates, the purpose and effect of each setting is thoroughly documented.  One thing I will note that may not be readily apparent is that you can run Doxygen against multiple directories with source code to get a single set of documentation.  It just requires that the value of your input (INPUT) property contain all of those directories (instead of a single one).