Jonathan Lalou's Blog

Archive for the ‘en-US’ Category

Managing a large, multi-team codebase is a monumental task, especially when it has evolved over many years. Introducing architectural changes and maintaining consistency across autonomous teams adds another layer of complexity. In a comprehensive discussion, Tristan Hamilton, a distinguished member of the HubSpot team, presented a strategic approach to future-proofing Android codebases by leveraging static analysis tools like KtLint and Detekt.

Tristan began by framing the challenges inherent in a codebase that has grown and changed for over eight years. He emphasized that without robust systems, technical debt can accumulate, and architectural principles can erode as different teams introduce their own patterns. The solution, he proposed, lies in integrating automated guardrails directly into the continuous integration (CI) pipeline. This proactive approach ensures a consistent level of code quality and helps prevent the introduction of new technical debt.

He then delved into the specifics of two powerful static analysis tools: KtLint and Detekt. KtLint, as a code linter, focuses on enforcing consistent formatting and style, ensuring that the codebase adheres to a single, readable standard. Detekt, on the other hand, is a more powerful static analysis tool that goes beyond simple style checks. Tristan highlighted its ability to perform advanced analysis, including type resolution, which allows it to enforce architectural patterns and detect complex code smells that a simple linter might miss. He shared practical examples of how Detekt can be used to identify and refactor anti-patterns, such as excessive class size or complex methods, thereby improving the overall health of the codebase.

A significant part of the talk was dedicated to a specific, and crucial, application of these tools: safely enabling R8, the code shrinker and optimizer, in a multi-module Android application. The process is notoriously difficult and can often lead to runtime crashes if not handled correctly. Tristan showcased how custom Detekt rules could be created to enforce specific architectural principles at build time. For instance, a custom rule could ensure that certain classes are not obfuscated or that specific dependencies are correctly handled, effectively creating automated safety nets. This approach allowed the HubSpot team to gain confidence in their R8 configuration and ship with greater speed and reliability.

Tristan concluded by offering a set of key takeaways for developers and teams. He underscored the importance of moving beyond traditional static analysis and embracing tools that can codify architectural patterns. By automating the enforcement of these patterns, teams can ensure the integrity of their codebase, even as it grows and evolves. This strategy not only reduces technical debt but also prepares the codebase for future changes, including the integration of new technologies and methodologies, such as Large Language Model (LLM) generated code. It is a powerful method for building robust, maintainable, and future-ready software.

Links:

• HubSpot website
• Code Quality at Scale: Future Proof Your Android Codebase with KtLint and Detekt | Tristan Hamilton

Google Cloud and Workspace offer a comprehensive suite of tools designed to simplify software development and enhance productivity. Richard Seroter’s overview showcased recent advancements, emphasizing infrastructure, AI capabilities, and integrations that empower creators to build efficiently and scalably.

AI Infrastructure and Model Advancements

Richard began with Google Cloud’s vertically integrated AI stack, from foundational infrastructure like TPUs and GPUs to accessible services for model building and deployment. The Model Garden stands out as a hub for discovering over 130 first-party and third-party models, facilitating experimentation.

Gemini models, including 1.5 Pro and Flash, provide multimodal reasoning with expanded context windows—up to two million tokens—enabling complex tasks like video analysis. Vertex AI streamlines customization through techniques like RAG and fine-tuning, supported by tools such as Gemini Code Assist for code generation and debugging.

Agent Builder introduces no-code interfaces for creating conversational agents, integrating with databases and APIs. Security features, including watermarking and red teaming, ensure responsible deployment. Recent updates, as of May 2024, include Gemini 1.5 Flash for low-latency applications.

Data Management and Analytics Enhancements

BigQuery’s evolution incorporates AI for natural language querying, simplifying data exploration. Gemini in BigQuery generates insights and visualizations, while BigQuery Studio unifies workflows for data engineering and ML.

AlloyDB AI embeds vector search for semantic querying, enhancing RAG applications. Data governance tools like Dataplex ensure secure, compliant data handling across hybrid environments.

Spanner’s dual-region configurations and interleaved tables optimize global, low-latency operations. These features, updated in 2024, support scalable, AI-ready data infrastructures.

Application Development and Security Tools

Firebase’s Genkit framework aids in building AI-powered apps, with integrations for observability and deployment. Artifact Registry’s vulnerability scanning bolsters security.

Cloud Run’s CPU allocation during requests improves efficiency for bursty workloads. GKE’s Autopilot mode automates cluster management, reducing operational overhead.

Security enhancements include Confidential Space for sensitive data processing and AI-driven threat detection in Security Command Center. These 2024 updates prioritize secure, performant app development.

Workspace Integrations and Productivity Boosts

Workspace APIs enable embedding features like smart chips and add-ons into custom applications. New REST APIs for Chat and Meet facilitate notifications and event management.

Conversational agents via Dialogflow enhance user interactions. These tools, expanded in 2024, foster seamless productivity ecosystems.

Links:

• Richard Seroter on LinkedIn

TL;DR:
To back up all your Docker images safely, use docker save to export them and gzip to compress them.
Then, when you need to restore, use docker load to re-import everything.
Below you’ll find production-ready Bash scripts for automated backup and restore — complete with compression and error handling.

📦 Why You Need This

Whether you’re upgrading your system, cleaning your Docker environment, or migrating to another host, exporting your local images is crucial. Docker’s built-in commands make this possible, but using them manually for dozens of images can be tedious and space-inefficient.
This article provides automated scripts that will:

• Backup every Docker image individually,
• Compress each file with gzip for storage efficiency,
• Restore all images automatically with a single command.

🧱 Backup Script (backup_docker_images.sh)

The script below exports all Docker images, one by one, into compressed .tar.gz files.
Each image gets its own archive, named after its repository and tag.

#!/bin/bash
# --------------------------------------------
# Backup all Docker images into compressed .tar.gz files
# --------------------------------------------

BACKUP_DIR=~/docker-backup
mkdir -p "$BACKUP_DIR"
cd "$BACKUP_DIR" || exit 1

echo "📦 Starting Docker image backup..."
echo "Backup directory: $BACKUP_DIR"
echo

for image in $(docker image ls --format "{{.Repository}}:{{.Tag}}"); do
  # sanitize file name
  safe_name=$(echo "$image" | tr '/:' '__')
  outfile="${safe_name}.tar"
  gzfile="${outfile}.gz"

  echo "🟢 Saving $image → $gzfile"

  # Save and compress directly (no uncompressed tar left behind)
  docker save "$image" | gzip -c > "$gzfile"

  if [ $? -eq 0 ]; then
    echo "✅ Successfully saved $image"
  else
    echo "❌ Error saving $image"
  fi
  echo
done

echo "🎉 Backup complete!"
ls -lh "$BACKUP_DIR"/*.gz

💡 What This Script Does

• Creates a ~/docker-backup directory automatically.
• Iterates over every local Docker image.
• Uses docker save piped to gzip for direct compression.
• Prints friendly success and error messages.

Result: You’ll get a set of compressed files like:

jonathan-tomcat__latest.tar.gz
jonathan-mysql__latest.tar.gz
jonathan-grafana__latest.tar.gz
...

🔁 Restore Script (restore_docker_images.sh)

This companion script automatically restores every compressed image. It detects both .tar.gz and .tar files in the backup directory, decompresses them, and loads them back into Docker.

#!/bin/bash
# --------------------------------------------
# Restore all Docker images from .tar.gz or .tar files
# --------------------------------------------

BACKUP_DIR=~/docker-backup
cd "$BACKUP_DIR" || { echo "❌ Backup directory not found: $BACKUP_DIR"; exit 1; }

echo "🚀 Starting Docker image restore from $BACKUP_DIR"
echo

for file in *.tar.gz *.tar; do
  [ -e "$file" ] || { echo "No backup files found."; exit 0; }

  echo "🟡 Loading $file..."
  if [[ "$file" == *.gz ]]; then
    gunzip -c "$file" | docker load
  else
    docker load -i "$file"
  fi

  if [ $? -eq 0 ]; then
    echo "✅ Successfully loaded $file"
  else
    echo "❌ Error loading $file"
  fi
  echo
done

echo "🎉 Restore complete!"
docker image ls

💡 How It Works

• Automatically detects .tar.gz or .tar backups.
• Decompresses each one and loads it into Docker.
• Prints progress updates as it restores each image.

After running it, your local Docker environment will look exactly like before — same repositories, tags, and image IDs.

⚙️ How to Use

1️⃣ Backup All Docker Images

chmod +x backup_docker_images.sh
./backup_docker_images.sh

You’ll see a live summary of each image as it’s saved and compressed.

2️⃣ Restore Later (After a Prune or Reinstall)

chmod +x restore_docker_images.sh
./restore_docker_images.sh

Docker will reload each image automatically, maintaining all original metadata.

💾 Bonus: Cleaning and Rebuilding Your Docker Environment

If you want to clear all Docker data before restoring your images, run:

docker system prune -a --volumes

⚠️ Warning: This deletes all containers, images, networks, and volumes.
Afterward, simply run the restore script to bring your images back.

🧠 Why Use Gzip?

Docker image archives are often large — several gigabytes each. Compressing them with gzip:

• Saves 30–70% of disk space,
• Speeds up transfers (especially over SSH),
• Keeps the backups cleaner and easier to manage.

You can still restore them directly with gunzip -c file.tar.gz | docker load — no decompression step required.

✅ Summary Table

🚀 Conclusion

Backing up your Docker images is a crucial part of any development or CI/CD workflow. With these two scripts, you can protect your local Docker environment from accidental loss, disk cleanup, or reinstallation.
By combining docker save and gzip, you ensure both efficiency and recoverability — making your Docker workstation fully portable and disaster-proof.

Keep calm and backup your containers 🐳💾

Phil Nash, a developer relations engineer at DataStax, delivers a comprehensive guide to leveraging generative AI in JavaScript at NDC Melbourne 2025. His talk demystifies the process of building AI-powered applications, emphasizing that JavaScript developers can harness existing skills to create sophisticated solutions without needing deep machine learning expertise. Through practical examples and insights into tools like Gemini and retrieval-augmented generation (RAG), Phil empowers developers to explore this rapidly evolving field.

Understanding Generative AI Fundamentals

Phil begins by addressing the excitement surrounding generative AI, noting its accessibility since the release of the GPT-3.5 API two years ago. He emphasizes that JavaScript developers are well-positioned to engage with AI due to robust tooling and APIs, despite the field’s Python-centric origins. Using Google’s Gemini model as an example, Phil demonstrates how to generate content with minimal code, highlighting the importance of understanding core concepts like token generation and model behavior.

He explains tokenization, using OpenAI’s byte pair encoding as an example, where text is broken into probabilistic tokens. Parameters like top-k, top-p, and temperature allow developers to control output randomness, with Phil cautioning against overly high settings that produce nonsensical results, humorously illustrated by a chaotic AI-generated story about a gnome.

Enhancing AI with Prompt Engineering

Prompt engineering emerges as a critical skill for refining AI outputs. Phil contrasts zero-shot prompting, which offers minimal context, with techniques like providing examples or system prompts to guide model behavior. For instance, a system prompt defining a “capital city assistant” ensures concise, accurate responses. He also explores chain-of-thought prompting, where instructing the model to think step-by-step improves its ability to solve complex problems, such as a modified river-crossing riddle.

Phil underscores the need for evaluation to ensure prompt reliability, as slight changes can significantly alter outcomes. This structured approach transforms prompt engineering from guesswork into a disciplined practice, enabling developers to tailor AI responses effectively.

Retrieval-Augmented Generation for Contextual Awareness

To address AI models’ limitations, such as outdated or private data, Phil introduces retrieval-augmented generation (RAG). RAG enhances models by integrating external data, like conference talk descriptions, into prompts. He explains how vector embeddings—multidimensional representations of text—enable semantic searches, using cosine similarity to find relevant content. With DataStax’s Astra DB, developers can store and query vectorized data efficiently, as demonstrated in a demo where Phil’s bot retrieves details about NDC Melbourne talks.

This approach allows AI to provide contextually relevant answers, such as identifying AI-related talks or conference events, making it a powerful tool for building intelligent applications.

Streaming Responses and Building Agents

Phil highlights the importance of user experience, noting that AI responses can be slow. Streaming, supported by APIs like Gemini’s generateContentStream, delivers tokens incrementally, improving perceived performance. He demonstrates streaming results to a webpage using JavaScript’s fetch and text decoder streams, showcasing how to create responsive front-end experiences.

The talk culminates with AI agents, which Phil describes as systems that perceive, reason, plan, and act using tools. By defining functions in JSON schema, developers can enable models to perform tasks like arithmetic or fetching web content. A demo bot uses tools to troubleshoot a keyboard issue and query GitHub, illustrating agents’ potential to solve complex problems dynamically.

Conclusion: Empowering JavaScript Developers

Phil concludes by encouraging developers to experiment with generative AI, leveraging tools like Langflow for visual prototyping and exploring browser-based models like Gemini Nano. His talk is a call to action, urging JavaScript developers to build innovative applications by combining AI capabilities with their existing expertise. By mastering prompt engineering, RAG, streaming, and agents, developers can create powerful, user-centric solutions.

Links:

• DataStax company website
• Phil Nash on Twitter/X

Thanassis Bantios, VP of Engineering at T-Food, delivered a 17-minute talk at Devoxx Greece 2025 on managing component ownership in feature teams.

The Feature Team Dilemma

Bantios narrated a story of Helen, an entrepreneur scaling an online delivery startup. Initially, a small team communicated easily, but growth led to functional teams and a backend monolith, complicating contributions. Adopting microservices split critical components like orders and menu services, but communication broke down as features required multiple teams. Agile cross-functional teams solved this, enabling autonomy, but neglected component ownership, risking a “Frankenstein” codebase.

Defining Component Ownership

A component, deployable independently (e.g., backend service or client app), needs ownership to maintain health, architecture, documentation, and code reviews. Bantios stressed teams, not individuals, should own components to avoid risks like staff turnover. Using the Spotify matrix model, client components (e.g., Android) and critical backend services (e.g., menu service) are owned by chapters (craft-based groups like Android developers), ensuring knowledge sharing and manageable on-call rotations. Non-critical services, like ratings, can be team-owned.

Inner Sourcing for Speed

Inner sourcing allows any team to contribute to any component, reducing dependencies. Bantios emphasized standardization (language, CI/CD, architecture) to simplify contributions, focusing only on business logic. He suggested rating components on an inner-sourcing score (test coverage, documentation) and dedicating 20% of time to component backlogs. This prevents technical debt in feature-driven environments, ensuring fast, scalable development.

Links

• T-Food
• Devoxx Greece

TL;DR:
If you see this error when running Docker on Windows Subsystem for Linux (WSL2):

ERROR: Failed to Setup IP tables: Unable to enable SKIP DNAT rule:
(iptables failed: iptables --wait -t nat -I DOCKER -i br-xxxx -j RETURN:
iptables: No chain/target/match by that name. (exit status 1))

👉 The cause is usually that your system is using the nftables backend for iptables, but Docker expects the legacy backend.
Switching iptables to legacy mode and restarting Docker fixes it:

sudo update-alternatives --set iptables /usr/sbin/iptables-legacy
sudo update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy

Then restart Docker and verify:

sudo iptables -t nat -L

You should now see the DOCKER chain listed. ✅

🔍 Understanding the Problem

When Docker starts, it configures internal network bridges using iptables.
If it cannot find or manipulate its DOCKER chain, you’ll see this “Failed to Setup IP tables” error.
This problem often occurs in WSL2 environments, where the Linux kernel uses the newer nftables system by default, while Docker still relies on the legacy iptables interface.

In short:

• iptables-nft (default in modern WSL2) ≠ iptables-legacy (expected by Docker)
• The mismatch causes Docker to fail to configure NAT and bridge rules

⚙️ Step-by-Step Fix

1️⃣ Check which iptables backend you’re using

sudo iptables --version
sudo update-alternatives --display iptables

If you see something like iptables v1.8.x (nf_tables), you’re using nftables.

2️⃣ Switch to legacy mode

sudo update-alternatives --set iptables /usr/sbin/iptables-legacy
sudo update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy

Confirm the change:

sudo iptables --version

Now it should say (legacy).

3️⃣ Restart Docker

If you’re using Docker Desktop for Windows:

wsl --shutdown
net stop com.docker.service
net start com.docker.service

or simply quit and reopen Docker Desktop.

If you’re running Docker Engine inside WSL:

sudo service docker restart

4️⃣ Verify the fix

sudo iptables -t nat -L

You should now see the DOCKER chain among the NAT rules:

Chain DOCKER (2 references)
target     prot opt source               destination
RETURN     all  --  anywhere             anywhere

If it appears — congratulations 🎉 — your Docker networking is fixed!

🧠 Extra Troubleshooting Tips

• If the error persists, flush and rebuild the NAT table:

  sudo service docker stop
  sudo iptables -t nat -F
  sudo iptables -t nat -X
  sudo service docker start
  

• Check kernel modules (for completeness):

  lsmod | grep iptable
  sudo modprobe iptable_nat
  

• Keep Docker Desktop and WSL2 kernel up to date — many network issues are fixed in newer builds.

✅ Summary

🚀 Conclusion

This “Failed to Setup IP tables” issue is one of the most frequent Docker-on-WSL2 networking errors.
The root cause lies in the nftables vs legacy backend mismatch — a subtle but critical difference in Linux networking subsystems.
Once you switch to the legacy backend and restart Docker, everything should work smoothly again.

By keeping your WSL2 kernel, Docker Engine, and iptables configuration aligned, you can prevent these issues and maintain a stable developer environment on Windows.

Happy containerizing! 🐋

In an era where digital payloads traverse global networks at breakneck speeds, the subtle art of data compression remains a cornerstone of efficient web delivery, often overlooked amid flashier optimizations. Antoine Caron, engineering manager for frontend teams at Scaleway, reignited this vital discourse at dotJS 2025, advocating for shared dictionaries as a transformative leap in HTTP efficiency. With a keen eye on performance bottlenecks, Antoine dissected how conventional compressors like Gzip and Brotli falter on repetitive assets, only to unveil a protocol that leverages prior transfers as reference tomes, slashing transfer volumes by up to 70% in real-world scenarios. This isn’t arcane theory; it’s a pragmatic evolution, already piloted in Chrome and poised for broader adoption via emerging standards.

Antoine’s clarion call stemmed from stark realities unearthed in the Web Almanac: a disconcerting fraction of sites neglect even basic compression, forfeiting gigabytes in needless transit. A Wikipedia load sans Gzip drags versus its zipped twin, a 15% velocity boon; jQuery’s minified bulk evaporates over 50KB under maximal squeeze, a 70% payload purge sans semantic sacrifice. Yet, Brotli’s binary prowess, while superior for static fare, stumbles on dynamic deltas—vendor bundles morphing across deploys. Enter shared dictionary compression: an HTTP extension where browsers cache antecedent responses as compression glossaries, enabling servers to encode novelties against these baselines. For jQuery’s trek from v3.6 to v3.7, mere 8KB suffices; YouTube’s quarterly refresh yields 70% thrift, prior payloads priming the pump.

This mechanism, rooted in Google’s erstwhile SDCH (Shared Dictionary Compression over HTTP) and revived in IETF drafts like Compression Dictionary Transport, marries client-side retention with server-side savvy. Chrome’s 2024 rollout—flagged under chrome://flags/#shared-dictionary-compression—harnesses Zstandard or Brotli atop these shared tomes, with Microsoft Edge’s ZSDCH echoing for HTTPS. Antoine emphasized pattern matching: regex directives tag vendor globs, caching layers sequester these corpora, subsequent fetches invoking them via headers like Dictionary: . Caveats abound—staticity’s stasis, cache invalidation’s curse—but mitigations like periodic refreshes or hybrid fallbacks preserve robustness.

Antoine’s vision extends to edge cases: CDN confederacies propagating dictionaries, mobile’s miserly bandwidths reaping richest rewards. As Interop 2025 mandates cross-browser parity—Safari and Firefox intent-to-ship signaling convergence—this frontier beckons builders to audit headers, prototype pilots, and pioneer payloads’ parsimony. In a bandwidth-beleaguered world, shared dictionaries don’t merely optimize; they orchestrate a leaner, more equitable web.

The Mechanics of Mutual Memory

Antoine unraveled the protocol’s weave: clients stash responses in a dedicated echelon, servers probe via Accept-Dictionary headers, encoding diffs against these reservoirs. Brotli’s static harbors, once rigid, now ripple with runtime references—Zstd’s dynamism amplifying for JS behemoths. Web Almanac’s diagnostics affirm: uncompressed ubiquity persists, yet 2025’s tide, per Chrome’s telemetry, portends proliferation.

Horizons of Header Harmony

Drafts delineate transport: dictionary dissemination via prior bodies or external anchors, invalidation via etags or TTLs. Antoine’s exhortation: audit via Lighthouse, experiment in canaries—Scaleway’s vantage yielding vendor variances tamed. As specs solidify, this symbiosis promises payloads pared, performance propelled.

Links:

• Antoine Caron on LinkedIn
• Scaleway