For my bachelor’s thesis at the University of Groningen I investigated ways of improving this experience of editing Wikipedia. Why doesn’t it already use a visual editor such as Google Docs? This has everything to do with wikitext, this language you see when editing a page. Wikitext is the language in which pages on several wikis, including Wikipedia, are stored and edited. Once you save a page, this wikitext gets translated into HTML, the language used by web browsers to show a page.

Wikipedia was founded in 2001, just after the internet bubble, but before people were speaking of a Web 2.0. Back then it made sense to use such a language as wikitext. Microsoft Word already existed, but an online variant simply wasn’t there yet. The techniques and standards for such an interface on the web were not developed yet, and only some early experimental designs were being tested. It was possible to use simple text boxes in web browsers, though, so initially this was used to edit pages. To be able to apply some markup to pages, some codes were introduced, such as '''bold''', ''italic”, [[link]], and == heading ==. These codes were translated into HTML by means of substitution: first occurrences of ''' were replaced by <b> and </b>, the HTML tags denoting bold tags. Similarly the other codes were replaced by their harder to read HTML equivalents.

Because Wikipedia was growing rapidly, it became necessary to extend this list of codes to make common tasks easier, such as maintaining lists of references, including info boxes placed at the top right of pages, and so on. These additions were essential to Wikipedia’s volunteers, but at the same time the wikitext language became ever more convoluted.

Now, however, people are expecting something better than a huge text box. To make it easier for potential volunteers to contribute, it is necessary to offer an interface that is widely known, such as a visual editor. On the other hand, it isn’t desirable to get rid of wikitext completely, as this would alienate tens of thousands currently active contributors, who are used to this language. A better solution would be to still store the pages in wikitext, but to offer both ways of editing: visual editor for new users, and traditional wikitext editing for existing users.

However, building a visual editor on top of wikitext is easier said than done. This is because of the way wikitext is transformed to HTML, with a number of subsequent substitutions. A common way of building a visual editor on top of a language, is by using an intermediate representation of the text, called a document tree or syntax tree. Such a tree represents the page in a hierarchical way. A page contains paragraphs, paragraphs contain sentences, and sentences contain pieces of text, links, media, and so on. Alas, wikitext can’t be described by such a hierarchical model, because these substitutions make sure there is no such thing as wrong wikitext. There are even substitutions that fix common mistakes, such as '''bold [[link''']]. This is equivalent to '''bold [[link]]''', which has a defined hierarchy: the link is inside the bold text. In the former example, this hierarchy is not present: the bold text ends before the link element is closed.

While this is a silly example, there are more complex cases, which are widely used in Wikipedia. There are people working on a intermediate representation that does allow for these kinds of cases, but as this is quite difficult it may take a while.

For my thesis I investigated if it’s perhaps possible to build a different kind of interface instead of a visual editor, which is both easy to use and easier to implement on top of wikitext. Eventually I arrived at a compromise: users get to see the same page when editing as when viewing, but they can’t edit it directly. Instead, there are some explicitly marked elements on the page that are editable, such as sentences, paragraphs, lists, info boxes, etc. Such editable elements are marked by either a light blue background colour, or in case of larger elements such as paragraphs, by a bar at the left of the element. When a user moves the mouse over such an element, it lights up in a darker colour, indicating it can be clicked.

Once clicked, a popup appears with the original wikitext for that element. Once the user has edited the wikitext and confirmed the change, the popup disappears and the page is updated with the new content.

Now, the user still has to edit wikitext, but in much smaller quantities. The idea is that there are not so many complex codes inside a single sentence or even paragraph, which makes it a lot less scary for potential volunteers to play around with a page. Also, the direct feedback when editing a small piece of wikitext may help in this, as it immediately clear what effect the changed wikitext has on the page.

The big advantage is that it’s not required to use an intermediate representation when generating such an interface. It’s only necessary to know for the editable elements to which parts of the original wikitext they correspond. For example, if it is known for a certain paragraph in the HTML output to which exact lines in the wikitext it corresponds, then we can show this wikitext when clicking the paragraph on the HTML page, and replace it when the user changes this wikitext.

To get the correspondence between wikitext and HTML I use a trick: annotation. Before the wikitext is transformed to HTML, I add some codes to it to mark some positions. These codes are chosen in such a way that they are not transformed into anything else, and they are also all unique. They are placed around basic elements, such as paragraphs, sentences, in fact everything we want to make editable and is easy to recognise. For every added code, we also record the exact position of the code inside the original wikitext. After this, the annotated wikitext is transformed into HTML, and the codes survive this transformation. Finally, the codes themselves are transformed again to make a valid HTML page (see Example 1). This way, every editable element gets a unique identifier based on the code it belongs to, so now it is possible to look up positions in the original wikitext whenever an such an element is clicked.

This doesn’t directly solve the problem of hierarchy, as HTML itself expects a strict hierarchy on elements. In the transformation this is fixed for the wikitext, but not for the added codes. This means that the example from above is still invalid:

<sentence-0>
<bold-0>'''bold <link-0>[[link'''</bold-0>]]</link-0>
</sentence-0>


After all, link-0 has to be closed before bold-0 is closed. This time, however, there is a remarkable simple solution: we can just remove all the conflicting codes! If it’s not possible to edit a single link in some cases, this doesn’t really matter, as it can still be changed by editing the entire sentence:


<sentence-0>
'''bold [[link''']]
</sentence-0>


There is always an element at a higher level that doesn’t conflict with any other element. In the worst case this means the highest element — the entire page — has to be edited, as that can never conflict with anything else. This is rare, however, and in most cases editing a single sentence or paragraph suffices. Such a fallback mechanism for weirder cases of wikitext does not exist for a visual editor.

You may wonder whether or not such an interface in which the user still has to edit wikitext — be it a bit less — is any improvement at all. To test this, I’ve worked together with GRNET, a Greek research institute, to test this hypothesis. They tested my final interface with “real” users, to see whether it works or not. The results were mostly positive, users found it quite easy to do most basic operations. Complex tasks were still difficult for most users, especially because users tried to do things they were used to do with visual editors, such as dragging and dropping of elements. While this is a downside of such a new editing paradigm, it was great to see how most tasks became a lot easier.

Despite these positive results you won’t see this interface on Wikipedia anytime soon, as it’s not finished. In my thesis I describe all the algorithms and other ideas for finishing the interface, but as the Wikmedia Foundation recently started working on a true visual editor, I decided to put this project on hold for now. On the other hand, an editor like this has other advantages, such as being easier to use than one big text box for power users who don’t want to use a visual editor, or for newcomers who’d like to slowly learn to do more complex tasks. So who knows, perhaps one day you can use my interface to edit Wikipedia!

• Adapted from “Help, ik wil Wikipedia veranderen“, FMF Periodiek, #3 2011.
• Based on the bachelor’s thesis “In-line Editing: a New Approach to Editing Wikis“, Jan Paul Posma, University of Groningen, 2011.
• Implemented in the MediaWiki extension InlineEditor.

This first picture has been taken at my parents’ home. I used a star filter, which doesn’t really show, except for the reflection in the window. But this filter also gives the entire picture a soft look. Sometimes they have a dog at home, when friends are on vacation. In this picture, Niño can (barely) be seen laying in the shadow. This picture really shows the peaceful atmosphere that’s there.

I like this picture because it shows a typical state of my desk. I’ve used a bit of overexposure, so that the notebook is shown correctly, and everything else is brighter, which looks quite interesting!

This one is the coolest picture I’ve taken so far! Using only a briefcase to support the camera, and an extended shutter button, the timing here is remarkable. A few cars that were very similar approached me, so there is only one very bright line visible. I was also very lucky there was no traffic in the other direction, because now the background is very dark, which is in great contrast with the line. If there was traffic in the other direction, their headlights would’ve enlightened the background. The fact that it rains adds to the atmosphere by having great reflections on the ground.

This is a simple photograph of my friend Hans, but I really liked the colour contrast. He has a nice expression on his face, and the background is just right. Simply a decent picture.

This one has, again, been taken at my parents’ home, and I like the natural chaos that is displayed. A Harry Potter book on the table, some pillows missing or not straightened, the shadows falling in a weird way. It’s just how things are, nothing more, nothing less.

This is an interesting one, because it took a while to get it right. I noticed this bike before my house, and immediately thought about photographing it. The problem is, there are only a few moments each year, in the summer, when the sun is actually in the right position. I had to wait a few weeks, and when the moment was there, I took a few shots. Luckily it was a beautiful day, and the rusted bike with the grass growing through it, in combination with the awesome perspective, makes this one of my favourite pictures so far.

Because of the weird angle my dad’s lower leg is making, I wasn’t quite sure whether to publish this picture. Still, nothing can be totally perfect, and while this is one has great timing, a great expression and good lightning, the imperfections are what make it worthwhile to look at. The ball is mid-air, almost impossible to spot against the white background.

You might see a pattern of organised chaos emerging, and maybe that is the case. But I like this one most because it reminds me of the cool times at SCN. Experimenting with electronics is inherently chaotic.

When I was in Washington, D.C. for a conference, I took many pictures at night while touring the city. Most of them were miserable failures, but this one was unexpectedly great. This is one of the few pictures that looks way better in real life, as it was impossible to scan the moon properly.

A classic airport picture: I couldn’t let the moment pass! The huge amount of air and clouds in this photograph adds to a sense of space, which in this case I’d argue to be a good thing.

Decorating the Christmas tree! This one has been taken with a star filter, and with a shutter time of several seconds.

Let’s get into details! The system is running on Aleutia T1, which is a really nice, silent PC-ish thing. PC-ish, because the performance is not really up to todays standards, but on the other hand it’s quite cheap, really silent and comes pre-installed with Ubuntu. Cool! (However, I installed Windows XP…) I got mine with a SSD, which means that there are no moving parts whatsoever, therefore it can stay on 24/7.

Using a simple XAMPP setup, it runs my photoframed software mentioned in the previous post (demo, source).

The webcam setup is quite interesting. First I tried to plug the webcams using some USB extension cords. It was highly unstable, so now the PC is actually positioned in a cardboard box, lifted from the ground, so all the cables fit exactly.

Another issue with the webcams is having it stream, but also have it stream securely. A promising format seemed to be MJPEG: this is just like sending out JPEG frames as fast as the connection can manage. I run the following code to generate a MJPEG stream using VLC. The stream is only accessible from localhost for security reasons.


vlc.exe dshow:// :dshow-vdev="USB Video Device" :dshow-adev=none :dshow-size=640x480 --no-sout-audio --sout=#transcode{vcodec=mjpg, vb=512, fps=1, width=640, height=480}:standard{access=http{mime="multipart/x-mixed-replace; boundary=7b3cc56e5f51db803f790dad720ed50a"}, mux=mpjpeg, dst=127.0.0.1:8080/cam.mjpg}


The boundary thing is a code required for modern browsers to correctly recognize the data type. If you remove the IP-address at the end, you’ll allow anyone to watch the stream. Now the next proxy is to make sure only authenticated people are able to see the stream. I tried this using a PHP script which simply read the stream and echo’ed it (and some other variants). I also tried using the Apache proxy module. But both options have the same problem: as I have a terrible internet connection, I really need the last frame. Once a frame is transmitted, the new frame must be the most recent frame possible. However, all options I tried seem to cache the data, so you’ll see 1 second of recording spread out on, like, half a minute on the client.

In the end I just went with a simple script I found online somewhere, that reads exactly one MJPEG frame and spits it out as ordinary JPEG:


$boundary="\n--";

fclose($f);


Now you have to refresh the image using for example Javascript, so that’s fine too. The webinterface I’ve written for this purpose also features a slider to set refresh interval, which is pretty handy if you’ve got a shitty connection like myself. Also, this brings me to the home automation part, which is actually pretty brief. All devices in my room are plugged into a KlikAanKlikUit unit, and the PC’s got a TPC-200 interface plugged in, and a little bit of software does the trick (demo, source).

The TPC-200 interface comes with a DLL which has one single command: Send(id, value), with id being an integer and value a boolean. A simple executable wrapper, hacked together in VB, makes it easy to send commands from PHP, using exec.

The first room control breach has happened already: I used the inferior Apache Basic Authentication for the login procedure, and it turns out that sessions can keep open for a long period of time. Even when the server restarts during that time. I logged on the system on the laptop of a friend of mine, and 3 days later, he scared the crap out of me by playing with my lights. ;-) The PC restarts every night at 5am, so I’m still amazed that the session lasted that long.

Anyway, I quickly tracked him down using the access logs and we had a good laugh about it, but I still don’t trust the security anymore: the inside camera is pointed at the ceiling now… SSL and stuff like that will probably be secure enough, but if you’re considering building the same setup, don’t plug in your nuclear power plant.

Most of the original source code is lost, and the system doesn’t work well anymore, so I’m redesigning it. In a few months you can expect another blog post on this, but I thought a writeup of the old design would be nice.

It started with an old laptop. In an impulse I decided to see how quickly I was able to strip it until only the bare essentials were left. It was quite easy to disassemble it, and the wires were long enough to separate the display from the other components.

Once the laptop was disassembled, it was easy enough to go to the DIY store and buy some materials. With some careful measuring, patience and painting twice, the job was done in a few evenings.

To display the photos, a clock, and some RSS feeds, I used a PHP script by Tommy van der Vorst, running in a fullscreen Firefox window. It worked pretty well. After some modifications, it was used by myself and others for 3 years.

A few months later I stumbled upon this post on a forum, which describes how to easily hack a cheap home automation remote control to hook it up to a computer. There were sets available for about €20 to control lights and devices with a remote control. So I bought two of these sets. The first hack was to hook it up to ordinary lights that are directly connected to a power source, without a wall socket in between. The setup wasn’t very safe, but it worked.

Next, I followed the instructions on the forum post: hook up the remote control to the serial port, detect commands using LIRC, and send them back to the remote control. It worked fine on the computer, but the problem is that on laptops the serial port is weaker: it usually won’t give a nice and strong 12 volt signal.

The solution was rather simple: by hooking up transistors to every button, you can simulate a press of that button simply by putting a small voltage on the transistor. The easiest way to do this is by using the parallel port. Fortunately, the laptop was pretty old so this was no problem.

With some Visual Basic programming, the Microsoft Speech API and some PHP scripts it was possible to control the lights by voice and over the internet. Which is pretty cool. Unfortunately, I lost most of the source code, so I won’t be able to share it here. Right now I’m building a new version, and when it’s done I’ll share the code!

For now, I’ve started improving the PHP script that shows the photos, which I’ve dubbed photoframed. It’s pretty nice already, you can download and contribute to it on my github page. It even works perfectly fine in an iframe like the one below.

In a few months the new system should be up and running, so I’ll probably write another blog post then. Meanwhile, I invite everyone to look at the source code of photoframed and contribute. Or you can just leave a message in the form below. ;-)

In 2008 our class graduated, and we decided to hold a hippie festival. Unfortunately, it wasn’t as popular as Woodstock about forty years earlier, but still it was totally awesome! A few weeks ago I found all the video material of that day and decided to make a compilation. The first video is about the morning, giving an impression of the great atmosphere in the school. The second video is the show, which is entirely in Dutch.

You probably know balloon art: done by magicians or clowns, on the street or at children’s parties. Some german guys have taken it to the next level. They thought visualizing the structure of complex molecules would be an excellent job for the famous balloon.

In my final year at high school we made some balloon molecules, and our chemistry teacher absolutely loved it. So here are some hints if you want to do it too:

• Use a balloon-pump! You have to blow up so many balloons, you’ll get completely exhausted when not using a pump.
• Get enough balloons of the same color! Check out the photos, our first model looked more like a rainbow than an actual buckyball.
• Learn the knots and techniques and practice them! We had a lot of balloons popping because we didn’t know how to do balloon art exactly. There are excellent guidelines on how to do the knots and techniques on the site of the professionals.
• Have lots of fun!!

One of the coolest projects I have worked on resulted in the turning of heads when biking through the city, and was also a great challenge as it involves some tricky hardware and software. The result was pretty darn amazing though.

So this was a really cool project that took a lot of my time when I was seventeen years old. Do you know these gadgets that write text in the air? Ever wondered how they work?

It’s pretty simple, actually. There is a row of LED-lights that you swing through the air. Those leds alternate very quickly between on and off, in a very specific pattern. When you move the leds at exactly the right velocity, the pattern will become visible to the human eye, and you can actually read text or see an image.

You are able to see this text because your mind will stitch the images together, like when watching TV. It all happens so fast, that you won’t see the individual frames, but you see the image as a whole. Or in case of the TV, it looks like you’re watching an actual moving scene. This phenomena is called Persistence of Vision (POV), and quite useful when making awesome things. :-)

In theory it’s possible to attach a row of leds to the side your bike, and get the same effect as swinging it through the air. The problem with that is that you have to go fast. Very, very fast. Instead, there is something on the bike that has a much higher velocity than your forward velocity: the angular velocity of the weels.

Depending on the size of the weel and your forward velocity, you’ll get a fair number of rotations per second, enough to make it blurry to the eye. So why not take the row of leds, and put it in the wheel. Sure, you have to do some funky math to get a nice image, but it looks cool, right?!

But of course, it already exists: SpokePOV by the artist/engineer Ladyada (who, by the way, makes very cool things!). Lucky for me, those kits only come in one color. What could be cooler than making a full-color SpokePOV?

After carefully selecting parts – RGB-leds are expensive! – the drawing began. For this I usually use KiCAD, an awesome open-source electronics CAD program.

Designing the circuit board was a devilish job. The routing of all the lines to the leds took a lot of time to perfect, not to mention fitting it on a board that is as small as possible. A cool thing about Kicad is that you have an awesome 3d viewer. But a 3d model with missing components kinda sucks, so I drew a few models myself in 3ds Max.

All that done, the schematics were sent to Niels at MakePCB, who also supplied most of the components. And how awesome, a few weeks later an envelope with the circuit boards arrived. A few hours of soldering later, and the hardware was finished.

But the hardest part was yet to come: the software. Luckily Microchip supplied an excellent USB bootloader, which I tweaked a bit to use the leds as status indicators. The embedded software is all about performance: it has to be able to keep up with the speed of the weel. Therefore it was necessary to supply the program with an image in a format that is easy to decode, and small at the same time.

First, a computer program in Java converted a normal image to a rotational image using some simple trigonometry. Normally, when composing images, pixel data consists of 3 bytes per pixel: one for each color. Uncompressed, this took way too much space for a small PIC microcontroller. JPEG or PNG compression was not an option: way to complex to decode. So the color data was reduced to 1 byte per pixel: 3 bits for red, 3 bits for green and 2 bits for blue. Why the reduced count for blue? Well, there are 8 bits to the byte, so some color has to go down, and blue is the best choice as the eye is the least sensitive to that primary color.

To display the colors some standard techniques are used such as pulse-width modulation (PWM) and LED-multiplexing, which I won’t cover in detail. However, the decoding of the pixel data to 3 bytes is kinda interesting. The C implementation was too slow, so it had to be done by hand, in assembly. Using assembly for this critical piece of code (which is only a few lines long) improved the speed of the whole program by a factor 6.

TBLRDPOSTINC
MOVF TABLAT, 0, ACCESS			// Read TABLAT to WREG; WREG = RRRGGGBB
MOVWF CurrentPixel, BANKED		// Put WREG in CP (CurrentPixel)
RLNCF CurrentPixel, 1, BANKED		// Shift CP to left;    WREG = RRGGGBBR
MOVF CurrentPixel, 0, BANKED 		// Put CP in WREG
ANDLW 0x06				// AND WREG with 0x06;  WREG = 00000BB0
MOVWF PWM2_0, BANKED			// Put WREG in blue channel

RLNCF CurrentPixel, 1, BANKED		// Shift CP to left;    CP   = RGGGBBRR
RLNCF CurrentPixel, 1, BANKED		// Shift CP to left;    CP   = GGGBBRRR
MOVF CurrentPixel, 0, BANKED 		// Put CP in WREG
ANDLW 0x07				// AND WREG with 0x07;  WREG = 00000RRR
MOVWF PWM0_0, BANKED			// Put WREG in red channel

RLNCF CurrentPixel, 1, BANKED		// Shift CP to left;    CP   = GGBBRRRG
RLNCF CurrentPixel, 1, BANKED		// Shift CP to left;    CP   = GBBRRRGG
RLNCF CurrentPixel, 1, BANKED		// Shift CP to left;    CP   = BBRRRGGG
MOVF CurrentPixel, 0, BANKED 		// Put CP in WREG
ANDLW 0x07				// AND WREG with 0x07;  WREG = 00000GGG
MOVWF PWM1_0, BANKED			// Put WREG in green channel

The algorithm of the program is pretty simple: take the time of one complete cycle (360 degrees). This time is measured by using a magnetic switch, with a magnet on the frame on the bike. The time is divided by 256, and a timer is set to fire a function. This function will take the next pixels, decode the colors for all the leds (on the front and on the back of the device), and feed this color to the leds using PWM and multiplexing. Result: people watching you as you go down the street at night. Mission accomplished.

As you can see on the photos, I ended up mounting two boards on the wheel. Otherwise you had to drive quite fast.. The synchronization of the two boards happens automatically, because they will both align to the magnet. Except when accelerating or slowing down, both boards remain in sync quite well.

I managed to get this project approved as an assignment for school (‘profielwerkstuk’), so the documentation is quite extensive. It can provide an interesting read if you like to know more about the used components, programs and techniques. You’ll also read about some major design decisions. It’s only available in Dutch though.. Download.

There are still a few un-soldered boards laying around here, as well as all the hardware designs and software code. However, I won’t post it here as many things are unfinished and not at all ready for production. Also, the parts are pretty expensive, especially when taking into consideration you need at least two boards per wheel. If you’re interested though to take this to the next level though, feel free to contact me and we can talk about it. But be warned: a lot of work needs to be done to have it work really well.

Update: it seems that around the time I built this, some other guys also got the idea and commercialized it. Their simple version does not support images or synchronization of the units, but looks awesome nevertheless. Their pro version is very cool and even supports animations and on-the-fly wireless programming but is priced at thousands of dollars. It seems though, they have done a great job! :-)

My writing skills are average, as is my knowledge of the English language. So if you have suggestions of any kind, please, don’t hesitate to leave a comment!

That being said, let’s look at a fun little project I worked on about two years ago. I had a bet with Marcel Vlastuin that I could produce a self-enumerating pangram. This is an example of such a pangram:

This sentence contains three a’s, one b, three c’s, two d’s, thirty three e’s, seven f’s, one g, six h’s, ten i’s, one j, one k, one l, one m, twenty four n’s, sixteen o’s, one p, one q, nine r’s, twenty six s’s, seventeen t’s, five u’s, five v’s, four w’s, four x’s, four y’s, and one z.

Pangram, the word coming from the greek pan gramma, literally means “every letter”. The best known pangram is without any doubt “The quick brown fox jumps over the lazy dog”. But I had to make a self-enumerating one, without doing research to it, and with my name in it.

For this purpose I built a small program that could generate such a pangram. It would take the previous sentence, count the characters and generate a new sentence. When it got the same sentence twice, the job was done. But there was one problem: many times the program would alternate between a small set of sentences, and never get out of this loop. Therefore it was necessary to add a bit of randomness. The original sourcecode was lost when my old laptop crashed, but as I sent Marcel the generated pangrams, they were still in my mailbox! The pangrams are in Dutch.

JP vond deze zin, die vier a’s, twee b’s, drie c’s, acht d’s, zevenenveertig e’s, drie f’s, vier g’s, drie h’s, zeventien i’s, drie j’s, een k, twee l’s, een m, twintig n’s, twee o’s, twee p’s, een q, acht r’s, twintig s’en, vijftien t’s, een u, elf v’s, zeven w’s, een x, een y en zeven z’s bevat.

Deze voor Marcel gegenereerde zin omvat drie a’s, een b, twee c’s, vijf d’s, eenenvijftig e’s, zes f’s, zes g’s, een h, zeventien i’s, vier j’s, een k, vier l’s, drie m’s, tweeentwintig n’s, vier o’s, een p, een q, tien r’s, twintig s’en, elf t’s, een u, elf v’s, vijf w’s, een x, een y en zeven z’s.

Jan Paul Posma is trots op deze zin omdat die acht a’s, twee b’s, drie c’s, zeven d’s, negenenveertig e’s, vier f’s, tien g’s, drie h’s, tweeentwintig i’s, vijf j’s, een k, twee l’s, drie m’s, negenentwintig n’s, vijf o’s, vier p’s, een q, acht r’s, zesentwintig s’en, eenentwintig t’s, twee u’s, negen v’s, negen w’s, een x, een y en vijf z’s bevat.

In deze zin staan tien a’s, twee b’s, vier c’s, zeven d’s, eenenvijftig e’s, vier f’s, zeven g’s, vier h’s, drieentwintig i’s, drie j’s, een k, vier l’s, een m, achtentwintig n’s, vier o’s, twee p’s, een q, twaalf r’s, vierentwintig s’en, achttien t’s, twee u’s, elf v’s, acht w’s, een x, een y en zes z’s, en is bovendien door Jan Paul gegenereerd!

Thus winning the bet, a fine dinner. Thanks Marcel! I guess that concludes this F1rSt P0st!!!11oneone42, thank you for reading it. :-)