Wednesday, June 18, 2014

Pull Requests instead of Emailing Code



If you modify code from an open source repository, such as GitHub or BitBucket, here are the reasons why you should submit a pull request to get your code back into the main repo.



  • To avoid paying the stupid tax.
    • In short, your feature or fix will be available in future versions that you might want to use. If your code doesn't get into the master branch then it makes it difficult or impossible to keep up with future versions.
  • Make open source better.
    • If you've fixed a bug or added a feature then it's highly likely that others will need that.
  • Improve your resume.
    • More and more recruiting managers are looking at what you've done when they're hiring you. Having contributed to an open source project is a great way to show that you've done real work that people are using.
  • Get Credit
    • You've done the work. Now get your name on that repo and take credit for some of the work that you've done.
  • Use the Tools
    • Do you use Git? Have you ever submitted a pull request? These are questions you might be asked at an interview. Try it and practice it so you can demonstrate this skill. Even if I was hiring a junior right out of school I'd expect them to have at least done this.
  • Understand someone else's code-base
    •  Making a contribution to someone else's code-base forces you to read their code and understand their style and way of architecting a project. This is an invaluable skill as 80% of the work you do is reading over code. Even if you wrote it you'll have forgotten it to the extent that it becomes foreign in a few months time.
 This list came from a conversation that I was having with the owner of the ABot project on GitHub. ABot is a web crawler (spider) built for speed and flexibility.


He was telling me how other developers will add features to ABot and then email the code to him. If he decides to accept the code and integrate it into the project then it's all getting committed by him under his name. He was telling me how he doesn't want the credit for this work. By not submitting your code through a pull request on GitHub it makes it very difficult to give the credit to the person who did the work.

Tuesday, June 17, 2014

HTTP Status Check



I recently created a Node.js utility that will cycle through a list of URLs and check their HTTP statuses:

Npm: http-status-check

GitHub: http-status-check

This utility came out of a need to keep daily tabs on a number of URLs and the statuses that they were returning.

I plan on expanding it with other input and output adapters. Obvious input adapters would be databases. What else can you think of? Obvious output adapters would be email and any other type of messaging system.

Pull requests are welcome.

Update 4/July/2014

Added an excludedHeaders option. This is a list of headers that you want the check to fail on if they are present in the response from the server.

At first blush this may seem like a strange check to make. The common use case is the X-Powered-By header. This header allows the server to advertise the technology that is powering it. As a security concern, when possible, I'll remove this from sites that I publish. I feel that telling malicious attack bots what you're running on will help them exploit any vulnerabilities your stack might have.

Update 5/July/2014

Added an expectedText option. This is text that we expect to be present in the body of the response from the server. By default it is case insensitive but you can change that by supplying an object instead of a string.







Saturday, June 7, 2014

Using WebSockets when your Reverse Proxy doesn't allow it

As developers we don't always get to choose where our software runs. We often face economic or other restrictions based on infrastructure that already exists.

I recently moved a Node.js application from Linux server to a Windows Server 2008R2. Crazy right? It's working surprisingly well in the Windows environment. IIS 7.5 already owned port 80 so I had to setup a site on IIS, bind the domain to that site and use it as a reverse proxy to the Node app which was running on an arbitrary port.

In this case it happened to be IIS in any other case it might be Ngnix, Apache or any other server or reverse proxy that is between your Node.js application and the web. The problem that I faced is that this version of IIS does not support WebSockets so it looked like I couldn't use that and had to allow socket.io to fall back to long polling for this application.

There is, however, a solution, and it's rather simple.

Your site's facade, let's call it mdomain.com, is running on port 80 on IIS which is configured to run as a reverse proxy passing all traffic through to port (say) 4444 where your Node application is running.

When a client (a browser) connects to your site you provide it with the usual payload of HTML, CSS and JavaScript and in that you also provide it with the port number or sufficient information for the WebSocket part of the client to make a direct connection to your Node.js server and bypass the reverse proxy completely.

Using this little trick our site can remain on the default port going through the reverse proxy and all our WebSocket traffic can run over the application specific port.

Tuesday, June 3, 2014

JavaScript Dependency Injection.

Using JavaScript Dependency Injection for Spies, stubs and mocks in unit testing.

I was in the process of picking a Dependency Injector for use in a project in JavaScript. My default to narrow down the top three is to use Google as my initial search and then GitHub's star count as the top-three filter and then compare the features that I need.

After looking a SinonJS, sandboxed-module, rewire, and proxyquire I decided to be slightly more analytical and objective about how I compared them. I decided to include the Watch and Fork count in addition to the Star count. I created a spreadsheet that compared them:
 

watch star fork Avg
rewire 20 425 16 0.48
sinon 52 1471 233 2.08
sandboxed 10 190 24 0.29
proxyquire 2 195 12 0.15

84 2281 285 3

I averaged the modules giving each of the attributes a one third weighting. Given that starring is 27 times more common than watching you might question this weighting. I justify it because starring is a less costly action (no update emails) and more likely to do than watching.

Seeing this as a pie chart makes this information easier to absorb. The clear winner amongst these four modules is SinonJS with almost three-quarters of the attributes.