Adventures in Tech

Like many people, I love to read, especially when traveling and going on vacation. Because travel space and carry-on weight are always at a premium, I am forced to get a small book that I can carry easily with me. The choice of book is a gamble: either it will be an enjoyable hit, or a disappointing miss. In the latter case all is not lost, since I can usually buy another book at the airport, or at a local bookstore where I am at.  I have always wondered how nice it would be to be able to carry my whole library with me, and read the book of my choosing and mood. So when the Kindle came out, I was very excited, and bought one immediately. The promise of carrying my whole library in the digital device without incurring the weight was overwhelming. The Kindle did not disappoint: the screen was as easy on the eyes as the printed page, the battery life was fantastic, and the added bonus is that I could buy books all over the world and have them delivered wirelessly to the Kindle without

I have been an iPhone user for about 4 years now, but have recently been frustrated with the poor battery life on my phone especially with relatively moderate usage--I use the phone for the occasional phone-call or text message, and use it primarily for work emails. I grew tired of having to charge the phone multiple times per day, and started to look at other options. My coworkers have been pleased with the battery life on the Samsung S3, so I decided to give it a try. I went to the AT&T store, and upgraded my phone. Before I did, I looked at the iPhone 5, and while it is a beautiful design, I thought its screen size is a big disadvantage compared to the Samsung. My first impressions with the Samsung were not very positive: the usability is inferior to the iPhone, and things were not as intuitive or as consistent. However as I continued to use the phone, I discovered a lot of features that in my mind overshadowed the usability issues, and the phone started growing on me. Fi

I have always enjoyed physics and astrophysics, and the epitome of that enjoyment was attending a live lecture by the famous by Dr Stephen Hawking at the Flint Center yesterday. The event was roughly two hours, divided in three parts. First, Dr Hawking gave a fascinating exposition of black holes and the Hawking radiation, then his long time friend, Prof. Kip Thorne gave an excellent talk about his research on black holes. The sessions ended with a Q&A session dubbed: the best of Hawking. The event was sold out, and the Flint Center was overflowing with patrons standing up on the side to listen to Dr. Hawking. It is not hard to understand why. Dr Hawking is a world renowned physicist who can explain complex topics in simple terms that everyone can understand and enjoy. Because of his deteriorating physical condition due to ALS, most of the lecture and Q&A session were prepared--later on Kip revealed the reason is that the technology that Dr. Hawking uses to communicate all

At work we have been doing most of our development in Java, and it has been serving us quite well. For a new project that we started, we looked at other JVM based languages, that would help us develop a little bit more efficiently, as well as leverage the big code base that we have. Since a couple of people on the team knew Groovy and Grails, and have used it in the past to develop web applications, we went with that choice, and so far it has served us well. Development became a little bit more pleasurable, and we got rid of some of the Java boilerplate. Out of curiosity I started experimenting with other JVM based languages, and since a lot of my friends at other company were singing praises for Scala, I decided to play with that. The first step is setting up a Scala development environment, and with a couple of additions to my .emacs file, I got just that: For Scala development in emacs, you need a couple of things: scala-mode ensime You can download scala-mode from 

I have been using mutt for some time now as my primary email client, and have found that I have not missed using any of the more graphical interfaces like Mac Mail, or Gmail web interface. Not even to look at HTML emails, PDF documents, or Word documents. Thanks to a couple of open source utilities, I can convert these documents to text, and read them from within mutt, leading to a seamless experience, and a much more pleasant email workflow. The following lines in your   ~/.mailcap config file configure the utilities and do the magic: HTML emails text/html; links -html-assume-codepage utf8 -html-numbered-links 1 -dump %s; copiousoutput I use the  links browser to do the conversion from HTML to text. There are many other options to use, such as Lynx, or w3m, but I like links because it formats the HTML tables better than Lynx or w3m, and handles utf8 characters better. You can also turn off the html numbered links easily if you choose to. PDF files application/pdf; pdft

Big Data has been gaining a lot of press lately, and NoSQL even more. A lot of new software development is moving to using NoSQL databases to alleviate the scaling pains of traditional RDBMS systems when the data size grows very large. The NoSQL databases usually expose a simple key value based API, where you can set, retrieve, and scan values based on the value of the keys you're interested in. The API is sufficient for most applications, but sometimes you want more than the simple retrieval API; you want SQL, where you can join keys, and have more complex filtering rules. Here is where PiQL plays a role. Last week I attended a talk about PiQL by Michael Armbrust. In the talk, Michael introduced PiQL: a query system that runs on top of NoSQL key-value stores, and allows developers to write SQL queries that execute efficiently against the simple key-value retrieval API. The system operates in two stages: the first is the static analysis stage, and the second is the execution s

For the last decade I have used web based email almost exclusively for work and personal use, and in due course have accumulated a rather large email archive. Lately I have been traveling a lot, and started missing offline email, especially since the flights don't have wifi in general, so I decided to augment my online email with an offline one. My first choice was Apple Mail. The setup and mailbox imports were a breeze, and the interface is beautiful. However the mail client crumbled under the large number of messages that I have: color beach balls were a common sight, and the client seemed to leak memory--after an hour of use, the memory footprint was roughly 2.5GB which made matters worse. I had a similar issue with other mail clients, and while talking to a colleague at work, I remembered that I did not experience these issues with a very old mail client that I used before: mutt.  So I went back to set it up. Mutt is not for the faint of heart, but techies should feel at

I am not an Apple fan, but I do like their computers, and recommend them to colleagues and friends for a variety of reasons. They are well designed, and in addition to an excellent user interface, they run a flavor of Unix--which makes the life of computer programmers a lot easier. But most importantly, Apple's customer support is impeccable, that despite all the hardware issues I experienced in the past, I still recommend Apple computers. Let me explain why. A year and a half ago, I bought a Mac Book Pro for work. At the time it was the first generation unibody laptop, that had an i7 processor, lots of memory, and lots of disk space. Alas, like first generation models everywhere, it also had a lot of hardware problems. The most annoying of which was the screen randomly turning dark, with the hard drive spinning out of control. The only way to get out of this state was by forcing a reboot by holding down the power button, and losing everything I have been working on. At first

Not all of us are lucky to work with greenfield projects; the majority end up working with codebases that we inherit. These codebases have had their share of modifications that moved them away from the original elegant design: bug fixes, feature additions, and enhancements that were done in a hurry because of delivery pressure, without regard to code hygiene and future maintainability. The code then feels heavy, complex, hard to understand and more painful to maintain. There are a lot of ways to characterize code complexity, but the one that jumps to mind is "cyclomatic complexity" described by the McCabe paper from 1976  http://www.literateprogramming.com/mccabe.pdf .  The paper describes how to measure the cyclomatic complexity of different program control paths, and recommends a bound of 10 for manageable code complexity. NIST also selects the same number http://hissa.nist.gov/HHRFdata/Artifacts/ITLdoc/235/chapter2.htm . The numbers, despite being arbitrary, provide a g