This Week at Skills Matter: 26 – 29 August

The Open Tech School

The Open Tech School

As you read this we assume you’re asking the same question as us – can this really be the end of summer? But don’t be gloomy (even if this was the chilliest August Bank Holiday ever recorded), we’ve got six fantastic meetups this week, from Londroid looking at moving your app interface beyond 2D to an introduction to web programming with the Open Tech School. Check them all out below!


The London Android User Group join us for another fully booked talk this evening, as they discuss Holo to Material Design. This is an open discussion around one question – what if an interface wasn’t just 2D? If app developers take advantage of virtual light sources, realtime shadows and put an emphasis on clean typographic layouts with rich animated touch feedback, can they transition their beloved Holo? And if so, should they? And when!?

In anticipation of the talk, you’re also invited to share your own examples and apps using #materialdesign. Find out more and see the full agenda on the group’s page.

Also joining us tonight, the Open Tech School return for the second part of their introduction to web programming using Javascript. Be sure to bring a laptop!


The Neo4j User Group bring along speaker Rik Van Bruggen – regional territory manager for Neo Technology for the BeNeLux, UK, and Nordics – for a talk on importing data into Neo4j. With examples, strategies and live demos Rik will demonstrate the advantage of using a graph database to represent complex relationships between pieces of data directly, covering the various aspects of the data import process for Neo4j and present the existing procedures and tools.


Get hands-on with FParsec on Thursday as Phil Trelford and the F#unctional Londoners, as they introduce parsing domain-specific and general purpose languages using FParsec. Along the way you’ll cover creating a simple Abstract Syntax Tree (AST) with discriminated unions, and interpreting or compiling the language using pattern matching.

Go back to basics for WebGL Workshop London’s talk on WebGL, Three.js and Babylon.js. This month they finish the rotating dice in raw WebGL, then do the same in Three.js and Babylon.js for comparison. This is the second part of this talk, the first of which you can watch here.

Finishing off the week the London Java Community bring us their Java 8 Roadshow. Join speakers Tori Wieldt, Raoul-Gabriel Urma and Richard Warburton as they take you through the great new features on Java 8!

A Look at Swift: Strings and Things


This is a guest post by Boisy Pitre, Mobile Visionary and lead iOS developer at Affectiva. Here he talks to us about string manipulation and interpolation, the simplicity of Swift and the power of Apple’s compilers – and how with Swift, less is more.

This is a follow-up post to Boisy’s While It’s Compiling interview from iOSCon 2014, which you can read here.

One of the very cool things about Swift is probably the most mundane: string manipulation and interpolation. The fact that as a developer, we can juggle using strings as naturally as numeric types is a huge deal. In this article, I’ll show you just why this is important, and how it can be not only a time saver, but a bug saver too.

Back In My Day…

Us “old timers” love to start out telling stories with that phrase. In this case, “back in my day” is not that long ago when we were (and still are in most cases) using Objective-C as our primary development language. Objective-C inherits a lot from C, and one of the things it tried to improve on was strings. If you’ve ever worked with C, you’ll remember the obtuse functions we had to use just to concatenate two strings:

char s[255];
strcpy(s, "This is a string. ");
char *p = strcat(s, "And this is another!");

No kidding. If this is foreign to you, then be thankful. Such code is fraught with potential security issues, not to mention the real possibility of outright crashes. Granted, functions like strncat and strncpy came along to limit the security risk by enforcing a maximum number of bytes to copy, but still remained unwieldy to use and slightly unnatural in appearance.

Objective-C did its best to make things better. Here’s the C code above, rewritten in the simplest Objective-C style:

NSString *s = @"This is a string. ";
NSString *p = [NSString stringWithFormat:@"%@ And this is another!", s];

… still not elegant, but fairly descriptive, and safe from the dangers of accessing memory in a more direct fashion in C. And by God, we loved it. And still do.


Swift’s Response

If you think the above code is easy to understand, then you’ve probably seen it one thousand times over. If you think it’s way too complicated, then you’re probably right in line with the new crop of developers who have cut their teeth on scripting languages like Ruby and Python. No matter which camp you’re in, you have to appreciate the simplicity of this:

let s = "This is a string. "
let p = s + " And this is another!"

Come on. This is just too easy, isn’t it? That’s all it takes to add two strings in Swift. I have to tell you, when you come from the old way, it almost feels like cheating. Deep down, you don’t trust the compiler and think all of this pretty, sugary stuff is eating up tons of CPU cycles. Where are the good old “bare metal” programming days going to?

You can relax, because Apple’s compiler wizards have worked hard to optimize these statements under the covers. Just bask in the enjoyment of all that typing you’re going to save.

Format Specifiers… Ugh!

Another win that we get in Swift is with the printing of constants or variables. How many times in your code do you do this? A lot. And it’s a lot of typing… and tedious to boot. Here’s a simple contrived example:

int x = 42;
char *s = "life";
printf("The answer to %s is %d!\n", s, x);

Now multiply that times one hundred lines!

This has been the bane of C and Objective-C for a long time. Keeping track of what format specifiers to use for what types is a pain, but what’s even more of a pain is if you have a ton of them in one printf statement, and forget a couple, or worse, transpose the variables so that the types don’t match. Compilers got smarter over time and warned you of such transgressions, but what a time killer nonetheless.

C++ tried to get it right, and did a decent job, but it still didn’t have that “natural” syntax flavor:

cout << "The answer to " << s << " is " << x << "!\n";

Nice try, C++, but Swift cuts through this problem like a hot knife in butter:

let x = 42
let s = "life"
println("The answer to \(s) is \(x)!")

You may have to get used to typing a backslash followed by open and closing parentheses around your variable names, but this is clear and concise and has minimal chance of collision with your string characters.

Less is More

Strings are just one of many things that Apple has really made fun and easy to use in Swift. The theme of the language certainly seems to be “less is more.” Less typing and gaining more functionality. After all, computer languages are about us humans expressing ourselves more naturally in our work so that things can get done quicker.

If you haven’t started learning Swift yet, you should. If you have started, hold on to your bucket seats, because it’s going to be a wild but great ride!

FullStack, the Node and JavaScript Conference: Call for Papers


The Call for Papers (CfP) is now open for the FullStack Conference.

We are excited to present FullStack, a brand-new conference in the JavaScript and Node space. The conference will feature three main tracks; NodeJS, JavaScript, and Hackable Electronics.

As with our other conferences, we aim to have between 25-50% of talks targeting newcomers. Contiguous to these sessions, we are also looking for talks on:

  • Web Audio
  • WebRTC
  • Internet of Things
  • Work/project experiences using JavaScript or Node
  • AngularJS 2

If you work on a library/framework we also invite you to bring a demo. If you are working on or know of some exciting hardware, we would also love to have it as part of our hackable electronics space.

But don’t let this list limit your imagination! If you have anything that odd and quirky that you think will keep us all amused and make the crowd smile, then head through to the CfP using the link below to submit your ideas!  All talks should be around 45 minutes (aim to talk for 35 to 40 minutes and 5 to 10 minutes for questions). The selection will be made by the programme committee on the basis of making this as varied and interesting an event as possible. All speakers will receive a complimentary ticket to the conference.

If any of the above sounds like you then head across to the CfP submission page now! If you have any questions, please contact

The CfP will close on Sunday 14th September, and successful presenters will be contacted the week commencing September 21st.

While It’s Compiling: Skills Matter interviews Brian Sletten

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.


Brian Sletten is a software engineer with a focus on forward-leaning technologies. His experience has spanned many industries including retail, banking, online games, defense, finance, hospitality and health care. He focuses on web architecture, resource-oriented computing, social networking, the Semantic Web, data science, 3D graphics, visualization, scalable systems, security consulting and other technologies of the late 20th and early 21st Centuries.

We caught up with Brain ahead of his REST and Resource-Oriented Architecture Bootcamp, which will take place at Skills Matter on the 29th September in London.

A lot of people ‘do’ REST and see the power of semantic web, but don’t necessarily see an intrinsic link. How do think they are connected?

This is a common oversight and I think it largely stems from the fact that people think of REST in terms of services because it was always couched in opposition to SOAP. In reality, the resource abstraction is a superset that allows us to uniquely identify documents, data, services and concepts. In this sense, ‘doing’ REST is really just extending the patterns and concepts from the Web of Documents into a Web of Data via a familiar set of architectural constraints.

Incidentally, the exact same ideas will extend to the Web of Things as well. It’s all just The Web. The confusion about the Semantic Web is generally that people think it is something other than an enriched form of the Web we already have. They think it is something we are waiting for. If you re-read Tim Berners-Lee’s original proposal, you will see that the notion of conceptual things (authors, topics, etc.) were very much part of the plan for solving information management and exchange within a single organization. We just zeroed in on the presentation part of the plan.

A major benefit of the Web is letting people request information in the way that they want to. The existence of RDF doesn’t have to mean we stop using JSON, XML or HTML. It comes down to what kind of developer experience you want for your API, where you want to spend your integration effort (or force your clients to) and how you plan for a future that you may not control. These aren’t incompatible ideas and we understand how to adopt them incrementally and in defensible ways. There is absolutely nothing Ivory Tower here; these technologies are grounded in a very pragmatic reality.

So often with software change, it comes down to how well people adapt. How can engineering teams begin to apply Resource Oriented Architecture (ROA)?

It’s aggravating when I see organizations try to mandate top-down standardization of service infrastructure, even if it involves a move toward REST. They will never get an effort like that right no matter how earnest or heavy-handed they are. The Web did not grow in a top-down fashion, nor could it. It was an organic process that grew around standards. The trick to adopting these ideas is just to adopt them incrementally. There is obviously more to it than that, but once you get a clear picture of how to think about resource abstractions it is easy to identify a single piece of information to expose in this way.

In subsequent iterations or releases, you can pick more. As the organization starts to internalize successful resource-abstractions and APIs, it can begin to parallelize the effort and to identify useful tools and approaches to share between teams. If done properly, you will accumulate a series of reusable resources that have lifetimes well beyond what you originally conceived.

Different teams can pick different implementation technologies, but that is a feature, not a bug. You don’t have to go all-in on a single technology stack. You can allow a competition of ideas to occur behind-the-scenes without significant impact to the organization. That same freedom allows you to adopt new technologies without impacting existing systems. Letting things grow organically doesn’t mean initiating chaos.

Having resources work consistently is part of the plan because that is what the Web is. Your browser does not need to read API documentation to interact with a new site it has never seen. The goal is to produce resources with a Uniform Interface, no matter what they are. Don’t overthink the adoption process, just don’t underthink it either.

Brian Sletten

If there was a simple way to get to the crux of ROA and it’s capabilities, what would it be?

Fundamentally, one of the main problems with large scale, distributed systems is that consensus is pretty much impossible. It’s great when you can achieve it, but that tends to be in smaller communities of interest, teams and co-located business functions. Beyond that, it can be a Fool’s Errand. This is true in terms of world view, technology selection and service and system lifecycles. Any technology or initiative that assumes or requires consensus is unlikely to succeed.

The fallacy of large initiatives like Enterprise Data Warehouses is that there is a single view of information within an organization. Different people have different needs of information in different contexts. This is why so many people ETL (extract, transform and load) data. Absent agreement, they simply copy the data and frame it how they want for their needs.

This of course yields new problems of data consistency. Even powerful technical solutions like Big Data don’t ultimately solve the problem of consensus. What we need is an infrastructure that allows us to agree to disagree. REST alone does not solve this problem, but it goes a long way toward allowing interoperable systems that don’t leak implementation details and choices. It gets organizations to think in terms of resources, allows for content negotiation, independent system life-cycles and technical evolution. In this context, applying the standards associated with the Semantic Web allows us to exchange information with people we have never spoken with. It affords us the ability to achieve collaboration without coordination. This is a ludicrous concept to people who have attempted large-scale data integration in the past, but it is possible because of a few simple building blocks that solve fundamental problems.

People are among technology’s biggest problems, but we can also apply technology to solve the problem of people.

At the heart of semantic web is the aim to standardise data into a digestible form, or rather a ‘web of data’. Could you give an applied enterprise example of how this has worked?

To some extent, these ideas are as widely applicable as the Web has proven itself to be (if not more so!). I have worked with all manner of organizations (big, small, commercial, non-profit) in adopting these technologies. Closed systems that have the freedom to mandate structure can certainly be built without these approaches, but they will never be able to exchange information with the rest of the world as freely and easily as they might need to.

As I have said above, achieving consensus remains the biggest obstacle in most data integration initiatives. Even if you are able to extend your closed system to adopt a single new content source, that approach is not one that scales efficiently or cost-effectively. I have had success at applying these ideas by allowing data integration to occur that would have been too expensive to even consider under normal technical frameworks.

One customer was an organization that sold hundreds of thousands of products. They had their own way of thinking about and describing their products but they needed updates from vendors as new offerings become available. They didn’t have a large internal database of product ratings and reviews so they subscribed to this information from third parties. There were additional data sources that tracked things like parental guidance on product suitability, related accessories, suitable product replacements for out-of-date inventory, etc.

Imagine trying to manage all of that in a world that changes constantly including new category-busting products like the iPad and you’ll get a sense of the issues involved. Trying to standardize on a single world view encoded in a single schema or object model would simply not work. But, a relatively small team was able to adopt resource-oriented thinking and Semantic Web-oriented standards to allow it all to connect with minimal effort.

It suddenly became possible to query the customer’s data, sorted by rating and targeting certain kinds of customers. Information could be accepted from vendors and partners in the forms they currently used with only a minimal mapping effort to make it accessible to the standards we were using. Re-categorizing products took a matter of minutes or hours, not days, weeks or months. In addition to lowering the cost of integration, this allowed us to explore long-tail products in different contexts in ways that impacted the bottom line.

How can adopting resource-oriented technologies minimise business<>technical tensions?

Reducing this tension is one of the main consequences of using these technologies. Business should be in charge, not technology. The people who understand markets and customers and opportunities and threats should be able to imagine initiatives and run with them, not be limited by what the technology currently allows. Relational database systems are fantastic tools for processing information that we understand, but they are terrible for modeling the unexpected.

XML documents are great for having a validating structure of agreed upon syntax, but are less useful for content we’ve never come across before. JSON is a suitable tool for developer-friendly exchanges of data, but integrating across data sources requires custom development. Big Data systems are great for dealing with volumes of data that have previously been untenable, but at some point we cannot put everything into a single container.

Software deployment has gotten much easier, cheaper and safer with the adoption of testing, continuous delivery, dev ops, etc. but sometimes that still isn’t the right solution for a problem of perspective. How can we look at things differently? What happens if we allow this new information into our system?

The resource-oriented abstraction allows us to think about our worlds independent of how we choose to build systems to store information about them. Technical change is business cost. If adopting a new world view or allowing new information into the system has a high cost attached to it, businesses will simply not be able to justify the cost of implementation. We are stuck in the world of what technology makes easy or even possible.

Resource-oriented technologies do not eliminate these existing systems or the value they provide. They simply allow us to operate at a level above them and provide integration opportunities that shield clients from unnecessary details and drive down the costs of integration. This rebalances the relationship between business and technology by allowing cheaper experiments and longer life-cycles for what we have already produced. This isn’t some kind of techno-utopian fantasy. It is possible to adopt these ideas today, incrementally and driven by business value and priorities.

Brian Sletten’s REST and Resource-Oriented Architecture Bootcamp

Brian will be running a three day course at Skills Matter from Monday 29th September, which will provide a broad, example-driven and compelling vision of computing’s future.

While learning how the technical and business value of Web semantics is available and useful today behind firewalls and on the public Web, the course will also help you understand how tensions between the business and technical sides of the house can be mediated by adopting resource-oriented technologies. These provide information-focused, business-friendly solutions that grow with the organisation and its changing business needs.

You can find out more about this course here. If you are interested in attending, or have more questions, you can contact a member of our team on +44 (0)20 7183 9040 or email

This Week at Skills Matter: 18 – 22 August

Lightning Talks at Skills Matter

Lightning talks are the theme of the week here at Skills Matter with Swift London, Cassandra London, the London Software Craftmanship Community and Women Who Code all featuring them.

For those not familiar with the concept, lightning talks are short presentations ranging from just a few minutes to around ten minutes long, designed to bring you as much information in as short a time as possible. But don’t worry about the speed, if something piques your interest we still have plenty of time after the meetup to continue the conversations and to ask those burning questions!

Never miss a future meetup – follow us on Twitter now!


Kicking off the week, Swift London return for their second meetup with guest speakers Al Skipp and Johannes Weiß, as well as a series of lightning talks. Johannes will present an introduction to Functional Programming, showing that understanding the strengths of FP and learning to think in a Functional way will be an increasingly valuable skill for all Swift developers. Al will continue the theme, showing us why Functional Programming is handy for any young Swift Developer.


Steve Smith joins us on Tuesday to talk about Release Testing & Risk Management. Exploring the topics from a Continuous Delivery perspective, Steve will discuss why Release Testing is an antipattern, and offer an alternative risk reduction strategy.

We’re also delighted to welcome back the OpenTechSchool who continue their introduction to web programming series with the first of a two-part introduction to Javascript. You will need to bring a laptop to work on the exercises!


Join Cassandra London for an evening of 6 lightning talks followed by a talk on testing with Cassandra by Christopher Batey. Christopher will talk about how to test your applications that use Cassandra, starting at the unit test level through to the black box acceptance tests. Most of the talk will be around a new framework, Stubbed Cassandra.

Git, the revision control and source code management system, is the focus for Benedicte Slee’s talk as she joins Women Who Code on Wednesday. Initially designed and developed by Linus Torvalds in 2005, Git has since become the most widely adopted version control system for software development. There will be a hands-on session after the talk, so be sure to bring a laptop!

Finally on Wednesday, the London Software Craftsmanship Community join us for their August Meetup. Timo Tuominen looks at application as data flow, exploring the problems and solutions encountered when building a reactive architecture in a large-scale Android project with the software agency Futurice. Antonio Terreno will then take us through the world of Microservices, sharing his experience at Forward Internet Group where he had the luck to witness the creation of one of the first microservices architectures.


Finally on Thursday, our last meetup of the week sees the London Java Community host Richard Warburton and Colin Vipurs for an evening looking at Lambda Behave & the common reasons Unit Tests are brittle.