Yammer is a web app that lets you “connect and share with the people in your company or organization”. It’s basically Twitter for your intranet.

We use it to fire off quick messages about the progress we’ve made and the challenges we’re facing on our projects. Using the Yammer API we’ve been able to tie Git into the system so that notifications are sent out after each commit which contain the commiter, the commit message, and a hash tag associating the Yammer message with the git repository name.

The idea of broadcasting status information like this is similar in concept to Alistair Cockburn’s idea of Information Radiators. From his page describing the concept:

[...] “information radiator” refers to a publicly posted display that shows people walking by what is going on. Information radiators are best when they are big, very easy to see (e.g. not online, generally), and change often enough to be worth revisiting

My favorite example has always been using lava lamps to indicate build status.

Anyway, the code has been made available on my github at http://github.com/rboyd/git2yammer/tree/master. Using git with yammer has been great for us so far and I hope you find it useful in your projects as well.

You know you should do it, but you still don’t. It’s eating at you really. Always in the back of your mind, that nagging thought — what would happen if I lost all my data?

So here you go. My recipe for taking nightly snapshots of mission critical data and backing up to Amazon S3. Just replace the relevant directories, MySQL password, and S3 bucket name with your own. You’ll also need to setup your AWS SSH keys before s3cmd will work.

Note: this script requires the program s3cmd which can be installed on debian-based systems (like Ubuntu) with apt-get -y install s3cmd

GIT_DIR="/srv/git"
HUDSON_DIR="/srv/hudson"
REDMINE_DIR="/mnt/redmine"
BACKUP_DIR="/root/backups"


DATE_TAG=$(date +%m_%d_%Y)

backup key directories

tar pczvf $BACKUP_DIR/git.$DATE_TAG.tgz $GIT_DIR
tar pczvf $BACKUP_DIR/hudson.$DATE_TAG.tgz $HUDSON_DIR
tar pczvf $BACKUP_DIR/redmine.$DATE_TAG.tgz $REDMINE_DIR

#

backup databases

mysqldump --password=your_pw_here --all-databases | gzip -c > $BACKUP_DIR/mysql
.$DATE_TAG.gz

for f in $BACKUP_DIR/$DATE_TAG
do
    /usr/bin/s3cmd -c /root/.s3cfg put $f s3://your_bucket_here.com/$(basename $f) >> 
/root/backup.log 2>&1
done

Save that script to a file named backups and drop it in /etc/cron.daily. Make sure it’s root-owned (chown root.root backups) and has the proper permissions (chmod 755 backups).

Keep in mind this will accumulate files in the backups directory in its current state, so you might want to add a line to remove the backups after storing to s3. Personally I like to delete them manually after ensuring the backup was performed correctly.

I hope this saves somebody’s ass someday — it’s already saved mine.

Cover of Guy Kawasaki's book Reality Check.

Having spent a few years there myself, I found his portrayal of Silicon Valley both hilarious and accurate.  If I had a nickel for every company suffering from extreme amounts of wasteful spending or delusions of grandeur — well, I never would have banked on those stock options.

My favorite thing about the book though has to be the way he presents the various personalities at play in startups and business.  He presents some of these roles in a list that would make David Letterman proud.  For example, from The Top Seventeen Lies of CEOs:

“Working together, we’ve established our goals.” In other words, these are the goals that the CEO decided will make him look good.  Few managers believe that these goals are doable, and yet they are the ones who are going to have to accomplish them.  But that’ what “working together” means: The CEO decides and the workers do.

(similar sections on lies told by VC, Entrepreneurs, Engineers, Lawyers and Partners)

Other sage wisdom in this book includes advice on effective communication techniques, especially emailing, demoing, and presenting.

There’s a hilarious chapter on handling the competition where he cites some pretty clever little tactics.  For example the new pizza store that offered customer discounts if they brought in the torn-out Yellow Pages of the competitors restaurants.  Or the hardware store owner that responded to a competing national chain opening up right next door by hanging a sign over his door that read “MAIN ENTRANCE”.

Mr. Kawasaki left me with a “just go get it done” attitude after reading this book.  This is definitely one of my favorite books on business, startups and tech culture and it definitely deserves a place on your bookshelf.

Anyway, I was thinking about the future of software development and I remembered reading an interview with Dr. Simonyi in Forbes circa 2002 about a technology he was developing called “Intentional Programming“. Not much has been written about Intentional Programming but we do have a few resources on the subject.

• US Patents: 6,966,054, 7,051,279, 7,165,238, 7,237,226
• YouTube Videos: Intentional Programming demo (Part 1) – Editor, Intentional Programming demo (Part 2) – Compiler
• One chapter in the book Generative Programming: Methods, Tools, and Applications
• Interviews with Charles Simonyi (here, here, here, and here)

Simonyi’s vision is in line with the theme of this blog: building good software should be easier. His approach seems to resonate with similarities to other concepts such as domain specific languages and metaprogramming. Intentional Programming calls for domain experts to capture their intentions of a program’s inner-workings in a tree structure which is versioned and databased and later translated into program code. This translation borrows from biology and the system responsible for this work is called an “enzyme” in Intentional Programming parlance.

Did Microsoft scrap the project? Critics of Simonyi have spoken out against Intentional Programming by asserting that his method merely shifts the complexity from application development to the development of these new translation modules — and perhaps rightly so. Also missing from materials on the Intentional approach is any mention of the debugging and testing processes.

Is Intentional Programming vaporware? Perhaps. Or perhaps Simonyi and his team are already quietly enjoying levels of productivity that the rest of us can only dream about.

Good programmers are like Judo masters — they both practice the art of maximizing efficiency.

Larry Wall (the founder of Perl) defined laziness as:

“The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful, and document what you wrote so you don’t have to answer so many questions about it. Hence, the first great virtue of a programmer.”

He’s not talking about programmers with bad work ethic here. No, he’s talking about expert programmers who know how to make every keystroke count. From Wikipedia’s article on Judo:

“The word “judo” shares the same root ideogram as “jujutsu”: “jū” (柔, “jū”?), which may mean “gentleness”, “softness”, “suppleness”, and even “easy”, depending on its context. Such attempts to translate jū are deceptive, however. The use of jū in each of these words is an explicit reference to the martial arts principle of the “soft method” (柔法, jūhō?). The soft method is characterized by the indirect application of force to defeat an opponent. More specifically, it is the principle of using one’s opponent’s strength against him and adapting well to changing circumstances. For example, if the attacker was to push against his opponent he would find his opponent stepping to the side and allowing his momentum (often with the aid of a foot to trip him up) to throw him forwards (the inverse being true for pulling.) Kano saw jujutsu as a disconnected bag of tricks, and sought to unify it according to a principle, which he found in the notion of “maximum efficiency”. Jujutsu techniques that relied solely on superior strength were discarded or adapted in favour of those that involved redirecting the opponent’s force, off-balancing the opponent, or making use of superior leverage.

Master software developers have a strong command over their tools. One of the most important tips from The Pragmatic Programmer is to Use a Single Editor Well:

“The editor should be an extension of your hand; make sure your editor is configurable, extensible, and programmable.”

They’re also fluent in multiple programming languages and understand how to choose the best one for the job. When more than one language may be appropriate, they choose the most expressive language available. Consider The FizzBuzz Problem (a simple “weed-out” problem given to interview candidates) which has been stated as:

Write a program that prints the numbers from 1 to 100. But for multiples of three print “Fizz” instead of the number and for the multiples of five print “Buzz”. For numbers which are multiples of both three and five print “FizzBuzz”.

There are many general purpose programming languages that could be used to solve this problem. Programmers have invented a game called Code Golf. The rules are simple — solve a problem with the shortest possible program.

Here’s a list of scores which demonstrates how various languages stack up to solve the FizzBuzz problem. We see Ruby and Python coming in at 56 characters each. Compare that with C# (123) and Java (130) and you start to get the idea here. If you were the policy carrier responsible for insuring these programmers against carpal-tunnel syndrome, who would you rather cover?

I have often visited a website or reviewed a proposal from a designer and get the feeling that the design is inadequate — but until I read this book I didn’t have the tools to identify and outline specific problems in web design. In the first few chapters the author describes a test for recognizing issues with areas such as: presentation, layout, navigation, search, and site identification.

One of the fundamental takeaways from this book is that your website should be a “Mensch” — a Yiddish term which roughly translates to “a stand-up guy”. Make things easy on your users. Don’t ask them to fill out information in forms until that information is absolutely needed. Make your website accessible to users with disabilities. The book follows it’s own advice and is written in a very friendly and down-to-earth language. It is illustrated with comical illustrations and great quotes throughout.

The last few chapters describe the benefits of conducting usability testing on your website. It calls for testing early and often, and it outlines a plan for doing it without destroying your budget.

Krug offers the book and hands-on training workshops at his company’s website, Advanced Common Sense. See for yourself, the entire text of Chapter 2 is available online. If you build websites by vocation or avocation, I highly recommend you do yourself a favor and get yourself a copy of this book.

P.S. BTW, in keeping with the spirit of this site (that is, growing a community of people sharing ideas for building better software) I’m not linking to this book with any sort of affiliate code, nor will I ever do this in the future. That’s just annoying.

The players: Hudson – An extensible continuous integration engine Git – Fast version control system Gitosis – Easier and safer repository hosting Merb – Lean and mean Ruby web app framework Cucumber – Execute feature documentation (stories) in plain text The Setup:

Fresh Ubuntu 8.10 server install. I’m running mine on Amazon’s EC2 using Alestic’s public ami-7806e211, but you should be just fine following with a local server if you’re not on the cloud yet.

Step 0: Pre-installation

It’s a good idea to update our packages before getting started:

apt-get -y update && apt-get -y upgrade

Step 1: Install Java, Apache and Tomcat

Hudson is a Java web application that plays nicely with Apache 2.2 and Tomcat 6. First we’ll install Java, here’s how to get it going:

apt-get -y install sun-java6-jdk

You’ll have to accept Sun’s license agreement during the Java install, but it’s pretty painless.

Then we can just:

apt-get -y install apache2 tomcat6

If you try to install all three packages at the same time, tomcat may not start properly. YMMV.

Step 2: Convince Tomcat that it wants to run behind Apache, and prepare it for Hudson

Now we need to configure Apache and Tomcat to communicate with each other over Apache’s binary AJP protocol. We also need to prepare Tomcat for our Hudson install. This is pretty boring and labor-intensive stuff, so instead of walking you through the specifics, I’m going to just publish my config files and have you use wget to overwrite yours with them. If you want to see what I’ve modified then you can always backup your copies and diff them against mine.

wget http://pastie.org/pastes/315473/download -O /etc/tomcat6/context.xml
wget http://pastie.org/pastes/315475/download -O /etc/default/tomcat6
wget http://pastie.org/pastes/316125/download -O /etc/apache2/apache2.conf
wget http://pastie.org/pastes/318217/download -O /etc/init.d/tomcat6

Now let’s create a directory for hudson to live in and restart Tomcat.

mkdir /srv/hudson
chown tomcat6.tomcat6 /srv/hudson
/etc/init.d/tomcat6 restart
/etc/init.d/apache2 restart

Step 3: Install Hudson

This step is pretty painless, we just grab the latest version of Hudson and move it to Tomcat’s web app directory.

wget http://hudson.gotdns.com/latest/hudson.war
chown tomcat6.tomcat6 hudson.war
mv hudson.war /var/lib/tomcat6/webapps/

Don’t worry, Tomcat will load it and set it up automatically. At this point you should be able to access Hudson’s control panel. Aim your browser at http://yourhost/hudson/ and have a look around.

Step 4: Install Git and Gitosis

The Git version control system seems to be the hacker’s choice these days. We’ll grab the Git toolset itself as well as Gitosis which will allow us to manage users and public or private repositories.

apt-get -y install git-core python-setuptools
git clone git://eagain.net/gitosis.git
cd gitosis
python setup.py install
adduser --system --shell /bin/sh --gecos 'git user' --group --disabled-password --home /srv/git git
cd ..

Now we need to generate a SSH key to manage Gitosis with. This way you can add the private key to your keychain and manage gitosis from any machine you like. Use a passphrase, or don’t, it’s up to you. Then let’s run ssh-agent and add the new key.

ssh-keygen -t rsa


...

ssh-agent /bin/bash
ssh-add ~/.ssh/id_rsa

Finally, let’s initialize Gitosis now that we have our key:

sudo -H -u git gitosis-init <~/.ssh/id_rsa.pub

We also need to make sure the post-update script has the proper permissions to execute so that our changes to the configuration take effect after we push them. Here’s how:

chmod 755 /srv/git/repositories/gitosis-admin.git/hooks/post-update

While we’re on the subject, let’s add Tomcat’s user account (tomcat6) to the git group so that it can clone repositories off of the local filesystem.

[sourcecode language='php'] usermod -G git tomcat6

Step 5: Install Merb

apt-get -y install ruby-full libsqlite3-dev libxml-ruby libxslt-dev libxslt-ruby
wget http://rubyforge.org/frs/download.php/45905/rubygems-1.3.1.tgz
tar -zxvf rubygems-1.3.1.tgz
cd rubygems-1.3.1
ruby setup.rb
ln -s /usr/bin/gem1.8 /usr/bin/gem
cd ..
gem install merb

Step 6: Start the project and manage it with Git

Now the real fun begins. The whole point of this exercise of course is to build our killer robots in the most efficient way possible. So let's generate a new Merb application and get it under version control.

merb-gen app robot
cd robot
git init
git add .
git commit -a -m "Initial import."
cd ..

Now let's create a repository in Gitosis for it. You can do this step on any machine, it doesn't need to be the server -- just make sure you've added your private key from Step 4 with ssh-add first.

git clone git@yourhost:gitosis-admin.git

Now open gitosis-admin/gitosis.conf in your favorite editor and add a group and make a new repository writable for our project. Here's what mine looks like:

[gitosis]


[group gitosis-admin]
writable = gitosis-admin
members = rboyd@plato

[group robot-dev]
writable = robot
members = rboyd@plato

Now commit that, and push -- your new repository should be ready. Run this from the gitosis-admin directory:

git commit -a -m "Adding robot repository."
git push

Now let's get back into our robot directory and push our repository to Gitosis.

git remote add origin git@localhost:robot.git
git push origin master:refs/heads/master
cd ..

Step 7: Install Cucumber

gem install webrat  # dependency for cucumber
git clone git://github.com/david/merb_cucumber.git
cd merb_cucumber/
rake install

Now we can get Cucumber setup and working in our Merb app:

cd robot
merb-gen cucumber

As anyone who's tried to take over the world before knows, automation is key. The most important part of building an army of killer robots is to make sure that your robots know how to self-assemble new killer robots. Otherwise you'll be bogged down building them all by yourself. Let's spec it out. Create a file features/replicate.feature in your robot directory. Make it look like this:

replicate.feature

Feature: Replicate
In order to take over the world
Robots should be able to

find parts and self-replicate

Scenario: Find parts
Given that there are parts available
And that the Robot needs parts
Then it should take any that it needs

Scenario: Self-replicate
Given that the Robot has all of the needed parts
Then it should be able to build a new Robot

You can run your Cucumber stories with the command rake features. We don't have these steps implemented yet though, so let's create them in features/steps/robot_steps.rb:

require 'spec'


class Robot
def initialize
@backpack = []
end
attr_accessor :backpack

def take_from!(parts)
parts.each { |p| backpack << p }
end

def needs?(parts)
true
end

def can_replicate?
true
end

def build!
backpack = []
return Robot.new
end
end

Before do
@robot = Robot.new
end

Given /^that there are parts available$/ do
@available_parts = []
@available_parts << {:type => :leg}
@available_parts << {:type => :leg}
@available_parts << {:type => :brain}
@available_parts << {:type => :chainsaw}
end

Given /^that the Robot needs parts$/ do
@robot.needs?(@available_parts).should be_true
end

Then /^it should take any that it needs$/ do
before = @robot.backpack.length
@robot.take_from!(@available_parts)
@robot.backpack.length.should be > before
end

Given /^that the Robot has all of the needed parts$/ do
@robot.can_replicate?.should be_true
end

Then /^it should be able to build a new Robot$/ do
@new_robot = @robot.build!
@new_robot.class.name.should == "Robot"
end

Now when you run rake features you get the results you'd expect. All green! Good. Now we'll want to commit our changes to the repository, but before we do, let's get Hudson setup to kick off our tests as soon as it gets our latest changes. This is what continuous integration is all about.

Step 8: Wire everything up

First we need to add the Git plugin to Hudson. Fire up the browser again and aim it at http://yourhost/hudson/pluginManager/available -- then click the checkbox next to the Git Plugin. Let's add the Rake Plugin while we're at it. Then click the Install button at the bottom of the page.

Hudson tells us "Once the installation is completed, Hudson needs to be restarted for changes to take effect." so let's do that again:

/etc/init.d/tomcat6 restart
/etc/init.d/apache2 restart

Hudson likes to tag revisions from Git with its build number. But it needs a .gitconfig with user and email settings before git will allow this. So let's drop this file in /srv/hudson/.gitconfig:

[user]
name = Hudson
email = hudson@yourhost

Ensure that it's owned by the proper user:

chown tomcat6.tomcat6 /srv/hudson/.gitconfig

Now let's enable security for Hudson. Click Manage Hudson then Configure System. For now, make it look like this:

Now you should be able to create new users by clicking the sign up link in the top-right corner. Create two, one for yourself (I'll call mine admin) and one for Gitosis (gitosis) to use to trigger builds automatically upon updates to the repository. Once these user accounts are created, login and head back to Configure System switch over to Project-based Matrix Authorization Strategy and remove all privileges for Anonymous (this is a good idea because Hudson comes with a Groovy script interpreter on by default which is a potential security vulnerability), and add all privileges for your admin account. Your gitosis account can get away with only Read and Build permissions. Here's how it looks:

Now we're ready to crate a New Job. Name it robot and select Build a free-style software project, then click OK.

On the project configuration page you tell Hudson how to fetch and execute any build steps for the project. We'll configure it to grab the robot.git repository from the local filesystem (bypassing gitosis altogether). We'll also enable the checkbox for Trigger builds remotely.

We're almost done, now we just need to tell Hudson to kick off a rake features after grabbing updates. Click the Add build step drop-down menu and select Invoke Rake and just type features into the Tasks input box.

Now let's set Gitosis up to trigger your build upon code checkin. Add this line to /srv/git/repositories/robot.git/hooks/post-receive, replace pass and secret with whatever you used for the gitosis user password and the build trigger token:

/usr/bin/curl -u gitosis:pass http://localhost/hudson/job/robot/build?token=secret

Then set file permissions on post-receive and post-update:

chmod 755 /srv/git/repositories/robot.git/hooks/post-update
chmod 755 /srv/git/repositories/robot.git/hooks/post-receive

That's it. Now Gitosis and Hudson should play nicely together to automatically kick off builds and run your tests whenever you add new code to your project.

Step 9: Check in your code

Back in our robot project directory, we still have our Cucumber test code that we haven't added yet. Run git status to see these new files. Let's commit our changes and push it to Gitosis and watch Hudson run the build:

git add .
git commit -a -m "Adding tests."
git push

Now just sit back and watch the build progress on the job page (maybe check out the console output) and prepare for world domination!

Paul Graham had this to say about the variation in productivity between commoon programmers and truely spectacular ones in his essay Great Hackers: “Productivity varies in any field, but there are few in which it varies so much. The variation between programmers is so great that it becomes a difference in kind.”

So when you’re hiring, how do you identify a great programmer? Joel Spolsky has written an article The Guerilla Guide to Interviewing and it is a definitive contribution on this topic. The book Programming Interviews Exposed is another fantastic resource. You should definitely read these and apply their wisdom.

I recently fielded a question on stackoverflow (a software development Q&A site) which related to this topic, so I’ve decided to republish my answer to this blog. Here is my interview outline to help you craft specific questions to fire at your candidates. I’ve tried to list these topics in order of importance.

General Intelligence (brain teasers/logic puzzles)

• Counting toggled lockers
• Crossing bridges
• Weighing marbles
• Burning fuses

Computer Science Knowledge

• Data structures (stacks, queues, lists, trees)
• Algorithm knowledge (sorting, search, shortest path, Euclidean algorithm, Hamiltonian cycle, data compression)
• Algorithm analysis
• Recursion/Tail Recursion versus Iterative solutions
• Models of computation/Finite state machines
• String matching/Regular expressions
• Backus-Naur Form

Programming Exercises

• GCD, Factorial, Fibonacci, Towers of Hanoi
• String and list reversal
• Determine if a singly-linked list has a loop (can you do it with only two pointers?)
• Find the bug

Tools, Technique and Methodology

• Debugging
• Version Control
• Agile Software Development
• Object-oriented analysis and design / UML
• Design Patterns
• Coverage analysis
• Continuous integration

Security

• Buffer/Heap overflow
• SQL injection
• Cross-site scripting attacks

Basic Mathematics

• Numeral systems (convert from one base to another)
• Probability Theory
• Distance between two points on Cartesian plane (Pythagorean theorem)
• Square root (Heron of Alexandria, successive approximation)

Cryptography

• Public key cryptography
• Symmetric-key cryptography
• Hash functions
• Cryptographic protocols (secret sharing, zero-knowledge proofs)

Discrete Mathematics

• Logic
• Set theory
• Graph theory
• Information theory
• Combinatorics
• Proofs (like existence of irrational numbers, infinite primes)

Anyone has conducted a significant amount of interviews in this industry knows that the majority of potential recruits won’t last through the first 30 minutes of the interview, so much of this list will be unnecessary most of the time. Before you dismiss my more complex topics as overkill, just keep in mind how expensive and emotionally taxing it can be to recognize that you made a poor hiring decision and to later correct it. Good luck in building your team of awesome developers!

It’s always a good idea to maintain a network of colleagues that you can call on for advice when you need it. Recently a friend and I were discussing our respective software projects, and I started asking him questions about his methodology. I asked if he was making use of any continuous integration systems, like Hudson or CruiseControl.rb. He wasn’t. I asked him if he had used any tools for coverage analysis, like rcov or NCover. Neither was he doing any similarity analysis (Simian) to identify code violating the DRY principle. I asked him what he was using for TDD/BDD (check out Cucumber), and he replied that he wasn’t doing any.

Many software teams I’ve encountered (or even been a part of) have ignored these tools. This isn’t terribly uncommon. Finally I ask him, “are you even doing any version control?”. He was not.

I found this to be very surprising, because my buddy has been working on his project for the better part of a year. He hopes to productize his software and take it to market. It’s apparently a fairly mature code base, and yet it is not under the safe watch of any versioning system. It’s shocking to me, because here we are in the year 2008. Today’s software engineering tools are more powerful than ever before, but to a large extent they go unused. Why is this?

With regards to versioning, my friend has several options. Traditionalists are still using CVS, and Subversion is still quite popular. Microsoft has its line in the water with SourceSafe, which I think has been integrated into TeamSystem, but I’m not quite sure. Even some of the strongest open source advocates I know readily plop down cash for Perforce, they say it’s THAT good. There’s new entrants to the arena all of the time, like Eric Sink’s SourceGear. Linus Torvalds uses git to help manage the development of the Linux kernel.

My buddy’s reason for not using any of them? “I’m the only person working on the code. Why would I need to version it?”

I believe this is the most common reason for not using a versioning system — people just don’t know when the project is established enough to merit using one. Many less experienced developers feel that the right time to start using version control is when there are multiple developers touching the codebase. While this would certainly be a good reason (and I can’t imagine many successful teams of developers not using versioning), it’s flawed reasoning that the lone coder working in isolation doesn’t benefit from the virtues of version control. My take on it is that you should be using version control as soon as you have code that you care about enough that you would be disappointed to lose it. That’s when it’s important enough to version it.

All of this of course inspired me to climb up on my soapbox and preach about the many reasons for versioning your software. So here are my Top 10 reasons for using a version control system:

1. Never again suffer from the confusion of juggling multiple versions of your codebase by hand.
2. Provides a single source for backups.
3. Multiple developers easily work against the same code base.
4. Branches are easily managed with version control. Sometimes you want to experiment and take the project in a whole new direction.
5. Commits can reference ticket numbers or bug ids so that developers can easily answer the question “when did we fix that bug?”.
6. Easily diff new versions against old ones to pinpoint changes.
7. Easily integrate with a web tool like Redmine to provide project statistics at a glance.
8. Plays a key role in continuous integration systems.
9. No real software engineer or manager will take your project seriously unless it’s under version control.
10. Develop with impunity. With version control you’re like a trapeze artist flying worry-free over a safety net.
  For these reasons, I believe that just after the compiler/interpreter and debugger, a versioning system is the most useful weapon in the software engineer’s arsenal. If your project isn’t under version control yet, what are you waiting for? Here’s a nice tutorial and a cheat sheet for git to help you get started. Once you’re up and running, you might want to check out Gitosis (do it yourself) or github (managed hosting) to share your repository with the world.

This book really got me thinking. What tribes do I belong to? We’ve heard it said “Do what you love, and you’ll never work a day in your life” and “Follow your bliss”. I love building elegant systems — especially software. I want to hear from you if you share this passion. I want to trade ideas with you about the best way to do that. That’s our tribe.

Over the course of maintaining this blog, I expect most of my posts to relate to the following 4 assertions:

• Good software makes users lives better.
• Building good software is hard but it can be easier.
• Happy developers build good software.
• Happy developers use powerful tools.

What is your passion? What is your tribe?