November 24, 2011
One of the many neat features of VIM is support for remote editing. The Vim command is simply:
:edit scp://username@hostname/directory/path/starting/in/home
If the scp:// protocol wasn't already a give away, VIM uses secure copy (scp) to edit remote files. This means many of the same tricks used with scp on the command-line can be used inside the Vim command.
Instead of typing in a password every time, use ssh private/public keys and ssh-agent. Or utilize aliases and settings defined in ssh configuration files (~/.ssh/config).
So a quick edit of the hosts file on a remote server named tux is as simple as:
:e scp://tux//etc/hosts
November 17, 2011
Lisp is quite common in Computer Science. As a nearly "syntax free" language, it is an excellent language for explaining computational concepts. Although it is quite common to see the Lisp dialect Scheme (or a equally trimmed down pseudo-lisp) used, there are some great texts written in Common Lisp, a few still in Emacs Lisp, and increasingly more in Clojure.
Since the goal of these texts is to be illustrative of concepts, not vocational in teaching a particular dialect, even small pieces of time spent deciphering syntax differences is wasteful. The best resource I've found for the fellow academic minded lispers out there is the Hyperpolyglot Lisp reference table.
As someone who learned Scheme in The Little Schemer and continues to use it while working through Structure and Interpretation of Computer Programs and The Seasoned Schemer I've found the Hyperpolyglot reference table to be very helpful while stepping out of Scheme and into papers written in other dialects, like many of Paul Graham's that use Common Lisp.
At the end of the day its the concepts that matter, and any tool that can cut down on distractions like syntax, is well worth it.
November 12, 2011
I frequently buy eBooks on any topic that peaks my interest. But when I want to learn something in earnest, I buy a print copy and lug it around with me.
I underline, make margin notes, test things, and make long lists of things to come back to and practice later. It's an excruciatingly slow process.
Even then, my mind is far from a steel trap - in fact it's more like a sieve - so I frequently have to refer back to old notes and supplement gaps with the more modern methods of Google'd articles, Stack Overflow posts, and recorded presentations on InfoQ.
But in the end all notes and practice works in a lasting way. The truth is learning requires hard work. While it's important to work smarter, you first have to be willing to work hard and grind it out when the going gets tough.
Head down, power through. It's the luddite mantra.
November 2, 2011
Alex Tabarrok's recent article College has been oversold travels over some familiar ground. The gist of argument is undergraduate college students need to focus more on practical sciences than liberal arts. Or as Alex says, "going to college is not enough. You also have to study the right subjects."
I find this focus on immediate practicality short-sighted and unfortunately all too common.
The value of an undergraduate degree is more than vocational, it is about teaching life long skills as young-adults transition into adults. Skills like critical thinking, communication, self sufficiency, and research/study skills are just as important, if not more important, than the specific major they are studying. These are the tools that over a lifetime transcend specific careers and keep the doors open transitioning to new ones.
As college tuition rates rise the drum beat of "do something practical" grows louder. I'm not advocating a path of extreme liberal arts, but rather no matter what major a student pursues it is important to cultivate personal development skills just as much as knowledge on a particular subject. The truth is the world doesn't need more computer science graduates. It needs more hard working people passionate about what they do.
October 24, 2011
Man pages are an invaluable tool in the Unix eco-system. Providing both a starting overview and a deep-dive future reference, what you need to know about a command is only a $ man <command> away. But there are times when the man command doesn't provide all the information needed.
Many of the most common Unix commands like alias, cd, and set are contained under the singular man entry "built-ins". Cases like these try help as well. It follows the same basic structure $ help <command>. Though help is intended to provide simpler summaries than man, many entries still cover important details like command flags for built-in functions. If there isn't a man entry at all, it is unlikely there will be a help entry as well. But it's worth the quick checked.
Also, don't forget about the apropos command. It's great for trying to find a new or forgotten command. Since it's available on the command line it can be quicker than looking up a reference book or a Google search.