My takeaways from BUILD 2016

There was a lot of information to ingest at BUILD this year. Whether you're working with Xbox, Azure, Windows, or even Linux containers, I would find it surprising that there wasn't at least one announcement that touched your development universe.

My takeaways from BUILD 2016

There was a lot of information to ingest at BUILD this year. Whether you're working with Xbox, Azure, Windows, or even Linux containers, I would find it surprising that there wasn't at least one announcement that touched your development universe. Even though there were no toys given away and it was way too overcrowded, I felt it was one of the most exciting BUILD in years. With that said, here is a quick overview of what I took away from the event and what I'm looking forward to in the coming year.

.NET Core 1.0

If you've been following the beta and the community stand-ups from the ASP.NET and Core teams, you already know about the shift to v1 Core. Even though this change was costly in terms of time, it's a good move for the long term. Core is the future of .NET. It delivers on what most .NET developers have wanted for years, true xplat development. With Java now in an Oracle chokehold, this will make .NET even more attractive to SMBs and Enterprises. Core also sheds so much of the Windows weight, making it feel and operate more like Node...and that's a very good thing. Finally, bringing Mono into the fold paves a clear path from full .NET/Mono on Windows/Mac/Linux to a Core-only future. Competing xplat frameworks for .NET is not ideal for the community, so this is a hugely positive move for the future. For all things Core, check out the Github site.

Conversations, Intelligence, and Bots

The day one keynote was littered with information on the new conversation-based platforms of the now and near future. If you are already a Slack user, a Siri/Cortana/Google/Alexa user, or even a veteran IRC user, you are no stranger to bots. The big difference now is the intersection with machine learning and the ubiquitous adoption of webhooks in our applications (integrations). We've moved from sandboxed bots to learning bots that can talk to each other. This "new" platform opens up the entire world to advanced application interactions via the interface or "head" that we are already used to. Think how easy it is to use voice dictation or thumb out a text message. If you can do that, you can book a flight, make reservations, schedule appointments, you name it. We can move beyond complex native apps or the mobile web...the interface we need already exists. The devices we have already know so much about us, it's about time we put that to good use. You provide the language, your device/service provides the context, and the intelligent bot does the rest. This entire area of development and technology has been a personal interest of mine for the past couple of years, and I'm excited to be a part of the platform's future. DevOps was essentially born from this, so I see this next step, the intelligent conversation, as a natural evolution to the automation and integration story. For more in-depth information, check out the Microsoft Bot Framework and Microsoft Cognitive Services.

Azure Functions

WebJobs are dead; long live WebJobs Azure Functions. In a clear answer to the AWS Lamda service, we now have the Azure flavor of event-based on-demand code execution. This need has been especially confusing, if not impossible, to implement in Azure over the years. Should I use a worker role? A WebJob? A Node job on the Mobile app service? I could go on. We all have jobs we need to run. Some need to run based on a specific event, and some need to run on a schedule...Some may need to just run on demand.

Given the many use cases, no single app model has solved this with the promise of all the cloud offers. Functions answer the call by offering simplified triggers, making it easy to get data in and out through bindings, and handling the container bits for you...It feels like a complete solution that is enterprise ready. Getting production code running reliably without dwelling on cost, scale, or availability has vast implications. Where did we deploy that Slack slash command webhook again? Functions are a big step in the right direction, and I look forward to using the 💩 out of it. For more info on the full announcement, check out the Azure blog.

Service Fabric is here

Demoed at BUILD last year in its bare form and touted as the battle-tested system that many of Microsoft's services run on, it is finally generally available to the masses. Microservices are here to stay; if you are not already building your services this way, you will be soon enough. There are considerable advantages to segmenting your services, like independent updates, versioning, and scale. Not only that, but the fabric also maintains the reliability of your services, dealing gracefully with failures, and even managing state. In addition to microservices, it supports the virtual actor pattern via reliable actors. So if you've looked at or are familiar with frameworks like Orleans, you will feel right at home here. I'm working with Orleans on a large project, so I'm especially interested in leveraging service fabric and its actor implementation. Carve out a couple of hours in your schedule for the entire run down and head over to the Azure documentation.

Bash and Linux on Windows

Seriously. No VM here; this is Linux on Windows running natively. While some might see this as pandering, I see real productivity value here. The ability to apt-get packages and get development environments up quickly is a massive boost to local development. Redis, Mongo, you name it, will be much easier to set up...not to mention the plethora of support on the web. I currently use both Mongo and Redis in my .NET azure apps, and both do work on Windows as well, but this will be my preferred method of development moving forward. You can even install emacs if that is your thing, but for those who want to get more comfortable with Linux, this should be a welcome addition to Windows 10. Not all packages will run yet, but you can expect this feature to improve over time. Scott Hanselman has a nice write-up on this feature on his blog, check it out.

Xbox, UWP, and Hololens

Some cool announcements in this group. Finally, the promise of .NET/JavaScript UWP apps on Xbox One. Every retail Xbox One console can be used as a development device! I completed some code labs on this at the conference, and the process is dead simple. I've been waiting a long time for this capability and can't wait to start building some UWP apps for the big screen. Also, on the UWP front, some new conversion capabilities will package up any Win32 or WPF app into a UWP app that can be published to the Windows Store. They call this process a Windows Bridge, the category they define for porting to Windows 10. That goes for any desktop app, including AAA games. UWP apps are also "double-click" installable for easy side-loading. That makes UWP incredibly accessible for most Windows users and game developers, so I think we'll see an explosion of Windows Store apps on all Win 10 devices. Finally, Hololens is shipping. If you have 3k to spend, or your company does, it's all yours. I'm intrigued by the technology, but I can't see the value for most due to the price and capability. It's not like your average consumer will have this in their house. At this point, Hololens is purely an Enterprise product we may start seeing in businesses or sales showrooms. I get why they didn't give these out; it doesn't make sense unless you are developing for these niche target markets the device is currently targeted for.

Xamarin for all

This was expected, but it was great to hear it officially announced. I did find it surprising that even the community edition will get full Xamarin support...and they even one-upped that by open-sourcing the SDK. They made some nice tooling improvements for the Visual Studio integration, especially the iPhone emulator display. You still need a Mac connected, but it's one less thing you have to do to test your iOS app. The most impressive part of the Xamarin stack to me was the Inspector/Workbook. This app allows you to inspect your WPF, Android, iOS, or Mac app in real-time. It also functions as a REPL by allowing you to execute and evaluate code in line. Its Linqpad meets the quick watch debug window. To top off, the entire workbook is stored in MarkDown format, so you can build interactive documentation by simply loading your repo's README.MD file. There are so many applications for this. I highly recommend you download the Inspector for both Windows and Mac; you'll have a lot of fun with it. I also recommend you check out Miguel's session, in which he demo's a lot of this functionality on the Mac.