Skip to content
September 14, 2011 / Rohit


Lately I have developed interest in AWS (Amazon Web Services). It, unlike Google App Engine, provides a REST based API to most (if not all) of its services.Having a RESTful API means easy integration with any language of your choice. If you don’t have SDKs for your language, then you should be able to use the REST API and work with the service or create your own SDK over the REST API.

Amazon’s cloud based storage service S3 also provides a REST API. For the past couple of days I was playing around with its API. Specifically, I was trying to write a Go wrapper for the S3 service. What I found was that the REST API just within S3 is pretty inconsistent.

Depending on what you want, the request parameters might go into the HTTP headers, the request URI or even the request body as XML. It is not evident which parameters go where.

Check the PUT Bucket Logging documentation to see what I mean.

September 13, 2011 / Rohit

Base 64 Encoding in Go

The Go language documentation doesn’t have enough examples. Here is one way to do it:

package main
import (

func main() {
        str := "Hello world"
        encodedStr := base64.StdEncoding.EncodeToString([]byte(str))
September 2, 2011 / Rohit

Go Pasty!

Yesterday evening I wrote my first ever web app using Go. It’s called Go Pasty! and is essentially a pastebin clone with lesser options. If you haven’t used pastebin, the idea is to to have a shareable URL which contains code/text provided by the user. So for example, if you want to share some code, instead of emailing the other person you can put it on Go Pasty! and share the URL with them.

The implementation is pretty straightforward and involves only validating and saving the user input in persistent storage. When the user requests a URL, the code tries to fetch the corresponding text and displays it with syntax highlighting.

The syntax highlighting is done with SyntaxHighlighter Javascript library. The storage is done using the app engine datastore. The complete source code is present on github.

August 29, 2011 / Rohit

Looking inside initramfs

If you are curious to look what goes inside your initramfs, do the following:

WARNING: Don’t clobber things in your /boot directory. BE CAREFUL!

1. Your initramfs will be present under /boot/initrd.img-2.6.XX.XX
2. Create a temporary directory and copy the initrd image there

 $ mkdir ~/temp
 $ cp /boot/initrd.img-2.6.XX.XX ~/temp

Insert your kernel version number in place of “XX.XX”

3. You will have to rename the initrd image to a gz so as to gunzip it. Rename
it by issuing the following inside the temporary directory:

~/temp$ mv initrd.img-2.6.XX.XX initrd.gz

4. Unzip the image

~/temp$ gunzip initrd.gz

5. The extracted image is a CPIO archive. You can extract the files and
directories out of it using.

~/temp$ cpio -id < initrd

6. You will be able to see the internal structure of the initramfs in your
temporary directory.

~/temp$ ls
 bin conf etc init initrd lib lib64 sbin scripts

7. You can run busybox by typing:

~/temp$ bin/busybox sh


August 10, 2011 / Rohit

Doing A Project Report The Right Way

I have been doing my project report for the last month and due to a combination of laziness and procrastination, I am still not done. Going through the process I have realized few things which I should have done.

  1. Log everything. When working through a project, especially which requires a report at the end, it’s always good to keep a daily log of what you did. It’s best kept at one single place accessible to whoever is working with you. All long email correspondence, long commit messages, hand drawn sketches, discussions should be documented in the log. A blog or a wiki will be ideal for this.
  2. Document immediately after completing a task. Time and again I have made this mistake of not documenting a piece of work, once it was finished. “Yeah, I will remember what I did”, “I have commented the important parts”, “This is trivial, who will forget it?” … Well ..”young stupid me, I have forgotten!” It’s best to document when you are just done, as opposed to later on. It’s still fresh in your mind and you will be able to write without effort. Don’t think that comments in code are sufficient to recollect what you did — you will still need to go through all the code and figure out how it works. These task level documents could become sections or sub-sections in your report.
  3. Start writing your report as soon as you begin the project. You should begin with an outline. Doing so will give some structure to your document and the work which you are doing. Your log (1) and task documentation (2) can be pruned so that they fit nicely into your outline. By doing this, when you are done with the technical work, the report is already done!
  4. Take it one paragraph at a time. If you, like me, didn’t follow any of the above 3 steps, then you are going to trudge and plod and struggle to finish the report. I like writing and in spite of that, I find it hard to make myself type the report at a stretch. One of the reasons is that the problem which I solved is now way in the past. The technical work was done 2 months ago and I wasn’t disciplined with documentation.
    If you are in this situation, the only way out is to do it little by little. Take a bite sized piece and work on it. It could be just a paragraph, a diagram, a graph or something else. Once you are done with that, reward yourself with some Facebook, frisby or chocolate, but then get back to another paragraph. It will take time, but  eventually you will see your document take decent shape.

Documenting is not rewarding in the short term, but in the future you will be proud and relieved that you did. I wish I could go kick some sense into the past-Rohit.

August 9, 2011 / Rohit

Converting PDFs to be Readable on the Kindle

Turns out it’s pretty straightforward to read PDFs on the kindle. You just send the PDF to your “” email with the subject “Convert”. Amazon will do the conversion and send the document to your kindle next time you sync.

And I went through all this effort for no reason. Bleh.

August 8, 2011 / Rohit

You and Your Research

I wanted to read the paper " You and Your Research ", by Richard
Hamming, on my kindle, but the font was too small. So I
took the HTML version of the paper, typed it into LaTeX and created a PDF with a
large enough font.

  • You and Your Research (PDF Version): Suitable for viewing on
    the Kindle 6″. Set the contrast to “Darkest.”
  • You and Your Research (LaTeX Source): If you want a larger
    font than what is there, change the line near
    the top which says


    to something like




    To get the PDF:

    1. Delete any *.aux files present from a previous run
    2. run
      pdflatex you_and_your_research.tex