IG Charts - A Technical Introduction

Sergio Santos photo

I recently gave a technical overview of IG charts at our Krakow IG office. You might find the slides interesting.

The broken promise of static typing

Daniel Lebrero photo I was quite surprised at a recent blog post by Uncle Bob Martin, titled: "Type Wars", in which he writes:

The tragedy of 100% code coverage

Daniel Lebrero photo It is funny how things turn around. ​ For fifteen years I have been preaching TDD (Test-driven development, or as it used to be called: test-first approach), or at least for developers to write some unit tests. However, in recent times I have found myself saying more often, "Why did you write that test?" instead of, "You should write a test."

Charts Incubator

Michael Bird photo Last night someone decided to come into the office at 6pm to work on IG’s charting product for the evening, even though they were on holiday for the week. They were joined by five others who ended up staying until 10pm.

Why did this happen?

Logging levels: the wrong abstraction

Daniel Lebrero photo So you just wrote another try/catch block and again you start wondering: should I log this exception as an ERROR or a WARN? Or perhaps you wrote another one of those conditional branches that “should never happen” and again you start wondering: what log level should I use for this “impossible” case?

You are asking the wrong question.

Never fail the same way twice

Henock Zewde photo At IG we write a lot of software. We have thirty or so teams in multiple geographic locations developing and supporting around two hundred disparate applications and services, utilising a diverse range of technologies old and new.

Pipeline 2016 Conference Review

Gustavo Elias photo I have attended a number of conferences before, though not always as speaker, but Pipeline 2016 has certainly been the most fun to date.

Towards RESTfulness

Lucas Gut Galan photo IG’s journey towards RESTfulness began as a set of REST APIs built for our mobile platforms as an aggregating façade over our internal services. Two years into the journey we realised that we were building an inflexible monolith that tried to support front-ends with very different user experiences, and which required constant enhancements. Change became painful.

In the pursuit of cake

Ian Reay photo Good team dynamics is a critical part of a healthy agile team, so as we were reflecting on our general health and happiness in a bi-weekly retrospective meeting, we decided that we wanted to tackle a team building exercise together.

So you want a Public Web API?

Robert Morschel photo So you'd like your customers to integrate with you, and what better way to do this than a shiny new public web API? Perhaps, like IG, you had a suite of existing web services for your web and mobile platforms, so it's simply a matter of "exposing" these, right?

But is your existing API good enough to expose as is? What exactly makes for a good public API?