/dev/fort: you can build it in a week @emw
0 likes566 views
/dev/fort is an event where a group of individuals isolates themselves to build web projects without the distractions of the internet or management pressures, allowing them to focus on high-quality development. Attendees are encouraged to collaborate intensively, test their ideas, and utilize a curated collection of documentation and tools, referred to as 'internet in a box'. The experience promotes learning, better teamwork, and the belief that technology can be advanced without the usual compromises encountered in a corporate environment.
![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.](https://image.slidesharecdn.com/devfort-emw-with-notes-130505050651-phpapp01/85/dev-fort-you-can-build-it-in-a-week-emw-20-320.jpg)
/dev/fort: you can build it in a week @emw
- 1. 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.
- 2. 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.
- 3. What is /dev/fort? Some things we’ve built WLNY (bit bucket). Mostly Final. Spacelog. History Mesh. BeHabitual.
- 4. 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…
- 5. Technology at about 8.5 “We don’t have time”
- 6. Technology at about 8.5 “Something something velocity”
- 7. Technology at about 8.5 “I don’t care about accessibility”
- 8. Technology at about 8.5 “I don’t care about accessibility” “I don’t care about testing”
- 9. Technology at about 8.5 “I don’t care about accessibility” “I don’t care about testing” “I don’t care about security”
- 10. 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”
- 11. 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”.
- 12. 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.
- 13. 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.
- 14. Technology at 11 Doing the Right Thing Test your code
- 15. Technology at 11 Doing the Right Thing Information security
- 16. Technology at 11 Doing the Right Thing Monitor usage
- 17. Technology at 11 Doing the Right Thing Semantic HTML
- 18. Technology at 11 Doing the Right Thing Maintainable CSS* * this is a lie; CSS isn’t maintainable
- 19. Technology at 11 Doing the Right Thing Javascript not required
- 20. 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.
- 21. 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.
- 22. Internet in a box Package mirrors CPAN, ruby gems, PyPI, npm…
- 23. Internet in a box Documentation mirrors RFCs, Internet Drafts, w3.org, jQuery documentation…
- 24. 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.
- 25. Internet in a box Twitter Oh yeah, and we have twitter as well.
- 26. 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.
- 27. 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.
- 28. Internet in a box github.com/spacelog And there…
- 29. Internet in a box github.com/historymesh And a lot of places…
- 30. 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.
- 31. What can we learn from this? Collaborate better Really quickly, too.
- 32. 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.
- 33. 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.
- 34. 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.
- 35. 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.
- 36. 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.
- 37. 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.
- 38. 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.
- 39. Additional photos by Mark Norman Francis http://flickr.com/photos/mn_francis
- 40. Additional photos by Stephanie Hobson http://flickr.com/photos/stephaniehobson
- 41. Questions?
- 42. Questions?
- 44. Questions? james@devfort.com* * so call me, maybe?