After I first showed off Code Golf, many people’s reaction was that it really needed a way for you to execute your solutions against a problem. I did a little bit of experimentation with Azure Automation but eventually settled on Azure Functions are the perfect engine to process solutions.
Here’s how it works.
Each problem has an input field that allows the author to pass in prerequisites to problem so people have access to predefined variables or possibly functions.
An example of taking advantage of input would be in the solution below. Although it doesn’t solve the problem it does show that the variable is being defined and access automatically.
Azure Functions are implemented with the Azure Web Jobs SDK. It’s just a glorified Azure Web App that can host and execute these tiny snippets of code. In order to upload a solution to Azure Functions, you can take advantage of the Kudu API and use the virtual file system to upload new files onto the Azure Web App. Functions require two files and a folder to be present before showing up in Azure.
You need to create a folder with the name of the Function you’d like to define. I’m just using GUIDs for Code Golf since I delete the function right after it’s executed. You don’t need to directly create a folder with the VFS API. You can instead upload a file into a folder that doesn’t exist and the entire structure will be created. You’ll need to authenticate with Basic authentication in order to perform this operation. Here’s how I’m currently doing it in Code Golf.
In the above example I’m creating a function.json file that contains the binding definitions for the function. You can see examples of this directly in the Azure portal or in the Functions documentation. You need to create the function.json first or it won’t work in Azure.
My function.json consists of an HTTP trigger binding for input and an HTTP binding for output. Authentication isn’t being enforced on the endpoints since they are just being deleted right after execution.
After creating the function.json you need to create the actual executable file. If you’re using PowerShell, this would be run.ps1. If you’re using C#, this would be run.csx. Here’s an example of what a run.ps1 looks that is generated by Code Golf. Nothing is processed from the HTTP trigger. We just start running the solution developed by the solution author. You can see the Input was prepended to the author’s solution.
Starting a function is as easy as making an HTTP GET to the Function URL.
Output from the solution is stored in an $output variable and written out to the output binding. This value is then sent down as the content body of the request to start this Function. Output is then written back to the solution output pane on the Code Golf website. Magic.