Saturday, August 30, 2008

Less Awful Resume Tool

(UPDATE 12/5/2015: moved to github)

If you read Steve Yegge's Ten Tips for a (Slightly) Less Awful Resume, you'll notice that he lists various words and phrases that you should avoid using in your resume. I was re-reading that hilarious, uncouth, yet insightful blog entry a couple days ago and started sweating that I might have a Weasel Word or two in my own resume. This could happen purely by accident, of course (we all get sloppy now and then, right?), so this obviously called for an automated tool. As a result, I present to you the Less Awful Resume Tool, or, lart.
lart is a simple tool (written in Python) that searches a text file (ideally your resume) for those words and phrases called out in Steve Yegge's essay, and alerts you to their presence. I have claimed no copyright over this work, and the code is hosted at the Less Awful Resume Tool project on gitorious github. You can do a git pull as instructed there to get the code, or download a zip archive. There's no installation, it's just one file that you run as a command-line application, passing it a text version of your resume (which is the only version you need, according to the essay). If you'd like me to add a feature or fix a bug, feel free to send me a pull request (or just leave a comment here if that's easier).

Monday, August 18, 2008

Bad Vibrations

Having seen Bristlebot, I thought I knew exactly what I was looking for as I carefully disassembled my Samsung SGH-C417 phone. You see, it had accidentally gone for a ride in the washing machine and after quickly removing the battery, and then patiently letting it dry for a few days, it still wouldn't stop vibrating. Everything else worked fine, so I figured I'd open it up, find the little motor that looks like the one powering the Bristlebot, cut the wires to it, and then I'd still have a working cell phone. Here are some pics of what I saw once I opened it up: Can you see the little DC motor? I couldn't either, and as I fought with stubborn little screws and plastic tabs to uncover more of its innards, I became more frustrated with this little phone. I could still power it up and feel it vibrating the whole time, but I could not pinpoint where it was coming from. I definitely could not see a spinning motor anywhere. After a while, the last part to look under was the board with the LCD screen embedded in it. It was getting late and I couldn't see any way to carefully remove it, so in frustration I just put my screwdriver tip under it and pried. The ribbon cable to the camera lens tore and the wires to the speaker broke. The other battery or speaker looking thing remained attached and it finally caught my eye. "Could that be it?" I questioned. There was nothing under the board. "How could it be?" I agonized, but sure enough, when I connected the battery to the main board and powered on the phone, that's exactly what started vibrating. It had been in plain site within easy reach of my wire cutters from the moment I had pried apart the plastic cover, but I hadn't questioned what it was. Like the befuddled Stormtrooper, I only knew that it wasn't the DC motor I was looking for. Here's a closer look at the battery/speaker looking vibration source: After this failed repair job, I soothed my bruised embedded systems engineering ego by taking the cell phone parts to work and arraying them on my desk. As interested engineers stopped to paw through the mess I asked each of them to identify what makes it vibrate. Very few figured it out without my help, even though most of us firmware engineers have hardware experience in our past. A couple EEs where stumped for a bit too, which was very consoling. I still don't know exactly what that part is called or how it works. Is it a solenoid relay that is rapidly switched on and off? Feel free to educate me in the comments. I guess the moral of the story is to remove all pre-conceived notions when you enter a debugging task and question everything you don't understand. Or maybe it's just that you should check your pockets before putting your pants in the wash.

Wednesday, August 13, 2008

Open Office Stupidity

If you receive a document as an attachment, open that attachment, start editing, and then click save, guess what happens? You work is quietly saved in a file in /tmp. Guess what happens when you try to find that important file later? Sure, it shows up in the menu under File->Recent Documents, but when you select it, it has likely been deleted, as is the fate of most files left in /tmp for too long. Wonderful.

This happened to my brother-in-law (a non-geek who has successfully been using Linux for a couple years now, well, until now, I guess) a couple weeks ago resulting in the loss of some hard work of his, and I almost let it happen to me today. Couldn't we make our apps a little smarter? If it's running on a UNIX like system, would it hurt to make it aware that /tmp is not a safe place to save its user's files? Could it at least give people a little warning before doing so?

UPDATE: I don't know what happened, but I received an attachment today and Open Office 2.4.1 and Firefox 3.0.1 on my Ubuntu 8.04.1 system opened it read-only, with only a "save as" option available. It wouldn't even let me edit the document before doing the save as. This is excellent and exactly how I think it should work. For the record, a quick search leads me to believe that Firefox changed to save temporary files as read-only. One can only hope other mail clients do something similar.