In my first Sound and Fury post I flat out said that people who leave negative Open Source comments are bad people and sucky developers.  This isn’t a retraction, I still totally think that.  I just wanted to share.

This here project is a brilliant solution for FLOSS.  Echo Chamber adds commenting forms that never post anywhere but local storage.  The hate-vomiting suckmonkey thinks their petty, egocentric bile is being heard and no-one else even knows it exists.  No server load.  No moderating.  Blissful, peaceful silence.

My comments, BTW, are actually on, so feel free to start a discussion with me here or on Twitter as @DylanLacey.




Internet Comments, am I right?

They’re occasionally a useful source of discussion (usually in curated communities or niche content) but mostly, they’re a swirling cesspoll.  The comments are where people write hateful, toxic vitriol.

On YouTube this is often in the form of attacks on the presenter.  Open Source projects, though, tend to get more… religious.  Your product isn’t their favourite product and thus must be purged.  They want a feature from the thing you made and gave them for free and DAMN HOWDY if you aren’t the worst person alive for not giving it to them.  They don’t understand how to use it and so you must perish.

If you leave pointlessly negative comments on Open Source projects, screaming demands or trashing the free work people have done for you, then as far as I’m concerned you suck as a developer and you’re a bad person.  I have more respect for the noobiest of noobs then I do for people who piss all over others in Open Source.

I’d never hire anyone who made their team-mates feel bad when they wouldn’t do something optional for them.  I’d never hire someone who yells at others rather then fixing bugs, who acts like they’re entitled to things, who can’t interact professionally in public situations.  As far as I’m concerned, you’re not a good developer if you do those things, you’re a terrible staff member who happens to be OK with development.

Being a good Open Source citizen in the venues you use it is, in my mind, a defining characteristic of good devs.  “GitHub Resumes” aren’t useful just because they show your work style but because they show your workplace style.  How you’ll get along with others.  Whether I can trust you to not ruin my team.  If you’re helpful and good at communicating and compromising and not a complete dickhead.

(Corollary: If you defend people who do this because they’re productive or talented or useful for the project, you’re also a sucky developer and a bad person.  We don’t let famous surgeons ignore ethics no matter how brilliant.)


A friend of mine just bought a new BMW because he’s living the Software dream.  We’re currently about 2 hours out of Sydney and I’ve been slowly going out of my mind.  I don’t do downtime well.

I’ve been trying various strategies to prevent myself chewing off my own face out of frustration, almost all of which have cost me data and will add even more money to Telstra’s bloated, greedy pockets.

My mate and I are both developers, so much of the trip has been spent listening to podcasts.

We tried out a few new ‘casts.  Clockwork is “Four people, four topics” in no more than 30 minutes.  We probably won’t subscribe; it was more of a long form digest where we prefer in-depth discussions or really unique news, and our interests didn’t really resonate with the hosts.

I wanted to find some productivity podcasts because I’m tired of getting in my own way when it comes to inflicting my own brand of fucking rad on the world.  Sadly, after two episodes I’ve decided I’ll not be listening to the Time Hackers podcast again.  One felt like the entire thing was a read for through her affiliate link (which wasn’t called out as an affiliate link).  The other was about how having a boss is the best thing ever because they get angry at you when you procrastinate because how dare you!  I am glad I’m not her employee.  We also washed out on 168 Opportunities because it shared with Time Hackers a really ironic trait: The hosts weren’t succinct and the information not dense enough.

(I was tempted to listen No Such Thing As A Fish, a podcast by the QI elves about 4 interesting facts that plays a lot like the show, but I decided to be serious instead because… I made poor choices?)

Podcasts aside, my fingers got itchy, so I played Alphabear (If you want to find it in the iOS App Store instead… Go do that).  It’s what Scrabble would be, if Scrabble was single-player, had special powers and bears.  And because it’s about spelling words, it’s technically educational!

I mopped out my email.  I’ve been trying Inbox and I think I kinda get the premise, possibly?  It’s annoying I can’t apply multiple labels from the mobile app and I’m not entirely sure that marking things ‘done’ is archiving them but… I deleted 200 of 403 messages, so… huzzah?

That made me go and categorize Evernote notes because what’s more productive then pouring pointless hours into a productivity system?  Actually doing work, like buying USD for an upcoming trip to the States (Anyone who wants to catch up with me between the 19th of July and the 2nd August in SF, let me know!)

Started writing this blog article, so of course I had to update my Google Analytics plugin.  And install it and the WordPress app on my phone.  The WordPress App can connect to self-installs of WordPress which is pretty neat.

I didn’t play any of the 3DS games or read any of the books I planned.  I did, however, add a bunch of stuff to my reading list, including Beacon 23 by Hugh Howey, author of the freaking amazing Wool books.  Once we settled on using the Ruby Rogues podcast to save my from insanity, I picked up Astro City from a pick, along with Three Parts Dead.  That should help on the plane trip to the States, at least.

Overall productivity score… Probably about even.  I managed to get a lot more done then I expected on actual tasks, but didn’t bring anything to completion.  I did, however, get a bunch of new ideas and write this blog post hunched over my tiny phone screen, so that’s a plus.

Thank you for driving DylanLacey coaches, we hope you enjoyed your trip… And please fly next time.



Rails Camp and You.  And Me.  And 89+ other Rad people.

I went to Rails Camp once.  OK twice.  OK several times, and I also hosted one in Brisbane.  They’re excellent places to learn, socialise, ‘network’ (socialisation’s creepy, selfish and greedy cousin) and hack.

They’re also terrifying if you’ve never been to one.  Stuck at a remote campsite with people you don’t know, no internet access, and having to write good code?!  That’s legitimately terrifying.

But!  It’s OK.  Deep breath.  Here’s some truth:  No-one cares about the code you’re writing on Rails Camp.  For Reals.  Spouses, don’t read this next bit: Rails Camp is a really awesome way to work on your Ruby experience for everything except code because it’s not actually super professional learning code times.  No-one will judge your code unless you want them too.  You’re free to do as much serious or silly hacking as you want to.  Or play some boardgames.  Or go on a photo walk.  Or talk to people about hiring or salaries or managing minions or learning JS (you’ll find friends doing just that!) or just… being chill.  The Rails Camp people are super excellent.  Every camp is run under the Ruby Australia Code of Conduct.

The remoteness and the lack of Internet… That requires some more planning to deal with.  I’ve got a good feeling about this upcoming Rails Camp, and I want you to, too.  (Awkward sentence that.  Ahem).  So here’s the list of things that you can do to enhance your Rails Camp experience, in time order.

The Big List of Stuff To Panic and Do Today for Rails Camp Tomorrow

Now in Rough Chronological Order!

I’m about as organised as a bowl of cooked spaghetti.  But I’ve tried to put this list in chronological order, so you can read each heading in order and do the items.  Anything starting with italics is only relevant if you’d like to bring that thing.  If something takes a long time (like a backup), kick it off and go to the next section until it’s done.  It should go without saying that you should ALSO bring anything the organisers have emailed too you or posted online.


  1. Back it up.  For Reals.  Start backing it up to something you’ll leave at home.  You do this regularly anyway, right?
  2. You’ll need that backup for the next bit, in case everything gets SNAFU’d.
  3. Update ALL THE THINGS!
    1. Homebrew (Mac only) - 'brew update && brew upgrade'
    2. RVM - 'rvm get head'
    3. Latest Ruby - 'rvm install ruby'
    4. 'git pull' in any projects you want to work on
    5. 'bundle update' ditto
    6. All the gems you might need - There's usually a Rubygems mirror but it doesn't hurt
    7. Dash (Mac only)
  4. Break anything?  No?  SUCCESS!
  5. RE Dash:  Dash is an awesome offline documentation tool for Mac an iOS.  You can download it here.  It’s free with nagware and otherwise not too expensive.  Once installed, make sure you’ve downloaded and updates all the docsets you might need!  I’m using Ruby 2, HTML, Capybara, bash, Ruby on Rails 3, Ruby on Rails 4, Sass, RSpec Expectations and selenium-webdriver.
  6. Go close all your browser tabs.  If they’re action items, stick them in a list somewhere;  Nothing’s worse then getting distracted from fun hacking with that cruddy work stuff.


  1. Empty out your memory card/s onto your favourite mass storage device.
  2. Charge it.
  3. Make sure your lenses are clean.
  4. Pack your memory cards.
  5. Pack your camera.

Other Entertainment

  1. It’s going to be cold.  No-one will notice under your jumper that you’re wearing the same clothes for three days in a row.  Thus, we’re going to pack fun stuff first.
  2. Boardgames.  People tend to play games after dinner, so if you’ve a favourite feel free to bring it along!  Don’t worry about bringing Cards Against Humanity.  Someone’ll have it covered.  (I’m bringing Boss Monster!)
  3. A Tipple.  Rails Camps are not big drinking events.  But some people like to have a nip or two of Scotch at night.  I will personally judge you if you bring Malibu, because I am a jerk and that’s tacky.
  4. Sportsballs?  IDK.
  5. Drones, fancy colour changing lights, Arduinos and other tech toys.  ‘Nuff said.

Luggage & Clothing

  1. Cold Weather Stuff.  It’s going to be cold.  This goes double if you’re from QLD like I am.
  2. Kigurumi.  There’s usually people bringing Kigurumi.  Kigurumi are awesome.  I’m a legit adult.
  3. Other dorky but comfortable gear.  Some people bring wearable sleeping bags, like these Selk Bags.  Those people are awesome and you should buy them a beer whenever possible.  I may be one of those people >.>
  4. Sleeping Bag.  Even if you hear you don’t need it, it’s never a bad idea to be prepared.  There’s some team has that as a slogan…
  5. Thongs for the bathroom.  Flipflops if you’re Podean.  Jandals if you’re Antipodean, but the other kind.Take this from a Scout — Cold grotty shower floors aren’t any fun.  Neither is getting your feet cold when dashing to pee in the middle of the night.  For the non-Aussies; Thongs are flip-flops.
  6. Suitcase. Duh.
  7. Any Meds & First Aid Supplies.  Just in case.
  8. CPAP Machine.  Pretty sure you won’t forget this one if you need it.


  1. Pack your laptop power brick in your backpack.  If you have a spare, put this in instead so you don’t take your primary out to use it and then forget to put it back in.
  2. Pack a powerboard.  Just in case.
  3. USB charger for your phone.  Even if you don’t have internet access you know you’ll get the shakes if your phone starts going flat.
  4. Chargers for anything else you’re bringing to play with.


  1. Coffee.  You’re a developer.  Worse, a Ruby developer.  Chances you’re into wanky coffee are higher then chances that a Rails 2 app on Ruby 1.8 has security holes.  While most camps provide coffee (and some have rad baristas!) the coffee nerds often bring their favourite blends and coffee making toys.
  2. Cancer Sticks.  I’m asthmatic so I get judge-y, but addiction is a beast and it’s not cool to be jonesing all weekend;  There’s often no stores nearby camp, so make sure you bring enough to get by.
  3. Chocolate and sweets.  Because what’s a better thing to share with your fellow devs then Vegemite Cadbury!

Print Media is somehow still a thing

Even print media about rich people making more money is still a thing, which probably says something about who those people are and their attitudes to change. Yes, that’s an Old White Men joke.

But print media knows the end is nigh and has moved online as well as being available in print, and Fortune magazine is no exception! It’s even writing articles about these shiny new technical whatzcalits, like a recent article, ‘Why APIs will save your business from getting “Uber-ed”‘.

Oh, sweet fish sauce, that article. It’s… you don’t… I started making fun of it on Twitter then quickly realised there was just too much and you, Dear Reader, would be better served by a blow-by-blow commentary. Fair Use Away!


Why APIs will save your business from getting “Uber-ed”
It’s no longer about what you build alone. It’s about how you smartly incorporate what others have built.

I am seeing a technology shift that only happens every 10 to 15 years – one in which companies will become “composites” of other companies.

(Like how, 10 years ago, Apple become a composite of Swarovski, Swatch and 90s era Sony, or how Alta Vista became a composite of Betamax and Crystal Pepsi)

Uber is a perfect example. It didn’t have to build its own mapping, payment, or communications services. Instead, Uber is a composite of what it considers the best of those programs and more — Google Maps, Braintree (payment), Twilio (for mobile SMS), Oracle, etc. Uber was able to quickly connect to these systems using little pieces of code called APIs.

(Yes, the API itself is a tiny chunk of code you just put in your own code and magically, billing happens)

MuleSoft is in the business of APIs, and today’s announcement of MuleSoft’s latest $128 million financing round at a $1.5 billion valuation is evidence that this trend is more than gathering steam. [Disclosure: I am an early venture investor in MuleSoft.]

(Disclosure: The only way I can made money from my API middleware As A Service investment is convincing you all that your existing APIs are in fact legacy ‘integrations’ instead)

Companies pursuing API-led connectivity strategies include MasterCard, Unilever, Nestle, Tesla, Intuit, BSkyB, Verizon, News Corp and Sutter Health. This shift it is only possible because of a once-in-a-generation convergence of megatrends: cloud, mobile, and the “Internet of things.”

(API-led connectivity strategies: much better then those old ‘protocol’ and ‘carrier’ based ones.  Also mega is _last_ generation’s slang.  The hipster generation prefer ‘whatevertrends’)

If you’re not taking full advantage of this trend, your organization could be “Uber-ed” and out-innovated, just like the taxi companies have been. Uber has upended the global taxi industry in large part by using APIs masterfully. In just a few short years, Uber has become seemingly ubiquitous and is reportedly valued at $50 billion. The old-world taxi companies are struggling to compete with this API-savvy juggernaut. You don’t have to be in the transportation industry to be Uber-ed. Any business without a viable API strategy stands to be altered on this scale.

(This is so blatantly wrong it’s being funny _for_ me.  Taxi services weren’t out-innovated because of Uber’s mystical oneness with the API universe. They were out-innovated because they didn’t try to innovate at all. They still don’t; Their reaction has been to try to legislate, sue and bully Uber out, not try to fix their product and compete.  This is like saying a greasy sidewalk hotdog grill gets less customers on a date then a fancy restaurant because the restaurant’s supply chain is faster)

Why CEOs Should Care

(They shouldn’t)

Companies are currently spending more than $590 billion per year to integrate existing, disparate systems. Traditional businesses rely on large sales forces, paperwork, and fax machines to generate revenue with customers and through partners. This is expensive, time consuming, and scales only as fast as the sales force grows. Today’s startups eliminate much of this friction, time, and cost by building their solutions with best-of-breed components, which they access via APIs, or “application program interfaces.”

(So existing disparate systems, they don’t have APIs, they have ‘integrations’. Because they’re old, see? APIs are jazzy and sexy and new. So new, we only literally just now got a definition for them, halfway through this article! Until APIs were invented last year, absolutely every business was unscalable and did everything with FAX.)


Using APIs as building blocks, Uber was able to go to market far more quickly and nimbly than its competitors. What’s more, in August 2014, Uber launched a publicly-accessible API that would become the foundation for their digital ecosystem, allowing companies like OpenTable, Google and United Airlines to embed Uber into their apps.It’s a mutually beneficial arrangement: Uber reaches more customers and establishes new revenue streams, while app providers like United Airlines, Open Table, Google Maps and others can offer a transportation service to their customers and profit from it at the same time.

(Again the fallacy that sexy startup VC backed API based data-viagra, and not being thoroughly better, are what made Uber work. This time, thought, it’s because you can get a pizza on the way to the airport. What’s the deal with Airline food AM I RIGHT?)

Contrast this with Hertz, Avis, and other rental car agencies that have been United Airlines partners for decades, but are nowhere to be found in the United mobile app. That’s because these rental car companies don’t have an API (or at least not one that’s public). OpenTable, Google Maps, Starbucks, and dozens of other apps offer the Uber service — but not services from Uber competitors like Lyft — so there is definitely a first-mover advantage in each market.

(…You literally just said that lack of an API is why United’s business partners aren’t in their mobile app)

Another simple but enormously successful example is UPS, founded 108 years ago. UPS has captured a large share of the parcel-shipping market for the burgeoning online commerce sector by publishing an API – just a few lines of code – which makes it easy for shopping sites to integrate shipping seamlessly into their online check-out process.

(Again this ‘few lines of code’ thing. Every word in the phrase ‘an API – just a few lines of code –’ is bullshit. APIs can take thousands of lines of code to write and powerful ones, hundreds of lines to consume. That’s completely ignoring that APIs aren’t actually code, any more then a delicious cooked steak is DNA)

The “Connected Era” is Happening Now

There are progressive management teams productizing their company’s value-add as a service via APIs now, allowing any connected business to instantly become a customer or partner.

(I think I just went partially blind from buzzword poisoning)

Everything and everyone will be connected digitally – including customers, employees, partners, and even “things” like appliances and cars – all through APIs. How a business wins or loses is increasingly dependent on how well they connect to external third party apps, devices and services.

(Connecting to things now acceptable as a substitute for competence, performance, price, utility or human rights)

More Examples

News Corp Australia’s CIO Tom Quinn last year declared a “cloud first” strategy that gets rid of hundreds of applications residing in the company’s data centers. This shift requires big changes in the way IT is delivered. Said Quinn: “Technologies are changing so fast, and new systems are coming onboard so often, that you don’t want to be locked into a big monster piece of tech. We are not holding the business ransom to detailed, intricate, costly in-house development in order to get things hooked together.”

(No, now you’re holding it to ransom with services you can’t customise, by forcing (possibly good) process change on unwilling staff and by risking services being sold, absorbed or shut down.)

With APIs, you can hook, and unhook, to the best available software and services on your own timetable.

(Making in house systems talk uses ‘big monster piece of tech’, is very hard, messy. Making cloud services talk uses APIs, is somehow much easier despite doing the same thing, simple. Providing those services don’t go bankrupt, don’t have downtime, support the operations you want via API, are reliable, don’t break the API randomly, don’t communicate insecurely, have well managed downtime, support request caching and retries…)

Sutter Health is a large hospital network in California serving more than 10 million patients each year. It created an app in three months with APIs,

(Did they build an app which they built an API for, or did they build an app that used existing APIs?)

versus nine months without, to help diagnose and better treat an autoimmune disease.

(Were the time savings due to actions Sutter Health took, or just made possible by the systems they’re using being more modern?  Also, how do you know how long it would take them without the APIs? Do you have an API to contact the parallel universe where they don’t use APIs to ask Sutter Health how long their app took to develop, and if so, how do the people in that universe communicate with your API, given they don’t use APIs?)

Previously, accessing information across multiple data sources used to be a huge challenge. Now it’s possible to get real-time access to healthcare data. The Sutter Health app connects disparate data—from EMRs to administrative systems—and can display this data on any device.

(Some false correlations here. News Corp moved its support software into the cloud to avoid lock in and APIs let you connect different apps which might avoid lock in SO NEWS CORP USED APIS! It used to be hard to access multiple sources of data (apparently) and now you can get real-time access to data and Sutter Health’s app was delivered 6 months faster (apparently) SO APIS LET YOU MAGICALLY ACCESS ANY DATA IN REALTIME!)

So whether you’re the CEO of a Fortune-500 company or small business, building a company from scratch or reinvigorating a well-established one, you owe it to your stakeholders to explore what APIs can do for your business.

(So please go shout at your CTO to buy the first _enterprise grade_ API-based product he can find: mine)

Gary Little is a general partner at Canvas Venture Fund, an early-stage venture-capital firm based in Menlo Park, CA. He serves on the boards of Adara, Evernote, MuleSoft, PeopleMatter, Sonatype, and Totango.

(And yet he still doesn’t seem to fully grasp what an API is.)

My Summary

This article, man.  It seems to fundamentally misunderstand what an API is, treating them like a chunk of code that can be applied to any system to make it vomit money. All of the effort of making or implementing to an API is handwaved away. It draws this imaginary distinction between system integration of older & non-cloud products (which apparently don’t use APIs for some reason) and integration with cloud products (which do).

Plenty of older systems have APIs. They’re just shitty. Even if you use a modern service it’s not like lego; you have to tell the API what to do, and if you are linking cloud products you often need a 3rd party system to host the glue code linking them together and implementing your business rules.  And there’s going to be just as much business rule logic for a new API as an old one;  It’s only things like data marshalling and synchronisation that most truly non-API based legacy integrations are bloated by.  There’s just often a LOT of that.

That’s disregarding that you need to have APIs offered by the systems you want to integrate.  If your core business app is from a 3rd party and has no API you’re screwed.  If your billing system isn’t out of contract for 15 more years and doesn’t have an API you can’t exactly add one without assistance.  There’s no magic panacea for crap systems.  Good systems have good APIs, but lots of otherwise perfect systems don’t.  You can’t forcefully add them.  The better version of this article avoids treating APIs like a miracle (and all the logical fallacies).  It focuses on flexible and well-written systems, with open APIs and data formats forming one part.  But it also focuses on using industry standard business processes, the importance of offering an API to, at least, your business partners, and providing enough value through it that people want to consume it.

The entire article reads to me like a PR piece, trying to get CEOs in a buying mood for ‘APIs’ like they’re pieces of hardware, in the hopes that they’ll investigate the author’s VC baby as an ‘Enterprise’ option.  Even if this isn’t the case… It’s just a load of bollucks.


In Japan, things are a little more advanced. We know they’ve already got flying lazer cars and evil death robots who battle special teenagers with super transformation sequences, but they even have more boozing. See, the age of majority is lower then in the United States – it’s 20. In Japan, you get a whole year of extra boozin’ over your counterparts (although Australia is still two years ahead again).

Why am I bringing this up besides skyting at my friends from Freedomland? Well, because today, my favorite programming language, Ruby, can go out, smoke an entire pack of Lights, grope a paid adult entertainer, down an entire bottle of whiskey and then loudly throw up all over the street, because it turns Twenty today.

Now, I know you aren’t invited to the party (Because you’re not as cool as me and Ruby’s Daddy Matz doesn’t want your sort around) but Ruby is going HARD. It’s already updated it’s official age on its profile! OK, so there’s a decimal point in the wrong place but like YOU could write your age correctly after getting shitfaced on 2 bottles of sake and that really weird beer your sketchy friend drinks. Frankly, as long as Ruby doesn’t wake up next to Oracle, covered only in honey and fake fur, I think it’s doing pretty well.

Happy Birthday Ruby, Thanks Matz, and Rock on, Ruby Community! (Check out the SWEET gifts Ruby got At Ben Hoskings’ Blog)

(TL;DR for boring people –> Ruby version 2.0 is out AND it’s the 20th birthday of Ruby. Install, Code, Win.)


From the beginning of my career, I’ve been tending smaller and smaller. From consulting gig, to Government enterprise, to 300 person company, to smaller Government enterprise (never again) to a publishing company… Each one getting smaller in size, and feel. Agile, dynamic companies full of smart people is where it’s at.

I’ve also realised that I want to make things that matter to me, and one thing I’m really passionate about is developers. I *love* helping people and I love making cool shit, so being able to help people make cool shit is really exciting to me. I also think that people need time to think, to work and act… Doing things manually that aren’t valuable wastes the most valuable thing any given person has, their mind. I want to help free them.

Both of these put me on a trajectory to one single possible outcome, which I’ve chosen to put in interpretive danceeasily digestible image format:

Technically this is the Bridge

(This is San Francisco)

"THE" Bridge.

(I am here. Over my right shoulder is the Bridge)



I read from stdlib/json, line 23... (I am Ruby Developer Evangelist)

17 if you count our Consulting Miniature Schnauzer

(I am Employee Number 16 Here)

Which is good because it's cold.

(They even gave me a hoodie)

(My job involves a lot of trips on these)

(I’m also required to drink a lot of these. It’s a burden)






(Sauce Labs do Selenium Testing in the Cloud) (Sauce Labs do Selenium Testing in the Cloud)

(It's fucking AWESOME)

(It’s fucking AWESOME)

3630920835_6a5f3a9b77 (You get Screenshots for every action and video of the entire test)

(And if you're not able to deploy development to the outside world, we provide Sauce Connect, an awesome VPN tunnelling solution)

(And if you’re not able to deploy development to the outside world, we provide Sauce Connect, an awesome VPN tunnelling solution)

(Sauce Labs do Selenium Testing in the Cloud) (Sauce Labs runs our own cloud)

8328690534_6e588141bb_b (Instances run in seconds and last only as long as you need. Our CEO calls it Efervescent Computing)

(I am insanely excited to be able to work with such smart people on such a cool product)

(I am insanely excited to be able to work with such smart people on such a cool product)

My bailiwick is to make it better for Ruby developers to use the product, including improving the gems, writing better documentation and building the community. Plus, a unique opportunity to use my personality to insult people all over the world! If you want to offend your manager, disrupt your office and get kicked out of your favorite bar for getting shouty about whether RSpec shits all over Test::Unit (It does), let me know. Hell, even if you just want help with the Sauce Gem or tests from Ruby land, hit me up.

You can Find me on (T) or (E)


So I worked all weekend this week. I won’t get paid. I won’t even get a nod from my boss, although I was there for even longer for a standard work day. Jerks. Time to burn the office down. Get my stapler back.

OK, so they’re not jerks, and I wasn’t working at work. I was at Brisbane’s Global Day of Code Retreat, taking generous advantage of the Thoughtworks office’s fridge and wifi.

The idea is that you spend a day focusing on implementing the same thing over and over, so you can hone your professional skills. In the same way as a sculptor might practice straight lines over and over, we implemented Conway’s Game of Life using TDD techniques in 45 minutes. Every 45 minutes you had to delete your code and tests, debrief, and start again with a new constraint. Some of the constraints felt more annoying then educational, but on the whole I felt I got something out of every session. I also got to teach a couple of people something about TDD & RSpec, and I love helping others improve, so I got a kick out of being able to contribute like that.

I’m going to post how I found each session today, then mull over the others and post some observations a little bit later. I think it’s best to see how learning effects you in other contexts (like actually at work) before you jump into critiquing it, so I’m going to see how the next work week goes.

Session 1

Language: Ruby
Testing Framework: RSpec

This session just booted people off into implementing Conway’s life. I worked with a young Thoughtworker whose name eluded me, and we got about halfway into an implementation before time was up.

We spent the majority of this session just discussing what way to do things. I was a big fan of using a “Cell” object which maintained a list of its own neighbours, without directional information because it doesn’t matter. Doing it like this allows for arbitrary topologies (And I suspected that might be one of the constraints.)

Potentially tricky issues with this approach include implementing the tick for every cell at once(If you duplicate the cells, you have to duplicate the network and ensure you’ve duplicated every cell with its new state. If you mutate the network in place, each cell needs to know if it’s neighbours have ticked, and if so, what their state was last tick.

At the end of the session we had a discussion about what techniques people tried. Having a “Cell” object was quite popular (OO is like herpes, it spreads with contact), there was one “have a universe holding an array of cells” solution, and the one which I liked most, which was using the co-ordinates of the cells as a key for a hash of booleans, representing whether the cell is alive or dead. I really liked this… It’s unbounded (unlike an array in many languages) and *doesn’t* require a hojillion objects.

Session 2 – Ping Pong

Language: Ruby
Testing Framework: RSpec
Constraint: Each time you write a test, you ensure it tests properly, then you pass it to your pair and they have to do all the implementation. Then they write the next test, and you implement that

This session we decided to try the hash technique one of the groups suggested last time. I say”we decided” but actually mean “I decided”, because prevarication frustrates me, my partner had no strong opinions and I thought it sounded interesting so I made a snap decision.

The Ping Pong criteria is how I’d probably prefer to do pairing in the future, although usually it irks me (I need to be doing something and my “I’m not doing anything” behaviors usually irritate my pair). It meant that your tests had to be higher quality, and there was a defined place where you had to hand over to the other member of your pair — No long stints at the keyboard or just watching.

We didn’t get an implementation finished though, although I worked out how I’d like to derive neighbours. I proceeded to teach people a tiny bit of matrix math all day (more on that later)

Session 3 – Silent Ping Pong

Language: Ruby
Testing Framework: RSpec
Constraint: The same Ping Pong TDD as before, but this time you’re not allowed to talk

I paired again with a Thoughtworker this time, a gent from China called Hiyun (I hope, sorry if I’m wrong mate >.>). Wow. Dude was a shortcut pro. I learned a shittonne of RubyMine shortcuts and tricks I’d always wanted too but never devoted time to (Which is obviously my fault). It was really cool, probably my favorite session of the day.

We went back to the “Cell as self aware object” paradigm (drink). With the exception of a couple of inadequate tests, this session worked remarkably well. The inadequate tests required a lot of gesticulating. Once you’ve written something it’s hard to prove that the test is wrong rather then the code.

I think not being able to talk focused our attentions on communicating *only* our requirements through tests. There was no discussions of where you worked, what you thought of Test::Unit VS RSpec, why’s DHH’s hair like that; it was purely a “get shit done” event.

I think the most surprising thing was that we finished. It was almost like being unable to design architecture by consensus made one arise naturally out of requirements, which I am… skeptical of. I’m not sure how well our solution would have accommodated change, but maybe most software projects are simple enough that it doesn’t matter.

Session Four – No Primatives

Language: Ruby
Testing Framework: RSpec
Constraint: Rather then using native types to store results, cells and so on, use a wrapper class or object. No Arrays of cells, no returns true

Oh god so hard. Getting away from primitives in Ruby is hard. Every time I wanted to wrap something I heard a tiny voice in my head stop talking about bees, games, cooking and Alice in Wonderland for a minute to scream “NEEdleSS ComPleXItY!“. All I wanted to do was use built in objects so I could rely on methods that Someone Else Has Tested™.

This session, we did something horrific. We decided that, if we weren’t going to use primitives, we’d use something as far removed as possible. Something so non-primative it’d make your eyes haemorrhage.

Yup. Files. To check if there was a cell at (4,5), you checked the directory ./data/4 for file 5.cell. If it existed, it was alive. Touch a location to make a cell alive, rm to delete it. We were planning to store the current generation number in the file to allow for ticking.

How’s that for non-primitives, bitches?

Session Five – Tests must pass in 3 minutes

Language: Java
Testing Framework: JUnit
Constraint: Once you start writing a test, you must write code to make it fail in three minutes or less. If you get to three minutes without it passing, you must revert all you changes and delete your test

The intent of this constraint, I believe, was to force you to test small amounts of functionality rather then huge sweeping changes. The idea is that small tests are good tests, and it’s tempting to write large tests that try to do too much. When they fail, you’re not actually sure why, and you lose much of the advantage of a full test suite.

My pair (Hi, Mike!) and I chose Java because it was our lingua franca (Scala was preferred but it’s quite hard to use a language without a dev environment, oddly enough). This may not have been the wisest choice, because of one simple truism:

Fuck me Java is Verbose!

It’s not just the punchline to the “what’s wrong with other people’s languages” joke. It was never really bought home to me just how verbose Java was until I had to spend so much time setting up each test. I’d just spent most of the day writing Ruby and now I’m having to give all my tests annotations and a typed, static method signature, and set up my variables types, and then set up and type the method and ensure to return the right sort of thing, and just making so much boilerplate it nearly made my eyes bleed (I propose we call this Stigjava.)

Even Mike, who writes Java for a living, was surprised. He said it bought Java’s verbosity into stark relief after a day of writing Ruby and Haskell. It forced us into doing true TDD because otherwise we simply couldn’t make a test that tested anythingin time. We had to implement the minimal amount every single test pass. Here’s how we had to test that we could get a list of neighbours for a cell:

  • Write a test to ensure that there is a “getNeighbours” method. Just that one exists. Pass it

  • Write a test to ensure the method returns an (empty) ArrayList. Pass it.
  • Write a test to ensure the method returns an ArrayList containing eight things
  • Run out of time because it took so long to learn how much code we could write at once

It was just astonishing. I’m not Java bashing (so passé), just really surprised. Writing the code to pass things, and even the tests, wash’t too hard, just getting to a point where we could do something took forever. And Mike is an IntelliJ wizard – Otherwise we’d have been screwed. He was making sweet combo love to the keyboard to bust out methods and variables and implement the signatures correctly and we were still fighting the clock.

Session Six – No Returns

Language: Ruby
Testing Framework: RSpec
Constraint: None of our methods could return values.

Woah. OK. Globalling it up. During this session I had a bit of an idea how to use events to generate a grid of neighbors, but didn’t implement it cleanly. Actually, this session was embarrassing because I forgot that Ruby is pass-by-reference, so resorted to using Globals. Don’t tell my mother. The solution wasn’t really productive, just because every time I manipulated the global objects I felt dirty and wanted to cry.

During this session, the pair using Haskell gave up on the constraint and just started trying to get it working at all. Globals were popular (at least we weren’t alone wallowing in filth) and only one group used callbacks. The idea I’d had was callback/eventing based, but wasn’t async, so obviously I need to do a bit more work about doing that kind of programming at need, rather then when forced.

Then, we had beer, a debrief and a powwow. Roughly half the room left straight away and the rest wanted to hang for a bit, which I always enjoy. I’m looking forward to the next one. I’m thinking this time, we use the presence of machines on a network as live cells….


A quick tip. It’s relatively easy to build a test, or an entire suite, and never actually ensure it gets run. Which makes all the effort that goes into it worthless AND gives you a false sense of security. It’s like having a photo of a security camera feed instead of the feed: “Of course everything’s safe, look!”

So, every time you create a new test file, assert that false == true. And run it. And make sure it fails.

Otherwise you’re wasting everyone’s time, especially your own.


The Story

(If you just want the solution, check out the “Solution” section below)
My parents have a Linksys SPA-3102 ATA for making long distance and international calls (family in Victoria, daughter in Austin) because the idea of using a headset and a desktop program is weird and disturbing. Well, and it’s easier. Hi dad!

Recently the VOIP server (Privately operated) was broken into and used, no doubt, for one of those cheap phone cards or to power some sketchy “Hello this is Microsoft what is your credit card you have a virus in your cheese” scammer. The server admin reset the DNS binding, security and username policy so the ATA had to have its settings updated, which proved a challenge for my parent because the bloody thing wasn’t responding to its web interface.

So since I’m vising them at the moment I’ve been taking a look at the adapter and found that indeed, it’s not responding, and I’ve checked every device on the network to find out if it’s one of them (Which first involved finding the IP of the router because apparently is a ‘proper’ address for a router. Which is security in the same way that hiding a key under the doormat is: You deserve to be broken into).

The problem was, I figured out, that its web interface was disabled (somehow). You can fix that, thankfully, with the magic of DTMF tones.

The Solution

It turns out these particular ATAs have a DTMF interface usable from any connected handset. So, as long as you’ve got a handset, you can dial numbers into it and get the information (and perform any configuration) you need.

Finding your ATA’s IP address

Enter the DTMF administration console by entering * * * * into the phone and waiting for the lovely British Robot Lady at the other end of the phone (I’m going to call her Estelle) to tell you you’ve entered the “Linksys Configuration Menu“.

Enter 1 1 0 # and Estelle will read out the device’s IP address.

Enabling the Web Interface

From the main menu (Just after Estelle welcomes you to the configuration system):

  1. Enter 7932
  2. Enter 1 #
  3. Wait to be asked to save
  4. Enter 1

You should now be able to head to the IP address quoted, on port 80 (the standard HTTP Port) to access the web interface, which is what I recommend for most tasks (If only for reasons of speed). Oh, and don’t forget you’ll probably find Advanced Admin mode more useful… Click on “Admin Login” then “Advanced on the right hand side of the web admin console’s header to enable it. And, just because it’s not *overly* clear, all the VOIP settings are under the “Voice” tab.