We attended ProgSCon The Programming Conference in London on April 22 to learn about different languages, architectures, algorithms and coding practices, as well as new trends and ideas.

Questions tackled at the event included: How to get the best of a given programming language? How to squeeze out the last drop of performance juice? Which language is best in which field? How to choose the correct architecture?

Interesting talks

Containers, FTW!

A brief introduction to open source Mesosphere DC/OS and Marathon. DC/OS takes advantage of Apache Mesos to abstract an entire data centre into a single pool of computing resources. Whilst Marathon provides a container orchestration platform for Mesos and DCOS. (View the slides)

Decoupled APIs through microservices and building APIs

A good refresher on good ol’ basics, such as which features a microservice should have and how to build APIs to connect different microservices. (View first slides deck, and the second)

Questions about documentation and how to avoid writing it

Some good advice about how to document apps without writing tons of boring documentation.

Is it really necessary to write documentation for every single function in our code? What does ‘constructive laziness’ mean? Should everyone write their own documentation? (View the slides)

Real life clean architecture

Mattia Battiston talked about his experience dealing with the architecture problems of their application. He explained that the main part of their app, the centre of everything, are the use cases, not the database nor the framework.

There is probably no simple, single solution but he expounded how they solved it through Clean Architecture and explored the positives of this decision, giving a few useful ideas. (View the slides)

Insights

In addition to obtaining a Python programming book (thanks Fabrizio Romano for the gift!), we also gained the following insights:

• It’s always better go forward instead of backward. When testing out new features with our customers, always have the option to switch off a feature rather than having to rolling back a change to remove it.
• We get paid to resolve problems, not to write code. We should always start by thinking about the people that will use and the people that support our apps and that consideration should be at the core of our programming.
• Untested code is broken code. When building out microservices, high integration test coverage is paramount to keeping the cost of change low, especially where multiple services interact.
• Smart endpoint, dumb pipes. When we are building microservices the communication between them should be simple and lightweight, if it is getting complex, it could be a time to refactor.

We look forward to seeing you at ProgSCon next year!