Here are slides from a presentation I recently gave at Adobe on May 6, 2013. The examples linked to in the slides provided the basis for most of the discussion.
As web applications grow increasingly more dynamic, software design patterns and principles become crucial for robustness and scalability. Let’s break out of the stigma of hodgepodge, spaghetti code found in web apps of old! In this presentation, we discussed modularity, communication patterns, and patterns used within MV* frameworks with examples from Backbone.js and AngularJS.
These are slides from presentations I gave at Adobe on February 5, 2013 and April 30, 2013.
Presented at 360|Min 2012 in Las Vegas, NV.
It’s almost time for another 360|Flex conference! This conference will be held in Denver, Colorado, April 15-18, 2012. Get your tickets fast while discounts are available! It’s always a huge opportunity to learn new things and get in touch and have fun with the community.
As we create software is seems like we come in contact with the same patterns over and over. Usually, we end up re-writing them over and over as well. Take an array of user objects, each with a
username property. We need an array of all the usernames from all the objects. So, like many times before, we create a new array to populate, create a for loop, snag the object at the current index, grab the username and push it into the array.
To me, that’s boring. It’s mundane. Underscore makes it fun again. With Underscore, we just use pluck():
var usernames = _.pluck(users, 'username');
Ah…concise, fast, and boilerplate is gone. Want to find all objects within an array that pass a specific test? Use the
filter() function. Just want a reference to the first one that passes the test? Use the
find() function. Want to retrieve the union of two arrays, that is, retrieve a single array of all unique objects contained within multiple other arrays? Try the
union() function. Merge properties of multiple objects into a single object? Use
Once you grasp the power of Underscore you’ll find yourself being more productive with less code while having more fun. Some have called it the bowtie for jQuery’s tux. I concur. Continue reading »
Never build large apps
The secret to building large apps is NEVER build large apps. Break up your applications into small pieces. Then, assemble those testable, bite-sized pieces into your big application.
This post is intended to be the first of a series. I want to be clear about what it entails and its intended audience.
For the past several years I’ve been an architect in enterprise-level RIAs. This is a fancy way of saying I oversee the design and construction of apps that are web-based but have a lot of the same characteristics as desktop applications. Some of the applications I work on are in fact desktop applications but heavily communicate with the web. The line becomes very blurry, but the main point is–I deal with applications which in my world are quite different than what is often considered a “website” even though they both live within a browser.
Recently I implemented Jonathan Schemoul’s SmoothGallery and ran into a few issues. I’m certain there’s at least one other person out there searching desparately for answers, so here they are Continue reading »