The end of programming?

While this blog has so far been mostly timeless, I'm going to comment here on a current event: an article arrived today in my mailbox, titled "The End of Programming"^* and subtitled, "The end of classical computer science is coming, and most of us are dinosaurs waiting for the meteor to hit," written by Matt Welsh.

I'm arguing that the use of PicoStack to develop small web applications could continue, long after most computer applications are developed using artificial intelligence (AI) techniques, and code is being written routinely by AI agents instead of humans.

Managing channels

A previous post, Pico channels, defines and describes channels, and prescribes some best practices for managing them. 

This post tells a story of bad consequences when that advice was ignored^*, and also describes a more resilient way to set up the channels for one particular application.

Consider a pico that records temperature readings from remote sensors. The sensors need a channel to post their readings periodically. A web application allowing the history of those readings to be explored also needs a channel to the pico.

Notifications

Each pico, from the moment it is created, is a first-class Internet resource, exposing a rich API of events and queries. It maintains a boundary between its internal state and the outside world.

When something interesting happens inside the pico the owner/controller of the pico may want to be notified.

A previous post about sending email illustrated this for that notification method. In this post, we'll discuss sending a message into a Microsoft Teams channel. Similar techniques can be used so that our pico can notify other message systems.

Scheduling events

Picos are a good fit for applications that have a relatively small amount of state for each entity, and that perform relatively quick computations, relatively infrequently.

Web applications fit that profile. From time to time, someone requests information about the state of an entity. That state is expressed as a web page, and that doesn't take a lot of time to compute.

Every so often, an event occurs that is of interest to the entity, and the pico reacts to that event by changing its state, which also doesn't require a lot of compute time.

Sometimes, though, we'll want the entity's pico to spontaneously wake up and do something. This is where scheduled events come into play.

Sending email via a web API

This is part four in a series^* on using web APIs to accomplish useful things in a PicoStack web application.

We have talked about consuming web APIs in a read-only fashion, safeguarding web API secrets when they are required, and wrapping the complexity of an API in a ruleset used as a module.

In this post, we'll use all of these techniques and demonstrate how to use a web API to send simple text email messages.

Wrapper opportunity

When using a web API it can be nice to have a wrapper around the various HTTP requests that can be made.

On the plus side, this allows for a separation of concerns. Your code doesn't need to get into the details of making the HTTP requests.

Often, the provider of the web API also supplies wrappers for various popular programming languages. Some, like TMDb (used in the previous post) accept wrappers from their developers and list them for use by other developers.

Web API secrets

In the previous post, we consumed a web API which was provided freely (which we called "public") in that it didn't need to know who we were. Most web APIs require consumers to identify themselves, and do this by giving out an API key and/or client secret.

The identifiers we will obtain from an API provider are intended for our use only, and we are responsible for that usage. In this post, we'll show a couple of ways to keep them secret while we consume such APIs.