blog #programming

Designing an MVC architecture for web applications

A while back I was tasked to create a web application based on the popular MVC architecture pattern. Part of the task was not to use a framework, but to write the application all by myself. So I looked at my notes from school that taught me this basic model of an MVC architecture:

Writing that perfect Makefile

Realizing that I didn't want xmk to miss Make's core feature made me feel a bit silly for trying to reinvent it. Thus I ended up spending a good couple hours trying to come up with a Makefile that could make me feel satisfied. Pretending I was only ever building for one platform without any separate debug buils led me to this:

xmk (cont.)

Some updates after having put more thought into it.

xmk
xmk is another build automation tool inspired by Make. It features a hierarchical block structure and a function interface to facilitate Make-like dependency resolution.It aims to be simple and explicit even in projects that are meant to be compiled for more than one platform.
Make and build automation

Trying to understand makefiles caused me quite the trouble back when I was working on my game engine a few years back. I eventually settled on a lukewarm solution that worked, but always recompiled the entire game it was targeting. No matter how I looked at it I wasn't happy with the makefile format and ended up writing my own build script that would read flags and libraries from a yaml file. It worked surprisingly well and only compiled source files that needed to be (re)compiled.
This weekend I took another look at make. Learned a few additional things. In the end I still wasn't happy. However I also found myself no longer quite so satisfied with the build script I had written. It's too inflexible and the yaml tree it operates on is actually quite ugly to write and read. So I decided I'd try to invent my own flavor of Make. Here's the planned result:

Making sense of object-oriented programming

You're a programmer. You always know the exact specifications of the thing you've set out to model. You can always trust dependencies you rely on to just work and never break. You can trust that the environment you're programming for remains stable und unchanging for time immemorial.
Your neurologist suggests that your naivety and optimism may be cause for concern. Or maybe you just woke up to an angry customer's mail complaining that the feature they had requested wasn't realized to their satisfaction. Or did you wake up in front of your screen, still having to fix that dependency issue that came up in yesterday's update? In any case, you probably don't have much time to think about where things started to go wrong.

Further experimenting with non OOP PHP

Cleaned up the mess I posted yesterday. The code should be pretty self-explanatory now. First I introduced type classes to mimic C structs:

Experimenting with non object oriented PHP code

I'm working on a framework written in PHP and trying to keep the code simple by omitting the functional and object oriented approaches as much as possible. What I'm having in mind might be best defined as loose modular programming. It might lead nowhere good but that's why this is an experiment.

Confused about inheritance in PHP

Got another job that deals with PHP. I haven't used the language in years and admittedly not made much use of its object orientated facilities during the time I worked with it in the past. As expected even the later additions to PHP have their oddities and pitfalls. For example today I tried to implement the following

Dependencies sure are fun

Now that my website is static again I needed to put together a new script for the hit counter. It seems the data related to the last time this site was delivered statically was not very important to me at some point, because otherwise I would still have it stored somewhere.