Update Hiccups

For over three months now we’ve been working on updating our multi-carrier manifest system to its latest version. The update was first made to our test system. Then we had the job of thoroughly working through the system to discover any bugs, errors and changes that adversely would affect our production system. After having corrected all known issues within the test system we went live with the update in our production system this morning.

Unfortunately everything did not go smoothly. Elements that worked fine in testing like printing USPS and FedEx shipping labels all of a sudden failed. Fortunately after a few hours of troubleshooting on the phone with support we were able to resolve the issues.

Test systems are essential and highly affective at streamlining the update process. But they are not foolproof. Slight differences between the systems or failing to follow the exact same steps in the update process can result in errors in production even when the test system was flawless.

Separation of Test Systems

Deployed the current version of our new website to one of our servers today so our management team could start reviewing the site and provide their feedback. It was initially suggested that I simply deploy the test website from my laptop. However, I felt it better to run the test system off a server.

First off, my laptop is not always at work when some of our managers would be previewing the site. Second, the server acts as another layer of backup in case the code on my laptop becomes corrupt or gets erased. However, the most predominate reason why I wanted  a test system on one of our servers was for a separation of systems during the testing procedure.

When I edit code in Visual Studio I often break the website. This is part of development – trial and error. If this website code is being viewed by others they may experience errors. By having a test server where I can upload code when I’m ready for it to be viewed, I’ve created a system where I can control the whole process and specify exactly what I want others to see.

The next step will be to deploy the code to an actual live production server which will host the website. Then updates will go from my laptop, to the test server and finally to the production server. This process works well and ensures that by the time the code reaches live status it’s been tested and is ready for the Internet.

Baby Steps

Recently we’ve faced a challenge within our multi-carrier shipping system to insert some custom code for one of our biggest clients.  The code is to stop shipping orders if a certain individual’s name appears in either consignee or company fields.  The challenge is that he/she may not always have the name in the same format and/or order.

I challenged my IT assistant to use Google to come up with a solution to this situation in Visual Basic.  Since we can’t use a simple “=” or (Name = “Bob”), we’ll need to use a function containing something in the order of a wild card.

In SQL I would use “Where Name Like ‘%Bob%'”.  But this does not help us in VB.

Surprisingly right before I left the office my assistant informed me that he’d found a solution.  It was relatively simply but not what I would have expected.  Now if Bob is the first, middle or last name the system will catch the shipment.

In fact, I didn’t even fully catch what the solution was.  I just told my assistant to thoroughly test that the code worked and place comments around the code for future reference.

The important thing here is that I was actually able to delegate programming research.  Its the small things.  The baby steps.

Working Out the Bugs

I officially deployed the XDock system yesterday.  The last major issue I needed to work out was printing 4 x 6 labels on our thermal printers.  This little project took the better part of a month of off and on work.  But its down now?

Projects are never done!  Especially directly after you finish “deploying” them.  I got a few emails today with different issue that users were encountering.  There were all relatively superficial but legitimate issues that needed to be fixed.

I’m be working out the bugs on this project for a little while to come.  You can only catch 95% of the issues in development and testing.  The rest will come to light from your users after you deploy.

Testing Going Slowly

So all last week our accounting department was supposed to be using our new auditing system.  They were going to start with the back billing section for a few select clients and expand from there.  However, due to other pressing issues and people being gone, by Wednesday hardly any of the system had been used.

A little bit more was done between Thursday and Friday, but still not enough to assess how well the system is working.  Now we’re going into Thanksgiving week where we only really have a half a week for testing.

So I’ve moved on to other projects while I wait for feedback from our staff.  These things generally take longer than planned.

Glad I Updated My Code to the Test System First!

So I’m just about to head out of town for the next four days and thought I’d update some of my recent code to our production system.  I’d added some cool new functionality to our auditing system that could be of use to several of my users in my absence.  As per standard procedure I updated my test system first and then opened up the system to ensure that it worked.  I got an error on the home page of my auditing system and was completely unable to access any functionality.

I’m now faced with the frustrating task of figuring out why it works in debug mode within VS2010 but not when I deploy it to the test system.

However, had I blindly updated our production system and then headed out of town worse things would have happened.  Test systems exist for a reason.  Use them even when you think you’re sure that everything will work fine.

Using the Test System

We’re upgrading our manifest system from version 9.3 to 10.1 this week.  The upgrade is managed via the company that provided and currently supports the system.  Our main responsibilities is for testing and the good part about this is that our test manifest system is updated first.  A lot can change between versions for better or for worse.  We’re hoping this new version will fix a number of outstanding issues.  But there is also the chance that it will break elements of the system that currently work just fine.

That’s why the test system is so important.  It’s updated first and we systematically run a series of shipment scenarios  through the system to ensure that everything is shipping and rated correctly.  Only when the test system fully checks out do we then upgrade our production system.  This way if something goes very wrong it will not affect our daily operations.

Starting to Use Apple’s Safari Browser More

For the past six months I’ve been using Apple’s Safari web browser for writing and managing my blogs.  I’m a horrible speller and Safari will underline any misspelled word while you’re typing.  IE 7 does not do this and having my spelling corrected while I type if a huge benefit.

Today I started using Safari to search Google for coding tips for Visual Studio 2005.  The problem with VS2005 is if I already have an Internet Explorer 7 window open while trying to run my website in debug mode then I cannot step through my code line by line.  Thus I started using Safari for my web searches and research because it did not disrupt my debugging.

I’ve been exclusively using Internet Explorer for 10 years.  However, more recently I’ve been finding more and more benefits to using Safari.  There are benefits to branching out and not always using the same program all the time for the same function.  Especially with web browsers which are always free it makes sense play the field.

Functionality vs. Performance

Nine months ago I migrated our scanning system from MS Access to our online WMS (Warehouse Management System).  In doing so I brought over all the same functionality and features.  One of these features was seeing a table of all the items that are left to be scanned in the order.  This feature worked well in the Access model and tested well in my web based model.  However, it was not until much later that I started seeing some of the drawbacks.

I like to build screens with lots of functionality that convey the maximum amount of information to the user.  Thus the table on the screen showing those SKUs left to be scanned in the order seemed like a good idea.  The problem was that the system had to regenerate this entire table after each item was scanned.  This worked well in testing when I was dealing with 1 to 20 line items, but did not work so well in actuality when we had well over a 100 line items be re-rendered every few seconds.

Thus my users were using the old Access based system for their larger orders and not benefiting from other new functionality I’d added when I upgraded the system.

So today I rebuilt the system with only the basics on the main scanning screen.  The user has the option to switch to another sub screen that has all the information on the order.  But when they’re scanning the functionality is left to a minimum.

Its nice to add bells and whistles, but these extra features start adding up after a while.  There is always a balance between functionality and performance.  At a certain point a system needs to preform first and foremost.  Anything extra just gets in the way.

Fix One Thing, Break Another

Today I fixed a bug in our multi-carrier manifest system that was caused when another issued was fixed.  The bug itself was originally fixed six months ago.  Then promptly become unfixed when the second issue was fixed.  Sound confusing?

Our manifest system comes with custom scripts that we can edit on our own.  We had a problem with a certain shipping service level rounding both up and down to the nearest pound for rating when it should 100% of the time always round up.  Our manifest provider helped me write code to fix this issue.

Then a few months later they again helped me write code to automatically change between service levels based on certain criteria.  In doing so they commented out the rounding fix code; presumably for testing purposes.  The code remained commented out and we again had a rounding error.

The problem was that I still assumed that the rounding issue was fixed and it took several months before we found out that a lot of our shipments were rounding down to the nearest pound and not rating correctly, thus leading to lost revenue.  It was not until today that I was able to fully understand the sequence of events that happened and fix the problem.

Be careful when updating your code that you don’t comment out or otherwise disrupt other lines of code within your scripts.  In this case our manifest company had to comment out the rounding code to test their service level swap code.  They just forgot to uncomment the code when they were done.  Thus be very careful when others update your code that you check it over before signing off on the project.  Otherwise months could go by before you discover that there is even a problem.