In the last month I was looking for a Node.js library for authenticating with APIs that use OAuth 1.0a or OAuth 2.0, and found a pretty good library: node-oauth. It was great but it would have been nicer if it had promises instead of callbacks, and maybe if the OAuth 2 class implemented more methods. I started to worry that the library didn’t seem maintained, there were lots of issues and pull requests that are still waiting for a response or to be merged into the code.
I’ve also been reading Free as in Freedom and The Cathedral and The Bazaar and the hackers of each book, Richard M. Stallman and Eric S. Raymond, both took other projects and improved them and contributed back their changes and improvements to the community. With their maintenance, the projects (Emacs and fetchmail) had vibrant developer and user communities.
So I have decided to basically adopt the node-oauth project under the new name node-oauth-libre. This blog post is the announcement that I’m doing this and yes that means I’ve really forked the code. The node-oauth-libre project uses the GPL version 3, with the original code and patches to the original project licensed under the MIT license.
Remember if you’re reporting an issue, please include your Gruntfile and any messages displayed by Grunt or the grunt2gulp program such as an error or stack trace. This makes it much faster for me to track down the issue and to test it with grunt2gulp and Grunt.
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.
Here we learn to use Protractor with Selenium WebDriver providing the functionality to take screenshots.
Update: Andrew Batz has kindly put together an NPM-installable package with the code in this article. Click here to check it out or download it using npm install screenshot-protractor
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:
Here I’m going to talk about how to use mocks when writing unit tests for Django, the Python-based web framework. Using Django test mocks has really opened my eyes on how to write much better unit tests. Previously, and in some cases still do when using 3rd party services, I would use fake API servers to serve fake data for testing end to end. With the mock library, I can easily mock out server responses in Django tests. Continue reading “Django Unit Testing with Mocks”
All of the top-level definitions in the AngularJS API are included in the auto-complete dictionaries. The dictionary for angular-html-mode contains all the common directives.
However, to give a more detailed answer and one issue…
The first reason is true. Technical debt can be measured in onboarding time. If you don’t have an up-to-date set of documentation describing how to get up and running and your system requires lots of extra twiddling and fiddling around, then you have a lot of technical debt. When you do onboard a new developer, make sure they fix some of that and simplify the process further. By the time you get to onboard employee M + N you should have less onboarding time and less technical debt.
As the article points out, if Facebook with so many complex systems and many projects can allow for real useful code to be deployed within a day, your less complex system with 1/100th of the servers and complexity should take a few hours to be setup and allow you to deploy useful code.
With respect to the second reason I agree that you should know what you’re testing and why, elaborate test suites indicate that you’re testing the wrong thing or your tests are brittle. For example, I had to write unit tests that mocked out 3 dependencies and had methods called “add” and “remove”. Guess what I was testing? That’s right, whether the class would add or remove the object to an array/list/some other data structure. It didn’t require any special business logic or require elaborate rules and conditionals, it was a straight addition or removal. My test was essential the same as a unit test for a linked list or array data structure’s insert/push/append/delete methods. Those kinds of tests can be safely removed.
The third reason I’m iffy on. On the one hand, yes it makes sense to use AWS or Google App Engine or some other cloud service. On the other hand, those can be expensive and sometimes there are laws in your country that require keeping data within the country. That leaves three options: expensive local cloud server, private servers (VPS or co-located), private cloud. In Canada our web hosting services are always more expensive, same with our domain registration. Both private co-located servers and a private cloud require maintenance and/or lots of cash. Some Canadian companies aren’t limited and can use AWS or Google App Engine…but they end up not using it to the maximum ability because the company introduces some other limitations that defeat the purpose of using cloud-based hosting such as not designing the architecture to be scalable to take advantage of the cloud. You can see this in consulting and contracting firms where every single project requires a separate server as if the client you’re working for can’t envision their website growing exponentially…how depressing.
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.
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.
2017 Update: grunt2gulp is still being used but it seems now that people are moving from Grunt and Gulp to webpack (or Rollup.js). Gulp is still a very cool build tool to use. However, I recommend that people move away from Grunt as soon as possible on to more modern tools like Gulp and Webpack and Rollup.js.