Thursday, 29 December, 2022

When I started prototyping Chatterbox for ChatGPT, I decided - as an experiment - to utilize ChatGPT in the process. I know, so meta, right? Here are some of my observations, thoughts and takeaways from that experiment.

Getting Started

I wanted to build the native UI with SwiftUI (+AppKit where necessary) and I knew I’d want to embed the actual ChatGPT website in a WKWebView. I asked ChatGPT how to interact with HTML elements from the surrounding Swift code and learned about the evaluateJavaScript method of the WKWebView class. This allowed me to prototype the app and start experimenting with different ideas and features.

ChatGPT as a Mentor 🧑‍🏫

As I was building the prototype, I continued to ask ChatGPT in order to learn about topics, I have not encountered before (while most of my SwiftUI experience was transferable to macOS, I did learn quite a few new things about AppKit in the process). In a way, ChatGPT played a role in the development of Chatterbox - it helped me learn the skills and techniques I needed to bring the app to life. When it worked, it got me there faster than searching Google and/or Stackoverflow, but I will say that, quite often, it gave results that were either slightly wrong or completely wrong and made up.

The first case is not an issue (IMO) because I only consult it for pointers on “how to get started with something” rather than copying and pasting whole blocks of code verbatim, so fixing minor issues on the fly while implementing a solution is easy enough most of the time. The problematic part is when ChatGPT gives a completely false and made up answer but does it in a way that sounds fully confident and professional. On some occasions it hallucinated completely non-existent APIs (which sounded plausible enough). There’s something particularly disappointing about that experience because I always get my hopes up about this “super convenient magical API that would be a perfect fit for my problem” 🥲

ChatGPT as a Rubber Duck 🐤

Are you familiar with the term “rubber duck debugging”? If not, you should read up on it because it is an absolutely brilliant technique! While developing Chatterbox, sometimes I would ask ChatGPT for help when encountering errors or problems. While the responses where often pretty generic and not too helpful, sometimes the mere act of formulating my question and seeing it reflected in ChatGPT’s response was enough for me to realize what the problem is 💡

Will ChatGPT become my go-to rubber duck debugging companion? No, because:

1. Formulating questions in writing is tedious (I enjoy typing and think I’m pretty fast too, but just “talking to myself” is quicker)
2. Anika the Radar Plushy (one of my dearest “souvenirs” from my time at Apple) would be really sad to be replaced by an AI chatbot. She’s such a loyal coding companion, never complaining and always listening to me blabbering on about all the random issues I encounter during my work ❤️

Summary

Ultimately (like many of you, I’m sure), I have come to the conclusion that ChatGPT is quite impressive and can be very useful, but it is just a tool after all - and a flawed one at that. Used as a research, learning and debugging companion (while reflecting critically about its output) it can speed things up and make you more effective. But it can also be distracting and outright confusing by “teaching you” things that don’t actually exist while sounding absolutely confident, often requiring to “manually double check with Google” after all…

It has certainly earned its place in my toolset (and is always at hand with Chatterbox’s global hot key) and I’m curious to see how it develops and how I and others will continue to find creative uses for it and ways to integrate it into our workflows. Feel free to reach out if you’d like to share any cool use cases for ChatGPT that you discovered for yourself.

Friday, 20 March, 2015

When I started to learn about web development it felt to me as if everyone was suggesting to use a CMS for everything. Back then I have chosen to get started with Drupal after considering also Wordpress, Joomla and a few others and I have to say that it served me well all the time.

Nevertheless I have become tired of the amount of maintenance that a full blown CMS demands.

No matter how well the update mechanism is designed (Drupal’s drush up is super convenient), it is still a somewhat tedious procedure. Things may break. Thus one has to create, maintain and, in the worst case, re-deploy backups.

Another critical aspect is the fact, that security updates often allow for no more than a few hours to pass until vulnerabilities are widely exploited. This may not be a problem for companies capabable of paying staff all around the clock to react quickly in such scenarios, but it surely is a challenge for individuals like me running their own websites.

Keep It Simple

I basically wanted to get rid of two things: The database and all server side code.

Databases Are Cumbersome

Not relying on a database makes various things so much easier. One can quickly migrate to another host by uploading a bunch of files without even bothering to export/import SQL or change database credentials in some configuration file. One of the most outstanding advantages for me is the fact that, without a database, your complete website can be tracked using a version control system.

So Why Do You Want to Get Rid of PHP?

The simple answer is: Because I can. Given the type of content I provide on this website, there simply is no necessity for dynamic, server side code. PHP only imposes superfluous performance and security drawbacks, which I hereby avoid.

The Jekyll Workflow

I personally consider Jekyll’s workflow another major selling point for this system. Other CMSs come with heavy web interfaces for content creation, which often feel sluggish and are anything but a pleasure to interact with. In the worst case you may end up waiting for the post you have been typing for the past 2 hours to be processed just to find that the system decides to give you a timeout instead and discard your data (been there).

Jekyll uses plain text files formatted in Markdown. Therefore you can use your editor of choice to compose your posts. Simply type jekyll serve in the corresponding directory and it processes your files and even hosts a local web server to test your page. Setting up a web development environment has never been so easy.

Conclusion

There are many valid examples for projects that demand CMSs, databases and server side logic. It took me a while to realize that my personal website is not one of them, but now I am very content about the new found simplicity that Jekyll offers.

In the end of the day there is no such thing as the “best CMS”, as it all boils down to the maxim of choosing the right tool for the job.