Feet Have Been

Every year I try and make it my goal to really learn at least one web framework. I don’t need to become a master at working with it, but I need to know it enough to consider it one of the “tools” available to me.

This year I started trying to work with CodeIgniter, but then got sidetracked by various personal projects. That and the fact that most frameworks just feel too bloated to me. They keep trying to add on all these “features” and as nice as they are, they shouldn’t really be part of the CORE framework. They’re modules to enhance it. Not to mention that most frameworks have such a weird learning curve that it takes a long time before you’re comfortable with it.

That’s why I was pleasantly surprised by a new PHP framework I stumbled across called (Limonade-php)[http://limonade-php.net]. Limonade-php is a “micro” framework. It’s more or less one file with a few resources, a LOT smaller than any other framework I’ve seen. But it’s so ridiculously amazing that I knew I just had to work with it. Limonade allows you to build RESTful applications pretty much instantly. There’s almost ZERO learning curve and things just make sense.

For example, adding a new page is as simple as dispatch_get('/page/route','func_name'); But can be made complex by utilizing some handy features to allow for query parameters. dispatch_get('/page/:id/some/:resource','myfunc');

Of course being almost 100% RESTful compliant, you have access to methods such as dispatch_get, dispatch_post, dispatch_put, dispatch_delete all of can be mapped to the same path allowing you to REALLY build RESTful applications.

I was so impressed with Limonade-php that about an hour after playing around with it I started writing a tool that I needed for my daily work. It was a very simple bug-tracker allowing for multiple projects, bugs and users. It allows you to color-code projects, which immediately translate into color-coded bugs. And it was all done in a single file that is under 550 lines of code (not counting primarily HTML views and CSS).

So check out (limonade-php)[http://limonade-php.net] and if you like, take a look at (Lemontrac)[https://github.com/AngeloR/Lemontrac].

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).