Do you remember what a "normal" software team looked like?

A product manager, an engineering manager, a designer, and six or seven engineers. Weekly planning meetings, a backlog to groom, a sprint to run. For most of the last decade, that was just... how teams worked. It was the water we all swam in.

That was my daily life as an software engineer and then an engineering manager for most of my career. That shape was so familiar it felt like a law of nature rather than a design choice.

I recently came across an article on the LeadDev website that argued that traditional team shape is breaking apart - and fast. AI is reshaping the traditional team structure that engineering managers are used to, and the engineering manager (EM) role itself is splitting into two very different futures. One stays close to the code. The other expands outward across multiple teams, with ratios that would have seemed absurd five years ago.

It's a well-argued piece and I agree with most of it. But reading it, I kept thinking: there's a third role sitting right in the middle of this split that barely gets a mention.

The Technical Program Manager (aka a TPM).

I've spent time on both sides of the engineering/management divide. I've been an engineering manager, and I'm an IC now. And one thing that experience teaches you is that the messiest, most overlooked part of any org isn't the people management or the code - it's the space between teams. The dependencies. The cross-functional delivery risks. The "who owns this?" conversations that stall projects for weeks.

That's exactly the space that gets wider as teams shrink.

I know what you're thinking - aren't we just adding extra headcount? Not quite. A single TPM can serve across four or five of those small teams simultaneously, handling the cross-cutting work that would otherwise fragment across every Engineering Manager and tech lead in the building. It's not a new layer. It's a better shape.

That LeadDev article is really describing one thing: small, fast-moving, AI-augmented teams. Tech leads that are head down in the code. Wide-span engineering managers that are spread thin across five or six of those teams. Who's looking at the whole picture? Who's tracking that Team A's output is the input for Team B's Q3 milestone? Who's in the room when the product roadmap and the engineering capacity don't line up?

That work doesn't disappear just because management layers do. If anything, it gets harder.

A good TPM doesn't typically manage teams and doesn't write production code - but they hold the connective tissue of a programme together. They ask the questions that fall between job descriptions. They translate between engineering constraints and business timelines. They're technical enough to smell risk early and organised enough to do something about it.

In a world where your Engineering Manager is managing multiple engineers across multiple teams, the last thing they have time for is running a cross-team dependency log or facilitating a technical risk review. That's not a criticism - it's just scope. Something has to give.

The Technical Program Manager (TPM) fills that gap.

So why isn't this already the obvious answer? Partly because the TPM role itself is poorly understood. Ask ten people what a TPM does and you'll get ten different answers - some companies use the title for someone close to project management, others for a semi-technical lead, others barely use it at all. It's a role that's been historically inconsistent, which makes it easy to overlook when org charts get redrawn. But that inconsistency is also an opportunity - as the Engineering Manager role fractures, companies will need to define this connective-tissue work somehow, and the TPM title is sitting right there, half-formed and ready to be shaped into something more central.

What's interesting is that the skills which make a great TPM are almost the opposite of what each fork of the Engineering Manager role is optimising for. The Tech Lead path doubles down on technical depth. The wide-span Engineering Manager path doubles down on people skills and influence. The Technical Program Manager has to hold both - enough technical credibility to challenge engineering estimates, enough interpersonal range to keep a dozen stakeholders aligned.

If you're currently an Engineering Manager wondering which way to lean as your org flattens, it might be worth asking yourself: which part of the job do you actually find energising? The 1:1s and the career conversations, or the delivery and the cross-team puzzles? Because that second category - that's Technical Program Manager territory, and it might be a better fit than either fork.

And if you're an IC watching all of this from the sidelines, wondering where the growth paths go from here - don't sleep on it. The role is less visible than Engineering Manager and less glamorous than staff engineer, but in a flatter org running lots of small teams, it might just be the most useful person in the building. 🙂

Have you ever walked out of a 1:1 and realised you can't quite remember what you agreed on last time? Or spent five minutes before a catch-up scrolling through Slack threads, trying to piece together a conversation from three weeks ago?

I've been there more times than I'd like to admit. That's exactly why I built Meeting Notes - a lightweight, local-first desktop app for keeping organised notes with the people you work with.

Why I built it

Most of us are using the wrong tool for this. Notion is powerful but noisy. Word and Google Docs works, but it's not really shaped for quick, personal notes. And anything cloud-based means your candid thoughts about a tricky conversation are living on someone else's server.

I wanted something simple and fast. Something that felt less like a productivity system and more like a trusted notebook. No accounts to create, no syncing to worry about, no cloud. Just notes, stored on your machine.

What it does

The app is organised around people, not documents. You add the folks you meet with regularly - their name, role, and team - and every note you take lives under their profile. It builds up a natural history of every conversation over time.

Here's what's included:

• 📝 Track meeting notes for multiple people
• 👥 Manage contacts with names, roles, and teams
• 🏷️ Tag and filter notes by topic (things like hiring, architecture, or follow-up)
• ✍️ Markdown support with live preview and a formatting toolbar
• 🎙️ Voice recording with offline speech-to-text - record your mic and/or system audio and transcribe straight into the note
• 💾 Autosave every 20 keystrokes, so you never lose your work
• 🎨 Light/dark theme
• 💡 Discussion prompts suggested when you start a new note

And everything runs completely offline. Your data never leaves your machine.

The voice transcription feature

This is the one I'm most pleased with. Hit record, have your conversation, and the transcript drops straight into your note - all on-device using the Whisper model. No audio is ever sent anywhere. It even summarises what you discussed. I use it during walking 1:1s and it's become one of those features I didn't know I needed until I had it.

Give it a try

Meeting Notes is free, open source (MIT), and available now for Windows. Head over to the releases page to grab the latest version - just run the installer and you're up and running in under a minute.

👉 Download Meeting Notes - v1.2.0 · Windows x64

The source code is on GitHub too, if you want to take a look, contribute, or build it yourself.

If you've got any thoughts or run into anything unexpected, I'd love to hear from you - drop a comment or open an issue. Happy note taking! 🚀

Ever wished your AI assistant actually knew your stuff? Your files, your schedule, or even a custom data source? That's exactly what the Model Context Protocol (MCP) makes possible.

MCP is an open standard for connecting AI assistants like Claude to external data sources and tools. Think of it like a USB port for AI - a single, standardised connector that works with any compatible device. Build the server once, plug it into any MCP-compatible client.

In this guide, we'll build a custom MCP server from scratch using Node.js. The example is deliberately practical: a bin collection reminder system. Simple enough to grasp quickly. Complex enough to cover every core concept you'll need.

What is the Model Context Protocol?

MCP gives AI assistants a common language for talking to the outside world. Instead of every tool needing its own bespoke integration, MCP provides a shared standard.

Your MCP server exposes "tools" - functions that AI Assistants can call. The server does the work (reading files, querying a database, calling an API), then returns structured data. The AI Assistant handles the rest.

Right now, Claude Desktop and VS Code (amongst others) support MCP out of the box. The ecosystem is growing fast.

The Problem We're Solving

To build a basic example (and experiment with real data in my life) - I wanted to create an MCP server that gave me the details of my Bin Collections. I wanted to be able to run a simple chat query and get a response. Ideally, this would save me time logging onto my local council's website and entering my information time and time again.

Here's the scenario. Garden waste goes out fortnightly on Fridays. Recycling is every Saturday. General refuse is also fortnightly on Fridays - but on different weeks. It's surprisingly easy to get wrong, especially when you factor in that holidays throw the schedule off.

So we'll build an MCP server that Claude can query to answer questions like "when are my bins next due out?" A simple use case that's genuinely useful and it teaches you the full pattern.

Setting Up the Project

Create a new Node.js project:

mkdir bin-collection-mcp
cd bin-collection-mcp
npm init -y

You only need one dependency - the official MCP SDK:

npm install @modelcontextprotocol/sdk

Update your package.json to use ES modules. Add "type": "module":

{
  "name": "bin-collection-mcp",
  "version": "1.0.0",
  "description": "MCP server for local bin collection day lookups",
  "type": "module",
  "main": "index.js",
  "dependencies": {
    "@modelcontextprotocol/sdk": "^1.0.0"
  }
}

The Data Structure

Before writing any server code, think about your data. We'll use a simple JSON file - bin-days.json - that stores collection dates:

{
  "collections": [
    {
      "date": "2026-05-29",
      "day": "Friday",
      "types": ["garden"],
      "notes": ""
    },
    {
      "date": "2026-05-30",
      "day": "Saturday",
      "types": ["recycling"],
      "notes": ""
    }
  ],
  "binTypes": {
    "general": {
      "colour": "black",
      "description": "General household refuse"
    },
    "garden": {
      "colour": "brown",
      "description": "Garden waste - grass, leaves, small branches"
    },
    "recycling": {
      "colour": "blue",
      "description": "Paper, card, plastics, tins, glass"
    }
  }
}

Each collection has a date, day name, an array of bin types, and optional notes. The binTypes object describes what each bin is for. Keep it readable - you'll be updating this file manually.

Building the MCP Server

Create index.js. We'll build it in steps.

Step 1 - Import Dependencies and Load Data

#!/usr/bin/env node

import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import {
  CallToolRequestSchema,
  ListToolsRequestSchema,
} from "@modelcontextprotocol/sdk/types.js";
import { readFileSync } from "fs";
import { resolve, dirname } from "path";
import { fileURLToPath } from "url";

const __dirname = dirname(fileURLToPath(import.meta.url));
const BIN_DAYS_PATH = resolve(__dirname, "bin-days.json");

function loadBinDays() {
  const raw = readFileSync(BIN_DAYS_PATH, "utf-8");
  return JSON.parse(raw);
}

The shebang at the top makes the file directly executable. We're loading the JSON synchronously each time it's needed. Not the most efficient approach - but simple, and it means changes to your data file are picked up immediately.

Step 2 - Add Helper Functions

Here's the business logic before we wire up the server:

function getUpcomingCollections(data, daysAhead = 30) {
  const today = new Date();
  today.setHours(0, 0, 0, 0);
  const cutoff = new Date(today);
  cutoff.setDate(cutoff.getDate() + daysAhead);

  return data.collections.filter((c) => {
    const date = new Date(c.date);
    return date >= today && date <= cutoff;
  });
}

function getNextCollection(data, binType) {
  const today = new Date();
  today.setHours(0, 0, 0, 0);

  const upcoming = data.collections
    .filter((c) => {
      const date = new Date(c.date);
      if (date < today) return false;
      if (binType) return c.types.includes(binType.toLowerCase());
      return true;
    })
    .sort((a, b) => new Date(a.date) - new Date(b.date));

  return upcoming[0] || null;
}

getUpcomingCollections returns everything within a date window. getNextCollection finds the soonest one, with an optional filter by bin type. Clean, testable functions. Keep your business logic separate from your server wiring.

Step 3 - Initialise the Server

function createServer() {
  const server = new Server(
    { name: "bin-collection", version: "1.0.0" },
    { capabilities: { tools: {} } }
  );
}

The capabilities object tells clients what your server can do. Here we're saying: this server exposes tools. That's all your AI assistant needs to know upfront.

Step 4 - Define Your Tools

This is where MCP gets interesting. You're essentially writing a contract - here's what I can do, here's what you can ask me:

server.setRequestHandler(ListToolsRequestSchema, async () => ({
    tools: [
      {
        name: "get_upcoming_collections",
        description:
          "Returns all bin collections scheduled in the next N days (default 30). Useful for planning ahead or giving a full schedule overview.",
        inputSchema: {
          type: "object",
          properties: {
            days_ahead: {
              type: "number",
              description:
                "How many days ahead to look for collections (default: 30)",
            },
          },
        },
      },
      {
        name: "get_next_collection",
        description:
          "Returns the next upcoming bin collection, optionally filtered by bin type (general, recycling, garden).",
        inputSchema: {
          type: "object",
          properties: {
            bin_type: {
              type: "string",
              description:
                "Filter by bin type: 'general', 'recycling', or 'garden'. Leave empty for any type.",
              enum: ["general", "recycling", "garden"],
            },
          },
        },
      },
      {
        name: "get_bin_types",
        description:
          "Returns details about each bin type - colour and what can be put in it.",
        inputSchema: {
          type: "object",
          properties: {},
        },
      },
      },
    ],
  }));

Your inputSchema uses JSON Schema to define parameters. The AI assistant reads this to understand what arguments to pass. Notice the enum on bin_type - that tells the AI assistant exactly which values are valid. Good schemas mean fewer errors.

Step 5 - Handle Tool Calls

When the AI assistant actually calls one of your tools, this handler runs:

server.setRequestHandler(CallToolRequestSchema, async (request) => {
    const { name, arguments: args } = request.params;
    const data = loadBinDays();

    if (name === "get_upcoming_collections") {
      const daysAhead = args?.days_ahead ?? 30;
      const collections = getUpcomingCollections(data, daysAhead);

      if (collections.length === 0) {
        return {
          content: [
            {
              type: "text",
              text: `No bin collections found in the next ${daysAhead} days.`,
            },
          ],
        };
      }

      const formatted = collections
        .map((c) => {
          const types = c.types.join(", ");
          const note = c.notes ? ` (${c.notes})` : "";
          return `• ${c.date} (${c.day}): ${types}${note}`;
        })
        .join("\n");

      return {
        content: [
          {
            type: "text",
            text: `Upcoming bin collections (next ${daysAhead} days):\n\n${formatted}`,
          },
        ],
      };
    }

    if (name === "get_next_collection") {
      const binType = args?.bin_type || null;
      const next = getNextCollection(data, binType);

      if (!next) {
        const label = binType ? `${binType} bin` : "any bin";
        return {
          content: [
            {
              type: "text",
              text: `No upcoming collections found for ${label}.`,
            },
          ],
        };
      }

      const types = next.types.join(", ");
      const note = next.notes ? `\nNote: ${next.notes}` : "";
      const label = binType ? `Next ${binType} collection` : "Next collection";

      return {
        content: [
          {
            type: "text",
            text: `${label}: ${next.date} (${next.day})\nBins out: ${types}${note}`,
          },
        ],
      };
    }

    if (name === "get_bin_types") {
      const lines = Object.entries(data.binTypes)
        .map(
          ([key, val]) =>
            `• ${key} (${val.colour} bin): ${val.description}`
        )
        .join("\n");

      return {
        content: [
          {
            type: "text",
            text: `Bin types:\n\n${lines}`,
          },
        ],
      };
    }

Each tool returns a content array with text. You can return images or embedded resources too - but text handles most cases just fine.

Step 6 - Start the Server

const transport = new StdioServerTransport();
await server.connect(transport);
console.error("Bin collection MCP server running");

We're using stdio transport - the server talks via standard input/output. That's why logging goes to console.error. Stdout is reserved for MCP messages.

Testing It

Make the file executable, then run it:

chmod +x index.js
node index.js

You should see "Bin collection MCP server running" in the console. The server is now waiting for requests on stdin. You can also write unit tests against your helper functions directly - they're just plain JavaScript functions.

Connecting to Visual Studio Code

VS Code supports MCP servers through its settings. Open your settings.json (Cmd+Shift+P → "Open User Settings JSON") and add the following:

{
  "mcp": {
    "servers": {
      "bin-collection": {
        "type": "stdio",
        "command": "node",
        "args": [
          "/absolute/path/to/bin-collection-mcp/index.js"
        ]
      }
    }
  }
}

Reload VS Code and your server should be picked up automatically. Then try asking Copilot Chat in agent mode:

• "When are my bins next due out?"
• "Show me all collections in the next 7 days"
• "When is the next recycling collection?"

VS Code calls your tools automatically and gives you a natural language answer. It feels like magic the first time. ✨

The Pattern to Remember

MCP servers always follow the same structure. List your tools. Handle tool calls. Return content. That's it. Once you've got this pattern in your head, you can build servers for anything - your local filesystem, an internal API, a Raspberry Pi sensor, whatever you like.

I took this a step further and deployed this code to an Azure App Service and this made it available from anywhere. The full code for this project is on GitHub. Give it a try - and if you build something interesting with it, I'd love to hear about it.

Over the years, I’ve learned that being a Technical Program Manager (TPM) is a bit of a strange hybrid role. You’re expected to understand the tech well enough to contribute meaningfully, but you’re not the one writing and deploying the code anymore. The best TPMs I’ve worked with are the ones who stay close to the technology - curious enough to dig in, and technical enough to be useful.

The challenge? Tech keeps changing. Super Fast. And in 2026, AI has pretty much woven itself into every part of engineering. Systems are more distributed, products ship faster, and teams expect you to keep up.

A while back, I wrote about how to stay technical as a TPM - the habits, the routines, the mindset. Tinkering with side projects, spinning up local environments, sitting in on design reviews.

Building on from that article, here are the technical skills I’ve found most useful as a TPM in today’s world. These aren’t lofty certifications - just practical things that make your day-to-day easier.

Understand the system

You don't need to design the architecture. But when someone pulls up a diagram, you should be able to follow along.

Start with the basics - APIs, queues, microservices, events, caching. Not so you can lecture anyone, but so the conversation makes sense. Then go one step further: spin up a local dev environment. As I mentioned in the previous post, doing this even once gives you a whole new appreciation for what engineers deal with daily. Dependency hell, environment variables, build steps - the works.

From there, learn enough cloud to be dangerous. Containers, serverless, CI/CD, what "region" and "quota" and "scaling" actually mean in practice. You don't need to run Kubernetes clusters. You just need the vocabulary to keep up - and the instinct to know when something sounds harder than it should be.

Follow the work

This is where a lot of TPMs fall behind - and where the gap between good and great really opens up.

Learn how engineering actually works. Code reviews, branching strategies, feature flags, testing pipelines, linters, release cycles. Not so you can manage them - so you can plan around them. So when an engineer says "that'll need a flag" or "we are code complete", you know exactly what they mean and why it matters.

Get comfortable reading logs and dashboards too. You don't need to be on-call. But poking around metrics when something goes wrong - understanding the shape of a problem before the postmortem - makes you genuinely useful in those moments rather than just present.

And read the docs. Design docs, API Docs, and postmortems. You don't need to absorb every detail. You just need to skim well enough to spot a risk before it becomes a crisis. It's a small habit that compounds fast.

Speak the language

Here's the one that often gets overlooked: learn to read code.

Not write it - read it. Follow a pull request. Understand the logic. Tinker with a small script now and then. In the previous post I mentioned keeping a GitHub account and doing a bit of vibe coding just to stay sharp - this is exactly why. It keeps you connected to the craft in a way that's hard to replicate any other way. And it builds real empathy for engineers doing this every day, under pressure, at pace.

Pick up some basic data fluency while you're at it. Running a small query, calling an API, building a quick graph - these are small things that let you answer questions yourself instead of waiting on someone else every time.

And take AI seriously. Not as a buzzword - as a genuine shift in how engineering teams work. Understanding how your teams actually use it, how it affects velocity, how it changes estimation and debugging - that's table stakes now. Personally, I've found it invaluable when getting up to speed on a new codebase.

The 2026 layer: AI is now part of the system you're managing

This is where I'd add something that wasn't in my original post - because it's genuinely new territory, and most TPMs haven't caught up yet.

AI is no longer just a productivity tool sitting alongside engineering. It's becoming part of the system itself. That changes what you need to know.

Understand AI agent orchestration

Teams aren't just using AI to write code anymore. They're running autonomous agents to handle whole chunks of work - prototyping, testing, triaging, even making decisions. Rather than one massive agent that attempts everything, orchestration coordinates multiple specialised agents, with each one handling what it does best.

As a TPM, you need to understand how these pipelines are structured, where they can fail, and how to think about estimating work when part of the team is an agent. Gartner forecasts that 40% of enterprises will have embedded AI agents by the end of 2026 - this is not a future problem. It's a now problem.

Know what MCP is

Model Context Protocol has quietly become one of the most important standards in AI engineering right now. It's an open-source standard for connecting AI applications to external systems - data sources, tools, workflows - enabling them to access key information and perform tasks. Think of it like a USB-C port for AI. You don't need to build one. But knowing what it is, why teams reach for it, and how it fits into a broader agent architecture puts you ahead of most TPMs right now. Google's explainer is a good place to start.

Rethink how you estimate

AI-assisted teams don't move at the same pace as traditional engineering teams - and the risk profile is different too. Features that used to take two weeks might take two days. But new failure modes appear: hallucinations, evals regressing, model updates breaking behaviour in subtle ways. Your planning instincts need updating. What does a sprint look like when part of the work is being done by an agent? What does "done" mean when the output is probabilistic? These are questions worth sitting with.

Get a basic handle on AI governance

This one is landing on TPM plates fast - especially if you're in a regulated industry or shipping to enterprise customers. In the EU, the AI Act is already phasing in requirements, with broader applicability arriving in 2026. In the US, state-level laws are also emerging.

You don't need to be a compliance expert, but understanding concepts like model versioning, audit trails, bias testing, and what "high-risk AI" means in a regulatory context helps you ask the right questions before they become blockers. This overview from OneTrust is a useful starting point.

One last thought

What's helped me as a TPM is keeping the habits small. Read the PR. Skim the doc. Run the build. Poke the logs. None of it takes long, but it compounds in a way that's hard to explain until you feel it - that moment where you're in a conversation and you actually know what's going on, rather than pattern-matching your way through it.

The AI layer makes this a bit more pressing right now, because the ground is shifting quickly. But the underlying idea is the same one from my previous post - staying technical isn't about being the smartest person in the room. It's just about staying curious enough to be useful.👍

A few weeks ago, I wrote about how PowerToys Workspaces helped me stop wasting time arranging windows every morning. Since then, a few people asked what else I use from the PowerToys suite. So today I want to talk about another tool that's quietly become part of my daily workflow - Advanced Paste.

Have you ever copied something from a webpage, pasted it into a doc, and then spent the next two minutes stripping out all the weird formatting? Bold text that shouldn't be bold, font sizes that don't match, colours that make no sense. Yeah. It's one of those small annoyances that adds up over time.

Advanced Paste fixes that - and a whole lot more.

What is Advanced Paste?

Advanced Paste is a clipboard management tool built into PowerToys. The idea is simple: instead of just pasting whatever is on your clipboard as-is, you get to choose how it gets pasted. Plain text, Markdown, JSON, even as a file - all from a single keyboard shortcut.

Think of it like having a smart clipboard that knows what you actually need, rather than blindly dumping whatever formatting came along for the ride.

You open it with Win + Shift + V by default, and a clean little window appears with your paste options. That's it.

Paste as Plain Text

This is the one I use most. Copy something from a browser or a rich text editor, hit the shortcut, and paste it as pure unformatted text. No bold. No headings. No leftover HTML weirdness.

It sounds almost too simple - but honestly, that's the point. Removing that friction from something you do dozens of times a day is worth a lot more than it sounds.

You can also set a direct keyboard shortcut for this so you don't even need to open the Advanced Paste window. Just copy, hit your shortcut, and you're done.

Paste as Markdown

Got some HTML on your clipboard and need it in Markdown? Advanced Paste handles that conversion for you automatically. So something like:

<b>Paste</b> <i>as</i> <a href="...">Markdown</a>

Becomes:

**Paste** *as* [Markdown](...)

If you write documentation, blog posts, or work in any tool that uses Markdown - this one will save you a surprising amount of time.

Paste as JSON

Similar idea, but for structured data. If you've got XML or some other structured text on your clipboard and need it in JSON format, Advanced Paste converts it on the fly. No manual reformatting, no copy-pasting into a converter website.

As someone who spends time working across different tools and formats, this one is genuinely useful.

Paste as a File

This is where it gets a bit more interesting. Advanced Paste can take what's on your clipboard and paste it directly as a file - a .txt file, an .html file, or even a .png file for images.

The .html option is particularly handy if you're copying a section of a webpage (links, formatted text, images and all) and want to save it as a proper file rather than lose all that structure.

Image to Text (OCR)

Have you ever needed to copy text from a screenshot or an image? Normally that means manually typing it out, which is tedious at best.

Advanced Paste has a built-in OCR feature that pulls the text straight out of an image on your clipboard. It all runs locally on your machine - no data being sent anywhere. Just copy the image, open Advanced Paste, hit "Image to Text", and the extracted text is ready to paste.

I've used this more times than I expected - screenshots from Teams calls, error messages in images, text in PDFs that won't let you select it. It just works.

Paste with AI 🤖

This is the most powerful feature in the set, and it's worth calling out separately.

If you configure an AI model provider - OpenAI, Azure OpenAI, Mistral, Google, or a local model via Ollama or Foundry Local - you unlock a whole new level of clipboard transformation. You can type a prompt and the AI will reformat or rewrite your clipboard content based on your instructions.

Some examples of what you can do:

• Summarise a long block of text
• Translate text into another language
• Rewrite something in a more professional tone
• Generate code from a description
• Reformat data into a specific structure

The local model options (Ollama, Foundry Local) are worth a look if you'd rather keep everything on your machine and not worry about API costs or data leaving your device.

You can also save your most-used prompts as custom actions and assign them keyboard shortcuts. So if you regularly need to "translate to French and clean up formatting", you can do that in one keypress without even opening the window.

Setting It Up

If you haven't already got PowerToys installed, grab it from the Microsoft Store or via WinGet. Then:

1. Open PowerToys Settings and navigate to Advanced Paste.
2. Enable Paste with AI.
3. I added Google's Gemini as a Model Provider. You'll need to enter an API key, but that is easily done depending on your AI Model Provider.

Once you've completed all those steps, it should be working as expected. The default shortcut (Win + Shift + V) is easy to remember - think of it as an upgraded version of the regular paste you already know.

A Small Tool with a Big Impact

I'll be honest - I didn't expect Advanced Paste to become something I reach for every day. But like Workspaces, it's one of those tools that solves a real friction point so well that you quickly forget what life was like without it.

If you're already using PowerToys, enable it today. If you're not using PowerToys yet - what are you waiting for? 😄

The Advanced Paste docs are a great place to explore everything it can do.

Have you ever sat down at your computer, ready to get into a flow state, and then spent the first ten minutes just arranging windows? Dragging your editor here, your browser there, nudging Slack into a corner - only to close it all two hours later, and start from scratch the next day? Yeah. Me too.

I've been a big fan of Microsoft PowerToys for a while now. It's one of those tools that quietly makes your Windows experience feel a lot more intentional. There are a bunch of great utilities in there - but recently I've been leaning heavily on one in particular: PowerToys Workspaces.

What is PowerToys Workspaces?

Workspaces is a Windows desktop management utility that lets you capture your ideal window layout, which apps are open, where they're positioned, what size they are, and then launch that entire setup with a single click.

Think of it like a saved game state, but for your desktop.

You could have a "Coding" workspace that opens VS Code to a specific project, a browser on the side, and Terminal ready to go. Or an "Email & Admin" workspace that brings up Outlook, your calendar, and a notes app. Whatever your workflow looks like - you set it up once, and Workspaces handles the rest every time.

Setting Up Your First Workspace

If you haven't already got PowerToys installed, you can grab it from the Microsoft Store or via WinGet. Once it's running, head into the PowerToys Settings and enable Workspaces.

To create your first workspace:

1. Hit Win + Ctrl + ' to open the Workspaces editor (or go to Settings and click "Launch editor").
2. Click "+ Create workspace".
3. You'll enter Capture mode - arrange your apps exactly how you want them.
4. When you're happy hit "Capture".
5. Give it a name, tweak anything you need to, and save it.

That's it. When it you launch it, it will open those apps exactly as you'd like them. You can create as many different workspaces as you'd like depending on your needs.

The Part That Surprised Me

What I didn't expect was how useful the CLI arguments feature would be. When you're in the editor, each app has a little dropdown where you can pass command line arguments. So for VS Code, I can point it straight to a specific project folder on launch. For Edge, I can give it a comma-separated list of URLs and it'll open all those tabs automatically.

It sounds like a small thing - but removing those few extra clicks every time you start a session adds up surprisingly quickly.

Desktop Shortcut

Within the workspace editor, you can select the option to Create a desktop shortcut which creates a handy shortcut on your desktop.

I find this super handy for when I start my PC first thing in the morning. Just a double click and your workspace is loaded and ready to go. If you prefer, you could pin it to your taskbar if you really want it front and centre.

A Few Things Worth Knowing

When a workspace launches, you'll briefly see windows jumping around the screen as PowerToys repositions them. There's a status dialog that pops up to show you what's loading, which helps - but it can look a bit chaotic the first time you see it.

Also worth noting: if you've got apps snapped using Windows' built-in snap feature, Workspaces won't preserve that snapped state. It uses its own positioning engine under the hood. Not a dealbreaker, but something to be aware of when you're setting things up.

How I Use It Day to Day

If you've read my recent post on staying technical as a TPM, you'll know I'm always looking for ways to reduce friction and stay in a coding mindset. Workspaces has become one of those small but surprisingly impactful habits.

I've ended up with two workspaces that cover probably 90% of my week:

• Coding - VS Code, Terminal, and a browser window with the relevant docs.
• Daily - Outlook, Teams, Slack and a browser.

Switching between them takes a double click. It sounds almost too simple - but honestly, that's the point. The friction of setting up your environment is just gone.

If you haven't explored PowerToys yet, it's one of the best free productivity tools for Windows and the Workspaces docs are a great place to start.

In my career, I've been many things - a Support Engineer, a Software Engineer and an Engineering Manager. These days, I've settled into a Technical Program Manager role (which I am thoroughly enjoying).

As a Technical Program Manager (or TPM), you're often expected to wear multiple hats - strategic planner, cross-functional communicator, and technical problem solver. But how do you stay technically sharp while managing programs at scale?

The role of a TPM is different from a program manager, you are expected to be technical. Here are some of the daily (and weekly) practices that help me keep my technical skills sharp.

Writing the occasional code

Early in my career, I was a software engineer. These days, my role doesn’t require me to write code, but I still have the urge to explore and tinker. I’ve built a bunch of small tools and love updating my GitHub account. I’m also big into AI right now (as is everyone 😂) and have been doing a lot of “vibe coding” just to learn something new or scratch an itch. Even writing a few lines here and there keeps your brain tuned to real engineering challenges.

Writing Technical Content

Blogging has been a powerful tool for learning. Whether it’s writing about Azure Text-to-Speech, troubleshooting Ghost CMS, or Game Development, the act of explaining technical concepts forces clarity and deepens my understanding. It also helps others, which is always a bonus.

Following tech blogs

One of the most useful habits I’ve developed is staying up to date with what’s happening across the tech world. Even if it’s not tech I use every day, it’s important to see how others are solving problems. You never know when a piece of tech or a pattern will end up being useful later.

<Insert your hobby here>

Outside of work, I love brewing my own beer. I even have a blog dedicated to it! One of the best ways to learn something new is to combine your hobby with tech. Recently, I built a fermentation tracker using a Raspberry Pi and temperature sensors. It keeps me close to hardware and scripting, and it’s a fun, low-stakes way to apply engineering principles.

Balancing technical depth with program management isn’t about doing everything - it’s about staying curious, being useful, and knowing when to dive in. Whether it’s through side projects, internal tools, or collaborative problem‑solving, staying hands‑on helps me lead with more confidence and empathy. It might all sound obvious, but the real impact has come from deliberately doing these things, day after day, with intention.

How to Stay Close to Your Company's Tech

While it’s important to understand what’s happening across the wider tech landscape, it’s just as important (if not more so) to stay close to the technology inside your own organisation. Knowing how your systems work, how your teams build, and where the real challenges live helps you make better decisions and builds trust with engineering.

Here are some of the things I try to do in my role to stay close to the tech:

Read Your Company’s Engineering Docs
Most teams have design docs, architecture overviews, or RFCs floating around. Even skimming them gives you a deeper understanding of how things fit together and why certain decisions were made.

Sit In on Architecture or Design Reviews
You don’t necessarily need to weigh in on every detail, but observing the discussions helps you understand trade‑offs, constraints, and how engineers think about the system.

Spin Up a Local Dev Environment
Even if you’re not coding every day, setting up and running the services your teams build helps you understand the tooling, dependencies, and workflows they use.

Use the Product Like a Real User
If your company makes consumer or developer-facing tools, actually use them end-to-end. It sharpens your instincts for what “good” feels like and what’s actually painful.

Why Staying Technical Matters for TPMs

• Credibility with Engineering Teams: Understanding the tech stack helps you ask the right questions and gain trust. This is especially important in a gaming role! If engineers don't believe you are credible and have the background knowledge, it becomes much harder to lead effectively.
• Better Decision-Making: Technical fluency helps you assess trade-offs, spot risks, and understand what “good” looks like.
• Faster Problem Resolution: When you understand the underlying systems, you can catch bottlenecks or misalignments earlier.

Time Management

So how do I fit all this learning time in?

In a busy work environment, it can be tricky to stay current while balancing program responsibilities. I also have a family, and being a present dad is non-negotiable.

One thing that has helped tremendously is deliberately blocking time for learning or tinkering - without compromising program delivery. For example, I use Feedly to read all the RSS feeds I subscribe to. First thing in the morning with a cup of coffee, I catch up on what's happening in our industry.

At Microsoft, we also have company-wide hackathons, and they’re a fantastic opportunity to try something new, collaborate with people you’ve never worked with, and solve real technical challenges. I try to participate whenever I can.

Balancing learning and work isn’t easy, but scheduling time for both makes it achievable.

Conclusion

I hope you’ve found this post useful. These are the things that have personally helped me stay technically sharp - they might not all be right for you, but it’s a good place to start. For me, it ultimately comes down to staying curious, being deliberate, and consistently carving out time to keep learning.

If you're a Technical Program Manager, how do you stay technical? I’d love to hear your approach.

Have you ever wanted to create a backup of your website or blog? Maybe you're migrating to a new platform, or perhaps you just want a portable archive of your content that you can read offline. I've previously experienced issues with this site going down and I wanted to make sure that I wasn't stuck without a backup of all my posts.

That's exactly why I built Backup Buddy - a command-line tool that turns any website into a collection of clean, readable Markdown files with all the images (and videos) preserved.

What Does Backup Buddy Do?

Backup Buddy takes a website's sitemap and automatically downloads every page, converting the HTML into clean Markdown format while saving all the images (and videos) locally. Think of it as creating a time capsule of your website that you can read, search, and store anywhere - no internet required.

The best part? You end up with content in Markdown format, which means you can:

• Read it in any text editor
• Import it into a static site generator like Hugo or Jekyll
• Search through it with standard text tools
• Version control it with Git
• Share it without worrying about broken links or missing images

How to Use It

Using Backup Buddy is straightforward. You just need to know your website's sitemap URL (usually something like https://yoursite.com/sitemap.xml) and run a single command:

backup-buddy https://yoursite.com/sitemap.xml

That's it! The tool will:

1. Download your sitemap
2. Find all the URLs
3. Download each page
4. Convert the HTML to Markdown
5. Save all the images
6. Organize everything into neat folders

Getting Started

Head over to the Git repo and download the latest release.

What You Get

After running Backup Buddy, you'll find an output folder with all your content organized like this:

output/
├── 1_my-first-post/
│   ├── my-first-post.md
│   ├── metadata.txt
│   ├── images/
│   │   ├── header-image.jpg
│   │   └── diagram.png
│   └── videos/
│       └── demo.mp4
├── 2_another-post/
│   ├── another-post.md
│   ├── metadata.txt
│   └── images/
│       └── photo.jpg
└── ...

Each page gets its own folder containing:

• The Markdown version of your content
• A metadata file with the original URL and backup date
• An images folder with all pictures from that page
• A videos folder with any videos from that page

Why I Built This

I've been blogging for years, and I've migrated platforms more than once. Each time, I worried about losing content, breaking image links, or dealing with complicated export tools. I wanted something simple that would give me a clean backup I could actually use.

The Markdown format is perfect because it's:

• Human-readable - You can open it in any text editor
• Future-proof - It's just text, so it'll work forever
• Portable - Easy to import into almost any blogging platform or static site generator
• Git-friendly - You can track changes and collaborate on content

Performance Features

One thing I made sure to include was speed. Backup Buddy processes multiple pages at once (10 by default), so even large websites with hundreds of pages get backed up quickly. You'll see real-time progress as it works:

[1/150] Processing: https://example.com/first-post
[2/150] Processing: https://example.com/second-post
  ✓ Saved to: output/1_first-post
  ✓ Saved to: output/2_second-post
[3/150] Processing: https://example.com/third-post
...

A Few Things to Know

While Backup Buddy handles most websites well, there are a few limitations:

• It only backs up URLs in your sitemap (which is usually everything important)
• Content that's loaded with JavaScript after the page loads won't be captured
• Images need to be accessible when you run the backup
• Very large sites might need you to adjust the parallel processing settings

Try It Out

If you've been looking for a simple way to backup your website or blog, give Backup Buddy a try. It's open source (MIT License), so you can use it freely and even modify it for your needs.

Check it out on GitHub: github.com/deanhume/backup-buddy

Have questions or suggestions? Feel free to open an issue or submit a pull request. Happy archiving!

If you’ve ever had an app crash at the worst possible moment, you’ll know how frustrating it can be - both for developers and players. Recently, I wrote an article for the Microsoft Developer blog that dives deep into this exact challenge: how to diagnose and resolve crashes effectively on Xbox and Windows platforms.

In the post, I share practical tips, tools, and workflows that can help you move quickly and efficiently. Whether you’re building games or apps, these techniques can improve the overall experience for your users.

👉 https://developer.microsoft.com/en-us/games/articles/2025/11/from-crash-to-resolution-practical-guide-for-xbox-windows-developers/

If you’ve got any thoughts or tips of your own, I’d love to hear them — drop a comment or reach out!

Many years ago, I wrote an article on the basics of OAuth and while it was helpful, it is now quite outdated. A lot has changed in the past 14 years! OAuth 2.0 has become the de facto standard for securing APIs and authorizing users in modern applications.

The older article I wrote used a SoundCloud example and older libraries, this updated guide walks you through implementing OAuth 2.0 in C# using Visual Studio Code, with modern libraries and best practices.

Whether you're building a console app, a web API, or integrating with services like Google or Microsoft Graph, this guide will help you get started with a clean and simple implementation.

Prerequisites

Before we dive in, make sure you have the following:

• https://dotnet.microsoft.com/en-us/download
• https://code.visualstudio.com/
• Basic understanding of HTTP and REST APIs
• A registered OAuth 2.0 application (e.g., via Google, Microsoft, or a custom provider).

Let's get started!

Step 1: Create a New Console App

Open your terminal and run:

dotnet new console -n OAuthDemo
cd OAuthDemo

Step 2: Install Required Packages

We'll use Microsoft.Identity.Client for handling OAuth flows:

dotnet add package Microsoft.Identity.Client
dotnet add package Microsoft.Extensions.Configuration

Step 3: Configure Your OAuth Settings

Create a appsettings.json file to store your credentials:

{
  "OAuth": {
    "ClientId": "your-client-id",
    "TenantId": "your-tenant-id",
    "Authority": "https://login.microsoftonline.com/your-tenant-id",
    "Scopes": [ "https://graph.microsoft.com/.default" ],
    "ClientSecret": "your-client-secret"
  }
}

🔍 What is tenant-id? >This is the unique identifier (GUID) for your Azure Active Directory (AAD) tenant. You can find it in the Azure portal under Azure Active Directory > Overview. Alternatively, you can use your domain name (e.g., contoso.onmicrosoft.com) in place of the GUID. This might be different depending on your OAuth provider.

Step 4: Authenticate and Acquire Token

Here's a simple example using MSAL to get an access token:

using Microsoft.Identity.Client;
using Microsoft.Extensions.Configuration;

var config = new ConfigurationBuilder()
    .AddJsonFile("appsettings.json")
    .Build();

var clientId = config["OAuth:ClientId"];
var tenantId = config["OAuth:TenantId"];
var authority = config["OAuth:Authority"];
var scopes = config.GetSection("OAuth:Scopes").Get<string[]>();

var app = ConfidentialClientApplicationBuilder.Create(clientId)
    .WithAuthority(authority)
    .WithClientSecret(config["OAuth:ClientSecret"])
    .Build();

var result = await app.AcquireTokenForClient(scopes).ExecuteAsync();
Console.WriteLine($"Access Token: {result.AccessToken}");

Step 5: Make an Authenticated API Call

Use HttpClient to call a protected resource:

using System.Net.Http;
using System.Net.Http.Headers;

using var httpClient = new HttpClient();
httpClient.DefaultRequestHeaders.Authorization = 
    new AuthenticationHeaderValue("Bearer", result.AccessToken);

var response = await httpClient.GetAsync("https://graph.microsoft.com/v1.0/users");
var content = await response.Content.ReadAsStringAsync();
Console.WriteLine(content);

✅ Testing Endpoint: https://graph.microsoft.com/v1.0/users >This endpoint returns a list of users in your Azure AD tenant. To use it, ensure your app registration has Application permissions like User.Read.All and that you've granted admin consent.

If all works as expected, you should see a response similar to the following:

{
  "@odata.context": "https://graph.microsoft.com/v1.0/$metadata#users",
  "value": [
    {
      "businessPhones": [],
      "displayName": "Dean Hume",
      "givenName": "Dean",
      "jobTitle": null,
      "mail": null,
      "mobilePhone": null,
      "officeLocation": null,
      "preferredLanguage": "en",
      "surname": "Hume",
      "userPrincipalName": "email.com#EXT#@email.onmicrosoft.com",
      "id": "id-response-goes-here"
    }
  ]
}

*Optional: Set up an Entra ID test OAuth App

This is an optional step as you might be wanting to use your own OAuth provider, however, I wanted to be sure that my code worked and I set up an App in Azure's Entra ID that I could test with.

If you'd like to do the same, I recommend checking out these resources:

• Quickstart: Create a new tenant in Microsoft Entra ID
• Client Id & Secret from Entra ID

Conclusion

OAuth 2.0 doesn't have to be intimidating. With modern libraries like MSAL and tools like Visual Studio Code, you can securely authenticate and access APIs with just a few lines of code.

If you'd like to see an example of this code in action, please head over to the Github repo that I created to accompany this article.

Back in 2013, I published a blog post about a simple HTML Minifier I'd built for web pages. At the time, web performance was becoming increasingly important, and I needed a straightforward way to reduce the size of HTML files in my projects. What started as a personal solution has evolved into a tool that's been used by developers worldwide for over a decade. Today, I want to reflect on that journey and share what the tool has become.

The Problem (Then and Now)

Web performance has always been critical, but it's even more important today. Every KB matters when you're trying to deliver fast experiences to users across the globe on varying network conditions. While we have sophisticated build tools and bundlers now, the core principle remains the same: smaller files load faster.

HTML minification removes unnecessary whitespace, line breaks, and comments from your HTML files - things that make code readable for humans but add unnecessary bytes for browsers. When you're shipping production code, these extras are just wasted bandwidth.

What Started as a Simple Tool

The original HTML Minifier was straightforward: point it at a folder of HTML or ASP.NET Razor views, and it would strip out the unnecessary characters. It was born from a real need I had while working on ASP.NET projects where manually minifying views or integrating complex build processes wasn't practical.

HtmlMinifier.exe "C:\MyProject\Views"

That was it. Simple, effective, and it got the job done.

Evolution Over 12 Years

What's been fascinating is watching the tool evolve based on real-world usage and community feedback. Here are some of the key improvements that have shaped the project:

Framework Support

Early on, I learned that aggressive minification could break certain JavaScript frameworks. Knockout.js, for example, uses HTML comments for control flow. Angular had similar patterns. This led to adding configuration flags:

# Preserve HTML comments for frameworks that need them
HtmlMinifier.exe "C:\Folder" ignorehtmlcomments

# Keep Knockout.js comments specifically
HtmlMinifier.exe "C:\Folder" ignoreknockoutcomments

This was a great lesson in understanding your users' workflows. A tool is only useful if it fits into real-world scenarios.

Performance Improvements

As the tool gained users, performance became more important. People weren't just minifying a handful of files - they were processing entire web applications with thousands of views. I added:

• Recursive directory scanning for processing entire project structures
• Multi-file support for targeted minification
• Line length controls to prevent overly long lines that could impact certain text editors or source control systems
• Performance metrics showing bytes saved and processing time

# Limit lines to 60,000 characters
HtmlMinifier.exe "C:\Folder" "60000"

Modern Development Practices

The .NET ecosystem has changed dramatically since 2013. The project has evolved alongside it:

• Continuous Integration: GitHub Actions now automatically build and test every commit
• Comprehensive Testing: Over 60 unit tests covering edge cases, performance benchmarks, and real-world scenarios
• Better Error Handling: Proper validation, informative error messages, and graceful failure modes
• Cross-framework Support: HTML, Razor views (.cshtml), and Web Forms (.aspx)

Community Contributions

One of the most rewarding parts of this journey has been the incredible support from the community. Over the years, twelve different contributors have jumped in to help improve the tool - surfacing bugs and edge cases I hadn’t considered, submitting fixes for real-world production issues, adding support for specific frameworks and use cases, and even enhancing the documentation and usage examples.

Every pull request, issue, and suggestion has helped shape the tool into something better.

Performance Gains

The tool typically achieves:

• 10-40% size reduction for typical HTML files
• 20-50% reduction for files with heavy indentation and whitespace
• Processing speeds that can handle thousands of files in seconds

For a production website with hundreds of views, this translates to meaningful bandwidth savings and faster page loads.

Lessons from Maintaining an Open Source Tool

1. Simplicity is a Feature

In an era of complex build toolchains, there's still value in tools that do one thing well. The HTML Minifier has survived because it's simple to understand and use. You don't need to configure Webpack, install npm packages, or learn a new build system - you just run it.

But I'm also mindful that sometimes the best feature is knowing what not to add. The tool's simplicity is part of its appeal.

2. Real Users Reveal Real Problems

Some of the most impactful improvements came directly from folks using the tool in production. They uncovered edge cases I hadn’t even considered - like deeply nested HTML structures, Unicode and international character handling, quirky Razor syntax combinations, and performance bottlenecks with massive files. Their feedback helped push the tool to be more robust and production-ready.

3. Open Source is a Marathon

Twelve years is a long time. Technologies come and go, but useful tools persist. The key is:

• Responding to issues thoughtfully
• Being conservative with breaking changes
• Keeping the tool focused on its core purpose
• Appreciating and crediting contributors

Try It Yourself

If you're working on a web project and need a straightforward way to minify HTML, give it a try:

GitHub: https://github.com/deanhume/html-minifier

Reflections

Looking back at 12 years of maintaining this tool has been surprisingly rewarding. It's been used in projects I'll never know about, solved problems I didn't anticipate, and connected me with developers around the world.

The web development landscape has changed dramatically since 2013:

• We've gone from jQuery to React, Vue, and beyond
• Build tools have become incredibly sophisticated
• Web performance tooling has advanced tremendously
• The rise of SPAs, PWAs, and modern frameworks

Yet through all these changes, the need for efficient HTML delivery remains constant. That's perhaps the most interesting lesson: fundamental problems persist even as technologies evolve.

Thank You

To everyone who's used the tool, filed an issue, contributed code, or simply found it helpful - thank you. Open source thrives on community, and this project has been a small but meaningful part of my contribution to that ecosystem.

Here's to another 12 years of making the web a little bit faster, one minified file at a time. 🚀

Resources:

• GitHub Repository
• Original Blog Post (2013)
• Latest Release

If you've recently ventured into the world of Azure Functions, you're likely familiar with the versatility they offer when it comes to scheduling tasks. In this guide, we'll delve into using Azure Functions' Time Trigger function with Node.js and Visual Studio Code, uncovering some important nuances along the way.

This article assumes that you have some familiarity with Node.js and a basic understanding of Azure.

Getting Started

To begin, you'll need Node.js and Visual Studio Code installed, along with the Azure Functions extension. When you create a new function, it comes with some boilerplate code that includes a schedule property defining when the function should run. By default, it's set to run every 5 minutes.

const { app } = require('@azure/functions');

app.timer('timerTrigger2', {
    schedule: '0 */5 * * * *',
    handler: (myTimer, context) => {
        context.log('Timer function processed request.');
    }
});

The schedule parameter in the above code tells the Azure Function how often to fire.

The Challenge

But what if you want your function to run every 11 hours during a day? Crafting the right Cron expression can be tricky, and that's where I encountered some difficulties. I turned to an online Cron expression generator, hoping it would simplify the process. Here's what it gave me:

0 0 */11 * *

Feeling confident, I integrated this expression into my code above and deployed the Azure Function. However, it didn't work as expected. I scoured the logs for clues but found nothing. To troubleshoot and debug locally, I temporarily changed the Cron expression to run every minute, and it worked flawlessly. So why wasn't it firing every few hours?

The Revelation

After some online research, I uncovered the reason behind the issue. Azure Functions use an NCRONTAB expression, which requires a six-part format instead of the traditional five-part Cron expression. The online generator that I found online had provided a five-part expression, leading to the problem.

To be fair, the Visual Studio Code extension for Azure Functions provides the correct six-part format by default. My mistake was changing it using a five-part expression from an online tool - d'oh!

The Solution

To rectify this, I recommend using the NCrontab Expression Tester. This user-friendly tool not only helps you test your expressions but also generates the correct six-part Cron expressions tailored for Azure Functions.

When I updated my code to use the 6 part format:

0 0 */11 * * *

It ran perfectly!

Why NCrontab?

You might be wondering why Azure Functions use the NCrontab six-part format instead of the traditional five-part format. The answer lies in its flexibility. The six-part format allows you to specify seconds, enabling you to run your functions with higher precision and frequency.

* * * * * *
- - - - - -
| | | | | |
| | | | | +--- day of week (0 - 6) (Sunday=0)
| | | | +----- month (1 - 12)
| | | +------- day of month (1 - 31)
| | +--------- hour (0 - 23)
| +----------- min (0 - 59)
+------------- sec (0 - 59)

For further details on NCrontab expressions, you can visit the GitHub repository here.

Happy coding!

In my spare time, I like to do a bit of homebrewing. While it isn't the usual sort of topic that I post on this site, I wanted to cross post to an article I wrote about automating some of the brewing process.

If you've ever goofed around with Raspberry Pi's before, you'll know how fun they can be. In this article I go into detail about how I hooked up a Raspberry Pi to continually track and monitor the progress of my beer all whilst graphing it out to another application. It gets a little geeky!

Please head over to my homebrew website over at Humebrew.com to find out more!