bgror

Oh My Zsh gets an auto-updater »

Created at: 01.10.2009 05:21, source: Robby on Rails, tagged: programming zsh bash terminal project

I wanted to publically thank everyone for helping me get Oh My Zsh out there and continue to improve it. Many of us spend a lot of time in our terminals throughout the day and I firmly believe that having a well-working shell is nearly as important as having a well-working texteditor.

While Oh My Zsh isn’t a large project, it is my attempt to share what I’ve learned about using zsh with others… but honestly, my goal is to learn from you. I don’t have a lot of time to really dive into the deepend of the zsh-pool so am relying on others to share their tricks, hacks, functions, themes, etc. So, I thought that if I created a basic framework with outlined some conventions so that others could contribute, that perhaps I’d end up with a kickass shell.

So far… Oh My Zsh has been forked on github 25 times and is being watched by over 100 people.

Last week, I pushed out an update that introduces an auto-update feature. I’m quite keen of desktop applications that can auto-update themselves, so our initial version of this feature will ask you no more than once a week if you want to check for updates. This means that as we continue to extend and improve Oh My Zsh, you can keep up-to-date.

Uploaded with plasq’s Skitch!

It’s the beginning of a new month… are you still using Bash? Perhaps you’re using your own zsh configuration but want to see what else zsh can offer you? I invite you to install Oh My Zsh today. :-)

Just run this in your terminal and you’ll get setup. Don’t worry… you won’t lose your existing configuration. :-)

wget http://github.com/robbyrussell/oh-my-zsh/raw/master/tools/install.sh -O - | sh

For more infromation, visit http://github.com/robbyrussell/oh-my-zsh/

There is no magic, there is only awesome (Part 2) »

Created at: 25.09.2009 17:15, source: the { buckblogs :here } - Home, tagged: Essays and Rants awesome keynote programming talk

This is the second article in a series titled “There is no magic, there is only awesome.” The first article introduced the “four cardinal rules of awesomeness”.

If you’ve ever watched someone make string figures, it’s pretty obvious that the tool set includes a loop of string, and your fingers. But if you haven’t played with string figures much, you might be surprised to learn that you’ve got a lot more than string and fingers at your disposal.

There are figures that require the use of your wrists to hold the string. Some require you to use your lips, teeth, tongue, or nose. I know a few that use the neck. There are some that use the elbow, knee, foot, or toes. A few require you to set the figure down on a flat surface to manipulate it.

There are many figures that require the use of another person, or several people. Some figures actually require multiple strings. Some require additional props, such as sticks.

Different figures might require different types of string. Some, like Eskimo figures, work best with a thicker, shorter, stiffer string, while those of the Pacific islands tend to prefer longer, more supple and slippery strings.

With so many variables, and so many ways of combining them, how then does one ever excel at string figures? Is it hopeless?

Of course it isn’t. As with any other activity, there are simply a set of tools to be employed, and the expert will be well acquainted with them. It’s rule #1 of being awesome: know thy tools.

Knowing vs. Knowing

But what does that mean? It certainly doesn’t mean just “knowing what your tools are”, otherwise you’d all be on your way to string figure mastery, just by reading the above paragraphs. Knowing your tools necessarily means knowing, deeply, how to use a tool. It means knowing the strengths and weaknesses of each tool, knowing why a particular tool is best in any given situation, and knowing how to learn more about them.

In fact, those statements can be generalized into four questions that can be used to gauge the depth of your knowledge about most anything:

1. What does this do best?
2. What does this do worst?
3. Why should I use this in particular?
4. When was the last time I learned something new about this?

We’ll hit those four questions in each of the articles that follow, but for now, I’m going to apply them specifically the tools of my own professional domain: writing software.

The tools of computing

If you write software, step back for a minute and think about the tools you use every day. This includes your operating system, your text editor, your command shell, your SCM. It’s your web browser, your terminal client, your email and IM clients. It includes command-line utilities you probably use without thinking, every day: grep, sed, awk, find, ls and cd, to name a few. It’s even your hardware: the keyboard you use, your mouse, your monitor, your computer. It probably includes many other things that I’ve completely overlooked! (Note, though, that programming languages will be covered separately; they are certainly tools of the trade, but they’re such spectacularly important tools that they deserve their own rule of awesomeness. More on that when we hit rule #2.)

So, now it’s your turn. Go ahead and grab a scrap of paper. Make a list, right now, of the tools you use every day. I’ll wait.

Done? Okay, awesome. Now, go through each item on your list and ask yourself each of the four “knowledge gauge” questions:

1. What does this do best?

Compared with similar tools, what does this tool do best? Don’t use a pre-recorded, generic answer. Think about it. Consider it carefully. Be specific. For particularly powerful or flexible tools, there may be multiple answers, and that’s okay. Your answer may quite possibly be debatable, and that’s okay, too. The point here is that you need to have an opinion. If someone asks you why in the world you choose to use Vim instead of Emacs, don’t let the silence stretch awkwardly. Know your mind!

2. What does this do worst?

Related to the previous question: At what is this tool particularly bad? Again, this is in comparison with similar tools. And there is no such thing as a perfect tool, so there’s no point trying to skip this question. That’s a cop out. If you don’t have a few pet peeves for each tool in your toolbox, then chances are you aren’t familiar enough with your tools. Have an opinion.

3. Why should I use this in particular?

Given all possible alternatives, why am I using this tool in particular? Was it recommended to you? Are you using it “by mandate”? Perhaps it was it a gift, or a hand-me-down? Have you personally tried any of the alternatives? The real test of this question is having someone ask you for a recommendation. If you were to recommend this tool, and they were to ask “why” in return, what would you tell them? Similarly, if someone were to ask you about one of the alternatives, would you be able to give them an educated opinion? (You do have one, right?)

4. When was the last time I learned something new about this?

In many ways, this is the most important of the four questions. It’s purpose is to make you aware of potential stagnation. Certainly there is a point at which you say can that you know a tool “well enough”. It gets your job done. It suffices. Perhaps you’re even something of an expert, with deep knowledge about the tool. But no matter how well you know a tool, if you stop learning and instead put your expertise on “cruise control”, you’ll stagnate. Expire. Rot. Guaranteed. To be exceptional, you must be active.

Don’t stagnate. Seriously, just don’t. If it’s been a while since you learned something new about one of your tools, take a good look at that tool. Look at its documentation. Find tutorials or blog articles. Books, videos, podcasts, whatever. Try to find something new about it, something that you didn’t know before. Perhaps it’s a feature you weren’t aware of. Maybe it’s just a new application of the tool. Perhaps-now, don’t freak out here-it’s another tool altogether! Never be afraid of replacing your tools when something better comes along. (It’s actually really, really valuable to continually experiment with similar tools, even if you’re satisifed with what you already have. It’s like learning a foreign language: it gives you a new perspective, and can introduce you to things, to which you might otherwise have never been exposed.)

Keep in mind, too, that “something new” does not have to mean “something mind-blowing”. In fact, such discoveries will be the exception. The point here is to simply be proactive, regularly flexing your knowledge muscles. And then, you must apply that new bit of knowledge in your workflow. Otherwise, it’s not really learned, is it? It’ll atrophy if you don’t exercise it.

Try to find at least one new thing per day. It may be cliche, but it’s also true: “practice makes awesome.” Or something like that.

Have an opinion.

These questions are intended to make you think about your tool set. It can be hard, at first, to step back and “meta-analyze” yourself and your habits, but you really can’t have a meaningful opinion if you don’t think about things. And trust me, you want to have opinions. People without opinions are, frankly, boring. They’re pretty much the opposite of awesome. Blindly accepting recommendations, mindlessly reciting others’ claims, and cargo-culting others’ solutions might be an okay place to start, if you must, but it’s always a lousy place to finish.

Get first-hand experience. Learn. Expose your hidden assumptions. Ask “why”. Have an opinion.

Know thy tools.

There is no magic, there is only awesome (Part 1) »

Created at: 17.09.2009 05:45, source: the { buckblogs :here } - Home, tagged: Essays and Rants awesome keynote programming talk

The following is the first of a series of articles that I will be posting in the coming weeks, based on the keynote address I gave at the 2009 Ruby Hoedown in Nashville, entitled “There is no magic, there is only awesome.” I originally intended to publish the entire series of articles as a single article, but it got too long. At any rate, I think it’ll be more easily digestible as multiple posts.

I’m always surprised to discover that there are people who have never heard of string figures. These are the games that are played (in western culture, at least) primarily by children, using a loop of string. They place the string on their hands and, either by themselves or with a friend, manipulate the string into various patterns. As a kid, I learned how to do a few such patterns, including Cat’s Cradle and the cup and saucer, but it was just a novelty, and I was interested in other things. I promptly forgot nearly everything about these games, except that they existed.

Fast-forward almost thirty years. My wife bought one of those Klutz books for our kids, this one about string games. It only described a handful of figures, but it was enough to pique my curiosity. I hopped online to see if there was any other information available about the subject.

Thus did the floodgates open! I discovered that string figures are a nearly universal pastime, being found in almost every culture around the world. In fact, many widely separated cultures share string figure repertoires—a discovery that fascinated and intrigued ethnologists over a century ago.

A Bit of History…

When Franz Boas first described an Eskimo string figure in 1888, there was a sudden flood of academic interest in string figures. Ethnologists began theorizing that the shared string figure repertoires could imply a common origin of mankind, or might indicate migration paths or intercultural interactions of “primitive” societies. Some of these figures were so elaborate that it seemed almost impossible to believe that they could come from independent invention. Efforts were made to “collect” these string figures by sketching them, photographing them, or even mounting the finished patterns on cardboard.

In 1902 there was another breakthrough: Drs. Rivers and Haddon, two ethnolgists, devised a way to describe the process by which string figures were constructed, allowing researchers to collect not only the finished products, but also the steps leading up to them. This helped reveal an interesting fact: many of these different cultures’ figures that looked the same superficially were actually produced by very different methods. The argument for independent invention was strengthened, but it also became possible to see where one culture may have learned a figure from another, by comparing the similarities between the two methods of construction.

A few years later, in 1906, a remarkable woman named Caroline Furness Jayne published one of the first books about string figures, called String Figures and How to Make Them. Amazingly, this book remains in print, and is still one of the definitive works on string figures. In this book, Jayne took the nomenclature devised by Rivers and Haddon, and with a few simple modifications, made it more accessible to the layman. Using this modified nomenclature, Jayne then proceeded to describe (and, with the help of a friend, illustrate) 97 string figures from around the world, many of which she had collected herself and which had never been published before.

It really is a spectacular book.

However, because the system for describing string figure construction was so new at the time, there was a large body of string figures that had been collected, but for which there was no known construction method. Among these figures were several from the Pacific island of Nauru. These Nauruan (which is a palindrome, making this a de facto awesome word) string figures were so elaborate and complex that Jayne was skeptical they could be created entirely “on the hand”, and she speculated that perhaps they were (at least partially) created “artificially” (e.g., by laying the string down and moving loops around).

Still, she included illustrations of 15 of these figures in her book (see the section entitled “Nauru Figures” in Chapter 9), and said:

“I have brought together such of these [drawings] as I could obtain, in the hope that other observers will find out the method by which they are made; with our present knowledge it is practically impossible to work back from the finished pattern to the opening movements.”—Caroline Furness Jayne, “String Figures and How to Make Them”, 1906 (emphasis added).

Although Jayne died just a few years after her book was published, her work remained influential. Years later it was read by a woman named Honor Maude, who was intrigued by the Nauruan patterns. When, in the 1930’s, she had the opportunity to visit Nauru for a few weeks, she immediately dove in and began interrogating the natives about their string figures. She was able to learn many (though not all) of the Nauruan figures from Jayne’s book, and many others besides.

It turns out that the figures were (for the most part) created entirely on the hand. For many of the figures, including fairly complex ones, the process of construction was even surprisingly straightforward. And armed with the results of Maude’s research, other researchers have since been able to reverse engineer the rest of the Nauruan patterns from Jayne’s book.

The mystery was dispelled. There was no magic. There were only awesome patterns that could now be documented, described, and duplicated.

This could never have happened if it were not for the willingness of a few to explore. Late 19th and early 20th century ethnologists explored the world, travelling to places most people had never even heard of. Caroline Jayne explored both the body of existing research, as well as travelled the US herself, collecting figures. And Honor Maude explored much of the south Pacific, including Nauru, collecting string figures.

More recently, string figurists have explored in other ways. By “playing with string”, attempting variations on existing patterns and testing combinations of maneuvers, and by working backward from known patterns, they were able to unravel figures that Caroline Jayne called “practically impossible” to reverse engineer. These people explored their domain, understood it at a new level, and did the impossible.

These people understood that string figures were not magic. String figures were only awesome.

Being Awesome

It is human nature to look at something exceptional and feel distanced from it. But calling that feeling of distance “magic” does the exceptional a disservice. It’s a barrier we build to give us an excuse for not being exceptional ourselves. It’s not magic that separates the exceptional from the mundane: it’s awesomeness.

“Awesome” is excellence. “Awesome” is the willingness to dig into one’s domain, to explore what has been discovered, and to look beyond. “Awesome” is understanding what you do, and how and why you do it. You cannot be awesome until you look inside that black box and dispel the magic around it.

As a string figurist and a computer programmer (and someone generally aspiring to awesomeness!), I suggest that there are four cardinal rules to being awesome.

1. Know thy tools.
2. Know thy languages.
3. Know thy libraries.
4. Know thy communities.

Now, when I say “know” here, I mean more than just “know about”. I mean the deeper, intuitive knowledge that comes from prolonged first-hand experience. It’s one thing to say that you know what is inside a cave. It’s another to actually go spelunking.

And it’s another entirely to meticulously explore a cave, acting as cartographer and biologist, geologist and poet, cowboy and scientist, all in one.

Part of meticulously exploring your domain, then, is asking questions. Make no assumptions. Have your own opinions. Look under every rock, and behind every corner. Ask why five times for every question.

When I worked at BYU, my boss at the time, Doug Walker, liked to hold what he called “obnoxious question sessions”. In them, he would ask “obnoxious” questions that challenged the assumptions we had made about our systems. These could be painful and awkward if we didn’t have good answers for them. It became obvious, quickly, that we needed to have opinions about everything we did, and that we shouldn’t take anything for granted. And neither should you.

The articles that follow in this series will each be a kind of obnoxious question session. They might be painful. They might be painfully obvious! Regardless, I’ll be taking each of those four cardinal “rules of awesomeness” one at a time.

And I hope you’ll bear with me as I drag string figuring into each one!

Planting the seeds »

Created at: 05.09.2009 16:00, source: Robby on Rails, tagged: Ruby on Rails ruby programming PLANET ARGON seeds database development workflow faker github rubyonrails code

Yesterday, the Rails team released 2.3.4, which includes standardized way for loading seed data into your application so that you didn’t have to clutter your database migrations.

I noticed a few comments on some blogs where people were asking how to use this new feature, so here is a quick runthrough a few ways that you can use it.

Populating Seed Data Approaches

The db/seeds.rb file is your playground. We’ve been evolving our seed file on a new project and it’s been great at allowing us to populate a really large data. Here are a few approaches that we’ve taken to diversify our data so that when we’re working on UI, we can have some diversified content.

Basic example

Any code that add to db/seeds.rb is going to executed when you run rake db:seed. You can do something as simple as:

# db/seeds.rb

Article.create(:title => 'My article title', :body => 'Lorem ipsum dolor sit amet, consectetur adipisicing elit')

Just create database records like you would in your Rails application or in script/console. Simple enough, right? Let’s play with a few other approaches that we’ve begun to use.

Use the names of real people

We’re using the Octopi gem to connect to github, collect all the names of people that follow me there, and using their names to seed our development database.

@robby_on_github = Octopi::User.find('robbyrussell')

# add a bunch of semi-real users
@robby_on_github.followers.each do |follower|
  github_person = Octopi::User.find(follower)
  next if github_person.name.nil?

  # split their name in half... good enough (like the goonies)
  first_name = github_person.name.split(' ')[0]
  last_name = github_person.name.split(' ')[1]
  new_person = Person.create(:first_name => first_name, :last_name => last_name, :email => Faker::Internet.email,
                             :password => 'secret', :password_confirmation => 'secret',
                             :github_username => follower, :website_url => github_person.blog)
  # ...
end

We do this with a few sources (twitter, github, etc..) to pull in the names of real people. If you want to be part of my seed data, you might consider following me on Github. ;-)

Use Faker for Fake data

You may have noticed in the previous code sample, that I used Faker in that code. We are using this a bunch in our seed data file. With Faker, you can generate a ton of fake data really easy.

person.links.create(:title => Faker::Lorem.words(rand(7)+1).join(' ').capitalize,
                    :url => "http://#{Faker::Internet.domain_name}/",
                    :description => Faker::Lorem.sentences(rand(4)+1).join(' '))

We might toss something like that into a method so that we can do the following:

@people = Person.find(:all)

500.times do
  generate_link_for(@people.sort_by{rand}[0])
end

...and we’ll get 500 links added randomly across all of the people we added to our system. You can get fairly creative here.

For example, we might even wanted random amounts of comments added to our links.

def generate_link_for(person)
  link = person.links.create(:title => Faker::Lorem.words(rand(7)+1).join(' ').capitalize,
                             :url => "http://#{Faker::Internet.domain_name}/",
                             :description => Faker::Lorem.sentences(rand(4)+1).join(' '))

  # let's randomly add some comments...
  if link.valid?
    rand(5).times do
      link.comments.create(:person_id => @people.sort_by{rand}[0].id,
                           :body => Faker::Lorem.paragraph(rand(3)+1))
    end
  end
end

It’s not beautiful, but it gets the job done. It makes navigating around the application really easy so that we aren’t having to constantly input new data all the time. As mentioned, it really helps when we’re working on the UI.

Your ideas?

We’re trying a handful of various approaches to seed our database. If you have some fun ways of populating your development database with data, we’d love to hear about it.

Oh My Zsh gets theme support »

Created at: 31.08.2009 18:00, source: Robby on Rails, tagged: programming shell zsh terminal prompt git console themes

I just pushed a small change to Oh My Zsh, which gives it rudimentary support for themes. What I’m hoping to do is collect prompts from tons of people and make it simple for others to find a PROMPT that works well for them.

As of right now, there are only three for you to choose from. So, please head over to github, fork Oh My Zsh, add your theme, and send a pull request. :-)

Once I get it merged in, we’ll get a screenshot of it added to the Oh My Zsh wiki. (see themes)

I know that many of you have some really sweet prompts configured as I got a lot of response with my post, Show me your and I’ll show you mine.