You are viewing edgarverona

Alex Loret de Mola
26 June 2010 @ 05:03 pm
Okay, so I finally took the time to put up a replacement blog, so that I can get away from the full page ads that Livejournal has tastelessly decided to add to blogs.

It's at:

http://vthornheart.railsplayground.net/blog/


Any new posts will be happening over there!
 
 
Alex Loret de Mola
Well, my song reviews via YeaOrNay just got blown away... it turns out that in its default settings, Zune scours your computer for windows media player playlists and brings them into Zune, which does two things:

1) It overwrites the original playlist in such a way that the ActiveX Control no longer recognizes it as a valid playlist, and crashes when it tries to open it. (Why?  I can't imagine this was intentional on Microsoft's part... but it definitely does it, I've got the files to prove it)

2) It attempts to sync what it considers to be its version of the playlist, overwriting any changes you made to it. (Again, I can't imagine what made them decide that this would be a useful feature)

So basically, the Zune software had its own copy of my SXSW playlist... one without any of my changes... and it overwrote *and* corrupted the playlist file.  Fixing the corruption is easy because it's a text file, it just adds a bunch of unrecognized attributes... but it overwrites the ratings and sorting I did, which sort of defeats the entire purpose of what I was trying to do.

I found myself scouring the internet for ways to stop the Zune software from performing this undesirable task.  Turns out there's a registry setting that you can tweak to basically make it stop scouring your computer at all.

Go into:

HKEY_CURRENT_USER\Software\Microsoft\Zune\Groveler

Now in there, set "LibrarySync" to the hex value "ffffffff".

Doing this shuts off all linking of Zune with your Systems' concept of Music Libraries, and prevents it from performing its scour/corrupt/overwrite cycle on WPL Playlists.  The benefit is useful to get rid of and worth changing the setting, but the "your Zune is now isolated from what your system considers to be your Music libraries" drawback is admittedly annoying.

So here's how you minimize that drawback.

In the same folder, set the "RipDirectory" property to a folder *OTHER* than the one that you house your playlists in.  Contrary to the name of the property, "RipDirectory" is actually the folder where Zune will now look for your music.  This folder, and *only* this folder.  If you create playlists, it will create it underneath this folder.

The ideal technique to make both Windows Media Player and Zune happy is to make your "primary library" for music in Windows a place that only has my playlists and no music... and then to point Zune's "RipDirectory" setting to your *real* music folder (one that has no playlists, and is NOT set as your windows "primary library" for music, but is set up as a library), where Zune can proceed to make all the incompatible and annoying playlists that it wants without harming your Windows Media Player playlists.

(For those who don't know, you can set your windows music libraries and choose which one is primary by opening Windows Explorer, right clicking on your "Music" libraries on the left side, and selecting "Properties".  An interface pops up that lets you add folders to the library, and choose which one is the "Default Save Location".  This is what Windows Media Player refers to as your "Primary Library", and it will be the one that you'll want to have playlists and ONLY playlists located in.  Make some other folder the one that has all of your music, and add that to the library as a non-primary folder.)

If you do this, both Windows Media Player and Zune have access to the music without going to war over who controls what playlist.

The fact that I had to go into the registry to fix this is something I'm okay with, but I imagine most users wouldn't be... though admittedly, most users might not be looking for the kind of solution I'm looking for.  I know that any user who wants to use both Windows Media Player AND Zune would be extremely annoyed by their playlists being constantly overwritten.  It's apparently a well known problem out there on Zune forums, but who knows if they'll ever do anything about it.

Can't look a gift horse in the mouth though, the Zune is definitely nice to have.  I just have to find ways around their terrible compromises that they made in creating a whole new "Windows Media Player-esque" app just for the Zune.  Hopefully this will be helpful to other Zune owners having similar playlist overwriting headaches... as I had to scour forums for quite some time to find the real setting for LibrarySync in particular.  (I'd found the setting when browsing the registry looking for clues before I thought to look online, but I didn't know what a valid setting would be for it...)

 
 
I'm feeling: blahphew
 
 
Alex Loret de Mola
21 June 2010 @ 03:27 am
Last week, I won a Zune at GiveCamp from a raffle... having never owned a portable device with this much storage space before, my thoughts turned this weekend to how I might be able to help me solve some musical logistics problems.

By "musical logistics problems", I mean the 32GB of public domain SXSW music that's been sitting on my computer, unlistened to, for at least a year.  It's about 5000 songs, and most of them are - quite frankly - terrible.  What I desired was a way to very quickly give thumbs up or thumbs down on a song, and have it remove said song (placing it in a "good" or a "bad" bucket to be listened to and deleted, respectively) and continue to the next until it was all done.

The big problem is that performing such a task is a hassle with most media players.  Those that even have a ratings system make you go through a process that isn't laborious until you have to do it 5000 times in a row: choose the "star rating", move the file yourself, and then go to the next record.  Tolerable when you have only a couple of songs to rate... unpleasant when there's more than a dozen.

What I needed was an interface that I could - ideally, as it ran in the background - give the thumbs up or thumbs down to as I went about my day.

First Pass: Zune App

My first thought was that I could use this as an opportunity to delve into the Zune SDK.  This turned out to be a big rabbit hole that ate up much of Saturday afternoon before I realized that it just can't be done with the current SDK, nor with any currently existing hacks that expose the "hidden APIs" of the Zune such as OpenZDK.

I did have a lot of fun toying around with OpenZDK's framework in particular: they have a clever hack that convinces the Zune to run unmanaged code under the guise of it being a content file in a managed app.  Through it, you CAN do neat things: unfortunately, the new neat things that are unleashed all have to do with accessing the NVidia 3D Accelerator on the Zune.  (An interesting side note: did you know that the Zune SDK gives absolutely no access to the use of the 3D Accelerator?  They put a state of the art NVidia mobile chip in there, and the only people who get to use it are Microsoft and those who figured out how to hack it with OpenZDK.  I think that's pretty shameful, and a good indicator as to why the only apps in the Zune store are Microsoft apps... but I digress).

The big problem is that almost everything on a Zune is read only from a programmer's perspective: you can't create playlists, you can't alter playlists, and you certainly can't delete files programmatically.  Once I started to think about ways to get around it by using the Zune's wireless network connectivity (ALSO locked out from your use unless you do it through OpenZDK!) and perhaps hosting some kind of RESTful service on my computer that would modify playlists, I knew I was beginning to really hammer a square peg into a round hole.  The Zune just wasn't meant to do this.

After I slept on it, I realized that it's probably for the best.  If this app - whatever it ended up being - ran on a windows machine, we could easily hook it up to some speakers and have everyone in the room rate the songs, which provides a social and more democratic experience (after all, my wife may end up having to put up with listening to whatever we vote on!)

Noting that OpenZDK could be fun for a future project, I had to move on if I was going to get it done this weekend.

Second Pass: Windows Media Player Plugin

My second attempt was to create a plugin for Windows Media Player itself.  I'd never done it before - I was having a hard time even finding reference material online for such a thing - but I knew it could be done, and it seemed reasonable.

I found an open source project called WMP Keys (on SourceForge), and began to tear through its code to see how it worked.  It was all in C++, which isn't my preferred language these days but I could get by.  WMP Keys had some of the core of what I wanted: namely, the ability to assign complex functions in Windows Media Player to global hotkeys so I could do other tasks and still be rating songs.

Within about an hour, I had modified WMP Keys and its settings interface to accommodate as many features as it could.  It was able to automatically rate the current song via hotkey (a feature it already did), move to the next song as needed, and even sort the good and the bad songs into separate playlists.

But there was two tiny - but annoying - things wrong with it.  One was that I couldn't really put up the simple UI I wanted to put up (with the up or downvote), for when I didn't want to use the shortcut keys.  The other is that as a plugin I couldn't find a way to actually hook in to detect when someone's actions on the player *itself* changed to a different song or even playlist.  The former was a minor inconvenience, but the latter felt less acceptable.  Looking through the documentation at Microsoft, it sounded like being able to hook in as a plugin just wasn't going to happen: I had to have control of my own instance of Windows Media Player.  So though I was 90% there with this concept, I decided to take it one step further and write an app.

Third Pass: Using the Windows Media Player Control

In retrospect, I probably should've just been satisfied with my modifications to WMP Keys.  But I definitely learned a lot in the process of getting what I wanted working in this app!

Since it was an ActiveX control, I could interface with it in C# which brought me back to a more comfortable language for me.  I began creating an app that was bare bones but provided a bit more customizability than I was getting in the WMP mod: the ability to more easily change playlists on the fly, for example, and to control what happened when a new song began to play.

In the course of this, I found out a feature of .NET Windows Forms development that was hidden in plain sight and I never realized it!  The old school WndProc method, which I knew must exist in some form under the surface, is actually an overrideable method in Forms that you can use to handle messages directly from the Win32 API!  In this situation, it was necessary in order to provide those "act in response to a new song playing, regardless of how it started playing" reactions that I wanted the app to have.

I also did a bit of research and found some great code out there for registering and unregistering global hotkeys (http://www.pinvoke.net/default.aspx/user32/RegisterHotKey.html), and worked it into my app.  After creating a (frustrating!) hotkey settings assignment screen and doing a bunch of debugging, it was good to go!

Here's a screenshot of the silly app:



The buttons on the side are for approve/disapprove/skip song (to come back to it later).  In order for you to start approving/disapproving songs, you have to first choose all three playlists needed: the "to play" list, the "Good" list, and the "Bad" list.  (You can also create a playlist on the fly as needed).  Once you've done that, the windows controls appear and you can hit play to let it run, and go into the "Hotkeys" area to modify your hotkeys.



The hotkey modification process sucks at the moment, but it's enough to get by.  Basically you put your cursor in the textbox for each hotkey, and hold down your CTRL and/or ALT and/or SHIFT and single letter combination.  When you do this, it checks off the requisite checkboxes and upon hitting save, your new hotkeys are assigned.  Since it's just a quick and dirty app, I'm not planning on going back to fix it... but I'll throw the source somewhere in case anyone wants to play with it.

You can also double-click the menu bar on the main window to shrink it down to just showing the Approve, Reject, and Skip buttons, and double click again to bring back the whole interface.

On the whole, it was an interesting weekend project.  I learned a lot more about Zune's SDKs and Windows Media Player's interfacing options than I imagined I would going into the weekend... and I got something that at least I'll genuinely use out of it! =)

Okay, it's up on CodePlex now for your perusal in both hastily-created source and mostly untested binary flavors!

View the source/project: http://yeaornay.codeplex.com/

Download Binary: http://yeaornay.codeplex.com/releases/47530/download/128271

Enjoy, if possible! ;)
 
 
Where am I: home
I'm feeling: accomplishedaccomplished
Musical Stylings: None
 
 
Alex Loret de Mola
15 June 2010 @ 12:02 am
I had an extremely eventful weekend at GiveCamp!

For those who don't know, GiveCamp is a set of events that occur across the country where nonprofits are matched up with software developers for a weekend.  The goal is to complete whatever technical projects the nonprofit organizations need accomplished by the end of said weekend.

Needless to say, there were some awesome ideas and great causes there!  I was on the team that was aiding the Timothy Smith Network, a nonprofit organization in the Boston area that provides technical training and access to people in poor communities.  It was a great cause, and I was honored to help them out!

They needed an application created in Drupal that could be used for the entry of and reporting on annual reports from each of their 31 locations.  Currently, this is a laborious manual process done mostly with spreadsheets and passing information back and forth.

The content itself was significant: these annual reports featured 18 categories of information, each with potentially unlimited rows of data, and all of which needed to be hierarchically related to each other so that they could be bound to a single annual report.  For example, one category had to have the user enter several fields of specific information for each piece of computer equipment at the location: there could be dozens or hundreds of individual entries depending on the site.  I knew that Drupal was a content management system, and as such I was a bit nervous about being able to actually turn it into something that could easily be used as a data entry system... but Drupal is nothing if not diversely modded, so it wasn't out of the realm of possibility.

When I got to GiveCamp, I found that neither I nor the other person left on our team had any meaningful Drupal experience (I'd stumbled my way through posting two pages on a Drupal site once, and my colleague had used it for a few hours to put together a small personal site).  We proceeded to spend the next 24 hours rapidly attempting to learn how we could shoehorn Drupal into use as a data entry and workflow system.  During the day on Saturday, a third member joined our group and we continued our search for knowledge.  Luckily, she actually had a firm foundation in Drupal, so she was able to help us get through the initial "I have no idea what we're doing at all" phase and into thinking more about the core problem itself.

At about 6pm Saturday night, we had our major breakthrough: we figured out the right combination of modules and approach to content types that allowed us to do both the workflow and the hierarchical content with multiple nested content... but we'd only created one such form out of the 18 we needed to make, and we had none of the other infrastructure (such as routing between pages, being able to print the whole report, etc...) figured out.  We felt pretty discouraged, and I knew that we were at a critical crossroads: we either were going to have to surrender and do what we could while getting a decent nights' sleep, or we had to grind out those other 17 content types and all the related logic around getting them to work properly... and we had about 15 hours to do it.

With energy drink in hand provided by Bob, I set to work.  Thirteen sleepless hours later, all 18 content types were created and functioning, and functioning correctly within the desired workflow.  The team reassembled and my cohorts (which by that point, were reinvigorated and ready to roll) finished polishing up the rest of the missing features and adding one more super cool module that let those multiple instances of the content types be entered without having to actually navigate to a new page in order to do so.  Apparently this module is about to be rolled into the next version of Drupal's Content Creation Kit, so it was unavailable at their site except in the form of the CCK beta... so we searched online and found the pre-CCK version listed on another site and grabbed it. ;)

In the end, we got more done than I ever imagined we would have.  It's still rough around the edges: the report isn't looking great, it's devoid of any custom template, and some of the fields aren't validating as thoroughly as one would want... but it'll be a good first version for them.  I was glad to have been able to help in my own way to get us across the finish line, and I'm looking forward to the next GiveCamp!

... also, I won a Zune in the raffle at the end! =)  Woot! =)

I'm still recovering from the crazy sleepless weekend, but I think that I'll always look back on it fondly.
Tags:
 
 
Where am I: Home
I'm feeling: accomplishedaccomplished
 
 
Alex Loret de Mola
24 April 2010 @ 07:42 am
Okay, so last week I received this random message from a guy I don't know who was like "I went to your blog, but I don't like going to webpages with ads on it".  I thought, "that's odd, my blog doesn't have ads..."

... and then it happened to me just now.  Full page popover ad.

What the hell, Livejournal?

... and now I begin the search for a new location for my blog.  Forced full page popover ads on a blog *is* annoying.  They already put that side ad which was frustrating enough, but a full page ad is insane.
 
 
Alex Loret de Mola
07 February 2010 @ 01:07 am
These are fragments of the poem that I started writing when I was a sophomore in high school, but never have finished... it's the only relatively developed piece that I think I have from back then, and after a discussion with Katie earlier today I decided that I might try my hand at cleaning it up and finishing it now that more than 10 years have passed since I first had the idea.  I'm going to post this one public... I can use the input if I'm actually going to try my hand at improving and finishing it.

The Plot

The poem starts off as a recounting of actual history, and takes place in the early 12th century, when Frederick Barbarossa had attempted to depose the Catholic Pope and seat a new leader for the church.  The real Pope sent out monks in white garments across Europe to try and rally forces to his side, while he retreated to the lands known as Lombardy in northern Italy.  From this point, the fiction takes over as it follows one monk and his travel into the occupied lands of the middle east that were conquered in the first crusade.  He is welcomed by a group of Templar Knights, and to one in particular: a Paladin of the first order, according to the knighthood, a man renown for his skill in combat.

The man is particularly zealous, and agrees to leave immediately to help fight off Barbarossa.  On the trip back, the monk begins to realize through the Paladin's deeds that he in fact is not a good man: but rather, he is a merciless man who puts no value on human life and thinks himself the judge and executioner of those he comes across.  The engraving on the hilt of his sword states his belief system plainly: "God's wrath by this sword alone."

The two learn of a hidden artifact on their trip back: a breastplate said to be enchanted with the blessings of some Saint (that I've still not decided =) ).  It is said that the pious heart will render the armor impenetrable to any blade or blow.  They seek out this armor and the Paladin claims it as his own: but when he touches it, the breastplate becomes emblazoned with etchings of all the evil deeds he has done in his life.  The unarmed men he put to the sword, the houses of peasants he burned, the land he seized and the people he killed in the name of his God.  He considers it, however, to be an adornment of his many victories and achievements, and takes it as a good omen.

They return in time to join the Lombard League in the final march against Barbarossa.  On the battlefield when the Paladin's moment of glory is at hand and he charges toward Barbarossa himself with his sword in hand, his "impenetrable" armor is pierced cleanly through by an archer's arrow, rending his heart from his chest.  The Paladin falls from his horse dead, his blasphemous sword shattering as it strikes the ground.

After Barbarossa and the Pope come to a peaceful truce, Frederick has an aide retrieve the armor from the fallen Paladin as his parting prize.  Then, bringing it back into real historical events with a bit of a fictional twist, the poem was to end with Frederick's death on the way to the second crusade: drowning in a river, under the weight of his armor (which is true)... armor that felt unnaturally heavy when he fell from his horse, and which no force from him nor his men could remove in time to save him (which, of course, is my fictional addition to the fate of Barbarossa ;) ).

Anyways, that was the idea at least.  Here's

what I have so far


Long poem herein! =)Collapse )


You're still reading?

Anyways, that's as far as I ever got... I've not touched it since probably my Senior year of high school, at the latest: but I've always wanted to finish it and smooth out those rough edges.

Also, typing this (I'm fairly sure) for the first time, I'm beginning to realize that I lean on the use of words like "didst" as a meter crutch: when what I wanted to say is off by a syllable, I seem to find a way to throw a "didst" in there.  It makes me wonder if the use of that particularly antique word has always been as a crutch for bad poets like myself. =)
 
 
I'm feeling: thoughtfulthoughtful
 
 
Alex Loret de Mola
03 February 2010 @ 12:04 am
Just got back from our first meeting, and we're already seeing dividends from writing, estimating, and prioritizing user stories rather than talking about features on a whim at our meetings (as we used to, when we had meetings).

In meetings on the last game, we would sit for hours and talk about one - or perhaps two - features, and often not leave the meeting with any specific tasks to be done about them.

In the same amount of time, we were able to estimate and prioritize two dozen or so user stories, quickly discuss the benefits and concerns of the features being addressed, and commit to tasks for our first sprint.  Not too bad!

The estimating went well: we had Robin and Mike estimate art-related user stories (as Mike is primarily art, and Robin has dabbled enough in art to have a general idea of how long things take), while Robin and I estimated programming-related user stories (as both Robin and I are developers by trade and in the company).

We all adapted to the estimating process fairly well, I think aided greatly because Robin had been exposed to this method of estimating in a class that he took in college.  Our college never went into depth on Extreme Programming methodologies, and I think it would've been interesting if they had done so.  We touched on iterative vs. waterfall development in one of the classes, but in the end when Senior Project came around it was designed to be a waterfall experience.  But I digress.

Everyone walked away from the meeting with a stronger sense of purpose and a firm knowledge of what they'd committed to.  I feel emboldened by this excellent and productive initial meeting.

The task board is up and both stories and the initial tasks are written and posted... time to get started!  Well, Thursday at least for me... it's getting late, and I've got to get to bed. =)

Head to Facebook if you want to see pictures that I took... I'll try to get pictures from the actual meeting next time.
 
 
Where am I: Home
I'm feeling: happyhappy
 
 
Alex Loret de Mola
31 January 2010 @ 11:13 pm
Ugh, it's almost February!  That means March - and PAX East - is almost here!  Compared to preparations I've done in years past for PAX Prime, I feel vastly under-prepared.  I don't know if it's because PAX Prime came up so recently that I've not had time to recover, or whether March just seems more far away for some psychological reason... but I'm definitely lagging, and judging by the other community events' statuses most other pre-PAX event planning is lagging as well.  We've got to pull it together... got to get the Cookie Brigade ball rolling again, and finish planning and prepping the Magical Mystery Tour.

One thing that I think is really good is that it seems like different people are picking up the ball for East events than for the Prime events: I know that in my case, I don't think I'd have time to plan two MMTs in a single year.  Luckily MetaverseNomad is the most awesome event planner I've yet met, so she's got PAX Prime's MMT in the bag... much more handily than I currently have MMT East in the bag! =)  I've got to get on the ball, though with the site set up there won't be too much left to do I hope.

I think the Cookie Brigade needs to restart rallying, however, so I'm going to try and help out wherever I can to get that train rolling again.  Without DJ Breslin, Hypatia, and a lot of the normal "critical roles" in the Brigade coming up to PAX East, we've got to fill the gaps or this isn't going to go smoothly.

Luckily, there seems to be a new batch of cookie bakers coming through, which is really the most important part: we always seem to get by even with ad hoc planning, and even if somehow (not that I think it's likely =) ) I'm the only person distributing cookies I'll work my butt off to make it happen... but without cookies, management and distribution are meaningless.  So it is in this post that I want to salute you, the cookie bakers of PAX East 2010.  You do a great and most critical duty in a time of great adjustment to a new location and time, and an unfamiliar setting.  Thank you for the baking that you do, and I look forward to putting your cookies forth to the masses in March!

... speaking of which, did I mention it's almost March?  AAAHHHHHHH
 
 
Where am I: Home
I'm feeling: stressedstressed
 
 
Alex Loret de Mola
28 January 2010 @ 12:54 am
I figured that it would be an interesting thought experiment to elaborate more on the methodology we used previously in Medaverse, which we're now going to work hard to move away from.  WARNING: Don't try this methodology at home.  I'm illustrating this as a counterexample to show how having an organized methodology can severely improve not only efficiency and the ability to ship a product, but also improve the quality of life of everyone involved in the development lifecycle.  The methodology and (true) story described below of our experiences should be viewed as an anti-pattern to not be duplicated, but rather to be learned from.

I also want to note, for everyone mentioned here and everyone on the Gravitronix project, that this is in no way a "bashing" of anyone.  We all poured our hearts into this game: the people that burned out did so due to the intense and visceral devotion they had to making this game happen.  The constantly changing landscape and lack of methodology was due to our own communal inexperience in project management, and was not anyone's fault.  The important thing is that it was an experience that we can learn and grow from, and part of that growing process is to reflect back on it without shame so that we can improve.

We didn't consider this to be an actual methodology as we were developing it: it was just the process that naturally evolved from habits, lack of communication, and other situational scenarios... but towards the end of developing Gravitronix, Jeff had hit what we were doing on the head: he called our methodology the "Golden Bucket Brigade," which I will now elaborate on and extrapolate from our experiences.

The Bucket Brigade Methodology


** ROLES **

The core principal of the Bucket Brigade methodology is to lean most heavily on the skills of one core person (who we shall call the "Bucket Brigadier."  When that core person burns out from stress, frustration, or external life problems, another person who has been sitting on the sidelines must jump in and become the next Bucket Brigadier.  This cycle should repeat itself until the project is abandoned entirely or a shippable product is created.  If a shippable product is created, you are said to have a "Golden Bucket Brigade".

Initially, the Bucket Brigadier's responsibilities were given by a single, eternally growing design document and verbal instructions for new ideas that should be worked on, which potentially could change in priority and aim several times a day.  The longevity of a Bucket Brigadier seems to be entirely dependent on a combination of raw talent (to fix issues and implement ideas as they arose), patience (to deal with the frequently changing ideas and the interruptions they caused by being brought to attention at the moment of their conception), and willingness to sacrifice personal well being (to deal with the long hours, weekends, and sleepless nights required to attempt to fulfill the verbal and written designs).  However no amount of these in any combination can prevent the inevitable burnout of the Bucket Brigadier: they may at best prolong their tenure in the position.

The daily life as a Brigadier generally consisted of coding whatever was believed at the moment to be the most important task, having that task interrupted repeatedly for potentially higher importance tasks as they were envisioned and altered, and optionally sleep.  If you slept, you would then get up the next day and repeat that process (possibly going to your day job if you happened to have one at the time).

We also had what I can only deem as a "Brigadier's Anchor", which would be Jeff throughout the project.  Jeff made certain to pace himself: he had many sleepless nights as well as the rest of us, and overall he probably put in more hours than any two of us combined: he was able to do so by intelligently knowing when to step away from the chaos of the change that occurred during the day, and working entirely at night or at home.  He carved out a known piece of the game - the A.I. - and owned it... and owned it well.  He did a great job.  When he saw that a Brigadier was faltering, he would come by and offer resolve and a helping hand, and in doing so he resolved a great deal of bugs and created some of our most interesting features to boot (such as the ability to actually tweak so many of the settings in our engine).  He was the Anchor that kept the active Brigadier going, and without which the project also would have surely failed: and his consistent effort throughout the project really made the Bucket Brigade successful despite its glaring methodological flaws.  He made sure to pace himself, and in general was more sensible than the rest of us in terms of recognizing when to take a break.

We had several "External Workers", which were people who provided auxiliary effort: not that their effort was unimportant, but they did not have to go through the life-draining Brigadiering process that I describe in further detail below and that is the focus of this examination.  This includes our music creator (Brian), our character artists (Mike and Nicole), voice actors, and Beta testers.

Lastly, we had the "Idea Engine", which was Jesse.  In the stories that follow, the frequently changing ideas are often a source of frustration and difficulty: but it should be noted that it's not the ideas themselves (nor their source) that were the problem.  We *needed* these ideas in order to have a completed game, and someone needed to generate them.  Jesse was that idea engine.  What we needed and didn't have was an effective means with which to manage those ideas without interrupting current work in progress, which is a lesson that we were destined to learn the hard way, and which we're now taking steps to resolve.  He also served as our primary tester.  Jesse was there consistently in evenings and weekends, coming up with ideas and refining them: which is good for making a game, and which will be a point of great benefit rather than a point of frustration now that we are building a framework with which to handle the ideas being generated in an orderly manner.  Jesse also provided the lion's share of his personal savings to fund the project.

** THE HISTORY (as best I can piece it together) **

Arguably the first Bucket Brigadier on the development side was Robin, who put forth a lot of work doing initial porting of needed libraries and first steps working on the game.  Nicole created character art, and Mike inked it along with creating some additonal characters over the course of some portion of time in 2007, with some tweaking and changes of the original designs in 2008 and 2009.  However, the life of a Brigadier is nasty, brutish, and short: by probably around... late 2007?  (Early 2008?  I'm not certain of exact figures, because I wasn't physically there) Robin had understandably burned out of the role, and it passed to our promising intern Adam, and his friend Folini who became our primary sources for programming and art respectively.

Adam was second in line, and his tenure lasted for more than a full year as our Brigadier: a feat so heroic and unfathomable that if this were a different age, there would no doubt be heroic couplets written for that feat.  Adam was also the only person who ever took up the Brigadier mantle full time, having no alternative employment at the time... which makes his achievement downright astonishing.  I will be honest in saying that I don't think I could have endured even three months as a full time Brigadier: how he lasted for two years is beyond my ability to comprehend in retrospect: it wasn't until we reached the end of the project that we realized the insanity of our methodology, and it wasn't until this very week that we began to take real steps to change it.  Anyways, Adam created the engine and with his friend and skilled artist Michael Folini, they created the assets, foundational game rules, and user interface that would become Gravitronix.  They worked on countless improvements and features together, with Folini churning out art on demand and Adam coding with his vast wizardry: without them, Gravitronix would never have happened, and their contributions will never be forgotten.  Adam began to burn out of the Brigadier role shortly after I arrived in New Hampshire, probably around November of 2008... and I'm still mystified as to how a human being could last so long in such a stressful role.  I count Folini as a co-Brigadier though he was in an art role, because he worked Adam's strenuous schedule, and he had imposed on him the same constantly shifting requirements that Adam did: he experienced Brigadiering on the art side, which was a fate not shared for various reasons by our character artists, sound artists, etc.

I began to tune up, and in around January of 2009 (perhaps late December 2008) I began to bear the cross of the Brigadier.  I can only speak in depth on my personal experience as a Brigadier, so I'll give a glimpse into it as best as I can.

My primary goal as Brigadier was to make sure that all of the Lotcheck required features and requirements were implemented... which was a separate set of immense documents that detailed how we had to manually resolve and plan for a variety of scenarios that we, in honesty, had assumed up to this point that the Wii's embedded OS and framework would've handled for us.  Nope.  All of the requirements required careful manually developed features to integrate, all of them had to be to their meticulous specifications, and none of them could be ignored or forgotten.  For the next five months, I set to work on resolving each of them and verifying their correctness while continuing to fix bugs and add the (thankfully, shrinking) new features that were still being invented and modified.  I lived on the cases of an energy drink called "Unbound" which we procured from a nearby convenience store that was offering them at clearance prices because they had been discontinued... and by the time we got around to drinking them, some of the cases had already passed their expiration date.  A case of expired Unbound for 10$ provided a week's worth of life-giving sustenance, though definitely at the cost of sleep and probably long term personal health, especially when nights of 3 hour sleep became weeks of 3 hour sleep per night, which became months until I physically couldn't take it anymore.

As far as physical environment, we worked in an area that was perhaps no larger than a small bedroom, windowless and with flickering overhead lights.  We're fairly certain that it was once a closet.  I didn't mind it terribly at first, but when we moved to a room with a window around August 2009 I realized just how claustrophobic our original area was: even though our new room is physically smaller than the last one, the window makes a big difference for morale.  I don't know how Adam went a year spending his entire daylight hours in that sunless room.

One thing I had suggested when I moved here, after seeing Adam's growing (and understandable) frustration with verbalized feature requests being passed to him multiple times a day with no real sense of prioritization, was to implement some process whereby we could write down and track these ideas instead of having them interrupt actual work being done.  It would not fix our methodology, but it would at least stop the bleeding.  With Robin, we found and began to use Trac as a tool for writing down and tracking the completion of these goals: this proved to be a saving grace for all of our sanity and gave us just enough focus to start the march towards the finish line.  I don't know if we ever would have finished coming up with ideas and actually shipped the product had we not implemented that simple tracking tool: so even in our Bucket Brigade, our success depended on even some basic level of trackable task management... though it took us more than two years to finally put one in place, and even afterwords we still experienced a great deal of difficulty in prioritizing what was truly important and knowing when to stop adding features and drive for completion.

In that light and with our chosen work conditions, having the constantly changing requirements merely written down in the equivalent of a big list didn't help the burnout factor much.  I recall working 7 days a week for most of those next five months, finishing work between ~6 and 8pm and working until 4 or 5 am, only to get up and do it again the next day. (On weekends, I'd work pretty much nonstop from the moment I got off work Friday night until 4am Sunday)  At least one night every couple of weeks, I didn't sleep at all: which made me a useless zombie in my day job the next day, and for which I've always felt culpable because I knew I wasn't giving 100% to my employer on those days.  I certainly wasn't giving 100% to my wife, who hardly saw me until I finally burned out in mid-May, when we ran into what I will call the "deeply nested memory leaks of doom".

The Deeply Nested Memory Leaks of Doom was something I found out when I decided (for the fourth time in as many months) that we were "done", and I wanted to perform stress testing on the game.  I hooked up the profiler and began to run tests, and saw that our game went awry after a few games... very awry.  Weeks of inspection brought me no real wisdom other than that these memory leaks were systemic, throughout the entire engine and caused by a difficult to decipher web of various types of smart pointers, intrusive pointers, standard pointers and references, along with problems involving the way we were allocating memory.  I was in over my head, and I had no deep knowledge of the tangled event handling systems at the foundation of the engine that seemed to be having problems.  I was able to fix some memory leaks in the User Interface's tangled infrastructure, which was the one with which I had the deepest domain knowledge: but my experience with the inner workings of the event passing and lifetime of game objects themselves was its own subsystem, and one that I'd never had to delve into.  It appeared to "just work", until we realized that it was in appearance only.  I burned out hard after several fruitless and sleepless nights trying to untangle the problems, and Robin took up the cross to bring us home.

Strangely, I didn't personally realize that I was burning out until I was already there.  When we realized that Adam had burned out and that in retrospect Robin had before him, we all resolved to tell each other when we felt like we were burning out.  The problem is, I didn't realize it consciously until I started staying home instead of going over there... it probably wasn't until mid June (when I hadn't even stepped in the office for a month) before I realized that I had burned out a month ago.  I spent a lot of that month sleeping restlessly.

From May to August, Robin dove deep into the system with his more intimate knowledge of what was happening deeper in our engine and experience dealing with problems usually obfuscated from my worries such as the code behind our memory allocation.  He had been beginning to ramp up earlier in the year, beginning to pull out of his burned out state to contribute more and more... and so when I burned out, he was able to immediately fill the gap.  He rewrote our memory allocation component from scratch to utilize intelligent unit allocation (interestingly, memory allocation strategies is something that I'd never had to even think about working on windows and web apps... a whole other side of development), and added to it layer upon layer of robust reporting and debugging to add to the insufficient tools provided in the SDK for the job.  With those tools in hand, he set about painstakingly finding and hunting down each of the memory leak problems that permeated our system, and by the end of August we were back in ready to ship mode.

It would be another 3 months before we got the final okay to ship, during which time several small bugs were found by Nintendo and quickly fixed by Robin, Jeff, and sometimes me.  Jesse finished up the manual during this stage, and dealt with a lot of legal and paperwork issues such as ensuring that we secured an ESRB rating.

** CONCLUSION **

In relating these experiences above, I'm hoping that it provides an insightful glimpse into the need to embrace methodology over chaos, teamwork over individual effort, and structured and intelligent approaches to change over panic.  These are lessons I am still trying to learn, but I'm getting there slowly... and I feel that adapting the Scrum methodology has helped me to realize these fundamental problems and how crucial it is to ship them.

Each of us in our tenure as Brigadier risked our employment, our sanity, our interpersonal relationships, and even our physical well being.  It is an experience that I never want to repeat, and one that I have vowed never to repeat again: and I imagine that everyone else who went through the ordeal feel the same way.  Adopting a reasonable methodology and pacing ourselves will prevent this situation from ever occurring again.

From this experience, we continue to try and take away the following lessons:

* That it is utterly, irrevocably crucial to handle features in a managable and orderly fashion
* That sacrificing personal health for the sake of a project is ultimately self defeating
* That implementing even a minimum amount of managment is better than having none at all
* That if you don't put together a structure for visualizing your end goal, you will never reach your end goal
* That sequences of heroic individual effort can make a project happen, but not in a way that satisfies either the people working on it or the customers

It is recognizing these that we look to Scrum as a minimalist (yet sufficient) management methodology, and that we look to ourselves for the discipline to begin relying on teamwork rather than individual heroic effort.

The former is a lesson that I think in retrospect is obvious.  The latter is one that I still have to overcome personally, as individual heroic effort has been the required traits in every job I have had in my professional career up to now... and only through my current job am I realizing that that trait was not only a foolish one, but an ultimately ineffective one in comparison to teamwork.
 
 
Where am I: Home
I'm feeling: contemplativecontemplative
 
 
Alex Loret de Mola
26 January 2010 @ 11:22 pm
This past week, it seems, I've been on a Scrum/Agile evangelism kick.  Today I had a meeting with most of my fellow Medaverse comrades, and I shared with them the Scrum methodology: a vastly improved alternative to the catch-as-catch-can methodology with which we organize ourselves today (and with which, apparently, many game development studios also operate unfortunately)

I won't bore everyone with the details about Scrum again, but everyone saw the immediate and long term benefits that can be had, especially over our current "approachless" approach, which consists of people thinking of ideas and either forgetting them or interrupting someone else's work to see if that can be done first (without any real evaluation of whether said new idea should be a higher priority or not).

Scrum, for project management, is very good at:

* Allowing you to quickly prioritize and find the best time-to-value ratio for tasks to be done.
* Getting you very quick feedback on whether you're heading the right direction on a given feature, enhancement, or concept
* Forcing you to reevaluate your situation - at the least - every two weeks
* Providing a framework whereby new ideas can be addressed in an orderly manner, without interrupting current work
* Accommodating fast estimates for time that are "just good enough" to get a sense of how much can reasonably be done in a two week period
* Enforcing the need for features to be addressed in terms of benefits and testable acceptance criteria
* Encouraging communication by providing deadlines and enforcing daily meetings

For us at Medaverse especially, this will be a great boon.  The biggest challenge will likely be getting everyone to write reasonable user stories... it is a skill that takes time to develop, but it will be worth it.

I also find myself wishing that the free version of ScrumWorks had task management... the paid version is apparently $500 per user, which is rediculously high for basically being a highly specialized multiuser to-do list with reports... but compared to all the other options out there, it is the most user friendly that I've seen.

I did find some open source tools for Scrum management that I'm trying to evaluate right now:

Taskboard is extremely bare bones: it doesn't do any of the extended project management features, but it's also extremely open ended.  Basically it's a task list management application with features that make it easy to apply to Scrum.  Written in Rails, so I'm going to try and put up a host for it this week, but their online demo gave me a good impression of what it can and can't do.  It does do task management well for within a sprint, which is 90% of what I wanted such an app for anyways.

Agilio is open source, but has a paid version as well.  It looks more feature rich than Taskboard, but we'll see how it works out.  I'm downloading it even as I type. Scratch that: the most important features are all pay-to-use.

* TargetProcess isn't open source, but it's free for up to 5 users (there's exactly 5 people left in Medaverse right now, so that's convenient).  Still have to try it.

Everything else I've found so far either is a one user 30 day trial or extremely expensive and without any trial... hopefully one of the ones above will work for our purposes. =)

There is a Trac mod that supposedly does some form of Scrum management, but I can't envision any plugin to trac that would behave the way I would want for Scrum management: this plugin sounds like it merely bundles tickets into a sprint and lets you assign estimated points and due dates for them.  I'd like to be able to track it in the Scrum Whiteboard style... and I don't have time to implement my own solution.  I've got enough projects on my plate between my day job, Medaverse, and the Magical Mystery Tour.

If anyone runs into any more free or open source options, let me know!  I'm eager to try them out.
 
 
Where am I: Home
I'm feeling: happyhappy