I recently made a public talk at a local meetup, based on the previous blog post. It was recorded and can be watched below.

I start off by describing ChatGPT as a wheel of fortune where every spin generates a new word based on a probability distribution conditioned on the given prompt.

I then talk about how new technology tends to be used to do the things we already do in the ways we already do them (in terms of Marshall McLuhan). I explain this based on the notion of bounded rationality.

I then show how people have been trying to use ChatGPT as an alternative to existing technology, and how it often fails as an existing technology.

I finish by showing how we tend to anthropomorphise ChatGPT because the interface is chat, and that it again is a bad idea to treat it as something with human traits.

To conclude I explain that the way we try and use it is normal, and that it will take some time before this technology find its own use. And when it does, it will be become incredibly powerful. We should therefore start using it now and experiment and explore what this is, and how it may enable us to do new things, in new ways.

Watch the video on youtube here: https://www.youtube.com/watch?v=lOfsDaZsh1o

From the rise in popularity of ChatGPT and language models in general, I see two camps. Those who try and use ChatGPT as Google and find it gives bad results and thus think it's useless. And those who start using it in new ways to do things they didn't have technology for before and finds that it is super useful.

When new technology emerges, people have a tendency to try and use it for things we already do. The first TV programs were theatre plays. Marshall McLuhan talked about how it takes time before new technologies gets used for what the new technology affords, rather than just being used to do what we already can do. Mobile phones are not the same thing as the stationary phones in a household. Household phones did not allow for micro coordination, but required times and places to be agreed upon ahead of time.

ChatGPT and language models in general can do things we previously were not able to do. So we have a tendency to try and use it for what we already do. But what is interesting is not how well it can do things we already have good technology for. What is interesting is what new things it can do.

Previous tech could not generate a script for a book. LM can. They could not be used to write unit tests for already written code, or solve programming tasks. LM can. Current tech could not generate plausible text on a topic. LM can.

To evaluate the usefulness of new tech, it is not very relevant to ask how well it can do things we already can do, but to what new things it may allow us to do. And if this new thing is useful, then surely the tech is.

How bad it is at other things, become rather uninteresting. Don't use it for that.

In closing, here is what ChatGPT thinks Marshall McLucan would say about this new technology:

One aspect of large language models that might have interested McLuhan is their ability to process and generate human-like language, which he would likely see as an example of how media and communication technologies extend and amplify human capabilities. McLuhan believed that media and communication technologies have the power to transform society and culture by changing the way people think, communicate, and interact with the world around them.

It's possible that McLuhan might view large language models as a significant advancement in the development of artificial intelligence and as a tool that has the potential to transform how people communicate and interact with each other and with machines. He might also have seen the emergence of large language models as an example of how media and communication technologies are constantly evolving and shaping the way we understand and engage with the world.

Once a year I'm teaching a course called Design & AI. During this time I get to play around a little bit more with machine learning. As this technology is becoming increasingly available to people, I find it important for people to understand what's going on inside them. Much of it seems complicated when presented in abstract terms, but when looking at it in practical terms through using modern tools it is not as complicated as one may think.

After being asked by colleagues what is involved in implementing and training neural networks, I gave a seminar on the topic this week called Doing Neural Networks. I forgot to record the actual seminar but made a video with the same content afterwards as people asked for it. So, feel free to watch the video below where I explain what neural networks are through code.

(Some posts I make for my future self. This is one of those.)

TL;DR: To host a nextjs on S3 through a custom domain do the following

• Register domain on Route 53
• Request certificate through ACM
• Create S3 bucket
• Enable trailingSlash in nextjs in next.config.js
• Export nextjs app as static (next build && next export)
• Upload static content to bucket
• Enable static website on bucket and set Index Document to index.html
• Configure distribution on Cloudfront to distribute the S3 static website domain (not the S3 bucket ARN)
• Use the domain name registered through Route 53 and choose the certificate from ACM
• (If the certificate dropdown is empty or do not list the certificate for your domain, it is not available yet and you have to wait up to 24h)
• ...
• Profit

I often make prototype web sites or web apps to try out an idea. My weapon of choice these days is nextjs, which is a a quick way of getting started on building a web site in react. nextjs sets everything up to enable server side rendering and routing. Routing is done through files, so that a file in /pages/about.js is available as /about. It makes development easy.

To move the app from localhost to generally available to allow for feedback, I like the simplicity of hosting it on Amazon S3. To host a nextjs app, I therefore export it to static files, using next build && next export. When exporting static from nextjs, it will generate html-files that will be the entry points for the site. By default, a page like /pages/about.js will create the file about.html. Once exported, the page will load about.html, but linking to other pages (e.g. /products) will use react to update the page rather than reloading the web page.

To host the web site, one can simply upload the exported files to an S3 bucket, and use the bucket-domain-url to share the app (by making the files public), or enable S3 static website. The main difference between these two ways of accessing the content of the S3 bucket through a web browser, is how it handles folders. When accessing https://bucket-doman/folder/ it will list the content of the folder (if such access is granted on the bucket). However accessing https://bucket-website-endpoint/folder/ will try and serve the file index.html in the folder. While it is possible to configure an S3 bucket to serve index.html in the root directory, it is not possible to set index.html as the default file of any folder. Only static web site enables that. This will come in handy when enabling a custom domain.

Once the app is made available on an S3 static website as https://my-bucket.s3-website.eu-north-1.amazonaws.com, you might want to use a custom domain name for anything beyond an early prototype. There are two options for this: use another bucket as a domain-bucket and redirect to your website-content-bucket, or use Cloudfront. I will use Cloudfront, and register a domain using Route 53. Using Route 53 for domain names makes things easier, such as getting certificates.

Register the domain using Route 53. Then setup custom domain hosting using Cloudfront, by simply creating a new distribution in the Cloudfront console on AWS. As Origin Domain Name use the S3 bucket static website domain (do *NOT* use the bucket name as suggested by the console). Under Alternate Domain Names type your custom domain as registered through Route 53. Since you do not have a certificate yet probably, click Request or import certificate with ACM (Amazon Certificate Manager). Once you've created the certificate, be prepared to wait 24h before it becomes available in Cloudfront... Didn't say this would be fast. Once the certificate is available in Cloudfront, select the certificate in the drop down list (if there is no dropdown list, there is no certificate available yet). You now all set.

You will now have the nextjs static website hosted on S3 through your custom domain.

Finally, you will notice that if you browse from e.g. index.html using a link in your app to e.g. /about, and try to reload the page, you will get a 404. This is because the url is /about, but there is no S3 object with this name. Instead there is a file called about.html. So how do we fix this? The most trivial way is to make sure nextjs exports about as a folder with an index.html file in it. You can that by adding a next.config.js file where you set trailingSlash: true. Now all of a sudden everything will work as expected on your new custom domain.

If you accidentally do not choose to distribute the static website domain through Cloudfront, but instead pick the S3 bucket (an honest mistake), you can no longer host /about/index.html through the url /about/. This, it won't work. The fix is to enable static website on the S3 bucket, and to distribute the static website domain rather than the bucket through the bucket ARN in Cloudfront.

Last semester I gave a course on mobile app development using Flutter. The course was based around a series of video lectures, exercises, and supervision. Since the videos are recorded and there is not that much material on Flutter in Swedish, I decided to upload them to YouTube.

They are available here

The series of videos goes from introduction to Flutter, introduction to Dart programming, basic UI layouts, more advanced layouts, state management using StatefulWidget and Provider, and finally network communication.

Essentially it covers the basics of all aspects needed to build simple mobile applications.