Forem: Laura Weatherhead

Umbraco in the City - Community, Code, and Cuddles

Laura Weatherhead — Mon, 10 Nov 2025 12:37:40 +0000

Last Friday, I had the excitement of attending the first-ever Umbraco in the City conference in Manchester—with a twist. My nine-month-old was my plus-one for the day, and honestly, I wasn't sure how it would go. Would I catch any of the talks? Would the baby cooperation gods smile upon me? And add to that my new role as part of the Developer Relations team at Umbraco, I wasn't quite sure who to show up "as": developer, community member, candid contrib, HQ'r, or mother?

TLDR: The baby cooperation gods did smile, the Umbraco community showed up in the most wonderful way, and I got to be all of the above ❤️

Before I dive into the excellent technical talks I saw, I just want to say a really heart-felt thanks to the organising team - Adam Prendergast, Phil Whittaker, Rachel Breeze and Jon Whitter - who created a genuinely inclusive space. Bringing a baby to a tech conference isn't exactly standard operating procedure, but the organisers made it work without batting an eyelid. From the welcoming atmosphere to the practical accommodations, they showed that "friendly" isn't just a word we use—it's a practice.

And this matters. It matters that people at different life stages can still show up, learn, and contribute. It matters that we're building a community where participation doesn't require leaving parts of your life at the door.

So, thank you to everyone who made it possible. You set a wonderful example for what tech events can be.

Despite my adorable distraction, I managed to catch some really excellent sessions. Matt Brailsford delivered what might have been my favourite talk of the day—a beautifully illustrated exploration of vibe coding vs spec-driven development and an exploration of when we need to stop exploring a problem space with AI as a copilot and instead write a proper technical specification to use it as a tool.

Matt's talk hit home because we've all been there: riding the wave of intuition, letting AI suggest the next line, feeling productive... until suddenly we're three refactors deep and not entirely sure what problem we're solving anymore. He did a super job of explaining where AI sometimes makes a problem harder rather than easier, and I'm looking forward to trying out SPECKL which is a toolset aimed at finding that middle ground between vibes and full specifications.

I also thoroughly enjoyed sessions from Jonny Muir and Matt Wise, both of whom took us on some really fascinating journeys from the land of accessibility in Jonny's talk to the land of vibe coding in Matt's.

Over lunch, I had the privilege of joining my fellow Candid Contributions podcast hosts, Carole, Emma and Lotte, on stage. It had been a couple of years since we'd all been in the same physical location together so we were super excited about being there. We talked about the landscape of open source contribution in a project where there's already significant in-house development happening at Umbraco HQ. It's a fascinating dynamic—how do we make space for community contributions when the core team is so active?

We had some great input from the audience - and from Paul Seal, Michael Latouche and Kieron McIntyre in particular. Hopefully everyone enjoyed joining for a wee lunch break chat! If you fancy catching up with us, you can give the episode a listen.

Walking away from Manchester (baby on hip, head full of ideas), I felt deeply grateful. Grateful for a community that makes space for everyone. Grateful for organisers who put in the work to make events accessible. Grateful for speakers who challenge us to think more carefully about our craft.

And grateful for a nine-month-old who, against all odds, decided that yes, a tech conference could be fun.

9 Tips and Tricks for Chrome Dev Tools

Laura Weatherhead — Sun, 30 Dec 2018 10:22:51 +0000

Chrome is increasingly not just a browser of choice, but also a powerful development tool in its own right. New features are regularly introduced, some of which fall more naturally into (my) development cycles than others.

Here are some of the features I make the best use of and think are worth a wee highlight:

1. Conditional Breakpoints

Adding breakpoints to the script sources is an incredibly helpful way to know what's going wrong (or right!) and where. Being able to add conditional breakpoints helps you to get to the root of a problem even quicker by specifying parameter criteria that you are interested in investigating further. Ideal!

Read more about conditional breakpoints here.

2. Watch variables

It is possible to interrogate variables in the sources window when a breakpoint is engaged. This looks a bit like this:

This is fine, but say you want to keep an eye on multiple variables at the same time or want to compare, or just remind yourself what they are (or should be), then it's possible to expand the watch panel on the right-hand side and add as many variables there as you'd like:

3. Stop Infinite Loops

If you have ever accidentally run a javascript function, realised a second too late and had to watch as your computer begins to grind to a halt as you feverishly try to force quit Chrome, then this one is for you...

Hit pause script, and then...

Read more about stopping infinite loops here.

4. Measure interactions

Ever wanted to know how long something takes on a website...?

How long after page load does someone play a video or click a button?
Where are the performance bottlenecks? How long does a script method take to run?

You can now use window.performance to trigger measurement starts and completions, and consequently extract the data.

onPageLoadOrMethodStart() {
    window.performance.mark('start');
    ...
}

onMethodCompletionOrCtaInteraction() {
    window.performance.mark('end');
    window.performance.measure('customMeasure', 'start', 'end');
}

retrieveData() {
    const customPerf = window.performance.getEntriesByName('customMeasure')[0].duration;
}

Handily, the data is also printed out in the performance window on the top panel, so you can see all measurements at a glance. Awesome!

Read more about measuring real world interactions using the User Timing API.

5. Pretty print minified files

Minified files in production are industry standard, and are to be expected, but sometimes it's handy to attach breakpoint or look into individual structures or methods. Make it readable - make it pretty! (bottom left-hand corner of the sources panel):

6. Monitor Events

Ever wondered why your event listeners weren't firing, or were firing at random times?

You can track page events and interactions using the console.

Try it now:

Right click and "inspect" the search input bar at the top of the page
Copy this into the console: monitorEvents($0, "key");
Type something into the search input...

7. Export Requests Data

You've got a problem. Something looks weird, but you're not sure why. You've got heaps of network requests to sift through, the answer must be in there somewhere... You could really use a hand, wouldn't it be handy to share them with someone else?

You can!

You can download the requests as a HAR file, and send it to a colleague who can import it into their Chrome to cast an eye over the requests also. Simply right-click on any request and select Save as HAR with Content. Ta-da.

Read more about exporting requests data and how to analyze HAR files.

8. Enable dark theme (purely aesthetic...)

Open dev tools > go to Settings

Toggle it!

9. Chrome Extensions

There are also a load of really handy extensions for use with various frameworks and tools. Ones that I have found particularly useful are:

VueJS dev tools (Really excellent user experience)
ReactJS dev tools
Google Analytics

Learn. Do. Teach.

Laura Weatherhead — Mon, 17 Dec 2018 14:24:48 +0000

In the drizzly February of 2015, I was in San Francisco with a gaggle of Scottish women visiting some of the big tech giants such as Pinterest, Facebook and Google. Whilst there, we were invited to IDEO.

For those who are unaware, IDEO is a digital product design company based out in Palo Alto (amongst other places) and they are connoisseurs of human-centred design. Some examples of their ideology include:

Employing a 96-year-old woman to design and build a range of products to support the elderly.
Having an entire PlayLab which makes your inner child want to crash out on the beanbags and play with magic.
Building fantastic projects such as a sassy parking space assignment chatbot.

One thing that really stood out to me during our visit was their mantra of employee progression: Learn-Do-Teach. I have used it as a signpost in my own career ever since.

At its core, the idea is simple, they ask:

For each skill that you possess, where is it on the learn-do-teach scale?

For example, a high-level snapshot of my own LDT scale at the moment:

I know that I'm happiest when I have pending learning to supplement what I am already actively dabbling with, but it's different for everyone. There are some paradigms (such as C# .NET) that I will never feel I fully "know", but always work with and am capable of teaching aspects of...! It always depends, and it's always a fluid model - the joy of being a developer is that you can never really stop learning! <3

As we come to the close of 2018, now might be a good time to line up your own learnings or teachings. What's next for you?

What were (or are) your initial thoughts about the technology/software development industry?

Laura Weatherhead — Sun, 09 Dec 2018 10:45:28 +0000

“It’s all men.”

“You need a technical degree before you can even knock on the door.”

“Everybody is really clever.”

I’m curious... how do we, as a technical industry, initially present to groups like:

new starts?
juniors?
graduates?
people making lateral moves from other industries?

But also children, or parents? What do they think the unwritten rules of working in technology are?

Doesn’t matter if you’ve dispelled them now or if they are actually true - every viewpoint is valid:

What did you think the rules were?

Azure Web Apps - the troubleshooting era

Laura Weatherhead — Wed, 05 Dec 2018 21:12:33 +0000

So I am in something of a complicated relationship with Azure.

I like that (in general) it makes my life easier.
I like that hooking up continuous integration is so incredibly easy.
I like that managing deployment slots and setting up new ones is logical and can be done quickly (albeit with something of a deployment wait); and I like that you can configure instances that will scale up or down depending on the demands that are made on their resources.

I don't like how long everything seems to take to update/deploy/propagate.
I don't like that the UI seems to have been built by about 200 people in simultaneous development so that sometimes things happen automagically and sometimes you have to hit 8 different confirm buttons before it registers that yes, you really do want to do that.
I don't like trying to troubleshoot performance issues when there are so many different places for logs/analytics/insights.
And I don't like that occasionally their idea of an error message is an unhappy cloud.

I got 99 problems (well not concurrently, but that's how it felt)

Recently, I was trying to get to the bottom of some rather frustrating performance issues on our Azure cloud catalog.

The symptoms included:

intermittent downtime
slow app restarts
laggy front-end performance

One NET Core app in particular was very sickly and would classically take 7-8 minutes to find it's wee feet again when restarted. Bafflingly, it was also one of our simplest, smallest, lowest traffic apps, so what gives?

Have you tried switching it off and on again?

Cue a montage (although in reality it was more an increasingly frustrating, ever-decreasing spiral) of trailing through spiky graph after spiky graph in Application Insights, downloading memory dumps, clicking hopefully through every log folder on blob storage and tentatively poking through various routes on the "Diagnose and Solve Problems" dashboard which wants to "chat" to you. Endearing.

I started using phrases like "possible thread starvation" when colleagues asked how I was getting on, and spent enough time reading about startup configuration in Net Core that I was able to troubleshoot app bootstrapping at 50 paces, and yet still felt no closer to a solution.

Although, that's not strictly true. I knew a little more about why things were happening...

we have ~7 production sites sitting within one App Plan, and this plan scaled up and down on a schedule (7am and 10pm) as well as when resources were under pressure or released outwith this period
when the plan scaled, the app service instances within it were either spun up or wound down for the sites and it was this period that made the poor wee Net Core app the most unhappy
the Net Core app was the one which Pingdom kept pulling up for downtime issues, but actually all of the apps had a bit of a wobble during the restarts (they were just sitting under a different alert criteria, doh!)

With this information, I could at least narrow my conversation with Google from the abstract and teenage-angst flavoured "but why?" to a more concrete "managing azure app restarts" and "configuring multiple instances of net core apps". This was small but hopeful progress.

Cutting a long (and, oh, terribly exciting) story a bit short

Further investigation and coding montages led me to a set of guidance that I will lay here for future reference, and for any who are also trying to nurse sickly Azure Web Apps back to health:

First, and the biggest win for me: the AlwaysOn setting on the Application Settings tab. For those not familiar:

When Always On is enabled on a site, Windows Azure will automatically ping your Web Site regularly to ensure that the Web Site is always active and in a warm/running state. This is useful to ensure that a site is always responsive (and that the app domain or worker process has not paged out due to lack of external HTTP requests).

Extracted from Scott Guthrie's blog

Sound sensible eh? And it is - on production sites. But, and here is the small hole we'd dug for ourselves having been lent a shovel by Microsoft, it is not a slot specific option so - to avoid production sites idling by accident after a staging swap - we had the AlwaysOn option always on. On every slot. On every environment. For every project.

That means that every time our 7 production sites scaled up, we'd get (e.g.) 2 instances of each, and both of these would get restarted and warmed up and then pinged to ensure they are AlwaysOn. So far, so good. But then all of the staging and dev slots would be pinged and forced to start up and the sheer volume of I/O totally destroys the performance of, well, pretty much everything and gives the perceived downtime. Why does Azure Web App suffer so much with this? That's a different kettle of fish.

There's no nice way of managing this for us at the moment - if you handle slot swaps with a script I imagine you can toggle the AlwaysOn option post-swappage. We've just had to add it as a manual check at the end of a deployment. It's not the end of the world, but it's certainly a little irritating nuance to be aware of!

Other, smaller, wins included: moving from IMemoryCache to IDistributedCache on the Net Core app (to minimise I/O storage writing, and to enable us to take future advantage of load balancing), and ensuring that HTTPS Only flag is set to true so that the app initializer isn't bounced around anywhere silly on startup.

Net Core security - NWebSec to the rescue!

Laura Weatherhead — Fri, 30 Nov 2018 15:18:39 +0000

A quick overview of securing a Net Core webapp using NWebSec and the web.config

First up, let's install NWebSec middleware from nuget via the package manager

PM> Install-Package NWebsec.AspNetCore.Middleware

For those of you (like me) who are a little rusty on security best practise, two of the general principles are:

Reduce attack surface (make it as hard as possible for potential attackers to glean information about your app)
Restrict access (unless securely authorised)

The ingredients for a safe Net Core app broadly feed into these practises and include the following (non-exhaustive) list:

[HSTS] HTTP Strict Transport Security Header
X-XSS-Protection Header
X-Frame-Options Header
[CSP] Content-Security-Policy Header
X-Content-Type-Options Header
Referrer-Policy Http Header
Remove the X-Powered-By header to remove the additional information transferred by verifying the app tech
[HPKP] HTTP Public Key Pinning Header

Let's take these one at a time!

[HSTS] HTTP Strict Transport Security Header

This is what it sounds like - force all comms to go through HTTPS! Using the .Preload() indicated below forces it from the first request.

app.UseHsts(options => options.MaxAge(365).IncludeSubdomains().Preload());

X-XSS-Protection Header

This response header prevents pages from loading in modern browsers when reflected cross-site scription is detected. This is often unnecessary if a site implements a strong Content-Security-Policy (spoilers!)

app.UseXXssProtection(options => options.EnabledWithBlockMode());

X-Frame-Options Header

Ensure that site content is not being embedded in an iframe on other sites - used to avoid clickjacking attacks.

app.UseXfo(options => options.SameOrigin());

[CSP] Content-Security-Policy Header

The content security policy essentially allows you to whitelist resource origins when the site is loaded. These policies are usually to do with server and script origins.

There are a heap of different ways you can configure this and they are very much dependent upon your requirements and what you need to load in and out. You can read more about your options in the handy Mozilla docs

An example would be:

app.UseCsp(opts => opts
    .BlockAllMixedContent()
    .StyleSources(s => s.Self())
    .StyleSources(s => s.UnsafeInline())
    .FontSources(s => s.Self())
    .FormActions(s => s.Self())
    .FrameAncestors(s => s.Self())
    .ImageSources(s => s.Self())
    .ScriptSources(s => s.Self())
);

X-Content-Type-Options Header

Blocks any content sniffing that could happen that might change an innocent MIME type (e.g. text/css) into something executable that could do some real damage.

app.UseXContentTypeOptions();

Referrer-Policy Http Header

This tells the site how much information to send along in the Referer header field (misspelt!). Default value is no-referrer-when-downgrade i.e. don't send any referrer data is we're downgrading security protocols and going HTTPS to an HTTP site.

This one depends a bit on your requirements, the options are listed in detail on Mozilla's dev site to help you make a decision. If you want to be super safe, then opt for:

app.UseReferrerPolicy(opts => opts.NoReferrer());

Remove X-Powered-By Header

Now let's make sure that we're not giving information away regarding the technology in use (i.e. ASP.NET). To do this, we'll remove the X-Powered-By header by adding to the web.config

<system.web>
   <httpRuntime enableVersionHeader="false"/>
</system.web>
<system.webServer>
   ...
   <httpProtocol>
     <customHeaders>
        <remove name="X-Powered-By" />
     </customHeaders>
   </httpProtocol>
</system.webServer>

[HPKP] HTTP Public Key Pinning Header

This one is interesting and to do with the whitelisting certificates. There are couple of plugins you can use to facilitate this and it's covered comprehensively in @JoonasWestlin blog here

Further links/reading: A good tool to test the security headers is using Geek Flare and a wealth of easy to digest information for general .NET security best practise is available at OWASP.org

This is just a quick point of reference to get started on Net Core site (mostly header-based) security - what's missing? Other recommendations?

The Happy World of ngrok

Laura Weatherhead — Tue, 27 Nov 2018 12:46:50 +0000

Current favourite tool: ngrok

Have you ever wanted to share something still in development with a product manager, project manager or even another developer just so they could give it a quick click through, maybe give you some pointers, nothing too intense?
Have you ever been working with a third-party service (Mailchimp, SendGrid, SparkPost, Twilio, Authy, the list goes on…) and want to use a webhook to channel data around on a dev site?
Have you ever been giving a dev talk and thought “it would be great if people could just access this site I’m running locally”, but you don’t want to deploy anything?

Ngrok is the answer. It’s a command line tool that gives access to your local server using a secure URL and an excellent debugging/inspection panel to boot.

It is the best thing. No, really. I am prone to occasional geeking-out on technology-fronts (a certain ramble about how finding the perfect monitor configuration could equate to finding true love springs to mind), but trust me on this one.

Reasons why you should love ngrok as much as I do:

It’s free! (I mean, you can pay if you want custom subdomains etc, but for most development/testing needs the free version is where it’s at)
It’s as easy as cmd ngrok http 80 and boom, you’re up and running
But what if you’re running on IIS express? That’s super easy too: ngrok http -host-header="localhost:[port-number]" [port-number]
The inspection panel is unexpectedly helpful, I’ve never felt so supported by a tool. I mean, I love Fiddler, but there’s just so much functionality I often feel like I’m shortchanging it a bit... (like someone built me a mansion and I’ve moved into the larder to live)

Just to be clear, I am in no way affiliated with ngrok or it’s devs, I am just excitable when it comes to speeding up my own dev processes!

Download it here: https://ngrok.com/download