Tuesday, July 13, 2010

Don't Be A "Warren."

I think it's a bad idea to write blog entries about one's current job.  However, that does not mean I am unwilling to pass along anecdotal wisdom gained from previous employers.  This is one such anecdote.

Like many of us in the tech industry, I provided technical support & assistance for clients by many communications avenues, including email.  One morning, I get an urgent email from "Warren" asking me to perform a routine task in a short time frame for an urgent deadline.  I also noticed he's carbon copied others in his office on that same email.  I take his request out of sequence, complete the task, and "Reply All" to let him and his colleagues know the request has been completed so they can do what they need to do.

About three minutes later, "Warren" calls me on my direct line and chews me out. "How dare you  include my supervisor . . ." on the email reply.  When I explained I hit reply all to notify all parties included on the original message of the completed status of the task, he cut me off and told me that he was the only person allowed to email his supervisor, period. 

Here's the point: All these years later, I don't remember anyone else's name from that office. I couldn't tell you what they did, or if they even did their jobs competently. They could have been the foremost in their field, but all I will ever remember is "Warren" and his pathetic macho bullshit attitude.  That is how powerfully cancerous to your organization's reputation one asshat like "Warren" can be.

Tuesday, July 6, 2010

LG Xenon, AT&T and the .jar/.jad issue

Once upon a time, I wanted to be able to read electronic books on my cell phone.  This sounds like a simple thing, especially when you consider that my LG Xenon supports Java midlets.  All I should have to do is locate an ebook reader program on a site such as getjar.com, and download and install it on to my phone, right?

Sure. If it were that simple, I wouldn't have written a blog entry about it now, would I?

So, I go to getjar.com, and scan through the half dozen or so offerings of book readers and test drive one or two of the most promising.  Although I'm able to install them, they do not seem to actually allow me to open any text files stored on my phone.  The only ones that do work are the ones that embed a book/text file inside the actual .jar (java archive) file itself. I do some research, locate the stats on my phone, and sure enough, it is supposed to support a file system API that allows programs to access the phone's file system.  That's JSR 75, if you want to know the Java programmer jargon for it.

The long and short of it is that AT&T does something to the firmware of the phones they provide which prevents third party programs from accessing the filesystem.  I get it-- it's for "security purposes."  You don't want just any old program being able to access the file system or the GPS interface, otherwise nefarious people might start using it to do bad things to your customers.  The part that galls me is that if a third-party developer goes out and spends serious coin ($200/year) on a certificate from someone like Verisign or Thawte, to validate their work as legitimate and unmodified, AT&T still denies them access to JSR 75.  You basically have to go through AT&T's internal verification process, which coincidentally will cost you more serious coin, and will not do anything towards making your "write once/run anywhere" program work with other cell phone vendors either.

It's sad, but my interest and enthusiasm in learning how to write Java midlets for cell phones just kinda died.

Sunday, July 4, 2010

How to check a solved Sudoku puzzle

When you solve a Sudoku puzzle, you should *always* verify your solution is correct.  That sounds simple, right?  You would proofread an email before hitting the send button, but . . . how exactly do you verify a Sudoku puzzle?

There are many Sudoku solver websites-- so you could, in theory, enter the puzzle manually into the site, have it solve the puzzle and then compare your solution with the solution generated by the Sudoku solver site.  But honestly, it's such a simple process that using a solver website is overkill.  If you can count to nine eighteen times in a row, you can check a Sudoku puzzle.

  1. Focusing on the first row alone, find and count the numbers from 1 to 9.  If you are missing any numbers, you have an error (either a blank or a duplicated number) in this row.  You should mark errors for future reference to be corrected.
  2. Repeat the process used in step 1 for all the remaining rows.
  3. Focusing on the first column alone, find and count the numbers from 1 to 9.  If you are missing any numbers, you have an error in this row.
  4. Repeat step 3 for the remainder of the columns.
  5. If you have checked all the columns and rows for the numbers 1 through 9, and no numbers are missing, then your solution is valid.

Note: You must check both the rows AND the columns.  It is possible for all rows to be correct, and still have a problem in one or more columns-- or vice versa.