JavaScript for Line of Business Applications

The first time I pulled up my text editor and starting working with Angular.js minifcation wasn't on my mind. Playing with Angular's cool features took precidence, and dependency injection was a very new concept to me. Of course, as my application grew and I began to think about compiling and compressing my javascript, I was presented with a fun plethora of javascript errors and missing providers. What happened? It all comes down to dependency injection and the way Angular handles internal dependencies.

You see, when you create a controller, directive, modules, service, etc. (basically anything where you can inject dependencies) Angular runs the parameters of your function through its registered components and looks for matches.

This is how most of us learn to use Angular, and it works great until we try to run it through uglify or minify to compress the code. If you know how minifcation works, it should be pretty obvious what happens. The first example above may compile to look a little like this (I've expanded the code back to readable JS to make it readable) ...

Two years ago I wrote about “How to get started with Node.js”: I think most of the information there are still valid… even the book Node.js in Action is still a MEAP (this time planned for release this month, August 2013).

This summer I’m planning on revising, during my holidays, the architecture of OpenROV, and given the huge number of people that are starting to use it, I want to inject" a bit more of “better ALM” in the mix, so I started to look around for coding conventions, development guidelines and how to do unit testing, continuous integration, build and so on: this post is a collection of some link that I found useful.

* Coding and development guidelines

* Testing framework

* CI and build

* Deployment

JavaScript source code visualization, static analysis, and complexity tool

Whenever a new commit is pushed to the master branch, our internal Jenkins server picks it up and runs not only the test suite, but the complete grunt pipeline. It also installs all the bower components before that, as those are not part of our repository. There are conflicting opinions on whether committing your components to the repository is a good idea or not. In our case we haven’t seen any negative side-effects. If the build and test suite passes, Jenkins updates or initializes a new git repository in the dist folder that the grunt build created and pushes the complete content to a dedicated deployment remote. After that, Jenkins kicks off capistrano which checks out the deployment remote on the staging server.

On our journey through Node.js we encountered several new problems that were either not a problem or were easily solved back when we were on Ruby on Rails. But I suppose this is to be expected when moving into a platform that's the first server-side implementation of its kind. When making the decision to move to Node, we evaluated a lot of different requirements we had for building our Single Page App, namely:

You can use “meteor deploy myapp.meteor.com” in your project root directory to spin up your app in a development environment that’s maintained by the awesome folks at Meteor. It’s a simple process. The problem is that it is explicitly stated that this is not for Production apps and you don’t get multiple hosts. So pretty quickly, you’ll need to find a new solution once you go live.

Note: Meteor’s hosting platform Galaxy is coming to beta in the coming months. It’ll likely stay in beta for a while with a disclaimer that it’s not for Production apps. When it’s ready, it’s going to be glorious, but until then, you’ll have to find an alternative solution.

Use “demeteorizer” to bundle up your application as a standalone node app and deploy it to one of the several Node hosting platforms like Heroku, Nodejitsu, or Modulus. This will certainly work if you only need one server (dyno, servo, or whatever each person calls it). But once you need to scale beyond that, you’ll bump up against the fact that none of them offer sticky sessions in a way that your Meteor app needs.

Don’t let their marketing fool you. Some claim to offer sticky sessions. They are lying and when you run into problems and in the face of proof (an ip log showing the same visitor hitting multiple servers), they’ll shrug their shoulders and say, “we don’t know Meteor”.

If none of this sounds attractive to you, then you do have another option. It’s the place we ended up at: we just rolled our own stack. And it was easier than you might think.

There is still no best answer to client-side package managers and dependency management. We still have to cobble together the solutions that work best in the context of each project, but at least we’re not downloading js/css manually through the browser, using wget or writing bash scripts to download/update our client-side dependencies.

We have better options.

Rich tools for instrumenting, analyzing, and visualizing web apps.
Make your app jank-free at 60fps! Squeeze every drop of performance out of your code.

* Rich Tracing
Choose what methods to trace and add custom data to each event. Track asynchronous flows and actions.

* Slick Visualization
Smoothly dig through millions of events in an awesome UI. See patterns and understand your code like never before.

* Extensible Framework
Write extensions to capture more data or visualize it in new ways. Write small node.js scripts to process traces and pull out useful data.

* Canvas & WebGL
Capture and replay HTML5 <canvas> and WebGL content. Write tools to analyze and test your drawing.

* Track Memory Usage
Find every byte allocated by every function via heap tracking. See not just the what but when and who of every allocation.

* Remotely Trace Android
Grab captures and analyze pages running on Chrome for Android using a simple remote controller.

Here are some of the things we wanted to do originally:
* Preprocess the index.html template
This lets us distinguish between builds for different platforms. E.g. Android vs. iOS vs. Web
* Compile the templates into a single template file
Less requests means faster load times. The single most important load time to minimize is the first one.
* Minify the CSS and JS
Both are interpreted languages which parse and run faster when there’s less characters to be parsed.
* Lint the existing codebase for semantic gotchas
A standard software engineering practice that catches subtle kinks in the code before they get out of hand.
* Run shell tasks as build phases
Handy for moving files around or further automation during intermediary stages of a build process.
* Connect to the PhoneGap Build system
We used this system in the early stages of the app to keep things relatively uniform across Android and iOS platforms.

I’ve been working with ASP and ASP.NET for about ten years now, starting with ASP classic and settling on .NET 2.0 as my favorite. My new year resolution this year (2013) was to upgrade my .NET work to .NET 4.0 using Visual Studio 2012 Express and really get to grips with MSBuild, so that I can concatenate and minify my JavaScript files as part of the normal build process of a .NET project, in Visual Studio.

I wanted a non-trivial project to demonstrate this process, because I find the devil is in the details. I have often faithfully followed an overly-simple tutorial or introduction to an unfamiliar subject, then discovered that the tutorial did not prepare me for when you want to do something even slightly difficult. So, in this tutorial we’ll be attempting to marry Knockout.js and jQuery UI. We will also be using a JSON file with a hierarchy of data to define a menu.

Create an Ember.js application in 5 minutes using Yeoman and its associated tools. This Ember tutorial gets you up and running fast.