hudgeon

That would certainly save some time, but maybe take away from the emotional appeal :)

Hmmm. Good question. I was using standard format to mean two things:

1. Common code format across the Power platform, and

2. the branding MS was using to describe everything that would be put under source control.

I have some doubts about whether the second point is true.

This article (https://docs.microsoft.com/en-us/power-platform/power-fx/ove...) discuss PowerFX stored as YAML files under source control.

And this article which predates the PowerFX announcement (https://powerapps.microsoft.com/en-us/blog/source-code-files...) discusses UI YAML files under source control.

But nowhere does it say that they are branding the UI YAML files under the PowerFX moniker.

PowerFX is MS's name for the standard code format. I believe their ultimate goal is that:

- business users build apps using a graphical low-code interface,

- these then convert to PowerFX source code that goes into the enterprise's source control system.

- The enterprise IT team tests the code, re-writes key components and deploys.

- And these changes are then reflected back into the low-code app development environment.

This allows business users to contribute domain expertise and IT to maintain their quality and governance role.

Needless to say, this is non-trivial from a tech perspective but, in my view, is a better approach than an enterprise having a separate deployment and governance framework for low-code/RPA apps than for their other custom applications developed in Java/C++ etc.

Thanks. As the article's author (and first time writing something that hits HN) it's been interesting seeing which parts of the article have struck a nerve and which parts have gone through to the keeper.

I've done a fun exercise with grade 5 and 6 students where you build a computer that can taste food.

It takes about 30 minutes and the students simulate the algorithm by walking around the class, so it's engaging.

Training the algorithm:

The students line up along one of the classroom walls. I name a food like broccoli or chocolate and the students walk across the classroom a distance (out of 10) that represents how much they like the food. Most students would walk further across the classroom for chocolate than broccoli for example.

The class then comes up with an median score that represents how much they like the food based on the position of middle positioned student in the class. For example, for chocolate, the middle positioned student may be 80% of the way across the classroom. For broccoli, the middle student may be 30% of the way across the classroom.

We then talk about the visible features of the food. Chocolate, for example, is in a wrapper, is brown, is rectangular etc. Broccoli is green, round, small etc.

Testing the algorithm:

After repeating this for 10-12 foods, we then take a food we haven't looked at yet. An apple, for example. The students individually write down their rating of how much they like it out of 10 (but don't tell anyone their rating). We agree the features of the apple and then calculate the score based on the score of the features from the 10-12 foods that we scored in the training.

The students then go to the position in the classroom that represents their rating and we calculate how much the computer likes the food.

Tips:

You need to carefully select your foods so you get multiple results for as many features as possible.

Class discussion:

There's lots to discuss:

Median, machine learning, bias etc