Sophia and I will be in Australia until the start of June. It's just a quick trip this time to catch up with family and friends.
Update: We're back from Australia. It was fun!
Off to Australia
New toy...
On the weekend I took delivery of a Wacom Intuos 5 tablet.. I’ve never had much of an artistic talent, or maybe I just didn’t like the messy paints, but I really liked the idea of a tablet… Anyhoo, after a couple of days of playing around and reading tutorials, I can now draw a snail… Enjoy my unabashed talent!
I also wrote my first hand-written letter in a long time… I sent it by email, of course. ;-)
Update: A cool little bug:
— by Robert Thomson, created 7th Apr, 2013, last modified 4th Jun, 2013 | Tags: World
Service Orchestration
I've been musing a bit about complicated service orchestration of late. For some situations, it's as simple as SSH'ing into one or more boxes in a predefined order and executing some actions; sometimes it involves copying files around, calling random APIs, adding/removing nodes from load balancing proxies, launching new VMs in a cloud and waiting for them to be ready or bringing them down again.
This has of course led me down the road of workflows and state machines, and has me wondering about the kind of interface that I would like to have for designing orchestrations as well as for for executing them. I think it'd be nice to kick a flow off from the command line and then query it's current progress or 'tail' it. You could also execute flows via a web-based job scheduler and have visual feedback.
As for design, I'm less interested in formal BPM workflows since they seem a bit of an overkill, although they can also be applied to service orchestration. A state machine model might be a better fit. I could imagine something similar to Puppet's model, having orchestration steps instead of resources, and it running until the dependencies for the finished state have been satisfied. There are a lot of possibilities, and I'm still looking for a model that would work for me.
As far as I've thought about it, a given flow would comprise of a set of discrete steps executed under certain conditions. There would have to be some state associated with the flow itself, but the conditions wouldn't have to limit themselves to that state (ie. a conditional could call a custom function which looks up external state). The discrete steps could be code, builtin functions and decision logic, or other flows. I'd like to be able to express these steps succinctly using a simple data structure, but turn to a real programming language to do the more complicated work.
— by Robert Thomson, created 5th Apr, 2013, last modified 5th Apr, 2013 | Tags: Tech
Python pipelines
I recently realised that one of my most common tasks is to deal with streams of structured data, perform some task on or with the data, and spit out the results. The traditional UNIX way is to do line-based processing, piping through awk, sed, grep, perl one-liners, and storing the results in temporary files which are then used as input to other commands. However, having pre-structured data makes more sense for many scenarios.
So I’m currently writing a set of python libraries for working with streams of structured data. It uses a push-based pipeline, where a stream processor can either modify, filter, or add new items to the stream before passing it onto the next processor in the pipeline.
Perhaps some command line examples would show the idea best:
$ pipeline in:hosts filter:location=~ec2 parallel:16 task:ping filter:+success ssh:“uptime -a” out:host_uptimes
$ pipeline blogposts:all filter:tags=~tech task:blogpost2html concat:-
$ pipeline in:shares task:get_latest_share_price task:analyse_share_value csv:share,value,profit
All of this can also be done programmatically with relative ease.
With the command line tool, if no output processor is provided, the default will be used which saves the structured data to “last”, using a default “database”.
— by Robert Thomson, created 3rd Apr, 2013, last modified 3rd Apr, 2013 | Tags: Tech
German Copyright Law & Employment Contracts
Like many IT geeks, my work is also my hobby. This often means that my personal fields of interest are often in the same problem domain as that of my workplace. Recently I decided to thoroughly investigate German copyright law and my work contract after a colleague suggested that I had crossed a line with an open source project of mine. I’m happy to say that after my efforts, I’m quite confident that I’m OK. I am going to share what I learnt, however.
Firstly – a clarification for those who don’t know or get confused easily. Copyright law applies to specific implementations, not to ideas. Also, I am not a lawyer, so ask a lawyer for a legal opinion. :-)
In Germany, copyright always belongs to the individual or individuals who wrote a piece of software. That means that any software I would write for work would have my name associated with the copyright. However, there are different rights associated with copyright. German (and most European) copyright law aims to ensure that the author retains the inalienable moral rights. The second set of rights are the economic rights, which govern how and if the software will be made available to others.
German copyright law states, in UrhG. 69b: “Where a computer program is created by an employee in the execution of his duties or following the instructions given by his employer, the employer exclusively shall be entitled to exercise all the economic rights in the program, unless otherwise agreed.” (auf Deutsch: “Wird ein Computerprogramm von einem Arbeitnehmer in Wahrnehmung seiner Aufgaben oder nach den Anweisungen seines Arbeitgebers geschaffen, so ist ausschließlich der Arbeitgeber zur Ausübung aller vermögensrechtlichen Befugnisse an dem Computerprogramm berechtigt, sofern nichts anderes vereinbart ist.”)
I interpret this to mean that so long as I don’t write something for work, in order to facilitate my work, or at the instruction of my employer, then I retain the economic rights. Very straight-forward and sensible, isn’t it?
I also assume, although I haven’t seen it stated here, that you shouldn’t use work resources for personal projects, or work on personal projects during work hours. Maybe this is more to do with the typical employment contract than copyright, but I could imagine it forming part of a copyright claim’s justification.
In the event that there is a dispute, however, it is a civil matter that can be dealt with in a number of ways. The suggested way would be to discuss it and reach an amicable solution, rather than involve expensive lawyers and courts. The best solution is to avoid potential disagreements in the first place, by making your company aware of any private projects which could cause problems beforehand. You don’t require their approval, nor do they have the right to deny it, but you should have them acknowledge it, preferably in writing.
The next thing to consider is your employment contract. In Germany, they assign a lot of weight to contracts and quite a lot is allowed (although there are more restrictions when it comes to employment relationships). My work contract, for example, considers work in a certain field to be somewhat “protected”, and for that field I should seek approval from the company before openly releasing any work to the public. Luckily I have little interest in that particular field.
As a general rule, you shouldn’t publish anything openly which could cause harm to your company. It has nothing to do with copyright – but as in any contract, you have a fiduciary duty to protect the interests of the other party, plus it’s just common sense to maintain a good working relationship with your company.
So my friends in Germany, go forth and write software!! :-)