walls.corpus

By Nathan L. Walls

  • Sunset, Jan. 2, 2021/Williams Township
  • On Bougher Hill/Williams Township
  • Sunrise, Dec. 19, 2020/Williams Township
  • Sunset, Dec. 27, 2020

Articles tagged “development”

By any other name: What to call similar things

On a recent code review, one of my teammates was adding a new branch of code behind a feature flag to adjust how our site search weights potential results.

The existing code had a constant I’ll call RESPONSE_WEIGHT. The new branch added RESPONSE_WEIGHT_NEW. Both would co-exist while the feature flag was present.

Given this is a temporary feature flag that should be retired once the code is determined to be steady-state in production, going back through the code and taking out the feature flag and the old branch will leave RESPONSE_WEIGHT_NEW.

In a few weeks or months, I or another teammate are going to look at RESPONSE_WEIGHT_NEW and wonder what new means. If, we decide to further adjust search result weighting, RESPONSE_WEIGHT_NEW is an outright misleading name.

Appending a name with _new or _old is tempting because it doesn’t require a lot of creativity. It isn’t a great idea, because the new or oldness of it quickly loses context.

If there’s a need to separate functionality or naming by a feature flag, use a suffix like: _2020_Q1, which ties the name to a point in time.

This will also likely leave an earlier name around, and, context dependent, those can also change with a suffix _PRE_2020_Q1, if there’s not already a data quantifier on something.

Then, if and when it comes time to remove the feature flag, the code isn’t populated with now contextless _new entries. Similarly, the code won’t be looking at _new2 or _new_new.

In this case, the pull request feedback resulted in RESPONSE_WEIGHT_2020_Q1, which is more likely to remain an accurate name as long as it lives on in the codebase.

Ruby Standard Gems

At work, I’m upgrading my team’s Rails application from Ruby 2.5 to 2.6. In the course of tracking down test failures between the two versions, I’ve found the following site helpful: stdgems.org/.

In short, it describes the gems that are shipped with Ruby and the versions that shipped with each version, which is helpful in tracking down behavior changes that might not be described by the language changes themselves.

In a case specifically relevant to how the application handles invalidly formatted CSV files, I learned that for the CSV gem, Ruby 2.5 shipped with version 1.0 while version 3.0, started shipping with the 2.6 series. That detail was helpful in determining that the way we structured the test for a failing case was no longer going to work, and I needed to restructure the test. Yay!

🔗 Escaping the SPA rabbit hole with modern Rails

Jorge Manrubia writes:

I remember thinking that Rails was focusing on the wrong target when DHH announced Turbolinks in 2012. My conviction back then was that offering an instant response time to user interactions was key to excellent UX. Because of network latency, such interactivity is only possible if you minimize your dependency on it and, instead, manage a lot of state on the client.

I thought this was necessary for the kinds of apps I was working on. And with that in mind, I tried many approaches and frameworks for implementing the same pattern: Single-page applications (SPA). I believed that the SPA wagon was the future™. A few years of experience later, I am not sure what the future is, but I really want to have an alternative.

This piece really spoke to me. There’s a wide world of possibility with JavaScript, front-end frameworks and Single Page Apps these days. JavaScript’s maturing and growth over the past few years are a fantastic story. What I’m less enthusiastic about is the complexity that seems to pervade front-end development work.

I think a lot of it is getting used to having these rich tools available to solve problems. I also think, in many cases, we’re over-applying these tools when simpler solutions would fit many problems better than the full framework Single Page App approach.

The Post-Meritocracy Manifesto

Coraline Ada Ehmke, creator of the Contributor Covenant, has created the Post-Meritocracy Manifesto:

Meritocracy is a founding principle of the open source movement, and the ideal of meritocracy is perpetuated throughout our field in the way people are recruited, hired, retained, promoted, and valued.

But meritocracy has consistently shown itself to mainly benefit those with privilege, to the exclusion of underrepresented people in technology. The idea of merit is in fact never clearly defined; rather, it seems to be a form of recognition, an acknowledgement that “this person is valuable insofar as they are like me.”

After reading and digesting the document, I signed on. It reflects the values I aspire to and value for myself and in my peers.

Meritocracy, as a term was always intended as critique and satire:

The co-author of a classic work of sociology, “Family and Kinship in East London” (1957), Mr. Young was also known for coining the word “meritocracy,” first used in his biting futuristic satire, “The Rise of the Meritocracy” (1958)

…but, in the libertarian space that is much of big tech, it’s not at all rare to see the term used as a value statement. Red Hat’s CEO, Jim Whitehurst has specifically defended the concept as a core Red Hat value:

Seeking consensus and creating a democracy of ideas is not what we at Red Hat would call collaboration. In fact, it’s a misstep. Rather, managers at Red Hat make it a practice to seek out ideas from those who’ve shown that they typically have the best ideas—those who have risen to the top of our meritocracy.

To get to the top, though, it’s not enough to merely have an idea; you’ll also need to defend it against all comers. That means there may be disagreements. Voices will be raised. Building your reputation, therefore, can take time, patience, and a thick skin.

That sounds like a hyperaggressive Thunder Dome where the loudest, most stubborn, person “wins”.

Whitehurst continues:

This environment can seem harsh at first. But keep this in mind: Open source software developers say, “In the end, nothing matters but the code. The code wins.”

This is a recipe that rewards “brilliant jerks” and assholes. Our industry has far too much of that. It chases valuable contributors with differing communication styles or different valuations about empathy out.

We can do better.

The Post-Meritocracy Manifesto goes in a different direction and sets a more inclusive vision:

  • We do not believe that our value as human beings is intrinsically tied to our value as knowledge workers. Our professions do not define us; we are more than the work we do.

  • We believe that interpersonal skills are at least as important as technical skills.

And, directly countering Whitehurst’s point about the code being paramount:

  • We understand that working in our field is a privilege, not a right. The negative impact of toxic people in the workplace or the larger community is not offset by their technical contributions.

I feel fortunate that my coworkers and company, from where I sit, are substantially closer to the values expressed in the Manifesto and further from the world Whitehurst lays out. I hope anyone reading this would be so similarly fortunate. However, we have to actively encourage, support and reinforce this vision of an empathy-driven, diverse and inclusive tech industry.

If you’re involved in any part of the tech industry, please give it a read and consider signing on. Thank you.

The Airport Cemetery

My wife, Robin, and I visited the cemetery at Raleigh-Durham International airport after lunch Saturday, prompted by a discussion I had on Twitter earlier in the week with aviation geeks and meteorologist Nate Johnson.

Nate started with his surprise that Chicago’s O'Hare International Airport has a cemetery. That was also news to me, but I was reminded of the small cemetery at RDU. I figured Nate also knew it. But, no, it was news to him, and I suspect it’d be a small surprise to a lot of folks.

Robin and I have used RDU’s ParkRDU Economy Lot 4 for our occasional trips out of town, and on the drive in, we’ve passed Cemetery Road and seen a little bit of fencing. So, I knew it was there. But, it’s out of the way and for folks accustomed to coming and going from the airport via Aviation Parkway or Airport Blvd, they might never pass by. Even if you drive up to the Observation Park and then out to Lumley Road, you might miss it.

Here it is from using Google Maps’ satellite view:

Robin and I were in the area and, given the discussion from earlier in the week, we decided to drop by. There’s a chainlink fence around the cemetery and a small driveway, enough for two or three cars. There’s a pedestrian gate in the chainlink fence and a double swinging gate up a gravel and grass incline to allow vehicle traffic.

We walked around, looking at headstones and took a few photographs.

Here’s a view of the headstones looking diagonally SE to NW across the cemetery towards Runway 5L-23R:

Mt. Hermon Baptist Church Cemetery
I/RDU

This view is SW to NE, where cars parked in Lot 4 are visible in the background:

Mt. Hermon Baptist Church Cemetery
II/RDU

Finally, the sign that offered a clue about the history of the cemetery:

Mt. Hermon Baptist Church Cemetery III/RDU

The name Mt. Hermon Baptist Church struck a memory. I thought I remembered that church north of the airport, off of Leesville Road, just into Durham County. Looking at a map on my iPad, I could also see a Mt. Hermon Road running north and south that terminated on the north side of the Glenwood Avenue interchange with I-540. But, looking further, there was a continuation of the road on the south side of the interchange, crossing to Lumley Road and continuing as Commerce Blvd on the airport itself. (View on Google Maps)

That struck me as interesting and probably meant that it was contiguous at one time, before I-540 was built, beginning in 1992. Later in the afternoon, I went out for a walk and thought about where I might find a map of northwest Wake County from before I-540’s construction. I was thinking that I’d end up at the library looking for county property maps (and that will still be valuable), but, for whatever reason, I instead remembered the US Geological Survey’s topographic quadrangles. If I could get a past version of one of those, I might learn something.

As it happens, the USGS does have historical quads online in a variety of formats (PDF, TIFF, JPEG, etc) and scales. Using their TopoView tool, I was able to narrow down available maps for the area and then look at past dates. As it happens, there’s a 1982 edition map of the SE Durham quadrangle using 1973 survey data (large JPG).

Looking at the lower-right corner, there are a few things that we can see. One item is that Mount Hermon Road, labeled as Route 1646, is fully connected, with an interchange at Glenwood Avenue (U.S. 70). We see the absence of Interstate 540. Following Mt. Hermon Road south from Glenwood, we see the cemetery and a Mt Hermon Church on the map. Continuing south, we see that Runway 5L-23R does not yet exist. (It appears on the 1993 edition, but not on the 1991 edition 1:100,000 scale wider map from 1990 survey data, which is interesting because RDU history says the runway opened in 1986.)

The church congregation appears to have moved from what becomes a taxiway around the General Aviation apron, to Olive Branch Rd in Durham County. The cemetery is still taking newer burials. The newest burial we found is from Feb. of 2016.

This leaves me wondering when the church moved. I see there was a small cluster of buildings as an unincorporated settlement on the 1973 map, labeled Hermon. Digging into that might require looking at past census data and property tax records at the county level.

I’m fascinated by all of this and wonder how this all played out. Accordingly, there’s some interesting research to do yet in order to learn at least part of fuller history here. I will have a follow-up post when I do.

← Previous