Once you have a TPU such as a v4-32 deployed in whatever region and zone, I would recommend deploying with the tpu-ubuntu2204-base software version, as it provides the most complete setup for whatever training needs. The next step is to SSH into your machine and check it's still there ;). The process I developed for working with spot instances which might be preempted at any point by the provider starts with a bootstrap run which turns the bare VM into a Ray cluster. This starts with per-heating all the workers in the topology:

gcloud compute tpus tpu-vm ssh v4-32-us-spot \
  --zone ZONE --project PROJECT --worker=all \
  --command='python3 -m pip install --user "jax[tpu]" \
    -f https://storage.googleapis.com/jax-releases/libtpu_releases.html \
    stable-baselines3 gymnasium wandb tensorboard "ray[default]"'

If you want actual isolation, create and activate a venv on each node first. At this point it would be good to run a test to ask each worker to report on its world:

gcloud compute tpus tpu-vm ssh v4-32-us-spot \
  --zone ZONE --project PROJECT --worker=all \
  --command='python3 -c "import jax; jax.distributed.initialize(); print(jax.process_index(), jax.device_count())"'

This will print out a report from each node on its position and chip count.

Creating the Head

Now we have setup ray on all the workers, next we establish the head which we can then connect to with:

gcloud compute tpus tpu-vm ssh v4-32-us-spot \
  --zone ZONE --project PROJECT --worker=0 \
  --command='export PATH=\(HOME/.local/bin:\)PATH && \
    ray start --head --port=6379 --dashboard-host=0.0.0.0 \
    --resources="{\"TPU\":8}" --disable-usage-stats'

The head will let us connect to the cluster and make the deployment of our code much easier (we will later create an SSH tunnel for the head portal). Now we need to configure each of the workers to connect to the head and listen for jobs:

for w in 1 2 3; do
  gcloud compute tpus tpu-vm ssh v4-32-us-spot \
    --zone ZONE --project PROJECT --worker=$w \
    --command='export PATH=\(HOME/.local/bin:\)PATH && \
      ray start --address=INTERNAL_IP:6379 \
      --resources="{\"TPU\":8}" --disable-usage-stats'
done

This should be tailored to your worker count but it will use the internal IP of the main node which you can find on the GCP console or with a quick command. And with that we have aligned all the TPU workers to enable the full parallelization across the entire cluster. Great, but we still have no access from our local machine, to do that we need to create an ssh tunnel for the port 8265 or whichever you want to configure.

gcloud compute tpus tpu-vm ssh v4-32-us-spot \
  --zone ZONE --project PROJECT --worker=0 \
  -- -L 8265:localhost:8265 -L 10001:localhost:10001 -N

Now if you open http://localhost:8265 you will see the dashboard with your ray cluster with all the nodes we configured.

Submitting Jobs

Now we are finally at the fun part: actually sending training to the cluster.

The key idea is to submit jobs from your local machine to the Ray head through the tunnel on localhost:8265. Ray will package your working directory, install dependencies from a runtime env, and execute your entrypoint remotely.

I usually start with a runtime payload so every run is reproducible and self-contained:

{
  "pip": [
    "stable-baselines3>=2.2.0",
    "gymnasium>=0.29.0",
    "wandb",
    "tensorboard",
    "python-dotenv",
    "pandas"
  ],
  "env_vars": {
    "WANDB_PROJECT": "PROJECT",
    "WANDB_ENTITY": "YOUR_ENTITY",
    "WANDB_API_KEY": os.getenv("WANDB_API_KEY", "")
  }
}

With this in place, do a smoke test first:

ray job submit \
  --address http://localhost:8265 \
  --working-dir . \
  --runtime-env-json "$RUNTIME_ENV_JSON" \
  -- \
  python -m engine.train --algo ppo --total-timesteps 5000 --alpha 0.3 --device cpu

If that succeeds, scale to your real training command.

For distributed execution (one trainer per host or per TPU allocation), use your distributed launcher which will make the distribution of parameters or allocation of configuration easier for us to handle:

ray job submit \
  --address http://localhost:8265 \
  --working-dir . \
  --runtime-env-json "$RUNTIME_ENV_JSON" \
  -- \
  python scripts/ray_distributed_train.py \
    --train-args "--algo ppo --total-timesteps 100000 --alpha 0.4 --device cpu" \
    --num-nodes 4 \
    --tpu-per-task 8 \
    --base-seed 42

If you wrapped this in submit_ray_job.sh (which I recommend), the same flow is shorter and harder to mess up:

RAY_MODE=distributed \
NUM_NODES=4 \
TPU_PER_TASK=8 \
TRAIN_ARGS="--algo ppo --total-timesteps 100000 --alpha 0.4 --device cpu" \
bash ./submit_ray_job.sh

Once single runs look healthy, launch sweep agents so Ray fans out trials massively in parallel.

RAY_MODE=sweep \
SWEEP_KIND=ppo_rl_study \
SWEEP_METHOD=random \
SWEEP_RUN_CAP=900 \
NUM_NODES=4 \
AGENTS_PER_NODE=16 \
TPU_PER_TASK=0 \
WANDB_PROJECT=capstone_tpu \
WANDB_ENTITY=YOUR_ENTITY \
bash ./submit_ray_job.sh

A practical note: for SB3-based algorithms, most compute is CPU-side, so high agent parallelism is usually more useful than trying to reserve TPU for each actor. TPU matters most for JAX-heavy paths. The dashboard gives the visual view, but I still use CLI for reliability:

ray status
ray job list
ray job status <submission_id>
ray job logs -f <submission_id>

If something is off, these are the first things I check:

• Are all expected nodes alive in ray status? (Maybe got preempted)

• Are two Ray nodes accidentally on the same TPU host IP?

• Did the job start with the expected env vars (PHANTOM_JAX_PLATFORM, W&B settings)?

• Are metrics arriving in W&B at steady cadence? (Or did the run crash?)

Checkpoints and Artifact Uploads

For spot instances, assume interruption will happen. The minimum reliable setup is:

1. Save final model weights locally at end of training.

2. Upload that final checkpoint to W&B as an artifact.

3. Use deterministic aliases (latest, step-<N>) so resuming logic stays simple.

A minimal upload pattern looks like this:

artifact = wandb.Artifact(name="phantom-ppo-final", type="checkpoint")
artifact.add_file("engine/models/phantom_ppo.zip", name="model.zip")
wandb.log_artifact(artifact, aliases=["latest", f"step-{num_timesteps}"])

I intentionally upload only final weights for sweep runs to avoid artifact noise and storage bloat (you can maybe also use the new HF Buckets). When a spot VM gets reclaimed, the recovery loop is straightforward:

1. Re-run the bootstrap install on all workers. You can put this into a watchdog script that runs either in a foreground shell on your computer or in a docker container.

2. Start Ray head + workers again.

3. Re-open the SSH tunnel to 8265.

4. Re-launch sweep agents with the same SWEEP_ID.

Because sweep state is on W&B, agents can continue pulling remaining runs after cluster recovery. When you are done, stop Ray everywhere so the next startup is clean:

gcloud compute tpus tpu-vm ssh v4-32-us-spot \
  --zone ZONE --project PROJECT --worker=all \
  --command='export PATH=\(HOME/.local/bin:\)PATH && ray stop -f'

That is basically the full lifecycle: bootstrap, form cluster, tunnel, submit, monitor, recover, and tear down. Once this loop is scripted, TPU experimentation becomes much less painful and much more reproducible.

Behavior Modeling Parallelization

![](https://cdn.hashnode.com/uploads/covers/6793605016666de203f20485/62efc20e-428c-48a3-92d1-aa667e0d7484.png align="middle")

One thing that gave me a real throughput jump was moving the behavioral-profile logic into JAX parallel batches instead of evaluating profiles in Python loops. In practice, I keep a profile bank for human and agent transition kernels (and any synthetic contamination profiles) as fixed-shape tensors, then run divergence scoring and robust alpha selection with jax.jit + jax.vmap so each step evaluates all profile candidates in one compiled pass. If you want to scale beyond a single host, the same computation can be sharded across workers with pmap/multi-process JAX, where each process gets a slice of the profile bank and we aggregate worst-case signals at the end; this is especially useful when you are screening many levels at once. The important engineering detail is to keep shapes static (pad trajectories, use masks, avoid Python-side branching) so recompilation does not kill performance, and to pre-place profile tensors on device once to avoid host-to-device transfer overhead on every step. I also strongly recommend deterministic PRNG handling with jax.random.fold_in(process_index, global_step) so profile comparisons remain reproducible across nodes, which makes sweep analysis and equilibrium claims much easier to trust in your results.

Conclusion

At the end of the day, running RL at TPU scale is less about a single launch command and more about building a resilient workflow: bootstrap all workers, form a clean Ray cluster, submit jobs through a reproducible runtime env, and treat spot preemption as a normal event instead of a failure. Once that loop is scripted, the infrastructure gets out of your way and you can focus on the actual science and using JAX-parallel logic to evaluate policies fast and consistently. That is when the cluster stops feeling like ops overhead or MLOps project and starts feeling like a research accelerator.

PS: Let your AI agents help you with configuration and testing of the clusters itself.

How can I see the usage of my TPU chip? Can I run nvtop on a TPU machine?

These were some of the biggest questions I had when I started working with zt for my research. When running code on a TPU based setup, be that inside of Google Colab or via GCP it is helpful to get a better understanding of the current load on the chips you might be using. When you google "nvtop for TPUs" not much comes up apart from some issues on GitHub. Looking through the pull requests of nvtop you might come across the way to re-compile the code with support for TPU chips.

First, what is a TPU? A Tensor Processing Unit is a specialized chip designed by Google to speed up machine learning workloads, especially neural networks and large matrix operations used in training and inference. I was fortunate enough to work with a large allocation of multiple chips from Google and for the ease of future use, setup a small bash gist: here.

This mini-script will install the necessary requirements and fetch the source code of nvtop. Then it will compile it with TPU support enabled. A very simple way to run it is to do the following:

curl -sSL https://gist.githubusercontent.com/velocitatem/53ff537d3c439c3bd63d8a0f1370801b/raw/c348e534f7c24646c52eabce11cad9ee01611fb1/install_nvtop_tpu.sh | bash

What this does is simply fetch the script and run it on your machine (with the expectation of Ubuntu 22.04). This is not limited to running on provisioned virtual machines, but can also be run in the colab terminal:

![](https://cdn.hashnode.com/uploads/covers/6793605016666de203f20485/4697660f-ef58-4fd8-b827-b421b2f34426.png align="middle")

You can then run some Jax powered script to test it out and monitor the load.

With the paper/ directory setup I then created a few entries in my Makefile which helps me orchestrate everything else in my research. I have paper.build and paper.watch as targets which help with the day-to-day writing and the watch target will re-compile and render my paper in zathura which I could not recommend more.

The beauty of my workflow comes in the CI/CD stage. I want my advisor and stakeholders to always see the updated version of my work in the same place, like you can in Overleaf. I do not however want to make anyone clone my repo and self compile my work. That is why I built an on-commit build of my paper which ofcourse creates an artifact on GitHub. This however is still a bit cumbersome. Then I thought, what if I could use object storage like CloudFlare R2 (because setting up AWS S3 is a bit too tedious) to host my work?

![](https://cdn.hashnode.com/uploads/covers/6793605016666de203f20485/a28af780-d708-4220-bca4-c1ecb0a282b1.png align="middle")

Every commit, triggers a build, which triggers a push to the 'paper registry' under a timestamp aswell as -latest.pdf tag. Originally I wanted a persistent undo-tree for all the source files of my thesis, this however proved to not be such a good idea, nor would it make sense since each edit is tracked in a git repository. With this I have a full history of all the states of my work aswell as a unified place for the head of the process with a publicly sharable URL.

Since my work has multiple possible stakeholders each with different things they want to see, I created an automated mirroring pipeline which leverages codex to use per-mirror instructions to create perishable edits to the main work of the body and compiles the adjusted version. This way I can create a less technical or more technical mirror alongside my main fully humanly authored work.

We demonstrate that the current state represents a sub-optimal Nash Equilibrium. The collective acoustic output informationally equivalent to silence, despite the high energetic cost and noise pollution. We look at this from a very naïve perspective just as an observational analysis.

Game Theoretic Analysis

We model the dynamic between motorists as N player non-cooperative game. We specifically look at a sub-game of two drivers M one and two. Each player has two options of actions in a given state, B or Q which stand for beep or quiet. They earn a reward or payoff made of of a positive value (V) of safety with a negative cost of beeping which is almost negligible (C). This minimal cost mirrors what literature tells us to be true: costless signaling leads to informationally inefficient equilibria. Finally we take into account a parameter of degradation which helps us model the number of agents beeping (δ).

If M2 is Quiet, M1 should Beep because V − C > 0. If M2 Beeps, M1 should still Beep, provided that the degraded safety V (1 − δ) − C > 0. Since the cost of beeping C is functionally low (extremely low), the strategy B becomes strictly dominant. The system converges to the Nash Equilibrium (B, B) as defined in standard non-cooperative game theory. However, as N (the number of riders) increases, the total degradation δ approaches 1… The collective payoff becomes:

$$\lim_{N \to \infty} \sum U_i = N \cdot (V(1 - 1) - C) = -N \cdot C$$

This socially creates a local jamming equilibrium where the added benefit of safety is vanishing but the negligible cost still has secondary effects on the environment. Yet, no individual can rationally switch to silence without assuming maximum risk.

Information Theoretic Analysis: Entropy

We make X be the variable representing the presence of a motorcycle and Y be the auditory signal received by the driver. In an ideal system, warnings are rare (P(beep) approx 0.05), meaning the information content of a signal is high. However, in the Rio system, the dominant strategy described above forces the probability of beeping to approach 1 (p → 1). The entropy H(Y) will regress to 0 in this model (more in the paper):

$$H(Y)\approx−(1 \log_2​1)=0 \text{bits}$$

A signal that is always present conveys zero bits of information. The driver learns nothing new about the state of the traffic from hearing a beep, simply because the beep is a constant (in practice this might not however be the dominant case).

We can further view the traffic environment as a communication channel, where the capacity C is limited by the signal to noise Ratio (SNR) according to the Shannon-Hartley theorem:

$$C = B \log_2 \left( 1 + \frac{S}{N_{oise}} \right)$$

The channel effectively becomes saturated. The acoustic energy is high, but the information transmission rate is zero.

The observed model from Rio presents a paradox where deviation from the strategy is not in the interest of a drive but creates a lock-in. Our entropy model also hints that the signal overuse creates a vanishing value.

safe riders and dangerous riders use the same signal with probability 1. Consequently, the signal fails to distinguish types. The "baseline" of beeping becomes informationally identical to a baseline of silence in a prolific use of the dominant strategy.

1. Cover, T. M., & Thomas, J. A. (2006). Elements of Information Theory (2nd ed.). Wiley-Interscience.

2. Crawford, V. P., & Sobel, J. (1982). Strategic information transmission. Econometrica, 50(6), 1431–1451.

3. Fudenberg, D., & Tirole, J. (1991). Game Theory. MIT Press.

4. Hardin, G. (1968). The tragedy of the commons. Science, 162(3859), 1243–1248.

5. Shannon, C. E. (1948). A mathematical theory of communication. The Bell System Technical Journal, 27(3), 379–423.

Often, this initial version is just for show; it looks nice, but nothing functions. Many people, even experienced developers, assume that the starting version doesn't affect what you end up with after 10 adjustment prompts. This is simply how the software is designed to work. You might ask, “build me an Uber for dogs,” and you get a specific page. Then you ask, “make all the buttons blue with a shimmering effect,” and the results can be a bit disappointing. This is especially true in a conversation thread of 500,000 tokens, where some models might experience context anxiety (a fear of soon running out of context and not being able to complete the task).

For any one input of instructions of what to build, there are nearly an infinite variations of how that software might look - this is what puts the vibe into “vibe coding”. Using AI assistance to build software should not be a threat filled argument in a chat window. Many of these coding agent platforms do implement options of rules and setting up guidance but what in my experience works the best, is being very opinionated in choices relating to the technological stack of whatever your dream platform is.

The interaction loop of chatting does not incentivize a lot of precision from the human side, where you might end up with people taking screenshots of code to give it back to the chat window and asking for adjustments or, in general, not writing very high-quality prompts. After all this back and forth, you might end up with a software solution that very often will not be useful to many people because it's hard to deploy or maintain and is very narrow.

This ends up polluting the software space with thousands of random landing pages, half-done web apps with poor security, and overall no production-quality software. With the increasing capability of code-generating models (+ their autonomy) and decreasing cost per token on these models, my hypothesis is the following: Instead of progressively introducing features and adjustments to the model and codebase via a chat interface, we can have a single source of truth, which I call the statement of purpose.

The Place for AI Software Tooling

In a given organization with N individuals, there will be various identifiable bottlenecks that could be resolved with AI-generated software. A person in this group might have a specific problem of data transformation or connectivity between services, which they themselves do not have the technical skills to resolve but can describe well enough for AI to build a solution. The current existence of that solution might be isolated to one of these platforms like Lovable. Three weeks later, a colleague might face a similar issue but with a slight twist; however, they would be unable to reuse any part of the previously generated software and would have to do it from scratch. This isolation in human usage, software interoperability, and LLM context creates a significant slowdown in AI-assisted progress.

My new platform proposes to fix this by capturing the essence of various issues in these SoPs (statements of purpose), which then turn into one-click deployable software. Some of the key features this methodology allows for are:

• Progression of software capability at the speed of innovation: Imagine you vibe code the Uber for dogs, and 2 months later GPT-6 comes out. Half of the features that might not have worked in your previous versions, this new model is now capable of building. This allows your app to ride the wave of any new model advancement.

• The ability for AI-generated software to be interoperable with previously generated solutions. If each employee in a 1000-person company generates 5 Lovable apps, chances are a lot of work is being done in repetition. Peakz allows for software solutions to communicate with each other in established frameworks.

Technical Overview

The control plane centers on a FastAPI orchestration server and a PostgreSQL registry. Statements of Purpose and code references live in the registry. A worker picks up build requests, runs the Building & Deployment pipeline, and records artifacts and metadata. Generated outputs and run results are pushed to MinIO, which also serves as the source of truth for later redeploys.

The runtime plane is container-first. For each request the worker orchestrates isolated containers that mount two layers: a Deployment Layer for serving and a Development Layer for iterative work. Containers boot from a consistent Development Image with defined entrypoints. The image includes OpenAI Codex, a toolchain, and a lightweight devkit on Alpine Linux, enabling predictable startup and stack autodetection.

The access plane exposes running apps through a Next.js proxy that routes to the Deployment Layer. Users interact with the proxied endpoints while the worker manages lifecycle and scaling. Results and logs flow back to MinIO, and the registry database keeps state for SOPs, codebases, deployments, and versions. The separation of planes keeps apps isolated, auditable, and quickly reproducible.

Go ahead and visit abundantsoftware.eu to see more about how things look and feel. This is a platform that was built over 10 hours at this event.

When the lights went out across Spain and Portugal in April 2025, it wasn’t just a power cut. It was a silence.

Elevators jammed mid-floor. Metro tunnels went black. Airports turned into echo chambers of confusion. For 8+ hours, even as power slowly flickered back into buildings, something more vital was still missing:

Information.

Phones had charge, but no signal. Laptops had Wi-Fi toggled on, but nowhere to connect. And in that vacuum, whispers started doing what they always do in a crisis — spreading fast, mutating faster.

No one knew what had happened. No one knew when help was coming.

And that’s exactly the moment a tiny, often-overlooked device can make a world of difference.

What if there was a way to stay informed digitally— together — even offline?

The Wi-Fi Pineapple Nano, a cheap pocket router best known to cybersecurity tinkerers, wasn’t built for disaster relief. But it happens to be perfect for it. With a bit of preparation, this little box becomes an emergency communications node — quietly powerful in the most human way:

When people say “Where can I find water?” serve a map and list of nearby resources — no Internet needed. “I need to let my neighbor know I’m okay.” Host a local chat, instantly accessible to anyone nearby. “Did you hear a hospital was out of X?” Provide a single, verified source of local updates to stop rumors cold. “I have one phone with Internet left…” Share it via the Nano, fairly and securely, across the neighborhood.

The Nano can broadcasts an open Wi-Fi network — something like “EmergencyNet” — and any phone that connects instantly gets a pop-up page. No app. No login. Just local, living information.

This isn’t about tech. It’s about trust.

When disaster strikes, misinformation spreads faster than help.
It’s not malicious — it’s human. In the absence of news, people fill the gap with whatever they can find. An overheard conversation, a

But that’s exactly why a shared, live, low-tech bulletin board can matter more than extra food or candles. It becomes an anchor.

With a static site and a couple of JSON files, your Nano can carry:

• Updates from neighbors — who’s safe, who needs medicine, where traffic is backed up.

• Shared files — like emergency contacts, translated guides, or relief info in multiple languages.

• Voice bulletin streams — with a mic and a radio dongle, the Nano can broadcast looped updates over low-bandwidth audio.

And all of this works from a power bank — no grid, no cell towers, no problem.

It doesn’t take much

A USB power bank is enough to keep the Nano running for up to 16 hours, realistically. Two batteries, swapped morning and evening, can keep a whole street connected through the chaos.

With a second Wi-Fi dongle, it can also act as a gateway — tapping into any working hotspot and safely sharing the connection with everyone nearby. If someone has signal, everyone gets it.

Or set it higher — on a tree, balcony, or roof — and it becomes a range extender, passing messages from block to block. With a few of them daisy-chained together, even a full district can stay looped in.

A few files, a little prep — real resilience

Set up your Nano now, before the next blackout:

• Preload a small HTML portal with chat and bulletin board.

• Point captive portal domains to the Nano’s IP so phones auto-open it.

• Drop in maps, contact lists, APKs, even a copy of the Red Cross first-aid handbook.

• Add a hand written label: “Emergency Wi-Fi — join ‘EmergencyNet’”

That’s it. No database. No server. No DNS. Just one open SSID and a page everyone sees the moment they connect.

Because when everything else fails… clarity still matters

In a blackout, power is the first thing to go.
But certainty — or the lack of it — is what really shapes the days that follow.

A €100 box can’t replace the Internet. But it can help replace uncertainty with intel. It can bring structure to the mess.
And most of all, it can remind us that even when the grid collapses, we don’t have to go dark.

That's why I was excited to discover JUNO, a tool that elegantly solves one of the most persistent challenges in the Jupyter ecosystem: managing virtual environments and packages directly within JupyterLab.

The Virtual Environment Problem

If you've used Jupyter notebooks for any serious data science work, you've likely encountered these frustrating scenarios:

• Installing a package breaks your existing notebooks because of version conflicts

• Sharing notebooks that work perfectly for you but fail for colleagues

• Maintaining multiple projects with different dependencies

• Switching between different Python versions for specific projects

Traditional solutions involve creating separate virtual environments outside of Jupyter, then manually registering kernels—a process that's error-prone and requires command-line gymnastics.

Enter JUNO: Virtual Environments Made Simple

JUNO reimagines how we manage environments in JupyterLab by integrating virtual environment creation and package management directly into the interface.

Key Features

JUNO provides an intuitive UI for:

1. Creating and managing new isolated environments

2. Installing and managing packages with a visual interface

3. Switching between environments seamlessly

4. Sharing environment specifications for reproducibility

Hands-On: Getting Started with JUNO

Let's walk through a typical workflow to see how JUNO simplifies environment management.

Installation

pip install juno-manager

Creating a New Environment

Instead of the traditional approach:

# The old way
python -m venv my_new_env
source my_new_env/bin/activate
pip install ipykernel
python -m ipykernel install --user --name my_new_env
jupyter lab

With JUNO, you simply:

1. Open juno-manager

2. Name your environment and specify which packages to install (you can also do this later)

3. Verify your environment was created and add any other packages directly if you want

Behind the scenes, JUNO handles the virtual environment creation and kernel registration automatically.

Real-World Use Case: Managing ML Project Dependencies

Recently, I was working on a machine learning project that required TensorFlow for one notebook and PyTorch for another. Before JUNO, I would have:

1. Created separate virtual environments with different packages in various directories

2. Registered each as a kernel into my lab

3. Carefully selected the right kernel for each notebook

4. Documented the environment setup for teammates

With JUNO, I created two environments through the UI, installed the required packages with a few clicks, and could switch between them without any hassle.

# In my TensorFlow notebook (using the tensorflow-env kernel)
import tensorflow as tf
model = tf.keras.Sequential([...])

# In my PyTorch notebook (using the pytorch-env kernel)
import torch
model = torch.nn.Sequential(...)

The best part? I could export the environment specifications directly from JUNO, making it trivial for teammates to recreate the exact environment.

Under the Hood

JUNO isn't just a pretty interface—it leverages proven technologies like venv or conda while abstracting away their complexities. The software communicates with a backend service that manages:

• Environment creation and deletion

• Package installation and removal

• Kernel registration with JupyterLab

• Environment activation and deactivation

This architecture ensures that JUNO integrates seamlessly with existing Python packaging tools while providing a superior user experience.

Why This Matters for Data Science Teams

For teams building data products, reproducibility isn't just a nice-to-have—it's essential. JUNO addresses this need by:

• Reducing environment setup time from minutes to seconds

• Eliminating "works on my machine" problems

• Simplifying onboarding for new team members

• Making dependency management accessible to less technical users

The productivity gains are substantial. In my experience, teams using JUNO spend significantly less time debugging environment issues and more time solving actual problems.

Conclusion

Managing virtual environments in JupyterLab has long been a pain point for data scientists and analysts. JUNO transforms this experience by bringing environment management into the JupyterLab interface, making it accessible and intuitive.

Whether you're a solo data scientist juggling multiple projects or part of a team that needs reproducible environments, JUNO offers a compelling solution that streamlines your workflow and eliminates one of the most persistent headaches in the Jupyter ecosystem.

Give it a try on your next project—your future self (and your teammates) will thank you.

Saturday

I started the day community dev-room where I came to see the Build a Great Business on Open Source without Selling Your Soul - this was the second talk of that day as it is paramount to come early to get a seat in the lecture halls. This talk emphasized ways of monetizing successful open-source projects through feature development, enterprise support, consulting, education. All these aspects come together in three different models of structuring business around the OSS.

Another highlight of this day was To Mine Or Not To Mine - Training of (Generative) AI Models under the TDM Exception in EU Copyright Laws, in which the speaker highlights how lacking definition, structuring and comprehension of law-makers in the field of AI contributes to an unhealthy ecosystem where businesses and developers are left with a lot ambiguity and possible legal threat models which affect core functionalities of the business, opening them up for lawsuits. In a talk on Scaling Open-Source Solutions to Achieve the Sustainable Development Goal I had also learned about DGP (Digital Public Good) and its new members: Wikipedia, Open Food Facts and the Tor browser. Some references I took away from the mentions by the UN Members are:

• OSSCoP

• OSS4SDG

• <UNLOCKED/> - I was unable to find this newsletter online.

• UN OpenSource Portal

• Reboot The Earth

A presented list of opportunities associated with OSS in the EU can be found below, taken from this slide-deck.

Sunday

The last day of the conference I started in the Cybersecurity rooms where I was met with an interesting concept of the contrast between anonymity and surveillance. These talks explored various methods of de-centralized communication and proof of ownership which was reliant only on the end-user to verify in order to avoid third-party trust necessity. Trustchain was a big highlight of the security talks, touching on DIDs and Verifiable Credentials. Continuing the day I attended a talk in one of the main tracks on how to build better README files for open source projects, which much more than anything stressed the need for automation, clarity and the overall sanity of the community.

Attending FOSDEM 2025 was an enlightening experience that provided a comprehensive view of the current and future landscape of open-source technology. The conference highlighted the diverse ways in which open-source projects can be monetized while maintaining their core values, as well as the legal and ethical challenges posed by AI developments. The discussions on sustainable development and cybersecurity underscored the importance of collaboration and innovation in addressing global challenges. Overall, FOSDEM 2025 reinforced the critical role of open-source communities in driving technological advancement and societal progress.

The Issues with the Basics

After some time, searching up “meal prep recipes” stops yielding meaningful or novel results and one gets stuck on websites with recipes that you dont really want. What if there were a recommendation algorithm for food? Although not meant for food, Instagram is a very big knowledge base of recipes + visuals and instructions for food you might really like.

As I started making recipes from Instagram, I couldnt help but find the process very inefficient and bothersome - having to keep a post open and read chaotic captions. One evening I had finally decided to solve this issue as it had been bothering me for a while and the solution just seems so simple.

Solution

I quickly got to opening Emacs and starting a new project. First steps: i) Function that can extract the description from an instagram post. ii) Structure data from description into defined format. With a little help from ChatGPT and GitHub Copilot I was able to get these two down within about 20 minutes. And was then able to move on the a more high level approach to serving this app in a minimal and yet viable way.

Instagram Descriptions Extraction

The first safe bet for getting data from websites is selenium, which for this project has just the right amount of complexity, however in my search I did come across SeleniumBase which is actually capable of extracting much more information from website that other tools just cannot get to. Since the web is a very structured place, extracting the description was quite simple:

driver = webdriver.Chrome(options=options)
try:
    driver.get(url)
    time.sleep(5)  # Wait for page to load

    # Instagram caption is often in the og:description meta tag
    try:
        description = driver.find_element(
            By.XPATH, "//meta[@property='og:description']"
        ).get_attribute("content")
    except Exception as e:
        print("Error fetching description:", e)
        description = ""
finally:
    driver.quit()

And we now have our description given literally any instagram post form a public page.

Parsing Data into Structure

Once we have our description from the above function, we can then use a simple snippet form the OpenAI documentation which takes care of extracting any text data into a defined pydantic model. Our model is very simple:

class Ingredient(BaseModel):
    name: str
    quantity: float
    unit: str
    optional: bool

class RecipeSchema(BaseModel):
    name: str
    ingredients: List[Ingredient]
    instructions: List[str]

To make this a bit more efficient, I wrote some custom decorators which will cache our extraction and formatting functions so we do not over-send any requests and save on our OpenAI calls. Alternatively one could also use locally hosted LLMs or perhaps some regex parsing since this is a very simple case, but for the sake of my time I chose the easy solution.

Packaging

Once we have our core functionality I chose to create a flask wrapper which hosts our features in a minimal UI where anyone can submit a URL and view the recipes created and stored in an sqlite database. One reason why I did not go for streamlit which would be much easier in terms of development, is that I wanted to make this as interoperable as I could, so anyone could fetch the recipe with just a simple ?format=json flag at the recipe URL.

Once the app was up and running I span up a web app an pythonanywhere and could instantly get structured recipes from anywhere in the world. This is a very naive implementation as it was done very quickly and just as a tool for anyone to use when they need.

In conclusion, leveraging technology like Grocy, Instagram, and AI tools can significantly enhance the meal prepping process, making it more efficient and enjoyable. By automating the extraction and structuring of recipe data from Instagram, you can save time and effort, allowing for a more streamlined approach to meal planning. The integration of open-source software and AI not only simplifies the task but also offers a customizable and scalable solution for anyone looking to optimize their meal preparation routine. This innovative approach demonstrates the potential of combining technology with everyday tasks to improve productivity and convenience. You can find the website here: https://velocitatem.pythonanywhere.com/ or on my GitHub.

The Idea

The idea was simple: bring the power of AI directly into Spacemacs. Having tried various Chat GPT integrations, none of which seemed to align with the way I wanted to use LLMs, I was very glad that I came across fabric I wanted to make it easy to apply AI patterns to text, whether it was an entire buffer or just a selected region. The goal was to enhance workflow efficiency by making advanced AI tools more accessible.

Getting Started

I started by cloning installing the Fabric AI repository. Fabric AI is an impressive tool that allows you to apply various AI patterns to text. My task was to create a seamless integration with Spacemacs, so users could leverage these capabilities without leaving their editor.

git clone https://github.com/danielmiessler/fabric.git

With the Fabric AI code in hand, I began writing the wrapper. It is just a simple wrapper around the CLI interface provided by fabric, you can clone it from here and them simply load the lisp file into your configuration:

(load "/path/to/fabric.el/fabric.el")

Key Features

The core features of Fabric.el are straightforward but powerful:

• AI Integration: Directly integrates with Fabric AI, bringing advanced AI capabilities to your fingertips.

• Effortless Pattern Application: Apply AI patterns to your entire buffer or just a selected region with ease.

• Workflow Efficiency: Custom keybindings designed for Spacemacs enhance your workflow, making AI tools more accessible than ever.

Building the Integration

The integration itself was built around a few key functions. The most important were fabric-run-pattern-on-buffer and fabric-run-pattern-on-region. These functions allow users to apply AI patterns to either the entire buffer or a specific region of text.

Here’s a simplified version of what these functions look like:

(defun fabric-run-pattern-on-buffer ()
  (interactive)
  (let ((content (buffer-string)))
    (fabric-apply-pattern content)))

(defun fabric-run-pattern-on-region (start end)
  (interactive "r")
  (let ((content (buffer-substring start end)))
    (fabric-apply-pattern content)))

These functions call fabric-apply-pattern, which sends the text to Fabric AI and returns the transformed content. The transformed content is then displayed in a separate buffer, ensuring that the original text remains untouched.

Example Use-Case

Imagine you’re working on a large text file and want to enhance its content using an AI pattern. With Fabric.el, you can simply write your prompt into a buffer or highlight a region you want to send to the LLM. Then, use fabric-run-pattern-on-buffer or fabric-run-pattern-on-region to apply the selected pattern (or use the keybindings). Fabric AI transforms your content, all within your Spacemacs environment. One of my favorite use-cases so far is writing email and working with daily text messages and other common text modalities.

Contributing

One of the best parts of working on open-source projects is the community. I welcome contributions from everyone! If you’re interested in improving Fabric.el or adding new features, please fork the repository, make your changes, and submit a pull request. Let’s make Fabric.el even better together.

Final Thoughts

Building Fabric.el over a weekend was a rewarding experience. It’s amazing how much you can accomplish with a clear goal and a bit of determination. If you’re a Spacemacs user looking to enhance your workflow with AI, give Fabric.el a try. It might just take your productivity to new heights.