Category Archives: Programming

Techie programming type posts.

Scottish Developers Virtual Meetup

Developer groups quite often go through ups and downs, so after last holding an event back in May 2018 – the last one I attended was DDD Scotland almost three years ago – I thought Scottish Developers had long since disbanded. However I was really pleased to see a new event pop up on Meetup a week or two back organising a pandemic safe online virtual meetup with two very different speakers.

I have to say that one of the definite plus points amongst the numerous negatives for the lockdown is that many groups are discovering online groups and conferences. As the bigger tech hub in Scotland many of the events are held in Glasgow, so whilst I’ve taken days off to go to events like Code Craft Conf back in 2019, evening meetings are a lot more difficult. Going online allows much wider participation, so this event was hosted by Andrew in Caroline who were in different cities, with one speaker in Seattle in the USA, and the other in Aberdeen.

First up was Stephanie Stimac, a Microsoft employee on the Edge team whose talk was about the absolute minefield of HTML controls on web pages. This is a problem that has been around right from the earliest days of the web, and even almost thirty years later is still an issue – if you use the standard HTML controls in a web page by default they will use operating system components in a page and will look and function differently depending on which browser is being used to view the page, and especially if the browser is running on a different platform. This problem has never been fixed, web developers have merely worked around the problems initially by creating their own controls within pages, or more often than not using one of the now numerous frameworks that wrap up solutions to all these problems.

Thankfully, since I work very much in the middleware space, and with a standard browser for internal websites I don’t have to deal with browser complexities in my working life, however this did serve as a reminder of why I’ve always found doing that sort of stuff frustrating. This really is a problem that should have been solved long ago – Stephanie had some interesting statistics part way through her presentation of quite how many hours of developer time have been spend faffing around trying to deal with problems with the controls. Stephanie did offer some cause for hope, but we’re really not there yet.

The second talk, Gary Ewan Park talking about a Build Orchestration Tool called Cake was maybe more relevant to me, especially given that we’re in the process of moving our product builds from an ageing TeamCity platform to a modern Azure DevOps platform.

Although the build in TeamCity and ADO is doing the same task, how it does it is very different between the two, such that we currently have a specialist build team that is effectively recreating the TeamCity build for each of our products in ADO. Cake gets around that problem by moving the build into code. This means that the build can be run locally, and with one line in either TeamCity or ADO can be run the same way there too. The build orchestration is also written in standard C# – so the language that most .Net developers use, rather than particular configuration files for the build platform in use.

We’ll have to see whether we change how builds at work are done – as they’re the responsibility of a separate team who have been working on scripts in ADO specific YAML for a long while, but Cake does seem like a good way around the problem we’ve been having.

Anyway, it was a great restart for the Scottish Developers, and with another virtual meetup tentatively planned for April, hopefully not nearly so long to wait for another one.

If you want to watch the talks, a recording of the whole event is available on YouTube.

Code Retreat 2019

This last weekend was the tenth annual Global Day(s) of Code Retreat, with over one hundred and fifty Code Retreat events running on either the 15th and 16th of November. Not having been to one before it was great to find there was an event being run by Barney Dellar and Natalia Zon from Canon Medical Research at their office in Edinburgh, so I signed up to head along.

The basic idea of the Code Retreat is to look at how we as software developers code by coding the same basic problem in a series of exercises during the day with various restrictions. The basic problem is based around Conway’s Game of Life devised by British mathematician John Conway back in 1970, although during the course of the day it’s unlikely that anyone will get a working solution as your code is thrown away at the end of each exercise!

Each exercise lasts forty-five minutes, which is followed by a short retrospective session and a break, and then we start again. First off we had a simple attempt to solve the problem, to get used to pairing and the Cyber Dojo environment that we all used, however from there it got more difficult.

Session number two we were heavily restricted in the length of methods we could write, and in my case that was made more difficult by myself and my second coding partner coming at solving the problem from totally different directions! As a result of that in session number two I came up with a better explanation as to my thinking, which then came totally to nothing as session three we weren’t allowed to talk to or communicate with our pairing partner at all, except through the code we were writing, and we took turns to write tests and implement the code to pass the test.

Session four thankfully we were allowed to talk to our pairing partner, but had restrictions of not being allowed to use conditional or loop statements to solve the problem, this was just the kind of challenge that had a lot of the developers at the event still thinking about how to do it as they were leaving at the end of the day!

In session five we were exploring the Kent Beck idea of Test and Commit or Revert so if our tests failed for any reason we had to revert to the last successfully passing code, and delete what we had written since then. This is to encourage you to make small simple changes and always have working code rather than perform big changes that could potentially break.

The final session, Barney who along with Natalia was leading the event told us that since it was the last of the day we could do what we liked, resulting in lots of experimental solutions. However it was a ruse, and after twenty minutes he swapped the pairs around, and then five minutes later swapped development environments handing us all what was effectively legacy code with non-working tests, and in some cases in a language the new developers were not familiar with. The retrospective after that was interesting with all of us trying to explain where we were going with the half finished solutions that were passed on to others.

So was it worth giving up a Saturday for? Absolutely. Usually as developers we’re trying to learn development techniques at the same time as doing our actual work, it’s rare we get a chance to actually just look at how we code, and as such it was a really worthwhile day. Canon Medical Research actually ran the day twice, firstly on the Friday when it was mainly their own developers who attended, and then the public session on the Saturday. Certainly if you have a large number of developers it is the kind of event that could be run internally if you’re wanting to improve the coding skills of your team.

Code Craft Conf 2019

Last Friday was the annual CodeCraftUK conference in Glasgow. As a community organised event it’s much more reasonably priced than some of the bigger conferences, and also has a rather different structure than most of the big conferences – as they say on the conference website they put the confer back in conference, focusing instead on small group guided conversations and workshops. Since we have a daily parliamentary train that uses the Winchburgh Loop to go direct to Glasgow from Kinghorn that could get me to Glasgow in time for the conference I picked up a ticket and headed along.

Before talking about the conference, a little side note about the parliamentary train, if it ran more frequently it would actually be a pretty useful service – there have been a couple of occasions we’ve been going to events in Glasgow when there were events on in Edinburgh, in particular big games at Murrayfield when the normal route of taking a train to Haymarket and changing to the express service just really wasn’t attractive and we opted to drive instead. If there was a regular service direct to Glasgow, we would have used the train instead. Even with the meandering route the train takes, especially with the evening service there is little difference between the time it takes to go direct and going into Edinburgh and changing to a faster train.

Anyway, on to the conference.

First off I opted for a guided conversation entitled “What lies behind a job title?”. We had a mix of people in the group from recent graduates through to people like me who have been in the industry for years, and also from a variety of company sizes.

The conversation certainly confirmed my experiences over the years aren’t unusual. We had examples of companies, often the bigger ones, with rigid hierarchies, where teams had to have certain numbers of senior, mid-level and junior staff. There were also the common frustrations of junior engineers who were told what to do by seniors, seniors who only seemed to have reached that level by way of being in the role for a long period and so on. However there were other examples of more progressive companies that had done away with levels in job titles as they were regarded as unhelpful. There were also so amusing anecdotes such as a participant who is CTO in a small start up and said there was only one other developer, but that he used the CTO title because it opened more doors talking to larger organisations.

I along with quite a few others from the first conversation moved onto a second session called “Being T-Shaped”.

One interesting take away of the T-Shaped session is that there is not a single understanding of what being T-Shaped actually is. One explanation came from Agile Kanban practice where software development is split into a number of stages, the T shape idea coming from team members having most experience in one of the stages, but able to work on tasks in other stages if need be. However other participants in the conversation took T-Shaped as having a breadth of soft skills alongside deep technical skills in a particular area. Again this was a conversation that showed the differences within big and small organisations. In smaller organisations being T-Shaped is almost a requirement of the role, whilst in larger organisations there is sometimes push back against people working in roles that are not their own.

After the next break I opted for one of the workshop sessions, an hour crash course introduction to Machine Learning.

Machine Learning is one of the current buzzwords that sales and marketing people love to use, with really very little comprehension of what the term actually means – certainly they often confuse artificial intelligence in their products with genuine machine learning (check out this Wired article for an explanation of the difference). For what was necessarily a brief introduction we built a Jupiter Notebook that used freely available dataset, python code and TensorFlow to recognise handwritten numbers. This used a neural net that was trained with 60,000 handwritten numbers, and across the participants in the workshop achieved between 98% and 99% accuracy when given a second testing dataset of 10,000 numbers. Although it was a whistle-stop tour, we did get something working at the end of the session to take away, plus some recommendations of where to go to learn more.

For the afternoon sessions I went along to a two part workshop on Mob Programming, given by somebody who has been leading a team working entirely as a mob for the last five years. Alongside giving us experience of working in a mob to accomplish a task, he was also able to give some good advice.

For the first part of the workshop we were in a mob of six, and given the simple task of programming FizzBuzz, but using C++, a language quite deliberately picked because most of us would have little experience of it. We also followed the recommended practice for teams starting mobbing of having a driver who was at the computer and only allowed to do what they were told, a navigator who was doing the thinking, and the rest of the team not allowed to talk until their turn as navigator. We then rotated around the roles in order every two minutes and forty-five seconds. The rest of the mob not talking proved to be the critical practice, in that otherwise the mob has the potential to be dominated by some of the group, having the navigator being the only person allowed to speak ensures even quiet members of the team have a chance to speak and participate.

One of the key criticisms of mob programming, almost always from people who have never tried it, is that having the entire team working on a single task is slower than having everybody working on different parts of the problem. The workshop leader however is working at a company with two similarly sized and experienced teams, working on the same codebase, but one using mob programming, the other team using more traditional methods. Bearing in mind the usual caveats about it not being a good way to compare two different teams, the teams are working at a similar velocity, and certainly the company has not had reason to ask one or other team to change because of any significant difference in the work delivered.

The arguments in favour of it are an extension of the arguments in favour of pair programming in that the team is reviewing code as it is written, rather than the write, review, repeat loop that more traditional methods produce. It is also a good technique for ensuring consistent knowledge sharing amongst team members, and is an excellent way to on board new team members as they are just brought into the mob right from the start.

Certainly as an introduction to mobbing it certainly showed me what a beneficial technique it can be. There were several participants in the second part of the workshop who had been mobbing themselves for a while, and some who had been skeptical when their teams had started. All of them found the technique useful, and many said they would struggle to go back to not working in a mob. It’s not for everybody however, another participant in the workshop mentioned a team member who despite being an excellent part of a mob decided it wasn’t for them and swapped to a team who weren’t using the technique. On the basis of the workshop it’s certainly something I’d like to try in a team.

So was it worth the trip across to Glasgow? Definitely – and I’ll certainly be looking out for the conference next year. I probably learnt more from the workshop sessions, and the mob programming was especially beneficial, but the guided conversations were also good too. When you compare the cost of the bigger conferences, which sometimes veer towards being sales pitches for particular products, the conference is a bit of a bargain, and a great opportunity to learn from each other, not just from whoever is giving a particular presentation.

Open Space at Pivotal Software

Yesterday I had my first Unconference experience, where I attended a one day Open Space event, held at the offices of Pivotal Software, who are located just off Silicon Roundabout, on Old Street in London.

Firstly it’s probably worth explaining the concept of an Unconference or Open Space. The organisers of this event described it well when they said that the concept of the Open Space came about when people observed that many of the interesting conversations at other conferences took place in the coffee breaks, so when I arrived, the conference organisers had arranged a number of different rooms and environments, had divided the day up into a number of time slots, but all we had was a large empty wall to fill with sessions and activities, and sheets with the four principles, and one law that would govern the day.

Looking at the principles, the first three are about how the sessions run, basically don’t worry about who is or isn’t there, take the session as it comes, and don’t feel you have to fill the time slot:

  • Whoever comes are the right people.
  • Whatever happens is the only thing that could have happened.
  • When it’s over it’s over

The next principle is “Butterflies and Bumblebees”, which describes the way some people move between sessions. The Bumblebees don’t spend an entire period in one session, and instead visit many of the groups and sessions, cross pollinating between the sessions with fresh views and ideas they have maybe picked up from other sessions. Butterflies are not participating in any current session, but instead are tending to their own needs, but sometimes participate. At the Open Space both character types were apparent during the day.

The one and only law is the Law of Two Feet – basically if you’re not learning, or not feeling you’re gaining anything from the session, just walk away.

Wikipedia has a much more detailed overview of the technique – whilst we were using for a technical conference the technique could easily be applied to any subject area.

We kicked off with an ice breaker session to break us up into five groups to discuss sessions where we had to arrange ourselves into alphabetical order based on our country of birth. That proved to be an interesting exercise for several groups – the people from the United States actually all put themselves under A for America, I was in a group of three for England, but there were other English people down in a group at U for United Kingdom, and there was a lady who put herself at C for Crimea because she didn’t want to offend anyone, given that when she was born Crimea was in the Soviet Union, has been in Ukraine for a long period and Crimea has now been annexed by Russia.

In our groups we then talked a little about what we wanted to gain from the day, and then discussed what possible sessions we could do. There was an interesting mix. Firstly, some people had existing sessions they had done elsewhere that they were willing to run again – with hindsight I actually had one of those in that I had a copy of a Software Craftsmanship brown bag I’d done at work on my laptop – something for next time. Other people had current project they were happy to share and talk about with other participants, or skills they were willing to share. Other sessions were encouraged in the group discussion on sessions, so for example in our group we had a man who worked as a Biological Scientist, and was happy to talk about his work with scientific software. One key driver is that you don’t need to be an expert to propose a session, so several people had topics they wanted to talk about ranging from particular technologies or concepts, challenging principles, or just hot topics they wanted to discuss.

From there everybody with a proposed session lines up to give a quick elevator pitch of their proposal and suggest a location, taking in turns until all the sessions have been proposed. After that there is a rationalisation stage where sessions can be moved to resolve any potential clashes, to balance out the schedule, and refine a better schedule. After that it was into the first session.

The first session I picked was one on Unconditional Programming. The concept comes from Michael Feathers, whose superb book on Legacy Code actually sits on my desk much of the time. He came up with the term in a blog post back in 2013 and he has done conference talks on the same subject. It’s certainly an idea I’d come across previously, and the concept of Unconditional Programming is potentially one of the techniques Feathers discusses in his upcoming book which was originally going to be called Brutal Refactoring: More Working Effectively with Legacy Code, but may well be called Unconditional Programming.

The basic concept is that in many cases the use of conditional code such as the ubiquitous if/else construct actually couples different bits of the code together that shouldn’t be coupled, so removing the conditional will result in two separate more easily testable pieces of code that a cleaner and more easy to understand.

This provoked an interesting discussion, as the conditional is not really removed, it is merely moved, so rather than existing as an if statement the conditional is being provided by polymorphism in the factory class.

In the discussion we also had a few proponents of functional languages, one who uses Erlang, and another who uses Haskell who agreed that conditional free code was easier to achieve in functional languages, in particular through the vehicle of pattern matching. In this situation the pattern matching is providing the conditional rather than the if statement.

It was certainly an interesting discussion, especially with a mix of developers from both imperative and functional programming backgrounds.

My next session was given the title “How to produce your own Citymapper in 10 Minutes”, and was a developer who as a side project had been looking at routing algorithms and had been using London Underground routing as a test bed.

He started off showing us a picture of the London Underground map, and then highlighting that if you change the stations into nodes, and the lines between them into edges, you have a familiar concept in Computer Science, a directed graph. He highlighted that finding the shortest route in a directed graph was a problem that had been solved way back in 1956 by Edsger Dijkstra, and as such libraries to generate the shortest routes were available in pretty well every programming language. He then showed us some code that used the freely available underground station data that you can get from the TFL API and Dijkstra’s algorithm to work out the shortest route between two stations on the underground.

We then had a wide ranging discussions about how it wasn’t quite that simple, looking at issues of fast trains on lines like the Metropolitan line, and that it didn’t take account of the times to change trains. It was also highlighted that Dijkstra’s algorithm quickly breaks down with larger datasets, even if you use intelligent heuristics to prune potentially unsuitable routes that go away from the destination.

We then finished off talking about better options for graph and tree searching, and got onto talking about the A* algorithm that can produce routes more quickly, and especially a recent talk by Simon Peyton-Jones that covers the same subject area called Getting from A to B – Route Planning on Slow Computers.

My first session after lunch was entitled “Beyond SOLID” and was proposed by a developer who wanted to challenge whether the SOLID principles were really the best way to describe Object Oriented code.

We started working through each of the principles.

Firstly he stated that he though that the Single Responsibility Principle was primarily about code cohesion, and could equally be applied to other programming paradigms – it was something that was just good practice rather than something specific to Object Oriented Code.

Moving on to the Open/Closed Principle, he again thought that whilst the principle of being open for extension and closed for modification is primarily about plug ability of code, and is really a bit vague and doesn’t tell us much that is valuable.

The Liskov Substitution Principle he thought was probably one of the most difficult to understand of the principles, and whilst it gives us a better paradigm for understanding what object oriented code should look like is again not specifically about object orientation.

The Interface Segregation Principle is also about cohesion of code, but this time is more object oriented as it is specifically talking about contracts, using interfaces rather than concrete classes.

Finally the Dependency Inversion principle is again more object oriented as it is about how we use interfaces to instantiate concrete classes.

We then opened the discussion, and there seemed to be consensus that the SOLID principles were more principles of good design rather than specifically object orientation principles. We also discussed how being able to regurgitate the SOLID principles was almost a staple interview question, but it really didn’t indicate anything much beyond the interviewees ability to remember the acronym. It was also pointed out that SOLID has quite a mix of high level design principles, low level concepts, some architecture, and in the Liskov Substitution principle some quite deep Computer Science.

From there we tried to look at other principles or concepts that could describe Object Oriented coding including Design Patterns, Tell don’t ask message passing, CQRS command query segregation, keeping things small/replaceable parts, balanced abstractions, loose coupling, tight cohesion, code smells, and the classic OO principle of polymorphism, encapsulation, and inheritance/abstraction.

However when we looked at those principles, very few of them exclusively applied to Object Oriented code, many of them were just good design practices.

As with the earlier discussion on Unconditional Programming it was a good discussion about something that in many circles is regarded as a foundation of Object Oriented programming, but it is clear once you dig into it, certainly doesn’t cover all of Object Oriented programming, and is much more about good design than anything Object Oriented specific.

The next session I went along to had been convened by a developer and a mental health practitioner who were concerned about issues of developer mental health and burnout, and was a wide ranging discussion amongst a group of developers over work cultures, work pressures and how developers cope, or don’t cope with them.

From the discussion there certainly seems to be some variation in how companies handle their developers. Some will take all the hours developers will give with apparently minimal concern for their mental well being, at times actively encouraging and rewarding long hours that can lead to burnout. Others although they are good on limiting actual work, encourage their developers to be participating in their own time in community events and side projects, which again are increasing stress – several said they are now careful to limit their participation in communities to ones they consider directly relevant to their work.

We also had a good discussion about practices in our teams, covering working hours and stand up times. One company a developer worked for the director would actively force developers to go home at about 6pm. Another deliberately did not give their developers laptops and limited remote access to stop developers working long hours. Another operated a hot desking policy that used fixed desktop computers at each desk and the developers moving around and pairing. This also highlighted that pairing forces people to work common hours – one company explicitly banned using any code that hadn’t been written in a pair.

This again was a very interesting session highlighting the different ways different teams worked, and highlighting good practice, and bad practice across those different companies.

The final session was again a discussion on the broad topic of exploring where software development overlapped with other disciplines.

We started from the principle that the Software Industry has tried a number of metaphors over the years for describing itself such as Engineering or Craftsmanship, but we quickly reach the limits of those metaphors.

Over the course of the hour we drew connections with at least twenty other areas and disciplines including Philosophy, Biosciences, Psychology, Linguistics, Politics, Art and Design and Sociology.

Once again, with a diverse group of people it was a good exploration of all parts of software development drawing some parallels I’d not really though of before.

After that the day drew to a close with a quick retrospective where we sat and talked and shared experiences about what we had learnt during the day. As a first experience of an Open Space it was really enjoyable, from turning up with no idea of what I might learn there were a wide variety of sessions, and as the facilitators said at the beginning lots of interesting discussions.

Unlike other conferences I’ve been to, there was a pretty diverse range of participants also, with much closer to a 50:50 male to female split than I’ve seen elsewhere. Much as with DDD Scotland where one of the most interesting sessions was the Lean Coffee discussion, we got a chance to talk and explore ideas that you maybe wouldn’t see as a full session in a regular conference.

My thanks go to Denise and Spike at Pivotal Software for providing the venue and organisation for the event, and all the other participants for making it such an enjoyable day.

DDD Scotland

Last weekend was Developer Day Scotland. Much like the original Developer Days that I’ve been along to many of based on the Microsoft Campus that relaunched with a new team running them, this was a relaunch by the Scottish Developers. As there were some interesting sessions on the agenda, and since I fancied an excuse to take the West Coast Main Line over Shap and through the Southern Uplands – something I usually only glimpse whilst driving the M6 and A74(M), I grabbed myself a ticket and headed north.

The conference was held at the Paisley Campus of the University of the West of Scotland. The Reading Developer Day’s are relatively unusual being held at a company site, but then few companies have the kind of setup Microsoft have that is suitable. Having said that the experience of attending a DDD at a University showed up several advantaged, not least that they have much more space, and in particular the main hall is large enough to take all the attendees – at Microsoft the prize giving at the end of the day ends up being done with all the attendees stood in the foyer and the organisers stood on the stairs!

This conference I was very much picking sessions to tie in with upcoming work, rather than just sessions that piqued my interest as I have done at other DDD events.

First up I kicked off with Filip W talking about Interactive Development with Roslyn.

Filip started off with a quick recap of the history of C# as a language – enough to make me feel a little old as I can remember my first experiences with the early versions of C# back with Visual Studio 2003. This was to highlight that the way developers worked with C# hasn’t changed much over the years, which is why the new Roslyn compiler is such a game changer.

He started off with a simple feature, dotnet watch that allows you to run a specific command as soon as a source file changes. This needs the VS2017 project format, but allows a great deal of flexibility in how you work with code.

From there he moved on to Edit and Continue. Edit and Continue has been around for longer than C# – it was an often used feature of VB6 that was demanded in .Net as people moved across. It has however been problematic, as a general rule of thumb tending to support a version behind the current cutting edge C#. There have also always been a number of limitations, in particular not being able to change lambda functions at all. Roslyn has changed that. Finally it has now caught up with the current C# 7.

For the next part of his talk Filip talked about C# REPL, what is known in VS2017 as the C# Interactive Shell.

The C# REPL didn’t exist before Roslyn, because as a compiled language the kind of interactive functionality just wasn’t possible. With Roslyn, Microsoft has introduced a special mode that relaxes some of the parsing rules to make interactive development possible, including the ability to use syntax that normal C# code would reject as illegal.

Interestingly as Filip explained, each line is still compiled, which does give the interactive window some interesting advantages over interpreted interactive languages, allowing developers to interactively step back through compilation. It also integrates in with the current open solution allowing developers to manipulate and explore the current solution in more complex ways than previously.

C# REPL exists in several forms. It can be run directly from the command line, whilst the C# Interactive window in Visual Studio is a WPF wrapper around the C# REPL that leverages extra functionality. There is also an “Execute in Interactive” right click menu option to immediately run the code under the cursor. The final variation of it is Xamarin Workbooks which uses Markdown format text, and uses the C# REPL to execute any code blocks in the document. Output can also be sent to the iOS or Android emulators as well as running locally.

Filip finished off by discussing Live Unit Testing, something I’ve already been using in VS2017. This runs tests as they are actually being coded – it doesn’t wait for code to be saved. It does this by hooking in as a Roslyn analyser. It’s straightforward to write a custom analyser ourselves perhaps to enforce coding standards, or guide other developers in the way to use a library – indeed some third party library developers are already including analysers to do just this.

For session number two, I stayed in the main hall for Jonathan Channon talking about Writing Simpler ASP.Net Core.

Jonathan started by talking about a project he had worked on where speed had been an issue, and they had tracked the problem down to the large numbers of dependencies being inserted using dependency injection. The issue being that the inversion of control mechanism used to insert the dependencies was using reflection.

The issue is with the way we do SOLID in ASP.Net, so Jonathan used a series of examples showing how we can go from a solution heavily dependent on injecting dependencies and using mocking frameworks for testing, to something that uses no dependency injection or mocking frameworks at all. He has his examples for the talk online in a GitHub repository.

What is perhaps most interesting about his final solution is that the technology he is using has been around since the earliest days of C# – using delegates and static methods, along with his own Botwin library to simplify building an API going to a much more functional programming style model than is used in traditional ASP.Net.

Jonathan also highlighted a number of other blogs and videos. Mike Hadlow blogs on much the same technique highlighting how much less code using a functional style produces. Posts from Mark Seeman and Brian Geihsler also talk about how SOLID principles lead to a profusion of dependencies making codebases difficult to navigate.

Given that so much software these days follows the SOLID principles, this was a challenging different view on how systems should be developed, one of those “everything you think you know is wrong” type sessions.

The next session I attended was Paul Aikman talking about React.js and friends, which was one of my must attend talks as I was due to start working with React.js the following week for the first time. Paul has posted his slides on his website.

Paul started by taking us through how his company has eventually arrived at using React.js, starting out with Webforms augmented by JQuery, through Knockout and Angular 1, before settling on and sticking with React.

He also highlighted how there has been a gradual shift from performing a lot of processing on the server side with minimal client side functionality to the current situation where customers are expecting a rich and responsive experience interacting with websites that mean clients are now a lot fatter. He also discussed why having started with Angular 1, his company took the decision to shift to React, which effectively came down to the significant changes between Angular 1 and 2 meaning that they would effectively have to learn a new framework with Angular 2, so they went out to what they regarded as the best at the time, and changed to React.

He then gave a rapid overview of how React worked, which I found really useful coming to React for the first time during the following week. He highlighted that given the years of being told to separate logic and presentation with the MVC pattern, one of the biggest surprises with React is that it mixes logic and presentation together.

Paul also highlighted that React only focuses on UI logic, following the principle of doing one thing, and doing it well. There are additional libraries such as Redux and React Router that provide the additional functionality needed to build a web application.

After lunch, I decided to head along to Gary Fleming’s talk on API’s on the Scale of Decades which was on the problems with API’s, and how developers can write and API that can evolve over time rather than lock you in to poor early decisions. Once again Gary has his talk notes online which are well worth taking a look at. As a side note Gary was using an app called Deckset to run his presentation, that takes presentations written in Markdown syntax – considering the amount of time I spent reworking Markdown notes into a Keynote presentation recently, I’ve noted it down as something to look at further.

Gary’s talk was the one that promoted the most heated discussion of any I attended, both at the session, and also when I came back to the office. He started from the point that designing API’s is hard, but that what most developers want in an API is something that is both machine and human readable, changeable, testable and documented.

Gary started with a crash course in the concept of affordance, using Mario, and animals in a tree as examples! Gary was highlighting that in both the case of the game, and different animals using a tree in different ways it was through their knowledge and experience that they were interacting with the tree or we were playing the game, API’s should be similar. He used further examples where knowledge and experience allow us to interact with something – save buttons that look like floppy disks, even though many people now have never even used a floppy disk.

Applying this to our API’s the mechanisms for controlling them should be included in the information returned by the API, you shouldn’t separate them out.

Looking at a common affordance on an API, if there is a large dataset to return, generally we will page this, and there is a common set of affordances for stepping through the dataset. Going back to the days of the text adventure games from the early days of computer games, once again there was a common set of verbs with which to interact with the game.

A good tip Gary gave for thinking about the verbs and nouns to describe these affordances was to think about how you would ask voice assistants like Alexa or Siri to do what you want to do. He also suggested that well designed affordances are effective documentation for an API – if it is clear how to use an API you don’t need extensive documentation.

Gary then moved onto the problem of changing an API.

He used the example of the Ship of Theseus. In this thought experiment a ship over a long life has ongoing repairs such that eventually every single plank of wood and component of the ship has been replaced – is it the same ship? If we use this lens on an API, if over time we are changing our API, is it the same API, when do our changes take it from version 1 to version 2?

Gary’s suggestion was that we shouldn’t be versioning our API at all. To respond to the surprise from the audience he highlighted that we cope with this every day using websites, all of which change their API that we as users interact with. We apply our knowledge of the website and cope with the changes.

Gary then moved on to testing. His first example was asking the question of why we need brakes on a car? The obvious answer is to enable us to stop, but they also allow us to go faster. For the same reason we need tests on an API to allow us to change them faster.

Fundamentally, if we know that an API will inevitably change, we need to plan for those changes. He suggested that we should be using Consumer Driven Contracts, where the consumers of the API gives detailed expectations of how the API should behave, and then these form the basis of the tests against the API. He also highlighted the important of using fuzzers to ensure the API responds and handles unexpected data.

His final point provoked the most discussion, looking back at what he had been discussing he highlighted that JSON, which is what many APIs currently use is limited, and suggested that it is something we use by convention, rather than because it is the best tool for the job. He suggested that using HTML5 was a better option as it offered a richer interface that gave greater affordance to the users of the API. There was a good deal of incredulity from members of the audience, and indeed a similar level from our architect back at the office after the conference. Gary has subsequently said that there are limitations with using HTML5 also, but it was as much about getting people to question why they use JSON as proposing HTML5 as the solution.

My next session was also run by Gary, as I decided to pay a visit to the community room where he was running a Lean Coffee session.

The group came up with a mixed selection of topics to discuss. First off was a topic proposed by Becca Liddle who is the organiser for Women in Tech Scotland who asked about perceptions of women in technology companies. The discussion was wide ranging and covered a number of common issues around how women are treated both by company culture, and male colleagues, and also how male dominated tech culture can be off-putting to women and minorities. Becca had talked to a number of other women attending the conference earlier in the day and shared some horror stories of their experiences. Certainly food for thought as to how we encourage a more diverse workforce in IT. We also discussed what we were currently learning and broader issues around training, and also had a discussion about the impending changes being brought by GDPR which was in some ways a bit of a relief as it seems everybody is as concerned about it, and nobody feels they will be ready.

Next I went along to a session on Building APIs with Azure Functions by Kevin Smith. Again this was a session I attended because as a team we’re using Azure Functions in order to try and break up large bits of processing into horizontally scalable functions.

Kevin gave a good overview of the functionality available, highlighting the rapid development and simplified integrations, and also how they can be developed using Visual Studio. Kevin also has a good introduction on his website.

He also gave some good insight into the issues, including issues debugging them, and in particular problems with Microsoft breaking Azure functions. Ironically his final demo was also one that failed on the day I’m not sure whether it was because of a Microsoft breaking change!

My final talk of the day was Peter Shaw giving an Introduction to Typescript for C# Developers – once again it was a session I attended because we’re using Typescript for the upcoming work and the talk served as a good introduction.

First though a moan, Peter refused to use the microphone in the hall on the basis that he “had a loud voice”. Now he certainly did speak loud enough that I with good hearing could hear him without a problem, however experience looking after the sound at church is that if somebody does that there may well be people in the audience who have hearing difficulties, but nine times out of ten when challenged like this, they won’t feel comfortable in drawing attention to themselves as being unable to hear. At church the reason we ask people to use microphones is because however loud peoples voices are they can’t speak loud enough to drive the induction loop that many people with hearing difficulties will use, and speakers refusing to use the microphone leaves those people feeling discriminated against. Sometimes they will suffer in silence, other times they will complain to the sound crew, almost never will they complain to the speaker, who carries on in blissful ignorance thinking they have a loud voice and everything is fine. I hate working with a microphone too, so do many other people, but they are there for a reason, so if you’re a speaker, and there is a microphone, please use it!

Anyway, moan over, onto the talk. Peter started with an overview of why Typescript is important. More and more applications are moving into the browser, much as Paul Aikman highlighted in his talk on React we’re moving from applications where much of the functionality is in complicated server side C# code, to applications with richer client side experiences using Javascript. Similarly the growing variety of internet of things often use Javascript.

For developers used to the rich type-safe world of C#, Javascript can be a bit of a shock. Typescript is a language designed by Anders Hejlsberg who designed C# to open up Javascript to a back end developer used to C#.

As such the syntax is familiar to anyone who is used to C#, and makes the transition to Javascript development relatively painless.

Interestingly Peter highlighted that Typescript is more of a pre-processor than a compiler – ultimately what is produced is valid Javascript, but Typescript acts like a safety net enabling the developer to write enterprise scale Javascript applications.

There are a number of subtle differences however driven by the differences in Javascript. For example Typescript has Union Types that allow for the Javascript ability to change the type of variables. Undefined and null are still usable, however the Typescript team advise against them.

There is lots of Typescript support around. Many of the most common Javascript libraries already have typescript type files defined to allow them to be used from Typescript. Peter referred us to Definitely Typed as a good repository of high quality Typescript definitions.

As an introduction it was a useful talk giving me as a C# developer taking first steps into Typescript confidence that it won’t be a difficult transition.

After that we had the closing section of the Developer Day with the traditional raffle and prize giving, and as is traditional (and much to the disappointment of the kids because an Xbox X was one of the prizes) I didn’t actually win anything in the raffle. Was no bad thing however as I’m not quite sure how I would have got an Xbox back to Reading on the train…