one weird trick for making a page think it's somewhere else

Haven't thought of this trick for years, but it's good to know about:

if you're ever updating a page that might, say, usually live on a remote server, but you want to edit it locally, and without pulling down all the css, images, etc, you can tell the page that all relative links actually should be based on a specific URL using the <base> tag... for instance, I'm editing the front of alienbill.com so I put
<base href="http://alienbill.com/">
at the top.

In effect, it makes pretend that the page is at that location for purposes of image references, stylesheets, etc.

FOLLOWUP: I update alienbill so its use of old school display tables and what not is no longer professionally embarrassing. If you view the source, you can see how I got the block effect; sometimes it's hard for us veterans to remember you get your anchor blocks to act a bit more like divs and what not.

programming the atari 2600 part i: joustpong

In mid-2002, I decided to port my original Visual Basic videogame called JoustPong to the Atari 2600 - a system that had been released a quarter of a century earlier!

JoustPong (or FlapPing as it was later renamed, since the Atari Corporation feels it has exclusive rights to games with the word "Pong" in the title) is among the simplest of games. It came from this quote from a person named "Otter" on the old Usenet group rec.games.video.classic. In 1998 Fairfield Research had kind of spammed the group about Gaming 2001-- The Future of Gaming! and he replied:

"The future of gaming can be summed up in two words -- Pong and Joust" 

Dan Mazurowski then brainstormed this idea:

JoustPong - what a great idea! Two great tastes that taste great
together! Hey, your Joust is in my Pong! Well your Pong is in my Joust!

Seriously, the idea is intriguing. Each side has a bird that can move
vertically (and ONLY vertically) by flapping. They bounce an egg back on
forth. If they miss the egg, it lands in a hatching area (nests?) and
three riders are born. Then they all jump on birds and attack the two
players. When they are knocked from their mounts, you have eggs bouncing
around pong style again, which eventually end up in the nests, to
produce three more riders. Each generation is different, just like in
regular Joust. After three generations, the level ends. Higher levels
could feature more eggs, obstacles in the playfield, bonuses, and
perhaps special items to bounce at the other player to kill them. Of
course there would also be visits from the Pteradactyl, and perhaps the
lava troll could climb out of his pit once in a while for some fun. For
a one player game, the gameplay would be similair to handball (keep egg
in play to avoid hatchlings and rack up major points).

I can't believe I have just come up with an arcade game idea that
requires only ONE button to control it.   :)

I was then inspired to actually make this game -- or at least the first six sentences and concluding remark of Mazurowski's pitch. I used Visual Basic - a language I taught myself in the early 90s, and actually had taught in a class at Tufts University. (In their "Experimental College", where anyone, even undergrads can propose a for-credit course to teach.)

I simplified the game down to its Pong-like layout, and came up with a pleasant surprise: not only did it play well, it was easy to make a computer opponent that could pay a decent but imperfect game. For human and computer player alike, pressing the button to flap against gravity was simple enough, but it was easy to overshoot as well.

(I'd like to add that VB3 and VB4 were delightful little languages, and empowering. Around the same time I had to learn 16-bit Windows programming in C, but it was so cool to be able to whip up a little game like this (or InterGalactic SpaceMan BlastFest, an original concept so desperately in need of remaking) in a short amount of time. I had nothing quite like these languages until I discovered Processing in 2004 and could put my Java skills to work and share my stuff online.)

In 2002, having already made a few ports of the title (including one for the Palm Pilot using a fun little on-device compiler and runtime called "PocketC" and a Java servlet) and seeing the flexibility of the concept, I thought that the time was ripe for porting this game so it could run on an actual, physical Atari 2600, the pre-eminent system of the early-1980s, and a nexus of my childhood playtime. (The circumstances of the Great Video Game Crash had left me with a larger than average Atari collection.) There was a small scene for Atari homebrew, focused on the Stella mailing list, and over the course of the project I received support from the site AtariAge.com - still going strong as the preeminent classic Atari resource. (They're the ones who produced the physical cartridges in the end.)

The Stella list was full of smart people, most of whom understood assembly language and the peculiarities of the Atari 2600 chipsets much better than I did. Many of them loved programming the Atari because it was so challenging, unlike me who loved it despite of the difficulty. (I tried to pay back to the community by making a tutorial for the novice, 2600-101 - I've gotten feedback from people who found it a great help.)

The Atari is such an odd beast to code for - having to do so in primitive assembly language was only the first hurdle. The best description of the effort is Nick Montfort and Ian Bogost's book Racing the Beam. Unlike systems that had a reasonable amount of memory, the Atari didn't map memory so that you could, say, turn on a pixel at a certain coordinate. Instead, the programmer had to stuff graphics data into memory locations at just the right time as the electron beam swept across the TV screen, and he or she didn't have many programming instruction cycles to do it in. It is a testament to the design of the original system, designed for ports of simple late-70s games like "Tank" "Pong" and "Outlaw", that it could be geared up to do some amazing feats of visual game design (I've always been impressed by the port of Battlezone.)

I kept a Developer's Blog throughout that time, 2002-2004 (including a year hiatus in the middle) Sadly, and strikingly, those dates are also bookends for my first marriage, mentioned as asides in the blog itself. While I think it's unfair to say that this project "destroyed my marriage", there's certainly a chance I should have been focused on showing my partner that I was interested in growing to be a better partner, rather than indulging my inner man-child on projects like this. Live and learn! Or live, anyway. (Still, tough to know if such diverted focus is a symptom or the disease.)

Anyway, I got the game done. Reading through, I had forgotten what an immense struggle it was at times! Since I was hoping to make something interesting enough for collectors to purchase, over time I added a few elements back into the simplistic formula. "Pterry", the pterodactyl from the original title, flew figure-8-ish patterns, and would add a bit of chaos and unpredictability by batting around both the ball and the players themselves. I also threw in a variation with defensive walls - looking a bit like a vertical version of Breakout, but it was the original pun title "Poorlords" that stuck, since the awesome 4-player game "Warlords" also featured defensive walls, and this was like a 'poor' version of that.

And now, this programming projects dirty little (not-quite) secret... the heart, and hardest part of any from scratch Atari game, is the "kernel" (where you're actually drawing the screen / "racing the beam") and I had a clever but not brilliant one. Because the Atari only has 2 player sprites at once, when I added Pterry I used the "flicker" strategy: one frame would display Player 1 and Pterry, the next frame would have Pterry and Player 2, the next would have both Players and no Pterry sprite... but at 60 FPS, the flicker is slight.

However one of those Stella wizards, a man by the name of Paul Slocum, figured out how not have to do a flicker at all. The Atari has a few tricks they threw in to mix things up, including doubling or tripling either player sprite (making 2 or 3 identical copies on screen.) Slocum's genius was to push one sprite all the way to the right of the screen, and THEN duplicating it, which shoves the clone back to the left side of the screen. By carefully tweaking the timing and putting in the right bits at the right moment, both players could share the single sprite, and so Pterry could have his/her own as well. This was a kind of programming genius!

So once I was finished I had physical cartridges made and sold, including color manuals and label arts... we even released it with limited edition custom T-shirts!

I still think JoustPong is kind of a terrific game.

There is something so cool about a game that can be even simpler than Pong - a single click-button suffices where otherwise a fancy twisty knob would be needed. (Of course, Pong is a bit more complex than people give it credit for - not only is there a lot of "English" to put on the bounce, the original arcade game even has a fancy ending screen!) And the iOS enfant terrible Flappy Bird used the same basic "flap against gravity" mechanic. (Actually if you aren't inspired enough to download an Atari Emulator and grab the Rom from the AtariAge page you can get the idea from the processing.js/HTML5 port of FlapPing that I made for a "Flappy Bird Game Jam" - one player only, but it has an acoustic (Tuba) cover of the 2600's theme music.)

I've enjoyed seeing my game in action - at the now defunct New England Classic Gamer's trademeet, we held a tourney, and the drama of it was palpable. The tension among the spectators ratcheted up with each brick knock from the players' defensive walls - this game is a very decent quick deathmatch.

So despite the possible cost to my personal life, and despite having humbly acepted a much more finessed version of the heart of the code, I am still proud of having slogged it out. I think my circa-2003 self should somehow be a rolemodel for my current edition. (If a bit more mature and more aware of the emotional needs of the people I love.)

(Heh, googling up Dave "liveinabin" Exton, who made the cover art, I found this interview I had given to Gameroom Blitz and then totally forgotten about. That's at least 16 seconds of my Andy Warhol-promised fame!)

unixish recursive copying of files newer than X

This probably isn't the most efficient way of doing this (more of a note to my future self, because this is good enough.)

Googling for how to just copy files newer than a certain date, I realized I didn't want to copy per se, that it was probably better go ahead and do the tar command:

tar -cvf newerstuff.tar --newer-mtime '22 days ago' .

Now in practice, I brought this down to my local machines to test and inspect the results. (After gzip'ing it). This command makes folders for the whole structure, even the empty folders that had nothing new in them... so  

find . -type d -empty -delete

got rid of those, and I felt a little better about the result of tarring and gzip'ing that instead. I presume there might be some way to have the first tar command ignore 'empty' folders, or the fact is it wouldn't have hurt anything if they were included when I untar'd in the new location, but still.

Update: this page shows an alternate method for skipping those directories, but it's still a little clunky, relying on a temporary file touched to reflect a certain date. 

groovy and ambiguity

I'm learning grails/groovy for work.

Grails is kind of cool, though I think its insistence on DRY (Don't Repeat Yourself) and "convention over configuration" lead to code that is easy to write, but harder to learn really well, because there's so much there the novice or intermediate coder might not know. Increasingly I'm aware of a bathtub-curve spectrum of coders, those who prefer power and conciseness, and those who prefer understandability and explicitness.

Anyway, a trivial JSON Controller in Grails:

package someapp

class SomeJsonController {

    def index() {
        def foo = params.foo
        render(contentType: "application/json") {
            ["key":"value", "a list":["1",2,foo]]
        }
    }
}

Put in the correct folder that gets automagically mapped so
http://localhost:8080/mmaudit/someJson?foo=3
returns

{"key":"value","a list":["1",2,"3"]}

I was mildly bummed when I realized my observation that Groovy used JSON as its native list and map syntax was a bit off. It uses [] as delimiters for both, as opposed to JSON which uses [] for its lists and {} for its maps. So you see GWIM (Guess What I mean) magic at work in the code example.

I was curious what happened with the empty collection [] - how would it know what it was?  ... I ran the experiment with that Controller, and it's the empty list. Reading about groovy Collections I find out [] is canonically empty list, which makes sense, and [:] is the empty Map, which seems a little wrong to me - it feels more like a one member Map with null key and value, but I guess that ain't really a thing.

wide screen

Sometimes the answer to a number of web design questions is "well what is company X doing?" -- the assumption being that these are smart companies who might even be doing A/B testing with a lot of thought and metrics. So following FB's lead, it's a decent practice to request a web browser at least 1400 pixels across to show everything? To me that implies they think people tend to run FB maximized, or at about that width - relatively few screens are near double that.

Of course, there was a quiet revolution in the 2000s that tended to abstract literal pixel resolution from what every program feels it's working with. Compared to some early attempts in the first half of that decade, the results are astonishingly transparent to users and developers alike.

decent little online diagram tool

https://www.draw.io/ seems pretty good. Integrates with a few online services like Dropbox.

under the hood

Man. Nothing has made me feel more like a toddler in a toy store than this article on new-ish features on CPUs in a while. Most coders have NO IDEA what's going on in them there chips, myself included.

"the problem with angular"

A friend tweeted me The Problem with Angular. The tl;dr is that A. the syntax is very server-coder minded (I've noticed the resemblance to JSTL etc before) and that it's not super-performant. Personally, I also note that it's not particularly easy to model what's going on in your head.

One disagreement I have is with this bit:

Although there are front-enders that are enthusiastic about Angular, I have the feeling that their number is surprisingly low for a major framework.

Personally, I've seen the opposite, I'm kind of impressed by the number of supporters vs how many places I see using it.

As has been said before:

Working on getting to one of the peeks. I think; I wonder if Angular 2.0 combined with WebComponents will make it less relevant rather than more, as time goes on...

note to self: reset intellij font size

It's a little annoying that intelliJ has multiple ways of changing the font size (including pinch gestures and crap like that) but, unlike browsers, cmd-0 doesn't get things back to normal. (Thus failing the "a UI should do what surprises the user the least" mantra hard - and adding to my general distrust of gestures.)

The most expedient way to get back to normal seems to be hit cmd-shift-a, then type "reset font size". (I dig when UIs seem to blend Photoshop-esque short cuts with Infocom-like text parsers!)

text overlay effect with css masking

A long while ago I made a Java-based tool called k/stencil, though (unusually for me) I somehow removed it from its place on my website, and can't find the old code.

In short I could use it to make stuff like this:

Basically I was trying to automate making stuff like this, that I made in the ancient version of Paint Shop Pro that was my go to for too many years:

Anyway. These days, CSS can totally do the same effect. To whit:

.overlay {
    font-family:impact;
    font-size:80px;
    background-image: url(http://kirk.is/features/wallpaper/full/umbrella.jpg);
    background-size: 400px 300px;
    background-position:-20px -20px;
    line-height:60px;
    letter-spacing:-4px;
    padding:10px;
    -webkit-background-clip: text;  
    background-clip: text;  
    color: rgba(0,0,0,0);  
}

plus

<div class="overlay">KIRK.is<br>k/stencil</div>

can make something like

So, to honor, or replace, my old tool, I thought I'd build a tool. But then I realized that was kind of overkill... I mean the tool I was envisioning would be a highly configurable expert-ish tool,  basically saying "ok, here's the basic CSS, you edit it and I'll show you the changes updating on a sample!". Which is exactly what jsFiddle is. Duh.

So I made one of those!

UPDATE: I changed my mind, because why the jsFiddle is ok, it doesn't let you quickly play with sliding the image or changing it's zoom, so I reinstated http://kirk.is/features/kstencil/. I used basic jQuery mouse events for sliding the background and used noUiSlider as a lightweight library for the zoom widget.  Anyway, check it out, it's rough but effective.

tags n stuff

One thing I enjoy on my personal website is the restrospect page, where I show entries for this month and day for each year going all the way back to the blog's start in late-2000. Another thing I like on the site is a best of page, away of collating times I was actually creative on the day, but I haven't updated that listing for many years. I decided to try to bridge the gap with a personal "tag" based system; since I hit the retrospect page most days, I might as well use that daily review to gather the more interesting content I've made.

So I made a customized version of the retrospect page that I'll use for tagging over the course of 2015. The code I made is terribly hacky (as befits most of the rest of the backend of the site) but two bits of jQuery came in handy: the Tag-It library, which made the tag w/ autocomplete widget very easy, and then I had a chance for me to review using jQuery promises via the when() function, since I needed two separate Ajax queries (one that returned all unique tags, used to populate the Tag-It's autocomplete, and another for any previous tags I had entered) but wanted both to complete before I went ahead and initialized the tag widgets.

Both of those page have concise documentation pages, and I didn't run into any "gotchas", so I'm not going to go into more details here.

semi-meta: blogspot tags and chronological order

I decided to use a tag for my recent run of "advent director's commentary", so I could make a permanent link to the assembled posts. Problem was that the posts are then in reverse chronological order, and would make for backwards reading.

Yet Another Bloggers Tips Blog to the rescue! That link has a script I was able to copy and paste into my template here, and then I could construct the following link:

http://kirkdev.blogspot.com/search/label/advent2014#order=ASC

Cool! I should go back and figure if I have any other series to permalink using it.

animal advent ala ed emberley: director's commentary 21-25

Day 21: Gorilla

The copy of Emberley's book I grew up with had a square on the back cover and the caption "What can you make from this shape? An Ape!"

I made this one fairly early on in the sequence, after the whale, and when i started thinking that every puppet should have some kind of interaction. Its zoom effect is testament to how I made every puppet scalable - most of the puppets don't leverage that much, but I tried to reduce the amount of magic numbers and hardcoding.

Day 22: Giraffe

Actually, this is one of the few others that does use the scaling as well! These entries from the last few pages of the book really have a lot of nice detail and elegance.

Day 23: Alligator

On the home stretch. The disorder of the boxes really adds to the personality of this one, and I worked to make the jaw snap.

Day 24: Dragon

What a beauty this one is! Very tricky making all those funky S-shapes. The fire and smoke was my own creation. I was pleased with the way I got the legs moving.

Day 25: Santa!

The only one that is my own design - and that has its own color palette, distinct from the animal puppets. (It's funny comparing his design to my old Advent santaskate - that the two are so similar reinforces the idea that Emberley was a lasting influence that I reinvoked when I started making processing applets without importing graphics.)

This Santa is actually an homage to a cardboard advent calendar I grew up with, and still makes a seasonal appearance at my mom's house... I made an animated GIF of it a while back, but the short of it is for my folks the pullstring was a slightly naughty joke.

I think I recycled some code from the whale for the presents, but added rotation. (Come to think of it, it's just my old Advent giftplosion.)

animal advent ala ed emberley: director's commentary 16-20

Day 16: Deer

One I created later, when I was kind of scrounging to find enough good candidates to finish the set. The interaction (bowing down as if to eat) is particularly dull, but overall the creature is pretty.

Day 17: Fish

Visually, this is one of my favorites. This plethora of fish really showed off Emberley's design style. And gave me a chance to use some Java subclassing! (Plus, I've been making little fishtanks like this, with the similar sense of kick and water drag since... yeesh, like 1994, in Windows C Programming, or maybe Visual Basic.)

I thought somewhere I heard an admonition not to make "dead fish" in gaming, not to just move a static fish sprite around and call it a day, so each fish here pushes with its fin and tail a bit.

Day 18: Octopus

This one I'm really proud of. I was tempted to just make each an arm an S, and have them rotate around the fish or something, and call it a day, but I realized I could do more. For a long while I've been inspired by the Processing.org "Reach 2" Example - I'm still not sure I quite wrap my head around how it works, and in fact it turned out to be too fiddly for me to use directly, so I had to reinvent the technique from scratch. Each arm is a series of joints, and each joint "wants" to turn to towards the mouse, but each is constrained to a certain amount of angle, and also can only adjust its angle at a specific rate. (Plus, each has a "default" angle it returns to to create the "S" shape in the deconstructed form)

Day 19: Whale

Another early one, and one of the first to really add a cool interaction. Emberley's book has an alternate whale blowing stylized dots, and by using simple x/y speed I was able to make a nice display.

The flexing of the whale was fun, but I had to "cheat" it somehow, because the squares and triangles that make up the whale at rest don't touch when it it is flexing. At first I had these cheat-y circles to fill the joint space that would hide in deconstructed form. Later I figured out to redo the math and have an extra triangle implicitly get draw on the side of "proper" structures. The end result wasn't perfect, but better than the circles.

Day 20: Monkey

Another one that didn't quite live up to my hopes. I couldn't quite get the flip to have a sense of weight and physics behind it, and again I was nearing the end of my time and gumption, so I just let it be. It's a pretty cute monkey though!