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.
However, grunt2gulp.js is starting to get…hairy. It’s about 400 lines (or more?) now and it’s time to split things up into separate files at the least.
I created a new branch called zesty-coffee and it’ll be using CoffeeScript. I’m using the npm preinstall script to compile the files into the bin/ script. Next step is making sure the conversion is complete and works correctly and after that I’m going to create a Gruntfile.js for linting the generated grunt2gulp.js file and for generating the JSDocs from it. After that we’ll have a good working example of a Gruntfile that can be converted to gulp within the repo so it’s easier to dog-food grunt2gulp.
In other news I’ve been slowly but surely fixing some issues with yeoman-generated Gruntfiles. That’s my big goal for 0.0.2 charming-cheetah.
As I work with SPAs (Single Page Applications) it becomes more obvious that some parts of a web app can only be inspected visually. As part of an end2end test or user acceptance testing, manually checking screenshots is still faster than manual testing. Screenshots at different steps of a process can be put together into a presentation or PDF and presented to clients or other stakeholders to show them that not only is the backend code working, but the frontend looks and feels right.
So here’s a snippet for taking a screenshot with Protractor, which is designed for AngularJS, and an end2end test that uses Jasmine and Protractor.
When to take screenshots during an end2end test:
- to inspect the layout/styling
- to inspect how the site looks across multiple browsers
- to verify with client/stakeholders that we’re building the right thing
- to share with other developers when debugging an issue
It’s neat, they provided their own example. It’s in Japanese but you can read the translation by selecting your language in the left sidebar. Really cool, they have some more screenshots.
This was just a small thing I hacked up based on a shell/command-line tool called doing and it makes me happy that someone else has found it useful.
In the past year I’ve been trying to get my system for productivity and organization done. I have read and re-read Getting Things Done and things are slowly coming together. As I mention in a previous post, I’m using ZenDone for the list of next actions and the contexts that I can do those next actions, and I’ve been using Evernote for storing all sorts of notes and more details on the things I have to get done and for organizing projects.
However, I’ve been missing something: a list of priorities for the day. This is different from a list of next actions and from calendar events; you may have to do some chores today but they aren’t a priority, you might have to go to three meetings but only one of those meetings is a priority.
The list of priorities for the day is an idea inspired by the book The One Thing. It proposes that we have to discover the one thing in life that we want to do and align everything around that. Ideally all of your priorities will be related to and aligned with the one thing that gives your life purpose and meaning.
Here I’m going to talk about how to use mocks when writing unit tests for Django. Using mocks has really opened my eyes on how much better unit tests can be written.
At least judging by the stats on the Learning AngularJS newsletter (click here to check it out). The last two newsletters were about AngularJS 2 and the open and click rates were much much lower. It looks like the people subscribed want more real-world AngularJS 1.x articles and tips. It makes sense as there is a lot of AngularJS 1 code out in the wild and AngularJS 2 has only just hit the developer preview stage and won’t be out for another year.
While the documentation for jasmine is great, sometimes all you need a cheat sheet to reference for the API. I found this jasmine testing cheat sheet to be very useful after doing lots of Python unit testing which doesn’t use the same API as jasmine at all. The cheat sheet helps reduce the penalty of the context switch.