Angelfire Retrospective

Angelfire was the first place I learned to code. And to learn how to design websites. The latter of which I never really got into, but in the past I didn't even think there would be a distinction. It was all part of programming, you did everything yourself, right? Not that there was much out there to really get excited about.

To those unaware, Angelfire in the mid-nineties, alongside GeoCities, was one of the most popular website that hosted websites. However, more than just a hosting company, Angelfire and its peers created similar platforms as WordPress, Blogger and others of that ilk.

This was the era of frames, <i> tags and most especially tables. No CSS, no JavaScript, something called CGI that did form processing (totally over my head at the time) - but the one thing it gave you was a real live website address on the Web.

I would navigate to my page, a made-up skateboarding company where I made designs using MS Paint, every day. I would try and load it on school computers, and I would use the first edition of HTML For Dummies to try and implement every possible tag, including <blink>. 

These were halcyon days of development for a young teen, as the HTML isn't processor or platform intensive and so provided me, and others I'm sure, with the ability to code without paying for Microsoft's development suite or even Borland's C++ compiler (which I eventually owned). Instead, you could just build something on your desktop, try it out and share it. Sure it was painfully slow, but it was a start.;

The details of Angelfire's purchase by Lycos and other minor points about its business (did you know it started as a medical transcription service?) are pretty nineties and not very exciting, but the late nights from this pain-in-the-ass web host will always make the name Angelfire perk my ears up.

Atari: Game Over

Currently on Netflix, the documentary Atari: Game Over does one thing very well - makes you very endeared to Howard Scott Warshaw.

Warshaw is the game designer and developer for the Atari 2600 game E.T. based on the film of the same name, that in 1983, supposedly killed the video game industry and thus, millions of copies of its cartridges were shamefully buried in the desert. 

This documentary is the story of the filmmaker's, Zak Penn, attempt to find those cartridges and to answer the question - What happened to Atari? 

Like a lot of recent video game documentaries, the film begins with some variant of "Now, video games are everywhere." This is probably an unnecessary line, considering the audience for this film has to be specialized enough to care about buried Atari cartridges but let's move past this.

The film uses Warshaw as the central character around the history of late 70s and early 80s video game development, explosion and subsequent downfall. Warshaw, who is now a therapist, had, before creating E.T., developed classic games like Yars Revenge and the adaptation of Raiders of the Lost Ark to Atari. Warshaw is naturally a part of this arc of history and admittedly realizes that he tried for decades to find the same high as he felt as a young man on the wave of the video game craze. 

While Game Over does the perfunctory history of the history of Atari and interviews with Nolan Bushnell, what it does so much better than its peer documentaries is tie it to Warshaw, who is person that the audience can actually connect to. In contrast Video Games: The Movie has a group of young people talking about how "AWESOME" Atari was, which may be fun for them, but when sitting in movie and asking yourself 'why should I care?' Game Over answers with Warshaw's experience and life. 

The climax of the film, not surprisingly, is the big dig, where Atari cartridges are discovered in a land fill. People come out in droves to see the dig and a cheer goes up as the old games are found. Ernest Cline, author of Ready Player One, is there too. He makes an appearance for several scenes throughout in a DeLorean from George RR Martin for no reason other than I can assume to throw some nerd-credibility in there, cause seriously, he serves no plot or historically illuminative purpose. But, really, his presence is a lot like the cheer as the games are found.

I am a game and vintage computer collector myself. I don't have a tremendous amount of money, so often I content myself with old programming books from the 70s. I own three Atari's including a Sears Atari. I own multiple copies of E.T. and my most rare game is Swordquest: Waterworld. I get excited about old gaming stuff, but not enough to break my bank. 

Nothing about the Atari dig excites me. As the different people at the end of the film explain, hating E.T. has become fashionable. There are far worse games on the Atari 2600, even the Atari 5200 in its entirety is terrible. The dig and its excitement in the film are Internet Exciting not actually exciting on a gaming level. That strikes me as a little hollow, like just throwing a bunch of retro gaming t-shirts on a character in a film and calling them a "gamer." To any screenwriters out there looking to exploit this market, I recommend you use Ernest Cline. 

I don't doubt anyone's authenticity, but self-congratulation and masturbation in gaming docs is horrendous, and it's the only part of the film that starts to dip into this realm. Fortunately, Warshaw carries it past this. 

Warshaw, having been demonized for his creation of E.T., is understandably touched by everyone's involvement, hardwork and enthusiasm. This is actually moving. It's validation to a person that his who had to give up a career he was good at and loved. As the film notes, there are no lifetime achievement awards for Warshaw. 

I didn't obtain any new information from this film, but it did make me like Warshaw more and that's for a guy who is already pretty likeable. If you haven't seen his series Once Upon Atari it's one of the more in-depth "documentaries" on gaming and programming history I've seen.

What is Wrong with Fighting Tournaments

The above video is funny and a pratical annoyance for anyone playing tournament fighting games. Personally, I always figured there were other fighters going on in the background, and to be fair, in the original Mortal Kombat you do see a bunch of random bodies lying around in the spike pit that look fairly fresh.

But there is one more element to most fighting games that I depise besides the fact that they are not technically tournaments - no one in the game treats it like a tournament. Watch the below series of cut scenes. Well, probably don't need to watch all of it. In theMortal Kombat (reboot) there are only a handful of times when people are actually fighting in matches. Aside from that, people just try to constantly randomly kill one another.

Well shit - if you can do that just fucking have everyone do a fatal melee. In the MK universe in particular, I know Shang Tsung's a bad guy, but if all he ever does is cheat and have people murdered than what the hell is the point of having a tournament. Just have people come to your evil island and throw them in the fucking spike pit or whatever.

And real quick - who the hell are those monks in the background?

My point is: the lacking of any semblance of a tournament really makes these tournament games feel like they are awkwardly trying to fit a larger story into what is essentially two people pummeling each other. AND that's exactly what they are doing. BUT - I would suggest that there may be actually interesting stories to be had in fighting tournament games, if the designers had characters that actually adhered to a tournament. Perhaps there are different conditions as you go through the tournament, just a thought.

Now, if you'll I have a creepy island to head to for a tic-tac-toe competition...

Civilization is Words

A civilization runs on words, Your Reverence. Civilization is words. Which, on the whole, should not be too expensive. The world turns, Your Reverence, and we must spin with it...Once upon a time nations fought like great grunting beasts in a swamp. Ankh-Morpork ruled a large part of that swamp because it had the best claws. But today gold has taken the place of steel and, my goodness, the Ankh-Morpork dollar seems to be the currency of choice. Tomorrow...perhaps the weaponry will be just words. The most words, the quickest words, the last words.

Terry Pratchett, Truth

First Time with Chrome Extension API

This is not a tutorial article on the Chrome Extension API. There's plenty out there, so this is more a fun discussion of what I enjoyed about using the application framework. 

For those programmers or soon to be programmers - the Chrome Extension API is a JavaScript / HTML / CSS framework that allows the developer to build essentially websites within the Chrome browser, whether a full page app or pop-up box.

The JavaScript API allows the app to access Chrome-based features and information such as tabs, history, window content and notifications. Other services like accessibility, internationalization and cron-like tools are also available. With that understanding, let's look at what makes this a great framework more generally. 

Let's first start with the API docs, speaking of tutorials. Well, these are tutorials per se, however, I am thoroughly impressed with the accessibility and simplicity they demonstration regarind the extension framework. By the time I got to the fourth API group, I was already intuiting what would be present and what calls would be named, and violia, I find what I need immediately. For beginners, particularly I imagine if you a programming newbie, this is such a blessing. Sure, it'd be great to know how to write JS well beforehand, but even the bare minimum of knowing how event listeners work will get you a long way. 

Which brings me to my second and perhaps biggest gush about the API - it's trimmed down simplicity. I'm reminded of the antipattern I've seen in joking projects like Simple PHP Easy Plus when I see an API like this. This is exactly what developers want most of the time. For basic services, we don't need extreme complexity or minute controls. I just need a couple couple calls to say - do this ONE things at some point. It's refreshing on its own, and empowering, as I believe the really exciting part about extension / plugin services is the combination of services rather than the direct detailed manipulation of those services one at a time. 

While the API calls themselves are mostly what you might guess Chrome would have available, the background app is perhaps the best part. As the name implies, a simple background.js (or whatever name) is a script that runs continually based on event listeners regardless of the state of the front end of the plugin. I found this helpful for not only the listening events, but app bootstrapping on installation as well. 

Simply put - it's nice to be able to quickly spin something up.

I don't know how big or powerful the Chrome Extension market is. I see a lot of popular brands on there, but I'm not sure how much that was motivated by the marketplace being yet another marketplace EverNote and the like need to be in, or if these are really used heavily as plugins. With that in mind, I'd say it's a great place for developers to cut their teeth a little and get something out there to the world. 

On that note - I will soon have an extension in the store called BetterSpent. Check out the gitHub project and let me know if you want to contribute. 

Haul from Powell's

Went to Powell's the other week and got a might haul of books from their computer sections. None of these are very modern, but I love old books.


The Art of Computer Programming Vol 2


Switching and Finite Automata Theory

Charles Babbage: On the Principles and Dvelopment of the Calculator and Other Seminal Writing

He Had Such an Impact

And I really had no idea who Tokuro Fujiwara was until recently. His short Wikipedia summary ends thusly:

He is notorious for making his titles difficult for the average video game player.

That is what I remeber and know best about Fujiwara's games. This is my short gush about how great of designer this guy was.

As the creator of Ghost 'N Goblins, Fujiwara can probably credit himself with creating one of the most difficult games of all time. If you don't know, not only is the game ridiculously hard, but you have to do it twice. The same game - twice.

As it turns out, Fujiwara had a much greater impact on my early gaming career than just frustrating me. Fujiwara also created or worked on as a producer fantastic, and some easy games, like the game adaptations of Ducktale and Aladdin, two games that I could probably beat right now if given the rest of the evening.

Fujiwara also worked on Strider.

Strider was a game I didn't actually play very much, but for some reason watching kids play it at the arcade enthralled me. Looking back at the longplay above, I can't really say it was the best designed game, but that flash of the sword still looks cool.

While, I guess you might consider a lot of these games one-off's, Fujiwara's most enduring contribution was his production work on the Mega Man series. I can't really pretend to add anything to the discussion of how great Mega Man is, but it was one of the more foundational titles of my youth and the majority of the games in the series still elude my victory yell. While he can't be credited with creating the series, looking through the rest of his CV, particularly Mega Man X, I get the feeling of "Oh, I knew something was familiar in that. "

In this way, Fujiwara is an internally divisive designer - his games in many ways annoyed me to no end, and still do, yet his work blew me away and has fascintated imagination for years. Even the difficult titles.

Randomly, one title stood out to me amongst his credits -Little Nemo.

I've been a huge fan of Winsor McCay and Little Nemo is one of those comic strips that is simple to describe but never gives you any sense of how wild and explosive the work was. I've always found it strange they decided to adapt the comic into a NES game. Not surprisingly, Fujiwara was invovled in it as well.

I really can't say much about the game as it wasn't one I really played growing up, but I will close in saying that the difficulty of Fujiwara's games did a lot to help me imagine how I would make games as much as the colors, music and levels. And after all, the difficulty has kept Ghost 'N Goblins on my mind since I was six.

Towards Skyscrapers

I was once asked by an employer what I wanted to build and I told him (a couple drinks in at this point) - skyscrapers.

I'm no architect, what I meant, was that I wanted to build large pieces of software. The challenge of a large piece of software is there for most developers whether they are working in OS, web apps, games or whatever else. There is some skyscraper for your world. Except, maybe brouchure-ware.

Walking in downtown Seattle, I realize that I feel should never be trusted to build a skyscraper. What do I know to preserve a standing structure in the face of a real world environment? I take solace in the three posts below of a few people who started by asking simple questions and built cities from there.

Larry Page co-founder of Google on a Java forum asking about User-Agents:

I have a web robot which is a Java app. I need to be able to set the User-Agent field in the HTTP header in order to be a good net citizen (so people know who is accessing their server). Anyone have any ideas?

Notch inventor of Minecraft, sharing his alpha build:

It's an alpha version, so there might be crashes. You can read some background and insight on my blog available from the game page. The main inspiration for this game is Infiniminer, but it's going to move in a more Dwarf Fortress way, gameplay wise. =)

[Personally - I'm a little disappointed he didn't keep fortress mode]

Linus Benedict Torvalds asking for documentation for a project:

Due to a project I'm working on (in minix), I'm interested in the posix standard definition. Could somebody please point me to a (preferably) machine-readable format of the latest posix rules? Ftp-sites would be nice.

No one starts by building Skyscrapers and I guess after all, history didn't either.

What Most People Miss About Drupal

I've been working with Drupal for about six years or so. Like many, I sort of fell into Drupal in the manner by which a lot of us end up aligned with one CMS or another. Meaning, it was a historical alignment rather than an academic one. 

Regardless, Drupal is still a good reprsentation of what a CMS can and should be. It definitely has its shortcomings (loading times, come on!), but there's a lot to draw from its architecture and patterns. That said, there's a lot of what both developers and non-tech savy end users mess up as they attempt to get more complex with their CMS. These aren't technical issues so much as conceptual ones. 


The System Doesn't Know What You're Thinking

There's this adage in programming - the computer does what you tell it to do, not what you want it to do. With Drupal in particular there are loads of settings, permissions, weighting, and so forth that need to be optimized for your particular site's content. While this can be frustrating, it does just take a little bit of time to get everything in order, however, while a user not being able to see the navbar can be annoying, the most common place I see this issue is with images. 

Drupal's fancy image cropping, scaling and processing are awesome, it's one of my favorite parts about spinning up a Drupal site. But what most folks forget is that while it can make everything fit a certain dimension for your design, Drupal doesn't know where your picture looks good. Maybe someday Drupal will be able to find the best cropping of a photo for a thumbnail, today is not that day. 

I've seen this in subtle ways elsewhere. For example, folks will develop and complex user system hierarchy, but then not want to manage it, wishing the system would just know where there new users should go. Likewise for node type management, particularly when there are a load of custom fields per node. 

You Must Have a System as Well 

Drupal is a CMS. It's a system that tries to publish content for you in an organized way. However, your end as a site content producer must be systematic for the site to work well for you. Drupal is not a tack board to simply plop content however you would like on the front page. Having a loose system for how you would like to display, publish and arrange content, while it can be expressive for some content producers, it is also very brittle and the system's liable to break and stumble over itself. 

This most commonly occurs in design and in the block system. You'll have a hundred blocks or so that have these extremely specific node listings for display. None of that is fun to maintain and it some point you'll want to toss it all out.

Layout and Content Are Not the Same Thing

This is my personal rule, and I've violated it plenty of times, but at no point should you have these complicated layout fields in your nodes that designated whether something should have a particular background color, text color, width, whatever. All this should be built out into the theme. Content producers are not designers and they shouldn't be forced to make design decisions as they produce content. 

Use different node types if the layout is really that complex, but more importantly, Drupal works well with a simple design rather than an overly complex one that ends up sucking the energy out of the site editors as they try to create nodes that just look decent. 

Tagging and Sorting Are Not the Same Thing

Drupal's taxonomy system is awesome. It's all you need and just so. As such, the system should not be jimmy-rigged to work with a blending of ordering and of tagging. This basically comes up in situations where you define a list of words like "featured", "top" and such to make things sticky to the top of lists. First off, there's already a sticky feature in Drupal. Second, without a doubt, site users almost always mix up their ranking systems so the content lists don't come out looking as they should. 

I always recommend that people use nodequeue or node references if you want to manage specific content lists and let your related content float naturally using some system like publication date. This will typically give you all the control you need without having an extra layer of hassle. 


More often than not, developers tend to give themselves trouble by not holding their Drupal implementations to an organization where it will work well. Sure, you can make Drupal do such and such, but often times it's a hack rather than an innovation. While these make-it-work solutions can satisfy you for a short period, they tend to give Drupal site managers and content producers more work. 

Best advice - keep it simple. Spend your coding time making good themes, organizing proper Views, and using custom module dev for more complex queries or data entry / processing. If you find yourself spending a lot of time in custom fields, taxonomies or blocks, you may want to reconsider your approach.