Follow Blog via Email

I hear this question so much these days. What is the next Angular ?
Or what JS framework would you recommend we use?
Tho which I always answer, there is no silver bullet, there never has been.

Its all about the context in which the application is going to be developed. What good is it to build something in Angular with Node, or Ember with Rails or Backbone with Python, or what ever other stack if the people who are going to implement the code aren’t going to follow standards or simply, don’t know how to tie all the pieces together.

Some things permeate languages and libraries and that is what always should be sought after. A house is judged not by the hammer that built it, but by its architecture and livability.
Small methods, tested code, documentation, good use of memory etc. All these are examples of architecture and style not of tools.

The question we should be asking ourselves is how do we develop this application so we can pluck out pieces of it and put in newer/better pieces without having it fall apart.
It needs a solid base that is loosely coupled and well structured. Clear interfaces and code flow. Single priority methods, good analysis of cyclomatic complexity, multiple device testing automation etc.

In reality you can have your app be small pieces of a lot of things, so long as you can assert it does what its supposed to do and so long as they are all used for the right thing. Focus on having good people that know what they are doing instead of finding silver bullets. Focus on having good test coverage so that when you do pull the pieces out, you know exactly what is broken or what to fix.

In the world of corporate applications, tech is rarely the problem, normally its people and how they are managed or how competent they are at their job.

In the world of AJAX where requests take time, we’ve come to develop a handful of incredible solutions such as promises and deferred responses in order to continue to execute JavaScript with out blocking the thread. This is an incredible achievement for true async comes to existence

But what about the user? The user doesn’t give a damn about your miraculous promises. The user wants the page to do as he/she says.. NOW!

A few months ago a colleague of mine was chasing a pretty interesting bug. We were trying to figure out why some database items were getting duplicated or erased every time a user would submit a form. It made no sense for we had a bunch of form submissions that were pristine, yet some were simply corrupted.

We debugged through the AngularJS code and it was pretty straightforward. The form was getting sent to a service and that service, responded with a 200 if it was saved o,r with the corresponding error code if it was not. So what the hell was going on?

Double click was the cause of the problem. Our users were a bit older around the ages of 50-60 and they are used to double clicking everything. Hence when they submitted the form they actually submitted it twice and this cause all kinds of unhandled issues in the back end. Yes in theory there should have been a check to make sure that user has or has not submitted a form and then updated accordingly but, the UI could have been a little bit more understanding of the crowd and helped out more in handling the situation.

Sample spinner

A simple swap from button to spinner disables the user from being able to submit twice and informs the user that the system has noted his/her request and is working on it.

Some times its trickier. For instance when we have multiple events that can take place on the same page. In this particular case, a global method that detects whether a spinner is present in the DOM or not and if so alerts the user to hold on does the trick quite effectively and elegantly.

An example of a good interaction is Ladda. Here, as the event happens, the button gets injected a spinner right there.

Another cool spinner solution for all device, resolutions and browser versions is spin.js. You should definitely give it a spin (get it?).

Some word of advice, always think about spinners early in the development cycle, and include them in every action that can potentially have latency. Your users will thank you, and you’ll avoid having to debug very weird issues.

The current situation in the world of corporate apps can be described with one word, chaotic.

Between legacy code that has been around for N years jumping from developer to developer with no documentation. To over complicated interfaces that are over complicating the code. To a mixture of N technologies in one single app. Lets face it, these things were not built with maintainability and support in mind. The problem we face today is, how do we fix all these apps? Where do we start? How do we bring sanity into them? How do we bring them into state of the art tech stacks?

This post represents my opinion of why using AngularJS in corporate applications will not only bring sanity to your apps, but it will allow them to evolve into the future.

1) Start little by little

In an Enterprise you are probably starting with an ugly brownfield project, not a nice green field. Something that has been cooked and baked many times over. Making sense out of it is so hard that developers normally tend to just throw away and rewrite. This of course affects cost and time.

With AngularJS this is not the case. You can start by sprinkling it in some places of your app that you can slowly start to rewrite. Believe me I’ve done this before and it actually WORKS. Not only does it work but it allows you to put the seed of a soon to become amazing application. Given the fact that you can put your ng-app anywhere, you can say for instance – Hey, why don’t we start updating this app with the home screen. Then you get your back end guy to write the web services (yes I am a front end developer), you start writing your tests with Karma Test Runner (thank you Voijta Jina) and in no time you suddenly have a Controller a View and Model for the home section of your app, which kicks in when a the given home route is reached. All of this controlled by AngularJS and living nicely encapsulated in its own little world. My friend you have just done a very very good deed.

2) Fast developer adoption, at just a click away

Technology changes so fast that keeping up to speed has become quite a hard task. You either have the right ways of learning or you suffer buying all kinds of O’reilly books and trying to figure out how this thing works.

One of the cool things that have popped not so recently into the scene are Javascript MVC frameworks. These came to be because the community realized how much Javascript was becoming hell to maintain and make sense out of. Javascript MVC frameworks are a good thing and need to be learned and applied when necessary, such as in our case of web applications.

With AngularJS if you know absolutely nothing about JavaScript MVC frameworks you can basically just hop into the AngularJS site, take the tutorial (which is quite cool by the way) and in 10 lessons or so (About 15-30 mins) you will know exactly how to start breaking out and building up an application using a Model a View and a Controller (MVC) and the best part, having all of it be testable.

This allows for large teams to go online at any point in time, take the tutorial and, because they are learning from the same source, they can ask and feed from each other at their own pace. This is very important specially if you have a team that is working remotely from each other.

3) Productivity and Scalability.

Having the ability to scaffold a project quickly with all the goodies that you need is key to getting started and producing efficiently. I’ve been in projects that take about 1 week just for everyone to jump on and install everything that is needed for the given project. This slows down productivity and it is a clear sign that something is still missing from the recipe.

In order to fix this we can use Yeoman. Yeoman is a workflow comprised of a collection of tools that allow you to quickly start, run and build a project.

Yeoman glues pretty well with AngularJS (makes sense since they are both part of the same family). Yeoman will allow you (via generators) to create an AngularJS repo that includes all the latest Twitter Bootstrap stuff, angular goodies, Karma Test Runner etc. And glue it all together just by initializing it under a directory with any name (preferably something related to your app). It will use that name to namespace the application and with that, it will create a sample view tied to a sample controller, tied to a sample test (thank you Brian Ford).

This structure not only allows you to quickly assemble something up, but it lays the roots for something way bigger to evolve. On top of that, once you are ready to deliver, you just run a grunt command and your files get compressed and combined (use ngmin) and put into a separate distribution folder. How sweet is that!

Aside from everything because you are building a single page application, everything should be RESTFUL which means that this app can and will interact with ANY back end code as long as it gives the front end the JSON it needs. You are decoupling your code and logic making it easier to scale and evolve.

4) Tests tests tests

Situation: There are thousands maybe hundreds of thousands of lines of code in a project. You are dropped smack in the middle of it. There is no documentation and there is a new feature that needs to get implemented ASAP. You start fiddling around with the code, next thing you know something else where breaks and you have no clue why… now you have to spend hours maybe days navigating through spaghetti code to see how your change broke something else.. bad, very very bad.

One of the most important things for maintaining a large code base throughout time is the usage of tests. By using Karma Test Runner given to you by the AngularJS generators in Yeoman, you can have your unit tests running all the time in the background, that way if you change anything and hit save, your tests will automatically re-run and you will know if you are breaking something, where you are breaking it, and if the tests are built correctly maybe even why you are breaking it.

This is super useful because normally this is how developers test insert a new piece of code. They add in 10-15 lines, they save then whoops, something breaks. Then they comment out 8 lines of code or so. Save, rerun still breaks? No? Ok so the error must be in these 2-5 lines.

Way way simpler to do this than to have to navigate through N files of hidden dependencies and figuring out what the previous developer was thinking when they were building this out.

5) Good community support

So many times you find yourself stuck with a piece of code and have absolutely no idea why it is not working. The community has never failed me so far when it comes to helping me out with a problem. I ask a question in Stackoverflow or a Google group and within a few hours or maybe even minutes, I get the answer I was needing, sometimes even from the core AngularJS team its self! This not only helps you out but by solving your issue, others might solve their issues as well. This speeds up the learning curves and the detection of any glitches that the tool might have. It basically feeds on its self and continues to evolve and grow.

Conclusion: The usage of a very opinionated Javascript MVC framework such as AngularJS is an excellent way to start cleaning up legacy code for it allows you to start in small pieces and bring sanity piece by piece. If your tech team is not on the bleeding edge they can take the AngularJS tutorial online at their own pace and learn how to use it. Once they are done and ready to produce they can incorporate Yeoman and kick start this upgrade within a few minutes, using AngularJS, Twitter Bootstrap, Karma Test runner and many other goodies that Yeoman scaffolds out. As the developer starts building they can use Test Driven Development to create unit tests and scenario tests for everything they build out in AngularJS. This will guarantee that in the future if anyone new jumps on the project and needs to make modifications, they will be able to do so more easily and with more awareness of what their lines of code are affecting.

AngularJS is not the final bullet proof solution, but it is helping pave the way for cooler things that are coming in newer versions of Javascript such as object.Observe, better controlled scopes etc. These will in theory (and I do believe so my self) bring order in a more natural way into all applications using Javascript.

When it comes to waterfall charts and d3 you have very few options.
1) Your are on your own, which means you are free to draw it how ever you want (which is pretty much the coolness of d3)
2) You use this repo https://github.com/sattybhens/waterfall which will give you a horizontal chart. Has a mix of ruby and coffescript
3) You use this plugin that resembles to what most jQuery users or Highcharts users are used to which is a config object that generates a chart. https://github.com/climboid/d3Waterfall
Currently it only supports vertical waterfall charts. Feel free to use and contribute.

So I previously wrote a post on how to create a map of anywhere of the world using d3. I’ve decided to take that a step further and created a python script that automates the entire thing.
Follow the instructions in this github repo and you should be good.Note: You will need to install GDAL and have Python running.

A good friend of mine, Laurent Brucher was tasked to interview a candidate with regards to his front end skills. We talked for a while, shared ideas and in the end he came up with a clever challenge for the candidate to code out.