Posts tagged "tools" - nolan caudill's internet house

Building a static website with Claude

Mon, 09 Feb 2026 22:21:25 -0800

I moved this personal blog to a static site from Wordpress tonight, mostly on a whim.

If this was 10 years ago, I’d have written out a step-by-step instructions of exports and one-off migration scripts but since this is 2026, this is a much more anticlimatic post.

Instead, using Claude Code, I essentially said, “Here is an export from my wordpress site. Make a static site with a clean, simple layout, preserving the current URL structure.” A few minutes later, after asking me a few questions like which generator to use (I went with Hugo), I had a new site. That was it. Magical!

I then quizzed Claude on the best place to host a static site, and it suggested Cloudflare Pages. Setting up the GitHub hook so that a git push automatically triggers a new site build took a couple of minutes but that was the bulk of the complexity. Cloudflare has a very easy to use DNS migration wizard. Even though that’s always a little scary, the switchover worked fine.

I have to say: building software with Claude is fun. I had stepped away from writing code for the better part of a decade and stepping away for a few weeks usually means new languages, libraries, tools, and services to research and learn how to use. Even when I had the itch to build something, the starting cost was huge and I just wouldn’t. Now, I can just describe what I want to see and off it goes. Excited to keep doing this more.

Software I gladly pay for

Wed, 11 Sep 2024 14:25:23 +0000

I always enjoy reading about software that people will actually choose to pay for and endorse, so here’s some of mine.

Deliveries: We probably buy more than we should over the Internet, but this helps us track what’s coming and when. The bonus feature that I enjoy is the calendar syncing that add arrival dates so I can see when things are coming out at a glance. It has some fiddly bits, like a couple of the delivery services don’t expose an API Deliveries can hit to automatically update but being able to manually set delivery dates is a decent workaround.

Flighty: If you travel a lot by plane, Flighty can you help stay up to date with all the connections, delays and flight times in one polished app. This past summer, we did a multi-week, many-many flight trip to the East Coast, Amsterdam, and Copenhagen, with connections galore and this app was my go-to. It knew about delays sooner than the boards at the airport in some cases, and had lots of extra info about flight ETAs that were fun to know, like how long you taxied for. Another bonus: it syncs with your calendar (if you’re noticing a theme…) which would auto-update as flights moved or got rescheduled, leaving one less thing to think about before travel.

Timeshifter: With that same big trip, jet lag was a concern and this app was truly clutch. You enter in your flight information and sleep patterns and it gives you a regimen of when to seek and avoid light, when and when not to drink caffeine and other tips leading up to the trip. We followed it fairly well, but not perfectly, but landed in Amsterdam after an overnight flight feeling adjusted and honestly had no noticeable jet lag for the trip.

Macrofactor: I saw a trendline on my weight earlier in the year that I wanted to reverse so I pulled out a calorie tracking app (again) to attempt to lose some weight (again). In reading about nutrition, I saw Macrofactor pop up a few times. This app works by “simply” taking the number of calories you take in, looking at how your weight changes over the previous week and using that to figure out how many calories you typically burn. It then spits out some calorie goals for the upcoming week. Best of all: it’s the first weight management thing I’ve done that’s ever worked, and I learned a lot about nutrition along the way.

Raycast: I’ve shied away from using the Spotlight-esque apps over the years but decided to give Raycast a go. I use it probably a few hundred times a day now. It has simplified logging into my next Zoom meeting, rearranging the windows on my desktop, gives me a more useful calculator and unit conversions tool, and the quick links make it so much faster to go to the same 3-4 URLs I go to during the workday.

YNAB: Having a budget gives me a great peace of mind and YNAB works perfectly for me. It’s a more powerful version of the envelope system of budgeting (“give every dollar a job”) and it’s nice to see how our spending breaks down and how particular goals trade-off. We’ve been using it for our budgeting software since 2017 and I’m positive money would be a greater source of stress if it were not for YNAB.

These are a few of the daily go-tos, and is undoubtedly an incomplete list, but these are the few I rely on and willingly pay money for.

Tiny Tiny RSS, a Google Reader Replacement

Sat, 15 Jun 2013 07:00:00 +0000

Google Reader is being discontinued on June 30th. This is probably the web application I’ve used the most and for the longest so I was a little bummed when they made the announcement. I immediately started looking for its replacement. I wanted the replacement to be something that had a liberal open-source license (so I could poke at the code and share patches) and something I could host myself to avoid having to worry about the whims of some big corporation’s product roadmap. After some exploration, I found one called Tiny Tiny RSS. It used just PHP and MySQL, which meant I didn’t need to install or maintain any new things on my server. The code looked relatively sane and clean so I downloaded and installed it. Within probably half an hour, I had a very usable and surprisingly feature-rich RSS reader that even included an API. It’s also multi-tenant right out of the box. The only caveat I had was that it didn’t have a usable mobile version. Today, I figured out that some kind developer had written a plugin that exposed a fever-compatible API which Reeder for iPhone supports. (Hint: After installing the plugin you have to enable API access for your account to make it work. In retrospect that seems obvious, but I had to printf-debug my way through the app to figure why it wouldn’t accept my username and password.) The end result of all this is that I have an RSS reader that will stay running as long as I’d like with no danger of it and/or my data being sold to the highest bidder along with a nice-looking iPhone app to read on the go. This whole thing is also proof that the web can be resilient to vendor lock-in as long open standards (like OPML, RSS, HTTP, etc.) and the spirit that encourages them (like Reeder’s your-URL-goes-here screen) sticks around.

How Secure is my Dropbox?

Sun, 14 Apr 2013 07:00:00 +0000

The answer to this is: Secure as any other “private” content uploaded to the Internet, which is “not very.” Dropbox is a widely-used service that lets you keep a specific directory in sync across many computers. Copy a file into the Dropbox folder on your work computer and it is nearly instantly available on your phone and your home computer. No more emailing files to yourself or scrambling to find a site that’ll let you upload a big file. They even give you a slick, web-based interface to browse your files. This all sounds really easy and convenient which, unfortunately, usually means it’s not secure. The problem is that Dropbox stores your files on their servers encrypted in a way that they can read them. First, what does one mean by “secure”? My definition of secure is that no one else in the world could possibly see the contents of something unless I let them. If it’s a text file, no one except me can read it; if it’s a photo, no one except me can see it. For most of the files people want to share or sync, the security level of Dropbox is adequate. Disregarding that bug a couple of years ago where anyone could log in with any password, Dropbox is password protected and they recently introduced two-factor authentication, where you have to type in both your password and a short-lived, always-changing set of numbers from your phone. All connections between you and Dropbox go over SSL. This means no one can snoop on files you send to Dropbox and no evil person can trick your computer into thinking they are Dropbox. From my limited knowledge of Dropbox’s internals, gleaned from reading a few security analysis reports, they do encrypt your files before uploading them. The downside is that they own the key to decrypt them “to ensure everyone has the ability to view and share files on the web painlessly.” Translated, this means that people-who-are-not-you can read your files. I’ll assume that Dropbox, the company, follows industry standards for security. Only certain engineers get access to certain machines. Only certain support people get access to your files as necessary. Only code that’s been properly vetted for security bugs is deployed. The weak spot in all of Dropbox’s efforts are the people. This isn’t a knock on Dropbox at all; people are the weakest spot in ANY security system. Servers are constantly barraged by people trying to break in, and they often succeed. Support people sometimes stray and snoop at files they they shouldn’t. Developers write bugs that let random people on the internet get access to things they shouldn’t. It happens, despite best efforts in engineering or culture. People make mistakes. If you’re wanting to keep your music in sync between computers, or want to quickly send a photo to a friend, Dropbox is great. It’s incredibly convenient. If it’s a file that you wouldn’t want another person to have, like your password file or financial documents, you don’t give it to Dropbox. There is one (and only one) workaround to this though. If you encrypt a file on your computer before giving it Dropbox, they won’t be able to read it. 1Password, the popular password manager, takes this approach. They store your passwords in a file they then encrypt on your computer using high-grade encryption software. They then place this encrypted file into your Dropbox. Even if this file was to leak somehow, no one else but you could open it. Dropbox is purely the syncing service, which is still a handy thing to have. The sad part of encryption is all the tools are terribly hard to use. TrueCrypt is probably the easiest of the bunch but there’s still a bit of learning curve to the terminology (partitions, volumes, and encryption algorithms?). I use GnuPG to encrypt my files, but that involves using a command-line interface, something most people aren’t (and probably shouldn’t have to be) comfortable using. OpenSSL is the Swiss Army knife of all things encryption but using it properly is like knowing some secret wizard’s spell. Dropbox can read anything you give to it, in the state you give it to them. Give them something that only you can read and you get the joy of having this file everywhere while still being the only one who can open and read it. I’m not saying to not use Dropbox. It’s just a fact that any file uploaded to Dropbox, given enough time, stands a good chance of being seen by someone you don’t know, so adjust your file syncing accordingly. This post was inspired by a Twitter message from Kellan yesterday.

FlickrTrickle

Sat, 30 Mar 2013 07:00:00 +0000

This is a little tool that I wrote a couple of years ago that I think a handful of people use occasionally. To keep up with my philosophy of “if it can be open sourced, it should be open sourced,” combined with asking for people’s read-and-write privileges to their Flickr accounts without showing the code, I finally got around to taking out the secret config bits, writing a README and opening it up. Below is a copy of the README.

What?

FlickrTrickle lets you slowly introduce photos you upload to Flickr into your contact’s streams so they’ll get seen by working around Flickr’s interface that only shows the last five photos show from a contact, regardless of how many they just uploaded.

This is the code behind FlickrTrickle.

Why?

So let’s say you go on a trip, like hiking the Appalachians, touring federal prisons, or visiting Disneyland, and get shutter-happy and take more than 5 photos. With the rise of digital cameras, taking multiple pictures in one day is not unheard of, and is practically encouraged in some circles. Now, you want to upload your more-than-a-handful number of pictures to Flickr. You’re quite proud of these photos, either due to their composition, their dynamics, or the way the light plays softly against edges of your latte art next to the kitten, and want your friends to see them. But Flickr (rightfully) wants to keep your photos-from-your-friend’s stream from being dominated by one person if they were to upload 150 photos so they only show the last five uploaded from each your contacts. This is very egalitarian of them.

Through anecdotal experience, anything beyond that 5-photo barrier gets next to no views. Maybe my storytelling abilities don’t drive people to want to see those next photos but the interface doesn’t help me out either.

You want more. You want your friends to see your photos. The best way to make this happen for me is to only upload a maximum of five at a time. Remembering to do this and keeping track of what you’ve already made public is an exercise in bookkeeping, something that computers are quite good at and my wife will attest to that I’m terrible at.

How?

The way around this is to use three different Flickr features: tags, privacy settings, and the date-posted-at attribute.

Flickr sorts your photos in the global stream by the date posted to Flickr. Like most things on the site, this is adjustable by the API, meaning you can lie to the computers and say “yep, I uploaded this one a second ago even though you saw me upload it two weeks ago.” Computers are gullible that way. We can use that superpower and upload photos to Flickr whenever we’d like but set them private just to get them up there. Sometimes you want a photo to be a private without being visible to this trickling-interface (trickle-face?) so the code only pulls photos you’ve tagged with “flickrtrickle.”

Then through a magical web interface (aka, this code), you select the ones you want to be visible to your friends and the date stuff automatically work itself out so it looks like you uploaded them at that moment.

You get to upload all your photos to Flickr at one time, and then “trickle” them in a few at a time.

Security vs Convenience

Tue, 18 Dec 2012 05:57:00 +0000

Until a few months ago, my Flickr account was still using the same 6-letter password that Yahoo automatically assigned to me in the late 1990s. Most of my other accounts were using a variation of this password, with a dumb algorithm that used pieces of the site’s URL with some numbers attached. None of this was good.

After Mat Honan’s terrible hacking fiasco this past summer, I realized that, yeah, this could happen to me too and I should just take care of locking everything down the best I can. Here’s the current state of how I’m staying safe online.

The first major improvement I made is that I started using a password manager, going with LastPass. I’ve used a Linux laptop at home forever and use Macs at work and have an iPhone so I needed something that worked on these different systems. LastPass has an iPhone app, a Chrome plugin, and a nifty website so this worked for me. Quite a few of my friends use 1Password, which works on the same principle of storing passwords in an strongly encrypted file. The main difference is that LastPass stores this encrypted file for you whereas 1Password requires you to take care of transporting, protecting, and syncing this file.

After using a password manager for a few months, there’s no way I could go back to remembering a hundred or so slightly different passwords and often having to reset them due to forgetfulness.

I then started making the effort that every time I hit a site that hadn’t been added to my LastPass account, I would change the password to a new, machine-generated password. I also started storing fake answers to security questions alongside each password in a special notes field the manager provides. Now every site I log into has a long, hard-to-crack, and unique password with security questions that no one could answer.

My current goal is to know only the password to my password manager with all the others locked away. The downside to this is all my passwords are protected by just one password which is a weak spot as passwords can be logged, guessed, or brute forced. Luckily, LastPass offers two-factor authentication which means that people would need both the password and my phone that runs the Google Authenticator app.

The tricky thing

Using two-factor authentication is incredibly secure but the tricky part to consider is what happens when I can’t access my phone, like in the case of the battery being dead, or stolen or lost in the worst case. Most services that offer two-factor authentication also give you the option to set up ahead of time a short list of one-time passwords. These should be generated and stored where you always have access to them. I store these in two spots: in my wallet and a symmetrically-encrypted file on my personal server for redundancy.

Security and convenience sit on opposite ends of a spectrum. While it takes a little effort to set up, it makes your accounts much more secure from data leaks and hacking attempts and not having to remember multiple, insecure passwords is a burden one should be happy to be relieved of.

A Well-Designed Post

Mon, 28 Nov 2011 08:00:00 +0000

Yesterday, I toyed around with the idea of turning my entire blog into a nicely-formatted book, in both PDF and epub format. This would probably interest no one but myself, but I’ve seen other people turn these online words into a feel-it-with-your-hands book, and to me, seeing something physical from the effort seems to add more weight to the work, but figuratively and literally. I wanted Latex output, so I installed pandoc (which might be one of the most magical pieces of software I’ve ever used) and ran it across the Jekyll-created HTML. I then started the yak-shaving to clean up the headers and footers and download the remote linked images. The part I enjoyed most about using pandoc is that it automatically did a lot of the spell-casting that resulted in nicely-sized images that always gives me fits when dealing with Latex. I then tried to work all these steps into an automated flow, but realized that beyond putting files in their appropriate places, I actually enjoyed the manual “typesetting” that Latex needs so I tried to stop engineering things for once. Once I actually saw the some hundred-odd paged book, I had a few more ideas of things that might neat to see in print from the past year and thus don’t have anything to show yet for the book efforts, but I did want to just put up a sample of what one post looks like. Here’s my Thanksgiving post from last week. There’s something odd about seeing what was originally web content in a more typographic form, and it will be even more odd seeing it in print (if it progresses that far). I plan on documenting the whole process as I’d like to see other try this out.

Nobody puts tarsnap in a corner

Thu, 24 Nov 2011 08:00:00 +0000

I woke up this morning around 7:30 with my laptop (a Lenovo R61i running ArchLinux) not feeling quite as snappy as usual. After viewing top, I saw where my nightly backup to tarsnap was still running, which kicks off via cron. This script usually takes 5 minutes, tops.

My first feeling was that it was probably the couple of gigabytes of email that I backed up from Gmail yesterday, though even with the extra bits, my outbound bandwidth should have been able to allow that go through much faster than 4+ hours.

So I attached to the running tarsnap process with strace, just to see what it was doing. I saw lots of selects, receives, and sends, so it appeared to be sending things across the network, which was good.

Seeing the network activity, even though it was behaving properly, set off alarms. A bunch of new files to backup wasn’t the only thing I changed yesterday: I had also switched out my Linksys WRT54GL’s router firmware with Tomato, mainly due to its extensive Quality-of-Service settings.

We’ve got a few streaming media devices around the house and I wanted to give them priority (based on MAC, static IP, network interface, etc).

Another nice thing about Tomato is that comes with graphs. I love graphs, and Tomato gives you bandwidth graphs, broken down by timerange and NIC.

Pulling up the graph verified that I had a block of outbound traffic start at 3am, but it was never rising above 30kbps. It was being capped.

So I went back to the QoS interface and sure enough there was a class of traffic labeled “lowest” for “Bulk Traffic” (which matched any TCP/UDP packets heading out to a port 1024 or above) and it was being capped at 30kbps. While fiddling with the inbound limits in the QoS admin, I completely glazed over the outbound limit defaults. (Also, this is why I’m not a network operator.)

Since this is the only outbound traffic of any significance through this router, and I run it at night to not interfere, I just disabled all outbound limits.

Here’s the 24-hour bandwidth graph after turning the outbound limits off:

The green is outbound traffic, being capped for several hours, and then spiking and then quickly finishing.

So Tomato is awesome but is evil in that way that only computers can be, which is by doing exactly what you tell them to do.

My New Rule for RSS

Tue, 25 Oct 2011 20:00:00 +0000

A couple of months ago, I realized that I spent way too many spare moments in front of my computer screen, trying to get my Google Reader unread count to zero. Then, I realized that when I did get to it to zero, I got agitated. I had beaten the game, killed the end-boss, and now I wanted to play again. So I was bothered when it wasn’t zero, and I was bothered when it was zero, and this wasn’t good. So I declared bankruptcy and started over on the whole thing, unsubscribing from everything. (After carefully backing it up of course. Every feed is sacred, or something like that.) I added back the blogs of a few close friends, and instead of the 20 or so music blogs subscribed to one good aggregator. I debated resubscribing to some of the big tech blogs, but I figured my daily visit(s) to Hacker News and simply talking with my friends and coworkers would get the important stuff in front of me. So now that I’m slowly adding back blogs I truly find useful and give me more than they take (in time, in attention), I stumbled across a good rule for my RSS reader: if I have to start adding tags or folders to keep my feeds organized, I have too many. I just added a new RSS feed and started to tag it, you know, to keep my addiction organized. I then stepped back and realized that the reason I was tagging it was so that I wouldn’t feel crushed by seeing so many unread blogs in my reader. These folders masked the issue. It was similar to what a kid does when he doesn’t want to finish his vegetables so he spread them around on his plate to make it look like he ate more than he actually did. So since I’ve declared bankruptcy on my RSS reader and did the major housecleaning, I feel calmer when I’m front of my computer, and less like I need to keep hitting the lever for the next fix.

My Jekyll and Git Workflow

Sun, 03 Jul 2011 07:00:00 +0000

A few weeks ago, I decided that I wanted to start blogging again. The reasons for why belong to another post but this is a purely technical explanation of how I setup git and jekyll to do things like drafts, site design tweaks and a write-anywhere environment.

git: savepoints for poorly formed thoughts, and a little distribution

From painful past experiences in code, I knew that version control was a must and I knew git, so git it was. Also, I could fork Tom Preston-Werner’s original jekyll blog, which I liked because it was simple and was clean enough that I could edit it without too much effort. Another reason I’m using git is so that I can write from different physical locations. Ground zero for clumsy sentences is my laptop. My anywhere-I-am writing location is sitting on the same server that I run the site from. Publishing from my laptop is just an rsync, and from the server is just a cp away. I’ve got one central repository on the server that is just a bare checkout of the blog. This is my push and pull point for both my server and laptop writing repositories. I probably could set both writing environments to talk to each other directly, but I like the simplicity of having a third repository that just gets pushed to, especially if I do some writing in one and then switch to the other. My github repository should more or less mirror what you see on the site. The only reason it won’t is if I’m holding back a few minor commits so I don’t spam people that follow me on github.com and I’ll batch those up. It’s only my master branch though, which doesn’t include in-process items, and I’ll explain that in a bit When I’m at home, or have my laptop with me, I can just write locally. If I don’t have Internet access for some reason, I can keep going. This is a great improvement over my last WordPress blog. Having to write in a form field in a web browser offers too much distraction since all those interesting things are just a tab away.

ssh -L 4000:localhost:4000 nolancaudill.com

If I don’t have my laptop, I can just ssh into my box, locally forwarding port 4000, so I can use the webbrick server and see things in my browser by hitting “localhost:4000” as if I were working locally.

git: also, great for drafts

Now that I’ve got distribution and publishing down pat, I’ll explain how I do drafts. This is actually really simple: I just use a new branch coming off the master branch for every post I’m writing. When I’m ready to publish a post, I just checkout master and do a git merge –squash branchname and, bam, I have one commit on my master branch that introduces a new post, including any images that I’ve added. I do a squash since I don’t really care to publish my fumblings with the English language. It’s a bit of a shame that I lose the historical record of how the post was formed since I have the data, but I realized that I would never look at it again and I don’t want the overhead of having to deal with a long standing branch for every draft. Since I’m basically trying to keep two writing environments in sync, I found it’s crucial to not do any destructive branch operations like rebase. It’s tempting since I might make a change to my master branch, like a CSS change, and want to just move my draft to the end of the branch. It’s better to just do a merge and while that’s messy if it happens a lot, as soon as that branch is published, the branch goes away. Whenever I stop writing for the session, I commit all changes to my current draft branch and do a git push. My origin is set up as that central repository on my server as I push and pull a lot more frequently to that and it really is central to my flow. When I pick up at another time or place, I just do a pull, getting in changes from the other environment, and get going. Another change I made to my flow is adding the following to my bashrc:

alias jekylldraft='vi $(git diff --name-only master -- _posts/)'

With this, on one of my draft branches, I can just run jekylldraft and it figures out which file in the posts directory is not on master and loads it up.

design tweaks

If the design change I’m making is small, I’ll just add a new commit on my master branch. If something is more involved, I’ll create a new redesign branch and just merge that in when I’m done. Simple.

scripts make my life easier, and so can you!

I’ve got a little directory that has three scripts in it: one to publish locally, one to publish from laptop to server, and one to do my two git master pushes. The first two could probably be combined but I’m a simple guy. The first thing either of my publish scripts does is checkout the master branch. This stops me from doing something dumb (again) like publishing one of my draft branches. I forget things but my script never does. And I use the && bash idiom so that if the checkout from master fails, the whole script stops.

backups

I use tarsnap to do a nightly backup of my writing directories (here’s my crappy perl script that does this). Git’s not a backup, especially the way I use it by only publishing the master branch to github.com. I have backups running on my Linode server, backups on tarsnap, and then the code physically stored in three spots (ie, laptop, server, and master branch on github). I’m not that paranoid about losing anything and requiring redundant backup methods, this was just more a snowball of backup systems that I didn’t fully think through.

other niceties

Since I’m writing on both a Linux laptop and a Linux server, I use vim as my common editor. Here’s the settings I use in my vimrc that seem to work for me. I’ve pieced these together using the vim docs and from other various helpful blogs that I’m a bad person for not writing down and remembering to thank them.

autocmd BufRead,BufNewFile *.markdown setlocal lbr 
autocmd BufRead,BufNewFile *.markdown map j gj
autocmd BufRead,BufNewFile *.markdown map k gk
autocmd BufRead,BufNewFile *.markdown setlocal smartindent
autocmd BufRead,BufNewFile *.markdown setlocal spell spelllang=en_us

The first three settings are the most helpful in writing prose instead of code. The lbr tells vim to wrap on word boundaries and don’t insert real linebreaks in the text. The j and k commands are mapped to to the helpful commands that goes down to the next row instead of the next line.

fork me

If you liked to see more about how everything is laid out, and get a head start on starting your own jekyll and git enviroment, check out my stuff and feel free to fork. Update: I added the bashrc snippet for jekylldraft. A second update was made later that stopped the bash subsitution (the backticks) from running everytime bashrc was loaded.