“Good design means never having to say “Click Here”.
‘You have enemies? Good. That means you’ve stood up for something, sometime in your life.’
- Winston Churchill
(Via Minimal.)
I’ve had several interested friends ask about “how the precompiler” went. As the acting Iteration Manager I can say that it exceeded my every expectation but what does that “mean”. Well I’m going to be compiling the information that was collected from the event and putting it into a case study for a team of 50 developers, whom only half of which were familiar with the tools and process methodology, working from scratch on an application.
What did we learn?
What did we succeed at?
What did we fail at?
Those at the retrospective probably know some of those answers because we discussed them as a group and I made notes about how I may present this workshop in the future. (possibly at CodeMash again next year?)
But I wanted to let everyone know that we did complete most of the app to make it fully functional. In fact, in the afternoon we were already looking to refactor the architecture of the application and that is where it is right now. So, Cory Flanigan’s group at set out to do just that. Cory and I will seek to complete the touches and push out to http://symposiast.com.
So, stay tuned and if you’re interested in seeing where we ended up check out the code that was committed and merged into master at http://github.com/fallenrogue/CodeMash-2010-Precompiler-Application.
Perception is truly reality. The way we see the world shapes how we look to solve problems. It’s with that grain of salt that I offer up this response to Mr. @JonathanPenn’s tweet to substantiate my claims on the interwebs this morning. Boy, I hate getting into these messes but he’s right to call me out and clarify. Here’s our convo:
With that history you must know that I spent years in .NET and C# so Java is going to seem like second nature to my eyes; rather than, say, a C++ programmer who will, likely, see something familiar in Apple’s Cocoa/Obj-C environment.
That said, my comment takes the following into consideration…
Java is dominant right now (stats!). In the Enterprise, they’ve got a pretty large hold on the development community and love it or hate it, that lowers the barrier of entry to developing on Android. Most Java developers will be immediately comfortable with the conventions laid out in Android’s development cycle and given there’s an exceptional Eclipse plugin for Android development Java developers don’t need to learn much more than Android’s specifics in their own language, IDE and platform of choice.
There’s a mountain of Java tutorials available. Even if you’re new to Java you’re going to be hard pressed to miss out on the latest and greatest information that the platform has to offer. My searches for information on Cocoa development have met with wildly differing opinions and little consensus. In fact, I was in the C based API on my sample app to play/manage sounds until Jon mentioned there was an Objective-C based API that could do the same thing. Even Apple’s documentation was wishy-washy on the subject until I took the time to read the Cocoa Touch programming guide for Audio (not a fun read, BTW) that it even mentioned the class Jon pointed out.
On a 1-1 basis Android’s frameworks seem to be providing developers simple abstractions to every possible task that you’re going to want to perform on the device while Apple’s Cocoa Touch frameworks seem to be a mess of improvements over Cocoa, missing abstractions and idioms are published by Apple and not driven by the community using them. AGAIN- that is conjecture but that’s what I’m seeing.
Take, for instance, the following snippets to load an internal sound file reference and play it. First iPhone -
NSString *soundFilePath =
[[NSBundle mainBundle] pathForResource: sound
ofType: theType];
NSURL *fileURL = [[NSURL alloc] initFileURLWithPath: soundFilePath];
AVAudioPlayer *newPlayer =
[[AVAudioPlayer alloc] initWithContentsOfURL: fileURL
error: nil];
[newPlayer prepareToPlay];
[newPlayer setDelegate: self];
[newPlayer play];
See, it’s not complex. The syntax is simple enough (for the AVAudioPlayer class, this is not the C API which is far more complex) but things like getting a reference to an internal URI is 2 lines of chunky code that create references that I need to track now. It’s not bad, but there should be a simple way to load our references.
Let’s compare that snippet with the Android version.
MediaPlayer mp = MediaPlayer.create(this, R.raw.mySoundFile);
mp.start();
That’s it. I’m not splitting hairs over brevity; that’s not the point, the point is that the abstraction seems to be in the right place. We know we’re going to play sounds on a device. We know that those sounds are going to be local or networked. These are clear points of abstraction in OO and should be provided to the developer (IMHO).
From my perspective I get to tell the right objects to do what I want them to do and the details and minutia are encapsulated behind a nice API. If we’re on the same topic here are 2 equally good APIs first from iPhone and then from Android
UIImagePickerController *picker = [[UIImagePickerController alloc] init];
picker.delegate = self;
picker.sourceType = UIImagePickerControllerSourceTypeCamera;
// cruft leading to our delegate implementation...
-(void)imagePickerController: (UIImagePickerController *)picker didFinishPickingImage(UIImage *)image editingInfo:(NSDictionary *)editingInfo
{
// now I have image reference I can use! Sweet!
}
See, there’s an operation that I know I’m going to need to perform on a phone equipped with a camera. Once you’re familiar with cocoa’s delegate/callback system then doing something with the camera is that simple. But still, I’m interfacing with a Controller object and not the Camera or “media” object. From an MVC perspective Apple’s controllers seem pretty heavy and try as I may there’s something icky. The Abstraction is there, though which is my complaint with many of the other functions I’d expect an always connected device to abstract. Let’s look at Android’s API for doing the same thing.
Camera camera = Camera.open();
camera.takePicture(null, null, new PictureCallback(){
public void onPictureTaken(byte[] _data, Camera _camera){
//Handle the photo
}
});
So, lines of code aside they’re very similar but the Android object API is clear and uses the same idioms it has established with other objects in the system. There’s no muddy “is it a Controller or Model” confusion. To me, that’s an simple OO encapsulation that provides an intuitive API. AGAIN: my eyes, my perspective and my opinion.
For the last few points, before I go back to exploring both of these GREAT platforms. Things that have me more interested in Android at this moment than iPhone…
1: Android is open. Which means there’s a greater chance that your app will be seen on a diverse set of devices. This is a blessing and a curse. You’ll be required to handle such discrepancies but again, Google seems to have abstracted those decisions into small questions you can ask the platform in one method. But you will have to be concerned about it and I can see a legion of experts born from this very issue. Good knew is you can sell or give away your apps on your terms. Not Apple’s.
2: Testing. Java has better support for current BDD/TDD methodologies. I’m going to state conjecture as fact here. I can’t find a great BDD framework for Obj-C and who cares if I can’t use it well in cases where I’m testing C code.
3: Memory Management is a solved problem. Google knows it, you know it. the C champions will always lay claim that Garbage Collection is slower than their own hand crafted memory management techniques and that may, in fact, be true. But by what degree? What about line of business application developers? They know the value of one less thing to worry about; one less thing that can go wrong. I know obj-C 2 has an opt-in GC but I never see it in use on the iPhone and I’m not sure why. I assumed it wasn’t supported, again, someone please let me know in the comments if this is wrong.
As one who primarily has developed line of business applications and the bulk of that on the .NET platform or in Ruby, Google’s Android platform seems directly poised at the GTD crowd and Apple’s iPhone seems hell bent on restoring C++ and it’s superset Obj-C to the forefront of Alpha-Geekdom. Both are great approaches but when you couple the innovation coming out of the Android devices, the open source ease of startup, tooling support and articulate APIs; Apple needs to continue to innovate on the development side as well as the consumer side.
Apple is, hands down, the reason we’re even interested in this comparison. I love my iPhone. I’m certainly not giving up on my goal of getting in the App Store with something, ANYTHING. But I must say, if they are not cognizant of the power that Google is providing developers they may see folks piloting, prototyping and promoting Android over the iPhone.
I don’t know if it’s time for the Cocoa community to build a better boat or Apple’s but somehow, to me, that’s yet another solved problem and therefore another win for Android.
OK, Jon. I await your post clarifying all of this up for me on the iPhone side and even better, I CANT WAIT to pair with you on iPhone fun at CodeMash! ;)
Those of you who were fortunate enough to hear Uncle Bob Martin speak at Columbus Ruby Brigade last Monday are aware of the amount of wisdom that can be garnered from listening to him. If that is the case then certainly pair programming with him for the day would be equally enlightening.
Monday morning when I walked into the EdgeCase offices there in a corner was a face that I was familiar with but had never met personally. This is not unfamiliar for me, I’m usually the last person to know anyone with a reputation that precedes them. I say hello and introduce myself but as he was already pairing with our friend Adam I said hi, got a Mountain Dew out of the fridge, found a seat in the bullpen and got down to the business.
10 minutes into the day Adam has something else that has to be done for a client so we look around and Ken says: “Leon why don’t you pair with Uncle Bob on a few features”
I don’t know the app.
I don’t know what were working on.
I run to sit next to Uncle Bob.
I don’t care what we’re working on, there’s no way that I’m going to impress a man who’s literally been there and done that so it was time to sponge. Or at least I thought. Over the next 5 hours we meticulously poured over the details of what I would perceive as a simple feature to understand not just what the feature is but why we couldn’t test the particular abstraction. Uncle Bob was interested in seeing how we could test a haml view in isolation of the rest of the app and frankly I was fascinated. We were looking over APIs and playing around with how to mock state for our view just so we could ensure that numbers that were currency would be properly set to 2 decimal places.
You see, it was not that the task was simple or complex, the task was not important. What was important was how we were planning to work on the task. How were we going to cleanly isolate the functionality so that we could simply test and verify that we had, in fact, completed the task. In the end, we didn’t quite isolate the view in the way that he (and eventually I) wanted but we completed the task and Uncle Bob was clearly amused by the session that day and, as I hope, he seemed to have fun pairing with me as we ran down the rabbit hole, exploring the possibilities of our API and expanding my concept of what it means to be testable.
It’s difficult to communicate wisdom transferred; it’s difficult to work next to someone whom you’ve respected from a far for so long and package the experience in 500 words or so and I hope that I’ve been able to capture a bit of it. While I may not communicate it well now, know that it was a great experience, one that I hope to replicate again and again as I seek to improve how I approach my craft and evolve my understanding of the profession I’m in.
Thanks Uncle Bob for the great day of code! I had a blast!
So, if JavaScript ever really had a true intention, I believe that intention was to bring static HTML documents to life. I’m sure if we read the history since 1995 (give or take a year) then we’ll notice that most work with JavaScript was aimed at giving the static web a much needed shot in the arm.
To understand how JavaScript works its magic we have to dive into the DOM or Document Object Model and it’s relationship to the document being rendered to the client.
At the top of the stack we have the object that does the presenting to the user: The Window aka The browser. This is represented as the Window object. A window is presenting one document at a time (I mean, you can’t have more than one URL at once, right? Well, frames but those are children of the main document.) and therefore Window has a property of Document.
window.document
or just…
document
Why can we just call on document? Because our top level object is implicitly the window. Pretty sweet, right? Making sense? I hope you said yes. If not, we’re just looking at the HTML document you requested from the server the same way JavaScript does… as objects. Now we know we’re speaking the same dialect but what else is added?
In plain English: The DOM is an object model for traversing and manipulating documents rendered by web browsers. There is a W3C standard for the DOM and the reason that JavaScript can hurt is because it is inconsistently implemented by browsers. So developers took to writing a lot of boiler plate “browser sniffer” code to ensure that behaviors were similar for all users viewing their sites. Internet Explorer is typically dragged through the mud because it’s version 6 of the browser was exceptionally slow to adopt DOM elements and events as standard and instead continued down its own path. But why? The answer is simple. IE 4 and 5 drove innovation in the DOM/JavaScript space. IE added additional attributes and events, e.g. drag and drop
As you can imaging there are various objects representing the HTMLElements that are part of the document (and some that may not be!) so we won’t list all of them here, I just wanted to let you know the top level context in client side JavaScript (window) so that you’re not surprised but what you’re going to see when we move to the bane of client side JavaScript: Events. (this is, without jQuery or your lib of choice!)
So, working with the DOM is made stupid easy when you’ve got help in the form or jQuery or MooTools or Prototype or some other lib that equalizes the DOM implementations of various browsers. Those folks are doing great work and I encourage you to use them (I certainly do!) for your work. BUT let’s look at what Mozilla’s Firefox does with HTML events so we can see how these event objects and the implicitly passed this contextual object cause confusion to the uninitiated.
First we have to establish an event to listen for. We do this in Mozilla’s flavor of JavaScript by doing adding a “listener” to a particular event. How about a click on a button? Easy enough. :)
Here’s the HTML document we’re going to use. Save it as an html page and open that document in Firefox. Open Firebug and follow along.
OK, first up is to grab a reference to the button element in the document.
var btn = document.getElementById("clickr");
Now, let’s create a simple function that will handle clicks the user makes on “clickr”.
function ourCallback(evt){
alert(evt);
alert(this);
};
Now let’s listen for clicks on btn.
btn.addEventListener("click", ourCallback, false);
If you’ve been reading along then it should come as no surprise the to types of objects that are alerted when we run this code in the Firebug JavaScript console.
The event object sent as an explicit argument is… [object MouseEvent] The this operator at this point gets the value of the implicitly passed sender… [object HTMLButtonElement]
So our button is this because it directly broadcasted the click and all listeners know who initiated the click.
That should make pretty good sense by now but what happens if the callback function has expectation on this that we’re not going to know at runtime? Here’s a case where things can be odd and cause lots and lots of frustration, well at least for programmers in the late 90s. :) Let’s create an object that simply counts a number every second. We’ll add an interval counter that alerts that value. Sounds simple right? It is, if you know what to expect when using this. Consider the following…
var ob = {count:1, currentCount: function(){ alert("my count is "+ this.count);}}
ob.currentCount();
setTimeout(ob.currentCount, 2000);
So, what’s going to happen when we run this sample? We’ve created an object to do our incrementing (even if we don’t have an incrementer for it… details!) for us. On line 2, ob calls currentCount and then on line 3 we ask the window to tell ob to call currentCount after 2 seconds. right? well, not so much, go ahead on run it. If you’re following along you’re going to see the following message alerted to the window:
my count is 1
my count is undefined
OH NOES!!! That’s right, friends, let’s read these same 3 lines of code the way JavaScript did… in plain english:
“Ok, the programmer created an object with one property and one method and assigned it to a variable named ‘ob’. Cool. I can do that. Next the programmer is asking ob to call currentCount. Cool, no problem. Finally they want the window to call currentCount in 2 seconds. done and done!”
You see, here we have our first curiosity caused by the simplicity and power of JavaScript. Remember when we said functions where higher order and first class citizens? Remember how “this” refers to the contextual object? Well if you do, then in plain english, what is happening here is that we’re delegating the function defined in ob.currentCount which is
function(){ alert("my count is "+ this.count);}
So, when we call the setTimeout method we’re just caching the function signature and not any reference to the parent object that references the function. So when the function is called after 2 seconds what is really being called is this:
window.currentCount();
But that’s not what we mean. We want ob to call it. SO, let’s not forget that other great feature of JavaScript: closures. Let’s instead, curry the exact state that we want in the form of a closure to be called at the timeout.
setTimeout(function(){ob.currentCount();}, 2000);
Now when you run line 3, you should see the right alert message. WOW! Isn’t JavaScript cool?! I think so! Anyway, I hope that goes a long way to helping you understand what’s going on in the browser when you’re using JavaScript. Even though libraries like jQuery let us forget about these particulars when we code it’s nice to know what’s going on under the covers. :)
OK, take a deep breath, hold your nose and get ready to finally understand this.
When my friends first dive into JavaScript the this operator throws people for a major curve. To really understand what it is I’m going to try my best to distill its essence into a simple explanation that while not fully encompassing the nuances of “this” use should go along way to helping you understand the resulting behaviors of using this.
From Mozilla:
The this keyword refers to the context object aka the current object.
See, that’s simple right? Well, not really. The problem presents itself when we add in JavaScripts scoping rules (hopefully in this series soon!).
OK, first this being a pointer to the context object is passed into functions implicitly. That’s right folks, it’s not sitting there waiting in the scope that it was originally created in, no, it’s actually passed through to functions auto-magically when you call a function. Consider the following code running in a browser context.
var frank = {name:"Frank"};
var betty = {name:"Betty"};
function sayMyName(){
document.write(this.toString()+"'s name is "+this.name+"<br>");
}
betty.sayMyName = frank.sayMyName = sayMyName;
All we’ve done here is introduce a few new objects, frank and betty, a globally accessible function called “sayMyName” and gave both betty and frank properties that will call that function. So, if we run this we’re going to see…
[object Window]'s name is
[object Object]'s name is Betty
[object Object]'s name is Frank
Ah, did you see what happened there? the first time we call it the current top level context in the browser is actually the Window object! It was passed to our function (because there’s always a caller) implicitly. So, when betty calls the function the betty object is the current object making the call. Therefore, we see it’s something of type Object (remember where we inherit from?) and that it responds to name with Betty. Frank is the same.
The lesson here is that this is not set when the function is defined it’s determined when the function is executed and the current contextual object is this. So, where does this mess with people’s heads? Check this example out…
Let’s run this sample and then run it again with the commented out line… well back into the code. That should bring this crazy subject clearly into light.
The important thing to remember is that this is a reference to context object. When we transfer the context to a variable in the top level (global) space we’re really adding that as a property on Window in the case of browser scripting. So, the first time we call it, name is not defined, but if you call it a second time, you’ll notice that name is updated to the variable and since window now has a name value it’s printed to the screen.
There’s a whole host of variations on this very wide topic but I believe if you understand exactly what this is referring to it can help you to quickly identify when it’s been used in an unintentional way in your JavaScript code. In fact, having written this part, I believe we could do another follow up on the quirks of this in the browser which is where most will have context to it. Events… yes… events + this can be tricky. Stay tuned for that. :)
For a few years the alpha geek crowd has been debating (read: justifying their own preferences) what type of Object Oriented Language features are the most developer friendly. I never have the heart to remind these folks that everyone experiences the world differently and some will always understand class based OO and others want something else. Well, one of those “something else” is used in JavaScript: Prototype Based Objects.
Given my known readership and audience I’m going to assume you’re all familiar with a class based language. I’m going to use C# in this example but the comparison should hold up for similar languages like Java.
Let’s take a look at defining a class with with to create objects (a.k.a. instances). My example is a simple model that most folks can relate to… Person!
C#
Now let’s do the same thing in JavaScript…
JavaScript
These examples are nearly identical from the standpoint that they represent the same data. They are 2 ways of saying the same thing, one in class based way and the other in a prototype based way. By assigning the proto attribute on a prototype based language you’re essentially saying this is your new “parent”, thus providing the object the features and functionality.
Now, in the JavaScript version we did not create a constructor for creating those objects but we can do that too if we like…
And finally, remember that our functions are first class citizens and can be used to establish members for an object.
Now, proto is not the idiomatic why of defining this inheritance. Most the time you’ll see the more common “prototype” property. Why did I show the other? Just giving you options. Here’s a slight variation on what we’ve done using the prototype object.
As you can see, this is very close to the version I presented and is more common. It’s nice to know but methods just for your own reference. I personally prefer the latter but that could be habit more than preference.
OK, well, that’s basically it for now from a 500000 foot view. Well talk more about this awesome topic soon!
JavaScript is an object oriented scripting language.
It is a dialect of the ECMAScript standard.
It is dynamic, loose typed and prototype-based.
It has first-class functions. That means a function is an object in JavaScript. You can treat it as such.
If you’re looking for some history of the language and an introduction of the “why” check out Mozilla’s A re-introduction to JavaScript And once you’ve ready that or if you’re skipping it please continue…
It’s time to say hello to one of my favorite languages again. This time from my perspective. If there’s something you love, I believe you have little reason not to share it with the world. Do I want everyone to start programming in JavaScript? Well, that’s a lofty goal and not really my point here. My point is more to share my passion and clear up a few misconceptions.
So, play along with me friends… first task is to create a way to play. There are many but I’m going for low barrier for entry. Open firefox and download (if you don’t have it) firebug.
Now that you’ve got a way to play with JavaScript and the DOM, let’s start building a better understanding the features of the language. Create a blank HTML page and open it in Firefox. This will be the blank canvas with which we experiment with the language in a REPL style system via Firefox and Firebug. Let’s play with the loose type system first. Try assigning a variable a numeric value and then assign the same variable a string.
See? Type is loose.
Wanna see why we functions are “first-class” or “objects”? Let’s create a function. The syntax for creating a function is…
function [name](params[,n]){
//method body
}
Now, why is name optional? Because functions, even without a name, are still objects. A common practice is to keep the function anonymous but assign it to a variable for later use.
var sayHello = function(say){alert(say);}
If you type both types of function into firebug you’ll see…
That they can be called the same way and as objects can be passed around just as you would any other type of object.
Internet darling jQuery makes extensive use of this feature in its implementation. It typically calls this practice “accepting a callback” which is just another way of saying “give me a function to call when I’m done doing whatever I’m doing and I’ll call it. I will also pass that function data related to my initial task.”
Finally, what does it mean to be “prototype based”? Well, that’s where we’re going to start Part 3, so until next time write something fun using Firebug and JavaScript. Try using the DOM’s document object to write something to the page.
See, good times. gooooood times. :)
This is a tough one. I don’t generally like to discuss the built in objects of a language because they are easily searched for. Instead I’ll list a few and then talk about using them as that’s a little more subjective and worthy of discussion and continual review.
Quick Reference:
- Numbers
- Strings
- Booleans (true|false)
- Objects
- undefined and null
- Date
- Regular Expression
- Functions
- Array
So, yeah, mostly these will function as you’d expect them to. Therefore, as I stated before, let’s skip that. Instead let’s discuss some fun things that are legitimately ambiguous to developers sharpening their JavaScript knives.
One of the things that throws folks is the notion of object being a specific type and staying that way after being initialized from a class. But in JavaScript objects are more like Hashes in Ruby or Dictionary<key, value> in C#. If you make that mental connection then seeing the JavaScript Object Notation (or JSON) will provide context for what you’re working with.
If you remember from part one, our first object creation was done as such:
If you look the object is created as it’s defined using the object notation which looks remarkably familiar to just some key-value collections mentioned about. When doing this you can then access those properties on the person instance using the dot or [] notation
person.name
person["name"]
both are fine ways to access the properties on your objects. So, knowing that, there are a couple of ways to create new objects in JavaScript they both establish a direct relationship to the super “Object” class.
var person = new Object();
var person = {};
{} is object notation so by specifying it on the right side of the assignment operator (=) yields a new Object instance to person.
There are many different ways to use the properties of this new object (which we mentioned earlier see new/[]) but the important thing to note is that since our objects have no concrete relationship to strong types we can access and assign properties on our objects at will.
person.likes_cake = true
if perfectly legal even if the member “likes_cake” is not a property on person. This allows for some real dynamic behaviors to occur at runtime. So, why would you use [] vs the . property syntax? Well, if you’re a daring individual you could assign properties that are named the same as reserved keywords. for example, “if” is a reserved keyword in JavaScript so just coming out with
var letter = {};
letter.for = "leon@foo.com"
is not going to work. BUT if use the [] property notation we can!
var letter = {};
var letter["for"] = "Leon@foo.com"
pretty cool stuff there! I don’t know that you’d want to do it from an idiomatic standpoint but it’s possible if you’d like to have it.
Functions are important to understand and as a bonus they are remarkably simple to understand. Basically, here are the “rules” to live by…
AND as a bonus every function gets a few properties that may be of value. One of my favorites is the “arguments” object. It’s just an array of all the arguments that were passed to the function. Let’s play a bit with it.
pretty excellent stuff, right? many languages share this feature but I enjoy the compact way that JavaScript lets you extend the use of a functional all the way to runtime. Now that’s fun but with all languages that provide higher order functions it becomes very important to understand how they can be called recursively. Tail recursion (in short: last part of the function calls itself again until told not to) is an important concept but how do you know what do call again if your function has no name? Well, the answer lies in the arguments object. Let’s write a small tail recursive anonymous function. We’ll assign it so that we can call it a first time but since it doesn’t know what it’s own name we’ll use the arguments object’s callee property to call the method until we’re done. Type along with me using FireBug…
In there we see 2 things: first that the callee property is a little more than just a pointer to the current function, it also is an object that is persisted across the function calls so we were able to use that to hold a reference to a number as we counted down from the first argument that was passed in. Pretty cool, right!? That’s some wonderful, powerful introspection and provides JavaScript some of that signature magic that makes me fall in love with it over and over again.
Next we’ll take a look at arguably the most powerful feature in JavaScript and one that has gained a lot of exposure in other languages recently: closures.
Now closures have variation of definition and the minutiae of that semantic debate are not in the scope of this article. Instead let’s go with the following simplistic definition: closures maintain the scope of the variable at the time that the function is created and persisted after you believe they have fallen from scope. A simple example of this “scoping” would be using an inner function to establish an outer scope while establishing an inner scope for later use.
function greeting(prefix){
return function(name){
return prefix + " " + name;
};
}
helloTo = greeting("hello there,")
document.write(helloTo.toString());
document.write("<br><br>");
document.write(helloTo("Leon"));
let’s run this code to examine the results in our REPL environment: FireFox+FireBug :)
That’s enough for now, friends!
Well, I’ve had a few requests for the slides on this one. So, without further adieu, I present the slides for my cucumber introduction.
I will also be presenting this topic at CodeMash in January and the Cleveland Ruby Brigade on 11/30/09. So, stop on by and let’s talk BDD in person.
Read this. Don’t skim, read the whole thing. Then come back here. I have a thought that I wish to express here and it may be controversial to some. You’ve been warned.
The issue in this cashto’s blog entry hovers mostly around platform and language. Simply put, unit testing is the art of testing small units of code. In Test Driven Development you do not write new code until you’ve written a test that clearly articulates your intent. You essentially use the code that you plan to implement via a test and only then write the implementation behind the api that you’ve just crafted. That process has a side effect, commonly referred to as “Emergent Design”. One commonly documented side effect of Emergent Design is that it encourages highly modular, de-coupled sections of code that have high cohesion and low coupling. In some circles, these are indications of a healthy code base.
Now, having spent a great deal of time in C# and about a year doing Ruby professionally, I can say that the approach that I prefer to take, BDD, is significantly more complex in a static language on a proprietary platform than when writing similar software in a dynamic language on an open platform. Therein lies the difference. When I read articles like this, I see them almost universally from the static language camp. By camp, I mean to imply that these are folks that have chosen to work in static typed languages on open and closed platforms. The bemoan the time it takes to craft tests, ponder their significance and after some frustrating exploration chalk it up to another fad but ivory tower academics. The problem with this assumption is that these techniques are solving big problems for folks like me who, in a dynamic language, needs a little more coverage to ensure that the expectations I’ve defined for the system are being met. Unit testing provides this. If I were interoperating with SharePoint’s object model (and I have… extensively) then I would not worry about unit testing. Why? Because the effort that it takes to isolate the units provides diminishing returns against how I will write it. So, if you want to skip it there… I’m not gonna hold it against you. BUT, if you write a Ruby gem that I plan to use and I install it and run the tests and there are no tests then you’re not playing nice and I WILL hold it against you.
Yes, my expectations for cultures and communities is slightly different. That’s me. that’s my experience. How about an analogy? In static languages, I believe that Dependency Injection is a valid and powerful pattern. In Dynamic languages it’s a waste of time that provides no value. Does that mean that DI is bad because I prefer a dynamic language? No, of course not. It only means, given my circumstances, DI is worthless. Is DI worthless? no. Make sense? Yes. Sound overly politically correct? Yes.
This is all to provide the following context: The blog above was written by a man who works for Microsoft on Microsoft products. Given their slow uptake for developer testing support and de-emphasis on unit testing and TDD(ing) .NET projects. That’s the experience that has shaped cashto’s reality and you should know that when you read that article. It’s no wonder, to me, that when developers look to gain from the experiences of developers outside their home platform they grow frustrated and no amount of practice ever seems to make the problem go away. The reason is not that they don’t understand or haven’t tried the idioms they see rather that culturally, it is not valued in the same way that watching the compiler fail is, or in the case of ASP.NET, the same way pressing F5 and getting a mini browser REPL going is.
When I worked, briefly, at Telligent their code base was written using that “Microsoft” model. I often tried, sophomorically, to get the entire team to see the benefits of testing, because I was needed it in my own workflow. As the other developers either sided with me or against me I noticed how smart people with lots of experience can simple never come to an agreement. If I wasn’t laid off, then it was clear to me that we were probably never going to be a match made in heaven. That’s not a slight on Telligent, they were a great employer and I got to work with some very highly respected developers in the Microsoft domain. It simply proved to me, that I didn’t belong there. So, I joined EdgeCase. Suddenly I’m not fighting anymore. I’m not arguing. I’m back to the business of writing software and not fighting ideological battles and writing “memos”.
So, is it “Ok not to write unit tests”? Sure, of course it is! If you wish to do so, it’s quite alright. The chances are, though, you will find it difficult to relate to and work with an increasing number of talented software craftspeople who believe in automated testing as a fundamental aspect of their workflow and that would be the real shame.
Hey, if you would like to follow along today during my 1:00 talk please feel free. If you missed it, here are the slides, I’ll publish the code samples some other time.
