Categories
Code Programming WordPress

__DIR__ vs dirname( __FILE__ )

Calling a constant should always be faster than a function call, right? PHP contains two different ways to get the directory that a file is currently in. __DIR__ is a magic constant added to PHP in 5.3. The official PHP documentation specifically states: “This is equivalent to dirname(__FILE__).” Equivalent in return doesn’t necessarily mean equivalent in performance though, so I decided to test the performance of both accross a couple of variables.

Testing Methodology

When running lots of tests, I’ve found that travis-ci can be a big helper. You can define the matrix of the tests you want to run as your testing matrix and then use the results. So I setup a repo for my tests. The repo contains four main pieces:

  1. A file generator which creates the code I’ll actually run the performance test on.
  2. A test running script which runs the actual tests.
  3. The travis.yml file to define my tests matrix
  4. Files used for the actual test. This is not linked, there are 400,000 files. The generator shows them off.

My test calls the function I am looking for 100,000 each. One run has all the files in 1 directory, and the other has one file per directory. I wanted to rule out the possibility that a single directory could affect this call.

I ran this test on six version of PHP: 5.6.40, 7.0.33, 7.1.27, 7.2.15, 7.3.9 and 7.4-dev. Each test did 650 runs and I looked at the user time for each of those runs. This means that I called both __dir__ and dirname( __file__ ) 130,000,000 times each. I then took the times for each of these runs and looked at that maximum (slowest) run for each and the 95% time ( the average between the 618th and 619th slowest) to rule out any extreme cases. Overall, the results between maximum and 95% are similar.

User is the amount of CPU time spent in user-mode code (outside the kernel) within the process. This is only actual CPU time used in executing the process. Other processes and time the process spends blocked do not count towards this figure.

Stack Overflow

__DIR__ vs dirname( __FILE__) Test Results

95% performance

Script5.67.07.17.27.37.4
dir ( 1 folder)1.42.762.082.512.271.3615
dir ( many folders)1.382.292.552.36152.651.57
dirname( 1 folder)1.58152.272.74153.242.411.5215
dirname( many folders)1.682.292.08153.292.68151.87

Overall, the results show that __dir__ is generally faster, but it’s rarely much faster. Consider that in the slowest run ( using PHP 7.2 and calling dirname( __FILE__ ) on multiple folders), each call took 0.0000329 seconds. The fastest run was 2 hundred-thousandths of a second faster. This is such a micro optimization that except under extreme scale, it’s unlikely you will ever notice a difference. That said, under most versions of PHP, __DIR__ is faster.

So: __dir__ or dirname?

At the end of the day, the performance of __DIR__ is ever so slightly better, but more importantly I think it’s clearer and easier to read. So I’m on team __dir__, but the performance is only a bonus.

If you have a different thought, or think that my testing methodology could be improved, please let me know in the comments below.

Categories
Art Programming WordPress

Art and Commit Messages: Volume 2

Last year I published volume 1 of Art And Commit messages and sold nearly 50 copies! For my first zine, I was ecstatic that so many people were willing to spend $3 on something so unknown. I have already started thinking about Volume 2 and think that it will be a great thing to publish at WordCamp US. I’m also thinking it might make sense to include some different things this time.

Art by more Artists

Volume 1 featured my art, for Volume 2 I would like to feature the art by more artists. I am also thinking of budgeting a small amount so that artists are compensated, but as Volume 1 didn’t make any money I think this is going to be a low amount. Maybe $50 for each piece.

Are you interested in having your artwork featured in Art and Commit Messages? Let me know:

Essays by More Writers

Along the same lines, I want to feature a couple of essays about commit messages from a variety of people. What kind of essays would you like to see in volume 2?

Finally, I want to figure out some sort of game to include. Maybe I loved reading Highlights for Children too much as a kid, but I think a game would be fun.

Art and Commit Messages: Strange Bedfellows

Art and Commit Messages might feel like an odd combination but the best of both are snapshots that convey an intent. Art transposes the emotion of the creator to an audience. It can transport you into the brain of the artist. The best commit messages similarly transport you into the brain of the creator. They share the coders intent.

That’s the message from the cover of volume 1. I absolutely recognize the odd combination, but they are two things that I care about and I hope that by combining these two strange bedfellows I can encourage people to write better commit messages.

Overall, my goal remains to encourage high quality commit messages through education, entertainment, and an understanding of history. I’m not looking to make money, if I was I wouldn’t be making a zine.

Do you have other ideas for making Art and Commit Messages better? Leave a comment or get it touch and let me know!

Categories
Art Four Short Things Programming Uncategorized

Four Short Things – 16 February 2019

Inspired by O’reilly’s Four Short Links, here are some of the things I’ve seen, read, or watched recently.

Git for Ages 4 and Above

My friend Adam recommended this talk as a good deep dive into git. One thing I often preach is the importance of understanding the tools you use on a regular basis. It doesn’t matter what editor you use (but really, it should be vim), what matters is knowing how to use your editor. The same can be said for git. Git is much more powerful than git commit, git push, and git pull. The piece I used yesterday? git checkout master -- filename.jsto revert a single file in a branch that didn’t actually need changes.

Tom Brown at Laugh Fest

Do you live in or around Grand Rapids? If so I highly suggest checking out The Tom Brown at Laugh Fest in March. You will laugh your socks off.

Public APIs

This collection of mostly JSON REST APIs has everything from APIs around art, music, and photography to weather, news, and NFL arrests. It’s a great first stop if you are looking for a data API.

Two Elephants

I finished my first new canvas of 2019.

Four Short Things is a series where I post a small collection of links to art, news, articles, videos and other things that are me. Follow my RSS feed to see Four Short Things whenver it comes out.

Categories
Art Design Four Short Things Programming

Four Short Things – 9 February 2019

Inspired by O’reilly’s Four Short Links, here are some of the things I’ve seen, read, or watched recently.

The Value of Good Design

MoMA’s spring exhibition includes a show featuring everyday objects, the types that it’s feasible to find in our homes. Brooms, Rakes, Chairs, A Slinky. With an emphasis on work that appeared in shows from the 1930’s to 1950’s, there is plenty of Eames, Saarinen, and Bruan to make any home goods nerd geek out. In addition to the main section of the show, there is a small lab where you can couch and sit on some of the items on display. It’s open until June 15.

Terraform

Describing itself as “Write, Plan, and Create Infrastructure as Code”, terraform allows for almost every part of your infrastructure to happen as code. You can thus keep your DNS in GitHub. You can keep your GitHub config in GitHub too.

What’s new in PHP7.4?

Odds are, you aren’t running PHP7.3 yet, but that doesn’t mean work hasn’t started on PHP7.3. Heck, 8.0 is already being planned. It’s still early, but coalesce assignment is my prediction for what is going to cause the most useless arguments and also be the biggest win.

Inclusive Design: Who’s Opportunity is it?

My friend David uses his journey to help explain how inclusive design is a win for everyone. He looks at Inclusive design as an opportunity for business, content, quality, performance, and people. Definitely was one of the best things I read this week.

Four Short Things is a series where I post a small collection of links to art, news, articles, videos and other things that are me. Follow my RSS feed to see Four Short Things whenver it comes out.

Categories
Art Design Four Short Things Programming

Four Short Things – 2 February 2019

Inspired by O’reilly’s Four Short Links, here are some of the things I’ve seen, read, or watched recently.

Design Patterns for Managing Up

The first time I was introduced to the phrase “Managing Up” I hated it. Why should I be responsible for my boss? They are supposed to be responsible for me. As I’ve grown I have recognized that as with all relationships, the manager-managee relation requires all parties to invest in its success. This article covers four challenges and offers patterns of behavior to help build and improve the relationship. These four situations are:

  1. Someone asks you something you don’t know
  2. There is a problem that is your fault or responsibility
  3. There is a decision that you don’t agree with
  4. Your manager gives you negative feedback

Metropolis II

LACMA is the largest art museum in the western United . On my first visit, Chris Burden’s kinetic sculpture stood out to me. I like art that reminds me of the building and imagination you do when you are young. Metropolis II is a massive sculpture that features cars and trains traveling around a city.

Picasso’s Drawings of Bulls Inspired Apple’s Famously Simple Designs

“Pasadena, Norton Simon Museum, Picasso P. The Bull, 1946” flickr photo by Vahe Martirosyan https://flickr.com/photos/vahemart/31475770070 shared under a Creative Commons (BY-SA) license

Picasso’s lithographic drawings of The Bull start as a full picture of a bull and over the course of the drawings, become more abstract and minimized to only a few lines. But it is still clearly a bull. Apple incorporated this into its design education. The continued minimization and removal of elements is evident. A phone is still a phone without a headphone jack, and a bull is still a bull when it is made with simple lines.

How We Made The Force Report Database

This “how we built this” article explores all the work that went into the Force Report Database from NJ Advanced Media. Awesome to see data reporters sharing not just the outcome (in this case a tool to help the residents of New Jersey understand police use of force) but all the steps and missteps it took to get there. The lessons learned at the bottom could also make it easy for other places to replicate this reporting.

Four Short Things is a series where I post a small collection of links to art, news, articles, videos and other things that are me. Follow my RSS feed to see Four Short Things whenver it comes out.

Categories
Art Four Short Things Programming

Four Short Things – 18 January 2019

Inspired by O’reilly’s Four Short Links, here are some of the things I’ve seen, read, or watched recently.

100+ Lessons Learned for Project Managers

I am a firm believer that software and web development can learn a lot from other disciplines. Much as Akin’s Laws of. Spacecraft Design can be easily modified for the web, I think these lessons from Jerry Madden, the former Associate Director of Flight Projects at NASA Goddard Space Flight Center, can also be valuable. One that stood out to me, since it seems so incredible accurate, is lesson #14.

The first sign of trouble comes from the schedule or the cost curve. Engineers are the last to know they are in trouble. Engineers are born optimists.

Lesson #14

Untitled by Mark Rothko

Mark Rothko is often thought of for his large “multiform” colorful paintings, but The Met’s Epic Abstraction show also includes a few of his watercolors. It’s a nice reminder to not be siloed into what we are most known for. Overall, this show lives up to its name and features many epic pieces of abstract art. It has no end date currently scheduled, but I have a feeling that it will depend on the construction of a new modern wing.

The Marvelous Mrs. Maisel

When this first came out, I watched the first two episodes but never really fell into it. Then over the last my entire family seems to have all watched this separately. It’s funny, sad, and displays the same level of intellectual dialague that Amy Sherman-Palladino displayed with Gilmore Girls.

Anatomy of a Dress Shoe

Over the last four years, I’ve gone from regularly using one pair of shoes to having a number in regular rotation. I’ve mostly bought them second hand, but I’ve also taken the time to learn about Goodyear Welts, and even got one pair resoled. Shoes are one of the most important articles of clothing that we ware and this overview will help you the parts of the shoe.

Categories
Programming WordPress

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

Categories
Design Programming tao

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
Categories
Programming

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. 

Categories
Programming

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. X is always the major version number (see WordPress
  5. Versions always use periods to separate numbers 
  6. Version numbers never decrease
  7. 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.