Engineering Long-Lasting Software Alpha Edition Review

There’s a reason why I bought and read this book apart from its rather catchy title: Engineering Long-Lasting Software: An Agile Approach Using SaaS and Cloud Computing, Alpha Edition.

I’m always looking for good programming resources for beginners and experienced developers. I think I was asked several times through this blog about resources and I could only give common ones. Some of those who asked were from New York, India and elsewhere.

In the past five years or so, there were only a few resources on Ruby on Rails. Best practices and better guides were written a few years later as developers realized how they should code.

The Kindle book costs $11.99 and it was worth reading. It’s best to read it using Kindle for Mac or Kindle for PC. I think it’s a good book for those who have insufficient background in web software development and/or Ruby on Rails.

The introduction is heavy with theory but not knowing how “things connect” is a real predicament.

In the first chapter, you’d read about the difference of engineering software from hardware. The differences may be apparent but realizing what the difference means matters.

Successful software can live decades and is expected to evolve and improve, unlike computer hardware that is finalized at time of manufacture and can be considered obsolete within just a few years.

I think that applies to web software development but less for mobile application development.

Throughout the book, there’s an emphasis on beautiful code. Some often don’t understand why Rubyists like poetry code and conciseness and why it has anything to do with software life. I think the authors did a great job of explaining even without quotations like this:

Ugly programs are like ugly suspension bridges: they’re much more liable to collapse than pretty ones, because the way humans (especially engineer-humans) perceive beauty is intimately related to our ability to process and understand complexity. A language that makes it hard to write elegant code makes it hard to write good code. Eric S. Raymond

The walk-through on Ruby was a little focused on those with background in Java but it was still good. Some Ruby examples include the use of “method_missing” and how to create pretty time helpers similar to what ActiveSupport provides.

class Fixnum
  def seconds  ; self ; end
  def minutes  ; self * 60 ; end
  def hours    ; self * 60 * 60 ; end
  def ago      ; Time.now - self ; end
  def from_now ; Time.now + self ; end
end
Time.now    
# => Mon Nov 07 10:18:10 -0800 2011
5.minutes.ago
# => Mon Nov 07 10:13:15 -0800 2011
5.minutes - 4.minutes
# => 60
3.hours.from_now
# => Mon Nov 07 13:18:15 -0800 2011

The book isn’t free of error like many other technical books. I’ve encountered some problems with code examples but I think those are trivial.

On each chapter, they mention pitfalls. I could not agree more with this:

Pitfall: Relying too heavily on just one kind of test

It’s kind of common even for teams to leave out a few tests. I often see open source projects without unit tests and integration tests. The only tests that exist are functional tests. It seems that many embrace this due to time issues. Ash Maurya, author of Running Lean, prefers “functional tests over unit tests.” But reading the next few lines, he actually really meant integration tests.

These bootstrappers often want to save some money and time as they are just validating their idea so they often given technical specifications that “if it takes too long to write unit tests, don’t do it.” It’s like choosing which grammar mistake to commit because Twitter only allows 140 characters. There are always limitations and there should always be limitations.

In my case, I normally write unit, functional and integration tests for all projects. But I honestly write more integration tests and less unit tests like most developers. Be careful of not writing validation tests for models though. It could cost you in the long run.

Pitfall: Nesting resources more than one level deep

  resources :movies do 
    resources :reviews do 
      resources :users do 
        resources :ratings
      end 
    end
  end

Don’t do that.

I think my favorite chapter is chapter 8 (working with teams vs. individually) and I wish the missing chapters (9 and 10) weren’t missing.

Etcetera

You don’t need to pay over $1,000 USD to learn Ruby on Rails

They usually never ask for certificates. I always wondered why on tech conferences we organized, they asked for it. Some companies do ask for it but for those hiring Ruby on Rails developers, they never do that.

I personally think it doesn’t matter and for future events we will co-organize, we will not give certificates even if they ask for it. I found those who didn’t ask for it were more attentive.

If you buy some of the books recommended by the authors of this book, it would not cost $1000.

Here are a few things I do or intend to do which could help some beginners:

What I did a few years ago which I still do now:

  1. I usually download the Rails searchable API doc and make it available for access through http://localhost/rdoc. If you have Apache web server installed then this is very easy. This makes it easy to search for existing methods and helpers so you don’t have to create them.

  2. I often read open source code when I find time and contribute to open source as well.

  3. Stalk (I mean follow) other Rubyists.

What I want to do soon:

  1. Participate in code reviews (open source). I could start a new group or join an existing one. It seems easier to do the former. Please let me know if you are interested.

  2. Participate in a hackathon. I never tried.