Over three years ago, we embarked on an experiment of utilising counter-measures to prevent badly written clients to our RESTful APIs.
Bad clients are ones that make unhealthy assumptions about property ordering and presence, and violate Postel’s Law, thus creating a blocker to having evolvable APIs.
Since then, new APIs that we’ve released have implemented these counter-measures (which we’ve open-sourced here) and I’m happy to report that they seem to be working.
I say seem, as it is difficult to prove empirically — as these are new APIs we don’t have the data to compare before/after — however, anecdotally, the noise around clients breaking due to unhealthy assumptions on these APIs has been zero. …
Given the recent coverage on the security incident at PageUp and my upcoming talk at YOW! CTO Summit Melbourne on the lessons drawn from it, I thought it would be an appropriate time to share the Thank You letter I sent to my team as the acute stage of the crisis was drawing to a close.
I believe it gives valuable insight as to how we handled it as a team, draw from it your own conclusions.
Subject: “Thank you!”
Sent: 18th of June, 2018
“As the tides are turning, and we’re having more and more of our customers reactivate their instances, I wanted to express my gratitude to all of you. …
As a short exercise, I modelled a simplistic view of the dynamics between velocity, technical complexity (a.k.a tech debt, product complexity) and the pressure to deliver that every software team experiences.
This naive model assumes:
PageUp is on a journey towards an event-driven, API-centric integrations into our client systems
Here at PageUp, we take great pride in our unified talent management platform which serves many multinationals around the world. We also humbly recognise that no system can do everything for everyone. That’s why we stay out of payroll processing, and instead offer partnered solutions and integrations into existing clients’ systems.
Creating a seamless experience when integrating into our clients’ business processes requires great integration capabilities — many of which have evolved over the years. …
I have always struggled with vulnerability, this post is about how I learnt to embrace it, and how it enriched my life immeasurably.
In September 2014 I went to my second ever Burn, it was the regional burn event for the east coast of Australia — Burning Seed.
While my first Burn, Burning Man in 2013 was a once-in-a-lifetime party in the Nevada desert, Burning Seed 2014 was a world-view altering experience which I have since made into a recurring fixture of my calendar.
Over the course of my first Seed’s five days I made many meaningful and fulfilling connections with an amazing variety of colourful and wonderful individuals. …
As a vendor of a SaaS used heavily by large enterprises, a key capability of our platform are APIs that allow integrations with our clients’ internal systems as well as our technology partners’ platforms.
The reality that follows any 2nd-party accessible APIs is that we often wield very little control over the quality of the client code that accesses our system — as such we must make our system resilient and assume the worst of our API consumers.
To allow as much forward compatibility as possible, we want any client code (whether internal or external) to follow Postel’s Law (well explained in PACT’s specification philosophy) to prevent integrations from relying on temporary side-effects in our APIs and ensure they are forward-compatible with minor changes in our APIs. …
In the history of our civilisation, as the size of our communities rose above Dunbar’s Number, our ability to maintain individual relationships with every person we encounter in our daily lives has been compromised.
Today, we live in cities that vastly overshadow the estimated size of a group that we can comfortably maintain a cohesive relationship with: 150 people.
As a result, our brain has been taking cognitive shortcuts, abstracting away the details of the individuals we interact with, and instead objectifying them — in essence treating them as symbols and/or tools: we interact with “a barista” or “a doorman” rather than with Helen or Joey. …