I’ve used many languages for my scripting needs, but my favorite — believe it or not — is probably Bash. Bash may not have any types, and scripting with Bash may be fraught with pitfalls, but sometimes the problem at hand is solved most succinctly and elegantly with small focused programs that compose well.
Bash’s composition comes in the form of piping one program’s output into the next program. No program needs to know where its input comes from, just like Lego blocks don’t care what block they stack on. This is an incredibly useful approach. For instance, take a look at how easy it is process the contents of the clipboard:
pbpaste | base64 | pbcopy
We just base64-encoded whatever was in the clipboard (at least, on Mac OS X; Linux has similar programs under different names, and on Windows you may need to write your own versions of
pbcopy). You can use
pbcopy and the rest of the Bash toolbox to do whatever processing of clipboard text you have in mind, and thanks to pipes, you can do it very concisely. Read more on Plays Well with Others – Lessons in Reusable Tooling…
When I went to college, I had no idea how to take notes, so I did what I thought I was supposed to do: I wrote everything down. For four years of college, I wrote paragraphs and outlines of class lectures, and other than studying for tests, I never looked at those notes again. When I graduated and said goodbye to all those lectures and tests, I stopped taking notes. Life’s tests, after all, are open-book.
But last October I started taking notes again. Midwest UX was held here in Grand Rapids, and one of the workshops was titled “Drawing What You Mean – In Real Time”. The presenter, MJ Broadbent, revealed the secrets of a kind of note-taking I had never heard of. It was called sketchnoting, and I was shocked that no one had told me about it sooner. Read more on Doodles with Meaning – The Art of Sketchnoting…
Humans are story machines. We think in stories. We process in stories. We store in stories. When you add up all the television shows, movies, books, jokes, rumors, and gossip we tell, story-telling is in the running for our biggest industry. We require stories. We’re so hopelessly bad at dealing with information that isn’t in story form that we invented computers, which of course gave us whole new things to tell stories about.
We need stories because even with billion-word languages, there are still experiences we can’t express with lone words. Shakespeare wasn’t afraid to make up words, but even he resorted to tiny stories. Characters “fought fire with fire” or went on a “wild goose chase” or learned that “all that glitters is not gold.” Four hundred years later, we make up words at the drop of a hat, but we still haven’t come up with catchier ways to express the dozens of tiny stories Shakespeare inserted into our language.
“Accumulate idioms… The only difference(!) between Shakespeare and you was the size of his idiom list – not the size of his vocabulary.” – Alan Perlis
Unlike computers, the mind’s memory is also its processor. The stories we know affect how we think. Sometimes, where we don’t have a story, we have a blindspot. That’s why it’s valuable to accumulate metaphors, like cleaning dust from our mental lens. Stories help us perceive the world more clearly and more memorably.
As adults it’s easy to think we have the vocabulary we need, but just because we have the words doesn’t mean we have the stories. Here are a few perspective-shaping stories to get you started. Read more on The Proper Care & Feeding of Your Mental Story Machine…
Here are a few reasons to explore LiveScript. Read more on Graduating from CoffeeScript to LiveScript…
In Douglas Adams’s Hitchhiker’s Guide to the Galaxy series, an advanced civilization builds a supercomputer to calculate “the ultimate answer to life, the universe, and everything.” After millions of years of calculation, the computer finally gives its answer: forty-two. Despite being an advanced civilization, it succumbed to the pitfall of getting an answer without first understanding the question.
We often fall into the same trap. I once worked on a development team that practiced Agile programming. Every now and then the team would debate whether we were really practicing Agile, whether we should do more Agile, whether we should abandon Agile altogether, and whether we should adopt some other methodology. The debates centered on personal preferences and impressions of team productivity. Alternatives were suggested based on what the team had tried before and who had what certifications. Never did our conversations start with understanding what problems the various disciplines were designed to solve. Neither did we begin with the most important question: what problems were we trying to solve? We jumped straight to the answers without first understanding the question. Forty-two. Read more on Considering a New Methodology? First, Understand the Question…
I’ve spent a lot of time with D3 over the past several months, and while I’ve enjoyed it immensely, one thing had eluded me: saving visualizations as images. When I needed to turn a browser-drawn SVG (scalable vector graphic) into an image, I used FileSaver.js to save the content of the webpage’s SVG node as a file, then opened the file in Inkscape and rasterized to an image format. Unfortunately, this process often created discrepancies between how the visualization looked in the browser and how it looked in the final image.
While making a calendar as a gift over the holidays, I finally figured out how to save SVG content as an image directly from the browser. Not only is the workflow a lot smoother, but the results are much more consistent than processing the SVG through Inkscape. The core code for the process is laid out below, and the complete script is on GitHub. Read more on Saving Browser-based SVGs as Images…
For the last several months I’ve been pair programming every day, working with another developer on a Windows application. Both of us usually use Macs, so we’ve adopted a company Windows laptop to do the work, and as we’ve experimented with our pairing tools, we’ve learned a bit about how tools affect getting the job done.
Alternating Mac & Windows, Dvorak & Qwerty
When we started on the project, my pairing partner and I sat with our Macs in front of us and the Windows laptop in between, pushing the PC back and forth depending on who was driving. The keyboard and trackpad were unfamiliar, and despite weeks of using them, we still only tolerated them, frequently sighing at clicks we didn’t mean to make and keys we didn’t mean to hit.
Read more on Adventures in Pair Programming – 2 Devs, 3 Computers…
The ability to know what day of the week a given date falls on is usually associated with savants. But with a little memorization and some arithmetic, anyone can do the same. There are several techniques, some requiring more memorization than others, some requiring more arithmetic. The technique in this post requires memorizing 12 single-digit numbers for the year you’d like to use it on, but it requires less calculation than alternative methods (such as this one). Read more on Mental Math Tricks — Find the Day of the Week a Given Date Falls On…
One of the most visible parts of Atomic Object is this blog, Atomic Spin. Untold numbers of potential clients and employees contact us because of what they read on Spin and what high regard they have for it.
Spin’s success isn’t an accident; it’s a group effort. Everyone at Atomic is asked to contribute regular posts, and though it may be unusual to ask programmers to write, it’s more unusual to have so many programmers who are so good at writing. One of the things that sold me on working for Atomic Object was how well their programmers expressed themselves on the company blog.
Programmers aren’t natural-born writers. Some love to write, but others are happy to express themselves solely through code.
Spin isn’t a good blog because Atomic is made up of unusually good writers. Spin is so good because Atomic is made up of unusually good programmers. Like good writers, good programmers insist on expressing their ideas as clearly as possible. Programmers use code, and writers use language, but the underlying skill is the same. The medium is the easy part. The hard part is learning to express yourself. Read more on Hackers & Writers – Practicing the Non-Linear Arts…