Thankfully, I found Dev Containers, which turned into its own rabbit hole but lets us lock down Claude without having to maintain our own docker image.

This reflection post talks through the containerised setup and some issues I faced while setting it up. If you just want the solution, then the implementation is in the .devcontainer/ directory of this website’s source code.

Feature or docker image?

I assumed that Anthropic would ship an official Claude base image you build on top of. They don’t, they only post a recommended starting point. Claude Code installs into any Dev Container through the ghcr.io/anthropics/devcontainer-features/claude-code:1.0 feature, which you reference in devcontainer.json like any other devcontainers feature. It works wherever the Dev Containers spec is supported e.g. VS Code, Codespaces, JetBrains, and (with some rough edges) Cursor. In VS Code it can be configured to pull in the Claude Code extension, keeping Claude decoupled from the base image entirely.

That leaves three layers to assemble: a base image, the tooling you use, and Claude Code on top. The real decision is whether you bake those middle two layers into a custom docker image you push to a registry, or assemble them per-repo through devcontainer.json features. A custom image is the better call for a team, where you want a validated, secure, and reusable environment everyone builds on. For a solo setup spun up per-repo, features are easier. The cost is a slow first build and less control over exactly what lands in the image, which is what post-create.sh helps automate somewhat.

My devcontainer.json ended up looking like this, trimmed to the main parts:

{
  "image": "mcr.microsoft.com/devcontainers/base:ubuntu",
  "features": {
    "ghcr.io/anthropics/devcontainer-features/claude-code:1.0": {}
  },
  "remoteUser": "vscode",
  "mounts": [
    "source=claude-code-config-${devcontainerId},target=/home/vscode/.claude,type=volume"
  ],
  "runArgs": ["--cap-add=NET_ADMIN", "--cap-add=NET_RAW"],
  "postCreateCommand": "sudo zsh .devcontainer/post-create.sh",
  "postStartCommand": "sudo /usr/local/sbin/init-firewall.sh",
  "waitFor": "postStartCommand"
}

The non-root vscode user is important if you ever run with --dangerously-skip-permissions, Claude Code requires it. The named volume on ~/.claude means login persists across rebuilds instead of re-authenticating every time. The NET_ADMIN/NET_RAW capabilities exist so that we can create the containerised firewall. waitFor: postStartCommand blocks the terminal until that firewall script finishes, so there’s no window where Claude is already running before egress is locked down.

post-create.sh is the everyday stuff a feature-based setup doesn’t hand you for free: setting git aliases, adding a couple of zsh aliases for kubectl and terraform, locking down sudo/su.

init-firewall.sh sets default-DROP policies on iptables, then builds an ipset allowlist of everything the container is allowed to reach outbound. Part of that allowlist is GitHub’s own published IP ranges, fetched live at container start:

gh_ranges=$(curl -s https://api.github.com/meta)
while read -r cidr; do
    ipset add allowed-domains "$cidr"
done < <(echo "$gh_ranges" | jq -r '(.web + .api + .git)[]' | aggregate -q)

Everything else —npm, api.anthropic.com, the VS Code marketplace— gets resolved and added individually. The firewall script finishes by checking its own work: it tries curl https://example.com and expects that to fail, then tries curl https://api.github.com/zen and expects that to succeed.

Firewall and sudo

I spent a decent chunk of time configuring who’s allowed to touch iptables. The common-utils feature grants the vscode user blanket passwordless sudo by default, and my first cut of post-create.sh narrowed that down to the iptables/iptables-save/ipset binaries themselves, with no argument restriction. Which meant Claude or anything else running as vscode, including under --dangerously-skip-permissions, could just run sudo iptables -F && sudo iptables -P OUTPUT ACCEPT and the firewall would be gone! Anthropic’s own reference devcontainer avoids this by granting sudo on one fixed script path instead of the raw binaries, baked into their image at build time so the script itself can’t be edited either. I didn’t want a custom Dockerfile yet, but dev containers can do the same thing with just postCreateCommand: copy init-firewall.sh to a root-owned /usr/local/sbin/init-firewall.sh outside the bind-mounted workspace while the feature’s broad sudo grant is still active, then narrow sudo down to NOPASSWD on that one frozen executable file only. The tradeoff is that editing the live init-firewall.sh to allow a new domain now needs a full Rebuild Container, not just a restart, since the frozen copy is what actually runs.

Claude has it’s own way to limit it’s own execution too using .claude/settings.json. We’ve configured this on top to deny any Bash(sudo *) and Bash(su *) commands, so in normal mode Claude won’t even attempt the command. But --dangerously-skip-permissions does exactly what its name says: it bypasses every permission rule, deny rules included. So that file is a speed bump for the default mode, not something to lean on once the safety’s off. The frozen-script sudoers restriction is the one that locks it down regardless, because it’s enforced by the OS, not by Claude Code.

Gap in the firewall

One thing I noticed was that api.github.com/meta’s ip ranges aren’t scoped to the API. They cover GitHub’s whole edge network, which includes GitHub Pages in some cases. For example, this website, westernwilson.com, runs on GitHub Pages. So with the firewall up and supposedly restricting the agent to an approved set of domains, I could still reach my own site. And by the same logic, any other *.github.io page, or anything hosted there by someone with worse intentions. A page on *.github.io could potentially hold a payload hosted somewhere else entirely, and the firewall would wave it through without ever knowing the difference.

I see three ways to close that off:

• Proxy the traffic and filter on hostname instead of IP. Cleanest in theory, but Encrypted Client Hello can still hide the hostname from anything sitting.
• Drop *.github.io from the allowlist entirely. Unfortunately this also takes raw.githubusercontent.com out too since they share the same ip ranges, but if that’s not something the container needs, it’s a fine trade.
• Accept the risk and move on.

I haven’t picked one yet, for now I’m sitting with the risk while I think about which tradeoff is actually worth it.

Logging in to Claude

Logging in had its own gotcha. In VS Code there is a big orange “use your subscription” button that opens a browser and waits for a callback to localhost, which never makes it back into the container and just hangs. The fix is to skip the button, open a terminal inside the container and run claude, which kicks off the same browser flow but resolves the callback correctly.

We then use ~/.claude, which is now owned by the vscode thanks to the chown at the top of post-create.sh, so once logged in, we gain stickier login sessions.

In doing the whole login dance from a bare terminal meant that my first real session with Claude Code inside the dev container was just text based interaction with no IDE extension wrapper around it at all. It’s an interesting way to work and removes a lot of the UI distraction, but not something I’ll rely on fulltime.

Port forwarding

The other thing that briefly worried me is VS Code forwarded around thirty-two ports the moment the container came up. My first thought was that something in the container was reaching out on its own. It’s not, after some searching I found that it’s VS Code’s automatic port-forwarding scanning the container for anything listening on a port, for example a dev server that you’ll want to open in a browser. It’s a separate, fairly trigger-happy feature, and apparently a known source of noise; This GitHub issue describes the exact same “over 20 ports auto-forwarded” behaviour after a setting silently flips from process to hybrid detection mode.

If you want to see the actual config rather than the excerpts above, it’s all in this repo under .devcontainer/. Treat it as a personal setup to extend, not a hardened image to copy verbatim.

Further reading: Anthropic’s Dev Containers docs and the VS Code Dev Containers tutorial.

Hardware & software of choice

• Macbook Pro 16
• AnyType for personal notes
• Claude
• Flow for pomodoro timing
• Arc browser
• Kindle ereader (11th Gen Paperwhite)

Technical Stack

• Cloud & Infrastructure: AWS (EKS, IAM, RDS), Terraform, Docker, Kubernetes, Helm, PostgreSQL, OpenStack, GCP (wanting to learn)
• CI/CD: GitHub Actions, TeamCity, Octopus Deploy
• Languages: Python (FastAPI, Flask), Bash, Go (learning), some C# & Java
• Observability: New Relic, Sumo Logic, Prometheus, Grafana, Kibana / ELK
• Practices: REST API Design • Infrastructure as Code • Observability • Security Controls • Agile/Scrum

Also worked with:

• Frontend: Vue.js (Nuxt), React (Next.js), Tailwind CSS, Hugo
• ML basics: Google’s MLCC with hands-on experience using Pandas, NumPy, TensorFlow

Linting and formatting code

Recently, while working on a personal DevOps project, I spent some time looking into linting tools. They amazingly save your brainpower for the actual problem, instead of code styling. Whether it’s two spaces or four per indent, single quotes or double, I don’t mind. Other people have thought deeply about these trade-offs, landed on reasonable answers, and codified them. I’m happy to piggyback on that.

I aim to write code that works, and let the styling happen automatically.

There’s a side benefit too: when a codebase consistently uses a popular linting tool, anyone familiar with it can scan the code and immediately know where to look. It’s like how headings in a research paper let you scan before you commit to reading.

Three touchpoints that matter

Good linting hygiene should show up at meaningful points in your development lifecycle:

1. In your IDE (or text editor), as you write
2. Locally, before you commit
3. In CI/CD, before code merges

Each layer serves a different purpose. Together, they make code quality essentially automatic. (Tools like SonarQube go deeper —security, coverage, and code smells at a project level— but that’s a reflection for another time.)

In the IDE (or text editor), I use VS Code with the relevant extensions installed and Format on Save enabled. It does what it sounds like: when the file saves, the formatter runs. Sometimes this needs dev dependencies installed to work properly; check the official docs and you’ll figure it out quickly, I’ll go into Ruff for Python specifically later in this post.

Locally, before committing, is where things get interesting. At various companies I’ve seen the same pattern repeat: developer forgets to format, pushes code, CI fails, they fix locally, force-push, CI reruns. This adds ten minutes to the dev cycle, minimum. Multiply that across a team and it adds up quickly.

Git’s pre-commit hooks solve this cleanly. When you attempt a commit, a hook runs your formatting and linting checks first. If they fail, the commit doesn’t go through. This means no broken CI and no annoying formatting fix commits. This enables the code to validate itself before it ever leaves your machine.

The one catch: developers can skip the setup step entirely, which is exactly why the third layer exists.

In CI/CD, the pipeline enforces what the pre-commit hook encourages. Even if someone bypasses local hooks, nothing merges unless the linting passes. This is your actual quality gate and is what you rely on.

Why Ruff instead of Black and Flake8

Three or more years ago, I used Black for formatting and Flake8 for static analysis. Two tools, two configs, two things to install and maintain. It was a minor friction, but that friction compounded and was a little naff.

Ruff replaces both with a single tool. It’s faster, simpler, and opinionated enough that you don’t have to make many decisions. For a project where the point is less thinking about styling and formatting, that’s exactly what I wanted.

The Setup (Python / FastAPI)

Three things to configure, in roughly this order:

Step 1: VS Code + Ruff extension

Install the Ruff extension from the VS Code marketplace — the official one is published by Astral (charliermarsh.ruff). Once installed, add this to your .vscode/settings.json:

{
  "[python]": {
    "editor.formatOnSave": true,
    "editor.defaultFormatter": "charliermarsh.ruff",
    "editor.codeActionsOnSave": {
      "source.fixAll.ruff": "explicit",
      "source.organizeImports.ruff": "explicit"
    }
  }
}

Committing .vscode/settings.json to the repo is intentional. Anyone who clones the project and opens it in VS Code gets the same formatting behaviour automatically. No extra knowledge required.

No separate Ruff installation is needed as the VS Code extension ships its own binary, and the pre-commit hook (added in Step 2) bundles its own too. You just need to add your Ruff config to ruff.toml:

[tool.ruff]
line-length = 88
target-version = "py312"

[tool.ruff.lint]
select = ["E", "F", "I"]

The select block opts into pycodestyle errors (E), Pyflakes (F), and isort import sorting (I). This covers what you’d previously have needed Black, Flake8, and isort to do separately.

Step 2: Pre-commit hooks

First, install the pre-commit package:

pip install pre-commit

Then create a .pre-commit-config.yaml in the root of your repo. Here’s exactly what’s in the project:

repos:
  - repo: https://github.com/astral-sh/ruff-pre-commit
    rev: v0.11.4
    hooks:
      - id: ruff
        args: [--fix]
        files: ^api/
      - id: ruff-format
        files: ^api/

A few things worth noting here. The files: ^api/ pattern scopes the hooks to the API directory only — the frontend has its own linting story (ESLint + Prettier), so there’s no point running Ruff across the whole repo. The ruff hook handles lint checks and the --fix flag means it’ll auto-fix what it can rather than just reporting issues. The ruff-format hook handles formatting, equivalent to what Black would have done. Once the file is in place, install the hooks:

pre-commit install

This wires the hooks into your local .git/hooks/pre-commit. From this point, every time you run git commit, Ruff runs first. If it finds issues it can’t auto-fix, the commit is blocked and the problems are printed to the terminal. Fix them, stage the changes, and commit again. You can also run it manually across all files at any point:

pre-commit run --all-files

Useful for a first run after setting up, or after pulling in changes from someone else who hasn’t had the hooks installed.

That’s it. Once it’s done, your automatic project linting works in the background. Which is perfect.

Setting the scene

First a bit of background, I’m a copious note-taker. I’ve been this way ever since I was a wee boy. Writing notes helped me focus on the speaker better, even when my notes tended to be more of a gibberish scribble and mostly illegible for future Western. With physical note taking however I would consistently forget my notebooks and have to write on spare paper. Then I’d lose the spare paper and the state of my notes was a mixed bag. So, I shifted to digital notes to try solve this problem. What have I tried? Google Docs and Drive, OneNote, BookStack, Wiki.js, Confluence, Notion, Evernote, Obsidian, Google Keep, and others.

Unfortunately, no tool was perfect; they all missed one aspect of my requirements, or felt clunky, or had features locked behind paywalls, or couldn’t be used while travelling without Internet access (Notion, I’m looking at you!). My requirements:

1. Offline notes with online sync
2. Free with no paywall
3. Cross-platform – Windows, Mac & Android
4. The Notion-like block WYSIWYG text editing
5. Configurable to use PARA to organise notes (recent ~5yr old requirement)
6. Markdown export so I’m not locked into a tool
7. Great security
8. (optional) Graph view to show linkage between notes, so you can see grouped ideas
9. (optional) Import function or API to script the import
10. (optional) Collaboration with other note takers

Introducing AnyType

AnyType hits every requirement above and took them further; open-source, offline first, free forever, online peer to peer sync between cross-platform devices, block editing with Markdown text shortcuts, AnyType Gallery to share and use community templates, great security first, imports and exports, graph view, API and basic collaboration features. The app is positioning itself as a web3 everything app built on freedom and trust. They’re building something special here and since it’s inception has consistently improved month on month. It’s much more polished than it used to be, it’s a joy to work with nowadays. I’ll explain some of the features below, but honestly the best way to get a feel for it is to download and try it yourself: https://download.anytype.io/ The main concepts in AnyType to understand are:

1. ‍Objects - all things are objects in AnyType ‍
2. Types - categorise the Objects you create to have a Type ‍
3. Properties - attach metadata to Types and create relations between them ‍
4. Query - List view showing a single Object/Type
5. ‍Collections - Folder-like collection of different Objects/Types
6. ‍Templates - speed up your workflow with pre-defined templates for object creation

For example, to create a Book tracking system, you could define:‍

1. Book type with the properties: Title, GoodreadsUrl, and links to an Author
2. Author type with the properties: name & bio‍
3. Quote type with a property that links to our Book

Now, when you create a new Book, you can link it to a new or existing Author and write whatever notes about the book that you want. Then when inspired by a Quote, you can create a Quote and link it to your Book. The note taking is flexible, linkage can happen anywhere organically, and you can write whatever you want from within the Author, Book or Quote types. AnyType allows and in fact encourages these relationships between Types.

Quickly explaining PARA

If you’re new to Tiago Forte’s PARA methodology, you’re in for a treat. PARA is a simple yet powerful system to organise your digital life—whether that’s notes, projects, or files—into four clear categories. It stands for:

• ‍P - Projects: Active tasks or outcomes you’re currently working on. ‍
• A - Areas: Ongoing responsibilities or spheres of activity without a specific end date. ‍
• R - Resources: Useful reference materials or topics of interest.
• ‍A - Archives: Inactive items you want to keep but don’t need right now. As you use this system over time, you’ll develop an intuitive sense for where each note belongs. The key mindset shift for me was letting go of the need to choose the “perfect” category and remembering that it’s easy to move things around later.

How I use PARA within AnyType

Using PARA inside AnyType means you can create custom Types and Properties for each category, linking notes, tasks, and references easily. You can quickly switch between your active Projects, Areas and Resources, while your Archives keep everything tidy but accessible. I created a Template Space that should be available to copy from the AnyGallery thanks to my approved github submission. I’ll explain how it works below.

Key features‍

• PARA Dashboard is a Query of type Queries with a custom property PARA Type set to PARA
• Projects, Areas and Resources are a Query of Collection objects with the PARA Type set to Project, Area, or Resource respectively.
• A collection with an Is Archive property checked will show as Archived on the various dashboards.

1. ‘PARA Type’ Classification

• Introduces a dedicated “PARA Type” property that allows you to specify whether a Collection is a Project, Area, Resource, or **PARA.**‍
• When a Query’s PARA Type is set to PARA it will show on our PARA Dashboard.
• When a Collection’s PARA Type is set to Project, Area or Resource, they will display on their respective Query of Collections dashboard i.e. Projects, Areas, or Resources
• This structure makes it easy to filter, group, and view your content according to the PARA methodology.

2. ‘Is Archive’ Property

• Every Collection includes an Is Archived property.
• Easily mark items as archived to declutter your active workspace without permanently deleting anything.
• Archived items are automatically filtered out from main views but remain accessible for future reference.
• See all archived Projects, Areas and Resources both on the Archived query view, and also within their respective Projects, Areas, or Resources query views.

3. Manual Link Management via Templates

• Every Collection also has a “PARA Linked to” property, this overcomes a limitation I noticed where Queries were not showing on the Graph view for Collections created from their Query view.
• Templates automatically create this manual link property for each of our Projects, Areas , or Resources
• This linkage can be removed at any time, giving you control over what appears in the Graph view.
• Declutter your visual workspace by removing unnecessary connections, while still maintaining essential relationships.

How it all works together

• ‍Creating New Projects, Areas or Resources: Templates are used by default to add new Projects, Areas, or Resources. Each template ensures the correct PARA Type and properties are set when creating an object from each dashboard.
• ‍Change PARA Type: Updating the PARA Type property on a given collection will move it between Projects, Areas or Resources as needed. This is especially helpful if, for example, a Resource evolves into a Project later on.
• Creating New Objects: Within any specific Project, Area, or Resource, you can add any object—the default is a Page—and it will be created with the appropriate properties. You can link any type, such as Tasks, Bookmarks, Books, Quotes, literally any Type.
• ‍Manually Link to PARA: Use AnyType’s “Link to Collection” feature to link any object newly created to a specific Project, Area or Resource yourself. This is particularly useful in Graph view if you like to see clusters of related information.
• ‍Archive Projects, Areas or Resources: Archiving is handled with a simple checkbox field on Collections that have relevant PARA Types.

Shared Gallery

There’s a wide variety of community-created templates available for AnyType, giving you plenty of options to explore and enhance your workflow.

It’s easy to import and play with them too, simply go to the gallery and import it into a new space. While you can import templates into existing spaces, be mindful that this may introduce extra Types and Properties, potentially cluttering your setup and making cleanup tedious. So my advice is to first verify the new Types and Properties in a new, isolated space before merging them it into your main spaces.

Conclusion & Next steps

If you’ve made it this far, congratulations! Hopefully, you’ve picked up something new and feel inspired to try out AnyType or the PARA system for your own daily organisation.

Bonus note on AnyType’s API & MCP server

Recently AnyType added an official API and Model Context Protocol (MCP) server. This advancement allows AI agents and assistants to interact with and update your documentation directly. In the docs here they highlight RayCast.ai for seamless AI Chatbot integration and workflows.

With these tools, RayCast turns your AnyType knowledge base into an even more powerful resource—ready to answer your questions and automate parts of your note-taking system.

My website has gone through many iterations and frameworks:

1. Static site using html, css & JavaScript
2. Gatsby.js React framework
3. Quick attempt at using Next.js React
4. Nuxt.js Vue.js framework
5. Now Webflow

My goal was to get something that worked easily, let me update a blog quickly, and didn’t require too much maintenance. Finally, I’ve achieved that vague and ambitious goal with Webflow.

Bit of historical context

Basic static site

While at University, near 2015 I was first learning software development as a main focus. I felt like I needed an online personal profile, but I didn’t really know how to do it. So across 4 years I managed to cobble something together, though it wasn’t pretty and I haven’t got any screenshots to show it off. My first profile website used basic html and css. Honestly, not enjoyable… the css process took so much time and tweaking that eventually it caused longer and longer procrastination breaks (gaming). I finally understood the devs struggling with css memes. Skip ahead to my first graduate job, I learnt there are other ways to develop and I trusted that there had to be an easier way than crying over css (joking). So, with the internet at my disposal, I searched for a modern framework to build and deploy my site.

GatsbyJS

The many rabbit-holes I ventured figuring out what the “best” framework was, watching YouTube, doing tutorials of each framework and creating starter programs. Eventually I realised I was thinking about doing, but not actually getting anywhere, so I just leapt into one of them. Introducing GatsbyJS, which at the time was a new React framework that helped build static sites quickly from templates, it even had blog plugins to make the whole process easier, so this was exactly what I was looking for… or so I thought. My basic knowledge of html, css, and javascript helped, but I had to learn React, JSX syntax, Webpack, and how to deploy my site. They had docs, but it wasn’t super polished so there was a lot of time spent figuring it out on my own. On a grad salary I was looking for the cheapest (free) options for hosting; there were two options: GitHub Pages and Netlify. First, I tried GitHub Pages and succeeded in deploying it, but the workflow was tacky, it required me to run a command from my local machine to deploy it, which didn’t feel right. I learnt about Git Flow and wanted it to deploy when I pushed up my code up to master (I know that’s not entirely correct, and am now aware that PRs and merges offer a nicer dev workflow flow, but at the time pushing to master was the way). So I moved to Netlify, which watched your repository for changes on a specific branch, and deployed whatever was there for you. This worked great for me, and allowed me to iterate with development on Gatsby quickly. However… as it was early on, the framework and plugins were changing often. Updating the npm packages caused the website to break so much that I gave up making changes to the website altogether. I resigned to allowing my website to exist in it’s current state. Until I got inspired by a front-end engineer at another company I worked at. For added context, my career was taking me down the DevOps Engineer pathway, but I still enjoyed playing around with front-end development. So I’d chat to other engineers about what they were doing and what they enjoyed using. This inspired my next framework choice that I thought would surely be easier.

NuxtJS

Inspired by my teammate, and with an expert to back me should I fall into any of the traps. I started building a Nuxt website. I gave up on designing a website and though, “lets just get something working”. Following through the docs I cobbled together a very basic website that used their content module to generate pages from markdown. This allowed me to at least write blogs using markdown text and the pages would generate on deployment. The deployment was done through GitHub Pages and I eventually got it deploying using GitHub Actions, which I was using more at work. This was great and Nuxt v2 was working well. Then the Nuxt v3 update happened, and all my shit broke. So I spend another weekend tweaking and figuring out why the content renderers wouldn’t load my blog pages from Markdown. Turns out the interface changed for how we loaded content, so the old method didn’t work. With that fixed, I happily added a blog about using ChatGPT or Perplexity to support my writing style. Woohoo!

Time skip to now

I’m taking a break from work, travelling asia (see /blog/now-june-2025), I decided to attempt to write blogs to capture my learnings while creating music. Looking ahead to writing 10 or more blogs, I realised how much of a hassle my Nuxt stack would be for updating and posting blogs. Changes required markdown updates pushed to a git branch and merged into main, I could immediately see this adding friction that would stop me from doing the actual blog writing. Also because of how I was loading blog images, it made the whole /public/img/ directory structure ugly, and in the future I would have a huge dump of images that were difficult to update. Honestly, I might not even write so many blogs that this becomes a problem, but this future problem was enough to distract me from making music. I didn’t want to create a big mess that I had to clean up later so I looked for another solution. I looked into WordPress quickly, which a couple older colleagues of mine used for their personal blogs and another colleague who built the company websites using WordPress. It would’ve worked, and been cheap, but I didn’t want to touch it. It felt old, and I knew there were better tools out there.

So, why Webflow?

I was on LinkedIn one day and saw a post from Nikolai teaching people how to use Webflow. Nikolai actually introduced me to webflow way back in 2017 and it’d been swirling in my brain ever since, it seemed like a great tool. It’s fantastic for Web Designer to build websites without worrying about the nitty gritty of maintaining a website with code. It still requires fundamental understandings of website development and html & css, but it’s mostly no-code. After the whole Nuxt Vue major update I thought I cbf with this, lets try Webflow out. I don’t want to pay for Webflow yet, thats why my site is only available on https://westernwilson.webflow.io, in the future I intend to upgrade it so I can use my personal website url under https://westernwilson.com

What is the development process like?

I kind of cheated a bit, I used their AI tool to design and kick-start my new and improved personal profile website, then I tweaked the required bits and here we have it, a new website! The tweaking of Webflow was much easier for me than the frameworks. Everything you need to understand is in their docs, and to publish is very easy. No updating of packages under the hood, and it all just works. To be honest, the Webflow structure I currently have could probably be improved, but I’ll leave it as is for now since it works. The major learning was configuring the Content Management System (CMS) that comes in-built with Webflow to store my blogs. Couple searches on the web and Perplexity helped me figure this out over a day or so. So now, I have a blog website that gets updated from a CMS. I’m stoked! Adding links or audio files is a lot easier than before too. You still need some understanding of how web development html tags are structured and how they pair with css styling, but for me this solution is perfect.

Final words

I’m happy with Webflow, because now I can focus on playing around making music and writing blogs instead of constantly upgrading and tweaking my website.

Overview

VS Code is renowned for its versatility and has extensions for all types of development activities. This guide will show you how to harness its power as an SSH client, giving you a seamless development experience on remote servers.

What is VS Code?

Before we get started, let’s quickly clarify what VS Code is. Visual Studio Code, often referred to as VS Code, is a free, open-source code editor developed by Microsoft. It’s widely used in the software development industry and is known for its robust features and extensibility.

What is SSH?

SSH stands for Secure Shell, and it’s a network protocol used for secure data communication, remote command-line access, and other network services. It’s a fundamental tool for connecting to remote servers securely.

Official VS Code Tutorial

For a detailed, step-by-step guide on setting up VS Code as your primary SSH tool, please visit the official VS Code tutorial.

In a Nutshell

In a nutshell, here’s a brief overview of what you’ll find in the official tutorial:

• Installing the required VS Code packages on the SSH box.
• Installing the Remote Developer extension on your local machine’s VS Code.
• Setting up your SSH config file for VS Code for easy reconnection.
• (Optional) Creating an SSH key for effortless logins.

By enabling VS Code’s ssh capabilities you can centralise the tool you use for development. Happy coding!