imagiBlog

The 24th of August sees me starting a part time music making course. It’s something I’ve wanted to do for a long time. My singing classes have taught me some of the basics and I see this as a continuation. My tools will no longer be breath but:

• digital performer
• logic pro
• reason
• kontakt naitve instruments

I am curious though as to whether it turns out to be like Beardyman:

I’ve been browsing some journeys on the Bahn website and decided to see just how far it’s possible to travel. Quite far is the answer. All the way to Peking on the Trans-Siberian railway. Basically Munich - Moscow, Moskow - Peking. Quite a nice adventure if you have 181 hours to kill - 8 days of being on a train!

The team has been jamming away on a great mobile client, location butler and website.  And now has a blog too.  Read all about location changing everything at blog.buddycloud.com.

Imagine swimming 5269 kilometres down the worlds most deadly river.

1) What were the biggest challenges you faced on the Amazon swim?

The biggest challenges were:

—Dealing with pirates; trying to not come into their hands.
We tried to go through their territories unnoticed, and use local people and their knowledge to help us.

—Piranhas, snakes, spiders, candirú, bull shark or other animals which make unpredictable attack; you have to be ready all the time if any piranha attack you. We had some buckets of blood ready in case of emergency, to distract the piranha and get them away from me if necessary. We saw a deadly bushmaster snake, but luckily I didn’t step on it. If I had stepped on it I would have been dead in less than an hour.

—Malaria, dengue and other unknown infections I could easily get in such a water/jungle environment. It looks like I have an “iron” body and very good immune system.

—Floating debris; I tried not to touch any of the debris floating downstream as it might carry a snake, spider, red ants or any other poisonous animals

—Peeing; I didn’t pee into the water straight as this attracts a very dangerous fish called the candirú, which lodges up human orifices with a razor-like spike and then sucks your blood. I was peeing all the time through the wetsuit.

More on Tim Ferris’ site.

I work with helium (homepage) on a daily basis and wonder if this is how he goes to this type of party?

I was just checking out my network’s traffic prioritization this morning and realised I spent most of yesterday on the phone. VOIP traffic is marked as red on the graph:

Most of these are also international calls from my mobile phone. My monthly phone bill comes in at around 30€. (rental, some SMSs, 100 minutes and 10€ for internet access).

I’ve setup my mobile to, by default, make all calls via VOIP. These calls then go out via the cheapest provider for each route. The simplest of which are my family calls. Extension 103 reaches my mother in Chelmsford, 106, my sister in Scotland and, 108 my brother in South Korea. Other calls are then sent either via a VoipCheap trunk or through a Truphone trunk that I have terminated on my VOIP server.

For inbound calls, I have the following numbers that will reach me, where ever I am:

US: +1 425 906 3145
UK: +44 20 7043 6756
Germany: +49 894 2095 5854

I went through a lot of teething pain at the start setting everything up but, after a year or so, things just work. At some point I’d like to add ENUM peering to the setup so that voip nodes stay voip nodes and voice traffic never touches the legacy PSTN.

We’re back.  Here.  Welcome

Twitter has been having scalability problems. No surprise. Their architecture is based around pumping all data into a DB and then polling the DB. This is nuts. They are asking a DB to act like a router, something that it is pretty bad at doing. Putting a DB into the flow IS THE PROBLEM. It’s not the language, it’s not politics, it’s not even about friendships or past contributions to a community.

Remove the DB and rewrite, using a messaging protocol like XMPP. Send the messages directly to the correct nodes or clients and *only* if the nodes are off-line, store in a DB.

There is an O(n^n) problem here when users send messages to every other user through a database. If you replace that with the idea of subscriptions and use a decent messaging protocol, the problem goes away.

Relational databases are not the solution to all problems. And if necessary stick with Ruby for the presentation layer.

Another great xkcd cartoon.

As a kid I’d walk (my bike tire always had a puncture) up to Kloof’s library and either read Rolling Stone magazine or an Usborne book.  My favourites were the Usborne Books of the Future.  I’d sit there for hours absorbing the detailed panacea that was life beyond the year 2000.  It all seemed so wonderful compared with the day to day reality of living in a small suburb of a despised country. I remember getting mad for being born “too” soon and willed time to run quicker so I could begin enjoying my “Home of the Future”.  In it I was promised amongst other things, a giant sized TV (but not thicker than 5cm), the ability to work away from the office using faxes to communicate and a video disk to record TV.  Or course all this was powered by “sunshine power” (I guess solar power hadn’t caught on yet).  And when I got bored of lounging around the house I could take a spin in  a jet powered by liquid hydrogen travelling at mach 3.

And then I’d begin my 30 minute walk home wondering how it would all turn out and what I could do to speed things up.  I wanted to be ready. And once I returned home I’d ask,
“Mom, when will we be in the future?”