Death by a Thousand Cuts

Death by a Thousand Cuts

I was recently playing around with mail merge on Google Docs at home, because Tuesday is my skip day for work-life balance (ok, really, I don’t have a good excuse).

I used MailChimp’s mail merge, which I’ve previously used quite successfully, only to find that it wouldn’t load. The developer console gave me some random script errors, which I attributed to RequestPolicy, my Firefox cross-domain request blocker. Of course, RequestPolicy said it *wasn’t* blocking *any* requests, but I turned it off anyway and tried again. When that didn’t work, I turned off AdBlock and tried again. No more extensions that blocked requests at all. No luck.

Of course, a clean build of Chromium in incognito worked just fine.

Ad blockers, privacy extensions, and their ilk have been a sort of “compromise position” when it comes to privacy. Those of us who actually care turn them on, knowing that the vast majority of people who don’t care act as the lifeblood (or Soylent, if you wish to be provocative) of internet commerce. It allowed us to accept pretty much universal tracking of who we are and what we do, since we assumed *we* didn’t need to follow those rules.

What’s happened is not an immediate, intentional disabling of that technology, but a gradual atrophy. I recently read that AdBlock on Firefox ate up RAM, so I ended up turning it off on my phone, and getting much better performance as a result. Every single site I go to seems to want something from cloudfront.com. How do I know that Amazon can’t know what I’m doing across every single domain? Realistically? I can’t.

Remember the fable of the frogs in the pots? One frog was boiled quickly, and jumped clear to safety. The other frog was boiled slowly and croaked.

We’re the frog that stayed in the pot and built an insulating boat. And now that boat is leaking.

I’ve religiously kept my account on Facebook separate from the real world, and kept separate accounts for everything that matters, but the constant juggling I’ve used to square the circle is probably not going to work forever. And while it’s not exactly connected, I suspect that any solution that divided people into a class of digital “knows” and “know-nots” could not last forever.

Those of us who care about privacy may eventually be forced to make a choice:

a) accept the current norms in privacy

b) deal in a less technical and more political manner (that means organizing, talking to each other) with those who run the digital world

c) find some new, more financially and technically sustainable way of maintaining control over our information and who knows it.

The Best Way to Keep a Toilet Clean

It’s Friday night. Let’s talk about toilets.

“The supreme art of war is to subdue the enemy without fighting.”
― Sun Tzu, The Art of War

The first hits I get for “The Best Way to Keep a Toilet Clean” aren’t about keeping a toilet clean, they’re about fixing it when it gets dirty. All about scrubbing technique, waiting for 30 minutes, creepy guys with pumice stones blah blah blah.

If you want to spend an hour of your life chasing toilet scum invaders back across your own Maginot line, then those posts are there for you. If you’d rather your toilet spent some time cleaning itself, read on.

Continue reading

End-to-End JavaScript Testing is Easy (the minimal way to do it)

It’s not actually that hard to automate browser testing! Let’s dive in. We won’t use any obscure or (relatively speaking) bleeding-edge technologies here; just the basics. We’re trying to strip out all the fancy names and get to a nice, minimal, testing setup.

The players

The first question to answer is this: what do we use to test with? You’ve probably heard of Capybara, QUnit, Jasmine, Mocha, Karma, Protractor, WebDriver, Selenium, etc., but which does what? Let’s sort it out.

Regular old JS, do-it-all testing.

Candidates: QUnit, Jasmine, Mocha

What they’re good for: Testing JavaScript

If you want to assert that 2+2 is 4 using your fancy new addition framework, these are the usual suspects. QUnit is very old but tried-and-true (jQuery uses it); Jasmine is newer; and Mocha is the newest. From what I’ve heard Mocha has better asynchronous support than Jasmine, so when in doubt, I just use that.

Make the browser work automatically

Candidates: Selenium

What they’re good for: Automating web browsing

Yes, Virginia, there is only one actual browser automator, and that’s Selenium! I spent years (well, hours) googling this before I realized what was going on.

All the smoke and mirrors about PhantomJS and Protractor and Karma aside, any testing framework that is doing automatic testing of an actual web page in a real browser uses Selenium. (PhantomJS is a pseudo-browser, Protractor uses Selenium, and Karma, I think, is just for testing raw, not-the-same-as-your-real-web-page JavaScript).

Talking to Selenium from JavaScript

Candidates: WebdriverJS, WebDriverJS (I wish I was joking), Nightwatch.js

What they’re good for: Talking to Selenium from your JavaScript node app.

You can use Selenium from almost anything – a Java/C# program, C++ I think? – but here we’re going to stick with JavaScript. In order to access the browser and do things like browser.get(“http://google.com”) from 35 different browsers all at once, we need a library, and that’s where WebDriverJS comes in. Just use WebDriverJS with the capitalized D, it’s the official one.

Cooking it up

Now that we’ve got that sorted out, our path is pretty simple, and we’ll need all three. What we’ll do is:

  1. Start Selenium in the background; it can automatically spin up Firefox, IE, and Chrome windows on its own like magic.
  2. Install WebDriverJS so we can talk to Selenium (https://code.google.com/p/selenium/wiki/WebDriverJs)
  3. Create tests in Mocha that use the WebDriverJS library to automate the browser.

Here we get the best of every world. Selenium, a well tested browser automator, handles making Firefox do spooky automatic clicking. We use the official WebDriverJS to talk to Selenium, and we put our tests, just like any other test, in a standard Mocha example – no need to have some separate, slightly-different-syntax not-invented-here framework just to do our E2E testing.

While I could write a tutorial that would rapidly go out of date, I think it would be better to just link to the latest up to date tutorials and make some notes.

The recipe

Prerequisites: node, npm, java

  1. Start by installing Mocha and get the basic test running.
  2. Download the Selenium server.
  3. Install WebDriverJs (selenium-webdriver) so you can use Selenium in Node.
  4. Download and include the proper Selenium drivers for Firefox/IE/Chrome
  5. Run Selenium with Java, making sure to specify the drivers you downloaded in the previous step.
  6. Replace the basic test you wrote in Mocha with this one: https://code.google.com/p/selenium/wiki/WebDriverJs#Writing_Tests
  7. That’s it!

Some caveats I ran into:

  • First, while mocha understands being installed locally and globally (npm install vs npm install -g), selenium-webdriver only understands being installed locally.
  • Downloading the drivers for FF/IE/Chrome is a bit of a pain since the web links redirect to different places.

Other than that though, just use the standard instructions for Mocha/Selenium/WebDriverJs. No need to remember anything else from a random blog post (AKA, this one).

Conclusion

The only tricky part about autotesting your web browser is deciding what to use. Using Mocha + Selenium with WebDriverJS is a nice, commonly supported combination that’s minimal.

Adding things like Capybara, Nightwatch, and Protractor is nice, but frankly, you’ve got to install Selenium anyway, and you’re probably already using Mocha or something similar for your browser testing. All those new, fancy-name frameworks are doing is adding a bunch of syntactic sugar and extra dependencies. Alternatively, there are plenty of tutorials for setting this up, that require all sorts of caveats and weird tricks to remember. Who needs that?

Programming is a game with an inventory

An excellent game about managing inventory. And the occasional dungeon.

An excellent game about managing inventory. And the occasional dungeon. Via

In some video games, the player has an inventory – a set of virtual items that he/she possesses in the game world. Just like in the real world, virtual space is often limited, and we’re forced to discard and sort.

Some of us are naturally inclined to clean, to discard things until we feel organized again. That natural instinct defends us from asphyxiation under mountains of stuff.

Programmers have an inventory as well. Though that inventory is purely mental, it is no less of a burden to organize. While coding, I’ve squirreled away these nuts in the knotholes of my brain:

Thinking about my programming work as juggling mental inventory leads to several useful ideas:

 

 

Toolbox (wikipedia)

1) Keep a mental toolkit next to your brain (aka your L2 cache)

If you were a carpenter, you wouldn’t try to hold your hammer, nails, pliers, a saw, and a wrench in your hands all the time – you’d drop something. Similarly, if I tried to remember all the information I needed to do my job, just in my head, I would (a) drop things and (b) get exhausted quickly.

*(As totally obvious as the above sounds, I regularly try to remember far more than my brain can hold, and pay these totally obvious consequences on a regular basis.)

Just like a carpenter needs a toolbox, a programmer needs a info toolkit, pieces of paper or virtual sticky notes, to hold the information we regularly need to do our work and retrieve it quickly. I print out cheat sheets; Gas uses Evernote.

 

 

2666964344_32fe60a000_z

2) Aim to build the IKEA of APIs (or languages)

If you’re building an API for a programmer, they will have to carry extra mental tools to use what you’re building. If you can build the IKEA of APIs, something accessible using simple, readily available tools they already have, your users will be delighted and thankful.

It’s OK to require more tools, especially if your language is going to be 90% of where a user spends their time (SQL comes to mind, though it’s not a perfect example). However, think about how your programmer will hold the tools they need to use your API!

 

 

Windows-ui--choices

3) Respect those who use your apps

The same goes for app users. Most popular apps/applications do not actually require that much inventory accumulation, but there are quite a few that do. It’s not wrong to require the user to juggle a lot of tools (especially if you want to challenge your users, like a game), but be aware of what you demand!

 

Credits:

Inspired by reading 1/3rd of this essay: I Am Overencumbered

Image credit, 2