Ylan Segal

Book Review: Being Agile - Ekas & Will

Leslie Ekas and Scott Will present a practical approach to Agile that balances the philosophy of the Agile Manifesto with the tools and techniques needed to navigate the roadblocks that those wishing to implement Agile encounter on a daily basis.

The authors are not shy about sharing their extensive experience building enterprise software. I found myself nodding along on more to one occasion while reading the many anecdotes from the field sprinkled throughout.

The book is well-organized. Each chapter is devoted to one of eleven techniques, which in turn is divided into principles, practices metrics and breakthroughs expected. Of course the authors save the bet for last: Continuous Improvement, wich is rightly presented as the bedrock of the Agile methodology. The constant drive for individuals, teams and organizations to constantly improve on their past performance is the essence of successful software development (and more broadly, I would argue, of any human endevour).

This work is a great addition to the bookshelf of team members or leaders just starting out or well on their way in their Agile adventure.

Links:

StringInquirer: Nicer Syntax for Testing Equality

There is a well-known idiom in Rails, to tell wheather one is runnign in a specifc environment or not:

1
2
Rails.env.production? # => false
Rails.env.development? # => true

At first, it looks like Rails.env is a special kind of object that has methods defined on it to check for the environment properties. However, upon closer inspection, it looks like it is really just a String, but not quite:

1
2
3
4
>> Rails.env
=> "development"
>> Rails.env.class
=> ActiveSupport::StringInquirer

As the documentation says, StringInquirer is just a pretty way to test for equality. It can be used outside of Rails, say for example to be a bit lenient when reading environment variables:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
require 'active_support/core_ext/string'

class Logger
  def log(message)
    message if verbose?
  end

  private

  def verbose?
    env_verbose.true? || env_verbose.yes?
  end

  def env_verbose
    @env_verbose ||= (ENV['VERBOSE'] ||= '').downcase.inquiry
  end
end

Logger.new.log("Hello, World") # => nil

ENV['VERBOSE'] = 'yes'
Logger.new.log("Hello, World") # => "Hello, World"

ENV['VERBOSE'] = 'YES'
Logger.new.log("Hello, World") # => "Hello, World"

ENV['VERBOSE'] = 'True'
Logger.new.log("Hello, World") # => "Hello, World"

Book Review: The Rails 4 Way - Fernandez & Faustino

“The Rails 4 Way”, by Obie Fernandez and Kevin Faustino is a great reference book that covers most of what a Rails developer is likely to need on a daily basis. It covers the various DSLs and idioms (i.e. route definition, controller filter declaration, ActiveModel association and validations, etc) without getting into the details of Rails internals and how those features are implemented. The explanations are clear and the code examples relevant.

Just like Rails itself, “The Rails 4 Way” is opinionated and occasionally differs from the omakase 1 way; Most notoriously, but hardly controversial, using Haml as a template engine and Rspec for testing.

Most of the book can be read cover-to-cover or used as a reference on particular topics. The exception is section about rails helpers (Chapter 11) which, as the author themselves point out, is really just an alphabetical listing of the methods available, like the one usually found on appendices or online documentation.

I recommend this book to new Rails developers (maybe after trying out an online tutorial) and for experienced Rails developers who are still working on Rails 3 (or 2!) and are expecting to make the jump to Rails 4 in the near future.


  1. Want a laugh? See the dramatic reading of DHH’s post

Talk: Practical Unix for Ruby and Rails

Last night I had the pleasure of giving a talk at the SDRuby monthly meeting on practical uses of UNIX command line programs for Ruby and Rails developers. Check out the slides! and thanks everyone for the words of encouragment.

We Are All Atom Now

Back in February I wrote about Atom. At the time, I felt Atom showed promise, but was still a bit lacking. After Github announced that Atom is now completely open source in May, I decided to take another look. Most of what I use every day for development is open source, especially the tools with which I make my living: Linux, zsh, Ruby, Rails, etc that I find the idea of my editor being open source very appealing.

Code Navigation

Atom uses ctags, as does other Unix-y editors. Support for jumping back from declarations has now been added, wich was crucial for my workflow. Another issue I had was the lack of context when multiple symbols were listed when navigating, but I managed to wrestle my way through coffeescript to fix that. Now, it works just like I expect it to.

Speed

Atom has much better performance now and it is clear that the development team consider this a priority. Overall, I find that the speed while working in the editor (opening files, editing files, jumping between files, searching) is acceptable and I do not notice and lag. Opening the editor, however is another matter. It is very sluggish, even when opening directories that are not deep and with a small number of files. For example, I enjoy using Atom for my git commit messages since I am already familiar with the navigation and it has a nice syntax formatting. However, some times it takes several seconds to open and makes me want to tear my hair out.

Contributing

Being open source means any one can download the source and hack, but Atom makes it much easier than that. The guide explains how to create new packages for atom and it includes a testing framework out-of-the-box. I had never written a line of coffescript (or much javascript for that matter) and was able to use apm to download a package, make a few fixes and submit a pull request: I can see why there is so much excitement about Atom.

Conclusions

I have been using Atom as my main editor for the last 3 months. For being a beta version, I find the editor more than usable. Sublime Text 2 is a great editor and a lot of Atom is modeled after it (just as Sublime is modeled after TextMate). However, I believe Atom is here to stay and is my main editor for the foreseeable future.