Using Aspect Oriented Programming (AOP) techniques, you can easily decorate AngularJS controller methods to add additional behaviors. This can be useful for handling analytics and other common concerns in a typical application.
I have to agree with the other comment, this walk through is almost entirely incomprehensible on first view. egghead.io really launched me into angular in the beginning, and i was happy to purchase the pro plan, but lately the videos are visually cluttered on the screen, difficult to follow, and seem to be focused entirely on testing instead of actual application.
I understand how important the testing aspect of this is, but i find it easier to follow and understand and really learn the core principals in one video, and then dive into the testing of that method in a separate section. I felt like the earlier videos did this really well.
This is actually a really interesting topic for me, as AOP in angular is a critical part of a project i just started. same with the 'base model' example in the other video. but both videos haven't actually helped me really understand the concepts or execution because they are so fast and only focused on testing, not actually executing in a real-world situation.
that's just my feedback. (sorry, this is the only feedback mechanism you guys have. maybe this is an inappropriate place.)
Thanks for the feedback, and I agree with you. I'll take the blame, as Trevor originally delivered this with an example, and I asked him to re-cut in its current form. It would be more coherent, perhaps, is if this video ended with a simple usage example.
These concepts are a lot harder (and arguably more interesting) than what we've covered in the past. There is a huge difference in showing how to use a framework API and how to build a framework API. This video is the start of the latter.
With this in mind, the TDD is a critical aspect of developing framework APIs. Perhaps more so than code that is simply using an API. Skipping the testing portion implies that skipping the testing portion is how it should be done.
In my training and consulting experience, there is a clear stereotype: nobody really tests anything, and they certainly don't test-drive. "Test later" equates to "test never" in practice, and code like this should absolutely be test-driven.
We're working on getting better and continuing to push the envelope with these more advanced topics. It's sorely under-covered subject matter, probably because it is more difficult to teach ;)
At first, I was leaning towards agreeing, but on a second walkthrough, I followed very well. It's a higher level of js, and I love that my egghead subscription is going to help make me a better js programmer and not just teach me frameworks and tools. I was actually starting to use it less and less, but this kind of stuff will keep me coming back for a long time.
I came from several non-functional programming languages. It took me a while to really understand function scope and closures, and when I finally got that, felt pretty good. Realizing lately that this is the next step. Prototype and such looked so easy I never gave it much thought about it's true power.
Can't wait to see the next vid. I've already started playing around with this, so will be interested to see if it's used the same way I'm envisioning.