Steel – Blame the American Politicians

Trump tweeted: “Our Steel and Aluminum industries (and many others) have been decimated by decades of unfair trade and bad policy with countries from around the world.”

OK, yes, foreign governments like China subsidize their industries to undercut the cost of steel manufacturing.  But that’s not the whole story.  We have our own politicians to blame as well.  Read this (written in 2011!):

American Steal: How U.S. steelworkers lost to China

This [the weakening of the American steel industry] is occurring despite the existence of “buy American” laws governing major construction projects. The problem, as always, is Congress made compliance optional. If contractors wanted to buy American they could. If they wanted to buy from China or any other government that subsidizes its corporations, they were free to do so. Lawmakers had not been the least bit serious when they drafted the legislation.

Sadly, we have only ourselves to blame.




The Three Personas of the Technical Industry

  1. The 1950’s cubicle farm, COBOL / mainframe / monolithic persona
  2. The cool we’re actually doing real things like SpaceX persona
  3. The new age we’re smith-wording new concexts into em-urgent planetary care zones persona

Which persona are you?

Code Review – What You Can Learn From a Single Line of Code


(image credit – a good article)

My first article of 2018 has been posted on Code Project!

It never fails to surprise me what can be gleaned from a single line of code. Gone are the days of BASIC where each line did one thing, a print statement, a gosub or goto, if-then-elseif-end if. Nowadays, a single line of code can be a chain of method calls, LINQ expressions, and operators like ?: (ternary if-else), ?. (null continuation), ?? (null coalescing) and even if-then-else implemented as extension methods.

What we’ll look at here is what can be gleaned about the implementation from just one line of code.

Read more here.

Higher Order Programming on the Web is Alive


A hard to read screenshot of HOPE (aka Semantic Computing) is now working on the web under the code name “Temporal Agency” (I love that name!), using:

  • Docker to isolate user projects and sessions
  • C# (Yay!)
  • DotNet Core 2.0 (Yay!)


  • IDE-style programming.
  • Syntax highlighting editor (courtesy of Ace).
  • Layout of results declared in XML.

This is very snazzy, in my humble opinion.  I have a couple demos working:

  • Weather forecast, tying in to UndergroundWeather, with summary (as shown above) and full forecast layouts.
  • Address verification using the USPS API’s.

More to come!

HOPE Semantic Rendering of Microservice Data on the Browser

In a previous blog post, I described the high level architecture of microservices
running in a Docker container.  This blog post describes (again at a high level) the behind-the-scenes implementation of how a we render the output of a microservice back to the client’s browser. We’ll use the Weather Underground API for acquiring our current weather conditions.

First, let’s start with a semantic address:

public class ST_Address : ISemanticType
  public string Address1 { get; set; }
  public string Address2 { get; set; }
  public ST_City City { get; set; }
  public ST_State State { get; set; }
  public ST_Zip Zip { get; set; }

  public ST_Address()
    City = new ST_City();
    State = new ST_State();
    Zip = new ST_Zip();

Note that there are other semantics involved here (ST_City, ST_State, and ST_Zip) which we won’t go into here.  We’ll populate the ST_Address with the two pieces that Weather Underground requires, city and state, and then publish this type to the docker container:

The microservice, in HOPE terminology, is a “receptor” that is interested in
the type ST_Address.  As implemented in C# (fragment):

public class WeatherForecast : IReceptor
  public void Process(ISemanticProcessor proc, IMembrane membrane, ST_Address address)
    string json = Http.Get("[yourapikey]/forecast/q/" + 
      address.State.State + "/" + 
      address.City.City + 

    var data = WeatherUnderground.FromJson(json);

    var statForecast = data.Forecast.Simpleforecast.Forecastday.Select(d =>
          Month = d.Date.Monthname,
          Day = d.Date.Day,
          Weekday = d.Date.Weekday,
          High = d.High.Fahrenheit,
          Low = d.Low.Fahrenheit,
          Conditions = d.Conditions,
          IconUrl = d.IconUrl,
          MaxWind = d.Maxwind.Mph,

    // ...
    // Building the day and night detail forecast is not shown.
    // ...

    Response result = new Response()
      HopeResultWrapper = new WeatherResult()
        StatForecast = statForecast,
        DayForecast = daySummaryForecast,
        NightForecast = nightSummaryForecast,

    // Call back to the host with the result.
    RestCall.Post("", result);

The response is associated with an XML file that determines the rendering.
Here’s a fragment showing just the first to rows (the day and the icon) of
rendering definition:


HOPE renders this into HTML and sends the HTML over an HTML5 websocket to the browser where the page defines this tag:


and on receiving the message from host, executes this Javascript:

 ws.onmessage = function (wsevt)
   var msg =;

The result is rendered on the browser like this:


By changing the rendering to a VerticalGrid we instead get:


By changing the rendering XML definition again (not shown, it’s quite long) we can show the results from all three collections — stat, day, and night — to render a more detailed forecast.


Of course, in real life, you’ll want to render the results of many microservices.  We’ll look at how that works soon!