DEV Community: qingwancong

A board-by-board method for building an 87 87 white cat bead pattern

qingwancong — Tue, 28 Jul 2026 15:56:33 +0000

PDF page 2: the artwork reference for the subject and color balance. It is not a photograph of a finished fuse bead piece.

PDF page 1: the complete numbered placement map. Use this page for exact bead positions and 29 × 29 board boundaries.

A mostly white bead pattern looks forgiving until you start placing it. The silhouette is easy to recognize, but three pale colors can collapse into one under warm room light. The mistakes are rarely dramatic; they are usually a row of White placed where Toasted Marshmallow should have carried the shadow.

This white cat and camellia pattern is 87×87 cells. It spans nine 29×29 square boards, uses 16 colors, and contains 3,155 beads. The printable pack is three pages: a full view, a numbered placement map, and a material key. Here is the workflow I would use before touching the first peg.

Sort by code, not by color name

The four largest groups are:

White: 1,782 beads
Toasted Marshmallow: 735
Tomato: 152
Tan: 115

White and Toasted Marshmallow account for almost four fifths of the project. Put them in separate opaque trays and label each tray with both the symbol from the PDF and the color code. Do not rely on visual memory after sunset; pale beads change surprisingly much under yellow light.

The material list includes an 8% allowance. White needs two bags at that margin, while each of the other major colors fits into one. I still keep a small “unknown” cup beside the board. If a bead rolls away and I cannot identify it immediately, it goes there instead of being guessed back into the pattern.

Place the anchors before the white field

Do not begin by filling the largest empty-looking area. Start with the eyes, nose, ear edges, the red camellia, and the dark outline around the flower. These high-contrast landmarks make it obvious if the design has shifted by one column.

Once the anchors line up with the numbered map, fill the pale regions outward from them. A wrong white bead inside a large white area is hard to notice. A wrong bead beside a black eye or red petal is obvious immediately.

Give the nine boards names

Label the 3×3 board layout A1–A3, B1–B3, and C1–C3. Add the same labels to a printed copy of the map. When one board is finished, check only two things before moving on:

Compare the final two rows on every shared edge.
Take one overhead photo in the same orientation as the PDF.

That photo is not for social media. It is a cheap checkpoint. If the next session begins two days later, it tells you which board was finished and whether it was accidentally rotated.

Treat the PDF pages as different tools

The full image is for checking the cat’s pose and balance. The numbered map is for placement. The material table is for shopping and refilling trays. Trying to use the attractive preview as the placement guide is what makes a large project feel harder than it is.

Small isolated cells deserve a manual check, especially around eyes, whisker roots, and flower edges. In a face, a cluster of three dark beads may carry more identity than a patch of fifty white beads.

Test the iron before the cat

Make a tiny test patch from spare beads. Start with a dry iron at medium heat, always use ironing paper, and move the heat evenly without pressing hard. If the center holes close immediately, reduce the temperature. For a nine-board piece, uneven heat at the outer edges is more dangerous than taking an extra minute.

Let the piece cool before lifting the paper slowly. If children are involved, the ironing step belongs to an adult.

The useful part of a large pattern is not the thumbnail. It is the combination of a readable map, board boundaries, exact counts, and a material key. The cat pattern library and its printable workflow are available in the Toonbead printable pattern library.

Designing a Roblox Player Companion Around Verifiable Information

qingwancong — Fri, 24 Jul 2026 16:12:59 +0000

Player guides for a fast-moving Roblox game have a reliability problem: a useful page can become wrong as soon as an update lands.

I built Merge a Black Hole Companion, an independent, unofficial resource for players of XAF Games’ Merge a Black Hole. The project is deliberately scoped around information a guide can stand behind: current game status, codes with a source/verification label, beginner and raid routes, update notes, and small planning tools.

The central product decision was to separate facts from assumptions.

A live status surface uses the Roblox Games and Votes APIs rather than copying a number into a page.
Codes and update notes are labelled by source and verification state instead of being presented as permanent truth.
The upgrade tools run privately in the browser. They help a player reason about ROI or compare two upgrade paths without requiring an account.
Pages avoid publishing unverified progression tables, exploits, or fake “community” activity.
Every important route keeps the unofficial fan-site disclaimer close to the relevant player action and points people back to official links.

That sounds conservative, but it is a better fit for a game whose meta changes often. A companion does not need to pretend it knows every number; it needs to make its evidence clear and help players make a decision with the information currently available.

The implementation is a small Cloudflare Worker app with server-rendered, indexable guides, JSON-LD, a sitemap, and an Open Graph asset. The hard part is not the framework. It is maintaining the boundary between a useful player tool and an authoritative-looking page with no evidence behind it.

The project is available at https://mergeablackhole.net/

Why I Built a Free Printable Bead Pattern Library Instead of a Gallery

qingwancong — Tue, 21 Jul 2026 16:58:23 +0000

A usable craft template needs more than a pretty preview

A lot of digital craft resources stop at the image. They give you a small preview, perhaps a color approximation, and then leave the difficult translation to the person at the pegboard.

That is fine for inspiration. It is not enough for a pattern someone can actually start, pause, and finish.

The update I have been working on is a free printable pattern library for Toonbead. Each entry begins as original Toonbead Studio artwork and becomes a deliberately constrained 29 × 29 fuse-bead project. The point is not to generate a large collection of decorative thumbnails. The point is to publish templates with the missing handoff details included.

Treat the placement map as the source of truth

A finished-looking pattern image is helpful for seeing the result, but it is a weak build instruction. Small colors merge, visual counting is error-prone, and two similar shades can become indistinguishable once the image is printed.

Each library pattern therefore has a complete numbered placement map. Every colored cell uses the same symbol that appears in the printable PDF and in the material key. That lets the builder work from an unambiguous grid rather than trying to reverse-engineer a scaled-down preview.

The initial collection deliberately stays at one 29 × 29 board. That constraint is part of the product design: it keeps the project approachable, makes the page honest about the required footprint, and avoids presenting a multi-board undertaking as a quick afternoon craft.

Material counts should be measured, not guessed

The next gap in many free patterns is materials. “Use some blue and brown beads” is enough for an illustration, but not enough for someone preparing a project.

A pattern page should tell the person how many beads it contains, which real palette it maps to, and how to retrieve an exact color-by-color list. In the library, each template includes counted materials and a downloadable CSV with a small spare-bead allowance. The printable PDF is a four-page build document rather than a single poster: overview, board map, symbol key, and material information have different jobs.

This also creates a useful standard for future templates. A visual has not earned the label “free pattern” merely because it exists as a picture. It should be possible to check the grid, gather materials, and begin without inventing missing instructions.

Keep the origin of the artwork clear

The library templates are original Toonbead Studio digital artwork. They are not user submissions, and they are not photographs of completed physical pieces. That disclosure matters because a source artwork and a real-world build are different kinds of evidence.

Showing the source alongside the bead pattern makes the transformation understandable without pretending that the physical craft has already been completed. It also protects the library from drifting into an opaque feed of generated images with no clue how they became buildable.

A template should be a starting point, not a dead end

A useful free template does not need an account, an AI generation, or a credit balance to load. But a builder may still want to change the colors, alter the size, inspect another bead brand, or export the result again.

That is why the final link in the workflow matters: opening a library template in the Maker transfers a real pattern into a local editing context. Loading, recoloring, resizing, and exporting the public template remain local operations. Optional AI remains separate and requires an explicit choice later; it is not silently attached to a free pattern.

The result is a smaller promise than “unlimited AI art,” but it is more useful to a maker. A person can select a recognisable project, see the exact work involved, print it, and still adapt it for their own materials.

The first free library templates, including owl, butterfly, dinosaur, hedgehog, watermelon, cupcake, ghost, flower, star, heart, crown, and alphabet patterns, are available in Toonbead’s Pattern Library: https://toonbead.com/patterns

Designing an Own-Voice Consent Flow for an API-First TTS Product

qingwancong — Sat, 18 Jul 2026 16:03:26 +0000

Voice cloning is a product-design problem before it is a model problem

It is tempting to describe voice cloning as a simple pipeline: collect a sample, create a voice, synthesize some text. That description is technically tidy, but it skips the part that determines whether the workflow deserves trust.

A voice is not merely another media asset. It is recognisable, personal, and easy to mistake for identity. So the interface has to make the boundaries of the system legible before anyone reaches the satisfying moment of pressing “generate.”

This is the set of constraints I use when designing an own-voice text-to-speech workflow.

Put consent inside the action, not after it

A generic terms checkbox at account creation is weak context. The meaningful decision happens when a person uploads or records the sample that will become a reusable voice.

The flow should therefore make three things concrete at that point:

The user is supplying their own voice, or has the authority to use it.
The sample is being used to create a synthetic voice for the requested purpose.
The user understands that generated speech is a new output, not a recording of something they said.

A short spoken verification phrase is useful here. It makes the experience more intentional than a silent upload, and it gives the product a natural place to explain the boundary. The goal is not to pretend that one phrase solves every identity question. It is to avoid an interface that treats the source voice as an anonymous file.

Separate the clone from the script

There are two different decisions in this category of tool. The first is whether a voice should be created. The second is what text that voice should say.

Keeping those stages separate improves both the user experience and the auditability of the product. A creation step can focus on sample quality, consent, and what is retained. A synthesis step can focus on pronunciation, pacing, language, and the actual script. Combining them in one opaque button makes it harder for a user to understand what happened and harder for the product team to set responsible defaults.

This distinction also makes errors easier to communicate. “We could not create the voice from this sample” and “we could not synthesize this script” are different failures. They should not collapse into a vague loading state or, worse, a plausible-looking fake result.

Make failure honest

Generative products are often judged by their happy path, but trust is built in the unhappy path. If the voice provider is unavailable, the product should return a clear temporary error. If a sample is too short or unusable, explain the next useful action. If the request cannot meet the product's consent rules, stop before generation.

That may feel less magical than silently substituting a generic voice, but it respects the user. A workflow that creates media should always make the origin of its output clear.

Privacy is part of the interface

People reasonably want to know what happens to a sample after upload. The answer cannot live only in a policy page. The UI should say, in plain language, what the current action sends, what is processed remotely, and what the user can expect to keep locally.

For small creator tools, clarity has another benefit: it prevents product scope from drifting toward “clone any voice” as a growth shortcut. A focused own-voice workflow is not just a safer message; it gives the interface a coherent job to do.

The best use case is often continuity

The most grounded use cases are practical: recording accessible narration in a familiar voice, drafting a corrected pickup after a recording session, or turning a prepared script into an audio version without losing the creator's identity.

Those are not reasons to remove safeguards. They are reasons to build safeguards into the workflow people actually use. When a tool asks for explicit intent, separates creation from synthesis, and reports failure honestly, it feels less like a trick and more like a piece of creator infrastructure.

I am applying these constraints in ClonaTuVoz, a Spanish-first own-voice cloning workspace: https://clonatuvoz.com/

ChatWorkSkin: a free Codex skin builder with automatic macOS and Windows installers

qingwancong — Fri, 17 Jul 2026 18:29:34 +0000

ChatWorkSkin is now focused on one simple workflow: build a free Codex skin in the browser, download a layered .dreamskin package, and install it with a guided macOS or Windows path.

The current homepage positions it around these keywords: free Codex skin, ChatGPT skin for coding, Codex desktop theme, AI coding workspace theme, and automatic Codex skin installer.

What the page offers

A local visual builder for layered .dreamskin themes
Built-in original artwork presets for Codex desktop customization
A live Codex-style preview before installing
Automatic installer guidance for macOS and Windows
A restore path that keeps native Codex controls and app files intact

The key point is that the skin is not a fake screenshot overlay. It is built for a coding workspace where the sidebar, project picker, tasks, menus, and composer still need to work normally.

Try it here: https://chatworkskin.com/

Correction: ChatWorkSkin 1.2.2 latest UI uses the new fine-tune panel

qingwancong — Fri, 17 Jul 2026 07:23:07 +0000

I reposted ChatWorkSkin with the correct latest UI screenshot.

The current 1.2.2 build is about layered .dreamskin themes and native Codex controls, but the visual detail that matters is the new fine-tune panel. It shows optional foreground layers, theme name, theme copy, colors, and focal point controls in the current studio UI.

This replaces the older workbench screenshot I shared earlier.

Current product page: https://chatworkskin.com/

Search-intent mirror: https://chatgptskin.org/

Keywords: Codex skin, Codex theme, Codex desktop customization, AI coding workspace theme, dreamskin theme package.

ChatWorkSkin update: a visual Codex skin studio with layered .dreamskin packages

qingwancong — Fri, 17 Jul 2026 06:45:38 +0000

I pushed a new visual update for ChatWorkSkin / Codex Dream Skin. The project is still focused on one narrow job: make a Codex desktop workspace feel personal without breaking native controls.

The latest version is no longer just a background swap. It is a small local studio for Codex skins:

choose original artwork
preview the Codex desktop theme before installing
export a verifiable layered .dreamskin package
install on macOS or Windows with a prefilled Codex task
keep the native sidebar, task list, input box, and restore path intact

The product angle is for people searching for a Codex skin, Codex theme, Codex desktop customization, or an AI coding workspace theme.

Try it here: https://chatworkskin.com/

Search-intent mirror: https://chatgptskin.org/

The implementation deliberately avoids modifying the official app package. The skin package and install flow stay reversible so the desktop workspace can be customized without turning the app into a fragile fork.

Building a free Codex skin installer without touching the official app package

qingwancong — Thu, 16 Jul 2026 16:12:58 +0000

I shipped a small tool for a very specific search intent: people looking for a ChatGPT skin or a free Codex skin for their coding workspace.

The result is Codex Dream Skin: a free Codex desktop theme with original artwork, a local preview, and an automatic installer for macOS and Windows.

The important constraint was not visual. It was safety.

A theme tool for a coding assistant should not ask users to replace the official app, patch an app bundle, edit app.asar, or take ownership of protected Windows app files. That kind of shortcut may work once, but it is brittle across updates and hard to restore.

So I built the workflow around a different rule:

Change the mood around Codex, but keep Codex itself intact.

What the site does

The public page is built around the keywords already used on the website: Codex skin, Codex theme, free Codex skin, automatic Codex skin installer, Codex desktop customization, ChatGPT coding theme, Codex macOS, and Codex Windows.

The flow is deliberately simple:

Choose one of the bundled original themes.
Preview the Codex skin in the browser.
Prepare the one-command installer.
Paste it into Terminal or PowerShell.
Restore the original Codex appearance whenever needed.

The tool also supports a custom-image path on macOS, so users can turn their own artwork into a Codex desktop theme.

Why native controls matter

A lot of visual demos can fake a full app with a screenshot. That is not useful for daily work.

Codex Dream Skin keeps the real Codex controls in place:

sidebar
task list
project picker
menus
composer
restore path

The theme changes the surrounding visual layer and background treatment. It does not replace the workflow with a static mockup.

The safety boundary

The installer is designed around a local loopback session and a reversible restore step.

It does not modify:

the official Codex app package
app.asar
WindowsApps files
code signatures
conversation data
login state
API keys or model-provider configuration

That last point matters. A skin should stay separate from credentials and model routing.

Why I also use ChatWorkSkin

The search-domain angle is chatgptskin.org: it is for people typing things like “ChatGPT skin”, “free ChatGPT skin”, or “free Codex skin”.

The brand/workspace angle is chatworkskin.com: it frames the same project as AI coding workspace theme and Codex desktop customization.

Same product, two discovery angles.

Current state

Free to use
No account required
macOS and Windows installers
Built-in original themes
Custom image workflow on macOS
One-command install
One-click restore
Unofficial, not affiliated with OpenAI

If you use Codex Desktop and want the workspace to feel less default, the early version is here:

https://chatgptskin.org/

Why Automatic Cleanup Made This Cat Bead Pattern Worse

qingwancong — Wed, 15 Jul 2026 18:12:42 +0000

Disclosure: This is a digital prototype. The physical bead piece has not been built yet.

I’m building Toonbead, a browser-based tool that turns photos into fuse-bead patterns. I wanted the first documented pet case to show the whole pipeline—including the part that failed.

Test setup

The source was a real gray-and-white cat photo. The workflow was:

One protected Pet Icon AI restyle to simplify the fur and isolate the subject.
Browser-local mapping to a 58 × 58 grid with up to 16 Perler Standard colors.
Local counting and export: 803 beads, four 29 × 29 boards, a six-page PDF, PNG, and materials CSV.

The AI step prepared the image. Grid size, palette matching, cleanup, counts, and exports stayed local and did not use another generation.

The useful failure

I tested the one-click stray-bead cleanup. It removed several small white regions around the face. To the algorithm they looked isolated; to a human they were part of the cat’s muzzle and identity.

So I reverted the cleanup and kept the pre-cleanup mapping as the downloadable result.

That changed the product rule: cleanup should be reversible and visually reviewed, especially around eyes, muzzle, and markings. A lower bead count is not automatically a better pattern.

What the case includes

original cat photo
AI-assisted Pet Icon artwork
transparent 58 × 58 bead-pattern PNG
counted materials CSV
six-page printable PDF with four board maps

Every asset is labeled as a digital prototype. There is no claim that a finished physical craft exists yet.

Inspect the full case and download the exact assets →

If you build creative tools, how would you handle this: keep cleanup off by default, or protect likely face regions before simplifying?

Today I added five AI styles and a printable PDF to Toonbead

qingwancong — Wed, 15 Jul 2026 12:27:33 +0000

Today I shipped a few updates to Toonbead, a small browser-based tool for turning photos into fuse bead patterns.

The first update is a real style library instead of one generic AI look:

Pet Icon for dogs and cats
Cute Portrait for selfies and gifts
Clean Cartoon for people and couples
Retro Pixel for icons and simple objects
Pop Poster for bold portraits
Custom, where you can write your own visual direction

The style choice is explicit. It guides the optional AI restyle, but it does not try to draw the final bead grid. After the AI step, the browser still handles the craft-specific work: mapping to real bead colors, changing the grid and palette, cleaning up small regions, and showing board and bead counts.

I also shipped a browser-local printable PDF export. It includes:

a project overview
numbered board-by-board pages
a color key
a counted materials list
concise making notes

That distinction matters to me. A nice image is not automatically a useful craft pattern. The export needs to help someone move from a screen to a bead table.

Uploading a photo still does not call the AI route. The user has to press Generate with AI. Verified accounts get three free AI generations, while local pattern edits and exports stay free and do not use credits. Toonbead does not persist the original or generated image.

I am building this for pet portraits, personal gifts, and beginner-friendly weekend projects. I am still learning how many colors and boards feel manageable for a first-time maker.

Try the updated Maker: https://toonbead.com/maker

See the style library: https://toonbead.com/styles

If you make fuse bead art or build creative tools, I would love to hear what makes a printable pattern genuinely useful.

I added an AI restyle step to a practical fuse bead pattern maker

qingwancong — Tue, 14 Jul 2026 07:09:58 +0000

I’m building Toonbead, a photo-to-fuse-bead-pattern tool for makers who want results they can actually build.

The new part is an AI restyle step between the uploaded photo and the bead grid.

Most photo-to-pixel tools treat the image as the final result. That is not enough for fuse beads. A craft pattern needs a readable subject, broad color regions, a manageable palette, and enough structure to assemble on a pegboard.

Toonbead now splits the workflow into two jobs:

Upload a portrait, pet photo, or gift photo.
Choose either a free browser-local Basic pattern or the recommended AI restyle.
With one explicit AI generation, find and reframe the subject, simplify it into cleaner color regions, and remove the background.
Map that AI mother image to real bead colors in the browser.
Adjust grid size, color count, palette, cleanup, and crafting mode locally.
Export a PNG pattern and materials CSV.

The API is deliberately narrow. Uploading a photo does not call the AI service. Changing the grid or colors does not call it again. One explicit Generate action makes one same-origin request, and the result is kept only in the active browser session so the local craft workflow can continue without another generation.

The account flow is also simple: verify an email to receive three free AI generations. After that, one-time generation packs are available; there is no subscription. The browser-local Basic path stays free, including local adjustments and exports.

The privacy boundary matters here. The uploaded photo is transiently proxied through the server to the image model during an explicit AI Generate, then the generated image is streamed back. Toonbead does not persist the original or generated image, image URLs, or prompts. That is different from claiming the photo never leaves the browser.

I’m still treating the AI output as a starting mother image, not a final artwork or a guaranteed likeness. The craft-specific work remains visible and editable: real bead colors, board counts, bead counts, cleanup, and a pattern a person can follow.

Try the current maker: https://toonbead.com/maker

If you build fuse bead art, pixel art, or photo-based craft projects, I’d love feedback on where this workflow can become more useful.

Building a Private AI Diary with On-Device Speech Transcription

qingwancong — Sat, 11 Jul 2026 13:48:13 +0000

Writing a diary sounds simple until the blank page appears at the end of a long day. The friction is usually not a lack of things to say. It is the work of opening a keyboard, choosing a structure, and turning a messy thought into a sentence before the thought disappears.

That is the problem behind You Speak, I Journal, a voice journal app for iPhone. The product starts with speech instead of a blank text field: speak naturally, let the phone transcribe the recording, and then ask AI to organize the transcript into a journal entry, todos, reminders, and moments worth remembering.

This article explains the design choices behind that workflow, especially the boundary between on-device speech transcription and server-side AI organization.

Two different jobs: transcription and organization

Speech recognition and journal organization are related, but they do not need to happen in the same place.

The first job is transcription. The app needs to turn a person's voice into text while they are recording. Keeping this step on the device has practical benefits:

the app can provide immediate feedback while recording;
the raw audio does not need to become a long-lived server object;
the product can explain its privacy model more clearly;
a local transcript can remain available if the network is unavailable later.

The second job is organization. A transcript may contain several topics at once: a meeting decision, a grocery item, a worry about tomorrow, and a small moment from the day. A language model is useful for separating those threads into a readable entry and a short list of concrete actions.

The important design decision is to send only the current transcript needed for that organization step. The app does not need to upload a complete diary archive every time a new note is processed.

A local-first data boundary

"Private" is too vague to be a useful technical claim unless the boundary is specific. For this app, the boundary is:

The original recording is used for the current transcription session and is not saved by default.
The current transcript can be sent to the backend when the user asks for AI organization.
The backend performs authentication, AI processing, subscription checks, and necessary usage accounting.
The confirmed journal entry is stored on the iPhone by default.

This is not the same as claiming that no text ever leaves the device. The AI organization step needs the current transcript, so the product should say that plainly. Precise privacy language is less exciting than a sweeping promise, but it is much easier for users to understand and verify.

Why the output should not become a chatbot

It is tempting to make an AI diary sound expressive by adding a strong assistant personality. In practice, that can make a personal record feel artificial. A diary transformation should stay close to what the person actually said.

The organization step therefore has a narrow job:

correct obvious transcription errors;
remove repetition and filler;
preserve the writer's meaning and tone;
separate reflection from concrete actions;
generate a short title and summary;
avoid inventing facts, diagnoses, or emotional conclusions.

For example, a spoken note such as "I need to send the revised screenshots to Sam before Friday, and I was relieved that the review finally moved forward" contains two different kinds of information. The first is an actionable todo. The second belongs in the journal body. Keeping those outputs separate makes the result useful without turning the app into a full task manager.

Structured output matters more than a longer paragraph

A useful AI diary response is not just a polished block of prose. The app needs predictable fields so that each part can be shown in the right place:

{
  "diary": {
    "title": "The review finally moved forward",
    "summary": "A short reflection on today's progress"
  },
  "sections": [
    {
      "type": "daily",
      "title": "What happened",
      "content": "The review moved forward, and I felt relieved after the delay."
    }
  ],
  "todos": [
    {
      "title": "Send the revised screenshots to Sam",
      "scope": "today"
    }
  ],
  "reminders": []
}

The exact schema can evolve, but the principle is stable: the model produces structured data, while the app owns presentation, local persistence, editing, and deletion. This separation also makes it easier to test whether a revision changed the user's meaning or accidentally created duplicate todos.

Designing for failure

Voice capture happens in real life, not in a clean demo. A user may lose connectivity, stop speaking halfway through a thought, or receive an imperfect transcription. The safe fallback is to keep the transcript or a local draft whenever possible instead of replacing it with an error screen.

The same principle applies to AI output. If organization fails, the original text should remain available. The user should be able to retry, edit the draft manually, or save the note without AI. An AI diary should make the model optional at the point of failure, not make the user's memory depend on a successful API call.

The product lesson

The most important part of a voice journal is not the model's writing style. It is the reduction of friction between an experience and a saved memory.

On-device speech transcription helps someone start talking. A narrowly scoped AI organization step helps turn that talk into something readable and actionable. Local-first storage gives the finished entry a clear home. Together, those choices create a calmer workflow than asking the user to write, organize, and categorize everything at once.

That is the direction we are taking with You Speak, I Journal: speak first, organize second, and keep the finished journal close to the person who wrote it.