scribbles

The day monkey outraces a nitro fuelled engine

Anyone who is following the long benchmark javascript race between browser engines probably has noticed that for a first time since these particular records began mozilla's engine has crossed the daily finish line faster than one of the competition. Today Jaeger + Trace monkey cross breed is 1ms faster on the v8bench circuit.

A look at state management in http

HTTP is a stateless protocol. This fact has confused and tripped many aspiring web developers. Mostly stateless. It was stateless until Netscape, back in the misty days of 1994, baked cookies and released them for public consumption. Later the Internet power mind, IETF, published the standard baking recipes in their RFC 2109, followed later by RFC 2965, titled "HTTP state management mechanism".

The standard is clear and straight forward. Not surprisingly, it is a translation to network protocol language of one of the most widely used approaches of pure functional programming to managing state - when you have to care about state, thread it. In this post I'm trying to transcribe it. For my amusement, public confusion as well as for brevity I will use haskell like notation when trying to present the modelling of the utility of the http cookies as a carrier of the http state.

Karmic Koala on Aspire One

Ubuntu Karmic Koala is out for a bit. I've been running it for a week on my Aspire One netbook and so far have only good impressions.

The distribution upgrade went smoothly. I'm not surprised. Its Debian genes show reliability of upgrades. Yes, there were reports of upgrade problems on the interwebs, but so far as I understand they were related to binary blobs, i.e. closed source drivers and such, which is not surprising - it is hard to figure out whose responsibility it is to make them work properly - the infrastructure of a linux distro is very different from that of Windows or Mac OS X. It is unclear whose job it is to do trigger the updates if they were not handled by the default install in the first place - it is a very murky territory usability wise. But that is becoming a rather off-topic rant.

Learning to speak - erlang style concurrency in haskell ( part II )

A second installment of my attempt to code erlang-style concurrency abstraction in haskell. The effort in part I, was a bit short of the mark. Here I try to address some of the shortcomings, while leaving others open.

The main problem was that the receiver could escape outside of the process, which can cause various hard to debug mayhem. What will happen if two different threads receive data from the same channel? Yes, it might be intentional, but you could always duplicate a channel for that. What if it is a bug? What if it is a piece of malicious code? Better safe than sorry.

Learning to speak - erlang style concurrency in haskell

I'm on a learning haskell journey. But reading someone else's code and thoughts while educational is not that enlightening. Anyway, to cut the long story short:

  • I (still) want to see what this haskell thing is all about
  • I need a moderately complex problem to get a feeling of the haskell type system works, face the dreaded IO, while not wasting too much time
  • I need a decent actor style abstraction for some social/population based methods experiments I'm into

So this is how ended with Why not try my hand at erlang style concurrency. The best thing about it is that it aligns nicely with an individualistic view of the world. I can write sequential code to do something, which from time to time communicates with the rest of them, while the rest of the time doesn't really care.

Erlang implements lightweight processes with asynchronous messaging. The cool twist it puts on it is having reception guards - if a message is not matched by the guard conditions it stays in the mailbox (channel), and the rest of the messages are scanned. The first matching message is removed from the mailbox, the remaining messages are left in the mailbox in arrival order.

software patents, or my personal insights

Up until now I was avoiding putting my thoughts on 'paper', but here we are. My instincts simply say Restricting knowledge distribution and use is wrong. Some might say this makes me a communist devil, anarchist or whatever other epithet is currently cool in their circles. Let's avoid that for the time being. These scribbles are probably not 100% correct. But the ideas are what matters anyway. And will you find a difference from a bird's eye view?

Obviously this is a strong social issue, as in it reflects a growing concern of the society as a whole. The society as the human beings represented by a state, like UK, USA, France, Bulgaria, or groups of states like EU, UN, ... Some long time ago patents were introduced by the British Crown in order to give a temporary monopoly to inventors, so that they can protect and exploit their knowhow, while making the knowledge (their knowhow) public. This was a significant social issue. This way knowledge was immediately becoming exploitable by the society. People could benefit from the abstract knowledge or the principles behind the patentable invention. These principles were not patentable at the time, only some of their defined applications - the invention, machines, products etc... The monopoly lasted for a relatively short period of time. Longer than it would take at the time to reverse engineer an invetion and set up production of a competitive product, but not by too much. This is important, since timescales, im my opinion, are important when trying to rationalise the costs of patents to a society.

out of the (php) loop

inspired by Verity , my urge to display my writing talent and random buzz on the internet

This conversation was (allegedly) overheard in a nursery, which won't be disclosed to avoid litigation

Write a standard php loop on the nursery blackboard

Come on, can't be bothered. Are you joking?
foreach( $array as $key => $value ) echo "$key $value";

Wrong! Don't you ever learn proper language usage

What have I done NOW?

Hey Jess, hope you see this in time ;)

Happy birthday Jess, hope you delve deeper in your obsession with men with long hair, or your other (inked) ones for that matter.

And see you down the pub.

Overcomplicated design pattern implementations

I know that I often express myself in an overcomplicated way. I hope I don't do that in code. I'm really amased how people overcomplicate stuff in their minds. This particular rant is triggered by me wandering around the net flicking design patterns in php web pages.

Guess what? They are complex beasties. With multiple hierarchies of classes doing loads of complicated stuff over a lot of lines of code.

Take a look for example at Observer Pattern. Actually not a very bad code. Still on the big side. Still maintaining the dual observer/observed 'magic' separation. Compare it with this hooks implementation, the code at the bottom of the page. The latter is designed for a more complex scenario, i.e to mimic aspects in php, but still manages to be simpler.

But the best example, I suppose, is how do you code a strategy pattern in php? A typical code would be something like Strategy Pattern. Not a bad code. Well described, documented, etc... But wait! A startegy is:

The Strategy pattern defines an object that represents an algorithm for a particular task.

But algorithm == function (or method), isn't it? So the variable function problems is $func = "a_function"; ... $func()

I think this should do it. Yep, for complex strategies you might need to compose stuff, but still there are surely better ways, rather than having these long hard java/c++/... inherited ideas.

Powered by Drupal, an open source content management system