Sunday, April 29, 2007 I have talked about White Peak Software being a product company for the last couple of years, but the transition from services to products has been challenging. I'm working on a new email program call Vertigo but progress has been slow for various reasons. I learned trying to get a product like Vertigo out the door at single person software company is a huge challenge especially when you rely on services work to bootstrap any R&D work.
What I need is a different approach, so 8 weeks ago I came up with a set of short term goals to start building momentum towards being a product company. Tomorrow is the last day of the 8 weeks and I'm happy to say I reached my goals as of today. It hasn't been easy especially over the last couple of weeks which has had me working 14 hour days, but momentum is finally starting to build.
Over the last 8 weeks I released an update to SMTP Diagnostics and published a new product called Killink CSV. I have also made numerous improvements to the White Peak Software web sites including a fully integrated store front. More work is needed but things are off to a good start.
My next challenge is to sustain and build on top of the momentum started over the past 8 weeks. This means a new set of goals for the next 8 weeks. The new goals include:
* At least 2 product releases
* Sell at least 20 units of my products
Key to the next 8 weeks is selling 20 units. This means not only getting updates to Killink CSV out the door but making improvements on the marketing side. Currently, my plans include a press release campaign and Google AdWords. I also plan to do a better job monitoring conversion rates and web site traffic, something I have ignored over the last year and a half.
My motivation level is high and will only get higher as sales increase. But even with a high level of motivation I must do a better job managing my time during the next 8 weeks. I've been working 14 days recently and it's starting to wear on me...and on my wife too. posted by Kirby | April 29 06:57 PM | comments (0)
SMTP Diagnostics 1.7 has been released and is available for download. Read here for more information. posted by Kirby | April 29 09:46 AM | comments (0)
Friday, April 27, 2007 White Peak Software has a set of support email accounts. Each time an email is received it is logged to a tracking database and internal notification emails are sent out. In addition to responding to incoming email I review email messages marked as spam each day.
I noticed today the number of spam messages received had dropped to only 5. This seemed odd but a new grey listing anti-spam measure was also implemented this week on the mail server. I thought it was too good to be true that 99% of spam messages received were being filtered by the mail server. After all the mail server is configured to mark most spams not deleted them for fear of fault positives.
As it turns out the reduction in new spam messages was not the result of improved filtering but a problem with the tracking system. The support mail accounts have been overloaded the last 48 hours and the tracking system has been slow to catch up. The problem has been fixed and the queued messages are now being processed.
If it had not been for the reduced spam count the problem might have gone undetected for a longer period of time. For once spam proved to be useful. posted by Kirby | April 27 09:32 AM | comments (0)
Thursday, April 26, 2007 I was so swamped yesterday that I forgot to blog about the latest release of Killink CSV. Killink CSV 1.0 is available for download and purchase. You can read the official announcement here. posted by Kirby | April 26 09:17 AM | comments (0)
I posted a new version of the Connection Tool for SQL Server. This free tool provides an easy way to test and build connection strings for SQL Server databases. This latest version has improved support for Windows 98/ME and Windows Vista.
One unfortunate side effect with this release is you must delete the ConnectionToolForSQLServer.exe.config file if you used the previous version. This file is found in the same directory as the ConnectionToolForSQLServer.exe program file. If you don't you will get an error message similar to this:
ConnectionToolForSQlServer.exe
This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.
I explain the reason for this here. posted by Kirby | April 26 09:07 AM | comments (0)
Wednesday, April 25, 2007 I learned a valuable lesson today about naming configuration files for my programs. When I started building.NET applications I followed the .NET convention for naming program configuration files: MyProgram.exe.config
These days I write less .NET applications and more native Windows applications using Delphi. I continue using the .NET naming convention for configuration files for all my programs even native Windows applications. This hasn't been a problem until today.
Today I embedded a manifest into a program and when I ran the program I got the following error message:
C:\MyProgram.exe
This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.
Without the manifest the program ran fine, but the program failed each time the manifest was included. I first thought a problem was with the manifest. I review the manifest over, and over, and over again. I even used a manifest from another application that does not have the problem. After banging my head on the wall for a couple of hours I found the source of the problem, and it wasn't the manifest at all.
Like all my programs, this particular program creates a configuration file using the .NET naming convention MyProgram.exe.config. But in this one case the configuration file is stored in the same directory as the program file, and here in lies the problem.
Apparently Windows XP, and I assume Vista as well, expects the program configuration file to be based on some specific config file schema when the manifest is embedded in the program file even if the program is a native Windows program. I knew this to be true with .NET applications but I didn't realize the same is true for native Windows applications.
I have not spent time figuring out the expected schema. I suspect it is the .NET config file schema, but I now follow a new naming convention. I do not name my config files MyProgram.exe.config any more. Instead I use MyProgram.config, which does not have any negative side effects when stored in the same directory as the program file.
Update: If you want to use the .NET config file naming convention for your native Windows application, your .config file must be an XML, and the root element must be <configuration>. Other root elements might be allowed but I know <configuration> works. posted by Kirby | April 25 05:35 PM | comments (0)
Saturday, April 21, 2007 Yesterday was a 16 hour work day for me. It was a long day but a good end to a long, busy week. However I made one last minute mistake last night. I posted the new release of Killink CSV but I forgot to update the download page with links to the new download files. My apologies to anyone who tried downloading the program in the last 12 hours.
I updated the download page this morning, so all is well now. posted by Kirby | April 21 09:00 AM | comments (0)
Friday, April 20, 2007 Whew, it's been a long, busy week.
I have been hammering away at various performance issues with Killink CSV and I'm happy to announce a stable build is now available for download. This is Release Candidate 1. Assuming no more show stoppers the final release of Killink CSV should be posted in a few days.
I'll try to find time this weekend to blog about some of the performance improvements made in Killink CSV. One aspect I find exciting is the use of a custom dataset that allows a single copy of the delimited data to exists in memory and is used to feed data to the print module. But more on that later.
I've also been busy this week cleaning up the White Peak Software web site and the Killink CSV web site. The SMTP Diagnostics web site will be updated soon. Also look for a new release of SMTP Diagnostics coming soon with better Windows Vista support.
And if you haven't seen it yet check out the new White Peak Software Store. The new store front is fully integrated with the White Peak Software web site giving the customer a more seamless shopping experience.
As I said, it has been a long, busy week. posted by Kirby | April 20 08:06 PM | comments (0)
Monday, April 16, 2007 Yesterday I had a need to install PowerPoint 2007. Typically I install something like this in a virtual machine to avoid problems with other applications but yesterday I was in a rush so I installed PowerPoint 2007 in my "production" VM. The Office 2007 installation gave me the option to keep my Office 2003 applications and install only PowerPoint 2007. "Groovy!" I thought. Well, it turns out not to be so groovy.
After installing PowerPoint 2007 and doing what I needed to do, I launched Outlook 2003. As Outlook 2003 was loading the Office 2007 installer popped up and attempted to install something. I cancel the installer and Outlook 2003 finally loads. I checked my mail, read a few messages, and clicked Reply to author a response to a new message. Here's where the problem started.
I have Outlook configured to use Word as the editor for messages. When I tried to reply to a message Outlook locked up. Not only did the application lock up but the entire operating system locked up. I had no choice but to power off.
Rebooting didn't help either. Outlook 2003 did not properly load, and I had a new problem. Microsoft's automatic update was now maxing out the CPU. To regain control over the machine I killed the automatic update process.
After dealing with this mess I believe I found a work around. After installing PowerPoint 2007 and before launch Outlook 2003, launch Word 2003. If your experience is similar to mine you will notice Word 2003 loads without the XP theme. After about 30 seconds Word 2003's UI switches to the XP theme. It is after this point that Outlook 2003 is once again able to use Word 2003 as its editor.
I can't guarantee this will work for you but it did work for me. I'm now able to use Outlook 2003 once again.
The only problem that remains is the automatic update for Windows. It still maxes out the CPU and the process must be manually killed. I can handle doing this until I have time to re-build a new "production" VM.
Update: I found this wordaround to the maxed out CPU problem. posted by Kirby | April 16 08:23 AM | comments (0)
Tuesday, April 10, 2007 I'm coming to the conclusion that having code loop millions of times to copy data from one structure to another is never going to be fast.
I'm using two controls, a spreadsheet control and a report printing control. Unfortunately the two do not support the same data structures so to print a report Killink has to copy the data from the spreadsheet to the report which means looping. And when there are a million + rows with 3 columns the code is looping 3 million + times. Not much can be done to speed it up.
What I need is a way to keep the data in a single data structure that is supported by both components. I'm starting to have a better understanding why certain commercial software tends to not rely on 3rd party components and libraries. However, time is important to me so I must rely on 3rd party components for certain features.
For now Killink will have to warn the user before allowing a huge files to be printed. "You wish to print a file that is very large. It will take some time to prepare the data for printing. Do you wish to continue?"
The report I'm trying to preview during testing will have more than 15,000 pages. I don't see anyone realistically printing this many pages but you never know. posted by Kirby | April 10 03:22 PM | comments (2)
The first version of Killink is feature complete, but there was one thing that was brothering me, large file support. Opening, printing, and saving a large file in Killink is a rather slow process so I've been working on improving these 3 areas.
The first area I worked on was opening a large file, which is what I will talk about today. After profiling the application I found the biggest bottleneck was populating the spreadsheet with display data. This was an easy fix that involved "freezing" display while the spreadsheet is loaded with data. This change resulted in a huge performance increase. The test file I used took minutes to load prior to the change and only 2 seconds after the change. But then Killink took another perform hit.
A beta tester reported the bug that embedded new line characters were not properly handled. I modified the CSV parser to check each byte of data as it was read from the hard drive. However this is a very inefficient approach. A better approach is to buffer each read. In other words, instead of reading a single byte from the hard drive it is better to read a chuck of bytes. The chuck can be any size such as 65K chucks or 1MB chucks.
Buffering the file read process gave Killink the performance boost it needed to open large files. It's not as fast as I would like it but it's getting closer.
The performance improved version of Killink should be ready for download in a couple of days. posted by Kirby | April 10 10:41 AM | comments (0)
CSV (also known as comma separated values, comma separated list, or comma separated variable) is a commonly used file format that stores tabular data. Each data element, or value, is separated with a comma or other single character delimiter such as a Tab character. These types of files are also called delimited text files or flat files.
Many software application support CSV delimited text files either as an import or export data format. For example, Outlook users can export the address book to a comma separated value file and import the contacts into another application.
I have worked with comma and tab delimited text files throughout most of my career. I have written applications that produce delimited text and consume delimited text. And while XML is my preferred file format for sharing data there is no escaping the usefulness of CSV delimited text files.
While CSV delimited text files are typically used to import and export data between software applications there are times when individuals must manually create or edit comma and tab delimited text files. And many of these individuals use a spreadsheet program such as Microsoft Excel. However, using a full featured spreadsheet such as Excel to create and edit CSV delimited text files seems overkill to me.
For starters, say you only need to manipulate CSV delimited text files and have no need for working with spreadsheets. The licensing cost of Excel is hardly justified. Secondly Excel imposes certain size limitations. Excel is limited to 65,536 rows of data and 256 columns per worksheet. This means you will not be able to open a delimited text file containing 100,000 rows. Faced with high licensing cost, overkill list of features, and size limitations I decided to write Killink.
Killink is a spreadsheet-like editor for delimited text files. It supports delimited text files using any single character delimiter including comma and tab, and it supports large delimited text files.
Version 1.0 is currently in beta test which is open to the public. Visit the Killink download page and give the latest release a test drive. I appreciate any feedback, good or bad, you might have about Killink. Feedback can be posted to the Killink Support forum.
Update: Microsoft has improved the limitation of Excel. Excel 2007 supports 1 million rows per worksheet. posted by Kirby | April 10 09:58 AM | comments (0)
Monday, April 09, 2007 Writing code while listening to Led Zeppelin puts me into the zone especially when I'm making bug fixes. posted by Kirby | April 9 08:55 AM | comments (0)
Wednesday, April 04, 2007 I'm adding a new feature to Killink to allow the user to integrate the application with Windows Explorer. Not a difficult task. Just involves making some registry settings. But one registry setting I need to make must go under HKEY_CLASSES_ROOT, and this hive is under administrative control in Vista.
This isn't such a big deal if I am using an installer. Installers will typically ask for elevated permissions to perform the install. But I'm trying to provide a version that does not require an installer. This means my application will have to ask for elevated permissions when the user clicks the option to integrate with Explorer. It also means I need to display the shield icon indicating that elevated permissions are required to perform the task.
This really has me bummed out because it means more work (and learning). Now I have to learn up to ask for elevated permissions within the application.
Sigh... posted by Kirby | April 4 10:51 AM | comments (2)
Jim Douglas replaces Ben Smith as CEO for CodeGear. This move makes no sense to me, but then again I have never really understood Corporate America.
In my opinion Ben Smith seems like a fine CEO for CodeGear. I have admired his openness and his willingness to connect with the developer community. Heck, he has even responded to blog posting here at thecave.com as well as to other blog sites. His actions have given me greater confidence in the future of CodeGear. But this latest move by CodeGear has me scratching my head wondering what the future will hold for CodeGear.
Best of luck to Ben. I for one think you did a great job kick starting CodeGear. posted by Kirby | April 4 08:48 AM | comments (1)
