kunalb

Joined 16 years ago

Karma

Submissions

Member since

Sep 24

http://explog.in

View on Hacker News

Recent submissions

Comment · 13 years ago

For clojure, I'd actually recommend using light table. From my experience with the latest dev versions, the learning curve isn't hard at all and immediately having your code evaluated is pretty powerful and intuitive. [I started learning clojure recently as well]

Comment · 13 years ago

True -- any visualization that doesn't get the message across is just about useless.

Luckily we have very tight feedback loops -- and I can push new versions every couple of hours so I can customize it really fast to suit their needs/mental models.

Comment · 13 years ago

I disagree with this post: there's another use case for visualizations -- consuming data as fast as possible to take action (eg firefighting). I work on tools for engineers, and I've found that a rich, non-standard visualization that people can learn to parse quickly after a tiny bit of initial acclimatization -- but showing them exactly what they need can help a lot.

Comment · 14 years ago

I just tried the Beethoven intro lesson for guitar -- first off, these are awesome for me as an almost-n00b guitar player!

Two suggestions:

- When you're holding really long notes the interval to see the next note is really small [the tab moves forward only once the long note ends so you don't have as much time to transition your fingers because you don't know/remember the next note; while in practice these should be the easiest transitions]

- Indicate the note lengths as well in terms of fourth or eighth notes, for those of us who like to count along.

Comment · 14 years ago

My attempt at hammering the xkcd servers -- also colours missing tiles correctly (black/white depending on south/north): http://explog.in/xkcd.html

[edit: basically lays everything out in a single huge page so that you can scroll instead of dragging]

Comment · 14 years ago

For those who don't tweak their toolchains spending one chunk of time and forgetting about them is obviously better than doing nothing else, but personally I recommend continuously evaluating what you do on the shell (well, obviously this can be generalized, but I won't go there) and tweaking away your pain points and repetitive tasks.

Some specific recommendations --

- Keep a version controlled `dotfiles` folder, link important files to it and share it across dev envs.

- Add shortcuts to modify your vimrc (<leader>v) and apply it (<leader>V) to help you tweak fast and get instant feedback.

- Using an approximation of REPL for any work I do has been the single largest productivity boost I have: minimize keystrokes between (Write Code) <> (Build/Compile/Run/Whatever/Get feedback) <> (Write code). I started using vimux recently (lets you run commands in a split pane without actually leaving the pane with vim installed) and have never been happier.