Lately, I’ve been starting to see idiot popup windows on blogs that should know better.  The popups are from “Snap Preview Anywhere™”, a javascript thingie that displays a popup window when you move the mouse over a link on a page.

It sounds like a clever idea, but then again someone once thought the attribute was a clever idea.

I find the popups to be very annoying.  If you are trying to read something and you move the mouse over one these snap-enabled links, your experience has been disrupted.  I’m not the only one who dislikes SPA.

The idea is to show a preview of the site behind the link so that you can tell if you want to click that link.  Come on people, it’s 2007 and our browsers have multiple tabs.  No mysterious force is preventing me from opening that link in a background tab.

The good news, it’s pretty easy to fix.  You can disable the popup by going here and scroll down to the “Snap Preview Anywhere Activation” block and follow the instructions.  That method requires that your browser allow cookies.

If you are using FireFox, you can really take the snap out by installing AdBlock Pro and adding snap.com to the list of blocked sites.  That works very nice.

About a year ago, I put together a PC to automate all of our QA-Ready and production builds. We don’t have a huge number of applications to build, but I wanted an automated way to build each application. Before “Build Box”, each project had one developer who was reponsible for the build.

This worked, but it had some serious limitations:

1. It relied on a developer’s machine to the build, which meant it required access to that developer. If he/she wasn’t there, the team lead had to make sure that the machine would be accessable.
2. Nothing was automated, no two products were built the same way. This opens the door wide open for mistakes like not having the current source code.
3. Making a build was a major disruption for the developer who earned the build. This limited the number builds that would get buillt a day or week.

We use FinalBuilder to drive the build process. I can not say enough good things about FinalBuilder. It Just Works. With FinalBuilder, we use the following pattern to build each product:

1. Get the latest source code. We use Vault, FinalBuilder knows how to drive Vault.
2. Build the version information from .ini files stored in source control. With FinalBuilder, this was the easiest way to update the version number for the files. By alloing FinalBuilder to control the version resources, we can use the same mechanism for Win32 builds and for .NET builds
3. Build the actual project or projects.
4. Create updated installers. We use both the scripted and Windows Installer installer tools from Wise, FinalBuilder plays well with both. The only party of installer building that I can’t automate, is the code to deal with upgrades in place. With Windows Installer technology, I need to handle that myself. That only happens once per product release, it’s liveable.
5. Deploy the latest bits to the QA server. QA gets two copies of everything. The first copy has the final filename, the second has the build number appended (ie. something_278.exe) to it.
6. Send out an email to QA and the developers that notifies them that a new build has been released.

Now, any developer can remotely connect to the buildbox and start the build process. Of the course the fun part is getting the buildbox setup in the first place. It’s like having another developer on the team, it gets everything installed.

I have two machines that I do the brunt of my programming on.  One is a P4 1.8 Ghz box, circa 2002 that was my main work horse.  Last year I got a Pentium D 2.8 Ghz and that’s the new main work horse.  Over the years, they have accumulated all the compilers that I work with (Delphi 5, Delphi 7, BDS 2006, VS 2002, VS 2003, VS 2005).   In a stunning show of solidarity, both machines had hard drive failures within a few months of each other.  The older one fell down August and the new guy blue screen in the most spectaculiar way just before Christmas.

To make a short story long, I had to repave each machine with new drives.  I have a nice long list of tools that I absolutely require to get the job done and I have been reinstalling each item as I need it.  I”ll post that list later.

When it came to the compilers, I only installed the latest of each one.  That meant BDS 2006 for my Delphi needs, and VS 2005 for my C# needs.  I didn’t install the older versions of Delphi.  That was a mistake, I should of installed Delphi 7.  I really like BDS 2006, but CodeGear (née Borland) really broke the help system.  There are two many broken links, you have to explicitly the results to Delphi, or you end up with VB references.  And the content is missing many of the examples that were in Delphi 7.

But that’s an annoyance, I installed only VS 2005 (plus SP1), completely forgetting that of the projects that I am involved with has an ASP.NET 1.1 front end.  Oops, I should have saw that one coming.  I don’t do any of the coding on that bit, but I lost the ability to step throught that code to test my BDS 2006 based web service.  I’m trying to decide if I want to install VS 2003 (plus the older rev of DevEx) just to test some code.  What happens if you install VS 2003 AFTER VS 2005?  I spent too much repaving these boxes, I don’t relish the thought of screwing it up by installing VS IDE’s out of chronological order.   I think if I really need VS 2003, I’ll create a VMWare session with Win 2K and install it there.  Or I’ll create a VMWare image of our build box (everyone should have a buildbox), it has every compiler already configured.  Supposedly, I can create a VMWare session from an actual PC, that should be an interesting trick.

This was completely copied from here.   This was bugging me to no end and I wanted to make sure that I had an easy to find copy.

Removing the Language Toolbar in Windows XP

1. Click the Start Button.
2. Select Control Panel option.
3. Double-Click the Regional and Language Options icon.
4. Click on the Languages tab.
5. Click the Details button.
6. Click the Language Bar button.
7. Remove the checkmark from the Show Language Bar option.
8. Click OK.

I just came across Ed Dague’s blog. He’s much more than a floating head on a an obscure web site. His comments on local media and politics are both interesting and intelligent. His take on Spitzer’s naming of Michael Balboni as Deputy Secretary for Public Safety shows how 2 out of the three 3 local stations completely missed the hidden implications of that move.

He had to retire too soon from local TV for health reasons, but I’m glad to see that he has a forum for sharing his thoughts.

We dropped support for Sybase’s Adaptive Server Anywhere, effective 12/31/06.  It wasn’t an easy decision, but it was the right choice for us.

About seven years ago, our main application used file based database storage, through the BDE.  As we were designing what would be the present day version of application, we evaluated many different client/server solutions.

• It had to be designed for SQL.   Sounds like a given, but at the time file-based databases usually had SQL bolted on.

• It had to require zero maintenance.  Many of our clients do not have an IT department that can run a database that requires hand holding or was difficult to install.

• It had to be affordable.  We didn’t want to have to charge for a database runtime for entry level pricing.

• It had to have name recognition.  That makes a big difference when making sales presentations.

• It had to support views, procedures, and the other good stuff that comes with a modern SQL database.

• Had to run on Netware.  Many of clients were running Novell Netware as their network server and they wanted the data to stay on the server.

The president of the company wanted us to use Microsoft SQL Server.  It fit the list except for the last item.  Novell Netware.

That was hard one.  We needed a database that would be on the Netware server.  That meant it had to run on the Netware box.  The number of client server databases that run on Netware is a short list.  Back in 2000, the list included Oracle, Advantage, Pervasive, Interbase, Sybase SQL Anywhere.

We had ruled out Oracle because of cost and support concerns.  Advantage was a client server engine wrapped around a file based storage system and didn’t have the name recognition.  Pervasive was the current incarnation of Btrieve and I had bad experiences with Btrieve in the past.  It didn’t have the name recognition that we wanted and pricing was a concern.

Interbase met everything, but the name recognition.  At the time we were considering it, it was in the process of going open source and we had concerns over the long term viability.  Plus there was the name recognition.

That left Sybase’s Adaptive Server Anywhere.  It had everything, but the name recognition.  It did have a feature that none of the others had.  It supported the T-SQL dialect of SQL that Microsoft SQL Server uses.  That allowed us to write code that would be compatible with both SQL Server and Adaptive Server Anywhere.  There were a few places where the SQL was different, but that was less than 1% of the time.

Sounds great, so we did end support at the end of 2006?  There were a few reasons that added up to a big reason.

Performance was a sore point.  All things considered equal, SQL Server was faster than Adaptive Server Anywhere.  The more complicated the SQL, the bigger the disparity in the performance.  We ended up migrating most of our clients that were on Adaptive Server Anywhere to SQL Server or the MSDE.

The Sybase native OLE DB provider (ASAPROV) had bugs that never got fixed.  Our Win32 applications use ADO and OLE DB to connect to the databases.  The native Adaptive Server Anywhere OLE DB provider would throw strange errors when working with client side record sets.  I submitted multiple bug reports to Sybase and they addressed some but not all of them.   Instead using their provider, we used the Microsoft’s generic OLE DB to ODBC provider (MSDASQL) to connect to Sybase over ODBC.  That worked, but it added an extra layer to the mix.  Another concern was that Microsoft has deprecated MSDASQL and stated that it will not be available in 64-bit operating systems.  At some point a custimer was going to get a 64-bit edition of Windows and wouldn’t be able to connect to the database.

The additional testing time became a concern.  Sybase releases frequent updates, and we found many bugs that were reported on our application were caused by bugs introduced in the latest and greatest patch from Sybase.

After talking to some of of clients, we made the decision over a year ago to end Sybase support.  We down to a handful of clients still using Sybase and we expect to be migrating their data within the next few months.  It has gone very smoothly.