Live From CodeMash 2014!

I was lucky enough to attend the CodeMash 2014 this week, and saw some great content, had fun playing games and also got to give a talk! Telerik, of course, was a HUGE sponsor of the event and we had a lot of great people here. We all had fun, the conference was great, and I wanted to share a few of the highlights from my visit - starting with Brian Prince and high CodeMash-Orange hair!

The Game Room And Kendo UI Booth

We had a great booth this year - I know this booth setup has been around before, but it was the first time I’ve seen in real life. Hopefully, if you were here, you got to stop by and say hi to some of us at the Kendo UI booth.

We also sponsored the game room - a room where people gather to play board games and card games and whatever other types of games they wanted to play. Fun times were had by all - especially on this giant, 9 foot square Settlers Of Catan!

A Few Session Highlights

But the conference wasn’t all fun and games. It was also… fun. And there were games! And BACON! Oh, and there were some amazing sessions as well. Here are some of the highlights from the sessions that I went to, including some links to resources for us web and JavaScript developers.

Glenn Block: Async Javascript

If you ever get a chance to see Glenn Block speak, you should go. He’s always a great speaker with a ton of informative things to talk about. In his session this year, he walked through several examples of JavaScript with asynchronous code and callbacks in NodeJS. Then he showed different versions of the same search screen he built, using different libraries to manage and control the async flow of the code.

He showed the async JS library to clean up nested callbacks, and showed “waterfall” method, saying “in this case, waterfall is actually a good thing”. Async is not composable, though - you have to tell it what to coordinate. For composing - adding new parts to the process, as needed - you want promises.

He then showed the q JS library and bluebird.js for promises and how to created method chains and clean up callbacks with promises.

Up next was the RX framework - observables and observers. Reactive provides declarative model for managing async code. Promises are 1 thing that flow through a series of steps. RX allows a collection of things to flow, modifying the collection along the way. Think pub/sub, with promise like chaining - pipes and filters. Where promises allow you to chain one thing through many “then” methods, RX allows you to pipe collections through a series of processing steps.

Lastly was the idea of coroutines. He showed two separate things for this in NodeJS.

He showed a library called Fibers to use coroutines today. This library lets you write async code that executes sequentially. This is similar to ‘async/await’ in C# or similar to signalling threads where you wait for a signal to continue the code. Signalling that the async code is done allows you to yield some data back to the place from which Fibers first started waiting for the async code to finish.

Coroutines are also coming in ES6 and are known as generators. This is basically what fibers provide, but native to the language - including browsers! While it’s not yet available everywhere, it is already available in some modern browsers.

The DOM Is Not Your Application

Noel Rappin gave a great talk about how and why you should extract your DOM use - selectors, modifiers, etc - out of your application code and treat it as a 3rd party dependency. I have done things sort of on the path of what Noel showed, but had never taken this idea as far as he did. Frankly, I love the idea of wrapping my DOM access code in something that is a dependency for my other code.

We’re comfortable farming out things that are not our primary concern - libraries APIs, etc. Why don’t we do this w/ the DOM? jQuery sort of does this, but not really. At least jQuery is easier to use than the raw DOM.

A naive way to use libraries is to call them directly from our code. Bad idea. This is hard to update, hard to adapt to changes, duplication in our app because we have to call the API multiple places. A better idea is to create a wrapper/facade/etc that your code calls. Create a single point where the 3rd party is called. Gives you app semantics in the wrapper so your code can focus on your domain.

But why do I need to shield from the DOM? You should write code that has good characteristics, that are well defined, etc and keep your dependencies at bay. This allows you to change the DOM elements (not API) without having to change the app code that needs to use the DOM.

Ultimately, the DOM is an API. Isolate your app from 3rd party APIs.

Limit your DOM touch points, pull DOM out of your app and treat it like a 3rd party dependency.

My SOLID JavaScript Talk

I was also lucky enough to give a talk on the SOLID Software Development principles at the CodeMash this year, and I brought my audio recording equipment with me! The result is a live recording with (hopefully) adequate audio to introduce JavaScript developers to the benefits of the five SOLID principles in object oriented development.

I’ve uploaded the slides and code to Github. If you don’t have Keynote, you can get the slides from my SpeakerDeck account as well. I also made the recording of the video available on YouTube!

Of course there were a ton of other great sessions - many of which I enjoyed a great deal. But I found these to be the highlights for web development and getting ideas on how to move forward and improve.

I hope to be returning to CodeMash in the future, and am certain that Telerik and Kendo UI will continue to be a part of it!