Are you ready to Level-Up?

March 19th-23rd: try{harder} Level Up is a conference with a difference:

1. 5 days, 4 nights.
2. 8 try{harder} mentors who took part in the original try{harder} and want to share it with…
3. 8 new try{harder} participants who want to level-up.
4. Everybody teaches, everybody learns.

You can read more about how try{harder} came about here, or skip straight to the Level Up conference details.

Why this, and why now?

We actually decided to run try{harder} Level Up almost as soon as we’d returned from the original event in October. All 16 members of the original meeting wanted to commit to a repeat event in 2012, and we felt that it would be ideal to run it as a ‘closed’ group – we’d been changed by an incredibly rich experience and wanted to pick up from the same place next time.

But the experience also felt too valuable not to share. try{harder} was the best conference we’d been to. We’d learned more in those 4 days than at every other conference we’d ever attended, put together.

So, it was suggested that perhaps the people who would benefit most of all would be those who are right on the cusp of becoming ‘advanced’ developers. People who will be the fresh faces on the conference circuit in a year or two, given the right mentoring and an opportunity to learn not just about their discipline, but also about learning itself.

And then Adobe murdered our baby

I’d intended to launch the Level Up conference in November. And then there came the week of the Adobepocalyse, and it felt like there were more urgent conversations for our community to be having.

In the weeks following, what emerged was a feeling not that the conference was irrelevant, but that it was more relevant than ever before: we need to be ready to deliver projects in different ways, with stronger meta-skills and a broader understanding of the problem space we operate in than ever.

We don’t know what we’ll be doing 2 years from now, except that it won’t be what we’re doing today. In that context, a conference that covers a wide range of advanced development subjects as seminars, where you also benefit from the insight emerging in the questions of fifteen of your peers from different backgrounds, feels like an excellent fit.

Do you want to try{harder}?

Pound (or dollar or euro) for pound and hour for hour, try{harder} will surpass any other learning experience available. You’ll also work with a try{harder} mentor to create your own seminar. So if you’ve ever wanted to speak at one of the major industry conferences, this is a chance to get the kind of experience that can make that possible.

We expect that you’ll become a member of the try{harder} family – with ongoing access to mentoring and advice from a diverse range of experts.

You’ll build relationships with other inspirational developers, and if you’re lucky then it can also lead to future work. Dominic (@devboy_org) recently moved to San Francisco to work with Alec (alecmce), as a direct result of the time they spent coding together at try{harder}.

One of the things that emerged out of try{harder} in October was that many of us feel driven to work on meaningful projects, and this is something we hope to be able to collaborate on in future.

But don’t just take my word for it – read for yourself:

What to tell your boss

If you’re selling this idea to your boss, they probably don’t want you dreaming about running away to join the try{harder} circus… but we do use each other for confidential consultation on technical problems; having a network of advanced developers who willingly lend their experience when you encounter something new or unexpected is invaluable.

Because of the size of the group, in every session you can ask the questions that make it relevant to the challenges you’re facing at work right now.

If you’re a mid-to-senior level developer you should leave try{harder} Level Up ready to lead projects. If you’re already a senior developer you’ll go back to work more effective, more efficient and more flexible than ever.

In his article “No Silver Bullet: Essence and Accidents of Software Engineering”, Frederick P. Brooks analyses the key factors in creating great Software Designers – the people who don’t just write code, but creatively determine what code should be written (we probably refer to them as architects or technical leads). It’s worth reading the whole article but the part you need your boss to read is this final summary:

How to grow great designers? Space does not permit a lengthy discussion, but some steps are obvious:
1. Systematically identify top designers as early as possible. The best are often not the most experienced.
2. Assign a career mentor to be responsible for the development of the prospect, and carefully keep a career file.
3. Devise and maintain a career development plan for each prospect, including carefully selected apprenticeships with top designers, episodes of advanced formal education, and short courses, all interspersed with solo-design and technical leadership assignments.
4. Provide opportunities for growing designers to interact with and stimulate each other.

try{harder} is a high quality, concentrated dose of point (4), picking up point (3) and creating opportunities for (2) along the way. All you need now is for your boss to identify you as advised in (1)!

[The article was written in 1987, but is cited in Peter Norvig's (head of research at Google) piece "Teach Yourself Programming in Ten Years" which is also worth a read.]

We understand that it’s a lot of money if you’re freelance

Shaves as close as a blade or your money back.

We’re self-employed too! We can see that although, on paper, it’s good value for 4 days of small-group learning (even before you consider the fact that it includes accommodation and some food), £1300 still feels like a big chunk of money. So here’s a deal: if you don’t feel that the conference has paid for itself within the six months after it, I’ll give you 2 days of my time, free, as a refund, working remotely on any AS3 project you choose.

The challenge is akin to playing a game – and many of the rules of good game design apply just as well to your code base as the product of your compiled application.

A golden rule: ‘Guess what I’m thinking’ is not a fun game

But it is! I can hear some of you shouting. What about 20 Questions! What about ISpy! Yes, ok, they can be fun, given certain conditions: ISpy requires a small enough possibility space. It’s more fun in a car than a supermarket. 20 Questions (a beautiful binary search of the whole universe!) relies upon having an agent that can accurately tell you which pile of hay your needle resides in.

Without those constraints, ‘Guess what I’m thinking’ is just frustrating.

Let’s try it:

Guess what I’m thinking of right now. I’ll give you a clue, it’s an actual concrete thing.

No, it’s not that.

No, it’s not that either.

A comparison search of the whole probability space of ‘things’ is going to take a pretty long time.

This is, in itself, the main reason why I have never shifted myself over the pain barrier to learn Flex. There are just too many moments in which I find myself being asked to guess what Adobe were thinking, without the mechanism to make that game much fun at all.

Instead I’ve chosen to play other games: learning ruby, python, particular domains of problem solving and so on. Games in which I regularly get to intuit an answer that I’ve never been explicitly told in order to solve the puzzle in front of me.

Intuiting new solutions is fun (and the opposite of guessing)

Game designers work hard on providing the minimum amount of information, just-in-time, for the player to progress in a game.

If you take something as simple as a Facebook ‘blitz’ time-waster game, there are often layers of complexity which are invisible to the novice player, yet the player who is unaware of the hidden complexities isn’t penalised for their incomplete understanding.

As the player builds their experience, they eventually get sufficient exposure to the game’s patterns that usually they can intuit the additional layers without being spoon fed them. We may build in ‘hints and tips’, but for the majority of players these are timed so that they confirm what the player had already intuited for themselves.

If we’re simply handed an answer that makes sense, or it is presented in a way that reveals a hole in our thinking, it can sometimes be satisfying, but usually the chemical impact of ‘given’ information is minimal. So we don’t retain it. So we end up having to look it up all over again next time. We also only understand it as a specific solution to a specific problem, making it more difficult to teach someone else, who might have questions that expose the shallowness of our understanding.

Robotlegs makes your codebase into a great game

I experimented with Robotlegs and found that it brought fun to my codebase, and many other developers make the same claim. Of course it’s not perfect, but once I’d grasped a few key principles it felt as if I could intuit new solutions, and they often turned out to be correct.

Robotlegs felt like the original Tombraider games. I got a kick out of solving new puzzles for myself. I quickly felt confident taking on ‘boss’ problems, and it didn’t feel like I was just mashing buttons until I happened upon the right combination.

Other frameworks and utilities have often felt more like the early Harry Potter games – you do a lot of wandering around and from time to time you have to resort to a cheat site to get any further because the solution to the puzzle is so unintuitive. Not fun.

If our codebase is a game, how else can we maximise the fun?

There are two major pieces of work on the question “What *is* fun?” that I’m aware of – Pierre Garneau’s 14 Forms of Fun, and Marc Le Blanc’s 8 Kinds of Fun.

I prefer Marc Le Blanc’s model, partly just because the list feels more applicable to a wide range of problems. I’ve worked with consultants on applying this list to job design – profiling people’s ‘fun preferences’ against roles, and it maps well to teaching and writing as well.

The 8 Kinds of Fun

• Sensation – Game as sense-pleasure
• Fantasy – Game as make-believe
• Narrative – Game as unfolding story
• Challenge – Game as obstacle course
• Fellowship – Game as social framework
• Discovery – Game as uncharted territory
• Expression – Game as soap box
• Submission – Game as mindless pastime

If we substitute the word Code for the word Game, I see that Code as mindless pastime is a little tangential – though I don’t doubt that there are times when we want to bury ourselves in code so as to escape the world around us. I think the Fantasy and Discovery elements largely collapse into one concept for coders – exploring new territory / possibilities, often without a specific goal in mind.

My 7 Kinds of Code Fun

• Sensation – Code as sense-pleasure
• Discovery – Code as experimentation
• Narrative – Code as unfolding story
• Challenge – Code as obstacle course
• Fellowship – Code as collaboration
• Expression – Code as soap box
• Submission – Code as distraction from the world

Sensation – Code as sense-pleasure

Aesthetically, nicely laid out, clean code can be beautiful. It’s worth knowing that in brain-chemistry terms, “Truth” and “Beauty” are largely the same. The most attractive solutions combine both, something that mathematicians have always known intuitively.

Discovery – Code as experimentation

Whether your terrain of choice is generative art, byte weaving or just the kind of ‘what if?’ that lead Robert Penner to come up with AS3 Signals, there is something immensely satisfying about experimenting.

One of the reasons I advocate TDD is that a really comprehensive test suite allows coders (including you) to ‘play’ in your production codebase safely.

Narrative – Code as unfolding story

The reason I trained as an engineer and not a pure scientist or mathematician is that I get a kick out of making *things* that enter the world as physical or virtual objects, and change people’s lives in small ways.

I don’t think it’s a coincidence that at try { harder } the group featured people who’d had prior careers as choreographers and in theatre. Many developers are in love with the process of bringing a story to life.

Agile processes with great test coverage allow us to add new ‘episodes’ to the narrative of our product regularly.

Challenge – Code as obstacle course

This is the area programmers are most likely to be drawn to and aware of. Fixing bugs and delivering features feeds our ego and our families, and also keeps us from eating, sleeping and spending time with the people we love!

We want any obstacles designed in to our codebase to be the kind that can be overcome using the tools and patterns that novice users of the code can quickly pick up. And we want to avoid priming the player (developer) with red-herring solutions.

Fellowship – Code as collaboration

We can ‘collaborate’ with other programmers in real time using pair or group programming, or in near-real-time, passing iterations back and forth between us. Probably just as frequently, we wind up ‘co-creating’ work without ever having an interaction with the coder who comes before or after us.

Sometimes picking up someone else’s code is just a joy, and other times it’s a nightmare. My belief is that avoiding “Guess what I’m thinking” games in our codebase is the primary difference between the two. And no, comments, and even documentation, don’t get around this, because if there isn’t a coherent pattern that the game player can use to intuit novel solutions then it’s still no fun to have to reference the “cheats” constantly in order to make progress.

Expression – Code as soap box

Our code expresses what we believe about code. Have you ever met a developer who wasn’t passionate about their particular coding style?

Submission – Code as distraction from the world

Euro crisis? Shh… I’ve nearly got this code figured out…

I only stayed a day and a half – partly logistics and partly that, being autistic, I find these situations very demanding and I wasn’t sure how much I could absorb before my brain started playing up. I think I found just the right balance for a first-time, but would definitely stay for the whole conference in future.

My only regret is that I was too shy to interact with many of the other speakers. Conrad Winchester is a god send! And Seb Lee-Delisle is a really, really, really sweet person who I instantly felt relaxed with. But I should have pushed myself to talk more with some folk – though partly I was just valuing the interactions I was having with smart people around Robotlegs and so on.

I had the opportunity to talk with Jon Howard, who had the session that clashed with mine, at the speakers dinner. If I wasn’t already doing exciting things I’d have been hitting him up for a job for sure – I’d love to work on his team!

It’s an incredibly well organised conference. I was a little nervous about logistics as nobody had officially said to me “Your session will be in the pavilion, you need to get there x minutes beforehand” – but the number of people who’ve got knowledge of how it all works from previous experience means that my peers were able to gently steer me in the right direction and it was all very smooth and felt like a very collegiate way to do logistics.

Respect to John, and all those who worked hard to deliver Flash on the Beach. A new name is in the pipeline but I won’t hesitate to go back, whatever they call it, as a speaker or as an attendee. It’d be great to see more techy women there in future, but the blissfully empty women’s toilets were a pleasant novelty!

Here’s my take on the sessions I got to attend…

DEVELOPER CONSOLE FOR FUN AND PROFIT - ANDREAS RØNNING

This was a really interesting presentation thwarted only by the fact that it needed to be at least twice as long – every feature Andreas Demonstrated just filled me with questions.

To be honest I had a slightly negative bias against the console as a debugger before Andreas began – I’d seen how technically impressive it was in the video of his 2010 Elevator Pitch, but I’m an ardent TDDer and only fire up the debugger a handful of times each year, preferring to write assertions to explore odd behaviours. As it turns out, the console is much more than just a debugger.

In essence, the Doomsday Console gives you a ton of levers for tweaking your application at runtime. This is the bit that feels exciting!

I totally agree with Andreas’s assertion that text is the best format for this (usually), and the power to do anything from shifting object positions to spawning new processes and objects opens up great possibilities.

I was eager to see examples of actual, non-visual bugs that the Doomsday Console gives you the power to squish, although dozens pop in to my mind already, but this would have taken a second session – so I’ll watch the project for examples over the coming months.

That said, Andreas’s presentation was running in flash, and a problem with the screen setup led him to use the console to hack the position of his content nearer into the middle of his screen. I once did a 3-screen projected animation for the ‘Gothic Nightmares’ exhibition at the Tate gallery, and the capacity to do these tweaks without having to recompile between changes would have made the very painful alignment process a breeze.

I expect that most attendees are, like me, still having regular ‘oh, and I could do *that*!’ moments fairly frequently.

Andreas is also a very lovely guy who generously lent me his Mac->VGA adapter for my session. Phew!

FLASH 11: GET READY FOR GAMETIME – ROB BATEMAN

NATURAL FEATURES TRACKING AND IMAGE PATTERN DETECTION / RECOGNITION – EUGENE ZATEPYAKIN

Sadly I didn’t manage to get in to either of these sessions – both of which had to turn away huge crowds. On the plus side, I got to have some interesting conversations with various folk about very geeky things. There were various ‘not good enough’ murmurings, but it’s hard to know how John could better organise it – and as a speaker I did appreciate that people weren’t coming in after my session started.

SCALING & ORGANISATION: MASSIVE FLASH-PROJECTS – HOW TO BUILD A TOP 10 GAME ON FACEBOOK? – WOOGA

I *loved* this session. I just absolutely *loved* it.

Wooga are pushing out great Facebook games and expanding at the rate of adding a couple of team members each week. How do they do it? Well, basically they run it like an open source project (though they didn’t describe it using those actual words).

There are no project managers – everybody is a maker and the team collaborate to make collective decisions.

They use a broadly Agile process – frequent releases, short meetings, constantly moving goals reflecting what they learn from the process and product feedback after each release. They’re using the Agile manifesto – the spirit of Agile, not a rigid set of instructions.

There are no ‘rules’ about project processes – except that they are using TDD, version control (even for artists), and continuous integration to keep the gremlins away.

I won’t lie, for me the best thing was that it called BS on the idea that game development is somehow special and different and that practices such as TDD, mocking, CI and so on don’t apply to games.

I grew up around jazz musicians and still do work with NYJO, the National Youth Jazz Orchestra where crazy talented people get their first taste of life as a professional musician. They get to improvise and shine and do all kinds of mind-blowing stuff, and they also spend a ton of time practicing scales and arpeggios. Good practices set you free – they don’t constrain (unless you’re doing them wrong).

I heard a few discontented murmurings – people felt they had been misled about the session content. But the title says it all. The audience might have hoped it would be about something cool and awesome and magical that they’d never seen before, a silver bullet or rainbow-crapping-unicorns. But it’s not. It’s about mocking your service layer, giving your teams respect and autonomy but also responsibility to follow practices that avoid software-lock, and not cutting corners.

Wooga – I love you.

THE TALE OF A TRAVELLING SALESMAN AND HIS FOUR COLOURS. – JOA EBERT

You may or may not already know this, but I used to be one of those people on TV. As a result I have shared space, done interviews and generally hung about with a lot of properly famous people. I generally don’t get star struck.

I am star struck by Joa. I was even standing next to him while I was talking to John (FOTB organiser), and I was too shy to thank him for his work on Signals, or even say hello.

Anyway – Joa is part math genius and part comedian. “Every morning the same disaster, how should I put on my clothes?” – followed up with one of the most brilliantly clear illustrations of a practical application of graph theory.

His session was just pure joy for me – no doubt partly because he feels joy himself when he implements beautiful solutions. It reminded me of the recent neuroscience data that has shown that ‘truth’ and ‘beauty’ feel very similar to our brains.

I came away wanting to graph the world. And specifically it gave me insight into a couple of Robotlegs 2 problems we’re tackling, and how these might translate into a graph problem that has probably had papers written about it in other fields.

I’m a math geek so in terms of pure mathematical theory there was little I hadn’t met before, but there was something in the way Joa conceptualised and illustrated it that felt very fresh.

Here’s to whatever FOTB reappears as in 2012.

I was lucky to get it out of the way early – and to have plenty of friendly faces in the audience.

It’s somewhat difficult to recreate the session purely as a set of slides, as the interaction (which the attendees were very generous about) was key to the experience, but I’ve produced an extended version of my slide deck which includes the main points that I covered verbally and the instructions for the exercises. Do give them a go.

If you’re brand new to Robotlegs then the slides won’t sufficiently explain the architecture – you’ll need to pick up a copy of our ActionScript Developer’s Guide to Robotlegs for that!

I’m also pondering doing a VO / screencast version, but it would run at over an hour and I’m not sure you’ll want to sit through it.

So – for now, here’s the Slide Share embed, and don’t forget to pick up your “man brain” file from this post.

man brain

I was totally blown away by Flash on the Beach. What a lot of smart, interesting people!

My full slides will follow tomorrow. I’m going to release a flick-through version that includes extra text, and a screen-cast version with voice. Thanks to everybody who made my first FOTB experience so rewarding – I’m very glad that I got out of my comfort zone and did it.

For now – a little something for the lovely people who attended my presentation on “Robotlegs 2 and your brain” – that vital missing ‘man brain’ entry file.

Tested on Mac OS X but it should work for Linux too.

Download brain.1.gz: brain.1.gz

Don’t unzip it.

Then open your terminal and type:

manpath

It’ll return something like

/usr/local/share/man:/usr/share/man:/usr/local/git/share/man:/usr/X11/man

Pick one of those paths (I use /usr/local/share/man), and check there is a man1 subdirectory.

Then type:

cp /path/to/download/brain.1.gz /usr/path/you/chose/man1/brain.1.gz
man brain

Ahhh…

(If you get a permission denied error, you may need to add ‘sudo’ to the front of the ‘cp /path/…’ line – it depends on the directory you choose to use.)

Robotlegs Pomodoro Timers – even better than a Kinder Surprise Egg!

I’ve been using the Pomodoro Technique for a good few months now.

The pattern I use is:

1. 25 minutes uninterrupted task-focussed activity (no IM, no twitter, no email, no internet) – this is called a Pomodoro
2. 5 minute break for checking emails
3. rinse and repeat

I love it. And here’s why:

Focus, without neglecting your responsibilities to other people

The intention behind the technique is primarily to improve time management by reducing distractions. I have maintenance contracts with some of my clients, and knowing that they’re unlikely to wait more than 25 minutes for a response allows me to turn my email off while I get on with coding or writing.

Tweet, read the news or hang out on facebook guilt free

During my breaks, any activity except for my task is valid. No more self-loathing. Sometimes I answer a quick question on the Robotlegs forum, sometimes I deal with emails, sometimes I just read the news – knowing that I’m gaining, not losing, from switching my foreground attention to something else, and that when my end-of-break timer goes off I’ll be back on the main task.

Movement is good

My back and my bladder are both appreciating the fact that I don’t spend six hours sitting in one position without moving. I try to leave my desk in every break, even if it’s just for a moment. I’ve got a floor-desk and we share a standing desk in our home-office. I’m trying to make sure that certain kinds of regular task are always carried out at the standing desk.

Less barrier to doing the sucky tasks

My schedule includes a Pomodoro of housework and a Pomodoro of admin every day. I group them together, followed by a Pomodoro of dog walking and then lunch – and I’m feeling great about making sure these happen every single day. I really suck at admin – I tend to end up with huge piles of unopened post, generating an ever increasing barrier to dealing with it. Doing a single Pomodoro of admin is keeping the pile down without feeling like if I start to dig in to it I may never come out. The housework Pomodoro is going down extremely well with my wife!

Better estimation

I’m starting to get a feel for how big a task is in terms of Pomodori. When my client asks for a change I’m able to outline classes, think about how many Pomodori might be required to get each class done, and come up with increasingly accurate estimates.

Micro-sprints improve productivity

I find that setting myself a goal can spur me into sprinting for most of the 25 minutes, getting something done within a Pomodoro that otherwise I might have stretched over a couple of hours. And this is why I think Robotlegs and the Pomodoro Technique are so well suited.

Robotlegs and the Pomodoro Technique: a perfect match

One of the things I love about Robotlegs is that it really encourages you to create many small classes, and yet this seems to be one of the aspects that causes a sad-panda face in many programmers. I’m going to talk more about the neuroscience behind this in my Flash on the Beach session, but in a nutshell I believe the antipathy towards many-small-classes flows out of three issues:

• Naming classes is harder than naming functions
• Developers tend to think in terms of half-day coding problems
• Refactoring relies on comprehensive tests, which most AS3 code bases don’t have

Shifting from thinking in terms of 4 or 6 hour coding sessions has made a surprisingly positive difference to how I program. I group my coding Pomodori together into 2-hour blocks, because I do think they’re more useful that way than scattered between admin and writing tasks, but the combination of Robotlegs, TDD and the Pomodoro Technique allows me to get meaningful coding-work done even in a single 25 minute session.

The many-small-classes approach suits the Pomodoro Technique

Micro-sprints require your brain to accept the possibility that your goal can be reached within the 25 minutes. The many-small-classes approach, which Robotlegs encourages, provides multiple opportunities for meaningful goals that can be attacked within a Pomodoro. Sometimes you can really push it and pick up two or three whole classes, with tests, within a Pomodoro.

If your class was written (nicely) in a Pomodoro, then it’s likely that the future-coder (maybe you in six months time) can grok it quickly too. It *must* have few responsibilities. Of course, not all classes can be written in a Pomodoro, just like not all classes can be kept below 60 lines, but if you have it on your radar, your chances of leveraging the simplicity where functionality can be broken down cleanly are much higher.

A refactoring Pomodoro is a great brain-drain

A few times a week I’ll notice that I’m still slightly fuzzy about the functionality I’m about to tackle, so instead I’ll devote a Pomodoro purely to refactoring code around it. Robotlegs supports refactoring by encouraging flexible, testable code. (If you don’t have test coverage you’re not refactoring – you’re just moving shit around).

So – come on, how do I win a Robotlegs Pomodoro Timer?

Mmm… engraving

I had 50 custom Robotlegs Pomodoro timers made – they’re nice, twist-to-set, old-skool timers, with the Robotlegs logo engraved in to the metal.

If you’re one of the Robotlegs core team, or one of the people who reviewed our Robotlegs book, there’s already a timer set aside for you. I’ve also set them aside for Ondina, Camille Reynders, Paul Robertson, krasimir and Michał W who’ve been giving a lot of time to the forum these past few months. We want to hold some back for people who contribute to Robotlegs 2. The only other way to get your hands on one of these babies is to come to my Flash on the Beach session – Monday at 12pm.

The session will require you to engage your brain (and a pencil and paper) to tackle various exercises – and some of these exercises will give you the opportunity to win a Robotlegs Pomodoro Timer for your own desk. Bribery? For sure!

ps. This blog post, including photos, took exactly 3 Pomodoros.

The Robotlegs Book pages from afar

You can pre-order the print version here, and the e-book should be released very soon – they’re estimating August 9th but I’m hoping it’ll be sooner as we tamed the DocBook beast ourselves and pushed it to production in great shape. There will be a print + ebook deal from O’Reilly shortly.

I just received a message from Yennick Trevels via Twitter, and he asks an important question about the book:

So, what kind of book *is* this Robotlegs book? Well, it’s not a cookbook, it’s not an API reference, and it’s not really about the basics of Robotlegs either (though it’s ideal for getting started with Robotlegs).

This book is about architectural decision making in your projects, as expressed through Robotlegs. It has a lot of code samples, plenty of diagrams, thorough coverage of the core Robotlegs API and also deep discussion of why you would take a specific approach, and what the advantages and risks of other approaches might be.

The chapter list

I will post the whole Table of Contents as soon as we’re through production. This is a list of the chapters in the book:

1. Robotlegs is a lightweight framework for ActionScript
2. The Robotlegs dream
3. Anatomy of a Robotlegs application
4. Automated Dependency Injection
5. The Robotlegs context in action
6. The CommandMap in action
7. Models and Services – how are they different?
8. Connecting views with Mediators
9. Working with Robotlegs: Rich Examples
10. Testing your Robotlegs application
11. Power-ups
12. Appendix A: Troubleshooting tips
13. Appendix B: Swiftsuspenders – the power behind the Robotlegs injector

O’Reilly were keen to keep the book to 120 pages – part of a new strategy they’re following to bring smaller, more focussed books on niche subjects. This led us to make two important decisions:

• we built two real applications (not HelloTwitter, proper, interesting apps), one Flex app and one AS3 app, and used these for many of the code samples as well as providing a complete downloadable source, with tests, for each app
• coverage of extended topics, for example modular Robotlegs, is limited to a brief overview, so that we could explore the core in greater depth

However, don’t read the lack of coverage of non-core features to mean that this is only a book for beginner Robotlegs users; we set out to produce something that would also be of value to experienced Robotlegs users. At times I wondered if we’d set ourselves an unrealistic goal – can you really write a getting-started guide that is also a challenge to experienced developers? When we received the feedback from our tech reviewers I – literally – jumped up and down with excitement to see that we’d managed it.

Our nine tech reviewers covered the full spectrum of experience with Robotlegs. Some are working on their first Robotlegs project, others are Robotlegs utility builders with intimate knowledge of the Robotlegs API. Nobody felt that the book wasn’t for them (and no, not all of them were our friends!)

While I know it’s much more fashionable to be modest and somewhat cool when people say you’ve done something great, I feel like the trumpet blowing you’re about to read is justified.

Firstly, there could be no great book about Robotlegs if Robotlegs wasn’t, in itself, brilliant. Of the core Robotlegs team members, I’m the most able to voice this without feeling awkward. Robotlegs was pretty much complete before I got involved. I chose Robotlegs because it was already awesome. I take no credit for that awesomeness – all I’ve done is help other people to find it too.

So, while I hope you’ll appreciate the work that Joel and I have put in to communicating it, the real star of this book is the framework, not the authors.

Secondly, I feel like I owe O’Reilly extra credit for this book because of the superb training they gave me at Head First boot camp a few years back. Although this book isn’t a Head First book, it was written with everything I’ve learned as a Head First author in mind.

Thirdly, you’re allowed to shout about things when you’re part of a team, right? Between Joel, myself and our reviewers, this book is a real collaboration.

What our reviewers said about the book

Our tech reviewers added a great deal to the clarity of the book with their input, but what I really want to share with you is a handful of the lovely things they said when submitting their feedback. (So – here’s the part where I show off, look away now if that’s not OK with you)

Neil Manuell:
The definitive Robotlegs introduction. Every dev team should have a copy both as a reminder of good practice and a primer to any new member

Douglas Reynolds:
I’ve already used the pre-release copy twice as reference this week… something that is an indicator to me of a book that continues to be useful after 1st read… those are my favorite books.

Sean Moore:
A TON of really great info. I’m learning so much it’s insane. This book is going to help a lot of people very, very much. It’s answering a lot of questions I’ve had and also helping to remedy a lot of stuff I’m doing wrong.

Mike Cann:
Just taking one glance at the table of contents leaves me itching to dive into each chapter.

Complex yet simple, in depth yet concise, challenging yet fun. And that’s just the table of contents.

The long awaited book on RobotLegs and it does not disappoint.

James Wagstaff:
You appear to have written this book just for me, or at least exactly at my technical level (mid-weight developer, in too deep to not have an MVC framework)

Dependency chain problems. Been banging my head against that one for a while. It’s really good you put as much into explaining the problem as the solution.

[This book] read like some of the best tech books I’ve read. Plain English, well explained and a good grasp of what it’s like to meet Robotlegs for the first time.

Angela Relle:
I enjoyed the writing style, I like the feeling that the book has been written collaboratively. Having read the book, I think I have a deeper understanding of the principles I’ve been picking up from your tweets and in the RL forum and I have a whole list of things I will be either improving in my current project or doing in my next one

Really like that you have a “Power Ups” and a testing section (I’ve got tests in place for my commands, but not so much for mediators, so this will come in handy).

Simon Bailey:

As I skimmed the Test chapter I was hoping you would offer examples for all MVCS, [and we did] brilliant!

Weyert de Boer:
Every Frog robot needs quality legs to do its job. The Robotlegs book is the best way to learn the Robotlegs walk.

David Hunter:
Good luck with the book, I have really enjoyed reading it, should be
perfect for newbies *and* more experienced Robotlegs developers.

This book is about Robotlegs 1.x

For those of you who already have half-an-eye on Robotlegs 2, here’s the crucial info: while some parts of the API may be different in RL2, almost all of the content of this book will still be directly relevant. If O’Reilly commission a Robotlegs 2 book it will have to be a longer book to cover the extra features, but we’ll make sure that owners of the Robotlegs 1 book have a mechanism for getting a discount.

Sensible information about the plans for Robotlegs 2 will emerge as soon as we’ve had a chance to consult with Joel. Until then, I can only say that right now I feel like the luckiest AS3 dev on the planet, and here are 20 things I have learned:

This has pros and cons.

The cons are the obvious ones: some habits are not so good to have. I have had most of them!

The pro is that making good habits is useful.

In programming, habits are my default behaviours – my normal-for-me practices. We all have them – and, just like lifestyle habits, there are good ones and not-so-good ones. Ones we adopt mindfully and ones we just kinda slipped into. And we don’t really like it when people point out our bitten nails.

Stray: you’re doing it wrong!

I can admit that there’s a part of me that feels pretty satisfied with my TDD practice. I get great coverage, I do end-to-end and integration tests as well as unit tests. I write very little production code that isn’t absolutely required. I refactor with confidence. And, importantly, my test code doesn’t look like I used my 5-years-ago self to write it… and yet last week I had one of my core testing habits challenged: Joel Hooks and Sean the Flex Guy cited the (new to me) concept of “one assert per test”.

@stray_and_ruby I think they are just lazy way to avoid creating multiple tests to proof effect of a behavior. Not the good lazy
jhooks

Lazy? Wow, I’ve not recently thought of myself as a (bad) lazy coder. Hrm…

Now, Joel and Sean are both smart people with plenty of experience, so my starting position is to be curious about what they mean by ‘One assert per test’. I know that I don’t stick to this – and it didn’t make immediate sense to me. I jumped on github to check the test-suite for Robotlegs, found that there were many situations where there was more than one assert per test, so I asked Joel and Sean a few questions – just checking out what ‘one assert per test’ really means.

On closer examination, some of the Robotlegs tests – for example in the MediatorMap – have redundant code, because they assert that a value isn’t null (for example) prior to asserting that it equals X. The ‘assertEquals’ will always cause an error anyway, and I know I do this in my own code simply because I prefer a fail message to an error message.

In the discussion on twitter, some people voiced the concern that this ‘rule’ was overkill. And I agree that if it was to be applied rigidly then it probably would be, but that’s not how these ‘rules’ about good practice are intended to be applied. We are not circuit boards – we’re human beings.  Rules such as ‘one assert per test’ are useful when adopted as the default behaviours that we drop into when we don’t mindfully choose to break them.

Refactoring your default methods and parameters

In my mind, refactoring our default behaviours is the key to levelling up – whether we’re trying to change our body weight or improve our code. The important thing is not to make changes to how you behave when you’re trying your hardest, but to tweak the habitual processes that we fall in to when we’re not paying attention – because this is how we spend nearly all of our time.

The problem is that we human beings have evolved to be capable of change but reluctant to do so. We’re not abstract creatures, we live in a concrete world, and the ultimate problem we’re engaged in – staying alive – is a concrete problem. As a result, most of our decision making faculties rely on ways of interpreting the world where previous concrete experience is valued highly. Or – as neuroscientists summarise it:

What fires together wires together.

This brings us to paradox: it makes survival sense to value previous concrete experiences over theoretical abstract experiences, and yet we can never improve our situation, and create new habits, without experimenting with abstract ideas in the concrete world.

Nature seems to have a few strategies for dealing with this – first of all, we’re not all equally averse to experimenting. Somebody somewhere was prepared to be the first person to eat a mushroom. (I suspect we actually subjugated people and used them as guinea pigs for most of this process, but anyway…). Secondly, we have an awesome feat of biology called ‘Mirror neurons’. These mirror neurons allow me to watch you doing something and have the same neural pathways activate in my brain as if I was doing that activity myself.

The third tool in our arsenal is the ability to reflect on our own processes. Human beings are prone to many different flavours of bias, but we also possess the ability to understand what bias is and begin to recognise it in our own decision making. If we can identify a specific bias – for example that we only have concrete experiences of A and abstract understanding of B – we can choose to take steps to dilute the bias (by getting some concrete experiences of B too).

Swallow with a glass of water vs Suck it and see

The extent to which we can evaluate an abstract solution is – again, with survival sense – correlated with how much pain the problem it addresses is causing us, and how much awareness we have of the link between the pain and the problem. Analgesic solutions are an easy sell – you just have to wait for the pain to motivate the patient.

A pattern such as using mocks and support objects to avoid ever having to do new Thing() in a test case (other than testing Thing) sounds a bit high level until you need to add one parameter to a much-used config VO in your code base and find that you need to edit 37 test cases. Pass me that glass of water, I’m gonna take 1000mg of mockolate!

But ‘stopping the pain’ can only take you so far – there are options and alternatives that can bring joy to your code, not just analgesia, and these are the ones that our safety-first survival brain will attempt to subvert. After all – nothing hurts right now, why risk changing the process?

From an abstract perspective you will never choose to make these changes – you have to shift into the concrete, give them a go (a proper go) and see whether it turns out to *feel* better than the old way.

So, all weekend I programmed using one-assert-per-test, and it was a surprisingly long lever to pull on. I’d figured it wouldn’t really make much difference in the coding process, only to the reader, but actually it was not just ‘not bad’, it was actually enjoyable. It seemed to create a nicer rhythm in switching between the test and the code, with faster red/green cycles.

After just 2 days, one-assert-per-test is my new default behaviour. There will be times when I mindfully break that rule, but the win is that when I’m not paying attention my process will be a little better than it was last week.

It might seem like a tiny thing, it’s certainly not in the pareto 20% that solves 80% of my problems (I don’t feel that I have many problems). But it doesn’t cost me anything, and these little tweaks are the details that save me a couple of headaches a year, or allow me to write a couple more quick replies to questions on the robotlegs forums without missing a deadline. It all matters.

Your brain is part of your tool chain

The human brain is amazing. And largely mysterious, at least in terms of how it works. But we have increasing volumes of detailed observation of what our brain does and doesn’t do, what it does well and what it does badly. We also know that while there are some changes in how it behaves in different contexts, it’s more influenced by hormonal and chemical changes – doing *anything* under stress is different from doing *anything* while relaxed, and so on.

So – it seems sensible to me to pay attention to how my brain works most of the time and assume that the same general rules hold true when I’m ‘being a coder’.

For example, my brain is great at holding on to information until it’s no longer needed. Addresses, phone numbers, flight numbers and departure times – pop them in short-term memory; drop them as soon as they’re dealt with.

My brain is also pretty good, though less reliable, at reminding me of something important regularly enough that I am prompted to deal with it eventually, until it’s no longer important. For example, if we’ve run out of peanut butter then my brain will regularly throw “buy peanut butter!” into my conscious thoughts – not always at a useful moment – until the peanut butter has been bought. And once it has been bought, I may go several weeks without ever thinking about buying peanut butter.

And this is why I obsessively develop using test-first.

If you *are* using test-after, you’re fighting your brain’s natural garbage collection process. Personally I don’t have the cognitive energy surplus to do that – either I’d miss a chunk of the information or I’d be exhausted.

It seems to me that my brain has evolved to be more suitable for test-first development, which I consider to be a process for:

1. maintaining constant mindful engagement with the purpose of the code about to be written
2. capturing the details of the complexity around that purpose as they emerge rather than retrospectively
3. using automation to ensure that we never unknowingly regress, and new code only moves us forward

I don’t go to the supermarket and then come home and write a retrospective list of what I should have bought. Do you?

Yup – but this is different kind of conference, a collaborative conference.

To skip my ramblings about why we’re setting it up the way we are, just jump straight to the try { harder } site:

Why do we need try { harder } ?

The insightful @davidarno pointed out last week that there was a lack of training/events around advanced, non-visual development.

@stray_and_ruby I’m thinking TDD, Git, Ant, ASDoc, Flex skinning, mocking, AVM, mobile flex, FP11 experiments etc. Real flash geek stuff! And no generative art whatsoever

Of course the first thing I did was tease him that it’s not possible to desperately need a solution to such a high-level problem – but I also believe he is right.

Code generated art has its place; Flash Math Creativity, and Mr Penner’s tweening equations, were a critical part of my falling-in-love-with-flash phase… but these days it’s deployment automation and test patterns (and of course Mr Penner’s as3 signals) that get me really excited.

So – where do we start?

A geeky flash-dev conference, that covers the less sexy looking side of things. Now, there’s a clue in that, isn’t there?

I suspect a big-room presentation on, for example, branching strategies in git, is going to have its limits. For starters, there’s not a lot to see. And there aren’t a lot of stories to tell.

This is a tough gig to deliver for the speaker, because the main purpose visuals and narrative in a presentation is to take the audience on a ride together, with the speaker leading them. A compelling story around git branching strategies is a hard thing to find. And so the audience aren’t captured by *your* (weak) story. They’re already thinking about how they could use this in their own work – which in many ways is a win – but in the context of a formal presentation, you’ve lost them and pretty soon you’re going to be staring out into tumbleweed.

So – we should have some sympathy for the selections made by big conferences, and the content the speakers choose to deliver. They do it for a reason, and that’s why an advanced development conference for our community needs to be totally different.

Fortunately the quality of that difference also addresses the aspect of conference presentations that I find hardest (as a speaker) to deal with…

The expert-learner paradox

In my experience, teaching beginners is technically significantly more difficult than teaching other experts. And yet psychologically the reverse is true – when the knowledge-gap between myself and someone I’m teaching is obvious, I can feel confident that I’m imparting something useful, even though this is a false confidence because it’s very easy to leave a beginner more confused than they started out. When I’m teaching a group of my peers I spend a lot of time worrying about whether they think I’m a twat for putting the ‘expert’ hat on.

A peculiarity of learning is that there comes a moment after which the more you know the more you know you don’t know. And so there seems to be a fairly early peak in your confidence of your knowledge, after which there is only a greater and greater sense of how little you understand in comparison with the (impossible) state of fully-knowing your subject.

A few people have been kind enough to share their experience of presenting at Flash on the Beach, and they seem to have a similar feeling – it’s uncomfortable to put yourself on the stage when you have people in the room who you know are at least as expert as you are (even when those people are genuinely supportive of you in that situation).

Peer-to-peer networks beat broadcasting

Recently I’ve helped out a couple of people with Robotlegs, project sprouts and some integration/end-to-end testing. And in return I’ve received some fantastic help from them around my own questions and weaker spots.

I’ve also learned an enormous amount from answering questions on the Robotlegs tender forum. Sometimes you don’t really know what you think until you’re asked to form an answer to a question.

I suspect this is the real reason why so many of us in the tech community put time into blog posts and screencasts. We might claim that it’s because it’s good for our career (and it is), good for building contacts and so on – but many of us are essentially introvert, so I’d speculate that the real thrill is in exploring our own thoughts, and consolidating our own learning.

Still, there is, for me, a greater thrill in learning-together. For someone with autism I do a passable impression of a sociable person, but the truth is that while I have a strong moral framework that means I genuinely care about most human beings, what really interests me about you is how your mind works and how your mind can help my mind to understand and build something greater than I can on my own.

If we were musicians, I’d want to jam with you

We can talk about code – that’s great. But really I want to write code with you. I want to set up the programming equivalent of a 12-bar-blues and then see where we go. Which is why I’ve loved the idea of the code retreat format since I first heard about it (from Joel Hooks).

And so I started to play with the idea of combining all of these things – peer-to-peer learning in a group small enough to have conversations as well as presentation. A set up where everybody teaches as well as everybody learning, where there’s less (artificial) hierarchy to feel weird about. The opportunity to ‘jam’ with other programmers as well as taking master-classes. Plenty of space in-between to digest and regenerate, and – crucial for me – the chance to somehow include my wife because not only does she keep me sane but she’d probably prefer to have my enthusiastic ramblings drip fed through a few days than have the whole lot drop on her when I return!

So, are we doing this or what?

I shoved up a twitter survey that many of you were kind enough to respond to, and responses were positive and we generated a really diverse list of content that could be presented. People were enthusiastic, flexible and split clean down the middle on questions like “weekend or mid-week?” and which locations would work. Two thirds of people wanted to bring their partner or family, which also influenced the choice of venue: Center Parcs.

And so, I should confess, my decision to create another flash-platform conference is almost entirely selfish, but also shaped by your feedback and by input from the lovely Neil Manuell who is going to be my co-facilitator / organiser.

And we bring you:  try { harder } beta-conf