I have been working a lot in Microsoft’s Azure platform, and for the most part it has been a relatively smooth transition. Lots of new things to learn, a fair bit of code refactoring and adapting to the new cloud environment.

Recently, I ran into a odd problem at a client of mine that runs on Azure. My client came to me regarding a January email that was supposed to go out at the beginning of the month, and the January email showed December data.

So I dug into this, and verified the report was scheduled to run on the First Wednesday of every month, and verified that the emails were inserted into our outgoing mailbox a minute after midnight on Wednesday January 1st. I spot checked a few of the emails, and indeed they did have (incorrectly) December information. I looked thru the code, and the sql server stored procedure and still could not find a reason.

Finally, I looked at the job run log and found the problem:

The job that was supposed to run at midnight was kicked off at 11:59:57 by Azure’s job trigger. When the report runs, if checks to see the current month year of the run to choose its data, and in this case, it was December.

It’s curious to me that the scheduler is that imprecise. For years networks have had a common time synchronization service which pretty much guaranteed times across servers, but apparently there is a discrepancy between Azure services. I will have to get use to the idea that these cloud services provided by Azure my be loosely coupled, and these services may be more autonomous than my previous windows network world.

My work around for this is simple. I can delay the run of this job a couple hours, so the job will run at 2:00am instead of midnight. My assumption at this point is 2 hours should be safe. But in this brand new cloud world, there is always something to surprise you.

A while ago, I bought a Hue light and bridge to experiment with. Hue Lights are a smart home light that can be automatically turned on and off via a timer or event trigger. I decided to start experimenting with Hue, because they have a pretty easy API to use that allows fully flexible integration with other sorts of devices or data.

I could of gone the simple route and just used IFTTT.com to integrate my hue lights with other devices. For a few years now I have been using IFTTT.com, and for the most part I could handle all my geeky smarthome needs using IFTTT. However, I don’t find it as flexible as just coding it myself. IFTTT does have the ability to use its custom language platform, but after looking at it I decided I didn’t have the energy to learn another proprietary language/structure, so I have decided to do more with building my own custom logic in C# and using Microsoft Azure. I will still use IFTTT for most the simple things, but my goal is to start integrating everything into my own custom platform to manage devices.

So my first ‘Hello World‘ application using the Hue API and Microsoft Azure platform was to turn a light on every morning, varying the color of the light by the weather forecast for the day. So if it is supposed to rain the light will be blue, if it is to be sunny the light will be yellow.

There were numerous hurdles to doing this, primarily because I was trying so many new things. Learning the base Hue API for internal access was by far the easiest, I was able to run commands from my local network in under an hour. After that, I tackled the logic to call the weather API, which also turned out to be pretty easy. It turns out the National Weather Service has an API that you can call to get the days weather –
https://www.weather.gov/documentation/services-web-api. Pretty simple authentication, and once I got past that I found the endpoint to call and in an hour or so I had logic built to pull the days forecast. Thinking I was close to achieving my goal, I was feeling 90% done with my project. Of course, as with most programming projects, it turns out the last 10% of the project consumes 90% of the time. Here is where it got complicated:

1. Hue remote API access.I want this program to run out at Microsoft Azure, so that I don’t have to have my PC have to wake up at 6AM to run the job. So I had to configure my Hue bridge to take requests from outside my home network. Hue uses OAUTH to communicate security credentials, and my understanding of OATH flow was not that current (I am an old username / password guy..) so I had to first re-conceptualize the whole authentication / refresh token flow and figure out how to support it. Once I figured all that out I had to figure out how I wanted to store my tokens, so I had to build a subsystem to manage that whole process. I made this work more complicated than I needed to of course, because I made it flexible to handle future APIs that use Oauth. So I burned several hours getting an understanding of the workflow, and building out all that. But now I think I have a platform ready that will make my next Ouath integration easier.
2. Azure Functions and .NetCore.  This is a great example of how software projects go way over deadline. Because I am in charge of the scope for my little experiment, I decided to expand it a bit. I wanted to set up a new Azure function to handle all my future IOT needs. Microsoft’s Visual Studio now comes with a nice template to build Azure Functions for Azure, so I decided to use it. I also decided to build it using .Net Core, which is the newest and most efficient .net framework. .Net Core allows to run .net on Linux machines, so in the future if I want to run these or other programs locally on a Raspberry Pi, that sets me up to do that in the future. It turns out I seriously underestimated the time it would take to build this out using .Net Core. The biggest hurdle was all my utility class libraries are built in .net Framework 4.7, which is not compatible with .Net Core. So I had to reinvision my future architecture for my class libraries. I experimented with .Net Standard (a compatibility standard), and threw that out. I ended up just standing up parallel utilities in .Net Core, which at this point I will use for all my IOT projects. I think it was the right thing to do, but this probably tripled the time I had budgeted for this project. Once I got all this build out and plugged into the new Azure functions project. I was easily able to publish this project to Azure, and my project was live! Each day at 6AM the program wakes up at Azure, and turns the light on in my house.

My first few days of testing happened to be rainy, so the light was always blue. I got tired of that pretty quick, so I decided to add logic to vary the color of the light by ‘raininess’. Using this code, I now can vary the light color by approximately the forecast for the day:

string shortforecast = p.shortForecast.ToLower();
int rainScore = 100; 
rainScore += (shortforecast.IndexOf("rain likely") >= 0) ? 155 : 0;
rainScore += (shortforecast.IndexOf("chance of rain") >= 0) ? 100 : 0;
rainScore += (shortforecast.IndexOf("occasional showers") >= 0
           || shortforecast.IndexOf("slight chance rain showers") >= 0            
            || shortforecast.IndexOf("light rain") >= 0          
             ) ? 50 : 0; 
if (rainScore == 100 && shortforecast.IndexOf("rain") >= 0)
        {          
             rainScore += 25;
        } 
int sunScore = 100; 
sunScore += (shortforecast.IndexOf("sunny") >= 0) ? 155 : 0; 
sunScore += (shortforecast.IndexOf("sunbreak") >= 0) ? 100 : 0; 
sunScore += (shortforecast.IndexOf("partly cloudy") >= 0) ? 50 : 0; 
if (sunScore == 0 && shortforecast.IndexOf(" sun ") >= 0)
      {
         sunScore += 25;
      }

I then build the color for the hue light of the rain and sun intensity. Note that I am using one of these ridiculously expensive color hue lights (around $50), which gives me the flexibility of using a vast array of colors.

So for now my experiment is complete, and I am enjoying a quick glance at the light to see the days weather forecast. This has been an interesting (though over budget) experiment, leading me to even more ideas for the future. Please don’t think I am an idiot for spending $50 for a light that changes color based on the weather – I consider this is an experiment and the first step in building out a fully integrated smarthome.

Another example about how little Microsoft cares about its Microsoft Access product appeared to me today when a client of mine ran into a problem with their Microsoft Access database. Suddenly they started getting ‘Query is corrupt’ messages in the application.

Since I hadn’t made any changes to this application in a long time, I did the usual compact and repair assuming that would fix it. After trying all my usual tricks, I finally went to google where I found the culprit.

According to this support article from Microsoft, this problem was introduced by an office security update that was automatically installed on my clients computer. Comically, the article provides a byzantine workaround to fix the problem:

If you encounter this issue before the fix is available, the recommended workaround is to update the query so that it updates the results of another query, rather than updating a table directly.

For example, if you have a query similar to:

UPDATE Table1 SET Table1.Field1 = “x” WHERE ([Table1].[Field2]=1);

You can create a new query (Query1) defined as:

SELECT * from Table1;

And update your original query to:

UPDATE Query1 SET Query1.Field1 = “x” WHERE ([Query1].[Field2]=1);

I applied that fix to the various spots in my application where I update tables, and that got me through the day. Since someday somebody will stumble across this code and think I am an idiot, I made sure to reference the article in my comments as to why this is coded so ugly.

What amazes me about this is the casual approach Microsoft is taking to fixing the problem. Their plan is to fix it December 10th, almost a month after introducing the problem. My question is, how many small businesses are running mission critical Access apps, and don’t have any Access developers on hand. I know of a few companies in that situation, and I guess once they download this update, they will have to find a workaround.

Curiously Access users on the Office 365 platform will get their fix on November 24th. That is still 2 weeks out, and it may foretell that customers running older versions of Office software will be considered second tier customers.

I have said before that I have concerns about Microsoft’s ongoing commitment to Microsoft Access. This latest development only reaffirms my position that even though there are still many active Microsoft Access applications out there, Microsoft must think they are not important.

On Wednesday, October 2nd, Microsoft made some interesting announcements regarding new devices and notably, a new version of windows. This Windows Central article gives a great overview of how Windows 10 is being reimagined, and I think it looks intriguing.

Windows 10 in its current state is a big monolithic dinosaur, the accumulation of 10 + editions of the base windows 95 architecture. I can only image the spagetti code that exists inside windows 10, but the fact that every patch that is released for Windows 10 comes with headlines of issues, it appears that it is really getting unmaintainable.

So Microsoft announced Windows 10x, which appears to be a rearchitecture of the operating system to cover a wide variety of devices. Instead of a ‘one windows for all devices’ mentality, it is being modularized to only run the components that make sense for each device. According to the Windows Central article referenced above:

This new edition of Windows 10 is based on Windows Core OS, a modular version of Windows 10 that aims to modernize and componentize the OS for all kinds of device form factors such as HoloLens 2, Surface Hub 2X, and more. 

Initially, Windows 10x will only run on the new mobile devices they announced. This stripped down windows 10 assumedly will contain only the bare minimum of functionality needed, which makes sense for new mobile devices. To reduce Windows size and complexity, why not strip out printer support, win32 support and other ancient code needed to run older technology? Windows 10 still has code to run 1990’s era Visual Basic 6 on Windows 10 – is it necessary to port support for that to a new operating system?

I think Microsoft came to the conclusion that Windows 10 in its current state is unmaintainable, and it needs to be rearchitected. I give them alot of credit for thinking ahead and envisioning a better future for Windows. Here is a prediction – I think they will re-brand this before launch, dropping the 10x name and having a name not related to Windows 10 at all.

I have been pretty critical of Microsoft over the years, but I have to give them credit for turning it around. Since Satya Nadella arrived as CEO of Microsoft in 2016, things have changed much more than I expected. They are making smart decisions (mostly..), and really challenging the old ways of doing things. I knew that Nadella would be a huge improvement over the Ballmer administration, and so far I think Microsoft and Nadella have exceeded everybody’s expections.