While It’s Compiling: Skills Matter interviews Tom Stuart

In the run-up to CukeUp! 2015, we caught up with BDD expert and enthusiast Tom Stuart to ask him about his talk and what he thinks of the current state of BDD. Tom is a computer scientist and programmer. He has lectured on optimising compilers at the University of Cambridge, co-organises the Ruby Manor conference, and is a member of the London Ruby User Group. You can find him on Twitter here, and visit his website here.


You’re leading an open-discussion at CukeUp that’s looking to define what BDD actually is. Can you give us a brief overview?

The title of the discussion is “WTF is BDD?”, and the idea is to try to get everyone to agree on a simple, clear, concrete description of what BDD is and literally how to do it. I don’t know if that’s a realistic goal, but I thought it would be interesting to try.

Where did this need to redefine BDD come from – what has led you to this talk?

It’s not about redefining it so much as just nailing down a usable definition in the first place. I honestly don’t think we have one right now and I find that frustrating.

The term “behaviour-driven development” has mostly worked well for discussions between experts — primarily this means consultants and trainers — because the people involved in those conversations know how things have been done differently (and badly) in the past, and are able to use that experience to interpret, frame and prioritise the whole cloud of ideas that swirls around BDD.

But I’d say there’s been a failure to communicate the essential idea of behaviour-driven development to the wider non-expert community, which is a shame because it’s the non-experts who stand to benefit the most from it. I find BDD very useful but I also find it difficult to persuade other people to do it because there’s nothing to point at to show them what I’m talking about. That makes it look like it’s not a real thing. It‘s embarrassing.

Right now the only guaranteed way to “learn BDD” is to pay one of those consultants or trainers to come and teach it to you, which is fine in itself, but it shouldn’t be the only option. If BDD has validity and value then we should be able to communicate it straightforwardly, without jargon or enterprise-consultant-speak.

And even among experts there’s a lot of noisy disagreement over the details of what BDD is. There are so many blog posts out there about “doing BDD right”, “doing BDD wrong”, “BDD is not X”, “BDD is just Y”, “if you’re not doing Z you’re not doing BDD”, and so on. This sort of debate is a sign of a healthy and inquisitive expert community, but again it’s not helpful for getting people engaged in the basic principles and practices of BDD. It puts them off — “if these clever experts can’t even agree on what it is, what hope do I have?”. I like to think that if we set aside the fine-grained disagreements for a moment, we’ll be able to agree on some big fundamental stuff that would be useful right now to people who need help with their software development process.

You’re currently working on a book and screencast – How to Write a Web Application in Ruby. How did that come about? And when can we expect to see it!?

It’s adapted from a workshop I run for Ruby developers. In the workshop we incrementally build up a complete web application from scratch by reading the appropriate specifications and using only the Ruby standard library — TCPSocket, URI, CGI, that sort of thing. Then, once it’s working, we refactor it by replacing bits of our hand-rolled implementation with battled-tested third-party code like Rack, Active Record and Action Pack. So halfway through the workshop we have a long manual implementation of a web application, and by the end we have essentially a short single-file Rails app. People seem to get a lot out of the workshop when I run it, so the book and screencast are about taking that same content and making it available to anyone online.

The stated goal of the book is to help Rails developers to understand their tools better by illustrating what each piece does in isolation and how they fit together. Its unspoken ideological goal is to make the point that software isn’t magic and it doesn’t come about by a process of divine revelation. It’s just stuff made by people, and you’re a person, so you can make that stuff too. You don’t need to wait for someone else to come along and make a framework for you to use; you are capable of building a thing yourself. Of course there are good pragmatic reasons to reuse someone else’s work instead of building everything yourself, but ideologically it’s important to know that you have a choice. Software is brilliant and it should be empowering, not constraining.

I’m ashamed to say that it’s become a bit of a long-term project now, not because I’m not excited about it, but just because I’m a terrible procrastinator and I don’t have a publisher breathing down my neck about it, so I can easily put it on the shelf for months at a time while I’m working on other things. I first announced it on the Ruby Rogues podcast in August 2013 so it’s definitely been brewing for a while.

I’ve resolved to get it shipped this year. That sounds terribly pessimistic. What I mean is that I’ve made a resolution to speak at fewer conferences in 2015, because they ordinarily take up so much of my time, and the idea is that I’ll be freed up to get the book finished. It’s the main thing I’m working on right now. I just checked the PDF and it’s 77 pages so far. So it is real and it will be out before too long.

Your writing spans a pretty huge range of topics – not just technical (like this post from your website on the London Cycle Hire scheme). Where do you find your inspiration from?

I would love to say something motivational and high-minded here, but the truth is that my writing is mostly born of frustration. I am very excited about the possibilities presented by general-purpose computation, and that excitement turns to frustration when those possibilities go unrealised because of bad education or lazy design or whatever it is.

So much of what is wonderful and beautiful about the computable world is hidden under a thick layer of inane jargon, poor documentation, crummy explanations, arrogant behaviour, confusing interfaces and so on, and I feel compelled to try to dismantle those things whenever I see them. Often that amounts to just unproductive complaining, but sometimes it motivates me to try to build a really clear explanation of a particular idea, or at least a really clear illustration of why some existing thing is bad. That’s actually still just complaining but I invest some effort in dressing it up as something superficially more constructive.

Explaining things clearly, whether through human language or computer code or interaction design, is really difficult to do, but that’s what makes it important and worthwhile. I think that you can change someone’s life in a tiny way if you help them to understand something fundamental about the universe, so it’s worth putting a bit of effort into. In practice the main thing I’ve learned is that this is a terrible way to try to make a living.

Were you always going to be a developer? What do you think you’d be doing if you weren’t?

I was fortunate enough to have access to easily-programmable computers from a very young age, so yes, I’ve been programming for as long as I can remember, and it’s hard to imagine doing anything else for a living. I suppose that latterly I’ve been spending more time explaining things to humans than to computers, so under different circumstances maybe I’d have become a teacher. I am a huge fan of mathematics so it’s likely I’d have ended up as a maths teacher, if not an actual mathematician, if computers hadn’t existed. It’s a frightening thought.

Finally, and back to CukeUp; what are you looking forward to most at this years conference?

Well, obviously my bit is probably going to be amazing, but social convention dictates that I pick something else. Actually I’m really looking forward to the workshops, because workshops (more so than talks) are often an opportunity to really learn something new — to be that person who’s having their life changed in a tiny way. So I’m hoping to be shown different ways of thinking about Cucumber and BDD, and to get the chance to ask some awkward questions, and to find something new and interesting to complain about.


While It’s Compiling is a continuing series of interviews with experts across a range of bleeding-edge technologies and practices, exclusive to Skills Matter. Be sure to subscribe to this blog for future interviews, or follow us on Twitter.

Find out who we’ll be interviewing next, and get a chance to put your questions forward with the hashtag #whileitscompiling.

FullStack 2015: Call for Papers

FullStack 2015

Our second edition of FullStack – the conference for JavaScript, Node & IoT developers – returns June 25th-27th. The conference is independently organised for and by the community.

Following the tremendous response to our Call For Thoughts, and with support from Cian O’Maidin (nearForm), Rob Moran (ARM), Robert Rees (Guardian), Sarah Clarke (Google) and members of our JavaScript, Node & Angular community, we have been able to identify some key themes for this year’s conference:

  • ES6 and io.js
  • App Architectures for Performance, Maintainability, etc.
  • Software rendering
  • Virtual DOM (e.g. React)
  • NodeJS and associated technologies
  • Implementation stories and soft skills
  • Dev Ops/NoOps
  • Microservices
  • AngularJS 2.0 and related topics
  • Hardware
  • Internet of Things

To submit your proposal, head over to the Call for Papers page. We’re especially keen to hear from people who haven’t spoken at the conference before. If you’re worried about presenting alone, feel free to pair with someone on your team. The community is very friendly and this is a safe way to dip your toes in the public speaking arena. If you need some help a great place to start it here.

If you have any questions then please contact us at info@skillsmatter.com.

The CfP will close on March 20th. All presenters will be contacted the week commencing April 6th. 

Please be sure to read the Skills Matter Code of Conduct. It outlines what we expect from our speakers and guests so that we can continue to provide a fantastic environment to learn and share skills for everyone.

Unit Testing Lambda Expressions & Streams

Richard Warburton

This is a guest post from Richard Warburton, who has worked as a developer across varied areas including Statistical Analytics, Static Analysis, Compilers and Networking. He is a leader in the London Java Community and runs OpenJDK Hackdays.

Richard also teaches a course on modern development with Java 8 at Skills Matter, alongside Jim Gough & Raoul-Gabriel Urma. At the end of this course, you will be ready to use Java 8 on your day job and be familiar with the cutting edge programming approaches which allow you to write more flexible and concise code. You can find out more information about the course here, or head to the Skills Matter page to book your place now!


Usually, when writing a unit test you call a method in your test code that gets called in your application. Given some inputs and possibly test doubles, you call these methods to test a certain behavior happening and then specify the changes you expect to result from this behavior.

Lambda expressions pose a slightly different challenge when unit testing code. Because they don’t have a name, it’s impossible to directly call them in your test code. You could choose to copy the body of the lambda expression into your test and then test that copy, but this approach has the unfortunate side effect of not actually testing the behavior of your implementation. If you change the implementation code, your test will still pass even though the implementation is performing a different task.

There are two viable solutions to this problem. The first is to view the lambda expression as a block of code within its surrounding method. If you take this approach, you should be testing the behavior of the surrounding method, not the lambda expression itself.

Here’s an example method for converting a list of strings into their uppercase equivalents.

public static List allToUpperCase(List words) {
    return words.stream()
                .map(string -> string.toUpperCase())
                .collect(Collectors.toList());
}

The only thing that the lambda expression in this body of code does is directly call a core Java method. It’s really not worth the effort of testing this lambda expression as an independent unit of code at all, since the behavior is so simple.

If I were to unit test this code, I would focus on the behavior of the method. For example, here is a test that if there are multiple words in the stream, they are all converted to their uppercase equivalents.

@Test
public void multipleWordsToUppercase() {
    List input = Arrays.asList("a", "b", "hello");
    List result = allToUpperCase(input);
    assertEquals(asList("A", "B", "HELLO"), result);
}

Sometimes you want to use a lambda expression that exhibits complex functionality. Perhaps it has a number of corner cases or a role involving calculating a highly important function in your domain. You really want to test for behavior specific to that body of code, but it’s in a lambda expression and you’ve got no way of referencing it.

As an example problem, let’s look at a method that is slightly more complex than converting a list of strings to uppercase. Instead, we’ll be converting the first character of a string to uppercase and leaving the rest as is. If we were to write this using streams and lambda expressions, we might write something like the following.

public static List uppercaseFirstChar(List words) {
    return words.stream()
                .map(value -> {
                    char firstChar = value.charAt(0);
    firstChar = toUpperCase(firstChar);
                    return firstChar + value.substring(1);
                })
                .collect(Collectors.toList());
}

Should we want to test this, we’d need to fire in a list and test the output for every single
example we wanted to test. The test below provides an example of how cumbersome this
approach becomes. Don’t worry—there is a solution!

@Test
public void twoLetterStringConvertedToUppercaseLambdas() {
    List input = Arrays.asList("ab");
    List result = uppercaseFirstChar(input);
    assertEquals(Arrays.asList("Ab"), result);
}

Don’t use a lambda expression! I know that might appear to be strange advice in an article about lambda expressions, but square pegs don’t fit into round holes very well. Having accepted this, we’re bound to ask how we can still unit test our code and have the benefit of lambda-enabled libraries.

Do use method references. Any method that would have been written as a lambda expression can also be written as a normal method and then directly referenced elsewhere in code using method references. In the code below I’ve refactored out the lambda expression into its own method. This is then used by the main method, which deals with converting the list of strings.

public static List uppercaseFirstChar(List words) {
    return words.stream()
                .map(Testing::firstToUppercase)
                .collect(Collectors.toList());
}

public static String firstToUppercase(String value) {
    char firstChar = value.charAt(0);
    firstChar = toUpperCase(firstChar);
    return firstChar + value.substring(1);
}

Having extracted the method that actually performs string processing, we can cover all the corner cases by testing that method on its own. The same test case in its new, simplified form is shown here:

@Test
public void twoLetterStringConvertedToUppercase() {
    String input = "ab";
    String result = firstToUppercase(input);
    assertEquals("Ab", result);
}

The key takeaway here is that if you want to unit test a lambda expression of serious complexity, extract it to a regular method first. You can then use method references to treat it like a first-class function.


There’s a buzz in the air… or is it on your arm?

Can you feel it yet?

Apple Watch

This is a guest post by Boisy Pitre, Mobile Visionary and lead iOS developer at Affectiva. You can find him on Twitter here, and see his previous guest posts here.


It is the imminent release of Apple’s latest gadget-wonder… the long awaited Apple Watch. Announced last year, the wearable device is due to hit stores in a few months; its launch, sale price, and subsequent success or failure is the basis for immense speculation in and around the techno news websites and journals.

Last Fall’s announcement of the eagerly anticipated watch was true to Apple’s style of introducing something new: bold yet gentle, glamorous yet modest, confident yet demure. Touted as something truly personal to the wearer, the Apple Watch wooed and wowed the event’s audience and the wider general public. It was easy to see that this wasn’t just another technology device trying to act like a watch, but perhaps the very redefinition of the watch itself.

Predictably, it didn’t take long after the announcement for the questions to follow. How briskly will it sell? Who will buy it? And who wears a watch anymore?

What’s Old is New Again

The concept of wearable devices isn’t necessarily new; it’s been around for some time and has existed in various incarnations. Thinking back 15 years ago, I can distinctly remember attending PalmSource (yes, I’m talking about the Palm Pilot for those of you who can remember) in 2000, and witnessing an attendee walking around the show floor with Palm devices strapped to his forearms. It was reminiscent of Locutus of Borg in an episode of Star Trek: The Next Generation.

Thankfully, we’ve come a bit farther in style today. From arm bands with iPods to smartwatches like the Pebble and offerings from Samsung, you don’t have to look like a cyborg to have technology up close and personal to your body. And all indications are that with its myriad of colors, band styles, and body types, the Apple Watch will be as much of a fashion statement as a technology wearable.

Of course, as developers we are the spark and fuel that moves the pistons of Apple’s engines. Seeking new opportunities and pathways for our work is a constant motivation. So what does the Apple Watch mean for the developer?

A Totally New Platform

Just like the iPhone spurred the creation of the amazing “app economy” in 2008 with the release of the native iPhone SDK, the debut of the Apple Watch brings a whole new set of creative potential to the table. Although it has some utility on its own as a timepiece, where the Apple Watch really shines is its integration with the iPhone itself. The Apple Watch is really complete when it can pair up with an iPhone. The iPhone acts as a deliverer of both content and apps to the watch via Bluetooth. In essence, your Apple Watch becomes an extensible and conveniently accessible accessory to your iPhone.

This means if you have an iOS app already written, you can extend it to bring its functionality to the Apple Watch (assuming that there is some aspect of your app that makes sense appearing on someone’s wrist). Your iPhone is the “carrier” of the smarts that your Apple Watch will use; and in doing so, you have whole new ways to extend the usefulness of your iOS apps.

Think Different

A watch is not a phone, and a phone is not a watch. We carry our phones in our pockets and on our hips, but our watches adorn our wrists. As something that you will wear on your arm, the Apple Watch becomes a very convenient, immediate, and intimate place to view and interact with data. It opens up a whole new world of ideas for apps.

Not only is the Apple Watch as a platform more physically accessible, but its screen is considerably smaller in size than any previous iOS device. Given that the largest Apple Watch is 42mm tall (the other option is an even smaller 38mm in height), you have to carefully think about your app idea, and how it will “fit” onto such a targeted space.

The smaller design space of the Apple Watch, along with the intimacy and complete accessibility that it offers, is certain to inspire creative app extensions. It’s going to be interesting to see where developers will lay stake in this brave new world.

And It Will Get Better

Like all technology, the Apple Watch is bound to get “smarter” over subsequent revisions and generations. The perceived limitation of its tethering to the iPhone will become less and less pronounced, eventually to the point where Apple Watch may become a truly stand-alone, Dick Tracy type futuristic device. Think full audio and video interaction… a complete communications experience right on your wrist.

Challenges certainly remain to get there. Increased processing horsepower and capacity required to drive more features will require more battery life, and that will challenge Apple in interesting ways. There’s not a lot of room to put larger and larger batteries on your wrist.

Are You Ready?

Wearables are about to get a lot more popular, and the apps that will empower them are going to be more and more in demand. If you’re an iOS developer with an existing app, I encourage you to look at how your app might be able to augment your user’s experience on their wrist with their Apple Watch. Not all apps may be able to find that crossover, but many will, and with it will come the opportunity for you to become more familiar and close to your users.


Swift London Are you interested in iOS development? Swift London is a group for iOS and OS X developers of all abilities who want to learn how to use it, who meet regularly at Skills Matter. You can join them for their next meetup on Tuesday 17 February – full details here.

The organisers of the Swift London Meetup group have also put together an impressive line-up for a two-day Swift Summit which is taking place in London on 21 & 22 March. The programme includes speakers such as Chris Eidhof, Daniel Steinberg & Ayaka Nonaka. See the full agenda here.

While It’s Compiling: Skills Matter Interviews Arti Mathanda

CukeUp!

CukeUp! 2015, the conference all about BDD, is coming to London next month on the 26th and 27th March! There’ll be talks and workshops by Behaviour Driven Development experts and the inspiring Rachel Davies and Dan North will be our keynote speakers. In preparation for this fantastic event, we’ve picked the brains of Arti Mathanda, the event’s programme lead, to find out more. Check out the full programme here.


Arti, you were invited to join the CukeUp! 2015 organising team by Matt Wynne, lead developer at Cucumber Pro. Can you tell us how this came about and what points of difference you hope to add to this year’s programme?

I’ve known Matt for several years now. Last year we caught up again at Sandi Metz’s course and we started to talk about how one of the CukeUps that I had attended was very code focussed and he asked if I would help out with this years conference. I said yes! I was hoping to help make CukeUp more business focussed and also to help increase visibility for minority speakers.

What topics will you be exploring in the workshop you’re delivering at the conference this year?

My colleague Adam and I will be talking about how we use Hypotheses and Measures and how to use them to prioritise your work.

What initially attracted you to working with BDD?

It just seems like the right thing to do. BDD done right helps you figure out why you’re doing the work you’re doing and if it actually makes sense to spend time and resources doing it.

What questions would you most like to ask the community about at CukeUp!?

What are some of the topics you’d like to hear about at the next CukeUp? What are your favourite talks/workshops from this year. Most importantly – did you have fun!

What themes are you most looking interested in hearing about at the conference?

I want to hear about product owners and business stakeholders using BDD – rather than just the tech teams.

As is often the case at tech events, less than half the speakers at CukeUp! are female. What do you think holds women back on the tech scene? Is this changing?

There’s a multitude of reasons why women hold back on the tech scene. One of them is as innocuous as people organising conferences tend to ask people they know to speak at them – and since tech is typically a white male dominated industry, that usually leads to mostly white men being asked to speak. We made a concerted effort to reach out to the women we knew in the industry, whose work we admired. We have a pretty good number of women speaking at this year’s CukeUp including the keynote speakers on Day 1. There’s still work to be done, but we’re heading in the right direction. We also made sure there was a good Code of Conduct and resources for people who were scared of public speaking.

Read more about CukeUp! 2015 and see the full line-up here


While It’s Compiling is a continuing series of interviews with experts across a range of bleeding-edge technologies and practices, exclusive to Skills Matter. Be sure to subscribe to this blog for future interviews, or follow us on Twitter.