As an “oh yeah… meant to tell you.” – I’ve been CTO of Amicus since the beginning of the year. It’s awesome. We’re helping caused-based organizations kick ass.

Twitter: https://twitter.com/#!/AmicusHQ

Ruby

• 2 space tabs (no tabs)
• wrap 3rd party APIs whenever you’re using them a lot
• use modules to namespace gems with many classes
• try my best to rely on 3rd party code, contribute back when broke
• edge cases aren’t edge cases at scale – they happen. Think about them.
• anything intended for the greater world must be specced to perfection, anything used internally must at the very least have enough specs that I cannot typo anything.
• Interaction with 3rd party APIs are hard to spec which is why it’s better to wrap in your own classes. Initial testing can hit the live API, and then you can move off of doing that.

Rails

• always REST, write controllers as if they were an API
• controllers shouldn’t do much
• models can get kind of thick. Break out into modules when *too* thick, but play that loose.
• classes wrapping models (especially for your REST api) are encouraged and dropped right in the models folder. Model != Db table.
• Rails 3.1+ asset management is a gift. Use it. Pass config from backend to front end using erb.
• Your models should be very well specced. Your controllers really only need a surface layer. Acceptance tests are awesome to have when you get there.

JavaScript

• CoffeeScript is better
• jQuery is a gift. Use it.
• namespace everything – global functions do not belong
• any custom code you use belongs in your own namespace at Motionbox we used MBX.blah
• I tend to believe that changing prototypes is OK, but I recognize the why of “don’t” and so don’t do it myself. I don’t avoid libraries just because they change prototypes.
• Use an MVC framework (even for little things).
• Spec out the MVC models. I rely on the acceptance tests for the V and C code (mostly). Any tests that rely on HTML can be brittle.

CSS/HTML

• namespace all your CSS under one global class (you’ll thank me later)
• never use style words in your classes or IDs. HTML is supposed to be what a document IS not what a document looks like. If something is a submit button it’s a “submit-button” not a “blue-submit-button.”
• Use the minimum amount of HTML to have your app look right. Play with it, don’t just git ‘er done.
• HTML should at least look like it’s functional (forms should point at the right place and be submittable). However, I’m not a zealot when it comes to progressive javascript enhancement. My target audience probably has Javascript enabled. Yours may not… think about your audience.

IE doesn’t allow you to set cookies when your site is in an iframe unless your site has set P3P headers. Also, ordering matters – the P3P header must be set *before* the cookie is set.

If you’re using ruby, this gem works pretty well: https://github.com/hoopla/rack-p3p

Further reading: http://stackoverflow.com/questions/389456/cookie-blocked-not-saved-in-iframe-in-internet-explorer

All the articles I read about setting headers, etags, etc were all really old. Hopefully, if you’re using rails you found this article. Just install the gem and add the line from the README to your application.rb – no monkey patching. Good luck.

/users/my.username/files/file.ext

Rails will parse that first period as the beginning of the format param… so you lose the files route, etc.

It does let you use %2E though which will be unescaped to the period in your params… so

/users/my%2Eusername/files/file.ext

will give you the correct user_id param of “my.username” and continue on its routed merry way.

Just a simple reminder. Probably more for me than you

His 2005 Stanford commencement speech [VIDEO] was powerful at the time, but now carries even more weight. “Stay Young. Stay Foolish.” At 56, I guess he will always remain young, but he was certainly not foolish.

Steve Jobs set an example that almost none of us will attain, but in striving we hope to make the world just a little bit better.

http://www.quirksmode.org/blog/archives/2011/08/twelve_steps_fo.html

Exactly. I’ll go one step further and say “be the cloud OS that no one else is.” Embrace the web. It could save you. I’d like to do a longer discussion on this, but I have to watch my words (probably, no one has told me this).

Wow. This woman describes succinctly what I’ve been trying to describe for a few years now. At the ol’ Motionbox (pre Snapfish acquisition) this is exactly what we were doing. We went from the horrible waterfall, to a version of Agile (not formal) and settled on something remarkably like what Mary writes.

It worked fantastically. It keeps everybody invested and focused on the end result rather than the details. It also keeps your team working together and doesn’t allow for excuses like “that wasn’t on the list.”

It, however, does require everyone on your team to be a good-to-great communicator and to be very good at their jobs (weak links stick out like sore thumbs). However, if that’s not what you’re striving for anyway… you’re probably doing it wrong.

Hardcore agile guys… what’s your take?

I’ve never been the zealot that makes sure all code is perfect before shipping. I also recognize the tremendous value that aesthetic code brings (that’s why I’m a ruby guy). However, the important part of writing code is getting it out to the users. Those users might be your fellow coworkers (if you’re doing something back-endy) or they might be consumers.

My code will not matter unless someone is using it. So I get it out quickly.

That being said, I’ve seen us cut corners too many times and it always comes back to haunt. It costs hours and hours cost dollars. Bad code is not good for anybody.

My users will suffer from bad code because I won’t be able to react to their needs in a timely manner.

I think I have been intuitively following a pattern now for a while that seems to work out. I’ve been calling it “Path to Pretty” in my head.

It’s ok to ship code that I would consider lacking if the intent and next steps for improvement are clear.

By clear I mean that I must be able to go back in 2 months, look at the code and intuitively see what I was trying to do. If it’s not fully optimized or there are 20 extra lines, so be it.

As long as there is a clear path to pretty I now consider my code shippable.

Footnote: I’m sure I’m not the first person to do this and there’s probably some other name for this technique. This article was mostly for my own selfish benefit.

I started looking around for ruby libraries, but nothing was as mature as I would like. I forked a branch on github and chugged along on getting the jruby and c versions to work with the same api.

Zookeeper exposes a super simple API, but with that simple stuff you can build a lot of complex cluster logic.

A limited api of create, delete, get, set, watch lets you do some really advanced things around a cluster.

Examples

I added some abstractions based on the Zookeeper recipes.

Locks

Message Queues

I also implemented a simple message queue on top of zookeeper. However, because of the way the zookeeper "children" calls are made (returning all children), I wouldn't recommend using this for queues where pending messages will reach into the thousands.

More...

There's a ton you can do with this thing (priority queues, meta data store, etc). I think it's a nice addition to the ruby toolset.

I'm just pondering now... trying to flesh out what I think is going to happen and how we can embrace it sooner.

TO COME:
Events: Modern JavaScript architecture is actually pretty powerful, how can we take the "bolted on functionality" approach to servers.
Messages: They're kinda like events right?
Request/Response Cycle: it's probably dead?