Skip to content


New set of presentations

So it is finally time to retire my previous set of presentations and put some new ones together. There are some major categories I need to cover:

  • IoT with Mobile
  • Azure IoT Gateway modules
  • Stream Analytics edge
  • Azure ML edge
  • Alternative application interfaces
  • FuseThru advantage
  • Azure IoT architecture

This post is a way for me to put out some ideas on what to speak on and edit them as time passes and I get feedback. So here are my initial attempts:

IoT and Mobile

So in this talk I want to show some command control scenarios and some data ingestion. To do this I will show a scenario where a mobile device running a Xamarin application will control an LED or a servo or a relay or some other visible actionable device. Then on the data ingestion side, a set of devices consuming physical data and broadcasting them over the air via Bluetooth. The mobile app will consume that data and showcase it in the application.

Azure IoT Edge

This talk can reuse the Bluetooth devices from the IoT and mobile talks. Using those, a gateway can have a module configured  to consume the device data. With that I can show how to make a module and deploy that module to the gateway. Then I will add a stream analytics module from the edge to consume the data internally to the application.

Stream Analytics Edge

This is a talk very similar to the Azure IoT Edge talk except instead of focusing on creating the module in code, I focus on the architecture of the gateway and show how to create an edge module in stream analytics. The data consumed will most likely be the same Bluetooth devices as above.

Azure ML Edge

This talk will take a little different set of hardware. Video is such a game changer when it comes to machine learning. It really shows how powerful machine learning is. To accomplish that demonstration will require a video input. I would love to be able to use the HoloLens but I think I will settle for an easy to use camera. Once the camera is streaming data to a gateway, I will try to push a ML algorithm for computer vision down to the gateway to consume the data and output any detection events.

Alternative application interfaces

I would like to continue to be able to show the different ways an application can consume data and interact with the user and the environment without a screen. To do this, the following interfaces should be shown:

  • Audio input
  • Audio output
  • Video input
  • Control output
  • Control input

This is one I really need to think on. I would like to get a combination of each input to each output.

FuseThru advantage

One presentation should be on how Fusethru’s Fuseworks technology can greatly reduce the computing cost of distributed IoT data. In the demo, I will showcase a large amount of data moving through the Fuseworks application on a Multitech box using different incoming sensors to showcase how easy to use and how the application uses its existing power to accomplish big data queries.

Azure IoT architecture

The simplest demo. Go thorough the different styles of Azure IoT architecture and showcase a use case for each.


Proxygen – Getting started with Facebook’s HTTP Server

So recently I have been writing a tool for querying data from the fog. I needed a high thru put ingest engine that could handle a large amount of data while synchronizing ad-hoc data pipes (I know that sounds like buzz word drivel but it is what I needed). Since I have been courting her for a while, I thought I would finally ask Proxygen out for coffee to help me solve this problem. After we went out for our cup of coffee, I was saddened to learn that the Proxygen is a closed book of opensource software. The code is there free to read but to say that the documentation is lacking would be generous. Folly, a Proxygen dependency has a nice level of documentation here. Realistically, the examples and the doxygen docs are enough to get started.

I already wrote a post on getting started with a Proxygen HTTP Client. Now this one is about getting the server up and running. There is an example in the Proxygen documentation samples echo server. The echo example falls short in describing how to customize your own server implementation. As I describe rolling your own server, I will be leaving out specifics to my employers domain. That should leave some easily filled gaps for the reader. The ultimate goal is to have a ASP.NET style web api and a file server that I can use to create a full web solution. To create an easy API, the pieces of Proxygen must be utilized properly.


In the echo server examples, there is an EchoServer.cpp source file that showcases how to setup a Proxygen http server. In this file, utilities are setup and the server is launched. Most of the file reads easily enough but the current goal is customization. To customize the execution pipeline, a handler factory must be placed in the Request handler chain found:

options.handlerFactories = RequestHandlerChain()

In the code above, replace “EchoHandlerFactory” with an HandlerFactory that fits the needs of the project. The next section has an overview of custom HandlerFactory creation.

Handler Factory

Handler factories allow for the creation of handlers (explained below). Each request will go through the handler factory to create a handler for that request. To treat this like ASP.NET, the Handler Factory works like the route config and the dependency injector all in one. With the EchoServer example, the EchoHandlerFactory is in the EchoServer.cpp source file. The EchoHandlerFactory handles the dependency resolution and if routing was available could use the HTTPMessage* to get the path and return the appropriate handler.


The Handler is going to handle the HTTP lifecycle and return an appropriate response. The Echo Handler sample has the handler source located in EchoHandler.cpp. In it, the HTTP lifecycle is handled. In it there are a few methods to make note of:

  • onRequest – This method can be used to determine authorization and authentication to the web resources. In it, the headers for the request are passed.
  • onBody – This is where the folly::IOBuf is built for the request. The buffer will be appended to during each read of the request and can be converted into a folly::string and then to a std::string.
  • onEOM – This is the method where you can respond to the request. The example shows how to us ResponseBuilder to put together an Ok response to the request.


Twitter Auto Publish Powered By :