Feet Have Been

After you’ve been programming for a while, one of the first things that you start doing is working out the database. You decide how your data should be stored, and you think about the optimal ways you can do this. You think about what technology would best support your idea, and then you get to work mapping out the back-end. And when that’s all done you start writing your classes. You write the little pieces first, like what the user object should look like. Then you build the classes and objects that would utilize the user object, creating new objects as necessary. And finally, when you’re all done, you start designing the front-facing portion of your application. Whether it’s for the web or for the desktop, as a programmer this is generally the last step.

And you’re doing it all wrong.

Designing an application from the STORAGE point of view is all wrong. Imagine designing a car based on the garage that you were going to put it in. Yes your car will always fit in the garage, but you’re going to run into problems. You’re probably going to have to make some concessions on the size of the car. But when you’re programming, you get to design the garage too. So why not build the car to be the best damn car ever, and then build the garage around that? That way you never need to compromise and you can be damn sure that the car is always going to fit.

Now, lets apply this metaphor to programming.

The first step I take when building an application is to decide its purpose. Is the application meant for non-technical users? Is it meant for children or adults? Is it going to be maintained by me or other developers? What’s the life expectancy of this application? Are there any third party applications that need to talk to it, or vice versa? These questions help us define how we should be building the application. It imposes some features and necessities while still allowing us a lot of freedom.

To me, data is the most restrictive part of our application. It’s the only part that we have no say in. The data will always be the data. We can’t adjust it to suit our needs. As programmers we spend so much time living with things that have no real substance. The code we right can just as easily be re-written a different way. The database we design could have been designed a completely different way. But yet we insist on building our application on things that can shift at will. The Data is concrete. The data is ALWAYS the data and it can never look like anything else. It can never change shape.

So we should start with The Data. We should say “what is the best way to display this data”. Designers think this way (the good ones do at least) and it’s time for programmers to think this way too. I’m not talking about how The Data should look to users, but how The Data should function in our application. Too often we end up having complicated queries simply because we forgot that we need to use The Data in a certain way.

We should model how the data needs to be displayed. Once we have that mapped out our Data will start to fall into some shapes. We simply coral those semi-ambiguous shapes into something concrete and now we have a solid database design that really does model our Data. And because we built our database on REAL Data, we know that we will always have a place for The Data and that things are as simplified as possible.

I’ve been working with JavaScript a lot lately and with NodeJS garnering so much attention, I figured it was time for a new project.

I decided to start working on a Multi User Dungeon style game. You remember those old games where you would connect via telnet and then execute commands like “walk north” or “attack” by entering them into a prompt? Well over the next few months I’m going to be working on my own version of that.

In order to make to make it REALLY accessible, I have of course gone with using JS client side with jQuery to handle events and ajax, but where this is really different from my normal projects is the backend. I’m opting to run NodeJS with Express and DBSlayer. So this game will really be running on almost 100% pure JavaScript. Of course I’ll be running a standard MySQL database since it seems to make the most sense for this. I investigated other non-relational database mechanisms, but to be honest, they’re not suited for structured inter-related data. 

As well, this is the first time I’m hoping to use a vcs to handle my source. I was initially looking at GitHub, since that seems to be the standard nowdays, but I find Git… awkward. SVN seems to make more sense to me so I’ll probably end up using that. I might sign up at Beanstalk or Assembla that way I still get the option of keeping my source closed during development. I like the idea of open source, but I can’t imagine anyone would be interested in my work while it’s still being worked on. Things change very frequently, and nothing remains where it is.

I’ve been working on it for a few days now and here is the current state of the code:

The core only contains a few objects. game, screen and something called Cobra. Cobra acts as a “command manager”. Since MUD’s are essentially a bunch of commands, Cobra is the object that registers them and calls them when commands are entered. So what this allows us to do is to define separate “commands” that never pollute the global namespace.

Another feature of Cobra is capture, which allows us to temporarily bypass it. Why? Basically we can create temporary commands that exist as long as we want! Huzzah!

Anyways, I shall keep you all informed as to how this proceeds and maybe even do a quick walkthrough of setting up Node/npm/Express/DBSlayer and MySQL (which is ridiculously easy).

Google has been offering their URL shortening service for some time now, but for those of you trying to follow along with the official documentation here: http://code.google.com/apis/urlshortener/v1/getting_started.html you’ll have noticed that it’s not quite working. Here’s how to get url shortening up and running

1 2 3 4 5 6 7 8 9 10 11 12 13 

<?php 
$longUrl = 'http://facebook.com;
$ch = curl_init();
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_URL, 'http://goo.gl/api/shorten');
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_POSTFIELDS, 'security_token=null&url='.$longUrl);

$content = curl_exec($ch);
curl_close($ch);

echo json_encode($content);
?>

If you’re getting any errors about curl not being enabled, simply pop open your php.ini file and look for this line: ;extension=php_curl.dll Then just delete the ‘;’ at the front. Don’t forget to restart your server for the new extension to come into effect.