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.
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.
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
I also started exploring three.js, a WebGL library.
The macro I wrote simplifies the render loop, you supply the scene and camera object and the body of the loop and you’re set. The macro sets up the renderer.
Again, not the most appropriate use of macros but it was a nice small way of getting used to macro definition syntax and to explore how much potential power there is.
There’s also a Grunt task plugin to run sweet.js which automates the whole macro compilation step. Just add file watching and reloading and the experience is pretty much the same as developing with CoffeeScript.
Hope this encourages other JS devs to check out what sweet.js can offer and maybe one day we’ll have a nice set of macros to simplify the common JS frameworks out there.
PHPUnit Essentials would have come in handy while on a
recent contracting gig and on all the other PHP projects I’ve worked
on. The book is published by Packt Publishing who seem to be the new
O’Reilly, the last book I bought from them was on AngularJS and it was
a great guide whereas as the O’Reilly book on AngularJS was outdated.
Overall the book was a good read and it’s worth getting as both a guide and a reference.