JavaScript Garbage Collector Presentation

Last time I mentioned that I would be giving a talk at a local event - the Carolina Code Camp. Well, today was that day and I'm happy to report that the presentation and the event as a whole went very well! I hope to refine the presentation even further to present again at future events.

For anyone interested the GitHub repository that holds the actual presentation with all links used is available to view.

For a working version of the presentation (latest version), it can be found here.

My First Speaking Engagement is Official

I've often thought about being the one in front of the room during a code camp or some other speaking event. Though, like most of us, I've always been reluctant to put myself up there, scared that someone will call me out on not knowing what I was talking about or, worse yet, they all walk out on me.

However, with the fine coworkers at Wintellect and other friends, I decided to bite the bullet and sign up as a speaker for the Carolina Code Camp this year. After a couple of days of debating with myself on what to talk about, I decided that a talk on the JavaScript garbage collector would be interesting. I've always enjoyed learning about performance and this should be practical for others to learn as well.

So if you're near the Charlotte, NC area on Saturday, May 3, I encourage you to attend what has always been a great event since I've been going three years ago. Hope to see you there! If you end up going and even go to my session, try to refrain from throwing things.

The JavaScript Garbage Collector Demystified

Consuming the Jamendo API with AngularJS: Services

It took a little while to get back to this little project. After watching some nice stuff from NgConf the other week, it helped get me excited again for AngularJs. Plus, I was stuck on a problem for quite a while that I'll explain in more detail below that really slowed me down. After a bit of a break I got back to it and was able to figure it out.

Services

Before we looked at how to use the $http get method from AngularJS, but all of that was within the Angular controller itself. To separate things out and to help us test easier I moved the $http calls into an Angular service.

To recap, let's take a look at our controller currently:

As mentioned earlier, we have our $http call right inside of our controller. While that definitely works, it's better to separate that out into it's own service. Let's refactor this down a bit...

Now this looks a bit cleaner. We're first passing in the albumsService as a dependency into the controller. Of course, if Angular can't find that the albumsService is defined, it'll throw an error.

Next, we have the function definition of our getAlbums method. In here we extract out the artist from the scope and then call the getAlbums method on our service. In our call to the service we give it a function as a callback if the $http get was a success that we'll see later when we look at our service. This basically just gets the results and puts them into the scope.

Now let's take a look at our service.

Pretty straight forward as it's basically the same as what we had in our controller earlier. We inject in the $http Angular object and we create our getAlbums method while prepending it with this

When we call our success promise from the get method, I just pass in the callback method that we defined in our controller earlier. This makes it a bit easier on our service since the callback method was updating our $scope object and we don't have to worry about that here in our service.

I mentioned earlier that I had a bit of an issue that kept me from finishing this up. I kept getting an $inject error on my service that indicated that it wasn't defined, but I couldn't figure out why that was. After some fiddling around with it, it turns out that I was trying to inject the $scope object into the service and Angular doesn't like that. That's also a reason to use the callback.

Conclusion

Moving the $http get call to an Angular service is mostly just a small refactoring, but it's a good one to do. We will see later when we start to do testing how much easier it is to have that separated out.

Of course, this was just an introduction to Angular services so there's tons more to learn about them. I'll recommend Dan Wahlin's AngularJS in 60ish Minutes to anyone. In fact, I've referenced it a few times to remind myself about services. There's also the WintellectNow video from Jeremy Likness on AngularJS Services that goes into much greater detail of services.

You can play with the demo and, as always, you can play around with the code itself.

As An ng-conf Virtual Attendee...

This past Thursday and Friday, Google held a public conference for all things AngularJS. I'm sure you've noticed lately that I've been a bit of a fan of it, especially the more I play around with what it all has to offer. 

Luckily, the fine folks who put on the conference decided to stream it as it was going on. Awesome! I got to catch a few of the sessions. Though, it's not the same as actually attending as I couldn't meet all the great people and speakers there, watching the live stream is the next best thing.

I didn't get to see all of the sessions yet (they have all been uploaded), but here are the ones I have seen that seemed to stand out:

In total, I'm glad I was able to catch what I could of the live stream and hope that next time I can be able to join in person. I hope at some point I can be able to contribute something to help make everyone's life easier with AngularJS.

Code Katas Can Be Helpful

After reading a few posts in the development community lately about code katas, I felt I should put out my own opinion about the subject. 

At work, a few of us developers decided to take a couple of lunches each week and get together to work on a code kata that we all decide on prior to the meetings. This was mainly so we can increase our skills in development, but mainly it was a way for us to use a new or not so familiar language for a fairly small coding project.

For our first shot at a kata we decided to try Poker Hands (you're always welcome to view my progress), which we had to rank two player's poker hand and determine who won and display how they won (high card or higher set of cards). Not exactly the easiest kata to do, especially when doing it in a language you're definitely not familiar with, but we thought it was one that could give us a good challenge.

Another aspect to doing katas is to do solve very small problems. One of my favorite ways to do this lately is by playing around at Code Wars. I've been messing with the JavaScript and Ruby katas there and have been learning quite a lot about the languages as each new kata I do gets progressively harder. They have a pretty slick interface, as well.

I feel this site does a lot of things right. Most importantly, once you've successfully finished a kata it will also display how others have successfully implemented it. Looking though those can help see how other people use the language to their advantage.

Sure, you can also be doing other things in order to learn, such as messing around GitHub for a project to contribute to or volunteering. However, a big benefit to doing these small katas is because they are small compared to these other types of projects. You won't feel as overwhelmed by the size of the project or try to figure out where to start. Here you just create the appropriate class or function and make sure all the tests pass. 

Of course, you want to do code katas because you believe they help and because you find them enjoyable. I feel like I'm learning new languages little by little the more I do these. I seem to have rekindled my love of programming just by doing these katas. I hope I'm not the only one.

YUI: The Other JavaScript Framework

When you think of JavaScript frameworks, what pops into your mind? JQuery, KnockoutJS, or EmberJS? Did you know that Yahoo! has one of their own? It's YUI  and it's actually not too bad of a framework. 

It's definitely not what you'd think of when creating a new web application. For any kind of DOM manipulation, I'm sure the first thought will be to use jQuery. I wouldn't exactly count out Yahoo!, though. They have some of the top engineers of the country and they released YUI as an open project for anyone to fork and contribute to.

Below is a very small example of using YUI. How easily can you read through it? 

Fairly simple, right?  You get one instance of the element with the "btn1" ID and on the click event run the function that has the alert.

Let's look at a more complex example of YUI in action. We're going to make a JSONP call to the GitHub API. Let's take a look.

Not too much more here than in our first example. I'm still using the selector and click event handler as we've seen but in the click handler of the button I make a JSONP call to the GitHub API. The real magic happens during the function that handles the response from the JSONP call. The Y.Lang.sub  call takes in an HTML template and uses the data from the response to bind the items in the brackets. Of course, the names have to match what you get back in the response.

Conclusion

These are just very small examples of what you can do with YUI. The documentation contains a ton more examples and functionality of what the framework is capable of.

I do believe this is easier to maintain and use than using jQuery. I do have to say, though, since I've found AngularJS, I believe I'll be using that more and more. If I couldn't use that, however, YUI would be my framework of choice.