Get The FREE Learning AngularJS Newsletter

Since I like using AngularJS and the current client project and the last few client projects I’ve been on use AngularJS, I realized there may be others out there who want to start learning AngularJS or enhancing their current AngularJS web apps. So I started a newsletter where we post the newest books, tutorials, articles, modules and code libraries that AngularJS developers should check out.

Click here to start getting the newsletter!

You can click here to check out the Learning AngularJS Archives before you sign up.

Quality Software Costs Money – Fund FOSS (Free/Open Source Software) Projects

Originally posted on SourceContribute:

Poul-Henning Kamp has written a fantastic article about why companies should just “throw money at developers” of free/open source software projects. The recent Heartbleed problem with OpenSSL could have been caught had there been more developer time devoted to the project. However, that developer time costs money and we should be far more giving to free/open source projects.

FOSS does not materialize out of empty space; it is written by people. We love what we do, which is why I’m sitting here, way past midnight on a Saturday evening, writing about it; but we are also real people with kids, cars, mortgages, leaky roofs, sick pets, infirm parents, and all kinds of other perfectly normal worries.


The only way to improve the quality of FOSS is to make it possible for these perfectly normal people to spend time on it. They need time to review patch submissions carefully…

View original 150 more words

Top 3 Influential AngularJS Bloggers

1. Todd Motto

A developer at Google working with AngularJS every day it seems, Todd Motto is writing quite a bit on Angular and JavaScript in general. His opinionated AngularJS style guide for teams was popular on reddit and hacker news and has inspired AngularJS devs to think about writing their own style guides based off of his style guide.

He also has a nice article on creating an AngularJS directive from one of your existing plugins/scripts.

2. Year of Moo

They don’t post articles about AngularJS often but when they do, they’re full-on guides that cover a lot and contain many useful ideas.

One of their most popular articles is about unit testing, end2end testing and midway/integration testing with AngularJS. This article is the standard reference that is linked to everywhere whenever unit testing in AngularJS is discussed.

3. Misko Hevery

The father of AngularJS posts non-stop on Twitter about Angular and how it works with Dart, Google’s JavaScript-based language. He re-tweets many great articles that can help you when developing AngularJS apps, and he has over 10,000 followers.

UPDATE: I forgot someone on this very brief list!

4. Ben Nadel

Ben Nadel has been writing AngularJS articles for…since forever (2012) it looks like and in great depth too. He wrote a good article covering performance of $scope.evalAsync and even wrote his own replacement for $resource/ngResource called httpi.

More Places To Get Your AngularJS Fix!

Overall it’s hard to find out who’s the most influential, there are more and more people checking out AngularJS every day and it’s a decentralized community, you can find great information in all sorts of places.

If you’re learning AngularJS or becoming a master,
check out the Learning AngularJS newsletter.

If you want to keep up with the latest news in the AngularJS community,
check out ng-newsletter.

Neglected machine learning ideas

Originally posted on Locklin on science:

This post is inspired by the “metacademy” suggestions for “leveling up your machine learning.” They make some halfway decent suggestions for beginners.  The problem is, these suggestions won’t give you a view of machine learning as a field; they’ll only teach you about the subjects of interest to authors of machine learning books, which is different. The level-3 and level-4 suggestions they make are not super useful either: they just reflect the tastes of the author.

The machine learning literature is vast, techniques are bewilderingly diverse, multidisciplinary and seemingly unrelated. It is extremely difficult to know what is important and useful. While “metacademy” has the horse sense to suggest reading some books, the problem is, there is no book which can even give you a survey of what is available, or make you aware of things which might be helpful. The best guide for the perplexed, in my not…

View original 2,007 more words

AngularJS: testing services that use $resource

Currently I’m working on a project that uses ngResource (imported into the code as $resource) and the unit tests related to the service relying on $resource were failing. I jumped in to do a rewrite or to scrap them entirely if necessary.

My tool kit:

  • Karma test runner
  • Jasmine unit testing/spying/mocking framework

The service looked something like this:

The Problem

How to unit test a service that relies on $resource was the problem. When I searched around on how to test services or factories that rely on $resource, it appeared that people were trying to mock out $resource which didn’t work. Most of them also tried what we see above and mocked out $httpBackend. This partially works, but didn’t allow for the forcing of certain code paths which is necessary for getting maximum test coverage.

Unit Tests Vs. Integration Tests

AngularJS uses dependency injection to make it easier to test things like this, but once you’re mocking out objects like $httpBackend and $resource, you’re no longer writing a unit test. You’re instead writing an integration test.

An integration test works by testing the class and its integration with other dependencies. With $resource-based services, your unit test for the service is an integration test.

The Solution

After some days of searching StackOverflow and other tutorials and articles on how to unit test AngularJS services that use $resource, “Working Effectively with Legacy Code” gave me an answer in a few minutes of reading: move the functionality into a new class.

To break the dependency of the service on $resource, I used the advice of “Working Effectively with Legacy Code”. This is a wonderful book that every software developer should have on their shelves or on their ebook reader. Great reference books are a god-send and quickly help you solve a problem.

The reason for this is that the callback functions given to the $resource promise are private functions. There is no way of accessing them until you call the promise and force it.

To avoid writing unit tests based on mocking and to avoid having inaccessible/untestable functions, I moved the callback functions to a new class and the OriginalResource now only contains methods that require $resource:

There is now a new service, Original, that doesn’t rely on $resource. The old service, OriginalResource, hooks up the new service to the $resource class. This is far easier to test because you can invoke the success or failure callbacks whenever you like and check to make sure it changes the right parts of the system.

The conclusion: when you’re writing services that interact with the backend, you may need to break your service into two services to avoid mock objects. And this is okay! There’s nothing wrong with refactoring code to make it testable without having to resort to mocks. “Working Effectively with Legacy Code” has a lot of other good advice for dealing with spaghetti code.

Things I have learnt in the first 5 minutes of using Elastic Search

Rudolf Olah:

pretty much the same experience I’ve been having, at least the documentation part. it’s almost non-existent and single sentences to explain options in the query DSL are useless, there aren’t enough examples either.
what’s with JS and newer developers completely forgetting to write documentation? It’s strange and unfortunate.

Get this great book on using Elasticsearch. It helps fill in the blanks that the documentation has.

Originally posted on Sammaye's Blog:

After hearing all the raving about Elastic Search and how it was awesome and “rad” or whatever “hip-young” programmers want to say I decided I would give it a go.

To get the point since this might be a bit tl;dr: I am not overly fond of it. I am unsure what companies like GitHub see in it.

It has a queue, no need for a river

Excactly that, implement it into your active record and you don’t need to river.

I would in fact advise agains the river, it ues the oplog which can be slow and not only that but you are adding yet another lock on top of the secondaries that are trying to read as well, which may increase your chances of replication falling behind, this is of course dependant upon how often the river pings your oplog and how many new ops you have in…

View original 1,689 more words