For those of us who are on Google’s Legacy Free G Suite plan, there was an announcement the other day that all good things must come to an end. Sometime in the July timeframe everyone will need to either start paying or stop using the service. Fortuitously, Apple recently (in October) announced custom domain support for iCloud. For people who were using G Suite only as an email service (i.e. no Google Docs, or other Google Apps), and are only using it for personal accounts, iCloud can serve as a perfectly acceptable email host.
The migration path is pretty straight forward:
Go to iCloud Settings and click on the Manage button under Custom Email Domain
Click Add a domain you own
Select if this is for a single person or for a family account (I believe this controls if the domain is made eligible for family sharing)
Enter the domain
When entering existing emails, only enter the ones that already exist
Enter the DNS records (MX, SPF, DKIM, TXT, etc) that Apple provides into your DNS configuration
Test sending an email
If you have the legacy Gmail account and the new/updated iCloud account both in the Apple Mail app on a Mac, you can just copy and paste to migrate all old emails (I moved thousands of messages going all the way back to October 2010 in about 5 minutes with this process)
At this point my plan is to just let my old Google account exist, but I expect Google will make it inoperable on their announced timeline.
My wife was watching Shark Tank a few weeks ago and we were both chatting about a thing we saw (which wasn’t funded). It was kind of a clever idea, and I’ll sidestep the entire discussion of whether or not it is a “good” product or not, I just wanted to see what it would take to build something kind of like it (this is loosely inspired by LoveSync, but the LoveSync does have some interesting features around time and also their hardware is much prettier than what I’m using).
As a quick aside: this method of asynchronous communication in which parties are only notified after reaching consensus seems like an interesting UX pattern. I was very interested to see almost the same pattern pop up (in almost the exact opposite context of LoveSync) in the form of the Bail App, which I believe is still in development (if it’s even feasible).
So, to the meat of the project: this project is 2 IoT buttons hooked up to an Azure IoT Hub which trigger Azure functions and make use of Azure Table Storage for data persistence. When consensus is reached, a notification is sent via Twilio to all interested parties.
To start, configure the Rebutton to communicate with your IoT Hub. The docs do a pretty good job of describing this.
Ensure that the buttons are communicating with the hub. This command will let you see events as they come from the event hub: az iot hub monitor-events -n <yourapp> --properties anno sys --timeout 0
In the Azure Function Apps blade, you’ll need to create the following functions
Event Hub Function
The first of the three functions needed is the function which will process event hub messages. At a high level all this is doing is being invoked any time an event occurs and then just writing the event data to the Azure Table Storage table defined in the configuration. You’ll need to configure it something like:
The timer is the next function. It runs on whatever cron schedule is defined (I currently have it running every 10 minutes), and it just looks for consensus in the table for both configured devices. Consensus in this case is defined as one or more single-click events from each device. If any non-single-click events are discovered, then it is assumed that consensus is impossible, and the messages will not go out. It would be an interesting exercise to extend the current logic and use the other button events (double-click, long-press, super-long-press) for other functions.
Upon discovering consensus, the timer function writes to an Azure Queue and writes a “FINISH” record to the table storage to prevent the next run of the function from also triggering a message.
The code for it is here.
Queue Trigger Function
The final function needed is the queue trigger which is responsible for actually sending the messages to Twilio. The code is incredibly simple as Azure has a pre-built integration with Twilio which abstracts away the vast majority of the code that would otherwise need to be written.
At this point, everything should be wired up, so pressing both buttons should trigger the Twilio message.
Assuming usage remains fairly constant, Azure forecasts that I’ll spend ~$0.30 per month, plus ~$50 for the buttons. I think it’s worth it for the fun I had building this, plus if the current application of the buttons gets stale, I’m sure I can repurpose them for something else. Interestingly, these buttons are built on the Arduino platform, so conceivably I could do a whole lot of customization by changing the firmware around (which might happen eventually).
This was a fun project which didn’t take very long to put together and entertained me. It was a timely project for Valentine’s Day. If you end up building something like it or have any feedback on this article, please reach out, I’d love to hear!
The Microsoft.DotNet.Web.Spa.ProjectTemplates::2.0.0-rc2-final SPA template currently has a little issue with making EF work properly. If you encounter this issue you’ll notice that running Update-Database in the Package Manager Console results in ng serve being run, which prevents the migrations from being applied.
To fix the issue, we need to slightly change Program.cs and Startup.cs as follows:
public class Program
public static void Main(string args)
// This needs to have all of the code originally in BuildWebHost
// This is only invoked by EF
public static IWebHost BuildWebHost(string args) =>
.ConfigureAppConfiguration((ctx, cfg) =>
.AddJsonFile("appSettings.json", true) // require the appsettings file!
In Startup.cs look for app.UseSpa inside of Configure:
// To learn more about options for serving an Angular SPA from ASP.NET Core,
// see https://go.microsoft.com/fwlink/?linkid=864501
spa.Options.SourcePath = "ClientApp";
// Get the "DesignTime" configuration param set above
bool.TryParse(Configuration["DesignTime"], out var designTime);
// Only launch the server if we are in development mode AND we are not in design time (which is EF)
if (env.IsDevelopment() && !designTime)
With those changes Entity Framework starts working perfectly again. Hope this saves people a few hours.