Good morning Percona Live visitors! Attached to this post you can find a spreadsheet (both LibreOffice or Excel, as you prefer) that you can use towards the end of my tutorial. I've also attached the slides so you can download a copy of them.
For reasons that I will blog about in a couple of weeks, several people last week asked me what I think about open core. My answer was that nowadays I don't care much about the topic. Long time readers of this blog might be surprised at such an answer, so I thought this was a good time to reflect on why I don't think it is very important anymore, and more importantly to document the empirical evindence that we now have about open core as a business strategy.
As I hinted yesterday I've tried to automate the deployment of a sharded MongoDB cluster in Amazon. It's unnecessarily difficult (rumor has it 10gen is doing something about it in the future) but it's doable with appropriate amount of persistence.
I occasionally post so called "one liners", shell commands that can be used to filter out some data I need. The main reason I do this is that I can later find this when I try to google for it. This will be my first one liner for MongoDB. Ok, so it is actually 3 related one liners.
If you need to find out if a shard is already part of your MongoDB cluster, try this:
echo "db.shards.find()" | mongo $MONGOS/config | grep Shard4 | wc -l
The result will be either 1 or 0.
Now, if the shard exists, you might want to know a hostname and port number of one of the members of that replicaset:
Yesterday I described my first ideas at mapping the preferential voting method used in Liquid Feedback, to an approval voting method as supported by Helios Voting.
After writing it I had a Heureka moment and went back to check some details on how Liquid Feedback, and in particular the Schulze method actually works. It turns out it is not necessary at all to keep a record of the +N ... 0 ... -N scores given to each vote, this is merely an implementation approach used in Liquid Feedback. The only thing that is really needed is just the pairwise comparisons of all alternatives. This is stored in Liquid Feedback in the
battle table. In fact, that is precisely what Solon delivers back to Liquid Feedback as results of the voting.
It's been a while since I last did any hacking on Solon Voting. Solon is my project to implement secure e-voting for delegated democracy platforms. You can read previous blogs here.
When I started Solon, I was first focused on just tweaking Liquid Feedback in order to enable use of cryptographically secure e-voting algorithms. I wasn't aware that an open source implementation of a homomorphic e-voting algorithm actually exists. But then a couple of people introduced me to Helios Voting. This has been great news. What remains now is basically to glue together Helios with the already existing Solon-LiquidFeedback combination, and we will have a first ever cryptographically secure voting solution for delegated democracy. Of course, this is a very rough prototype, but it will properly encrypt the votes and will produce verifiably correct results.
Last week I had some vacation, so I finally had time to play with Helios a bit more. The results of this week's hacking are now committed on Github.
The next Helsinki MySQL User Group is set for Tuesday, February 19. Lari Pulkkinen from Arbitron Mobile will talk about their project adopting SSD disks for better MySQL performance. Yes, there are benchmarks included.
Note the changed location: Oracle office in Gräsantörmä 2, Espoo. We are glad to have Oracle Finland sponsoring the user group by taking turns as meetup host. Food and sauna will be available after the talk as is customary.
It's been a few months ago that I wrote a series of blog posts about Solon Voting. Solon is a project I started in July to implement cryptographically secure e-voting for direct democracy platforms, in particular Liquid Feedback which is used by the Pirate Party and other organizations in Central Europe. In the previous posts I already covered how delegated voting works, and how to divert the data flow of Liquid Feedback so that the voting phase could be handled by a cryptographically secure e-voting module. In the last post I then went on to look at requirements for secure e-voting. Those requirements are frequently referenced in this post.
Having laid out the requirements, I want to spend this post on briefly talking about the algorithms that exist for cryptographically secure e-voting. This is very superficial of course, it's intended to be layman understandable for those that don't really want to read the highly mathematical academic papers on the topic. If you do want to read academic papers, you can find lots of them on Google Scholar, just search for "e-voting" and you're all set for months to come! (No, I'm not qualified to recommend you any good papers. Just go and Google for something just like I did and if you find something interesting, let me know!)