Category Archives: Uncategorized

Reflections on a workshop

At the start of last week, I ran an API Workshop for Brighton Java. It was a fun event, and people enjoyed it. But nothing is ever perfect, and I wanted to note some potential improvements.

The workshop had been designed as being freeform. As outlined in the previous post, I wanted to provide people a space where they could play with ideas. Everyone made some progress towards an idea, but future sessions could be much more engaging. The main changes to make are:

  • There need to be a series of wins at different levels. The first stage would be getting the basic example working, then perhaps amending that, and then converting the code for new functionality. Obviously, not all attendees will manage all of this, but everyone should come out of the workshop having achieved something.
  • While I had provided a working example and asked people to bring along a laptop and IDE, not everyone found it straightforward to get this example working . Java is never going to achiece the ‘write once, run everywhere‘ nirvana that Sun promised. Some people didn’t have a compatible JDK on their machine; others were more comfortable with Android and wanted to convert the example. One possibility is using VMs as a fallback, but that brings its own issues.
  • A workshop that was already potentially complicated had the additional challenge of picking an idea to work on. I should have prepared a set of possible examples, which people be inspired by, or even reproduce.

Running an effective workshop in a couple of hours is challenging, which is why good faciliators are in-demand and highly paid (and why it takes years of training to become a teacher). But I’m very excited about what I could achieve with some more preparation on the points above. It’s definitely a session I’d like to run again.

Fun with APIs

The next Brighton Java session is a workshop about building small applications by combining APIs (it’s September 23rd, details and signup on Meetup). I think everyone will able to produce something interesting in a couple of hours, despite Java’s reputation for being being heavyweight (although we might have to skip error handling and testing).

There is a good resource of public APIs on github. The workshop will involve picking two of these APIs and combining them (I’m old enough to remember this being referred to as a mashup). There are particularly interesting possibilities involving time and location, but as a practise example, I combined Kanye.REST‘s random Kanye quotes with cat pictures.

(There is an API endpoint returning random APIs, so I guess you could even produce a service to suggest mashups…)

I’m going to prepare a full worksheet for the event, but in the meantime, here are the simple steps I followed to produce a very simple API:

Set up basic project

I downloaded a Spring Boot guide application to use as a basis and imported this into intellij. This gaves me a build system with no need to mess around. When importing the project, I made sure to use external sources for the build tooling, which set all the libraries appropriately.

Add dependencies

The example I worked with used REST, so I added the Jersey libraries to gradle.

compile 'org.glassfish.jersey.containers:jersey-container-servlet:2.25.1'
compile group: 'org.json', name: 'json', version: '20190722'
compile 'org.glassfish.jersey.inject:jersey-hk2:2.28'
compile 'org.glassfish.jersey.media:jersey-media-json-jackson:2.22'

EDIT – 23/9 – Jersey is probably not the best library to use for REST APIs. Spring includes RestTemplate, which also has some great testing support in TestRestTemplate. However, it does not seem to have a user-agent set, which upsets a lot of servers. So I am going to use Jersey for this demonstration to make the code simpler, although I would use probably use RestTemplate if i was going into production. Thanks to David Pashley for raising and discussing this issue with me.

Add classes to manage responses

Next I made some classes to map the responses. This produces a coupling between the endpoint and the code. I’m not sure if there is a way to make this more flexible, but as this is a quick-and-dirty demo, it will do.

import com.fasterxml.jackson.annotation.JsonProperty;

public class Quote {
@JsonProperty("quote")
  public String quote;

  public Quote() { }
  public String getQuote() {
return quote;
}
}

Add the basic code

I then edited the HelloController class within the downloaded Spring Boot project, and wrote some quick code for downloading the APIs. This is a very long way from production quality, with no error management, but it does the job:

package hello;

import javax.ws.rs.core.MediaType;
import org.springframework.web.bind.annotation.RestController;
import org.springframework.web.bind.annotation.RequestMapping;
import javax.ws.rs.client.Client;
import javax.ws.rs.client.ClientBuilder;
import javax.ws.rs.client.WebTarget;

@RestController
public class HelloController {
@RequestMapping("/")
public String index() {
String responseString;
String location = "";
try {
Client client = ClientBuilder.newClient();
WebTarget target2 = client.target("https://api.kanye.rest");
Quote response2 = target2.request(MediaType.APPLICATION_JSON_TYPE).get(Quote.class);
responseString = response2.getQuote();
WebTarget target = client.target("https://aws.random.cat/meow");
CatPic response1 = target.request(MediaType.APPLICATION_JSON_TYPE).get(CatPic.class);
location = response1.getLocation();
} catch (Throwable t) {
return t.getMessage();
}
return "<h1>" + responseString + "</h1><img src=\"" + location + "\"/>";
}
}

At this point the code can be executed from the command line with the command ‘gradle bootRun’.

Some other useful resources

speaking at Brighton Lean Agile on 9th jan 2019

Due to a last-minute drop-out, I’m speaking at Brighton Lean Agile on January 9th. The title of the talk is “We’re agile, but…” and looks at some of the ways I’ve seen agile going astray in implementations.

Despite the simplicity and popularity of Agile, it often goes wrong in practise. Drawing on 15 years’ experience of Agile as developer and PM, James Burt will lead a discussion on why agile sometimes fails, and what can be done about it.

The session is currently full but there is a waiting list, as people sometimes drop out as the event approaches. Refreshments are provided by the sponsor, Bright Interactive.

The LJC Open Conference

Amazing views at LJC
The view from the main room

I followed up my two days at µCon with the LJC Open Conference. The third early start in a row was made a little more difficult by a late night – I gave a talk in Eastbourne the night before – but the sessions kept me alert. Rather than µCon’s deep focus on one area, the Openconf was an opportunity to learn about many different things, with introductions to Spock and Cassandra, as well as a good discussion about Akka, actors and other methods of distributed computing.

I don’t have a use for Cassandra yet, but it was good to learn more. In his talk, Chris Batey made an interesting point that abstracting out underlying data storage architecture can be a bad thing, since it hides the particular nature of that layer. For example, in Cassandra it is important to be aware of the partition key’s meaning. The slides are online.

The lightning talks were excellent, including a spoof on devops and consulting by Daniel Bryant, who coined the term QAOps, as well as a report on mob programming. I also caught Daniel Bryant’s presentation on microservices, which I’d missed at MuCon, having chosen the other track.

It was a good day out and excellent value. I’m very glad that I was able to go.

Day 2 of µCon

The second day of µCon proved to be as interesting as the first. I have another huge list of things to investigate, and there are some things I need to get underway at work tomorrow. As I said in my  post about day 1, the most important thing about microservices is, for me, the discussion of the problems and patterns of modern web-development. Pretending that monolithic applications work is no longer an option.

  • The relationship of microservices to SOA came up several times, with people questioning whether this was just a re-branding or rehabilitation of SOA.
  • Another good question emerging from microservices is why we still can’t produce satisfactory architecture after all this time (Conway’s Law dates back to 1968).  We have a cycle of new techniques becoming common, then standardised, then growing bloated and cluttered until someone takes a clean-sheet approach and we start again.
  • The concept of cohesion is one that I haven’t paid enough attention to; (micro)services should be ‘loosely coupled, highly cohesive’. It was also good to be reminded that logical and physical architecture do not need to be the same. I don’t think we pay enough attention to things as simple as package structure.
  • Jeppe Cramon pointed out that “a service that only deals with data is a database,” and we already have APIs for that. Why wrap that in REST?
  • One thing that’s difficult for me personally is getting out of the database transaction mindset. Cross-service transactions are a bad thing, but are likely to become prevalent as large software providers make it easier for people to do things the wrong way.
  • Jakub Korab had an important lesson for developers working with monoliths: if you touch any external system then you’re working with distributed computing. Monolithic architecture is an assumption that has worked (more-or-less) for a long time, but it’s not really true. All developers should have an awareness of the CAP framework and the Fallacies of Distributed Computing.

The only major problem I had with µCon was the lack of female presenters. If a subject has no female practitioners with something to say, then the topic may not be ready for a conference. Otherwise it was an excellent two days. I’ve already booked a ticket for the 2015 event.

Reflections on the first day of µCon

I spent today in London, attending the first day of µCon, a conference dedicated to microservices. A lot of delegates seemed to be in the same position as me – working with a monolithic application that needs separating. Microservices are certainly not the answer to my problems, but many of the techniques and architectures will help me. The most relevant session was Chipping Away at a Monolith by Mark Landeryou and Steve McDonald from SagePay, which gave me a lot to think about.

Some other immediate responses:

  • There was a great deal of pragmatism. As enthusiastic as people were about microservices, there was an air of caution rather than triumphalism. This is a good solution in some situations but certainly not a silver bullet.
  • The question of technical debt came up a lot. I’ve read several things recently questioning the use of the term ‘technical debt‘, and some of the speakers took a similar view. I’m often seeing it used thoughtlessly and dangerously.
  • Many microservice architectures have focussed on HTTP/REST, but some of the other options (pub/sub messaging, thrift) are interesting.
  • Conway’s Law is a constant reference point, and I need to sit down and read the original paper. I find myself wondering recently why we even organise programmers into IT departments rather than place them in the business where they are needed.
  • The Unix Philosophy came up a lot too, with one speaker describing Unix pipes as the most perfect API ever invented.
  • My main concern with microservices is that they are an ideal. Most people have good intentions but still somehow find themselves dealing with difficult codebases. Greenfield development is rare and temporary. Maybe we need conferences focussed on monolith programming – but I expect that would be a hard sell

Another early start tomorrow for day 2. It’s going to take me a few days to read through the notes I made properly (21 pages so far), but I’m looking forward to another day of talks.

A new weblog

I’ve been writing drafts of technical posts recently. I was going to put them on my personal site, but they didn’t seem to fit there. So I decided to start a whole new site for my technical writing.

Over the last year or so I’ve been playing with a lot of fascinating technology: microservices, Spring boot, AWS, Jenkins, REST and so on. For a while I’d been bored by programming but I now feel enthusiasm again. I’m full of ideas for things to learn and services that I want to build, and wanted a space where I could write about what I’d learned and what I was thinking.

I’m off to µCon on Thursday, then the LJC Open Conference on Saturday, both of which I’m sure will give me a lot to write about. There are various new technologies I want to play with, like Vagrant. I’ve been thinking about how the lessons from microservices apply to the world of monoliths. Programming has become massively more complicated over the years I’ve been doing it, but that is starting to feel exciting.