We launched Google Reader in 2005 in an effort to make it easy for people to discover and keep tabs on their favorite websites. While the product has a loyal following, over the years usage has declined. So, on July 1, 2013, we will retire Google Reader. Users and developers interested in RSS alternatives can export their data, including their subscriptions, with Google Takeout over the course of the next four months.

create a self signed x509 cert with a single openssl command

This is how you create a nice self signed x509 cert with a single openssl command:

openssl req -newkey rsa:2048 -keyout server.key -out server.crt -nodes -x509

openssl req -newkey rsa:2048 -keyout server.key -out server.crt -nodes -x509  -subj /

Now it’ll just take another couple of months to finally read up on how to write a config file for that :)

golang package cappedqueue

Just finished the first few lines of hopefully somewhat usable go code. The code is available on github in case someone indeed is brave enough to use it…

To quote the README.rst file:


cappedqueue is a simple package to make sure you can submit to a queue. Losing items is on purpose so that you can rely on not accidentally blocking or filling up your memory

see the cappedqueue_test.go file for details on the usage…


The Importance of API “Transports”

SQL Databases are dead

There I said it. I jumped the NoSQL waggon and I refuse to use anything that is remotely uncool and old.

Of course the above is a lie. Well kind of. In reality I do think that the interface by which you communicate with a SQL database is dead (or rather should be, but so should FTP — another story — still there are a few people left using it).

I’m not really talking about the query language itself, I’m talking about the “transport” (lacking a better word).

So is (nearly) any other protocol

I’ll leave the kool new aid road now and talk about the transport stuff a bit.

My problem with API interfaces currently is that the usage of these interfaces is quite annoying. Let’s look at the products that people use all over the web.

Say you go to Facebook or Google and what to use their API to do something with the social networks represented by the data. On the API page of Facebook you’ll find some source package that implements a transport protocol, a domain specific language and to complicate things a bit further also a certain data representation.

Reality is that right now to use some service on the Internet there is only a single transport protocol. HTTP, maybe add SSL on top of that but the transport is HTTP. I’m not saying that the HTTP protocol is the ultimate protocol. It’s shortcomings are quite well known.

The point is that you can solve a whole set of problems all in one go and be done with it.

Back to the SQL Example

So you have this cool new project and decided to use some relational database system. Now you also decide to use a framework that relies on interactions with other systems being non-blocking. So you run around the web and look for some non-blocking driver for you RDBMS of choice.

Then you run around the web and look for some non-blocking driver for you storage part, then you run around the web…(you get the idea).

Now if all your satellite systems would be exposed oder HTTP you’d…run around the web and look for a non-blocking HTTP client and be done with this category of problems.

Just don’t use HTTP…please!

Please, please, please…don’t just use HTTP because I used it as an example here. A unified (or generalized) transport really needs some serious thinking.

Of course you can just run away now and scream what kind of idiot I am, but the next time you run around the web and and look for a driver because the transport of services isn’t generalized enough to be reusable.

Also please don’t confuse the transport with the represenation — which should be considered equally important and would solve another stack of problems.

And if you go that last route, that still doesn’t say that should be only a single language per domain, having a single language per domain would be not that good without wasting further thoughts about those last two statements.


What is big data?

It’s actually quite simple: You have big data whenever a single host isn’t enough to either store or process your data.

What does it mean?

Suppose you have a Postgresql Database and you run into scaling problems. There’s a choice now, either get better hardware so that you can continue to work on a single host or split the database to span multiple hosts.

Suppose you have a file store and all disks are full. You can either buy larger disks or use some distributed storage system where you just add hosts to expand the total storage capacity.

In both cases you are dealing with big data.

Big data (for me) isn’t anything that says X MB of data. It’s simply the case when you need decide to use a distributed system to handle your data.