on
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:
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.
I often read open source code when I find time and contribute to open source as well.
Stalk (I mean follow) other Rubyists.
What I want to do soon:
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.
Participate in a hackathon. I never tried.