It’s already been thoroughly nitpicked over the years, but apparently we’re all fighting about how to pronounce “GIF” again on Twitter. It’s only been, what, 32 years now?

I see we're fighting about gif again today. May I please draw your attention to my definitive article on the matter (it has real live corpus data!)https://t.co/Is44k5hDvT pic.twitter.com/03DhjZuRwF — Gretchen McCulloch (@GretchenAMcC) March 27, 2019

While Internet linguist Gretchen McCulloch says that she has written the “definitive article” on the matter, which basically says it could go either way, I personally find the argument of web designer Aaron Bazinet, who managed to secure the domain howtoreallypronouncegif.com, rather convincing in its simplicity: “It’s the most natural, logical way to pronounce it. That’s why when everyone comes across the word for the first time, they use a hard G.” Bazinet relates the origin of the debate as such:

“The creator of the GIF image format, Steve Wilhite of CompuServe, when deciding on the pronunciation, said he deliberately chose to echo the American peanut butter brand, Jif, and CompuServe employees would often say ‘Choosy developers choose GIF(jif)’, playing off of Jif’s television commercials. If you hear anyone pronounce GIF with a soft G, it’s because they know something of this history.”

McCulloch, however, points out that this sort of variation exists across many parts of language and should be embraced, not weaponized.

"But Gretchen, how will I weaponize a trivial and harmless consonant difference to make other people feel bad and self-conscious about themselves?" Maybe just….don't do this. Language variation is okay! It's fascinating! It doesn't need to be a tool to put people down! — Gretchen McCulloch (@GretchenAMcC) March 27, 2019

The point is, there are lots of other words that now exist in this world that have spellings that simply don’t translate to an expected pronunciation.

Linkerd. Containerd. SQL. These are just a few examples.

Sometimes, I wonder if this is the tech world’s way of sussing out who’s in the know and who’s a n00b — that weaponizing that McCulloch mentioned — by choosing pronunciations that would obviously go against the grain. It’s like Houston St. (for the New Yorker in the know, that’s “how-stin” not the Texas “hyu-stuhn”) or Couch St. (dear Portland…”cooch”? really?) or Manor Rd. (Austin likes “may-ner” here).

If it’s pronounced “container-dee” and “linker-dee” why’s there no visual clue? Why no capital D, at least? And why pronounce it “sequel” for “SQL”?

Because it’s the secret password to get into the cool kids clubhouse… or, rather the result of entering this new era with primarily text-based communication where pronunciation comes second to a word’s creation. In the past, spoken language came first and was then later codified into letters and spelling, but now the tables have been turned and we find ourselves spending decades debating whether it’s “gif” or “jif” because the guy who invented the standard happens to want to pronounce this word a certain way.

Maybe the real solution is to just live our lives forever in Slack and forget about that whole “talking” thing — it’s just a legacy app anyways.

This Week in Programming

GitLab Adds Secret Detection, Open Sources ChatOps: Starting off this week, GitLab has announced version 11.9, which adds a couple interesting features such as multiple merge request approval rules and, most notably, that of secret detection. The new feature scans each commit to make sure it doesn’t contain secrets, such as an API key, and when it finds something, it immediately alerts the developer of the merge request, giving them time to invalidate the leaded credentials and create new ones. (More on this sort of problem with GitLab competitor GitHub momentarily, for scope.) The new version of GitLab also helps with the review process by adding “greater controls and more structure with Merge request approval rules.” GitLab had already allowed users to specify when a merge would need approval by someone, and now “multiple rules can be added to a merge request to require individual approvers specifically, or even require a number of approvers from a particular group.” Finally, GitLab has also decided to open source ChatOps, which it calls “a powerful automation tool, allowing you to execute any CI/CD job and receive the status of the job directly from chat apps like Slack and Mattermost.”

Starting off this week, GitLab has announced version 11.9, which adds a couple interesting features such as multiple merge request approval rules and, most notably, that of secret detection. The new feature scans each commit to make sure it doesn’t contain secrets, such as an API key, and when it finds something, it immediately alerts the developer of the merge request, giving them time to invalidate the leaded credentials and create new ones. (More on this sort of problem with GitLab competitor GitHub momentarily, for scope.) The new version of GitLab also helps with the review process by adding “greater controls and more structure with Merge request approval rules.” GitLab had already allowed users to specify when a merge would need approval by someone, and now “multiple rules can be added to a merge request to require individual approvers specifically, or even require a number of approvers from a particular group.” Finally, GitLab has also decided to open source ChatOps, which it calls “a powerful automation tool, allowing you to execute any CI/CD job and receive the status of the job directly from chat apps like Slack and Mattermost.” Meanwhile, Over at GitHub: Speaking of vulnerabilities and code repositories, ProgrammableWeb relates the story of some research that indicates rampant GitHub data leaks of, you guessed it, “API tokens and cryptographic keys in alarming numbers.” The summary report, entitled “How Bad Can It Git? Characterizing Secret Leakage in Public GitHub Repositories,” describes the scanning of about 13 percent of the open-source repositories on GitHub over six months, finding “that over 100,000 repositories suffered leaks of secret information” with thousands of new leaks occurring daily, calling the problem rampant and far from solved. GitHub responds that many of the leaked tokens are likely void and that their own practice “includes notifying service providers within seconds of leaks being made public,” as well as employing “token scanning,” which has “notified service providers about more than 100 million potential token matches for verification and revocation.”

Welp… Just got trolled by Google, and my dumb ass STILL clicked on the correction link like it was going to give me a different set of results. ??‍♂️ pic.twitter.com/qvKgtdQBtI — Jeremy Sinclair (@sinclairinator) March 23, 2019

Microsoft and Facebook Intro Open Source Python Tools: Two new open source tools have arrived for the Python community this week. First, InfoWorld tells us of Microsoft’s speedy type checker for Python, called Pyright, which is an open source static-type-checking system for Python “that aims to be faster than existing type-checking solutions for Python such as Mypy.” The tool is written in TypeScript, runs on Node.js, doesn’t require an existing Python runtime to function and primarily meant “to be used as a Visual Studio Code plugin, but can also run as a standalone command-line tool.” Microsoft boasts that Pyright is “‘typically 5X faster’ than other Python type checkers that are themselves written in Python, such as Mypy, Pytype, and Pyre.” Next, Facebook announced that it is open-sourcing Python Test Runner (ptr), which allows developers to run Python unit test suites. Python Test Runner “crawls a repository to find Python projects with unit tests defined in their setup files” and then “runs each suite in parallel with configured enabled steps.” It runs on Linux, MacOS and Windows and is available on Github and PyPI.

Two new open source tools have arrived for the Python community this week. First, InfoWorld tells us of Microsoft’s speedy type checker for Python, called Pyright, which is an open source static-type-checking system for Python “that aims to be faster than existing type-checking solutions for Python such as Mypy.” The tool is written in TypeScript, runs on Node.js, doesn’t require an existing Python runtime to function and primarily meant “to be used as a Visual Studio Code plugin, but can also run as a standalone command-line tool.” Microsoft boasts that Pyright is “‘typically 5X faster’ than other Python type checkers that are themselves written in Python, such as Mypy, Pytype, and Pyre.” Next, Facebook announced that it is open-sourcing Python Test Runner (ptr), which allows developers to run Python unit test suites. Python Test Runner “crawls a repository to find Python projects with unit tests defined in their setup files” and then “runs each suite in parallel with configured enabled steps.” It runs on Linux, MacOS and Windows and is available on Github and PyPI. Swift Five is Alive: Next, some news for you iOS devs with the release of Swift 5, which Apple is calling “a major milestone in the evolution of the language.” According to the release, with the stability of the Swift Application Binary Interface (ABI), “the Swift runtime is now included in current and future versions of Apple’s platform operating systems: macOS, iOS, tvOS and watchOS,” with a focus on Linux, Windows and other operating systems as Swift development on those matures. The latest version also includes “a reimplementation of String, enforcement of exclusive access to memory during runtime, new data types, and support for dynamically callable types.” A playground is available to play with some of the new features and an updated version of The Swift Programming Language for Swift 5 is also available and free on the Apple Books store.

Microservices are mostly just subroutines dressed up in formal clothing. https://t.co/siogVoadHO — Grady Booch (@Grady_Booch) March 25, 2019

Feature image via Pixabay.