I have been reading Joel Spolsky's stuff for a long time. He has a particularly unique common sense approach to software development. His outlook tends to support my own feelings on 'big business' and software development.
His latest article hits particularly close to home.
The Duct Tape Programmer talks about 'practical programmers', that is, programmers who are more concerned with just getting the job done, and less concerned about being flashy. I have worked with a number of astronaut developers who work far above the actual product. These people are more concerned with using the latest tool or technique. What the customer wants, or WHEN they want it, is a secondary concern to them.
Read Joel's article and gain a little insight into blue collar software development.
Showing posts with label programming. Show all posts
Showing posts with label programming. Show all posts
Friday, September 25, 2009
Friday, August 28, 2009
SQL Server, Windows locales, and the default user
I've run into this before, so I'm writing it down now.
I have a package of software that contains an interactive component, as well as several services. All pieces add and update SQL server database entries that contain dates. These dates are of DateTime type.
We ran the package on a machine that was originally configured with a Canadian locale, and its associated date formats. At some point, the admin user account had its locale changed to US and then SQL server 2005 was installed.
The problem was that the interactive component created database entries with correct date formats, but the services were trying to update with incorrect date formats. Both pieces got their date values using the DateTime.Now function.
Turns out that the services were running as the LocalSystem user, and the interactive piece was running as the logged in admin user. The LocalSystem uses the locale associated with the Default user. The admin user had been configured with a US locale, and the Default user still had the Canadian locale that was set during the initial Windows install.
To fix this,
- Open Control Panel
- Select Regional and Language Options
- In XP, select the Advanced tab
- Select the check box "Apply all settings to the current user and to the Default user profile"
- Click Apply
- In Vista, select the Administrative tab
- Click the "Copy to reserved accounts..."
- Click Apply
You will need to restart any services that are running as the LocalSystem user for this to take effect.
Whew!!
I have a package of software that contains an interactive component, as well as several services. All pieces add and update SQL server database entries that contain dates. These dates are of DateTime type.
We ran the package on a machine that was originally configured with a Canadian locale, and its associated date formats. At some point, the admin user account had its locale changed to US and then SQL server 2005 was installed.
The problem was that the interactive component created database entries with correct date formats, but the services were trying to update with incorrect date formats. Both pieces got their date values using the DateTime.Now function.
Turns out that the services were running as the LocalSystem user, and the interactive piece was running as the logged in admin user. The LocalSystem uses the locale associated with the Default user. The admin user had been configured with a US locale, and the Default user still had the Canadian locale that was set during the initial Windows install.
To fix this,
- Open Control Panel
- Select Regional and Language Options
- In XP, select the Advanced tab
- Select the check box "Apply all settings to the current user and to the Default user profile"
- Click Apply
- In Vista, select the Administrative tab
- Click the "Copy to reserved accounts..."
- Click Apply
You will need to restart any services that are running as the LocalSystem user for this to take effect.
Whew!!
Thursday, March 26, 2009
Specify a Date Format on The Fly
I write DICOM migration software in C#, and was recently faced with the task of setting a date format on the fly so that I could convert any date to DICOM format.
After much Googling, I found that DateTime has a TryParseExact() method that will allow you to specify the source string date format and put the successfully parsed date into a previously defined DateTime object. Once it was here, it was easy to use ToString() to format it DICOM-style.
CultureInfo enUS = new CultureInfo("en-US");
DateTime dt;
if (DateTime.TryParseExact(txtDateToConvert.Text, txtDateFormat.Text.Trim(), enUS, DateTimeStyles.None, out dt))
{
if (null != dt)
txtDICOMdate.Text = dt.ToString("yyyyMMdd");
}
After much Googling, I found that DateTime has a TryParseExact() method that will allow you to specify the source string date format and put the successfully parsed date into a previously defined DateTime object. Once it was here, it was easy to use ToString() to format it DICOM-style.
CultureInfo enUS = new CultureInfo("en-US");
DateTime dt;
if (DateTime.TryParseExact(txtDateToConvert.Text, txtDateFormat.Text.Trim(), enUS, DateTimeStyles.None, out dt))
{
if (null != dt)
txtDICOMdate.Text = dt.ToString("yyyyMMdd");
}
Thursday, August 7, 2008
Use Windows Installer Properties When Setting Registry Key Values
Whew! That's a mouthful!
I needed to set a registry key value based on the the installation directory of the package. Turns out you can use Windows Installer properties enclosed in square brackets.
Like this...
[TARGETDIR]bob.exe
... to get at the bob.exe in its install directory. This expands to...
C:\Program Files\Bob Application\bob.exe
... in the registry during installation.
You can use properties like
I needed to set a registry key value based on the the installation directory of the package. Turns out you can use Windows Installer properties enclosed in square brackets.
Like this...
[TARGETDIR]bob.exe
... to get at the bob.exe in its install directory. This expands to...
C:\Program Files\Bob Application\bob.exe
... in the registry during installation.
You can use properties like
- TARGETDIR
- ProgramFilesFolder
- Manufacturer
- ProductName
- SystemFolder
Friday, May 23, 2008
Why C Programming Skills Are Important
I think this quote is awesome, but the whole post is worth a read for anyone thinking about learning C.
"A lousy developer who happens to know C is simply better equipped to hurt himself or somebody nearby."
C and Morse Code
"A lousy developer who happens to know C is simply better equipped to hurt himself or somebody nearby."
C and Morse Code
Tuesday, March 4, 2008
Get the Unix Epoch time in one line of C#
I saw this code someplace else on the interwebs and stringified it.
((int)((DateTime.UtcNow - new DateTime(1970, 1, 1)).TotalSeconds)).ToString()
((int)((DateTime.UtcNow - new DateTime(1970, 1, 1)).TotalSeconds)).ToString()
Tuesday, January 22, 2008
SharpZipLib

#ziplib (SharpZipLib, formerly NZipLib) is a Zip, GZip, Tar and BZip2 library written entirely in C# for the .NET platform. It is implemented as an assembly (installable in the GAC), and thus can easily be incorporated into other projects (in any .NET language). The creator of #ziplib put it this way: "I've ported the zip library over to C# because I needed gzip/zip compression and I didn't want to use libzip.dll or something like this. I want all in pure C#."
http://www.icsharpcode.net/OpenSource/SharpZipLib/
Creating a Shortcut on the Start Menu

When you are using MS Developer Studio to create an install setup program, dev studio doesn't automatically create shortcuts for your application—you have to create these yourself.
Most applications create a shortcut in the Programs folder on the Start menu (or in a subfolder of the Project folder).
Open the Files view of your installer project. Click the Application Folder to view its contents. Right-click the Primary Output from your application item and choose Create Shortcut to Primary Output from 'your application name here'
Now, when the user installs your program, a shortcut will be placed in the Programs folder on the user's Start menu.
Subscribe to:
Posts (Atom)