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.
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. ”
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()
'9ec4c12949a4f31474f299058ce2b22a'
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.
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?
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 )
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.
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.
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]
PStack
(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> 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)
10