tmux crash course

So you've probably heard about tmux and want to get started.  It might sound intimidating but after you follow this tutorial, you'll find that it's really not that bad.

Here's a basic crash course, written so that you can follow along, step-by-step.

Installation on OS X

brew install tmux

Basic commands

tmux new-session -s foo

Creates a session named foo.

Congrats! You are now attached to a session and you should see one tmux window.

A bit of terminology: you create a session which can have one or more windows, which we'll see below. Within a window, you can split it into panes.

(I'll use ^ to indicate "Ctrl", so ^b means Ctrl+b)

^b c
will create a new window.  You should see a status bar at the bottom of your terminal listing out the current windows. Do it again to create another.

Now you have multiple ways to switch between windows:

^b 1	switches to window 1
^b 2	switches to window 2
^b p	previous window
^b n	next window
^b w	choose window from a list
^b l	(lower case "L") go to last selected window

Next, you probably want to split your current window into panes.

^b "	Split vertically
^b %	Split horizontally

To switch panes:

^b o	Go to the "next" pane
^b up	Go to the pane above. Try left, right, and down as well.

Here's a cool feature of tmux that you might be familiar with if you've ever used screen.  You can detach from a session and reattach at a later time, with all of your windows and panes intact!

^b d .

Detach from current session

Finally, to reattach to a session

tmux attach -t foo

Reattach to a session named foo

Hope you found this to be useful.  Please let me know if you have any questions. Thanks!

TDD: Test behaviors, not methods

What I observed when a developer tests methods instead behavior
One of my favorite books, Growing Object Oriented Software, Guided by Tests by Steve Freeman and Nat Pryce mentions that you should test behavior, not methods. The book, also referred to many as "GOOS", states on page 43:

We do better when we focus on the features that the object under test should provide, each of which may require collaboration with its neighbors and calling more than one of its methods.  We need to know how to use the class to achieve a goal, not how to exercise all the paths through its code.

 When this advice isn't followed
A few years ago, I coached a fellow developer in TDD.  Although I showed how to "write the code you wish you had" and how the tests drive the design, they refused to write the tests first, which is okay -- it was a big improvement from before when there were no tests.

My observations were that the specs described methods, and it was hard to figure out what the class actually did.  Also, one of the core behaviors of the class was never tested!

Another problem was when my team and I wanted to actually use an instance of the class, we couldn't quickly figure out which method, or set of methods, we should call to get the job done.  The specs read like a list of methods, not how an instance actually behaved.

What are your experiences? Do you prefer to test methods, or behavior?

Proxy Pattern -- one way out of many towards Clean Architecture

Earlier this year, I bought several of the Clean Coders screencasts, which motivated me to implement a clean architecture in Rails.  It also motivated me to read Uncle Bob's classic text, Agile Software Development: Principles, Practices, and Patterns. I've known about the SOLID principles, but the book really shines once you read past those initial chapters.


For example, here's a great quote from Uncle Bob Martin's PPP, regarding the PROXY pattern:

"It is a way to keep the business rule assets of your project separate from the implementation mechanisms that are currently in vogue." (page 345)

However, this isn't the only way to accomplish this. After reading and understanding the principles in the book, I've found that:

• By following the D in the SOLID principles (Dependency Inversion Principle), it naturally leads you to design principles such as the PROXY pattern.
• You have no fear of frameworks polluting your code because the SOLID principles will ensure that the dependencies point in the correct direction
• Your tests will run extremely fast
• The only slow tests you have will be integration tests with external resources (database, web services, file system, etc.) and frameworks
• It's easier to upgrade since you only need to worry about integration failures, not the interaction between business logic and the new framework API. 

If you haven't read the entire book yet, I highly recommend checking it out.  It will change the way you think about writing software forever.