When to use Serializers?

An article, posted about one month ago filed in ruby, rails, ruby on rails, service, architecture, when to use, json & JSON-API.

Define Serializer

Serialisation (I’ll use s in writing about the concept, and z when discussing the thing itself) in programming is about converting the state of an object into something that can be stored or transferred. When you really want to serialise the state of an application to disk, you probably want full, unmodified serialisation, so the question about serialisation typically comes up when you want to share data with external parties. To these parties you don’t want to share the raw data, but pre-process it a bit, perhaps convert the internal state to objects that are more generic and don’t expose the full internals. In such case you might want to consider introducing the concept of Serializers.

Alternatives to using serializers

Before introducing new tooling, always consider the following default options Rails offers:

  • Serializers live on the view-layer. The default approach rails suggests is to have e.g. {index, show}.json.jbuilder files in your v…

Continue reading...

Generating and parsing data URI's in Ruby

An article, posted more than one year ago filed in uri, data, url, data-url, ruby, link, browser, html, json & api.

I’m fond of data-URI’s (MDN Link). 12 years ago I reappropriated a tool that stored a webpage with its related resources in a Microsoft specific format and rewrote it into something that would store it in normal HTML where the related resources were encoded in data URI’s. Recently the topic came up again at a project I was working in, where microservices are still a thing. And while discussing it with colleagues it seemed as if knowledge about this quite useful URI-scheme wasn’t on top of everyone else’s mind. Instead, the original idea was, we could upload the resource to S3, pass the link, download the resource from S3 at the receiving end, and then have some policy that takes care of deleting it… nah…

data-URI: The basics

This is the most simple data-URI:

data:,Hello%2C%20World%21

You [can open it in your browser](dat…

Continue reading...

Delay your decisions

An article, posted about 7 years ago filed in agile, design, project, keycloak, json, editor, visualisation, visual & graphing.

I design very little upfront. Sometimes I need to make an estimation, I design a little more. Sometimes the project is hardly specced and there is a lot of exploring to do.

In this post I would like to give a demonstration of how a recent project developed.

Initial stage

Client: “We want a fancier frontend for our data”.
Me: “Sure, any limitations?”
Client: “We give you 4 months”
Me: “Can I use any tech I want?”
Client: “Na, we want to be able to continue on what you’re going to create, so please use P, X, Y and/or Z.”
Me: “Sure, P is not my favourite, but some time ago I’ve dealt with it, so ok, we keep it simple anyway.”

The plan that followed:

Initially I thought I could fancy up the CSS, but the old product was in a very bad state and not really maintainable. So I decided to create a thin API layer in P (yes of PHP), a modern front-end layer in JavaScript using a framework that I co-introduced in the organisation a few years ago (R…

Continue reading...