… like I said … “half-jokingly”

I give you the Slap-Slides, proof of concept! (no audio)

The code is written in Johnny-Five, running in NodeJS, connected to an Arduino Nano. I bought the cheapest veggie-chopper I could find at my local grocery store, ripped the blade out and mounted a 10k button on to the plate that the blade was previously on.

I’ll be soldering this in to a proper set up housed entirely in the veggie-chopper, and stabilizing the button (right now it fails every 2 or 3 clicks because of the mounting in the veggie chopper.

UPDATE: I have it nearly complete.

I have the primary circuitry soldered on to a component board, and some holes cut in the housing in order to clean up the entrance of a USB cable in to the chopper.

Here’s a series of pictures that show the components and assembly… making code skinny, one slap at a time :D

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

It was almost a year ago that I announced a book on building Backbone.js plugins. Since then… nothing. Well I finally got tired of sitting on it and over the weekend I made a bunch of edits, cleaned up a lot and released the first 6 chapters of the book via Leanpub!

https://leanpub.com/building-backbone-plugins

Learn the how and why of building plugins for Backbone.js. This book provides first hand lessons learned, best practices, and patterns for building flexible add-ons and frameworks components, based on my experience – both success and failure – from the last few years of working with Backbone and building plugins for it!

On Buidling Backbone Plugins

I’ve built more than a handful of Backbone related tools, plugins and add-ons in my time working with it. From nearly the beginning of my exploration and use of Backbone, in fact, I’ve been looking for and developing better methods of handling common tasks and solving the same problems. This has led me to create plugins and frameworks such as MarionetteJS (Backbone.Marionette), Backbone.Picky, Backbone.ModelBinding and many more – some published on my Github account, many unpublished and created for a specific client application.

In all of the plugins and add-ons that I’ve built, there have been lessons learned. The continued success of frameworks like MarionetteJS provide many useful insights in to how to properly create view layers and additional object types that support the creation of large Backbone application. Equally as valuable, though, failures such as Backbone.Modelbinding provide insight in to the patterns and practices that should be avoided when creating add-ons. Or, at least, they illustrate some of the scenarios and circumstances in which these patterns and practices fall apart.

A Work In Progress

This book is a work in progress, with 6 chapters roughly completed at this time, 3 or 4 additional chapters in rough draft, and one or two chapters planned beyond that. Expect this book to change over time, with edits and additional chapters being added. Early adopters will be able to purchase the book at a discounted price. The amount of demand I am seeing from early adopers will largely determine the schedule that I keep for additional releases, and the eventual price that is charged for the finished product.

https://leanpub.com/building-backbone-plugins 

Be sure to follow the book on twitter for updates, as well: @BackbonePlugins

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

The probe is a 100K “meat probe” (aka “thermistor”) that I took from a store bought meat thermometer. Something like this replacement probe would work great. It’s a bit of a guessing game as to wether the probe is a 10k or 100k Ohm probe. I tried 10, 100, 1k, 10k and finally 100k resistors in my thermistor setup. You can read about thermistor setup on the Arduino playground, and at Hacktronics.

The Arduino code produces a JSON document when I make an HTTP request to it. The software is built with Kendo UI Mobile, and reads the JSON document on a 1 second interval.

I’ll be blogging about this more, and hopefully soon, with plans on going through a step by step “how I learned” series – at least, that’s the plan. For now, this little teaser video should give you a good idea of what can be done with an Arduino, some simple parts from a store, and a mobile app framework like Kendo UI Mobile. :)

… I need to learn how to optimize my C code for battery life. I’ve run that 9volt battery maybe 10 or 20 minutes, total, and it’s already dead. :P

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

I quietly released it over the weekend, and I’m glad I did. I already had a bug report and have released v1.0.1 to fix it. :D

The last few years of working on Marionette have been tremendously fun, exciting, frustrating at time, and have provided much more work and opportunity for me than I had ever imagined. I started this project out of need, and hoped that it might help a few people out – at least show them what could be done and give them ideas on how to do it. I never expected that this project would have 1/10th the number of stars it has on Github, or that this project would lead to working with dozens of amazing companies, travelling around the world, create new friendships, and land me some awesome speaking opportunities on podcasts and at conferences! 

What’s New

There’s a ton of new things that have happened since I started the 1.0 release candidates. And actually, going in to “release candidate” model was probably the worst mistake I’ve made with Marionette, so far. I had far too many breaking changes, far too many times for it to really be a release candidate series. But things are stable now, and have been for a bit. There were a few additions and breaks in this release, some of which came from dependencies.

You can read the complete change log and upgrade guide in the repository, but I want to highlight a few of the notable things quickly.

Backbone.Wreqr Updates

Backbone.Wreqr is an integral part of Marionette and helps to provide a lot of the communication infrastructure for scaling applications. 

In the latest release of Wreqr, I’ve renamed “addHandler” to “setHandler” for all Wreqr objects. There was confusion around the name “addHander” as it implied the ability to add multiple handlers. Since none of Wreqr allows multiple handlers for any one registered name, I changed this to “setHandler”. Anyone updating to Wreqr v0.2.0, along with Marionette v1.0.0, will need to account for this.

I’ve also made the commands somewhat persistent when there is no handler currently registered. Several people noted that they were running in to situations where a command needed to be executed, but due to the order of module loading being unpredictable, the handler wasn’t there. To fix this, a command can be executed whether or not the handler is available. As soon as the handler is available, the actual execution of the command will take place. Commands will persist in memory, for the life of the page. Refreshing the page or navigating to another page will destroy the not-yet-executed commands.

Marionette.RegionManager

One of the most requested features in recent times has been the ability to add and remove regions from layouts. I set out to solve this and realized that half of the code I needed was already in the Application object, and the other half was in the Layout object. So I consolidated most of this code in to a single object called RegionManager. Both the Application and Layout now use a RegionManager to manage their regions. This allows a more consistent way of managing the regions, and provides all of the add and remove functionality that is needed, on both.

STICKERS!!!!

WOOO! STICKERS!!! :D

You can order yours from DevSwag. They are providing order management and fulfillment for stickers, for Marionette and many other amazing open source projects.

Semantic Versioning: A Goal

I have a goal, moving forward, of using Semantic Versioning for the version numbers. I don’t think I can promise perfect semantic versions, though, for a few reasons. First off, this is my first project to hit v1.0. I know I’m going to make mistakes and screw up some little detail here and there. But for the most part, I plan on following semver. Secondly, and more importantly, though, Marionette relies on other libraries which have their own release cycles. Sometimes releases coincide. Other times they don’t. Sometimes they break Marionette, other times they don’t. This will make it challenging to follow semver.

What’s Next?

It’s been a whirlwind ride with near constant updates along the way. I’ve learned a ton about JavaScript and running an open source project. And this is the first time I’ve pushed an open source project to 1.0, so I’m sure there are still a ton of lessons left to learn.

There are still more than 50 tickets open in the Marionette repository, and a lot of things that I want to do to help re-stucture some of the ugly parts. I want to tear apart Modules, for example, and create separated namespacing, sub-applications and components. There are a lot of other feature requests and issues reported that need big changes, too. I’m looking forward to where Marionette will head, and hope to continue to build a strong community around it – including a more active core contributor team.).

Thank You!

Yes, it’s the grammy-award speech time! Someone start the “wrap it up” timer…

I owe an especially large thanks to Jarrod Overson, Matt Briggs, Brian Mann and Tony Abou-Assaleh. These guys have been a great core team to bounce ideas around with, to help out with issues, and provide needed support and feedback. And to Ruben Vreeken for all the work he puts in to the Google group, answering questions. :)

Marionette wouldn’t be what it is without the amazing contributors. Everyone that has contributed in any way – answering questions in the google group, sending issue reports, ideas, pull requests, writing blog posts and articles, screencasts, and talking at user groups and conferences. I’m still and continuously amazed at how much has been done in the community with this library. Thank you all!

A special thanks to Backbone, of course, which is what got me into JavaScript again, and allowed me to build Marionette. Thank you to MedienFreunde for the amazing logo and website.

And thank you to all of the awesome people building apps with Marionette. Projects like Halo Waypoint, Redbull Music Academy, and StubHub are among the most widely known systems built with Marionette – then there’s the three error reporting / analytics tools: AirBrake.io, RayGun.io and CrashLytics. But there are so many more out there, still It’s been awesome seeing Marionette in all these places, and I’m looking forward to seeing where it goes from here! :)

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

When it comes to the Mediator and Event Aggregator patterns, there are some times where it may look like the patterns are interchangeable due to implementation similarities. However, the semantics and intent of these patterns are very different. And even if the implementations both use some of the same core constructs, I believe there is a distinct difference between them. I also believe they should not be interchanged or confused in communication because of the differences.

It’s All About Logic

The TL;DR version of this article is this: where does the logic live? An event aggregator has no logic, other than forwarding events from a publisher to a subscriber. A mediator, on the other hand, encapsulates the potentially complex logic of coordinating multiple other objects and/or services, to accomplish a goal. A mediator contains real application / business / workflow / process logic.

This is the line I’m drawing in the ever-shifting sands of implementation details and fuzzy heuristics.

Event Aggregator

The core idea of the Event Aggregator, accoring to Martin Fowler, is to channel multiple event sources through a single object so that other objects needing to subscribe to the events don’t need to know about every event source.

Backbone’s Event Aggregator

The easiest event aggregator to show is that of Backbone.js – it’s built in to the Backbone object directly.

var View1 = Backbone.View.extend({
  // ...

  events: {
    "click .foo": "doIt"
  },

  doIt: function(){
    // trigger an event through the event aggregator
    Backbone.trigger("some:event");
  }
});

var View2 = Backbone.View.extend({
  // ...

  initialize: function(){
    // subscribe to the event aggregator's event
    Backbone.on("some:event", this.doStuff, this);
  },

  doStuff: function(){
    // ...
  }
})

In this example, the first view is triggering an event when a DOM element is clicked. The event is triggered through Backbone’s built-in event aggregator – the Backbone object. Of course, it’s trivial to create your own event aggregator in Backbone, and there are some key things that we need to keep in mind when using an event aggregator, to keep our code simple.

jQuery’s Event Aggregator

Did you know that jQuery has a built-in event aggregator? They don’t call it this, but it’s in there and it’s scoped to DOM events. It also happens to look like Backbone’s event aggregator:

$("#mainArticle").on("click", function(e){

  // handle the event that any element underneath of our #mainArticle element

});

This code sets up an event handler function that waits for an unknown number of event sources to trigger a “click” event, and it allows any number of listeners to attach to the events of those event publishers. jQuery just happens to scope this event aggregator to the DOM.

Mediator

A Mediator is an object that coordinates interactions (logic and behavior) between multiple objects. It makes decisions on when to call which objects, based on the actions (or in-action) of other objects and input.

A Mediator For Backbone

Backbone doesn’t have the idea of a mediator built in to it like a lot of other MV* frameworks do. But that doesn’t mean you can’t write one in 1 line of code:

var mediator = {};

Yes, of course this is just an object literal in JavaScript. Once again, we’re talking about semantics here. The purpose of the mediator is to control the workflow between objects and we really don’t need anything more than an object literal to do this.

var orgChart = {

  addNewEmployee: function(){

    // getEmployeeDetail provides a view that users interact with
    var employeeDetail = this.getEmployeeDetail();

    // when the employee detail is complete, the mediator (the 'orgchart' object)
    // decides what should happen next
    employeeDetail.on("complete", function(employee){

      // set up additional objects that have additional events, which are used
      // by the mediator to do additional things
      var managerSelector = this.selectManager(employee);
      managerSelector.on("save", function(employee){
        employee.save();
      });

    });
  },

  // ...
}

This example shows a very basic implementation of a mediator object with Backbone based objects that can trigger and subscribe to events. I’ve often referred to this type of object as a “workflow” object in the past, but the truth is that it is a mediator. It is an object that handles the workflow between many other objects, aggregating the responsibility of that workflow knowledge in to a single object. The result is workflow that is easier to understand and maintain.

Similarities And Differences

There are, without a doubt, similarities between the event aggregator and mediator examples that I’ve shown here. The similarities boil down to two primary items: events and third-party objects. These differences are superficial at best, though. When we dig in to the intent of the pattern and see that the implementations can be dramatically different, the nature of the patterns become more apparent.

Events

Both the event aggregator and mediator use events, in the above examples. An event aggregator obviously deals with events – it’s in the name after all. The mediator only uses events because it makes life easy when dealing with Backbone, though. There is nothing that says a mediator must be built with events. You can build a mediator with callback methods, by handing the mediator reference to the child object, or by any of a number of other means.

The difference, then, is why these two patterns are both using events. The event aggregator, as a pattern, is designed to deal with events. The mediator, though, only uses them because it’s convenient.

Third-Party Objects

Both the event aggregator and mediator, by design, use a third-party object to facilitate things. The event aggregator itself is a third-party to the event publisher and the event subscriber. It acts as a central hub for events to pass through. The mediator is also a thirdy party to other objects, though. So where is the difference? Why don’t we call an event aggregator a mediator? The answer largely comes down to where the application logic and workflow is coded.

In the case of an event aggregator, the third party object is there only to facilitate the pass-through of events from an unknown number of sources to an unknown number of handlers. All workflow and business logic that needs to be kicked off is put directly in to the the object that triggers the events and the objects that handle the events.

In the case of the mediator, though, the business logic and workflow is aggregated in to the mediator itself. The mediator decides when an object should have it’s methods called and attributes updated based on factors that the mediator knows about. It encapsulates the workflow and process, coordinating multiple objects to produce the desired system behaviour. The individual objects involved in this workflow each know how to perform their own task. But it’s the mediator that tells the objects when to perform the tasks by making decisions at a higher level than the individual objects.

An event aggregator facilitates a “fire and forget” model of communication. The object triggering the event doesn’t care if there are any subscribers. It just fires the event and moves on. A mediator, though, might use events to make decisions, but it is definitely not “fire and forget”. A mediator pays attention to a known set of input or activities so that it can facilitate and coordinate additional behavior with a known set of actors (objects).

Relationships: When To Use Which

Understanding the similarities and differences between an event aggregator and mediator is important for semantic reasons. It’s equally as important to understand when to use which pattern, though. The basic semantics and intent of the patterns does inform the question of when, but actual experience in using the patterns will help you understand the more subtle points and nuanced decisions that have to be made.

Event Aggregator Use

In general, an event aggregator is uses when you either have too many objects to listen to directly, or you have objects that are unrelated entirely.

When two objects have a direct relationship already – say, a parent view and child view – then there might be little benefit in using an event aggregator. Have the child view trigger an event and the parent view can handle the event. This is most commonly seen in Backbone’s Collection and Model, where all Model events are bubbled up to and through it’s parent Collection. A Collection often uses model events to modify the state of itself or other models. Handling “selected” items in a collection is a good example of this.

jQuery’s on method as an event aggregator is a great example of too many objects to listen to. If you have 10, 20 or 200 DOM elements that can trigger a “click” event, it might be a bad idea to set up a listener on all of them individually. This could quickly deteriorate performance of the application and user experience. Instead, using jQuery’s on method allows us to aggregate all of the events and reduce the overhead of 10, 20, or 200 event handlers down to 1.

Indirect relationships are also a great time to use event aggregators. In Backbone applications, it is very common to have multiple view objects that need to communicate, but have no direct relationship. For example, a menu system might have a view that handles the menu item clicks. But we don’t want the menu to be direcly tied to the content views that show all of the details and information when a menu item is clicked. Having the content and menu coupled together would make the code very difficult to maintain, in the long run. Instead, we can use an event aggregator to trigger “menu:click:foo” events, and have a “foo” object handle the click event to show it’s content on the screen.

Mediator Use

A mediator is best applied when two or more objects have an indirect working relationship, and business logic or workflow needs to dictate the interactions and coordination of these objects.

A wizard interface is a good example of this, as shown with the “orgChart” example, above. There are multiple views that facilitate the entire workflow of the wizard. Rather than tightly coupling the view together by having them reference each other directly, we can decouple them and more explicitly model the workflow between them by introducing a mediator.

The mediator extracts the workflow from the implementation details and creates a more natural abstraction at a higher level, showing us at a much faster glance what that workflow is. We no longer have to dig in to the details of each view in the workflow, to see what the workflow actually is.

Event Aggregator And Mediator Together

The crux of the difference between an event aggregator and a mediator, and why these pattern names should not be interchanged with each other, is illustrated best by showing how they can be used together. The menu example for an event aggregator is the perfect place to introduce a mediator as well.

Clicking a menu item may trigger a series of changes throughout an application. Some of these changes will be independent of others, and using an event aggregator for this makes sense. Some of these changes may be internally related to each other, though, and may use a mediator to enact those changes. A mediator, then, could be set up to listen to the event aggregator. It could run it’s logic and process to facilitate and coordinate many objects that are related to each other, but unrelated to the original event source.

var MenuItem = Backbone.View.extend({

  events: {
    "click .thatThing": "clickedIt"
  },

  clickedIt: function(e){
    e.preventDefault();

    // assume this triggers "menu:click:foo"
    Backbone.trigger("menu:click:" + this.model.get("name"));
  }

});

// ... somewhere else in the app

var MyWorkflow = function(){
  Backbone.on("menu:click:foo", this.doStuff, this);
};

MyWorkflow.prototype.doStuff = function(){
  // instantiate multiple objects here.
  // set up event handlers for those objects.
  // coordinate all of the objects in to a meaninful workflow.
};

In this example, when the MenuItem with the right model is clicked, the “menu:click:foo” event will be triggered. An instance of the “MyWorkflow” object, assuming one is already instantiated, will handle this specific event and will coordinate all of the objects that it knows about, to create the desired user experience and workflow.

An event aggregator and a mediator have been combined to create a much more meaningful experience in both the code and the application itself. We now have a clean separation between the menu and the workflow through an event aggregator. And we are still keeping the workflow itself clean and maintainable through the use of a mediator.

Pattern Language: Semantics

There is one overriding point to make in all of this discussion: semantics. Communicating intent and semantics through the use of named patterns is only viable and only valid when all parties in a communication medium understand the language in the same way.

If I say “apple”, what am I talking about? Am I talking about a fruit? Or am I talking about a technology and consumer products company? As Sharon Cichelli says: “semantics will continue to be important, until we learn how to communicate in something other than language”.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

The Worst Part

The worst parts of the constant rejection include not getting any feedback on why, and the constant growing self doubt. But the absolute worst rejection was from CodeMash last year, where they passed me up in favor of some other guy that wanted to do a Marionette session. I heard reports that it didn’t go well… and they chose this guy over me, the creator of Marionette. That one still stands out as the most crushing rejection.

But enough self-pitty-crap. You’re here the find out WHY and how to fix it, right?

The Submission

I ended up posting one of my recent submissions to a gist so that I could get some actual feedback. This is the basic session submission information that I’ve been using for a while now. I change it up from here, based on the specific talk that I’m going to give, but it generally looks like this:

Scaling JavaScript Apps With Backbone And Marionette

Nearly everyone understands how to build a simple JavaScript application these days. From the classic “Todo” JavaScript app, to simple forms-over-data jQuery apps, we’ve all been around that block a few times. With the recent explosion of JavaScript MV* tools and frameworks, though, many of us find ourselves in over our heads, looking at patterns and practices that work well for small applications and pages but fail when scaling to anything substantial.

In this session, Derick Bailey will give you an introduction and walk through of many of the patterns and practices that your JavaScript applications need to be scalable. You’ll learn why copying Ruby on Rails’ pattern of “Models”, “Views” and “Controllers” folder names is wrong for scaling JavaScript apps, and how to correct that . You’ll learn about the necessity of separating the various concerns of your application. You’ll learn about patterns that aggregate and coordinate functionality from other parts of the system, how and when to properly decouple disparate areas of your application through messaging patterns, and more. And all of this will be illustrated with Backbone, MarionetteJS and additional plugins and patterns that can give you an edge in creating scalable applications in JavaScript.

I asked people to tear this apart for me, and tell me what I have been doing wrong. I got exactly what I wanted, and I have a lot of great tips to move forward, now. 

The Raw Responses

There’s a lot of useful tips in the raw responses, and lessons that can be picked from the responses. Rather than just trying to summarize things, though, I’m just going to post the responses directly and add my reactions.

@derickbailey I’ll be honest, it’s the beard man. They are Jealous of your testosterone.

— Scott Koon (@lazycoder) March 15, 2013

Ok, Scott’s probably right. My beard is amazing. But it’s probably more likely:

@derickbailey Ok, I’ll be actually honest here. I have no idea WHY code on the client needs to scale past a single user?

— Scott Koon (@lazycoder) March 15, 2013

Here’s one of the problems: semantics. “Scalability” is an over-used and abused word these days. When I say “scalability” in that abstract, I mean scaling to 10′s of thousands of lines of code, dozens of feature areas, sub-applications and general code size. I’m not referring to number of users since this all runs on client-side, one-person-at-a-time browsers. 

@derickbailey True, but you don’t say that in the abstract. I’m guessing you mean tons of data on the client w/complex cardinality.

— Scott Koon (@lazycoder) March 15, 2013

Dually noted, and something I need to clarify in my abstract.

@derickbailey @jbogard @robconery Needs more excitement! Get me excited about something!

— Kelly Sommers (@kellabyte) March 15, 2013

This is more likely the largest issue, and is the most common thread of feedback that I got. I spent years learning to take the emotion and extraneous fluff out of my written communications because I worked for large corporations where CEO’s wanted logical justification for me spending $100,000 on servers and software. Hand-waving doesn’t go over well in that environment, but apparently it’s what you need in a conference submission.

Rob Conery responded to my gist, with this:

##Taking The Suck Out of Javascript with MarionetteJS

Many have heard of Single Page Applications and, even though most of us in the room might not admit it, have experimented with the idea late at night… only to face the inevitable self-loathing and vacant, soulless feeling the next day. In this talk Derick Bailey will show you a happier path for building Single Page Applications, using Marionette together with BackboneJS.

Marionette helps to structure your Javascript applications – doing the things you don’t want to do (or have tired of doing thousands of times over) – and it won’t leave your code feeling bloated and lifeless.

This sparked a small response line in twitter:

Even if it bums people out, it’s a much more exciting and entertaining abstract. I would go to this session.

@robconery @kellabyte @derickbailey just do what jon skeet did in his abstract “I’M JON SKEET. SCIENCE BITCHES!!”

— Jimmy Bogard (@jbogard) March 15, 2013 

hmm… I’m considering this, though I think Jon Skeet might have problems with me claiming to be him. :D

@derickbailey @jbogard @robconery the abstract is too long. I liked the direction Rob was heading in the comments

— Chad Myers (@chadmyers) March 15, 2013 

Also very true. Anyone that has read me blog or articles knows that I have a hard time being concise. I definitely need to work on the length of abstract, which would also help move it toward the goal of more excitement. Less to read means I have to pack more information and punch in to fewer words.

In a separate email conversation, Steve Smith (@ardalis) had this to say:

Rob’s comment is great. Short, exciting, attention-getting abstracts are the best, but they’re not easy to write. What’s at least as important to those selecting sessions for an event is the speaker themselves. If you’re well-known, especially for the topic, that matters far more than the abstract. It’s also helpful to include your speaking background, so that those who don’t know you at least know you’re not new to speaking. Including ratings can help, too, as in: “Presented a similar talk to 100 developers at XYZ code camp and was rated 9.2 out of 10”

My first pass at abstracts usually look a lot like your initial one, which is kind of like the standard Microsoft product naming convention of describe-what-it-is-in-general-terms. If I’m submitting to something I already know I’m accepted for, I usually won’t spend a lot of time trying to sex it up, either (like, for a user group, for instance). But for something like TechEd or any other larger event where I don’t necessarily already have an “in”, I’ll try to spend more time making the abstracts more exciting, and also demonstrating my past experience.

There’s a lot of great summary in here, for sure. I’m not sure I buy the “celebrity” angle at this point, though. In spite of being invited to speak about Marionette (among other things) and in spite of Marionette being the most watched Backbone framework on Github, with my name all over it, people still reject my sessions in favor of other people. 

Unless you’re Jon Skeet, Addy Osmani or Paul Irish, you’re going to have to beg your way in to most conference submissions. You’re going to have to pay attention to the detail and make the submission exciting, or you’ll be passed up in spite of your name being all over the project that they want to hear about.

Lastly, @kellabyte capped it off with a dose of reality for all of this advice:

@derickbailey @robconery @jbogard Nothing guarantees anything we say is worth a damn though :P

— Kelly Sommers (@kellabyte) March 15, 2013

While this is true, I’m grateful to have received this feedback! This is infinitely more useful than the generic, patronizing “we had too many great submissions to choose from” responses that conference organizers like to send.

What Other Advice Do You Have?

I know I have a lot of work ahead of me to improve my submissions, and I’m still looking for more advice and more feedback. What else would you add to the conversation? What other tips and tricks do you have? 

I don’t want others to have to go through this. Help us all learn from your lessons and patterns in successful session submissions. Post in the comments here, or in a response blog post. Just be sure to share your tips with the world so that others can hopefully avoid the mistakes and learn from the successful lessons.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Mark “Ploeh” Seemann wrote a post on testing trivial code. There have been several responses saying he’s wrong and that you shouldn’t test trivial code. Some of the responses have been a little less graceful than others (and slightly gross and maybe NSFW – an orangutan peeing).

Everyone that has responded so far, is wrong in some way. I’m wrong in some way as well and I’m sure this is going to turn in to another “beating the dead horse” conversation quickly with people pointing fingers and poking eyes. I just want in on the fun while it is here to be had.

Ploeh Is Right, For The Wrong Reasons

I think Mark is right in that we should test most of our “trivial” code (if not all of it). I think he’s very very wrong is saying that we should unit test all of it – especially with the examples that he showed of unit testing a C# auto-property for a date/time field.

Mark is right because this field must add some value to the system. If it doesn’t add some value, it shouldn’t be there. If it does add some value, we should guarantee the value that it adds. 

Jimmy Bogard Got It Right

Jimmy wrote a post that I think was unrelated, but happens to fit perfectly in to the conversation. In that post he says:

When should you test?

When it provides value.

When is that?

It depends.

Ultimately, it depends is the only reasonable answer. But let’s take the example of a date/time auto-property that Mark used in his example, for our purposes and discussion.

The value that a date/time property adds may not be in the business logic that uses it. It may not have anything to do with handling of the date/time in some creative way to make sure other things happen at a certain time. It might be as simple as an invoice date, or perhaps a purchase order # on an invoice. Both of these fields are trivial, but both add value to the idea of an invoice. I wouldn’t unit test these fields if they are only used for display purposes, though. Instead, I would focus the test on the place that the field provides value – the end to end solution.

Mark Rendle Got Part Of It Right, Too

I think Mark Rendle got some of it right in his response, too. He talks about the idea of validation code in the UI to ensure a date can’t be set in the past, if that is what the business needs are.

This leads to the real point in adding value in tests.

Functional Tests, Not Unit Tests

The value that trivial fields used for display purposes adds, is found in the display of the information. In this case the use of an Invoice Date and Purchase Order Number on the invoice that is sent to the person that needs to pay it  provides value to both the person sending the invoice and the person receiving the invoice – so test that. Test the display of the information because that’s where the value is found. Write a functional test that runs your invoice generating process and use a simple UI test to ensure the date shows up. This is where a test provides value for trivial code in this case – functional tests, not unit tests.

A unit test around a C# auto-property is a bad idea because it only tests the compiler and runtime as others have pointed out. But a functional test that proves “When I supply a Purchase Order Number, Then the invoice should display the Purchase Order Number” is a valuable, functional, end to end test. After all, If I were a customer of a company and I sent them a PO# for an invoice, I would want that PO# to show up on my invoice. If it didn’t show up, I’d be a little “YOU ONLY HAD ONE JOB TO DO!” upset. If I send you a PO# because I need it on my invoice, you better send the invoice back with the PO# or you’re not getting paid – at least, you are decreasing the chances of getting paid on time.

Value In Trivial Code

There’s no value in testing trivial code? My “BS” alarms are ringing. You want to write unit tests for auto-properties in C#? My “BS” alarms are still ringing loud and clear!

My example of using a functional test to prove the value of a PO# is only an example, and not meant to be the ultimate answer or solution. You need to take the time to understand where the value for your trivial code really is. Once you do that, you’ll understand how to properly scope your tests to prove the value of that trivial code. 

If you can articulate the value of that auto-property when you’re talking to a coworker, you can write a correctly scoped test to prove the value. If you can’t provide a description of the value of that trivial code, though… it probably doesn’t need to be there.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Method Rewriting

If you’re not familiar with method rewriting in JavaScript, it’s basically just replacing a method at runtime, from within the method itself.

var myObj = {
 
  foo: function(){
    console.log("bar");
    
    this.foo = function(){
      console.log("quux");
    }
    
  }
 
};

myObj.foo(); // => "bar"
myObj.foo(); // => "quux"
myObj.foo(); // => "quux"
// ...

In this example, the “foo” method contains code to replace the “foo” method with a new method implementation. When the “foo” method is run the first time, it outputs “bar”. Then it replaces the “foo” method with the new implementation. Subsequent execution of this method will output “quux” instead of “bar” because the method has been rewritten.

And BOOM Goes The Dynamite

The problem I ran into has to do with the way we set up event handlers in JavaScript, by passing function references around. Consider the following Backbone.View implementation:

var MyView = Backbone.View.extend({
  
  initialize: function(){
    this.model.on("change", this.render, this);
  }
  
  doSomeExtraWork: function(){
    console.log("extra work");
  },
  
  render: function(){
    this.doSomeExtraWork();
    this.$el.html("... rendered HTML stuff goes here ...");
    
    this.render = function(){
      this.$el.html("... rendered HTML stuff goes here ...");      
    }
  }
  
});

var model = new Backbone.Model();
var view = new MyView({model: model});

view.render(); // => console.log of "extra work"
view.render(); // => no console.log! yay!

model.set("foo", "bar"); // => console.log of "extra work". BOOO!

When the view is instantiated, a “change” event from the view’s model is handled. When the model changes, it calls the “render” function. This ensures the view is always up to date with the latest data from the model. It’s not a very good solution from a performance perspective, but it solves the general problem.

Now let’s introduce a more complicated scenario where the first time the view renders, it should do a little bit of extra work. Subsequent execution of the render method should not do that extra work. I’m not going to get in to detail about what the extra work might be in a real application, but I can illustrate the point using some simple console.log calls. 

When you run the above code, the first call to the render method logs the “extra work” message. Calling the render method a second time, directly, does not produce this message. That’s good. It means our function re-writing worked. However, changing any of the data on the model will produce the “extra work” message, which is not what we want.  Worse still, it will replace the “render” method on the view instance again, and again, and again, every time the change event fires.

Lighting The Dynamite

The problem is the way we hand off a reference to the function for the event handler. When we call `this.model.on(“change”, this.render, this);`, we are handing a method pointer to the “on” function –  a callback that points directly to the current implementation of the “render” function. This is not a reference that gets evaluated every time the change method fires. It is evaluated immediately when the event handler is set up, and a direct reference to the render function itself (not the object that holds on to the render function) is passed through as the event handler.

When the render function is called later on, the render function itself replaces the view’s “render” function with a new function. It re-writes itself… except this is a bit of a misnomer. The function it not actually re-writing itself. What it is doing, really, is replacing the view’s reference to itself with a reference to another function. It’s the equivalent of this:

// set up the initial object and method
var myView = {
  render: function(){ ... }
};

// replace the render method
myView.render = function(){
  // ...
};

In this code, it is very clear that the “render” method is being replaced. The original function is not being “re-written”, but only replaced. Method re-writing does exactly this, but does it from within the function that is being replaced. 

Now, getting back to the event handler… when the “render” function replaces itself, it only replaces the function on the view instance. It doesn’t have a reference to the “on” method and it doesn’t know how to replace that event handler with the new function reference. Therefore, the “on” event handler still references the original render function, even after the render function has replaced itself on the view.

The result is that the “change” event fired from the model will cause the original render function to be executed. Since the original render function contains the method re-writing code, it will replace the view’s render method again. Every time the “change” event fires from the model, this will happen. If the “change” event fires 3 times, the “render” function on the view will be replaced 3 times.

Powerful But Dangerous

Lesson learned: method rewriting is like running with a lit stick of dynamite. It’s a powerful tool that serves a purpose – but the scope and references to the functions that are being re-written need to be controlled very tightly, or it will blow up in your face.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Getting Started

Read Rob Conery’s series on screencasting. He was kind enough to blog everything that I wouldn’t have been able to say as well as he does. :)

http://wekeroad.com/2012/08/22/screencasting-like-a-pro-beginning-middle-end
http://wekeroad.com/2012/08/24/screencasting-like-a-pro-the-script
http://wekeroad.com/2012/08/31/screencasting-like-a-pro-the-demos

Also read Scott Burtton’s article on audio compression. Note that this is not file compression… this is audio compression, as in sound engineering.

https://gist.github.com/scottburton11/3222152

Equipment / software:

You need a minimum amount of hardware and software for building screencasts. This list should be fairly obvious:

• A computer (duh?)
• A high quality microphone
• Screen/video recording / editing software
• Audio recording / editing software

Notes On Recording

Things to keep in mind when recording the audio and video

For recording the video:

• Close all programs that are not part of the recording / coding / screencasting process – especially email and IM apps
• Record the entire desktop, not just part of it
• Record at your normal screen resolution. Don’t change the monitor resolution or anything else, to record.
• Re-size all windows that you are going to record, down to 1280×720 (720p) resolution
• Do not record computer audio
• Do not record any audio while recording your screen (the exception to this is if you need to record yourself talking to yourself, so that you can take notes for the real audio recording)

For recording the audio:

• Turn off your phone. Srsly – I’ve seen screencasts where people say “hold on…” and check txt messages. WAT
• Wear a headset if you need to hear the computer’s audio while recording the audio
• Record your voice-over separately from the screen recording
• Edit the audio to remove clicks, pops, breathing and other noises
• Use a small to moderate amount of audio compression, to keep the audio levels closer to even (see the above link to Scott Burton’s article on audio compression)
• Export the audio at the highest possible quality, using a lossless audio format. Do not export as MP3 or any other file format that would reduce the quality of audio

When recording audio, be aware of background noise. A broadcast quality mic will pick up everything. If your office has wood / tile floors, like mine, you probably don’t want to record in that room because of echo. Find a room with no bare walls, with as few hard surfaces as possible, and with as much “soft” stuff to absorb sound, as possible.

I have a small set up in my closet for recording audio, with a mic stand and a portable sound booth. I don’t expect everyone to have this kind of set up, but using a closet full of clothing will reduce the background noise and create a “dead room” effect, where your voice is more natural.

On a Mac

I work on a Mac these days, so I have more specific info about this than I do windows.

• Do not record video on a Retina display
• Use Screenflow to record and edit video
• Use GarageBand to record and edit audio
• Splice the audio together with the video, inside of ScreenFlow, after editing the audio separately
• To resize your apps to the appropriate size, use a tool like SizeUp or applescript like I talked about in another post.

Screenflow settings:

• Go to “Preferences”, “Advanced”, and set “Screen Recording Preferences” from “Adaptive” to “Lossless”
• Go to “Preferences”, “Advanced”, and set “Video Magnification” to “Smooth”
• Go to “Preferences”, “Timeline”, and set the default transition to “Cross Dissolve”

On Windows

Use Camtasia … is there anything else? Not sure about anything else here… suggestions? What is the Garage Band equivalent on Windows?

The Video And Audio Script

Like most things in software development, iteration is the key to success. Learn to iterate your script for both audio and video. This usually means writing one of them first, while thinking about the other. Then writing the other while editing the first to adjust for the things you forgot about.

Organize your scripts as if you were writing blog posts – short sections with a beginning, middle, and end in each section. Be sure the entire episode also has a beginning, middle and end, as well. 

When writing the audio script details, write as if you are speaking – because you are. Don’t write for written publications. Write for a an audience that is listening to you do a presentation at a user group. Write in your speaking voice.

You need to be able to record the audio and video in short bursts – 1 to 2 minutes, maybe 3 to 5 minutes at most. This is critical because you will make mistakes, and you will have to re-record parts and you want to minimize the amount of audio and video that you have to re-record. Building your audio and video script in small, distinct segments will help facilitate this.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

I know PHP is not the sexiest language in the web world right now, but it has a few things going for it: maturity in the language and frameworks for it, the amazingly friendly community of developers, and how quickly I can get a simple web server up and running.

To illustrate that last point, here’s a quick comparison of what it takes to get sample web app up and running with my three favorite languages / runtimes right now.

Ruby / Sinatra

The fastest way I know to get a Ruby web app up and running is to use Sinatra. I love Sinatra for it’s simplicity and flexibility. I have a handful of projects and websites built in it. But it takes a bit to get up and running. I have to install the Sinatra gem and everything else associated with it, then configure an app.rb file with all the right routes and other configuration options to serve up the project files.

Sinatra is my primary choice when building Ruby apps. It’s great for sharing with the Ruby community because everyone understands it. It’s also cross-platform so anyone on Windows, Linux or Mac can run it. But it is no longer my primary choice for cross-platform demos and sample apps.

I don’t use Rails unless I know I need to build a full stack, server-side MVC app w/ all the logic and complexity that comes along with Rails. This is not a knock against Rails. It’s just “the simplest thing that could work” philosophy, and getting things done.

NodeJS

Node is about the same amount of work to get up and running for a simple demo app. I have to install the Express package through npm and then configure an app.js file to server things correctly. This takes about the same amount of work as Ruby and Sinatra. 

There are 3 distinct advantages that I see in Node/Express over, though:

• Jade as default HTML templates
• Easier to run cross-platform
• NPM eats RubyGems lunch

With Sinatra, I have to go through extra steps to install and configure HAML as the template engine. It’s worth the extra 2 or 3 things to do, and I always do it. But with Express, Jade is the default template engine. Jade is HAML++ in JavaScript and I love it more than HAML for it’s even further reduction of noise in HTML tag attributes, etc.

NodeJS is far easier to run cross-platform. Installing and configuring Ruby on a Windows machine is dead-simple. On a Mac? It takes me an hour+ every time I help someone. The community is trying to fix this, but hasn’t yet. I don’t know about Linux, but I’m getting it’s easier on there than on a Mac. NodeJS, on the other hand, is just easier to install and use everywhere. I can share a NodeJS app with any developer on any platform, and be confident that someone who has never installed or used NodeJS will be able to get it up and running in less than 10 minutes.

NPM is also eating RubyGems lunch right now, for simplicity and feature set, because NPM includes what Bundler does for RubyGems. It really comes down to that. I hate having to “gem install bundler” and then “bundle install” separately. That’s stupid. RubyGems should include Bundler in it the way NPM does.

For these three reasons, Node/Express have become my default stack for sharing code with the world. But Node/Express still require more work than PHP, to get a sample web server up and running.

PHP

What does it take to get a PHP web server running, so I can begin hacking on a sample app?

php -S localhost:5000

Done. 

No package manager config files to build. No packages to install. No need to configure a web server file with code. I just type that one liner and I’m good to go. I can edit and display any .php file or .html file that I want, without any other infrastructure work.

The good news is that I can also get something very similar to Ruby/Sinatra or NodeJS/Express with the PHP Slim framework. It’s the PHP counterpart of Sinatra and Express – but it’s optional. I don’t have to use this to get a basic PHP project up and running.

The downside to PHP is that it took me a few days to get it installed and configured on my Mac. OSX comes with a poor version of PHP built in, so I had to install the latest. After many different attempts from many different sources of advice, I finally got it installed through Homebrew. Then I had to figure out why the new version wasn’t the default version. Moving beyond that, I had to figure out that “SQLite” and “SQLite3″ are considered separate, unrelated things instead of just versions of SQLite.

Once I got past those hurdles, though, I found myself quite productive with PHP, quickly. The ability to stand up a sample project in one line of terminal commands is quite appealing. I don’t know that PHP will become a regular thing for sharing code, though. I’ll certainly use it when I want to share with the PHP community, or when I need to get a web server up and running in no time flat to server a simple HTML page, though.

If you haven’t looked at PHP, or it has been a long time (it has been near 13 years since I used it last), I’d recommend checking it out again. If nothing else, it will server as a quick way to get a simple web server off the ground, to start demoing some HTML and JavaScript.

What’s Next?

I probably need to learn Python for my next web server language. I keep hearing good things about it from a language purity perspective. But that will have to wait until I see another opportunity to learn something new, again.

Post Footer automatically generated by Add Post Footer Plugin for wordpress.