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.
There’s a new task runner around, Gulp.js, and it’s supposedly very good (haven’t had a chance to try it yet) but there are still many projects using Grunt. If you want to try out Gulp on an existing Grunt-based project, it can be tedious to start rewriting things because Gulp is imperative and based on the idea of streams while Grunt is more declarative.
grunt2gulp.js helps make the transition from Grunt to Gulp. I used the files on this blog post as a test case, and I also used a Gruntfile from a strongloop project as a test case. Both test cases are included in the examples directory.
What I like about gulp from what I saw is that it’s a wrapper around orchestrator and vinyl-fs and it’s straight-forward. Grunt is monolithic from what I’ve seen and I think moving to Gulp will be a good move over the long-term. However, I think there is still a place for a declarative sort of task configuration file.
In any case, if you’re trying to move to Gulp from Grunt, check out grunt2gulp! Feedback would be great, and patches would be freaking awesome.
Working on a django site at work, it’s not bad, however still working with angularjs code after work and on the weekends.
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
1. Todd Motto
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
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.
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
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:
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.
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.