Joachim Enger

My brother is a photographer and I’m constantly pushing that he needs to have some sort of portfolio or something on the web, to promote his work and his awesome self. To that end he lets me go wild with creating a website for him and I’ve used his portfolio page to test various CMS systems and design ideas, some more useful than others (I’m looking at you concrete5).

The latest iteration runs on my Sections framework (gotta eat that dog food) and is based on the Foundation framework, which I have fallen absolutely in love with. The greatest part of the framework is how it adapts to the size of the screen and means that the website will work on mobile devices without me having to do anything.

Well almost, because having a layout which responds to the size of the screen means that you need to take into consideration where you apply padding, borders and margin so that when the content is shifted around it doesn’t break the style or you see the dreaded horizontal scrollbar. Mobile browsers have thrown a wrench into web design conventions, but with a responsive style framework and some forward thinking we may come up on top.

What the gallery looks like

Another thing I had to deal with was that everything was going to come from my brother’s flickr account, so that he can take pictures and put them up there without having to worry about his dumb stupid website that his geeky brother had thrown together for him. Also, instead of insisting on him only uploading images of a certain size, I just built a simple GD-based resizing script that would take any new images, resize them to the right formats and then save them in folders on the server. Now I had a steady stream of pictures that fit perfectly into the design I had built. Thank science for modern web development libraries!

I’m pretty happy with the result and my brother doesn’t have to do anything outside the usual to keep his website up-to-date.

Internet Explorer has a PR problem

I was perusing Hacker News when I came across not one, but two beautiful websites heralding the new generation of web content with a peculiar and somewhat surprising backer. Microsoft, or more specifically, the Internet Explorer team has decided to promote modern web standards by funding two projects, a browser-based version of the iOS/Android game Cut the Rope and a extension to CSS which supports OpenType typography features.

Made by designers for designers.

My initial response to the discovery that IE was behind these two projects was disbelief, followed by doubt, and then more disbelief. I grew into a web developer in the midst of a chaotic time for web browsers, where majority control over the masses of web-surfers was wrestled away from Internet Explorer 6 over the course of 6~7 harrowing years. I’ve spent countless hours tweaking and downgrading my designs, hacking at a wall of bugs and generally tearing my hair out to get things to work with IE6 and now Microsoft is trying to promote HTML5/CSS3 features as if they were never standing in their way to begin with.

I am aware that we have come a long way since IE6, but Internet Explorer’s story isn’t exactly the greatest example of forward motion in the history of application development. IE7 was released in 2006, five years after IE6, and at the time felt like a direct response to the introduction of Firefox, which came out of nowhere and exploded in popularity with its countless extensions and tabbed browsing. Since then, every new version of Internet Explorer has been promised as the “one they get right” in terms of following defined web standards and exploring new undiscovered territory, but it has come short every single time. IE is the best example I have seen of the narrow-mindedness of enterprise-focused software:

• Littered with proprietary features
• Focused on innovation-stifling backwards compatibility
• Long and obscured development cycles

I hope you’ll forgive my aggressive stance, but you must realize that I learned the basics of web development in an environment where everything I did in terms of following the guidelines for HTML and CSS was usually counteracted in some unholy and incomprehensible way by IE6. Later incarnations proudly proclaimed their superiority, but the few changes and lackluster support for internationally-accepted standards felt like a joke and, being the one shackled with the task of tearing apart my work in search of the one thing that IE misunderstood, I took it like a personal insult. Every new version of IE still required a conditional CSS stylesheet and at some point, just when IE9 came out, I stopped caring and decided that people still stuck with Internet Explorer would see a broken, ugly version of the website. The browser had gone from a nuisance, to a problem and was finally disregarded as nonexistent.

It's a good looking game.

My hyperbolic examples aside, I will argue that the mentality behind the decisions on where to take Microsoft’s flagship browser is counter-productive to the modern environment around development. Open source projects have gotten huge and aren’t going anywhere and people are getting very used to small, incremental updates and a transparent development cycle and it amazes me that it took Microsoft over 5 years to realize this.

That said, past my initial response of rolling my eyes and thinking that this was a shallow attempt to regain some ground with developers, I can’t help but think that this is a great thing. Both of the websites work damn well (in Opera and Firefox) and are examples of the web moving forward to provide more varied content. Also, Internet Explorer 10 is being developed with preview builds and updates from the development team and is getting a warm reception from the community. I am not changing my browser anytime soon, but maybe I’ll stop judging people as the enemy if they’re using the browser that came with their Windows system.

Edit: It has come to my attention that Microsoft are using slightly underhanded methods to promote their new browser. Maybe things aren’t that different after all.

Another edit: Microsoft seems to know how we feel (from Reddit).

PK Bloggin’!

I used to write with Joe Walker, who keeps a blog called PK Bloggin’! and when I noticed that his WordPress theme was breaking I had to step in and do something about it. I kept the main colors from the existing theme and threw something simple together and the end result was clean and he was very happy with it.

I based the theme of a WordPress variant of the Foundation framework created by Drew Morris and I must say that it’s the best CSS framework I’ve had the pleasure to use. I’ll be sticking with this from now on.

What Spotify Apps Say About the Future of Web Development

Spotify recently announced that they are adding support for apps that will run inside the Spotify application and which will be able to interact with the music and other segments of the program. Of course I was instantly all over this and, much to my amazement and shock the whole app platform boils down to a website running inside a Chromium-instance which gives you access to the main application via JavaScript-objects.

The current app lineup (of which the official We Are Hunted app is by far my favorite) showcases some of the cool things that can be done with the API, which lets you not only get the currently playing tracks, but create play queues from within the app, allow for dragging of tracks/albums/artists into your app and even have direct control over the music player.

Chromium's inspector open inside Spotify

The API was fascinating and all, but what caught my attention more was the idea that it was a fully-functioning Chromium-browser inside the program. This is nothing new, as Steam does something similar (using Internet Explorer, I think), with the application interface mirroring their main website, and PhoneGap has a way to wrap your website in a native shell which will run on mobile devices while giving your app access to hardware and system functions. However, I was fascinated by the possibilities it presented and I had to dig deeper to see what I could make.

I built a small app that fetches flickr pictures based on the currently playing artist, which took about evening of coding and taught me a lot. I am now of the firm belief that HTML/JavaScript is the future of app creation. Where I was once a stout supporter of native code using native UI, after building a website that runs inside of another application, I have completely reversed my opinion on the issue.

Spotify is a platform which doesn’t have built-in UI elements, doesn’t support multi-core processing and can’t run complied code at a-billion-calculations-per-second, but it doesn’t have to. The only thing it needs to support is letting you interact with the application itself and using a compiled language or going down the dangerous route of making their own scripting language would only have needlessly complicated the process and created an enclosed space with high barriers to entry. Sticking to HTML and JavaScript worked like a charm and given my long experience with building websites I was able to take an idea and build it in shorter time than it would take to get my app through Apple’s App Store Approval Board*.

What really blew me away, which in hindsight really shouldn’t, was the fact that it was a fully-functioning web browser, which meant that any code that would work on the web would work inside Spotify. I gave this a test and my aforementioned app experiment uses jQuery to perform the ajax call and DOM-selections, and follows a lot of the JavaScript coding conventions I learned while working on the Endless YouTube project.

What makes me think that the future of apps lies in HTML and JavaScript is mostly because of how prevalent it is and how easy it is to insert a sandboxed instance inside your application nowadays, opening up for anyone who has built a blog or made a drop-down menu to create apps that integrate with the program as if they were a part of the native code. The future of web development isn’t on the web, it’s taking what works on the web and shoving it anywhere you can find room.

As a final test to see if this web-to-app idea really holds weight was to try to see if a canvas-based game I built with some of my coworkers would work inside Spotify.

It did, and I didn’t change a single line of code to do it.

* Not trying for any subtle commentary here, just providing a useful and humorous metric.

spotify-flickrstream

I created a simple Spotify app which will fetch a continuous stream of pictures from flickr based on the currently playing artist. It was done over a period of a few hours without any prior knowledge about the API and is a testament to how easy HTML/JavaScript-powered apps can be. There is minimal interaction with Spotify itself, just a callback which listens for when a new track is playing (pretty much the one they showed in the tutorial) and some scaffolding, the rest is normal web code which would work on any modern web browser. It blew my mind how easy it is.

Unfortunately there is no way to share apps just yet, but if you have a preview version of Spotify and a developer-enabled Spotify account (it’s just one email away) then you should grab the code and see how much can be done without any prior knowledge.

Source on GitHub

Ninja vs Samurai

I recently made a game using LÖVE, in an effort to eat my own dog food but also for the fun of it. It started as an experiment to create a puzzle game which felt like an action game, or rather take an action game concept and build a puzzle game out of it. I took a simple idea, sneaking around without being seen, and built a game around it.

Doesn’t look like much, but it gets the job done. After some more tweaking I felt that there was a game in here somewhere, so I recruited a coworker of mine to create some nicer graphics and he came up with the idea of ninja vs samurai. A game is born.

You control your ninja and have to get to the escape hole without being seen by the samurai, who have a dramatically limited field of vision, but who will kill you instantly if you are spotted. Along the way you will find scrolls you can pick up and you can try to complete levels in a limited amount of moves.

The game is available from IndieDB for Mac and Windows and the source is on GitHub.

Source on GitHub

Git Guidelines for Iterative Development

I’m a big fan of Git versioning software, having received rudimentary training at work and getting into using it at home. It not only allows me the great benefit of being able to roll back unwanted changes or branch off into strange experiments, but thanks to GitHub I have backups of all my (recent) code in a format which makes it available to share with other geeks.

In my short history of using Git I have crafted a few guidelines that I follow to make my personal development experience just a little bit better. These guidelines aren’t complicated rules, but more of a description of the mindset I am in when using Git for my personal projects. These reflect a methodology which has evolved over a period of working on my own and I find them useful in keeping myself on track and having some quality control over my own work even when there is nobody else there to scrutinize it.

A small byword before we begin: I’m not sure about the true definition of iterative development, but in my mind it means that you start off with a small project and slowly but surely add components and features, each time ensuring that your modifications don’t break what you are working on. This could mean that you start off with a tech demo and work towards fulfilling a specification or it could just be adding to an existing product to create new and better versions of it. The topic is broad and my personal interpretation is vague and undefined, but in lieu of wasting everybody’s time explaining everything I’ll just leave it as: cutting a big project into smaller tasks that are done one after another.

There is But One Master Branch

What is the master branch anyway? Is it just the branch named “master”? Is it the single branch which all branches merge into before deployment? Is it the single branch that all branches are based on? Sure, it can be all of that, but in my mind it represents the final product. I don’t have a habit of working on multiple branches, especially because I am working by myself, but the master branch is the only one that I push to GitHub and the only one I can really depend on when it comes to showing what I’m working on to others.

In most projects all work is done to reach a single goal, the final product, which should be reflected in the way that Git branches are treated. Working on a separate branch should be done with the intent to merge it into the master branch at some point and you should never have multiple branches that reflect different versions of your program or different final projects that are part of a single ecosystem. When I migrated my Endless YouTube Player from PHP to Javascript there was a temptation to create different branches to hold the different versions, but in the end I understood that the move from PHP to JS was a part of the evolution of the project, and holding on to a stunted PHP version in its own separate branch would just create the illusion of an unfinished new feature being left to die. This is a task that is best left to tags, which are great for keeping track of previous versions of the project for whatever reason.

Push/Merge Only When You are Finished

This makes sense, right? You only merge back into the master branch or push your changes to the central repository once you are finished with what you’re working on. It’s of course up to you to decide what “finished” means, but for me it was when I was working on a specific feature which took me a few hours to complete, spanning over multiple commits.

I use GitHub’s Issues tracker to keep tabs on what fancy features I want to add to the various projects I’m tinkering with and it makes sense to leave any changes I have done in concordance with one of the issues on my local computer and wait until I’ve completed the task before I push it up to GitHub. This only really makes sense when the tasks are small enough to not span over several weeks, because losing my laptop or having the harddisk spontaneously burst into flames would be devastating if I had a month’s worth of work without a backup. However, if you’re breaking up your project into month-long chunks then I can’t really help you.

Every Commit is a Finished Product

This is probably the one which will either incite ire or have you cheering on my pedantic view on iteration; commits, no matter how big or small, result in a finished product that could be deployed and released into the world. This might be a little hard to explain, but it ties in with the previous guideline in the sense that whatever changes you’ve made to your code will not result in any unfinished function or pending changes left for subsequent commits.

If you’ve added a new feature then the feature is ready to be used, even if there is no way to trigger it. If you’re fixing a bug which requires you to change two parts of the program, then one part is changed and made to work with the rest of the program before the other change is implemented. Let me try with an example:

One of the features I was trying to implement in my upcoming puzzle game was the addition of collectibles scattered around the puzzle boards. A part of this feature was to change how the game keeps a player’s score, allowing it to keep track of the amount of moves the player had used to reach the goal as well as the amount of collectibles the user had picked up in that particular level. First I changed the scorekeeping to allow for multiple variables associated with a level, making sure every piece of the game which referenced the scoreboard was aware of this change. This was then committed (with an appropriately descriptive comment) and I moved on to adding the collectibles counter to the scoreboard which was then added to a separate commit.

This may seem like overkill, especially on such a small feature where the difference between the two commits was about 10 minutes of work, but it encapsulates the primary mentality I have when it comes to iterative development. Every task can, and should, be broken down into smaller sub-tasks which are completed sequentially and without affecting the rest of the project. Commits are just a simple way to create a symbolic separation between the sub-tasks and having the commits never break existing functionality or leave an unfinished gap to be filled in later is just good form. Good form results in better code and happier coders. That’s a scientific fact, look it up.

Tagging = Deployment

Depending on what type of project you’re working on, the concept of “deployment” can have many different meanings, but a good rule of thumb is to define it as any time where the project can be seen by people who aren’t directly involved in its creation, whether that be showing it to a client or putting together a demo to post on a social game development website.

The idea behind this guideline is to define the points where the project is production-ready and create a tag on only those instances, as those are the points in time which is it interesting to look back on. You can always go back to any commit you’ve created, such is the beauty of versioning, but, much like the previous guideline, this is a symbolic gesture of “it’s done” that ties in with the iterativeness of the project.

Those are the guidelines I follow, at least so far, and they have served me well, crafting a neat and logical Git history for me to follow. That said, these are based on my experiences with working by myself, so I won’t guarantee that they’d work in large teams that have to deal with bug fixing alongside feature development or some other crazy stuff that geeks get stuck doing when they’d rather be micro-managing their commit messages.

LÖVE Presentation

I recently had a presentation at my workplace about the wonders of 2D-game development using LÖVE. I’m not sure about the usefulness of posting the slides of a presentation without the accompanying presentation which (thankfully) wasn’t recorded, but for the sake of sharing information and not letting my hard work die a silent death in a GitHub repository I opted for posting it here.

The presentation is on my GitHub pages: http://michaelenger.github.com/love-presentation/ (use the spacebar to go to the next slide) and the examples are available in the repistory itself.

Publishing on IndieDB

I’ve been working on a small game prototype in LÖVE for the past couple of weeks, which takes the basic tenements of stealth gameplay—sneaking your way around patrolling guards—and presents them as a basic 2D puzzle game. The original graphics wasn’t much to look at so a crafty coworker of mine came up with something better, along with the idea to use a ninja (who has lost his weapons) escaping from samurai as the premise of the game, rather than nondescript circles whom nobody can relate to. People seemed to really like the game and I thought that, with my recent discovery of Desura, I would try to build a complete game and publish it on said platform.

Desura have a strict quality assurance policy and half-finished prototypes aren’t allowed, but their indie games portal IndieDB, the sister site of ModDB, is open to anyone who wants to add content. Well, as long as it is actual content, so no vague game ideas and obscure storylines consisting of a checklist full of spelling mistakes. You can even publish an existing game or mod from one of the sites directly to Desura and they all use the same login info, so it seemed like a good idea to at least start off on IndieDB.

I used the game distribution instructions to package my LÖVE file with the executables  and got ready to add my very own game prototype to the indie community when I came across their game adding page.

It’s huge! I didn’t expect to be expected to add so many pieces of information and look at all those required images. It took me a good half hour to scrape together all the images that were required and when I finally submitted the form it told me I had to wait for a moderator to approve my content. That was annoying. It then provided me with the helpful hint that adding downloads, images and articles would help my cause as the moderator would see that the game is in active development and isn’t just a half-baked idea in my head.

So I took some screenshots and uploaded them along with the actual game files (a Mac OSX and Windows version), finishing up with a short article about how I just added the game to IndieDB, which felt a little redundant. Well, after all that work I was left with more “a moderator will be looking over this, so check back in a few days time” messages whereupon I left, feeling a little deflated.

However, no matter how annoying the verification/moderation process is, I saw the benefit of it the very next day, when my content had been approved and my article was right on the front page of IndieDB. Clicking into the game page showed a few nice screenshots and had a header image and icon, which made the game feel more real and more professional than if I had just uploaded a pair of files with some text “please play my game lol”.

 Their scrutiny probably seems pointless when you have all your affairs together, but it probably saves the games list from being littered with the kind of crap that comes from lack of moderation (YouTube comments anyone?), so I can see the benefit of having a human being at least look over things before they are posted. Also, having it force me to spend a little more time on the presentation of my game ended up in something that looked pretty good, so it’s hard for me to complain about it. They host the files and provide me with a platform on which to promote my creation, so I am willing to play by their rules.

Endless YouTube Player

Endless YouTube Player is just that, an endless youtube player which will take a search term and give you an endless stream of videos from YouTube. It started out as a PHP library, but thanks to a JS-savvy co-worker of mine, I ported it over to JavaScript. I can be used thusly:

// Create the object (with an optional search term)
var youtubefeed = new EndlessYouTube('s club 7');

// Set the search term
youtubefeed.setSearchTerm('death metal');

// Get the videos
//   It will call the callback with an object filled
//   to the brim with video information
youtubefeed.getNext(callback);
youtubefeed.getNext(callback);
youtubefeed.getNext(callback);

The end result can be seen on GitHub tagged in various versions (PHP version and the first and second JavaScript versions) and I’m making use of the GitHub pages feature to host the page itself so that anyone can play an endless loop of cat videos :3

First version

Second version

Endless YouTube

Source on GitHub