User Groups: Seattle, WA. Portland, OR. Architect's User Group
Discussion Groups: LAVA, Actor Framework, LapDog API
Articles: approx a dozen in various states of incompletion
Books: (See my posts on the forums)
I started programming LabVIEW in 2006 when I stumbled on the Tic Tac Toe Challenge.Intrigued, I installed a 30-day trial and coded up a contestant--Toe Jam.Toe Jam ended up finishing in the middle of the pack, but I had fun writing it.Later on that year I accepted a new position as a test engineer for Microsoft's Zune, responsible for testing the capacitive touchpad (and later the capcitive touch screen.)As part of my job, I had to create a 2-axis robotic system to precisely control an artificial finger, so naturally I turned to LabVIEW.
Over the next several years I became more experienced with LabVIEW and eventually decided I wanted to return to programming rather than be a test engineer.Around 2009 I accepted a position as a developer with the XBox Accessories team, creating test tools for the product design teams.It was while working on a complex RF testing application for XBox controllers that I discovered that, contrary to what I had read on the forums, the QSM was not the bee's knees.There were no guidelines available to users explaining how to integrate a QSM loop with other loops, what kind of commonly promoted techniques were safe or not safe, or how to refactor a QSM as it grew in complexity.Without any guidelines, our applications inevitably grew into a big ball of mud as we frantically tried to satisfy the test engineers' ever-changing requirements.
Dissatisfied with the constant grind and problems with the status quo, I started looking for smarter ways to develop software.In particular, I wanted to write software in a way in which it is not only easy to change what the software is supposed to do, but it is easy to predict what the software actually will do after the change is made.I focused on implementing code that satisfies the requirements now, not implementing code that satisfies what the requirements might be next month.I also wanted to take advantage of arguably the single biggest advantage Labview has over most text languages--cheap multithreading.Above all, I didn't ever want to code myself into a corner that was difficult to get out of.
I spent the next several years experimenting with various ideas and implementations, posting ideas on LAVA, and taking bits and pieces of what worked while discarding those things that did not.The old school Labview programmers I was working with were content to continue doing things the same way they had been, so I left Microsoft and started a consulting business while refining my techniques.Eventually I realized what I had was an agile approach to actor-oriented programming in Labview.The philosophy I took towards my coding methodology now had a name:Agile Actors.Over the past couple years I have become a vocal proponent of actor-oriented programming and have tried--with varying levels of success--to teach AOP to other developers.