neo-dzygn

Calling it Quits

Mark — Tue, 12 Apr 2005 19:03:34 -0400

After a long time, this weblog is coming to an end… I haven’t been posting much here recently, and certainly no longer pieces. From now on I’ll be posting those at Novemberborn. I’ve set up two feeds there, one for links and one for all text entries. Right now they redirect to delicious feeds, which creates the crazy circumstance that the Atom feeds you think you are loading are in fact RSS 1.0 feeds. That’ll change once I get a proper app running on Novemberborn though. (No promises on that.) So, go and subscribe to those feeds. There are some goodies in them already (namely this and this from the meeting of last Sunday). See you on the other site!

Sunday, April 10, Utrecht

Mark — Fri, 18 Mar 2005 11:40:47 -0500

And there’s another one coming up! Sunday, April 10th, in Utrecht. We’ll be meeting at 1pm at Utrecht Central Station, after which we’ll hopefully (it depends on the weather) go find a nice spot near the Dom. For more info and signing up see the wiki, spread the word, and be there!

Why Mozilla Memory Leakage is Not That Bad

Mark — Wed, 16 Mar 2005 14:51:14 -0500

Today Anne linked to an article on Mozilla.org: Using XPCOM in JavaScript without leaking. This article explains that, indeed, you can create memory leaks in Mozilla by using closures. However, the leaked memory will be collected after the document is closed (e.g. you load a different page):

(…) neither the element nor any of the properties nor any of the objects reachable from those properties can be freed until the document is no longer displayed.

Basically this means that you won’t run into the memory leakage issues IE suffers from. You can optimize your code though to prevent memory leakage for JavaScript objects which are no longer being used. Personally I don’t think this is much of a problem, unless you are developing a heavily used web applictaion which will stay open for hours. This also means that Event Cache cannot be used to optimize memory usage in Mozilla, unless you create specific caches for specific pieces of the code.

SxSW 2006

Mark — Tue, 15 Mar 2005 20:25:57 -0500

According to Mike sIFR was all the rage during SxSW. Also, Mike’s been telling me I should really go next year. Well, I don’t know what my life will be like in a years time, but I’ll certainly try! On a related note, JavaScript is the new black, and some panels on the 2006 conference on the subject would be really interesting…. ;-)

Noise

Mark — Fri, 25 Feb 2005 17:32:25 -0500

Mind Hacks, page 109:

Having evolved to cope with noisy internal signals gives you a more robust system. The brain has developed to handle the odd anomalous data point, to account for random inputs thrown its way by the environment. We can make sense of the whole even if one of the parts doesn’t entirely fit. […] “Happy Birthday”, sugn down a crackly phone line is still “Happy Birthday”. Compare this with your precision-designed PC; the wrong instruction at the wrong time and the whole thing crashes.

Our brains are designed to work with noise; it sometimes even adds noise itself. This, of course, does not apply to computers: the processor is designed to handle instructions - it may be fast, but it’s dumb. But if our brains are noisy, does that mean that a noisy programming language will be easier to work with? Or at least, will it be easier to learn? How many typos have you made over the years, which resulted in fatal errors or mindless debugging? What if it would have worked? There is a programming language - to use this as a generic term - that is noisy: HTML. Actually the parsers allow for noise, they are capable of extracting the intention of the writer in the same way as the brain is capable of filtering signal out of noise. And even though there are no real statistics on this, this very feature of HTML parsers has likely speeded up the adoptation of HTML and thus of the internet. If an eleven-year-old kid can make something which resembles a website, even though his code isn’t valid, that encourages him to learn more. And along the way he learns more about programming, learns different languages, meets new people, buys Mind Hacks and then writes this. But I digress. If we want to allow for noise in our programming languages, if we want to make them more human, how would we do that? Fixing things at compile time is hard: the wrong guess results in unexpected behaviour. However this is how the brain works (although comparing the brain to an interpreted language would probably be more apt). Through evolution our brains have learned to make better guesses, and to use new data to improve it’s guesses. Computers, on the other hand, can’t do this: the processor may be fast, but it’s still dumb. Therefore we may want to use the potential of the brain for improving (or verifying) the guesses. Which means we need editors which can handle noisy input, much in the way that HTML parsers allow for noise. Which also means that the editors need to learn from “knowing” which guesses were correct and which were not. Let’s take this Python code:

foo = ["hello", "world
def bar():
  print foo

I have made two mistakes here: I haven’t finished the string world, and I haven’t finished the list. An intelligent editor though could have known this: strings started with one quotation mark do not contain new lines. Therefore it has to end at that line. And a function cannot be defined inside a list, therefore the list has to end after "world. The editor could have fixed this code and directed my attention to it for verification. The result is that my code contains two bugs less, and hopefully my mind will have learned not to make that mistake again. Actually word processors allow for noise already. If you start a sentence without an uppercase letter, Word will change it into one. If you type three periods after each other, Word will convert it into one character. Agreed, at times Word isn’t very intuitive, but I’d like to see more software like this.

Event Cache

Mark — Tue, 22 Feb 2005 19:26:18 -0500

Since Novemberborn doesn’t have a feed yet… Event Cache.

Spreading Viruses

Mark — Sun, 20 Feb 2005 17:49:09 -0500

A Bluetooth virus has been spreading on mobile phones. Read more about it on Yahoo! News. (Seriously, read it. I’ll wait.) I’m wondering if viruses like these can be used to simulate the spreading of real viruses. The Bluetooth range can be compared to the time an aerosol virus survives in the air, the type of phone to the immune system, and the time before the virus is activated (as it requires a reboot of the phone) as the incubation period. Interestingly enough the virus took eight months to reach the USA from the Philippines, that’s quite some time!

WordPress 1.5: Don't Update...

Mark — Wed, 16 Feb 2005 14:02:34 -0500

… the dates on existing items! This is seriously annoying me as I see feeds with over ten entries which are just “updated”. Bah.

More sIFR News

Mark — Tue, 15 Feb 2005 19:16:01 -0500

Thanks to the fine, fine TextDrive staff there’s now a support forum for sIFR. In other news, Six Apart released their new website which uses sIFR (RC1 though). And finally there’s The Globe and Mail which is using sIFR now on the individual article pages. And if that wasn’t good enough, I’ve heard that another big site will be redesigning with sIFR soon… stay tuned!

Television Programme Soundtracks

Mark — Mon, 14 Feb 2005 19:33:06 -0500

This is something I’ve noticed several times now: soundtracks for television programmes (such as newsitems) have an eery relationship to the content of the programme. For example, today I heard NY Excuse by Soulwax. The song is about an excuse to someone who is paying…

This is an excuse that we’re making. Is it good enough, for what you’re paying?

The newsbit was about the Kyoto Treaty, global warming and how the USA didn’t do anything to lessen it’s contribution to worldwide pollution.Gives a whole different interpretation of NY Excuse, eh?