grails notes

Grails note to future self: domain object String are assumed to be not nullable. Plus, .save() with failed validation returns false but does not throw an exception.
(You can call .save(failOnError: true) though)
---
Also, IntelliJ's debugging with breakpoints wouldn't work until I followed the advice at http://stackoverflow.com/questions/19247944/intellij-idea-debugger-isnt-working-on-a-grails-project, namely swapping out BuildConfig.groovy's grails.project.fork to

grails.project.fork = [
        test: false,
        run: false
]
---
Also, when making a domain object, it can be tempting to just define a 1 to Many relation with something like:

static hasMany = [ people : Person ]

The thing is, you might have to explicitly declare a member Set... also if you are adding in things to the many and they have a pointer the other way, you might have to explicitly set that as well. (I think using the default scaffolding hides some of the potential tripups of GORM)
---
LOL, this is turning into a liveblog.

Had some frustration because I assumed setting "many" members of a one to many relation, and then saving the parent object, would save the members. NOPE!

However, I like being able to say
def map = ["code": params.id,"group":myGroup, people: myGroup.goons as JSON];
That as JSON is pretty sweet, and a nice way to shove stuff into JQuery land.
---
YAARGH... if you're not doing things the right way and putting stuff in services and transactions and what not, DON'T FORGET TO FLUSH. I burnt like a super frustrating hour on this.
---
More late hour mistakes: unlike some similar systems, Grails isn't smart enough to say that a parameter coming in as the string "false" is actually boolean false.
---
OK, that was fun. By fun, I mean intensely frustrating at times, but with success at the end.

Probably my biggest rookie mistake was having my Grails controllers manipulate domain objects directly rather than using Services - which also would have helped me construct some better tests.

It's worth me reflecting on unit tests at that point. I write tons of ad-hoc, test-ish things when I'm developing, I tend to code in almost absurdly small tests and make sure what I just wrote works before moving on. But I guess each one is a proof to myself that I am using the system correctly... so when the part it's working on works, I throw the ad hoc test bit away. In general, I don't intuitively feel the value of preserving the ad hoc test by elevating it into a proper unit test; if what it's testing fails, that seems like a really fundamental problem in the underlying plumbing! I have more of a knack for component and integration tests.

A lot of smart people emphasize unit tests, and while they still feel "too small" to be useful to me (and also much more likely to be confirm implementation than functionality) I want to better internalize the instinct for them.

Here's a pretty good page: What I wish I knew about Grails before my first Grails Project.

GORM seems better than some alternatives, but its opaqueness added a lot of friction to this project. It's funny, too, because really the Object layer was an artifact I didn't care about much, just a middle man between some underlying relational storage, and the JSON that I really wanted. (Alas, the old "Object Oriented Porgramming Oversold" site, a surprising survivor of the worst of the geocities purges, finally sucumbed, but you can see it on the Internet Wayback machine. Again, sometimes it's hard to say that kind of thing without sounding like a kook, but I think he had some points - which is one reason why people dig "encapsulation over inheritance", for instance.)
---
PS if using "grails war" to build something for tomcat 6 (instead of 7) you may have to edit
grails.servlet.version = "3.0" 
to 2.5 in BuildConfig.groovy

grails quickie: random key gen

Doing a hackathon project in Grails, partially as a learning exercise.

Man, it's so slow using a new environment, even one meant to be lightweight and fast like Grails!

Anyway, this came up in two projects... to generate a random unique key:

int keyLength = 8
String charset = (('a'..'z') + ('A'..'Z') + ('0'..'9')).join()
String randomString = RandomStringUtils.random(keyLength, charset.toCharArray())

when I paste that into IntelliJ, it offers to autoinsert

import org.apache.commons.lang.RandomStringUtils

which according to this SO page (probably where I got this snippet at first) is already on the Grails classpath.

html5 autocomplete without js!

From this codepen.io...  just do something like

<input list="dwarves">

<datalist id="dwarves">
    <option>Doc</option>
    <option>Grumpy</option>
    <option>Happy</option>
    <option>Sleepy</option>
    <option>Bashful</option>
    <option>Sneezy</option>
    <option>Dopey</option>
</datalist>

to get this:

Excellent! I kind of wish I knew an easy way to extend that to multiple entries, like with a tag system.

wunderground - weather edward tufte could be proud of

For obvious reasons, Bostonians have been EXTREMELY INTERESTED in the weather as of late. It has been a heck of a season here in "Hothworld".

There's a plethora of apps and sites out there to tell you the forecast for the next 5-10 days, but few that hit a sweet spot of conciseness and detail. Some take very wordy approaches, like the local TV news weatherman, and go on and on about fronts and pressure systems and what not. It's can be nerdily interesting, sure, but a bit much when you're just trying to make plans for the next few days. Others, like the default iOS weather app, undershoot: each day is represented by a single weather type icon (sun, snowflake, cloud) and two numbers (expected high and low). That's not enough info! There's such a difference between a sprinkle and a deluge, or some light snow flurries and the kind of blizzards Boston has been enjoying, but you don't know what to look out for with such a simplified display.

Enter Weather Underground. There's a lot going on on their typical city weather page, with a day summary (they use different modalities, including a unique version in words "Today is forecast to be MUCH WARMER than yesterday.") But my eye is always most drawn to their 10-day-forecast:

It's a little hard to see shrunk down like this, but it is truly a thing of beauty. If you're in a hurry, you can just skim the top row, and get about the same amount of information as the iOS app. But then, below that... WORDS! "Snow Showers" says something that a mere cloud with snowflakes icon doesn't. More importantly... a guesstimate as to the AMOUNT of precipitation, and a reminder of the type (rain vs snow, with the icon ghosted out if it will be a trace amount.)

(If I had a program on my phone that was just that top row, that would probably be sufficient... Sadly, the iOS wunderground app drops the precipitation amounts... clearly someone there doesn't realize the beauty of what they've got.)

Below that is a graph that seem to risk information overload, but it's still cleanly presented. There's a certain pleasure in seeing the red line mark the rise and fall of temperature over day and night across multiple days. Personally I don't find the "pressure" line as useful, but it's educational to see how the rise in pressure tends to precede precipitation. And the break-out of precipitation in amounts over the course of a day is great in an area where mornings can be snowfests and afternoons crystal clear, or vice versa (also, the area under the precipitation graph (time duration x probability) echoes and reinforces the guesstimate as to total amount.)

Wind speed and direction aren't often useful to me personally, but it's easy enough to ignore that bottom part, and I imagine very interesting for some regions and/or activities. (The arrows embedded on the line itself help distinguish it from the other two lines. Similarly, red is a good choice for a temperature line, because of the semantic association with heat.

Information Display expert Edward Tufte (his last name pronounced so that you can slip it into that "Humpty Dance" rhyme) talks a lot about "information density"; the more meaningful information you can put in proximity, the smarter an analysis you let people make. (Personally I think he tends to neglect ideas like chunking and other tough to quantify aspects of helping people navigate great volumes of data, but still.) Compare wunderground to Google's default weather display:

It takes up about the same amount of screen real estate, but tells you so much less at a glance. There's no whole day precipitation estimate. Much of the same hour-by-hour temperature / precipitation / wind are there as well, but you have to click for it, you can't get it all at once.

I admit Google's is prettier, and has that nice sense of breathable white space, and so some might prefer it. Overall though, I'm smitten with wunderground allowing me to absorb the story of a week at a glance, and wish more apps would give the total precipitation estimations.

scrum/kanban standup timer

PROBLEM: In our retrospective, it was brought up that sometimes the daily standup meeting drags, in part because we get too focused on a ticket, solving-problems, etc.

(PARTIAL) SOLUTION: http://kirk.is/tools/standuptimer/ , a trivial webapp (on the same shared desktop screen) with a simple stopwatch to quietly keep track of time elapsed and a notepad to jot down what should be tabled and discussed at the end of the stand up. When the elapsed time is greater than the goal time, it simply changes to red - enforcement is still up to the team.

TECH NOTES: Not a lot to report. In order to try and strengthen good habits I put it in a self-executing anonymous function block, though it's meant to be standalone. (I can't wait until Web Components become everyone's standard goto for this stuff -- it would provide a parallel kind of wrapping for the HTML and CSS that we have for Javascript. (And the Javascript, for that matter, without needing the awkwardness of the block.)

I also thought localStorage was about the right level of persistence for the goal time and table'd item textarea; enough to be lightly persistent, but no worries about the server grabbing information.

I was thinking about making a gong play or something when time was elapsed, but it just seemed like would be distracting.

I do dig being able to whip up things like this in short order.

programming the atari 2600 part ii: loaded4bear

(2018 Update: I'm putting backups of some of the tools here)

I went to the MIT site for the Global Game Jam, a worldwide "make some new friends and make a game with them, in one weekend!" event I've annually since 2009. One of their optional "diversifier" bonuses (extra gimmicks to aim for, beyond the main theme) was

NES: Make the game playable on an old school console, either directly or through an emulator.

I could do that! I'd made an Atari 2600 game before! And thanks to a kind of amazing creation called batari Basic I thought it might even be doable over a weekend, instead of a year and a half.

Enter Batari

Batari Basic is a genius, enabling tool for the creation of Atari 2600 games; it lets you code game logic in something like good ol' BASIC (and then formally compiles that into assembly language, rather than being interpreted) but more importantly it takes care of the all important, super-difficult display kernel. It also uses some of the precious Atari 128-bytes-of-RAM to store a big, clunky playfield that can be manipulated on the fly. In short, it's one of those homebrew things I never would have thought possible until Fred "Batari" Quimby came and did it.

I pitched a vague idea for an Atari game (something about 2 players indirectly fighting each other, maybe by pushing blocks around - initial game proposals are notoriously disconnected from final results at Game Jams) and attracted a small team consisting of me, Oliver Getz on music, and Winnie Gong for art.

It was pretty touch & go the first night; I tried to get a development environment going, just to make sure that what I was proposing was even feasible. I was an early proponent of batari Basic in 2005, and even created its first homepage, but it had been years since I've played with it, and in the years since I'd switch to Mac, so that was another known risk factor.

The Setup

The first step was getting an emulator going to play any results on: Stella (go to Downloads | Stable Releases on the sidebar) seems to be the default choice.

A few of the Stella defaults were a little wonky (by default, it uses ctrl for the fire button, which when combined with arrow keys becomes the OSX "Change Desktop" keypress... and while my first USB gamepad was sensibly detected and assigned, with the second one I had to go into settings and manually configure up, down, left, right, and fire. Also, PROTIP: for a more fun/authentic experience, go to Options | Video Settings | TV Effects and put it on "Bad Adjust" - it's a bit more true to the old crappy switchbox connections we had back in the day.)

See? It's too pure, too clean!

"Bad Adjust": That's more what we remember, scanlines color bleed and all

Of course here the temptation is to just spend the night playing old Atari games ("for inspiration"). (By the way, a great spot for ROMs as well as community (players and programmers alike is http://atariage.com - they're even the place to go if you want physical versions of your game made.)

The second step was to make sure I could run batari Basic. At the moment I'm working with some of the bB keepers to improve this process, but I think the easiest path at this moment is to get the .zip file from http://atariage.com/forums/topic/214909-bb-with-native-64k-cart-support-11dreveng/
(I found it better to not have any spaces in the path to those files or my build files.) I unzipped the contents of that file into ~/dev/atari2600, then I added

export bB=~/dev/atari2600
export PATH=$PATH:$bB

to my .profile, at which point I could go into the samples/ folder and run

2600basic.sh zombie_chase.bas

which produced zombie_chase.bas.bin, and I could play that in Stella.

The Music

Once I had proved I could make Atari programs on the Mac, I wanted to make sure I could set up Oliver to do his music thing; he was enthusiastic about learning about and working within the constraints of the system's sounds. Years ago I had made the page do re bB: the BASICS of batari music that provides an overview of the theory and practice of the beast, and includes webTune2600, an HTML front end I had made to a command line program that would find the "nearest hit" note sounds for Western music so I was able to point him to that.

(I was a little surprised webTune2600 still worked - my sample batari Basic music code on the page had (memory-wasting) loops with some code that was busted on modern bB, but I've since updated the page with corrected versions.)

The Panic

The chronology is a little fuzzy to me; I think of as of Saturday morning, I was just getting over the issue with music, and I was still nervous about taking on this project. I had a fallback Plan B of making Yet Another Processing / html5 game, which had the secondary benefit of giving our artist Winnie more stuff to do. (Integrating art and keeping non-programmers occupied while the code grinding is underway are frequent challenges for Global Game Jams - and even more so with the minimal "pixel art" I needed for this game.)

But Oliver encouraged us to step up and just DO this, and that's what we did. I was impressed with the aplomb with which he took on the techie aspects of this; I showed him "do re bB" and made sure his compiling system worked, and he took it from there, and provided 3 great sets of music. He also listened to my feedback for specific musical bits (I'm an amateur tuba player myself, so just full of bad ideas) and he seemed an eager audience for some of my old school video game music knowledge (I showed him the hyped up Toccata and Fugue from Atari 2600 Gyruss, Rob Hubbard's C=64 Intro to Skate or Die, and the jazz improv of Atari Ballblazer (comparable to Coltrane, according to musician Pat Metheny) - Oliver himself sings in Berklee's "Video Game Music Choir" so he has a bit of an abiding interest in this stuff.)

The Grind

From here, it was time to hunker down. Some of the modern batari Basic users are fans of "Visual batari Basic", which has some integrated graphics editors and what not, but it's Windows only, and I prefer command line tools (In retrospect, I should have at least set up an editor to do syntax color highlighting.) However, my past self was more into this than I remembered - I had made a browser based sprite editor called playerPal 2600... a little clunky now, but pretty slick for 2007 or whenever it was. You can draw up multiple frames of a multiple color sprite, go to "generate code" and it will output code you can put into a "foobar.bas" file, type "2600basic.sh foobar.bas" and get out "foobar.bas.bin" - this is a binary you can immeditely run in stella, or even dump to a real Atari (especially if you have a Harmony Cartridge), and just like that your little character is running around in real Atari space. (And unlike my music sample code, the code produced by PlayerPal works fine on modern bB!)

The semi-canonical reference for the language is the GIANT batari Basic Commands page, kept up to date by "Random Terrain". This page is... kind of overwhelming.  It's so much information, and not always put together in a way a newbie might find intuitive (I've been collaborating with RT to help smooth out some of the rough edges.) Still, I was able to piece together stuff I had forgotten along with new stuff that had been added.

The game evolved organically from this point, based on what seemed fun with what batari Basic made easy. It's very good at shoving the Playfield Pixels around (big blocks on the screen, vs the smaller playfield graphics), and so one early thing I tried was having the blocks move the opposite way than the main character (which turned into a bear, for no reason better than that's what emerged when I started playing with playerPal 2600) Even without having the playfield blocking movement or shots, it added a kind of pleasing, noisy "camouflage" aspect to things. I added a second player and had them start shooting at each other - not such an original choice, but promisingly reliable for the game jam.

The nice thing was at this point we were making playable demos, and I was able to have Oliver (who was toiling by my side, sometimes on Atari music, but also moonlighting on some of the other GGJ games) test out various ideas, and then we would choose what seemed the most promising. I started with typical "bullet moves in direction player was last moving" (which was tricker to make than I had suspected), then switched to "spears" - horizontal or vertical, and you could steer perpendicular to the main movement. Over playtests this (d)evolved to a simple "you can totally steer your bullet, but you are frozen (and vulnerable) as you do so". Similarly, while more subtle movement is possible on the Atari, it was easier to keep the players and the bullets moving at the same frenetic speed. (Since the Atari 2600 runs at 60 Frames Per Second and has low resolution, it's easy to make things run pretty fast and harder to make them move more slowly.)

The Result

So that was the game!  I liked the balance of offense and defense; you freeze and become more visible when you fire, and you can also wrap around the screen, so there's a lot of opportunity to try to catch your opponent unawares. There are little psych-out strategies like making your opponent think you're focused on your bullet, but then immediately firing a new bullet as they try to sneak up on you. (And again, bullets and bears move at the same pace, so there are some fun race around the screen times that happen as well.)

Before the next afternoon we added scoring, a splotchy-explosiony sound, a title screen, an end screen, and I integrated Olivers' 3 songs (a catchy, funky title song, an anxiety-producing gameplay tune (using only one voice, so the other could do the explosions) and a small victory ditty.) You can download loaded4bear.bin at the project website, or here is a demo if it in action:


You might have noticed I didn't talk about Winnie's role much... unfortunately she was sick for Saturday and Sunday, but she made up this awesome 2600-style box art for it:

(I love the box art tradition that has so little to do with the game inside...)

Oliver and I also made a cheesy old school rap, to liven up our presentation in the truest of 80s spirits:

My name is Kirk

and I'm here to say

I love Atari

in a major way!

We made a game

that's lots of fun!

You play a bear 

with a BIG SHOTGUN

(Ok, by this point in the weekend we were both pretty loopy.)

Anyway, a new Atari game in a weekend! Its been nice getting back into the scene a little bit, and maybe I'll get some more Atari work in before the year is out.

sqlsmush: primitive sql/iBATIS query log and parameters log merging

Last year I was doing some SQL log spelunking, and was getting frustrated when I wanted to rerun a query iBATIS had generated for me... it was generating SQL with great big heaps of parameters, but putting the actual injected parameters on a different line of the log, and merging the two was frustrating and error-prone.

I hatched up a primitive script to merge the two lines: http://kirk.is/tools/sqlsmush/

Roughly speaking, the top field gets something like

select * from user where firstname = ? and lastname = ?

and the bottom gets

Parameters: [FOO,BAR]

and then pressing the button spits out

select * from user where firstname = 'FOO' and lastname = 'BAR';

which can actually be copy and pasted into MySQL Workbench or wherever, and modified, and the results inspected.

(It turned out to be easier to suggest double clicking on the log in intelliJ to highlight the whole line, and then it can be copy and pasted in the blank, and so the primitive script kind of relies on that, like how the second line will start with Parameters:)

Primitive, not super-robust, but useful! Coworkers were asking about its location today, and so I thought it deserved its own devblog entry. I enjoy being able to craft and host simple tools such as this.

textarea autoresize in jquery

Jack L Moore's autoresize for textareas is pretty hip!

quick points on the wii

I just finished Codename Revolution: The Nintendo Wii Platform. It's part of the MIT Press "Platform Studies", books that discuss specific video game platforms ranging from low level technical details, to high level design and aesthetic decision, to wider cultural implications.  (Bogost and Montfort's amazing Racing the Beam on the Atari 2600 being the first and foremost book in the series.)

A few minor thoughts while reading the book:

1. The book goes into some detail about the main menu of the Wii, how it was meant to be friendly and employed the idea of television-esque "channels" (which extends the a metaphor of the living room placement of the Wii, also echo'd in the use of "remotes" as the primary control.) One particularly unfriendly aspect of this menu is that you can ONLY select a channel by using the Wiimote in its "laser pointer" mode - and therefore have to have the sensor bar set up and well-positioned, a Wiimote ready to go with battery, etc. It would have been fairly trivial to allow, say, a Gamecube controller, or even the Wiimote D-pad, to select a game, but they elected not to do that. 

Combined with the way inserted discs don't "autoplay", this may have been a deliberate "forcing function". Despite the "this is a virtual console" rhetoric, it's as if they don't want you to forget you're not just playing a Gamecube. (I feel this more pointedly because at my folks' place, we use a projector, and would prefer not to have a sensor bar always strung across, especially if we are just playing Super Monkey Ball 2 or what not. Ironically, the workaround for us is to use a Guitar Hero guitar, which has a small joystick that can control the cursor, since the guitar otherwise blocks the IR sensor)

2. I was wondering if the book would mention "Super Monkey Ball: Banana Blitz". It was a launch title, and the first to really explore the interaction space of the Wiimote, via some 50 minigames. Some of these totally fall flat on their face, the pre-Motion Plus sensors just aren't up for what the designers are experimenting with, such as using the Wiimote like the slide of a trombone. (It also suffered from the early Wii lack of standards for buttons for pausing / restarting games etc.) Some of the other modes were quite clever, and I was disappointed never showed up elsewhere, like holding the Wiimote upright as a (slightly clumsy) "flight stick"-style joystick, one that didn't need a fixed base. (The fact that the minigame used it to pilot a submarine probably reflects the lack of precise control the early model suffered from.) 

3. While the GameCube gets some attention in the book I would have loved to see more mention of the Nintendo 64; in particular, when discussing Nintendo's philosophy about games as a social space, this device having 4 controller ports was very forward thinking. (And of course, the much-maligned 3-pronged controller pushed the envelope as well by introducing/popularizing an analog thumb-stick, and then later things like the rumble pack.) Personally, I'll always hold a small grudge against Sony for having the industry-leading PS2 only support 4 players with use of a separate device, and thus less support from game developers.

Overall the book is a fine read.