Wednesday, April 23, 2014

Rails, how developers grow, and what's wrong with it

Rails is a great tool for automating the heck out of pumping out a quick and dirty site in short order.

It's a terrible tool for learning. The community isn't like the IRC communities I've been involved in. It's catering for a lot of developers early in their journey.

This is what I see on /r/rails or hacker news or being actively practised far too often:

  • I just discovered service objects
  • Test Driven Development/Unit Tests are dead, because it's too hard to stub out ActiveRecord.
  • Uh, guys, I started using after_save hooks and now my persistence layer is working with Sidekiq and the Mail server to kill all humans.
  • DHH said something outrageous! 60% of us are rushing to take his word as gospel right now; cause like, uh, nuts to the status quo!
  • Oh neat I discovered modules, and that classes are objects, so... like, I'm not going try to do evil... but... here's a gem I wrote that adds a search to all of the defined classes, because it's not like that could cause conflicts; right?

and it makes me cranky. It's actively harmful for people who don't have seasoned peers near them, ready to slide over a polite link on SOLID; or talk to you about the Principle of least astonishment.

Surely we can do better.

Where are the articles on

  • If you are testing your active record instances, that's not a unit test. Go extract your domain models and test those please.
  • Here's 10 terrible ways to write a component/gem/etc; because it's the people using your code that have to put up with your mistakes when your github repo becomes abandonware.
  • How to open up a github project to collaborators when you don't have the time to maintain your code anymore.
  • How to write a decent readme that sums up your gem/repo/etc.
  • What is Single Responsibility Principle? How does it apply within the context of ActiveRecord, Controllers and triggering after-create/after-save events?
  • Why are we OK to use FactoryGirl for tests (obviously useful), but much less willing to use the Factory Pattern to assemble our object graph; when convention breaks down in the face of complexity?
  • KISS: Why it's often worth writing code you might feel is imperfect if it helps your team collectively understand what the heck you are doing.
  • Why version control systems have a blame feature, and the startling reality the next guy looking after your system can track you down and beat you to death with your own severed legs.
  • Stop reading the ember.js documentation now, and just go look at the source code, it'll save us  all a load of time.
  • Magic is generally bad unless you are all wizards; but like Lord of the Rings it's freakin' easy for one or more of you to turn evil.

Interestingly, many these are framework and language agnostic - in my experience though, many framework centric types tend to only know their framework and community; so it distorts their understandings. 
It's not their fault - otherwise smart people have set out to solve a number of problems, then tried to generalise them having already learnt a significant amount of things the hard way - they just keep forgetting to share their learnings.

The best resources I had when I was learning was a mix of IRC (there is nothing like asking a stupid question and realising you just did so infront of the guy who invented the web, or the language you are using right now), and wikis like Portland Pattern Repository.

No comments: