What Would You Say Ya Do Here?

Since starting at Addisolv I've received a lot of questions that go something like this:

So What Do You Do at "Addisolv"?

Or

So What Does Addisolv Do?

A cynical answer might be...

Microsoft Web Mercenary

I produce web applications using Microsoft .Net, in popular CMS platforms such as Umbraco, Sitecore, and Kentico. In the day-to-day, I will be working to prepare the CMS for customer content, then implementing data integration with JavaScript, C#, and SQL.

But doesn't lack all romance?

Undoubtedly, parts of the readership stopped in the last paragraph. Either because their Python-loving retinas were seared by the word "Microsoft" or because the banal facts of my job just don't express what I do in a way that makes them care.  An alternative way to say what I do might be...

I Help Businesses Live on the Web

I apply my expertise to produce an interactive, living experience for people, helping spread a business' message across the web. In the loftiest of terms, Addisolv tries to turn one person's sales pitch into another person's adventure.

Maybe my words aren't perfectly descriptive (yet), but it hopefully captures a universal point for all companies: your efforts are often boring, but the aspiration of those efforts should inspire. A business should be more than a legal fence around a pile of money, both the ones you work for and the one that you're in. Start speaking like it.

Welcome Citizen!

I've migrated content from my old Posterous space into this site, with the hopes of expanding it into a proper compendium on myself. The digital age knows no limits on vanity, but it does have technical limits on SEO, so after much consideration I figured it was time to declare an independent republic for myself. Welcome citizen!

Every New Beginning

I am very excited to announce I am joining the newly formed US branch of Addisolv right here in Richland, WA. I will be ending my time at PNNL, which had done me the infinite favor of first challenging me in web development, in January and starting at Addisolv in February. I will still be in Richland and still working in web devlelopment; still writing code, but also writing a new chapter in my career.

This would not have been possible without the serendipity engine created by DocType Society. It was at November's meeting that I first I met Kenn Petersen, a multi-talented Dane who is both CEO at CleanVantage as well as working as the US mastermind for Addisolv, who was hoping Richland had some talented .Net developers willing to make the leap to build something new. Happily, it seems I fit the bill.

Of course, it is the responsibility of any early employee to realize something: I'm the worst employee my company will hopefully ever have. I first read about this idea in the Valve company handbook and it goes something like this: when interviewing someone, you must search for someone so skilled that you not only fear they are better than you, but consider it a prerequisite for taking the job. As a pyramid of superior folks takes off above you, you come to realize: I'm the worst we've ever had, Fantastic!

I'd like to thank my family for supporting me in this new venture, my wife and oldest daughter are very excited (younger daughters still perturbed as usual that Daddy is not a useless layabout able to play all day). I would also like to thank my friends in the Binary Basin who inspired me to think bigger, embrace change, and realize "solid retirement package" is not a synonym for "happiness".

Holiday Hackathon 2012

For the second year in a row, DocType Society held a Hackathon, this year at Room to Think and sponsored by &yet. We had a lot of people show up, join teams, plus a lot more people just drop-in to say 'hi'. It was 24 hours of furious coding, swift design, and good times.

Scantastic!

I was lucky enough to join forces with Bruce Schmoetzer, Shenoa Lawrence, and Jon Hjelle to prototype an iPad app for Passbook-enabled self-checkout Shenoa dubbed "Scantastic". Bruce had mentioned the idea well beforehand during the Tri-Cities iPhone/iPad App Developer meetups. Source code for the prototype is available on Github.

Passbook (available even on Android) offers a lot of possibilities as an electronic replacement for membership cards, but lots of organizations have old laser scanners that can't scan a mobile phone. An iPad is a perfect device for capturing barcodes on another device, and could be used for self-checkout for any item with a barcode. Thus, we built a simple prototype app that acts like a library on an iPad: tracking an inventory, its members, and items they have checked out.

The team was able to make the app, incorporating a friendly and beautiful design from Shenoa, and demonstrate a simple process for checkout using books on hand at Room to Think. We are hopeful it could be used as a proof of concept and a great simple integration with the ZBar barcode reader library for iOS.

D &! D

Hats off to Doug Waltman, who stayed awake all 24 hours through the power of energy drinks, and Joseph Weakley who prototyped a gamified client for the &! task management app.

Taking their design cues from D&D (or Everquest or WoW, etc), it turned tasks into deadly weapons that were used to "fight" the project like a mythic monster. As you shipped your tasks, you built up power points to spend on your class abilities, such as healing your fellow teammates or launching a magical strike against the beastly assignment.

I can't help but think there really is a market for gamified project management. Gaming is no longer a fringe activity just for the young, and there are voices crying out that games make the world a better place. Maybe this prototype will become something great.

Who's the Ugliest of Them All?

The hackathon culminated with the DocType Society & Room to Think Ugly Sweater Holiday Party, where I took the grand prize for ugliest sweater. All credit for the victory should go to my wife, who handcrafted the monstrosity. Photo evidence here (that's me standing in the back). We played Cards Against Humanity, a game for terrible people; perhaps more terrible than we.

Hackathon 2013?

Thanks again to Room to Think for hosting us and &yet for sponsoring. Thank you very much for everyone who attended. I've learned you're all energetic and talented people (and at the party I learned you're all terrible people). After a great experience, I'm hoping for a third year!

TriConf 2012

Woke up this morning after TriConf, a Tri-Cities local convention on technology, design, and entrepreneurship, feeling blissfully drained.  Two nights and one day of meeting new people, learning new things, and sharing my own experience takes a lot, but what's gone is replaced with a renewed sense of wonder and drive.

The Promiseland

A big theme of TriConf, articulated succinctly by Nick Napoli, was "finding my people". Most came expecting to learn a few tips to apply in their work; however, the refrain of Cheryl's final keynote last night captured the true aspiration for every TriConfidant's attendance: "Living in the place you belong, with the people you love, doing the work that's yours, on purpose."

Instead of approaching connections like the chore of "networking", we've been successful focusing on passion. In a short amount of time, spoken passion can become shared passion.  Amongst the many technical lessons of the last three days, the universal message is realizing that in the life of a creative worker, there is no line between professional and personal, our circle of colleagues is indistinguishable from our circle of friends, and a legacy cannot be left by accident.

Great Talks

The main activity of TriConf is getting volunteers to stand up and share their knowledge. The DocType Society Vimeo channel will soon be filled to the brim with the talks for the whole conference. There is a spontoneity in the barcamp format used by TriConf that forces speakers to rely only on what they bring in the door the first day: their well-honed skills and most honest values. 

If you're trying to navigate the Vimeo channel, I recomend: the stellar keynotes from Paul Carlisle, Amanda Divine, Anne, Carl Cadwell, and Keith Nerdin.  Cheryl Broetje was revelatory, serendipitously tying together the unversal message of TriConf. Fritzy's futurism talk and Keith's talk on hitchiking & entrpreneurship were downright hilarious. How Can We Make DocType Society Better, a discussion mediated by John Higley, also contains some great wisdom that coalesced a lot of the best observations on the nature of the conference and community.

Thank you Adam Brault for being a mighty MC and starting it all, &yet for solving the logistics of a great event, and thank you everyone who came for continuing the tradition. Thanks Adam Baldwin for wrangling all those gigabytes of video to prove it happened.

Object-Oriented Design Patterns

Thanks to Doug Waltman's resistance to reading the gang of four book on the subject, I had the honor of being one of the first three speakers on Friday night, speaking on the topic of Object-Oriented Design Patterns.  If you would like the presentation notes, get them on Prezi.  If you missed the talk, please watch it on Vimeo.

The Technology of Culture

Saturday I had two opportunities to share a concept I first encountered in the book Snow Crash, that the social practices of a civilization are themselves a form of technology.  This means TriConf is not just about innovation, it is an innovation.

Culture is the operating system of society, software running on the neurological cicruity of people sharing a common bond. Like code, it can be copied at will, improved over time, and must struggle against obselescence. Building a community means forking an open source product and installing it on enough hardware. DocType Society and TriConf are each just singular implementations.  The reusable and self-replicating kernel is sharing passion and making connections.

Now to just wait 364 more days until the next innovation.

Ten Years Ago Today

Ten years ago in the lonely town of Pullman, WA, I was sitting down in a dorm room wondering what to do with the first Friday of my college career.  I didn't know it during that forgetable evening, but I had taken my first big step down the road I continue to this day: code.  I had grown up with computers, watched the rise of the consumer internet, and knew software would make a worthwhile profession, but one decade later I'm still a student.

My first programming class at Washington State University jumped in at C with the most basic (and famous) of programs...

#include <stdio.h>
 
int main(void)
{
    printf("hello, world\n");
    return 0;
}

Aside from introducing me to curly-braces and semi-colons, this immediately gave me my first insight on programmers: we are not composers.  Instead of arranging every note in the symphony, programming is more like conducting.  We direct an existing orchestra of seasoned musicians, providing minimal reinterpretation of an existing body of work.  While sometimes we invent new melodies, largely we are remix artists with a very large sample library.

The symetrical moment to this in my life when I was ten years old and something special happened: my family bought our first computer.  It was an Apple PowerPC, with a 75mhz processor and a massive 1 gigabyte hard drive.  It's easily outclassed by the first smartphone I owned, but for the time, it gave me the internet and a digital landscape that could be reshaped.  In the form of the classic 2D space game Escape Velocity, I had my first experience modifying how a program behaved on a computer through its publicly available mod tools.

The discovery of meddling with its behavior, the anticipation of it loading (and sometimes crashing), and the triumph of it working.  At the time I was exploiting a game for total sprite-based galactic domination, now I experience that cycle everyday.  The thousands of hours playing EV, and the respective Star Wars, Star Trek, Babylon 5, and myriad other amateur made expansions taught me that anyone can build something special and trained me to have the willpower to attain it.  Recently, Jane McGonigal has been burning up the internet with insights along these lines, but I serendipitously discovered it in 1997.

Since sitting down in Diane Law's introduction to programming class, I've written apps in so many languages beyond C and harnessed so many more capabilities than "printf:.  Reflecting on the languages, frameworks, and lines of code that have passed through my eyes since then, I've found the rate of learning has not diminished since college.  The programmers I admire most acknowledge Socrates' insight that knowledge most often shines a light on our own ignorance and that insight is most often fleeting and incomplete.  On this equally forgettable Friday night, I will have had another week of new beginnings, another week of learning, and yet so many more to go.

BNR Day 7: Just Hoping for Clear Skies

It’s the end of the last full day at the ranch. The day was another great one: more iOS, more Cocoa Touch, a game of mini-golf, and southern style ribs with a whole chicken breast for garnish.  I’ve pre-packed everything I can in my little cabin, making it feel even more lonely.  Tomorrow I fly home and my time at Big Nerd Ranch comes to an end.  Today felt like everyone definitely had turned a corner and gone from falling to flying, pulling up to see nothing but clear skies ahead.

Today we covered some deeper subjects such as low-level touch events and layers, the underlying architecture that Cocoa Touch uses for drawing and animation.  These are areas that have analogous .Net Windows Applications capabilities, such as System.Drawing to cover manipulation down to the pixel; however, their lack of analogs in ASP.Net means this area might be a big challenge for someone without any previous applications experience.  It’s hard to be a programmer, but areas like this really lay bare how diverse a toolset we’ve forged and how different the skillsets between the wielders can be.

When extolling the boundless possibilities of the web, we often celebrate the (sometimes annoyingly) balkanized technology can be in building a web app.  Having three client-size languages, HTML, CSS, and JavaScript, plus a server-side language to realize a design, is a lot of effort in the eyes of most applications programmers.  They usually need only one language and one framework to make everything happen; in the case of iOS with the optional help of an interface builder to help them with visual content.

I recall missing the simplicity of homogeneous code when coming to web from applications.  For all of the conflicting perspective I might have from previous experience, it feels good to be back in the mode of only deciding where to put my Objective-C code rather than puzzling over exactly what kind of code to write.  Oddly enough, .Net WebForms was written as a way to ease application programmers into the web, but I really always felt it was such a leaky abstraction that fails at that task.

For all the waffling criticism I have placed on Objective-C and Cocoa Touch framework this week, I would need a month to share all my thoughts on the quality of the ASP.Net framework.  In insulating the programmer from the real web, but not being on a platform where its core architecture is seamlessly applicable, ASP.Net actually seems the worst of both worlds.  It controls the HTML and styles for a page (badly), while supplying an event model that can just as easily hurt as help you, was designed from the ground up without JavaScript in mind (to have some changes bolted on later), and continues to persist in my daily repertoire despite far superior alternatives (Microsoft can do web services and MVC too everybody).

I accept that web programming is about mastering a diverse and specialized palette of skills, applying each with consideration like a painting.  I accept that applications programming is about using a discerning eye to mold something from a single substance like a clay sculpture.  Both have offered me challenge and reward.  Unfortunately, ASP.Net is about slathering clay on a canvas and calling it art.

I’ve highlighted many issues with coming to Objective-C from ASP.Net over the week.  I’ve tried to draw a line on a map around each mountain I’ve seen, but the bitter truth just might be that ASP.Net is a bad place to start from for any destination.  It strives to cloud up your perception of what’s really going on to the point where you can’t find your bearings to fly out.

BNR Day 6: Hitting The Wall

As we go into the last full day of class tomorrow, and after 16 hours of learning a day for the last week, everyone’s reserves are running low.  We’ve been let into Willy Wonka’s factory and are so full of wonder and chocolate that we’re getting type 2 diabetes.  Everyone’s struggling for their own way to overcome, because we all know great things are on the far side of adversity.

The last couple days have been drilling through different areas of the Cocoa Touch framework, including core MVC app development patterns, the camera, and writing to the file-system.  Acceptance of Objective-C has set in at this point.  Scott rightfully pointed out more than once that the minimal additional syntax from C lends great learnability. 

At this point, the framework learning is more about picking up on the writing style of the author.  Just as a novelist enjoys relying on particular tropes and themes, API writers have to make similar commitments to design patterns; otherwise, they lose the audience.  After a certain point, programmer’s true skill is not parsing code so much as documentation. 

As far as framework difficult, if an ASP.Net programmer can overcome the language, the core MVC concept is the biggest challenge.  They will likely have a perception of “extra work” concerning management of a controller class, view class, and often the nib/xib file for each part of the screen where once they just had a code-behind (or control) class and the aspx file.  However, the advantages in cleaner design and necessities of superior memory management will make even the most skeptical programmer embrace it.  With the added bonus it will make learning the modern MVC.Net architecture an absolute breeze.

Learning a framework is less like memorizing geography and more like anthropological analysis of the bygone culture that once occupied a single region.  Situated in their particular time and place, what kind of lives did they lead and how did they decide how to lead them?  It’s not about climbing to the top of an ancient ruin to grasp understanding at the top with finality; it’s about finding the story each stone can add to a history to shape your present.

BNR Day 4: Whale Watching

One camper (or is it rancher?) observed today that life at the ranch has settled into a routine like a cruise ship: sitting, eating, sightseeing exotic places and code, repeat.  For the rest of the week, the class will transition from learning Objective-C to harnessing its unique features to build iOS applications.  We’ll be following the Big Nerd Ranch iOS Programming book under the tutelage of Scott Ritchie, former NeXT Step and Apple employee, now acting as our captain to steer this cruise ship out to the ocean of iPhone and iPad app development.

The UIKit framework in iOS utilizes a Model-View-Controller architecture for handling data, drawing that data, and receiving events from user input.  Today’s topics highlighted the lifecycle of the controller and views, then the myriad of techniques that exist to hook up between the View and the Controller.  There are similarities for the adventurous .Net programmer struggling for a foothold.

Both frameworks implement a method-based callback method for receiving simple UI events.  In .Net it’s referred to as the Events & Delegates system.  The analogous pattern in Objective-C is called Target-Action.  The controller passes to the caller a receiver object and the selector (method name and a description of its arguments in a compact syntax) of the desired method to be called on event firing.  The XCode interface builder can be used to make these connections, but here is equivalent code performing this in each language:

// C#
firingObject
.eventName += receivingObject.methodNameOnReceiver;

// Objective-C
[firingObject addTarget:receivingObject action:@selector(methodNameOnReceiver:) forControlEvents:EventName];

 In addition, Objective-C has a special implementation of the observer OO design pattern it calls “Delegation”.  By implementing a protocol (Interface in C#) in the controller and passing a reference to the calling object, a set of instance methods can be called on an object; this pattern is utilized by complex features like GPS.

ASP.Net practitioners should be familiar with the life-cycle of a code-behind class.  When receiving a request, the page will go through being created, loaded with ViewState, and custom control events, with numerous events (or overridden instance methods) fired at each step in the process.  These events run in sequence for each initial load and postback of an .aspx page. 

In the case of an iOS app, there is no constant cycle of destruction during normal operation.  The creation process happens only once then the event-loop takes over.  There is a partial destruction and restoration process when an app moves from the foreground to background in the system, but we’ve yet to cover that.

When conceptualizing an iOS controller and view’s lifecycle versus an ASP.Net page, there are analogous components and steps.  The Controller in UIKit is a lot like the code-behind class in ASP.Net.  Where .Net uses the .designer.cs (or .designer.vb) file to describe the fields of a class in code, XCode utilizes a .xib file, which is an XML-based description of the interface and its connections to fields and instance methods in the owning controller class.  Here are the generic steps with corresponding actions in each framework:

UI Lifecycle

ASP.Net Code-Behind

UIKit Controller

Object and direct children created, but system doesn’t have full context yet

Constructor  in C#

new in VB.Net

 

Init (OnInit method)

init instance method

Runtime steps in to load UI, providing crucial context for event coordination later

ViewState loaded by runtime (NOTE: Member controls are created during construction)

.xib file loaded, instantiating the View and readying its connections make in Interface Builder.

With full context restored, instance methods can manipulate the object and its children, performing additional setup

Load (OnLoad method)

viewDidLoad

System enters event-loop, receiving user events and routing them to listeners setup during creation

 

Events & Delegates

 

Methods previously passed as event handlers during load in C#

 

Instance methods marked with “handles” and an event list in VB.Net

Instance methods called through connection in the .xib file using the Target-Action pattern.

 

Instance methods called by implementing a Protocol and assigning self as a Delegate (Observer Pattern)

This comparison hopefully throws a life-ring to any struggling .Net programmers who find themselves in the deep ocean of Objective-C and UIKit.  It is important to remember that each framework has a disparate set of features with some overlap.  Look for similarity, but expect and appreciate differences.  Even atop this cruise ship, where we’re sometimes only getting a high-level view through example, we’re always looking to sort out the whales from the Loch Ness Monster.

BNR Day 3: NSLog(@"Oh Boy");

After two days on Objective-C, under the mentorship of Step Christopher, I'm feeling confident it's going to be a good week.  It's always possible to criticize the design of a language, but overall, learning it is about just wrapping your head around a new set of words and relating it back to what you already know.  I am confident life under the hood with iOS will be pleasant most of the time, but it's easy to imagine things getting out of hand with Objective-C in ways I've yet to find in other languages.

Ultimately, Objective-C has to solve the same handful of problems that other object-oriented language, building a machine with the same capabilities, just different components.  Breaking down the parlance a bit, I arrived at this mapping of high-level features between C++, C#, and Objective-C:

C++ C# Objective-C
Class Class Class (@Interface + @Implementation)
Abstract Class + Multiple Inheritance Interface Protocol
- Extension Category
Function Object (Functer) Lambda (Delegates if you don't need variable closure) Block

Of course, the mapping isn't strictly one-to-one.  In particular, the C++ technique for inheriting a set of abstract classes to fulfill a behavior contract is more akin to a design pattern.  Both C# and Objective-C allow only single-inheritance plus conforming to a contract, making their implementations more of a language feature rather than programmer convention.

By far the thing I had the most sudden programmer fight-or-flight reaction to today was the Block syntax in Objective-C. True to the theme of the language, the syntax is very explicit, but also very chaotic when trying to read.  For an example, try this article on Blocks from Big Nerd Ranch, I'll spare you an out-of-context sample here; I've already betrayed my bias.

Unlike in the class method declaration, this does follow a more C-like function syntax.  The class method looks like it is a series of C-style casts wrapping an identifier, with colons helping delimit arguments. As a newcomer, the more C-like Block syntax certainly helps me learn, but at first blush it seems inconsistent with their established syntax for their other form of dynamic language function.

Additionally, this is the first time I've encountered closure being implemented in a language with manual memory management, which leaves me awestruck by the possible pitfalls it opens.  Not only can you wrap up a read-only variable in a closure, they also give you facility for your blocks to opt-in on writing to variables.  This means the ball of chaotic characters on the screen, ultimately living in a single variable, is dynamic behavior AND its own graph of objects in memory that needs managed.  As a neophyte, it's reignited the paranoia I once only reserved for pointers-to-pointers-to-pointers in C++.

BNR Day 2: Genres of Code & Objective-C

The first two days of class at the Big Nerd Ranch are centering around teaching the Objective-C language itself, using the curriculum captured in their book on Objective-C Programming.  Today was an overview of the C language, with an initial dive into the object-oriented extensions of the language.  Even with a background in OO languages, I was a little taken aback by the syntax.  After a day of exercises and guidance from our instructor Step Christopher, I wasn’t feeling so much like a hair metal band at a polka festival.

The stand out issue with Objective-C when first reading about it was the syntax for calling class and instance methods; it was all of these square brackets [[[wrapping names] in:incoherent] patterns].  Having grown up on C++, then transitioning to C# in my current job, I had a pretty fixed concept on how behavior belonging to objects should be called.  For instance methods, something like:

objectName->methodName(arg1, arg2); // C++, w/ pointer
objectName.methodName(arg1, arg2);  // C# and C++

Or for class methods, something like:

ClassName::staticMethodName(arg1, arg2); // C++
ClassName.staticMethodName(arg1, arg2); // C#

Java, JavaScript, and even VB.Net had done me the courtesy to unify around this language pattern, but Objective-C doesn't do it this way.  The historical context of Objective-C, with C++ being distant illegitimate cousin rather than a direct progenitor like those other languages, meant the designers have arrived a different solution for calling into classes that was very much influenced by Smalltalk; a language barely whispered in one class in college, then immediately discarded for more exaltation of C++ and Java, which picked up their OO styling from Simula.  What’s more, they wanted to realize dynamic-typing behaviors in the language above-and-beyond polymorphism in C++.  Here’s an example of Objective-C:

[objectName methodName]   // Instance Method
[objectName methodName: arg1 arg2Id:arg2] // Instance with Arguments
[ClassName methodName]  // Class Method
[ClassName methodName: arg1 arg2Id: arg2] // Class with Arguments

Losing my parentheses is quite a shock, magnified by having to know the identifiers of the receiving method’s arguments, it made a lot of the Apple Developer Doc examples pretty opaque at first. The key about the square bracket syntax is understanding that they are a core feature of dynamic object behavior in Objective-C, for both polymorphism and duck-typing-like behavior.  Any object or class can be passed in on the left, meaning the method call (or “message”) is not tied to the type of the receiver at compile-time and is entirely runtime-dependent.  Beyond just virtual methods in C++ & Co, this means disparate objects of disparate classes could stand-in for each other if they simply have matching method prototypes.

The other oddity is the arguments to the method.  Arguments come after the method name, separated by a colon.  The first argument to any function can be received implicitly, with subsequent arguments received in the order they are declared by the implementing function and marked by the names of the identifiers.  It’s kind of like if every method in .Net required you to use the “:=” operator (which normally enables out-of-order argument passing) for every argument, except the first one, and it hard to be in the order declared by the receiver.

The recurring theme in Objective-C of “same idea, completely different implementation” looks like it will be following tomorrow.  The concepts of classes are pretty straightforward the same, but as a practicing C# programmer, the words Interface, Protocol, and Extension are about to take on new meanings. 

When I started off in college, I thought I was learning “programming”, much like how when playing trumpet I thought I was learning “music”.  That is until I realized that I needed to know “classical music” and “jazz music”, with a large cross-over of shared techniques, but many details in each genre that define it as an art of its own to master.  The more I branch out in computer languages, the more I realize I was trained on “C-based, Simula-Influenced, statically typed, statically scoped, object-oriented programming”; with perhaps a lacking in breadth.  Sometimes you hear music so different, you wonder if you were deaf before hearing that new melody.

Big Nerd Ranch Day 1: The Journey

Jeff Boyus and I arrived today at Big Nerd Ranch in Historic Banning Mills, Georgia, for a 7 day class on beginner Objective-C and iOS programming.  After a long day flying cross-country, I'm surrounded by wilderness, only tenously connected to the internet, and excited by the promising hunt for knowledge in the coming week.

Big Nerd Ranch, as I am experiencing this week, is like a boot camp for developers.  They are in a camp-like retreat, outside of Atlanta, GA, where we have not much to do, but learn and practice our craft.  We'll have two days on Objective-C, the programming language of choice for OS X and iOS, followed by five days on learning the ins-and-outs of core development for iPhone and iPad.

Jeff was adamant that this was the best choice for training and he seems absolutely right.  Unlike on my previous out-of-town training tip with PNNL with a usual 8-hours of class then 16-hours of whatever schedule, this week promises to be a huge bang-for-the-buck.  We will get more hours of training, with less hassle, than any of the other options we found, and I can't think of a better way to immerse someone.

A big part of the magic formula is the setting's unique ability to form culture.  Maybe it's just the Lord of the Flies-like scenario, but you can't help but take on a tribal mindset when surrounded by the other students who have the same goal and no one else around.  We are a hunting party here to spear knowledge, claw all we can from its bones, and drag it back in pieces to feed our respective kin.

Very few people out to make the next instagram and more people working for companies looking to harness mobile for an internal audience.  Similar to PNNL's desire for mobile: they are facing a workforce that has adapted to mobile, found they like it, and their hunger for it in the workplace has left management looking for a way to built capabilities to make their own.  That's the appetite we have to satisfy on our return. 

Gathering around the campfire-like glow of Macbook monitors, we sharpen our spears, anticipating the chase ahead...

Mobile First Web

Last year I started experimenting with Responsive Design, trying to learn the CSS techniques and looking at JavaScript libraries that lended to modifying a UI to its form-factor. This year, I started trying to pull together design and development best practices on how to apply these techniques, in anticipation of more mobile-centric work coming down the road.  I was able to boil down the reading into a rather succint presentation that went over very well with the mobile-curious at work.

Luke Wreblowski's Mobile First web design approach, both the book and the ecosystem of opinion around it, was the touchstone.  Beyond that, a rundown of best practices and new features for development, particularly budding browser features, rounded out the content.

Why Mobile First?

Going mobile first means tapping into an ever-expanding market.  What many don't consider is that mobile devices are not just the current fashion in the US, but also likely to be the de facto computing device in emerging markets around the world.  If you want a web page to be seen by a someone in India or Africa, your best bet is to go mobile since smartphones and wireless networks reach so many places where desktops are hard to find.

Mobile Design 

While I had done some projects in the past that used media queries to apapt 3rd-party tools to scale down to mobile, I quickly found that's the wrong way when starting from scratch.  Starting with the most constraints (usually a vertical-oriented, mobile phone sized design), then progressively enhancing really is the way to go.  It forces simplicity, making the content more focused and code higher performance.

Mobile Development

On the development side, I also experimented with some of the browser capabilities like GPS.  You can try them yourself by firing up my version of Ben Nadel's geo-location demo. Seems to work best on Android and Firefox (choose "Always share location" then reload the page).

I also tried my hand with offline features, such as AppCache and localStorage.  Bruce had asked about them at a previous DocType Society meetup and while they're inferior to the lofty future of browser-based SQL-like solutions, they're an intriguing capability for the service-oriented applications I've started building at work.  Even in a non-mobile app, the ability to cache AJAX results across sessions is handy.

Conclusion

The presentation has a lot of content and it's hard to callout all of it here.  Compiling information for talks is a great way to find the shortcomings in one's own understanding.  If I can talk about it for 60 minutes, then I'm feeling much more confident that my next Mobile First project will be a success.

Special thanks to John Higley for letting me borrow his copy of Mobile First; my baby has kept me from returning it to him, but it'll make its way back eventually.

Don't Wait Forever

Most people think planning is a virtue.  If they wait long enough, surely the moment they are "ready" will coincide with the moment that is "best".  I tried to wait and plan for my kids as much as possible, but in the end it wasn't entirely up to me - which is probably all for the best.  While consideration can keep us from jumping into shark-infested waters, too much could mean starving on the beach without any fish.

I'm the son of old parents.  By the time I was born, my mom was only 30, but my dad was in his late 40s.  Since my dad was in the Army at the time, I understand they had a lot of travelling that wasn't conducive to child-rearing.  I don't want to condemn them for logistical decisions that ultimately led to great things like my fully-funded higher education; however, it did mean growing up with my parents on the other side of a great and alienating temporal divide.

Let me frame it for you this way: when it came to music, I liked Metallica.  They preferred tracks that predated the proliferation of electric guitars.

Your chosen timing will always have some trade-off and will never guarantee against all disasters.  As an analytical mind might be able to comprehend, the type prone to analysis paralysis, the equation of life is so complex that there is no universally optimal solution.  Thus, many possible random inputs can give the same output as your best laid plans.  If it's mostly a die roll anyway, then you only need so much time to study the numbers.

I certainly suggest you should complete your education and start your career, particularly young women who might otherwise be pressed too early in life into child-rearing.  Be responsible, but don't wait breathlessly for this unreachable concept of "Ready".  You can't shield your children from every struggle. Sometimes seeing yours will mean they have a role-model, someone who can show them how to swim somewhere other than the calm and clear waters.

All My Girls

Community & Capitalization

What is it that converts opportunity into achievement? This week at DocType Society, I overheard a conversation between Doug WaltmanPhillip Brothers, and a few others wondering how long until the development community in Tri-Cities receives some national recognition.  Intuitively, we each know community building is creating value and working toward that goal, but we couldn't directly articulate why.  That had thinking of this societal conundrums and Kenyans.

Why are Kenyans good runners?  When competing against larger countries, why do they win so often?  Answering such a question is frought with racial stereotypes and pseudo-science, but the explanation I like best is more sociological.  As recapped by Malcolm Gladwell, the Kenyan "secret" boils down to a culture that excels at inspiring people to run and cultivating people who run, rather an innate advantage.  It's an elegant answer: more people trying to achieve a goal means more achievers.

For anyone waiting for us to blossom into the mid-columbia silicon valley, we need to focus on getting everyone we can to build their big ideas.  Since we can't compete on size, we have to compete on the Kenyan effect, known more formally as "capitalization", building success from focus rather than scale.

What improves capitalization?  Education is the most obvious.  Opening Delta High School is probably the single biggest attempt by the local government to bolster local achivement in the tech sector.  I greatly admire their initiative and think it will have a big impact; it makes me proud to be a Tri-Citizen.  For people past school age, returning to college is a good idea, but it does have financial barriers.  

DocType Society and Room2Think are very efficient options.  Like formal education, they broaden and deepen the participant's knowledge through sharing, except in this case using the unorthodox metholody of peer-to-peer.  Beyond that, they offer role-models and success stories, from Franco's Exam Refresh to Digital Augment's Crumblin, that fuel aspiration and offer real-world insight.

Tri-Cities has a little in common with Kenya.  They also get a lot of sun and most Americans would struggle to find us on a map.  We're small places, competing against the world.  We don't have every opportunity, but if we turned every opportunity we had into achievement, we'd be unstoppable.

99 Problems and .Net is One

Back in .Net WebForms, where I remain trapped at work, they took great pains to hide the harsher realities of HTML from the developer.  They provide excellent tools and solve a lot of common problems, but they also sow codependence on the part of developers.  I've always pinned it on the framework being originally developed for and by Windows developers.

Injecting customization, particularly as JavaScript, can be very hit and miss.  For instance, data sitting in the standard boring table can be easily zazzed up by jQuery plug-ins likejqGrid or DataTables, which I've harnessed on other project to great effect.  Unfortunately, .Net's DataGrid control, which abstracts the concept of an HTML table, makes a total Ned Stark out of the standard table (it cuts off the thead).

One of the easier ways to handle it, is to craft a jQuery plug-in to adapt the HTML before feeding it into the real plug-in.  It's rather simple to make a plug-in that re-appropriates the first row of a DataGrid into a new thead, certainly less time-consuming than rewriting .Net controls.  Thankfully, the future (known to many as "the present") of .Net is built on cold hard reality.

 

Be the Verge

Verge

  1. To come close to or be in transition to some state or quality
  2. The edge, rim, or margin of something

At work we have a lot of people that do a lot of things, plus outside of work I know many vibrant professionals who have taught me a lot.  Going forward, a trademark of what I do will be working to create and sustain communities, within work and beyond.  I've been trying to spread the idea of spreading ideas diligently, but there can be some resistance.

Most undervalue it.  For instance, my co-worker who works on integrating AutoDesk Mapguide with .Net technology.  He has so little to work with when he Googles that he often browses through documents in other languages in hopes that the code they contain might be decipherable out of context to fix his problem.  I can understand his fear of putting a spotlight on himself, where he's just as likely to be boring or mistaken as he is to be brilliant, but he has to at least start lighting candles so others can see him in the darkness.

It's very easy to forget that we each have something to share and sometimes need to just start sharing until insight falls out of it.  Shotgun philosophy, if you will.  I'm going to push to let go of sheepishness around the idea that I might be boring the audience and remember that if I do lose them, it's only because I'm competing with the great invention for manufacturing distraction ever: The Internet.