
I recently created a demo Alexa skill that allows me to talk to the Claude AI. (The code follows [alexa-gpt](https://github.com/k4l1sh/alexa-gpt) but switching out the OpenAI API call with the Claude API).

It was an interesting experiment and it really revealed to me just how nice it was to talk to something that better understood what I was saying and was able to reply in a more human-like way.

Previously Alexa would reply "Hmm I don't know that one" or "Here's what I found" (coupled with an unhelpful reference to an unrelated website). This frustrated me as a user and resulted in me using the device less. I felt I had to change how I interacted with the device to get it to work. I remember one time I said "Open Spotify" for it to rudely reply that I can open Spotify with the command "Play Spotify"! It knew I what I wanted but I apparently didn't speak the right incantation.

With the test skill using a LLM however the results were much better. Whilst the LLM cannot search the web or look up live data it can answer more nuanced questions. I personally find LLMs useful as a soundboard for ideas and to run through things prior to implementation. For example I may ask what it thought of one architectural design over another for a certain implementation. Weighing up the pros and cons of both. Speaking to it rather than typing also meant that I could chat with it whilst doing other things.

I found this very powerful and I highly suspect assistants to start to use generative AI to provide better responses to questions and to understand the users intents better. It will be interesting to see how Alexa and other tools evolve in this space. I would love to have a more natural conversations with Alexa.

I also envisage that assistants will become more personalised (and potentially more characteristic). With generative AI it's possible to have responses have personality and flair. Assistants could be tailored to the individual to provide a nicer experience. We are already starting to see Meta add personality to its AI chatbots. It's only a matter of time before speech-based assistants see the same evolution.

While there are certainly risks and challenges with more human-like AI assistants, I believe the overall impact will be positive if done thoughtfully. More natural and engaging assistants can help people in many ways and I'm eager to see how developers balance utility and personality as this technology continues maturing. One thing is clear - the era of robotic commands is drawing to a close. The future is a real conversation.

Experimenting with an AI-powered Alexa skill showed the power of natural conversation versus rigid commands, making me excited for assistants to leverage generative AI's nuance and personality to provide more humanized and personalized interactions.

Natural Language Assistants


I was fortunate enough to be able to attend the iJS conference in London this year.
There were some really interesting talks this year and I wanted to share some of the key themes I observed.

## 🚀💻 JavaScript UI Framework Performance: making web clients do less

A key area of the conference was exploring techniques and methods for improving the performance of UIs.
We had some exceptional talks from the creator of SolidJS (Ryan Carniato) and Qwik (Miško Hevery) who spoke about the use of Signals to reduce the amount of JavaScript run on clients.

I was really pleased to see this focus on performance and I see a potential shift in the UI framework ecosystems to focus on improving performance whilst maintaining developer experience.

## 💪💻 Offloading work to clients: making web clients do more

Rather interestingly there were also a few talks that had the opposite sentiment.
These talks explored how work could be offloaded to the browser to reduce server processing costs.

These explored the use of WebAssembly to extend the functionality of tools that can be used in the browser.
By allowing the browser to do things that may have traditionally have been done using a server or proxy developers
can reduce costs. This of course has some impact on clients but the use cases here were focussed on long-lived client applications where the performance impact is not as substantial.

One talk put forward an idea of "Uber for compute" by using idle CPU on company laptops for computation resource (similar concept to [SETI](https://en.wikipedia.org/wiki/Search_for_extraterrestrial_intelligence)).

## 💥🌐 OpenAPI: the end of REST?

A few talks explored the use of APIs. I had a small existential crisis following a talk by Thomas Bayer on the death of Hypermedia.
One thing that really stood out to me was how he described REST being a _religion_. (Amusingly followed by a talk titled "The 10 commandments of REST").

<img
  alt="A screenshot of a StackOverflow question titled What is the difference between POST and PUT in HTTP?"
  width={"100%"}
  src="/images/blog/post-put-so.png"
/>

([Source](https://stackoverflow.com/questions/630453/what-is-the-difference-between-post-and-put-in-http))

The above is a screenshot from a StackOverflow question about when one should use POST or PUT. The speaker showed this and explored how the comments interpreted
the REST spec in different ways to and were undecided between them on what and when to use each verb.

There are issues with REST that make it complex and cumbersome. How do you model `add(1, 2)` for example?

The general sentiment was to explore the OpenAPI spec (which now has dropped REST in documentation) and to use more of an RPC style.

To quote Thomas:

> Use the RPC style and be proud of your API!

## 🐘🤫 The elephant in the room

There were many other interesting but one theme that was notably absent was the impact of LLMs and GPT-3+.

There were subtle mentions of it in talks but I noticed a sentiment from speakers and attendees that fell into 3 categories.

1. Nothing has changed.
2. Things have changed but it's normal now.
3. The real impact has yet to come.

Understandably we can't see into the future but with the impact of LLMs on the software career community it was interesting to hear thoughts, excitement, doubts and general unease from others on this.

All we know is the future is yet to come.


Attending the iJS conference sparked thoughtful rumination on web performance, API design, and the elephant in the room - how AI will shape the future of web development in ways we can't yet grasp.

iJS London 2023 Recap


I was inspired to write this blog post after a evening stroll.

I tend to take a lot of inspiration and philosophy from non-software disciplines such as architecture, civil engineering and other engineering disciplines.

On my evening walk for some reason I acknowledged the streetlights more than I usually would. Many are out and it causes there to be long stretches of darkness on the road. As I walked I observed them more and noticed that they varied so much. Some made of concrete, some out of metal others attached to telegraph poles or trees. Even the lamp itself varied in brightness, colour and bulb type.

These streetlights have been here for many years and the streets themselves have changed over time. The streetlamps being so varied made me reflect on how they are maintained and improved. With them being so varied they must be maintained individually. Replacing only when something needs changing or is broken.

I thought of the engineer who would come out to these streetlights and repair them. Do they see an streetlight that has been running for many years and get an urge to update it? Do they get frustrated about the way things were done when it was first installed? Do they grumble and complain about how things have improved since then?

The same mentality is present in software engineering. Many teams will have some form of "Legacy". I always thought of legacy as a positive word. "This is the legacy I will leave" e.t.c. In the context of software engineering, however, the term 'legacy' is generally seen as negative.

The reason being is that this legacy code is the streetlights when they were first installed. The person who installed them has moved on and technology has moved on too. Over years of neglect and underresourcing the applications becomes a burden to the team. The team now want to get rid of it as fast as they can. Security patches and simple bug fixes are painful because there are no tests, no documentation and no one knows how it works.

What we have to remember is that we are also building this legacy. We may not be around in the same role 5-10 years from now when what we are working on right now is being neglected.

We may like to believe we are using the latest technology and building more maintenable applications but regardless it will still be viewed as legacy one day. Trends change and things move on.

For that reason should we care about the quality of what we build? I would say yes but being mindful. Perfection is an unobtaionable goal. At the end of the day your software won't live forever. How can you build it in a way that is quick and maintainable for the period of time your users will use it.

Just like the streetlights, what choices will you make to make sure the lights stay on before we replace the light completely?

Observing varied old streetlights during an evening walk made me reflect on how we maintain 'legacy' code--though it may one day be outdated, focusing on sustainable quality without seeking perfection ensures the 'lights stay on' until it's time to fully replace.

The streetlights of software engineering


Today I was playing around with some Stable Diffusion (more on that in a future post!) and I realised how impatient I had become to software runs taking time.

Doing Stable Diffusion requires a lot of processing power and when you can't scale this without incurring costs (and it being unnecessary to scale); then you must wait for the process to complete.

Part of the training I was doing took greater than 30 minutes and generating images can take a couple of minutes per run. On the grand scheme of things this is not a long time but where I am used to near instant feedback on computations it made me reflect on my perception on this as a whole.

In addition, recently we have added a video to one of our products. The video takes about 5 seconds to load due to its size. Many of us internally noted this delay because of how much it stood out from the norm. We are so used to videos loading in seconds. Sites loading in milliseconds. We have benchmarks and SEO rankings purely based on page load times. It's so ingrained into our psyche now and it wasn't always this way. When we had dial-up we would have loved 5 second load times. As technology advances and improves we always demand more.

As a software engineer I pride myself in ensuring I write efficient logic. Can I save a few milliseconds here? How can I make it faster to deploy? What can I do to reduce cold start times? I'm always trying to find the possible improvements to optimise for this vector (amongst others).

So naturally when something takes a substantial time it sticks out to me like a sore thumb and my mind starts to think on how to optimise it?

But the thing is. Do I need to? I'm only running the model a handful of times and it's not even that long a duration to wait. Sure if this was a production app, used millions of times a day then it starts to make sense. But if I spend an hour saving 2 minutes on the run time I've actually lost time.

I think I have a temptation to automate and optimise and I am learning to get a balance between action and inaction for these.

Sometimes the best thing to do is wait, take a break and learn to live with the loading bar.


My impatience with computation wait times while playing with Stable Diffusion showed me how spoiled I've become by instant tech--though optimizing isn't always necessary, I'm learning to embrace brief delays and find balance rather than constantly automation.

Living with the loading bar


Here is our dog Crumble

<img
  src="/images/blog/crumble.jpg"
  alt="A picture of a cockapoo smiling at the camera"
  width={"100%"}
  style={{
    maxWidth: "500px",
    display: "block",
    marginLeft: "auto",
    marginRight: "auto",
  }}
/>

I had the idea of making a homage to him in RTGames Minecraft world server.

I am not the best Minecraft builder however so I spent a lot of time thinking of how I would represent him in the voxel game.

My initial thought was to create a 3D model of him. Pass it through a Voxelizer and then build in on the server.

That idea was going to fail though. Taking a 3D model of an active puppy was near impossible and even then the end result wasn't really what I wanted...

<img alt="A construction of a cockapoo dog in Minecraft with strange colours" width={"100%"} src="/images/blog/crumble-model.png" />

As you can see in the above image it is a very big build but the colours are off and it's doesn't capture him.

NOTE: To do this I used [Smoothie-3D](https://www.smoothie-3d.com/site/page_index.php) to turn a still image into a 3D model of him and [Drububu Voxelizer](https://www.drububu.com/miscellaneous/voxelizer/index.html?out=obj) to convert it into Minecraft (and then fixed the colours a bit myself manually with creative mode and World Edit.)

Why was I spending time with this convoluted method when I miss the point completely. I want to have Crumble on the Minecraft server.

So why don't I JUST DO THAT?

So I did, I'm not the best builder but I can try...

And in 2 hours work (including writing this). He is now at the North Pole on RT Game's Minecraft Server :)

<img alt="A construction of a cockapoo dog in Minecraft" width={"100%"} src="/images/blog/crumble-rt-1.png" />
<img alt="A construction of a cockapoo dog in Minecraft in the background with a Christmas tree in the foreground" width={"100%"} src="/images/blog/crumble-rt-2.png" />
<img alt="A close up of the cockapoo dog in Minecraft" width={"100%"} src="/images/blog/crumble-rt-3.png" />


After failed attempts at converting a 3D model of my dog Crumble into Minecraft blocks, I realized I was overcomplicating things--so I stopped striving for perfection and just built a fun likeness of him by hand in a couple hours, imperfections and all!

Crumble in Minecraft


This is my first blog post in my new "creative" website.

Originally my site was a free HTML template that I tweaked to fit my purpose.

But it had no flair!

I was so caught up in trying to make things perfect that I created a boring site and never managed to add anything I want

I always thought things had to be 100% perfect, use the latest web frameworks, be accessible, have CI/CD pipelines etc.

I lost sight at what the web was for...

About how I started my journey in the first place...

So I ripped it all up and started from scratch.

I'm writing the HTML pages directly. I don't even care about styling right now or reducing effort.

All I care about is having a place to express myself creatively using my passion of software development.

This is what I have...

**And it's liberating. :D**


I'm back to the basics just writing HTML and coding for the sheer love of it again--this is true creative freedom!

Blog