If you've ever tried to share code like an API proxy, math calculations, or validation logic between multiple projects, you'll know there are many options. In this post I'll summarize the most common, then dig into the most versatile for .Net projects: private NuGet feeds. I'll cover how to:
Along the way I show a cool time-lapse video of solder paste condensing into its mercury-like liquid state.
This is a very different code hour. Please write in in the comments or me hit up on twitter to let me know how it went and if he should do more like this or if I should really just stick to coding.
A couple of months ago calculating code coverage on the command line was quite challenging in ASP.Net Core. Fortunately, as of last month and Visual Studio 15.8, generating the metric is easy.
In this post I'll summarize what code coverage is, how it can be abused, but also how it can be leveraged to gently increase design and architecture quality, reduce bug regressions, and provide verifiable documentation. But first a short story:
When building a devops pipeline you can go two main directions: put logic into a text-based make-like tool such as Cake, or embed your logic exclusively in a Continuous Integration server like Team City or Visual Studio Team Services. The CI route provides an incredible amount of power quickly. It can distill a breathtaking range of devops complexity to a few checkboxes thanks to 3rd party plug-ins. But it comes at a cost. Here are the 4 main reasons I prefer to put my CI logic in make-like tools.
After the DC Earthquake of 2011, I became intrigued by the earthquake data exposed by the United States Geological Survey (USGS). During this time, I wrote my first app for the Windows Store that used USGS's earthquake data, Rumble Radar. Over the years, I have reused the data mainly for Spatial Data Visualization demos, but also as the basis of Xamarin, UWP and Windows Phone demos. What I failed to do, time and time again, was to build a reusable library for interacting with the USGS GeoJSON API. Therefore, I always had duplicated code in most of my demos which didn't necessarily add value to the topic or technology being showcased. That is why I wrote the UsgsClient library.
Updating Raspberry Pi apps in the field can be tricky. This post covers the general problem and address some specific side-loading problems you are likely to run into.
If you've ever clicked the "Decrypt HTTPS Traffic" button in Fiddler you know how extremely easy it is to initiate a man-in-the-middle attack, and watch (and even modify) the encrypted traffic between an application and a server. You can see passwords and app private information and all kinds of very interesting data that the app authors probably never intended to have viewed or modified.
It's also easy to protect against against man-in-the-middle attacks, but few apps do.
UPDATE (Oct 16, 2018):
Since this post was published, there have been 5 more minor updates to Tizen Studio 2.x and a few weeks ago I was able to successfully get everything working on the current latest (version 2.5 released in August).
Based on early comments, we know 2.0-2.3 was broken, but likely 2.4 (released in May/June) might have worked too... but I never tried it so... ¯\_(ツ)_/¯
Any way, go ahead and give the newest Tizen Studio 2.x another try (following the official docs worked for me!)
(Original post is below)
TL;DR - In the Package Manager Configuration, turn "Auto Update" OFF and make sure 1.3 is the selected version. Then, manually add the TV Extensions 3.0 repository to the Extensions SDK.