Programming on the Edge

Mocking should be Mocked

Published by Matt Hicks under , , , , , on Wednesday, February 25, 2015
I've worked with and for a lot of companies over the years and with the ones that actually care about unit testing Mocking (Mockito or some other variation) typically quickly enters the scene. My argument is that in proper coding you should be able to write proper unit tests without any mock objects. I'll go a step further and say that encouraging mocking in your tests actually encourages poor code quality.

What's the purpose of Mocking?

Mocking is extremely common in unit tests, but why?  The basic idea is that you are attempting to test one specific "unit" of functionality, but you don't want calls to the database, third-party calls, or other side-effects creeping into your unit tests. On the surface this seems like a valid use-case.

Why is Mocking bad?

There are many problems related to mocking that I'll try to quickly step through.

Unnecessary Complexity and Decreased Modularity

Though the purpose of mocking is actually to reduce complexity it very often increases the complexity of your unit tests because you often end up with confusing and complicated mocking to avoid running aspects of your code that you don't want executed in your tests.  You often end up pulling your hair out trying to figure out how the internals of the system are supposed to work in order to get the mocks to operate as expected and then all your tests start breaking as soon as that internal logic changes.  You often end up in a scenario where your code works fine because it's written modularly to continue working but your unit tests break because they are essentially implementing the internal functionality via mocks.

Unit tests testing the Mocking framework

In extremely complex unit tests or even simpler unit tests that are managed over a long time or through many developers it becomes more and more confusing what the purpose of the test actually is. I can cite dozens of examples where I've been auditing unit tests only to find out that the unit test does nothing but test the mocking framework instead of the code.

Need for Mocking Represents Bad Code Separation

This is what my entire complaint really boils down to.  If you actually need mocking in your unit tests, your actual code that you're testing is poorly written in the first place.  You should be writing code in proper units to allow individual testing without the need for mocking at all.

For example:

You might have a scenario similar to the code above and you want to test the checkout functionality of your system, but you don't want the payment gateway to be called and you don't want it actually persisting to the database so you might mock those out to avoid those being called. Instead, consider the idea that there are four units of functionality clearly defined in this case:
  1. Validating the Order
  2. Calling the Payment gateway
  3. Persisting the information to the database
  4. Creating a Receipt
Herein lies the problem. You have tight coupling in your code of dissimilar things making mocking necessary. If instead you were to refactor your code to look more like this:

You can see now that each unit of functionality has been broken out into its own method that can be individually tested as needed without the necessity of mocking. Further, the code is significantly cleaner and more maintainable as a result of this refactoring. Not only does it make our unit tests cleaner and easier to maintain without mocks, but it also enforces a higher level of code quality through modularity in your code than was there before.

If you ever decided that the checkout method needed to be unit tested you could refactor it so it takes in a PaymentGateway implementation and Persistance implementation as arguments to avoid side-effects and allowing a test instance to be created to fulfill those needs. Though this is a form of mocking, it follows a better paradigm of consistency and modularity than mocking frameworks do.

As you can see, this is an all-around better way to write code and though it is understood that in existing projects mocking still may be necessary, there is no excuse for such to be necessary in new code.

Nabo TV: Next Generation Media Center

Published by Matt Hicks under , , , , , , on Monday, December 01, 2014

For years media centers, DVRs, and video streaming sites have existed to watch TV and Movies. Over the past several years these services have stagnated. Though there are no shortage of media centers, they all seem to be doing pretty much the exact same thing. For years we have watched and longed for a more featureful interface on our TV to be able to watch the content we're looking for, and for years we have been disappointed.

This is where Nabo TV comes in. We want to bring innovation back to the TV and push the boundaries of what is currently being done on the TV, not just as a product company, but as individuals who enjoy watching media on our TVs.

I just started a Kickstarter to help fund and increase visibility for this endeavor.  Please help me get the word out.

Why Templates Suck

Published by Matt Hicks under , , , , , , , on Thursday, September 26, 2013
The Problem

I've been asked a lot recently about what template engine I prefer and most people seem shocked when I say that I do my best to avoid them and just generally don't like the idea of templates.  Let me first define what I mean by templates before I get into my explanation so there's no confusion.  When I refer to "Templates" here I'm talking specifically about user-interface templates and primarily HTML templates.  My definition of a template in this context is a mechanism for allowing dynamic content to be incorporated into design.

The Good

To your average designer or developer I'm sure the immediate response is, "But templates can save so much time!" and they are correct.  Templates are definitely an improvement over developers generating UIs dynamically.  Templates exist for the specific need of collaboration between designers and developers.  This has always been a big problem as designers generally don't know the programming languages the developers are using and the developers don't have the creative design skills to be creating user interfaces.  The solution provided by templates is a dumbing down of the dynamic contents (developer side) that allows designers and developers to interact via templates so both can continue to work effectively and collaboratively.

The Bad

Here are the primary points I have against templates:
  1. Templates are a dumbing down of your programming language by definition. You cannot accomplish everything you can in your language of choice in a template.  This leads to multiple layers of abstraction and increases the complexity of your application.
  2. Templates often try to solve #1 by incorporating WAY too much of the language and thus become increasingly complex and painful for designers to utilize.
  3. Templates are yet another "language" you have to learn and maintain.
  4. Templates never find the right balance. Templates either focus too much on keeping it simple and thus create severe pain for developers for their lack of capabilities or they incorporate way too much and become impossible for designers to understand.
  5. Templates generally require (though not always) a server-side technology to process and populate data into.  This means your designers can't work on the user interface without requiring a server to run it on. This not only makes set up for a designer much more complicated, but it decreases their ability to make quick changes and see the results.
 The Awesome

Hopefully I've effectively shown the problems with Templates, but I have yet to offer a better alternative.  Yes, I believe one does exist and I've been developing this way for over a year and it is being utilized effectively with several production sites (ex.  The idea is to allow designers to work with HTML and create representations of the content for the site independently of the developers.  The developers then manipulate the content in code before delivery.  Hyperscala was an ideal framework to support this type of development since it allows interaction with HTML, CSS, and JavaScript in a type-safe infrastructure so you can manipulate the DOM without impacting the designer's work.  For an example of this take a look at my post comparing Hyperscala to Play Framework (

Hyperscala: Web Site

Published by Matt Hicks under , , , , , , , on Monday, March 18, 2013

I have been negligent giving proper support to Hyperscala's public appearance and have spent the past several months working on the API itself. However, today I finally released a very basic web site at

The site is incredibly basic right now and not all that pretty but it is written in 100% Hyperscala and has links to the source code on Github on every page along with working examples.

Feel free to ping me if you have any problems with the site or something is missing that would help make the site better.

case class Scala

Published by Matt Hicks under , , , , , , , on Tuesday, February 19, 2013

I've been pretty busy the past few weeks with clients and haven't had much time to blog. Last week, however, I gave a presentation to the OKC JUG (Java Users Group) about Scala. As anyone that actually reads my blog must know, Scala is my primary language and I absolutely love it. This week since I don't have a lot of time to delve into anything complex I'll simply share my presentation slides comparing Scala and Java code:

It is amazing how much more simplistic tasks can be accomplished in Scala versus Java.

Hyperscala: Why not Play?

Published by Matt Hicks under , , , , , , , , , , , on Wednesday, January 30, 2013

This article is continuing in the series on exploring Hyperscala. If you have not already done so, I would highly recommend reading the following previous posts as many topics discussed here build on concepts previously discussed:

The Play Framework is perhaps the most popular web framework among Scala developers today. I have been asked quite a few times what is wrong with Play that made me decide against using it and instead write my own web framework. To be fair, Play is a pretty awesome framework and is a great choice for web applications. However, there are a few problems I have with it that led me to choose against using it moving forward:

Templating Language
Though Play does a far better job of this than pretty much anyone else I've seen, you're still dealing with special syntax in your HTML templates for accessing your Scala code. This is incredibly problematic when there is a separation of designer and programmer. Life becomes quickly more difficult when the programmer injects all the Play-specific code into the HTML file that came from the designer and then the designer needs to make a change. Not only does it become difficult for the designer to even preview what the content should look like now, but it is highly likely that the designer will mess something up when they are trying to make changes to the HTML. This was something I spent a lot of time considering and trying to come up with a better solution for in Hyperscala. I have worked at a lot of large companies that have teams of designers and teams of developers and it is incredibly painful bridging that gap. In Hyperscala there are actually several solutions to this problem, but the best one for this specific scenario, I believe, is DynamicContent. We've discussed this in a previous post and demonstrated it in yet another post. The idea is keeping the HTML clean and pure and the developer simply loads in only what they need to manipulate by the HTML 'id'. In my opinion, this is the simplest solution and a much cleaner separation between the designer and the developer.
Yes, there is module support in Play, but it is confusing at best and extremely limited at worst. There is an inherent problem in any framework that doesn't have complete control over the HTML and Play simply does not. The way Play works is very similar to JSPs where content is injected but the HTML is never parsed or comprehended. This leads to several problems when you have modules that need to introduce something like jQuery but shouldn't load it multiple times and want to avoid an issue where another module is trying to load a different version. These are complicated issues that need to be dealt with in large web applications. In Hyperscala the Module system is incredibly powerful and solves all of these problems incredibly well. Not only that, but a Module in Hyperscala is dead simple to write and even more simple to use.
Complicated Setup
Any framework that needs its own console in order to create an application is too complicated. Yes, I agree that it's cool that the Play framework has its handy-dandy console utility to create your application for you, setup your IDE, and probably even brush your teeth for you. However, I very much dislike "magic" that happens and is unexplained. I prefer to understand what is going on under the hood and though you can do this in Play, the decision was made as a default route to hide this from the developer. I prefer to work with frameworks in which you add a Maven dependency and then start writing some code. I don't want configuration files. I don't want a bunch of boilerplate code that is generated on my behalf. I want to instantiate something and run it. This is exactly what Hyperscala does. Once you include your Maven dependencies for Hyperscala you need only create an implementation of Website and add a Webpage to be up and running. In Play you have a minimum expectation of an Application.scala, index.scala.html, application.conf, and routes file.

In an effort to compare Hyperscala with Play practically I decided to take an example from Play and re-write it in Hyperscala. My hope was for a simple 'Hello World' example to keep it simple and straight-forward, but what Play considers their 'Hello World' example is quite a bit more than that. It will have to do.

First lets take a look at the Application.scala file:

This is fairly simple. The idea is that this page asks you for your name to display, the number of times to repeat it, and a color. When you hit submit, it validates the form (based on the validations specified near the top of the page) and then either displays errors or writes out the name you specified the number of times you specified in the color you specified. Notice here that the form validation process is hard-coded, so no special handling is necessary. I point this out now because in Hyperscala there is no "default" for how validation should be handled so it takes a little more code (but not much).

Next we take a look at the HTML files defined for the display.

hello.scala.html index.scala.html main.scala.html

It's fairly clean and I'm sure once you get used to the Play syntax it becomes easier to grasp. However, this would be quite difficult for a designer to work with. I'm sure there is a better way to represent the page for designers, but then you obviously lose out on much of the power of Play.

Now lets take a look at how this same functionality would look in Hyperscala. Like I've said several times now, there are many ways to accomplish the same task in Hyperscala and this is just one way.

First lets look at the HTML, since this is what we really should start developing from. We can focus on getting the design exactly how we want it before we even think about Hyperscala:


This is our basic HTML for the page. Notice there is absolutely nothing specific to Hyperscala or non-HTML in the file at all.


I've extracted the 'configure' page out into this snippet because we're not only going to replicate Play's Hello World example, but we're going to leverage the Realtime module of Hyperscala to avoid doing a POST and thus keep you on the same page for the entire experience. I could have replicated the form posting utilizing FormSupport mixin, but hopefully this will work as a good example of how easy real-time communication is in Hyperscala. Again, notice that there's nothing special about this HTML. It can easily be previewed in the browser and edited by a designer.

Now, lets take a look at our Scala code:

PlayHelloWorldPage.scala PlayHelloWorldConfiguration

Not much to see that hasn't already been explained in past examples but there are a few things of note. First, notice the call to Realtime.connectStandard(). This, as the scaladocs says, connects all inputs, textareas, and selects to fire change events and buttons to fire click events to the server. We can do this manually, but this saves us a few lines of code. The other thing of note here is the adding of validation. The 'addValidation' method is received as an implicit conversion on FormFields (input, textarea, and select) by importing org.hyperscala.ui.validation._. We utilize some built-in validations and use the ClassValidationsHandler to apply the error class to the outer container and set the message to the error container when validation fails on a field. Like I said before, how validation works in Hyperscala is not built-in, it's part of the UI sub-project and defines some convenience functionality of how error might be handled, but opens the door to supporting validation errors any way you see fit.

In conclusion, I would argue that while in this example the lines of code may be equivalent, the benefits should be seen particularly for larger applications and for interaction with designers. I do not want this to come off as me bashing Play Framework. I have nothing but respect for the framework and the developers that created and use it. My purpose in this post is merely to compare and contrast the architectural choices in one framework against another and to hopefully better explain why I believe Hyperscala to be a better framework in many situations.

Source code referenced for the Play Hello World example came from Play samples on github:

Source code referenced for the Hyperscala comparison came from Hyperscala examples on github:

Hyperscala: Chat Example

Published by Matt Hicks under , , , , , , , , , , on Tuesday, January 22, 2013

Up to this point we've talked about the high-level features of Hyperscala and have gone through a simple Hello World example, but today we're going to write a real application to show a fairly simple real-world web application.

The real-world application we're going to write today is a chat example. This will utilize real-time messaging, cross-session interaction, abstraction from the user-interface through DynamicContent, and much more.

We will be building upon concepts we've already discussed in the past two posts, so if you haven't already read them I would recommend doing that first. I'm going to skip over the project setup and even the website configuration and focus solely on the webpage for the chat in this post.

The first thing we need to do is to create our webpage class and for the purposes of this tutorial we'll call it ChatExample. As we can remember from previous discussion the basic setup for a webpage simply requires extending from

Pretty simple so far. Next we are going to leverage existing HTML for the user-interface rather than writing it all in Hyperscala. This is generally the preferred route when you have a disconnect from the designer and the developer and allows for a very clean separation of duties.

The first HTML file is chat.html. It defines the form and layout of the page:

This should be put in the src/main/resources path in your project. Now, DynamicContent requires the HTML to be presented to it as a String, so we need to load and cache that HTML file:

That will load in the HTML file and store it as a String for usage in each page instance. Now lets create a DynamicContent instance in our page to load that HTML for usage and add it to the body of the page:

Now that we have the DynamicContent loaded we can extract any HTML elements we want to modify or listen to:

If you look back at the HTML file you'll see that the Strings being supplied reference the HTML elements by id for lookup and loading. After these elements are loaded we can then modify them or even introspect the existing data from the HTML. Technically we could just load the entire HTML file and parse it as a Hyperscala structure, but that would be a waste of resources and add unnecessary complexity. By using DynamicContent we can reference only the things we care about in existing HTML and the design can change over time without any necessity of the Scala code changing (so long as those elements remain of the same type and id).

Next we need to add some real-time support to these elements so we can listen for changes and clicks:

The require call is necessary to make sure we have support for Realtime messaging. This is a Module that provides two-way communication between the server and client preferring WebSockets and falling back to long-polling AJAX. The other three lines simply connect JavaScriptEvent to the client-side corresponding JavaScript events. This will intercept client-side events of the specified type and fire them on the server as well. Note that this is simply making that occur, we now need to actually listen for the changes we're interested in:

The above code listens for changes to chatName and updates the internal nickname. This will allow you to distinguish between who is messaging. Second, we add a ClickEvent listener to the submit button to send the message. Now lets see the body of these methods:

This method is rather simple. It calls off to our companion object calling its sendMessage method passing your nickname and the message you typed. Next it clears the value of the TextArea. Finally, it uses jQuery to request focus back to the TextArea. We'll cover the ChatExample.sendMessage method in a minute.

First we add a nickname property to our page instance so we can reference the currently accepted nickname for this user. The updateNickname method first checks to see if the chatName has anything entered. If it doesn't then it assigns the name 'guest'. Next it calls off to ChatExample.generateNick with the nickname to verify that an existing nickname isn't already present. Finally, we assign the chatName input's value to be the newly assigned nickname.

Now we need a HTML representation of each chat entry:

We need to load the HTML again, so we add another val representing the HTML as a String in our companion object below Main:

Now we create a custom class representing an individual chat entry:

We can simply instantiate this and add it to our messages div for each message. Notice that this is very similar to our previous use of DynamicContent except this time we are extending it instead of simply instantiating it. Also, notice the use of reId = true during load of the name and body divs. This is necessary when using an item multiple times on a page as you'll end up with duplicate HTML ids in the code if you don't. When we specify reId = true that will simply assign a new unique id to the element at the time it loads it so each time it will be different.

Lets look at the rest of the content of our companion object now:

There's quite a lot going on in the above code although hopefully the majority is fairly easily understood. First we see we're keeping a history of all the messages so when a new person joins they get to see what's already been said. The instances method gives us a peek into the powerful session framework to look up all of the ChatExample pages across all sessions on the site. The generateNick method takes the supplied nickname and checks to see if it's already in use. If it is then it will add an increment to the end until an available nickname is found. Finally, sendMessage broadcasts the message to all pages adding a ChatEntry in their context. It is necessary to mention context at this point. For many of the underlying features of Hyperscala events and other information are localized to a page so in order to invoke changes across multiple pages we must work within that pages' context. As you can see it is incredibly easy to contextualize to the page by simply calling the context method and passing a function to be invoked within the context.

We have covered a very broad scope of functionality in this post but hopefully it was all clear and understandable. The end result should look like this:

All of the source referenced in this tutorial can be found in the GitHub repository: