Copy
Let's be good internet citizens!
View this email in your browser

Breaking other servers with Node.js »

It's easy to get excited about Node.js and its async programing style - kick off 10 things at once, no problem! But downstream services might have a problem, especially if you have lots of users all kicking off 10 things at once. Let's write Node.js code in a way that respects the limitations of its dependencies - by breaking them first! Read More »


Links of interest...

https://www.jwz.org/blog/2016/10/they-live-and-the-secret-history-of-the-mozilla-logo/ - An intriguing history of the Mozilla logo, involving They Live, Andre the Giant, and graffiti. And of course, open source before open source was a thing! Bonus: A monitor that makes you feel like you're in They Live, and the physics that makes it work.

http://qz.com/625870/after-years-of-intensive-analysis-google-discovers-the-key-to-good-teamwork-is-being-nice/ - According to Google's Project Aristotle, "psychological safety" is what makes for a great team. An unexpected conclusion in an industry focused on rock stars! I first heard about this concept at OSFeels in July, during Shawn Rider's excellent talk: Work is Not a Dare.

https://codeascraft.com/2016/10/19/being-an-effective-ally-to-women-and-non-binary-people/ - A fantastic article with specific tips on how to start making the tech space more human, more welcoming for people of all types. A comprehensive bibliography too - if you need more information, or feel like you know the basics already. And, some Seattle-specific discussion in the same vein.


Thoughts...

In the last week I've been thinking a lot about the definition for a Unit Test. It's surprisingly hard to nail it down! We know it has to run fast, and it should test one 'unit.' But what's a unit? Even at last week's group discussion at the Seattle Software Craftsmanship Meetup, nobody had a crisp, universally satisfying definition.

This is my definition for a Unit Test:
  1. It runs very fast, a couple milliseconds at most.
  2. During the test, nothing is exercised outside of the project itself - not other services (like databases), not other computers, not other processes.
  3. It tests one 'small' thing - usually one function or class. Likely not beyond one file. Third-party dependencies can be included here, but ensure that they don't violate item #2.
  4. Changes outside that one target of the test should not cause failures.
You might be thinking "but most of my code couldn't even be a potential target of a Unit Test, then!"

To that I say: It might be time to refactor. Most of your tests might actually be Integration Tests, and should be runnable separately since they will take longer. But do we have a good definition for an Integration Test? :0)


Until next week!


Scott Nonnenberg
blog.scottnonnenberg.com
scottnonnenberg.com
Unsubscribe or update your preferences.

Copyright © 2016 Gamma Corvi, Inc., All rights reserved.

Email Marketing Powered by Mailchimp