Juliet, Naked by Nick Hornby

3/5

Classic Hornby. It's fairly close to High Fidelity with it's themes of love and music obsession-ism and so feels slightly too comfortable but certainly worth a read if you're a fan. 3/24/2010 2:00:00 AM

 

The Girl with the Dragon Tattoo (Millennium, #1) by Stieg Larsson

3/5

Slow, but highly atmospheric mystery. The first half of the book is dedicated to setting the scene and then the pieces start to fit into place like a glacier melting. The pace makes the occasional punctuation of extreme sexual violence all the more shocking. Fun enough, so I'll probably read the rest of the trilogy and try to catch the film (which has to be a profoundly truncated version).3/22/2010 2:00:00 AM

 

Practical WPF Charts and Graphics by Jack Xu

4/5

Be aware that this book is 90% code, 5% mathematics and 5% explanation. This isn't a criticism, Dr. Xu builds up a complete charting library that includes 2D, WPF 3D and manual 3D methods. The mathematics covers the theory and practice of 2D and 3D transforms as well as techniques for smoothing, interpolating and trending data. It's a fast read to get a sense of the content and then a great reference work to dip back into as needed. 3/14/2010 3:00:00 AM

 

C# Design and Development: Expert One on One by John Paul Mueller

1/5

This book is just atrocious. Each section sells itself as providing all the information you need about a certain topic, then provides trivial and often incorrect or at least highly subjective details. A couple of examples:

The chapter on error handling makes the point that you should catch the most specific Exception possible, but then goes on to demonstrate catching a FormatException, a DivideByZero exception and then just System.Exception. The whole point is to avoid catching Exceptions that you can't handle. There's a legitimate debate here between trying to plaster up the cracks with general catches and letting the application die with a useful stack, however this book doesn't discuss it. There's also very brief coverage of creating your own derived Exception but it doesn't touch on serialization.

Serializing an XML file is somehow included in the section on "Special Coding Methodologies", and labors over calling both .Flush() and .Close() on a StreamWriter. Despite the fact that you only need to call Close(), and that StreamWriter is IDisposable and so a using statement is really the way forward for this example.

I could go on, but won't. Avoid. 3/8/2010 2:00:00 AM

 

Links

If you send email to customers it's important that you let them know where the email will come from and then use then use this address consistently. Using different email addresses is a recipe for getting trapped in spam filters. This is equally important for marketing and other messaging like bills and canceled flights.

I bring up flights because I'm flying to the UK later today and was planning to return on Sunday. British Airways' Cabin Crew is going on strike this weekend and my return flight has been canceled. Instead of sending a text message BA tried to notify me by email. This would have been fine if they used the address they've used for years, but instead they used a new address and a new domain. In fact in the process of canceling and re-booking I (eventually) got email from britishairways.com, my.ba.com, email.ba.com and pop3.amadeus.net.

Since I've had the same email address for twelve years now I get a fair amount of spam. I use SpamArrest to keep myself sane:

94.9% of my email is spam. Since I started using the service SpamArrest has eaten 482,494 messages for me. I'm far from alone in using white list based email filtering so if you want your message to get through transparency and consistency are the way to go.

Yes.

Some more color. I use Intuit's assisted payroll service, which is fantastic. You run payroll straight out of QuickBooks and Intuit handles all the tax disbursement and filing for you.

I got an email today with an attachment called securedoc.html claiming to be a message from Intuit. The idea is that you open the attachment and then login to view the message.

It really couldn't look any more like a phishing email, however I called Intuit and remarkably it's a real message. They seriously expect me to open an email attachment and provide account information. The support person at Intuit was able to read the message to me and it was just a routine acknowledgment that some tax rates had been updated.

Intuit is seriously training its customers to fall victim to phishing attacks. The right approach would be to say that a message is available and to log in to your account to retrieve it, or better still to send a message through the existing system in QuickBooks. Securedoc.htm is just begging customers to provide their account information to the bad guys.

Intuit's payroll service stores bank account information, employee Social Security numbers and other data that you really don't want to expose. If you're an Intuit Payroll customer please call and complain. If you've received one of these messages I'd also recommend forwarding it to spoof@intuit.com, their address for reporting phishing attacks.