Was ist neu?

Die App wurde von Grund auf neu entwickelt, um die zukünftige Weiterentwicklung zu vereinfachen. Die Benutzeroberfläche jedoch ist sehr ähnlich geblieben. Auf der Startseite werden wahlweise alle vergangenen oder zukünftigen Wettkämpfe angezeigt. Die bedeutendste Neuigkeit ist die integrierte Resultat-Anischt. Die Ranglisten können nun direkt in der App angezeigt werden:
Ebenfalls können in der App die Zwischenzeiten analysiert werden:

Was ist verschwunden?

Weggefallen ist in MyOApp die Funktion Wettkämpfe auf der Startseite zu verstecken. Ebenfalls gibt es keine Windows Phone app mehr.

Wie erhalte ich das Update?

Falls du MyOApp bereits installiert hast, wird in den nächsten Stunden ein Update verfügbar sein. Falls du MyOApp noch nicht installiert hast, kannst du es im Play Store oder im iTunes Store herunterladen.

Credits

Merci an Simon Räss an dieser Stelle für die Vorarbeiten!

Zukunft

Ideen für die Weiterentwicklung gibt es viele:

• Integrierte Startlisten
• Benachrichtigungen wenn eine neue Rangliste publiziert wird
• Filtern und Suche auf der Startseite
• Internationalisierung der App indem auch Wettkampfkalender anderer Länder angebunden wird.
• Integration von Grafiken für die Resultate

Habt ihr ein Feature welches umbedingt eingebaut werden soll oder ein Bug entdeckt? Schreibts in den Kommentaren oder direkt an me@yannisguedel.ch

PS: Falls du ein Entwickler bist: MyOApp ist Open-Source. Zögere nicht ein Pull Request für dein Traum-Feature zu senden: https://github.com/yannisgu/myoapp-react

That's why I built a small tool, which discovers mistakes based on GPS data: LiveOMeter. LiveOMeter gets its data from GPSSeuranta. For each event tracked with GPSSeuranta you can draw the course on the map and LiveOMeter will calculate the splittimes for every runner. LiveOMeter then calculates which splittimes can be considered as error and show them accordingly in the results:

To use LiveOMeter proceed with the following steps:

1. Open LiveOMeter: http://liveometer.azurewebsites.net/
2. Select an event in the dropdown at the top of the page.
3. Click on "Draw course"
4. Draw the course on the right panel on the map simply by clicking on the start and then on every control.
5. Click on "Finish drawing course". This will save the course on your local computer, so you don't have to redraw it the next time you visit the event.
6. Enjoy the detailed live results

What is an error?

LiveOMeter uses a similar algorithm as WinSplits to detect errors: For each leg, a quotient of the average of the 25% fastest split times and the runner's split time is calculated. These quotients are called performance indices. The medium value of the runner's performance indices over the whole course is considered the runner's normal performance for the course. If for a leg the performance indice is 10 per cent bigger than his normal performance the leg will be considered as error.

Troubles

Note that there are currently some restrictions/bugs/problems:

• There is no autorefresh on a live event. To get the newest data you will need to reload the page and reselct the event.
• Forkings and loops are not directly supported
• No styling was done so far... so it looks a little bit ugly
• LiveOMeter uses the first passage at the control as splittime. If the runner passed next to a control while going to another, this will be used as splittime, so there will be a negative time.

If you find any other bugs fill free to report them on GitHub: https://github.com/yannisgu/LiveOMeter/issues
Or if you are a developer, don't hesitate to do a pull request!

OcadDiff can be downloaded from the download page.

Currently OcadDiff has a limited function set and there are some restrictions users must know:

• Only changes to objects will be shown. Changes to symbols, courses or other settings will be ignored
• If an object changes OcadDiff will show the object once as removed and once as added, since it does not understands that the added and removed object are actually the same
• There is no support for background maps
• Some symbols like a earth wall or a small erosion gully are not drawn correctly

If you find other issues or you have ideas for additional features don't hesitate to create a GitHhub issue or to drop me a line via email: me@yannisguedel.ch. And if you are a developer, don't hesitate to contribute with a pull request!

Cusom deployment script

The most transparent way to customize the deployment process is to have a custom deployment script. In fact what Azure does during deployment when there is no script, it just creates one for you. The easiest starting point is to let Azure create this deployment script which can then be customized according to your needs. In order to generate this script you need the Azure CLI tools. You can use the Windows Installer to install those tools or run npm install azure-cli -g if you have node installed.

Now navigate to the root folder of your repository with your favorite command line tool. If you have a ASP.NET application run this command to create the script:

azure site deploymentscript --aspWAP .\path\to\Website.csproj --solutionFile MySolution.sln  

Replace .\path\to\Website.csproj and MySolution.sln with the relative path to the csproj of your ASP.NET website of to your solution. Now this created a deployment script called deploy.bat in the root of your repository. The next time a deployment happens on Azure, this script will be used. If you look at the script there are basically 3 steps which are performed by default:

1. Restore NuGet packages
2. Build the website and deploy with Web-Deploy to a temporary location
3. Sync the temporary location to the webite root directory

To customize the process just edit the deploy.bat. We could for example add a Web.config transformation during the deployment. Normally you have different configurations for your local development environment and for the production environment, e.g. connection strings. This can be handled from the Azure Portal but then the config is not versioned under source control. Instead we just could create a XDT File called Web.Prod.config which contains all the settings for the production. In order to perform the Web.config transform during the deployment, we need to call msbuild with the following parameter: /p:PublishProfile=Prod;VisualStudioVersion=12.0. In the generated script the msbuild looks like this:

:: 2. Build to the temporary path
IF /I "%IN_PLACE_DEPLOYMENT%" NEQ "1" (  
  call :ExecuteCmd "%MSBUILD_PATH%"
      "%DEPLOYMENT_SOURCE%\path\to\Website.csproj"
      /nologo /verbosity:m /t:Build
      /t:pipelinePreDeployCopyAllFilesToOneFolder
      /p:_PackageTempDir="%DEPLOYMENT_TEMP%";AutoParameterizationWebConfigConnectionStrings=false;Configuration=Release
      /p:SolutionDir="%DEPLOYMENT_SOURCE%\.\\"
      %SCM_BUILD_ARGS%
) ELSE (
  call :ExecuteCmd "%MSBUILD_PATH%"
      "%DEPLOYMENT_SOURCE%\path\to\Website.csproj"
      /nologo /verbosity:m /t:Build
      /p:AutoParameterizationWebConfigConnectionStrings=false;Configuration=Release
      /p:SolutionDir="%DEPLOYMENT_SOURCE%\.\\"
      %SCM_BUILD_ARGS%
)

You can see that MSBuild is called with different parameters in case the deployment happens directly in the web root or if it happens in a temp directory which is then copied to the web root. Basically we need to add our parameters to the SCM_BUILD_ARGS variable. To do this add the following line after :: 2. Build to the temporary path:

SET SCM_BUILD_ARGS="%SCM_BUILD_ARGS% /p:PublishProfile=Prod;VisualStudioVersion=12.0"

So now when the next deployment happens the Web.Prod.Config file will be transformed to the Web.config file.

Summary

In this post I only showed an example what could be customized during the deployment pipeline. However with a custom deployment script you can just do anything you would like to do during the deployment.

Luckly Azure App Services has a pretty good support of staging environemnt which then can be easily be swapped with the current production environment. Note that this functionality is only avaiable with the standard plan.

To create the staging website, open the previously created production website. I you haven't any, check part 1 of this serie on how to create one. Make sure the app runs on a standard plan and go to Settings => Deployment Slots

Next click on the Add Slot button and fill the form. I strongly advice taking the production website as Configuration Source.
Now Azure created a copy of our Web App which can be easily be swapped with the original one. On this Web App we now need to reconfigure the continuous deployment as we did for the original one. For this go to Deployment => Set up continuous deployment and provide the details of your source code repository.

At this point we want all deployment happen on our staging Web App. There should be no direct deployment to our production Web App. That's why we need to disable automatic deployment on the production Web App. So open it and go to the deployment settings. Here simply click Disconnect.

Now when you change something to your code and push it to the master it will deploy the change to the staging Web App. You can then test it here and update it if necessarily. When everything looks good and you want to publish the changes to production, simply press the Swap button.
Done. So what happened when we swapped both web apps? Basically the file system of both Web Apps interchanged. So the production Web App now serves what was staging before and the staging one servers the files from the last deployment.

Conclusion

In this post showed how to easily configure a staging environment for you Azure Web App in order to deploy quickly but still have an environment where we can test everything.
In the next post of the serie "Continuous Deployment on Azure App Services" I will show how the build and deployment process can be customzied. Stay tuned!

And don't forget to follow me on Twitter to get an update when the next post is out.

In this post I want to make sure the terminology is clear and I will talk about how to setup continous deployment for a basic ASP.NET web site. In the following blog posts I want then proceed to more advanced topics when it comes to continuous deployment on Azure App Services. So let's start with some terms.

What is Continous Deployment about?

Well the base idea is to deploy every change as fast as possible to production. The idea behind this concept is that small change = low risk to break anything. When you deploy lot of features at the same time, the risk to break anything is just bigger than when deploying only a small portion at a time. And well if something breaks it's clear which feature introduced it and it's also fairly easy to rollback to a previous version. However continuous deployment doesn't come for free. There are some requirements your code must have before you can start with continuous deployment:

• Build, installation and deployment including changes to the database must be fully automated. And this is valid for every step of the installation of the web site, even if it only would take 10 seconds to do manualy. Just automate everyting!
• Automated tests are not voluntary. Idealy there are Unit Tests for logic and Integration Tests for functionality. The minimum is that there is some sort of tests.
• There must be simple way to rollback the deployed code. The challenge here is to have the database in sync with code. The best way is to never introduce breaking changes on database level. Never delete a column or table, never rename a column or table, never change the type of column. Create a new one and copy the data is often the better solution when working in a continuous deployment environment. The other possibility is to have database migrations which when applied doesn't care if the database is behind or in front of the current code.
• You need to have your source code cleanly versioned in a VCS. Git is highly recommended here.

And what are Azure App Services?

Azure App Services which were called Azure Websites previously are the PaaS from Microsoft. They provide an super easy way to host ASP.NET, Node.JS, PHP, etc... web applications. In addition of hosting applications, Azure App Services provides a lot more features needed when operating a web application: Monitoring, Performance Analysis, Analytics, automated deployment, everything can be done directly from the Azure Portal. And the coolest thing is that you can have 10 Azure App Services running for free. So if if you haven't an Azure account yet, you should start directly by creating a new one at https://tryappservice.azure.com/

Enough terminology, I want to have my code deployed!

Ok, so for this demo I will use the new Azure Portal located at http://portal.azure.com/. You can create an new website with New => Web + Mobile => Web App
Enter the details here. You can select a free website here:

And now the fun begins. Open you fresh website in the portal and select "Setup Continuous Deployment"

Choose your Git or Mercurial repository here, depending on where it is hosted. You can fork my demo ASP.NET website from Github if you need one to test. Now Azure will automatically build and deploy the website. Of course a NuGet restore will be done before the build is started.
And the collest thing of this whole stuff: anytime you commit something to master it will automatically deployed to your website!

Conclusion and Future

So now with only a few clicks we have a working continuous deployment environemnt on Azure! Of course this example was very basic and for real world projects some customization can be needed. So more posts about Continuous Deployment and Azure App Services. The next topics will be:

• Customize the deployment process
• Rollback a deployment
• Add a staging environment
• Automate the setup
• Add test environments for different branches

Follow me on Twitter to stay updated when a new post is out!

Apt-Get for Windows "OneGet", supports @chocolateynuget. Thanks @ferventcoder for helping them see the light! http://t.co/JfBoSxehtB

— Scott Hanselman (@shanselman) April 3, 2014

I know chocolatey quite good and have used it several times to automate machine installs, but this "OneGet" was new to me. So I opened the link and went through this blog post from Microsoft. I almost freaked out when I realized this was the announcment of the preview of PowerShell 5, which includes chocolatey in its core. That's so cool, since it fills a big gap between Linux and Windows. But OneGet is not only Chocolatey it's a set set of command to talk with a package manager. Chocolatey is simply the first package provider which can be used with OneGet. In this blog post I won't explain a lot about OneGet, since others have done this before. If you never heard about OneGet, read first the blog post withinwindows.com before you continue.

Well, what about other package manager, how can they benifit from OneGet. In this blog post I you will explain how to write your custom provider from OneGet. Since there is no documentation, this post is based on reflection. So the official way will probably be a bit different than this, but I am sure the core concept will keep the same. According to the wiki on github (yes github, it will be open-source!!) it will be possible to write plugins in .NET or PowerShell. I will only cover the .NET-Part in this post.

Write own package provider

So let's start. Basicaly a plugin is a DLL which must contain two classes: A plugin and a provider. A plugin could provide different providers and is responsible to create this providers. In this example we only have one provider for the plugin. The DLL has then to be placed in the OneGet-Module folder under C:\Windows\System32\WindowsPowerShell\v1.0\Modules\OneGet and registered in the OneGet-Module Metadata file (OneGet.psd1).

The provider and the plugin don't need to implement any interface or to inherit from any class, but they have to implement a specific set of methods and properties.

The plugin needs this members:

And that provider needs to implement the following memebers:

Note: There could be more members and not all required, but this are the memebers, the chocolatey provider implements, so that is probably a good base.

Every method in the provider class has a parameter "c" of type Func<string, IEnumerable<object>, object>. This function is like a factory to create functions to interact with powershell. E.g. if you call c("YieldPackage", null) you get a function to give a package back to PowerShell in the GetInstalledPackages or FindPackages method.

I will not explain every method here, but you can download my example package provider to explor the details how to implement your own package provider.

Test the package provider

To test your provider, compile your package provider and put the DLL and the dependencies into C:\Windows\System32\WindowsPowerShell\v1.0\Modules\OneGet
Note: Do not forget to copy the Semver.dll library when you test my example.

Then you have to register the plugin. Edit the file C:\Windows\System32\WindowsPowerShell\v1.0\Modules\OneGet\OneGet.psd1 file as administrator. Then edit the line 'Microsoft.OneGet.Plugin.Chocolatey' to 'Microsoft.OneGet.Plugin.Chocolatey', 'NameOfMyDll'
Note: On Windows 8 you first have to be owner of the C:\Windows\System32\WindowsPowerShell\v1.0\Modules\OneGet folder, to edit the file.

Then test your package by running Get-Package in a new PowerShell console.