This is a known issue (anthropics/claude-code#34255), and there’s a community tool called claude-remote-watchdog that auto-detects and fixes dead sessions. But getting it working properly has some gotchas nobody tells you about. Here’s the complete walkthrough, including every pitfall I hit along the way.

What You Need

• Claude Code CLI (Pro or Max plan)
• tmux — your Claude Code sessions must run inside tmux for the watchdog to see them
• macOS or Linux (this guide uses macOS with Homebrew)

Step 1: Install tmux

If you don’t have it:

1
2
3
4
5
6
7
8
# macOS
brew install tmux

# Ubuntu/Debian
sudo apt install tmux

# Fedora
sudo dnf install tmux

Verify it’s installed:

1
which tmux

You should see something like /opt/homebrew/bin/tmux.

Step 2: Run Claude Code Inside tmux

This is the critical part. The watchdog reads tmux pane content to detect stuck sessions. If Claude Code isn’t running inside tmux, the watchdog has nothing to scan.

1
tmux new -s life

You’ll see a tmux status bar at the bottom of your terminal. Now launch Claude Code inside this session as you normally would.

That’s it — you’re now running Claude Code inside a tmux pane.

Quick tmux survival guide:

• Ctrl+B then D — detach (session keeps running in background)
• tmux attach -t life — reattach to your session
• tmux ls — list sessions
• Ctrl+B then C — new window inside the session

Step 3: Install the Watchdog

1
2
3
git clone https://github.com/sma1lboy/claude-remote-watchdog.git
cd claude-remote-watchdog
./install.sh

This creates symlinks in ~/.claude/:

• ~/.claude/commands/remote-watchdog.md — slash command
• ~/.claude/scripts/remote-watchdog.sh — the actual watchdog script

Test it manually:

1
~/.claude/scripts/remote-watchdog.sh

You should see something like:

1
2
3
=== Remote Control Watchdog 22:05:42 ===
[HEALTHY] claude (%0)
[OK] All Remote Control sessions healthy

If you see [SKIP] No Remote Control sessions found, make sure you have /remote-control active inside your tmux session.

The install also adds a /remote-watchdog slash command you can run inside Claude Code. It’s nice to have for manual checks, but I went with the cronjob approach below for fully unattended recovery.

Step 4: Set Up Cron (The Right Way)

Use crontab to run the watchdog every 5 minutes, completely outside Claude Code:

1
crontab -e

Important: Add a PATH line before the cron entry. Cron runs with a minimal PATH that doesn’t include /opt/homebrew/bin, so it can’t find tmux. Without this, the watchdog will run but report [SKIP] every single time because it literally cannot execute the tmux commands it needs.

1
2
PATH=/opt/homebrew/bin:/usr/bin:/bin
*/5 * * * * ~/.claude/scripts/remote-watchdog.sh >> /tmp/remote-watchdog.log 2>&1

If you’ve never used crontab before, you’ll see:

1
2
crontab: no crontab for yourname - using an empty one
crontab: installing new crontab

That’s normal. It created a fresh crontab with your entry.

Step 5: Disable the Update Banner

This is the second gotcha that took a while to figure out. Claude Code shows an “Update available! Run: brew upgrade claude-code” banner in the status area — the same area where the Remote Control status normally appears. When this banner is showing, the watchdog captures that text instead of the Remote Control status, so it reports [SKIP] even though your session is right there.

The fix is to set DISABLE_AUTOUPDATER=1. More on where to put this below.

Step 6: Set Up Your Shell Alias

By now you probably want a quick command that launches Claude Code with all the right settings. Add this to your ~/.zshrc:

1
c() { DISABLE_AUTOUPDATER=1 claude --effort max --dangerously-skip-permissions "$@"; }

Then reload:

1
source ~/.zshrc

Now c gives you:

• DISABLE_AUTOUPDATER=1 — kills the update banner so the watchdog can see the status bar
• --effort max — maximum reasoning depth (Opus only)
• --dangerously-skip-permissions — no permission prompts for every command
• "$@" — passes through any extra arguments, so c -c continues your last session

Step 7: Skip the Safety Confirmation

When you run --dangerously-skip-permissions, Claude Code shows a scary warning and asks you to confirm. To skip it, add this to ~/.claude/settings.json:

1
2
3
{
  "skipDangerousModePermissionPrompt": true
}

If you already have settings in that file, just add the key to the existing JSON.

Step 8: Enable Remote Control by Default

So you don’t have to type /remote-control every time you start a session, run /config inside Claude Code and set “Enable Remote Control for all sessions” to true. Every new Claude Code session will automatically start with Remote Control active.

Checking the Logs

Your watchdog logs to /tmp/remote-watchdog.log. Check it anytime:

1
2
3
4
5
# Last few entries
tail -20 /tmp/remote-watchdog.log

# Follow live
tail -f /tmp/remote-watchdog.log

A healthy log looks like:

1
2
3
4
5
6
=== Remote Control Watchdog 13:40:00 ===
[WARN] claude (%1): 'reconnecting' — confirming next check
=== Remote Control Watchdog 13:45:00 ===
[DEAD] claude (%1): stuck on 'reconnecting' — auto-reconnecting
[ACTION] Cycling /remote-control on pane %1 (claude)...
[OK] Reconnect sequence sent to pane %1 (claude)

The watchdog uses a 2-check grace period — [WARN] on first detection, [DEAD] and auto-reconnect on the second. This avoids false positives on transient drops.

How the Fix Actually Works

When the watchdog detects a stuck session, it sends tmux keystrokes to cycle the /remote-control menu:

1. Ctrl+C to clear the prompt
2. Types /remote-control which opens the TUI menu
3. Navigates to “Disconnect this session” and presses Enter
4. Types /remote-control again, which auto-connects to a fresh bridge

Your actual Claude Code session — with its full conversation history — never stops. Only the remote bridge gets cycled. Think of it like unplugging and re-plugging a cable.

Known Issue: Effort Level “max” Doesn’t Persist

If you set "effortLevel": "max" in settings.json, it gets silently downgraded to “high” when you interact with the /model UI. This is a known bug. The workaround is using the --effort max CLI flag every time, which is why we put it in the shell alias above.

The Complete Setup Checklist

1. Install tmux (brew install tmux)
2. Start Claude Code inside tmux (tmux new -s life, then launch Claude)
3. Install the watchdog (git clone + ./install.sh)
4. Set up crontab with the correct PATH
5. Disable the update banner (DISABLE_AUTOUPDATER=1)
6. Add the shell alias to ~/.zshrc
7. Skip the safety confirmation in ~/.claude/settings.json
8. Enable Remote Control for all sessions via /config

Quick Reference

Remote Control is genuinely useful when it works — start a task on your laptop, continue from your phone on the couch. The connection bug makes it unreliable, but with this watchdog setup, the dead sessions get automatically revived without you lifting a finger. Set it up once and forget about it.

Why QdrantSync?

Snapshots are powerful, but they’re not always the best option for every scenario. Challenges arise when migrating data:

• Cluster Size Differences: Snapshots assume identical setups, making it tricky to adjust for varying cluster configurations.
• Flexibility: Adapting data, schema, or replication factors during migration requires extra effort.
• Incremental Updates: Snapshots don’t support partial or staged migrations easily.

QdrantSync solves these pain points by providing a robust and flexible alternative for seamless data transfer.

Key Features

• Customizable Migration: Fine-tune schema settings like replication factors and prefixes to suit your destination cluster.
• Incremental Migration: Mark and track migrated data, allowing you to resume or refresh migrations without duplication.
• Scalable Batch Processing: Scroll through large datasets efficiently with real-time progress tracking via tqdm.
• Error Handling: Safe operations ensure no unintended overwrites or data loss, with options to continue migrations for existing collections.

Getting Started

1. Install:

   1
   2
   pip install QdrantSync
   qdrantsync --help
   

2. Migrate Data:

   1
   qdrantsync --source-url <source> --destination-url <destination> --migration-id <id>
   

Use Cases

• Migrate Qdrant data between environments (e.g., staging to production).
• Upgrade infrastructure or move to a different cloud provider.
• Perform selective or incremental backups.

Contribute

I’d love to hear your feedback or see contributions! The project is open-source and MIT-licensed.

GitHub Repo

Check it out here: GitHub.

Have you run into similar challenges with Qdrant snapshots? Let me know your thoughts or suggestions!

Why Validate JSON Outputs?

In the world of machine learning and data science, models often need to output data in structured formats, JSON being one of the most popular due to its versatility and wide adoption in web services and applications. Ensuring your model reliably produces valid JSON responses is crucial, especially in production environments where data consistency and integrity are paramount.

Introducing Custom Metrics in MLflow

MLflow, an open-source platform for the machine learning lifecycle, includes capabilities for tracking experiments, packaging code into reproducible runs, and managing models. However, it might not natively support specific validation checks like verifying JSON output. This is where custom metrics come into play.

Step-by-Step Guide to Creating a JSON Validity Metric

Below is a detailed walkthrough on how to implement a custom metric in MLflow for checking JSON validity. This script demonstrates adding such a metric and using it to evaluate a model’s predictions.

1. Define the JSON Validity Evaluation Function

First, we define an evaluation function that checks if a given string is valid JSON. This function iterates through each model prediction, validating each one and appending the result (1 for valid, 0 for invalid) to a list of scores.

1
2
3
4
5
6
7
8
9
def _json_validity_eval_fn(outputs, references):
    validity_scores = []
    for _, row in outputs.iterrows():
        prediction = row["prediction"]
        if _is_valid_json(prediction):
            validity_scores.append(1)
        else:
            validity_scores.append(0)
    return MetricValue(validity_scores)

2. Implement a Helper Function to Check JSON Validity

A helper function uses Python’s json.loads method to determine if a string is a valid JSON. It returns True for valid JSON strings and False otherwise.

1
2
3
4
5
6
def _is_valid_json(s):
    try:
        json.loads(s)
        return True
    except ValueError:
        return False

3. Create the Custom Metric

We then wrap our evaluation function in a custom metric definition using MLflow’s make_metric function, specifying our evaluation function, whether a higher score is better, and a name for the metric.

1
2
3
4
5
6
def json_validity() -> EvaluationMetric:
    return make_metric(
        eval_fn=_json_validity_eval_fn,
        greater_is_better=True,
        name="json_validity",
    )

4. Evaluate the Model

With the custom metric defined, we can now use it to evaluate a model’s output. In this example, we use a remote tracking server plus MLflow deployments, feel free to adapt this to your needs, the DataFrame in my example are two inputs designed to produce JSON outputs and invoke mlflow.evaluate with our custom metric.

1
2
3
4
5
6
7
8
9
10
11
12
# Point the client to the local MLflow Deployments Server and set tracking URI
set_deployments_target("http://localhost:7000")
mlflow.set_tracking_uri("http://localhost:5000")

# Evaluate the model with the custom metric
with mlflow.start_run() as run:
    results = mlflow.evaluate(
        model="endpoints:/chatgpt-35-turbo",
        data=eval_data,
        inference_params={"max_tokens": 100, "temperature": 0.0},
        extra_metrics=[json_validity()],
    )

Final code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
import json
import mlflow
import pandas as pd
from mlflow.deployments import set_deployments_target
from mlflow.metrics.base import MetricValue
from mlflow.models import EvaluationMetric, make_metric


def _json_validity_eval_fn(outputs, references):
    # Initialize a list to store validity scores
    validity_scores = []

    # Iterate over each row in the DataFrame
    for _, row in outputs.iterrows():
        # Extract the prediction from the current row
        prediction = row["prediction"]

        # Check if the prediction is a valid JSON
        if _is_valid_json(prediction):
            validity_scores.append(1)  # Valid JSON
        else:
            validity_scores.append(0)  # Invalid JSON

    # Return a MetricValue object with the scores
    return MetricValue(validity_scores)


def _is_valid_json(s):
    """
    Helper function to check if a string is a valid JSON.
    """
    try:
        json.loads(s)
        return True
    # json.decoder.JSONDecodeError inherits from ValueError
    except ValueError:
        return False


def json_validity() -> EvaluationMetric:
    """
    Creates a metric for evaluating the validity of JSON strings produced by a model.
    """
    return make_metric(
        eval_fn=_json_validity_eval_fn,
        greater_is_better=True,
        name="json_validity",
    )


# Point the client to the local MLflow Deployments Server
set_deployments_target("http://localhost:7000")
mlflow.set_tracking_uri("http://localhost:5000")

# Create a test case of inputs that will be passed into the model and ground_truth
eval_data = pd.DataFrame(
    {
        "inputs": [
            'Convert the following description into a JSON object: MLflow is an open source platform for the machine learning lifecycle, including experimentation, reproducibility, and deployment. Structure the JSON with keys for "name", "description", and "features".',
            "Provide a brief explanation of what Apache Spark is.",
        ]
    }
)

with mlflow.start_run() as run:
    results = mlflow.evaluate(
        model="endpoints:/chatgpt-35-turbo",
        data=eval_data,
        inference_params={"max_tokens": 100, "temperature": 0.0},
        # model_type="question-answering",
        # Include the custom metric for JSON validation
        extra_metrics=[json_validity()],
    )

    # Print aggregated evaluation results
    print(f"Aggregated evaluation results: \n{results.metrics}")

    # Evaluation result for each data record is available in results.tables
    eval_table = results.tables["eval_results_table"]
    print(f"Evaluation table: \n{eval_table}")

Conclusion

Adding custom metrics to MLflow allows for flexible and precise evaluation of your models, tailored to your specific needs. By validating JSON outputs, you ensure that your model meets the requirements for structured data output, enhancing its reliability and applicability in real-world scenarios.

I hope this tutorial has been helpful. As always, I encourage you to experiment with this script and adapt it to your projects. Happy coding!

• Scale
• Performance
• Disaster recovery

In this blog post, I’ll walk you through my research process, offering insights into the various aspects I considered and revealing why we eventually decided on Qdrant. Let’s dive into the journey of this decision-making process.

Milvus: A Renowned Name with Robust Architecture

The first port of call on our journey was Milvus, an esteemed entity in the realm of vector databases. With a multi-layered, robust architecture, it has gained significant traction on GitHub, cementing its position in the landscape of popular vector databases.

At its core, Milvus boasts a design that is both comprehensive and sophisticated. Its default configuration deploys a considerable number of pods, reflecting an impressive level of scalability and resilience. However, this also means that it demands substantial resources, which, while suitable for some, proved to be a bit too resource-intensive for our specific needs.

Despite the undeniable merits of Milvus, including its high performance, scalable architecture, and strong community support, it felt like a larger tool than we required for our particular scenario. As a result, its advanced functionality and the operational overhead associated with managing such a system seemed somewhat disproportionate to our use case.

While Milvus undoubtedly excels in many dimensions, it underscored the importance of aligning the capabilities of a tool with our project’s specific needs, a lesson we carried forward in our quest for the optimal vector database.

Pinecone: A Powerful Proprietary Solution

Our exploration then led us to Pinecone, a fully managed vector database renowned for adeptly handling unstructured search engine requirements. Pinecone distinguishes itself with its intuitive features and streamlined operations, which were evident in the recent 2.0 release.

The standout feature in this new release was the introduction of single-stage filtering. This innovation greatly simplifies data querying, allowing users to retrieve relevant data more efficiently, without the need for multiple filtering stages. This unique aspect undoubtedly adds value, especially for teams seeking streamlined and efficient data management.

However, despite Pinecone scoring highly on most of our key considerations – such as performance, scale, and data persistence – it fell short in a couple of critical areas for us. Firstly, Pinecone is a proprietary paid solution and not an open-source platform. Secondly, Pinecone does not provide a self-hosted option. This was a crucial requirement for us, as we were specifically seeking a self-hosted vector database to maintain greater control over our data and operations.

In conclusion, while Pinecone’s impressive capabilities and innovative features make it an excellent choice for many, it was not the perfect fit for our specific scenario due to its proprietary nature and lack of a self-hosting option. But, I can see Pinecone as the perfect choice for companies that need a solution but don’t want to deal with self-hosting this kind of service.

Qdrant: A Robust Rust-built Vector Database

The next milestone on our exploration was Qdrant, a vector database built entirely in Rust. As we delved deeper into our research, it quickly became evident that Qdrant was a formidable contender in the arena of vector databases.

One of the key aspects that set Qdrant apart was its dynamic query planning. This feature allows for more efficient processing of queries, resulting in quicker retrieval of relevant information. The payload data indexing feature also emerged as a major highlight, contributing to faster data access and improved search capabilities.

Another standout element was Qdrant’s Scalar Quantization feature. Often mentioned in discussions and articles, this feature is noted for its significant role in enhancing performance and efficiency. It achieves this by reducing the size of stored vectors while maintaining their distinct characteristics, leading to optimized resource utilization.

A major attraction of Qdrant was its ease to run container. This allows for smooth deployment and management of Qdrant within a Kubernetes environment, which is particularly beneficial for teams using container orchestration systems.

Despite the many strong points of Qdrant, our research did uncover some online concerns like missing authentication in the Qdrant API, this feature was addressed recently. But, it is in the development branch. However, this is a minor issue for us since we are not exposing the database to the outside. This is a relatively new Database and offers excellent performance, making it an enticing choice for our needs.

In the end, the combination of dynamic query planning, payload data indexing, Scalar Quantization, and seamless Kubernetes integration swayed us in Qdrant’s favor. Despite minor concerns, its robust performance, efficiency, and compatibility made it an ideal choice for our specific requirements.

PGVector: A Trusted Postgres Extension with Scaling Challenges

Finally, we turned our attention to PGVector, an extension of the widely trusted PostgreSQL database. PostgreSQL’s reputation as a robust and reliable solution for many businesses initially made PGVector an intriguing option in our quest for the ideal vector database.

However, upon further research, a few limitations came to light. One significant concern was that scaling PGVector within a Kubernetes cluster could pose challenges. Kubernetes is often used for managing containerized workloads and services, and any difficulties in scaling within this environment could hinder operational efficiency.

Another aspect where PGVector seemed to falter was performance. Compared to its competitors, search operations in PGVector were reported to be slower. While this might not be an issue for smaller scale projects, it could potentially become a bottleneck in more demanding scenarios, affecting the overall efficiency of data retrieval.

On a positive note, with Postgres there are plenty of tools and integrations already available online, a key factor in our evaluation was disaster recovery, and Postgres definetly scores high in this category. However, the lower performance and scalability scores made it less appealing compared to the other options we were considering.

In conclusion, despite its roots in the well-regarded PostgreSQL database, the challenges related to scaling and performance led us to explore other options.

The Final Choice: Qdrant - A Winning Combination of Performance and Scalability

After conducting comprehensive research and carefully evaluating our options, we found Qdrant to be the ideal choice for our specific needs. This Rust-built vector database showcased superior performance and exhibited a significant edge over its competitors in a number of key areas.

Qdrant’s seamless scalability within a Kubernetes environment was a major factor in our decision, as it ensures the database can grow and adapt to our evolving needs. Moreover, standout features like dynamic query planning and payload data indexing further solidified its position as our top choice. These features collectively contribute to efficient data retrieval and improved search capabilities, which are critical to our operations.

For those setting off on a similar journey in the world of vector databases, we plan to use the official Helm chart for deploying Qdrant in our Kubernetes clusters. This resource provides a reliable, streamlined approach to deployment, simplifying the integration process.

In conclusion, this exploration through the landscape of vector databases has been a valuable and enlightening experience. I’m eager to see how Qdrant’s robust capabilities will enhance our operations at Builder.ai. I hope that sharing our journey will provide useful insights for others navigating the complexities of vector database selection. Until next time, happy coding!

In this blog post, we will provide an introduction to vector databases. We will discuss the different types of vector representations, and we will explain how vector databases work. We will also discuss some of the benefits of using vector databases.

What are Vector Representations?

Vector representations serve as a bridge, translating various forms of data - such as text, images, and audio - into numeric form. This conversion facilitates the encapsulation of meaning, characteristics, or features from the original data, making it more accessible for computational processing and analysis.

Several types of vector representations are commonly used, each with its unique advantages and applications. Here’s a closer look at some of these:

• Word Embeddings: These are vector representations specifically designed for words, capturing their semantic meanings. These embeddings are often derived from extensive text corpora, leveraging machine learning techniques to represent the nuanced relationships between words. Word embeddings find wide-ranging applications across numerous tasks, including text classification, machine translation, and question answering.

• Image Embeddings: Just as words can be translated into numeric form, images can be transformed into vector representations as well. Image embeddings distill visual content into a format that machines can understand and process. These embeddings, generally learned from large image datasets, can represent the content of images, enabling tasks like image classification, image retrieval, and object detection.

• Audio Embeddings: For audio data, audio embeddings provide a means to capture and represent the distinct characteristics of sound. These vector representations, trained on extensive audio corpora, can encapsulate the content of audio recordings. Applications for audio embeddings are diverse and include speech recognition, speaker identification, and music genre classification.

In essence, vector representations provide a powerful tool to translate various forms of data into a language that machines can understand, process, and learn from, paving the way for a broad spectrum of data analysis and machine learning tasks.

How do Vector Databases Work?

At their core, vector databases are engineered to handle the storage and querying of vector representations of data. They employ a mix of strategies to efficiently manage these vector representations, making it possible to retrieve relevant data quickly and accurately. Let’s delve into some of these techniques:

• Hierarchical Indexes: Imagine storing and organizing data in a tree-like structure, where each branch leads you closer to the information you’re seeking. That’s essentially what hierarchical indexing does. It allows vector databases to swiftly locate vector representations similar to a given vector, reducing search times and increasing efficiency.

• Spatial Indexes: Spatial indexing involves using specific data structures, like kd-trees or quadtrees, which are designed to handle multi-dimensional data. This approach allows vector databases to rapidly find vector representations that are in close proximity to a given vector. In other words, it’s like having a map that guides you to the data points that are ‘nearest’ to your location in a multi-dimensional space.

• Graph Indexes: Graph indexing makes use of graph data structures to store and query vector representations. If you picture your data as a network of interconnected points, then graph indexing helps you find the data points that are directly linked to a given vector. It’s akin to finding friends-of-friends in a social network.

In a nutshell, vector databases utilize these techniques to efficiently navigate the high-dimensional space of vector representations, making it possible to quickly retrieve the data that’s most relevant to your query. This functionality is integral to many machine learning applications and data analysis tasks.

Benefits of Using Vector Databases

There are many benefits to using vector databases. Some of the benefits of using vector databases include:

• Faster Search: Vector databases can be used to quickly find vector representations that are similar to a given vector representation. This can be used to improve the performance of search applications, such as search engines and recommender systems.
• More Accurate Search: Vector databases can be used to find vector representations that are more semantically similar to a given vector representation. This can be used to improve the accuracy of search applications, such as search engines and recommender systems.
• More Flexible Search: Vector databases can be used to perform a variety of search queries, such as nearest neighbor search, range search, and keyword search. This makes vector databases more flexible than traditional relational databases.

Conclusion

Vector databases are a powerful new technology for storing and querying vector representations of data. Vector databases can be used to improve the performance and accuracy of a variety of applications, such as search engines, recommender systems, and machine learning applications.

Sentry is a popular error tracking and monitoring tool that helps developers identify and fix issues in their applications. By default, Sentry captures unhandled exceptions and logged errors. However, in some cases, you might want to focus on unhandled exceptions only, or you might encounter a situation where Sentry reports handled exceptions without your consent from other integrations. In this blog post, we will show you how to configure Sentry to capture unhandled exceptions only in your Python applications.

Note: Handled exceptions can be useful in some situations, especially when you want to capture them manually. If you prefer to keep capturing handled exceptions, you can modify the function presented in this post to only ignore logger events.

Configuring Sentry to Capture Unhandled Exceptions Only

To achieve this, you can utilize Sentry’s before_send callback. This callback allows you to modify and filter events before they are sent to Sentry. Here is the code that demonstrates how to configure Sentry to capture unhandled exceptions only:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
sentry_sdk.init(
    dsn=dsn,
    environment=environment,
    before_send=sentry_before_send,
)

def sentry_before_send(event, hint):
    """Filters Sentry events before sending.

    This function filters out handled exceptions and logged errors.
    By doing this we will only receive unhandled exceptions on Sentry.

    Args:
        event (dict): The event dictionary containing exception data.

        hint (dict): Additional information about the event, including
            the original exception.

    Returns:
        dict: The modified event dictionary, or None if the event should be
            ignored.
    """

    # Ignore logged errors
    if "logger" in event:
        return None

    # Ignore handled exceptions
    exceptions = event.get("exception", {}).get("values", [])
    if exceptions:
        exc = exceptions[-1]
        mechanism = exc.get("mechanism")

        if mechanism:
            if mechanism.get("handled"):
                return None

    return event

With this configuration, Sentry will ignore both handled exceptions and logged errors, focusing only on unhandled exceptions. This helps to reduce noise in your Sentry dashboard and allows you to concentrate on the most critical issues in your application.

We hope this post is helpful to those who want to customize Sentry’s exception reporting behavior. Happy debugging!

Introduction

Today, I am excited to announce the release of a new open-source project called Killport. Killport is a simple command-line interface (CLI) tool designed to help you easily free up ports in Linux. If you’ve ever encountered the issue of a port being occupied by an unknown process or you want to quickly kill a process listening on a specific port, Killport is here to save the day!

In this blog post, we’ll discuss how Killport can help you resolve common port-related issues and demonstrate how to install and use it on your Linux system.

Why Killport?

As developers, we often work with applications that require specific ports to function properly. Occasionally, these ports may be occupied by other processes, causing conflicts and preventing our applications from running smoothly.

Searching for the process that’s listening on a specific port and then killing it can be a cumbersome task, especially when you’re in the middle of development or troubleshooting. That’s where Killport comes in. It simplifies the process of freeing up a port by automatically finding and terminating the process that’s occupying it.

Installing Killport

The easiest way to install Killport on your Linux system is by running the following command:

1
curl -sL https://bit.ly/killport | sh

This command will download the Killport installation script and execute it, installing the Killport binary in your $HOME/.local/bin directory.

You can also find binary releases for various Linux architectures on the Killport GitHub releases page.

Using Killport

Using Killport is straightforward. Simply run the following command, replacing <port> with the port number you want to free:

1
killport <port>

For example, to kill the process listening on port 8080, you would run:

1
killport 8080

Killport will then identify the process occupying the specified port and terminate it, freeing up the port for your application to use.

Conclusion

Killport is a handy CLI tool that makes it easy to free up ports in Linux by killing the processes listening on them. By simplifying this task, Killport saves you time and helps you maintain a smooth development workflow. Give it a try, and let us know what you think!

Don’t forget to star and contribute to the Killport GitHub repository if you find it useful!

In this blog post, I’ll share my findings and insights on the different types of Azure virtual machines available and how to select the best one for your workload. Whether you’re new to Azure or a seasoned user, this guide will provide you with valuable information to help you optimize your performance and cost efficiency on the cloud. So, let’s get started!

Introduction

Microsoft Azure offers a range of virtual machines (VMs) to suit a variety of computing needs. There are several factors to consider when selecting the best VM for your workload, including memory, CPU, storage, and networking requirements, as well as operating system compatibility and cost.

Here’s a brief overview of the machine types available on Azure:

• General Purpose: These machines are designed for a wide range of workloads and are available in several series, including B, Dsv3, and Dasv4. They offer a balance of CPU, memory, and network resources at an affordable cost.

• Compute Optimized: These machines are optimized for high-performance computing workloads and are available in several series, including Fsv2 and Fs. They offer the highest CPU-to-memory ratio and are ideal for compute-intensive applications.

• Memory Optimized: These machines are designed for memory-intensive workloads and are available in several series, including Esv3, Easv4, and M. They offer a high memory-to-CPU ratio and are ideal for data analytics and in-memory databases.

• Storage Optimized: These machines are optimized for storage-intensive workloads and are available in several series, including Ls and H. They offer high disk throughput and are ideal for applications that require large-scale storage solutions.

• GPU: These machines are designed for graphics-intensive workloads and are available in several series, including NV and NC. They offer dedicated GPU resources and are ideal for applications that require high-performance graphics processing.

Choosing the Best VM based on Your Requirements for Kubernetes Clusters

When selecting a VM for your Kubernetes cluster on Azure, it’s important to choose one that meets your specific requirements. Here are some factors to consider when choosing the best VM for your workload:

1. Memory and CPU requirements

Memory and CPU are two of the most important resources to consider when choosing a VM for your Kubernetes cluster. In general, Kubernetes clusters require a high amount of memory and CPU resources to run efficiently. When selecting a VM, make sure it has enough memory and CPU resources to handle your workload.

2. Storage requirements

Storage requirements are another important consideration when selecting a VM for your Kubernetes cluster. Kubernetes clusters require storage for both the operating system and the container images. When selecting a VM, make sure it has enough storage capacity to handle your workload.

3. Networking requirements

Networking requirements are also important when selecting a VM for your Kubernetes cluster. Kubernetes clusters require high network bandwidth to handle the communication between nodes and pods. When selecting a VM, make sure it has a high network bandwidth capacity.

4. Operating system compatibility

Make sure the VM you choose is compatible with your Kubernetes cluster. Azure offers several Kubernetes solutions, including Azure Kubernetes Service (AKS) and Azure Red Hat OpenShift (ARO), each with different operating system requirements.

5. Cost

Cost is also an important consideration when selecting a VM for your Kubernetes cluster. Consider the cost of the VM, as well as any additional costs for storage, networking, and other services.

Recommendations

When selecting a VM for your Kubernetes cluster, it’s important to choose one that meets your specific requirements. If you’re unsure which VM to choose, start with a General Purpose VM, which offers a good balance of CPU, memory, and network resources at an affordable cost. If your Kubernetes cluster requires high-performance computing, choose a Compute Optimized VM. If your Kubernetes cluster requires a high amount of memory, choose a Memory Optimized VM. If your Kubernetes cluster requires a large amount of storage, choose a Storage Optimized VM. Finally, if your Kubernetes cluster requires high-performance graphics processing, choose a GPU Optimized VM.

Keep in mind that you can always scale up or down your VM based on your Kubernetes cluster requirements. Azure also offers several tools and services, such as AKS Advisor, that can help you optimize your VM configuration for better performance and cost savings.

Conclusion

Choosing the right virtual machine (VM) for your workload is crucial for optimizing performance and cost efficiency. Microsoft Azure offers a range of VM types to meet different computing needs, including General Purpose, Compute Optimized, Memory Optimized, Storage Optimized, and GPU Optimized machines.

When selecting a VM, it’s important to consider your specific requirements, such as memory, CPU, storage, and networking needs, as well as operating system compatibility and cost. For Kubernetes clusters, in addition to the above factors, high network bandwidth is also a critical requirement.

Based on your specific workload needs, you can select the appropriate VM type, scale up or down as needed, and optimize your configuration for better performance and cost savings. Azure offers several tools and services to help you do this, such as AKS Advisor for Kubernetes clusters.

In summary, choosing the right VM for your workload is essential for achieving optimal performance and cost efficiency on Microsoft Azure. With careful consideration of your requirements and the available VM types, you can select the best VM for your workload and achieve the best possible outcomes.

Requirements

• Docker (https://docs.docker.com/get-docker/)

Get and run Redis

1
docker run -it -p 6379:6379 --rm --name my-redis redis

That’s it!

Note: If you want to run something more customized, I recommend looking into the Redis documentation.

Redis client

I didn’t have the opportunity to work with Redis before, so when I looked at the CLI client, the commands were completely new to me. If you are looking for an easy way to view the data. I recommend QRedis.

Installation

1
sudo pip3 install qredis

Connecting

1
qredis -p 6379

Ah! Much better.

I started looking around in my parents’ house, it’s a big house with a lot of space, enough to keep things that nobody needs anymore, so I went to the garage, and I found this old screen:

I used to use this old screen, but the support was broken, so there was no way to keep it straight.

I also thought I had a Raspberry Pi so that I could build some kind of video game. Here is my old Raspberry Pi 1:

I decided to create a little game on the raspberry pi involving my niece in the process, I felt like I wanted to teach her that anybody can be an engineer and create stuff.

We dedicated some time to building our own game. I wanted to start with something simple, so the following code for the pong game was a good start: github.com/Wireframe-Magazine/Code-the-Classics/blob/master/boing-master/boing.py

We ended up making many changes to the game, and my niece even wanted to change the bars for 2D warriors:

It turns out the Raspberry Pi 1 was super slow, even with overclocking. I was not surprised. When I bought it, it was a revolution but not anymore. The Raspberry was struggling a bit to run this simple game, but we had a lot of fun just doing the game, so I didn’t care much.

When she left, I knew I had two options:

• Stop the adventure here
• Build this pong machine and find two remotes for two players

I am not going to lie; I was as excited as her to finish it. I started looking around at home, and I found just one old PS1 controller and a PS-USB adapter, but the controller was broken :(

My next finding was the item that made me change course and build a driving arcade instead of the pong machine:

It’s an old driving controller for PlayStation 1. I also found this old stool that I decided was going to be the machine body:

I knew that building this kind of machine would require more computational power so I had to buy the latest Raspberry Pi 4 to finish this project, setting up the controls was a nightmare, but once I was done, I got a few games on Retropie and set up the Kids mode on it:

After some wooden and painting work, the machine was ready to use. Here are some pictures with the kids playing on it:

I regret not taking more photos of the machine to show how everything fit, cables, connections, etc. The final result was tidy and the only cable getting out of the device was the power cable.

The only item I had to buy was the Raspberry PI. Everything else was in my parent’s house, which is crazy. It took me about three or four days to finish everything.

Thank you for reading!