Douglas Crockford could sue the White House

Recently, the White House switched to using WordPress for whitehouse.gov. While doing so, they deployed the most recent version of WordPress. WordPress 4.9 includes a copy of CodeMirror for an improved experience when it comes to editing code. In order to provide linting of JavaScript ,CodeMirror uses JSHint.  And this is where things get interesting. 

JSHint is mostly licensed under the MIT license. I say mostly since it inherits some code from JSLint which uses a modified form of the MIT license. It requires that the software only is used for Good, not Evil.

"The Software shall be used for Good, not Evil."

So the White House is using software that can only be used for Good, not Evil. Which means that if the White House has used its website to do evil, it has violated Douglas Crockford's license. 

The next minor version of WordPress removes JSHint, but the inclusion of it will live on in internet archive history.¬†ÔĽŅ

Random Thoughts On…Product Engineering

For the past 5.5 years, I've been a part of the product engineering leadership at a couple of organizations. While I'm not sure if these ideas translate to client services, I know that they have all been valuable to me as I work long term building products and brands.

  • It's important to periodically reevaluate your tooling and process. Iterating on the process can be just as important as iterating¬†on features. As a team, you are able to take all that you have learned about how you work and try to improve upon it.¬† It's important to not do this too often though, otherwise, you are spending your time chasing something shiny rather than building something that solves problems.¬†
  • Users over business¬†requirements. Users over short-term¬†wins. Users over everything. If you aren't building for people, your motivations are wrong and you need to rethink what you are doing. Always think about users. If you are discussing working on anything and no one has asked how it benefits users, ask that question.¬†
  • Implementors need to have control over either the schedule or the scope of a project. Giving up both leads to burn out and/or low quality work. Implementors mean everyone actively¬†contributing, and not just the engineers.¬†
  • Design is more important than you think. Design is not done at a specific point. Designers need to be involved in everything. Yes, even the most underhood back-end project. Design thinking is undervalued. I've yet to see it be overvalued.
  • Share your work and ideas internally early and often. Even when they are half-baked or you don't think they are very good.¬†
  • It's important to understand that what is a high priority for you, isn't always a high priority for the team. That said, every member of the team should have at least one personal priority accomplished on a regular basis.
  • At least once a quarter, you should do a sprint focused on developer experience, refactoring, and bug features. Keeping the code easy to work with shouldn't be forgotten.
  • Do things that don't scale, but make them scale if you keep doing them.
  • There are a lot of things you can optimize for and deciding what you want to optimize for is a challenge. Sometimes you need to optimize for Time To Launch, others you want to optimize to make it easier to iterate on the UI. Figure out what's important on a project by project basis.
  • Don't forget any of Akin's Laws of Spacecraft Design, especially¬†number 1.
  • At the end of the day the rules for success are 1) keep the site up 2) faster is better than slower 3) experiment with everything else

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 "
    last="}'"
    cmd="${first}\$${1}${last}"
    eval $cmd
}

This simple function allows me to pull one whitespace broken element out. Imagine an access file filled with lines like:

172.16.194.2 - - [13/Jan/2017:14:55:31 -0500] "GET /infidelity-husband-had-affair/ HTTP/1.1" 200 20685 "https://www.google.com/" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36" "1.1.1.1, 2.2.2.2, 127.0.0.1, 127.0.0.1"

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 {
 UNIT=$1
 if [ -z "$UNIT" ]; then
 UNIT="1";
 fi

 first="sort|uniq -c|awk '{printf(\"\n%s \", \$0); for (i =0; i<\$1; i=i+"
 last=") {printf(\"#\")};}'; echo \"\""
 cmd="${first}${UNIT}${last}"
 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
access_concat(){
	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.
    access_concat(){
        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.