I ran into an interesting little subversion problem earlier. I was trying to commit a change, and the commit just seemed to hang indefinitely. I couldn’t sent an interrupt, and eventually resorted to killing the process. I tried all sorts of command line options in case there was an authentication problem – with no luck. I then thought I had made a mistake when switching my working copy to a different branch. I checked the logs on the server to find nothing pertinent; it seemed as though svn didn’t get as far as taking to the server. At a loss, I thought there was nothing for it but to run the command with strace. Bingo!
Strace showed that subversion reads from /dev/random as part of the commit, and that’s where the problem seemed to be happening. After doing some research, I discovered that /dev/random generates random numbers using the so-called entropy pool. This entropy pool is just random bits of noise generated from things such as mouse movements, time between keystrokes and so on. For whatever reason, on the client server, this entropy pool was empty! Using /dev/random is cryptographically more random than using /dev/urandom; and /dev/random blocks when the entropy pool is empty, whereas /dev/urandom is non-blocking. Moving /dev/random to /dev/random.old and linking /dev/urandom to /dev/random solved the problem. There may be a better solution to this, and depending on your cryptographic requirements it might be better to find an alternative, but this did the trick for me. One svn commit later and all was well.
I’ve had some exposure to database replication through PostgreSQL/Slony. I’m reasonably familiar with master/slave replication but in the last few days I’ve had to get my hands dirty and grok multi-master replication with MySQL, specifically with two MySQL servers in master<->master mode. Although conceptually it’s not a significant leap from simple master/slave replication the added layer of replication in both directions made my brain melt a little bit at first. Now that I’ve got my head around as much as I need to, I’m writing this as a gentle reminder should replication screw up again!
A month ago I handed in my resignation to Diet Chef, and this past month has certainly flown by. Today I start a new job with Maglabs.
I thoroughly enjoyed my time with Diet Chef and will miss my friends there, and with any luck we’ll keep in touch. I learned a lot about marketing at Diet Chef and it was a very different environment to that which I became accustomed to at Valley Technology; but different in a very positive way.
My time there made me realise that I’m very much a back-office PHP coder. I enjoyed the varied challenges there but my passion lies more with getting something awesome working well rather than making something look beautiful (in no way a criticism of my previous employer, far from it, I just want to be more focused in my work); I’m no designer although I definitely believe any design has to be functional and usable. I want my work playground to involve more complicated coding challenges, maybe mashing cool APIs together now and then.
With a wedding to Jo to save for and who knows what in the future I also have to be realistic and that unfortunately means being financially motivated as well as looking for the right career fit. I’m looking forward to being able to fulfil both these needs with Maglabs. With that I bid my friends and colleagues at Diet Chef farewell and the very best of luck and success in the future, while also hoping for the same for myself in the future.
The Yahoo! Query Language (YQL) is a fantastic web service from the Yahoo! Developer Network (YDN) that can dramatically speed up development time if your application involves requesting data from multiple disparate web services and somehow combining that data. You can think of YQL as a gateway API that allows you to quickly and easily select, filter and combine data from across the web.
Those who are familiar with MySQL may be used to terminating a query with ‘\G’ to have the client output the query results vertically with each column/value pair a line at a time. There is in a equivalent in PostgreSQL too. The psql client uses ‘\x’ to toggle vertical output, and ‘\g’ to send the current buffer to the server for processing. To get the same effect in psql as ‘\G’ in MySQL, just end your query with ‘\x\g\x’.
