I love infrastructure and anything that has to do with it. That is - I love tinkering with different services and see what I can do to make them play nice with each other. I also like being efficient with what and how I deploy, and recently something dawned on my - I am spending way too much money on hosting my personal blog, that is 90% text. A recent analysis brought me to the number: 30$/mo.
At GitHub Universe 2018, the team announced a new an exciting capability of the platform - GitHub Actions. At its core, this allows you to run "micro-CI" (or not so micro) within the repository itself. The benefit is two-fold: you can still plug in to other CI services, and you can also segment the workflow directly from the repository (there are some pretty interesting workflows out there already).
Yet another one of those times where people kept asking about something on Twitter, and I thought that it would be easier to write a blog post explaining the inner workings of things instead of responding in 280 characters. This time, this relates to "How can I build my own little docs.microsoft.com", so let's tackle the problem head-on.
Thought I’d start a series of videos talking about documentation and anything related to it.
API documentation - something that often remains an after-thought for developers purely because writing it can be cumbersome, it requires working with a bunch of different tools (often very old), and maintaining it makes developers cringe just because that means they have to come up with good examples and descriptions, and let's face it - most developers would rather focus on writing code.
In our team (docs.microsoft.com - we are hiring), we extensively use both GitHub and VSTS, for a variety of reasons. The problem of connecting the two came along as we were thinking about our public feedback channel. We ultimately want to have all user suggestions directed to the PM and engineering teams; however, internally all processes revolve around VSTS and engineering work is tracked there. The idea was to build a bot that can create VSTS work items from suggestions in GitHub.
Last weekend I hacked together a solution that allows Nest stream capture locally. This weekend I got a chance to improve it a bit and make the entire solution cloud-ready.
One of the features that I love the most about Visual Studio Team Services is the ability to build my code in the cloud. In my project I have a requirement for dynamic build provisioning, which works well. However, I recently tried to figure out how can I get the list of steps from a build definition, and was hitting a roadblock up until I got some help from Chris Patterson.
If you already checked out the Intro to Azure Notification Hubs post, there is some new material ready for you, that describes how to build a push notification service for Chrome, Xamarin.Android and native Android.
A bit ago, Scott Hanselman and myself recorded a nice intro to sending push notifications with Azure Notification Hubs. Check out our session to learn more.
While working on Beem, I always relied on a static XML file to fetch me the list of available online radio streams. It’s a good way to keep the content dynamic, and when new stations are added, I do not have to re-submit the application for certification but rather just update the XML file.
Multiple applications that are already in the Windows Phone Marketplace operate with a variety of content, such as pictures, text files and music. More often than not, that content is stored locally, in the application isolated storage, and although it is a good way to preserve that content, this method is bound to create some inconveniences in case the user decides to switch phones or do a complete device reset.