Yet Another Developer

Not as awesome as Audiotool. But I _love_ the design.

So my apartment building has one of those annoying air-lock style entryways. Luckily mine is only keyed on the second door, so I don't have to fumble with keys outside exposed to the weather. However the inside door has a really difficult lock. It has managed to skin my knuckles twice in 2 weeks. To me this was a perfect opportunity to make something with an Arduino :D ## The Idea It's simple really. The front door can be opened by pressing the 'door' button on my door intercom.  That's the button on the right. This is inside my apartment. These things are pretty common in New York. So all I need to do is find a way of pressing that button from outside my apartment building. ## Design choices I first thought of using an RF key fob. I still like that idea, I'm looking at [this project](http://www.opensourcerf.com/) for inspiration. The only problems are: - I don't understand RF very well. I don't want to spend money on parts that may not do what I need, or take too long for me to comprehend. - I already have an Arduino Uno with me in NYC. - I've been itching to use the Ethernet shield on my Arduino :D If my first version goes well, then I'll look into using RF. ## The Plan 1. Connect my Arduino+Ethernet to my home network. 1. Connect to my home network via my phone as I walk up the front steps of my apartment building. 1. Open a saved web link on the phone which points to the Arduino. 1. Click a button in the web app, which tells the Arduino to energise a relay which in turn 'presses' the door button. ## Next Steps Next up, I need to prove the basics. Can I easily hijack the door button on my door intercom? Can I get onto my network quickly with my phone. As a further stretch. I'd like to have the phone present me with the web app as soon as I join the home network.

I should have listened to those people telling me to use Ableton! This is the result of my first hour tweaking.

I haven't done much documentation yet either, but the most important thing is there, TESTS! :D

Making the round, 'in your face' at the 'surface'. Let's be rational for one second. A laptop does not usually have a detachable keyboard, very few are this lightweight and thin, and very few are touch screen.

I saw a presentation from Richard Hickey, who I admire a great deal. But i think he committed a fallacy of some kind when he compared Tests and Guardrails (he may have been echoing someone else's fallacy, I'm not sure). I don't see Tests as guardrails on the programming road. I see them as an integral part of the road infrastructure.

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.

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: ## Caveat 1 ## 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. ## Caveat 2 ## 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. ## Caveat 3 ## I have never claimed to know what I'm talking about ;)

Now to follow up [the previous post](http://squeedee.tumblr.com/post/388804844/robotlegs-on-the-wrong-foot), I thought I'd share a list of useful resources you can use to make your life better with [Robotlegs](http://www.robotlegs.org) MVCS. ## MVCS vs Core First, a very quick but important point. Robotlegs ["Core"](http://api.robotlegs.org/org/robotlegs/core/package-detail.html) 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](http://api.robotlegs.org/org/robotlegs/mvcs/package-detail.html). 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](http://github.com/tschneidereit/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](http://wiki.github.com/robotlegs/robotlegs-framework/best-practices) handy. - Install [Git](http://git-scm.com/) and a nice graphical Git client. I like [SmartGit](http://www.syntevo.com/smartgit/index.html) - Download the Robotlegs swc, it's simpler than working from the source. Use the download link on the [Robotlegs homepage](http://www.robotlegs.org/). - Use git to check out the [Robotlegs demo bundle](http://github.com/robotlegs/robotlegs-demos-Bundle). - Start with the [introduction to dependency injection](http://wiki.github.com/robotlegs/robotlegs-framework/best-practices#dependencyinjection) - 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](http://github.com/robotlegs/robotlegs-utilities-StateMachine). 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 ](http://knowledge.robotlegs.org/) - 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 ](http://knowledge.robotlegs.org/) - see previous point. - [The chat](http://www.robotlegs.org/community/chat.html). 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](http://groups.google.com/group/robotlegs), but as I mentioned in [the previous post](http://squeedee.tumblr.com/post/388804844/robotlegs-on-the-wrong-foot), it's easy to get lost on there. ## Any other great resources? Sure there are! - [Joel's presentation slides](http://joelhooks.com/2009/11/14/texflex09-robotlegs-slides-and-a-robotlegs-t-shirt-giveaway/) are awesome - [The community blog](http://www.robotlegs.org/community/) 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](http://www.flashandthecity.com/) and [360Flex](http://www.360flex.com/) ## Good Reads - [Martin Fowler's Refactoring ](http://www.amazon.com/exec/obidos/ASIN/0201485672) - Hell, [Martin's whole site](http://www.martinfowler.com/) :) - [Rob Martin's Clean Code](http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882) - I hear this is good, I've not found time to read it yet. ## 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.

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](http://wiki.github.com/robotlegs/robotlegs-framework/best-practices) and [The demo bundle](http://github.com/robotlegs/robotlegs-demos-Bundle). I’ll make some more in depth suggestions in the next post.