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!
