Book Shelf Clearing

Written on 9:52:00 PM by S. Potter

In an effort to reorganize my office, I am clearing off space on my bookshelves and selling books (on Amazon marketplace) that I have already read. Since they are all software development related I thought I would list the most relevant below in case any blog readers are looking for books on the subject for cheap:

  • [SOLD] Deploying Rails Applications: A Step-by-Step Guide (Facets of Ruby) (buy it new or used)
    Very good for the beginner or intermediate Capistrano recipe writer. It also contains some good pointers at the end of the book on benchmarking. Released relatively recently (within 3 months I think?)
  • SOA in Practice: The Art of Distributed System Design (Theory in Practice) (Published Aug 2007)
    This book is more for the unRESTful SOA types than the RESTful folk like me. The author obviously has some old-time experience, so if you are into old school SOA standards (WSDL, SOAP, UDDI) then this would provide a lot of good architect-level areas to consider, which are often ignored including: service lifecycle, versioning, security, service management and more. One gripe I had with the book is in the versioning section. Let's just say his preference for naming is definitely NOT my style:) Otherwise this contains good reading material for the architect just getting into SOA in an enterprise setting.
  • Rails Cookbook (Cookbooks (O'Reilly))
    Great for starting Rails projects with limited Ruby on Rails experience. It covers Rails 1.2, but most recipes will only require minor changes.
  • The Art of Agile Development
    Covers all aspects of agile development from planning to delivery. If you aren't already an agile development ninja, this is in my top three agile books.
  • Webbots, Spiders, and Screen Scrapers: A Guide to Developing Internet Agents with PHP/CURL
    Last year I had to work (for a short while) with PHP in the crawling/bot arena. This book contained got me developing bots and crawlers in no time in PHP.
  • Ajax on Rails
    This would be a decent book for Rails developers that aren't believers in Unobtrusive Javascript (UJS). I have to purge this book from my bookcase now that I am a big UJS convert:) I hope you understand. I got this when it first came out, before I had seen the light. Seriously though, if you don't care about UJS principles, this book covers good ground on using AJAX Rails helpers. You should realize that the book was written pre-2.0 (Rails release that is).
Also those wanting to branch out on their own as a consultant, the following books might be for you as I found both very helpful when first starting my software consulting practice in 2001:
  • Getting Started in Consulting
    If I could only recommend one of these two consulting books it would be this one hands down, since this is more about general consulting principles and practices and the second book might be slightly dated in the initial chapters, because both were written before the software outsourcing/offshoring mania.
  • Getting Started in Computer Consulting
PS I have been using Amazon Prime for two months now and love it. You can try Amazon Prime FREE for one month if you like too.

Tips to Enterpreneurs Hiring Ruby on Rails Consulting Firms

Written on 10:20:00 AM by S. Potter

I know I am taking a break from my DataMapper/Merb series of posts today, but I have seen enough fakers out there in the Ruby on Rails world that I just have to get a few things off my chest: Below is a list of things to avoid when hiring a Ruby on Rails consulting firm:

  • Overexcited marketing speak. Drop any firm that has something like the following on their website: "We believe Ruby on Rails is the most elegant, powerful programming language on the planet". These people might know a thing or two about configuring WordPress or Drupal or perhaps only Photoshop, but definitely no serious Object Oriented development of large scale Ruby server applications. Basically anyone that calls "Ruby on Rails" as a whole a programming language has an inadequate skill set to build a non-trivial web application. In addition anyone that knows more than three non-similar programming languages will know Ruby is not "the most powerful programming language on the planet". Sorry I had to find a quote on the web to prove I wasn't exaggerating. There are many more fakers on the web too, so look out! Remember you aren't looking for people using the most powerful programming language, you want results.
  • Agile this, agile that, agile everywhere. Beware of firms using the word agile like there is no tomorrow. Some use is fine, but ask them what they mean by agile. And what benefits you, the client, will receive from an agile team. Don't get me wrong if a web application is built in an iterative fashion with lots of client involvement and sign off, with lots of useful automated tests/specs that are run often then this is almost certainly a great thing for the project. However, beware of the firms or freelancers that are using agile simply as a buzzword. (Note: some firms like mine use agile a lot in web page titles for SEO purposes, so not all firms that use agile a lot in titles are faking. So make sure to ask firms what they mean by the word agile when they use it).
  • Why Rails? If any firm tells you that a web application written using Django, TurboGears, Merb or other web frameworks will never be as good as a Rails web application, then drop them off your consideration list immediately. The same is true if the converse is said. If they answer with something more measured and sensible like "our engineers have found developing applications in Rails to be more productive than X, Y and Z, which we previously used, and it provides us with the right amount of control/flexibility without us needing to worry about all configuration than previous frameworks" then at least they aren't misleading you just to get a sale. Of course, you might be looking for other points in the answer (other attributes of a web framework that would make business sense like active community, skillset, etc.). Also in general you should look for measured answers to all your questions, not answers that lack insight and promise they can do EVERYTHING under the sun for you in 2 weeks time. You will be disappointed if you hire that firm or freelancer.
  • Expert in everything, expert in nothing. Consulting firms and/or freelancers need to choose a specific set of technical competencies so they can be experts in those areas. Beware of consulting firms or freelancers that claim to be experts in every framework, programming language and operating system.
  • Ubiquitous buzzwords. Beware of too many buzzwords. Even if you know what a buzzword means, ask the person using too much jargon to clarify so you can evaluate whether they really know what they are saying.
  • Everything AJAX. I previously worked through a consulting firm on the west coast (I'll not name names). The consulting manager who led project management functions on all the firms' projects was convinced that if we just put an AJAX form in here and there it would solve all our problems. My experience with this firm wasn't overly positive. I like the people on a personal level, but their work quality and focus tended to create hard to use web applications. Beware of people who think AJAX is the answer to everything. It has its place, but don't go overboard. PS Make sure the people you hire write unobtrusive Javascript rather than embedded Rails Prototype helpers. UJS has many benefits including graceful degradation (benefiting those that do not have Javascript enabled), avoiding browser incompatibilities and improved code organization (separation of concerns). Users of your web application will appreciate the forethought and your developers can be more productive!:) Win-win.
  • Novice.has_many :problems Look for previous Object Oriented modeling experience for the engineers on the project team. Even though ActiveRecord (the default Ruby on Rails Object Relational Mapping framework) provides a higher level of abstraction for ORM associations than other frameworks, don't be fooled into thinking anyone can model your business domain correctly without experience and/or know-how. Many developers who are used to using Hibernate or TOPLink (as only two examples) before in Java or Smalltalk respectively will have likely done a lot of OO modeling. Ask them about the most complex business domain they have modeled previously to be able to guage their skill level and experience in this area. This point is most important in applications that have more complex business domains.
  • Why should I care about your data? Look at my cool Photoshop spinning logo. Rails consulting firms and/or freelancers should have a good understanding of the importance of data modeling. Even if they do not have specific data modeling expertise they should at least know that indexing appropriate columns and defining column size limits where appropriate can save not just storage space, but also shave time off queries (depending on the query and usage scenario). That way when your application gets to the point where the database needs to be fine tuned, the data architect you hire will have an easier job than if your schema was designed by a PHP weekender that thinks the Drupal or WordPress database schema is finely tuned (sorry, it's horrendous and yes you should know that anyway). This is a very important consideration if your application is supposed to hold a considerable amount of data and/or if you have strong reporting requirements. As a side note, make sure to ask them if different database schemas are sometimes needed for querying large data sets (classical reporting requirements) versus CRUD usages. The answer should be yes and you should ask them to explain this a little to see how much they really understand.
  • I can design, develop, deploy and manage perfectly. Usually firms and freelancers are much better in one or two areas than all equally. Some are better at graphic design and got into development to earn $20/hr extra. That's fine, but you should know what you are getting yourself into. Ask what their strengths and weaknesses are. For example, I am excellent at developing and very good at deploying and systems engineering. I can use Photoshop and Illustrator (just like graphic designers can copy Rails code from forums and paste it into their editor), but ask me to create a visually stunning logo that encapsulates your company's image and I am lost (just like the graphic designers that can't write original code themselves). Know what is most important for your application needs and hire the appropriate people. Usually outsourcing graphic design to a design firm and hiring a flexible developer that can work with external teams well, gets you the best value for money. Throw away the firms and people that don't have any weaknesses. They are lying.
One point I would like to make to round this piece off is that if you find a young, eager engineer with higher than average aptitude, he/she can really do a lot for your project. However, you should expect them to make a few mistakes. Nobody is perfect and without prior experience with large scale server applications it is virtually impossible for someone not to make mistakes. If you can afford a few mistakes here and there, then this might be the way to go. Give them an equity stake if capital is an issue for you, they are more likely to take a risk with you than a seasoned consultant with a mortgage to pay or spouse and children to feed. However, never hire someone who claims to be a Ruby/Rails expert at a high rate if they simply copy and paste sample code from Ruby/Rails forums online (you would be surprised how many there are out there). It's a terrible waste of your capital and frankly it takes work away from better firms and/or freelancers out there and you will end up with badly written software that runs poorly. As a final note, hire a firm, freelancer or in-house engineer that has similar energy level and compatible personality to yours. Or at a minimum hire a firm or freelancer that you can trust and has been recommended, but not just through popularity contests like those at (I know three freelancers who are excellent Ruby engineers with only have 1 recommendation on the site and I have worked with one person that has more than ten recommendations and consider them subpar to most Ruby/Rails developers I know).

DataMapper: Flexibility of mapping model attributes to table columns

Written on 10:13:00 AM by S. Potter

I know an esteemed ex-colleague of mine (even if he is an Apple zombie now - yes, becoming a fan of Apple on Facebook deserves some heckling;)) has reservations about the apparent unDRY-ness of DataMapper with migrations. I used to share his reservations before I wrote two applications using DataMapper. Neither Merb application was particularly spectacular, but both had to work with legacy database schemas. Oh the joys of crazy DBA naming conventions! Let's look at a brief example of DBA naming madness (some names were changed, but the conventions used are the same):

  - uid_int: int (PK)
  - acc_id_int: int
  - amt_int: int
  - ref_code_string: varchar(64) natural key
  - desc_string: varchar(128)
  - entered_dt: datetime
  - changed_dt: datetime
In another table managed by a different group we had:
  - ID: int (PK)
  - Balance: int
  - UserID: int (FK)
  - EnteredDateTime: datetime
  - ChangedDateTime: datetime
I kid you not. Two different conventions, both relatively unreadable as Ruby attributes as they both violate popular coding conventions in some way. In ActiveRecord you would be left doing non-trivial coding to hide the ugly column names in the model and map Ruby-friendly names to the appropriate column. In DataMapper this is not so. Lending from the design pattern's primary purpose - to explicitly map model attributes to database columns to decouple the two - we can write something like the following using DM:

class Order
  include DataMapper::Resource
  set_table_name("ordersTable") #ridiculous name really, but what can you do if other older applications rely on this already?

  has(1, :account, :child_key => 'acc_id_int', :repository => repository(:accounts))
  property(:id, Integer, :serial => true, :field => 'uid')
  property(:amount, Integer, :field => 'amt_int')
  property(:reference, String, :field => 'ref_code_string', :key => true)
  property(:description, String, :field => 'desc_string')
  property(:created_at, DateTime, :field => 'entered_dt')
  property(:changed_dt, DateTime, :field => 'changed_dt')

class Account
  include DataMapper::Resource

  property(:id, Integer, :serial => true, :field => 'ID')
  property(:balance, Integer, :field => 'Balance')
  property(:created_at, DateTime, :field => 'EnteredDateTime')
  property(:updated_at, DateTime, :field => 'ChangedDateTime')

This way we can write readable Ruby code with the model. Next time we can look at lazy loading: how to switch it on and off and when to use it for greater effect.

DataMapper does have migrations

Written on 9:27:00 AM by S. Potter

I wanted to bust a myth out there that DataMapper does not have regular migrations, just the auto migrations. At least in post 0.9 versions DataMapper has both. In other blogs about the topic I found quotes like: "DataMapper migrations pull your database structure directly from the Ruby code for your models, so there’s no need to write separate migration files...". This, in my opinion, gives the wrong impression to those that are worried about non-trivial schema migrations. The author of that quote appears to have never moved one column into multiple or vice versa (a non-trivial schema change), among other schema changes where a DataMapper auto migration would not work in a production environment. In merb you can just create a new DM migration with the following: $ merb-gen migration name_of_your_migration (Assuming you have set the use_orm setting to :datamapper in config/init.rb.) A simple DataMapper migration might look something like:

migration 1, :create_orders  do
  up do
    create_table(:orders) do
      column(:id, Integer, :serial => true)
      column(:amount, Integer)
      column(:completed, Boolean)
      column(:description, String, :size => 255)
      column(:created_at, DateTime)
      column(:updated_at, DateTime)

  down do

If you have problems with Boolean not being recognized, throw in the line: include DataMapper::Types to the top of the migration (yes, this needs some finessing obviously). Hope that helps a few people that may have been mislead by some blog posts inadvertently. Migrations are needed for many cases I come across where auto migrations just will not cut it without losing data in production (not a good thing if data matters in your application:)). BTW A minor annoyance of mine in Merb is that for DM migrations you need to use this ugly Rake task: dm:db:migrate to migrate to latest version. To rollback migrations you need to use this ugly thing: dm:db:migrate:down[version]. Where those using AR in Merb just keep using db:migrate and db:rollback. This is an area that needs cleaning up to promote ORM agnosticism the way Merb is supposed to do.