Time for a change, part 2

March 2nd, 2017

This the 2nd part in a series of posts about improving the dev culture in the Milwaukee and surrounding area. See all the post in this series under the community tag.

In the previous post, I told a story of Sally. She is a passionate developer that is getting frustrated with the status quo in Milwaukee. The post was mainly aimed at companies in the area. This post is aimed more at the developers in the area. The overall feedback from the previous post was pretty positive however there was one common comment that come up from story of Sally. The common comment was “how did Sally attempt to change her company?” This question is what we are going to explore in this post.

Change is very hard for most people. In fact, I would argue that change is a fear that is right with public speaking and death for many people but different in that many don’t know they are fearful of change. Change can be risky, Change is unknown, Change can move you from your comfy safe box.

The first question from the story of Sally that should be asked is did she have the support from the business for the changes she wanted to make? Any change is easier with support from others. The higher up the organization the support goes, the easier it gets to affect change in an organization. The best case scenario here is if c-level execs are leading and/or cheerleading the effort. Since Sally was thinking of moving out of Wisconsin, it is safe to assume she didn’t have much support in this way.

The next question is then what has she done to drum up support? More importantly, how? Many developers’ first instinct is to try to win others over by using the thing they know best: their technical knowledge. Which is great when talking to other technically minded people. Most of the time. It falls flat if you are trying to convince non-technical people.

Let’s assume that the change(s) Sally wanted to make were valid and would in fact be beneficial to the team and company. What would she need to do? She would need to get her ducks in a row. When she presents her ideas to her audience, she needs to be able to show them these changes will positively affect the things her audience cares about. She needs to show that she has thought through changes and be willing to get answers for the questions that come up. Even better, know her audience well enough to know the questions they will want answered and have them answered ahead of time.

There are 3 outcomes to this. The change is agreed to, flat our refused, or declined/deferred with reason.

If the change is agreed to. Make sure it succeeds. There will be trust and credibility to be gained. This can be used for further changes down the road.

If the change is flat our refused, well that sucks. These are hard to take. Many devs crave to have answers to the question of “why”. Not having reasons will likely irritate a dev. If you get too many of these answers, it may be a sign to move on (which is a totally different topic).

If the change was refused or deferred with reasoning provided. This is where understanding is needed. Many developers don’t like to be told they can’t do they thing they wanted to do. I know it is more fun to be upset then to find understanding. However, there are lots of reasons why a suggested change would get shot down. Many of them are very valid. A solid example is software licensing. You can’t just take some piece of software or code off the internet and use it if it is licensed wrong. No matter how much it would help. Hell, tons of companies shy away from Reactjs because of the inclusion of a patent grant. But I digress. Point being there is a lot to be learned here. A lot that can be used in further discussions either on this change or future changes down the road.

The story of Sally is just made up but has its roots in truth. I have been the developer that just spews technical lingo at a director only to be frustrated when he or she says no. I have watched my peers do the same thing. I have even seen a few of them get so frustrated they moved out of Wisconsin. On the flip side, I have seen great changes happen and it is exciting.

Look, none of this is easy. If it was, I wouldn’t be writing this. And this has everything to do with making Milwaukee and Wisconsin a better place for developers. It is going to take work on our part to do this. It is going to take stepping out of our comfort zones and making the places we work better. I know there is a ton of nuance here and there have been whole books on “How to Win Friends and Influence People” written. This is just a start. Just me saying that we need more developers to stop accepting the status quo and work to make our hometown a better place for everyone.

Time for a change

December 22nd, 2016

Most of the people who know me and are reading this probably know me from my work with the Milwaukee JS meetup. Anyone that has had a conversation with me at the meetup has probably heard me talk about making Milwaukee and Wisconsin better. Specifically for tech but overall as well. This is a subject that I am passionate about and is one of the key reasons I continue to put effort into Milwaukee JS.

Honestly, it doesn’t matter who I am. The only thing that matters is that you read this and start to give a damn. It is time for the people here care. For the companies here to care. It is time for real change not just saying words but actually doing something that will better all of us.

Time for a story. Sally is a software developer that works for you or with you. She is a good developer, gets her work done and is currently contemplating moving out of the state to pursue better jobs. This seems crazy right? I mean Sally’s job pays decent. Her company is stable. Why would she risk everything to move 2,000 miles?

The answer? Many people and companies don’t want to hear the answer. Or they don’t want to believe the answer. The answer is because Sally’s job consists of writing code that is outdated, boring, and is the bare minimum the company needs. She spends her nights learning whatever she can to become a better developer but all attempts to use what she has learned at her company have failed. So she is willing to risk everything, move 2,000 miles just for a chance to use more of the skills she has accumulated.

Many of you are thinking this story is just that; A story. Well, I hate to break the news to you it isn’t. I have at least 8 friends and acquaintances that have moved for this very reason. And more that are considering a move and they probably work for you or with you right now. Most them could have been considered “community leaders”. They ran/run meetups and tried to make an impact at their respective places of employment only to have it not go anywhere.

Need more proof there is an issue? Go to a meetup. Any meetup. Talk to the developers that are there. They will tell you the struggles are real. They will tell you that it is hard to find places to work in the area that actually give a damn about development. They will tell you that it has crossed their mind at least once to move 2,000 miles to a place where more people give a damn.

Still need more? Fine. Walk down to your HR/talent acquisition people and ask them. Ask them how much work they have to do to find a hireable person. They will tell you, that in Milwaukee it is really hard to attract talent.

Ok so there is a problem. So What can I do about it?

As a company let your developers participate in the developer community of Milwaukee and Wisconsin. On company time. Developers have lives outside of work but many of us would love the chance to show off what they do at work. They should not be expected to do this on their time. They should be doing it on yours as it will benefit you. So let them. Not only will this net more engaged developers but it will allow your company to shine in the community which in turn will help attract more talent.

I bet the majority of our small community in Milwaukee don’t know the cool and interesting problems that are being solved in your four walls. Hell, I would bet some of the employees inside your four walls don’t know the extent of interesting problems that are being worked on within your four walls.

So I beg you. Let them speak. Let them blog. Let them be more open on the awesome you are doing and the problems you are solving.

As a developer in this community, I encourage you to step outside your comfort zone and push your employer to allow you to contribute to the community. This can be blogging, speaking, tweeting or whatever. I for one believe that we, as developers, are the best advocates for our employers to other developers.

At this point you maybe asking yourself why does this person care so much about a company he doesn’t work for. Why does he care about what I do?

The answer is simple. I am selfish. As the quality of developer jobs in Milwaukee improves, we will attract more talent. As more talent comes to Milwaukee, I (we) can all learn more from our peers. The more I (we) learn from our peers, the better I (we) become. To put it another way, I want smart people around me because it motivates me to be smarter, better, faster.

Full disclosure: I organize the speakers for the Milwaukee JavaScript Meetup. MKEJS has over 1100 members. It is very hard to find speakers. After a fear of public speaking, the next top excuses are “I am not doing anything interesting”, “I don’t do anything on the side to talk about” and “My company won’t ok me speaking” All of these point to a problem in our community. All of these are fixable.

So this post is just one step in my work to make an impact. I need more and different speakers to keep MKEJS going. To keep it interesting. I want speakers from every company, every background, race, and gender. I am asking for help in making this happen not only for MKEJS but for every meetup in Milwaukee.










Consider my Hapi Edge Developed

August 25th, 2015

The nice people over at Bleeding Edge Press noticed that I submitted a pull request to hapijs related repos at some point and asked if I would be interested in reviewing a book about hapi. Being a fan and apparently wanting to pushing myself I said sure. A few hours later a copy of “Developing a Hapi Edge” by Van Nguyen, Daniel Bretoi, Wyatt Preul, and Lloyd Benson was in my inbox. So let’s do this!

A quick elevator pitch on hapi. It is “a rich framework for building applications and services.” In non-marketing speak it is a framework for building applications for the web. It is exceptionally good at restful APIs and best known for being the framework that powers parts of Walmart. Personally, I like it because it just gets out of my way. In fact this very site is served through a hapi proxy.

Over the past few days I read through the book. I am going to start of with what this book isn’t. It isn’t the book you should buy as your first node book. This book makes the assumption that you know node, have an understanding of the web, and jumps right into hapi. This is a good thing because the book can focus on hapi.

When I say the book jumps right in, I am not kidding. Chapter 1 is a brief history and overview of the book. Chapter 2 turn up the speed. It starts off with setting up a simple server and revs up to different tools that you can use to setup and run you hapi application. This pace is continue throughout the book. I like the pace because it never stays on any topic to long. About the time I am getting tired with a topic the book moves onto the next one.

At the pace of the book, you may get overwhelmed with all the info coming at you. Trust me, by the end of the book it all comes together and it will all make sense. The authors make up for the pace by having a full blown application that book is based on.

Hapi-plugins.com is the project this book is based on and each chaptor shows how a different part of the hapi infrastucure was built. The best part about this project is the code is available on github. It makes it really easy to see what the book is talking about in a real web application which helps in the learning of hapi. Other technical books or blogs have just shown code demos that you would not use in a real application. Having this project a long side the book was refreshing because if feels like the authors really wanted to show real world use of hapi instead of just some demos.

The authors even took the time to go over debugging and security. While these chapters are by no means a complete resource, it was nice to see a brief overview on the topics. It was enough to get your started with debugging and to get started at developing a secure website. Like everything else in the book, there was little fluff and was right to the point.

So is this book right for you? If you are looking at a quick and short guide to learn hapi, on a team that is using or about to use hapi, or a technical book worm, then “Developing a Hapi Edge” is a good buy for you. If you are looking for a reference book, this is not really it nor does this book claim to be that. The hapi documentation is really well done and an excellent reference.


The responses of giving notice.

January 14th, 2015

This morning is the day. After 6 years with the company, Tom has decided it was time to move and is putting in his notice. He is nervous and excited. Tom meets with his direct manager and lets him know. Because of their one on ones Tom’s manager is not surprised and saw it coming.

Later, Tom is in the teams weekly update meeting and breaks the news. It is a rough moment because he has spent the last 6 years with this team and now he was leaving. In that moment, everything is now different.

Jen has worked with Tom for many years. They have become friends and colleagues. She is understanding of why Tom has decided to leave and is supportive. She knows that they will stay in contact long after Tom has left the company.

Hugo is the VP of Development and has been with the company since forever. Hugo is extremely upset. He views Tom’s choice as an insult to him and the company. How could someone just leave? Hugo will make it known of his anger to Tom, typically by being passive aggressive. Making comments about loyalty and trust.

Adrian is the Project manager. She is scared. Tom was a big part of the team and with him gone, she is unsure on how they are going to fill in the gaps.

John, another developer on the team, is sad. Tom was a mentor to him and now that he leaving, it’s like a peice of John is now missing. John is visibly upset over the news and anytime the topic of Tom leaving comes up, the emotions return.

Taylor, a mid level developer, is excited. With Tom leaving, this means there is a chance to step up and get noticed. She is pretty much pushing Tom out the door so she can start taking on more responsibility and start showing her worth.

When a person puts in their notice, everyone affected has one or more of the above reactions to some degree. In my experience, the majority of people will be like Jen. They will be understanding and supportive, maybe a tiny bit sad. They understand that the action of the person leaving is not directed at them nor some insult. The unexpected outliers that have a more extreme reaction are the ones to look out for as these are the people that make leaving a company harder than it should.

The bright side of it all is that these feelings will pass. Adrian will see that people like Taylor step up and fill the gaps. John will realise that Tom was a great mentor and has prepared him well. Even Hugo will get over it as anger is sometimes just a defence mechanism.

When you put in your notice, be ready for the sudden and abrupt change in how your soon to be ex-co workers interact with you. As you tie up loose ends, you will slowly fade to the background. Don’t fret though, you are about to start something new.


Ampersandjs and ASP.NET MVC

November 13th, 2014

Ampersand is a newish client JavaScript framework that helps build native web applications. It is built and maintained by &yet. Ampersand is different than other frameworks because it is not a monolithic library that solves all your problems. It is a collections of small modules that all solve a single problem that when put together make up Ampersand. This allows you to easily switch out modules that don’t work for you. To read more about Ampersand and its benefits check out the following links.

I recently wanted to know what it would take to run the Ampersand-cli demo app using ASP.NET MVC instead of node.js. So I did just that. The can be found on my github. Head over there and check it out. What follows is some the key points that is a bit different than the node.js version.

Getting Started

Node.js is required when setting up my demo code. It is not required but I used it because it is easier if you do. Node allows us to use npm and tools like gulp and browserify which we will cover in a bit.

First we need to install gulp and browserify from npm. Navigate to the WebApp root folder from the command line and run:

npm install -g gulp browserfiy

Next install all the dependencies found in the package.json from npm by running

npm install

Next run gulp.


Finally build and run the visual studio project.

Browserify and gulp 

Ampersand highly suggests to use a common JS loader like browserify. In my example, I followed this suggestion. Browserify is a commonJS loader that allows you to require(”) modules, like node, in the browser. Gulp is a streaming build system that allows you to run jobs such as pre-compiling CSS, copying files, and many other things.

When browserify is pointed at our main app.js file (Scripts\App\app.js) and run, it will bundle all of the app’s JavaScript files into one file (Scripts\app.bundle.js).

Gulp and the corresponding gulpfile.js is used to watch the JavaScript files and automatically run browserify when things change. This means that as you edit files, gulp will rebuild the app.bundle.js file. All you have to do is reload the browser to get the final results.


With any native web application frame, the odds are good you are doing routing on the client side. Which means the server must serve the same html, css, and js for any page that is request. To do this, a catch all route is created.

    name: "Default",
    url: "{*.}",
    defaults: new { controller = "Home", action = "Index"}

Base Layout and Action

Notice the _Layout.cs file is basically empty. This is because everything is loaded via Ampersand including anything in <head>. This also means that our default controller and action serve nothing. The only things our default action needs to serve is any CSS and JavaScript.


Ampersand’s demo site uses Jade templates and complies them at runtime down to a single template.js file. Meaning that all HTML is served to the user the first time the application loads. In my examples, I sort of replicated this by creating an Action that creates a single JS file with all the HTML templates. This can be better and more automated but for the purposes of this demo I stopped here to show a direction that could be taken.

See the Template Controller and the views in the Template view folder.

Templates do not need to be served this way. You could make HTTP get requests for them in Ampersand. I did it this way to keep in the spirit of the original demo.

Sample API

The simple API was created using Web API. Nothing really different going on here expect that because of C# our models are strongly typed.


The original Ampersand demo used stylizer and a CSS preprocessor. I took the output from that and put it into site.css. You could do whatever suits your needs here.

Final things to Note

In this code, the app.bundle.js and template JavaScript is not far future cached. It could be. That is something you will need to figure out. There are many different ways to do this in MVC, I did not want to suggest one. The same goes for the CSS.

Much like Nuget’s packages folder, the node_modules folder is not checked into source control. Running npm install command will repopulate this folder much like Nuget’s auto restore.

Other than what is about, the rest of the application is vanilla Ampersand, no other changes were made.

Source Code: https://github.com/Oobert/Ampersand-and-ASP.NET-MVC/tree/master

My bout with Shyness

October 16th, 2014

I am shy. I am very lucky that it is not crippling. But it is bad enough that it has and is keeping me from doing what I really want to be doing. For example It was keeping me from being active in the development community. I would like to be able to introduce my self to people I want to meet when I see them. Mainly I would like to stop being anxious when I meet new people.

It is weird because I have not been able to figure out if I am an introvert or extrovert. I have traits from both sides. I love talking in groups of people I know but also love the times I off doing things on my own. Communications is one of my top 5 strengths from Strengthsfinder. I don’t know if it is possible but I feel that I am both but on different days.

Now my shyness is really around people I don’t know or don’t know well. If I don’t know you, I am not comfortable around you. I can not just walk up and start a conversation. It causes me large amount anxiety. I would go to meetups and conferences and talk to no one while I was there. It bugged me a lot. That is until I decided enough was enough and that it was time to do something about it.

3 years ago, I attended the first That Conference. I love learning, it was inexpensive, and close by. I knew exactly 1 other person that was attending. I was excited. That was until morning of day 1.

Day 1 started with Clark Sell standing in front of the attendees and issuing a challenge. He stated that That Conference was designed to be a social conference. Yes the session are awesome but the organizers put ample time between sessions and had after hours events to foster socialization among the attendees. His challenge was to take these opportunities to meet new people.

Pretty much after that moment, I was freaked out. I was thinking I can’t do this. I am going to be that guy sitting in the corner by himself for 3 days. For the most part of day 1 that was true. Thankfully the 1 other person I knew is more outgoing than I am and found a group of people to hang out with on night 1. If it wasn’t for that 1 person, I would have been hiding in a corner for all 3 days.

To be clear, I love That Conference. I love, now, that it is setup to be social. And this challenge was exactly what I needed but I didn’t know it at the time.

After the conference was over, I was inspired to do awesome things. During the following months, I decided it was time to get over my shyness or at least deal with it. I didn’t really have a plan yet but I had an idea of what I wanted to do. I didn’t want to be the person in the corner anymore. I started off by attending more meetups. At the very least I was getting more comfortable with being around people I didn’t know.

About a month before the 2nd That Conference, I got it in my head that was going to do an open spaces with the topic of developers with disabilities. I am dyslexic, this was my in. After the 3 days, I ended up chickening out. Fear sucks. The whole drive home, I regretted not doing it. The feeling sucked even more than the fear.

All was not lost, one amazing thing happened during the conference. During the time between the 1st and 2nd year, I became a bit more active on Twitter. While at That Conference, Clark Sell sort of called me out for not saying hi. I was hiding behind twitter and he basically said stop it. This sort of forced me into doing something I am not comfortable with. That was getting out of my chair and saying hi. I did it. It was a small victory. It was a step toward the realisation that getting over this is possible.

At this point it is August 2013 and it was time to get serious. I set 2 goal that I wanted to complete. Become active in development community and host an open spaces at That Conference 2014.

About this time, I learned that Milwaukee’s development community had an IRC channel (#devmke on freenode). I jumped in and idled. Even with just text between me and others I had anxiety about joining in the conversations. Over time, I learned who was who and started to join in. Slowly. Because of Twitter and IRC, I got to follow and interact a bit with people that organized some of the meetups in Milwaukee.

In early 2014, the organizers of MKEJS were talking in IRC about the need for a topic/speaker for that month. I suggested that they do a Node School workshop. I am not sure how but my suggestion turned into me facilitating the workshop. Node School workshops are a set of self guided lessons that use node to teach you node and other aspects of JavaScript. My job facilitator would be to get people started, show them how to use it, and help them if they get stuck. On top of this, this was looking to be the most popular MKEJS meetup yet.

Facilitating this workshop was an great step forward. They say facing your fears is a good way to get over them. Well public speaking to a group of people I don’t know. What could possibly go wrong? I faced them head on and everything went really well and gave me the confidence to do more. Shortly after, I was asked to help co-organize the MKEJS meetup which I accepted and at roughly the same time joined the Content Advisory Board for That Conference.

This August was the 3rd That Conference. So far I have reached one of my goals and have become more active in the development community. Now it was time to complete goal number 2 and do an open spaces. Before the conference, I told a few people my plan and asked them to help me make sure I do it. Since I didn’t went to let them or myself down I completed the goal. Here I am 3rd in line to tell my topic to roughly 1000 other developers, most I have never met. Yes I was nervous. Yes, stumbled a bit but I did it.

The conference went amazingly. I was able to meet many people I know from IRC and twitter in person for the first time. I was uneasy about approaching complete strangers but did so on a few occasions to recruit speakers for MKEJS.

Since That Conference this year, I had a new goal of giving a talk. This goal was completed in September when I gave a talk Titled “Rocking with Web Audio API” to MKEJS.  The next goal is to give a talk at That Conference next year.

I am still a bit shy and still have problems approaching people but I am going to continue to work at it. It has been a slow process and I think it had to be for me. I had to be ready for the change to happen and that takes time.

As I was writing this, I realised that a lot of my anxiety stemmed from not having confidence in myself. The reason this took time is that I needed to build up my confidence before I could do the next thing. Now to work on that talk for That Conference 2015.


Stop chasing carrots

September 19th, 2014

My first job out of college was working for a large printer of magazines.  There was a good number of developers and for the first few years things were good. The company had some interesting abilities outside of print that I thought were really interesting and I stayed longer than I should have because the potential to get bigger was there.

Then 2008 happened. We all felt the crunch. Print is not really a growing industry and the recession did not help. Yet, I stayed. I stayed even after new projects required over time from day one. I stayed even though perks and benefits of working for this company disappeared because they needed to make the bottom line look better. I stayed for another 3 years. Why? Because I was chasing the what could be. The metaphoric carrot  if you will. I believed the promises. I was a fool.

During those years, I was consistently underpaid when compared to market average. The work environment went from happy to hostal. Time lines went from reasonable to this needs to be done yesterday.

One day the carrot was removed. The CEO stood in front of the company and said they were going all in on print which mean the interesting abilities outside of print were being sidelined for projects that pushed print. I was done. I stopped working overtime. My work suffered. It didn’t take long before I left.  I couldn’t chase a carrot I didn’t believe in.

This experience taught me a major lesson:

Stop chasing carrots

This is not an original idea. This is an idea that is supported by science and research. When a task requires even the slightest cognitive processing, carrots no longer work. In fact they tend to be more harmful than helpful. Dan Pink’s TED talk The Puzzle of Motivation sums this up very well.

In Dan’s talk he suggest that people who work in creative fields require different motivators. Motivators that you have right now, not that you may get at some point in the feature. Dan suggests 3 different items:

  • Autonomy – Can you do the work in a manner that works for you?
  • Mastery – Do you have a chance to learn and grow?
  • Purpose – Does the work affect the world in even the slightest bit?

There are many other factors but these 3 are important. Looking back on my relatively short career, I have to agree. My biggest issues were doing things I did not believe in and doing them in a way that didn’t work for me. Going back to my story above, I left that job because I no longer had a purpose I believed it. It made me sad that the focus of the company switched because those areas outside of print had purpose and were awesome.

Whatever you are doing are doing for a job, make sure you are getting something from it. If you are working 80 hours a week because you may get a raise, you are doing it wrong. It is very likely that you will not get anything and soon this type of effort will become expected from you. If you are working 80 hours a week because you love what you are doing and you are making that choice then I am not going to tell you not too.


C# HttpClient integrated authentication

July 14th, 2014

HttpClient has become the standard way to make http requests in C#. This is mainly used for API calls but has other uses as well. Recently, I have had to make http requests to servers that require authentication and the documentation on how to do this is scattered. The funny part is that it is really easy to do.

var uri = new Uri("&lt;url&gt;");

var credentialCache = new CredentialCache();
    new Uri(uri.GetLeftPart(UriPartial.Authority)),
            "&lt;auth method&gt;",
            new NetworkCredential("&lt;user name&gt;", "&lt;password&gt;", "&lt;domain&gt;")

HttpClientHandler handler = new HttpClientHandler();
handler .Credentials = credentialCache;
var httpClient = new HttpClient(handler );

var response = httpClient.GetAsync(uri).Result;

<auth method> can be basic, digest, ntlm, or negotiate. Then just updated the Network Credentials to that of the user you want to make the call and you are good to go.

It appears that kerberos on its own does not work. This may be because of my server configuration. However if you use negotiate, HttpClient will use kerberos if the server is configured for it otherwise it will fallback to NTLM.

Why having an open door isn’t enough

June 17th, 2014

Recently Jason Fried wrote an article titled “Is Your door Really Always Open?” In it, he suggests that having an open door policy is great but also a cop-out. And I agree with him. So much so that I would like to go a little deeper as to why this is a problem.

I am an introvert and a bit shy. because of those traits, it is going to take a lot for me to go into my bosses office and talk. I am not going to do this unless I absolutely have to or I know it is likely that my point will be made. Recently I came across some videos called “The Power of Introverts” that suggests that this is a trait of introverts as a whole. They tend to be more calculated when they speak up and wont do so unless they know they will be heard.

What this means to a manager is that having an open door isn’t enough. It means that many of the employees a managers has are not just going randomly walk into your office and talk.

The other problem that I have seen with open door policies is that employees only use them to bring up problems or things they want to change.

If an employee is to honest to often they get labeled. Labels are bad. It is hard to remove labels. Labels keep employee opening up because they don’t want the label.

As an employee, these are the main two things that keep me from bursting into my bosses office and being honest. As an employee, the easiest way to fix these problems is to do what Jason Fried suggested in his article. That is, as a manager/boss, you need to be the one to open the communication. You need to go out and actively communicate with your employees. Once they get comfortable, they will be honest and more willing to come to you about anything. This has the added bonus of hearing more than just the negative things going on in the office.

So I wrote a state machine. Why? Because it sounded fun!

February 7th, 2014

I had a problem. I was tasked to make a wizard type interface for a few workflows in an web app. The workflows had 3+ steps with the current max number of steps at 10.


Option 1: I could control state on the server. After every step in the workflow the data of that step would be posted to the server where the server would keep track of it in session and take the user to the next step. This is very doable, and is pretty much how web apps have functioned before ajax. The downside to this is controlling partial state on the server is hard because session management is hard. You have to account weird scenarios like what happens if the user starts the same workflow in a different browser window, you now have to somehow identify what window goes to what session. Or how do you know when to clear a workflow in progress because the user navigated to a different page in the web app. What happens if they come back? All of these question can be fixed in some form but normally involve a lot of if statements.

Option 2: Wouldn’t it be easier to keep all workflow data on the client until the workflow was completed? Yes, yes it is. However this means that the client can no longer do full page reloads between steps. No problem, there are frameworks that cover this such as Angular.js. In my solution, I am loading and unloading html templates into the DOM manually and using Knockout.js for data binding. Why did I roll my own this way? Because IE8 but that is a different blog post. By keeping all the workflow state in the browser, we have less issues to deal with but a few new ones come up. For example, do you care that the user has to start over if they hit refresh? Do you need the browsers back button to work? These were easy for my use cases, it didn’t matter at the moment because of how this will be used in production. I started down this road, things were going well. But then I noticed that my JavaScript was getting kind of cluttered with if statements such as…

if (here) do this
else if (over there) do that
else if (holy crap) I have no idea
else if (another one?) and I am lost

Option 2b: State machines! About 2 steps into the first workflow, I noticed a pattern. Every step in a workflow loaded something, waited for the user to do work, moved to the next step. The lightbulb went off and I started looking at state machines in JavaScript. I found many like machina.js and npm had many in there as well. machina.js being the first in my search results, I went with it. It looks good and probably would have solved my problem but it has(had?) a dependency on underscore.js Due to the nature of this project, introducing an external library is time consuming, introducing two is a huge pain. But, you guessed it, that is another post someday. In the end, I decided to build my own. Why? Because it sounded fun, also I didn’t need a full featured library, yet.


So I wrote a state machine. It had a few requirements there were identified upfront.

  • Know what was the current state
  • Be able to change to a new state
  • Call an unload method on the old state
  • Call a load method on the new state
  • Pass data to the new state
  • Be able to generically call methods on the current state

Over time, I am sure the requirements will grow and we will make the choice of growing this code base or moving to a more feature complete option. And here it is.

    var fsm = function (states) {
        this.states = states;
    fsm.prototype.changeStateTo = function (newState, obj) {
        if (this.current &&
            this.current.unload) {
        if (this.states[newState]) {
            this.current = this.states[newState];
            if (this.current.load) {
    fsm.prototype.callAction = function (action, obj) {
        if (this.current[action])

As you can see, the state machine takes in an object that is the different states that it can be. A usage example is below.

The changeStateTo function will call unload on the current state, and then call load on the new state. It has some light error checking to make sure states and methods exist before continuing.

The callAction method is a generic way to call a specific action (function) on the current state. An example of this would be if there is a button that is on every screen, you could use this method to call that action when it is pressed on the current state.

And a small example of usage.

    var myFsm = new fsm({
            StateRelatedObject: { 
              text: "hello"  
            load: function ()
                //do work like load template or show/hide page elements
            StateRelatedFunction: function()
                //do specific work related to this state.
                //can access objects or methods on current state like...
                this.StateRelatedObject.text = "hello world";
            unload: function()
                //clean up after yourself here.
            load: function () { },
            StateRelatedFunctionOrObjects: function() { },
            unload: function(){ }
    myFsm.callAction("StateRelatedFunction", { /* data in here */ });

The object that is passed into the state machine can get rather large. This is ok because it is segmented into it different states and is well organized.

Testing is pretty easy too!

    //setup test parms here.


    //do asserts on data here.
    //example: myFsm.state1.StateRealtedObject.text === "hello world";


Edit 03/06/2014: I fixed a misspelling in code. I also posted a complete code example to github.