Typical Noise

Alex Arnell

Coffee fueled terminal junky. A Software Developer with a strong passion for good software design and an unquenchable thirst for learning.

What I love about AngularJS - Part 1

I have been developing AngularJS applications for a several months now. I have really come to like the framework and this series of post will explain why. If you are looking for yet another tutorial on how to get started with AngularJS then this serious is not for you. Instead I intend to address a fundamental issue I have with the approach we have taken to writing software and how AngularJS has resolved my frustrations.

There are a lot of client side frameworks available. They all provide developers with some form of MVC pattern. Most of them simply re-hash the same patterns we have seen in server side frameworks like Rails, Django, and similar. Granted, most of them do offer new capabilities like some for of 1-way or 2-way data binding. They all still fall short when it comes to solving a fundamental issue I have with the way we structure and build applications today.

All of this frameworks a great, don’t get me wrong, but they all seem to focus on the MVC. It does not matter if the application is largely server side or client side. Take your typical Rails application. Everything will start out clean early on in your applications development. Your models are clean and small, the controllers are simple and you have no logic cluttering up your views. However, as the business goals evolve and more and more business logic is placed into your application that logic needs to go somewhere.

Most likely the first place this logic will appear is in the Controller. As time goes by the Controller gets more and more complex and soon it’s a 1000+ line beast. This is how I’ve seen a lot of early Rails applications structured. Lucky for the community this was quickly recognized as a bad approach. So all the business rules where moved out of the Controllers, leaving them to focus only on coordinating the interaction between the models and the views.

So where did that business logic end up? In the models. This is what coined the term “Skinny Controllers, Fat Models”. I argue that this logic does not belong in the model. A model shouldn’t know or care about the business rules defining how to transfer funds from one user’s bank account into another users bank account. A model should represent the data and that is it.

The business logic is the heart and soul of your application. It’s the entire reason for your application to exist. It is your Use Cases. Controllers, Models, Views, these are all part of the framework you are using they are not your application. So why do we treat these constructs as first class citizens and struggle to find a home for our business rules within our chosen framework?

AngularJS is a framework that solves this fundamental issue. Over the next few posts I will go into more detail about what makes AngularJS different and it how solves this problem.

Tmux Pro Tip

If you ever find that you've done something silly like

 bind -n o select-pane -R
 bind -n O select-pane -L

Then reloaded your tmux config live. Now when ever you type o or O you're switching panes left and right. No problem easy fix just remove the -n

 bind o select-pane -R
 bind O select-pane -L

Now it works as intended, but wait. Tmux does not automatically unbind keys. So how do you get your Os back?

Simply detach from the session and tell tmux to unbind them

 C-a d # note I have my prefix bound to C-a
 tmux unbind o
 tmux unbind O
 tmux attach