20250807 Weekly Development Meeting

[josecelano]

• Time:

  • 09:30 in Canary Islands (WET / UTC+0)
  • 10:30 in Vaduz (CET / UTC+1)

• Location:
  https://meeting.blockfinance-eco.li/nautiluscyberneeringweeklydevmeeting

• Expected Duration: 2 to 4 hours, including breaks

• Confirmed Attendees:

  • Cameron Garnham (@da2ce7)
  • Jose Celano (@josecelano)
  • Constantin Bosse (@cgbosse)
  • Graeme Byrne (@grmbyrn)

---

Agenda

1. Weekly Updates (Each participant will take a turn)

Each team member should come prepared with comments added in advance to this discussion. During their turn, they will:

• Review their notes/comments and provide a summary of:
  • Issues worked on
  • Progress made
  • Other relevant tasks completed
• Share any challenges faced and request assistance if needed
• Highlight any difficulties that may risk delays or affect the final product's quality
• Outline their planned tasks for the upcoming week
• Mention any new technical topics they've noted for potential future discussion (to be added as comments in this thread)

🔁 This format ensures everyone follows a structured sequence during the meeting.

2. Technical Discussion Planning

After all updates:

• Any proposed technical topics will be reviewed
• A decision will be made on whether to:
  • Schedule a follow-up technical meeting, or
  • Continue with the discussion immediately, time permitting
• The attendees for the follow-up meeting will be determined, allowing others to resume their work as needed

[josecelano]

Torrust Tracker

New issues:

• Return random peers in announce requests instead of the first 74 peer torrust/torrust-tracker#1604

Torrust Tracker Demo

Issues:

• Phase 4: Hetzner Infrastructure Implementation torrust/torrust-tracker-demo#28

I've been working on implementing the provider Hetzner. It's almost finished. I have deployed the tracker to a new "staging" environment.

TRACKER_DOMAIN: http://tracker.torrust-demo.dev
GRAFANA_DOMAIN: http://grafana.torrust-demo.dev

There is a draft PR: torrust/torrust-tracker-demo#29

There are a couple of TODOs:

• I was using self-signed certificates by default, but I'm going to use them only for development and testing environments.
• I still have to generate Let's Encrypt Certificates (this might require more helper scripts, although I can also leave it to do it manually).

As you can see in the PR, I've been struggling to define a good architecture to handle environments. We have many concepts that I've been introducing progressively, and the refactors have been hard (a lot of debugging after the changes). I'm not happy with the current code becuase:

• We use bash.
• We don't have unit tests.
• The code does not reflect all the concepts well.
• Documentation might be contradictory in some points.

We have some complexity like:

• Environment types: development, testing, e2e, staging and production. They reflect the intention of the environment. What is the environment used for?
• Enviroenment: it's a deployed tracker in a concfrete provisioned infrastructure
• Provider type: a cloud hosting provider (compatible with cloud-init). It requieres custom env vars. WE have temapltes with the list of varaibles a provider needs.
• Provider context/environment: concrete variables that are required to provision the insfrastrcuture (create the VM) for a given environment.

Some examples:

• We can deploy for "development", locally using the "libvirt" provider.
• We can deploy for "staging", remotelly (remote VM) using the "hetzner" provider in a staging Hetznet account.
• We can deploy for "production", remotely (remote VM) using the "hetzner" provider in a production Hetzner account. IT's a different tenant from staging (isolation is done with different account for now).

Regarding the process:

1. Setup dev tools
2. Generate infra config
3. Validate infra config
4. Provision infrastructure (create VM and prepare for the app with cloud-init)
5. Generate app config (compose nginx, prometheous, grafana, ...)
6. Validate app config
7. Deploy app (copy all the things into the VM and run it. In this step we also generate SSL certs when needed)

One concrete aspect that have not been solved correctly is the source of true for env vars for a given environemnt. We have two env vars files:

• One for the "provider context?" (create the VM)
• One for the "app context?" (deploy the app). It contains varaibles to setup de app, but not only

Those two files represent one environment.

On the other hand, we have two ways to handle environments:

1. We regenerate config files from templates on each command execution (terrafom)
2. We generate config files from temapltes once, when the user runt the command and we store them in separated folders (app config files). This allow us to track, debug and backup, locally the generated artifacts.

Pros and cons: the second option requires handling conflicts (what to do when the file is already there: keep it, delete it, merge. For now, I'm just keeping it, you have to delete it, to use a new one).

AI Development Notes

This week have been horrible. I think the project has reached a size where my current workflow does not work anymore. I desperately need to take control of the code and write unit tests. I have a lot of problems with the agent:

• It adds a lot of things I did not aks. FOr example, extra env vars when I asked for another thing, or extra validation in the wrong place, etc.
• It's summarizing the conversation very often. I guess the inital propmpt is too big and we reach the context limit very quickly. I need to reset the conversation every 15 or 20 minutes otherwise it summarizes after each reply.
• I have to repeat the same many times. I was adding isntrucctions in the "copilot-instructions" file to avoid that, but I cannot do that for everything otherwise everything would be inside that file.
• When it does a new things, many other things are broken. That was not a problems at the beginning of the project but now is overkilling. I spend a lot of time debugging.
• I waste a lot of time waiting for the agent.
• I have lost focus working becuase of the waiting time. It's not that much to switch context to another tasks but enough to loose focus.
• I have lost the control of the code, I donot know some parts and I'm afraid is going to make a disaster in hidden parts.
• Sometimes it ignores rules becuase it's hard to give the rigth context. That would take me a lot of time if I have to careffuly write prompt with all the considerations. I was trying to "tune" auto rules to avoid that but it does not work. I would like the agent to hava "memory" and be able to load the rigth context. For example, if there is a rule that we have split infra config and app config, they it should follow that rule always. I can put that in the "copilot instrucctions" but the file would be very big if I put everything there. I ahve to find out other ways to automatically add context depending on the prompt.

On the other hand, I have to say that:

• I have changed my mind very often.
• Refactor have been big and complex

In summary, I think I should go back to the way I was using LLMs in the tracker:

• For research
• Refactors
• Small changes
• With unit tests
• Controlling and reviewing everything generated by the agents (that means smaller tasks)

I will do that with the next big refactor we want to do: migrate from Bash to another language (Perl?).

Hetzner Notes

The API and panels are fine so far, but for floating IPS, you need to execute code on the server to assign an IP to a server. IT's not a big problem since the goal of the repo is to deploy a VM for the tracker that is not going to change dynamically.

NOTE: Total time spent on Torrust ~ 32.5h

[grmbyrn]

Eternal Recall

• Deployed app to Vercel
• Added AI chatbot to answer further questions users might have about a specific coding question. Limit questions to be about programming.
• Added streak calendar so users can create a routine for their learning. They can also see their longest streak.
• Added accomplishments so that users have motivation to continue using the app and reach these milestones.
• Added pagination for languages which have more than 10 quizzes.
• Added additional Next and Rust quizzes.

Blog

• Wrote two blog posts on Zustand in Eternal Recall and Zustand for beginners.

Learning

• Continued Rust and Next
• Fullstack path and prompt engineering on Scrimba