This course targets software developers and data scientists looking to understand the initial steps in a machine learning solution. The content will showcase methods and tools available using Microsoft Azure.
Description
No data science project of merit has ever started with great data ready to plug into an algorithm. In this course, Cleaning and Preparing Data in Microsoft Azure, you’ll learn foundational knowledge of the steps required to utilize data in a machine learning project. First, you’ll discover different types of data and languages. Next, you’ll learn about managing large data sets and handling bad data. Finally, you’ll explore how to utilize Azure Notebooks. When you’re finished with this course, you’ll have the skills and knowledge of preparing data needed for use in Microsoft Azure. Software required: Microsoft Azure.
Architecting Xamarin.Forms Applications for Code Reuse
Abstract
A well-architected application is flexible to changing business requirements. This course will teach you how to architect Xamarin.Forms applications in a way that promotes reusable patterns.
Description
As business requirements change, so do solution assumptions. In this course, Architecting Xamarin.Forms Applications for Code Reuse, you’ll learn different architectural patterns in Xamarin.Forms. First, you’ll explore project structure and organization. Next, you’ll discover patterns and standards to promote code sharing. Finally, you’ll learn how to utilize dependency injection in Xamarin.Forms. When you’re finished with this course, you’ll have the skills and knowledge of architecting Xamarin.Forms projects needed to optimally promote code reuse.
Google’s Protocol Buffers are a perfect fit with the multilingual approach of Azure IoT Edge. Using ProtoBuf, a message format can be written once and used across multiple frameworks and languages while benefiting from the speed and message size intrinsic to ProtoBuf. For this Azure IoT Edge use case, we will generate a message in C++ and send it to a module written in Python to filter out the values that are sent to IoT Hub.
Steps
Create the message format
Create a C Azure IoT Edge Module
Add ProtoBuffers to build
Create C models
Create a Python Azure IoT Edge Module
Add ProtoBuffers to project
Create Python Module
Create the message format
Creating the message format is trivial. Following the language guide, there are two message types to create.
A temperature reading, consisting of a float and a string
The above is all that is needed to create the model for ProtoBuf. Creating the language specific code for each module is covered in their module sections.
Create a C Azure IoT Edge Module
Prerequisites
This article assumes that you use a computer or virtual machine running Windows or Linux as your development machine. And you simulate your IoT Edge device on your development machine.
Take these steps to create an IoT Edge module based on Azure IoT C SDK using Visual Studio Code and the Azure IoT Edge extension. First you create a solution, and then you generate the first module in that solution. Each solution can contain more than one module.
In Visual Studio Code, select View > Integrated Terminal.
Select View > Command Palette.
In the command palette, enter and run the command Azure IoT Edge: New IoT Edge Solution.
Browse to the folder where you want to create the new solution. Choose Select folder.
Enter a name for your solution.
Select C Module as the template for the first module in the solution.
Enter a name for your module. Choose a name that’s unique within your container registry.
Provide the name of the module’s image repository. VS Code autopopulates the module name with localhost:5000. Replace it with your own registry information. If you use a local Docker registry for testing, then localhost is fine. If you use Azure Container Registry, then use the login server from your registry’s settings. The login server looks like .azurecr.io.
VS Code takes the information you provided, creates an IoT Edge solution, and then loads it in a new window.
There are four items within the solution:
A .vscode folder contains debug configurations.
A modules folder has subfolders for each module. At this point, you only have one. But you can add more in the command palette with the command Azure IoT Edge: Add IoT Edge Module.
An .env file lists your environment variables. If Azure Container Registry is your registry, you’ll have an Azure Container Registry username and password in it.
Note
The environment file is only created if you provide an image repository for the module. If you accepted the localhost defaults to test and debug locally, then you don’t need to declare environment variables.
The default C module code that comes with the solution is located at modules >> main.c. The module and the deployment.template.json file are set up so that you can build the solution, push it to your container registry, and deploy it to a device to start testing without touching any code. The module is built to simply take input from a source (in this case, the tempSensor module that simulates data) and pipe it to IoT Hub.
When you’re ready to customize the C template with your own code, use the Azure IoT Hub SDKs to build modules that address the key needs for IoT solutions such as security, device management, and reliability.
Compile the Protocol Buffer file
To compile the Protocol Buffer file, use the command line compiler protoc. For more information on how to use protoc for each platform, check out the Protocol Buffer documentation. For the C module, we will use the C++ compiler options:
To create and serialize the object, use the following code:
TemperatureReading reading;
reading.set_reading(get_temperature_reading()); //get_temperature_reading is your function on generating the temperature reading value
auto message_body = reading.SerializeAsString();
Build and deploy your module for debugging
In each module folder, there are several Docker files for different container types. Use any of these files that end with the extension .debug to build your module for testing. Currently, C modules support debugging only in Linux amd64 containers.
In VS Code, navigate to the deployment.template.json file. Update your module image URL by adding .debug to the end.
Replace the C module createOptions in deployment.template.json with below content and save this file:
In the VS Code command palette, enter and run the command Edge: Build IoT Edge solution.
Select the deployment.template.json file for your solution from the command palette.
In Azure IoT Hub Device Explorer, right-click an IoT Edge device ID. Then select Create deployment for Single device.
Open your solution’s config folder. Then select the deployment.json file. Choose Select Edge Deployment Manifest.
You’ll see the deployment successfully created with a deployment ID in a VS Code-integrated terminal.
Check your container status in the VS Code Docker explorer or by running the docker ps command in the terminal.
Start debugging C module in VS Code
VS Code keeps debugging configuration information in a launch.json file located in a .vscode folder in your workspace. This launch.json file was generated when you created a new IoT Edge solution. It updates each time you add a new module that supports debugging.
Navigate to the VS Code debug view. Select the debug configuration file for your module. The debug option name should be similar to ModuleName Remote Debug (C).
Navigate to main.c. Add a breakpoint in this file.
Select Start Debugging or select F5. Select the process to attach to.
In VS Code Debug view, you’ll see the variables in the left panel.
The preceding example shows how to debug C IoT Edge modules on containers. It added exposed ports in your module container createOptions. After you finish debugging your C modules, we recommend you remove these exposed ports for production-ready IoT Edge modules.
Create a Python Azure IoT Edge Module
Create an IoT Edge module project
The following steps create an IoT Edge Python module by using Visual Studio Code and the Azure IoT Edge extension.
Create a new solution
Use the Python package cookiecutter to create a Python solution template that you can build on top of.
In Visual Studio Code, select View > Integrated Terminal to open the VS Code integrated terminal.
In the integrated terminal, enter the following command to install (or update) cookiecutter, which you use to create the IoT Edge solution template in VS Code:
pip install --upgrade --user cookiecutter
Ensure the directory where cookiecutter will be installed is in your environment’s Path in order to make it possible to invoke it from a command prompt.
Select View > Command Palette to open the VS Code command palette.
In the command palette, enter and run the command Azure: Sign in and follow the instructions to sign in your Azure account. If you’re already signed in, you can skip this step.
In the command palette, enter and run the command Azure IoT Edge: New IoT Edge solution. In the command palette, provide the following information to create your solution:
Select the folder where you want to create the solution.
Provide a name for your solution or accept the default EdgeSolution.
Choose Python Module as the module template.
Name your module PythonModule.
Specify the Azure container registry that you created in the previous section as the image repository for your first module. Replace localhost:5000 with the login server value that you copied. The final string looks like <registry name>.azurecr.io/pythonmodule.
The VS Code window loads your IoT Edge solution workspace: the modules folder, a deployment manifest template file, and a .env file.
Add your registry credentials
The environment file stores the credentials for your container repository and shares them with the IoT Edge runtime. The runtime needs these credentials to pull your private images onto the IoT Edge device.
In the VS Code explorer, open the .env file.
Update the fields with the username and password values that you copied from your Azure container registry.
Save this file.
Compile the Protocol Buffer file
To compile the Protocol Buffer file, use the command line compiler protoc. For more information on how to use protoc for each platform, check out the Protocol Buffer documentation. For the Python module, we will use the Python compiler options:
Each template includes sample code, which takes simulated sensor data from the tempSensor module and routes it to the IoT hub. In this section, add the code that expands the PythonModule to analyze the messages before sending them.
In the VS Code explorer, open modules > PythonModule > main.py.
At the top of the main.py file, import the temp_pb3 library that was created by protoc:
import temp_pb3
Add the TEMPERATURE_THRESHOLD and TWIN_CALLBACKS variables under the global counters. The temperature threshold sets the value that the measured machine temperature must exceed for the data to be sent to the IoT hub.
TEMPERATURE_THRESHOLD = 25
TWIN_CALLBACKS = 0
Replace the receive_message_callback function with the following code:
# receive_message_callback is invoked when an incoming message arrives on the specified # input queue (in the case of this sample, "input1"). Because this is a filter module, # we forward this message to the "output1" queue.defreceive_message_callback(message, hubManager):global RECEIVE_CALLBACKS
global TEMPERATURE_THRESHOLD
message_buffer = message.get_bytearray()
map_properties = message.properties()
key_value_pair = map_properties.get_internals()
print ( " Properties: %s" % key_value_pair )
RECEIVE_CALLBACKS += 1print ( " Total calls received: %d" % RECEIVE_CALLBACKS )
data = TemperatureReading.ParseFromString(message_buffer)
if data.reading > TEMPERATURE_THRESHOLD:
map_properties.add("MessageType", "Alert")
print("Machine temperature %s exceeds threshold %s" % (data["machine"]["temperature"], TEMPERATURE_THRESHOLD))
hubManager.forward_event_to_output("output1", message, 0)
return IoTHubMessageDispositionResult.ACCEPTED
Add a new function called module_twin_callback. This function is invoked when the desired properties are updated.
# module_twin_callback is invoked when the module twin's desired properties are updated.defmodule_twin_callback(update_state, payload, user_context):global TWIN_CALLBACKS
global TEMPERATURE_THRESHOLD
print ( "\nTwin callback called with:\nupdateStatus = %s\npayload = %s\ncontext = %s" % (update_state, payload, user_context) )
data = json.loads(payload)
if"desired"in data and"TemperatureThreshold"in data["desired"]:
TEMPERATURE_THRESHOLD = data["desired"]["TemperatureThreshold"]
if"TemperatureThreshold"in data:
TEMPERATURE_THRESHOLD = data["TemperatureThreshold"]
TWIN_CALLBACKS += 1print ( "Total calls confirmed: %d\n" % TWIN_CALLBACKS )
In the HubManager class, add a new line to the init method to initialize the module_twin_callback function that you just added:
# Sets the callback when a module twin's desired properties are updated.
self.client.set_module_twin_callback(module_twin_callback, self)
Save this file.
Build your IoT Edge solution
In the previous section, you created an IoT Edge solution and added code to the PythonModule to filter out messages where the reported machine temperature is below the acceptable threshold. Now you need to build the solution as a container image and push it to your container registry.
Sign in to Docker by entering the following command in the Visual Studio Code integrated terminal. Then you can push your module image to your Azure container registry:
Use the username, password, and login server that you copied from your Azure container registry in the first section. You can also retrieve these values from the Access keys section of your registry in the Azure portal.
In the VS Code explorer, open the deployment.template.json file in your IoT Edge solution workspace.This file tells the $edgeAgent to deploy two modules: tempSensor, which simulates device data, and PythonModule. The PythonModule.image value is set to a Linux amd64 version of the image. To learn more about deployment manifests, see Understand how IoT Edge modules can be used, configured, and reused.This file also contains your registry credentials. In the template file, your user name and password are filled in with placeholders. When you generate the deployment manifest, the fields are updated with the values that you added to the .env file.
Add the PythonModule module twin to the deployment manifest. Insert the following JSON content at the bottom of the moduleContent section, after the $edgeHub module twin:
In the VS Code explorer, right-click the deployment.template.json file and select Build and Push IoT Edge solution.
When you tell Visual Studio Code to build your solution, it first takes the information in the deployment template and generates a deployment.json file in a new folder named config. Then it runs two commands in the integrated terminal: docker build and docker push. These two commands build your code, containerize the Python code, and then push the code to the container registry that you specified when you initialized the solution.
You can see the full container image address with tag in the docker build command that runs in the VS Code integrated terminal. The image address is built from information in the module.json file with the format <repository>:<version>-<platform>. For this tutorial, it should look like registryname.azurecr.io/pythonmodule:0.0.1-amd64.
Deploy and run the solution
You can use the Azure portal to deploy your Python module to an IoT Edge device like you did in the quickstarts. You can also deploy and monitor modules from within Visual Studio Code. The following sections use the Azure IoT Edge extension for VS Code that was listed in the prerequisites. Install the extension now, if you didn’t already.
Open the VS Code command palette by selecting View > Command Palette.
Search for and run the command Azure: Sign in. Follow the instructions to sign in your Azure account.
In the command palette, search for and run the command Azure IoT Hub: Select IoT Hub.
Select the subscription that contains your IoT hub, and then select the IoT hub that you want to access.
In the VS Code explorer, expand the Azure IoT Hub Devices section.
Right-click the name of your IoT Edge device, and then select Create Deployment for IoT Edge device.
Browse to the solution folder that contains the PythonModule. Open the config folder, select the deployment.json file, and then choose Select Edge Deployment Manifest.
Refresh the Azure IoT Hub Devices section. You should see the new PythonModule running along with the TempSensor module and the $edgeAgent and $edgeHub.
September 20th at Cobb Center in Detroit I will be presenting:
Alternative Device Interfaces and Machine Learning
Abstract
In this presentation, we will look at the how users interface with machines without the use of touch. These different types of interaction have their benefits and pitfalls. To showcase the power of these user interactions we will explore: Voice commands with mobile applications, Speech Recognition, and Computer Vision. After this presentation, attendees will have the knowledge to create applications that can utilize voice, video, and machine learning.
Description
Users use voice (Alexa, Cortana, Google Now) or video as a mode of interaction with applications. More than a fad, this is a natural interface for users and is becoming more and more common with the ever-decreasing size of hardware.
Different types of interaction have their benefits and pitfalls. To showcase the power of these user interactions we will explore: Voice commands with two app types: UWP and Xamarin Forms (iOS and Android). Speech Recognition with Cognitive Services: Verifying the speaker with Speaker Recognition API. Computer Vision with Cognitive Services: Verifying a user with Face API.
By utilizing UWP, Xamarin, and Cognitive services; a device with the ultimate in customization for user interactions will be created. Come and see how!
The internet of things allows for communication with devices through various means (without touch, mouse, keyboard, or a screen). Mobile devices give users a dynamic interactive experience with these devices by communicating over several different wireless protocols or through the cloud. In this presentation, we will see how to use Xamarin to create a cross platform mobile application to control devices of all shapes and sizes. After this presentation, attendees should be able to create a basic mobile application and have that application communicate with peripherals over Bluetooth and the cloud.
Description
This presentation is to showcase creating mobile applications with Xamarin and how those applications can interact with both off the shelf and with custom hardware. First, we will create a Xamarin Forms application; for iOS, Android, and Windows; that will interact with both Microsoft Azure and Bluetooth Low Energy to create an interactive experience with the hardware and the cloud. To get a better understanding, we will discuss mobile communication with the cloud and hardware to get a picture of how mobile can act as a bridge between the two.
After nearly a year of hard work, the Home Control Flex application has finally reached a new release point. There have been major improvements around the use of Xamarin Forms and the use of mobile features. There were major changes around framework dependencies and utilization of navigation pages.
The major problems in the previous version was poor usage of navigation pages, dependencies on old frameworks, and lack of sharing of global resources. Adding all of these failures together resulted in an unstable application that crashed on multiple pages. Fixes to those crashes were a slow roll out of shims and hacks to keep the previous decisions working.
The largest problem was the poor usage of navigation pages. For some reason, to implement a tabbed page where the tabs were at the bottom on Android, the previous developers decided to use a ContentPage, and make the tab pages within the ContentPage ContentViews and swap those views out whenever a tab was changed. This caused almost every major problem that could not be resolved in the app moving forward. To fix it, the BottomNavigationBarXF Nuget packages was used. The base renderer was overridden to implement some custom functionality but overall it was a clean integration or at least as clean as such a big overhaul to the navigation system can handle.
Since the pages were being swapped out whenever a tab was changed, the previous developers mush have decided that instead of needing navigation pages, they would just continue to change the view out and have their own navigation stack. Without using NavigationPage within their app, the page lifecycle was completely off and the were object disposed exceptions that were being thrown by the Forms framework due to the fact that the views lifecycle was not correctly managed. Xamarin Forms couldn’t track whether a view was to be reused or not and would collect on disappeared views that were going to come back later. Once NavigationPage was used this was no longer a problem.
When I inherited the app there were multiple frameworks being used in the application. It seemed to have a javascript approach where a framework may be brought in for some partial functionality or even a single method. Xamarin Forms Labs was the biggest offender when I inherited the app. The previous developers had referenced it to use it for one control and two converters. Once it was removed, the application was much more light weight on disk. At the time it was removed there was no noticeable performance gain but that was most likely due to the lack of utilization within the app and the fact that I had only been with the app for a month.
This app was riddled with copy and paste code reuse. Every page shared the same Style declaration with the same name (which was the style for that page). Every page had a declaration of a Converter for inverting a boolean. All these “shared” resources were moved to the App.XAML for reuse by every page within the application.
After fixing the above issues, changing a variety of pages within the app, and adding a load of new features, the app should finally be a stable release with market effects that was expected out of its first release. I hope to continue to improve on the line of applications from Telular including this app.
I’m proud to be presenting Alternative Device Interfaces and Machine Learning at CodeStock this year. With AI becoming more and more ubiquitous, it is important to note the effect on a user’s experience. This presentation is meant to show how to create modern applications using machine learning provided by a third party and showcase what some third parties provide.
In this presentation, we will look at the how users interface with machines without the use of touch. These different types of interaction have their benefits and pitfalls. To showcase the power of these user interactions we will explore: Voice commands with mobile applications, Speech Recognition, and Computer Vision. After this presentation, attendees will have the knowledge to create applications that can utilize voice, video, and machine learning.
Users use voice (Alexa, Cortana, Google Now) or video as a mode of interaction with applications. More than a fad, this is a natural interface for users and is becoming more and more common with the ever-decreasing size of hardware.
Different types of interaction have their benefits and pitfalls. To showcase the power of these user interactions we will explore: Voice commands with two app types: UWP and Xamarin Forms (iOS and Android). Speech Recognition with Cognitive Services: Verifying the speaker with Speaker Recognition API. Computer Vision with Cognitive Services: Verifying a user with Face API.
By utilizing UWP, Xamarin, and Cognitive services; a device with the ultimate in customization for user interactions will be created. Come and see how!
If a Custom Renderer is added to a Xamarin Forms Android project and suddenly the application crashes before loading the first screen then do a rebuild or clean of the Android project and re-run.
A common pitfall I see in Xamarin Forms is adding a Loading page icon for every page. This is one of the problems that plagued the current Home Control Flex application. Instead of having to loading icon on each page you can crate a base page that has a loading screen on each. You can do this using the ContentPropertyAttribute on your base page as shown below.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters