The next session on the FSI DevCon was focusing mostly on Machine Learning – how can you use many of the achievements recently came out of Microsoft (most of them open sourced!) to target creating a new kind of AI. We’ve seen some amazing demos of Project Oxford's (Microsoft's in-cloud solution for evaluating queries like 'Twins or not?' and much more serious questions as well) scalability, up to 150 billion evaluations per second. As I have been a Windows Hello user as well, obvious was the question – does the face recognition being the same in Windows Hello and Project Oxford? Turned out to be they do share some of the codebase, but Hello does depend on 3D camera points and much more to make it more robust.
· Microsoft expands availability of Project Oxford intelligent services: http://blogs.technet.com/b/machinelearning/archive/2015/10/26/microsoft-expands-availability-of-project-oxford-intelligent-services.aspx
· Microsoft open sources Distributed Machine Learning Toolkit for more efficient big data research: http://blogs.technet.com/b/inside_microsoft_research/archive/2015/11/12/microsoft-open-sources-distributed-machine-learning-toolkit-efficient-big-data-research.aspx
· The Language-Integrated Quantum Operations (LIQUi|>) simulator: https://github.com/msr-quarc/liquid
One of the best quotes of the days I think should be paired up with the next discussion topic: Universal Windows Apps and Platform, which was: "Windows RT OS? No we are not discussing that now." There is not much I'm allowed to share on the rest of the discussion.
The last big topic we dived into was bitcoin and block chain – to help figuring out what my/our strategy is supposed to be on it. If you still struggle separating the two: if block chain is Manhattan, bitcoin is just one building in it. Same way: if block chain is the iPod, Ethereum (more on that later) is iTunes. We discussed the basic on block chain and bitcoin – What are tokens and addresses. How it works as a P2P network. How it forms consensus. What is a block chain VM and how it works. Why resolving the truth is going to help you next to just storing the information. What are smart contracts and why they are smart – how you are incubating disruption here. We looked into what ÐApps are, how they are distributed applications built with the smart contract platform Ethereum. How the smart contracts enforce themselves as they live on the block chain, how they react to events, multiparty actions, how they can help you transfer assets. How you can create composite contracts. What clause chains are? And most importantly: how you end up with a giant worldwide distributed virtual machine. We looked more deeply how ÐApps work – how it's a combination of a contract and a JavaScript GUI to work with Ethereum and eth. And then popped up the reason why we were there – to learn about 'Azure Block chain as a Service'! We looked at how Ethereum block chain as a service serves a vision with service fabric and microservices, and I think I agreed on that block chain is can be a bigger thing than FIX if needed. The ability to fire up my own ubuntu/go based solution for playing with block chain in the cloud is appealing, and the support in VSCode is giving me a good development IDE to write the sols and configuration files for it.
As the last of this series, I'm saying this here the last time: It's a different Microsoft now! 🙂
We quickly figured out: Microservices ARE happening. For me this brings back soft memories of the first time I was doing real multi-tier applications – at that time expectations from the systems weren't that complex, therefore in some perspective those were close to being microservices with today's scale and view. Part of the current problem is that the tools already catching up with trend. When would the developers catch up? As on the previous session, we learned how much the software development should focus on optimizing development productivity – no empty cycles, more information at hand. Which is interestingly leads to the question, and recognition: there are actually two kinds of developers, those who wants to sit in the most complex cockpit available with as much HUD as possible and integration into all the workflows and systems – and at the same time the large group of developers who would rather see there development cockpit also made of smaller microservices, that are pluggable – for the latter was VSCode dreamed for, and I think it does fit those shows perfectly with the large number of extensions. Next came a topic many of us were dying for to hear about – is Javascript (e.g. hybrid), Xamarin (e.g. cross compiled language tailored for the device and capabilities) or native the answer. I think we answer we got – "it depends" is actually the best answer you can do, there is no one size fits all. We have seen companies moving back and forth between these technologies as they did develop their mobile and desktop experiences, so even it might be different based on the growing or changing requirements. Also, we got a more detailed answer, where the major point was about 'code sharing' – e.g. your choice should depend on what targers you have and how much code and design you can or want to share, and whether you can depend on having a network of you have to be thinking an 'offline first' approach.
One of the first questions was about how RedHat and Microsoft are going to cooperate on giving support for CoreCLR for Linux, e.g. whom to call if the server is on fire. I think best is to be summarized as the quote ‘Open source does not decrease the level of support and / or change the release process'. Next question was on ‘How to respond to a new fancy JavaScript framework coming every month', and the answer was really to focus on developer enablement – if approached with the relevant tools (e.g. nuget/npm/bower/cordova plugin and extension support in the IDE, quick uptake of the new libraries by the people creating the packages, etc), the actual framework picked becomes a less relevant question. It was interesting to learn the scale of open source dependency – in the (now opensourced) VSCode 130 different open source components were used as a dependency. With switching to opensource – as we learned – insight was given into where a project is going, and enabled other teams and projects to build on the capabilities earlier. What is a nice side effect: the definition of ‘Done' had to become from crisp, under the set of watching eyes. Socializing side was also strong – you are socializing in a virtual open space across the continents, something hard to achieve otherwise; and also – opensource projects and being opensource became a recruiting tool both for Microsoft and both for companies using Microsoft tech. Also – it does not have to be big bang! Do something meaningful but small first, and do see how the community reacts, and also: Releasing imperfect code does result in engagement – and engagement is actually a good thing. We were reminded on two blogposts from Scott Hanselman between the lines: 
Connect2015 – this was bigger than Build: the number of announcements, the number of demos, the number of speakers and partners were close to jeopardize the bigger brother conference. Hence, I'm trying to cover the event – as it was little (?) overwhelming, I'm not trying to nicely structure it despite my plan to do that 🙂
In the next 5 minutes of the keynote we were able to tick out "publish to a Linux docker container in azure to run asp.net 5" from our todo list app (see