Latest Posts from csaunders


Breakable Toys

eugor
I've been having a hard time keeping focus recently when it came to my side projects. My Android project has somewhat lost steam. After building some of it out I had simply lost interest. Perhaps in a few weeks I'll be interested in it again, but I want to keep learning instead of waiting for that motivation to come back.

After my attempt at a typing based rogue-like I decided that it's time to come back and try building one again. My focus this time is to not try anything crazy and to make a game that's playable. There are so many components to a rogue-like that I never got to experiment with or never really got to understood while working on the game I built during the Toronto Global Game Jam.

I've chosen to use the Go programming language to implement this game. My main reason is that during hack days a few months ago I was implementing a theme synchronization tool but never got a full opportunity to learn the language to it's fullest. As a result I was extremely jaded and frustrated with the language. Now that I'm in a less stressful situation now so I have time to experiment and try things. I can build something, see how it works and throw it out if I want.

I've been following the 15 steps to building a rogue-like and am around step 4 or so. Either I'm completely off, or the first steps were super straightforward given the terminal UI library I chose.

So far the map is a pretty interesting part. I've gone with a few restrictions, such as a room is only allowed to have 4 doors; one for each direction. I also took a somewhat naive approach in that my maps are represented as Trees. The nice thing about using a Tree to represent my map is I can just traverse all my nodes and render those as well. The problem though is most dungeons aren't tree-like, or at least interesting ones aren't. So moving over to a graph should be interesting, I'll just need to figure out a way to pull this off that will prevent me from getting stuck in loops. I know git is implemented as a directed acyclic graph, so maybe I can steal some ideas from there.

Next up is to actually move my character into the map and prevent them from walking over walls and all that fancy stuff.


The Library is my Coffee Shop

Library

I recall the first time I ever really used the library for anything significant. During my 3rd year of university I needed to escape the computer science side of campus so I could sit down and focus on my assignments distraction free. For a while it worked, but I was also involved in student politics so I knew people all over. Even the other end of campus wasn't distraction free. I needed to get somewhere I could camp out with my head down and get some work done. It was around then that I figured it was time to step into the library. They're supposed to be quiet and intended for study, so I gave it a shot. That was where I discovered the study desks reserved for graduate students on the top floors. I had finally found my Oasis!

Fast forward a few years and I was working for real from coffee shops and co-working spaces. These were good spots to work from but they are loaded with distractions; something I don't cope with very well. With a coffee shop people are constantly entering or leaving, people are having conversations, the internet expires every hour or is of disturbing quality, the list goes on. Co-working spaces sometimes suffer from the same problem plus you now have technically minded people talking about stuff too!

So here I am hiding in a public library in my study desk blocking out as many distractions as possible while hacking on some code. It's liberating to be able to stare forward and not accidentally make eye contact with a stranger or get distracted by someones erratic hand motions in my periphery. As an added bonus I don't need to worry about being kicked out since it's a public space for anyone to use for however long they want.

Perhaps next time you're looking for a place outside of the office or home to work, head over to your local public library and give it a try.


Playing around with the Philips Hue SDK for Android

Rainbows
After having seen a friend's Hue installation I decided that I'd be interested in some of these little devices myself. The idea of being able to schedule when my lights turn on or perhaps get even more advanced with my configuration would be definitely interesting.

The developers at Philips have taken an awesome approach and published the API for these lights, which means we have the opportunity to do whatever we want with these lights. Aside from just publishing how the API works they also have an iOS and Android SDK.

Eager to work on an Android app again I grabbed all the relevant pieces and started working on new project. If you are a native to Android development you might find the SDK a little bit weird to work with! The SDK in question has definitely been a direct port from the iOS SDK, which makes some things look a little weird. The API is also very callback heavy, which can make learning it at first a little bit weird.

public class BridgeSearcher implements PHSDKListener {
    private PHHueSDK sdk;
    public BridgeSearcher() {
        sdk = PHHueSDK.create();
        sdk.setDeviceName("Bridge Searcher");
        sdk.getNotificationManager()
            .registerSDKListener(this);
        PHBridgeSearchManager manager =
            (PHBridgeSearchManager)
            sdk.getSDKService(PHHueSDK.SEARCH_BRIDGE);
        // Perform uPnP search
        manager.search(true, true);
    }
}

Now I haven't shown the callbacks yet, but this is what you need to do in order to detect all the bridges in your area. In a home you'll probably only ever have one, so you can safely assume that when you successfully detect the bridge you can grab the first (and only) element from the List.

// Still in BridgeSearcher.java -- One of the Callbacks
@Override
public void onAccessPointsFound(List<PHAccessPoint> accessPoints) {
    if(accessPoints == null || accessPoints.size() == 0){
        // Android Logging
        Log.d(
            "BridgeSearcher",
            "For whatever reason we found APs but got null or an empty collection!"
        );
        return;
    }
    PHAccessPoint ap = accessPoints.get(0);
    // Now that we have an access point lets 
    // connect to the bridge!
    ap.setUsername("BridgeSearcher");
    sdk.connect(ap);
}

So we've grabbed our detected access point and set the username. The username is required since that's how authentication works on Hue. It's not really strong or anything, so it's easy to masquerade as other apps. Though this really isn't an issue since there is a step that requires direct user input. Sending that connect attempt will actually fail because my user isn't configured yet. We will find out about that because we'll get a bunch of error callbacks as well as an authentication required callback. Note: Your username needs to be sufficiently long otherwise the Hue SDK will raise an Exception

// Still in BridgeSearcher.java -- Another callback
@Override
public void onAuthenticationRequired(PHAccessPoint ap) {
    sdk.startPushLinkAuthentication(ap);
}

With this you are now waiting for the Hue button on the bridge to be pressed. Once that button is pressed you will have a user account and can change the colours of your lamps and do a bunch of other things too.

// Again still in BridgeSearcher.java -- Final callback of this article!
@Override
public void onBridgeConnected(final PHBridge bridge) {
    // You don't need all the details in order
    // to actually modify a light. Just it's ID.
    // From my observations light IDs start at 1
    final PHLight light = new PHLight("", "1", "", "");
    Thread thread = new Thread(new Runnable(){
        boolean on = true;
        PHLightState state = new PHLightState();
        // Setting to 255 causes an exception to raise :(
        state.setBrightness(254);
        state.setHue(46920); // Make light blue
        state.setOn(true);
        bridge.updateLightState(light, state);
    });    
}

And there you have it, you've found a bridge, gone through the authorization flow and updated one of the lamps. It's a little bit weird, but one of the nice things about this is it's all asynchronous so your code doesn't need to worry about every blocking on the main thread and getting the ANR of death. Though don't forget that these all occur in a separate thread, so be sure to run any UI updating code on the main thread!


Shop Product Sink: Simplify your Shopify Product Synchronization

Down the Drain

A little while ago I mentioned that I was working on a rails engine to simplify keeping products in sync with Shopify. I'll admit that the post was pretty sparse with details and I should really clarify what I meant. Currently the tools available to work with Shopify are somewhat few and far between and mainly cover the most basic requirements. There are many aspects of the product if you want to do anything substantial still require a bunch of boilerplate code.

Gotta Fetch 'em All

A major aspect of many applications is keeping products in sync with what is available on Shopify. Let's say you are building something that catches order creation webhooks. Let's also assume that you don't want to deal with the implementation of synchronization and you'll just pull in the product details as you need it from the API.

# webhooks_controller.rb
def create
  order = ShopifyAPI::Order.new(webhook_data)
  products = order.line_items.map do |line|
    ShopifyAPI::Product.find(line.product_id)
  end
  process_order_with_products(order, products)
end

With the newly released leaky bucket API you are at a higher risk of running out of API calls far more frequently. The refresh rate is about 2 requests every second and let's say your "best customer" has orders with an average cart size of 2 products coming in every second. You shouldn't really have to worry about anything because you'll rarely get close to the limit of 40 requests.

Now let's just say that your average cart size were to increase by 1 on average. Now, after processing each request you are 1 request in deficit. After about 40 seconds of constant orders you'll have burnt through your API requests. Now you have an extremely frustrating edge case because now your application doesn't work when you need it to. Either you'll have to handle for this or add a caching layer for products.

Cache, Cache, Cache, Cache, Cache, Cache. Everbody!

While handling the edge cases might seem like a solution, it's a hack and doesn't really result in easy to understand code. Handling an edge case means adding a layer of indirection that makes your code murky. Using a caching layer allows you to cleanly abstract that part out and keeps things simple, primarily because you shouldn't experience those edge cases as frequently.

# webhooks_controller.rb
def create
  order = ShopifyAPI::Order.new(order_params)
  products = order.line_items.map do |line|
    ProductCache.find(line.product_id)
  end
end

# product_cache.rb
def find(id)
  if product = fetch(id)
    return product
  else
    # Note: This is a blocking operation
    remote = ShopifyAPI::Product.find(id)
    store(remote)
  end
end

def fetch(id)
  # CachedProduct is an ActiveRecord
  CachedProduct.find(id)
end

def store(api_product)
  CachedProduct.create(api_product.attributes)
end

Now this isn't even the best approach here. This will cover the majority of the popular products which is pretty decent but you still run the risk of having some kind of sale go on where you get hammered by a bunch of different orders for different products. Another thing to keep in mind is this implementation does run the risk of going stale. This requires either running jobs to fetch the products and update them or to drain your cache and rebuild it again.

Call me when something interesting happens. Here's my number

So instead of trying to handle the fetching of products during the request which runs the risk of timing out let's move this around a bit. We really want that cache because it keeps things simple for us but we also want it to use as few requests as possible and keep it as fresh as possible. You might have noticed that I mentioned we were handling order webhooks; and well awesomely we can also handle product webhooks too!

There is one thing that sucks about this though, now you are responsible for building out an entire infrastructure to handle those products and the events related to them. We all have more important things to do and this is where a tool I've been working on, shopProductSink comes in. This is a Rails Engine (sorry Sinatrans) that you can easily glue into your rails app to get full product synchronization working. I'll apologize that there is a bit of configuration involved, but I couldn't think of a better way around it :(

Configuration!?!?!

Yes, indeed there is a bit of work that needs to be done before the engine can work it's magic. The engine doesn't have any way of knowing where your application is hosted, so you'll need to setup your default_url_options otherwise when registering webhooks we'll fail since we don't know what host to report. Say you were to only set this in config/production.rb then it would look something like this:

# Somewhere in config/production.rb
app_routes = Rails.application.routes
app_routes.default_url_options[:host] = 'your.domain.tld'

Until further notice another thing you need to ensure is that your application secret is set in the environment for user that will be running your app in production. This is required in order for the webhooks controller to validate any incoming requests. Let's say you were deploying then all you'd need to do is the following:

heroku config:add SHOPIFY_API_SECRET=abracadabra

Jacked up and Good to go

After you are all configured and you're running all you need to do is fire a few commands and you'll have an active product cache as well as have your application setup for receiving webhooks for your shop.

def post_shop_install
  installation_params = {
    shop: newly_installed_shop,
    token: newly_installed_token
  }
  import_products(installation_params)
  setup_webhooks(installation_params)

Let's look at our import_products method in detail and explain what's going on here.

def import_products(options)
  importer = ShopProductsSink::Importers::Product.new(options)
  importer.import
end

Here what we are doing is grabbing the Product import engine that is available in the shopProductSink engine and getting it to import the shops products (provided in the options/installation_params). Keep in mind this depending on the shop this can be a long-running task. So it's probably in your best interest to run this in the background using a tool such as delayed_job or resque.

Now let's look into our setup_webhooks method!

def setup_webhooks(options)
  ShopProductSink::WebhookRegistration.register(
    installation_params
  )
end

I took a slightly different approach to how this works and you can see it in action on github. The tool tells Shopify that it wants to be informed about product creation, deletion and updates in order to keep the local cache in sync. Now after a user of your application modifies anything to do with products you'll receive a message from Shopify about it. The engine comes with a default controller that will be used that will take care of validating all incoming webhooks.

Caveats

The importer is rather aggressive and doesn't handle the edge cases quite yet, though I am hoping it's slow enough and grabbing large enough pages for this to not be an issue. The default is 250 products per page which should be sufficient, but you never know, there's some shops out there with crazy numbers of products in them.

There are a few cleanup tasks I need to do for the engine, but it's ready for general usage by the public and I look forward to your feedback!

Some of you might have noticed that I didn't mention sidekiq as a background worker. This was primarily because the Shopify API gem wasn't thread-safe, though there has been some work done to use a fork of ActiveResource that makes the gem thread-safe which you should be able to sub in.

Special Thanks

I'd like to thank Stephan Hagemann for helping review this article.


An Approach to Token Based Key Distribution for Mobile Clients

Do not duplicate

Back during Rails Rumble 2013 the team I was on was building an application for use by peoples phones. We were deliberating on how we could easily get the application data from the server to the phone without having to resort to poor solutions like username/password combinations or some convoluted OAuth flow that requires embedding application secrets in the binary.

Token-based authentication is an approach I've heard of before and is used in popular applications such as Campfire. The one problem though is the key distribution isn't the nicest thing in the world. With Campfire the user is required to find their token, copy it then paste it in the correct location of their API consumer in order to interface with the product. While this might work alright for a desktop client, once you venture into mobile data entry can sometimes be a little tedious.

Our assumption for the application was that a user would be using the app from their desktop first. This would mean all their session data isn't available on their mobile device so in order to go somewhere to get the data they need would require logging in via their phones web browser and going through the same steps as described previously.

I wanted an easy way to get the information to our mobile clients that required very little in terms of technology. Our approach was to provide a link embedded in a QR Code that could be scanned by your phones barcode scanning application. Once you've scanned the code you now know where to go in order to grab the token that you need in order to get API access.

This Message will Self-Destruct in 5 Seconds

inspector gadget and stuff

There were a few things that needed to be taken care of when creating these URLs. Firstly, we couldn't lock the endpoints behind sessions since that would make it impossible to fetch the key. Secondly, it needed to be very hard for anyone to arbitrarily guess what the URL to get access to a token would be. Finally, we needed to be able to prevent "replay attacks" to the resource that contains the API token information.

In order to prevent people from guessing what the URL would be to get a token, we simply used UUIDs as the resource location. We had an object that held a reference to a token and would provide the token details when requested via JSON. This meant that whenever we needed to provide access to a token we could just create one off objects and link off to it's UUID identifier. Another added benefit is that if we wanted to we could regenerate another object that would reference the same token.

When it came to replay attacks, the main concern here was having someone watching traffic as it went by and clueing in that an endpoint is how keys were distributed. So what could possibly happen is I request my token, while this evil third party (let's call him Carçon) who is watching my requests also makes a request to get the same token. If we aren't careful we could accidentally give the API token to Carçon as well! The way we took care of this was by making it such that by looking at the token you destroy the external reference to it. In this case it would mean that when the attacker makes the request, instead of getting an API token they'd get a 404 instead since the object providing access was destroyed at the end of the initial request!

While I'm certain there are still some problems that might exist with this approach it felt like a novel way of solving the problem of key distribution. It also made much simpler for the developer writing our Android app since there they didn't need to store user credentials or do the OAuth dance.


Thoughts and Experiences from my first Global Game Jam

SpellSword

From January 24 – 26 was the Global Game Jam and I was determined to actually work on a game for once. After having missed my opportunity for Ludum Dare in December this had to happen. While there were a few last minute changes and I ended up working solo I was still going to build something. I decided to grab a few tools, some of which I already knew, others that I didn't, and roll with them. I had 48 hours to get something done and messing around with environments or learning something crazy new like Unity would've been a waste of time.

Knowing that I was by myself I made a few decisions about what I'd need to do. The big thing was I didn't have time for assets so I jumped onto Open Game Art and started looking for retro/8-bit style art that would match my roguelike dungeon crawler. This site ended up becoming the go-to for everything I needed.

There were a few issues with the assets though that needed some minor tweaking on my side. 8-bit and 16-bit style pixel art is somewhat popular, though one problem is often the images are extremely tiny. I fired up my image editor of choice and started making things a bit more realistic in size. There's various kinds of scaling algorithms but the one that works best for pixel style art is most definitely nearest neighbour. Other forms of scaling would leave the sprites looking alright but a tiny bit fuzzy which was definitely less than ideal.

Tiled Map Editor

With my re-sized sprite-sheet and sprites themselves I was ready to start building out my dungeons. This is where my game wasn't truly a roguelike since I wasn't procedurally creating rooms, but building them in this wonderful tool called Tiled. The purpose of a tool such as Tiled is to make it easier to build out maps that your games can use while also helping keep size down. Let's say you were to use a png to represent a very large level. There is a good chance the image would be very large and might even cause your performance to drop because of it. Tile maps on the other hand provide a bunch of meta-data about how your level looks and then you're able to only render what you need. Parts of this will include that sprite-sheet or map-sheet which your software will use in order to know what images to render on the screen. Another added benefit of at least Tiled is I was able to add objects which can be used for whatever. In my case I used them to represent the binding boxes of my rooms, where the player would start and where the exit of the dungeon was.

I'd experimented with Löve2D in the past and had learned enough Lua to at least be able to build something. I was still jumping into the Lua documentation to answer questions, but at least I was able to effectively put my ideas into code. Much of the game was built with a lot of write and run debugging, which worked for most things but started to get a little annoying. I'd run into the typical scripting language problems like "variable not defined" or "you used . instead of : on your function call" which was wearing me down a bit near the middle of day two. I normally build systems and pretty much always drive my design by unit tests. I was starting to work on my map bounds part and I knew that skimping out on testing because I'm making a game was going to cost more than finding a test framework, setting it up and using that. It didn't take too long before I found a tool that made the Rubyist in me pretty happy. There's a Löve2D testing framework called lovetest that gave me a really easy way to setup a test suite and run it. There was a simple naming convention to follow then everything else was like running Unit Tests in something like Ruby or Java. I was able to get immediate feedback and iterate on the errors much more quickly than I would've otherwise.

Another big tool I used during the jam was sleep. I knew going into it that I couldn't afford to run myself into the ground since I had a full time job to get back to on Monday. Getting sick because I pushed my body too far wasn't something I wanted, and besides I had a skiing trip the week after! While I didn't participate the full 48 or so hours, I think I ended up putting in about 27 or so. I noticed that there'd be a point during the day where things just weren't making sense anymore and I was making way too many mistakes. Sleep helped solve so many problems, it cleared my mind and kept me refreshed. I was also able to focus really well with very few distractions. I kinda feel that while I only spent about 26 hours or so building the game, they were all spent on building and not anything else like perusing Twitter or Reddit.

While my game worked I wouldn't say I finished it. Killing monsters doesn't quite work right, there's some collision detection issues, you can't die or beat a level. It does give me targets to keep working on and I was really in for building stuff and learning new things. For that I'd say it was a great success and I'm looking to participating in more to come!


SpellSword on Global Game Jam submissions site


Testing request-based modules and understanding Rails/Rack header munging

bike rack

I'm working on a tool to help make it easier to keep a local cache of product data from Shopify and one part of that means keeping up to date with changes. Thankfully the API provides an easy way to subscribe to webhooks which is quite useful. Though, I'm looking into the problem and know that just building another webhook controller would really only help me in the short term. It'll help me build out another part of the project but it won't really be usable outside of the project.

One big part of this project is I want to be able to tell someone "yeah, take this and add it to your project" with confidence. I don't really feel confident letting anyone use my code unless I've tested it at least a enough that I know the important parts work the way they should. When working with models and such it's pretty simple, though when you start working with requests things get a bit more complicated. The last thing we want our test suite to do is make external calls, they're slow and slow tests make us reluctant to run them.

Using the documentation I started building out some really simple tests to ensure that when a request comes in with the X-Shopify-Hmac-SHA256 header and I want to verify that I'm reading that in and calculating the HMAC correctly. I looked around for some examples of mocking request objects and only found some stuff talking about using tools like mocha or rspec to mock out methods that are called. I've been burned too many times by being stupid and not understanding APIs fully so I figured it would be better to use something. The most obvious is just work with the Rails request object since that's what I'm going to be using anyway. It's Rails, so as far as I'm concerned it's stable; not Standard library stable, but still pretty darn stable.

After giving the initializer a quick glance over and realizing I needed to work with a Rack env I dug a bit deeper into figuring out how to easily create the environment. This brought me to Rack::MockRequest which gave me exactly what I needed in order to build up that request environment.

With my test setup everything should be peachy and I'll be able to pull out that header and have me some passing tests.

class MyTest < ActiveSupport::TestCase
    test "authenticating a request" do
      controller('abracadabra')
      hmac = "u8aZR7htZKE6uWRg6M7+hTZJXZpcRmh5P4syND1EM24="
      controller.request = request('a message from shopify', hmac)
      assert controller.valid_webhook?
    end

    def request(data, hmac=nil)
      options = {
        :method => 'POST',
        :input => data,
        'X-Shopify-Hmac-SHA256' => hmac
      }
      ActionDispatch::Request.new(Rack::MockRequest.env_for("", options))
    end
end

I'd fire up my test and… it failed. I was getting a little frustrated and confused since this should work right? After a bit of digging around I got into ActionDispatch::Header#env_name which was doing some kinda weird stuff. Whenever you are dealing with a header that isn't your "normal" header (Content Type, Accept, etc.) it get's munged a bit. I'm not fully sure where, I think Rack might be involved in this mystery somewhere but I'm probably wrong. Anyway, let's say that along with your request to a Rails app you include the header Needs-More-Taters, well it'll go through your middlewares and all that business and by the time you actually end up looking at it from your controller it's now HTTP_NEEDS_MORE_TATERS!

What does this mean for my tests? Well my module isn't actually going through the whole dance for controller tests, my environment isn't getting setup correctly. Instead what I need to do is pass in the environment in the "proper" state. In my case it means in my options hash I needed to pass in the fully qualified names that Rails would expect to be there.

def request(data, hmac=nil)
      options = {
        :method => 'POST',
        :input => data,
-        'X-Shopify-Hmac-SHA256' => hmac
+        'HTTP_X_SHOPIFY_HMAC_SHA256' => hmac
      }

With this now discovered all my tests are passing! There was a bit of a yak shave involved (I'm notoriously good at falling into them), but it's cool because there was also a chance to learn a bit more about the innards of Rails and how I can just use plain Rack for testing.


Reducing the suck with Rails Engines

train engine

Mid last year I worked on adding a feature to the forum software at Shopify because I wanted to have a bit of context before clicking on a link in my emails. Since adding that feature I feel like I've become far more active on our developer forums and have helped answer a number of questions. It's also given me a lot of insight into the kinds of things that make software sucks.

One thing I'd often see are people asking about getting products along with order information. The problem is if an order would come in with 4 line items, they'd need to make another 4 API calls before they could do anything since the line items only contain product IDs. This is pretty shitty, and my response would typically end up being "you'll need to cache that locally and keep it up to date". Then I started thinking about the problem a bit more and realized that I'd be pretty pissed off if someone told me that.

On top of solving the business problem, I now need to do some boring bullshit in order to save on some API calls. Of course, if I want to passively keep the data up to date I need to add Webhook support and now this minor detail has exploded in scope if I want to be able to scale this at all.

Looking into it a bit more I realized that this is a problem that only needs to be solved once (per language/framework). Being a Rails developer and hearing so much about these engines that are all the rage I figured this is the perfect use case for them. The goal is to give Rails developers a drop in module that makes it super easy to get product detail caching working in your projects with little to no effort.

Currently the engine is in a state that with a little bit of code you can get a bunch of products imported into your application. For example, I have a controller with an import action that does the following:

def import
  api_products = ShopifyAPI::Product.find(:all)
  ShopProductSink::Product.create_from_resources(api_products)
  redirect_to root_path
end

And here is accessing that route in action:

Invoking /import for a logged in user

So there's a bit of work still on the developers side that requires a bit of insight and the API is still a little bit in flux. I'm currently not planning on doing any magic (I'm not smart enough for that yet), though I figure once I get it out there and get feedback I'll be able to make it even better.

If you're interested you can keep track of the project on github


Should we use JavaScript as a teaching language?

A few days ago Ashe Dryden mentioned she was looking into JavaScript as a possible language for teaching. Some argue that it’s a terrible language to start people off with. This got me thinking about the language a bit and whether or not it’s truly terrible.

I started learning programming with Java which is a pretty obtuse language. Even the most basic “Hello World” is about 15 lines long. There’s the whole public static void main(String[] args) which when you are beginning programming makes no sense. This is where scripting languages really win, you write stuff and you get results right away.

One thing I think we need to realize though is that building basic command line applications isn’t the most interesting. “Oh cool I made a computer say ‘Hello Chris’” but there are better things we can do to teach. For one, seeing something visual instead of a bunch of characters in a prompt is a good start.

This is where a language like JavaScript starts to make sense. When bundled with a browser, it comes with a complete widgeting library that learners can use to build some interactive applications. Using plain HTML and CSS they could build a text adventure game, though by adding JavaScript to the mix it can become far more interesting.

Creating games is a good way for people to learn. For one, it’s interactive which makes people more inclined to play with it which may even uncover bugs, pushing them to fix it and make their games better. If you were to give a group of students a basic introduction to JavaScript, variables and functions you could probably have students rolling out a Knots and Crosses game by the end of the day.

There are a number of positives that come with using JavaScript as a teaching language, the big one being that the student doesn’t really need to install any runtime. As long as they have a modern browser they should be good to go. Chrome, Safari and Firefox all come with excellent DOM inspection and debugging tools as well as a JavaScript REPL. I’ve been to a few classes where I was a Coach/Teaching Assistant, and getting an environment set up can be a massive time sink and it can be really discouraging for people just looking to learn. The language also comes with a lot of functionality that makes teaching advanced computer science constructs (such as closures) very simple.

It’s easy to dismiss the language because of the way it’s been built. Variable hoisting is kinda weird, the fact that if you aren’t careful in the way you create your closures can result in the same variable being “assigned” everywhere and double-equal comparison are a few. Though, as teachers we can help steer our students away from the gross bits of the language and if they encounter them try explaining them. If their eyes start to glaze over simply tell them that it’s the language being weird and show them how to get around it.

Sometimes starting off with a “shitty” language can be the way to go. In the end, if they become interesting in programming they can keep rolling with JavaScript or maybe they’ll be tempted to try out something else. Learning to program should be the goal and helping students do it as quickly as possible is the best way to get them there.


Learning to Love2D

4XpHX

I decided to spend the evening learning another game making framework. I’m still quite happy with Game Maker though getting to see how Lua works in a fun and interesting way sounded pretty neat. Initially I was going to try making some kind of Scorched Earth clone but got all hung up on procedurally building height maps, so I took it down to something super simple; Pong.

I saw that Love2D is integrated with Box2D so I figured I could probably leverage that to make a pong game. It would take care of all the deflections for me, so I’d really just need to switch things around based on some collision information. So really, all thats happening when you hit a paddle is the gravity reverses. While it’s nothing super exciting, it does add something kinda cool to the game. Depending on how you angle your shot you can either make a really hard to hit bouncy one or might even slow it down.

I also noticed that theres a bug which *may* cause the ball to even keep it’s gravity and just come back towards you. Feel free to give it a shot, though make sure you download Love2D and with that installed you can even start making your own love games too!

Download Pong

Controls