Categories
Design Programming tao WordPress

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…)

Categories
Code Programming

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.

Categories
Design Programming Uncategorized WordPress

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.”

Categories
Programming Uncategorized

Testing for Web Accessibility in 60 Seconds

You want to make your website more accessible, but you don’t know where to start. If you have 60 seconds, I can help.

via David A. Kennedy.

Some great tips on how to do super simple, yet super valuable accessibility testing.

Categories
Code Programming Uncategorized

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).

Categories
Programming Uncategorized WordPress

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.

Categories
About Aaron Programming Uncategorized

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!

Categories
Programming Uncategorized WordPress

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.

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

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 http://vvv.dev/webgrind/ and you’ll be able to start seeing your data.

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

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

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

Categories
About Aaron Programming Uncategorized

A Crazy Idea…

I just submitted a proposal to a WordCamp for a talk I’m calling “Aaron Struck by Lightning”. It is an experiment in challenging myself and in giving real time choice to the audience as to what they learn next. Here is the basic summary I submitted:

6 talks, all five minutes long. The first one is chosen by me ahead of time, but the next five are picked by the audience voting from a list. The topic options will include build tools, design philosophy, Accessibility, WordPress APIs, Open Source, International Politics, and more!

Will it get accepted? Time will tell. Will it work? I have no idea.

Categories
About Aaron Programming Uncategorized

Aaron’s Rules for Better Meetings

Meetings are Toxic.

One of the most shared links among tech teams. In general, developers realize that meetings are not the place to get work done. In order to make meeting suck less, I’ve come up with a few simple rules. I generally define a meeting as something on my schedule for me and at least two others. I don’t include one on ones or impromptu discussions in my meeting rules.

  1. Meetings have agendas. There should be a specific list of things that need to be talked about and that should be sent out ahead of time. People should have the opportunity to gather information before the meeting so they can be productive participants.
  2. Does this meeting even need to take place. This questions isn’t asked often enough. Is the meeting only serving one person and not bettering the team/organization? Maybe it needs to be retooled. Maybe you should be sending out email updates or posting more in a chat room
  3. Meeting start on time, no matter if everyone is there. I’ve started meetings where I am the only one in attendance. When people came in late, they jump in where the room is at, no matter if the item they most wanted to discuss has passed.
  4. Anyone can all the Tangent Police. Sometimes you get off topic. When that happens, someone in the room needs to recognize it and just say something. It’s better for everyone.
  5. GRIPI Check. If conflict is arising, I try to work through and find the root of the conflict. Is there a goal that everyone agrees upon already? Does everyone understand there role? Does everyone have all the information they need? Is there other information that could help solve the problem? Are we doing the right process? Is there a way we could be going for an answer that would be better than what we are doing? Is the problem actually Interpersonal (hint: it probably isn’t)?

Those are my go to rules for meetings. How do you run effective meetings?

EDIT: I’ve since added a sixth rule