I was recently at Devoxx in Antwerp, primarily because I wanted to get involved in some of the sessions that were being hosted by guys from the AngularJS team at Google. I've had a chance to work a little with Backbone and KnockoutJS and had been recently deliberately holding off looking at AngularJS so I could hit the conference and workshops fresh and unencumbered with any preconceptions.
The sessions were great, and since then I've been working on a couple of projects that use Angular. As I've always found writing about a topic a great way to really cement what you know about it, and to understand where the holes in your knowledge are, I've started a new series of articles called ‘Practical AngularJS’.
Anyway, enough chatter - part one of Practical AngularJS is now finished. It's a new series, so it's early enough to have a say in where it goes, please comment and share and let me kn0w whether you find it useful, pointless, or anything in-between.
As a short teaser, in Practical AngularJS Part 1 - Introducing AngularJS we take a look at what AngularJS is, why we'd consider using it and when. We start out with a trivial task for a web application, and see how it quickly becomes a bit sluggish and painful to do certain things, then see how using AnguarJS can ease that pain, letting us focus on the important stuff and it help out with the grunt work. We take our initially messy app and make it a lot more manageable, and look into how we can with our new structure start to write unit tests for the logic.
So this is the bulk of Part 1. Unless there's a strong push for another topic, Part 2 will focus on testing. Testing is core to the development ideals of the AngularJS project and is something that it was built in mind for. We'll look into how quickly we can write unit tests, and the flexibility that we've got.
Rather than advocating patterns such as BDD or TDD, we'll again shy away from theoretical discussions about what is conceptually the best paradigm and just dig in - playing with the code and seeing what works and what doesn't. By the end of it you'll have a good idea of the freedom you've got with testing - leaving it up to you to choose the pattern or process that fits your style, or the style of your team and project the best.