Okay, people started complaining I should blog some more,
so, here it goes.

I’ve finally started something that I planned to do during summer
vacation. But until recently, I was lacking inspiration and motivation.

But, what I planned to do, and what I started to do, is take a look
at JavaScript and more specifically, AJAX.

I’ve never used the language before, but well… it’s just another
language. The basics of coding are the same anyways.

So, what I trying to do, is to bring the BlaatSchaap site to a new
level. Let’s call it “BlaatSchaap Live”. Basically, it means, let the
site do stuff that facebook does. Notifications if someone leaves
you a comment, without refreshing, and stuff like that.

When I started working on the current site, about two years
ago, I decided to do no JavaScript. Everything would be
server rendered, to make the site depend on the browser
as least as possible. In practice, it turned out, old browsers
wouldn’t render the site correctly anyways.
*casts a dirty look at internet explorer* Yeah, Internet Explorer,
older then version 8, renders CSS in a…. rather weird way.
This is something I experienced with the Radio BlaatSchaap
site back in the days. Two divs next to each other, with the
same height specified in the CSS would render with a
different height.

Well… enough about that. *casts another dirty look at MSIE*
That browser is officially ‘unsupported’ at my website anyways.

So, AJAX, JavaScript and PHP it is. So, I am rewriting everything.
Both server side and client side. I am working on a more modular
design too. I am thinking about writing a server rendered version too,
within the same new modular design, I am trying to separate functionality
from rendering code.

In the old design, it was all-in-ons. Every functionality module just added
it’s output (HTML code) into a variable, that get’s echo’d in the end.
In the new design, everything gets stored as XML in a variable.
In AJAX mode, XML renderer, the XML code gets simply echo’d
again.

If I decide to create a server rendered version of the site, this XML
gets processed again and so the content will be generated. This
may seem a little double work, encoding and decoding XML again,
but this way I can generate my content more flexible.

Current BlaatSchaap mobile support is also minimal. And the rendering
of the mobile part is also determined in the functional modules, another
reason to implement the new design.

There are also some other things about the current BlaatSchaap site that
must be changed, but I’ve decided to change them while rewriting, since
everything will be re-designed to fit in the new modular structure.
I am talking about redesigning the messaging system, adding photo album
support rather then just photo uploads.

A new feature I already started working on in the old model, and that
most likely won’t appear live in the old design, is a ‘facebook-like’ wall
support. The current WIP implementation already supports posting
external photos to your wall, with on server image caching.
Well… this feature will have to be ported to the new structure.

I might even restart some other BSCP’s (BlaatSchaap Coding Projects)
that have been frozen for the past years.

*pokes Nuky*  I might even consider BlaatNET ;) I even have my
plans for that :P

Another project, that has been sitting in the freezer for years
is BlaatScrobbler. This project was frozen because I had some
Mutex problems, on Windows, that is. and as you might know,
Windows is not my favourite OS, and that includes coding for it.
Interprocesscommunication, you know. I have my shared memory
working, but I need to signal my application when it can read data
from the shared memory, but that damn mutex refused to wait…

Yeah, that was another coding project from long ago.
So much to do….. so much I should have done the past
years. But now, now I finally have found my motivation,
I have more important stuff to do, like studying for my exams.
Damn math!

« »