DEV Community: loach

Publishing .NET Packages to NuGet.org with an API Key

loach — Thu, 10 Sep 2026 12:00:55 +0000

Publishing a .NET library manually is fine once or twice, but it becomes tedious when releases are frequent or automated through CI/CD.

The standard solution is to push packages to NuGet.org with dotnet nuget push and an API key.

This article covers the basic flow and the most important security consideration: never commit the API key into the repository.

Prerequisites

You need:

a .NET project
a generated .nupkg file
a NuGet.org account

For example, your package might look like this:

./bin/Release/YourPackage.1.0.0.nupkg

Create a NuGet API key

When creating a new key, configure at least:

a recognizable key name
an expiration period
the Push scope
an optional package pattern if you want to restrict which packages the key can publish

The generated key should be treated like a password.

Do not put it in source code, scripts committed to Git, or Markdown examples containing a real value.

Push a package

The basic command is:

dotnet nuget push <PACKAGE_FILE> \
  --api-key <YOUR_API_KEY> \
  --source https://api.nuget.org/v3/index.json

For example:

dotnet nuget push ./bin/Release/YourPackage.1.0.0.nupkg \
  --api-key YOUR_API_KEY_HERE \
  --source https://api.nuget.org/v3/index.json

A useful option for CI is --skip-duplicate:

dotnet nuget push ./bin/Release/*.nupkg \
  --api-key "$NUGET_API_KEY" \
  --source https://api.nuget.org/v3/index.json \
  --skip-duplicate

This avoids failing a rerun just because the same package version was already published.

Store the key in GitHub Actions Secrets

For GitHub Actions, store the key as a repository secret, for example:

NUGET_API_KEY

Then reference it from the workflow:

- name: Publish package
  env:
    NUGET_API_KEY: ${{ secrets.NUGET_API_KEY }}
  run: |
    dotnet nuget push ./bin/Release/*.nupkg \
      --api-key "$NUGET_API_KEY" \
      --source https://api.nuget.org/v3/index.json \
      --skip-duplicate

The API key stays outside the repository while still being available to the CI job.

Prefer narrow credentials

If the publishing key only needs to release one package family, restrict it to that package pattern where possible.

A narrow key reduces the impact if it is ever exposed.

The same principle applies to other CI credentials: give automation only the permissions it actually needs.

Closing thoughts

The mechanics of publishing a NuGet package are simple. The part worth designing carefully is credential handling.

A solid release flow usually looks like this:

build
  ↓
pack
  ↓
secret injected by CI
  ↓
dotnet nuget push

Keeping the credential out of the repository makes the process both automatable and reasonably safe.

PureSharp: Bringing Functional Safety to C# with Roslyn Analyzers

loach — Thu, 10 Sep 2026 11:55:44 +0000

C# is a very flexible language, but that flexibility also makes it easy for side effects and mutable state to spread through a codebase.

I built PureSharp to bring a few functional-programming ideas into everyday C# development and make them enforceable at compile time.

GitHub: https://github.com/mao2009/PureSharp

NuGet: https://www.nuget.org/packages/loach.PureSharp

What PureSharp tries to enforce

PureSharp focuses on three ideas:

Purity: methods explicitly marked as pure should not perform side effects.
Immutability: local variables can opt into a "do not reassign" convention.
Safer control flow: fluent conditional expressions should terminate explicitly.

The key point is that these rules are not just documentation. Roslyn analyzers report violations while you write and build the code.

Declaring a pure method

A method can be marked with [PureMethod]:

using PureSharp.Core;

public class Calculator
{
    [PureMethod]
    public int Add(int a, int b)
    {
        return a + b;
    }
}

Inside such a method, PureSharp can report operations that violate the declared purity contract, such as accessing mutable static state, calling methods that are not known to be pure, or performing I/O.

The goal is not to claim that every C# method can be proven mathematically pure. The goal is more practical: if a developer explicitly says "this method should be pure," the analyzer should help keep it that way.

Opt-in immutability for local variables

C# does not have a general-purpose const-style feature for local variables initialized at runtime.

PureSharp uses a naming convention: local variables beginning with _ are treated as non-reassignable.

public void ProcessData()
{
    int _result = CalculateValue();

    // Reported by the analyzer:
    // _result = 100;
}

This turns a simple convention into something the compiler can enforce.

The analyzer can also require immediate initialization and can suggest the immutable convention for locals that are never reassigned.

Fluent conditional expressions

PureSharp also provides Fluent.If, which makes it possible to use conditional branching as an expression:

int status = Fluent.If(score >= 80, () => 1)
    .ElseIf(score >= 60, () => 2)
    .Else(0);

The analyzer checks that a fluent chain is properly terminated with .Else().

The motivation is simple: if the construct is intended to produce a value, all paths should be explicit.

Why Roslyn analyzers?

These rules could be described in a style guide, but a style guide is only useful when someone remembers to enforce it.

Roslyn analyzers make the feedback immediate:

violations appear in the IDE
dotnet build can fail on violations
CI does not need a separate custom validator
rules stay close to the normal C# development workflow

That makes them especially useful for conventions that are easy to understand but tedious to police in code review.

Installation

Install the package from NuGet:

dotnet add package loach.PureSharp

After that, the analyzer participates in normal builds.

What I learned from building it

The interesting part of a tool like PureSharp is not the syntax of a single diagnostic. It is deciding where static analysis can give useful guarantees without pretending to understand more than it actually can.

C# remains an imperative, object-oriented language with many escape hatches. PureSharp is therefore intentionally opt-in: developers declare the rules they want, and the analyzer checks those declarations as far as static analysis reasonably allows.

That balance is what makes Roslyn analyzers attractive for this kind of developer tooling.

PureSharp is open source here:

https://github.com/mao2009/PureSharp

Using Ctrl+Enter to Submit in OpenCode and Enter for New Lines

loach — Thu, 10 Sep 2026 11:55:33 +0000

Another OpenCode behavior I wanted to change was message submission.

By default, pressing Enter submits the current prompt. If you are used to chat tools where Enter inserts a new line and Ctrl + Enter sends, this makes accidental submissions easy.

My preferred setup is:

Enter: insert a new line
Ctrl + Enter: submit the prompt

OpenCode configuration

Edit your OpenCode configuration file and update the keybindings:

{
  "keybinds": {
    "app_exit": "ctrl+d,<leader>q",
    "input_submit": "ctrl+return",
    "input_newline": "shift+return,return,alt+return,ctrl+j"
  }
}

This tells OpenCode to treat normal Enter-style keys as new lines and reserve Ctrl + Enter for submission.

The terminal may need configuration too

There is one important detail: some terminals do not send a distinct key sequence for Ctrl + Enter by default.

In that case, OpenCode cannot distinguish it from plain Enter.

For Windows Terminal, you can define a custom sequence:

"actions": [
  {
    "command": {
      "action": "sendInput",
      "input": "\u001b[13;5u"
    },
    "id": "User.sendInput.CtrlEnterCustom"
  }
]

Then bind Ctrl + Enter to that action in the terminal settings.

The exact terminal configuration can vary, but the principle is the same: the terminal must send a distinguishable sequence before OpenCode can bind it separately.

Why this improves the workflow

Long prompts often contain code blocks, lists, and multiple paragraphs.

Making Enter safe for editing removes the pressure to finish the whole prompt on one line and reduces accidental sends.

It also makes OpenCode behave more like many chat and editor-oriented interfaces.

Closing thoughts

Keybindings are a small detail, but AI coding tools are used interactively for long periods. Small interaction problems become surprisingly expensive when repeated all day.

For me, separating newline and submit made OpenCode much more comfortable to use.

Preventing Accidental OpenCode Exits with Ctrl+C

loach — Thu, 10 Sep 2026 11:50:23 +0000

OpenCode is powerful, but one default behavior kept getting in my way: pressing Ctrl + C could close the application itself.

If you spend a lot of time in terminals, Ctrl + C is muscle memory. You press it to interrupt a command, stop a long-running process, or simply because your hands move before you think.

Losing the whole OpenCode session because of that is frustrating.

The fix is simple: move the application exit action to a different keybinding.

Change the exit keybinding

Open your OpenCode configuration file and customize the keybindings.

For example:

{
  "keybinds": {
    "app_exit": "ctrl+d,<leader>q"
  }
}

With this configuration, Ctrl + C is no longer the application-exit shortcut.

You can then use Ctrl + D or the leader-based shortcut to exit intentionally.

Why this small change matters

AI coding agents often stay open for long sessions with valuable context.

A keybinding that is common for interruption in terminal workflows should not unexpectedly destroy that session.

Separating "interrupt what is happening" from "close the entire application" makes the interface much harder to use incorrectly.

Closing thoughts

This is a tiny configuration change, but it removed one of the most annoying sources of accidental session loss for me.

If you use OpenCode inside a terminal and frequently hit Ctrl + C out of habit, remapping app_exit is worth doing early.

Setting Up Japanese Input on Fedora KDE with Fcitx5 and Mozc

loach — Thu, 10 Sep 2026 11:50:12 +0000

After moving to Fedora KDE, one of the first things I wanted to fix was Japanese input.

My goal was not only to install Mozc, but also to make the conversion keys feel closer to what I was used to on macOS:

Henkan enables the IME
Muhenkan disables the IME

This article documents the setup I used with Fcitx5 + Mozc.

Install Fcitx5 and Mozc

On Fedora, install the required packages with:

sudo dnf install -y fcitx5-mozc fcitx5-configtool

Enable Fcitx5 in KDE

Open KDE System Settings and go to the keyboard / virtual keyboard settings.

Select Fcitx 5, or the Fcitx 5 Wayland launcher depending on your environment, and apply the change.

After logging out and back in, Fcitx5 should start as your input method framework.

Add Mozc

Open the Fcitx5 configuration tool:

fcitx5-configtool

Add Mozc to the list of available input methods.

If the keyboard layout is detected incorrectly, verify that the underlying keyboard layout matches your physical keyboard before adjusting IME shortcuts. Otherwise, a shortcut problem can actually be a layout problem.

Mac-like conversion key behavior

For Japanese keyboards, the Henkan and Muhenkan keys are convenient dedicated switches.

I configured them so that:

Henkan activates Japanese input
Muhenkan returns to direct input

This avoids using a single toggle key and makes the current IME state more predictable.

That small change made Fedora much more comfortable for daily development because I no longer had to wonder whether the next keystroke would be interpreted as Japanese or ASCII.

Why I prefer explicit on/off keys

Toggle shortcuts are compact, but they depend on remembering the current state.

Separate on/off shortcuts are more deterministic:

Henkan   -> IME ON
Muhenkan -> IME OFF

For programming, this is especially useful because switching from Japanese prose back to symbols, identifiers, and shell commands happens constantly.

Closing thoughts

Fcitx5 + Mozc works well on Fedora KDE once the desktop integration and keyboard shortcuts are configured.

The installation itself is simple; the quality-of-life improvement comes from tuning the input method to your keyboard habits.

If you are moving from macOS or another environment where dedicated IME on/off keys are part of your muscle memory, mapping Henkan and Muhenkan explicitly is worth trying.

Keeping Translated OSS Documentation Fresh with an SSOT and CI

loach — Thu, 10 Sep 2026 11:11:01 +0000

Publishing an OSS project in multiple languages is useful, but translated documentation introduces a maintenance problem very quickly.

Typical failure modes are familiar:

the English README changes but the Japanese version does not
nobody is sure which version is authoritative
a translation gains content that never reaches the canonical document
developers or AI tools read an outdated translation as if it were current design documentation

I ran into this while expanding the English documentation for PSXRecompStudio.

GitHub: https://github.com/mao2009/PSXRecompStudio

My solution was to make the English documents the explicit canonical source / SSOT and add CI checks that detect stale translations.

Why translations need a source of truth

Suppose a repository has:

README.md
README.ja.md

If both files are treated as equally authoritative, every edit creates a coordination problem.

Instead, I use a simpler rule:

English is canonical. Translations are derived documents.

A translated document is still valuable for readers, but architectural and specification decisions ultimately refer back to the canonical file.

Store the relationship as data

The canonical-to-translation mapping is kept in JSON rather than hard-coded into the CI script.

For example:

{
  "version": 1,
  "pairs": [
    {
      "canonical": "README.md",
      "translation": "README.ja.md",
      "language": "ja",
      "canonicalMarker": "[English README (Canonical / SSOT)](README.md)"
    }
  ]
}

This describes which file is authoritative, which file is its translation, the language, and which canonical marker should appear in the translation.

As the documentation set grows, adding a new pair is a data change rather than a code change.

Make the canonical relationship visible to humans too

The translated document should clearly say that it is a translation and link back to the canonical source.

That helps in two ways:

readers know which file wins when there is disagreement
CI can verify that the relationship is still declared

This avoids a common documentation smell: two almost-identical files with no explicit indication of which one is authoritative.

Detect stale translations in CI

The next step is to make freshness machine-checkable.

A practical approach is to record which canonical revision a translation was last synchronized against. CI can then compare that information with the current canonical file.

Conceptually:

canonical changed
      ↓
translation metadata still points to old revision
      ↓
CI reports stale translation

The exact implementation can vary. The important part is that freshness becomes a build-time property instead of something maintainers have to remember manually.

Why this matters for AI-assisted development

Outdated translations are especially dangerous when repositories are consumed by AI coding agents.

A human may notice that a translated document looks old. An agent may simply treat the first relevant file it finds as the current specification.

By declaring one SSOT and checking synchronization automatically, the repository gives both humans and tools a clearer hierarchy of trust.

Treat documentation like code

The broader lesson is that documentation maintenance benefits from the same ideas we already use for source code:

define ownership
define the source of truth
represent relationships in machine-readable form
validate invariants in CI
fail visibly when derived artifacts become stale

Translations are derived artifacts, even when humans maintain them manually.

Once I started treating them that way, the maintenance model became much clearer.

Closing thoughts

Multilingual OSS documentation is valuable, but duplicating information without an explicit authority model creates ambiguity.

Making one language canonical and validating translation freshness in CI gives the repository a predictable rule:

translations may lag temporarily, but they cannot silently pretend to be current.

That small distinction makes documentation easier to maintain and safer to consume.

Enforcing C# Architecture Rules at Compile Time with a Roslyn Analyzer

loach — Thu, 10 Sep 2026 11:01:55 +0000

When a C# project adopts layered architecture or Clean Architecture, we often define rules such as:

the Domain layer must not depend on the Application layer
the Domain layer must not call I/O APIs such as Console or File directly
interop entry points must stay inside a specific boundary

The problem is that rules written only in README files, ADRs, or design documents are still easy to violate.

A review can miss a dependency. A temporary shortcut can become permanent. Over time, the implementation slowly drifts away from the architecture described in the documentation.

To make these rules executable, I built ArchitectureAnalyzer, a Roslyn Analyzer that validates architecture rules during normal C# compilation.

GitHub: https://github.com/mao2009/ArchitectureAnalyzer

Project site: https://mao2009.github.io/ArchitectureAnalyzer/

Define the architecture as data

ArchitectureAnalyzer keeps project-specific rules outside the analyzer itself. They live in an architecture.contract.json file.

For example:

{
  "layers": [
    {
      "name": "Domain",
      "namespaceRoots": ["MyApp.Domain"]
    },
    {
      "name": "Application",
      "namespaceRoots": ["MyApp.Application"]
    }
  ],
  "forbiddenDependencies": [
    {
      "from": "Domain",
      "to": "Application",
      "reason": "Domain must not depend on the outer Application layer."
    }
  ]
}

With this contract, any type below MyApp.Domain is classified as Domain and any type below MyApp.Application as Application.

If Domain references Application, the build fails with a Roslyn diagnostic such as:

error AARC002: 'MyApp.Domain.Order' (Domain) must not depend on
'MyApp.Application.OrderService' (Application):
Domain must not depend on the outer Application layer.

This means the compiler catches the violation before a human reviewer has to.

Forbidden APIs

Architecture rules are not limited to layer-to-layer dependencies.

You can also block specific APIs from a layer. For example, to keep console I/O out of Domain:

{
  "forbiddenApis": [
    {
      "layer": "Domain",
      "type": "System.Console",
      "reason": "Console I/O must be abstracted behind an Infrastructure adapter."
    }
  ]
}

Then code like this can be rejected at compile time:

namespace MyApp.Domain;

public class Order
{
    public void Print()
    {
        Console.WriteLine("Order");
    }
}

Why JSON instead of hard-coded rules?

Different projects use different architectures. Hard-coding Domain, Application, and Infrastructure into the analyzer would make it project-specific.

Instead, ArchitectureAnalyzer follows a simple split:

The analyzer implements the mechanism. The project defines the policy.

That also means architecture rules can be reviewed and versioned in Git like source code.

Attribute-based layer declarations

Version 0.1.0 also supports explicit layer markers using attributes.

A contract can map attributes to layers:

{
  "layerDeclaration": {
    "required": true,
    "markerAttributes": [
      {
        "attributeFqn": "MyApp.Architecture.DomainAttribute",
        "layer": "Domain"
      },
      {
        "attributeFqn": "MyApp.Architecture.ApplicationAttribute",
        "layer": "Application"
      }
    ],
    "validateNamespaceConsistency": true,
    "markerNamespace": "MyApp.Architecture"
  }
}

Then a type can declare its architectural role directly:

using MyApp.Architecture;

namespace MyApp.Domain;

[Domain]
public class Order
{
}

When namespace and attribute declarations disagree, the analyzer can report the mismatch.

This is useful when you want architecture to be visible both from project structure and directly in code.

Why a Roslyn Analyzer?

The same validation could be implemented as a custom CLI or CI script, but a Roslyn Analyzer has an important advantage: it becomes part of the normal development loop.

You get diagnostics in the IDE, during dotnet build, and in CI without teaching developers a separate command.

Install the package and provide the contract as an additional file:

<ItemGroup>
  <PackageReference Include="loach.ArchitectureAnalyzer"
                    Version="0.1.0"
                    PrivateAssets="all" />
  <AdditionalFiles Include="architecture.contract.json" />
</ItemGroup>

Then the normal build is enough:

dotnet build

The same command naturally becomes a CI architecture gate.

What it does not do

ArchitectureAnalyzer does not decide whether your architecture is good.

It only answers a narrower question:

Does the implementation still obey the architecture rules this project explicitly defined?

Reflection, dynamic, generated code that is excluded from analysis, and some indirect access patterns are outside the guarantees of a normal static analyzer.

That limitation is intentional. The tool is designed to prevent architecture drift, not to replace architectural design.

Closing thoughts

Architecture documentation is valuable, but documentation alone cannot stop code from drifting away from it.

By moving the rules into a machine-readable contract and validating them during compilation, architecture becomes something the build can enforce rather than something reviewers merely have to remember.

ArchitectureAnalyzer is open source, and the project is available here:

https://github.com/mao2009/ArchitectureAnalyzer

I Built a Python Script to Cross-Post X Lists to Bluesky — x2b

loach — Thu, 10 Sep 2026 10:56:55 +0000

Introduction

Using both X and Bluesky means that useful information often ends up split across two timelines.

In my case, I keep a curated X list for official accounts and news in a specific area, while I increasingly use Bluesky as my main social feed.

So I built x2b, a Python script that automatically cross-posts new posts from an X list to Bluesky.

https://github.com/mao2009/x2b

At first, I thought the job would be simple: fetch posts from X and send them to Bluesky.

Once I started running it regularly, however, a lot of edge cases appeared:

avoiding duplicate posts
staying within Bluesky's text limit
not breaking emoji or combined Unicode characters
handling oversized OGP images
retrying only temporary failures
testing safely without publishing anything

This article is about how a small automation script gradually turned into something that can be operated more reliably.

What x2b Does

The basic pipeline looks like this:

X List
  ↓
Fetch posts
  ↓
Check whether each post was already processed
  ↓
Build Bluesky text
  ↓
Fetch OGP metadata and thumbnail
  ↓
Publish to Bluesky
  ↓
Persist processed post IDs

After setup, the normal command is simply:

.venv/bin/python x2b.py

Configuration is kept in .env:

BSKY_HANDLE=your-handle.bsky.social
BSKY_APP_PASSWORD=xxxx-xxxx-xxxx-xxxx
X_LIST_ID=1234567890

Preventing Duplicate Posts

A scheduled cross-poster needs to know which X posts it has already handled.

x2b stores processed X post IDs in seen.json.

The important part is not only what gets stored, but when it gets stored.

def mark_seen(seen, post_id):
    seen.add(post_id)
    save_seen(seen)

A post is normally marked as seen only after a successful Bluesky post.

If it were marked before publishing, a temporary Bluesky outage could cause the post to be skipped forever on the next run.

On the other hand, known permanent failures can safely be marked as seen because replaying the exact same payload would produce the same result.

So x2b does not treat every failure the same way.

300 Characters Is Not Just `len()`

Bluesky limits post text by grapheme count.

That matters because Python's len() does not always match what a user perceives as a single character. Emoji and combining sequences can consist of multiple code points while still appearing as one character.

x2b uses the grapheme package when available:

def count_graphemes(text):
    if grapheme:
        return grapheme.length(text)
    return len(text)

Truncation also happens on grapheme boundaries:

def truncate_text_to_graphemes(text, max_graphemes):
    if max_graphemes <= 0:
        return ""

    if count_graphemes(text) <= max_graphemes:
        return text

    keep = max_graphemes - 1

    if grapheme:
        return grapheme.slice(text, 0, keep) + "…"

    return text[:keep] + "…"

This reduces the risk of cutting an emoji or combined character in the middle.

x2b also has to account for the prefix added before the original X text, such as the author name and handle.

So the available body length is calculated from the final Bluesky limit:

available_length = (
    BSKY_MAX_TEXT_GRAPHEMES
    - prefix_length
    - TEXT_LENGTH_MARGIN
)

This is safer than blindly truncating the X text to a fixed number of characters.

OGP Failure Should Not Kill the Post

When an X post contains a URL, x2b tries to build a Bluesky external embed using OGP metadata.

But OGP data is external and unreliable by nature.

A remote page may have:

an unreachable image
a timeout
an unsupported or broken image
a thumbnail larger than Bluesky allows

The important design decision is that a thumbnail failure should not prevent the text itself from being posted.

If the thumbnail is too large, x2b tries to resize it with Pillow. If that still fails, the post continues without the thumbnail.

Download thumbnail
  ↓
Within limit → use it
  ↓
Too large → try resizing
  ↓
Still unusable → continue without thumbnail

This turned out to be essential for unattended operation.

Classifying API Errors

An HTTP 500 response and an invalid payload are both failures, but they should not be handled the same way.

x2b classifies errors into three groups:

class PermanentError(Exception):
    pass

class TransientError(Exception):
    pass

class UnknownError(Exception):
    pass

PermanentError

Used for known failures that will not be fixed by resending the same payload, for example:

text length violations
payload-too-large errors
known validation failures

These are not retried.

TransientError

Used for failures that may succeed later:

HTTP 429
HTTP 5xx
timeouts
network failures

Only these are retried, using exponential backoff:

delay = RETRY_BASE_DELAY * (2 ** attempt)
time.sleep(delay)

UnknownError

This category is intentionally conservative.

If an error cannot be classified, x2b does not silently assume it is permanent.

Unknown failures are not retried immediately and are not marked as seen, so they become visible again on the next run and can be investigated.

For automation, continuing to run is important, but silently losing work is worse.

Dry-Run Through the Real Pipeline

Testing an auto-posting script is uncomfortable if every test publishes something to a real social account.

So x2b supports:

.venv/bin/python x2b.py --dry-run

In dry-run mode, it does not:

publish to Bluesky
upload blobs
modify seen.json

But it still executes the same pipeline for:

fetching X posts
filtering
building Bluesky text
grapheme validation
OGP fetching
thumbnail validation and resizing
error classification
retry paths

The key idea is that dry-run disables only the side effects.

It is not just an early return such as:

if dry_run:
    return

Instead, it runs as much of the production path as possible and reports what would have been posted.

This makes it much safer to check what a cron job will do before enabling real publishing.

Testing Without External Services

x2b also includes pytest-based tests:

pytest

The test suite does not require a real Bluesky account, X API access, or external network access.

The most important cases are the ones that could cause operational problems:

no side effects in dry-run mode
retries only for transient errors
no retry loops for permanent errors
unknown failures are not silently marked as seen
oversized images are handled safely
generated text remains within the grapheme limit

External APIs are exactly where a small script benefits from clearly separated boundaries.

What I Learned

Fetching a post from X and sending it to Bluesky is not particularly difficult by itself.

The difficult part is everything around it:

What if fetching fails?
What if the same post appears again?
What if the text is too long?
What if it contains complex emoji?
What if the OGP image is huge?
What if Bluesky is temporarily unavailable?
What if the error is unknown?
How do I test it without publishing?

Handling these cases one by one is what turned x2b from a one-off script into something closer to an operational tool.

Conclusion

x2b started as a small personal utility for using X and Bluesky together.

As it evolved, it ended up touching several concerns that are common to API-based automation in general: idempotency, Unicode handling, retries, external media, error classification, and side-effect isolation.

If you are building a small Python automation tool of your own, I hope some of these design choices are useful.

The source code is available on GitHub:

https://github.com/mao2009/x2b

DEV Community: loach

Publishing .NET Packages to NuGet.org with an API Key

Prerequisites

Create a NuGet API key

Push a package

Store the key in GitHub Actions Secrets

Prefer narrow credentials

Closing thoughts

PureSharp: Bringing Functional Safety to C# with Roslyn Analyzers

What PureSharp tries to enforce

Declaring a pure method

Opt-in immutability for local variables

Fluent conditional expressions

Why Roslyn analyzers?

Installation

What I learned from building it

Using Ctrl+Enter to Submit in OpenCode and Enter for New Lines

OpenCode configuration

The terminal may need configuration too

Why this improves the workflow

Closing thoughts

Preventing Accidental OpenCode Exits with Ctrl+C

Change the exit keybinding

Why this small change matters

Closing thoughts

Setting Up Japanese Input on Fedora KDE with Fcitx5 and Mozc

Install Fcitx5 and Mozc

Enable Fcitx5 in KDE

Add Mozc

Mac-like conversion key behavior

Why I prefer explicit on/off keys

Closing thoughts

Keeping Translated OSS Documentation Fresh with an SSOT and CI

Why translations need a source of truth

Store the relationship as data

Make the canonical relationship visible to humans too

Detect stale translations in CI

Why this matters for AI-assisted development

Treat documentation like code

Closing thoughts

Enforcing C# Architecture Rules at Compile Time with a Roslyn Analyzer

Define the architecture as data

Forbidden APIs

Why JSON instead of hard-coded rules?

Attribute-based layer declarations

Why a Roslyn Analyzer?

What it does not do

Closing thoughts

I Built a Python Script to Cross-Post X Lists to Bluesky — x2b

Introduction

What x2b Does

Preventing Duplicate Posts

300 Characters Is Not Just len()

OGP Failure Should Not Kill the Post

Classifying API Errors

PermanentError

TransientError

UnknownError

Dry-Run Through the Real Pipeline

Testing Without External Services

What I Learned

Conclusion

300 Characters Is Not Just `len()`