Sunday, September 27, 2015

For years, the most popular link on my site has been a simple jquery slot machine effect. At the encouragement of a fellow developer (Ron Sparks), I have parlayed that into a proper github project. Maintaining the simplicity was key; there's another similar project that has stolen my google juice thunder, but it's more complex than what I have, so I have worked to Keep It Simple, Silly, so a novice coder can more readily customize it to the effect they want.

Improvements include:

under 100 (well-commented) lines!

wrapped as an instance

being available on github

allowing images to be used

each reel can have its own options

you can call the "win()" function rather than "spin()" and it will show a pre-selected result

Sunday, September 20, 2015

A year or two ago I made a "cheat sheet" for the chords my band plays. I wanted something that would be easy to manipulate via my iPhone, when I need a quick peek. To put it mildly, I screwed up the UI- and especially what it took to add a new song. I liked the idea of having all the data in the body of the DOM, rather than storing it in, say, JSON and building the page, but I made a dog's breakfast of it...

The core function (which is still there) was alright... tapping the title of a song (an h3 tag) opened up the notes associated with it (in a pre tag). The thing was, I linked the h3 and the pre tag via an id naming convention... so for each song header I had to come up with a shortname id, and then pre section it was with had to have the same id followed by "_". Bleh!

My new approach is to wrap each h3/pre pair in a div. Duhhr- that's just being neat and clean. So the code for responding to a click on a header is:function clickTitle(){ var header = $(this); header.parent().find("pre").toggle();}

and I can ignore IDs entirely.

I also realized that, despite ordering the headers alphabetically, it wasn't super-easy to locate a song - like I woudn't know if "When the Saints Go Marching in" be under "When" or "Saints", or would "Just a Closer Walk with Thee" be under "Just" or "Closer" etc... and the mobile safari find function isn't particularly smooth to move in this case.

When it looked like my next big project was going to be in Angular I thought about rebuilding the app using Angular, and in particular the nice loop with filter... some kind of ngRepeat with

item in items | filter:searchText

would do it, except again it implies an external data rather than DOM-data driven design. (I assume there's some way of doing a more DOM-centric version in Angular, but I'm not adept to know what it looks like... maybe I'll ask my Angular-loving buddy/guru.)

Anyway, jQuery has a decent ".contains()" filter for its selector chains... except it's not case insensitive. But, the font of all wisdom StackOverflow had the solution for that:

jQuery.expr[':'].Contains = function(a,i,m){

return jQuery(a).text().toUpperCase().indexOf(m[3].toUpperCase())>=0;

};

Adds a "Contains" (vs "contains") that is case-insensitive. So combining that with a .on('input') on the input box and it worked pretty well. (And I really like the "verb" centric approach, of setting up an easy to understand event handler in jQuery, vs the "noun" centric approach of setting a loop and filter that automagically updates in Angular.)

Thursday, September 17, 2015

I have never been as much of a typography and kerning wonk as maybe I should be, but the new iOS 9 lowercase keyboard feels wrong to me. (A lot of people don't like the way the keycaps swap, but it may be a matter of people getting used to it.)

Red lines are geared at the uppercase boundaries, blue line for lowecase. In my Processing you can press the button to swap upper and lower.

The lines I tried to draw might not be perfect, but it still seemed to reinforce my intuition... in short, it feels like Apple used the centering relative to the uppercase, and sometimes that feels off. Maybe to reduce the jarring-ness of the transition when you toggle from one to the other? Characters such as "f" "t" and "y" feel especially off to me.

Wednesday, September 16, 2015

I'm looking for the best way for me to quickly become proficient in ember.js - with the additional caveat that I'd like to up-to-date. One of the reasons we picked ember over angular is that Angular seems to be in a weird 2-on-the-horizon state, but ember has some of that same issue (but the changes in syntax and best practices seem less radical.)

Currently a good bet (though I'm just starting with it) is https://www.ludu.co/course/ember/ - its approach of starting with a single, meat-y "real world" style example seems really promising for my learning style.

I liked this quote, about its use of HTMLBars (a descendent of Handlebars) for templating:

One of the advantages of using a real template engine instead of just adding "magic attributes" to your HTML elements (like in Angular) is that there's a clear distinction between the markup and the logic in your templates.

Man! That is kind of central for me, something that subconsciously really bugged me about angular.

A lot of it comes from my strength/weakness of my long history in web development... I subconsciously map modern in-browser coding (with a library like jQuery or in some framework) to what used to happen on the server, while HTML rendering has always been HTML rendering. Angular's slamming them together as one thing never felt right to me -- similarly, JSP's "everything is a tag" had a similar semantic confusion!

But some engineers love the consistency of "we can do everything in xhtml-compliant tags". I suspect that these are the people who think in nouns and capabilities, vs other folks like me who think in terms of verbs and interactions.

Speaking of my strength/weakness routed in history: one thing about the "Libraries vs Frameworks" debate. I've done many, many projects over the years, but the bulk of them haven small scale, quick hit things. In most ways these are more forgiving than larger scale projects that have to be worked on by many people over a long term. I've learned from experience that coding libraries (such as jQuery) can "scale up" to handle more complex projects, and if you're thoughtful about it it doesn't even have to get too messy. I'm not yet convinced of the reverse however. When Ember pulls down 25,000 files - literally - to get to a proper "Hello,World" environment, it seems like it will never be great for things simpler than its sweet spot of power CRUD-ish apps.

A final confession / point to work on: all these years and I haven't ever grown to love unit tests. I like integration tests and End to End and the like, but unit tests, meh... especially when written by the developer who wrote the code itself. (Like I wrote a year ago It's really hard to get someone to find something they don't want to find!) Here's a new variation on the the thought: it's generally not so difficult to write code to a spec. The hard part is getting that spec right for all those hidden and implied edge cases, and not realizing what assumptions you're making - in my experience, that's where bugs actually happen. But all units test do is test an implementation against the spec! They can demonstrate you're doing the thing right, but don't have much to say about whether you're doing the right thing...

Still, unit tests are an excellent way of talking to the future, telling them what the spec is, and permitting more freedom for fearless refactoring....

Monday, September 14, 2015

I've been really enjoying making my blog going though the games of COMPUTE!'s Gazette, a magazine of the 1980s for the Commodore 64 and related machines... it's so satisfying to know I can put in 30-60 minutes of work on a semi-daily basis and have something tangible and interesting to show for it. Almost addictive!

The game is Tic-Tac-Toe variant. Players gold or orange (or as my friend point out, pee or poo) alternate either placing a piece on the 5x5 grid or sliding any row or column one space (with the piece that would fall of the board wrapping around to the other side)

The trouble is, even by 1986 standards, the UI was bad. When a player's turn starts, pressing left or right on the stick selects either the square (representing place a new piece) or the arrows (representing get ready to slide a row or column) Pressing the button reverts control to that round cursor-y thing at top... the joystick moves it from square to square. In "place" mode you press the button to claim the square, in "slide" mode you press the button and then have to press the joystick again in the way you want that square to slide (bring its row or column with it).

So not only was it hard to understand (using color highlight rather than an underline or pointer or something was confusing by itself) but indicating the direction via a joystick press was unreliable, and the process was rather clunky, switch focus around and having to press the button quite a lot, considering.

Players can now either click a blank square or click an arrow to indicate their intent.

I doubt there anything here that couldn't be done in the Commodore 64 program - ditch the mode selector at bottom and decorate the sides with arrows, boom.

I actually made this in part to see if it actually was a good game at its core... the answer is no, not really. My playtesters complained it's a bit stupid because for the first part of the game, you probably don't want to slide at all, since you lose a chance to stake out territory. I've made this 4x4 variant incorporating their suggestion to make each turn be a placement AND a slide... this version hasn't really been playtested yet, but I'm confidant it's an improvement over the original, though I'm not sure if the whole game is redeemable.

Friday, September 11, 2015

Before I mentioned some handlebars 101 and specifically looping... it turns out that all your variables inside a handlebars loops are local to the item you're 'on' at that point in the iteration, but if you want you can access the parent context via "../", e.g.

Monday, September 7, 2015

In my blog going over old COMPUTE!'s Gazettes, I found a game I remembered, kind of an odd breakout variant, called "Whirlybird". I remember being fascinated by the construction of its main sprite, a kind of spinning bird statue thing with a neat 3D feel. And more specifically, I remembered finding out that if I loaded the game then quit it and loaded the sprite editor Sprite Magic, I could see the 11 frames that went into its rotation, one at a time:

I decided I would get in touch with my middle school self and make an Animated GIF of the thing. The challenge was, even when I set the Commodore emulator to not have any fake-y video artifacts, I couldn't get a pixel-perfect unaliased version of the sprite that I could just slam into ImageMagick.

The safest route seemed to be to make 11 Sprite Magic screenshots, read them one at a time into Processing, and pluck the screen center pixel for each square in the actual sprite editor. I had my screenshot reader generate a series of function calls that recreated each frame in something like ASCII art:doFrame("_________####___________"+"___________##___##______"+"_______#___##__####_____"+"_____#####_##_######____"+"____################____"+"___###___######___###___"+"___##_____####_____##___"+"__________####__________"+"___________##___________"+"___________##___________"+"__________####__________"+"");

(I also generated asetFrames(24,11);
line that the receiving program could use to know the width and height of each mini-ASCII masterpiece.)

At this point I was able to make a second, semi-reusable program to convert the series of frames into a GIF, using the excellent GifAnimation library that is just a few clicks away from Processing's builtin Library manager.

Here is the final result:

To a normal person this might not seem like a worthwhile use of a few hours, but perhaps my fellow nostalgic geeks will understand...

Wednesday, September 2, 2015

I mentioned my efforts to retool my old Processing/Java applet games and toys for the modern web. Previously I discussed patching the sound playing, but lately I took on what I think will be the toughest challenge: the few games that used physics.

Back then I used JM Couillard's pphys2d library. It had a lovely set of examples and friendly syntax. Unfortunately, Processing updates a few year back rendered it inoperable, even in Java mode.

For these games I've decided to use one of the many variants of "box2d". The learning curve is a bit steep! The best introduction I've found for it is The Nature of Code by Daniel Shiffman. The whole book is a delight. (His code is so elegant it makes everything look easy... highly recommended.)

He published versions of the source code using box2d-html and p5.js. For the physics games I'm going to recreate from scratch (more or less) in p5, rather than the other games where I aim for a version that works in both Processing java and .js modes -- I might come back and see if i can make some kind of patch for pphys2d calls once I get a more solid feel for box2d. (Shiffman is a bit misleading... it's all not that easy!)

Anyway, here is my Hello, World-ish program I'm linking here for my own reference. (Here's a tarball with all 5 files: beebox.tar.gz) It's almost 100% just the Chapter 5, Example 2 from Shiffman redone, except I tweaked the createWorld() helper to take an argument to disable gravity, moved some files around, and then add a bee/ball character that tries to chase the mouse a bit, but is hit by the box. Unlike the original, this may well clog up your system after running for a while, since boxes are less likely to fall into no-need-to-compute irrelevance. Also, I realized that this example skimps by not explicitly setting the bee's fixture's attributes (density, friction, restitution), so look at the "box" code for that.