Fulfilling the Software Engineer requirement of having a blog.https://billson.me/en-au© 2026 Alex BillsonSun, 17 May 2026 11:17:27 GMTAstro vAstro v6.3.3https://billson.me/ramblings/2026-05-17_some-thoughts-on-hermes/https://billson.me/ramblings/2026-05-17_some-thoughts-on-hermes/The adventures of PeonSun, 17 May 2026 00:00:00 GMTI tried [Hermes](https://hermes-agent.nousresearch.com/) over the weekend and actually had a good time with it. I'm typically not someone who uses AI in my personal life, so when OpenClaw was doing rounds earlier this year it didn't appeal to me much. I've only been vindicated for making the effort to avoid that mess. Peter Steinberger is a talented dude, but just says some shit which makes it very hard for me to like him. Loves to chat about how he doesn't read the code he writes and subsequently [has a project with literally hundreds of CVEs.](https://days-since-openclaw-cve.com/) All this tangent to say, I can acknowledge OpenClaw has made big moves in helping us figure out what to do with these big capital expenditure guzzlers, but it would've been even cooler if it was written with just a little bit more care. Hermes is one of the many alternatives that tries to do this. [Nous Research](https://nousresearch.com/releases) make some very cool stuff, and whilst they've struck gold with Hermes, I really am pulled to their drive to improve open models out of the US. There seems to be better security involved in its design; even basic curl requests with heavy query string usage often required confirmation from me due to common exploits. My Hermes Agent "Peon" lives on the same laptop which was featured in my [immutable distros](/ramblings/2025-03-14_immutable-distros/) article. Any skills I have with computers are bound entirely to software, as I completely cooked a keyboard replacement that broke the trackpad in the process. Thankfully there's 16 precious gigabytes of RAM in this thing and an i7, so it's good enough to be my home server with the lid perpetually closed. ## The adventures of Peon  Hermes' killer feature is the "self-improving" nature of the software. Every message has the potential to write to one of the many Markdown files that backs the agent's memory. Something as simple as checking the prices of specific Magic Cards on my local game store's website eventually could be asked using shorthand. You almost need to rewire your brain a little bit to think how best to prompt the agent to better persist things. This post, for example, will get posted by Peon as I've cloned billson.me's repo to the host, and editing Markdown files is very trivial. I feel this kind of workflow is a slippery slope into some [pretty unhealthy habits](https://www.linkedin.com/posts/tomdkerwin_apparently-in-silicon-valley-right-now-activity-7439747785790410752-gaWx?utm_source=share&utm_medium=member_android&rcm=ACoAACICMlYBwbktMtf2LRJ62Y9C0vrE9tfRpfY), but on the more optimistic side of things, it's a really neat way to interact with a Linux server. My original goal for setting this all up was to get Affine running as a self-hosted Notion alternative; Peon helped get everything set up in `podman`, even inclusive of troubleshooting Postgres container startup issues. You're rewarded for preferring containerised and rootless software; this is consistent with the direction Fedora seems to be heading with its ["Hummingbird model"](https://fedoramagazine.org/fedora-hummingbird-linux-taking-the-hummingbird-model-to-the-full-os/). With regards to model choice, I've been loving Opencode Zen/Go as a model provider for open weight options, and Hermes supports it out of the box. I'm a big fan of Kimi K2.5 as a model that's smart enough to be useful without spending a painful amount of time thinking (looking at you, K2.6). All up, my usage for Peon sits at $1.75 USD, which I do feel, for all fun and games, has been incredibly good value. So overall I'm happy with the time I've spent using Hermes. Not sure if the honeymoon period will wear off, but it is cool to see how this ecosystem is developing and how open weight models really lower the barrier to entry.https://billson.me/ramblings/2026-05-16_oh-no-he-made-a-blog/https://billson.me/ramblings/2026-05-16_oh-no-he-made-a-blog/I'm sorrySat, 16 May 2026 00:00:00 GMTConsider this a launch of my ramblings! Whilst I've historically written on Substack, I've always struggled to maintain consistent momentum on [Keeping the Lights On.](https://billson.substack.com/) I do like writing, and hopefully long term I can continue to keep bigger articles for Substack. I just find that I enjoy writing more when I keep it casual and with this recent redesign of billson.me I now have a decent enough platform. As part of this launch I've added a few older posts I feel suit the vibe here. Have been loving [FeedFlow](https://www.feedflow.dev/) and the simplicity of RSS too so to contribute back to the personal web content mines you can subscribe to ramblings via RSS. All super exciting changes, there is something so much more fulfilling about setting something up like this.https://billson.me/ramblings/2025-09-17_linux-migration-guide/https://billson.me/ramblings/2025-09-17_linux-migration-guide/A grass toucher's guide to dropping Windows and actually enjoying your computerWed, 17 Sep 2025 00:00:00 GMT## Preface I've spent a bit of time using Linux as someone who considers themselves a regular grass toucher so use this as a guide to actually enjoying your computer again and dropping Windows. ## What actually is Linux? Something that is both a blessing and a curse with Linux is the nature of how it is developed is that the fact you're using Linux is generally quite abstracted away from what you day to day. Linux is a base (technically the _kernel_) of all these varieties (formally known as Distributions or Distros) of operating systems. Often times you probably don't even know what version of the kernel you are running, that's fine, you probably don't know what specific version of Windows you're running either. When someone _"moves to Linux"_ they're moving to a Linux distribution - each distribution has a few layers before you get to the thing you're actually using. For example, when you are using Ubuntu (a popular but kinda shithouse distro) you are using _a desktop environment based on GNOME_ which sits on top of _utilities and programs which are bundled in with Ubuntu_ which is heavily based on _the Debian distro_ which is based on _the Linux kernel_. Once again, you don't need to really care about this BUT all of this is to say a lot of the time with Linux you're really just picking: 1. A desktop environment 2. An operating system which is OR is based off a prominent distribution of Linux ## What changes when moving on from Windows? Your desktop being a separate component from your core operating system is not where the differences end. In defence of these changes; they're not too hard to get used to for casual use and are a net positive once you're willing to embrace them. ### Installing Applications Whilst Windows _does_ have an [app store](https://au.pcmag.com/migrated-15175-windows-10/113112/microsofts-app-store-has-been-broken-since-windows-8-can-it-finally-be-fixed) and _has_ embraced package managers such as [Winget](https://learn.microsoft.com/en-us/windows/package-manager/winget/) for installing software packagers from a central spot - these are still the exception to the standard way people use Windows. The same can be said for macOS; whilst the mac app store is more popular than the Windows equivalent it is unfair to say its the predominant way people install apps. You typically will find an installer online for your applications, which will then include the application along with some form of self-updater for many modern programs. Linux distributions will consistently encourage the usage of _package managers_ for installing software (packages). To a casual user these are essentially app stores; many modern Linux distributions will go out of their way to draw this comparison. My distro of choice provides an app store (Bazaar) which really tries to hammer this home:  The two key types of packages are: 1. Traditional Native Packages - these are core applications and will often require you to install the package as an admin, historically these are installed by the distributions using a command line utility although many modern installations have these installable using the same app stores as the other type of package. Think system utilities, and programs that require a greater level control over your computer. 2. "App" Packages - these are applications that don't actually modify your install, installable without any administration privileges and are typically more aligned with what you like to install on your computer. Think web browsers, music players, office apps, chat apps. "Apps" on Linux are a relatively new thing and have helped with adoption massively - the most predominant of these app technologies being "Flatpak". Using a website like [Flathub](https://flathub.org/en) to see what apps are available on Linux is a great way to confirm if you're ready to make the switch - you'll find popular apps like [Steam](https://flathub.org/en/apps/com.valvesoftware.Steam), [Spotify](https://flathub.org/en/apps/com.spotify.Client), and [Discord](https://flathub.org/en/apps/com.discordapp.Discord). A nicety of all of this tech - it is incredibly easy to update packages on Linux no matter the type and _you_ are in control of when this happens. Your operating system is just a collection of packages, when you want to update your OS you can using the same methods as updating your browser. All of this to say - yes installing apps on Linux is different but once you get over the difference it is a lot simpler. ### The Command Line Scary stuff I know, but _yes_ there is a higher need to use the command line on Linux **but** I don't think it is a _requirement_. As more and more distributions are created and existing distributions receive tooling to assist with usage, more user interfaces are being added to abstract away the command line. It's hard for me to comment on this objectively as I am a ~loser~ developer who like many developers LOVES this shit.  If I had to think of scenarios where the terminal is **absolutely** needed; 1. Troubleshooting very specific issues with software or hardware 2. Configuring anything you'd not care about if you were scared about using the terminal In many cases scenario 1 will be a process of taking a command from the internet, pasting it into the terminal, and clicking enter. With modern hardware however its very hard to find instances where this would be typically needed and as we'll talk about in the distro breakdown - many modern distros will handle this all for you. My final stance on all of this is you should consider learning the basics of the Linux shell but more because it is a nice to have as a user of a computer. Linux and macOS are both based off Unix at its core which means that the way you use the terminal is applicable to both. ### Compatibility with Windows This is the elephant in the room when trying out Linux and I had to pick if Windows productivity software or Windows games worked better on Linux - the answer is surprisingly the latter. Gaming on Linux continually gets better - unless a game is using kernel-level anti-cheat (something that Linux as an operating system will never support) the reality is thanks to Valve's Proton compatability software many new releases will work fine and in many cases old release will run better on Linux with less headaches compared to modern Windows. The same software that makes the Steam Deck a viable gaming platform make all Linux distributions viable for gaming. The rule of thumb is that if a game is Steam Deck Compatible it will run on your installation of Linux - as of this year there is even [a filter for general Linux support to reduce confusion](https://store.steampowered.com/linux). There is also [ProtonDB](https://www.protondb.com/) which has troubleshooting steps in the event a certain game doesn't work perfect out of the box. With regards to regular Windows software, Wine has been the standard compatibility tool to use (Proton is based on Wine) however I have to shoutout [Bottles](https://usebottles.com/). Its simple and comes with a lot pre-configured to make this seamless. The reality unfortunately for productivity software there is an incentive for companies to not support Linux and drive users to Windows. If you can't make things work nicely in Linux for required Windows software dual-booting might need to be the way but I've found these methods are more than enough. ## What should deter you from using Linux? The reality is there are things that stop you from using Linux, these are: 1. You play games with anti-cheat (popular multiplayer games) 2. You play games on a platform besides Steam (this is getting better but Game Pass for example) 3. You use Adobe products 4. You can't bring yourself to use Microsoft Office in the browser or an alternative to Microsoft Office like [LibreOffice](https://www.libreoffice.org/) If none of these deter you, you're sorted and can give it a crack. ## What do you recommend for Distros? This is the tough part as there's no one specific version of Linux but I've used a few and I can give some recommendations. ### Ubuntu  Ubuntu is _fine_, it is easily the most popular distro **but** it is incredibly boring and is becoming more and more like Windows. I would avoid it purely as it just a bit lame and it does take the fun out of things a bit but if you just want something you know will work this is one of the distros that falls into that category. ### Linux Mint  [Linux Mint](https://www.linuxmint.com/) was the first one I picked, it is really good! I would pick this over Ubuntu for an _"it just works"_ distro as they genuinely are doing some amazing stuff for making Linux user friendly. The only reason I moved on from Linux Mint is it is a generalist distro - I'm decent with computers so I actually just wanted something a tiny bit rougher around the edges. Generally with distros like Linux Mint they forego tuning the performance perfectly and using the latest and greatest to just make something stable. You might have a few less frames over another distro with Mint but it does just work. Another reason I moved on from Linux Mint is the desktop is just _fine_, like its boring but we like boring. It's entirely dependent on what you care about, people always talk about how they chuck Linux Mint on their Nanna's computer so take that as a good example of the crowd it caters to. ### Nobara  [Nobara](https://nobaraproject.org/) is what I currently use on my desktop. Nobara is based off the Fedora Desktop OS but it does some fun stuff to make it more interesting and better for Gaming. For starters it uses the KDE Desktop environment, KDE is the nicest looking desktop on Linux and honestly I can't see myself using anything else. It's just modern Windows 7, it just works, it has a tonne of great features, looks amazing on a 4K monitor, you can customise it so much or just leave it. 10/10, no notes. Nobara is a gaming oriented distro so apps like Steam comes out of the box, it also has many variants where for example you can have it boot into Steam Big Picture. I do like Nobara HOWEVER I have some minor complaints which aren't crazy bad but I've gotta be transparent that it does do things that would annoy me as a regular user. Linux updates are pretty much always optional so this criticism can be dismissed with "just don't update it" but Nobara gets so many updates at times it can be annoying. On a near weekly basis there'll be updates for like 50 packages, these often don't require restarts unlike Windows because every Linux distro has actually figured out software updates. Nobara also has a really small team around it and I would push it more as enthusiast distro for that reason as some processes can be very DIY - I like the terminal and even though Nobara does have a UI for everything it does lean in to using the terminal for certain configs. It's probably my Number 2 pick. ### Bazzite / Aurora [Bazzite](https://bazzite.gg/) has had a huge year - I would say it is the best plug-and-play Linux distro for gaming. Without getting into specifics, what makes Bazzite different to all the other distros mentioned is that it is an "Immutable Distro". Immutable distros are slightly different to regular distros as they essentially at anytime will nuke your install **and this is a feature**. Jokes aside when you update an immutable distro it will replace the entirety of your operating system with a fresh copy _excluding_ your home directory. I'm not going to go into specifics but for Bazzite this means that the only things that you keep between updates are: 1. Your files 2. Your installed apps and files for those installed apps You're probably wondering _"what else would I want to keep?"_ - great question, for many people this is actually all you need. If you are not making changes to the native packages and system level configurations of your device, immutable distros are great. If you are an entry level user who is scared of the terminal these distributions actually reward you for that mentality. Why does Bazzite work like this? The benefits of this approach are: 1. Your computer will automatically update as part of it turning on, new updates are downloaded in the background, if something breaks you can rollback to the last version exactly as it was 2. It's very unlikely things will break because your OS is essentially frozen to a specific version 3. If you do manage to break something the computer will fix itself as part of this update method Bazzite has usen this "image based" approach to also make variants of the OS that support specific devices, using Bazzite can allow you to create a homemade Steam Deck like I did with a Legion Go:  Bazzite can be configured to create a living room gaming rig, a gaming oriented desktop, a gaming laptop that works as well as a Steam Deck - all without any considerable tinkering. I mention both Bazzite and [Aurora](https://getaurora.dev/en) as Aurora is from the same company as Bazzite and has many of the same features **but** is oriented more to a non-gaming user. Personally I have Aurora installed on my laptop and Bazzite on Legion Go, many of the same features across both. This is my personal pick for anyone getting into Linux, it's dead simple and I've never had an issue with these distributions.https://billson.me/ramblings/2025-03-16_web-developer-roadmap/https://billson.me/ramblings/2025-03-16_web-developer-roadmap/Some advice on making sense of this messSun, 16 Mar 2025 00:00:00 GMT_(I probably need to give this a bit of a refresh for the big '26 but most of this still applies in my view. No matter what's going on with AI, fundamentals are good. Learning things is fun. Don't delegate all your thinking to a data-centre.)_ ## Preface Web Development is in a weird spot. I don't think there's been a better time to build websites and interactive web applications _however_ it's incredibly challenging to provide guidance for people trying to get a start in web development and don't necessarily have a background in computer science. The best way I can describe it is that the pieces are all there but it's quite difficult to organise them in a way them in a progressive manner. This for me will be a living document that hopefully people wanting to get into web development can get some use from - the purpose is to guide someone in what's needed to build a dynamic web application. ## Part 0. What's the end goal? The end goal for anyone learning web development is to build a web application that serves pages with potentially dynamic content. I've intentionally avoided talking about the following technologies in that sentence: 1. HTML 2. CSS 3. JavaScript 4. SQL 5. PHP 6. ASP.NET 7. Go 8. Python (The list can go on). The key takeaway for anyone starting out is the less you care about the code and more about the end product the more you'll enjoy web (and software) development in general. As an developer/engineer/hacker/tinkerer/beginner you _should_ care about the technology you use in the same way someone picking up a trade cares what kind of tools they use. Having a preference for a Milwaukee over DeWalt is a very similar conversation to preferring C# over Java - the final product does not change however. This roadmap will aim to balance the theory of software engineering with the reality that writing web apps is a process of stringing together various forms of markup and logic via scripting/backend servers. ## Part 1. Learn the Markup There's no way around it - you should learn the fundamentals of HTML and CSS before really getting into JS. You've probably heard of JavaScript frameworks such as React, Vue, Svelte etc... They are great in different ways and will provide you a common way to write _reactive_ web applications. Emphasis on _reactive_ though, reactivity in your web applications is actually on the tail end of your web development goals and you might find it overwhelming to build counter applications and TODO lists before you learn how to work with the fundamentals. ### Learning Goals Before you move on from working with fundamental HTML and CSS, you should consider trying the following: * Setup a local development environment and host a local HTML server * My recommendation is [VS Code + the Live Server extension](https://marketplace.visualstudio.com/items?itemName=ritwickdey.LiveServer), generally I would avoid just double clicking the HTML files on your computer and opt to instead use basic servers like Live Server to emulate what happens in the real world. * If you'd like something more approachable [CodeSandbox](https://codesandbox.io/) or a personal favourite of mine [Glitch](https://glitch.com) are both fantastic web based development environments. Glitch even provides a free hosting model * Use a CSS Library or Framework * Some personal recommendations from me are: [Chota](https://github.com/jenil/chota), [Bootstrap](https://getbootstrap.com) and [Bulma](https://bulma.io/documentation/start/overview/) * Libraries such as Tailwind and Material UI actually require a bit more of an understanding of JavaScript so I'd recommend avoiding for now * Build a personal portfolio/blog * This should include multiple HTML pages, CSS that is applied across all pages, common elements like a header * If you're wondering why you have to copy and paste so much code, don't worry those abstractions come later * [Glitch actually provides a fully functioning template for a personal blog](https://glitch.com/edit/#!/different-wiry-crime?path=README.md%3A1%3A0) * Feel comfortable with your tools and technology * Before reaching for more - understand the point of VS Code, the responsibilities of HTML and CSS, how it all comes together * This will make it easier to approach more complicated topics ### Good Resources * https://learn.microsoft.com/en-us/training/modules/get-started-with-web-development/ * Guided learning from Microsoft * https://developer.mozilla.org/en-US/docs/Learn/HTML * Fantastic starting point - MDN is the best resource for web development documentation in my personal opinion * https://youtu.be/PlxWf493en4 * FreeCodeCamp has excellent intro to HTML videos ## Part 2. Introduce the Dynamic There is a common belief that Modern Web Development _requires_ the usage of a frontend framework such as React, Vue, Svelte or Angular (to name a few). _"Yes and no"_ is my original response to this - whilst you'll find this is the standard experience for many modern web applications the reality is the instant need to reach for a frontend framework every time you have to render some form of dynamic content requires an understanding on how we got to the inception of those frameworks in the first place. With the inception of the internet, HTML documents were delivered from a server to a client (the browser).  The ability to render _"dynamic"_ content was limited by the capability of the technology of the time. Looking at the above diagram - the best chance you had at dynamic content was by replacing the HTML files on the server with modified HTML files. This doesn't scale well and there's very little potential for personalisation - there's no way to provide personalised content, secure certain routes to certain users, render potentially endless lists of results. Whilst I'm not the biggest fan of [PHP](https://www.php.net/) - it was one of the first and _to this day_ most popular means of providing dynamic content to a client. If we had a simple social media app, here's a rough idea of how the call to the server now looks:  Asking Copilot to generate some sample code for how this looks, the resulting PHP would look like: ```php <?php // Assuming you have a database connection established // and user authentication implemented // Get the post ID from the query parameter if (isset($_GET['id'])) { $post_id = $_GET['id']; // Fetch the post from the database (you'll need to adjust the SQL query) $sql = "SELECT * FROM posts WHERE id = ?"; // Change table and column names as needed $stmt = $pdo->prepare($sql); $stmt->execute([$post_id]); $post = $stmt->fetch(PDO::FETCH_ASSOC); if ($post) { $user_id = $post['user_id']; // Get user ID $content = $post['content']; // Get post content $created_at = $post['created_at']; // Get post creation timestamp // You can format the timestamp as needed (e.g., using date() function) $formatted_date = date('F j, Y', strtotime($created_at)); echo "<div class='post'>"; echo "<p>Posted by User #$user_id on $formatted_date:</p>"; echo "<p>$content</p>"; echo "</div>"; } else { echo "<p>Post not found.</p>"; } } else { echo "<p>Invalid request. Please provide a valid post ID.</p>"; } ?> ``` The key takeaway from all of this - the client receives a _rendered HTML template_ which is then rendered in your browser. This is the defining difference between a web SITE and a web APP - the web application can provide a dynamic experience based on various inputs. Another thing to note, PHP is not the only way of doing this. Unlike the browser which historically only supports HTML, CSS and JS there are many backend/API frameworks in a variety of languages. I can confidently say every semi-popular to popular programming language has a backend framework: [Python has Django (as well as many others)](https://www.djangoproject.com/), [Java has Spring Boot](https://spring.io/web-applications), [C#/.NET have ASP.NET](https://dotnet.microsoft.com/en-us/learn/aspnet/what-is-aspnet), [Go has Gin](https://github.com/gin-gonic/gin) and even PHP which by design can create web apps without any framework has [Laravel to provide some helpful abstractions and batteries included functionality](https://laravel.com/), There are some limitations to this _serverside_ approach to web app development: 1. Individual chunks/parts/components of pages can't change without a hard refresh (although there's been efforts to overcome this such as [HTMX](https://htmx.org/), [LiveWire](https://laravel-livewire.com/), [Blazor Server](https://learn.microsoft.com/en-us/aspnet/core/blazor/hosting-models?view=aspnetcore-8.0#blazor-server) to list a few) 2. Transitioning between pages/views in a serverside web app requires a full page change (think the browser loading bar spinning, the whole page refreshing) 3. All processing needs to happen on your server, you end up footing the bill for 100% of the user experience (this is a double edged sword) JavaScript is the means of solving these issues, which is where frontend frameworks come into play:  This same application now returns a payload (usually in JSON form) which the _client browser_ will take and render dynamic UI with. The benefits to this are: 1. The web app can change without explicit reloads of the page - creating a feeling similar to a desktop or mobile app. 2. Components can "lazy load" - parts of the page can be loaded before others allowing for different areas of the page to be prioritised 3. Pages can be gesture driven - swiping elements to achieve actions, drag and drop, dismissing modals and notifications to name a few 4. The client takes on some of the load of your web app - their device is now in charge of rendering the page and your API/Backend is purely for fulfilling requests for data AngularJS 1.0 (one of the first pioneers of client driven web apps) came out in 2010; in just under 15 years we've learnt of some of the drawbacks of the SPA (Single Page App) driven approach: 1. With the introduction of so many dependencies to render these pages - clients end up downloading massive "bundles" JavaScript just to run the page. Whilst caching alleviates this, in serverside app rendering the server is the main place to store dependencies. 2. Decision fatigue - too many frontend frameworks which all try to achieve the same goal but slightly different, for newcomers especially this is a tough learning experience. 3. There is a lot of challenge in writing performant web applications that are heavily driven by JavaScript - it's gotten easier however there are many ways with these frameworks to "shoot yourself in the foot" and bad web applications are often plagued with loading spinners, laggy user experience and on budget/low-end devices some apps may be close to unsuable. 4. It is harder to write applications that are SEO friendly & accessible to those with disabilities as pages are constantly changing and there's often no final "loaded" state in a frontend web app. 5. The architecture of these applications all things considered is generally more complicated with more points of failure - what used to be just a web server that served dynamic HTML is now a Web API that is often a separate service from your UI which provides data to the UI service which is then rendered for the browser. This is not to say frontend web frameworks are bad as right now I'd say there's never been a better time to be a frontend developer. I think it's just worth understanding that for many websites they can overcomplicate a simple design; it's worth understanding the journey of web app architectures and that whilst it's not the _"default"_ anymore server rendered web apps have a tonne of benefits. ### Learning Goals * Build a basic server rendered web app - for example it could be something that takes in a path such as `/hello?name=Alex` and in return _"Hello Alex"_ should be printed on the page. ** [The PHP tutorial could be used as a starting point for this](https://www.php.net/manual/en/tutorial.php) ** You're going to be learning JavaScript anyway so try using the [NodeJS package Hono which has HTML rendering](https://hono.dev/docs/helpers/html) ** As a .NET developer [I can recommend trying Blazor](https://dotnet.microsoft.com/en-us/learn/aspnet/blazor-tutorial/intro) which tries to mix both serverside and clientside into a single framework ### Good Resources * [I built 10 web apps... with 10 different languages](https://youtu.be/FQPlEnKav48) * Great overview of being able to use a variety of frameworks to achieve the same backends * [What it's like to run HTMX in production](https://hamy.xyz/labs/2024-04_htmx-in-production) * Overview of the mysterious middle ground of HTMX * [MVC Explained](https://www.codecademy.com/article/mvc) * Whilst the pattern is not as popular anymore, it's still the bread and butter of web frameworks such as Ruby on Rails and there is merit in understanding why MVC emerged as the most popular way to structure web apps for a very long time. ## Part 3. Sprinkle in the Reactive We've reached the point where acknowledge our JavaScript overlords. [The joke is there's a new JavaScript framework every week](https://youtu.be/cuHDQhDhvPE), there's merit to this but in 2024 the decision making process is getting easier. Looking at the [2023 Stack Overflow Developer Survey](https://survey.stackoverflow.co/2023/#section-most-popular-technologies-web-frameworks-and-technologies) - the top three frameworks that pop up are: 1. React (Next.js I will talk about soon as being part of this) * "The library for web and native user interfaces" - Developed by Meta * Pioneered an approach of developing web applications where HTML is defined within JavaScript files using a markup called HTMX * By far the most popular of the three - to the point that many ideas established in React and JSX itself are shared across other frameworks * Components are written using a function based, composable syntax 2. Angular * Developed by Google, not to be confused with the original Angular.js 1.0 release which differs greatly and was the biggest framework before react * Emphasis on a "batteries included" approach to web development - frameworks like React allow for various approaches to the same problem however Angular is _opinionated_ in its design and will tell you how to do things rather than provide the option. * Components are written as classes rather than functions 3. Vue.js * "The Progressive JavaScript Framework" - developed independently of a big tech corporation with Evan You as the key developer. * Tries to walk the line between being a full framework that an entire website is written and a smaller framework that can be added onto an existing website * Supports both a function based and object based approach to defining components Each of these frameworks are equally as usable for building frontend web applications - their priorities and approach to achieving this is what sets them apart. For this document we'll be focusing on discussing how to get started with React but it should be straight forward to switch in a different framework entirely if you'd prefer. The [React documentation's quick start](https://react.dev/learn) is great for as a starting point, including the tic-tac-toe tutorial. As you work through these tutorials there'll be a tonne words that gets thrown around and it can be confusing, before moving ahead let's rapid fire a few: ### NodeJS The defacto way to run JavaScript outside of the browser; used to run development environments, host servers, build websites. NodeJS and JS are not different, NodeJS is a way to run JavaScript on a server rather than in your browser. Fun fact is NodeJS is actually built on top of Chrome's JavaScript Engine "V8" - this means that when you run Node it's essentially just spinning up a component of Chrome. ### NPM Node Package Manager. Installed with NodeJS and can be used to work with NodeJS projects and install NodeJS dependencies. You'll often see commands such as `npm i some-package` - this adds the package to your NPM project which can then be used in your code. Often times your projects will support `npm run dev` for running a Dev server for your code. ### Build Tool JavaScript is a scripting language, you don't need to "build it" however when you have lots of JavaScript dependencies and technologies you need a build tool to convert source JavaScript into output JavaScript. With React for example, a build tool is almost always required as JSX is not the same as JavaScript and must be converted to vanilla JavaScript via a build tool. Examples of build tools are Vite, Webpack, Parcel, Rollup (there's heaps, you don't need to learn all of them). ### TypeScript JavaScript by default is a "loosely typed" language - this does not mean much when beginning to learn the language but as you work with more complex codebases it will make sense why it's used. I am a big Typescript advocate, [there's fantastic videos explaining why](https://youtu.be/EUlM3wx546o?si=9NLbAxST9ij7GxDm), for now just know that Typescript is something that is very quick to learn when you're more accustomed to writing JavaScript. The key things to keep in mind for React are: 1. React rewards you for writing good JavaScript - all React components are just functions 2. React components are best when they're cohesive and loosely coupled (like all good code) 3. React uses the same attributes as vanilla HTML and JS, `onclick` against a `<button>` in React is very similarly invoked as it would with vanilla JS. 4. React by design is state driven and it's worth understanding this. The UI changes when the state of the UI changes, that's it. Explore the `useState` hook and how it drives "re-renders" of your app On the topic of the various react frameworks, we'll go through the role of "meta-frameworks" such as Next.js and Remix later. My recommendation is follow guides that use build tools such as Vite ([MDN's tutorial seems excellent](https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Client-side_JavaScript_frameworks/React_getting_started)) as this keeps things simple and lets you focus on learning React. ### Learning Goals Completing the mentioned tutorials should be plenty, my other recommendation is to try implementing the same learning goals. For React specifically consider how you'd work with [lists of data](https://react.dev/learn/rendering-lists),the various ["hooks"](https://react.dev/reference/react/hooks) and generally the whole ["Describing the UI" section is insightful.](https://react.dev/learn/describing-the-ui) In Part 4 we'll try to put together data from a server into your frontend UI - for now focus on building Todo lists, forms, navigation bars, dynamic lists etc... ## Part 4. Present your Data The last piece missing in your web development journey is the way we actually persist the data that drives our applications. It was alluded to in Part 2 that often times what differentiates a web site from a web app is the presence of a persistent, dynamic, data store behind the web app. The PHP snippet below is an example of querying a database: ```php $sql = "SELECT * FROM posts WHERE id = ?"; // Change table and column names as needed $stmt = $pdo->prepare($sql); $stmt->execute([$post_id]); $post = $stmt->fetch(PDO::FETCH_ASSOC); ``` In the example above we use SQL (`$sql`) which is then prepared into a statement (`$stmt`) and after being ran with `execute`, the result is assigned to the `$post` variable. There's no absolutes in programming but you're pretty safe to assume that most web applications in their most basic form look like this:  When working with server rendered apps like the provided PHP sample, the UI and API can be considered merged together but generally you'll find most sites these days opt for the frontend (UI) and backend (API) to be separate components. I'll go more into this in Part 5 - but this "stack" is a pretty foolproof to build consistently structured web applications with their still being plenty of choice of what you use for the individual components. Typically, the _database_ component has been an SQL database variant such as [MySQL](https://www.mysql.com), [Microsoft SQL Server](https://www.microsoft.com/en-au/sql-server/sql-server-2022) or [PostgreSQL](https://www.postgresql.org) however there are plenty of alternatives. Like with Web Frameworks - this can lead to a feeling of decision paralysis and it becomes even harder to decide as you begin to look into other paradigms of data access such [NoSQL databases](https://aws.amazon.com/nosql/) and fully managed backends such as [Firebase](https://firebase.google.com). The best approach you can take in my view - learn SQL and the rest will make sense with time. Any of the three mentioned above will fit the bill (I'm currently loving Postgres the most) but by understanding where SQL fits in and how crucial a part it is of your application it will set you up for success as you review other storage options. [The fundamentals can be explained in 100 seconds](https://youtu.be/zsjvFFKOm3c), there are plenty of free tutorials online to go through the setup and once you're comfortable you can explore how applications connect to [SQL using Object Relational Mappers](https://www.youtube.com/watch?v=4QN1BzxF8wM&t=60s&pp=ygUOb3JtcyBleHBsYWluZWQ%3D). Once you understand this, you can then finalise it by returning that data from your API for consumption in your UI. This is lot to process all at once, but my recommnendation is start with SQL. You don't _need_ an API to work with SQL, similar to how you PHP and C# are lanaguages which can build backends, SQL is the language used for querying databases. Downloading a client such as [DBeaver](https://dbeaver.io) or [Azure Data Studio](https://learn.microsoft.com/en-us/azure-data-studio/quickstart-postgres) is a great way to get started writing SQL queries once you've setup an server. To recap all of this with an opinionated example, if I chose C# as the language for my first API and I had to connect it to a database I would: 1. Install Postgres locally (https://www.postgresql.org/download/) 2. Install a tool such as DBeaver, Azure Data Studio or PGAdmin to interact with the database (I'll go with PGAdmin as it's the specific tool for Postgres so less fuss to setup) 3. I'd then spend a good amount time with the database and learn the fundamentals, [Design Database with PostgreSQL](https://www.codecademy.com/learn/paths/design-databases-with-postgresql) seems like a great Codecademy course to learn this information for free. 4. Lastly, I'd learn how to query the database from my C# application. Writing a google query as simple as ["postgres C# tutorial" yieled this fantastic article](https://michaelscodingspot.com/postgres-in-csharp/) which goes over how to write commands against the database by hand using an ORM such as Dapper or how to use Entity Framework to generate schema for the database in code. 5. To expose this via an API in C#, [this tutorial from Microsoft is the last resource I'd review](https://learn.microsoft.com/en-us/aspnet/core/tutorials/min-web-api?view=aspnetcore-8.0&tabs=visual-studio) There's _a lot_ to learn when it comes to connecting all these components together however find comfort in knowing these motions are the same for every language. With the understanding of how to learn this in C#, it becomes much easier if I wanted to switch in a new database or a different language. If I wanted to write the same example above in a language such as Go, really all that needs to change is step 4 (potentially opting for an ORM such as [GORM](https://gorm.io/docs/)) and instead using a framework such as [Gin](https://gin-gonic.com/docs/quickstart/) for the API. ### Learning Goals * Implement the above example; you can choose to use C# or if you'd prefer a challenge try to piece together the same outcome with another language * Understand how to CRUD with SQL - Create, Read, Update and Delete. This is the bread and butter of building any API * You might not even need a server to learn SQL, try [SQLite](https://www.sqlite.org) which is a _file based_ version of SQL that is used heavily in Mobile and Desktop Apps. For smaller apps it is a fantastic replacement for SQL will save you spinning up a dedicated server to learn the basics of the language. [Dbeaver has a driver](https://github.com/dbeaver/dbeaver/wiki/Database-driver-SQLite) for SQLite it is supported by pretty much every programming language. ### Good Resources * [7 Database Paradigms](https://www.youtube.com/watch?v=W2Z7fbCLSTw) ## Part 5. What's next? When you step back and look at this all, there's a lot to web development. The complexity of getting into the industry is what prompted the creation of this document in the first place. My recommendation is to take each one of stages and really get to understand their place in the web development landscape. Find other tutorials and resources, the benefit of such a constantly evolving field is that the resources available to you for learning are also constantly developing. This final section is a rapid fire of concepts and technologies that you'll need to understand as you become a web developer - do not take this as gospel (to be honest that goes for most of this document). Software engineers love having opinions, myself included, and this section is heavily driven by what _I want_ from web development. ### Do I need TypeScript? Probably - it's a hard one because I personally would prefer someone learning how to create web apps avoid using additional layers of abstraction on top of JavaScript. JavaScript is a pretty shity language that you almost should experience in all its shittiness to fully learn it. There's quite a few existing languages that pitch themselves as being a way to avoid writing JS. [Coffeescript](https://coffeescript.org) was one of the first big attempts to make it happen. You also have languages such as [Dart](https://dart.dev/interop/js-interop) and [Gleam](https://gleam.run/news/v0.16-gleam-compiles-to-javascript/) which out of the box aim to compile to machine code but also support JavaScript interoperability. WebAssembly in the browser has allowed for languages such as Rust and C# to compile to your browser as a target. This has allowed frameworks to circumvent JavaScript entirely and is the foundation of frameworks such as [Blazor](https://dotnet.microsoft.com/en-us/learn/aspnet/blazor-tutorial/intro). These are all great pieces of technology (bar CofeeScript) - however I find that avoiding JavaScript in web development provides very diminishing returns. You will end up writing JavaScript if you try to avoid it on the web, it might be for to integrate with a component or to use a shared library for your specific use case but I do think if your intention is to not write JS at all then this falls apart pretty easily. All this is to say - this is why TypeScript is so popular. TypeScript as the name implies is an attempt to add types to JavaScript, a language with no explicit type system. [The explanation for JS developers is a good introduction to the language](https://www.typescriptlang.org/docs/handbook/typescript-in-5-minutes.html), generally the idea with TypeScript is whilst it _can't_ add runtime checks for types out of the box during the development phase you can avoid shooting yourself in the foot as much. You can write as much TypeScript as you feel like writing - the following lines of code are both valid forms of TypeScript. ```ts let name = "Alex"; let nameButTyped: string = "Alex"; ``` The `name` variable will have the type of `string` because it can expect that from the assigned value of "Alex", whilst the bottom variable is asserting it upfront. Play around with it, read the docs, I love TypeScript as someone from a strongly typed language background and believe in larger codebases it comes in clutch. ### Meta-Frameworks? You've probably heard of NextJS, Remix, Nuxt, Sveltekit, SolidStart etc... If not, congratulations you're happier than most web devs. Modern web dev heavily pushes you to use these frameworks as they help get you started with building quality web apps. These are known as _meta-frameworks_, they're frameworks on-top of frameworks and they all have similar goals: 1. Provide logical defaults and conventions for development (directory structure, routing, media resolution, tooling, SEO, hosting etc...) 2. Support different rendering modes for your web applications including generating static sites, pre-rendering frontend code on a server for better performance, hosting websites on cloud specific platforms such as AWS Lambda and CloudFront Edge functions 3. Add "Backend For Frontend" (BFF) capabilities for more complicated websites that need it These add some very much needed opinions to libraries/frameworks such as React (NextJS & Remix), Vue (Nuxt), Svelte (Sveltekit) and Solid (Soldstart) - all of these UI solutions out of the box do not enforce you to write code in a specific way despite there often being a best practice that can be followed. When working in a team, I love these frameworks! However it's good to know that you don't have to use them and often times for smaller apps tools like Vite will suffice a lot of the time. I like NextJS even if newer versions are making some _interesting_ decisions with regards to how you deploy it and changes to their router (see pages router to app router discussions on the internet). I'd also consider Remix as I find the model to be a bit more straightforward. [Astro](https://astro.dev) is also a fantastic framework for building websites that only need _a little_ bit of reactivity. There's lots of them and it's worth trying to pick one up with your next project to cut out some of the tougher parts of settings things up.https://billson.me/ramblings/2025-03-14_immutable-distros/https://billson.me/ramblings/2025-03-14_immutable-distros/My favourite way to use LinuxFri, 14 Mar 2025 00:00:00 GMT## Context I recently purchased a ThinkPad X280 as I've missed having a laptop and would like to avoid spending most of my life strapped to a desk chair as I undertake some work on the side. As an aside - I adore this laptop. The **sub**-1080p 12 inch display is very charming, the 16GB of RAM and i7 inside of it is doing the job and this is especially true as we get to talking about the software this device is running.  I've been using [Nobara](https://nobaraproject.org/) on my desktop, and have loved it since installing it. Nobara is self described as trying to *"offer a better gaming, streaming, and content creation experience out of the box"* - three things that this machine is not trying to do. I actually learnt of my choice [Aurora](https://getaurora.dev/en) as well as the great work done by its maintainers Universal Blue through [Bazzite](https://bazzite.gg/). Bazzite's been doing the rounds recently as the closest thing to Steam OS currently available to install whilst we wait for an official stable release from Valve. Where Bazzite appeals to the sweats - Aurora instead advertises itself as a productivity oriented OS especially catering to developers. Universal Blue as a company have a very captivating vision with their lineup of images - they're all in on Fedora Atomic based images with Bazzite and Aurora being examples of how you can tailor these images to specific use cases. I've been using Aurora on my laptop for around a month now. I could still be in a honeymoon period with this OS but I've had an overwhelmingly positive experience with it. ## The best way to use a computer I'll come out of the gate saying that - I think there is an argument here that this is how personal computing should be. Universal Blue make it very apparent on their home page what they're trying build: *"the reliability of a Chromebook, but with the flexibility and power of a traditional Linux desktop"* (I'm not a Universal Blue sleeper agent by the way, it's refreshing to see a company do something to make something better than the status quo). The best way I've found to describe the user experience considerations of immutable distros is *"everything adjusted outside the home directory is wiped on restart"*. I feel this is the uphill battle that these operating systems have - the concept is scary on paper. Even as I use this laptop it's taken me a while to figure out when this device actually updates, or what I can and can't do. I say this all within the context of myself being a developer - someone who naturally wants to know how this works and enjoys mucking with the inner workings. For the standard end user, the caveats of how immutable distros operate pale in comparison to the main blockers for broader Linux adoption. If I were to install Aurora on my Mum's desktop - I doubt she'd ever be concerned with the fact her system is essentially recreated on boot every time and it certainly would pale in comparison to much bigger blockers to Linux adoption such as *"how do I install Word on this"*. I could imagine if this concept took off in the broader corporate environment it would be a game changer. I'd be happy to relinquish my admin access if my work device came with a copy of Aurora installed - as I'll get into later if the operating system actually caters for a way of working that is so reliant on containerisation over making modifications to the base system you realise how little you actually need super user privileges to your own device. This does not come at a trade off of control - my Aurora installation may not allow me to break it but thanks to deep integration with [Distrobox](https://distrobox.it/) I still am able to fuck up my Linux installation as I'm prone to doing **but** within the safety of a container. Before I landed on using my X280 to remote into my desktop for development purposes, I found the flow of using containers to manage development environments to be very satisfying. The tooling is there, as much as Microsoft's consumer products and services continue to destroy any good faith I had for them you can't argue that the [Dev Containers](https://containers.dev/) spec isn't solid. I was able to have a fully functional .NET Development environment and accompanying Postgres database running off this laptop - all without ever needing super user privileges or installing `dnf` packages. There were times where I felt it was more of a headache than it was worth - I don't think this is an Immutable Distro problem and more a mindset shift that's required with any form of container reliant workload. It might be easier to just drop some web app files onto a server and put it behind a reverse proxy when compared to the process of getting your application containerised and deployed correctly *but* I don't think that's ever been the selling point of this paradigm. The small amount of effort put upfront results in consistent incremental improvements over the alternatives long term, that's why we do it. All this to say that yes - immutable operating systems on paper may sound a little weird but like developers like the team at Universal Blue cook.