Wednesday, January 14, 2015

Ignore files without modifying .gitignore

Brief note: Thanks to this episode of the Ruby Rogues featuring John Sonmez, I've been inspired to blog a little more often.

Problem: You use git and might use some tools that generate files that other people on your team don't use.  For example, you might use vim and create a Session.vim file.  Rather than clutter the .gitignore with these files, there is another elegant solution.

Solution: You can put these entries into .git/info/exclude and git will ignore them, just as if you had placed them in .gitignore.  There is one difference, however: .gitignore is usually committed, but .git/info/exclude is a file that exists in your working copy of the repo and it is not committed.  Therefore, if you clone the repo to another location on your computer, you'll have to add the entries to .git/info/exclude again.

There are advantages and disadvantages to each method -- don't fret about it too much though.  You can always revert your changes and try the other technique.

Restoring a Postgres database from a dumped file via pg_restore

So you want to restore your Postgres database from a dump file?

This article makes the following assumptions:

  • You don't mind having all the tables and indexes dropped.
  • The dump file has its own database name, perhaps something totally different from the database you want to restore.
I had to do this for a Rails project. Let's assume for the purposes of this example, that in our "development" section of config/database.yml, our:
  1. username is "fred"
  2. our database name is: coolapp_dev

To start the restore:
pg_restore  -U fred --dbname=coolapp_dev --verbose --clean --role=fred /path/to/dump_file

What do each of those options mean?
  • -U connect as the specified user
  • --dbname: The database name to connect to
  • --verbose: verbose mode, which I wanted so that I could diagnose any issues
  • --clean: drops the database before creating
  • --role: performs a SET ROLE before restoring
You can always see more detailed help by typing:

pg_restore  --help


Now, let's check that the database has the tables and data that we expect.
psql coolapp_dev fred
then type the following to list all tables:
\dt

Hopefully every table that you expected is there.

Summary
It can be a bit tricky to use these commands for the first time to set up an existing Rails application.  It's always a lot easier to start from scratch, but in legacy applications, we don't have that luxury.  Hopefully this article helped you out.  Please let me know if you have any issues in the comments.  Thanks!

Tuesday, December 09, 2014

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.  We won't cover installation here since it's well documented.  Just follow along and have fun!

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!

Friday, November 14, 2014

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?

Tuesday, November 11, 2014

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.

Friday, October 18, 2013

Book Review: iOS 6 Programming Cookbook By Vandad Nahavandipoor, O'Reilly Media

I reviewed this book as part of the O'Reilly blogger program.  

The format of the book consists of concise recipes which state the problem and show how to implement a solution with easy to follow code samples.  I love how the e-book has code samples in color with syntax-highlighting, and I found that the code was easy to translate to use with the Ruby Motion framework.  Of course, the recipes work fine with native Cocoa as well.

Being a cookbook, I don't think this book was intended to be read cover to cover, although I did just that when reviewing it. You could do that as well, but it might serve you better to use it as a reference. The good thing is that this book is organized almost like a non-cookbook; i.e. it has beginner topics in the first chapter(s) and gets progressively more advanced as you go on.

Although iOS 7 is available now, I would still highly recommend this book.
Read more about this book on its product page.

Saturday, October 06, 2012

Book Review: Code Simplicity: The Fundamentals of Software, by Max Kanat-Alexander, O'Reilly Media

Writing code seems like an easy task, and perhaps it is.  However, it can be difficult to write simple, clean code.

The book, "Code Simplicity: The Fundamentals of Software", explains:

  • Why do you want to write simple code?
  • How do you write simple code?
However, you will not find any code samples in this book.  While this may not be appealing to some readers, I did not feel that this lowered the quality of the book.  

It contains many guidelines and principles that experienced software craftsmen already know and might pass on to their apprentices.  Some of these principles:
  • Don't write code that isn't needed
  • Make the code easy to change
  • Comments -- should you add them? Why/why not?
A very experienced crafstman may not get much out of this book, but if you consider yourself a beginner or intermediate software developer, then I'd highly recommend this book.  It's full of great tips that will benefit you immediately and in the future.

You can find more about Code Simplicity on its product page on O'Reilly.

Thursday, March 01, 2012

Review: "The Little Book on CoffeeScript" by Alex MacCaw, O'Reilly Media

This book might be "little", but don't let that mislead you; it's packed with enough content so that you'll understand all of what CoffeeScript has to offer.

Alex MacCaw does a great job of covering the major features of CoffeeScript in six short, but detailed chapters.

He starts off covering the basic syntax, and then moves on to cover something that is frowned upon by many in JavaScript, but not so much in CoffeeScript: classes.  Initially, I was hesitant to use CoffeeScript's classes prior to reading this book, but after seeing how they are implemented, and how easy they are to use, I was sold.

After covering classes in Chapter 2, you'll learn about CoffeeScript idioms in Chapter 3, such as: each, map, select, min/max, etc.  Chapter 4 covers the Cake build system and shows you how to build and deploy CoffeeScript client-side applications, which is pretty awesome.

The book winds down in Chapter 5 talking about what CoffeeScript improved upon in JavaScript, and what it did not. The final chapter is written by the creator of CoffeeScript, Jeremy Ashkenas. It basically talks about the philosophy of CoffeeScript and invites you to create your own special language as well.

My thoughts on the book:
  • It's short and very easy to read.
  • You'll walk away feeling ready to write some CoffeeScript apps or sprinkle it in your Rails apps.
  • The one negative about the book is that in some parts, some syntax was explained after the fact, which made it difficult to understand some of the examples.
  • Overall, I'd highly recommend picking up a copy as it's concise and easy to read.