My current work project is a mobile app for a medical device company. The software is, depending on the eventual feature set, FDA regulated. This means we will eventually have to undergo a HUGE FDA audit on our codebase. Not a problem if we have out entire history with comments and tags tying commits to work items, right? Well, our source control server died.

Yesterday morning, our gitorious server decided to eat its virtual disk. IT is trying to get it pulled from a recent backup, but it’s a many terabyte off-site backup. But we have work to do. So we fired up a new git instance, pushed master from the dev who had the latest, and we started working again. Once gitorious is stood back up, we will push latest to that and our code reviews in crucible will work like a champ again. Yay!

Here is how we did it:

1. create a bare git repository on a developer’s machine (mine).

   git init --bare /c/GimmeTehCodez/project.git

2. Share the directory with windows sharing. I limited access to only my team members, but had to set them all to Read/Write access.
3. add a new remote for the mirror. Note the four /s in the remote URL. Two are a relative file URL, three are an absolute URL. Four is another computer. In this case it is Wallace who shares my GimmeTehCodez directory for coworkers to upload stuff that can’t be put in email. Kind of a neat hack, huh? No drive mapping needed!

   git remote add mirror 'file:////Wallace/GimmeTehCodez/project.git'

4. start by pushing the last good master back in to the repo

   git push mirror master

And we’re off and running again! We could get a network share from IT, but that would take too long and distract them from getting my server back.

If we were using TFS and had a server issue like this, how long would we be out? If we’d lost our code history, how much worse would the FDA audit be with all that lost history?

Next step is to start thinking about a ‘hot standby.’. Probably not needed, but it would be cool. Then I can think about using git-tfs to make our tfs projects stand-by as well…

Our most recent Sep book club has been The Passionate Programmer. One of the things mentioned was taking some third party code and reviewing it.

This is not a new idea. Many people has said the best way to understand the code you write is to understand the good and bad of code written by other people. In addition, reading code in a language you are learning exposes you to functions you might not understand as well as idioms you don’t understand. We had an idea of meeting occasionally over lunch and tackling some code. Here’s kinda what I’m thinking that would look like. Please comment and let me know if there’s something else I’m missing.

With that in mind, I found an article on the Haskell Wiki where they implement a chat server in Haskell.

I’m only posting the code review for the final version. Technically, the final version and my changes to make it compile. There are more about that in the comments. I added my initials, BJB, to the comments I made and if I had to look up an API, I provided a link to where I learned about it.

This chat server has a couple of interesting features. It uses lightweight threading to handle multiple incoming and outgoing IO. It uses channels to communicate across these threads. The forking calls are also used to create separate “loops of control” for each IO channel being handled.

Below are the comments I’ve added to the program.

Continue Reading »

I said I’d post a quick blurb on how things went in our experiment with an OpenSpace brown bag format.

In a word; well.

Here’s how we did it. I reserved three conference rooms with help from Kelly. Once we got together, we put some ideas on the board. We then did a quick show of hands to see what we wanted to discuss. Since we had a small group that wanted to talk about all of our three ideas, we just jumped right in and kept going until we finished. If we were larger or had a clearer split in desired topics, we would have split in to different rooms.

The had three main topics. Dasher, an internal pet project to get more visibility in to various project metrics around SEP, wanted to get some feedback. We discussed global variables in OO languages and their trade-offs. Our last topic was a discussion about practicing, learning not production use, Test Driven Development.

Would we do it again? Next time there is a hole in the brown bag schedule, I would.

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.