I’ve spent some more time over the last two weeks working on putting an idea of mine into action. My plan was to use Google AppEngine to serve the application and store it’s data in BigTable. After I spent some time with JDO annotations and making sure I got them correct I sent the application to the AppEngine dev server using Ant on my local machine and received an odd runtime exception. I received a similar error when I pushed the application up to Google’s servers. After spending quite a bit of time trying to debug an unfamiliar error I asked on the Java AppEngine Mailing List if there was a problem with JDO annotations and Scala. The response I got was that it was a known issue with the 1.1.0 version of the DataNucleus enhancement process.

I did as the thread suggested and replaced the datanucleus-1.1.0 jars in the AppEngine SDK with downloaded 1.1.2 jars. This eliminated the runtime exception when deployed to both the dev server and Google’s servers when attempting to save data. Sadly when I attempted to take the next logical step with the application code and retrieve data for display as well as save it I ran into a new exception. As far as I can tell the error is due to the internals of Google’s datanucleus-appengine (1.1.0) jar being incompatible with the newer datanucleus jar files.

Despite how much I would have liked for persistence to be handled easily on the AppEngine, mostly because I wanted to use the Google’s servers rather than having to host it myself, I am not really upset about being unable to use the JDO annotations. I could attempt to use JPA annotations rather than JDO and see if they work better but to be perfectly honest using the annotations forced the me to use mutable model classes which felt pretty un-Scala like to me. So for now I’m back to the proverbial drawing board on persistence and I’m even considering not using a persistence framework and interacting with the database through plain old SQL statements. I recognize this will force me to maintain the schema myself but at least I would feel like I was using the Scala language properly.

I did look for some Scala persistence frameworks but most everything I found is using Java based persistence in Scala classes and I’m just hoping to find a solution which feels more, I don’t know… correct.

After seeing a post on the github blog about David Baldwin using github as his blog I got to thinking about how much easier it would be to create my markdown posts offline and then commit them to some repository and have them show up as blog entries.

The comments for the github entry point out a number of people using various solutions to achieve an effect similar to what I want however I am somewhat loathe to give up on a web interface in general and Wordpress in particular. But this did get me thinking, what about a post-commit hook so after every commit a script examines the changed files and creates or edits posts as necessary. Google didn’t turn up much of anything in the way of making this happen and so I started thinking about how I would write my own solution.

As of right now I’m just in the planning stages but I did realize it would have to be a pre-commit hook on account of wanting to track the post id somewhere and the most logical place seems to be as some meta information at the top of the post. Currently I have the pre-commit hook reading the information I need to send about the post out of the file, the next step will be to figure out creating an XML object to send to the xmlrpc.php file of my Wordpress installation. In addition to dealing with hooks and xmlrpc¹ I’m writing the script using Perl in order to get some hands on experience with it.

I’ll admit I’m not 100% sure I can make the script do what I want it to do but I’m certainly going to give it a shot because looking at the solutions eluded to in the comments of the post on github there doesn’t look to be a solution to satisfy me yet.

My initial planning has the username, password and xmlrpc url being stored as config options via git config username|password|xmlrpc while post related information is stored in the actual post file. I think the most likely hang up will be modifying the file which is about to be committed (by adding the post id) because I believe I’d actually have to create the post via xmlrpc, write the response into the file, stop the commit, add the post file back to the index and re-commit. There may also be a problem with the way xmlrpc expects the categories.² Time will tell.

I’ve been working a great deal with JavaScript Objects which are used purely to store data but which need to be performantly converted into HTML code blocks. In order to achieve this I created a function which searches for specific delimiters and replaces the delimiters with the Object’s property of the same name.

The code to do this is fairly straightforward:

/* This code is released under a MIT license */
String.implement({
	template: function(props) {
		var regex = /%(\w+)%/g;
		var newStr = this.replace(regex,function replacer(mid) {
			var key = mid.substring(1,mid.length-1);
			var value = props[key];
			if (typeof value === 'string') {
				return props[key];
			} else {
				return '';
			}
		});
		return newStr;
	}
});

Using this function I can take a snippet of HTML and a JavaScript Object containing replacement information and easily turn the snippet into a useful String for user with the innerHTML property. For example, starting with the following HTML

<div id="template">
	<div class="test">
		<p>%testName%</p>
		<p>%testDescription%</p>
	</div>
</div>

I can execute this simple piece of JavaScript and get a useful HTML. The JavaScript and HTML output follow.

var newHtml = $('template').get('html').template({
	'testName': 'This is just a test',
	'testDescription': 'Please do not be alarmed this is a simple test'
});
$('template').set('html',newHtml);

The HTML will now look like the following

<div id="template">
	<div class="test">
		<p>This is just a test</p>
		<p>Please do not be alarmed this is a simple test</p>
	</div>
</div>

I’ve found this technique to be incredibly useful. Hopefully someone else will as well.