With Forgecraft, and any game really, there are usually quite a few animations running concurrently. I found these moments to be choppy, unresponsive and frustrating when they were implemented in javascript (especially on lower CPU environments like the iPad) and needed another solution. CSS3 transitions were an obvious choice to check out, as they’ve been shown to be a great way to add a little pizzazz to a modern web app and can be executed natively (and even GPU accelerated).

But, can they provide the technical underpinnings for an interactive gamely element? To be effective in this context, they’d have to be:

• responsive, consistent and reliable
• noticeably smoother than their javascript counterparts
• simple to integrate with scripting

Regarding the first 2 points, CSS3 transitions’ effectiveness will really depend on your particular use-case. With Forgecraft they were definitely response, reliable, and smoother than javascript and I decided early on to use them in lieu of javascript wherever I could. But, I won’t go into the benchmarks and A/B comparisons in this article… perhaps later. Let’s just skip straight to the useful part:

Product Intergortion obscure 30 Rock reference →

Integrating CSS3 transitions with the game’s scripting is pretty straight forward:

• Define transitions in CSS on your master element
• Define classes with resulting properties changed
• Trigger a class change using javascript
• Listen for the transition-end event with javascript

Of course, there are a few pitfalls with each of these steps that I’ll go into here. Let’s take an example from Forgecraft: the Bonus Strike event. Randomly while forging the player will see a bar pop-up like this:

The bar moves from left-to-right and the player’s goal is to click the icon when the moving bar is directly under the target (large white) bar. The moving bar is animated with CSS3 transitions.

Defining the CSS:

We have a bar that needs an initial negative offset (the start position) that transitions to its final position. Simple enough: we define the base CSS on the #bar element and give it two classes (.new and .activated) defining each of its states. We also define the transition between the two states:

position: relative;

background-color: rgba(153, 153, 153, 0.3);
border-right: solid 5px white;

-moz-transition-property: left;
-webkit-transition-property: left;
-o-transition-property: left;
transition-property: left;
-moz-transition-duration: 1.5s;
-webkit-transition-duration: 1.5s;
-o-transition-duration: 1.5s;
transition-duration: 1.5s;

}

#bar.new {
left: 0px;
}

#bar.activated {
left: 600px;
}

One pitfall you may run into: for the animations to work in Firefox, you have to explicitly define the initial state for whatever property you are transitioning. In this example we are transitioning the left property of the #bar element. You normally wouldn’t define left: 0; — that’s the default! But Firefox requires this to trigger the transition when that property changes.

Triggering the Animation in Javascript

Using jQuery, we simply apply the classes that we defined in the CSS when we want to trigger the transition.

Listening for the transition-end event

CSS3 Transitions would be useless if we couldn’t get their context from within our scripting. Luckily, a series of events are fired in javascript while the transitions are running, just like you’d expect in a javascript-based animation. The primary event we care about is when the transition ends as you’ll most likely want to trigger callbacks.

Unfortunately, each browser vendor has decided to name these events differently… typical huh. Modernizr to the rescue! (If you’re not using Modernizr, you should be. But that’s another blog post altogether).

There’s a hidden gem in the comments in the source code of Modernizr that explains how to use its .prefixed() API to make a simple wrapper around the browser-specific transition event names. Here’s how I implemented it for the transition-end event. Feel free to use this wherever you need it:

var transEndEventNames = {
‘WebkitTransition’ : ‘webkitTransitionEnd’,
‘MozTransition’ : ‘transitionend’,
‘OTransition’ : ‘oTransitionEnd’,
‘msTransition’ : ‘msTransitionEnd’, // maybe?
‘transition’ : ‘transitionEnd’
},

CSS3_TRANSITION_END = transEndEventNames[ Modernizr.prefixed('transition') ];

Bam, now we can use one simple event binding to handle all browsers:

Stopping a Transition Early

When the player hits the hammer-and-anvil icon during the Bonus Strike event, I needed to stop the animation early. The easiest way I found to do this, was to just set the animating property to its current value. The transition delta becomes 0, so the animation stops:

Transition: End

You may find that integrating CSS3 Transitions into your game makes your interactions smoother and more responsive, and with a simple API for scripting against transition events, developing against them should look and feel a lot like working in pure javascript.

More Forging Forgecraft:

• Introducing Forgecraft
• A Hybrid SQL MongoDB Data Solution

One of my primary goals while building Forgecraft is to learn as many new technologies as possible. I’ve learned the hard way that it’s better to leave this kind of exploration in your hobby projects and out of your production “for real” stuff. And, seeing as how there are so many emergent technologies right now in web development there’s a lot to explore!

Whole Hog is Too Much Hog

MongoDB has quite a bit of steam behind it in the Rails/Ruby community (and plenty of other places too), and with projects like Mongoid and MongoMapper (I went with Mongoid) it’s an easy drop-in replacement for Active Record that maintains all those ORM conventions you know and love. I decided against the replacement approach for one primary reason: I wanted to use existing, robust, and actively developed libraries that rely on Active Record.

Example: There’s no reason to roll your own authentication/user system when there are insanely popular and feature-full libraries already in place for them like Devise and authlogic (I went with Devise).

Fortunately combining Active Record with Mongoid and getting the best of both worlds proved to be easy and painless.

The Set Up

The instructions for Mongoid include a step to remove the Active Record libraries from being loaded and delete your database.yml. Simply skip that step and both systems will run in conjunction.

One small operational change you’ll have to make during development is explicitly defining when your rails generators should use Active Record. If you want to make an AR-driven model, your generators will look like:

rails g active_record:model Player … produces a model the extends from ActiveRecord::Base.

And by default, the data generators will use Mongoid:

rails g model Skill … produces a model that includes Mongoid::Document.

The Implementation

Here’s how this combo system really shines in my opinion: get all the great features of gems built on AR with all the schema less features of Mongo. I’ll walk through an example:

In Forgecraft, the authenticating object is the Player and players have many Skills which, right now, are Accuracy, Craftsmanship, and Perception. But, the skill list will likely grow and change over time as the game evolves. A typical AR/SQL based approach would be to create a skills table and a join table between players and skills resulting in a complex multi-table query to get a player’s complete skills.

It’s clear here that the Player and Skills would fit well together as a single document in Mongo, queried all at once in one tidy object. But, since the Player is also our authentication model, using Mongo would prevent us from using Devise to handle all of that boring and complex auth stuff for us.

Enter Hybridization. Forgecraft’s implementation uses the typical Devise set up around the Player object (again all on top of AR). All of a player’s skills go into a single document with a reference to the player, like so:

class Skill
  include Mongoid::Document
  field :player_id, :type => Integer

  field :accuracy, :type => Integer, :default => 0
  field :craftsmanship, :type => Integer, :default => 0
  field :perception, :type => Integer, :default => 0

  index :player_id, :unique => true

  def player
    Player.find_by_id(player_id)
  end
end

To set up the relationships like one would expect with Active Record is a simple method on your Player object:

class Player < ActiveRecord::Base

  # ...

  def skills
    @skills ||= (Skill.where(:player_id => self.id).first || \
                 Skill.create(:player_id => self.id))
  end

end

Bam! Now we can retrieve our skills as a single document (fast), and add new skills with ease (easy). Since Mongo is schema less, you could even have a different set of skills per player. Again, all of this is achievable through SQL — it’s been done for decades — but it just makes more conceptual sense to treat these as a single document.

Querying and working with these objects and their relationships looks and feels just like active record:

player.skills
player.skills.accuracy
player.skills.update_attributes(:accuracy => 5)
player.skills.inc(:accuracy, 1)

Benefits Outweight the Consequences

I know, I know — any time you introduce an additional system, especially a datastore, you introduce a lot of complexity, failure modes, testing, etc. But, I honestly think the benefits are worth this extra complexity. Speed, ease of development, and the potential for less schema-driven growth make this an ideal environment for me. I highly recommend it, and will be using it in the future!

More Forging Forgecraft:

• Introducing Forgecraft
• Integrating CSS3 Transitions with Javascript

This is a slight modification of this configuration. Check out his explanation for all of the params.

The one I added that I think is essential is dateext, which appends dates instead of incrementing digits to the end of the log files, like so:


-rw-r--r-- 1 britg britg 64M 2011-10-24 06:49 production.log-20111024.gz
-rw-r--r-- 1 britg britg 62M 2011-10-25 06:52 production.log-20111025.gz
-rw-r--r-- 1 britg britg 56M 2011-10-26 06:29 production.log-20111026.gz
-rw-r--r-- 1 britg britg 56M 2011-10-27 06:51 production.log-20111027.gz
-rw-r--r-- 1 britg britg 57M 2011-10-28 06:51 production.log-20111028.gz


Which, in my opinion, is much more parseable by our puny human brains.

Note: this is a Rails 3.0 project with jammit and compass installed. The exclusion of the assets folder is probably not ideal in a Rails 3.1 project.

{
	"folders":
	[
		{
			"path": "/Users/britg/Projects/ponycorn-fanclub.com",
            "folder_exclude_patterns": ["*.sass-cache", "tmp", "log", "assets", "cache"]
		}
	]
}

Grab the updated version here.

The New Relic API is pretty straight forward with regards to listing Accounts and Applications, but I personally don’t have this use-case. So, please let me know if the current implementation is lacking any functionality for those of you that do!

Why keep a browser window dedicated to this? Fortunately, New Relic provides an API, so I whipped together a quick and dirty menu bars app to display the stuff I care about. Here’s what it looks like:

If you’d find this useful, feel free to download the app here.

Warning: The app is very simple. It prompts you for your New Relic API key and then loads your first Account and first Application. Perfect for my needs, but I’m open to suggestions. Do a lot of you have multiple accounts or applications? If so, I can add an account/application selector.

Update: I’ve added support for multiple accounts and applications. Get the new version here!

Feel free to contact me a brit at britg dot com with suggestions or feature requests!

From @ddollar’s description of Foreman:

Using foreman you can declare the various processes that are needed to run your application using a Procfile.

Besides the normal processes (rails, workers, etc.) I’ve found great success running log tailing and watchr through Foreman. Here’s what my current Procfile looks like:

(View original to see this Gist.)

If your development pattern is anything like mine, it looks like:

• Edit a test, model or controller: check watchr output

• Edit a view, js or scss file: refresh the browser

Here’s what that looks like through Foreman:

This works well with watchr and log tailing output, as they rarely overlap. Even if they do, finding the appropriate output is easy with Foreman’s prepending of the process name and timestamp.

Have any other tips/tricks with Foreman? Let me know!

Believe me, I understand his reluctancy because I felt it too. If you had asked me two months ago what I thought users think about these, I’d say they thought it was spammy, obtrusive, and just plain shady. But then I found myself implementing it in Key Ring in our latest update. Oh, how my feelings have changed.

The Vocal Minority

I’ve heard that review systems tend to expose the vocal minority, and I believe this. It doesn’t matter if it’s Amazon or iTunes, the vast majority of people who are satisfied, or heaven forbid happy, with a product will never take the time to write a review or leave a rating.

But, there’s a small and extremely motivated group of people that are willing, nay eager, to sling around 1-star reviews at the slightest hint of inconvenience. They have a forum, and by God they will use it. This affects the sleep patterns of app developers in ways I never fathomed until I became one.

The Lazy, Content Majority

The ratings solicitation is the app developers’ last bastion of defense against the Vocal Minority. Key Ring was a meh-inducing 3 stars for the first year of its existence, and our reviews were pretty evenly dispersed between 1 star and 5 stars. After implementing a very unobtrusive, one-time, opt-in ratings solicitation, magically Key Ring is now a sturdy 4.5 stars! The 5 star ratings are through the roof.

Oh how I wish I could attribute the dramatic change to the new UI, speed improvements, or something else I could brag about. Nope, if you look at the written reviews for Key Ring it becomes obvious that the users who are content with the app (who would never give a second thought to rating or reviewing it) are blurting a few words of praise and tapping that last star on the far right just because the app happened to remind them, in a moment of whimsical curiousity and boredom, that iTunes has this rating system and using it might be slightly less boring than whatever they are doing.

The surprising thing is, we have not once had a single complaint or mention about the ratings solicitation. Hell, we get notified by users when we mispell words in our Terms of Service!

The Bottom Line

There are people out there who are completely satisfied with whatever you’re producing, but you’ve probably never heard from them. In an ecosystem that values the coveted “rating” so very dearly, a tactful solicitation for a review is a great way to expose your fans and let potential users of your app know that it is worthwhile. Don’t be afraid to implement one, and don’t think less of apps that do.

WebGL

This is a new spec that’s being developed by the Khronos Group (the group behind OpenGL) to expose OpenGL to browsers through the canvas element.

Why is it exciting? Three words: Javascript. Hardware. Acceleration. Damn, I need three more: In. The. Browser.

The concepts should speak for themselves, but if you still need some convincing follow the steps below and be sure to take a look at your CPU usage while running these demos. (Hint: CPU usage will be very low because you’re riding your GPU).

• Grab the latest nighly of Chromium here if you are not already running it.
• Start Chromium via the command line:
  • Windows: chrome.exe --no-sandbox --enable-webgl
  • OSX: Chromium.app/Contents/MacOS/Chromium --no-sandbox --enable-webgl
  • Linux: ./chrome --no-sandbox --enable-webgl
• Follow this link to some examples of WebGL in action.

Again, check your CPU usage while running the demos. It should be very low (if you have a GPU) as the demos should be hardware accelerated.

Web Sockets

Comet? Long-Polling? Forever Frame? In two years we will all be sitting around a trash barrel fire laughing about the days of yore when we had to use such hacks.

Why are we huddled around a trash barrel fire? Because it’s post-apocolyptic New Zealand, the last bastion of humanity. Anyways, that’s another “In This Decade” blog post…

From websockets.org:

[The Web Socket Interface] defines a full-duplex communications channel that operates over a single socket and is exposed via a JavaScript interface in compliant browsers

Here’s the spec in case you want to read it… haha, me neither.

Again, the concept here should speak for itself. Two-way communication with web servers in an easy-to-use interface.

var websock = new WebSocket("ws://www.websocket.org");

websock.onopen = function(evt) {
  console.log(evt)
  websock.send("Hello Web Socket!");
};
websock.onmessage = function(evt) {
  console.log(evt)
};
websock.onclose = function(evt) {
  console.log(evt)
};
websock.close();

Fortunately, there are already many projects implementing the web sockets protocol. To name a few,

• node.websocket.js
• em-websocket (Ruby)
• pywebsocket

One thing to note is that the web socket protocol will adhere to the cross-domain security restriction that XHR has. The good news is it will ship with support for server-side origin discretion using the same Origin headers in CORS.

It’s all about the gaming, stupid

I’m going to predict that in 2 years, we will see current A quality games developed in-browser ontop of these two technologies. Don’t get me wrong, AAA quality console and PC titles won’t be disrupted like the music and print industries any time soon. But, the “casual” label on browser games will go away.

This is what has me really excited about being a web developer in this decade. Parity with desktop development is inching closer, and all ontop of open technologies.

No plugins. No corporate owner.

Win. Win.

Enabling your server app is as simple as including a few extra headers when you detect a cross origin request. How do you know it’s a cross origin request? You’ll see the Origin: header — all CORS requests will have it. From there, response headers depend on the specifics of the request, but I won’t go over those here — check out the Mozilla Developer Center treatment for in-depth information.

I’ve been working with Sinatra a lot lately, so I put together an extension for Sinatra that makes enabling Cross Origin requests even easier.

sudo gem install sinatra-cross_origin

There are two ways to use the extension: globally or per-route.

Global

For when you want to share all your endpoints cross-domain.

require 'sinatra/base'
require 'sinatra/cross_origin'

class MyApp < Sinatra::Base
  register Sinatra::CrossOrigin

  enable cross_origin

  get '/' do
    "This is available to cross domain javascript requests automatically"
  end
end

Per Route

For when you want to share only some of your routes cross-domain.

require 'sinatra/base'
require 'sinatra/cross_origin'

class MyApp < Sinatra::Base
  register Sinatra::CrossOrigin

  get '/' do
    cross_origin
    "This is available to cross domain javascript requests"
  end
end

Configuration

You can mix and match app-wide config and request specific config.

require 'sinatra/base'
require 'sinatra/cross_origin'

class MyApp < Sinatra::Base
  register Sinatra::CrossOrigin

  configure do
    # Comma separate list of remote hosts that are allowed.
    # :any will allow any host
    set :allow_origin, :any

    # HTTP methods allowed
    set :allow_methods, [:get, :post]

    # Allow cookies to be sent with the requests
    set :allow_credentials, true
  end

  get '/' do
    # Only available to GET requests originating from
    # http://example.com.  No cookies allowed.
    cross_origin :allow_origin => 'http://example.com',
      :allow_methods => [:get],
      :allow_credentials => false
    "This is available to cross domain javascripts"
  end
end

Grab the source at Github: britg/sinatra-cross_origin.