I really should read instructions and here's a post intedned to remind me of that. I'm getting old, writing things down helps. A lot.
Anyway a lot of faffing about with a [node.js][node] / [npm][npm] problem because of some assumptions I'd made about it working the same as other package managers. The short and long of it is that it doesn't. So some definitions:
As with all good application languages it has a packaging system and central repository called npm.
[npm][npm] installs handy packages for you. Theres a load and the ones I've used seem to be petty robust and well maintained. Then again I haven't used an awful lot of them as yet. In your code you use "require" to pull in a module much the same way that you would in with a GEM in Ruby. And if you want to get a module you just use the command line
This is where it was a bit unfamiliar to me. I pretty much expected it to work the same way as installing a ruby gem, by default it'd be available to all of the ruby apps on my server. It doesn't, the install will happen in your current directory (or somewhere close by, but I won't go into that here ).
Well fair enough, I can see why. Localised versions of libraries means the default is for the author to tightly control the version their app uses. Install a newer version of a module for another app? By default it doesn't matter. That stuff can be a pain in ruby. There are ways and means of handling that sort of problem but you have to handle it.
What NPM will do is install its packages globally if you invoke it with the the -g flag
npm -g install
Well there we go, that's what I needed. So after installing I should be able to just pull in the library I want from any app on the system?
No. It just doesn't work like and I found that out by finally reading the instructions. All you need to do is
And it spews out a big list of mostly stupid questions asked by people like me with misassumptions. No disrespect to the NPM guys, I understand the path they chose and the reasons they did it but as I said at the start I really should start reading instructions a bit more.
What's The Point
So why mess around with this stuff? At Ruffian we're working on a self-funded project for a bunch of interesting and great reasons outlined by Billy in this blog post.
We're on the runway right now for a friends and family alpha test, the start of a longish journey of testing and tweaking that'll help polish our game into a shining beauty. It's going to take a while and one of the things we'll need to do is stat collection. For the first pass we don't have anything planed right now.
Stat collecting is pretty hard in my experience, it's not so much the mechanics but it's easy to get analysis paralysis about what you capture.
I'm pretty bad for that, sometimes I can mistake thinking about something for actually doing the thing. It's a behaviour pattern I try hard to recognise in myself and then break.
So what I thought may be a good idea is to just set up the mechanism technically for capturing unstructured data and we can just have the game spew out data to our capturer. A philosophy we're trying to follow for our own funded project is to have a really tight try->reflect->change cycle. Try stuff out, reflect on the implications, make changes and then GOTO 10.
If the game can spew unstructured information to a permanent store over time we can adjust the data it's sending to be more structured and in time let us have a stats backend we can get meaningful data from.
So we'd need some sort of server that can quickly capture and store simple KV values?
Someone's done one :D
And it looks good. Trouble is I'm an idiot so I've written my own in, yes, node.js. I've also an unreasonable prejudice against PHP. Yeah I know. That all said the API I implemented is pretty much the same as OpenKeyVal's. If my shonky work isn't up to scratch then it'd just be a case of pointing the game at their server or taking their code and putting it on our server.
What I made seems to be working now. I'll write some more tonight about the approach I took and what I found out. High level take aways (and why I thought I'd write -something- about it)
- This is an environment that's very quick to learn and do something in I've spent about five hours in total and have something I'm happy with. Thats' amazing for me, new language, new app environment, devved on a mac and deployed with ease on a Linux. I even learnt some c# for a c# command line client test.
- And that's despite some self indulgent mucking about Rewrote what I'd done in coffeescript (syntax sweeting for js, makes simple rubyists like me feel more at home)
- There's a lot of current interest in non structured database The NoSql approach. So I thought I'd have a go at Redis for this. It seems to be working and pretty fast too.
Code can be found on my github -> https://github.com/gazliddon/keyness
As a nascent JS and CoffeeScript programmer I'm sure it's idiomatically vile stuff. This kind of functional stuff is new to me but I think I'm getting a sense of why it's a great approach for asynchronous programming compared to the ugly and error prone locking approaches in imperative languages
Worth Pointing Out
I'm not a programmer! I mean I used to be. A long time ago in a galaxy far, far away but that's not what I do these days. And that's good because if my code is bad I got a great excuse :)
Tribal Towers Blog Post
Tribal Towers Blog
Tribal Towers Forum