Yet Another Developer

Rasheed Abdul-Aziz.
Clean Coder, Agilist, Ruby developer

Robotlegs. Getting Started

Now to follow up the previous post, I thought I’d share a list of useful resources you can use to make your life better with Robotlegs MVCS.

MVCS vs Core

First, a very quick but important point. Robotlegs “Core” is a very light prescription that defines interfaces only, for however you might want to structure your application. You can use as little or as much as you want. It is in fact, more complicated than the MVCS base implementation. I am going to focus on the MVCS implementation.

Notice those last two links are to the asdoc’s of Robotlegs? I urge you to ignore them. There are better ways to ‘grok’ how Robotlegs works.

MVCS is all you need.

To write a fantastic, best of breed, cleanly coded, easily maintainable application, all you need is the Robotlegs MVCS. Sincerely. There are some nice additions cropping up that improve some aspects, but not so significantly that you can’t do without them.

MVCS is only part of the picture.

To contradict myself, the Robotlegs MVCS is only a prescription for your application architecture. Specifically, it helps you string together service calls, domain modelling, mediation of views and user generated events. On top of that, it gives you, by default, a supremely simple and efficient IoC framework called SwiftSuspenders.

MVCS does not:

  • Replace a UI framework.
  • Replace a game loop.
  • Help with animations.
  • etc…

It should be evident, that if you want some 2D physics functionality, it wont be in Robotlegs. But whatever you pick for your physics engine, Robotlegs won’t get in the way :)

Okay, So how do you get started?

  • Keep the Robotlegs Best Practices handy.
  • Install Git and a nice graphical Git client. I like SmartGit
  • Download the Robotlegs swc, it’s simpler than working from the source. Use the download link on the Robotlegs homepage.
  • Use git to check out the Robotlegs demo bundle.
  • Start with the introduction to dependency injection
  • Use the demo ‘Hello[Flex|Flash]’ example, and my favorite, the ‘FlickrImageService’ demo. You will find these in the demo bundle. The Flickr demo is Flex 4, but it still makes a lot of sense and works well as cliffnotes.
  • Continually re-read the Best Practices.

Re-read best practices? Snore!

No really. I don’t mean start to end. I mean every time you question yourself, check the appropriate section. It does a great job of describing the responsibilities of each class of your application.

This is the point. Deep down, Robotlegs is for craftsmen, people who think that a brilliantly engineered, easy to repair, well laid out classic car is a thing of beauty. For people who remember being able to mod their Commodore 64.

A vintage piece of furniture get’s restored because it’s worth restoring. Code written 2 years ago is still maintainable when it’s worth maintaining. This is your investment in the future.

You get to this place by separating concerns and being as consistent as possible.

Use a State Machine to bootstrap

As your first projects get bigger, the context will get really spammy. I recommend Joel’s approach of using a state machine to bootstrap. I’m not a fan of the XML markup state machine, but it’s better than nothing. Visfleet has a StateMachine that’s described as a DSL, it works in house with an adaptor I’ve written, and I hope to release this, wrapped with tests, shortly.

How about help when I get stuck?

  • Twitter with #robotlegs often helps.
  • Ask the Robotlegs Knowledgebase - It’s important you ask your sensible questions here so that the community gains the collective’s answers in one place.
  • Search the Robotlegs Knowledgebase - see previous point.
  • The chat. It’s quiet now, but it’s growing. We had 10 users in there the other day, which meant that most questions this week got answered. It’s nice sometimes to be interactive.
  • Read the groups, but as I mentioned in the previous post, it’s easy to get lost on there.

Any other great resources?

Sure there are!

  • Joel’s presentation slides are awesome
  • The community blog lists recent contributions, samples, demos, screencasts and what-not from the community at large. I try to maintain that page, so drop me a line if you think something needs a mention.
  • Twitter, again, search #robotlegs.
  • User groups are starting to pay attention. Hopefully here in Auckland I’ll present Robotlegs to the Auckland Flash Platform Group sometime soon.
  • Robotlegs is getting a lot of mention at conferences. Take a look at FATC and 360Flex

Good Reads

Did I miss anything?

Did I? Have any other points of view to share? I remembered to bring disqus over to this blog last night so we have comments :) Look forward to hearing from you.

Robotlegs, On the wrong foot.

Disclaimer: My experiences may differ considerably from yours, YMMV.

This article was going to be a “Getting started” guide. I wanted to share the resources I’ve used and how they helped. As I wrote the article it began to sound like a “how not to get started” guide. So now that’s what it is. I’ll follow up with the Getting started guide in my next post.

Robotlegs Google Groups

I tried to follow the conversations on the Robotlegs group.

Following the conversations on the groups required some explicit knowledge of a lot of jargon. The jargon is easier to understand after you’ve worked with the framework.

Smalltalk MVC

I tried to apply my understanding of the history of MVC to Robotlegs

Actually I found bothering with any definition of MVC, even Fowler’s, didn’t help me stay clear on what I was doing with Robotlegs. I’ve never liked “MVC” for the dilution of terms it’s suffered over time. I think it should be called a programming “Mode” and not a pattern.

Robotlegs is lightweight, do your own thing

I listened to the “You can change Robotlegs to suit your own approach” that Joel and Shaun often said (paraphrased here).

I agree, it’s super light in it’s prescription at the Core level. At the MVCS level it’s still a light prescription. This is no reason to tamper with things until you’re well down the path. Trust me on this. Robotlegs MVCS is an amazing prescription, especially if you care for clean, well crafted code that anyone can read.

Distractions and ego

I thought with my extensive history with Flex, lightweight architectures etc, that I would want to build from Core and not use the MVCS. Don’t do this, not yet, and possibly never.

Then I was tempted to use Controllers over Commands.

Jesse Warden and a couple of others seemed to be a proponent of this shortcut. Honestly, before RL, so was I. I think Controlelrs can be O.k. but not when you’re trying to learn the Robotlegs MVCS and certainly not when you care about beautifully crafted code.

I’d argue that Controllers have more responsibilities than they need (where commands limit responsibilities to one). Also Controllers are too easy to abuse. You put state in to code something up quickly and suddenly you’re no better off than you were before you started separating concerns.

Then there was AS3Signals (which I really do plan on using). It’s a beautiful and elegant distraction. But don’t mess with it ‘till after. Just because it makes reading the demo bundle and literature more difficult.

Finally I got sidetracked by modular app development and sub-contexts for components. I wasted time trying, and did not learn much, other than realising it’s possible to write the meat of most applications without any of the above.

Summary

Really in closing, if I leave you with nothing else for now: Start with the MVCS Prescription and The demo bundle. I’ll make some more in depth suggestions in the next post.