In our previous post, we described four Mac screens on Quest Pro and how we eliminated shimmer in the configuration we tested. Since then, VRDesktopUltra has moved closer to being a workspace rather than just an image-streaming demo: with a saved layout, a place of your own in VR, and a regular Mac app.

The main result of this stage is five independent screens, all visible in the headset at the same time. Behind that milestone are changes that make everyday startup and returning to VR less cumbersome.

The fifth screen is a real external monitor

Our test setup now runs all of these together:

• three virtual ultrawide monitors at 5760 × 1200 each;
• the Mac's built-in Retina display, captured at 4112 × 2658;
• an external 1920 × 1080 monitor.

We connected the external monitor while the Mac app was running. The server detected it and began streaming it as a separate source, without restarting the server or the USB session.

The first check also taught us something important: receiving a fifth stream is not the same as showing a fifth screen to a person. The data reached Quest, but the monitor appeared far outside the configured workspace. We fixed its initial placement: a new screen now appears above the last available monitor, taking that monitor's position, rotation, and size into account.

After the fix, we checked not only logs and checksums, but also the actual scene in the headset. The external screen is visible and works alongside the other four. We then restarted the installed Mac app and confirmed that all five sources and the saved layout were restored.

This is a result from one specific Quest Pro setup, not a promise of any number of monitors under any workload.

The most satisfying result from our recent VRDesktopUltra experiments was a short message after another headset check: “Hooray, the shimmer is gone!”

Behind it were several iterations of image transport, a different way of presenting virtual monitors, and measurements that made us reconsider some early decisions. Our test setup now runs three virtual ultrawide Mac screens alongside the main Retina display, together in a single VR scene on Quest Pro.

VRDesktopUltra grew out of WireDeskVR, our earlier virtual workspace project built with Unreal Engine 5. The goal remains the same — comfortable Mac screens in VR — but the new implementation replaces UE5 with our own Rust and OpenXR stack.

Here is where the system stands as of October 21, 2026: the architecture we chose, why we chose it, and the boundary between a working experiment and an everyday tool.

We need a workspace, not just a large video

Displaying a computer image in a headset is only the beginning. When watching a movie, a small loss of detail might go unnoticed. With a code editor, terminal, or pixel artwork in front of you, the requirements are different: thin lines should not shimmer when you move your head, small text should remain legible, and scrolling should feel responsive.

We also want more than one rectangle attached to our gaze. We want a workspace: arrange screens around us, adjust their distance, size, and curvature, and move between them.

That leads to the first important decision: the Mac sends monitor content; Quest builds and presents the VR scene locally. Head tracking, controllers, and screen geometry are handled on the headset. Turning your head does not require waiting for the computer to render and transmit a new image of the entire virtual world. The last received desktop image stays in place while its next update is still in transit.

The core logic is written in Rust. On the Mac, we use ScreenCaptureKit, Metal, and hardware VideoToolbox; on Quest, OpenXR, OpenGL ES, and hardware decoding. Our protocol runs over a USB NCM network connection. The current path is wired, with no Wi-Fi fallback.

KnowledgeQuery

kqs is a Git-native platform for managing knowledge and documentation. Documentation, tasks, data specifications, and the links between them are plain Markdown files in a Git repository — and a single kqs binary adds search, an AI assistant, task tracking, and traceability from requirements to code. No servers, no external databases, no vendor lock.

Why

Obsidian and any markdown editor are great for reading and editing notes. But beyond a single folder, problems start: no sync between repositories, no cross-repo search, documentation lives apart from code, and nobody knows whether requirements are actually covered by implementation.

kqs does not replace Obsidian — it complements it with what's missing: multi-repo sync, full-text and semantic search, an AI assistant in the CLI, tasks in Git, and deep traceability of the requirement → design → code chain.

How It Started

I read a lot of technical documentation. SDDs (Specification Driven Development documents), RFCs, specs — I have to digest large volumes constantly. Regular reading hits a speed limit: you waste time on saccades (eye jumps between words) and regressions (backtracking across lines).

At some point I remembered RSVP — Rapid Serial Visual Presentation. Words appear one at a time in a fixed screen position, driven by words-per-minute. Your eyes don't move — they just stare at the center and absorb words.

SpeedReaderRust

RSVP (Rapid Serial Visual Presentation) speed reading overlay. Opens a file and displays words one by one in the center of the screen. Key feature: center letter highlighting (ORP — Optimal Recognition Point) for faster word recognition.

Features

• Pause and jump to editor at exact reading position (Space)
• Configurable speed (WPM) and editor command
• Drag overlay with mouse
• Works with any editor: Zed, VS Code, Vim, Helix
• Open source (MIT)

Install

cargo install speed-reader

Or from source: cargo install --path gui

Usage in Zed

1. Global Task

Add a task to ~/.config/zed/tasks.json so speed-reader is available from any project:

[
  {
    "label": "SpeedReader: Read current file",
    "command": "speed-reader",
    "args": ["$ZED_FILE"],
    "tags": ["speed-reader"],
    "hide": "on_success"
  }
]

If the file already has tasks, just append this object to the array. "hide": "on_success" closes the terminal panel when the overlay closes.

2. Run

Cmd+Shift+P → type SpeedReader → select the task.

3. Hotkey (recommended)

Add a keybinding in ~/.config/zed/keybindings.json:

{
  "context": "Editor",
  "bindings": {
    "cmd-shift-r": ["task::Spawn", { "task_name": "SpeedReader: Read current file" }]
  }
}

Now Cmd+Shift+R launches RSVP reading from any buffer.

4. Editor Config (not just Zed)

By default speed-reader opens the editor at file:line:col. Configure in ~/.config/speed-reader/config.json:

{
  "editor_cmd": "code",
  "wpm": 300
}

Supports Zed, VS Code, Vim, Helix, and any editor with editor file:line:col CLI syntax.

TradeTerminal

A universal trading terminal for Bybit and Binance with CLI interface and client-server architecture, designed to minimize exchange latency. Built in Rust, the project provides a powerful toolkit for professional cryptocurrency trading.

Key Features

Trading Operations

• Order Placement: Market and Limit orders with fast execution
• Risk Management: Automatic position sizing based on USDT risk with exchange fee consideration
• Take Profit: Exit position setup as percentage from entry
• Trailing Stop: Flexible trailing stop system with support for:
  • Absolute price values and callback in dollars
  • Percentages from current price
  • Ratios for activation based on distance to Stop Loss
• Auto-Stop (AS): Smart exit on active markets
  • Click on price to copy it for quick input
  • Trigger activates when price or percentage is reached
  • Liquidity timer (2 sec) - closes position if trading stops
  • Perfect for profit taking on volatile moves
• Hedge Mode: Support for simultaneous Long/Short positions on the same instrument

RFIDReader

A Rust-based firmware application for reading and writing ST25TB RFID chips using the LilyGO T-Embed CC1101 device (ESP32-S3 with PN532 NFC module). This tool is particularly useful for interacting with RFID chips commonly found in printer cartridges and other industrial applications.

Key Features

The firmware provides comprehensive functionality for working with ST25TB chips through an intuitive touchscreen interface:

• Complete Chip Operations: Read entire chip contents (up to 256 blocks) and write modified data back
• Data Management: Export chip dumps via serial connection and import hex data for writing
• Interactive Interface: TFT display with rotary encoder navigation for easy menu interaction
• Audio Feedback: Audible beep confirmation for successful read/write operations
• Built-in Hex Editor: Modify chip data directly on the device before writing

Technology Stack

The project leverages modern embedded Rust development:

• Hardware: ESP32-S3 dual-core processor (240MHz) with ST7789V TFT display (170x320)
• NFC Controller: PN532 module via I2C communication
• Language: Rust (no_std bare metal programming)
• Framework: esp-hal hardware abstraction layer
• Protocol: ISO14443-B standard

The Problem

Every figure skating trainer knows these situations:

• You're on the ice, an athlete finishes their skate, and you need to stop the music after the performance. To give specific recommendations to the athlete, not to search for the player to pause it.
• What if you need to work on a specific element? You can start from a specific second and repeat the element and composition to achieve athlete mastery.
• Or you need to instantly return to the beginning? Very often the start is missed or not heard, and you have to return to the beginning of the composition.
• Or queue up the next athlete's music while the current one finishes? Prepare the next accompaniment for the next skate. In advance. So the athlete doesn't wait while you find the right composition in your player.
• What if you have a training process for "hands" choreography. And the accompaniment needs to be constantly found in the playlist. The queue will always have the accompaniment designated for hands choreography. Now you don't need to search for it every time after other athletes' skates. It will be next in your queue.

Traditional music players just weren't designed for this workflow.

From Unemployment to Discovery

I'm currently between jobs, vibing with code non-stop. And here's what I noticed: developers won't become extinct, they just don't need managers anymore. Developers ARE the managers now, with AI cats as their assistants.

With this thought, I went googling for solutions, because ideas always come to me last in the world and someone has probably already started a project and is making money from it.

The Path to Discovery

I stumbled upon auto-claude. A system that allows you to run agents separately in each worktree so they can solve tasks independently from each other. And of course, they preserve context.

I thought: "This is it! Exactly what I need!"

But I decided not to stop there. I went to Grok and said: "Scan the market, are there better solutions?" And guess what? It actually found some!

Problem

Often thoughts come faster than actions, and once again I fell into this situation where I added files to the stage but forgot to commit, and immediately ran off to jump through commits using git reset and git checkout.

For those who are not yet familiar with this problem, git reflog won't help here. If you haven't done git add ., your last hope to recover files is only through:

• Time Machine
• Local changes if you're working in a JetBrains IDE
• Or if you're good at recovering data from an SSD
• etc

Net Monitor Rust

NetRS is a network monitoring tool written in Rust that shows real-time network connections using the Ratatui library for terminal-based user interface. The application lets users monitor active network connections and view connection details including local and remote addresses, protocols, and connection states. Users can filter connections based on different criteria. The tool uses the system's networking features to collect connection information and displays it in an interactive, easy-to-use terminal interface. This tool helps system administrators, network engineers, and developers quickly check network activity on their systems directly from the command line.

This offers a more efficient way to monitor outgoing connections from a specific process.

I developed this tool for the WireDeskVR project to check agent connection status.

It can also be used for other purposes. For example, to find where a specific process connects on your computer.

Example Usage

sudo netmonrs /Applications/Zed.app/Contents/MacOS/zed

We need sudo access for lsof.

How it looks

Controls

• Tab - Switch focus between active connections and history
• Up / k - Move up in list
• Down / j - Move down in list
• PageUp / Ctrl+u - Page up
• PageDown / Ctrl+d - Page down
• q - Quit application

Objective

The initial stage and first step involve creating screen capture functionality for the agent, enabling it to broadcast, transcode, and transmit the captured content over a network.

Project

First, we create a dedicated project to explore the possibilities. Since this is an agent, it will run on macOS as a service or background daemon. Its primary task is straightforward—since it has no UI, we will implement it using Swift and Swift Package Manager as a standard executable.

Source Code

The core function of the agent initializes a socket for each detected display. We will observe how this functionality performs.

    func start() async throws {
        let sender = NetworkSender(host: "127.0.0.1", port: port); sender.start(); self.network = sender

        let content = try await SCShareableContent.current
        guard let display = content.displays.first(where: { $0.displayID == displayID }) else { return }

        let encoder = VideoEncoder(width: display.width, height: display.height, bitrate: 20_000_000)
        encoder.delegate = self; self.encoder = encoder

        let captureSession = ScreenCapture(displayID: displayID)
        captureSession.delegate = self
        self.capture = captureSession

        try await captureSession.start()
    }

Introduction

JetBrains YouTrack provides a powerful workflow engine that allows teams to automate and enforce project management policies using JavaScript. Unlike simple status transitions, YouTrack workflows can validate data, enforce business rules, and ensure consistency across your development process.

This article explores practical workflow automation through three real-world examples: validating test environment deployments, enforcing time tracking, and ensuring task estimation. These patterns are applicable to any team using YouTrack for agile development.

Why Workflow Automation?

Manual enforcement of project policies is error-prone and time-consuming. Common problems include:

• Incomplete time tracking: Developers forget to log spent time
• Missing estimations: Tasks move to "In Progress" without effort estimates
• Incorrect state transitions: Test builds deployed to production accidentally
• Inconsistent processes: Different team members follow different workflows

YouTrack's JavaScript-based workflows solve these problems by:

1. Preventing invalid transitions: Block state changes that violate policies
2. Enforcing required fields: Ensure critical data is captured
3. Validating business logic: Implement complex rules programmatically
4. Providing immediate feedback: Show clear error messages to users

Introduction

Managing localization files in iOS and macOS projects can become challenging as your app grows. When you add new strings to your base language file, keeping all translation files synchronized becomes tedious and error-prone. This article explores syncLproj, a Rust-based CLI tool designed to automate this synchronization process.

The Localization Problem

In iOS/macOS development, localization uses .strings files with a simple key-value format:

/* User interface strings */
"welcome_message" = "Welcome to our app!";
"login_button" = "Log In";
"signup_button" = "Sign Up";

When managing multiple languages, several problems emerge:

• Missing keys: New keys added to the base language don't automatically appear in translations
• Key order inconsistency: Different files have keys in different orders, making diffs harder to review
• Orphaned keys: Removed keys remain in translation files
• Manual work: Copy-pasting keys across dozens of files is time-consuming and error-prone

Traditional approaches involve manual editing or Xcode's built-in tools, which lack automation capabilities for CI/CD pipelines.

Introduction

This post explores the journey of building a terminal user interface (TUI) file manager in Rust. We'll examine Blaze Ultra, a practical CLI application that demonstrates key concepts in Rust development including terminal manipulation, event handling, and modern UI frameworks.

Why Rust for CLI Applications?

Rust has become increasingly popular for CLI tools due to several compelling advantages:

• Performance: Near C-level performance with zero-cost abstractions
• Safety: Memory safety without garbage collection prevents common bugs
• Ergonomics: Modern tooling with Cargo makes distribution trivial
• Cross-platform: Write once, compile anywhere with minimal platform-specific code
• Rich Ecosystem: Mature crates like clap, ratatui, and tokio accelerate development

Popular examples include ripgrep, fd, bat, and exa - all demonstrating Rust's capability to create fast, reliable command-line tools.

Project Description

WireDeskVR is a VR application that allows users to work with the WireDesk interface in virtual reality. The project implements a full virtual workspace environment with the ability to interact with UI elements via gestures and controllers. At this stage, it is a proof of concept to see how technically feasible it is. Competitors and ideas circulating in the community have also been studied. There will be a lot of research and we will encounter many first-time challenges.

Technologies

• Swift
• ARKit / RealityKit
• Metal
• Core Motion
• SceneKit
• UnrealEngine
• Android
• Oculus/Meta Quest

Features

• 3D interaction with the interface
• Support for various controller types
• Integration with the WireDesk API
• Performance optimization for VR devices

I have had a long-standing dream since childhood to create a virtual desktop for working with a computer. Today, technology not only allows us to achieve that but also to implement it with artificial intelligence. This project is more of a test to understand how capable technology is today in helping achieve this goal. The main idea of the first stage is to create NoLatency, transmitting video data from MacBook screens to Oculus Quest. In subsequent stages, we plan to introduce a plugin system and our own binary protocol to unify data from other applications and other users in VR.

Roadmap

1. Establish a stable connection and configure workstations.
2. Examine and analyze the free space on the computer's resources, as well as on the Opulus system. If resources allow managing screens, also consider creating a gaming zone within virtual reality to let users relieve emotional load by dividing something in VR.
3. Screen sharing and the social component did not take off and are not popular among competitors, so we omit this part. At the third stage, we immediately move to beta testing of the binary protocol for transmitting custom data from macOS and the host to VR headsets.
4. Systematize and standardize the protocol, and also start developing a marketplace for users.
5. Capture the world and find someone to sell it to.