Tuesday, March 27, 2007

Damn good advice

This post by Andrés Taylor of advice for programmers is one of the best I've read in quite a while. Just thinking over the past couple weeks, I can already see at least five in action, particularly #10:

Some people are assholes. Most of the time, most of the people around you are great. You learn from them, and they learn from you. Accomplishing something together is a good feeling. Unfortunately, you will probably run into the exceptions. People that because of something or other are plain old mean. Demeaning bosses. Lying colleagues. Stupid, ignorant customers. Don’t take this too hard. Try to work around them and do what you can to minimize the pain and effort they cause, but don’t blame yourself. As long as you stay honest and do your best, you’ve done your part.

It really is true. Some people just aren't worth your time. The rest of the list is excellent as well.

Monday, March 26, 2007

Fixing Logician's cheesy printing with FinePrint

Without a doubt, one of Logician's weakest points is its printing support. When printing multiple documents, Logician sends each one to the printer individually rather than as a group. Since attachments are viewed in a browser window, it is not possible to print them in order with their original documents.

Where this really becomes a problem is using the integrated Biscom faxing. Because each document is sent to the fax separately, each one gets a separate fax cover sheet when it goes out and (presumably) is faxed in a separate call. For instance, when we fax pre-ops to the hospital, the hospital staff complains - understandably so - when they get hit with 10 cover sheets for what used to be one job. And faxing attachments? Not even worth the trouble.

Solution: FinePrint. I first heard about this product from one of Scott Hanselman's excellent posts. The application creates a virtual printer that intercepts your print jobs, allows you to manipulate them and then send them off to a real printer. It has quite a few features, such as reducing multiple pages onto one, etc., but only one of them - grabbing multiple print jobs at once - really helps Logician. But boy, does it help.

For instance, consider faxing multiple documents to another office, for say, a med-recs request. You can select all of the relevant documents (using shift-click, or to pick and choose, ctrl-click):



Print as usual, but select FinePrint as your printer:

All of the documents are loaded up in FinePrint's queue and ready to either be added to, selectively deleted, or just printed:
You can click back into Logician (without closing FinePrint) and print more documents to its queue. This is very helpful for adding attachments to the print job as you go.

If you end up with extra pages, or in the wrong order, you can right click on the queue to edit it:


Where I expect to see the biggest boost is with our med-recs request. Rather than having to print out (paper-wasteful) or print preview (time-wasteful) to find out the number of documents needed to fulfill a multi-part request, the staffer can now just use the total page count displayed by FinePrint to calculate the bill. And the best part: she can then just save the print job until payment comes in and then re-load it (without re-printing) and have it faxed or mailed in a flash.

FinePrint is well worth its $50 price. I've already noticed several other places in the practice this program may end up being a big help.

Sunday, March 18, 2007

Examining contents of pointers in Visual Studio

Oftentimes in C++, you'll be dealing with pointers, either as pointers to dynamic memory or as parameters to functions. Unfortunately, Visual Studio's debugger by default isn't very helpful about showing you what you need about what those pointers are pointing to. For instance, in the simple example below, we have 20 ints in ascending order:

When you run the program, it'd be nice to be able to see the entire contents of the memory during debugging. But by default Visual Studio only shows the first value:

This makes sense because the debugger has no way of knowing just how many ints we've allocated. We could be dealing with a gig worth of memory, all being handled by that one pointer. VS takes the safe route and assumes we're just dealing with one.

There is a way to see all of the memory, though. It was not intuitive to me and I had to search Google far and wide before I found it.

From the Autos window, right click and add a watch to the pointer variable.

Go to the Watch window, double click on the newly added variables name, type in a comma and how many values to view. In this case, 20 will suffice. Visual Studio determines how many bytes to show (and how to interpret them) by looking at the size of the type being examined.Voila. This trick isn't just limited to viewing pointers. With some creative casting, you can use it to examine the memory layout of any data structure in C++. I'll post on that if anyone is interested as well.