I’ve noticed a lot of developers in the Rails community have a habit of putting DRY at the top of their “How to write good code” list.
I would warn you against this philosophy. It’s not that DRY code isn’t a valid goal, it’s just that you can DRY your code in ways that violate important software design principles. So put your DRY to one side and start with:
A couple of places where I find developers are far to quick to ‘DRY’ are tests and views.
Test’s shouldn’t get DRYed up. Certainly you can dry up your DSL by creating useful matchers etc, but the more you ‘code’ in your tests, the more they become something else that needs testing.
Views will often be repetitive. Do not dry up views! Just clean up your DSL. If you do something a lot, find a good SOLID helper definition to give it. If your views/partials contain a conditional which handles the differing behaviors of controllers, there’s a good chance you’ve DRYed the wrong thing.
Random thought, but if some developers I’ve known were compilers, they’d create some interesting new types.
We already have:
But now into the mix we see:
and finally
I’ll often link to this on my posts. It’s just 3 caveat’s regarding my posts and where I’m coming from. The intent here is to ask that you consider your comments and replies and reactions in light of these three items:
I haven’t taken the time to try a lot of the patterns and processes I critique in my posts. I think my imagination is powerful enough to not need to pour time into thrashing each approach in real code/life. This is why we have strong communities (or at least need them), communities help you and I see past our assumptions. So by all means comment, just realise that “your way” and “my way”, while one possibly better than the other, might be just too much work to test in a real application. This doesn’t mean I won’t try, it’s just that while something looks great in a “Order Pizza Online” app, it doesn’t necessarily translate to “I’m coding for someone else’s real world requirements”
Hopefully, by posting about it, I can help you with your “imaginings” and you can help me with mine.
I purposefully ignore pleas to “Git’r’done”. It’s true, there are plenty of situations where you can do no better, but I’m not interested in it.
My assumption in writing about software architecture and development practices is that you and I are both on the “Clean code, Crafted Code, Best Practices, Code by convention” page.
I have never claimed to know what I’m talking about ;)
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.
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.
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.
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:
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 :)
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.
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.
Sure there are!
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.
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.
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.
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.
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.
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.
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.