Node and Blended Tech Stacks

The longer people write single page applications, the more of them there are. The notion of a SPA harkens back to the concept of client server architecture, invented some time in the 1960’s or 1970’s. Now we build SPAs with services constructed with Java, C#, Scala and Node. Some of the stacks we use have names like MEAN, and others are a hand-selected composite of disparate technologies with no name.

I have quickly come to believe that any tech stack with a cute name is likely a solution looking for a problem. Sometimes you want Mongo, Express, Angular and Node, but sometimes you want Couch, Ember, Spring and Java, do we call it JESC? Gross.

The important thing here is, we took Node out altogether for the Java stack. The benefit we get with choosing Java’s history and broad set of packages, you lose the ability to share code between services and your client-side code.

We are in a unique situation in the current stage of technology where we can write a client application and provide it as a interpreted file which runs on a remote computer at request time. The code we can push to the client also will run on a server. By ignoring this fact, we lose a great opportunity to write code once and share it client to server.

People call this isomorphic or universal Javascript. If the services are all written in another language, there is no way to leverage the client code in the compiled server code. There is, however, still a way to share business logic from the server layer with the client with a little fancy fingerwork.

First, let’s write a little logic to verify a record doesn’t have a quantity which is greater than the maxQuantity property. Once we have that simple function, we can then apply it across a list of records.

If this were in the client side code, and we wanted to do the same kind of check in Java, the code would look something like the following:

Obviously this logic is almost the same, but two different developers probably would end up writing each of these. This is problematic since we now have the same logic in two different files in two different languages. This definitely a violation of DRY principles. For a single validation like this, we can probably accept the duplicate code, but in large code bases, this kind of thing will go from being a one-off occurrence to a pervasive problem. Let’s look at a way to consolidate this.

Comments Off on Node and Blended Tech Stacks

Browser-side Isomorphic Javascript

With the advent of Node, there has been discussion of isomorphic Javascript.  The general idea behind this is code written for server-side purposes can also be used for UI purposes. The problem with this notion is, it doesn’t account for browser UI/middleware considerations in the browser.

As client-side development progresses and software as a service (SaaS) and single-page applications (SPAs) become more common, UI developers continue to program based on user interactions with the view layer and the underlying logic gets woven into the UI code, littering data logic with DOM related code, which tightly couples the UI code to the data code, creating complicated, unmanageable software.

What ends up happening is code gets duplicated to serve the same purpose, and then the code gets out of sync. Bugs creep in and pretty soon the software starts getting cracks in the facade. Even frameworks that are intended to avoid this kind of behavior, like Angular, are built in a way that allows for divergent code.  Let’s have a look at a snipped of code that could diverge quite quickly, in Angular.

Obviously there was some cutting and pasting that went on here.

What happens when the requirements are changed? Will this developer remember that the regex needs to be changed in two locations? Will this developer even still be working for the same company?

Even if this is remembered once, it is almost guaranteed to be forgotten about. This is especially heinous because there are clearly two different concerns being served here. One place the UI is handling input validation so the user can get immediate feedback, the other is likely to be related to handling validation before data is sent to a service somewhere.

It is not obvious even from this simple example that DRY could be applied here. Of course it can, but the solution is not completely obvious. Since this is not a post about Angular validation, I will leave the Angular-specific details as an exercise for the reader. Instead, let’s take a look at a more general solution.

Obviously the script handling the validation is pretty general so we’re probably safe to start there. Let’s keep it. That means all we really need is validation for the UI. Let’s have a look at something that would give us the behavior we want:

Now our element has the same validation attached that our outgoing data will use to ensure everything is on the up and up. Honestly, though, this is a fine first pass, but you and I both know this isn’t the only validator you are going to use to handle your user inputs. Why don’t we do a little more cleanup and write something we can really get some mileage out of.

Now, that’s what I call DRY code. Now we have taken one piece of logic, isolated it and applied it in the places we need it. Sure it took a little extra code to get us there, but you can see the difference it makes. Now if someone comes along later and says “gosh, it would be great if the ID values could start with efg instead of abc,” anyone who is currently working with the code can go and update the validation logic and it will update the requirements everywhere.

What’s even better is, now we have a UI validator that we can apply any kind of validation logic and not need to continue writing and rewriting UI logic to handle all of that mess. Extra special bonus is this entire thing is written in vanilla Javascript, so it’s extra small, tight and as fast as we could make it.

When you do this in your code, go ahead and pat yourself on the back. You deserve it.

In the end, what people are really talking about when they say isomorphism, what they really mean is “don’t repeat yourself.” When that’s the goal, then isomorphism doesn’t have to be limited to client/server applications. Take the lesson and run with it. Make your code better and your users (and your boss) happier. Let’s use isomorphic code to make the world a better place.

Comments Off on Browser-side Isomorphic Javascript

Everyday Functional Programming in Javascript

I gave a talk at the beginning of the year about functional programming. Someone asked “can you do functional programming little by little or do you have to do it all, all the time?”

When I answered, I felt I didn’t give them the answer they deserved or that I could have given.  This is my answer. Yes, you can do a little or a lot. You can write functional code little by little and solve things without changing your life and your career.  You can write programs that aren’t academic or theoretical. You can write everyday functional code.

So what does everyday functional programming look like?  Unless you work somewhere that you write in Lisp, Clojure, ML, F#, Haskell, etc, then it doesn’t look anything like the high-brow academic tutorials you see most often.  You don’t talk in monads and exclusively pure functions.  It’s not an ivory tower. At best you are a warrior acolyte of the functional cloth.

State is a thing.

So, when you are working in functional languages, state is a difficult knot to untie. Since values are immutable and shared state is the work of something unholy and evil, handling things like state machines becomes a chore. Who wants to go to work and think “today is the day I have to tackle the beast. I hate today?”

Not. Me. Thanks.

Sometimes you really need state. You actually need to know what happened and what is coming.  Sometimes you want something that you can mutate and something that is transitory, but still in memory. Hi to all of you Haskellians, yes I know there are other ways of doing that kind of monkey business, but I just don’t wanna. It looks a little too much like work and a little too little like fun.

First class functions are for everyone.

Now that I got the state stuff out of the way that OO does just so well, let’s talk about what functional workflow looks like in my happy little world. Arguably the thing I feel differentiates functional programming from programming that isn’t is the beautiful higher order function.

I mean, it’s magic right? Higher order functions, I mean look at this:

That’s what I am talking about. Functions that take functions as arguments. It’s all kinds of awesome, right?

Okay, in all seriousness, the real awesome comes when you start blending pure functions in with your stateful code and moving all of that stateless logic into something that makes more sense for what you are trying to accomplish. Let’s have a look at one of my all time favorite constructs. It’s what makes my world go ’round: either.

Watch this.

All of this because, honestly, who needs all the conditionals? Do you care about the conditional logic or do you just care about the data? Personally, I think conditional logic is the devil. I mean, honestly, the worst bugs and the most  difficult mess comes from all of these horrible, horrible conditionals. Let’s cut to the chase and just make it right.

Here’s something even more amazing, ready for this? ARE YOU READY? Yeah, you’re ready.

I mean, DUDE, you can skip all of the worrying. If something null happens, you just pretend it never existed and everything turns out just fine. With just one new function, all of a sudden you get  all of the functional goodness that Javascript has to offer.

What does either look like?

That’s it. It’s the gift that keeps on giving.

At the end of the day, what I am really getting at is this: everyday functional programming is all about cutting to the core of what you want to do and eliminating the conditions, unnecessary shared state and error prone code so you can keep your sanity. It’s not about all pure functions all the time. It’s not always about monads and currying. It’s about the little things that make a big difference so you can do your best work.

Callbacks, callbacks, callbacks!


There’s a promise in my spaghetti.


So, dig, I like promises.  People I work with and people I talk to think I don’t but I really, genuinely do. Promises (in a computer science way) are just plain awesome.  Here’s the idea:

Program module: Yo, system, I want to do something and I want it to happen on another thread so I can keep doing stuff.

System: Okay. I’m doing it. Here’s an IOU, let me know when you are ready to collect.

Program module: Okay, I need that stuff now.

System: I’m not ready yet. Please hold.

Program module: okay, I’ll wait.

System: Okay, I’m done now, here’s the stuff you wanted.

Program module: Cool, thanks. Game on!

What happened here?  Basically a promise was issued and the program continued running with an async process continued in the background. When the program was ready for the data, but the data wasn’t ready, the promise became a blocking operation. Once the system was done, it delivered what was needed and the block was released.  This is awesome because you don’t end up with something that blocks up front. This can be annoying when you need something to appear completely transparent and non-blocking.  Such is the way of the world.

Javascript promises are, let’s just say… different. Everyone likes to say “oh they stop callback hell! They are the magic bullet!” Incorrect!

Promises are just syntactic sugar over a callback structure, which basically seems like a big fat lie to me. I don’t like the idea that I am “getting rid of callbacks” and really all I am doing is tucking away functions in a place where I have to do a TON of work to get tests around them. I have seen some of the worst code ever written inside of promise callbacks because “hey, it’s promise. It’s cool, man. You don’t need to test that.”

*cough* yes you do *cough*

Did you notice how I said “promise callback?” Yep, there it is. Promises and callbacks are still the same. You still pass in callbacks. You still have to handle the asynchronous nature of it all. This is where I climb to the mountaintop and proclaim “the cake is a lie!”

Then there is the q.all argument:

“What if you need to do a bunch of things and then call back? That’s like… complicated, man.”

It is. This was one the one concession I make… well, I USED to make. Q.all is pretty cool. Don’t get me wrong, anything that will bundle up a bunch of async calls and then hang out until they are all done, THEN callback is pretty darn nifty.  The problem is you are still introducing this idea of promises into the mix.  Stuff happens, the spell is woven and magic happens… Magic that is basically untestable.

So, let’s stop trying to paint the callback turd with a single layer of abstraction that makes things murkier and more difficult to understand. Promises are magic that have become lingua franca of async spaghetti. Instead, let’s have a look at a handy new library borne of Node and easily pulled into the client: Async

Dear promises, never send to know for whom the bells tolls; it tolls for thee.

Async deals with callbacks differently. Instead of wrapping everything up in a nasty set of promise.then().then().thens, try async.waterfall(). It’s like magic:

], finishFunction);

Now your code actually says what it is doing. Callback hell is gone. Promises are eliminated. All is right in the world.

But what if I want to do a bunch of stuff that doesn’t happen in serial? Parallel. Check it, yo:

], finishFunction);

It’s like magic right?

In closing, all I would ask is, if you are going to write a bunch of async stuff, please give me and everyone else on your team a break. Async is the way to righteousness and the light. Promises are great when you absolutely, positively must have it sometime later, but most work can be done with async. Give it a try and make your code a better place.

Similar posts in Coding, Javascript, Site Architecture

We Live in a Biosphere

You may or may not be aware of this, but when we are interacting with an application, we are entering a biosphere. People always talk about suites of applications as being an ecosystem, but even within the constraints of single app, we are still interacting with a smaller, but equally important, ecosystem.

About three years ago, I wrote a blog about page-behavior taxonomy or, as I generally refer to it now, behavior taxonomy. This taxonomy is really a mental model the user creates based on previous interactions they have had within your page, site or application.  It’s really crucial to understand that as you present links, behaviors and interactions, you are training your user.  When you break that interaction model, you are breaking rules the user expecting you to follow.

Consider the biosphere projects scientists construct for the purpose of experimentation.  Everything in that tiny ecosystem must work together properly.  If an element is introduced which changes the ecosystem, it could cause a breakdown of the entire experiment. These small changes are what happens when the biological equivalent of microinteractions are not considered.

The key to considering these mental models is to look at the application as a whole and start developing an expectation of what the user will experience throughout their time in your app or site. If you look at the app as a whole early on, then it becomes clear what each interaction should bring.  Think about how people are going to move about.  What kinds of input are they going to give.  Why are they doing it and how would they expect it to work?

Of course you should expect change, but the if the initial behavior taxonomy is sound, new additions will only serve to enhance the experience.  If, on the other hand, care is not taken to develop the rules to which your app should adhere, you will paint yourself into a corner.  You will make decisions early on which will force your hand later on.  If you choose to break from the model, you will also break your users trust If your app is something that is going to be foisted upon users, they will learn to deal with it and resent you.  If your app is something users interact with by choice, they will leave.

In the end, we are all in this little biosphere together.  Let’s live in peace and harmony.  Consider the environment and care for it. Your users will thank you for it. Consider your app’s behavior taxonomy and make the web a better place.

Comments Off on We Live in a Biosphere

Plan Your Device Strategy

As mobile gains ever more ground and mobile first continues to be knocked around as the design strategy for the web, I encourage people to look at their use statistics.  Although mobile first is a great strategy if you don’t have statistics to draw upon for your site, or your reorganization needs a mobile injection, nothing will serve you better than the statistics regarding what your user does on your site.

Instead of simply adopting an oversimplified “mobile first” strategy, I decided it would be best to figure out what the user is doing in each mobile context.  For the simple sake of reason, I generally say we have three platforms and four positions to deal with.  Either your user is on a small-profile device like a phone or palm-top computing device, they are on a tablet, or they are on a standard computing device.

This gives us something really easy to work with.  There are three devices, two of which have two orientations.  It might seem like this translates to 5 total designs to commit to.  Fortunately, the phone in landscape is just about the same width as the tablet in portrait.  We are left with four design contexts to worry about.  Realistically, though, we can start with just three pieces of the puzzle and extrapolate the intermediate fourth.

My latest project, for which I am leading a team, needs two key items to make sense of the high-priority items on the site: device used and pages accessed.  After a bit of careful fiddling, I uncovered the following chart:

Device to Traffic Chart

Device to Traffic Chart

This chart helped me to figure out what our device strategy would be.  Clearly our visitors from mobile devices have much more limited interests than those visiting from a standard computer interface.  Mobile first means we should guess at what should go on a site and what the user will want to do on a smaller device.  By analyzing the data, we can clearly define interactions on mobile devices which may, actually, not be important to highlight on the desktop.

Instead of working with mobile as a pared down version of a complete site, we should aim to understand what a user wants to accomplish in a different context.  This is not a cut and dried rule of thumb but something we can produce through a little bit of careful reflection on what users are doing right now.

For your next project, instead of taking a mobile-first design stance, review your user data and serve users in each platform according to their needs.  Provide clear signposts for your users.  Develop a device strategy and make the web a better place.

Comments Off on Plan Your Device Strategy

Herding Cats or Looking at Curated Search

You know what makes Google awesome? Their search algorithm is pretty darn smart. You know what makes DOMZ awesome? Every stinking link on there has been verified by a real, honest-to-goodness human being. You know what sucks about site search on most websites, even when they’re running a Google custom search? The only time a human ever looks at the search is when they are actually using it to find something.

This is where a curated site search comes in.

When I say curated, I mean it in much the same way a museum curator takes care of the displays, carefully selecting the pieces to display and updating things as new events and collections are integrated or moved out of public display. Think about it, if you went to a site looking for glasses for your cat and did a search saying “Siamese cat glasses,” wouldn’t it be awesome if, right above all the standard mediocre search results, you got a little bit of content saying “we’ve got glasses that will look great on your Siamese cat?”

Of course it would.

The benefit of this is that you have a better understanding of what a person is looking for than a computer ever will. Why? Two reasons, really. First is because you are a person and, I suspect, you have done searches for things before. Second, no matter how good the crawler is that indexes your site, you have access to your analytics, which means you know what people are searching for. (You’re running analytics, right?)

An example of how this works can be found on the HP site. Below is a screencap of what their search looks like if you search for TouchSmart. (I picked that term because it is their current ad and I knew I would get something good. Color me sneaky.) You’ll note they have a list of search results on the screen, but the very first thing to come up is a link straight to the TouchSmart product information.

HP Curated Search Content

Pretty sweet, right?

Okay, maybe looking at a computer search page doesn’t get you all revved up and ready for action, but imagine if that image were your Siamese cat in need of glasses. Now we’re talking turkey, right?

That cat needs some glasses

This doesn’t do anyone any good if it doesn’t do anyone any good, right?



The long and short of it all is, by curating content for commonly searched items on your site, you make the information/product/widget/catglasses more findable. This means you are more likely to have conversions from site visitor to customer. Benefit to your customer: ease of use. Benefit to you: more business. Stick that in your ROI pipe and smoke it, Mr. Executive.

In the end, everyone wins when things are easier to find. Since so many users are search-centric, you can serve them well by anticipating the searches they are going to perform and give them the info you know they want up front. This front-loading of work helps to provide a clear signpost for users to do what they were at your site to do: make with the business with you. In short, if you are running a site search for your users you should consider curated content to provide for common searches and make the web a better place.

Comments Off on Herding Cats or Looking at Curated Search

Moving Pieces: Organizing for a Website Overhaul

I’ve read several different books and articles about web projects and how to make sense of what needs to happen when. Everyone has their own slant and it flavors how the entire process should go. Meanwhile they hope the “magic” in another group is happening.

It’s really important to have a list of the things you need to accomplish. I am not going to tell you who does what. That depends on your team and how you dole things out. I will tell you that each of these pieces needs to be addressed or you’ll have a tough time moving to the next step.

Without anyere’s my core list of stuff to check off:

  1. Analysis
    • Business and user needs
    • Content Inventory and analysis
    • Site analytics (Look at search terms. This is your user talking TO YOU)
    • Personas
    • Brand, voice and message
  2. Collect moving pieces
    • Curated existing content (text, images, documents, etc.)
    • New content (Get it early or you’ll hate yourself later)
    • Process functions (search, dynamic functions for displaying content, etc.)
  3. Design and prepare
    • Information Architecture (Hierarchy, page layout, workflow, wireframes, etc.)
    • Build structured documents containing all raw copy for the site
    • Colors, designs, images, flow, implemented voice and message
    • Get info about servers, technical needs, etc.
    • Prepare SEO deployment plan
  4. Build
    • Prepare comps using design specs and wireframes
    • Build templates to house content based on wireframes
    • Implement design via styles as comps are completed
    • Edit content to match voice and message and begin inserting into CMS
    • Prepare SEO: descriptions, titles, friendly URLs, etc.
    • Prepare 301 redirects for old pages being replaced or moved (I feel this SEO technique is important enough it needs to be stated separately)
    • Ensure servers are online, technical needs are met and everything is ready for launch
  5. Launch
    • Stage site out of the public eye and QA completely
    • Deploy site (Post-QA)
    • QA for sanity (All pieces are behaving like they were on staging, nothing is broken)
    • Celebrate!
  6. Postmortem
    • Review analytics and compare to pre-release stats
    • Inventory new site (include all new copy, new images, etc.)
    • Review conversions

Build your core list of needs and lead your team to the promised land. One project at a time, make the web a better place.

Comments Off on Moving Pieces: Organizing for a Website Overhaul

Project Kickoff: Prepare to Deliver the Goods

We’ve all been there at some point or another. A new project is just about to start. Everyone in the know is bracing for impact and the people who are going to contribute are blissfully unaware of the monster lurking around the corner.

Generally the kickoff goes like this:

“Hey, everyone, our client needs an update to their website. You know what you need to do, so let’s hit it. Peace out.”

Do they know what they need to do? At a high level, maybe? Probably not, really.

Stakeholders don’t know what’s coming. The client doesn’t know what they need. The design and development units are waiting until the other one is done with “their part.” In the end, everyone scrambles at the 11th hour and the project comes together. Barely.

Let’s hit rewind and do this kickoff the right way. If you are a team lead, figure out what you need. Sort out who your users are and what business needs are being addressed on your site. Contact stakeholders early, share what you need and the listen to what they want. Use this to sort out your priorities. Organize the moving parts, call your team together and give them the rundown.

Once people have their marching orders, collect everyone for happy hour. This is the first step in a long journey, start it with a cheers instead of a fizzle. Kick off your projects right and make the web a better place.

Comments Off on Project Kickoff: Prepare to Deliver the Goods

Information Organization for Seeking Behavior in 5 Steps

Information comes in all shapes and sizes. Some is simple. It’s copy that goes on a page. It’s an image. It’s a sound file. It’s a single PDF. It’s whatever atomic piece of information you can imagine. Then there is the molecular level, for instance, whole web pages with mixed content. Then there is listed information: movie titles, collections of documents, retail products, animals with feathers, types of beer, whatever.

Listed information can get tricky.
Continue reading “Information Organization for Seeking Behavior in 5 Steps” »

Comments Off on Information Organization for Seeking Behavior in 5 Steps