My last post seemed to garner a fair amount of interest and so I figured it would be good to cover some of the unspecified particulars that I left out of the previous post.
On Writing Cursive Left-Handed
I mentioned in the previous post that I write using a fountain pen (and occasionally with a dip pen). Given that, it may come as a surprise to some, but I am left handed. And while yes, writing with a dip pen does occasionally leave me with blackened palms from ink-smear, I've found this to be increasingly rare. It was certainly the case early on, but it's actually rare these days. Most modern inks dry incredibly quickly (so long as the right amount of ink lands on the page). That said I do end up with lots of ink on my fingers whenever I change the cartridges on my fountain pen.
I've also found that the amount of ink that smears on my hand went down now that I write in cursive. That may seem strange as cursive uses a lot more ink than print, but I think it has to do with the extreme bias I tend to write with. As I'm left-handed, I also tilt the page the wrong way. This helps with ink smear because I'm almost always writing on already dry text.
I tend to write on a 30-35° bias (32° is depicted here).
I was taught to write in the Zaner-Bloser cursive style as a kid and that's what I picked up again last year. As with all forms of handwriting, I've simplified my take on the style to be what I now consider to be a mix of Zaner-Bloser and the New American style which incorporate several print letters for capitals (ridding me of the annoying Zaner-Bloser F, G, H, and its uninspired A). None of these tweaks were born of me trying to adopt a formal style, instead each came from me tweaking my own style which happened to converge and resemble those above.
As part of this quest of mine, I spent a fair amount of time researching the history of cursive and its various styles. I learned a lot about how different techniques evolved and how the style I most recognize as "fancy, old-style cursive" (i.e. the Palmer Method) lost the battle mid-century to the style that I was taught as a kid. I still think the Palmer Method is cooler looking, but I have no interest in breaking my brain again to learn it.
On the Gear
My daily driver.
As this is partly a techie blog, I'd be remis if I didn't talk about the gear I use, though it's not particularly exciting.
As for the pens I use, my daily driver is a Schneider Base Uni. I have two of them (one stocked with black ink and the other with blue which I rarely use).
For my dip pen, I really like this ink. It's nothing special but it's cheap and works well.
Now What?
I continue to write a fair amount each day, and like I mentioned in my other post, that's largely because I find it fun to do. I've ended up performing a sort of near-nightly ritual where I write about something, anything just to feel the pen in my hand and hear the scratch of nib on paper. Sometimes it's (bad) poetry other times it's just stream-of-conscious rambling. Most of what comes out is uninspired or repetitive, but some aren't! Some are (dare I say it) even good!
Writing for me has become a new hobby, something I do to unwind and de-stress. That's not something I expected, but it is what happened.
I'm a software developer; I make my living on a computer. In this age there just isn't much reason for me to bother improving my handwriting.
I've thought that for years. While like most people my age, I learned to write in cursive in school (and to write in general) I'd essentially stopped using such an all-important skill in my daily life, save for the odd sticky-note here and reminder scribble there.
How It Began
I never wrote by hand. Why would I? You can't ⌘+f handwritten text, you can't change-control it, you can't even back it up easily. Why would you bother writing anything significant by hand at all?
An old programming teacher of mine once quipped:
People say that stuff on a computer isn't real, it's just digital. You can't touch it or save it. If the computer dies, it's gone. But I say they've got it backwards. Files on a computer are so much more real. I can prevent them from getting old, I can back them up for free, and I can send them to you without losing my original. On a computer, it's more real than it is on paper.
While I'm not sure I ever truly agreed with his point there, I did take that advice to heart for most of the past 12 years. In college, most of my work was digital already, and once school ended, I stopped writing by hand for all but a few rare tasks. I've always been a fan of writing in principle and many years ago I got a few fountain pens as a gift. Mostly they sat in a drawer, but occasionally I'd take them out and pine over how cool they were, then go about my day. I do keep a journal by hand, but writing in it has been an oft-forgot afterthought for most of my adult life.
Until last year.
How it Went
I've been working on a bit of a project now for over two years and part of that project has been writing a ton of notes for myself. I used to keep them in Notes.app on my Mac (since it syncs with all my devices), but after a while I got sort of disillusioned on doing that. As mentioned above, I live on my computer and it was starting to really get to me just how much time I spend at my desk, staring at a screen. So I took out a fresh notebook I'd been given years ago, and I started to take notes there instead.
I was hooked.
Within a few short weeks I had dozens of pages of notes, sketches, and musings in this little book (that was poorly made and now falling apart), so I dusted off the old fountain pens, bought some better notebooks on Amazon, and kept at it. I'd been taken in by writing. Writing by hand had so many downsides, but there were incredible upsides too. I no longer got distracted by notifications while writing. I loved flipping through my notes to review them. I rarely lost track of notes because I knew where they were in relation to other notes because human brains know where stuff is in space (mind-blowing, I know). I even got to talking to some friends about this new hobby of mine.
And that's when I went into overdrive. You see, a friend of mine gifted me a dip pen as a birthday present and I was supercharged.
One thing I've learned, that I find difficult to describe, is just how expressive it feels to write with pen on paper, even when you have nothing to write about. I was genuinely taken in by the sound of scritches of metal on paper. Over that first half of the year I wrote, by hand, over one hundred pages of text! That's likely more than I'd written in the past decade (and likely even further back) combined!
One thing still bothered me though: my terrible handwriting.
It's always been bad. It was bad when I was 5, 12, 20, and it's still bad. I knew it, everyone knew it. I never bothered to improve it either because:
I knew how to read it (most of the time).
Writing is something I rarely did, so why get better?
I'm lazy.
However, writing poorly didn't just mean my scribbles were sometimes difficult for me to read (and impossible for others to do so), it also meant something more important: my hand hurt when I wrote. My grip was too tight and my hand was unpracticed and sloppy. That meant I couldn't write for very long, even when I wanted to. What's more I've always romanticized writing (see the fountain pens above). I wanted to write better, but I didn't want it enough and I never really needed to. Now though, I was writing constantly and my bad penmanship was getting in my way.
It was time. I needed to revisit cursive.
How It's Going
I hadn't written in cursive since second grade. I stopped doing it the moment it was no longer required and I never looked back — until last October.
I can confidently say that I've written more cursive in the past four months than I have in my whole life before, combined. Easily. Over two hundred pages.
And it's great.
I'm by no means good at it, but I'm improving. I started with just trying to remember the letters. I have to imagine this is how learning to type on a DVORAK keyboard feels: your brain just breaks for a while. I even used those cursive worksheets they give to kids (with custom text of course).
After that I graduated to journaling in cursive and later writing in general in cursive. After four months, I can say that almost everything I write these days is in cursive by default. In fact I really only print when I need to scribble down a quick sticky-note or reminder (exactly as I did before all this).
My handwriting is by no means good, but I think my cursive is better than my print (especially if you take into account how long I've been practicing the latter vs. the former).
I've fallen in love with writing by hand. It's something I've always wanted to do well, but it took until now for me to set aside the time and effort to do it. I only regret waiting this long.
In what seems to be a new annual tradition, I'd like to discuss my favorite books from 2023. While I didn't achieve the same level of reading as 2022, last year was still one of the most productive reading years I've ever had—18 in total! You can see the totals of the books on my reading progress page, which at time of writing will look off since it doesn't count audiobooks in the counts (something I need to fix).
As a side note, I am curious if I can somehow automate the posting of recommended/recent books on that page. An interesting idea 🤔
In no particular order here are the books I recommend from last year:
The Book of Hidden Things, Francesco Dimitri
Francesco is quickly becoming my favorite author. I read Never the Wind last year and fell in love with his writing, and The Book of Hidden Things is more of the same excellent storytelling. Seriously, check him out.
Also he has a new book coming out this year, which I have already pre-ordered.
The Ocean at the End of the Lane, Neil Gaiman
This one was a really fun read. Neil Gaiman is a master and it shows. Really enjoyed this one, but I don't have much to say about it. A lovely story.
The Internet Newspaper, Adam Gnade
The cover hooked me immediately when I picked this one up on a whim from a local bookstore. The story takes place in San Diego (the author's and my hometown). If you like San Diego, 90's/00's music, and early 20-somethings mischief you'll like this. Also I love the size of this thing. Pocket novels are a lost medium.
The Secrets of Alchemy, Lawrence Principe
The book is an overview of the history of the practices of alchemy (mostly attempts to create a philosopher's stone and turn lead to gold), though it touches on the other uses for alchemy including metallurgy, medicine, and pre-modern chemistry. However the book really hits it out of the park when Principe does the homework and attempts to replicate several of the ancient alchemical recipes! Instantly I was hooked.
I read a lot of ancient history and one things I always try to keep in mind is that while ancient worldviews are very different from our own, and scientific thinking as we know it today didn't exist yet, that doesn't mean that people weren't experimenting, verifying, and sharing their ideas. For years people dismissed old alchemical recipes because we know their goal (chemically turn lead to gold) to be impossible, but that doesn't mean their experiments were useless, as Principe discovers. Some were very nuanced and precise. 10/10, fascinating read. Highly recommended.
It's available to rent for free on the Internet Archive, so please check it out.
Beren and Luthien, J.R.R. Tolkein
I read a lot of Tolkien this year and this one was my favorite. It's a little happier than the excellent Children of Hurin and features some of my favorite scenes from The Silmarillion. Basically if you enjoyed that chapter with the same name in The Silmarillion, you'll love this.
My favorite part: the song battle between a demi-god and an elf lord. 10/10. No notes.
As I am want to do, I spent an evening a while back putting together a Python version of John Conway's Game of Life: a "zero-player game" in which the board state progresses automatically according to a set of rules.
You can find the code for the game here. It requires just the Python standard library to run, so its easy to get started assuming you have Python >=3.10 installed. (It might run on lower than that but I didn't test it.)
A screenshot of my version of The Game of Life
Gameplay Video
Thrilling, right?
The initial board state for the game is randomized so each run-through is unique. Some end immediately, so you may have to run the script several times to see something cool happen.
Because it's written in Python, the game is single threaded and quite lacking in raw performance, but because it's written in Python the game was also incredibly easy to put together—taking about three hours in total including debugging, though I did spend three more hours optimizing the render performance for no reason.
As with most of my recent script projects, I don't really have a point or reason for doing it other than to have some fun building toy projects. Like I've said before:
Scripts are programming candy whereas app development is the real meat and potatoes. In a script you can take shortcuts, be a bit messy, and forgo worrying about the complexities of large software.
- Take A Break, Script Something
For all of the good things about Mastodon and the Fediverse more broadly, the technology has so far struggled to spread far outside of tech circles and into the broader public. Mastodon especially is pretty big these days, but its mostly filled with a lot of computer nerds like myself; there really isn't a very large music scene like there is on other social media sites.
I wanted to help fix that, so I threw together a simple Mastodon bot (a toot bot?) that regularly shares information about local music shows in San Diego.
With the San Diego Reader as its data source, the bot posts every hour about shows happening in the next day or two. Hopefully it will help my fellow San Diegans keep tabs on the music scene, and help to inspire more musicians and local music fans onto the platform.
So if you're at all interested in the San Diego music scene, be sure to follow sdmusiceventsbot on Mastodon! And if you're a local artist, make sure you add your event to the Reader to get yourself noticed by the bot! Be warned, San Diego has a lot of shows (more than the bot could ever reasonably post without looking like spam), so not all shows will get posted. The choices are random, so it's all up to the luck of the dice.
Nearly two years ago, my band The Fourth Section released an EP called Glass & Stone and this month we released our first, full-length album: Paper Peaks.
Recording an album has been a long-time goal of mine and something we as a band have been working toward for over three years.
I don't have much to say about the album, other than you should listen to it, but I can say it's been a true honor to have been able to make something like this with such amazing people. The three of us have worked hard since March to record, produce, publish, and promote the thing and it's taken a lot more out of us than I think we expected. Paper Peaks was a labor of love and something that could not have been done save for the support of my bandmates, our producer Jeff Berkley, and so many others.
If you like indie-rock and alt-rock, give it a listen and if you like it, please share it with your friends.
Last year Adventurer's Codex reached its 8th birthday. It's a milestone that I honestly didn't believe we'd ever hit, both because eight years is a long time and because—if I'm honest—I've never been sure how long this little project would actually last.
These days Adventurer's Codex is primarily built and maintained by three people: two are founders (including myself) and the third is a friend of ours, and as with any long-lived side-project Adventurer's Codex has occasionally suffered a lack of interest or enthusiasm from all of us. At the beginning the three founders met every week (sometimes twice a week) to build new features and plan the roadmap, later we rarely met at all, and sometimes nearly a year could go by before any of us even thought about Adventurer's Codex at all.
These days though the app is alive and healthy and with the support of our amazing patrons on Patreon we continue to make improvements and release features at a steady pace, and this year we're set to release a slate of amazing features that eight-years-ago-me could only dream of.
It makes me very happy to say this: the future is very bright for Adventurer's Codex.
I was browsing my Github Gists the other day, as you do, and I came across my first one published back in 2015: Rocket.py. This script was one part of a rocket trajectory simulator I built for a class in college. Now I don't remember much about that project, but I do remember that the simulation never actually worked—or rather that it never worked properly.
So since I had some idle time on my hands, I decided to spend an evening and take another stab at the project. These days I'm a far better programmer but I remember next to nothing about rocketry, and so I added a bit of a challenge for myself: try to look up as little as possible.
About two hours later I had this, a new rocket simulation that seems to produce accurate values (if you neglect drag—more on that later). Now my first simulation only output a set of numerical values for each second of flight, and while those numbers were useful for the class, they're not very interesting to look at so I added a little visualization (drawn with Python's turtle graphics).
Each phase of the flight is color-coded: green for powered flight, blue for cruising, and red for descent, and the flight statistics seem accurate enough to me when I plug in the numbers for the first stage of SpaceX's Falcon 9, so that bodes well. And at the end of each flight you get a summary readout in the terminal.
The code is pretty full-featured, and since it uses turtle graphics (and my other drawing project) it can even save the trajectories as EPS files for easy printing & saving. You can customize the launch angle, the burn time, specific impulse, fuel and payload weights and even the screen refresh rate using the many CLI flags. The script requires nothing but Python3.10 or later (with the tkinter module included of course), and so it's easy to play with if you're interested.
All in all it was a fun evening project, and I was especially surprised to find that I remembered a lot more of the intricacies than I expected. I still had to look up the equations for specific impulse, but that was it really. The kinematics stuff was beaten into my head in school so I doubt I'll ever forget that. Really the only thing that gave me any trouble was the drag—which I decided to omit anyway.
I had initially wanted to add the drag based on the mach number, but my memory failed me on how to do that and late-night searching only threw me down a rabbit hole of further questions. Past me knew a lot more about this stuff than current me does. In the end the drag was a nice-to-have feature anyway and by the time I got to that point it was nearly one in the morning, so I just declared victory and went to bed.
I have no real point to this post other than to show how much (and how little) I remember about rocket mechanics after all these years and to show off a cool bit of scripting. It's toy projects like this that got me interested in programming and they can be a really fun way to spend an idle evening.
Disclaimer: I think the values in the simulation make sense, but I didn't spend too much time validating them. If there's any real rocket people out there who find issues with my results, then I'm sorry; now you know one of the reasons I didn't go into aerospace.
I use Pine.blog for microblogging, and following the Post Once Sindicate Elsewhere strategy, I like to have those updates automatically cross-posted to other platforms like Micro.Blog and Twitter so that they gain a larger audience, and so that anyone who wants to can follow me no matter which platform or software they prefer.
Obviously I'm not manually posting to five different sites—that's what computers are for—and so I need some way to automate that work. Micro.blog makes most of that very easy since it can automatically ingest content from an RSS feed and not only add it to my microblog there, but also cross-post it to Twitter. That only leaves Mastodon out in the cold.
In recent months there's been a lot of new activity on Mastodon and I've really enjoyed seeing a larger segment of people discover such a great open-web focused tool. It was well past time that I add Mastodon to my cross-posting workflow, but there was a problem: Mastodon's posts are text only (with links at the bottom—like Twitter), but Pine.blog outputs HTML (or Markdown). I tried several tools, but each one would mangle my posts or just include the raw HTML as the text, neither of which was an acceptable solution. I needed something custom.
So I wrote a script! It runs every few minutes on the Raspberry Pi under my desk checking for new posts from Pine.blog and posting them to Mastodon. It starts with the raw Markdown, parses the HTML, strips and appends links, and even keeps track of what has and hasn't been posted before. It's a pretty handy script and I encourage you to check it out if you need something like it. I even made use of one of Mastodon's very handy features: Idepotency-Key which helps prevent duplicate entries from being posted in a short period of time.
As of today my posts are now Live On Mastodon, so you can rest assured that if you follow me there you aren't missing a beat. You'll get all... five posts I've made this year!
There's been a lot of buzz around ChatGPT lately and most recently the discussion followed Tom Scott's video in which he describes how he was able to use ChatGPT to generate working code to solve a problem—including asking it to fix several bugs with its own implementation—and then write an ad spot for him.
In the video Tom expresses his disquiet with the ongoing advances in machine learning and goes so far as to predict that "everything is about to change" in the same way "everything changed" once smartphones came along in the mid-aughts.
I've enjoyed using text-to-image AIs like Midjourney for a while now, but I'd largely stayed clear of things like ChatGPT. Tom's video though got me curious, and so I logged on to see what all the fuss was about.
tl;dr I was pleasantly surprised.
Introducing DeveloperGPT
There are so many things that developers do day-to-day that are at the same time important and dreadfully dull, and like many devs I find myself searching for ways to both save time and automate away as much menial work as I can. It's one of the reasons I love Bash so much. And while at some companies such work is often pawned off to junior developers in need of experience, as a one-man shop I have definite use for a sort of algorithmic junior developer who could take on some of that less-engaging work. And after watching Tom's video I started to hope that perhaps ChatGPT could be exactly that.
In order to see if ChatGPT could fill this role, I did what anyone looking to hire a junior developer would do: I gave it an interview.
Giving ChatGPT a Coding Interview
In total I gave ChatGPT five questions to answer. These questions were almost entirely development related and spanned the range of what I'd expect a junior developer to be able to do given time and access to the internet.
Test 1: Django Unit Tests: ✅
Prompt
write for me 4 python django unit test cases that each make a request to /api/users to do the following: create a user record, fetch a user record, delete a user record, and update a user record. Make sure to include partial update using the PATCH method. And be sure to use Python 3.10 compatible code.
Response
Sure, here are 4 Python Django unit test cases that cover the create, fetch, delete, and update functionality of the /api/users endpoint. These test cases assume that you have a Django application with a User model and a corresponding API viewset that handles CRUD operations for users.
from django.urls import reverse
from rest_framework.test import APITestCase
from rest_framework import status
from .models import User
class UserTests(APITestCase):
def test_create_user(self):
"""
Ensure we can create a new user object.
"""
url = reverse('user-list')
data = {'username': 'testuser', 'email': 'test@example.com'}
response = self.client.post(url, data, format='json')
self.assertEqual(response.status_code, status.HTTP_201_CREATED)
self.assertEqual(User.objects.count(), 1)
self.assertEqual(User.objects.get().username, 'testuser')
# ... (mine: omitted for brevity) ...
These test cases cover the basic functionality of the /api/users endpoint and ensure that users can be created, fetched, updated, and deleted. They also cover partial updates using the PATCH method. Note that you will need to update the URLs used in the reverse() function to match the actual URLs for your application.
The first test I gave ChatGPT was simply to write a suite of unit tests to verify that a Django User REST API allowed for standard CRUD operations. In general it did very well, even including a test for partial updates via the PATCH method, but it did assume I also wanted it to use Django REST Framework and its implementation of the PUT and POST tests don't include all the correct values. The assumption to use DRF is a fair one, but the other mistake is a red flag.
Still though it would have saved me from writing the bulk of the code—assuming it works. I didn't actually test the code.
Test 2: S3 File Clean Up: ✅
Prompt
write for me a python function that pulls data from a CSV file containing files that need to be deleted from S3 and that then deletes each file. Include error handling if a file cannot be deleted and return a list of all files that were and were not deleted. Also include suite of three test cases that ensure the function works, that errors are caught, and that the return value is two lists.
Response
As an AI language model, I don't have the capability to access files from your computer. However, I can provide you with a sample code that demonstrates how to delete files from S3 using the Boto3 library in Python.
import boto3
import csv
def delete_files_from_s3(file_path):
# Initialize S3 client
s3 = boto3.client('s3')
# Read the CSV file containing file names
with open(file_path, 'r') as f:
reader = csv.reader(f)
files = list(reader)
# Delete each file from S3
deleted_files = []
failed_files = []
for file in files:
try:
s3.delete_object(Bucket='your-bucket-name', Key=file[0])
deleted_files.append(file[0])
except Exception as e:
failed_files.append(file[0])
print(f"Failed to delete {file[0]}: {e}")
# Return the list of deleted and failed files
return deleted_files, failed_files
The function takes the path of the CSV file containing file names as input. It reads the file using the csv module and deletes each file from S3 using the delete_object method of the Boto3 client. If a file cannot be deleted, it is added to the list of failed files and an error message is printed. The function returns two lists, one containing the names of deleted files and the other containing the names of failed files.
Here are three test cases to ensure that the function works correctly:
# Test case 1: All files are deleted successfully
deleted_files, failed_files = delete_files_from_s3('file_list.csv')
assert len(deleted_files) == 5
assert len(failed_files) == 0
# Test case 2: Some files cannot be deleted
deleted_files, failed_files = delete_files_from_s3('file_list_with_errors.csv')
assert len(deleted_files) == 3
assert len(failed_files) == 2
# Test case 3: CSV file does not exist
deleted_files, failed_files = delete_files_from_s3('nonexistent_file.csv')
assert len(deleted_files) == 0
assert len(failed_files) == 0
In the first test case, all files are deleted successfully and the function should return a list of 5 deleted files and an empty list of failed files. In the second test case, some files cannot be deleted and the function should return a list of 3 deleted files and a list of 2 failed files. In the third test case, the CSV file does not exist and the function should return empty lists for deleted and failed files.
The second test involved writing a simple Python function to clean up stray files in S3 using a list provided by a CSV file. ChatGPT scored pretty well here. It included the asked-for error handling and API interface, but its tests are not correct. The third test especially would crash when the file was opened, but the script does not account for that.
Once again I didn't run the code, but assuming the use of boto3 is anywhere close to the actual API, it was faster to have ChatGPT write the code than for me to do it.
Test 3: Two-Column Layout in React: ✅
Prompt
write for me a JSX file using React that displays a two column layout with a list of appointments in the left column and the appointment details on the right columns. Use the react-bootstrap library for styling and no other libraries. Assume the list of appointments are passed into the component as props.
Response
Sure, here's an example of a JSX file using React that displays a two-column layout with a list of appointments on the left column and the appointment details on the right column, using the react-bootstrap library for styling:
import React from 'react';
import { Container, Row, Col, ListGroup, Card } from 'react-bootstrap';
function AppointmentList({ appointments }) {
return (
<Container>
<Row>
<Col sm={4}>
<ListGroup>
{appointments.map((appointment) => (
<ListGroup.Item key={appointment.id}>
{appointment.title}
</ListGroup.Item>
))}
</ListGroup>
</Col>
<Col sm={8}>
<Card>
<Card.Body>
<Card.Title>Appointment Details</Card.Title>
<Card.Subtitle className="mb-2 text-muted">Title</Card.Subtitle>
<Card.Text>
Lorem ipsum dolor sit ...
</Card.Text>
<Card.Subtitle className="mb-2 text-muted">Date</Card.Subtitle>
<Card.Text>
January 1, 2023
</Card.Text>
<Card.Subtitle className="mb-2 text-muted">Location</Card.Subtitle>
<Card.Text>
123 Main St, Anytown USA
</Card.Text>
</Card.Body>
</Card>
</Col>
</Row>
</Container>
);
}
export default AppointmentList;
Here, the AppointmentList component takes in a prop called appointments, which is an array of appointment objects. The left column displays the list of appointments using the ListGroup component from react-bootstrap, and the right column displays the appointment details using the Card component. You can customize the appearance of the list and the details as desired by modifying the styling properties of the components.
This test surprised me. I had ChatGPT create a two column layout in React for an appointment management application. Explaining a complex UI in words is difficult without visual aids, so I expected some misunderstandings, but it powered through and did exactly what I asked. It failed to add any navigation to the app nor did it use the data inside of the appointments array, so it's not really usable as a component, but it's certainly a good starting point and one I'd be happy to use as a starting template should I ever need such a thing.
That said, without tooling to make ChatGPT more available during development it would be easier to just write the layout myself.
Test 4: RSS Parsing in Swift: ✅
Prompt
write for me a Swift RSS feed parser that takes in a string of XML data and produces a Post object with a title, description, pubdate, and enclosure fields. Use only the swift standard library
Response
Sure, here's an example Swift RSS feed parser that uses the Swift standard library to parse a string of XML data and produce a Post object with a title, description, pubdate, and enclosure fields:
This last test was by far the most involved and open-ended. I asked ChatGPT for a Swift-based RSS Feed Parser and it certainly gave me something close. It used the correct Foundation APIs and even understood the need to concatenate the element text, but it failed to generate a valid test fixture (or even valid XML) and there's absolutely no error handling to speak of.
That said, it did produce valid XML once I called it out and there's something to be said for such humility. I would certainly use this code as a starting point if I needed to build something like this in the near future.
Should I Hire ChatGPT?
In general I'd say it performed fairly well as a developer, though its ability to imitate bloggers is very lacking. For the fifth test I tried to have it write this post, but the output didn't sound like me at all and it kept trying to sell itself using features it doesn't have. Overall I'd give ChatGPT a tentative recommendation and would probably hire it contingent of course on a 30-day probationary period to see if it can keep its tendency toward exaggeration in check.
It's Not an AI Apocalypse, It's Better
I don't really buy the idea that ChatGPT and its ilk will do much to disrupt our everyday lives in a dramatic way. I do however see both it and it's text-to-image cousins as being more and more useful as tools to automate away so much of the boring or tedious work of being a developer or a person on the internet in general.
Like I said, I already use Midjourney to create images for my D&D campaign and those images have had a significant impact in improving the gaming experience. We were never going to contract an artist for four once-a-week landscapes and so economically speaking the AI has had no external effect. Our D&D games just got marginally better. And that's great!
ChatGPT seems to me like it could be yet another advantage that enterprising developers would use to enhance their own productivity. If something like ChatGPT ever shipped inside of an IDE like Xcode, I could imagine a whole suite of amazing features (automatic complex refactors, automating test writing, and more). GitHub's Copilot does some of this, but it's in its infancy. In general I'd expect to see tools like ChatGPT improve a developer's productivity and let us focus more on the design and nuances of our code rather than on the tedious implementation; and for that I am very excited.