# Safer Serialization

Java serialization is a dogs breakfast. Sometimes we need to protect code or data structures so that they are restricted to types that are serialization-safe. We could require that the parameter is Serializable, and while every Serializable is serializaton-safe, there are things that can be serialized that don’t implement Serializable. Can we do better?

## Can we leverage Types-as-Proofs?

Following the glorious tradition of this blog, let’s treat this as a types-as-proofs problem. The proof we want is that the type can be serialized. So, naively, let’s directly represent this at a type.


trait CanBeSerialized[S]



This lets us protect methods with evidence that something can be serialized like this:


def sendOverRMI[S : CanBeSerialized](something: S) = ...



So, now we have protected sendOverRMI() so that it only accepts things that have evidence that they can be serialized. Now we just need some implicit witnesses. A good start is to allow all serializable types and all primitive types.

implicit def serializableIsSafe[S <: Serializable](s: S) =
new SerializationSafe[S] {}

implicit def valuesAreSafe[A <: AnyVal] =
new SerializationSafe[A] {}


There are probably other things that are serialization-safe. If you think of them, add an implicit. As you can see, this approach gives us an extensible way to protect code so that it only accepts serializaton-safe data. It’s decoupled from the Java Serialization interface just enough that we can accept the types we actually want. In retrospect, Java should have handled all serialization differently, either using a type-class approach or by explicitly exposing the meta-object responsible for serialization. However, given where we are now, the SerializationSafe type-class at least gives us a fig-leaf of safety in a mad world.

## Putting it all together

You can find a sketch of this approach as a gist:

/** Witness that a type is safe to serialize. */
@implicitNotFound(msg="Could not show \${S} to be serialization-safe")
trait SerializationSafe[S]

/** Serialization-safe witnesses. */
object SerializationSafe {

/** If you are serializable, you are serialization-safe. */
implicit def serializableIsSafe[S <: Serializable](s: S) = new SerializationSafe[S] {}

/** If you are a primitive, you are serialization-safe. */
implicit def valuesAreSafe[A <: AnyVal] = new SerializationSafe[A] {}

}

...

// a function that can only be invoked on something that is serialization-safe
def [T : SerializationSafe] somethingThatRequiresSerializableData(t: T) = ...

This code is untested and unused in any of my projects. Please pillage freely.

# Stripped-down semigroups

Semigroups are endemic within programming. In functional programming, they have a number of useful features that make them natural abstractions for transforming, aggregating and summarising data structures. However, the sheer diversity of possible semi-groups over complex data-structures can be blinding. Here I present n-valued logic as an abstraction for some key aspects semigroups that restores a bit of sanity to the zoo.

# Security: Treat it with Respect for Fun and Profit

I’m getting royally pissed off working with code-level security. There are any number of frameworks and magical incantations that provide security, but they all rub me up the wrong way. What I don’t like is how they try to hide things from me, so I never know if some code is calling into a secured context or what kind of authority I need in scope. It reminds me of all the insidious problems that happen if you try to add remoteness or transactions by hiding them. They always seem to crawl back out of their dungeons and try to eat your brains. We get code that may or will fail at run-time that we would rather failed to compile at all. Aspects, annotations and dependency injection at least make it fairly easy to build the dungeons, but can we not do better?

Of course, the FP solution is to represent the security concerns in the type-system. But what does the type of secured operations look like and can we do anything useful with it? Continue reading

Commutative Diagrams are used throughout mathematics and computing for describing proofs about function (arrow) composition. Here I hope to convince you that they are a useful abstraction for discussing science.

# Programming with Nouns & Verbs

I’d like to explore a way of looking at programming by analogy to nouns and verbs. This provides a framework for categorising languages and functionality, and I believe also gives insight into some of the causes for impedance mismatches that so complicate apparently trivial tasks such as transparent database persistence or dependency injection. Perhaps it also gives us a hint as to why some people are naturally drawn to Object Oriented Programming (OOP) and others to Functional Programming (FP), in all their varied forms. Continue reading

# What’s the difference between systems and synthetic biology, and why does it matter?

## So what is the difference between systems and synthetic biology?

In a word, intent. In systems biology (sysbio), we use all the available tools of molecular biology, genetics, statistics and modelling to produce accurate and predictive models of existing biological systems. In synthetic biology (synbio), we use all the same tools to construct biological systems with intended behaviour. Given this commonality of tooling, it is seductive to believe that this distinction is skin-deep, that sysbio and synbio are fundamentally the same endeavour. I believe that they are fundamentally different endeavours, and that this is due to synbio embodying intent. Continue reading

# Ultra-lightweight reactive swing

Reactive programming looks great, but before I knew much about it and when I just wanted an abstraction over swing listeners, I knocked up a reactive-inspired toolkit. This abstracts values that can change, which you can set and which you can get. It also provides a bunch of nice ways  to bind listeners in, either purely for their side-effects, or to bond the value of one value to another. Continue reading

# Implicitly logical

Implicit arguments are a powerful feature provided by the Scala programming language. Here I’m going to present a way to think about them which ties in with a simple extension to proofs-as-programs/propositions-as-types that hopefully makes it easier to understand what they do and how you should use them.

The short version is that we can interpret implicit arguments of a def as capturing proofs of theorems that will be supplied at the call site, rather than satisfied by the def’s implementation. Continue reading

# Typing database IDs

I’ve got several code-bases using squeryl to manage relational data models. It seems to work well in squeryl to model the database tables as case classes, linking tables together via foreign keys modelled as properties of type Long. To distinguish ID fields, I suffix them with _id, and either name them after their role in that association, or simply by using the target table name. My problem is that despite naming conventions, sometimes I get my IDs mixed up. Continue reading

# Graphviz from scala

I’ve been trying to debug some graph algorithms I’m developing, and got to the point where I needed to look at the graphs to work out what is going on. In the past I’ve used graphviz/dot to do this. So, now that I mainly work in scala, I had a hunt about for a scala graphviz library and came up empty.

One week later, I’ve hosted the source on github. I’ve named the project graphviz-s. It’s built using maven and tested with specs2. Continue reading