×

First time here?

You are looking at the most recent posts. You may also want to check out older archives. Please leave a comment, ask a question and consider subscribing to the latest posts via RSS or email. Thank you for visiting!

How I solved Jessica’s NYC Parking Problem with Twitter, Twilio and NO CODE

I’ve been reading a lot of great content on dev.to lately (seriously you should go check it out and follow some tags…great community there) and came across this great headline “How I Solved My NYC Parking Problem With Python, the Search Tweets API and Twilio” by Jessica Garson, a Developer Advocate at Twitter.  Jessica was trying to solve a problem that NYC folks have when trying to determine when to move their street-side parked cars each night due to ‘alternate  side regulations’ which determine when certain sides of roads can be used or the regulations won’t be enforced due to holidays, events, whatever.

New York City parking sign

She delved into using Python, the Twitter Search APIs and Twilio to tie these all together.  Fun problem to solve and results in a text to Jessica whether she needs to worry about moving her car or not.  Immediately after reading it I though of the game show Name That Tune.

Picture of Name That Tune game show

The premise of the game show is that contestants battle it out to who can identify a song based on the fewest amount of notes in a song.  So of course, it is 100% applicable to code, right?  Anyhow I thought to myself Self, I can solve this problem in less effort and with NO code!

Immediately I went to work using Azure Logic Apps.  Azure Logic Apps are a means to…well, let’s let the marketing people tell us what they are:

Azure Logic Apps simplifies how you build automated scalable workflows that integrate apps and data across cloud services and on-premises systems. 

Lots of buzzwords there but basically it’s workflow/orchestration platform that allows you to use ‘connectors’ between various inputs and outputs.  Logic Apps can be developed using code, but most are easily developed using no code and using the graphical connector tools.  If you’ve ever used/heard of Microsoft Office Flow this is powered by Azure Logic Apps underneath!  So immediately after reading the article I went to work.  I knew that Azure already had pre-build connectors for Twitter and Twilio and that I should be able to do this easily.  Connectors are pre-defined pieces of logic that help get access to events, data, and actions across other apps and platforms, in our case Twitter and Twilio!

Jessica’s problem was fairly simple: Watch when the @NYCASP account tweets and if it indicates rules are ‘suspended’ then alert her with a text message.  Now this relies on @NYCASP account being consistent in their tweets and it turns out they are VERY consistent in them, so it’s easy to search for the simple terms as Jessica did.  So let’s do the same. 

Screenshot of Twitter account for NYCASP

To get started I needed an Azure account which is free to get started and there are a ton of services free that you can use forever.  I also still needed a Twilio account like Jessica notes so you still need that to get your Twilio credentials…be sure you have that.  With both of these in hand, let’s log in to the Azure Portal….we won’t even need any tools other than a browser to complete this app!

In the portal you’ll create a new resource in Azure…search for Logic App and it will show up:

Screenshot of Azure portal

You’ll need to provide a name, choose a resource group plan and a geographic location where you want this to live.  If you’ve never created any Azure resources before, a resource group is a container for certain compute resources to leverage.  For this, I recommend creating an App Service resource group and using a free plan that comes with your free trial account.  Then you can use this resource group for your Logic App.  Once you have that created navigate to that resource and you will see a page that welcomes you with a tutorial video and some options for pre-configured templates.  Thankfully one of the starting options is “When a new tweet is posted” so let’s use that one to help us get started as it will default add the Twitter connector!

Screenshot of Azure Portal Logic App creation

This dumps us into the Logic App designer, a graphical interface that helps us do the connections.  You’ll immediately see the first ‘trigger’ which is our Twitter one and it wants you to sign in to be able to use the functionality (think of this as authorizing use of the API).  Once you sign in click continue and you’ll get the options.  Now basically we want to look for when a new tweet is posted by @NYCASP on a time interval.  Their account is pretty consistent so I chose every four hours and used the ‘from:@NYCASP’ query language as the search text.

Screenshot of Twitter connector

That’s it for Twitter.  No code successfully so far!  So now every 4 hours this will check for a new tweet from that account.  Now let’s do something with it!  In Jessica’s scenario we need to look at the tweet and act upon it only if a specific condition was met.  So let’s use that little “+” symbol on the designer and add a new action.  Search for 'Condition’ and you will see ‘Control’ come up as an option…select that, then you will see the Condition connector…choose that.  The condition connector gives us a simple decision tree: what is the condition, what do you want to do if true, what do you want to do if false:

Screenshot of Condition action connector

In the condition area where it says ‘Choose a value’ when you click in to there, data from the previous trigger will be made available to you and you can see all the details it exposes!  We will scroll and look for Tweet text and select that.  Change the oeprator to ‘contains’ and type in ‘suspended’ as the value.  It should look like this:

Screenshot of Condition action connector

Now we know that the tweet is telling us something about suspending…but Jessica wants to know if she has to move her car for tomorrow.  Let’s add another condition to now check to see if it contains ‘tomorrow’ in the text.  We follow the same steps in creating a new condition trigger and connecting it. 

At this point we have a nested condition.  Could we have put them in the same one?  Probably, but I’m just following similarly Jessica’s flow. 

It should look like this:

Screenshot of Condition Action connector

Now we know if both of those are true we need to send a text message.  Click the ‘Add an action’ button in the True condition and search for Twilio and select the ‘Send a Text Message’ action.  This will add the provided Twilio connector which provides this functionality (and more).  Similarly like twitter you will see it and after selecting have to authenticate to your account to get the credentials.

Screenshot of Twilio search for connector

After doing that you now simply enter the details of your text message.  For Twilio the From number must be your account SMS number unless you have premium services that enables you to do something more.  If you try to get fancy without premium services from them, this will fail.  Don’t get fancy…we’re just moving cars across the street remember?  Enter the text you want to send and to the phone number you want to send it to…done!

Screenshot of Twilio connector

Now on the false conditions we do still have to tell the Logic App what to do.  In these cases, unless you want to do more, again add an action and choose System, then look for ‘Terminate’ – it’s a simple action that basically just stops the flow and can log a message.  I configured mine like this on BOTH false conditions:

Screenshot of Terminate action connector

That’s it, I’m done.  No code.  This took me longer to write this post then it did to actually do the Logic App the first time.  Now I waited.  And waited.  And waited.  I completed the logic app right after reading Jessica’s article and wanted to ‘naturally’ test this with the real deal tweets.  But no parking regulations were suspended.  My logs looked like this:

Screenshot of Azure log files

UNTIL A FEW DAYS AGO!  My phone buzzed, I looked down and BOOM:

Screenshot of SMS text message stating 'NYC Alt Parking Suspended Tomorrow'

Animated GIF image of people happily dancing

I wonder if Jessica got a text message too!  I was so happy and I don’t even live in NYC or have to worry about moving my car to a different side of the street!  The logs of Logic Apps are pretty cool as well and also graphically follow your flow and show you input/output state along the way:

Screenshot of Logic App log

So with no code and only a few steps to authenticate to Twitter and Twilio, I was able to use only a browser and complete the same task.  Did I win Name That Tune?  Who cares…doing software isn’t a competition, it’s fun and we get to use the tools and technology we feel most productive with.  For me, this was just a gut reaction to see if could be done as easily as I thought and indeed it could.  So yeah I won :-D.

Check out more about the pieces I used to put this together and get your custom logic apps working:

Hope this helps!

Making my NuGet Package more trusted with signing and doing it all in Azure DevOps Pipelines

Like most things in life, this all started with someone’s message on Twitter.

You can code-sign a NuGet Package?  I don’t know why I didn’t know that other than I figured I had no idea that I should care or have even given a second thought to it.  But Phil’s article and subsequent discussion on Twitter made me just realize I should take a look at the flow.  After all more sage wisdom from Phil kicked me over the edge:

You’re right Phil, and how can you argue with that forehead…so let’s do this. 

What is NuGet? NuGet is a package management system that was primarily developed for .NET developers and has now become a de-facto package/release mechanism for that ecosystem.  What npm is to Node.js developers, NuGet is to .NET developers.  More info at https://www.nuget.org

I’ve got a little library for helping .NET developers be more productive with creating Alexa apps, Alexa.NET.  When I started this project I used to just have this on my local box and would build things using Visual Studio and manually upload the NuGet package.  Then people made fun of me.  And I ate my sorrows in boxes of Moon Pies.  Luckily I work with a bunch of talented folks and helped me see the light in DevOps and helped me establish a CI/CD pipeline using Azure DevOps.  Since then I’ve got my library building, a release approval flow, automated packaging/publishing to the NuGet servers.  I simply just check-in code and a new version is released.  Perfect.  Now I just want to add code-signing to the package.  Naturally I do what every professional developer does and Google’d went to read the docs about code signing NuGet packages.  Luckily there is some pretty good documentation on Signing NuGet Packages

The first thing you need is a code-signing certificate.  There are many providers of these and different prices so pick your preferred provider.  I chose to use DigiCert for this one but have used other providers in the past.  The process for getting a code-signing cert is a bit more than just an average SSL certificate so be sure to follow the steps carefully.  Once you have that in place, export the DER and PFX versions as you will need both of these for this process.  Your provider should provide instructions on how to do this for you.

Next up was to modify my Azure DevOps Pipeline.  I do my NuGet activity in a Release pipeline after a successful build and an approval step to actually complete the deployment.  My simple release pipeline looks like this:

Screenshot of Azure DevOps NuGet Push definition

The signing is provided by the NuGet CLI and so I just needed to add another task to this flow right?  I added another one in and was going to just choose the ‘sign’ command as the configured option.  Well, the ‘sign’ command isn’t a selectable option in the task.  There is a request to make this one of the default options for the Azure Pipeline Task right now but it isn’t in there yet.  So for this we will use the ‘custom’ option which allows us to pass in any command and args.  The docs already told me the commands that I would need: a certificate file being the minimum I would have to have.  Hmm, how am I going to have a certificate file in my CD pipeline?!  As it turns out there is a secure file storage in Azure Pipelines I can use! This allows me to upload a file that I can later reference in a pipeline using an argument.  Remember that PFX file we exported?  In your DevOps project under Pipelines there is a ‘Library’ menu option.  Going there takes you to where you can upload files and I uploaded my PFX file there:

Screenshot of Azure DevOps Library

The next thing I need to do is also provide my password for that exported PFX file (you did export it with a password right!).  To do this I made use of variable groups in Azure DevOps, created a group called CertificateValues and added my name/value pair there, marking the value as a secret.  As a variable group I can ‘link’ this group to any build/release definition without explicitly having the variable in those definitions.  This is super handy to share across definitions.  You can now link to an Azure KeyVault for secrets (more to come on that in a part 2 blog post here).  I’ve got my code signing cert (PFX) and my certificate password stored securely.  With these two things now I’m ready to continue on my definition.

Now how will I get the file from the secure storage?!  As I read in the docs, there is a Download Secure File task that I can add to my pipeline.  The configuration asks me what file to use and then in the Reference Name of the Output Variables area I give it a name I can use, in this case ‘Certificate’:

Screenshot of Azure DevOps Download Secure File

This variable name allows me to use it later in my definitions as $(Certificate.secureFilePath) so I don’t have to fiddle around guessing where it downloaded to on the agent machine.  Now that we have that figured out, let’s move back to the signing task…remember that ‘custom’ one we talked about earlier.  In the custom task I specify in the Command and Arguments section the full command + arguments I need according to the docs.  My full definition looks like this:

sign $(System.ArtifactsDirectory)\$(Release.PrimaryArtifactSourceAlias)\drop\*.nupkg 
    -CertificatePath $(Certificate.secureFilePath) 
    -CertificatePassword $(CertificatePassword)  
    -Timestamper http://timestamp.digicert.com

To explain a bit I’m using some pre-defined variables System.ArtifactsDirectory and Release.PrimaryArtifactSourceAlias to help build the path to where the drop folder is on the agent machine.  The others are from the secure files (Certificate.secureFilePath) and variable group (CertificatePassword) previously defined.  These translate to real values in the build (the secret is masked in the logs as shown below) and complete the task. 

Screenshot of Azure DevOps release definition

Here was my log output from today in fact:

2019-04-04T19:10:44.4785575Z ##[debug]exec tool: C:\hostedtoolcache\windows\NuGet\4.6.4\x64\nuget.exe
2019-04-04T19:10:44.4785807Z ##[debug]arguments:
2019-04-04T19:10:44.4786015Z ##[debug]   sign
2019-04-04T19:10:44.4786248Z ##[debug]   D:\a\r1\a\_Alexa.NET-master\drop\*.nupkg
2019-04-04T19:10:44.4786476Z ##[debug]   -CertificatePath
2019-04-04T19:10:44.4786687Z ##[debug]   D:\a\_temp\timheuer-digicert.pfx
2019-04-04T19:10:44.4786916Z ##[debug]   -CertificatePassword
2019-04-04T19:10:44.4787190Z ##[debug]   ***
2019-04-04T19:10:44.4787449Z ##[debug]   -Timestamper
2019-04-04T19:10:44.4787968Z ##[debug]   http://timestamp.digicert.com
2019-04-04T19:10:44.4789380Z ##[debug]   -NonInteractive
2019-04-04T19:10:44.4789939Z [command]C:\hostedtoolcache\windows\NuGet\4.6.4\x64\nuget.exe sign D:\a\r1\a\_Alexa.NET-master\drop\*.nupkg -CertificatePath D:\a\_temp\timheuer-digicert.pfx -CertificatePassword *** -Timestamper http://timestamp.digicert.com -NonInteractive
2019-04-04T19:10:52.6357013Z 
2019-04-04T19:10:52.6357916Z 
2019-04-04T19:10:52.6358659Z Signing package(s) with certificate:
<snip to remove cert data>
2019-04-04T19:10:52.6360408Z Valid from: 4/4/2019 12:00:00 AM to 4/7/2020 12:00:00 PM
2019-04-04T19:10:52.6360664Z 
2019-04-04T19:10:52.6360936Z Timestamping package(s) with:
2019-04-04T19:10:52.6361268Z http://timestamp.digicert.com
2019-04-04T19:10:52.6361576Z Package(s) signed successfully.

Done!  Some simple added tasks and reading a few docs to get me having a signed NuGet package.  Now re-reading the docs on signed packages I have to upload my certificate to my NuGet profile to get it to be recognized.  This time I only need to provide the DER export.  Once provided and my package is published, I get a little badge next to the listing showing me that this is a signed package:

Screenshot of NuGet version history listing

This was a good exercise in helping me learn a few extra steps in Azure DevOps working with files and custom task variables.  Immediately as I was doing this, my friend Oren Novotny couldn’t help but chastise me for this approach. 

So stay tuned for a secondary approach using Azure KeyVault completely to complete this without having to upload a certificate file.

Microsoft announced Build 2019 and you won’t believe what they chose to do!

Last week, the Microsoft Build team announced the dates of the conference as well as announced that there is a Call for Speakers.  Yes, that’s right, the premier MIcrosoft-provided developer event is asking the public to be a part of the show!

I was pretty excited about this as one who has been involved in the Professional Developer’s Conference (PDC), the previous name for this conference, and Build for the past number of years.  I shared on Twitter to get excited too!

After that I got a few questions about the process.  I should be clear that I don’t own the process, have no influence over your submission, probably don’t even have a say in the selection of sessions, but generally want to see people try and get excited about the conference and sharing your passion to others on a broader scale opportunity than usual.  A few on my team have discussed some of this topic of ‘what’ should people submit as well.  I’ll try to change your mind and share my opinion and some thoughts from some colleagues.

First and foremost: TELL A STORY!

I’ve been too guilty myself of being the one to share just all the ‘stuff’ my team did over time.  Sometimes these can be fun sharing all the hard work the team put in to releasing a product.  These ‘lap around my features’ sessions work well for presenters, but I’ve learned over time may not be the best for the audience.  When all I’m doing is telling you about a cool tech feature I’m doing a disservice to your time and the product capabilities usually.  I should be telling you how to solve a problem, how to innovate in your project/process, or how to make you more productive.  To do this I need to think of you, dear reader/attendee, and not me/my team/my product.  So to me, this is the best advice I can give you…put yourself in an attendee perspective and think about what you can share that will help them get to their ‘next,’ whatever that may be.

Some thoughts on how to do this…

  • How does your title read?  Is it “New network settings for Azure Virtual Machines” or could it be “Be smart and secure your cloud networks” – both probably end up showing a similar tech aspect, but the second focuses more on the problem, putting yourself in the audience shoes.  Think of titles as the problem question.  And hey, I often give advice as well to ‘think clickbait’ – some people hate that but it puts you in a mindset to entice the reader/user.  “Migrating your APIs to serverless infrastructure will save you time and money, I’ll prove it!"
  • Brief but specific abstract.  Your abstract shouldn’t be full of buzzwords and non-sentences.  If it reads like an analyst brochure, re-think it.  Start with leading off your title.  Someone is reading the abstract because the title grabbed them.  Get more practical in the first 1-2 sentences.  Keep it brief between there explaining what you’ll show, then end with what THEY will get out of it.  Some call this a ‘call to action’ but think about it in those terms like When you leave you’ll know how to save time deploying your containers to the cloud and have more time for code!
  • Think of the audience.  I said this already but sincerely think of them.  Most of the time I’ve seen conference sessions think of the speaker.  *I* want to show you something.  *I* know better than you so listen to me.  Flip that.  Put yourself in the other seat and tell them how you are going to help them.  If you tell me you’re going to help me in my job in a way that entices me in your language, you’re speaking to me…I’m relating more.  I may not know I need to figure out my container clusters in a specific node configuration…but I do know that I have a problem managing my apps at scale, for example.

These aspects speak both to the inevitable session but also to the Call for Speakers selection team.  The Build team (and other conferences) will receive lots of submissions.  Your title will be the first thing that needs to grab attention.  Then your first 2 sentences.  Telling a story through those helps be unique and specific to help someone learn and not come across as you wanting to ‘tell them stuff.’  Niall Merrigan has a good post about the process that he has been a part of that touches on some of these.  It’s a helpful read from a different perspective.  And different perspectives matter!  So another pro-tip…run your idea by a few that might be your target audience.  That will help!

So with all that said, good luck and submit an idea.  We’ve already got a LOT of submissions.  I have no idea how many will be chosen from the public group, but force the team to be in a hard place to choose the best and maybe expand the number of them…submit well thought out sessions!  Best of luck to you and I look forward to seeing you at Build 2019!

I hope this helps!

Microsoft Ignite for .NET Developers

This was the first time in a long time (I think maybe 10+ years) that I didn’t go to TechEd…err, I mean Ignite :-).  Was I sad to miss seeing old friends and hearing about TwoWay binding woes?  Sure.  Did I miss Orlando in the summer…nope (I get, it’s an easy shot, but yeah no).  I watched from afar though and found some really great stuff for .NET developers on different spectrums.  Ignite is Microsoft’s opportunity to share what is happening in the tech now versus only focus on futures.  I think for .NET developers we long for the ‘vNext’ of everything, but there is a lot of great things happening NOW!  And if you are a .NET developer who has been tip-toeing into the cloud development area, Ignite was a great place to start learning.

Here’s a list of things that I found for .NET Developers from Ignite. 

If you watch no-other ones, make sure to review these two higher-level sessions:

Aside from these broader sessions, here’s a list that might be relevant to you, dear .NET developer:

Lots of great stuff and maybe I’m missing a few.  Be sure to check out all the stuff from Channel 9 as well where a broad set of topics were covered in-between sessions with experts that were there.  Great smaller nuggets of knowledge that you should check out…here they are: Channel 9 Live at Ignite.

Another huge thing announced at Ignite was Microsoft Learn!

logo for Microsoft Learn

Microsoft Learn is a new online way of learning a bunch of new technology.  Through guided learning paths you complete modules and earn points and achievements.  It’s been fun a bit to compete with some co-workers on who can achieve the most badges!  One of the great things also is that you don’t need much to get started.  For the Azure content you do all the tasks IN THE LESSON through the cloud shell environment and with a free sandbox (no sign-up, no credit card)!  Check it out and see how many achievements you can get this week.

Sorry I missed some of the ‘hallway’ sessions (which are the best), but I’ll be looking for you all at the next one!  What were your favorite sessions?

Hope this helps!

Using machine learning to tune your SQL database in Azure

I’m presently working on posting my insight in moving a recent app of mine from an on-premise (colocated server) server to the Azure cloud.  My app is a pretty typical (and OLD) ASP.NET app with a SQL Server database backend.  There was some interesting things I learned in moving the web app portion to Azure App Service, but I’ll save that for a later post…this one is about Azure SQL Server.

My database was actually a SQLExpress database that has been humming along for a while.  It’s also an older schema and a typical relational database system.  The first step for me was to ensure I could move my data before I moved the site…I wanted a full move to a cloud platform.  There are a few ways of migrating databases to Azure as noted in this blog post Differentiating Microsoft’s Database Migration Tools and Services.  Recently one of our Cloud Developer Advocates, Scott Cate, demonstrated the newest full migration strategy, Data Migration Service (DMS), at the Azure Red Shirt Dev Tour.  Because this isn’t generally available I didn’t want to use it and as well my database didn’t warrant the need for managed instance features.  So I went with the Data Migration Assistant tool.

First was to get the tool and install it on my source server.  Because this is an on-prem server I just logged in remotely (RDP) as an admin.  You can choose to first run an assessment, but for me I went crazy and just wanted to migrate (don’t worry, that actually runs an assessment first as well):

After connecting to my SQL db instance I select the database I want to migrate.

NOTE: Use the “trust server certificate” checkbox when doing this migration from local db or you will see some failures in trying to connect to Azure.

After this I need to choose the destination and I can either select an already-created Azure SQL database or create one within my Azure subscription.  This link will launch instructions on how to create a new Azure SQL database on your subscription using the Azure Portal.  You will want to select your server size, etc. based on your needs.  There is some pricing guidance on the selections to help you understand your cost.  After this, return to the tool, enter the server you just created (or already had) and authenticate using your credentials for the server.  Then choose which database is the target for the migration:

Then the next step will show you the assessment and flag things that may need attention.  You need to examine these to assess whether they will be impactful to your app and either accept the script or not.  Once done you have 2 more steps: Deploy Schema and then (assuming that was successful) Migrate Data.  For me, this was rather quick and it was done.  I verified the data and was good to go!

Post-migration Tuning

After deploying the database and site I made sure that on the database I turned on the Automatic Tuning feature provided to me as a service for hosting in Azure:

And then I went away.  Immediately after a few days I returned to see some automatic tuning being done and analyzed.  Azure had analyzed my database under real conditions and made recommendations to actually alter the database to improve performance.  This is then automatically applied if Azure determines it will benefit my performance.  Here were the recommendations:

And notice the determination of impact for one of them:

You’ll see that Azure’s machine learning was smart enough to realize that one of the recommendations wasn’t going to improve (in fact it assessed it would actually regress a query) and decided not to apply the initial tuning recommendation.  Pretty awesome.  Taking a look at my performance profile of the database you can tell very quickly when these recommendations were applied:

This is awesome.  I’ve got some tuning still to go, but thankfully Azure did all the hard work of helping me identify the performance bottlenecks of my database, suggest and analyze some automatic tuning it could do, but also still give me all the data I need to further analyze troublesome queries.

You can learn more about this feature in a recent Channel 9 video talking about this:

It really is an amazing feature and combined with the easy migration, I’m really excited about moving this app to Azure App Service + Azure SQL!

Hope this helps! 

Build 2017 UI Recap

Well that was fun!  It was really exciting to share with the world what our team has been working on in designing and developing over the past few years with regard to Windows UI platform advancements.  Build 2017 was a culmination of a lot of efforts across the company in various areas, but for UI it was the introduction of our evolution of design, the Fluent Design System.  This represents a wave of UI innovations over time, with Build 2017 showing the first views of Wave 1.  There was a lot of great buzz about Fluent, but for a great introduction be sure to check out my colleague Paul Gusmorino’s session introducing the design system:

Of course as developers sometimes we wince at the word ‘design’ because we don’t have the skills, maybe don’t understand it, or want to ensure we can achieve it with maximum ROI of our own developer time!  We agree!  In defining the Fluent Design System, we ensured that a lot of these new innovations are ‘default’ in the platform.  Starting now with the Fall Creator’s Update Insider SDKs you can start seeing some of these appear in the common controls.  When you use the common controls as-is, you will get the best of Fluent incorporated into your app.  James Clarke joined Paul later to explain and demonstrate this in practice showing how the new (and some existing) common controls take this design system into account and help you get it by default:

In addition to what we are doing *now* we also wanted to share what is on the horizon.  I was able to join Ashish Shetty at Build and talk about what is new in XAML and Composition platform areas for developers.  We shared more of the ‘default’ that is exhibited in the common controls but also explained some of the ‘possible’ in the platform that you can achieve with great improvements to our animation system.  We also shared the vision for the future in this space around semantic animations and vector shape micro-animations.  Check out our session on this area:

We had so much to talk about that I wasn’t able to show the simplicity of enabling the pull-to-refresh pattern in the new controls area.  Not wanting you to feel ripped off, I recorded a quick demo of a few of the things we weren’t able to demo.  Take a look here at my impromptu demo insert for you!

There is a lot of great new things coming in the Windows UI platform area for UWP:

  • NavigationView
  • ParallaxView
  • RefreshContainer
  • SwipeContainer
  • TreeView
  • ColorPicker
  • RatingsControl
  • Improved text APIs: CharacterRecieved, CharacterCasing, IsTrimmed
  • Improved input APIs like PreviewInput
  • Implicit animations
  • Connected animations improvements for ListViewBase
  • Advanced color and HDR for Image
  • SVG support for Image
  • Keytips support for XAML
  • ContentDialog and MenuFlyout improvements
  • Context menu support everywhere
  • UI analysis and Edit-and-continue in Visual Studio
  • Narrator developer mode
  • and more!

It is so great to be a part of this latest release and continue to deliver value (hopefully) to you, our developer customer.  Please be sure to let us know how you are using these new improvements and the Fluent Design System.  Share your creations with us at @windowsui so we can share with others as well!

We also announced a vision for defining a common dialect for UI everywhere around XAML.  We call this XAML Standard and are drafting a v1 specification now.  We will want your input on this and have established an open process to encourage community collaboration.  Please join the conversation at http://aka.ms/xamlstandard.  This is at very early stages but with your help we will establish the right fundamentals first and evolve over time.  Getting the core right is critically important…you can’t unify on a set of control APIs if the foundation isn’t solid and makes sense.  In addition to this, .NET Standard 2.0 for UWP was announced as well and is a HUGE advancement for .NET developers writing apps for UWP.  Oh no big deal, just about 20K more APIs you have access to now.  Yowza.  Listen to Scott Hunter, Miguel and myself talk about these areas on Channel 9:

I’m excited to see the creativity unleased by our developer community.  Thanks for letting me be a small part of it!

Implementing a type converter in UWP XAML

Verbose XAML, we all love it right?  What?!  You don’t like writing massive amounts of angle brackets to get to define certain properties?  I mean who doesn’t love something like this:

<MapControl>
    <MapControl.Center>
        <Location>
            <Location.Latitude>47.669444</Location.Latitude>
            <Location.Longitude>-122.123889</Location.Longitude>
        </Location>
    </MapControl.Center>
</MapControl>

What’s not to love there?  Oh I suppose you prefer something like this?

<MapControl Center="47.669444,-122.123889" />

In the XAML dialect this is what we refer to as a ‘type converter’ or more affectionately at times ‘string to thing’ as the declarative markup is just a string representation of some structure.  In WPF and Silverlight this was implemented through requiring to use the System.ComponentModel.TypeConverter class model where you would attribute your class with a pointer to an implementation of TypeConverter that would override the common things you need, most of the time ConvertFrom capabilities.

In UWP where we currently could not rely on the exact same implementation of System.ComponentModel.TypeConverter as it is not a part of the API exposure to UWP apps at this time as well as being a .NET concept which wouldn’t be available to other WinRT developers.  In looking at ways to achieve the same primary scenario, we can now look at the Creator’s Update to deliver the functionality for us.  In the markup compiler for Creator’s Update we now leverage the metadata CreateFromString attribute in WinRT to generate the correct metdata to do the conversion.  The responsibility lies in the owner of the class (looking at you ISVs as you update) to add this metadata capabilities.

NOTE: To enable this capability, the consuming app must currently have minimum target to the Creator’s Update.

Let’s use an example following my pseudo map control I used above.  Here is my class definition for my MyMap control

using Windows.UI.Xaml.Controls;

namespace CustomControlWithType
{
    public class MyMap : Control
    {
        public MyMap()
        {
            this.DefaultStyleKey = typeof(MyMap);
        }

        public string MapTitle { get; set; }
        public Location CenterPoint { get; set; }
    }
}

Notice it has a Location type.  Here’s the definition of that type:

using System; namespace CustomControlWithType { public class Location { public double Latitude { get; set; } public double Longitude { get; set; } public double Altitude { get; set; } } }

Now without a type converter I can’t use the ‘string to thing’ concept in markup…I would have to use verbose markup.  Let’s change that and add an attribute to my Location class, and implement the conversion function:

using System;

namespace CustomControlWithType
{
    [Windows.Foundation.Metadata.CreateFromString(MethodName = "CustomControlWithType.Location.ConvertToLatLong")]
    public class Location
    {
        public double Latitude { get; set; }
        public double Longitude { get; set; }
        public double Altitude { get; set; }

        public static Location ConvertToLatLong(string rawString)
        {
            string[] coords = rawString.Split(',');
            
            var position = new Location();
            position.Latitude = Convert.ToDouble(coords[0]);
            position.Longitude = Convert.ToDouble(coords[1]);

            if (coords.Length > 2)
            {
                position.Altitude = Convert.ToDouble(coords[2]);
            }

            return position;
        }
    }
}

As you can see in the highlighted lines, I added two things.  First I added an attribute to my class to let it know that I have a CreateFromString method and then provided the fully qualified name to that method.  The second obvious thing is to implement that method.  It has to be a public static method and you can see my simple example here.

Now when using the MyMap control I can specify the simpler markup:

And the result would be converted and my control that binds to those values in it’s template are able to see them just fine

Yes, my control is quite lame but just meant to illustrate the point.  The control binds to the CenterPoint.Latitude|Longitude|Altitude properties of the type.

If you are in this scenario of providing APIs that are used in UI markup for UWP apps, try this out and see if it adds delighters for your customers.  I’ve uploaded the full sample of this code to my GitHub in type-converter-sample if you want to see it in full.  Hope this helps! 

Write your Amazon Alexa Skill using C# on AWS Lambda services

After a sick day a few weeks ago and writing my first Alexa Skill I’ve been pretty engaged with understanding this voice UI world with Amazon Echo, Google Home and others.  It’s pretty fun to use and as ‘new tech’ it is pretty fun to play around with.  Almost immediately after my skill was certified, I saw this come across my Twitter stream:

I had spent a few days getting up-to-speed on Node and the environment (I’ve been working in client technologies for a long while remember) and using VS Code, which was fun.  But using C# would have been more efficient for me (or so I thought).  AWS Lambda services just announced they will support C# as the authoring environment for a Lambda service.  As it turns out, the C# Lambda support is pretty general so there is not compatibility in the dev experience for creating a C# Lambda backing a skill as there presently is for Node.JS development…at least right now.  I thought it would be fun to try and was eventually successful, so hopefully this post finds others trying as well.  Here’s what I’ve learned in the < 4 hours (I time-boxed myself for this exercise) spent trying to get it to work.  If there is something obvious I missed to make this simpler, please comment!

The Tools

You will first need a set of tools.  Here was my list:

With these I was ready to go.  The AWS Toolkit is the key here as it provides a lot of VS integration that will help make this a lot easier.

NOTE: You can do all of this technically with VS Code (even on a Mac) but I think the AWS Toolkit for VS makes this a lot simpler to initially understand the pieces and WAY simpler in the publishing step to the AWS Lambda service itself.  If there is a VS Code plugin model, that would be great, but I didn’t find one that did the same things here.

Armed with these tools, here is what I did…

Creating the Lambda project

First, create a new project in VS, using the AWS Lambda template:

This project name doesn’t need to map to your service/function names but it is one of the parameters you will set for the Lambda configuration, so while it doesn’t entirely matter, maybe naming it something that makes sense would help.  We’re just going to demonstrate a dumb Alexa skill for addition so I’m calling it NumberFunctions.

NOTE: This post isn’t covering the concepts of an Alexa skill, merely the ability to use C# to create your logic for the skill if you choose to use AWS Lambda services.  You can, of course, use your own web server, web service, or whatever hosted on whatever server you’d like and an Alexa skill can use that as well. 

Once we have that created you may see the VS project complain a bit.  Right click on the project and choose to restore NuGet packages and that should clear it up.

Create the function handler

The next step is to write the function handler for your skill.  The namespace and public function name matter as these are also inputs to the configuration so be smart about them.  For me, I’m just using the default namespace, class and function name that the template provided.  The next step is to gather the input from the Alexa skill request.  Now a Lambda service can be a function for anything…it is NOT limited to serve Alexa responses, it can do a lot more.  But this is focused on Alexa skills so that is why I’m referring to this specific input.  Alexa requests will come in the form of a JSON payload with a specific format.  Right now if you accept the default signature of the function handler of string, ILambdaContext it will likely fail due to issues you can read about here on GitHub.  So the best way is to really understand that the request will come in with three main JSON properties: request, version, and session.  Having an object with those properties exposed will help…especially if you have an object that understands how to automatically map the JSON payload to a C# object…after all that’s one of the main benefits of using C# is more strongly-typed development you may be used to.

Rather than create my own, I went on the hunt for some options.  There doesn’t exist yet an Alexa Skills SDK for .NET yet (perhaps that is coming) but there are two options I found.  The first seemed a bit more setup/understanding and I haven’t dug deep into it yet, but might be viable.  For me, I just wanted to basically deserialize/serialize the payload into known Alexa types.  For this I found an Open Source project called Slight.Alexa.  This was build for the full .NET Framework and won’t work with the Lambda service until it was ported to .NET Core, so I forked it and moved code to shared and created a .NET Core version of the library. 

NOTE: The port of the library was fairly straight forward sans for a few project.json things (which will be going away) as well as finding some replacements for things that aren’t in .NET Core like System.ComponentModel.DataAnnotations.  Luckily there were replacements that made this simple.

With my fork in place I made a quick beta NuGet package of my .NET Core version so I could use it in my Lambda service (.NET Core projects can’t reference DLLs so they need to be in NuGet packages).  You can get my beta package of this library by adding a reference to it via your new Lambda project:

This now gives me a strongly-typed OM against the Alexa request/response payloads.  You’ll also want to add a NuGet reference to the JSON.NET library (isn’t every project using this now…shouldn’t it be the default reference for any .NET project???!!!).  With these both in place now you have what it takes to process.  The requests for Alexa come in as Launch, Intent and Session requests primarily (again I’m over-simplifying here but for our purposes these are the ones we will look at).  The launch request is when someone just launches your skill via the ‘Alexa, open <skill name>’ command.  We’ll handle that and just tell the user what our simple skill does.  Do do this, we change the function handler input from string to SkillRequest from our newly-added Slight.Alexa.Core library we added:

public string FunctionHandler(SkillRequest input, ILambdaContext context)

Because SkillRequest is an annotated type the library knows how to map the JSON payload to the object model from the library.  We can now work in C# against the object model rather than worry about any JSON path parsing.

Working with the Alexa request/response

Now that we have the SkillRequest object, we can examine the data to understand how our skill should respond.  We can do this by looking at the request type.  Alexa skills have a few request types that we’ll want to look at.  Specifically for us we want to handle the LaunchRequest and IntentRequest types.  So we can examine the type and let’s first handle the LaunchRequest:

Response response;
IOutputSpeech innerResponse = null;
var log = context.Logger;

if (input.GetRequestType() == typeof(Slight.Alexa.Framework.Models.Requests.RequestTypes.ILaunchRequest))
{
    // default launch request, let's just let them know what you can do
    log.LogLine($"Default LaunchRequest made");

    innerResponse = new PlainTextOutputSpeech();
    (innerResponse as PlainTextOutputSpeech).Text = "Welcome to number functions.  You can ask us to add numbers!";
}

You can see that I’m just looking at the type and if a LaunchRequest, then I’m starting to provide my response, which is going to be a simple plain-text speech response (with Alexa you can use SSML for speech synthesis, but we don’t need that right now).  If the request is an IntentRequest, then I first want to get out my parameters from the slots and then execute my intent function (which in this case is adding the parameters):

else if (input.GetRequestType() == typeof(Slight.Alexa.Framework.Models.Requests.RequestTypes.IIntentRequest))
{
    // intent request, process the intent
    log.LogLine($"Intent Requested {input.Request.Intent.Name}");

    // AddNumbersIntent
    // get the slots
    var n1 = Convert.ToDouble(input.Request.Intent.Slots["firstnum"].Value);
    var n2 = Convert.ToDouble(input.Request.Intent.Slots["secondnum"].Value);

    double result = n1 + n2;

    innerResponse = new PlainTextOutputSpeech();
    (innerResponse as PlainTextOutputSpeech).Text = $"The result is {result.ToString()}.";

}

With these in place I can now create my response object (to provide session management, etc.) and add my actual response payload, using JSON.NET to serialize it into the correct format.  Again, the Slight.Alexa library does this for us via that annotations it has on the object model.  Please note this sample code is not robust, handles zero errors, etc…you know, the standard ‘works on my machine’ warranty applies here.:

response = new Response();
response.ShouldEndSession = true;
response.OutputSpeech = innerResponse;
SkillResponse skillResponse = new SkillResponse();
skillResponse.Response = response;
skillResponse.Version = "1.0";

return skillResponse;

I’ve now completed my function, let’s upload it to AWS!

Publishing the Lambda Function

Using the AWS Toolkit for Visual Studio this process is dead simple.  You’ll first have to make sure the toolkit is configured with your AWS account credentials which are explained here in the Specifying Credentials information.  Right click on your project and choose Publish to AWS Lambda:

You’ll then be met with a dialog that you need to choose some options.  Luckily it should be pretty self-explanatory:

You’ll want to make sure you choose a region that has the Alexa Skill trigger enabled.  I don’t know how they determine this but the US-Oregon one does NOT have that enabled, so I’ve been using US-Virginia and that enables me just fine.  The next screen will ask you to specify the user role (I am using the basic execution role).  If you don’t know what these are, re-review the Alexa skills SDK documentation with Lambda to get started there.  These are basically IAM roles in AWS that you have to choose.  After that you click Upload and done.  The toolkit takes care of bundling all your stuff up into a zip, creating the function (if you didn’t already have one – as if you did you can choose it from the drop-down to update an existing one) and uploading it for you.  You can do all this manually, but the toolkit really, really makes this simple.

Testing the function

After you publish you’ll get popped the test window basically:

This allows you to manually test your lambda.  In the pre-configured requests objects you can see a few Alexa request object specified there.  None of them will be the exact one you need but you can start with one and manually modify it easily to do a quick test.  If you notice my screenshot I modified to specify our payload…you can see the payload I’m sending here:

{
  "session": {
    "new": false,
    "sessionId": "session1234",
    "attributes": {},
    "user": {
      "userId": null
    },
    "application": {
      "applicationId": "amzn1.echo-sdk-ams.app.[unique-value-here]"
    }
  },
  "version": "1.0",
  "request": {
    "intent": {
      "slots": {
        "firstnum": {
          "name": "firstnum",
          "value": "3"
        }, "secondnum" : { "name": "secondnum", "value": "5" }
      },
      "name": "AddIntent"
    },
    "type": "IntentRequest",
    "requestId": "request5678"
  }
}

That is sending an IntentRequest with two parameters and you can see the response functioned correctly!  Yay!

Of course the better way is to use Alexa to test it so you’ll need a skill to do that.  Again, this post isn’t about how to do that, but once you have the skill you will have a test console that you can point to your AWS Lambda function.  I’ve got a test skill and will point it to my Lambda instance:

UPDATE: Previously this wasn’t working but thanks to user @jpkbst in the Alexa Slack channel he pointed out my issue.  All code above updated to reflect working version.

Well I had you reading this far at least.  As you can see the port of the Slight.Alexa library doesn’t seem to quite be working with the response object.  I can’t pinpoint why the Alexa test console feels the response is valid as the schema looks correct for the response object.  Can you spot the issue in the code above?  If so, please comment (or better yet, fix it in my sample code).

Summary (thus far)

I set out to spend a minimal amount of time getting the C# Lambda service + Alexa skill working.  I’ve uploaded the full solution to a GitHub repository: timheuer/alexa-csharp-lambda-sample for you to take a look at.  I’m hopeful that this is simple and we can start using C# more for Alexa skills.  I think we’ll likely see some Alexa Skills SDK for .NET popping up elsewhere as well. 

Hope this helps!

Making circular images in XAML

A long while back it seemed like the new cool app thing to do was to represent people/avatars in circles instead of the squares (or squares with rounded corners).  I made a snarky comment about this myself almost exactly 2 years ago when I noticed that some apps I was using at the time switched to this:

Now since this seems to be a popular trend and people are doing it I’ve thought XAML folks have figured it out.  However I’ve seen enough questions and some people trying to do a few things that make it more complex that I thought I’d drop a quick blog post about it.  I’ve seen people trying to do profile pic upload algorithms that clip the actual bitmap and save on disk before displaying it to people stacking transparent PNG ‘masking’ techniques.  None of this is needed for the simplest display.  Here you go:

<Ellipse Width="250" Height="250">
    <Ellipse.Fill>
        <ImageBrush ImageSource="ms-appx:///highfive.jpg" />
    </Ellipse.Fill>
</Ellipse>

That’s it.  You’ll see that Line 3 shows us using an ImageBrush as the fill for an Ellipse.  Using an Ellipse helps you get the precise circular drawing clip without having pixelated edges or anything like that.  The above would render to this image as the example in my app:

Circular image

Now while this is great, using an ImageBrush doesn’t give you the automatic decode-to-render-size capability that was added in the framework in Windows 8.1.

NOTE: This auto decode-to-render-size feature basically only decodes an Image to the render size even if the image is larger.  So if you had a 2000x2000px image but only displayed it in 100x100px then we would only decode the image to 100x100px size saving a lot of memory.  The standard Image element does this for you.

For most apps that control your image sources, you probably are already saving images that are only at the size you are displaying them so it may be okay.  However for apps like social apps or where you don’t know where the source is coming from or your app is NOT resizing the image on upload, etc. then you will want to ensure you save memory by specifying the decode size for the ImageBrush’s source specifically.  This is easily done in markup using a slightly more verbose image source syntax.  Using the above example it would be modified to be:

<Ellipse Width="250" Height="250">
    <Ellipse.Fill>
        <ImageBrush>
            <ImageBrush.ImageSource>
                <BitmapImage DecodePixelHeight="250" DecodePixelWidth="250" UriSource="ms-appx:///highfive.jpg" />
            </ImageBrush.ImageSource>
        </ImageBrush>
    </Ellipse.Fill>
</Ellipse>

No real change other than telling the framework what the decode size should be in Line 5 using DecodePixelHeight and DecodePixelWidth.  The rendering would be the same in my case.  This tip is very helpful to when you are most likely going to be displaying a smaller image than the source and not the other way around. 

So there you go.  Go crazy with your circular people representations!  Hope this helps.


This work is licensed under a Creative Commons Attribution By license.

Build 2015 recap for XAML and native apps

Wow, what a week.  I have to say even as employees of Microsoft, we get surprised when we go to our conferences and see some of the bigger announcements.  There are things that are being worked on that are new or just in different divisions that we’re not focused on.  This past week at the Build 2015 conference was an example of that for me.  Lots of good stuff for developers from client to server!

Universal Windows Platform

At Build this year we introduced the Universal Windows Platform v10 with a set of new APIs and unified features for all Windows devices.  Perhaps the best vision of this is the Day 2 Keynote where Kevin Gallo walked through an example of this and a single app running on tablet, phone, Surface Hub, HoloLens, etc. 

Visit the keynote and watch the whole thing or if you want to jump to the start of this portion it starts at about 23 minutes in.  A really well done, compelling demonstration of the Universal Windows Platform.

XAML Session Recap

For the XAML developer on Windows, there was a lot of goodness shown from my team.  We’ve been working hard on a lot of internals and new API exposure for the Universal Windows Platform.  Our team had some representation in some deep-dive sessions from Build and the recordings are all now available…here’s a list for you to queue up:

One of the things I was really happy to have is part of the Office team come and talk about how they build Office on the same platform we ask you to build apps on.  It is good insight into a large application with lots of legacy and goals that might not be typical of smaller apps or smaller ecosystems.  A big focus for XAML this release was performance given that customers like Office and the Windows shells themselves leveraging XAML for their UI.

I hope that if you are a XAML developer you take some time to look at what new features are available in the Universal Windows Platform for you in Windows 10.

Get the goods!

If you want to get started playing around, the best way is to be a part of the Windows Insiders program.  Everything you need to get started you can find here https://dev.windows.com/en-US/windows-10-for-developers.  You’ll want to join the Insiders program, then download the Visual Studio tools and get started creating/migrating apps!  To help get you started after that here are some helpful links:

Give us feedback!

As you play around with the bits, please continue to give us feedback.  The best way is to be involved in the conversation on the forums.  Ask questions there, get help from the community, share learnings, etc.  Secondarily the Windows Insider Feedback tool (an app that is installed on Windows already for you as ‘Windows Feedback’) is available for you to give direct feedback to the teams.  Please choose categories carefully so that the feedback gets directly to the right team quickly. 

Thanks for helping make the Windows Platform better.  I hope these direct links help you jumpstart your learning!


This work is licensed under a Creative Commons Attribution By license.



DISCLAIMER:

The opinions/content expressed on this blog are provided "ASIS" with no warranties and are my own personal opinions/content (unless otherwise noted) and do not represent my employer's view in any way.