DEV Community: Asher-ish

Building a Dual-Publishing Blog Platform for Zenn and dev.to

Asher-ish — Fri, 20 Mar 2026 15:54:19 +0000

This very article was published to two platforms at once — Zenn (in Japanese) and dev.to (the English version you're reading now) — from a single git push. Here's how I built the system that makes it possible.

Zenn is a popular tech blogging platform in Japan, similar to dev.to. I write articles in Japanese on Zenn and want the same content available in English on dev.to. But translating by hand is tedious, and the two platforms have subtly different Markdown dialects. So I automated the entire workflow. The source code is public:

asherish / blog

Zenn (JP) + dev.to (EN) dual-publishing blog with bidirectional translation sync

blog

Zenn (Japanese) + dev.to (English) dual-publishing blog platform.

Write articles in either language, bidirectionally sync translations with Claude Code /sync skill, and publish to both platforms.

Architecture

Write/edit article (JP or EN)
  ↓
/sync                    ← Claude Code translates and syncs bidirectionally
  ↓
articles/ + articles_en/ updated
  ↓
Preview both             ← Zenn (JP) localhost:18000 + dev.to (EN) localhost:13000
  ↓
git push
  ├→ Zenn auto-publish   (GitHub integration)
  └→ GitHub Actions      → validate → dev.to API publishes EN version

Setup

Prerequisites

Node.js 20+
Claude Code (for translation sync)
dev.to API key

Installation

npm install

Environment Variables

Create a .env file in the project root:

DEV_TO_API_KEY=...

GitHub Secrets

Add DEV_TO_API_KEY to your repository's GitHub Secrets for the GitHub Actions workflow.

Zenn Integration

Link this repository (asherish/blog, main branch) at Zenn deploy settings.

Usage

1. Create a new article

npm run new:article

2. Write the article

Edit the generated file in…

View on GitHub

Goals

Write in Japanese, get the English version auto-generated (and vice versa)
Convert Markdown syntax differences between Zenn and dev.to automatically
Publish to both platforms with a single git push
Preview both platforms locally

How It Works (The Big Picture)

Write an article (Japanese or English)
  ↓
/sync                    ← Claude Code translates + converts syntax + updates state
  ↓
articles/ + articles_en/ are updated
  ↓
Local preview            ← Zenn (localhost:18000) + dev.to (localhost:13000)
  ↓
git push
  ├→ Zenn auto-publish   (GitHub integration)
  └→ GitHub Actions      → Validate → Publish to dev.to via API

That's it: write, /sync, git push — published on two platforms.

Directory Structure

blog/
├── .claude/
│   ├── settings.json               # Auto-allow permissions for sync scripts
│   └── skills/
│       ├── zenn-syntax.md          # Zenn syntax reference
│       ├── devto-syntax.md         # dev.to syntax reference
│       └── sync/SKILL.md           # Bidirectional translation sync skill (/sync)
├── .github/workflows/
│   ├── publish-to-devto.yml        # dev.to auto-publish workflow
│   └── scheduled-publish.yml       # Scheduled publish cron workflow
├── articles/                       # Zenn articles (Japanese)
├── articles_en/                    # dev.to articles (English, translated)
├── books/                          # Zenn books
├── scripts/
│   ├── sync-detect.ts              # Change detection script (JSON output)
│   ├── sync-apply.ts               # Post-translation processing script
│   ├── sync/
│   │   ├── convert.ts              # Zenn ↔ dev.to syntax conversion
│   │   └── state.ts                # Sync state persistence
│   ├── publish-to-devto.ts         # dev.to publishing script
│   ├── process-scheduled.ts        # Scheduled publish processor
│   ├── validate-published.ts       # Pre-publish validation
│   └── preview-devto.ts            # dev.to preview server
├── .sync-state.json                # Per-article hash tracking
├── .devto-mapping.json             # dev.to article ID mapping
├── package.json
└── tsconfig.json

Bidirectional Translation Sync

The heart of this repo is the /sync command — a custom Claude Code skill that detects changes, translates articles, converts syntax, and updates state in one shot.

Change Detection

Every article is SHA-256 hashed and tracked in .sync-state.json. When you run /sync, the script compares current hashes against stored ones to figure out what changed:

State	Action
Only Japanese exists	Full translation JP → EN
Only English exists	Full translation EN → JP
Japanese was modified	Diff sync JP → EN
English was modified	Diff sync EN → JP
Both were modified	Conflict → resolve with `--prefer ja` or `--prefer en`
No changes	Skip

The Three-Step Pipeline

Step 1 — Detect (sync-detect.ts): Compares hashes and outputs which articles need translation (and in which direction) as JSON.

Step 2 — Translate (Claude Code): Reads the source article and writes the translated body to the target file. Code blocks, inline code, URLs, and command names are preserved as-is. Platform-specific syntax (:::message, $$, etc.) is also left untouched — syntax conversion happens in the next step.

Step 3 — Post-process (sync-apply.ts): Converts Zenn ↔ dev.to syntax via regex, generates the target-side frontmatter, and updates .sync-state.json.

Separating translation from syntax conversion keeps the translation prompt clean and lets regex handle the mechanical conversions reliably.

Usage

/sync                    # Sync all articles
/sync my-article         # Sync a specific article only
/sync --prefer ja        # Resolve conflicts — Japanese wins
/sync --prefer en        # Resolve conflicts — English wins

You can also run change detection alone:

npm run sync                    # All articles (JSON output)
npm run sync -- my-article      # Single article

Why Claude Code Instead of the Claude API?

The first version called the Claude API directly from TypeScript (sync.ts + api.ts). I switched to a Claude Code skill because:

No API key needed — Claude Code handles the translation itself; no ANTHROPIC_API_KEY in .env
Better quality — full article context in every translation, no prompt-length workarounds
Interactive debugging — review and fix translations on the spot, re-run with /sync
Parallel execution — Claude Code's background agents can translate multiple articles at once

Zenn ↔ dev.to Syntax Conversion

Both platforms use Markdown, but each has its own extensions. The converter handles these automatically — here's what it translates:

Feature	Zenn	dev.to
Info box	`:::message ... :::`	`> ℹ️ ...`
Warning box	`:::message alert ... :::`	`> ⚠️ ...`
Accordion	`:::details Title ... :::`	`{% details Title %} ... {% enddetails %}`
Block math	`$$ ... $$`	`{% katex %} ... {% endkatex %}`
Inline math	$...$	`{% katex inline %}...{% endkatex %}`
Code filename	`js:app.js``	`js` `+` // app.js` comment
Image width	`![alt](url =500x)`	`<img src="url" alt="alt" width="500">`
Footnotes	`[^1]: text`	`Notes: 1. text` section

All conversions are regex-based and work in both directions.

Frontmatter

Frontmatter differs too:

# Zenn
---
title: "記事タイトル"
emoji: "🐙"
type: "tech"
topics: ["topic1", "topic2"]
published: true
---

# dev.to
---
title: "Article Title"
published: true
tags: topic1, topic2
canonical_url: https://zenn.dev/asherish/articles/slug
---

A canonical_url pointing to the Zenn article is added automatically to avoid SEO duplicate-content issues. dev.to limits tags to 4, so only the first 4 Zenn topics are carried over.

Local Preview

Both platforms can be previewed locally:

npm run preview        # Zenn  → localhost:18000
npm run preview:devto  # dev.to → localhost:13000

The Zenn preview uses the official Zenn CLI. The dev.to preview is a lightweight HTTP server that renders articles_en/ Markdown with marked in a dev.to-like layout. Ports are offset by 10,000 from the usual 8000/3000 to avoid clashing with Next.js or Express dev servers.

Publishing with GitHub Actions

Zenn has no publish API — it polls your linked GitHub repo and imports articles/ automatically. Just git push and you're done.

dev.to has a REST API, so a GitHub Actions workflow handles it. It triggers on pushes to main that touch articles_en/:

on:
  push:
    branches: [main]
    paths: ['articles_en/**']

The workflow runs three steps:

Validate — Checks that published status matches between the JP and EN articles. A mismatch (one side true, the other false) would cause an accidental publish, so the workflow stops.
Publish — Calls POST /api/articles (first time) or PUT /api/articles/{id} (updates) on the dev.to API.
Save mapping — Commits the slug → dev.to article ID mapping to .devto-mapping.json so future runs can update the same article.

Scheduled Publishing

Want to publish on a specific date? Add scheduled_publish_date to both articles' frontmatter:

published: false
scheduled_publish_date: "2026-03-15"

A GitHub Actions cron runs daily at 00:05 JST. When the date arrives, it flips published to true, publishes the EN version via the dev.to API, and commits. Zenn picks up the change automatically.

scheduled-publish.yml (daily cron at 00:05 JST)
  ↓
process-scheduled.ts
  ├─ scheduled date ≤ today → set published: true
  ↓
publish-to-devto.ts
  ├─ publish English version via dev.to API
  ↓
commit & push
  └→ Zenn auto-publish (GitHub integration)

Check scheduling status locally with npm run schedule:check.

Why Not Zenn's Built-in Scheduling?

Zenn supports scheduling via published: true + published_at, but it requires published: true upfront. dev.to has no equivalent — published: true goes live immediately. Using Zenn's native scheduling would leave the two platforms out of sync, which trips the validation script. Instead, a custom scheduled_publish_date field keeps both sides in sync, and the cron publishes them simultaneously.

Claude Code Skills

The repo ships three Claude Code skill files:

Skill	Trigger	What it does
`sync`	`/sync` command	Bidirectional translation sync
`zenn-syntax`	Editing `articles/`	Loads Zenn syntax reference
`devto-syntax`	Editing `articles_en/`	Loads dev.to syntax reference

The syntax skills auto-load when you're editing in the corresponding directory, so Claude Code always knows which platform's Markdown to use. Permissions for script execution and file I/O are pre-approved in .claude/settings.json so background agents can translate in parallel without blocking on approval prompts.

Wrapping Up

My daily workflow now looks like this:

Write an article in Japanese in articles/
Run /sync to generate the English version
Preview with npm run preview / npm run preview:devto
git push — published on both Zenn and dev.to

Since Claude Code handles the translation directly, there's no API key to manage, and I can review and tweak translations on the spot. The diff sync mechanism means manual edits to translations survive the next sync. The result: I just write in Japanese and everything else is automated.

Installing NVIDIA Drivers Without CUDA

Asher-ish — Thu, 19 Mar 2026 16:03:33 +0000

Motivation

In AI model development environments, different projects and programs often require different versions of CUDA. For example, one project might need CUDA 11.8 while another requires CUDA 12.2. In such situations, installing and managing multiple CUDA versions directly on your local environment can lead to version conflicts.

Furthermore, when sharing development environments across a team, configurations that depend on the local environment make it difficult to ensure reproducibility. If each team member uses a different CUDA version, errors due to environmental differences become more likely.

Therefore, CUDA should be installed inside containers rather than on the local environment. By using containers, you can flexibly switch between the CUDA versions needed for each project without affecting the local environment. Additionally, sharing containers across the team enables a unified development environment.

This article aims to install only the NVIDIA driver on the local environment without installing CUDA.

Check the Version to Install

First, use the following site to check which version to install. By selecting your GPU product name and OS, you can find the appropriate NVIDIA driver version.

https://www.nvidia.com/ja-jp/drivers/

If you don't know your GPU model, you can check it with the following command:

sudo lshw -C display

How to Install the NVIDIA Driver Without CUDA

There are two main methods for installing the NVIDIA driver:

NVIDIA repository + cuda-drivers: Installs from NVIDIA's repository. Provides the latest drivers. The repository configuration can be reused if you install CUDA in the future. See Reference: Installation via the NVIDIA Repository for details.
Ubuntu repository + nvidia-driver-XXX: Installs drivers that have been tested and packaged by Ubuntu. You can check the recommended version with the ubuntu-drivers devices command, and the procedure is simpler.

This article explains the installation steps using the latter approach with the Ubuntu repository.

About Secure Boot

Secure Boot is a BIOS/UEFI security feature that only allows trusted, signed software to run during PC startup. If the NVIDIA driver's kernel module is not signed, this feature can prevent it from working. Therefore, to install the NVIDIA driver successfully, you need to either disable Secure Boot or register a MOK (Machine-Owner Key).

Option 1: Disable Secure Boot in BIOS

Immediately after powering on, repeatedly press the designated key to enter BIOS.
- DELL: F2 or DEL
- HP: ESC (then F10) or F2
- ASUS: DEL or F2
- Acer: F2 or DEL
Navigate to the Secure Boot settings screen. It is usually found under one of the following tabs:
- Boot
- Security
- Authentication
- Advanced
Disable Secure Boot.
- Set the "Secure Boot" option to "Disabled".
- If you cannot disable it, try changing the Secure Boot mode to "Custom Mode" first.
- In some cases, changing OS Type from "Windows UEFI mode" to "Other OS" is sufficient.
Configure "CSM" or "Legacy Boot" if necessary.
- On some systems, you may need to enable "CSM (Compatibility Support Module)" or "Legacy Boot" when disabling Secure Boot.
- To do this, set "CSM" or "Legacy Boot" to "Enabled" in the "Boot" tab.
Save changes and restart.
- After making changes, select "Save and Exit".
- On some BIOS, you can save and exit with the F10 key.
Verify that Secure Boot has been disabled.

   dmesg | grep Secure

Option 2: Register a MOK (Machine-Owner Key)

If you want to use the NVIDIA driver with Secure Boot enabled, you will be prompted to register a MOK during driver installation. Set a password when prompted during installation. After rebooting, the "Enroll MOK" menu will appear — enter the password you set to register the MOK.

⚠️ If you do not select "Enroll MOK" during reboot, Ubuntu will still boot, but the NVIDIA driver will not work correctly.

Disable nouveau

When installing NVIDIA drivers on a Linux system, an open-source driver called nouveau may be enabled by default. When nouveau is active, it occupies the GPU, which can interfere with the installation and operation of the NVIDIA driver. Therefore, to install the NVIDIA driver correctly, you need to disable nouveau to release the GPU.

Check if nouveau is enabled. You can paste the output into ChatGPT to verify whether it is enabled.

   lsmod | grep -i nouveau

Run sudo vi /etc/modprobe.d/blacklist-nvidia-nouveau.conf and add the following configuration to disable nouveau.

   blacklist nouveau
   options nouveau modset=0

Apply the configuration to disable nouveau.

   sudo update-initramfs -u

⚠️ Do not reboot. If you reboot without installing the NVIDIA driver, you may experience display issues.

Install the NVIDIA Driver

Finally, it's time to install the NVIDIA driver. Once this is complete, you've achieved the goal.

Remove any previously installed NVIDIA drivers or CUDA.

   sudo apt purge "nvidia-*"
   sudo apt autoremove
   sudo apt autoclean

Update the package list to the latest state.

   sudo apt update
   sudo apt upgrade -y

Check the version to install on the NVIDIA official driver page as described in Check the Version to Install earlier in this article.

ℹ️ To determine which version to install, you need to know your GPU model. You can check it with sudo lshw -C display.

As a side note, you can also check the list of compatible drivers and recommended versions using the ubuntu-drivers devices command. Running this command will often show the open-source version of the driver recommended on the page above marked as recommended. In fact, NVIDIA's developer page also recommends using the open-source kernel modules for Turing and later architectures (Turing, Ampere, Ada Lovelace, Hopper), and starting from the R560 driver series, the open-source version is the default installation target (reference). However, even the recommended version may not always work correctly.

Install the appropriate version of the driver (the following command is for version 535).

   sudo apt install -y nvidia-driver-535

Verify that the driver was installed successfully. If GPU information is displayed, the installation was successful.

   nvidia-smi

Notes

The procedures in this article are intended for Ubuntu environments.
NVIDIA's official documentation describes different installation methods. https://docs.nvidia.com/datacenter/tesla/driver-installation-guide/#ubuntu

Reference: Installation via the NVIDIA Repository

This article introduced the method using Ubuntu's repository, but you can also install drivers using NVIDIA's repository. Here, we organize the information from the CUDA Installation Guide as a reference.

Installation Instructions Are in the CUDA Installation Guide

The NVIDIA driver installation instructions are documented in the CUDA Installation Guide. This is a good page to come back to when you get stuck. However, since this page is designed to support CUDA installation, you'll need to read selectively to install only the NVIDIA driver.

https://docs.nvidia.com/cuda/cuda-installation-guide-linux/index.html

Section 3. Pre-installation Actions describes what needs to be done before installation. In particular, we'll cover the following subsections:

3.4. Choose an Installation Method
3.5. Download the NVIDIA CUDA Toolkit

ℹ️ The CUDA Quick Start Guide also describes CUDA installation procedures, but it only covers full CUDA installation and does not describe how to install the NVIDIA driver without CUDA.

https://docs.nvidia.com/cuda/cuda-quick-start-guide/index.html#ubuntu

Two Types: distribution-specific package and runfile

Section 3.4. Choose an Installation Method of the CUDA Installation Guide explains that there are two installation methods.

Let's look at what the installation guide says:

The CUDA Toolkit can be installed using either of two different installation mechanisms: distribution-specific packages (RPM and Deb packages), or a distribution-independent package (runfile packages).

The distribution-independent package has the advantage of working across a wider set of Linux distributions, but does not update the distribution's native package management system. The distribution-specific packages interface with the distribution's native package management system. It is recommended to use the distribution-specific packages, where possible.

As described above, there are two installation methods: distribution-specific packages (deb/rpm packages) and distribution-independent packages (runfile). The guide recommends the former.

Note that the runfile also has --driver and --toolkit flags documented, which may allow installing only the driver or only the toolkit separately. However, the following sections assume distribution-specific packages (deb) as recommended by the guide.

Downloading the NVIDIA Driver

Section 3.5. Download the NVIDIA CUDA Toolkit of the CUDA Installation Guide explains the following:

The NVIDIA CUDA Toolkit is available at https://developer.nvidia.com/cuda-downloads.

Choose the platform you are using and download the NVIDIA CUDA Toolkit.

The CUDA Toolkit contains the tools needed to create, build and run a CUDA application as well as libraries, header files, and other resources.

When you open the link above and select your environment, the installation methods for both CUDA and the NVIDIA driver are displayed. However, if you select the runfile option, the NVIDIA driver installation method is not shown. You need to select deb.

https://developer.nvidia.com/cuda-downloads

For example, if you select Linux, x86_64, Ubuntu 22.04, deb (network), the following is shown as the NVIDIA driver installation step:

sudo apt-get install -y cuda-drivers

local and network Methods

The deb package installation method is further divided into two types: local and network.

Section 4.8 of the CUDA Installation Guide describes the installation method for Ubuntu.

https://docs.nvidia.com/cuda/cuda-installation-guide-linux/index.html#ubuntu

sudo apt-get install linux-headers-$(uname -r)
sudo apt-key del 7fa2af80

# Choose an installation method: local repo or network repo.

# local
sudo dpkg -i cuda-repo-<distro>_<version>_<architecture>.deb
sudo cp /var/cuda-repo-<distro>-X-Y-local/cuda-*-keyring.gpg /usr/share/keyrings/
wget https://developer.download.nvidia.com/compute/cuda/repos/<distro>/x86_64/cuda-<distro>.pin
sudo mv cuda-<distro>.pin /etc/apt/preferences.d/cuda-repository-pin-600

# network
wget https://developer.download.nvidia.com/compute/cuda/repos/{% katex inline %}distro/{% endkatex %}arch/cuda-keyring_1.1-1_all.deb
sudo dpkg -i cuda-keyring_1.1-1_all.deb
sudo apt-get install cuda-drivers-<branch>

The developer site also displays the necessary commands when you select the OS and installer type. The specific commands vary depending on the CUDA version, so please select your environment on the following page to check:

https://developer.nvidia.com/cuda-downloads

For example, if you select Linux, x86_64, Ubuntu 22.04, deb (local), the repository setup commands are displayed. After setting up the repository, you can install only the NVIDIA driver without CUDA by installing cuda-drivers instead of cuda-toolkit.

# cuda-toolkit をインストールすると CUDA がインストールされてしまう
# sudo apt-get -y install cuda-toolkit-<version>

# cuda-drivers をインストールすると CUDA なしで NVIDIA ドライバーのみをインストールできる
sudo apt-get -y install cuda-drivers

Fixing Ubuntu Desktop Freezing at the Login Screen

Asher-ish — Wed, 11 Mar 2026 15:58:14 +0000

When installing Ubuntu Desktop, the system may freeze at login if the default graphics settings are incompatible with the hardware. This article explains how to resolve this issue.

What Is Ubuntu Desktop?

Ubuntu comes in two varieties: "Ubuntu Server" for server use, and "Ubuntu Desktop" for personal and office use.

Ubuntu Server is designed primarily for server operations and is intended to be operated via command line (CUI). It does not include a GUI.

Ubuntu Desktop is designed for personal and office use, with an intuitive GUI included as standard.

Why It Freezes

Normally, the kernel initializes the framebuffer (the display area using the GPU) during boot and sets the optimal resolution. However, when this operation fails, the following problems can occur:

The screen goes black
The boot process freezes
The login screen doesn't appear

The main cause of this failure is that the open-source driver is not compatible with the installed GPU.

Note: Open-source drivers are the drivers installed by default on Ubuntu, such as nouveau (for NVIDIA), amdgpu (for AMD), and modesetting (a generic driver).

For example, the open-source driver may fail to initialize the framebuffer for the latest NVIDIA GPUs, causing a freeze at login. BIOS/UEFI settings or specific hardware configurations (e.g., multi-GPU environments) can also be the cause.

Installing a proprietary driver is required for NVIDIA GPUs to set the optimal resolution, but you can't install the proprietary driver without being able to log in first.

How to Log In

Using nomodeset disables automatic initialization and runs in low-resolution mode, allowing you to use the GUI environment. Note that this is a temporary fix — you'll need to install the proprietary driver as a permanent solution.

Display the GRUB menu at boot (press the Shift key repeatedly)
Press e before selecting "Ubuntu"
Change quiet splash to quiet splash nomodeset
Boot with Ctrl + X

This starts the GUI in low-resolution mode, allowing you to log in.

Install the Proprietary Driver

After logging in, install the proprietary driver to display the screen at the proper resolution. The following example is for NVIDIA GPUs.

Check the recommended driver:

ubuntu-drivers devices

Install the recommended driver:

sudo apt install nvidia-driver-xxx

The officially provided driver from the repository is recommended, but if needed, download and install the latest driver from the NVIDIA official website.

Remove nomodeset

After installing the proprietary driver, remove nomodeset from the GRUB configuration.

Edit the GRUB configuration (e.g., using nano):

sudo nano /etc/default/grub

Find the following line:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nomodeset"

Change it to:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

Save the settings and update GRUB:

sudo update-grub
sudo reboot

After rebooting, verify that the proprietary driver is working correctly with the following command:

nvidia-smi

Note: For AMD or Intel GPUs

Even with AMD or Intel GPUs, similar issues can occur due to open-source drivers.

For AMD: Check if the amdgpu driver is applied, and install the proprietary driver if necessary.
For Intel: Check if the i915 driver is applied.

If the specific problem is not resolved, refer to official documentation or support forums.

Publish Pipeline Test Article

Asher-ish — Tue, 10 Mar 2026 08:28:29 +0000

This is a test article. It will be deleted after confirming the publish pipeline works.