It’s all about APIs – 22/01/14

On Wednesday, I went to a meetup hosted by IBM about APIs and I thought I should jot down a couple of notes. The meetup was extremely well organised by Laura. It’s the only meetup with an initial detailed Agenda, a reminder a couple of days after (just before the event), the slides posted on the day after the event as well as a summary of the evening writing up Laura’s thoughts on the meetup. (If you are looking for the slides from the evening, you can find them at the meetup group itself.)

The meetup itself was a mix of an initial broad brush introduction to various common concerns API developers share as well as a slightly deeper dive into a particular aspect (API security). The evening was very much a group discussion facilitated through the initial slides given by the presenters.

Some particularly interesting issues raised by the group & slides were:

  • SOAP/XML vs HTTP/REST/JSON
  • A conceptually clean rest API vs APIs optimised for particular data interactions (or even particular devices)
  • The move away from completely open APIs towards APIs more closely managed with partners
  • Versioning
  • Three legged oauth authentications

Most of the issues are described in a fair amount of detail in the slides with references to further sources so I won’t go into more detail here.

An interesting evening. Hopefully there will be an opportunity to dive deeper into some of these topics at future meetups!

Advertisements

Javascript on devices #2 – 21/01/14

On Tuesday, I went to my second JS on devices meetup. Like the first one, it was full of really useful information and cool tech. It also really showed off the ease of using javascript across a range of devices. Alex did a really great job organising this. It’s also nice to see companies (like Badoo in this case) hosting these kinds of events and enabling great discussions.

Enough of the fluff though. Now for the meat. There were three separate talks – about quite different devices.

Google glass

Radek started off the evening by talking about Google glass.

Interestingly, this was the least technical of the talks. A fair amount of it was focussed on introducing us – the audience – to the device and its capabilities. My guess is that this is because Google glass is in a sense the device most foreign to a tech audience. The user experience is clearly completely different to normal computers, mobile phones, other (sensor based) embedded devices. It also felt like the USB connection-based video feed to Google glass did not manage to fully convey the actual experience of using it. Radek had to work quite hard to bridge the gap to the actual experience!
I’d really love to take one of these for a spin, but at $1500 to join the developer community, it is quite steep and a big investment. Still, some of the things which he showed were extremely cool.

On the tech side, Radek briefly introduced two different ways of developing for Glass: A mirror rest API and the more traditional Glass SDK, GDK. The latter is a close sibling of the Android SDK, but still very much under active development with new releases happening every month.

Radek also had to spend some time justifying glass as a separate device (as opposed to, say, a mobile). His argument was that Google Glass solves the attention problem that many people struggle with. I.e. glasses notify you about important events without distracting you too much from your day to day activities. Working with Google Glass is not as disruptive as getting your phone out. Personally, I have to admit that I still have to be convinced, but – still – I would love to try one!

Run Javascript on Arduino – what, why and how

In the second talk, Alex spoke about how to run javascript on the Arduino. You can find his slides here. He first spent some time giving us some Arduino context which, as an Arduino noob, I found very helpful: He talked about things like the different types of Arduinos and the different extensions (“shields”) you can get for an Arduino. It made me very much want to get one – especially because I don’t know nearly enough about the hardware/circuit side of things and this would really force me to catch up with it.

In terms of running javascript on the Arduino (the title of the talk), the approach Alex presented was that of running a javascript wrapper library on a computer which allows you to abstract the actual hardware instructions. I believe the words “Johny five” and “Noduino” might be appropriate here!

The downside, of course, is that in this setup the Arduino needs to be connected to a computer. However, Alex pointed out that this means that you can leverage the computing power and other in-built facilities (e.g. wifi) from the machine.

Nodecopter

Finally, Andrew talked a little bit about Nodecopter. You can find his slides here. Nodecopter is a project which managed to run NodeJS on Parrot’s AR drone 2.0. This drone has got some pretty cool facilities: Front and bottom camera, 4 rotors, ultrasound sensors, 1ghz ARM cpu with 512mb of storage. It is also a flying router – it shows up as an unsecured hotspot.

Andrew showed some pretty awesome hacks for this drone:

  • Controlling the drone via a dance mat
  • Controlling the drone via a Kinect
  • Virus copter

He also talked a little about two different ways of operating the drone: one loading a node cross compiler on to the drone and then loading javascript files via ftp or USB stick so that these can be executed on the drone without needing to interact with the drone over its wifi network, the other of loading different javascript files on to the device and interacting with it that way.

Altogether a pretty awesome evening with exciting talks about three very different, but very cool devices!

London Agile Discussion Group – 07/01/14

On Tuesday, I went to my first meeting of the London Agile Discussion Group meetup.
The topic for the evening was: “What is the difference between an epic, theme, story & task?”

The format

Before going further into a discussion of the topic, let me just introduce the format of the evening:
Altogether, it’s a pretty informal setup. David, the organiser, initially introduced the topic. We then divided into smaller groups of varying agile experience to discuss the topic. Having noted down some thoughts, each smaller group then reported their thoughts back to the larger group. This worked quite well at setting off a discussion among the larger group between similarities and differences between the different groups.

Some thoughts on the discussion

It was interesting to see what kind of definitions people came up with from the various terms. In particular, it was pretty interesting to see how tools (a lot of people used JIRA for their work planning) and local practices colour your understanding. A lot of sentences in our smaller discussion group started with “you know how in JIRA you do X”.

It also underlined how diverse some of the practice is out there: Both in where Agile is used (we had somebody there using it to organise her work in a one person team and we had people using it for non-software-development work) as well as in the particulars of the process (some people don’t use tasks at all because stories/PBIs are small enough to achieve quickly and intra-progress tracking of PBIs is unnecessary).

Another thing I realised is that I need to delve a lot more deeply into the Agile literature: My knowledge is so far fairly piecemeal and based on articles I have read, discussions with colleagues and other developers outside of the organisation.
(I have now added some more Agile focussed books on to my reading list. This reading list is by now creaking under the heavy volume of books which are in it. My conscience is having trouble with all of the half started and not quite finished books that I have lying around.)

This became particularly obvious, when we discussed some textbook-like definitions such as the INVEST definition of PBIs and the SMART definition of tasks (here’s a good article on invest and smart. Here’s another one on the independent in invest).

Summary

Most of the definitions we settled on in the end were fairly conventional:
People felt there was a clear hierarchy between epics (too large to deliver in a single go, needs to be broken down into PBIs), stories/PBIs (adhering to invest, a unit of functionality that the business cares about) and tasks (smaller units, “implementation details” which the business at large may not care about).
Theme may have been the most contentious one. Some people felt it was a label to be applied to various parts of the hierarchy. A thought I particularly liked was that themes should correspond to particular business visions. This helps maintain the bigger picture when you work on a particular small task.

However, while the end result may have been conventional, it was the process and the diversity of experience in the room which were interesting to me. The discussion also revealed an area in which I personally need to invest more time to become more competent.

Javascript on Devices #1 – 17/12/13

On Tuesday was the first meetup of a new meetup group: It’s all about running javascript on devices (e.g. the raspberry pi). In the past this would have been quite an usual meetup. Traditionally, embedded devices have always relied on native code to squeeze the most out of the computing power available on the device. However, javascript definitely seems to be the cool kid on the block and its community has leaps and bounds of energy for innovation.

For a native developer with (a little more than a) passing interest in web development this kind of meetup is a big culture shock. The technologies and tools bear a passing resemblance to what I’m used to in my traditional (mainly desktop-)client-server world, but everything feels a little foreign. Maybe because of that it also feels fresher and more exciting – like they are really pushing the envelope. Definitely lots of new stuff to research and think about (for me)!

For guys who do a lot of work with javascript or are familiar with embedded devices, these introductory talks may have been a little basic, but for me they were perfect. There were two talks:

  • A talk about the internet of things by Vlad
  • A talk about pushing javascript on to embedded devices with a simple git-push by Alex

The internet of things

Vlad’s presentation was split into two parts. He first talked about how with devices we currently have more of an intranet of things and the potential of moving towards the internet of things. He then spoke a little about the setup of his startup and how its work helps in moving towards the internet of things.

The intranet of things was Vlad’s metaphor for describing the current state of proprietary networks, protocol, standards and APIs that are prevalent in the embedded devices community. He argued that a move towards a REST & HTTP-based internet of things would bring big benefits to embedded devices:

  • ability to transfer experience of web development
  • proven scalability
  • reduction in development cost (ease of use, ability to reuse code for similar problems)

Another benefit is of course the ability to enable different devices to communicate and interoperate with each other. In my mind, this is the key benefit because pooling enables the kind of collaboration where the sum is greater than the parts: It is the kind of thing that turns a nicer development environment into a true platform on which higher level applications can be built:

For example, one of the things that Vlad mentioned is that we won’t need to physically search for our shoes in the morning and instead we will Google them. However, what if we could rely on a preference-based algorithm to physically select our entire wardrobe in the morning (entailing collaboration between lots of different individual units of clothing)?

He also talked a little about what may be necessary for this move towards HTTP (ADIs etc.)

The second part of his talk was more focussed on his startup‘s work towards this. This work has been to write REST APIs for particular projects as well as providing an infrastructure around these APIs. Interactions with the devices are supported at various levels of sophistication (QR code; RFID tag; sensors or raspberry-pi-like machines).

One of the interesting points was that his main customers are big companies who are looking to protect their (and their client’s data). Therefore, the normal deployment option is as a private cloud. Unfortunately, data security, identity and sharing are of course key concerns, when establishing a platform as described above. Private cloud-like deployment may limit potential.

In my mind, the main benefit is therefore the reduction of development cost and enabling a wider community to offer services for companies within their private cloud.

Deploying (javascript) more easily on to embedded devices

Alex’s talk had three parts to it:

  • Rise of javascript as a language and rise of devices

    This part talked about all the bits that you might expect from a young development community brimming with self-confidence: Describing milestones in the development of the language as Alex sees it (from original invention to use in gmail, to “javascript the good parts” to node.js to phonegap to nodecopter), showing us benchmarks in javascript execution times through time etc.

    Alex also described the evolution of devices, how devices are getting much more powerful and how we are reaching the point where squeezing performance for every clock cycle is no longer as important.

  • Using javascript for displays on bins

    The second part of the talk then described how Alex and his team first got involved in embedded javascript development. This was with a project for displaying ads on bins. The team here worked mainly on displaying ad content to end users. As part of this, they had to solve several interesting problems such securely interacting with the machines, finding a way of remotely updating content as well as underlying software, dealing with network reliability issues etc.

  • Use the experience gained for resin.io startup

    In the final part of his presentation, Alex described how this experience led them to develop an infrastructure that makes it easy to deploy javascript to devices. The service was compared in type to heroku (which I hadn’t heard of before) which offer a similar service for web applications. (I.e. they offer the ability to deploy to a hosted environment with a simple git push). Alex also described the technology stack they put together for interfacing with devices.Unfortunately, I can remember only some small parts of the infrastructure – in particular: docker and openVPN.

Altogether I found Alex’s talk very interesting and informative – with lots of pointers in new directions where I’d like to learn more!

London C++ User-Group-Meeting – 13/12/2013

Last Thursday was my first time at London’s C++ UGM. This is a fairly small and young group. It looks like it has only just been going (maybe four or five meetups so far). Having said that, the topics are obviously very relevant to me (and everyone at work) so I’m going to try and cajole some more people into going. Also: I’m sick and tired of being dominated by a crowd of Java programmers or web/mobile guys wherever I go. C++ can do cool stuff too (yes – honestly it can!).

The talk itself was about a testing framework called Catch originally developed by Phil Nash. TDD seems to be very much a hot topic at the moment in software circles. A large part of the change towards TDD is cultural. This means discussions about changing behaviour, processes are quite important, buy-in from product owners etc.

HOWEVER, that is not to say that the technical side of it is unimportant and unit testing in C++ still feels a little awkward to me. So new ideas in a new testing framework are definitely welcome. (Though there is hardly a dearth of frameworks out there….)

And interesting and good ideas this framework definitely has. I’ll just quickly go through the ones I picked up during the talk in bullet points (I haven’t actually tried it yet, so can’t actually share my own experience):

  • It seems to be really lightweight and easy to get started. All it needs is an include of a single header and a #define in one file so that it generates the main for you.
  • I really like the way that test asserts work. Instead of the standard EXPECT_EQ(actual, expected) (<—- Google syntax) where you are never sure which one was actual and which one was expected, it uses style similar to normal asserts i.e. REQUIRE(add(3,1) == 4). I also like the output this produces when this test fails: There is some very clever template matching going on here to produce both the actual numerical values as well as the original line of code triggering the failure.
  • Instead of fixtures, it introduces sections. These are ways of splitting one test into several sub-sections, all of which will be run (and set up) independently. While it is quite heavy on macros, this gives the test case code a nice coherent feel.
  • It works particularly well when used in conjunction with the “given when then” framework for setting up your test cases. It looks like this makes it very easy to express the intention of a test case beyond just using the name of the test case. Since this is one of the biggest challenges in reading/interpreting tests, anything which helps here is particularly welcome!

Altogether some interesting stuff here. I’ll definitely give Catch a shot for some of my projects at home and will report back after.

London Software Craftsmanship Community Roundtable – 10/12/13

On Tuesday, I went to YALSCCRTE (yet another London Software Craftsmanship Community round table evening). I described the format in an earlier post so without further ado, the below are some notes on the evening.

Lightning talks

Tribal leadership
This was a talk (slides here) introducing us to some of the concepts behind a book (“Tribal Leadership”) which analyses group dynamics and relationships in teams and organisations. Based on the analysis, they seem to have arrived at CMMI-like (i.e. “it’s got stages”) framework for categorising team behaviour. Quite an interesting talk. This definitely fairly relevant to Agile software development and the principles they have about distributed responsibility. The book definitely made it on to my reading list – so I’ll give it a full review when I get round to reading it.

Three types of leadership
Seems like it was an evening to talk about leadership stuff. This talk was more about the types of leadership necessary in a software project. It postulated that there were three different kinds of leadership: technical architecture, project management and team leadership. The talk also went a little bit into different ways of organising this (individual vs distributed responsibility). This very much tied in with the talk about tribal leadership. (Maybe distributed responsibility leads to a greater sense of team engagement and collaboration?!)

A Benefit, Complexity and Danger approach to estimation
This talk was about enriching traditional estimation methods with measures of benefits, complexity and danger. It is described in a fair amount of detail here. This sounds like quite an interesting approach – especially to facilitate communication between product owners and developers. Ultimately, I think you would also still need to converge on an effort score because that is what the product owner ultimately cares about.

Advanced Infrastructure for Continuous Delivery
This was a talk about the importance of establishing feedback loops in your development effort and how important a continuous delivery system (builds, tests, deployments) is to such a feedback loop. It posed the question of why a remote team called “IT” might be in charge of that infrastructure and suggested that one might be able to use development methodology for dev teams to administer infrastructure themselves.

How do you deal with a horrendous codebase & resistance to change?
This talk posed the above question to the group and facilitated a little bit of a discussion on the topic. For me, personally, the single most helpful comment was “always leave the codebase a little bit cleaner than before you touched it”. This is such a true statement and should be our guiding principle in practice – no matter the current level of understanding or ability!

Two discussions
After these lightning talks, there were then two longer discussions:

  • Domain Driven Design – how to achieve it
  • Greenfield project – how to do it properly

I took part in the latter one. A large part of the discussion here was heavily influenced by the “Growing object oriented software, guided by tests” book I am currently reading. It’s all about BDD, walking skeletons and such things. I’ll dive a little bit deeper into this subject matter, when it comes to reviewing the book. One of the most helpful ideas during the discussion (which is not in the book) was the idea to write a “shitty prototype” to get familiar with the subject matter and entities and to then THROW THE PROTOTYPE AWAY and do it properly (as they said in the discussion, the important thing is the throwing away here…)

Summary

Altogether this evening felt a little bit less “shiny and new” than the last (first) one that I went to. Of course that is to be expected. I guess you just know the format, have met the people before etc.
Having said that, the discussions were still very interesting and very much worthwhile. It’s great to spend an evening sharing ideas in a fairly free-format way with lots of passionate devs.

Silent Pair Programming – Review

On Thursday evening, the London Software Craftsmanship Community organised a Halloween treat – a silent pair programming session – at the Google Campus. A colleague of mine and I decided that we talk too much during the day and so a silent programming challenge might be quite appropriate.

I had not been to the campus before, but it is a very interesting complex. It’s clearly made to be hip, yet minimalistic and function in style. The intended audience is very clearly geeks with lots of power sockets to plug your machines in as well as nice and fast Wifi. There was also the tell-tale smell of cheesy-Pizza-Goodness, which I thought was a little cliché.

Before the start of the session, Sandro talked a bit about Global Day of Code Retreat which sounded pretty awesome and I’ll definitely try to sign up for it:

A code retreat is a day that you spend solving a programming problem (traditionally Conway’s Game Of Life). The day is split into six sessions each lasting 45 minutes of pair programming in a TDD fashion. After each session, you delete all of the code you have written and swap pairs for the next session. There is also time for a quick retrospective between sessions to share experiences. Gradually, the facilitator may introduce additional constraints to the sessions. A good, more detailed description of the structure can be found here.

I think it’ll be really fascinating to see how good solutions will disseminate through the group with this kind of setup. It could also be extremely useful as a hands-on training/collaboration session for a group of developers to remind people of coding standards or introduce new concepts to the team.

Now – let’s talk about the session itself.

The format of the session itself was to program a particular problem together with another pair in a ping pong fashion. The problem Frankie proposed for the evening was the Harry Potter kata. Ping pong programming works as follows:

Dev A writes a test and passes the keyboard to dev B.
Dev B makes the test pass and writes a new test, passing the keyboard back to dev A.
Repeat until you can’t think of any more tests.

This is a fairly well established practice and is for example described in the apprenticeship patterns book I reviewed earlier.

The twist for the night was that it was supposed to be a silent ping pong session: This means no communication about the code – no talking, no cheating with notepad, no comments in the code, no scribbling or upfront design. (Communication about other things – the weather, coffee or the IDE are fine though.) The goal is for the code itself to be clear enough to enable the next person to continue on without any additional information. If the code is not clear enough, then you say “I’m very sorry, but I’m stuck and not sure what to do” and pass the keyboard back. After you have made the test pass, you are also allowed to refactor as much as necessary.

Every 25 minutes, we then had a quick retro to discuss how things were going.

For me, this was a very interesting evening and I think I learnt a lot about incremental code & test design. I also realised that some of the code I think is clear is really anything but. Ping pong programming also made TDD and pair programming feel extremely natural.