Since learning Clojure will most often require a lot of experience in coding in Clojure, a practical consideration for any new learner will be having an effective environment for editing code, testing, deploying, etc. On the Clojure development (developer?) website, there are instructions on getting started with Clojure. I believe that these instructions are intended to be the official help resource for everyone, and people are making good effort to keep it up-to-date and authoritative. My attempt, with this post, is to formalize what I know, and then contribute over to the official documentation whatever others might find a useful addition.
People lavish praise for Apple’s attention to design details and the lessons from Steve Jobs (the good ones, at least). But it’s odd to see when those ideas don’t translate into what we expect. When it comes to designing things well, the earbud market seems to me like an Apple and a bunch of PC makers. Are most earbud makers aware of their lack of quality, or are content to take advantage of consumers’ naivete? Within the first minutes of using the Polk Audio Ultrafit 500 earbuds, I had made up my mind that these guys (Polk Audio) have actually done a thorough job in designing the earbuds, and I already had started to make up my mind just from opening up the package. My claims are a little over-the-top, so let me explain.
There are many ways to dabble in Clojure. My approach has been to read something, retain some fraction of it, and then repeat this process until those fractions equal a whole. When stepping into functional programming for the first time, especially after OOP, it’s not easy to grasp it right away. Sooner or later, the ideas will stick, right? That means learning in multiple passes, where some deeper level of understanding happens during each pass compared to the last. Kind of like iTunes Essentials with “The Basics”, “Next Steps”, and “Deep Cuts”. So that is what I want to present to you, in an ordering that will minimize your difficulty along the way.
Previously, I’ve created an episode of the online lectures for secure shell. I also wrote the initial code for the episode using phylogenetic trees, although it got re-written by Greg. So I was more like just the narrator in that episode, but now I know how triangular matrices can be handled by maps. It’s always nice when you can work alongside smart people and can imbibe some of their knowledge and wisdom.
For a while, now, I’ve been trying to explain to people what makes someone effective — productive and efficient to do programming and/or science research. Until very recently, I was working in a genetics research lab, and I was asked by coworkers about what it takes for someone to be productive. Whether it was in terms of programming productivity or ability to intuit scientifically, I had been on both sides of the non-/productive divide. I distilled the differences to being resourceful and resolved.
Everything in technology seems to increase in exponential fashion. There’s the ever-quoted Moore’s Law, where CPU speeds seem to double every 1.5 years. RAM capacities and HD capacities seem to follow this rate, although the correlation might be coincidental more than anything else. However, network speeds have barely increased in the past decade, it seems. The boon in high-tech, high-throughput technological advancements in modern genetics labs is also a bit of a curse. As the New York Times reports in DNA Sequencing Caught in Deluge of Data:
Ubuntu has rolled out with version 11.10 of its distribution (or should we say that Canonical rolled out with Ubuntu 11.10?). This is the second release that features Unity front and center, but unlike 11.04, there is no backup option to allow users to drop back to GNOME 2. To make matters more complicated, GNOME has pushed GNOME 3, also similar to Unity and a complete break from the GNOME 2.x line of desktops. Just as the options for Linux desktop environments is growing confusing quickly, so, too, are the options for a stable, functional distro itself.
You’ve got to love the “Berkeley way” of doing things. Not that citizens here think that they’ve really cornered some secret of how to live. They’re just very conscientious and considerate of their place in the world. They live well, but they also let live just as well. Here’s how some things go in Berkeley, and some of the local tips I’m learning as I’m getting myself set up.
SourceGear is a company that I’ve never heard (until now) that works on version control software. Eric Sink is the founder of SourceGear, and he has recently written and published the book Version Control by Example. I came to hear about it perhaps as many others who have seen it already would have — he is giving this book away for free (shipping costs covered), and as his FAQ page says, there are no string attached.
The book covers the history of Version Control Systems (VCS), the terminology and common feature sets, examples of each of those features (in Apache Subversion, Mercurial, Git, and SourceGear’s Veracity), a discussion of how to use a VCS effectively in practice, and details about how VCS’s work internally. Through following VCS’s throughout history, we are introduced to additional VCS features in a context that easily explains their motivations.
When evaluating Microsoft’s long-term strategic positioning of its core business over the past decade, it is clear to see the cracks that have been forming in a dominating mainstay of the computing world. And it is an instructive story, and one still in the making, about how fast things (businesses, trends, ideas, etc.) can be built and how they can erode just as fast.
And of course, part of the story includes Bill Gates’ decision to bow out, and the ascent of Steve Ballmer’s ascent, notwithstanding the antics, rages, utterances, and more antics. But one utterance I want to pick up on is the one that “Linux is a cancer”. Really?