So, I went to update one of my other blogs recently, and realized the archive page on it was way out of date. The tool I used to update it was gone. Turns out I still needed it after all.

Why it can't just be a website

The old version was a Blazor WASM app. Since it ran in the browser, it couldn't call the Write.as API directly because of CORS. My workaround was to write my own API for the Blazor app to call, running as an Azure App Service. That API ran on free Azure credits that I've since lost access to.

I didn't want to host something again, since that means paying for it. And I didn't want to fight CORS again either. So this time around, the answer was an app that runs locally on my own machine. CORS only applies to browsers, so a regular app can call the Write.as API just fine.

Rebuilding it with Claude Code

I rebuilt this one with Claude Code. I treated it like pairing with another developer. Claude wrote most of the code, and I reviewed every change before it went in. Good news was, I still had the source code for both the old Blazor app and the API on my machine, so we had something to work off of. We ended up with a simple .NET console app. You run it with your blog's alias, and it spits out the HTML for your archive page. Same output as before, same CSS classes, so if you customized the look of your archive page, it should still work.

It still uses my WriteAs.NET library to talk to the Write.as API. But we swapped out CommonMark.NET and HtmlAgilityPack for Markdig, which turns the Markdown of untitled posts into plain text in a single line of code. CommonMark.NET hasn't been updated in years, so it was time anyway. Going through my old code also turned up a few bugs, like the app crashing on short untitled posts. Oops.

From reading through the old code to having a working app up on GitHub, the whole thing took one afternoon.

Rate limiting

The biggest surprise was that Write.as now heavily rate limits calls to its API. And because of how I wrote WriteAs.NET, a rate limited call just comes back empty instead of throwing an error. So the first test run fetched 20 out of 55 posts, and would have happily given me an incomplete archive page without me knowing.

The fix was to slow things down. The app now waits 10 seconds between each page of posts, retries if it still gets rate limited, and checks the number of posts it got against what the blog says it has. It's slow, but it gets all of them. Funny enough, that's an improvement over the old version, which used to time out on blogs with a lot of posts. An API key would probably help with the rate limiting, but I don't have one set up right now.

There was also a bug in the new version where some emojis in post titles showed up as code instead of the actual emoji. That one got fixed real quick.

It's on GitHub

Back in 2022, I said I'd share the source code for the WPF version of this tool if there was enough interest. This time around, I'm just putting it out there: writeas-archive-generator. It's a console app, so no pretty UI, but it does the job. You'll need the .NET 10 SDK to run it, and the README has all the details.

Eventually, I want to build a Windows desktop app with a UI for it. But for now, this works, and my archive page is up to date again. Thanks for reading, and I'll catch you in the next DevLog.

Tags: #DevLog #ClaudeCode #DotNet #CSharp #WriteAs #WriteAsNet

Discuss... or leave a comment below.

Choosing a tech stack

Part of my discussion with Claude was what tech stack to build the new site on. I considered React, ASP.NET, or even a popular static site generator like Eleventy. But at the end of the day, those all felt like overkill for a static site with at most 2-3 pages. I decided to just have Claude build it with plain HTML and CSS. Any future updates I can handle myself by editing those files directly, and with continuous deployment from GitHub to Netlify, shipping a new build is quick and easy.

That continuous deployment pipeline turned out to be one of the real benefits of using Claude to help build websites. It knows GitHub, and it knows Netlify. I had no idea how to set up a pipeline that deploys automatically from GitHub to Netlify, and researching it myself probably would've taken a few hours. With Claude, I had step-by-step instructions and a working pipeline in under 10 minutes.

Getting the design right

The first design Claude came up with was kind of bland. I told it the design was “meh,” and it responded by putting together three more options for me to choose from. One of the designs seems to have taken inspiration from this very own site, it mimicked the blinking cursor, but gave it its own spin, pulling in some design cues from terminals and code. I chose that one. I toned it down a bit from the original concept, but I think it turned out pretty well.

This was the other big benefit of rebuilding the site with Claude. I can build websites, but I'm not much of a designer. Giving Claude some direction and getting back multiple design options to choose from, made that part of the process a lot less painful.

Sunsetting apps.dinobansigan.com

In other news, I took down the Blazor Web App at apps.dinobansigan.com. The site itself is still up, but it's now been replaced by a maintenance page (also built by Claude Code). That also means the Write.as Archive Page Generator app that used to live there is now gone.

Truth is, that app has needed a fix every few months since I built it. The root cause is different each time, but there's always something going on with it. At this point I don't have the bandwidth to keep chasing the fixes, especially for something only a handful of people ever used. So I'm letting it go.

That's it for this update. Between the new homepage and letting go of of the archive page generator app, it feels like I freed up space in my brain to focus on new stuff. Thanks for reading, and I'll catch you in the next DevLog.

Tags: #DevLog #ClaudeCode #WebDevelopment #WriteAs

Discuss... or leave a comment below.