I was wandering around the SEP.COMmons after passing a certification test on Friday and I noticed something. We had a whole in our brown-bag schedule. This will not stand! I wanted to try something out. I’ve seen Open Spaces work for conferences, but I was wondering how well they would work for a shorter time frame. Like an hour. With only two rooms.

My plan is to quickly explain the agenda, quickly get some ideas, quickly poll, and quickly break in to two groups to discuss those ideas.

I owe you one blog post about how well it went.

Read about Open Spaces on Wikipedia.

The point

I just got done with a company startup weekend. We were all coworkers and are all employee owners with no outsiders invited to participate. It was a blast and boy are my arms tiered!

This Friday afternoon before the pitch session, a group of us were talking about our project pitches and I mentioned that I felt the perfect startup weekend project is two things; It’s sexy and it has legs.

By sexy, I mean it appeals to my technical side. I want to play with new and exciting technologies. I want a toy that I’m proud to show off. I want geek-cred!

By having legs, I want to participate in a project I can see our company taking to market. I want a project I can see myself working on for a long time. Not because it is fun, but because I can see us making serious cheddar. Or at least enough to justify my salary.

Let’s take a look at one of the ideas I pitched (it failed to get picked up for the weekend by the way), an email client. It is not sexy, it’s email. I was trying to strip down outlook to its essentials. It doesn’t have legs. There isn’t an easy route to customers. It’s hard to be an indy dev. Especially when dealing with interfacing with exchange servers where your company already pays for Outlook. Besides, who gets excited over email? In my defense, I can rattle off Gmail, Sparrow, Eudora, and Mail.app that people love and the ones they hate like Outlook (express and office). It was gratifying, however, to notice how often people noticed they did hate Outlook over the weekend and say, “I should have voted for Brian’s project.” Though, I know they were just kidding.

The rest of the story

That said, I had a blast. I worked on an interesting project with a wonderful team. I didn’t get to play with the core of the project, but I did get to play with HTML5 and javascript. I didn’t know any of the stuff I did before I started, it just sounded like fun.

What did I learn playing with HTML5, JQuery, and Rx for Javascript? Browsers are way cooler than when I last did web development. DOM manipulation was crash prone in the early ‘naughties. And pretty! Oh, wow. I did some canvas drawing and some file dropping. I finally got around to doing some JQuery. While I’d played with Rx for .NET, I used some of the techniques to handle dragging ant-trails on a canvas using the JavaScript release of the lib. And I realized why people write frameworks like Yesod and WebSharper. Even as an experienced dynamic languages dev, I had to track down more than a few type errors coming from unfamiliarity with the libraries.

More important than the stuff I worked on are the people I worked with. Working with a team is far different than working along side teammates. It may sound like I’m splitting hairs, but that statement resonates. We were holed up in a conference room with most of us working face to face across a table. This type of closeness does bother some, but it speed up the sharing of information. We changed the environment in which we work and it deeply effected how we work.

It was a great experience and I’m glad I did it. It was exhausting. I’ve heard someone mention we should do this every quarter, but I noticed he wasn’t participating. I like the idea of once a year. Otherwise, it’s too much like work.

Stoics believe in pure reason. One of the things that clouds their reason, they believe, is negative emotions. In attempting to remove themselves from the clutches of these negative emotions, they steep themselves in them to remove their power. It’s a type of desensitization therapy to regard a flower each time you see one in bloom as a thing that will wither and die. Just like you and everyone you love. In some ways, they are obsessed with those emotions.

There are another class of people that are kind of the opposite of the Stoics. They don’t steep themselves in negative emotions, they discount them. If I feel sad, it’s because I’m a weak person. It’s not quite the same as Pollyanna seeing the bright side, but they think it is.

I’ve noticed this recently with some personal emotional stuff and some people’s responses, my own included.

In addition, I’ve seen people behave like this on projects.

One school of thought is, “Fail early, Fail often.” The thought being we learn by making mistakes. They drive towards failure and focus their energy on understanding their failures more than their successes.

The other school of thought believes, “Failure is not an option.” Signs of failure are ignored as something not worth considering or they throw good money after bad thinking a failure can be overcome long after the failure has consumed all.

The truth is somewhere in the middle. We can learn from our successes and our failures. And most importantly, we must neither ignore our negative emotions nor stew in them to the exclusion of enjoying the beauty around us.

I have started my Erlang based MUD a few times. The first time, I got bogged down in telnet details. The second time, I got lost building far too many proxy objects and indirections. Then I wasn’t even sure what I’d written was correct or that my changes wouldn’t break something.

I was having a hard time figuring out how to drive out the code. Where do I start?

This time around, I’ve gotten farther than I ever had before. I’m at a stage were I can move my character from one room to another. The perspective this time, I got a chance to drive the code out by running it via the REPL. I found a happy medium between top down and bottom up. This is similar to TDD use to test out an View-Model. My REPL based code had simple functions that mimicked the future texted based input. Seems like a duh now that I’ve said it. It really does feel more like I’m cutting with the grain.

But now, how do I make sure that I’ve got code that works constantly? Especially when I start dealing with more complex behaviors. I want to “record” my REPL sessions while focusing on building contexts since there are so many ways to build up a player and rooms. To do that, I’ve built a BDD micro framework based on E-Unit and a dash of rspec. I call it “test.hrl” and it is all of three macros!

-include_lib("eunit/include/eunit.hrl").
-define(It(Text,Func), {"It " ++ Text, Func}).
-define(It(Text,Setup,Cleanup,Func),
        {"It " ++ Text, setup,Setup,Cleanup,Func}).
-define(Describe(Text,Tests),{"Describe " ++ Text, Tests}).

It is based on the fact e-unit can used nested test descriptions to run tests. I just wrote some macros around it to make it fit my preconceptions of what a bdd framework should be like using terms I like.

When used, it looks like this

-module(player_tests).
-include("tests.hrl").

player_test_() ->[
  ?Describe("Bad Password",
    [?It("should return an error",fun setup/0,fun cleanup/1,
          ?_test(begin ?assertEqual(error, player:login("Tony", "BassPassword"))end))
    ]),
  ?Describe("Good Password",
    [?It("should have a player proxy",fun setup/0,fun cleanup/1,
                    ?_test(begin Me = player:login("Tony", "Hello"),
                                 ?assertEqual({ok,"You aint got jack!"},
                                 Me:inventory())
                           end))
     ]),
  ?Describe("Room Interaction",
    [?It("should describe the lobby",fun setup/0, fun cleanup/1,
         ?_test(begin Me = player:login("Tony", "Hello"),
                      ?assertEqual({ok, "It's a lobby"},
                                   Me:look())
                end)),
     ?It("should move to the kitchen", fun setup/0, fun cleanup/1,
         ?_test(begin Me = player:login("Tony", "Hello"),
                      Me:move("north"),
                      ?assertEqual({ok, "It's a kitchen"},
                                   Me:look()) end))])
].

setup() ->
        % I don't know why, but I need the print
        % to make the kitchen test pass
        io:format(""),
        stubs:fake_rooms().
cleanup(_Pid) ->
        stubs:stop_fake_rooms(),
        true.

Here’s my test runner

-module(test_runner).
-export([run/0]).
-include_lib("eunit/include/eunit.hrl").

run() ->
        eunit:test([player_tests],[verbose]).

The output looks like this

erl -noshell -pa ebin -s mnesia start -s test_runner run -s init stop
======================== EUnit ========================
module 'player_tests'
  Describe Bad Password
    It should return an error
      player_tests:7: player_test_...ok
      [done in 0.016 s]
    [done in 0.016 s]
  Describe Good Password
    It should have a player proxy
      player_tests:11: player_test_...ok
      [done in 0.015 s]
    [done in 0.015 s]
  Describe Room Interaction
    It should describe the lobby
      player_tests:18: player_test_...ok
      [done in 0.016 s]
    It should move to the kitchen
      player_tests:23: player_test_...ok
      [done in 0.016 s]
    [done in 0.032 s]
  [done in 0.063 s]
=======================================================
  All 4 tests passed.

This may not be perfect. I may not be the most ergonomic. I know it isn’t. But it’s close enough for me right now. I feel like I can describe what I want in a manner that fits me. Three macros and a slight change in how I view the world means I finally have this project moving forward well. It is truly amazing what just a little code can do.

I’m still thinking about teaching F# to my fellow coworkers later this year. In order to do that, I’ve had to start thinking about what to teach.

This class is a tough assignment for me. The people who want to take it have said, “No parsing!” evidently, parsing is for eggheads and dorks (Fuller is such a reactionary anti-academic). And I have to make it useful! Fine. My thesis is this; F# is best when used for libraries, when used for asynchronous programming and reactive manipulation of streams. Also, functional abstractions and immutability are great for data-centric programming.

Below is my rough syllabus. Please feel free to comment if you think something is missing. It almost surely is.

• Week one – Making sure you have F#, Basic Syntax, type inference, recursion. There will be a reading assignment to accompany this. In addition, I’ll have a github project up that will have some tests that need to pass. I’m calling these “worksheet” problems.
• Week two – Pattern matching, higher order functions, maps and folds. A few worksheet problems added to github. A game of life mini-project assignment?
• Week three – Algebreaic types, records. In addition, we will start dealing with tail-calls and branching recursion. Worksheets.
• Week four – Streams and Sequences. These are kind of what functional programming is about, to my mind at least. It will allow spring boarding to reactive (eventually). They will write a few streams in worksheets.
• Week five – Modules, Objects, and Mutable refs. We’ll write a lib that will be used by a CLR program to do the “Flocking Birds”
• Week six – Asynchronous Workflows. We’ll write a command line podcatcher that will be totally asynchronous, list of urls in a file spits out to RSS feeds, to saved mp3 files.
• Week seven – Mailboxes. A simple Spreadsheet (parser provided) will allow gets to happen threadsafe from the updates. A worksheet with some massive parallel updates of a queue where everything must be handled thread safe.
• Week eight & nine – Custom Workflows. You know… Monads. May take a couple weeks. Still no damn idea what I’m doing here, honestly. I need some workflow examples to implement.
• Week ten – Reactive Programming. We’ll write a generative seqencer that uses a WPF control and a sound lib I’ll provide.
• Week eleven – back to C#. A view of linq and lambdas.
• Week twelve – Topics in F#. Lightning talks! And a fluid simulation project. IN 3D! Again, I’ll provide the control.

Oh, theres so much to be fleshed out, but here is where I’m thinking of starting.

And I need to do the projects to make sure they are sized right.

Somehow, I’ve been suckered and bamboozled. I’ve been talked in to prepping an internal course on Functional Programming. To talk about functional programming, I need to have the students actually program functionally. There are several choices I’m considering; FSharp, Clojure, Haskell, and Erlang. There are plenty of others, but I’m not as familiar with them so they won’t be considered. They each have their own strengths and weakness.

Clojure was started on top of the JVM (Java Virtual Machine), but is also being ported to the CLR (Common Language Runtime). It’s a dynamic functional language that is a part of the Lisp family of languages. There’s a lot to be said for it. It’s got Macros. It’s got all kinds of documentation. It’s got all kinds of libraries. It has great IDE support. It even has a bunch of Emacs support as well.

Haskell is a research language that’s crossed in to industry. It compiles to machine code. It is strongly typed, way stronger typed than Csharp or Java. It is type inferred. It is Lazy and Pure. There is a community of developers releasing libraries. There are some really good documents as well. Many interesting functional research papers use Haskell as their implementation language.

Erlang is an industry secret that escaped to main stream use. It is a dynamic language that runs on it’s own interpreter. It has a bit parsing syntax. It has strong networking support. There is a growing community and some good documentation. It has a phenomenal set of libraries for concurrent programming.

FSharp is a fairly new language from Microsoft. It’s a strongly typed and type inferred language. It has some great language extension features like workflows and quoted code. It is a variant of Ocaml. It lives on the CLR and integrates well as a consumer of .NET libraries or as a .NET library to be consumed by C# code.

They are all very different and have different focuses, so I had to eliminate some. Erlang is out because it is almost too focused on concurrency to the point of distraction. Haskell is a wonderful language but has a sovereign ecosystem that would preclude it from being used with the majority of our work. Clojure is wonderful and I can turn a bunch of existing material from Scheme or Lisp without much work, but it is mainly a JVM language and I can’t vouch for the completeness of the CLR implementation at this time.

This leaves FSharp as my language of choice. It plays well with .NET and we have a LOT of .NET projects. I can use a lot of Haskell resources as a starting point. It should work well. I’m looking forward to class.

A few years ago, we did some embedded control testing that got me seriously thinking about language. The system was specked out using signal flow diagrams, the kind I remember from digital signal processing in college. The code was white-boxed C poking and prodding at a lot of global variables. Our test tool let us define values in terms of other values, invoke the C code, then assert some values with our expected. Think of this as like using excel to model signal flow.

Here’s an example of a signal flow diagram from DSPRelated.com

The signal flow diagrams used a lot of sub components, some that were deeply nested. Our test tool doesn’t have any abstraction; no functions, no macros, and no components. This lead to repetition in our test code. If I had three calls to a sub block, I would copy/paste/rename upwards of 60 lines of code for each block. Code reviews were important and kind of intense. We couldn’t stand the tool, but the tooling surrounding it was worth the hassle. We had code coverage, logging reports, and most importantly we had decision coverage.

But it still felt like I was programming in the wrong language. At that time in my life I tended to think, “I should be writing in Ruby.” But even that’s only part of the story.

What I wanted to do was model the diagrams more directly. I wanted to define a component, wire five of them together, define my input ranges, and make some assertions. I wanted my test code to feel like you were looking at a diagram. This would make the code easier to maintain, reduce duplication, and make it easier to review.

I sat down with Ruby’s mutable syntax and tried to whip up a model of a few representative diagrams. I couldn’t make it perfect, but I could hit the 80% mark and leave enough “bare metal” to work around for the last 20%. All it did was spit out the code I would have written by hand, but it was much easier to write in my little language. The best part is all our existing tools worked just the same.

test 10, "4 step floating average" do
  inputs :in => [0.0, 10.0, 13.0]
  inouts :delay_1 => [0.0, 10.0, 13.0],
         :delay_2 => [0.0, 10.0, 13.0],
         :delay_3 => [0.0, 10.0, 13.0]
  delay_1 = instance :delay, :delay_1_expected,
         :input => :in
  delay_2 = instance :delay, :delay_2_expected,
         :input => delay_1.output
  delay_3 = instance :delay, :delay_3_expected,
         :input => delay_2.output
  double :expected, "(in + delay_1'IN + delay_2'IN + delay_3'IN) / 4"
  assert :delay_1 , delay_1.output
  assert :delay_2 , delay_2.output
  assert :delay_3 , delay_3.output
  assert :answer, :expected
end

I am happy with the solution. Not because I get to write in Ruby, but because I can write the code that fits the solution. That’s when I started to really understand the power of language to clearly express the problem and solution at hand.

I’m presenting to IndyAlt.NET on Domain Specific Languages this week. This isn’t just programming language wankery, though I’ll admit that part is fun. It is about using the right tool for the job. I’m currently writing an application in C#. But the majority of my code should only superficially be called C#. I should bend C# to express the domain and let me program the solution, not the implementation.

I was at the statehouse on Friday because my wife is someone to be admired. Being there, I got to watch a bunch of people from all walks of life: teachers, professors, students, and politicians. I noticed two in particular.

More correctly, I noticed one half of that pair, a middle manager. In some small talk this person gushed about a boss to me (a nobody in the scheme of things) and I noticed this person had modeled personality traits on the boss in question. The boss has some traits to be admired, and some not. But the pointless traits were the ones I noticed being mimicked: taste in coffee, dress, and oddly enough speech patterns.

I admire many of my coworkers for various reasons. But I had to ask myself in light of this, how should I model myself after those I admire and seek to emulate? Does college football make me a kick-ass people person? Those aren’t the behaviors that begat the qualities I want for my own.

Back to my wife. She is one of the smartest people I’ve ever met. I admire her personability, her persistence, her compassion, and her organization among other fine qualities. But one of her defining character traits is, “likes pink.” This doesn’t mean I’m putting pink into my wardrobe. It does mean that I’ve started to work on my own professional development while she is hard at work, I’ve started to take an interest in other people, and I’ve kept my stuff in its place. Honestly, I still have much improvement in these areas, but the point is simple. Seek to understand how the people you admire got that way, and that will gives you tools to truly improve yourself, not merely parrot it.

There are few things in life better than humus and pita chips.

There are few things in life are as insidiously addictive as brain-crack, the idea not executed. These ideas sit in your brain festering, growing malignantly, until there is no hope of you ever achieving them like the “perfect utopia” they have become.

I bring this up because I had 2 in particular that where starting to rattle around in my brain like horrid clattering moose (moose clatter, right?). I’m a junkie for computer languages, and when Rick Minerich mentioned Irony recently followed quickly by a project manager asking about writing a testing DSL, I started to feel that tumor grow in my delicate, delicious brains. I should write a language. Then it split in twain. There is no reason to have a programming language, even a DSL, without an editor that understands it. I’d need a Visual Studio plug in to make that work. And those are hard, right? Besides, I would want to do it right and reuse the parser built for the first to syntax highlight the second. Uh, oh. I now have an idea for the perfect DSL framework rattling around in my skull.

The problem is, I only have enough room in my brain for a handful of things at any given time. So, I took the weekend to clean house. The idea is not to get something perfect. I just want to get it done enough to say, “I did that.” And now I can get to sleep tonight. My DSL isn’t for supporting your important work, it is for proving I know how to do it.

First lesson learned: Irony has crappy and out of date documentation. Every example I’ve seen uses API calls no longer in the library. In addition, most focus on how cool the internal DSL Irony uses for creation of the language grammar. And it is cool. But some of us missed the last mile. I’m not going to solve that issue here. I did, however, post my weekend exploration to github. Enjoy!

Second lesson learned: VS 2010 isn’t that hard to extend, once you know where to look.

Third lesson learned (again): I can’t spell. I had set the file extension to “circles” when I was using a file called “circle”. That means my plugin wasn’t triggering Saturday, so I had a Ukulele break and came back to it this afternoon.

Fourth lesson learned: Visual Studio lies. It gave me an error when my extension crashed about ActivityLog.xml but I couldn’t find it. I had to enable -log at the command line for the extension. Then it was easy.

Fifth lesson learned: a full grammar sucks for syntax highlighting. Effective syntax highlighting requires robustness because it should work, not only on a full program, but on a program as it is being typed. See the screen shots to better understand.

I’m not “finishing” this project. It has done what it was meant to do, serve as a prof of concept sketch that I can refer to later. Enjoy!

To understand the context of this post, I’m starting from having watched Mary Poppendeick talk about Deliberate Practice.

I hate that phrase, “Working hard, or hardly working?” It’s a mean-spirited jibe at someone’s effectiveness and work ethic. However, it says something about practice. If you are only going through the motions, you aren’t really practicing.

When discussing practice, it makes sense to identify two types. Practice, as in a practicing attorney, is the act of doing a thing. Practice, as in deliberate practice, is about isolating disciplines to find ways of improving. This second type is what I’m talking about today. It’s the soccer player dribbling around cones, the musician doing etudes, or the artist drawing a page of ears.

I’m going to define deliberate practice as “performing a discipline to gain feedback on the quality in order to improve proficiency. The key is ‘feedback’. Without the feedback cycle, we don’t improve. It is what makes the distinction in the phrase, “Ten years of experience, or one year ten times over.”

To practice, we deconstruct our performance into it’s constituant parts and strengthen our skills. The isolation is important, because it allows us to focus on one area for improvement at a time. Why isn’t doing as good as practice? A musician won’t focus on breath control and tonal quality while making a tricky 16th note run, so they perform one-minute drills, playing each note on a scale for one minute while maintaining centered tone. Sure, they may hit all the notes at tempo, but what about the quality of their attack, tone, volume, and speed of their transitions?

What does that have to do with Development? (Disclaimer, I say typical in the following because I still brush up against people from organizations who have these experiences. Your millage may vary) The typical factors effecting software development encourage “all performance, no practice.” The drive is to constantly move towards completion of the product. This is good, as we find business value and justify our paycheck. This is bad, because we don’t invest towards our future capabilities. I’m not talking about the perfect, flexible code that will slice, dice, and make julian fries. I’m talking about our ability to do a better job next week, month, or even year.

The typical industry workplace distracts us from improving in a couple of ways. The pressure on the project usually means the database expert does all the database code, preventing a sharing of knowledge and encouraging focus on existing strengths. Reviews, when done, are months removed from development and focus on finding defects. They are not intended to provide the more subtle feedbacks that will make fundamental changes in the way a developer addresses their work. Developers aren’t given time to explore and attempt to use new techniques and determine their impact on the fitness of the code base. All this leads to an environment that encourages stagnation and the status quo amongst the development staff.

Typical design reviews are done well in advance of development before any new lessons learned from the implementation of other parts of the system can be incorporated. Typical code reviews are delayed until the code is stabilized to reduce re-work. This means reviews happen well after the initial design decisions are made, so they can’t make meaningful comments on the larger patterns, but only look for defects or show stoppers. If we delay detailed design until we are actually working on a task, we see the code take shape while the design decisions are fresh. In addition, if the designer is actually the developer implementing their code, they learn what did and didn’t work well. Another way to get timely feedback is to target your development tasks at one or two days of work. This makes code review quick and doable as part of the normal work flow, the code can be reviewed before the developer being reviewed starts on new work. This starts to bring them into the practice feedback loop of do, evaluate, and do again. The tightest method of feedback is constant feedback. That comes from pair programming. Even if you don’t pair as part of daily routine, you should consider it as a means of knowledge transfer and training for ALL developers.

Practice is about strengthening your weaknesses. A quote from David Mead’s 10 Minute Acoustic Guitar Workout describes a player who had revisited several songs after a few years. He realized he still had the same problems in the same areas of those songs because he had not addressed those fundamental weaknesses, but practiced and played what he wanted. More correctly, what he could already do. If you encourage the developers to get done fast and perfect at all costs, then they will gravitate to what they already know. They will begin to have siloed code ownership. You’ll turn around and find out that the analytics specialist, the only one who knows that part of the code, is spending a week in the Keys, and you have a customer who wants a change NOW. This is an example of “bus-factor,” the degree to which losing a single team-member puts your project at risk. More insidious, they will drift apart in their understanding of the system because, “That doesn’t effect me.” If they don’t have a shared vision, they aren’t a real team. If the developers work on and share several sections of the project, you strengthen their weaknesses. Agile teams strive for ‘Generalist’ developers. This doesn’t preclude expertise, but that dev is now a reference and mentor sharing the knowledge. While one developer may be able to handle all the analytics now, what if you have to double her workload? If you have a team of UI developers, but aren’t focusing on the UI this release, do you let them go, or shift them to areas where they are needed?

Developers are usually not given flexibility to explore better ways of doing something. While uniformity make development easy, it can be a false prophet. “We can’t do that module differently because then we’ll have to change these two.” Experiment. Try it. Is it easier to maintain? great! Is it worse? Then you learned, and that’s valuable as well. Do you have to change solid, tested, working code because you have a new methodology? No. Wait to change the code until the requirements change. Often the first code laid down is fixed with rigidity, even if we find strong evidence for change. This can be a false economy. The local highway is expanding traffic lanes to accommodate more cars. Older homes are re-insulated and fitted with grounded electrical outlets. But developers seem to think the only way to change code is to burn it all down and start over.

This is about how an organization can try to enable the growth of its development staff. A lot of this points to lean processes and agile techniques. I’m not sure if the software craftsmanship movement, who prize practice so highly, developed the agile techniques because they sought feedback, or because they saw the effects of feedback, they began to understand practice.

Some time in the future, I’ll be addressing some practice techniques that individuals can use so they take some charge of their own growth. The organization can only do so much, you have to take it the next step.