Awash in the Waves of the Tech Conference Glory – InApps 2022

Whenever I leave a tech conference, I have a subtle feeling of being hungover for a few days after — long after the effects of any closing party or open bar have subsided. It’s more a feeling of my brain being overfull of stuff I don’t yet know how to make sense of than anything else. It’s having spent so much time in a big room full of staunch believers, it can make one’s head spin. Company sponsored conferences aren’t typically packed full of skeptics, but rather devotees, evangelists, and mercenaries. In optimistic terms, you can say that some attend to learn, network, and share. The skeptics, however, rather see countless opportunities for inculcation, indoctrination, and even bribery.

“Come get your swag! Free t-shirts! Sit through three demos, and you’ll get a hoodie!”

In the end, you walk away — they hope — a more capable, educated, locked-in and devoted user of their product. A walking advertisement, both in attire and attitude.

But none of that is really to say that you don’t learn things that make you do what you do better. You make connections, build relationships, discover new methods and spark new thoughts. You come away with questions answered and problems solved.

There’s many a cliche about coins, swords, clouds and otherwise, that could be applied here, but the long and short of it is that it’s not just one thing. The tech echo chamber is loud and focused. As we focus on efficiency and ease-of-use, extensibility and integration, we can forget to look at the other side. When something is “democratized” and delivers “high-performance,” that can only be good… right?

One author I consistently look to for both sides of the story is Kin Lane, who spent much of the past decade serving as The API Evangelist, exploring and writing about the world of APIs. Last fall he stepped back, writing that “the reality that not all API service providers truly want to help enterprise organizations genuinely solve the business challenges they face, and that many enterprise technology leaders aren’t actually concerned with truly solving real-world problems, has been one of the toughest pills for me to swallow as the API Evangelist over the last eight years.”

After six months of silence, Lane recently restarted his writing, and this week offers a piece on his personal blog about the sentinelization of APIs, which takes direct aim at a realm many of us so often unquestioningly proselytize. Lane, rather, looks at the darker potential of APIs, a technology we commonly view as a great connector, a democratizer, an integrator and enabler. Sentinelization refers to the weaponization of these APIs, in that they can be used against the very users who they were originally designed to serve.

“We are in the early stages of API sentinelization, with many more consequences to reveal themselves down the road,” writes Lane. “APIs are early sentinels. They are originally built as an application development unit, but are quickly being given (cyber)military tasks. They lack dedicated offensive weaponry, but like a Sentinel, or maybe a Bobcat backhoe, they possess a number of potential attachments that can be weaponized pretty effectively.”

Connection and integration and enabling may take on different meanings according to who wields the resultant powers, and Lane writes that APIs have an insidious nature, with their good nature only contingent upon the goodwill of their users.

“Think of it more as a cognitive tic or parasite that finds its way into your existence, allowing it to mine your experiences, and even direct them when they want to. Sure, most of these APIs are being used to construct specific application-based experiences today, but as we ratchet up cyberwarfare around elections, and other real-world events, the weaponization of these units are inevitable,” writes Lane. “The API sentinels know where we live, and already have their hooks in us in many ways. All that needs to happen is seismic shift in how tech companies operate to allow APIs to go from good to bad. It is something that can be driven by the desire of venture capitalists, a response to regulatory oversight, or maybe a new deal between the government and tech companies.”

In a separate post days later, Lane further expanded his ideas, with a piece examining the origins of reducing everything to a transaction and what he sees as the resultant realities of the modern technological landscape.

“Transactions are much neater, cleaner, and able to [be] routed, moved, bought, sold, and satisfy our rational belief system that keeps us developing reality across our beloved computational landscape,” writes Lane. “A computational belief system bundled with a strong belief in markets and (some) individuals, reinforces our (white men) natural rights to reduce things to a transaction, without any concern that those transactions are bits of human lives, or have real-world impacts on human lives.”

Well, those are words you certainly won’t hear on any keynote stage at a tech conference these days, but… perhaps they should be. We walk a dangerous path if we simply focus on “efficiency” and “performance” and “integration” if we don’t examine that other side.

And with that, here’s some of the latest news in features, efficiencies and performance.

This Week in Programming

• How Do I Program This Thing? While some of you may practice proper search methods, the rest of us are over here asking the Internet how to do things like it can understand us. Well, Facebook is aiming at doing exactly that with its Neural Code Search, a machine learning-based code search using natural language queries. While natural language queries may work for popular languages and platforms, others may not have such a big presence on forums like Stack Overflow, so Facebook has “developed a code search tool that applies natural language processing (NLP) and information retrieval (IR) techniques directly to source code text. This tool, called Neural Code Search (NCS), accepts natural language queries and returns relevant code fragments retrieved directly from the code corpus.” For the how and beyond, read on.

• GitLab Goes Full-On DevSecOps: GitLab came out with version 12.0 earlier this week, calling it “a key step in our journey to create an inclusive approach to DevSecOps.” The company briefly reviewed a few new features in 12.0 and then, as DevClass writes, “reeled off a list of security features which have actually been part of the platform for a while, including SAST, DAST, dependency scanning, and container scanning, as well as security dashboards.” Putting the move in context, DevClass further writes that GitLab’s “moves mirror what its rivals in the CI/CD/Dev(Sec)Ops world are doing. Aussie giant Atlassian, building out from its Jira base — bought OpsGenie last year and launched JiraOps. Meanwhile, GitHub last month bought dependency scanning outfit Dependabot, and is becoming steadily more integrated with parent Microsoft’s Azure services, including Azure DevOps.” For GitLab’s TLDR on the release, check out the video below.

• On the Way to Go 2: The Go team published a blog post this week about the next steps toward Go 2, which arrives in the form of Go 1.13 sometime in August (they hope). “We wanted our initial selection of proposals to be relatively minor and mostly uncontroversial, to have a reasonably high chance of having them make it through the process,” they write about the process, discussing the changes made to arrive at 1.13 before exploring what is proposed for Go 1.14. Three areas of focus for 1.14 include “package and version management, better error handling support, and generics,” with generics being the focus of a talk by Ian Lance Taylor scheduled for this year’s GopherCon in San Diego. The proposal for 1.14 includes a handful of new features, and the team writes that they are soliciting feedback, “especially interested in fact-based evidence illustrating why a proposal might not work well in practice, or problematic aspects we might have missed in the design.”

Feature Image by Dimitris Vetsikas from Pixabay.