Here’s to the crazy ones

I never had the privilege of meeting Steve Jobs. And yet, on hearing the news today, it felt like someone very close to me had died.

As someone I’ve followed from ever since I can remember – growing up listening to the stories of his showmanship and visionary designs, its hard to even remotely express the sense of loss I feel today.

Reading up on every book about him I could lay my hands on, watching liveblogs of new product announcements, and waiting with excitement at a WWDC or Macworld announcement – it almost feels like I actually knew him. And I think a large number of people from my generation share my feelings.

It is very rarely in a lifetime that you get to see someone like Steve Jobs accomplish the kinds of things he did – changing the very face of technology and entertainment as we know it. I’m so glad to have been in the valley to follow some of this first hand.

Here’s to the man who inspired an entire generation with his insane genius. And specially me.

Goodbye Steve. You’ll be missed.


For all of you who land on this site using the google query “nbdjs” – it stands for “No Big Deal, Just Saying”.

Courtesy of an ex Stanford post doc who shall go unnamed – you know who you are! :)

Mark Twain on Whiskey and Civilization

I found this gem of a snippet today, and I rather agree with what it says!

“How solemn and beautiful is the thought that the earliest pioneer of civilization, the van-leader of civilization, is never the steamboat, never the railroad, never the newspaper, never the Sabbath-school, never the missionary — but always whiskey! Such is the case. Look history over; you will see.

The missionary comes after the whiskey — I mean he arrives after the whiskey has arrived; next comes the poor immigrant, with ax and hoe and rifle; next, the trader; next, the miscellaneous rush; next, the gambler, the desperado, the highwayman, and all their kindred in sin of both sexes; and next, the smart chap who has bought up an old grant that covers all the land; this brings the lawyer tribe; the vigilance committee brings the undertaker. All these interests bring the newspaper; the newspaper starts up politics and a railroad; all hands turn to and build a church and a jail — and behold! civilization is established forever in the land.

But whiskey, you see, was the van-leader in this beneficent work. It always is. It was like a foreigner — and excusable in a foreigner — to be ignorant of this great truth, and wander off into astronomy to borrow a symbol. But if he had been conversant with the facts, he would have said: Westward the Jug of Empire takes its way. ”

Reading Java properties file in Clojure

A simple and effective way to read properties files in Clojure, since they transform into Clojure maps!

(into {} (doto (java.util.Properties.)
         (.load (-> (Thread/currentThread)
         (.getResourceAsStream "")))))

Next, to actually read this in, using atoms to swap the values like this seems to work,

(def *args* 
  (atom {:a 10, :b 20})) 

(defn -main [] 
  (swap! *args* assoc :a (read) :b (read)))

Decoding the US Military’s Cyber Command Logo code

From this Wired article here, it looks like there’s a number that is part of the cyber command’s logo – 9ec4c12949a4f31474f299058ce2b22a. Well, its 32 characters long, and looks like a hash. Sure enough, a quick python check later of the organization’s mission statement with md5 results in,

import hashlib
>>> hashlib.md5("USCYBERCOM plans, coordinates, integrates, synchronizes and conducts activities to: direct the operations and defense of specified Department of Defense information networks and; prepare to, and when directed, conduct full spectrum military cyberspace operations in order to enable actions in all domains, ensure US/Allied freedom of action in cyberspace and deny the same to our adversaries.").hexdigest()


Mutable vs Immutable datastructures – Serialization vs Performance

In my last post, I was playing around with methods to serialize Clojure data structures, especially a complex record that contains a number of other records and refs. Chas Emerick and others mentioned in the comments there, that putting a ref inside a record is probably a bad idea – and I agree in principle. But this brings me to a dilemma.

Lets assume I have a complex record that contains a number of "sub" records that need to be modified during a program's execution time. One scenario this could happen in is a record called "Table", that contains a "Row" which is updated (Think database tables and rows). Now this can be implemented in two ways,

  • Mutable data structures – In this case, I would put each row inside a table as a ref, and when the need to update happens, just fine the row ID and use a dosync – alter to do any modifications needed.

    • The advantage is that all data is being written to in place, and would be rather efficient.
    • The disadvantage however, is that when serializing such a record full of refs, I would have to build a function that would traverse the entire data structure and then serialize each ref by dereferencing it and then writing to a file. Similarly, I'd have to reconstruct the data structure when de-serializing from a file.

{:filename "tab1name",
      :tup #}
     {:recordid nil,
      :tup #}}>,


  • Immutable data structures – This case involves putting a ref around the entire table data structure, implying that all data within the table would remain immutable. In order to update any row within the table, any function would return a new copy of the table data structure with the only change being the modification. This could then overwrite the existing in-memory data structure, and then be propagated to the disk as and when changes are committed.

    • The advantage here is that having just one ref makes it very simple to serialize – simply de-ref the table, and then write the entire thing to a binary file.
    • The disadvantage here is that each row change would make it necessary to return a new "table", and writing just the "diff" of the data to disk would be hard to do.


So at this point, which method would you recommend?

Serializing Clojure Datastructures

I’ve been trying to figure out how best to serialize data structures in Clojure, and discovered a couple of methods to do so. (Main reference thanks to a thread on the Clojure Google Group here )

(def box {:a 1 :b 2})

(defn serialize [o filename]
  (with-open [outp (-> (File. filename)]
    (.writeObject outp o)))

(defn deserialize [filename]
  (with-open [inp (-> (File. filename)]
    (.readObject inp)))

(serialize box "/tmp/ob1.dat")
(deserialize "/tmp/ob1.dat")

This works well for any Clojure data structure that is serializable. However, my objective is slightly more intricate – I’d like to serialize records that are actually refs. I see a few options for this,

– Either use a method that puts a record into a ref, rather than a ref into a record and then use the serializable, top level map
– Write my own serializer to print this to a file using clojure+read
– Use Java serialization functions directly.


Ode to an Orange

A whiff of citrus – vibrant,
shiny, dimpled and thick,
your fingers move, probing
textural ecstacy,
as your tastes await
the sweet tartness within.
Peel away the layers
softly, envelop a piece,
let your tongue steep
in a myriad of flavors,
with the lingering scent
of summer under a blue sky,
look around,
and all is well again.

Stack implementation in Clojure II – A functional approach

My last post on the topic was creating a stack implementation using Clojure protocols and records – except, it used atoms internally and wasn’t inherently “functional”.

Here’s my take on a new implementation that builds on the existing protocol and internally, always returns a new stack keeping the original one unmodified. Comments welcome!

(ns viksit-stack
  (:refer-clojure :exclude [pop]))

(defprotocol PStack
  "A stack protocol"
  (push [this val] "Push element in")
  (pop [this] "Pop element from stack")
  (top [this] "Get top element from stack"))

; A functional stack record that uses immutable semantics
; It returns a copy of the datastructure while ensuring the original
; is not affected.
(defrecord FStack [coll]
  (push [_ val]
	"Return the stack with the new element inserted"
	(FStack. (conj coll val)))
  (pop [_]
       "Return the stack without the top element"
	 (FStack. (rest coll)))
  (top [_]
       "Return the top value of the stack"
       (first coll)))

; The funtional stack can be used in conjunction with a ref or atom

viksit-stack> (def s2 (atom (FStack. '())))
viksit-stack> s2
viksit-stack> (swap! s2 push 10)
#:viksit-stack.FStack{:coll (10)}
viksit-stack> (swap! s2 push 20)
#:viksit-stack.FStack{:coll (20 10)}
viksit-stack> (swap! s2 pop)
#:viksit-stack.FStack{:coll (10)}
viksit-stack> (top @s2)

Resolving Chrome’s SSL Error

I recently started getting a number of SSL related errors on accessing https links with Google Chrome on Ubuntu. One looks like,


The top link on Google’s search results is pretty fuzzy, so here’s the solution that works for me.

Go to Settings -> Options -> Under the hood, and enable both SSL 2.0 and SSL 3.0. This should allow Chrome to talk to the server with either protocol.

There’s also a DEFLATE bug that got fixed to solve this issue in release 340 something.