Preparing for Dragon*Con 2011 - Supplies

In all my years of geekdom, I have attended Dragon*Con several times and likely prepared well enough for several more.  This year, I document my preparation efforts and my new intent of freeing up all the more time and money with which to enjoy the convention itself.  Enjoy the checklists below.

Things to Bring

I just returned from my grocery store trip, where I bought significantly less than in the past.  Take a look:

 

It starts with two of the most important items: deli cheeses and meats.  Combined with bread that I already own, these constitute my primary lunch of sandwiches.  Useful both on the road and at the convention, they also carry well on foot thanks to their high calorie-to-ounce ratio.  Note how I did not bring enough for the entire weekend, as I plan to socialize with my fellow con-goers over restaurant meals and the like.

 

Another vital item: vegetables.  I neglect to eat enough of these already and the convention environment - packed with stalls and vending machines - will only make it easy to consume anything else.  Therefore, I make the strategic choice and buy them now in a form best suited to easy travel and consumption.

 

My nutritional infantry arrives next: the sweet snack. Granola bars rank high in the category for portion size and portability.  I expect to carry several of these on each expedition from my hotel room.

 

Right behind the first snack comes its backup: the savory snack.  I include the cheese spread to make the experience all that more filling and satisfying.  I also splurged a bit on the quality of this item in another attempt at strategic foresight: after hours of cheaper goods, I expect to crave more "real" food like nobody's business.  These will fit the bill without breaking the bank (compared to ready-made convention food).

 

Now for the invaluable hangover cure.  Any drink heavy in electrolytes will serve to replace those lost to partying (and walking) hard.  I choose something tasty to make it much more likely that my inebriated, exhausted future self will actually drink his fill before dehydration can set it.

 

I list this as a possible supplement to the Gatorade mix.  While I can (and recommend that you) drink lots of water straight up, this easier-to-add flavor could help that process along.

 

Your feet will thank you profusely when you remember to wear foot gels; I know that mine can hurt enough already.  Anything you can do to make the walking experience more pleasant will go far towards increasing your enjoyment of the convention, especially by the end of each day.

 

Finally, I always remember the personal care products and in a very portable size. Dodging con-crud requires lots of hand-washing, so I recommend lotion for everyone.  In this case, the hand sanitizer component proves a surprise bonus.

Things to Leave at Home

 

This might sound heretical, but the energy drinks will stay at home.  Something like 5-Hour Energy might solve the size and weight issues of standard cans but, in the end, caffeine may only mask exhaustion that your body can only cure with actual sleep.  A few power naps throughout the day will save money and restore the attention I need to actually remember those awesome late-night parties.

This year marks my first one without ramen.  For years, I have tried to include both the instant and cooked versions but it always proves too bothersome and messy for what amounts to an incredibly weak meal.  One less dealer room purchase translates to more than enough sandwich fixings to replace the ramen and I'll receive a much more satisfying experience in the process.

Let me know how much use you get out of this list, which I will update as the convention experience tests the mettle of my plan.  In the meantime, enjoy Dragon*Con.

On John's Anealio's Cover of Transformers

Has your nostalgia ever surprised you? How about twice for the same subject of early fascination? I had that exact experience when I came across John Anealio's cover of the Transformers theme. My formative years saw more than a few Saturday mornings spent watching that 3D cube bounce from Autobot to Deception logo while biting my lip in anticipation of what challenge would befall my beloved giant robots next. Would the Deceptions finally win? Would the Dinobots managed to cause less destruction than they tried to prevent? Would my little brother ask to change the channel again, just because we had a rerun on? I can still recall my lazy self reaching across the beige carpet of the living room floor with my tiny toe to push the Volume Up button before the Zoom-crank-boom-zoom of the scene change could hit. All of that recollection framed the adult experiences that would follow.

You will almost certainly laugh at this admission but bear with me: I nearly cried with joy upon first seeing Optimus Prime rise up in the first Bay film. It makes me a little choked up just to think about it now. My ongoing fascination with 3D animation - no doubt spurred on by that rotating cube way back when and explicitly encouraged by Beast Wars after that - prepared me for an experience that would both impact me with the full weight of one long-entertained life path and relay all manner of aspiration behind Optimus's first words. That I have thus far resisted seeing the sequels despite my love of the subject shares as much of its cause with my 3D animation career path detour as it does with my low expectations for these particular films. They both failed for a lack of focus, commitment, and follow-through.Upon reflection, seeing a red and blue dream of mine up on the screen likely caused me some pain in addition to the joy because my mouse-grasping hand had contributed nothing to the awesome sight.

How had I ended up up paying for the movie ticket from my uncreative office web-work payroll and nothing more? I can still remember the essentials of navigation and manipulation in Blender - my fingers reach for the G and X keys even as I type this - but I have not actually hit the F12 key and performed a real render in a year, perhaps more. Something clearly went wrong between ungraduate classes and now. When I dwell on this frustation, I get the same kind of feeling that arrived after I looked down on an office desk bestrewn with new Transformers toys: echoes of enjoyment but even more awareness of how well the plastic of the one grey Autobot sports car blends right into the neutral colors of the surface, almost disappearing into it entirely. Even the bright colors of the War for Cybertron Optimus can't quite contrast with enough energy.

You probably want to know how this relates back to John's song and now I can tell you.  The Autobots waged their war for millions of years. You can draw parallels to evolutionary timescales in place of this fiction but the story still puts a face to that same kind of fight that we ourselves continue to carry against the evils of the real world and entropy itself. John reminded me of this when he brought the underlying melancholy of the song up to the surface. Did you ever put serious thought to how many Transformers died in the original animated film? That film injected quite a bit of morbid realization into my younger self. Busyness consistently submerged that concern right up until the song presented a safe harbor for this recognition. I can finally see the extent of the life-crushing storm just beyond the high walls of the cove when it pulls me out of the moment for just one lyrical minute. Do I dare leave for the real life dangers of that ocean and risk a dashing against the rocks or do I sink back down into calm, frigid waters and the inevitable - if much more gradual - drowning in the darkness below?  I can no longer hide from that question.

The choice might reek of morbidity but only at first. Amid my pause for reflection, my phone's music player loops back around to the start of John's song and the refrain hits me with his interpretation of its earnest enthusiasm again. Transformers. More than meets the eye. That part of their story suddenly chokes me up more than I ever expected. This same quality applies to all of us. Hours of listening to The Functional Nerds podcast tells me how John himself could (and does) testify to the transformative power of persistent hard work. It might take more than a few seconds to us to transform, unlike the Autobots, but we don't need millions of dollars in special effects, either. It can start today.

This very post serves as one such example. It may have taken years of gradually-refined focus to set the stage for this most recent change but the new-found emotional investment in and dedication to its topic, borne out of John's cover, witnessed the doubling of my average writing rate. I suppose that a few minutes spent on pure reframing compares well enough to a fictional robot's impnossibly fast conversion when, instead of changing me into a car, it helps change my entire life. I look forward to hearing how you do the same.

Have you had that same memory-flood, deep river-cutting experience with another cover of a song? Have you thought about how much we have gained as a species and as a culture because people more talented than ourselves remain free to reinterpret songs for their (and our) generation, regardless of how big of a company owns the original? Have you just decided on a favorite song of your own that you can't wait but remix or remaster in your studio or on your lowly iPad? Don't wait, go and pound out some notes now while I do the same!

Skeptic's Paintbrush - Episode 1

A bit belated but enjoy the first episode of my new twice-weekly pod-journal, the Skeptic's Paintbrush:

skeptics_paintbrush_15Jan11.ogg

skeptics_paintbrush_15Jan11.mp3

Red-Green-Refactor in Real Life, part 1

I would never have achieved my initial progress with Ruby'Ai without lessons from The RSpec Book. Only the direction and focus provided by the Behavior-Driven Development (BDD) and Test-Driven Development (TDD) methodologies enabled me to work through the ambiguities of a new project like this, but some of the book's lessons had to wait until this month's alpha-build stage before taking properly.

Just last night, I finally got a handle on the two-stage Red-Green-Refactor (RGR) process enabled by Cucumber, which lets me share a real-life example of the process with all of you. As context, Ruby'Ai uses a domain-specific language (DSL) to describe visual novels (playable here and implemented here). For example (all source code: rgr_part_1.tar.gz, rgr_part_1.zip):

scripts/characters.rb
add_character :sam, "Samantha"
add_character :courtney, "Courtney"
scripts/scenes.rb
add_scene :first_day_of_class do
show tired_sam
narrate "The class bell rings, immediately lost underneath the coordinated shuffling of papers and the shifting of chairs."
sam "sighs at the sight of clock arms that signal an imminent lunch before leaning back in her chair to address the girl standing beside her."
show content_courtney
grateful_sam "You saved my life, really.  It's Courtney, right?"
pleased_courtney "Don't worry about it, Sam, okay?  I printed off extras for everybody, just in case."
end

I had already implemented some of the basics, like add_character and add_scene, leaving some unexplained code intermingled with the important parts, but these examples will focus on where the RGR process proper started with the description of scene contents. From an extract of the BDD document:

features/scenes.feature
Feature:
In order to have an engaging story
As a visual novel writer
I want to have scenes in my novel
 Scenario: minimal scene
 Given a character labeled :sam and named "Samantha"
 And a scene with following contents:
 """
 sam says "Hello!"
  smiling_sam "waves enthusiastically."
 """
 Then the scene should have the following steps:
 | condition | character | behavior  | content                 |
 | default   | sam       | statement | Hello!                  |
 | smiling   | sam       | action    | waves enthusiastically  | 

To explain the Then step: Ruby'Ai only provides an engine by which plugins export playable games, such as the Javascript-based prototype, so Ruby'Ai stores convertible steps for each part of the novel. These steps describe character speech, actions, narration, changes of location, and other events in a scene, one inseparable section of story and a close analogue to the screenplay equivalent. The condition describes the state of the character as they perform the action, by which the game chooses an image for the character (e.g. sam_smiling.png); the character names the involved character; the behavior describes the nature of the event (which may affect formatting); finally, the content describes what text the player will see associated with the rest of the step.

My major realization manifested here, the point right after writing the above feature example, when I remembered to take the development process directly to the lower-level Rspec stage. Having fallen in love with Cucumber early in the prototyping stage, I had come to rely on it almost exclusively and ended up writing pages of verbose feature lists. These grew unmanageable as they tried to describe every facet of the DSL and export process. The tool eventually interfered with my ability to further develop and debug the engine once I started spending as much time hunting through the output for the error messages as I spent addressing them. Almost all of this example code should have gone into the Rspec test fixtures, it turned out, but this next example from the alpha demonstrates a more proportional usage of these tools. It is a long example, but many of the parts overlap and we will break these parts down piece-by-piece in the second post of this series. Additional explanation available at the end.

spec/scene_spec.rb
require 'rspec/expectations'
require 'novel'

describe Scene do
before(:each) do
@novel = Novel.new
@novel.evaluate_character_script do
add_character :sam, "Samantha"
end
@novel.add_scene :at_the_park
end

it "should let a character say something explicitly" do
@novel.evaluate_scene_script :at_the_park do
sam says "So what do we do now?"
end
step = @novel.scenes[:at_the_park].steps.first
step.should_not == nil
step.target.should == @novel.characters[:sam]
step.behavior_type.should == :statement
step.content.should == "So what do we do now?"
end

it "should let a character do something explicitly" do
@novel.evaluate_scene_script :at_the_park do
sam thus "throws a frisbee."
end
step = @novel.scenes[:at_the_park].steps.first
step.should_not == nil
step.target.should == @novel.characters[:sam]
step.behavior_type.should == :action
step.content.should == "throws a frisbee."
end

it "should recognize conditions added to characters" do
@novel.evaluate_scene_script :at_the_park do
excited_sam "catches the frisbee as it's thrown back!"
end
step = @novel.scenes[:at_the_park].steps.first
step.should_not == nil
step.target.should == @novel.characters[:sam]
step.behavior_type.should == :action
step.content.should == "catches the frisbee as it's thrown back!"
step.condition.should == :excited
end
end

describe SceneBuilder do
before(:each) do
@character = Character.new :label => :sam, :name => "Samantha"
@scene = Scene.new
@builder = SceneBuilder.new :characters => { :sam => @character },
:scene => @scene
end

it "should mark explicitly stated content as such" do
statement = @builder.says "I like it here, it's so cozy."
statement.behavior_type.should == :statement
end

it "should mark explicit action content as such" do
statement = @builder.thus "settled into the couch."
statement.behavior_type.should == :action
end

it "should interpret behavior types implicitly" do
@builder.parse_character_behavior @character, "Can I stay a bit longer?"
@builder.scene.steps[0].behavior_type.should == :statement

@builder.parse_character_behavior @character, "pleads convincingly."
@builder.scene.steps[1].behavior_type.should == :action
end
end

SceneBuilder might appear redundant but it provides a clear delineation between the Scene - which only needs to store information about part of the novel - and the methods by which that information gets into the novel. For comparison, we do not need to know anything about the workings of a farm upon which an apple is grown to enjoy it and including farming instructions pasted all over the apple would only make it harder to eat. This approach may also facilitate a clearer implementation of the DSL code down the road.

iPhone Project Timeline (WIP)

I know better than to trust my own organic memory with this task, so here is an index of what has gone into the iPhone programming project thus far:

Stage One: Childish indiscretion

1. iPhone programming contest announced.
   
2. Ordered iPhone and Cocoa development books from The Pragmatic Programmers. Read a bit of the first in my spare time.
   
3. Contest start time arrived. Started reading in earnest, beginning on the basic tutorials once the development Mac was set up in the office (all while leaving time for my daily duties).
4. Brainstormed various project ideas.

Stage Two: Youthful vigor exerted and discovering the world at large

1. Researched the implementation details of said ideas, filtering out those which the technology and contest deadline made impractical.
2. Staunchly decided to go with a promising but time-pragmatic idea, expressly avoiding any thoughts of trying other projects in order to avoid a "paralysis of choice" situation.
3. Prepared multiple paper-based mockups of the layout and received coworker feedback on the now-visible idea.
4. Began coding a mockup in earnest.
5. Worked through the setup details necessary to load the app onto the developer iPhone hardware itself (as opposed to just the simulator).
6. Developed rudimentary implementations of the front-end GUI and online data-loading components, resulting in a presentable prototype.
7. With said prototype in hand, began demonstrating it eagerly to others and started soliciting coworkers as developer teammates while expanding and refactoring the prototype.

Stage Three: The college years

1. Met with a handful of coworkers over coffee, making a point of only inviting as many as I could hope to handle so as to avoid a "Too many cooks" scenario. Discovered just how nebulous of a project plan I had.
2. Assigned a high-level project component to each teammate, divided by functionality and with the hopes of avoiding unnecessary overlap (and the cross-coding that would result). The specific groupings: Backend GUI, Web-based data input, and Web-based data output.
3. Discovered the primary, extra-narrow purpose for the app, one with more personal value.
4. Worked out per-team member lists of actionable items. The early items represent comprehensible milestones that, with hope, elicit distinct actions on their owners' parts. Expressed the intent to further subdivide these actions as necessary.
5. Stayed on-hand one evening in case the Backend GUI developer needed any help with the initial iPhone tutorials. (He needed no such help, though, and knocked it right out.)
6. Wrote this blog post.

I'll add to this chronology in subsequent posts as the project progresses, especially as the contest deadline approaches.