It can be tricky to run integration tests targeting a web server using the command line. Essentially, we need to: Start the applicati...
JavaScript npmI was trying to get a global .NET Core tool working on my development machine, which just so happens to be running macOS. I also work wit...
.NET macOSWe’ve moved around CSS frameworks in the past few years, Semantic UI for our application layer, and Bootstrap for our static sites. As ou...
SASSNew to the frontend at RIMdev, or looking for more about our Frontend team? Here’s a quick overview of our team, tools, and culture! As ...
Team RIMdev FrontendSimple transitions Vue.js has an extremely helpful was to handle animations in web apps. In a simple example if we want to display somet...
Vue.js JavaScript AnimationsAs web applications have gotten more complex, so has the technologies used to build them. Magic can be good when all works as intended, b...
Webpack JavascriptWe’re in the process of scaffolding out our Microsoft Azure environments using Terraform. We’re looking at deploying consistently from ma...
Azure TerraformRequirement ASP.NET Core 2.2 or 3.0 Why can’t I do this in earlier versions? Read ASP.NET Core 2.2 First Look – Endpoint Routing ...
ASP.NET Core Routing MiddlewareHealth checks in ASP.NET Core are useful for reporting the health of your ASP.NET Core web application. But, this functionality can’t dir...
.NETAs I’ve walked through upgrading a number of solutions to target a new version of the .NET Framework, I’ve compiled a list of helpful ste...
.NETWhat is WSL? Windows Subsytsem for Linux (aka WSL) is an excellent tool for running Linux-based binaries natively in Windows. With the i...
WSL git ASP.NET MVCIn development it is common to not want to share everything in our code. Things like usernames, password, links to an api, and more shoul...
Vue.js JavaScript WebpackIn Vue computed properties are a life saver when it comes to being able to add logic to data that we need to use in the UI. We want to ke...
Vue.js JavaScriptUpdated Solution! Thanks for the post!If you don't want to create a web.config, you can also drive this through the <AspNetCoreHo...
asp.net asp.net coreI, Khalid Abuhakmeh, recently wrote about my [Razor Pages first impressions][khalid] and am mostly positive about the addition to the ASP...
asp.net asp.net core razorWe’re in the process of scaffolding out our Microsoft Azure environments using Terraform. While Terraform does an excellent job creating ...
Terraform OSSTL;DR Explicitly using SqlBulkCopy might never cause this problem since mapping is done manually, but NPoco’s usage does automatic map...
NPoco SqlBulkCopyAs you’re building out an API it’s important to keep response times in check. In many cases slowness is due to database calls, web reques...
Benchmarking OSSWe’ve accomplished so much this year thanks to @VueJS that we wanted to give back to the Vue community in some way. Ritter IM is sponsor...
VueJSEgg Fried Rice is a homey dish in China. In this post, I am going to show you my method to make this simple, quick, and delicious dish. E...
Food chinese cuisineWe are all in when it comes to static site generation. With Windows Azure GitHub integration, it has never been easier to deploy our content, but there is one problem that still needs solved:
How do I publish a future post when there are no forseeable deployments/merges happening between now and the publish date of the future post?
My current answer is to utilize Windows Azure Service Management to trigger a redeployment by utilizing the sync feature. This would be done through a job process. The redeployment would be run on regular intervals (hourly), thus giving future posts the oppurtunity to be published. Here is the basic code to interact with the REST API.
using System;
using System.Configuration;
using System.Threading.Tasks;
using Microsoft.IdentityModel.Clients.ActiveDirectory;
using Microsoft.Azure.Management.WebSites;
using Microsoft.Rest;
namespace Resync
{
class Program
{
private static string ClientId;
private static string ClientSecret;
private static string TenantId;
private static string ResourceGroupName;
private static string SiteName;
private static string SubscriptionId;
static void Main()
{
/* Get Settings */
ClientId = ConfigurationManager.AppSettings[nameof(ClientId)];
ClientSecret = ConfigurationManager.AppSettings[nameof(ClientSecret)];
TenantId = ConfigurationManager.AppSettings[nameof(TenantId)];
ResourceGroupName = ConfigurationManager.AppSettings[nameof(ResourceGroupName)];
SiteName = ConfigurationManager.AppSettings["WEBSITE_SITE_NAME"];
SubscriptionId = ConfigurationManager.AppSettings[nameof(SubscriptionId)];
var token = GetAccessTokenAsync().GetAwaiter().GetResult();
var credentials = new TokenCredentials(token.AccessToken);
var client = new WebSiteManagementClient(credentials)
{
SubscriptionId = "<subscription id>"
};
client.Sites.SyncSiteRepository(ResourceGroupName, SiteName);
}
private static async Task<AuthenticationResult> GetAccessTokenAsync()
{
var cc = new ClientCredential(ClientId, ClientSecret);
var context = new AuthenticationContext($"https://login.windows.net/{TenantId}");
var token = await context.AcquireTokenAsync("https://management.azure.com/", cc);
if (token == null)
{
throw new InvalidOperationException("Could not get the token");
}
return token;
}
}
}
Which of the following architectures would you choose?
THe idea is that this job would be included in each Jekyll instance and be deployed with the static site.
Rather than having each site responsible for calling sync, I would just centralize a job to do that sync for each site.
sync is in one place.I could see using either approach, and neither is clearly better than the other. Which would you choose and why?
