Almost everyone in the industry worth their weight is using LLMs now. Top tier models create really solid code nowadays.

This is not my experience. What worries me, is that I see posts like this all across the internet:

• All the good programmers are using LLMs. If you are not using agents for coding, you’re a bad programmer.
• Frontier LLMs are wonderful. You are just using the wrong model.

Anyway, if it works well for you, then I am happy for you. If you feel the need to evangelise, I think it would be more effective if you include some of your personal experience and include what is bad along with what is good.

Here is my personal experience from this Thursday:

• Gemini recommended a Kubernetes service to me (nice choice).
• The Helm config it gave had big problems. Settings were hallucinated and it used a feature that did not exist.
• After a day of doubling down on errors, I read a Github issue that said the Helm chart did not support the feature I needed.
• On Friday, I wrote my own Helm chart for the program from scratch. Thankfully, this is a skill that I have not lost. Its small, simple and I understand it.
• Total score this week: 1 day lost to AI.

I lost enthusiasm and then my interest slowly came back as I wanted to learn things. Just in case you haven’t seen this page, I thought it was really cool when I read it years ago: https://blinry.org/50-things-with-sdr/

Is there a course or a book that you are following or did you just dive in?

Thanks, the banking app works!

Learning Rust is a journey. I actually gave up twice before I learnt it properly. I built a simple interpreter as my first project and I found it challenging.

I think that tutorials, and the support you get, is much better now though. Its also a language well worth learning.

I find daily is better than weekly because I can actually remember what I was doing. However, it is mostly just a few hours each weekend for me a the moment.

I like the look of SailfishOS but there is the Ryanair app and a Banking app that I am sure will not work on it. Sometime in the future, I will probably have two phones, one for difficult apps and one with an OS that respects the user.

I haven’t used Kotlin for years but I did do a $WORK project in it once. I prefer co-routines in Kotlin to using async in Rust (which makes sense because it is a higher level language with a garbage collector). I also like how easy it is to write Domain Specific Languages (DSLs) in Kotlin.

Good luck with the job search. Its hard out there at the moment.

I got interested in constraint programming, and I had NO idea how it worked. It seemed like magic.

I have started on following the slides and code of MiniCP, and have started implementing the first steps in Rust. I find it very challenging but it is a great learning experience. I got such a thrill from solving the N-Queens problem in milliseconds from a program that I had written myself.

I am continuing to develop the implementation for a few hours this weekend. Because writing a constraint system is hard, I am also learning some new parts of Rust that I have not touched before.

That’s a cool docker compose setup and is definitely competitive with a single node k8s deployment I run for hobby projects (k3s). The simplicity of this docker compose setup is an advantage, but it is missing some useful features compared to k8s:

• No Let’s Encrypt support for Nginx using Cert Manager.
• No git ops support, the deployment shell script is manually run.
• No management ui’s like Lens or k9s.
• Will not scale to multiple machines without changing the technology to k8s or Nomad.

That said, I would be happy to run their setup if I hadn’t gone through the pain of learning k8s.

Github page for the library: https://github.com/gmcgoldr/stackerror

If you are using Android and have an interest in RPN calculators, I highly recommend RpnCalc. No ads, no tracking, just a great calculator.

Filling out forms to get CI runners means no serious users will be attracted.

I think this will have opposite effect. Only serious users will be willing to fill out forms and casual users will be put off by the bureaucracy. I agree that it is a downside though. In a perfect world, there would be no forms to fill in.

The problem with CI is that the internet is full of not-nice people who will use free compute to mine crypto. Gitlab had problems with this abuse and requires credit card details.

Its not the solution that you are looking for but Woodpecker runs well on k8s and directly supports Forgejo. I use them together on k8s and I am happy enough not have tried runners.

I do this for sites where I don’t care at all about security. One minor tip, that will protect against automated attacks if the password is cracked, is to add part of the website name into the password (e.g “mystrongp4ss!lemworld”) .

A human could easily crack it, but automated systems that replay the password on different sites would probably not bother to calculate the pattern.

I also use KeepassXC and Synthing together and I am very happy with this combination.

One tip that I have, if you are worried about the security of the database file being shared, is to get 2 Yubikeys and use these, along with a strong passphrase, to protect the database file.

At $work we write closed source Rust but we do not use Kellnr.

Instead we use a mono-repo, using a workspace, that contains most of our applications and libraries.

Our setup is mostly OK but needs some workarounds for problems we have hit:

• Slow cargo clean && cargo build, to speed this up we use sccache.
• Very slow Docker builds. To speed these up we use cargo chef.
• Slow CI/CD. To speed this up we use AWS instances as Github runners that we shutdown, but do not destroy, after use. This allows us to cache build dependencies for faster builds.

I am generally happy with our setup, but I am a fan of mono-repos. If it ever becomes to difficult to keep compiles times reasonable, I think that we would definitely look at Kellnr.

I enjoyed reading the Phoenix Project and learnt a lot from it. It is a classic for very good reasons.

There was another follow up book – The DevOps Handbook that went into more detail about solutions to the problems raised in the Phoenix Project. I got a lot from the DevOps handbook but I found it quite a heavy read.

Years later I found a smaller, but super practical book, that covered much of the same subject matter – Operations Anti-Patterns, Dev Ops Solutions. I recommend this Manning book after the Phoenix Project.

But then I haven’t read the Unicorn Project yet, so that is a book for the list.

The only thing you should keep an eye on is probably the license? But I’m not the right person to discuss about licensing :/

It is normal practice to keep the same copyright notice and add your name to it, e.g for this project I forked in 2021: https://code.alienscience.org/alienscience/dnsclientx/src/branch/master/LICENSE

LOL, yes. Just in case it is of interest:

• ESP32-S3 is the chip, this family usually comes with CPU + Bluetooth + Wifi.
• Reverse TFT, this is a small display put on the other side of the circuit board from the chip.
• w.FL Antenna, this is the connector on the Wifi Antenna.

I like these small boards, they are tiny and I need a magnifying glass for soldering. Its mind blowing how these tiny boards are more powerful than mainframe computers filling a room, and supporting 20 users, used to be.