New technologies arise so quickly that it is hard to achieve mastery in one before it is made obsolete.
So Knockout, Backbone, Angular, Aurelia?
And Azure released several new services into Preview in this month, while several that had been in preview were moved to General Availability. I can barely keep up with reading about the new services, let alone conduct experiments with the new features.
It has never been more true that if you are hiring purely to find someone who matches your checklist of technologies in use, you are missing something. As an experienced hiring manager, I suggest that candidates for advanced positions need experience in the core technology, and some version of front end/back end or whatever.
But you want people who are willing and able to learn new things. Their history is merely an indication of their aptitude and attitude.
Developers naturally get attached to technologies they’ve invested in. There is no good rule for when to stay with something and when to move on.
This is a fun field for someone who loves learning and relishes change. But it can be exhausting. And at some point, we must adopt a strategy to survive or we will all become shepherds and beekeepers.
If you deal with real-world systems, and you value availability, you will want a strategy for handling transient faults. As we move to a greater reliance on services and microservices, we have a greater responsibility to consider such strategies to maintain adequate availability of our solutions.
There are several frameworks out there to help with this in .Net. But the one I like best is Polly.
Scott Hansleman did a great post on it.
I like it because the syntax is very clean and intentional.
You can choose another framework, or roll your own. But you can’t ignore this without leaving your users vulnerable to outages. If the outages are limited in time and occasional, why not just RETRY?
The Azure Service Fabric Team Blog has a new case study of a customer using Service Fabric: https://blogs.msdn.microsoft.com/azureservicefabric/2016/03/15/service-fabric-customer-profile-talktalk-tv/. It provides great detail on the application architecture and the advantages of Service Fabric that are leveraged, but it speaks less about the organizational transformation that was involved. (more…)
This article records step-by-step how to create a new build definition using TFS Build 2015, and publish a website to a Microsoft Azure Web Site from an on-premises build agent. It also describes how to create custom build pools.
TFBuild 2015 is a huge transformation in how we use TFS to build solutions. It integrates with Visual Studio Online. But it also supports your favorite build tools like Ant, Maven, MSBuild and many more. It also supports a variety of scripting languages like DOS, PowerShell, bash Shell Script. This is a powerful testimony to Microsoft’s efforts to embrace cross-platform tools. You can read an Overview of Team Foundation Build 2015 at https://msdn.microsoft.com/Library/vs/alm/Build/feature-overview.
“How did I find out about this?” I was wandering around my local Visual Studio 2015 RC desktop, when I noticed two different types of builds. I saw “Build Definitions” and “XAML Build Definitions” and wondered what the difference was. I created a new Build Definition, and was transported to my VSO (Visual Studio Online) build tab, where they had a message
“We’ve built a new, scriptable build system that’s web-based and cross-platform. See vsopreview for documentation.”
So I clicked the vsopreview link and read about the wonders of this new build technology. Let’s create a build definition that will publish a website to Microsoft Azure. (more…)
I recently tried to install NDepend (http://www.ndepend.com/) version 6 to my home machine.
Visual Studio Extension Installer for Visual Studio 2013 worked just fine.
Visual Studio Extension Installer for Visual Studio 2015 failed with an error caused by a mis-configuration of my machine shown below.
Can’t install NDepend Visual Studio 2015 extension.
Reason: Can’t run VSlXlnstaller.exe to install NDepend Visual Studio
Reason: Can’t find the path to the file VSlXlnstaller.exe
Reason: Can’t resolve the environment variable %VS140COMNTOOLS% to an existing path.
I examined my environment variables (by issuing the SET command from a DOS prompt) and noticed that my VS140COMNTOOLS pointed to a path on the R drive that no longer existed. This was a side-effect of having previously installed Visual Studio 2015 Enterprise RC on the “R” drive, uninstalling it, and re-installing it on the “C” drive. Apparently the reinstallation did not replace or update the environment variable. Once I corrected the path (using System, Advanced, Environment Variables) to point to the valid location, C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE, I had no trouble installing the Visual Studio Extension for 2015. This is an odd situation, and I only include it here in case someone else has uninstalled and re-installed their Visual Studio to another drive at some point. Perhaps searching for this error will help.
I play to learn. My latest test was educational, and I’m sharing it in case others encounter it.
I ran into problems while playing around with Premium blob storage. I was testing blob storage, comparing performance between Regular and Premium storage, while uploading a 5 MB file. I found my error. I was trying to use block blobs on Premium storage, and only Page Blobs are permitted. But I did not realize that at first. Here was my diagnostic path, with errors to help others who may make the same mistake and search for the errors.