Developing Upwards

I had been pondering some architecture issues after a day of refactoring and cleanup on an HTML5 game I’m building at work. Some common data/UI integration problems were bugging me, mostly just for the feeling of good separation, and I was about to post to r/gamedev : I'm looking for advice on some minor architect issues in some HTML5 gamedev work I've been up to. My background is as a web developer professionally and a very trivial game developer as a hobby, and I"m only recently combining those. However, for lots of reasons related to the positioning of this game as *part* of a larger web project at work, it isn't a traditional <canvas> HTML5 game, but being done with a combination of DOM and concern-separated logic. I'm having trouble figuring out how where to draw the lines between the bits that implement my UI and the bigs that run logic behind it, and how to keep them in sync efficiently. There are patterns for this, but I don't feel like my

8 Gigabytes Sitting on Top of 8 Bytes From  http://en.wikipedia.org/wiki/File:8_bytes_vs._8Gbytes.jpg  via @Tef

Introduction I’m coming to an opinion of Javascript module loaders that is profoundly negative and I’d like to express why I think they are, generally, a bad idea. However, I do think they have a place, which I’ll get to at the end. Now, I understand I might be in the minority here. Between the competing specifications of CommonJS and AMD modules, loader systems like RequireJS or the (honestly really awesome) Google Module Server, and the huge cultural influence of Node on the Javascript world, you’d be hard pressed to argue against Javascript modules these days. Scripts are old hat, too stupid, too inflexible. Everyone knows that and no one would make an argument in their favor, right? I’m going to step out on a limb and say “Javascript Module Loaders Considered Harmful” and I know the baggage involved with declaring something “Considered Harmful”. I mean every ounce of context that phrase carries with it, and I hope I can persuade you. Harm #1: Confused Debuggers

I'm playing with some game dev fun on the side, and as part of motivating myself I hope to have something to post to /r/GameDev's Screenshot Saturday event every weekend. This quickly got me wanting to show off something other than a still image, so I went looking for how people produce the animated screenshot GIFs I see developers posting of their games all over. Here's what I found: Step 1: CamStudio This open source screencast recorder is very simple, very light, free, and does a good job of recording a basic AVI screencast of a portion of your screen. You can set it to record just the part of your screen where your game is running, so you don't need to worry with post-processing crop. I tried a few other tools before this, and all of them had more up-front configuration and none of them really worked well. Either they only recorded black, or they had awful framerates, or they made my whole system crawl. Just get CamStudio . Step 2: VirtualDub Maybe there i

We’re in a position that, for many projects, we must include some sort of browser storage. Unfortunately, we aren’t yet at the point where the best approach is entirely obvious. Between localStorage, WebSQL, and IndexedDB developers are left with a complicated pool of options and difficult to compare pros and cons. localStorage The simplest and widest supported option is localStorage. If you can solve your needs with it, you should. localStorage keeps simply key->value pairs of strings in the browser, even when your website is closed. There is no real structure to the information you store, making it good for simple cases like user preferences or caching of necessarily small things. Use localStorage when You need to store less than 2.5 MB, which varies a bit between browsers You can deal with the storage failing, which can happen in private modes or when hitting storage limits. Some failures are silent You can identify your stored data by easily known keys, and d

I'm looking to gauge interest in the community for building a feature postmortem blog. I tweeted the idea yesterday and immediately had some people who seemed to like the idea as much as I do. The goal would be writing in the context of a project about a specific feature you built, what you needed to refactor to make room for it, and what how your previous decisions had helped or made difficult the new work you were doing. How was the work able to be broken down? Did you account for future changes you know you'll make? What work did you intentionally leave for tomorrow or the next developer? At the heart of this idea is the thought process in my head when I sit down and work on something specific, and wanting to share that process with others and to get the same back to them. I would love to curate a reader submitted collection of these stories. Is there an interest? Please tell me if you'd like to read this and especially  if you'd like to contribute!

We need to train new developers, and we need to make programming approachable by more people, if only to get their attention before they dive deeper. I'm not speaking anything new hear, but I think there are some gaps in many of the common narratives. Narrative 1: We need to teach kids and more adults to program I agree! We need to get the attention of adults who might be interested in a career change, and we need to capture the imagination of children who can grow up and build the future software ecosystems we'll use in our retirements. But there is a gap in this narrative, between the learning to code and the actually being an active experienced developer. At least in many of these cases, education is given in some more approachable fashion, but it isn't given in a way that a clear path exists from start to finish. We hook them, and then we rely on a common trait of developers to get them through the harder bits. I'm going to use Python and games as an