My first steps with Azure Static Web Apps

Let me just start by saying that Build 2020 was awesome!!

There was a lot of great content going around for everyone, but as I was watching the “From code to scale! Build a static web app in minutes” session showing how easy it is to use Azure Static Web Apps, I couldn’t help but to try that for my own with this website!

My first attempt was to run through the “Tutorial: Publish a Gatsby site to Azure Static Web Apps Preview”, and in the end I was happy to see it created the Azure resources and the a new Github workflow showed up on my repository.

On close analysis of the workflow, I can see there’s a new Azure/static-web-apps-deploy action in use doing all the heavy lifting! Internally, this action is using Oryx build system to identify the type of source code in the repo and compile it.

Once the workflow started and got to the Azure/static-web-apps-deploy action, I quickly came to realize that it wasn’t happy with the fact that my “package.json” file had "yarn": ">=1.22" on the "engines" node… the build image only had yarn 1.17 and so the build failed:

error pedrolamas.com@0.1.0: The engine "yarn" is incompatible with this module. Expected version ">=1.22". Got "1.17.3"
error Found incompatible module.

At this point I edited my “package.json” file, lowered the yarn version requirement to “1.17”, and moved forward.

As expected, pushing this change caused a new workflow to start, but again, this failed:

error Processing /bin/staticsites/ss-oryx/app-int/content/assets/logo.jpg failed
Original error:
/bin/staticsites/ss-oryx/app-int/node_modules/cwebp-bin/vendor/cwebp: **error while loading shared libraries: libGL.so.1: cannot open shared object file: No such file or directory**

This time, the problem was a lot more complicated to fix: the libGL.so.1 library required by Gatsby to process the images was missing from the Oryx docker image!

At this stage I actually thought giving up and went to Twitter to somehow vent my frustration on what I just experienced:

John Papa quickly replied to that tweet, and asked me to open an issue on the Azure Static Apps repo.

After some messages exchanged, I followed up on a tip from Annaji Sharma Ganti to compile the source code before the Azure/static-web-apps-deploy action, and make the action point to the compiled static folder (the “public” folder in my case) - this way Orix would just skip the compilation bit and go directly to publishing the artifacts to Azure.

You can see here my changes to the workflow.

Finally, the workflow worked as expected and I could see my static GatsbyJs site hosted as an Azure Static Web App!

I then made a few more changes (like ensuring that GitHub would checkout the submodule with the website images and fixed some missing environment variables), added a custom domain, waited a few minutes for it to generate a valid SSL certificate, and… we are done!!

http://azure-test.pedrolamas.com/

I ran a website speed test with Fast or Slow and got 98 of 100 points, a 2 points improvement over a speed test of this website (which is built and hosted on Netlify with Cloudflare CDN)

Speed test results from Fast or Slow for this Azure Static Web App
Speed test results from Fast or Slow for this Azure Static Web App

Took a bit more of effort than I initially expected, but I’m very happy and very impressed with the result!

The Azure Static Web Apps is currently in “preview” so be aware that changes and improvements will happen before it is ready for production - in the meantime, go and try it out for free!

Microsoft Build 2020 registration is open, fully remote, and free!

Microsoft Build 2020, the biggest annual event from Microsoft for Developers by developers, is just around the corner!

In regular times, //build/ is an in-person paid event, but given the current situation with COVID-19, Microsoft announced that this year it will host the event virtually, and completely free!

The event starts on the with Satya Nadella, followed by 48h of live sessions!

You can register here right now!

My Windows Phone apps are now open-source!

As Windows Phone has been dead and buried for a while now, last weekend I uploaded all assets and source-code for my old Windows Phone 7.x and 8.x apps to GitHub, some of them never before published!

Here’s the list of the new repos:

All content is available under MIT license, but please bear in mind that I’ve built these a while back and so I give no guaranties that these are in working order!

What I've been up to lately!

A few months ago, I decided to take a break from UWP development, and since then I’ve been learning a lot of different technologies while working in new projects!

Don’t get me wrong here: I still love to work in UWP and will carry on doing so, but reality is that it’s been getting a lot harder to find companies looking for UWP experts to work.

At the same time, I believe there is nothing wrong with expanding your knowledge base by learning new stuff, so here we are!

Since learning React and TypeScript, I’ve fully migrated this website from Jekyll to Gatsby.

I enjoyed Gatsby so much that I have even contributed with a couple of PR’s and created my first Gatsby Plugin gatsby-remark-acronyms (this is also my first npm package ever)!

In my home I have a NanoPi NEO 2 SBC running Home Assistant as an all-in-one home automation solution, so I’ve open-sourced my whole configuration, including the Docker configuration that hosts it.

This gave me the opportunity to improve my Python skills, and so I have already contributed back with a couple of PR’s.

There are a few more projects I’m involved on that I haven’t mentioned above, but the more I learn new stuff, the more I think I should make a change to the site description: ”Windows Development”…

Changing the default binding mode with x:DefaultBindMode

On my Compiled Bindings considerations article, I wrote about the differences between regular bindings (Binding) and the UWP compiled bindings (x:Bind).

The most important bit to keep from that article is the fact that the default binding Mode for regular bindings is OneWay, while for the compiled ones is OneTime.

Best way to understand this is with some sample code:

<StackPanel>
<!-- the implicit binding mode here is "OneWay" -->
<TextBlock Text={Binding Name} />
<!-- the implicit binding mode here is "OneTime" -->
<TextBlock Text={x:Bind Name} />
</StackPanel>

Starting Windows 10 version 1607 (Anniversary Update, SDK version 14393), developers can change the default binding Mode by setting the x:DefaultBindMode attribute.

Applying the attribute to an element will make it and all child elements use the same value for binding mode.

Here’s the same sample code again, now with the x:DefaultBindMode attribute added to the root element:

<StackPanel x:DefaultBindMode="OneWay">
<!-- the implicit binding mode here is "OneWay" -->
<TextBlock Text={Binding Name} />
<!-- the implicit binding mode here is "OneWay", as set on the x:DefaultBindMode in the parent element -->
<TextBlock Text={x:Bind Name} />
</StackPanel>

Migrated from Jekyll to Gatsby

For the last couple of months, I’ve been working a lot on something quite different from my Windows Development expertise: writing .NET Core micro-services with React and Typescript front-end, running on Docker containers in Kubernetes, hosted on Microsoft Azure!

The thing is that the more I worked with React and Typescript, the more I was enjoying it — to the point that made me think on how I could use my new skills on this blog!

Back in 2017, I migrated my blog from WordPress to Jekyll and hosted on GitHub Pages.

From that moment my blog became blazing fast and I was fairly happy with the arrangement; plus, as far as I am aware, I had near-zero downtime on the blog!

However, I always felt that Jekyll in GitHub Pages was quite limited in what can be achieved (a simple example is that you can’t easily generate a page with all categories or tags).

I started to search for a React-based static site generator, and that’s how I found Gatsby!

Gatsby is a free and open source framework based on React that helps developers build blazing fast websites and apps

A month ago, I started to migrate the blog and today it is all Gatsby based, fully hosted on Netlify (provides free hosting, highly configurable build configuration, custom headers, redirect rules, …)

This very post if the first of many using the new platform!

As far as I can tell, everything is working properly, but if you find any problem, please report it by creating a new issue and I’ll take care of it as soon as possible!

Insider Dev Tour London

Microsoft is hosting the Insider Dev Tour London on June 18th, 2019 from 8:00 to 17:30 at the Vue Cinema in Leiceiter Square.

You can expect a lot of content around building Microsoft 365 experiences (Windows, Graph, Office, Teams), no matter your skill as a developer.

I will be there to talk about “Developing with the new Edge Browser”, and there will be quite a few familiar faces talking about other topics too!

More details and registration are available here!

Making the case for XAML Markup Extensions

Consider the following code:

<AppBarButton Content="Send" Icon="Send" />

In the above example, the AppBarButton.Icon property above is set to “Send” which is actually a value of the Symbol enumeration.

The Symbol enumeration is quite useful to quickly access glyphs from the Segoe MDL2 Assets font file, but this is a limited subset; a more complete list of the available glyphs can be found here.

If you want to use one of the symbols from that list that is not part of the Symbol enumeration, you need to escape the unicode point by prefixing it with ”&#x” and suffixing with ”;“.

For example, the unicode point for the “WindowsInsider” (Ninja Cat) glyph is “F1AD”, so the complete escaped code is ”&#xF1AD;”

In an ideal world, one would just use it like this:

<!-- this doesn't work! -->
<AppBarButton Content="Ninja Cat" Icon="&#xF1AD;" />

However, you will quickly realize that this doesn’t work!

The correct way is by using the FontIcon class and specifying both the font family name and the escaped glyph unicode point:

<!-- this works! -->
<AppBarButton Content="Ninja Cat">
<AppBarButton.Icon>
<FontIcon FontFamily="Segoe MDL2 Assets" Glyph="&#xF1AD;" />
</AppBarButton.Icon>
</AppBarButton>

MarkupExtension to the rescue!

Introduced in Windows 10 Fall Creators Update (v10.0.16299.0), the MarkupExtension class allows developers to write markup shortcodes just like the native {Binding}, {StaticResource}, or {x:Bind}.

To create a XAML markup extension, create a new class and ensure that it:

  • inherits from MarkupExtension
  • overrides the MarkupExtension.ProvideValue to provide the implementation
  • is marked with the MarkupExtensionReturnTypeAttribute and specifies the return type
  • has a name ending in “Extension”.

Following on our example, we can easily create a MarkupExtension that would return a FontIcon instance for a given glyph unicode point:

[MarkupExtensionReturnType(ReturnType = typeof(FontIcon))]
public class FontIconExtension : MarkupExtension
{
public string Glyph { get; set; }
protected override object ProvideValue()
{
return new FontIcon()
{
Glyph = Glyph,
FontFamily = new FontFamily("Segoe MDL2 Assets")
};
}
}

Having this on our code, we can then use it in XAML just like this:

<!-- this works just fine! -->
<AppBarButton Icon="{local:FontIcon Glyph='&#xF1AD;'}" />

In the end, we went from 5 lines of XAML code to just 1!