Earlier this week while under the influence of being stressed out of my mind being CEO of a startup and watching way too much Sherlock (there are only three episodes, watched every one at least four times) I decided that it was time for a new hobby.

The only requirements for said hobby were:

• mentally very bloody stimulating
• doable in polynomic time (rules out things like ‘invent cold fusion’)
• learn something new

Obviously the only real solution to this problem is designing a new programming language and making a compiler or interpreter for it. Sure, the other obvious solution is to find a cool opensource project and become an Important Contributor ™. But I’m gonna do that anyway, contribute code I’m developing at Preona to opensource projects that is.

No I needed something completely different. Totally unrelated to my daily work and so on. Making a language it was!

Because @skatey reminded me of Monkey Island earlier that day the language is called Murray.

Murray is a talking demonic skull in Monkey Island.

This led to some interesting design ideas. Since obviously the language needs to be inspired by the demonic talking skull … so let’s make the whole thing behave like you’re talking to the computer rather than programming.

Oh also I wanted it to run on Python and be inspired by Lisp, but without parentheses. No parentheses if at all avoidable!

Another big design goal is to eventually write a Murray-to-Python compiler in Murray. Right now I’m writing it in Python.

So let’s recap the primary design goals

• functional
• no parentheses
• as akin to talking as possible
• can compile itself
• Turing complete

The hello world

The hello world turns out to be pretty simple.

say "Hello World"

Compiles to python and works. And no, no I’m not just using a regex to replace ’say’ with ‘print’. I actually wrote a parser for this thing.

Everything that sticks together is considered a paragraph of code and will essentially evaluate to a big function composition like so f(g(h(x))). Ok? ok.

So when I write this:

say "hello world" say "meow" say "hai"

It compiles into something a bit like so: say( “hello world”, say(“meow”, say(“hai”)))

So the output becomes:

hai
None meow
None hello world

Which doesn’t seem too logical, the None should go on the other side … I should fix this.

But anyway, the None is there because ’say’ doesn’t return anything, we can fix the wonky output like this:

say "hello world". say "meow". say "hai"

What magic buffonery is this!?

Well the dot is another function again and Murray can understand one-char functions even when they are attached to something else. The dot is a simple function anyway, it sort of ‘destroys’ output by returning an empty string so it doesn’t get in the way later on in the execution stack.

But what about them code paragraphs I mentioned earlier? Well their intended use eventually is to define ‘functions’, but I haven’t figured this out too much yet. Right now they just do this:

say "meow1"
 
say "meow2"

This compiles into two distinct function calls so the output is like this:

meow1
meow2

Anyway, that’s all I’ve got figured out so far. It’s only been a few days since I started working on this and there’s a long way still to go. Suggestions very welcome, contributors appreciated, everything is open source and living on github. Just fork and ping me about it if you’re interested

Oh yeah, this Hello World is strange because it took me writing a compiler and making up a lot of stuff.

Related articles by Zemanta

• I Want A New Programming Language (kirkwylie.blogspot.com)
• Is Lisp secretly the world’s most popular programming language? : programming (reddit.com)
• Re: Revenge of the Nerds (paulgraham.com)
• Lisp sans (((paren-theses ((hell))))) | Lambda the Ultimate (lambda-the-ultimate.org)
• lice! : On Parentheses (licenser.net)
• The Clean Coder: Why Clojure? (thecleancoder.blogspot.com)
• Why Lisp Still Hasn’t Won – O’Reilly ONLamp Blog (oreillynet.com)
• Help me find something new to do with my time (ask.metafilter.com)

Officially this is something that cannot be done. Or rather that shouldn’t be done. When you look at the google appengine docs on “uploading to blobstore” this is what they have to say:

Blobs are useful for serving large files, such as video or image files, and for allowing users to upload large data files.

To prompt a user to upload a Blobstore value, your app presents a web form with a file upload field.

So ok, obviously the official documentation isn’t of much use here since it only talks about letting users upload files. But I needed something different. I needed to fetch an image from an url (gotten by intricate means, different story) and store it in the blobstore so it could later be served to many users. Obviously since file access isn’t permitted on appengine the only choice left was storing the file in the blobstore.

Naturally someone else has had this problem before right?

No. There are no solutions I could find online. None. Nada. Zilch. Niente.

After a few hours of hacking a week or so ago, however, I got it working.

Essentially the solution is to fake a form post to the blobstore url the API creates. An interesting gotcha is that a redirect happens. Initially I thought I was making the form post right back to my application, but apparently you’re first posting to the blobstore, then the blobstore posts back to you. For some reason I couldn’t keep the associated meta-data to go through with the request so there’s an ugly-ish workaround that happens.

Another thing that’s important to note for this tutorial/howto is that I am using django-nonrel and that the initial event that starts the process is triggered by appengine’s task queue.

The howto

First, these are all the imports I’m using, there’s quite a few, so heh

from django.http import HttpResponse, HttpResponseBadRequest, HttpRequest
from django.views.decorators.csrf import csrf_exempt
from django.conf import settings
from django.core.urlresolvers import reverse
import simplejson as json
import urllib2, urllib
from cStringIO import StringIO
 
from google.appengine.api.urlfetch import ResponseTooLargeError, DownloadError
from google.appengine.ext import blobstore
from google.appengine.api import urlfetch
 
from forms import ArticleProcForm
from models import Article
from lib import ImageExtractor
from lib import urllib2_file
from lib.urllib2_file import UploadFile
from lib.decorators import form_valid

First thing that you’re going to need is the function that starts the whole process (in my case this is a django view)

class ArticleProcForm(forms.Form):
    article = forms.IntegerField(required=True)
 
@csrf_exempt
@form_valid(ArticleProcForm, 'POST')
def article(request):
    try:
        article = Article.objects.get(id=request.form.cleaned_data['article'])
    except Article.DoesNotExist:
        return HttpResponse(json.dumps({'status': 'Bad Article'}))
 
    try:
        image_url = ImageExtractor.getImages(article.url)[0]['url']
    except IndexError:
        pass
    else:
        # important bit
        try:
            image = StringIO(urllib2.urlopen(image_url).read())
        except (urllib2.HTTPError, DownloadError):
            pass
        else:
            image = UploadFile(image, '.'.join([str(article.id), image_url.rsplit('.', 1)[1][:4]]))
            upload_url = blobstore.create_upload_url(reverse('Articles.views.upload'))
 
            try:
                urllib2.urlopen(upload_url, {'file': image})
            except (DownloadError, RequestTooLargeError):
                pass
        # end of important bit
 
    return HttpResponse(json.dumps({'status': 'OK'}))

Here is basically what happens in the important bit:

1. Download image from url and change it to a StringIO
2. Make an UploadFile (basically a bundle of byte-string-data and desired filename)
3. Create an upload_url with the blobstore API
4. Fake a file-upload form post

The next thing we need is a view that will handle the request the blobstore will send back to our app.

@csrf_exempt
def upload(request):
    if request.method == 'POST':
        blobs = get_uploads(request, field_name='file', populate_post=True)
 
        article = Article.objects.get(id=int(blobs[0].filename.split('.')[0]))
        article.media = blobs[0].filename
        article.parsed = True
        article.save()
 
        return HttpResponseRedirect(reverse('Articles.views.upload'))
    else:
        return HttpResponse('meow')

Basically it extracts the article’s id from the filename (the only way I could make work to pass that information) and stores some changes into the datastore. You’ll notice that I’m basically just storing the article’s id again in another field, this is to preserve knowledge of the file extension. It’s also important to note that the blobstore requires a redirect response upon success, otherwise it will throw an error.

Here is the get_uploads function I found online somewhere.

def get_uploads(request, field_name=None, populate_post=False):
    """Get uploads sent to this handler.
    Args:
      field_name: Only select uploads that were sent as a specific field.
      populate_post: Add the non blob fields to request.POST
    Returns:
      A list of BlobInfo records corresponding to each upload.
      Empty list if there are no blob-info records for field_name.
    """
 
    if hasattr(request,'__uploads') == False:
        request.META['wsgi.input'].seek(0)
        fields = cgi.FieldStorage(request.META['wsgi.input'], environ=request.META)
 
        request.__uploads = {}
        if populate_post:
            request.POST = {}
 
        for key in fields.keys():
            field = fields[key]
            if isinstance(field, cgi.FieldStorage) and 'blob-key' in field.type_options:
                request.__uploads.setdefault(key, []).append(blobstore.parse_blob_info(field))
            elif populate_post:
                request.POST[key] = field.value
    if field_name:
        try:
            return list(request.__uploads[field_name])
        except KeyError:
            return []
    else:
        results = []
        for uploads in request.__uploads.itervalues():
            results += uploads
        return results

Now the process of serving this blob to the browser is very simple and goes something like this:

class ImageForm(forms.Form):
    id = forms.CharField(required=True)
 
@form_valid(ImageForm, 'GET')
@cache_response
def image(request):
    blob = BlobInfo.gql("WHERE filename='%s' LIMIT 1" % request.form.cleaned_data['id'])[0]
 
    return HttpResponse(BlobReader(blob.key()).read(),
                        content_type=blob.content_type)

One final note

And one VERY important final note. The vanilla urllib2 library can’t handle file uploads, so I found one online that can. It’s called urllib2_file.

However it doesn’t quite work on google appengine. For example it can’t handle being told what you want the filename to be and some other details because it relies on raw file access. So I changed it a little bit, unfortunately I don’t quite know how to upstream my changes so I’m hosting it on github.

You can get it at github, feel free to contribute.

Related articles by Zemanta

• Using BlobReader, wildcard subdomains and webapp2 on Google AppEngine (notdot.net)
• Django protip #2: Forms are awesome (swizec.com)
• App Engine SDK 1.3.5 Released With New Task Queue, Python Precompilation, and Blob Features (googleappengine.blogspot.com)
• Parsing file uploads at 500 mb/s with node.js (debuggable.com)

Welcome to another installment of Swizec’s Django protip. Previously we discussed a better way to structure your django apps, but nobody cared about that because everybody is rather silly. This time we’ll be talking about how awesome forms are and why you should be using them for pretty much everything. At the end, I’ll show you some neat tips and tricks I discovered during my Django Epiphany.

Why forms

When you look at code a lot of web developers produce (and yes, even I did it plenty of times back in the day) you will notice a lot of work goes into retrieving data from GET and POST parameters. Now despite most developers simply ignoring GET parameters as anything really special or dangerous and just handling them as if they were regular variables, because hey, what could go wrong about retrieving a page number right? At best you’ll see code having a bunch of lines sort of like this:

$page = (isset($_GET['page'])) ? intval($_GET['page']) : 0;

Anyone notice a security flaw? Then think of this, what happens if the page is set to -1? Sure, if errors aren’t being displayed right to the user nothing too important. But if they get shown an SQL error … or worse …

However people are usually at least a little bit more careful about POST data because they realise that hey, this is something a person filled in a web form and perhaps the data should go through a series of a little bit more stringent tests before it gets chucked into the database. Hell, maybe we could even tell the user where they screwed up and if the planets are in constelation, why not also make sure those required fields are actually filled out … you know, so we don’t get any weird inconsistencies in our database.

But still, it’s a lot of work to do all of that by hand every god damn time. If only there were something easier, more transparent and plain old automagical …

Cue Django Forms

In django, all of this comes automagically. There is this thing called a “form”, which basically lets you define what parameters a request needs, be it GET or POST based, what they should validate against and most importantly, what’s required and what is not.

If you’re into that sort of stuff you even get building the form in a html, so the users can use it, completely for free and magically with all the required “Hey bozo, you filled so and so field wrong. Fix it!”. For every field! Magic.

But since most of my time is spent on developing API’s rather than user-facing websites let me show you how to use forms effectively in that sort of environment. For the html stuff just go check out the django form docs.

The basic use of forms goes a little bit like this (hopefully your forms are in a separate file from your views, this is just an example )

from django import forms
 
class ListForm(forms.Form):
    feed = forms.IntegerField(required=False)
    category = forms.IntegerField(required=False)
    since = forms.DateTimeField(required=False)
    count = forms.IntegerField(required=False)
    page = forms.IntegerField(required=False)
    include_content = forms.BooleanField(required=False)
 
def list(request, format='json'):
    form = ListForm(request.user, request.GET)
 
    if form.is_valid():
       articles = Article.objects.filter(feed__in=form.cleaned_data['feeds']
                                                  ).order_by('-time')[page*count:page*count+count]
       return HttpResponse(json.dumps({'status': 'OK',
                                        'count': len(articles),
                                        'articles': articles}))
    else:
	return HttpResponseBadRequest(json.dumps({'status': 'ERROR'}))

Well something along those lines anyhow. What you can see is that I basically define a form and check that it’s valid. Once I know it’s valid I can go on using its cleaned_data without much regard for anything.

Some tips&tricks

And now let’s get onto some tips&tricks

First thing you’ll notice once you start using forms like you properly should is that all of your views follow this pattern: get form; validate form; do something; or do something else;

So I wrote up a descriptor for that, now I can be certain that when I’m in my view the form is valid and I can use the data.

def form_valid(form_type, data_type):
    def inner(view_func):
        def wrapper(request, *args, **kwargs):
            form = form_type(request.__getattribute__(data_type))
 
            if form.is_valid():
                request.form = form
                return view_func(request, *args, **kwargs)
            else:
                return HttpResponseBadRequest(json.dumps({'status': 'ERROR'}))
        return wraps(view_func)(wrapper)
    return inner
 
## the usage goes like so
@form_valid(ImageForm, 'GET')
def image(request):
    blob = BlobInfo.gql("WHERE filename='%s' LIMIT 1" % request.form.cleaned_data['id'])[0]
 
    return HttpResponse(BlobReader(blob.key()).read(),
                        content_type=blob.content_type)

Using the decorator thus makes for much much cleaner code.

Now let’s look at some magic done with custom clean functions inside forms

## this enables us to handle <a class="zem_slink freebase/en/comma-separated_values" title="Comma-separated values" rel="wikipedia" href="http://en.wikipedia.org/wiki/Comma-separated_values">comma separated values</a> seamlessly
    def clean_feed(self):
        try:
            feed = [int(id) for id in str(self.cleaned_data['feed']).split(',')]
        except (AttributeError, ValueError, KeyError):
            feed = None
        return feed
 
## automagically parsing json parameters can be done too
    def clean_feeds(self):
        feeds = json.loads(self.cleaned_data['feeds'])
        if type(feeds) != list:
            raise forms.ValidationError("list of feeds expected")
        return feeds
 
## or how about logging in the user while we're checking the user/pass is correct
## don't manually log in users unless you know at least somewhat what you're doing, usually django handles this
    def clean(self):
        cleaned_data = self.cleaned_data
 
        if len(self.errors) != 0:
            return cleaned_data
 
        user = authenticate(username=cleaned_data['email'],
                            password=cleaned_data['password'])
        if user is None:
            del cleaned_data['email']
            del cleaned_data['password']
            raise forms.ValidationError('Bad login')
        else:
            cleaned_data['user'] = user
 
        return cleaned_data
 
## now the strangest thing, when you have to handle grabbing data by different parameters
##(like being given a set of feed ids, or a feed category id, you can do this by returning
## a QuerySet in the form's cleaned_data
def clean(self):
        cleaned_data = self.cleaned_data
 
        if not (cleaned_data.get('feed', None) != None or cleaned_data.get('category', None) != None):
            raise forms.ValidationError("feed or category required")
 
        if cleaned_data['feed'] != None:
            user_feeds = UserFeed.objects.filter(user=self.user,
                                                 id__in=cleaned_data['feed'])
        else:
            user_feeds = UserFeed.objects.filter(user=self.user,
                                                 categories__contains="'%d'" % cleaned_data['category'])
 
        cleaned_data['feeds'] = map(lambda f: f.id,
                                    Feed.objects.filter(id__in=map(lambda f: f.feed, user_feeds)))
 
        reverse_feeds = {}
        for feed in user_feeds:
            reverse_feeds[feed.feed] = feed.id
        cleaned_data['reverse_feeds'] = reverse_feeds
 
        return cleaned_data

Conclusion

Anyhow, that’s it as far as forms are concerned. Do sound off in the comments or on twitter if I fucked up somewhere. I know geeks like to argue. Come back next week when I’ll be talking about different magical things you can do with decorators and why they are uber awesome to use in django (or well any other type of python development really)

Related articles by Zemanta

• Django protip #1: A better App structure (swizec.com)
• Small trick for seamless base64 password storage in django (swizec.com)
• Django and SaaS (tidbids.posterous.com)
• Things i hate in django (almirkaric.com)

Yesterday I finally managed to take that hiking trip I’ve been meaning to for months.

And it was fucking awesome!

We went to something called Vodotocno jezero – a small mountain puddle really. But it was beautiful anyway. The trip started off with a long and bloody awesome drive. I like driving around tight gravel curves and making the car drift without using the handbrake.

When we got to the starting point it was hellishly cold. Probably less than 10C. Luckily for Girlfriend the backpack I was carrying contained some forgotten gloves. After a short wall some really lovely views opened up from a small and funny shepherd’s cottage thingy.

Then the real hike began. First there was a little steepness through a bit of a forest and after that a very nice and unsteep path across some hillsides with such a magnificently awesome view I almost shat my pants.

But the real fun began once we got off the marked trails and just winged it across the terrain. Some grass here, a rock there and those weird short pine things that grow up in the high mountains because trees can’t. Sure we almost got lost once we were near the saddle between to summits and we couldn’t quite discern where it was anymore but meh.

Eventually the view onto the small puddle and cottage next to it opened up and it was plain sailing therefrom. Well no, no it was not. Girlfriend twisted her ankle and what was supposed to be the final ten minutes before reaching the destination turned into a thirty minute painful weirdness. Turns out hoping rock to loose rock on a steep steep hill with a twisted ankle isn’t at all an easy task.

The trip back was even cunner. Took us something like three hours getting back to the car and we got a little bit lost so we took a nicely more dangerous path to get down than w did for getting up. Hoorah!

But hey, fuck it. I’m just incredibly choked that the GPS data later showed that saddle was 2004 meters high and I don’t think I’ve ever walked anywhere near that high before. Was awesome!

Therefore, some pics.

When I started coding for our latest project at Preona a bit of an epiphany happened. I suddenly got django. Every pattern that used to feel a bit strange and I may have fought a little, suddenly became obvious and simple. Suddenly out of the blue my whole codebase is so marvelously organised and separated into files it brings a tear to my eye.

In the old days the average Django App in my project had a structure a file structure a bit like so:

• models.py
• views.py
• tests.py
• RandomActualWorkLogic.py
• AnotherRandomOfWork.py
• …

Sure this works quite alright, but it feels a little weird and after way too much work you suddenly realise that instead of the clean design you envisioned as you started out, you’re left with a crow’s nest of interdependancy, circular crappery and your project is in pretty miserable shape.

This point was really driven home when I figured two different django projects should share some code. Extrapolating a clean interface and making stuff work … was a nightmare. I actually gave up after a week and decided to start afresh.

And boy, was that the best decision ever!

Better application structure

The first step was to take up a better way to organise my codebase inside applications. It goes something like this:

• models.py
• managers.py
• views.py
• tests.py
• forms.py
• decorators.py
• processing.py — (this is for certain special views)
• urls.py
• settings.py

The first result of this organisation is that now everything has its own place. There are no StrangeWorker.py crappy things anymore. All of those reside in a special ‘application’ just for those called a lib. Whenever you are making something and are looking for a place to put it -> the file is an obvious pick!

Another great result is that it’s now much easier to keep applications contained within themselves. Because both its specific url config and its specific settings config are contained within the application you can easily switch it around between projects or even make it a standalone thingy that projects can simply include.

Also because the file structure makes sense now and all those WeirdoWorker.py are separated elsewhere as proper libraries, there is less of a temptation to create mixed and confusing dependancies all over the place.

Conclusion

That’s it for django application structure. If you’ve got any better ideas do mention them on twitter or via the comments below. If not, that’s alright

Either way, join me in the next installment of Django Protip when I’ll be talking about using “Forms, forms for everything”

These days even the noobiest of the noobs know that passwords should never be stored in plain-tect on the server. For various good and bad reasons, but the gist of it is security through obscurity.

What a few less people know is that base64 is the same as plaintext. Not only is it a very simple two way hashing function, if it can be called that, it’s certainly not encryption, what’s worse is that any coder worth their salt can recognise base64 encoding at a glance. Decoding it is trivial, many tools online can do it.

On top of all of that, django already stores its user’s passwords very securily with one-way hashing AND salting.

So what the fuck am I doing trying to save passwords in base64?

Problem

The reason is in fact quite simple: External API’s.

Here’s the problem: what do you do when your service is accessing a third party API, which doesn’t support OAuth or OAuth is impractical in your situation for various reasons and the API doesn’t support some other means of logging in with a hashed password. Basically, the only way you can access this API is if you know the user’s password?

The obvious solution is to fuck it and store plain-text passwords. Nothing you can do right? Hopefully nobody will hack your database and get to the passwords.

Sure. But what when you’re browsing around for debugging purposes? How do you prevent yourself from accidentally reading someone’s password?

Solution

That’s where base64 comes in.

But since we don’t want to make our code silly, here’s a simple way of achieving this without ever having to worry about it again.

class PasswordManager(models.Manager):
    use_for_related_fields = True
 
    def create(self, *args, **kwargs):
        try:
            kwargs['password'] = base64.encodestring(kwargs['password'])
        except KeyError:
            pass
 
        return super(PasswordManager, self).create(*args, **kwargs)
 
    def get(self, *args, **kwargs):
        data = super(PasswordManager, self).get(*args, **kwargs)
        try:
            data.password = base64.decodestring(data.password)
        except AttributeError:
            pass
        return data
 
class GoogleAccount(models.Model):
    user = models.ForeignKey(User, unique=True)
    email = models.CharField(max_length=255)
    password = models.CharField(max_length=255)
 
    objects = PasswordManager()

Basically we write a module manager that encodes all passwords in insert queries to base64 and decodes them again on select queries. For completeness sake it’s also good to define a filter function where we perform the decoding on the whole set of returned entries. But for this sort of thing that’s rarely needed because you’re rarely going to be performing third party actions for miriads of users at once.

This way we achieve perfectly seamless base64 storage of passwords. Nice and easy.

The story begins with a young boy who had a pair of shoes he loved very much. They were the bestest and most durablest pair of shoes he ever did own.

And they were pretty too! My god, all the female shoes turned their heads as they walked by. The shoes were sporting a lovely black leather body with a red line or two in strategic places, topped off by a magnificent red Fallen logo. The shoe laces were knotted off at the base and survived most of their time being stunk up and walked upon by dirty socks as was the fashion of the time.

The shoes lived life together with the boy through all sorts of haps and mishaps. They were there when he got drunk, they were there when he decided it might be a good thing to do some sporty things like running and stuff. They bared it all!

Resilient little shoes that they were.

There were times when younger, more sexier shoes, almost took their place in the boy’s life. But it never happened, somehow, through some turn of fortune, they always came back to embrace the boy’s feet and make the nasty experience of walking all lovely and comfortable and just like he was floating about on a cushion of air.

But despite all, they were getting old.

There were giant holes gaping from pretty much everywhere. Their posterior was old and battered and nearly mashed up and eaten through like a pack of rabid wolves got their hands on them. Almost every time they made a step they tore through the boy’s socks in an act of defiance as if to scream “HEY I’M FUCKING OLD! I DON’T LIKE WALKING ANYMORE LEAVE ME ALONE!”

And the boy heeded their call and he did decide to buy a new pair very soon. But his mother heard them even more so one day she up and threw them in the trash. Alas, the boy now had not a shoe to put on his feet.

He decided to go for a run despite all. Do it barefoot so to speak.

Now his soles are kind of tender.

The end.

Related articles by Zemanta

• Barefoot running gains a following (seattletimes.nwsource.com)
• Vivo Barefoot Shoes, Now for Kids (wired.com)
• How to Transition from Running Shoes to Barefoot Running (walking-running-training.suite101.com)
• 5 shoes to rock your world (seattletimes.nwsource.com)
• Are Shoes That Simulate Walking Barefoot Better? (atomiurl.com)
• Barefoot Running – Baby (Forefoot) Steps in the Right Direction on Run #3 (runblogger.com)

Ok so today has probably been one of the crappiest days in a very very long time. Nothing spectacular happened, just a bunch of small very very irritating and annoying things, just enough to ruin your mood for a whole week.

Which is awesome since it’s Monday.

Even better, I’m going to London tomorrow and am expected to be all chirpy and awesome.

Because the day can speak for itself, I’m just going to list everything:

1. I got up quite a bit later than I intended.
2. It was cold and incredibly humid outside.
3. By the time I got to uni to have a grade officially noted down, I was dripping sweat.
4. Went to hackerspace to study, made tea.
5. 10 minutes later realised I’d forgotten my calculator at home, went get it.
6. Dripping sweat when got home.
7. This time get in car and go back to hackerspace.
8. Going for calculator took an hour. Made new tea.
9. Ten minutes later classmates called, let’s go study at a random open classroom.
10. It is now almost noon and I’ve only had a few sips of tea.
11. All vending machines at the faculty are out of energy drinks, everyone’s studying.
12. With the last change I’ve got I grab a coke.
13. At 3pm the exam starts and it’s a fucking assrape. I literally felt the professor’s dick go up my arse when I put my eyes on the problem.
14. Struggle through somewhat solving everything.
15. It took so long I couldn’t pick a time/date to go get my grade. Got one that is on a day when I’m in London.
16. Go back to hackerspace to mostly hang out, do some business stuff.
17. Laptop runs out of disk. Quickly empty trash.
18. Emptying trash takes two hours.
19. While emptying trash the only data file for my time logging app where I log pretty much everything I do so I can have an oversee of what I’m doing with my time … goes missing.
20. Fine I’ll just restore it from backups.
21. Mate beats me in almost every single game of Guitar Hero.
22. Get home, start restoring that file from backups.
23. Find out someone had turned Time Machine off on December 6th 2009.
24. Give up. The day is officially horrible. The only way it could get worse is if I magically break my leg while sleeping.

A local hackerspace I’m a part of is organizing a summer long hackday that’s starting in a few weeks.

What we need right now are the crazies, most whackiest and twoplus insane ideas you can possibly think of. And pimp ‘em out, get votes!

When the hacking carnage begins the highest voted ideas will be gathered up and teams will start working on them. You are also welcome to come put your arse where your mouth is and help make the idea happen, just so you know.

Then, when the carnage is over, there will be a demoday. Each team will present their idea in front of a bunch of business people and the likes, although personally I’m all for making them public and creating a huge party where everyone is invited. Hell, a barcamp. Hmm … yeah, I’ll convince everyone that that’s the way it should be done.

Anyhow, the demo day, then whomever is the best gets heaps upon heaps upon shitloads of bragging rights. They have essentially just become the awesomest dudes in the whole of Europe. That’s right, if you’re too much of a pussy to even participate in this thing you’re a de facto loser. Turn in your hacking license at once. You aren’t worthy of calling yourself a hacker.

Also, while you’re reading this, why not go ahead and vote for the three ideas I contributed

• Cheaper-than-beowulf cluster
• Smart RSS reader for iPad
• Mood music

Oh and do pass this around, the more crazy ideas people contribute the merrier