I’ve enjoyed using Medium for my last few blog posts, and so I’m going to move there for all new posts. I won’t be posting updates to this blog, unless I move again in the future. To view my ongoing blog posts read them on Medium here, or subscribe to the RSS feed here.
Thanks for reading!
I decided to write a longer piece on the new trend of Serverless Architectures. Martin Fowler asked me if I’d be willing to host it on his site, an opportunity I was happy to take. It’s an ‘evolving publication’, as Martin puts it – as I write this I’ve posted two installments so far and I expect there to be another 4 over the coming days and weeks.
Read Serverless Architectures at Martin’s site.
Cross-posted from Intent Media’s tech blog, here.
Last year I was inspired by several engineering leaders, including Camille Fournier (at the time CTO of Rent the Runway) and James Turnbull (CTO of Kickstarter) to roll-out ‘career ladders’ within the Engineering organization at Intent Media. The technology team grew large enough, and aged enough, and changed enough that the team members lacked clarity about (a) what expectations everyone had of each other’s work; (b) what opportunities people had to grow within the company; and (c) what areas of their work they could focus on in order to best move into those new opportunities.
I read how various teams overcame these challenges (especially Rent The Runway’s work here, here and here, and Kickstarter’s work here) and created, with the assistance of the rest of the organization (especially PJ (Paul Julius), CTO), our own version. In the spirit of giving back to the community that helped to inspire me, I present our model here. Enjoy!
Download – Intent Media Engineering Ladders
I recently wrote an update to my experiences following the London Bombings 10 years ago, which includes a discussion on mental health. I decided to try out Medium as a host for this, and the article can be found here.
One of the things I love about working out of WeWork Labs is coming across people in the technology world I wouldn’t normally meet, and finding out about what they’re up to. A couple of the members here run a meetup called The Test Tube (twitter at @testtubenyc). Its elevator pitch is ‘Speed Dating meets User Experience Testing’ which at first sounded like something I wouldn’t be that interested in. Other WeWorkers (yeah, I just did that, sorry) were highly complimentary of it though so I decided to try it out. And I’m very glad I did.
To set a little context here – I’m working on a brand new product with a friend of mine. We’re about 3 weeks in and have a very early, very rough, prototype of a small amount of what we want in the MVP. I thought it was too nascent to be able to get user feedback on but I was convinced by Pierre Wooldridge, one of the Test Tube organizers, to try out his meetup anyway.
Taking place this time at Gilt’s office in midtown about 50 people were there. After brief introductions and a short talk from one of Gilt’s UX people we got down to business. Here’s how it works:
- Everyone there is organized into a first pair, who I’ll refer to as Ms Green and Mr Red.
- Ms Green has 7 minutes to get feedback on her product from Mr Red.
- Ms Green starts by giving the briefest context possible, and by describing the scenario she’d like Mr Red to try to work through.
- Mr Red then uses the product, vocalizing his thought process as he goes.
- When there’s about a minute left they’ll try to summarize the experience.
- Ms Green and Mr Red then swap roles, giving Mr Red 7 minutes to get feedback on his product from Ms Green.
- After both people have gone through the process all pairs are rotated (a strict clock is kept in the room) and the process is repeated 4 more times, giving each person 5 different opportunities to get feedback.
I’ve never done user experience (UX) testing before with people I didn’t already know and found the process absolutely fascinating. Even with the extremely raw product we currently have there was enough there for our opposites to give what in their minds were just their first feelings but in ours’ was insightful feedback. As an example from 4 of the 5 rotations one of the most basic assumptions that I’d already made about the product, which affects the very first screen of the application, turned out not to fit people’s expectations.
One of the truly brilliant aspects of The Test Tube is the time constraint. Not knowing the people you’re sitting with could lead to social awkwardness and hesitancy. But with only 7 minutes you’ve got no time for that and so you’re forced to plough straight in. Furthermore since there’s only 15 minutes per pair you can get 5 completely different sets of feedback in less than an hour and a half – brilliant!
I’d like to congratulate Pierre and Tom on a fantastic idea, well executed. I’d whole heartedly recommend The Test Tube to other NYC software product developers, whether in startups or established businesses.
This wasn’t entirely obvious to me, so here goes.
First some very quick background. Travis CI is a wonderful, hosted continuous integration service, that is free and very easy to use for open source projects on Github.
I have a Clojure project on github that I want to build, but it’s in a sub-directory of its parent repository. It took me a few attempts to have Travis handle this correctly, but in the end it was simply a matter of doing the following in the .travis.yml file:
What doesn’t work (and which I tried before realizing what’s going on) is using before_script, or putting the ‘cd‘ call within a script line itself. This doesn’t work because Travis runs ‘lein deps’ after before_install, but before before_script (and therefore before script) and thus fails if you haven’t already changed to the directory where your project.clj is by this point.
My full .travis.yml at time of writing is as follows:
Recently I’ve been having a lot of fun using the Evernote API from Clojure, especially as part of developing Orinoco. I’ve now open-sourced my lowest-level Evernote code as Clojurenote.
Evernote already provides a thorough Java SDK and Clojurenote doesn’t aim to completely replace it. Clojurenote does, however, implement the following:
- OAuth authentication (using the fantastic Scribe Java library)
- Basic read/write capabilities, using an OAuth access token, or developer token
- ENML to HTML translation (ENML is the XHTML derivative that is used for the content of Evernote notes)
You’ll still need to be happy mucking in with the Java SDK but Clojurenote will make a few things cleaner and easier for you in your Evernote-accessing Clojure code.