Sazbean

Software Development Management

Main navigation

You are here: Home / Archives for Aaron Worsham

Aaron Worsham

/

CodeMash 2009 – Friday Morning Sessions

The guy who wrote Rails was clearly brilliant.  He just didn’t have alot of real world experience ~ Joe O’Brien, talking about the limitations of testing within Rails

So Joe O’Brien, from EdgeCase, is one of those really exciting presenters to watch because it is a certainty that both you and him are both going to learn something within 30 minutes.  Throwing the presentation safety net away and going off the map, Joe tackled the tangled subject of testing in rails by the only way that makes sense, actually doing it. Here is a bit of what you missed:

  1. Make a rails project, open a test file and make some assertions.
  2. Fix your errors and make more assertions.
  3. goto step 2

This was a great way to see they subject matter come alive, warts and all.  If Joe had the courage to start hacking away at a program’s test code in front of 30 people, maybe it wont be so scary when you try it in the comfort and protection of your cube next week.   So here are some of the things we all learned from this demonstration:

  • Mock up things to make tests more isolated can be proven by breaking the fixtures layer and demonstrating how brittle it really is.
  • Separating controller tests from models and views is a good thing!
  • Integration test that doesn’t start with the brower isn’t really integrated
  • Changing from QUERTY to Devorak keyboard mappings a week before a live demo makes for awesome typos

Look to March for the marriage of Merb and Rails for an alternative to the ActiveRecord ORM.  Also, learn to love mocking in test and find a moching library that you like, be it RSpec or Mocha or FlexMock (which they use in EdgeRails because it WAS actually invented there).  Also, look to the Pragmatic Programmers for a screencast on testing from Joe and Jim sometime soon.

/

CodeMash – Thursday Afternoon sessions

Remember fear is the mind killer, so just get over it and learn Functional Programming ~ Kevin Smith talking about Erlang

The two afternoon sessions, Erlang the Basics and Functional Concepts for OOP Developers, were one – two punches to the gut, in a good way.  If you tried to read a Functional Programming tutorial, maybe waded into the Lamda Calculus pool and found it didn’t have a bottom, you’re not alone.  I remember just innocently hitting Wikipedia for a definition of Functional Programming only to be turned back by the first sentence comprised entirely of mathematical symbols and polysyllabic words without definitions that didn’t also have mathematical symbols and polysyllabic words.

Thankfully, for the cost of gas, a room and a cheap ticket to this conference, I got the opportunity to let real functional programming masters explain it to me in English.

Kevin Smith, of EngineYard, does Erlang for a living.  That kind of makes him a grand pooba of Functional Languages in my book since OOP just about buries the list of code written today.  Still, as Kevin noted in his talk, there are high profile sites using Erlang today – Facebook is using it for chat, Amazon uses it as does CouchDB.  Unlike Haskell with its academic background, Erlang is the programmers functional programming languages ‘to make hard things eas(ier)’.  So what are those really hard things?  Well concurrency is the big one.

Not long ago, programmers had a one-machine-one-CPU view of the world that served them well in the Object Oriented Programming universe.  Software was rarely written to work as a unit over more than one CPU at a time because it was 1) very very hard and 2) impractical and unneeded for most cases.  Today, however, programmers are realizing that the multi-core growth path of hardware manufacturers has hijacked the stage, forcing us all to become concurrency experts. While OOP languages are saddled with the baggage of supporting shared memory and mutable variables, reducing them to a one legged man in a ass kicking contest, their distant cousin Functional Programming Languages aren’t feeling the same strain.  FP’s have immutable ‘variables’ (really they are unchanging pointers, so more like constants) and a very low cost for spinning up processes.  This frees them to run in a highly distributed way on many cores and many machines collaboratively. Erlang, written by the team at Computer Science Labs at Ericisson, had a real world need for a highly concurrent language to write their phone system on.  Its design works wonderfully to harness that 8 core desktop you have sitting under your desk.

Bryan Weber was kind enough to expond on this foundation talk by exploring Functional Concepts for OOP Developers.  My take home from this talk was the message model used by most Erlang programmers to achieve concurrency.  Like Scala, Erlang uses a mailbox with a send and receive paring to smoothly weave a web of interconnected processes that can be located anywhere on the network.  Simply spawn a process, which gives you a pid in response.  Now send a message to the pid.  The spawned process does a recieve to check the mailbox for the message.  Want to send a response, no problem.  Have the spawned process send to the parent and have the parent check the mailbock.  Done, you just did concurrent work.  This little scene is played out using Actors, which naturally, is an apt analogy.

I don’t know yet if FP will make it into my world any time soon.  Our concurrency neeeds are small so far.  I would say that Functional Programming isn’t the solution to all problems, but it just may be the answer to that tricky problem defying all other solutions.

/

CodeMash 2009 – Thursday Morning Sessions

Whould you want your surgeon to have a dull knife? ~ Nathaniel Schutta defending dynamic languages like Ruby as ‘sharper tools’

Travel issues prevented me from seeing the very early sessions of CodeMash, which was a shame because I was very interested in Eric Meyer’s talk on how JavaScript Will Save Us All!  (I added the exclamation marks because I think that’s what he really intended).  Still, I made it early enough to sit through a couple very good presentations before lunch, both of which followed a bit of a theme.  One was a love fest for Dynamic Languages as a persecuted, second class citizen given expertly by Nathaniel Schutta.  His message is simple, programmers need to be Polyglots and if you can’t handle learning different languages than you should get out of the business.  Harsh, but dead on accurate.  One of the languages you should have in your tool belt, Nathaniel tells us, is a Dynamic Language and that you can do a whole lot worse than Ruby.  I am already sold on this idea, or was years ago when I was nearly alone in lecture rooms during similar presentations.  Since then the crowd has gotten bigger but the message is still the same.  Most of this revolves around dismantling the arguments for the need of static typing to prevent errors from bad programmers.  Truth is, bad programmers don’t get better when they have a wet nurse hand out brainless advice through compiler warnings or errors.  Take off the training wheels already and let’s get some code written already.

You go though more hoops to do it, but you can do it ~ Venkat Subramanian Mads Torgersen talking about Dynamic languages on C#

Venkat Mads works for Microsoft on the C# language.  Now I am not genetically predispositioned towards this kind of talk, but since it was while I ate my ham on marbled rye, I felt no great persuasion to not hearing the good gentleman out.  Glad I did, though, because there were some interesting things going on in the CLR camp.  CLR itself was a happening idea, a VM that was designed from the beginning to be a shared platform (Common Language Runtime) so the pieces where already there to do something interesting.  However, it seems that early decisions were made to optimise speed for the C# type base on the CLR, leaving non-microsoft languages somewhat at a disadvantage and me somewhat bewildered by the earlier statements.  Dynamic languages, for example, run though a DLR library to get to the CLR.  This Dynamic Language Runtime handles the bindings to Ruby and Python, so IronRuby and IronPython handle the mappings between DLR and CLR maybe?  I was somewhat confused.  If you type something in your code as ‘Dynamic’ it is a Dynamic type in the compiler but then reverts to its true type in runtime to allow for the dynamic langages to duck type the thing.  For a complacated problem, the fact that this solution made perfect sense to someone as slow as me is a good sign that they might be on to something.