Categories
Google Tables

How to use Google Tables outside the US

Google recently launched a new product called Tables – a lightweight database similar to the likes of Airtable.

However being in beta, and launched by Google’s incubator Area 120, it’s only officially available in the United States for now.

But if you’re outside the US, at least for now you can still access Tables using the following method. Note that the usual caveats apply, in that Google may block this at any time and your success may vary.

  1. Sign up for a free trial of a VPN with a United States point of presence, such as encrypt.me
  2. Configure your computer/Mac/phone to use the VPN. Normally that involves downloading an app provided by your VPN provider.
  3. Enable the VPN, and open the Google Tables site. Click “Get started” in the top right-hand corner to login.
  4. You should get prompted to sign in with your Google Account. Enter your Google credentials, and as long as your VPN is active you should be able to login and start using Tables.
  5. If you’re not able to login still, make sure your VPN is located in the United States. To configure this in encrypt.me, go to Preferences > Transporter > North America > United States and choose a location.
Categories
Google Tables

Meet Google Tables – Google’s Airtable competitor

Google – through its incubator Area 120 – recently announced its own Airtable competitor, Tables. In this post we’ll take a look at how you can get started with Tables.

Meet Google Tables

What is Google Tables?

Think of Tables as a lightweight spreadsheet, similar to Microsoft Access database, or a competitor to Airtable. Using bots, you can create automations that do everything from emailing people when rows are added or changed, to modifying other rows or posting to a webhook.

Google Tables beta, available now in the United States.

Is Tables free?

Yes, there’s a free plan available. However it limits the number of rows you can have in a table to 1000, and you can only have 100 tables in total.

The paid plan ups that to 10,000 rows across 1000 tables, as well as providing more generous attachment sizes and actions.

Why use Tables instead of Google Sheets?

At this point Sheets are far more advanced than Tables. If you’re after functionality like formulas, you’ll want to stick to Sheets.

Tables really shines for lightweight data, like form responses and datasets that you might otherwise look to store in a database.

Be sure to check out Tables pricing too, as Sheets might be able to meet your needs for free.

Also note that Tables is still a part of Google’s incubator Area 120. As such it’s essentially still classified an experiment unlike Sheets, which is a fully-fledged Google product. This means there is no guarantee of Tables continued availability – particularly given Google’s history of losing interest in its experiments.

What other features does Tables have?

Tables allow you to create forms to allow anyone to input data into your tables. The form title, description and submission message can be customised, as can the layout of fields on the page. Each field maps to a field in your table, and can be hidden or marked as required.

The other powerful feature of Tables is automations via Bots. Bots allow you to perform various actions based on a set list of triggers, which include insertion or deletion of rows, column value changes, and cron or time-based.

What’s the difference between a workspace and a table?

A workspace is a collection of tables. Each table stores a particular set of data, organised into columns and rows. Workspaces can be shared with other people.

Where is Tables available?

Officially at the moment only those located in the United States can use Tables. But if you’re still keen to try it out, follow these steps to get access from anywhere.

Categories
Microsoft Teams

Microsoft Teams training resources

So your team is looking to start using Microsoft Teams as a form of internal communication? We’ve compiled a list of the best Microsoft Teams training resources for getting everyone up to speed about how to make the most out of the service.

While this list is far from conclusive, many of the resources below cover end-user and admin training, while some are more targeted to one scenario or the other.

Microsoft training

Free, Microsoft Training

If you’re looking for the best free training, it’s hard to go past Microsoft’s official training resources. Microsoft has created training for admins and end-users.

And if reading guides isn’t your thing, they even run free instructor-led sessions that anyone can sign up for, and run on a frequent basis.

Microsoft Teams essential training

Paid, LinkedIn Learning

One of the most-watched Microsoft Teams courses on LinkedIn Learning, this course will run you through the basics of setting up a Microsoft Teams workspace.

It then dives into incorporating the best of Teams functionality into your team’s workflow. A quiz at the end of each chapter helps recap what you just learnt.

Mastering Microsoft Teams Training

Paid, Udemy

While this training was recorded last year, the majority of the content remains relevant when using Microsoft Teams. Heavily focused on end-user functionality, this course won’t satisfy those looking for admin tips.

The course has some good content, and can be had at a more affordable price than the LinkedIn Learning course.

Adopt & Embrace Microsoft Teams

Paid, Amazon

If a book is more your thing, and you’re after a book that covers integrating Microsoft Teams within your team’s workflow then Adopt & Embrace Microsoft Teams is a solid buy.

The book covers integrating Microsoft Teams from a manager’s perspective, and includes chapters on getting to know Teams, through to some principles and best practices.

Categories
Azure DevOps

How to fix Azure DevOps library group permission errors

Are you trying to edit a variable group in an Azure DevOps Library, and getting the error “you do not have permission to create a variable group within library“? Continue on to find out how to rectify this issue.

The problem

DevOps project settings – these don’t apply to variable groups

Variable groups within Azure DevOps can have different permissions to your project settings. This can be useful to limit the number of people who can view and edit your config values, but can be confusing.

As such, while you may have appropriate permissions to edit and your project you may find yourself unable to create variable groups within your Azure DevOps instance.

If this has happened to you, you’ll be shown an error something along the lines of “Error: you do not have permission to create a variable group within library.”

The fix

Luckily there’s a quick fix to this issue, although it will require you to find someone with the correct administrator privileges first.

Once you’ve found the person who has the correct privileges, navigate to your project in the DevOps portal, and create a new group. Alternatively, if this is an existing group click on the title of the group you wish to edit.

If you did create a new group, name it and make sure at least one variable exists. Note that this can be a dummy value – but without a variable DevOps won’t let you save the new group.

Then, within the edit group screen, select “Security“. The title of the modal that appears should be something like “Assign security roles for Library/<your group name>”. If it’s not, make sure you selected the group first and that you haven’t clicked “Security” from the main Library screen.

Security roles apply to variable groups

DevOps libraries have 3 tiers of roles/permissions:

  1. Reader: Can only view items within the library
  2. User: Can use items within the library, but can’t edit them
  3. Administrator: Can use AND manage items within the library

Search for the user(s) you want to be able to add and edit variables (and to avoid the above error) and choose the “administrator” role.

Click “Add”, close the modal and then click “Save”. The above error should no longer occur for users trying to edit or create variables in the DevOps library.

Categories
Microsoft Graph

What is the Microsoft Graph?

Ever heard someone mention the Microsoft Graph and not known what it is? In this article, we’ll dive deeper into what the graph is and what it can provide you access to.

What is the Microsoft Graph?

In a nutshell, the Microsoft Graph is designed to be a one-stop shop (ie a single endpoint) for interacting with the Microsoft suite of products. For now it’s limited to only a subset of Microsoft’s product range, but Microsoft has grand ambitions for continuing to grow this over time.

Delve, Excel, Microsoft Bookings, Microsoft Teams, OneDrive, OneNote, Outlook/Exchange, Planner, and SharePoint as well as many enterprise and mobility services are currently supported.

The key difference between the Microsoft Graph and Microsoft’s previous service-specific APIs is that the Graph is designed around user scenarios and is independent of the service that customers may interact with.

For example, where previously you may have directly called anOutlook API to access a user’s calendar, using the Graph you simply interact with Calendar data directly without caring about the service.

One side-effect of the Graph is that instead of each Microsoft product having its own platform-specific SDK, you can use one SDK to access them all. You can find a full list of the SDKs here, but platforms include iOS, Android, .NET, PHP, Ruby and Python.

Does the API use GraphQL?

No – while the “Microsoft Graph” name may confuse some, the API itself is a normal REST API and doesn’t use GraphQL at this point in time.

Can anyone use the API or do you need to be a partner?

Anyone can sign up to use the Graph API for free.Many of the customer scenarios around email, contacts and calendars are available for use in production apps today.

Keep in mind that some APIs are still in beta (such as The ones backed by Microsoft Booking) and as such shouldn’t be used in production apps yet.

Categories
Azure

Creating your first Azure Resource Manager (ARM) template

If you’re manually creating infrastructure for your next app in Azure, you should consider using an Azure Resource Manager (ARM) template.

An ARM template is essentially a JSON file that describes the infrastructure you want to create in the Azure cloud. It can be run as many times as you like to spin up identically-configured environments.

Create the template

The first step when using an ARM template is to create the template file. If you’d rather start with an example template, Microsoft has an entire Github repo with some templates that you can clone.

The base template – normally called azuredeploy.json – is made up of the following structure:

{
  “$schema”: “https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#”,
  “ContentVersion”: “1.0.0.0”,
  “Resources”: []
}

The elements can be described as follows:

  • $schema: Refers to the properties that can be used within the template. If you were to load the URL in your web browser, it would return the elements and a description of each that you can use within your template. When uploading a template, these get validated to ensure you haven’t made any mistakes.
  • contentVersion: This is an internal version number for you to use to reference the current template. It should be in the format X.X.X.X, with X being any integer. You should only change this value in your template when a significant change is made.
  • resources: This is an array that will contain a description of all the Azure resources that your app or service needs. For now it’s empty.

Add resources to the template

As mentioned above, within the resources section of the template you need to describe the Azure services that you wish to provision. Each Azure service has a set of properties that can be set, with some mandatory. By default, a resource requires:

  • type: The type is a string that refers to a namespace of the resource provider and the name of the type of resource that you wish to provision. For example, Microsoft.DocumentDB/DatabaseAccounts implies you want to create a DatabaseAccount from the Microsoft.DocumentDB namespace
  • apiVersion: Similar to the template $schema version, each Azure resource type also publishes versions of their schema. This property allows you to specify which schema or version of the resource type you’d like to use and is mandatory
  • name: The human-readable string name that you’d like the resource to be called

While not mandatory, a location element is normally provided as well to specify the location where you want the resource to reside (eg. Australia East).

Luckily Microsoft publishes a full list of properties for each resource type. But if you’re still not sure, for most resources you can manually create the resource using the Azure Portal and go to the “Export Template” tab for the resource, and Microsoft will generate a template for you.

For this tutorial, let’s create a simple functions app. Add the following to your resources section in your azuredeploy.json file:

   "resources": [
        {
            "type": "Microsoft.Web/sites",
            "apiVersion": "2018-02-01",
            "name": "[parameters('siteName')]",
            "kind": "functionapp,linux",
            "location": "[parameters('location')]",
            "dependsOn": [
                "[resourceId('Microsoft.Web/serverfarms', variables('hostingPlanName'))]"
            ],
            "properties": {
                "name": "[parameters('siteName')]",
                "siteConfig": {
                     "appSettings": [
                        {
                            "name": "FUNCTIONS_WORKER_RUNTIME",
                            "value": "python"
                        },
                        {
                            "name": "FUNCTIONS_EXTENSION_VERSION",
                            "value": "~2"
                        }
                    ]
                },
                "serverFarmId": "[resourceId('Microsoft.Web/serverfarms', variables('hostingPlanName'))]",
                "clientAffinityEnabled": false
            }
        },
        {
            "type": "Microsoft.Web/serverfarms",
            "apiVersion": "2018-02-01",
            "name": "[variables('hostingPlanName')]",
            "location": "[parameters('location')]",
            "kind": "linux",
            "properties":{
                "reserved": false
            },
            "sku": {
                "Tier": "Dynamic",
                "Name": "Y1"
            }
        }
    ]

The above creates a Linux App Service hosting plan. It uses the consumption function tier (Y1) and isn’t a reserved plan.

The template also creates a function app (Microsoft.Web/sites) that dependsOn the hosting plan.

If you look closely, you might notice that some elements refer to variables and parameters. Let’s dive deeper into what they are.

What are parameters?

Parameters allow you to specify a value each time you deploy a template. For example, if you had a template and wanted to create a production and staging environment with it, you could create a environment parameter that would allow you to specify staging or production in resource names without modifying the template file each time.

If you didn’t use a parameter, you’d need to change the hard-coded string value in your azuredeploy.json file each time you wanted to change to a new environment.

Similarly if you wanted to be able to deploy your template to a different Azure location quickly, you could specify a location parameter. Then you could deploy to any Azure region by simply providing a new location parameter value – with no change to the template file required.

Within the template file, parameters sit in a top-level parameters element as follows:

{
  “$schema”: “https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#”,
  “ContentVersion”: “1.0.0.0”,
  “Resources”: [],
  “Parameters”: {
    “hostingPlanName”: {
      “type”: “string”,
      “DefaultValue”: “”,
      “Metadata”: {
           “Description”: “The name to give your hosting plan”
      }
   }
}

Parameters support a number of elements, but the most common include:

  • type: The type of value provided (eg. String)
  • defaultValue: A default value to use if one isn’t provided when the template is deployed
  • metadata.description: A description of what the parameter represents

Parameters can be set when deploying using the Azure CLI or PowerShell. Here’s an example of how you would provide a location parameter using the Azure CLI:

az group deployment create \
  —-name mytemplatename \
  —-resource-group yourResourceGroup \
  —-templateFile $templateFile \
  —-parameters environment=staging

Referencing the parameter is done using the following syntax – you can see a full example in the template we defined earlier with resources:

"location": "[parameters('location')]"

What are variables?

While parameters allow you to specify values when deploying a template, variables allow you to reuse values internally within your template file without duplication. For instance, if you had a value that you use in 3 different resources (such as a location or in the example above the hostingPlanName) that you didn’t want to expose to those running your template you could use a variable.

Like parameters, variables are also top-level elements. They’re simpler to specify, as you don’t need to provide descriptions, types and default values. They look like this:

{
  “$schema”: “https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#”,
  “ContentVersion”: “1.0.0.0”,
  “Resources”: [],
  “Variables”: {
     “HostingPlanName”: “yourHostingPlanName”
  }
}

You can then reference the variable within your resource definitions using the following syntax as seen in the resources section in the template we created earlier:

"name": "[variables('hostingPlanName')]"

Summary

In this post, you’ve learnt about how a template is structured, and what each element means. Stay tuned for our next post on deploying your template.

Categories
Azure DevOps

Azure DevOps system variables now read-only

Azure DevOps provides a number of predefined system variables out of the box on hosted build agents.

While these have officially always been read-only, informally you’ve previously been able to change the value of a predefined system variable by overwriting it in a pipeline task.

However, as of the January 28 2020 DevOps release this is no longer the case. The DevOps team have improved the security of system variables, and as such now actively prohibit system variables from being written to.

The variables include items such as the DefaultWorkingDirectory, JobName and TeamProject. These are all variables that you can otherwise use and refer to in your DevOps pipeline tasks.

This means you’ll need to now create your own task or pipeline variables where possible. If you can’t modify the task or pipeline variables, speak to someone with admin rights who can.

Categories
Azure

Managed identities and Azure App Service staging slots

If you’re using an Azure App Service on a tier that offers staging slots (standard and above) then you might want to consider what happens when you swap a slot.

If you’ve configured a slot then you’ll want to swap deployments at a minimum between a production and pre-production environment. Microsoft cover in depth what happens when you commence a swap, but what they don’t cover is what happens to any managed identities that you have setup for the app service.

In short, managed identities are tied to the slot in which you first create or assign them, and do not change when you initiate a swap between two or more slots.

You might recall that for an App Service you can have both a system-assigned or a user-assigned identity. These are configured to allow your App Service to access other Azure resources, without the need for sharing secrets and passwords.

When swapping slots, both system and user-assigned identities remain tied to the slot. They don’t swap – so if you need to change these, you’ll need to intervene separately.

Once you’ve generated or assigned an identity, don’t forget to then add it to any Azure resources your app needs access to.

Also keep in mind the lifecycle of a managed identity. User assigned identities won’t be removed whenever you delete a slot. On the other hand, system assigned identities will be deleted as soon as you delete a slot. Depending on your situation, you may prefer one of these approaches.

Categories
Azure

Azure Availability Zones vs Availability Sets

A common question for newcomers to Microsoft’s Azure platform is what’s the difference between an availability zone and an availability set?

An availability zone is a unique physical location within one Azure region, and provides high-availability for your application and infrastructure. Each zone is independent and has physically isolated power, cooling, and networking from other zones within the same region.

Different Azure services have varying levels of support for availability zones. Some will automatically replicate between zones, while others will require you to choose the zone to connect to.

Availability zones aren’t available within all Azure regions – in fact, currently there are only 10 regions across the United States, Asia and Europe that support availability zones:

  • Central US
  • East US
  • East US 2
  • West US 2
  • North Europe
  • UK South
  • West Europe
  • France Central
  • Japan East
  • Southeast Asia

On the other hand, an availability set is a concept that only applies to virtual machines. A set allows you to isolate virtual machine (VM) resources from one another when deployed, meaning your VMs will run across multiple machines and racks. This will help to avoid a hardware failure bringing down your entire application, and also means that outages from Microsoft updates won’t cause your application issues.

Unlike an availability zone which applies at the data centre level, an availability set only applies within the same data centre.

Categories
Azure DevOps

How to retry a failed stage in Azure DevOps

One of the biggest limitations of Azure DevOps has until now been the fact that you can’t retry an individual stage or step in a pipeline if it fails. Instead, you’d have to retry the entire pipeline again and hope that the failed stage passes.

As of September 2019, in most cases you can now retry a failed stage without the need to retry the whole pipeline – but there’s a catch. You’ll need to enable the Multi-stage pipelines preview feature, if you haven’t already. Note that this still doesn’t allow you to retry failed steps within a stage – rather it relies on the new multi-stage support to allow you to retry a collection of steps within a stage.

You can check if this is enabled by clicking your avatar in the top-right corner of the Azure DevOps portal, and then “Preview features”. Select “for this organisation [<your organisation name]” from the drop-down menu at the top of the screen, and scroll down until you see “Multi-stage pipelines”. If this is toggled off, you’ll need to turn this on before you can retry failed stages – you will need administrator rights to change it though.

Once you’ve enabled this, navigate back to your release pipelines and you should see the ability to re-rerun individual stages that fail throughout your pipeline.

Note that as this is still in beta, there are some limitations. Perhaps one of the biggest is that you can’t retry stages that are explicitly cancelled – only those that fail as a result of the task being run having an error can be retried today.