Gaslight & Steam

The term anti-resume is used in several different senses, most commonly refer to a narrative resume in the fashion of Anne Sexton’s Resume 1965. My own profile is a reasonable example of this form of resume.

The other sense of the term is that mentioned in Nassim Nicholas Taleb’s book The Black Swan where the author comments, “People don’t walk around with anti-resumes telling you what they have not studied or experienced.” For computer geeks, this seems to be doubly true since it’s often a point of pride about the depth of knowledge in a particular area one has, whether it’s a computer language, a code framework, or some particular anime director’s corpus of work.

To list all the things one doesn’t know, even in the broadest sense, would still be a ridiculously large list, not to mention a rather pointless intellectual exercise. But there would actually seem to be quite a bit of value in analyzing one’s abilities in terms of what one aspired to learn (but might never learn due to lack of aptitude or limitations of time) or what one planned to learn for a job role (a variation on the, “where do you see yourself in five years” question). In the latter, the anti-resume becomes a tool for planning one’s personal or career growth.

My first take on a personal anti-resume looks something like this:

• Foreign language (Japanese and Mandarin Chinese). Despite having had two years in college on the former and taking some lessons in the latter, my ability to speak these languages is below the level that might be considered functional. I comprehend enough Japanese to get the gist of conversations when my daughter’s friends speak Japanese with their parents and I can occasionally puzzle out words in katakana. My Mandarin is stuck pretty firmly at the preschool level, though I know all the words to the children’s song “Liang zhi lao hu” (“two tigers”, sung to the tune of “Frere Jacques”).
• The .NET web technology stack (IIS, C#.NET, SQLServer). I know just enough of these technologies to be dangerous, having worked off and on with IIS and deployed ASP pages, built at least one app with C# and used SQLServer on the desktop for Vignette. But I’d like to know more and I’d like to be able to build full-featured data-driven web applications with this technology with the same proficiency that I do with other technologies (LAMP and Java).
• Functional programming languages. Ever since first being exposed to them in a meaningful way at No Fluff Just Stuff in 2008, I’ve been excited about functional programming languages like Erlang or Clojure. In addition to learning more about those languages (pick one), I’m still fuzzy on concepts like lambda calculus and curried functions and would like to learn more, particularly when it comes to applying some of those concepts to the Javascript work I do.
• Probability. Having completed a course in statistics, I feel like I have some better tools to further improve my understanding of probability and things like Bayesian analysis. There are so many applications for probability in the computer field and I feel like I’ve barely scratched the surface with my reading.
• Geography and GIS. I have a real fondness for maps and geography along with the ways we use maps in ways beyond getting directions somewhere. The use of maps on the web and other technology like GPSes are of particular interest where they overlap with ideas of space over time and human relations to space (such as human migrations and land use, urban development, and community building). I may not be quite the GIS maven that Scott Davis is, but I have his book GIS for Web Developers and I plan to read it all the way through sometimerealsoonnow.
• Javascript and jQuery. I’ve been writing Javascript for years, though it’s only recently I’ve begun to explore its real capabilities, as enhanced by the various frameworks out there including YUI, prototype, jQuery and DOJO. I’ve had the ability to dive pretty deeply into jQuery in recent months and want to master its capabilities.
• Computer Security. With the recent concern about PCI compliance and working in an industry where we deal with confidential health records, security of our data, our applications and our servers (the latter two, respectively, accessing and storing the data) is a major concern. Among our many concerns are making sure we’re in compliance with regulations, checking that the site isn’t vulnerable to things like XSS attacks and ensuring that the applications are secure. We also work closely with the IT group that manages the servers to avoid inadvertently introducing security holes and exposing data.
• Algorithms and Design Patterns. My first serious exposure to design patterns was with my Java certification, though I discovered I’d been using some variation of various patterns without knowing what they were specifically. Having the knowledge and using it in a systematic fashion has made me want to learn more about patterns I haven’t used. The same holds true with algorithms such as sorting data and lists, traversing trees, and compressing data.
• Aikido. I’m currently a member of the Tsubomi Seishin Kan Dojo, but time constraints and finances have limited my ability to take aikido lessons right now. I hope to continue classes in the near future, probably as soon as I’m not spending as much time with school and learning some of the previous things in this list. Of the martial arts I’ve studied, aikido resonates with me, combining the breathing and moving meditation of tai chi with the discipline and weapons practices of karate. Not only that, but the people in my dojo are a really great bunch of folks I like spending time with.
• Writing. I’ve written extensively throughout my life and in number of different modes including fiction, poetry, technical documentation and this blog. There’s always room for improvement and learning. I’d love to write a book, perhaps a novel, and some short fiction, either fantasy or science fiction.

That’s just a quick take, but probably more than enough to keep me occupied for the next five years.

There have been many game designers and creators of game systems who I admire, but few as much as Dave Arneson. So I was saddened to hear he had passed away last week on April 7th. For someone like me who remembers the original three book Dungeons and Dragons books (as do many others), the Blackmoor supplement remains one of my favorites of all time and the first setting to really capture my imagination and to hold it more than the many others over the years.

Matt Blum wrote in his Wired Magazine column, “It was Arneson’s spark that transformed Gygax’s game Chainmail into the first edition of D&D, and begat everything that followed.” In his career, he was a man of many talents, combining a love of games not just as the developer of D&D, but as a teacher and creator in other mediums including computer games. In the Star Tribune (article no longer available), his daughter said, “…her father enjoyed teaching at Full Sail University in Winter Park, Fla., in recent years, where he inspired future game creators, and taught students to make a solid set of rules for their games.” His approach to games makes more sense to me than that of other designers and probably why some of my earliest favorite computer games tend to resemble computer versions of Arneson’s Temple of the Frog, among them games like Telengard, Temple of Apshai and Wizardry. There are some great insights in this previously unpublished interview with Dave Arneson from 2004.

Though’ll he’ll be missed, we’ll always be grateful for the person he was and the legacy he left. It’s truly a great one.

Javascript implements hash tables in a limited and somewhat unwieldy fashion as associative arrays. The jQuery.field plugin has some useful functions including a formHash() function that returns all the elements of the form with the field ids as the hash keys and the form values as the hash values corresponding to those keys.

Some people consider treating associative arrays as hash tables as being downright bad since they appear to have all the characteristics one would expect, but in fact, do not. For example, the way one iterates over the array and the ability to determine the size of the array (array.length).

This custom implementation solves those problems rather handily (and there’s an implentation in the comments with the Ajaxian post linked in the previous paragraph). I believe this is what people refer to when they recommend using objects rather than simple associative arrays (since arrays are, themselves, objects in Javascript).

For the purposes of the work I was doing, where it’s not intended for production and where performance (or scalability) is not a consideration, but rapid prototyping and the ability to easily correlate form fields with labels, this implementation seems to work just fine:

jQuery.fn.labelList = function(){
	var strValueList = [];
	var label = $(this).find("label");
	label.each( function (index) {
		var id = $(this).attr('for') || 'undefined';
		if (id) {
				labelText = $(this).text();
				if (labelText.substr(0,1)=="*") { labelText = labelText.substring(1, labelText.length); }
				if (labelText.substr(labelText.length-1,1) == ":") { labelText= labelText.substring(0, labelText.length-1); }
				strValueList[id] = labelText;
		}
	});
	return( strValueList );
}

Which is then used in a function something like the following which is called using:

$("#yourFormID").collectResults();
 
jQuery.fn.collectResults = function(){
	var currentForm = "";
	var myResults=$(this).formHash();
	var myLabelresults=$(this).labelList();
 
	currentForm += "
<ul>";
	$.each(myResults, function(i,item) {
		itemName = myLabelresults[i];
		if(itemName != undefined &amp;&amp; itemName != "") {
			currentForm += "
	<li>"+ itemName + ": " + item + "</li>
\n";
		}
	} );
	currentForm += "</ul>
";
	$("#outputContainerID").append(currentForm);
}