Getting started with Jest

In the past, my automated testing for javascript was done in either QUnit if it was a browser app or Mocha if it was a node app. On a new project, I decided to kick the tires on Jest and thus far, I really like it. It did have a bit of a learning curve through to get it up and running, but now writing tests in it feels natural and is going well. Here are a couple of things I've learned thus far.

Jest defaults to an outdated version of jsdom

.jsdom added support for HTMLElement.dataset in a recent version. However, due to minimum node version support differences, Jest by default uses an older version of jsdom.  Switching to the latest version though turned out to be fairly easy. I installed jest-environment-jsdom-latest and changed my package.json to run jest with "testEnvironment": "jsdom-latest". Alternatively I could have used --env=jsdom-latest.

Steal Configs From elsewhere

It's really easy to run down the rabbit hole of learning everything about how to set up a tool before learning if you want to actually use it. To get started, I stole some of the config from an ejected create-react-app application and looked at the docs for using jest with webpack. That was all I needed.

Use .resolves() for your promises

Unwrapping a promise and using .resolves() allows me to easily unwrap promises and keep my expectation in a single chain.  It feels as much like magic to me as promises did the first time I used them.

Additional Resources 

Overall, I'm excited to continue playing with Jest. 

Falsehoods Programmers Believe about Versions

Inspired by the list of falsehoods programmers believe about names and falsehoods programmers believe about time, here are some Falsehoods programmers believe about Versions and some examples of the falsehoods.

  1. Versions are always numbers
  2. When versions are numbers, they will always be sequential (See PHP 6)
  3. Software never changes how they use versions (see Firefox)
  4. When Software uses X.Y.
    Z , X is always the major version number (see WordPress
  5. Versions always use periods to separate numbers 
  6. Version numbers never decrease
  7. Semver is the only versioning standard
  8. 1.0 is always the first public release
  9. 1.0 is always a stable release
  10. There will never be a time when the second or third number in an X.Y.Z. version exceeds one digit. 
  11. Major version number changes always mean backward compatibility changes.
  12. Minor version number changes never mean backward compatibility changes. 
  13. Version numbers are never adjusted due to superstition
  14. Version numbers are never based on mathematical jokes (See TeX)
  15. Internal version numbers are always the same as external version numbers
  16. No two releases will ever have the same version number
  17. Version numbers are always base 10. 

Akin’s Laws of Spacecraft Design Modified for Websites

I have long been a believer that as creators and creatives working on websites, we can learn a lot of other fields.  One that I am constantly looking at for inspiration is spacecraft and astrophysics. Akin's Laws of Spacecraft Design are a collection of axioms collected and maintained by David Akin, a professor at the University of Maryland.  Here they are, lightly edited for websites. 

1. Engineering is done with numbers. Analysis without numbers is only an opinion.

2. To design a website right takes an infinite amount of effort. This is why it's a good idea to design them to operate when some things are wrong.

3. Design is an iterative process. The necessary number of iterations is one more than the number you have currently done. This is true at any point in time.

4. Your best design efforts will inevitably wind up being useless in the final design. Learn to live with the disappointment.

5. (Miller's Law) Three points determine a curve.

6. (Mar's Law) Everything is linear if plotted log-log with a fat magic marker.

7. At the start of any design effort, the person who most wants to be team leader is least likely to be capable of it.

8. In adtech, the optimum is almost always in the middle somewhere. Distrust assertions that the optimum is at an extreme point.

9. Not having all the information you need is never a satisfactory excuse for not starting the analysis.

10. When in doubt, estimate. In an emergency, guess. But be sure to go back and clean up the mess when the real numbers come along.

11. Sometimes, the fastest way to get to the end is to throw everything out and start over.

12. There is never a single right solution. There are always multiple wrong ones, though.

13. Design is based on requirements. There's no justification for designing something one bit "better" than the requirements dictate.

14. (Edison's Law) "Better" is the enemy of "good".

15. (Shea's Law) The ability to improve a design occurs primarily at the interfaces. This is also the prime location for screwing it up.

16. The previous people who did a similar analysis did not have a direct pipeline to the wisdom of the ages. There is therefore no reason to believe their analysis over yours. There is especially no reason to present their analysis as yours.

17. The fact that an analysis appears in print has no relationship to the likelihood of its being correct.

18. Past experience is excellent for providing a reality check. Too much reality can doom an otherwise worthwhile design, though.

19. The odds are greatly against you being immensely smarter than everyone else in the field. If your analysis says your page speed is one nanosecond, you may have invented HTTP/3, but the chances are a lot better that you've screwed up.

20. A bad design with a good presentation is doomed eventually. A good design with a bad presentation is doomed immediately.

21. (Larrabee's Law) Half of everything you hear at meetups and conferences is crap. Education is figuring out which half is which.

22. When in doubt, document. (Documentation requirements will reach a maximum shortly after the termination of a program.)

23. The schedule you develop will seem like a complete work of fiction up until the time your customer fires you for not meeting it.

24. It's called a "Work Breakdown Structure" because the Work remaining will grow until you have a Breakdown, unless you enforce some Structure on it.

25. (Bowden's Law) Following a testing failure, it's always possible to refine the analysis to show that you really had negative margins all along.

26. (Montemerlo's Law) Don't do nuthin' dumb.

27. (Varsi's Law) Schedules only move in one direction.

28. (Ranger's Law) There ain't no such thing as a free launch.

29. (von Tiesenhausen's Law of Program Management) To get an accurate estimate of final program requirements, multiply the initial time estimates by pi, and slide the decimal point on the cost estimates one place to the right.

30. (von Tiesenhausen's Law of Engineering Design) If you want to have a maximum effect on the design of a new website, learn to draw. Engineers always wind up building the website to look like the initial artist's concept.

31. (Mo's Law of Evolutionary Development) You can't get to the moon by climbing successively taller trees.

32. (Atkin's Law of Demonstrations) When the website is working perfectly, the really important visitors don't show up.

33. (Patton's Law of Program Planning) A good plan violently executed now is better than a perfect plan next week.

34. (Roosevelt's Law of Task Planning) Do what you can, where you are, with what you have.

35. (de Saint-Exupery's Law of Design) A designer knows that he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.

36. Any run-of-the-mill engineer can build a website which is elegant. A good engineer builds systems to be efficient. A great engineer designs them to be effective.

37. (Henshaw's Law) One key to success in a mission is establishing clear lines of blame.

38. Capabilities drive requirements, regardless of what the systems engineering textbooks say.

39. Any feature launch which "just happens" to include a new design is, de facto, a redesign.

39. (alternate formulation) The three keys to keeping a new feature launch affordable and on schedule:
       1)  No new designs.
       2)  No new designs.
       3)  Whatever you do, don't redesign the website.

40. (McBryan's Law) You can't make it better until you make it work.

41. The Internet is a completely unforgiving environment. If you screw up the engineering, somebody loses money (and there's no partial credit because most of the analysis was right…)

Bash Functions I use for access logs

The command line is my IDE.  Vim is my editor and all the functions and programs in bash help me be a better developer.  As much time as I am writing code though, I also am often spending a lot of time looking through logs to see what is going on.  Over the last five to ten years I’ve collected a number of bash functions to help make working with access log files easier. Some are stolen from my old coworker Drew, others from various places online, and others I’ve cobbled together.

function fawk {
    first="awk '{print "
    eval $cmd

This simple function allows me to pull one whitespace broken element out. Imagine an access file filled with lines like: - - [13/Jan/2017:14:55:31 -0500] "GET /infidelity-husband-had-affair/ HTTP/1.1" 200 20685 "" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36" ",,,"

I can run cat access.log | fawk 7 to pull out the urls. I can further pipe that to sort | uniq -c | sort -nr | head to pull out the most popular urls. I also have a function for visualizing these results.

function histogram {
 if [ -z "$UNIT" ]; then

 first="sort|uniq -c|awk '{printf(\"\n%s \", \$0); for (i =0; i<\$1; i=i+"
 last=") {printf(\"#\")};}'; echo \"\""
 eval $cmd

For example, If I want to see all the response codes, of the last 500 responses I can do something like

tail -n 500 nginx/access.log | fawk 9 | histogram 10

 466 200 ###############################################
 8 301 #
 5 302 #
 1 304 #
 18 404 ##
 2 429 #

I often want to look at more than one access log at a time, but they are gzipped to save space after rotating. I have a function to cat or zcat all of them.

# cat or zcat all the access logs in a folder 
# Pass in folder to search in as the only param
# Likely want > into another file for further use
	find $1 -name "acc*" -not -name "*.gz" -exec cat '{}' \;
	find $1 -name "acc*" -name "*.gz" -exec zcat '{}' \;

When it comes to working across many servers, I still rely on dancers shell in concert with these functions.  The occasional access log spelunking is much easier with these tools.

Color Is Based on Surrounding Color

“The redness isn’t a property of the apple. It’s a property of the apple in combination with a particular lighting that’s on it and a particular observer looking at it.”

via These X’s Are The Same Shade, So What Does That Say About Color? : Shots – Health News : NPR.

Next to typography, color is the most important part of the visual design of your website. Yet, color is also very misunderstood. Color more than any other part of web design, does not live in a bubble. Color is about how things relate to each other. Saying that #990000 is an easy color to read can change if your background is black, white, or pink

Ensuring that colors contrast correctly means both ensuring that there is enough luminance contrast, but also so that there is enough simultaneous contrast. And if that isn’t enough, we also need to remember to take into account the psychological effect of different colors and the cultural meanings that our color can have.

These four factors combine to make color selection a non-trivial problem.  What makes color an even harder problem is that we are only at the type of the iceberg for color perception.  What else effects color display? Our screens calibration. The tools we use to change how color display based on the time of day. The cones in our eyes. The lighting in the room.

Color is far from a simple problem. All these factors combine to show why we can’t rush color decisions. They need to be thought out and considered from many angles. As Josef Albers wrote in the seminal Interaction of Color, “In order to use color effectively it is necessary to recognize that color deceives continually.”

Aggregate Multiple Log Files From Multiple Servers

The majority of the time I need to analyze logs across multiple servers, I use logstash.  Sometimes though I want to aggregate the actual files on the server and go through them myself with awk and grep.  For doing that, I use two tools.

  1. In my bash config, I have a function called access_concat that reads out regular and gzipped access logs.
        find $1 -name "acc*" -not -name "*.gz" -exec cat '{}' \;
        find $1 -name "acc*" -name "*.gz" -exec zcat '{}' \;

    I can pass a path that log files are stored in and it will search them to find the files I actually want.

  2. Dancer’s Shell (or DSH) makes it easy for me to run a command across multiple servers.

Combining these two, I can run:  dsh -M -c -g prd-wp 'access_concat /logs >> ~/oct22.logs' to concatenate all of the log files that exist on the server today. I then just need to scp down oct22.logs and I can easily run my analysis locally.

Note that to do this, you need to configure dsh so that the servers you want to access are in the prd-wp group (or better yet, the logical name for whatever you are working on).

Changes should happen in Code, not in UI

If you are deploying your WordPress site, it generally doesn’t make much sense to have to go in and setup changes when you push the newest version live. When you push to production, production should have all your changes.

One more benefit of this method is that you never need to be signed in with a user who can change settings, change plugins, or change themes. Being signed in as a user with as few capabilities as possible is a one part of limiting your vulnerability in case of attack

This is what I use to stop the majority of activities from happening in the UI.

tl;dr; Don’t Update Options in the admin, update them in the code.

Accessability Camp Bay Area 2014

I’m excited to announce that I’ll be a part of the inaugural Accessibility Camp Bay Area 2014.  I’ll be leading a session entitled “Web Accessibility on a Time Budget”.  We will be discussing how to prioritize and implement accessibility improvements in the real world where time is a common concern.

If you are in the Bay Area, you should absolutely come on down. Registration is Free!. The event is coming up on March 15. I hope to see you there!

Profiling WordPress made easy with Varying Vagrant Vagrants

Varying Vagrant Vagrants provides a setup of WordPress that is ripe for you to start profiling the PHP WordPress and your themes and plugins runs. The combination of xdebug, Webgrind, and a simple chrome extension will have you looking at the PHP performance. Let’s take a look at what you’ll need to get going.

To start, you’ll want to clone the Varying Vagrant Vagrants (VVV) git repository if you don’t have it already. VVV comes with xdebug ready for you to turn on and Webgrind for you to view the xdebug output.

Once you have VVV installed, the next step is to enable the profiler. You have a couple of options for this. You can turn it on for all page views (which slows page views down considerably), or you can just enable it in “trigger” mode, when you pass a get/post parameter or have a specific cookie set. I like this option since it enables me to easily switch between profiling and not profiling. I also make use of the Xdebug Helper chrome plugin to turn the cookie on and off. It’s also enabled by default in VVV, so you don’t need to do any work. You do need to turn xdebug on, but that is as easy as connecting to your vagrant box and running [bash]xdebug_on[/bash].

Now that we are setup, we can turn on profiling in our browser.

In the browser bar, you'll find a nice bug.  If you click that, you'll see a simple menu.
In the browser bar, you’ll find a nice bug. If you click that, you’ll see a simple menu.

By default, disabled is selected.  We want to select Profile.
By default, disabled is selected. We want to select Profile.

Now that profile is selected, we will see a clock.
Now that profile is selected, we will see a clock.

That’s all it takes to start generating the profiling information. You’ll need to do this for each site you want to be generating profiling data. You can also select disable at any time to turn off profiling. Once it’s on for one of our VVV sites, head over to webgrind at and you’ll be able to start seeing your data.

When you first load webgrind, it’s going to look kind of empty.
Empty webgrind

After you select a profile file (from the dropdown with “Auto (newest)” pre selected) and click “update”, you will see your profiling information.

Screen Shot 2013-12-23 at 12.40.01 PM

And that is all it takes to get started with profiling on Varying Vagrant Vagrants with xdebug and webgrind. Happy Profiling.