You can build it in a week*
James Aylett
/dev/fort
* even if you get caught in a blizzard
/dev/fort is a tried & tested way of kidnapping a dozen people and
stranding them in an isolated spot where they are at risk of starvation,
hypothermia, whiskey and Carly Rae Jepsen parodies.
As a side effect we build websites.
What is /dev/fort?
A dozen people. An isolated location. No internet. No phones. A week to
choose an idea, develop it, design it & build it.
What is /dev/fort?
Some things we’ve built
WLNY (bit bucket). Mostly Final. Spacelog. History Mesh. BeHabitual.
Technology at about 8.5
I want to talk about one of the reasons I do /dev/fort. Because it’s a
holiday where you do your day job: it’s a bit weird. But in your day job
you’re balancing constraints of the real world against what you know
professionally.
We compromise; it’s rare that we get to turn technology up to 11. Or
even 10.
Before the first fort I’d pretty much given up programming. I didn’t have
any interest in it. I’d also had too many conversations that included
phrases like…
Technology at about 8.5
“We don’t have time”
Technology at about 8.5
“Something something velocity”
Technology at about 8.5
“I don’t care about accessibility”
Technology at about 8.5
“I don’t care about accessibility”
“I don’t care about testing”
Technology at about 8.5
“I don’t care about accessibility”
“I don’t care about testing”
“I don’t care about security”
Technology at about 8.5
“I don’t care about accessibility”
“I don’t care about testing”
“I don’t care about security”
“I don’t care about users”
Technology at about 8.5
“I don’t care about accessibility”
“I don’t care about testing”
“I don’t care about security”
“I don’t care about users”
“We just need to ship this”
If your manager says this, he may mean “our CEO has heard agile means
we move faster”. If your CEO says this, he may mean “our investors have
heard agile means we move faster”.
Technology at 11
But in a fort we get to set our own constraints. We don’t have managers.
CEOs and investors can’t find us. Nor, as a point of fact, can Sainsbury’s
home delivery. Although we did get a book from Amazon once. This is
getting off point.
Technology at 11
Doing the Right Thing
We choose not to compromise on quality. We call it “doing the right
thing”.
And I came back from the first fort excited about building things for the
web again. Other people have as well.
Technology at 11
Doing the Right Thing
Test your code
Technology at 11
Doing the Right Thing
Information security
Technology at 11
Doing the Right Thing
Monitor usage
Technology at 11
Doing the Right Thing
Semantic HTML
Technology at 11
Doing the Right Thing
Maintainable CSS*
* this is a lie; CSS isn’t maintainable
Technology at 11
Doing the Right Thing
Javascript not required
Technology at 11
Doing the Right Thing
And we do this in a week
Since we started /dev/fort I’ve become much more hardline about doing
the right thing when I’m working elsewhere. Sometimes you have to
compromise, but more often than not I’ve been better off sticking to my
guns. I’ve started to feel uncomfortable if anyone suggests otherwise.
People who pay attention to these things have been looking at GDS
recently and saying things like that it’s (quote from Paul) “won [us] the
right to finally say ‘no’ and do less, better, to do it properly and stop
cutting corners”. This is basically the same thing. Maybe, *maybe*, now
we can stop having this argument with managers and so forth…in about
ten years when they’ve heard of GDS.
Internet in a box
Something we get asked a lot is “how do you do this without the
internet?”. And I tend to assume the people asking are intelligent and
mean things like access to documentation rather than Twitter.
So we take the useful bits with us. RFCs, Internet Drafts, w3.org, jQuery
documentation, CPAN, ruby gems, PyPI, npm.
Internet in a box
Package mirrors
CPAN, ruby gems, PyPI, npm…
Internet in a box
Documentation mirrors
RFCs, Internet Drafts, w3.org, jQuery documentation…
Internet in a box
Wikipedia
Wikipedia provide dumps of their content. Turns out that grepping
through giant XML files is a painful way of reading Wikipedia, so we
wrote our own browser.
Internet in a box
Twitter
Oh yeah, and we have twitter as well.
Internet in a box
Bugle
Or rather bugle, “group collaboration tools for hackers in forts”, which
Simon Willison wrote. In a fort. We keep on adding bits to it, so it’s not
particularly like twitter any more. Warning: *only* suitable for use in a
fort due to hideous security holes that don’t really matter when you’re
surrounded by stonking great stone walls.
Internet in a box
github.com/devfort
We try to release anything useful so other people can use it too. Bugle’s
up there, and Steve Marshall is taking the lead in making chef recipes to
build a copy of the useful bits of the internet.
Plus, we put the sites we build up there.
Internet in a box
github.com/spacelog
And there…
Internet in a box
github.com/historymesh
And a lot of places…
What can we learn from this?
There are obvious things like eliminating distractions. Everyone kind of
knows this, but seriously: turn off notifications, don’t let email or IM or
IRC or kittens suck you in. Too many meetings is pretty bad too; you
can’t get away with none at all, but informal talks are usually better.
But there’s other learnings too. Some of them may be more surprising.
What can we learn from this?
Collaborate better
Really quickly, too.
What can we learn from this?
Collaborate better
A group working together
towards a clear goal
It’s surprising how few teams have a clear idea of what they’re trying to
do. It’s surprising how few *companies* have a clear idea. And if they
do, they’re not always great at sharing this with everyone.
What can we learn from this?
Collaborate better
Mentoring works both ways
You don’t really understand something unless you can explain it to
someone else. Also, everyone knows something you don’t. It might be a
trick with vim, a CSS technique you haven’t seen before, or something
really complicated like how to slice an onion. Mentoring provides
benefits in both directions, and isn’t a waste of more experienced folks’
time.
What can we learn from this?
Collaborate better
Try eating together
Some companies have made this a cliché. It’s not about paying for
everyone’s lunch, it’s about socialising. Admittedly at forts we do more
than just eat lunch together; we eat, we cook, we laugh, we drink, we
give impromptu performances of Gangnam Style. You may not want to
go that far.
What can we learn from this?
You can do things properly and
still have velocity
Prioritise what’s important. Make sure things get talked through before
you start building. If someone’s still arguing it means something’s
wrong, although it might not be what they think.
What can we learn from this?
You can do things properly and
still have velocity
Tech doing it right seems to
affect scope less than design
Perhaps because these days there’s *lots* of off-the-shelf support for
what developers care about, but only *almost* what designers care
about. eg: Django ships with a password reset flow that sends a one-use
email token. But it doesn’t log you in after setting the new password,
and doesn’t send HTML email.
What can we learn from this?
Learn to love distributed
git means that you can commit from the battlements.
Scripted deployment (“continuous deployment”) means you can deploy
from anywhere, which means you can fix problems & do your job
anywhere. A pub, a restaurant, the deck of HMS Ocean.
I’d love to say that we’ve released a /dev/fort site from an airport, but
we haven’t. Although we did nearly get one running from a hotel in the
middle of a blizzard.
What can we learn from this?
Don’t get stuck in a blizzard
Seriously, those things are cold.
You may be wondering “how do I come to a fort?”. We run about two a
year, but forts are always popular so I’m talking to potential sponsors so
we can run more. In the meantime, get a recommendation from
someone who’s been.
Additional photos by
Mark Norman Francis
http://flickr.com/photos/mn_francis
Additional photos by
Stephanie Hobson
http://flickr.com/photos/stephaniehobson
Questions?
Questions?
Questions?
james@devfort.com
Questions?
james@devfort.com*
* so call me, maybe?

/dev/fort: you can build it in a week @emw

  • 1.
    You can buildit in a week* James Aylett /dev/fort * even if you get caught in a blizzard /dev/fort is a tried & tested way of kidnapping a dozen people and stranding them in an isolated spot where they are at risk of starvation, hypothermia, whiskey and Carly Rae Jepsen parodies. As a side effect we build websites.
  • 2.
    What is /dev/fort? Adozen people. An isolated location. No internet. No phones. A week to choose an idea, develop it, design it & build it.
  • 3.
    What is /dev/fort? Somethings we’ve built WLNY (bit bucket). Mostly Final. Spacelog. History Mesh. BeHabitual.
  • 4.
    Technology at about8.5 I want to talk about one of the reasons I do /dev/fort. Because it’s a holiday where you do your day job: it’s a bit weird. But in your day job you’re balancing constraints of the real world against what you know professionally. We compromise; it’s rare that we get to turn technology up to 11. Or even 10. Before the first fort I’d pretty much given up programming. I didn’t have any interest in it. I’d also had too many conversations that included phrases like…
  • 5.
    Technology at about8.5 “We don’t have time”
  • 6.
    Technology at about8.5 “Something something velocity”
  • 7.
    Technology at about8.5 “I don’t care about accessibility”
  • 8.
    Technology at about8.5 “I don’t care about accessibility” “I don’t care about testing”
  • 9.
    Technology at about8.5 “I don’t care about accessibility” “I don’t care about testing” “I don’t care about security”
  • 10.
    Technology at about8.5 “I don’t care about accessibility” “I don’t care about testing” “I don’t care about security” “I don’t care about users”
  • 11.
    Technology at about8.5 “I don’t care about accessibility” “I don’t care about testing” “I don’t care about security” “I don’t care about users” “We just need to ship this” If your manager says this, he may mean “our CEO has heard agile means we move faster”. If your CEO says this, he may mean “our investors have heard agile means we move faster”.
  • 12.
    Technology at 11 Butin a fort we get to set our own constraints. We don’t have managers. CEOs and investors can’t find us. Nor, as a point of fact, can Sainsbury’s home delivery. Although we did get a book from Amazon once. This is getting off point.
  • 13.
    Technology at 11 Doingthe Right Thing We choose not to compromise on quality. We call it “doing the right thing”. And I came back from the first fort excited about building things for the web again. Other people have as well.
  • 14.
    Technology at 11 Doingthe Right Thing Test your code
  • 15.
    Technology at 11 Doingthe Right Thing Information security
  • 16.
    Technology at 11 Doingthe Right Thing Monitor usage
  • 17.
    Technology at 11 Doingthe Right Thing Semantic HTML
  • 18.
    Technology at 11 Doingthe Right Thing Maintainable CSS* * this is a lie; CSS isn’t maintainable
  • 19.
    Technology at 11 Doingthe Right Thing Javascript not required
  • 20.
    Technology at 11 Doingthe Right Thing And we do this in a week Since we started /dev/fort I’ve become much more hardline about doing the right thing when I’m working elsewhere. Sometimes you have to compromise, but more often than not I’ve been better off sticking to my guns. I’ve started to feel uncomfortable if anyone suggests otherwise. People who pay attention to these things have been looking at GDS recently and saying things like that it’s (quote from Paul) “won [us] the right to finally say ‘no’ and do less, better, to do it properly and stop cutting corners”. This is basically the same thing. Maybe, *maybe*, now we can stop having this argument with managers and so forth…in about ten years when they’ve heard of GDS.
  • 21.
    Internet in abox Something we get asked a lot is “how do you do this without the internet?”. And I tend to assume the people asking are intelligent and mean things like access to documentation rather than Twitter. So we take the useful bits with us. RFCs, Internet Drafts, w3.org, jQuery documentation, CPAN, ruby gems, PyPI, npm.
  • 22.
    Internet in abox Package mirrors CPAN, ruby gems, PyPI, npm…
  • 23.
    Internet in abox Documentation mirrors RFCs, Internet Drafts, w3.org, jQuery documentation…
  • 24.
    Internet in abox Wikipedia Wikipedia provide dumps of their content. Turns out that grepping through giant XML files is a painful way of reading Wikipedia, so we wrote our own browser.
  • 25.
    Internet in abox Twitter Oh yeah, and we have twitter as well.
  • 26.
    Internet in abox Bugle Or rather bugle, “group collaboration tools for hackers in forts”, which Simon Willison wrote. In a fort. We keep on adding bits to it, so it’s not particularly like twitter any more. Warning: *only* suitable for use in a fort due to hideous security holes that don’t really matter when you’re surrounded by stonking great stone walls.
  • 27.
    Internet in abox github.com/devfort We try to release anything useful so other people can use it too. Bugle’s up there, and Steve Marshall is taking the lead in making chef recipes to build a copy of the useful bits of the internet. Plus, we put the sites we build up there.
  • 28.
    Internet in abox github.com/spacelog And there…
  • 29.
    Internet in abox github.com/historymesh And a lot of places…
  • 30.
    What can welearn from this? There are obvious things like eliminating distractions. Everyone kind of knows this, but seriously: turn off notifications, don’t let email or IM or IRC or kittens suck you in. Too many meetings is pretty bad too; you can’t get away with none at all, but informal talks are usually better. But there’s other learnings too. Some of them may be more surprising.
  • 31.
    What can welearn from this? Collaborate better Really quickly, too.
  • 32.
    What can welearn from this? Collaborate better A group working together towards a clear goal It’s surprising how few teams have a clear idea of what they’re trying to do. It’s surprising how few *companies* have a clear idea. And if they do, they’re not always great at sharing this with everyone.
  • 33.
    What can welearn from this? Collaborate better Mentoring works both ways You don’t really understand something unless you can explain it to someone else. Also, everyone knows something you don’t. It might be a trick with vim, a CSS technique you haven’t seen before, or something really complicated like how to slice an onion. Mentoring provides benefits in both directions, and isn’t a waste of more experienced folks’ time.
  • 34.
    What can welearn from this? Collaborate better Try eating together Some companies have made this a cliché. It’s not about paying for everyone’s lunch, it’s about socialising. Admittedly at forts we do more than just eat lunch together; we eat, we cook, we laugh, we drink, we give impromptu performances of Gangnam Style. You may not want to go that far.
  • 35.
    What can welearn from this? You can do things properly and still have velocity Prioritise what’s important. Make sure things get talked through before you start building. If someone’s still arguing it means something’s wrong, although it might not be what they think.
  • 36.
    What can welearn from this? You can do things properly and still have velocity Tech doing it right seems to affect scope less than design Perhaps because these days there’s *lots* of off-the-shelf support for what developers care about, but only *almost* what designers care about. eg: Django ships with a password reset flow that sends a one-use email token. But it doesn’t log you in after setting the new password, and doesn’t send HTML email.
  • 37.
    What can welearn from this? Learn to love distributed git means that you can commit from the battlements. Scripted deployment (“continuous deployment”) means you can deploy from anywhere, which means you can fix problems & do your job anywhere. A pub, a restaurant, the deck of HMS Ocean. I’d love to say that we’ve released a /dev/fort site from an airport, but we haven’t. Although we did nearly get one running from a hotel in the middle of a blizzard.
  • 38.
    What can welearn from this? Don’t get stuck in a blizzard Seriously, those things are cold. You may be wondering “how do I come to a fort?”. We run about two a year, but forts are always popular so I’m talking to potential sponsors so we can run more. In the meantime, get a recommendation from someone who’s been.
  • 39.
    Additional photos by MarkNorman Francis http://flickr.com/photos/mn_francis
  • 40.
    Additional photos by StephanieHobson http://flickr.com/photos/stephaniehobson
  • 41.
  • 42.
  • 43.
  • 44.