Welcome to ^<@<: pronounced exactly as it's spelt.

Checklist for upgrading CakePHP

  • .htaccess
  • favicon.ico
  • cake/libs/model/datasources/dbo/dbo_sqlite3.php
  • app/app_controller.php
  • app/config/database.php
  • app/controllers/*
  • app/models/*
  • app/views/boa_*
  • app/views/helpers/*
  • app/views/layouts/default.ctp
  • app/views/pages/*
  • app/views/posts/*
  • app/webroot/css/*

History of Social Games

This is an interesting article, so I'm posting a link here so I can find it later.

EDIT: Also, this is missing a lot a staples, not to mention entire categories, but still is a nice list.

Done Refactoring

I think that's everything. A lot of work for something so little used, but the main point was learning the framework. Porting an existing project to a framework teaches you much more than those 'make a blog' canned projects do.

So, will I be doing anything useful with this site? We'll see. I'm full of ideas (full of something, at any rate), but it's the implementation that's always the problem. Still, we'll see how long this 'unemployment' thing lasts.

This is why we do sanity checks.

So I'm making a CakePHP controller that will display a single blog post (using the term loosely; in effect it will be a generic comment system, allowing me to make a comment on any model object). I'm having difficulty with the CakePHP database API -- I'm trying to retrieve a post by ID, but am getting NULL back. After trying a bunch of things that don't work, I do a 'sanity check': I run SELECT id FROM posts; on the SQLite 3 database. The result: a bunch of NULLs. Huh?

By default, SQLite 3 gives each table a primary key called ROWID. If you define a column with type INTEGER PRIMARY KEY, SQLite will make that column an alias of ROWID. This much I already knew. After double-checking my schema, I found I defined my primary key column as INTEGER UNSIGNED, which apparently SQLite didn't recognize. What irks me is that it failed silently. Anyway, this is why we do sanity checks -- 99% of the time they just confirm what we already know, but those 1% occasions they save us from an afternoon of wasted work.

(Not really expecting anyone to read this, let alone care. This is more for my benefit; not just to remind me about this SQLite gotcha, but also to continue testing with real data. Down with boring Lorem Ipsum!)

CakePHP Refactoring

Hello my large number of frequent readers, I'm back with another of my prompt and timely updates. Things are a bit of a mess here as I'm refactoring everything to use CakePHP. Why? No reason, just wanted to learn another web framework, since you can never have enough. I used symfony for a couple of projects last semester, and was less than happy with it.

How easy common tasks are is only half the strength of a good framework. The other half comes from keeping difficult tasks possible; a good framework should get out of your way when you need to do something specific and unanticipated. For instance, making a controller that's not tied to any model object should be easy. A lot of frameworks brag about how their scaffolding allows you to make CRUD pages very quickly. But when you think about it, programmers spend a fraction of their time working on straightforward stuff like that; we spend all our time on the tricky stuff that's specific to whatever the current project is. So just give us our tools and then get out.

Anywho, I have a bunch of minor grievances about CakePHP, but so far I've found it much more straightforward than symfony was, so I'll probably use it for any future PHP projects.

On the off chance that someone is actually reading this, you can tell that almost all of my links are broken. If this were a real site, I'd be more diligent about clean updates and redirects. I'm not going to worry about that -- if for some reason you need some of my files, just e-mail me and I'd be happy to get you what you need.

Started Contest Scenario Planning

You can find it here. I'm really, really tired, so it's probably really, really incomprehensible.

Oh, and CSS is just stupid.

Minor commit for LoD1; Typo fix for PN2 scheme

After who knows how long, I actually changed a few things in LoD1. Nothing worth mentioning, but it was nice to commit something, no matter how small. I had hoped to wrap it up a while back, but a Hebrew night course and hospital visits are sucking up my free time. I plan on having it out before Duke Nukem Forever.

Minor typo fix for the PN2 AvernumScript scheme definition. You may need to clean the cached compiled schemes. On Vista, remove all .cscheme files from \Users\USER_NAME\AppData\Roaming\Echo Software\PN2\.

Stuff Happens

  • Moved /scenarios, /scripts, and /utilities to /boa/scenarios, /boa/scripts, and /boa/utilities. Parts of /misc have been moved to /boa/misc. Yeah, there'll be broken links. Better now than later.
  • In case there's any other Programmer's Notepad fans out there, I've made an AvernumScript scheme. Being able to whip up lexers for small, special purpose languages is probably Programmer's Notepad biggest strength. So you'd think it would be better documented. C'mon Simon, even an XML schema definition for .scheme and .schemedef files would've helped.
  • I've set things up so I can host Subversion repositories here. You can access the web interface at /svn. At the moment, I'm the only who can write to it (through SSH), but go nuts if you want to view it. Not much on it right now, but from now on anything that I put on this site will be developed on there.

Project Darkstar

The last couple of days I've been playing with the Sun Gaming Server (or Project Darkstar). Aside from a few gotchas, it's pretty intuitive. In a short span of time (probably well under eight hours if I had been working on things straight and not changed my mind halfway through) I was able to whip up a server and client for a simple game. That includes learning as I went. The server doesn't seem to want to set up the database here (Darkstar uses Berkeley DB), so it seems the world will never get to play Rock Paper Scissors Online. Oh well. Following are my impressions at first blush.

  • Server side, everything is Java. State is persisted through Plain Old Java Objects that implement the ManagedObject interface. Such objects are serialized and kept in a Berkeley DB. Yeah, serialized. I guess the name of the game is getting your model right on the first try, so you don't have to wipe your database six months down the road. ManagedObjects keep a ManagedReference to other ManagedObjects (they can't directly refer to one, or they'd just serialize a stale copy along with their own state when they get saved). Haven't looked at the source, but I'm guessing ManagedReferences are just UUIDs for primary keys along with generics to make life easier. The whole system is a bit annoying to use, until you remember that your using a piece of software that appears mono-threaded but is actually multi-threaded, able to run on multiple JVMs, and accesses a database behind the scenes. Kudos to the team for letting people write servers without reinventing the concurrency wheel, or the database tier wheel, or the communication wheel. The only major issue is lack of garbage collection on ManagedObjects (they are stored in a database, after all). Could turn some Java programmers off, though it might be possible to write a Task that performs a garbage collection on the database periodically.
  • Darkstar seems to solely use Berkeley DB. I can see people in the near future writing extensions to let Darkstar use all sorts of free or proprietary databases. Hey, if you already own an Oracle licence, you might as well use it.
  • Unlike the server, clients can be in any language. The client APIs at the moment are in Java and C. Communication between the server and the clients are done with byte arrays, and thus can be language independant (though if you only want Java clients, I guess there's nothing stopping you from serializing communication objects). In a way, I wish Sun would have made all communication with XML, and had the Java API use Documents for communication. I understand what they did was for generality and performance reasons, but another useful extension would be making XML communication a breeze. From the initial projects I see right now, communication is done through serialized Strings, which is fine for whipping up a MUD, but not for a game of decent complexity.
  • The client API is event-driven, which makes writing a traditional MUD difficult. I tried making my client run off the terminal at first, but then gave up and began to use Swing. A cleaner client API for those who want to write MUDs (all communication with Strings, blocking I/O, etc.) would also be great.
  • Finally, I don't think Darkstar is just a game server. You have this great framework for dealing with persistent objects on a server that can span multiple machines, with the ability to connect to an arbitrary number of client machines. This doesn't have to just be gaming software (to pick an example, Sun's Project Wonderland is built off of Darkstar). By the same stroke, Darkstar is too generic to be immediately used to build games. There will be the need for a role-playing framework, a first-person-shooter framework, and so on.

Pretty interesting stuff. Might give me something to do for the next little while. Summer activities are slowing down, and I'm beginning to feel the absence of homework.

The 'c' in filectime() doesn't stand for create.

Who knew? Anyway, no content, but I'm having fun learning CSS.

ANT! BERKELEY DB! IVY! JIRA! NETBEANS! SOAP! TOMCAT! XML-RPC!

Otherwise known as: I started work this Monday. A steep learning curve, but I haven't gone crazy. Yet. In light of recent events on Shadow Vale, I have ceased the strenuous work on my unfinished scenario, and produced another. You can find it here. Remember, always take my scenarios as seriously as they deserve to be.

Hello World

Don't let the new layout fool you. There still is nothing on this site. Hopefully, that won't last long, but don't get your hopes up. Right now, I'm just playing around with PHP. I didn't do much refactoring, and most links should still work. /developing/ moved under /scenarios/, and both /dikistats/ and /dumps/ moved under /misc/ (if for some strange reason you need access to those things).