Sending end-to-end encrypted emails using Thunderbird (OpenPGP).

Mozilla Thunderbird makes it extremely easy to send end-to-end encrypted emails using OpenPGP. In order to do this, both the sender and the receiver will need to generate a secret and public key pair using the Thunderbird email client. Here are some of the steps to follow (by both the sender and receiver):

1. Click on the Account Settings -> End-to-end encryption for the account you wish to configure as shown in the screenshot below:

2. Click on Add Key as shown below

3. Next, Thunderbird allows you to create / import a Personal Key for your email account. In my case, I don’t have a key yet, so I will choose the first option and click on the Continue button.

4. Generate the key. I have set the key to not expire, and increased the key size.

5. Confirm that you want to generate the public and secret key.

6. You will receive a confirmation indicating that the secret and public keys were generated successfully.

7.Open the Key Manager (see button on the bottom left corner of the screenshot above)

8. Click on FIle -> Backup Secret Key(s) to file.

9. Enter a password to protect the secret key and save it. You can later import this secret key into an email client such as Thunderbird on another desktop.

10. You can also Export your public keys to your desktop or email them to a friend from the Key Manager.

DO NOT SEND ANYONE YOUR SECRET KEY OR THEY COULD READ ALL YOUR ENCRYPTED MAILS.

11. The next couple of steps are the easy part. Let’s take a look at the sequence of steps for users A&B who have generated their secret & public keys.

• A and B exchange public Keys via email (this can be done from the Key Manager ->File -> Email public key)
• A imports B’s public Key and accepts it as a verified key after checking the fingerprint either in person or via another app (not email).
• B does the same on his end.

12. When sending an encrypted mail, first type the recipients email address and subject, then click on Security -> Require Encryption. Also choose to digitally sign the message (Enabled by default). You can also encrypt the subject (recommended).

The email will look like a black box to your email server as the contents will be encrypted. See snapshot from Gmail below.

David Allen’s list of cool/convenient lists to have

Sourced from the GTD Times page. Pasting it on my blog because I need to reference it, just in case the original link/data disappears. There are quite a few valuable articles on the GTD Times web page.

There are critical reminder-type lists that we all need to let our brain relax (re: outcomes and actions). There are other lists, though, that can be useful, fun, and interesting, that fit in the area of “reference” or “support.”

• Account and $ numbers- credit card #s, PIN #s, etc. (make sure wherever you keep these, it is safe and secure.)

• Affirmations- personal self-talk scripts for positive internal programming.

• Basic personal numbers (self and family members)- drivers license, social security, insurance policies, Whatever you may need for yourself and others when filling out forms. (Again, make sure wherever you keep these, it is safe and secure.)

• Birthdays- (if you don’t put them on your digital calendar system), group by date, as reviewable (those during a month, put in tickler for that month, etc.)

• Borrowed stuff- things you’ve loaned folks and might care to get back someday.

• Checklists- Travel, Take sailing…, Personal New Habits to Create, etc.

• Gifts- organized by people and/or a general list of neat things to buy for others. Great for birthdays, ad-hoc niceness, and holidays.

• Ideas I don’t know what to do with, now that I’ve had them…- we all have them, and they don’t fit anywhere except in an “they don’t fit anywhere” place.

• Jokes- the current ones that you’d like to get some more mileage out of (but damn! they disappear out of our brain so fast.)

• Might wanna buy…- could be one mega-list, or (more commonly) grouped by the type of thing it is: cds, wines, books, videos.

• Might wanna do when…- possibilities when you’re in a certain location or doing a certain activity. By city, country, or region (things to do/think about when I’m in Napa Valley, London, Santiago.) Or by activity (Web surfing places to visit.)

• Might wanna do with…- if you’re into any animate or inanimate objects: my kids, my spouse, my dogs, my piano, my woodcarving tools, my garden, my computer.

• Previous addresses and employers- keep at least your last three. (What a pain when you have to supply them and you don’t have them!)

• Quotes- quotes I’d like to see again from time to time.

• Restaurants- for business or pleasure, to review for ideas instead of same-old same-old.

• Style or product numbers I may need when I’m buying things- oil filter, vacuum cleaner bags, labeler cassettes, etc.

• Tips/Shortcuts- speed-key codes, shortcut codes for new systems (voicemail, answering machine, pager, software apps, new Palm III, etc.) Any new skill set you’re learning can have a remind-me-about list specific to its features and activities until they are habitual and under your belt.

• Vacation things to do- those things that you might like to do if you are into seriously doing nothing (take pictures, hike, hotels to stay in for a night, spa treatments, places to explore, etc.)

Back to blogging…

Its been a long time since I posted anything on this blog. There are many excuses that I can give….I was busy with my new role at Vonage. I was busy trying to figure things out and find out how stuff works..I’ve been looking for a new place to stay….so on and so forth….But none of that is really true. I guess I just got bored of blogging for a bit…and allowed myself to spend more time watching movies or just lazing around in the evening. So now that I have resumed blogging and will keep at it(hopefully), here’s an update of things that changed since I last blogged.

1) I moved to the Software Engineering team at Vonage about a couple of months ago and have been working on quite a range of extremely interesting projects, and have learned new software development tool called Ab Initio. I like the tool and the philosophy around which it has been built…so that’s nice. The team’s been treating me pretty well and I enjoy my work.

2) I will be relocating at the end of this month. It’s slightly farther away from work, but that’s fine…I like the place better.

3) I’ve become active on Facebook. I find it a lot more appealing that Orkut (which I’ve almost given up on). Some people consider social networking sites to be a waste of time. I think that it’s nice to see the lighter side of your colleagues and friends in an environment that is much more relaxed and casual than work. At the end of the day, you see that your colleagues are as human as you are, and it goes a long way in establishing better work relationships as well :). I’ve also been able to reconnect with quite a lot of my old school friends, some of whom I haven’t spoken to since quite a few years.

4) I’ve also restarted viewing Ted talks (www.ted.com). I’ve been an ardent follower of Ted since they launched and all through grad school, but somehow got distracted in the middle. Ted keeps me inspired 🙂

5) It has also been a long time since I visited Baltimore. I used to drive down almost every weekend (3.5 to 4 hrs each way) but put that off recently due to a variety of reasons. Look fwd to heading there this weekend.

I’ll save more for another blog.

So, what do I work on?

My job title says “Production Support Engineer”. A manager from another team once quizzically asked, “How does your title connect to what you actually do here?”. I thought, the word “Engineer” must have come from the fact that I have a Masters degree in Electrical and Computer “Engineering”. The word “Production” must have been a result of the production databases that my reports connect to, and the word “Support” must have come from the fact that supporting the processes that generate these reports is a part of my job.

I work in the Database reporting team at Vonage. We support about 500+ perl/unix processes that connect to a wide variety of databases(Oracle, PostgreSQL, MySQL, Vertica) and provide our management data that is required for their key business decisions. Actually, we don’t just ‘support’ them. 90% of our time is spent in development of new reporting packages. The dev, testing and production of these packages is entirely handled by our team. Given that the data is in various locations, most reports that we design connect to multiple sources, perform background ETL using Perl and present the data to the end users in a seamless manner. Mostly we use Perl for cronned jobs. Nowadays, I use Pentaho’s ETL tool (PDI / Kettle) for expediting adhoc reports. My supervisor (Scott Macfawn) sometimes says…”Pentaho to the rescue”, and it’s true. The tool that you use doesn’t matter if your head is just about to roll. I’ve been recently trained on Ab Initio and Oracle BI EE too and will be using them in the near future.

Some one once told me, “All you do is embed SQL in Perl code”. What’s so hard about it? I smiled :). If a software developer writes bad code and releases it into production, the software might cause maybe one system to crash. The next patch can fix it. On the other hand, if I write bad code and push it into production, a database might come crashing down, affecting the millions of phone customers that we have. Usually I touch (or should I say hit?) multiple production databases, so the effects can be disastrous. Code and resource optimization become critical.

Each day is different. Some pass along smoothly. Others are roller-costers with cases escalating very quickly to senior management about report requests submitted today but were needed to be completed and released into production yesterday. I get to talk to senior management and work with them on their report requests. Most people live their lives in cubicles, completely unnoticed. I am glad, I don’t. There’s a level of confidence that comes with knowing that your work gets converted into action. It makes work, well more interesting.

What is the next action?

Most people, like me, have received a lot of advice over the years. Many have been extremely useful and implementable, others not as much.

The best form of advice that I have received from anyone (David Allen’s GTD book) has been the practice of asking, “What is the next action?” and immediately writing down both the result/outcome and the next action associated, whenever I need to get something done. At home, the next action could be as simple as getting out of bed early in the morning or logging in to my e-statements, to generate the list of payments that are due. If I am unable to sleep because I am stressed over something, marking the next action down on my calendar for the next day as an appointment is all that it usually takes to de-stress. If this doesn’t work, my mp3 player and headphones come in handy and music comes to the rescue and stops the otherwise never ending chatter.

No matter how complicated the situation is, this comes in handy. At work, my projects move on faster as it has become almost second nature for me to keep asking this question over and over again. Unless the result / outcome is not clearly defined and the next action is not written down, I usually don’t start working on tickets. We use a ticketing system at work, for our reports. Some times, I see half baked report requests ending on my queue. In such cases, the requestor has a vague idea of either what he needs, what is available, or in some cases is extremely busy to clearly define the requirements. In this case, the next action is usually just to schedule an appointment with him to clarify the requirements. Many times, my manager has already clarified the requirements so it makes things easier, but otherwise, I find this approach extremely useful.

So the next time you hit a brick wall, try the following steps

1) Ask yourself, “What is the intended outcome?”

2 ) Write it down

3 ) Ask yourself, “What is the next action?”

4) Write it down and then work on it until it gets done.

5) Repeat steps 3 and 4 until your project gets completed.

For a more detailed explanation on how and why this works and many more cool tips, I would suggest reading the book, “Getting Things Done” by David Allen.

Cubicles, knowledge workers and headphones.

Gone are the days when each knowledge worker had the luxury of an office.   Back in India, my dad had provided me with the luxury of having a big room for myself,  where I could lock myself up and work when required. I could play music as loud as I wanted late into the night without affecting my dad sleeping in the next room. I believe that these luxuries never spoiled me but really gave me an edge over some of my friends who needed to step out of home for entertainment.  I did well in academics, cracked the GRE and TOEFL and joined UMASS for my Masters in Electrical and Computer Engineering.

When I first walked into my cubicle (or office) in the VLSI research lab at UMASS Amherst, I felt very uncomfortable and uneasy. I had never worked in a cubicle before. Most research labs and workplaces are cubicles separated by thin partitions. I had entered a world where my attention was distracted by anything that moved. And why not? Your neighbor’s visitor is your visitor. You can hear the discussion and hope that it ends quickly. His cell phone rings and he talks loudly, with little understanding that you are trying to get work done. Over a period of time, I got adjusted to this new environment, well before joining the corporate world.

At work, from where I sit, I immediately know if there is any communication happening in any one of the 31 cubicles that are around me. That simply means my distractions are multiplied 32 times , including mine. Is that bad news?  Not necessarily.  How do I ever get work done? Let me explain.

Walk  into any software development company. I am sure that  you will find at least one developer punching away on his keyboard, blissfully unaware of his surroundings, with his ears surrounded by headphones. At UMASS, I have seen some senior professors doing the same. While it is very easy to assume that the person is whiling away his time, some of the most productive students in my computer lab at UMASS used to spend long hours listening to the radio while working on their research projects. Do you see a trend here?

I believe that headphones are our way of isolating ourselves from all the confusion, distraction and chaos around us. Instead of hearing all the noise around, why not listen to some music?  Reduce the total number of distractions from 32 to 1 .  Tune into a radio station and start programming.   Since it is a radio station, I cannot control what is being played and that is why I think it works.  Any given day, I would chose a radio station over an mp3 player. I can work for as long as 5 hours with music on. Most of the times at the end of the session, I can’t recall even one song that was played.  The focus on work is intense and my work gets done quickly. Sound’s awesome? Try it out and let me know if it works. One awesome channel that I would recommend is 102.7 FM (New York). If you are connected to the internet, you can listen to this channel online at http://www.fresh1027.com/

If you are a manager, it might help trying to ignore the headphones on your employee’s ear, as long as he / she generates results. With that little extra freedom, his / her productivity might soar and you get increased employee work satisfaction in return.

PS: I wrote this article while listening to music. I am not sure I would have written something as long as this otherwise. Something would have distracted me in between and this article would have been truncated to about 1/5th of it’s current length.

The wipers stay up…

It’s been snowing quite frequently now in New Jersey. Yesterday there was a snowstorm. It took me some time to dig my car out of the snow from home and almost ended up falling on my rear in the process. When I reached Vonage, I noticed something peculiar about a Toyota Siena parked in the lot. It had it’s wipers up. I looked at it for a split second, shrugged and walked along.

The temperature setting in my car is set to 75 degrees Fahrenheit and after spending about 45 min in that temperature, stepping outside into the freezing cold can be unnerving. Suddenly I wanted to be the employee of the month. Why? Simple. There are 4 parking spots reserved for the employee(s) of the month, all extremely close to the entrance. Rarely have I seen any cars parked there.

As I walked towards the entrance, I couldn’t help but think about the upright wipers. Then suddenly it struck. The owner of the car was a smart guy. Once it snows and the ice sticks on the windshield, it takes some effort to scrape it off.  The friendly wipers now come in the way of the cleaning. They might get damaged.  Also, driving on the road with wipers disabled by ice chunks over them  can be extremely hazardous. Why not avoid it altogether? Before it starts snowing, raise the wipers. Come back from work, clean the windshield and lower the wipers. Clean quickly and get into the cosy car.

I dashed back to my car and raised my wipers. That evening, I had a smile on my face as I cleaned the windshield.

Flat….well almost

It snowed through yesterday and when I walked towards the car this morning around 8:15 am, I wasn’t very pleased to find it covered in snow. My car seems to have an attraction for snow as much as I hate it. I wonder how I pulled through 3 years in Massachusetts during my Masters, where winter starts early and ends late. Back then I didn’t have a car and envied those who did. Well, the grass always looks greener on the other side doesn’t it?

I was however well equipped this morning and had the right tools for excavating my car from the snow dump. It took me a good 30 min to clean up my windshield, top, windows etc and before the car could be driven. As I pulled out and accelerated on route 18, I felt that the ride was not very smooth. Usually my car rides really smooth and has a pretty good shock absorbing system. Anyway, on the way back from work, I stopped by Sears and requested them to check my tires. It looked ‘OK’ from the outside..but when he took the reading, both the back tires had about 7 psi left in them (the normal should be 32 psi ) …that could be extremely dangerous at the speeds at which we drive here. I found this to be very interesting (actually annoying) coz I just had the tires checked when I went in for an engine oil change a week ago.

Read this article for more info:

http://www.trustmymechanic.com/tire_pressure.html

Anyway, nothing happened en route and here I am. But the first tool that I am going to get would be an air pressure sensor. Folks, check your air pressure more often. Particularly, if your car has radial tires like mine does. The appear slightly deflated even when they have the right air pressure, so its tough to know the difference by just looking.

Prof. Randy Paush

Late last night, I came across an interesting youtube video called, “The Last Lecture” by Prof. Randy Paush. The title intrigued me and soon I found myself reading / watching / gathering as much info as I could on him. His sheer will power and positive mindset during a terminal condition simply amazed me..I have added both his lectures to my video collection, so I can refer to it when ever I need to feel better.

Here’s my fav. quote from the speech

“The brick walls are there for a reason. The brick walls are not there to keep us out; the brick walls are there to give us a chance to show how badly we want something. The brick walls are there to stop the people who don’t want it badly enough. They are there to stop the other people!”

-Atchuth.

Legacy junk code

Sometimes you get handed over some code that is just plain junk, and you have to support it because it serves some purpose.  These kind of codes are very easy to identify, bad spacing, hard coding of values instead of using parameters, very little comments …if any at all, and most importantly huge chunks of glob that are there…for no useful reason.The glob of code could be a function that was written eons ago, but then the business requirements changed and it is no longer needed. Typically in such a case, one would remove both the function and the statement calling that function. In this case, the genius decided to remove the calling statement, but leave the function cleaning for a lesser mortal to do.

I was handed over one such masterpiece earlier this year, in which all that was required was a “very small change”. By the time I scanned the code, I knew more or less that this going to come and bite my back over and over again. Usually, I can tell what a program does by just parsing the subroutines in the code (this is Perl by the way) and identify where they map to in the main subroutine. In this case, since it was so much glob, there was very little I could make out directly. Also, the code had no indication about the ticket request that came in, so there was little reference to any documentations/ discussions that might have happened between the report writer (Yes, we write business intelligence reports)  leave alone the original request itself.

So, I cleaned up as much as I could, made the modification as requested  and tested and sent the report for installation. And it has come back to me…..to be corrected again. Now, I need to look it up all over again to see where the discrepancy is. Wish my luck 🙂

Anyway, complaining doesn’t do any help, does it ?. Here are a few tips that I learnt in my software engineering class during my Masters. I try to follow them as much as feasible, so somebody who reads my code does not have to break his head against the wall and applaud my moronism (I made that up)

1) Break the code into small parts. If each module fills up more than one window screen, then it is  probably too much.

2) Comment as much as you can. Comments can really help in deciding whether you code stays for ages or gets tossed out of the window the day someone figures out what it is trying to do (if they ever do).

3) Please, please keep as much links to the related documentation as possible. What were the business requirements that this code was originally designed for? How did it change over time and most importantly why?

4) There are many more I know, I leave the rest for the readers to contribute…I know that there are tons of readers out there who write much better code than I do.

Thanks,
Atchuth.