DEV Community: Jun

When should you publish a dev post? I counted, and JP vs EN are mirror images

Jun — Mon, 22 Jun 2026 03:34:26 +0000

Let me confess something a little creepy.

I have a habit of peeking at other people's dev posts.

Not stealing the writing — relax. I run a tiny read-only job that fetches the public pages on dev.to, Zenn, and Qiita and counts only the boring parts: titles, post times, like counts. Who published what, at what hour, and how far it traveled. Then it tallies the lot.

The reason is petty: my own posts weren't landing. The content is already in my hands — so I wanted to know how much the rest, the when and how you publish, actually moves the needle. By the numbers, not by gut.

So I counted across three platforms. And the conditions that make a post fly turned out to be roughly mirror images between Japan (Zenn / Qiita) and the English-speaking world (dev.to). Here's the story.

First, my most important disclaimer

This post is full of numbers, so let me put up a guardrail before any of them.

This is correlation, not causation. A result like "weekend posts don't do well" could mean the weekend itself is bad — or it could mean people who post on weekends are just dashing something off on the side. The data can't separate those. Please read it that way.

Also, I only keep aggregate numbers I computed myself. I don't store or reuse anyone's article body (read-only GET, count the features, throw the page away). I peek, but only at the overall shape. Nobody gets singled out here.

With that out of the way — four findings I enjoyed.

1. The best hour to publish is just your readers' time zone

This one came out cleanest.

On Qiita, posts published in the morning win (+32pt in the GOOD group). Midday is +14pt. Evening is -32pt, late night -14pt.
Zenn likes midday too (+27pt). Late night is -15pt.
dev.to is the exact opposite. Late night Japan time scores +7pt — Japanese evening is actually weak.

The trick is obvious once you see it. dev.to's readers are English-speaking, mostly US. Late night in Japan is the US working day. Zenn and Qiita readers are in Japan, so the Japanese morning-to-midday slot just works.

So the right answer to "when should I publish?" isn't the platform — it's which time zone your readers live in. English version in the dead of Japanese night; Japanese version in the Japanese morning. Obvious in hindsight. Still satisfying to watch it fall out of the data.

2. On weekends, Japanese posts die

This one honestly spooked me a little.

Zenn posts published on weekends score -54pt. Only 15% of the GOOD group went out on a weekend; 69% of the BAD group did. Qiita is -25pt too.

Meanwhile dev.to is -6pt — basically noise.

The funny part: the Japanese platforms have more weekend posting, yet those posts don't travel. Everyone writes on Saturday, ships on Saturday, and sinks. Sound familiar? (It does to me.)

This follows straight from finding 1: Japanese engineers seem to read dev posts around the weekday commute and the start of the workday. On weekends they're the ones writing code, not reading about it.

And this is the textbook "correlation, not causation" trap. Weekend posts might simply be lazier than the ones people sweat over on a Tuesday. Maybe the day isn't cursed at all. But the direction is unambiguous: shipping a Japanese dev post on the weekend is playing on hard mode.

3. Numbers and colons travel differently across the ocean

Title craft splits by platform too.

A digit in a Zenn title costs -35pt. "3 ways to…", "the 2026 edition" — those just don't fly.
On dev.to a digit is basically nothing (-2pt). Don't sweat it.
The colon format ("X: Y") is a headwind on all three (dev.to -14pt, Zenn -15pt). I thought it looked sharp. Readers disagree.
For good measure, Zenn dislikes bracket titles (【】, []) at -23pt.

The only thing mildly positive everywhere was the question-form title (dev.to +7pt, Zenn +8pt, Qiita +7pt). Ask, and people can't help clicking. This post's title is a question. Subtle, I know.

4. Shorter usually wins

Last one is simple. Shorter posts travel further.

Zenn's GOOD group runs about 6,700 characters in the body; the BAD group about 11,700. The posts that landed are nearly half the length. Titles too — all three platforms have shorter titles in the GOOD group.

"Write more and it'll get through" turned out to be a fantasy. My hands are slowing down as I type this. (This very post could probably stand to be cut.)

The four times the numbers almost fooled me

I've been saying "X works" — but when you tally things, fake correlations show up constantly. Here are the four I tripped over. Without this section, this whole post is just a pile of dangerous claims.

1. Emojis work — no they don't.
On Zenn, "title has an emoji" was 100% in both the winners and the losers. For a second I thought "emojis are mandatory?!" — but Zenn requires an emoji in the frontmatter. If everyone does it, it can't explain a difference. A metric that's structurally saturated looks like signal and is pure noise. Writing "emojis work" would have been a great way to embarrass myself.

2. "Japan engages more" is a misread.
By median likes, dev.to is 1 and Zenn is 3. Tempting to read "Japan engages harder!" But that's just different platform sizes and different like-cultures — comparing absolute values across countries is meaningless. Look at the shape. Zenn's top 10% reaches 74 likes; dev.to's reaches 13. Same word "viral," totally different ceiling. Never brawl with raw absolute numbers.

3. The sample is small.
Zenn's winning group is 26 posts. Shouting "-54pt!" off 26 posts is, frankly, scary. Each platform has its own cutoff and its own sample size (Zenn 26, Qiita 28). So I don't call any of this a "law" — I file it as an observed hypothesis and only promote the ones that reproduce in another week. A number seen once is still a horoscope.

4. And all of it is just correlation.
I'll say it one more time. Whether weekends are weak, whether long posts are weak — the data can't tell me if the condition is bad or if the people who post under it are just careless. Numbers point a direction; they don't guarantee the reason.

Counting kills your instincts, one at a time

What it really taught me is that this was never a hunt for a growth hack.

It was the opposite — a slow execution of every gut feeling I'd been carrying. "Surely emojis help." "Surely a digit gets the click." One by one, the things I vaguely believed got quietly voted down as I counted.

What survived is a few plain lines. English version in the dead of Japanese night; Japanese version on a weekday morning. Short, and ideally a question. That's it.

No secret hack. But I got to drop a stack of instincts I'd been trusting without ever checking them. Before you fight on content, at least don't trip over your own feet in the delivery. Next time your post mysteriously won't land — go count. (And lose your instincts one at a time, same as I did.)

Playing hide-and-seek with an API key our CFO's Claude Code kept hiding

Jun — Thu, 18 Jun 2026 01:23:22 +0000

There's a B2B SaaS that a non-engineer executive built all the way to production in two days, by handing everything to an AI.

Real customers use it. It works. Features ship fast. It's genuinely impressive.

And then I got handed the infra and the ops for it. I'm the guy who walks the "it's running in production" code path one step at a time. Treasure hunt, minefield sweep — somewhere in between.

Today's story is about one of those steps: where the secrets (API keys and friends) were kept, and the game of hide-and-seek that played out there.

Here's the punchline up front: every time I said "uh, that's dangerous," the secret's hiding spot moved house. And every time it moved, I got the look that says "there, now it's safe, right?"

Hiding something and securing something are not the same thing. That's the whole article.

Stage one: hardcoded in the source

The first one I found was a fastball right down the middle.

The API key was written straight into the source code.

API_KEY = "(the real key string)"  # ...right there in the open

Classic vibe coding (= you give an AI a fuzzy instruction and it builds the thing). Getting it to run is the only priority, so it lands on the shortest path that works — embed the value as-is. The AI happily emits "code that runs"; it just won't emit "code that treats a secret like a secret" unless you ask.

So I say my piece: "Hardcoding the key in the source is bad. One look at the repo and it's leaked."

The exec, bless them, was agreeable and fixed it right away. Fixed it, sure — but —

Stage two: relocated to the README

They said it was fixed, so I checked. The key was gone from the source. Oh, nice.

Except — it was now in the README.

As a "setup step." Very helpfully.

## Setup
1. Clone the repository
2. Set the following key: (the real key string)

…you see it, right? The secret just moved from the source to the instructions — it's still sitting inside the repo, not one millimeter less exposed. If anything, what was buried deep in the code got promoted to a prime, front-and-center spot in the document everyone reads first.

In hide-and-seek terms: it came out of the closet and is now standing in the entryway. Easier to find. Great job.

I get the feeling of accomplishment — "I removed it from the code." I do. But in secret-management land, the moment it's inside the repo, it's already game over. You've handed it to everyone who clones.

Stage three: stored in the DB (progress!), but…

"The README is no good either. The point is: don't put it inside the repo at all." I explained it once more.

This time they really thought about it, and the next time I looked, the key was stored in the database.

Which — directionally — is correct. It left the repo. No secret in the code, none in the README. Progress. I clapped. Genuinely.

I did. But.

When I actually peeked inside, the value was sitting there in plaintext.

No encryption, no masking, nothing. Open the table and anyone can read it — the key string, just sitting there on its throne.

Putting it in the DB does not equal safe. The location changed; the secret was never once actually concealed.

In the source → in the docs → in the DB (still plaintext). The hiding spot took a three-stop trip and finally made it "outside" — but it hasn't moved a single step closer to "concealed." The seeker in this game is still looking in exactly the same place.

"Hiding" and "concealing" are different things

I'm not telling this to laugh at the culprit (= the exec). Honestly, it's a really natural instinct.

Human intuition goes like this:

If you put it somewhere out of sight, it's safe.

The closet, the attic, a box pretending to be a safe. Make it invisible and you feel like you've protected it. In the physical world that's half true.

But in software secret management, that intuition slips. The question isn't "is it hard to see," it's:

Does putting it there keep it out of the distributable (the repo)?
Is read access actually narrowed to only the people who need it?
Even if it's read, is the content encrypted so it's meaningless?

That's what matters. Moving the location is "hiding." Only when you satisfy the above do you "conceal." Take it on a three-city tour and, if it never once meets the bar for concealment, the game of hide-and-seek never ends.

So where should it live?

Roughly, this:

Don't put secrets in the code or in the repo (hardcoding, README, committed config files — all out). The code should know only the secret's name, never its value.
Inject the value from outside the runtime — environment variables, or a secrets manager (a vault built for exactly this).
If you absolutely must keep it in the DB, store it encrypted. Plaintext means "if the DB leaks, everything leaks."
And rotate any key that might have leaked. A key that ever sat in plaintext in a repo or a log is contaminated; treat it that way.

This SaaS is about to launch, so I tackled the secrets first. We also had an external red team review the source for vulnerabilities, and that pass is done. Secrets are "leak once and it's over," so they go ahead of refactoring and tests — order-wise, this was the thing to knock out first.

Meanwhile, the obviously-should-be-refactored code and the gaping lack of tests are, for now, left exactly as they are. Because, well, it works. After launch we'll clean it up little by little, update by update. The CFO charges ahead building features; I follow behind sweeping up bugs. That's the split, and right now we're in the just-ship-it phase.

The most interesting part: it happened on Opus 4.8

Read this far and you're thinking "well, a non-engineer built it, so sure." I thought so too.

But here's what made this one genuinely interesting.

This exec runs the top-tier AI plan, constantly — the smartest current model (Opus 4.8), on the highest tier. By any reasonable expectation, this kind of rookie mistake shouldn't happen with that gear.

And yet it did. The secret got hardcoded, moved to the README, and landed in the DB in plaintext. Even with the strongest tool in hand.

It's not that the AI is bad. A smart model emits "code that runs" in an instant. It does — but what counts as a secret, and where it should live, only gets satisfied once you ask for it. Don't ask, and it will cheerfully, brilliantly, help you drop a plaintext secret into your DB.

In other words —

Even with the smartest model, if the operator doesn't know what to protect, intelligence doesn't convert into safety.

The capability of the tool and the safety of the result are on different axes. The same way "this knife is sharp" and "you didn't cut your finger" are two different sentences.

Takeaways

"Building" got fast; "treating a secret as a secret" is a separate skill. Even in an era where a non-engineer ships to prod in two days, this part doesn't fill itself in unless you ask. The brighter the light, the sharper the shadow.
Moving the hiding spot is "hiding," not "concealing." The moment you feel accomplished about relocating it is your cue to stop and look again.
The reviewer's lens, when you inherit something, isn't "does it work" — it's "how could it leak." The more it's running happily in production, the more likely a plaintext key is enthroned behind it.
Even the smartest top-tier model won't save you when it can fail, it fails. Tool capability and output safety are different axes; intelligence converts to safety only when you ask "what are we protecting."

A non-engineer shipping to production is genuinely amazing. I'm not knocking it.

It's just that a secret belongs not in an "invisible place" but in the "right place."

Before you stuff it in the closet and relax — take one more look: is it visible from the entryway? Stay safe out there.

CPU and DB were bored, yet every site timed out: a slow-read bot that starved Apache's workers

Jun — Mon, 15 Jun 2026 11:47:23 +0000

One morning, a bunch of EC shops sharing a single server all tripped their monitors at once with "response timeout."
Let me be honest up front: the outage itself self-recovered in about five minutes. There's no heroic recovery scene here.
The real story is not those five minutes. It's how I chased down the creepy part: every usual suspect was innocent, yet the sites were down.

The stage: one shared web server (Apache prefork) hosting dozens of EC shops.
If you run something like this, your stomach already hurts. One shop's trouble drags the neighbors down with it.

One morning, every shop's monitor went red at once

The alerts fired together. Multiple shops, same instant, "socket timeout."
When every shop on a shared box dies simultaneously, your first suspect is "the foundation died" — CPU, memory, DB, that sort of thing.

Except when I looked, something was off.
The sites were down, but the server was perfectly healthy.

Every usual suspect was innocent

I ruled them out one by one.

CPU: 84% idle. Bored.
DB: not saturated even at peak. Not the bottleneck.
Memory: no sign of the OOM killer. No process restarts.

Every classic load-trouble suspect came back clean.
And yet the monitor kept returning "socket timeout" — meaning the TCP connection was being established, but nothing came back after that.

That's when something nagged at the back of my mind.
If CPU and DB have headroom and memory is fine, then what's running out isn't "compute" — it's the slots that serve responses.
In Apache prefork terms, that's the number of worker processes.

My trusted error.log was, in fact, dead

"If we hit MaxRequestWorkers, error.log would say so."
I opened the global error.log expecting that line, and did a double take.

Nothing. Not a word.

Digging in, the culprit was the logging pipeline.
ErrorLog was piped to syslog, but the fixed tag I'd attached didn't match rsyslog's routing regex.
As a result, server-scope errors (server-wide, not per-VirtualHost) landed nowhere and vanished into thin air.
Even the one line I wanted most right now — "reached MaxRequestWorkers" — simply wasn't there.

This is the quiet but scariest part of the whole thing.
In the middle of an incident, the instrument I was relying on wasn't even plugged in.
(I fixed the routing side afterward so server-scope errors are retained. More on that at the end.)

I sorted the access log by %D and felt a chill

With error.log dead, I went back to the log that was still alive: the access log.
What saved me was the response-time field (%D, in microseconds).

Things invisible when you aggregate by request count show up the moment you sort by %D.
159 requests had taken 15+ seconds each. The worst held a worker hostage for 17 minutes (1040 seconds).

Seventeen minutes, for a single web request. Normally we live in milliseconds, or seconds at worst. This was minutes.
And all of them targeted one single shop, from one single IP.

Count-based aggregation will never float this kind of attacker to the top.
That was the biggest lesson of the day, so I'll put it in bold.
To find a stall, sort by time spent (%D), not by request count.

The culprit wasn't "the one making lots of requests"

The IP turned out to belong to an overseas commercial proxy / scraping vendor — spoofing an old Chrome UA, pretending to be a browser.
And here's the nastiest part.

It sent 217 requests over about 8 minutes — roughly 0.45 req/sec. Low, if anything.
That slid right through the connlimit/hashlimit I had in place (drop above 20 concurrent connections or above 1 req/sec).
Ordinary rate limits are built to catch "too fast," so they were useless against "deliberately slow."

What was it doing?
It fired requests promptly, but deliberately read back the response only in tiny dribbles.
A worker can't be released until the response is fully received, so each one held a slot for 10, 15 minutes.
Do that with many requests at once, and prefork workers fill up one by one until you hit the ceiling (128) — and at that moment every shop's slots are gone.
The foundation (CPU/DB) stays idle the whole time while the sites go down. That's the creepy part, explained.

This is the response-side version of the well-known slowloris (which dribbles out requests to occupy workers).
It's the family known as low-and-slow — it hits you with "slow," not "fast."
There's no flashy traffic spike, so staring at load graphs won't reveal it.

What I did on the spot (stopgap)

Once the culprit was clear, I stopped the bleeding first.
The action was simple: immediately block that single IP.
Concretely, one DROP line at the top of the firewall (iptables). I backed up the pre-change state just in case, then added it, and confirmed the collateral shops were serving 200s again.

But let me be honest here.
This is just swatting the hand that's hitting you right now — not a permanent fix.
The vendor rotates IPs, so IP blocking inevitably becomes whack-a-mole.
And the commonly suggested mod_reqtimeout watches the case where the request side is slow (the original slowloris). The case here — the response-reading side being deliberately slow — can't be caught by a request-side timeout.
It's the same reason a simple rate limit got slipped.

The real fix is "a front layer that absorbs fast and slow," I think

From here on, this is not what I actually did, but the conclusion / the homework (I haven't deployed it yet, honestly).

As long as bare prefork Apache speaks dynamic content directly, the structure itself — "a worker is held until the client finishes reading the response" — never goes away.
So the sensible fix is to put a front layer that buffers the response in front of Apache.
A CDN or reverse proxy receives the full response first, then patiently babysits the slow client on its own.
That way the Apache worker is freed the moment it has flushed the response, and "slow clients" can no longer take slots hostage.
A complementary output-side / idle timeout (cutting off no-progress while streaming a response) helps too.

In short: let the front layer, where slots are plentiful, deal with slow clients — not Apache, where slots are precious. That's the structural answer, the way I see it.

So what did I actually learn

Not crypto, not algorithms — three humble but effective takeaways.

1. If you have CPU/DB headroom but still get socket timeouts, suspect worker/connection exhaustion.
Look at the free slots in the worker pool, not the load graph. Resources can be plentiful while "slots" run dry.

2. Hunt stalls by time spent (%D), not by request count.
Low-rate low-and-slow won't appear in count aggregation. Sort by %D and it finally shows its face.

3. Check that your monitoring logs themselves are alive — in peacetime.
"error.log happened to be dead exactly during the incident" is not funny. On a quiet day, make sure your instruments aren't silently dropping into the void. This one stung the most.

It's precisely because it isn't a flashy attack that it's so easy to miss.
Are the slots in your worker pool actually free right now?
Watch out for the customer who makes few requests but overstays forever.

How a Slow Office VPN Led Me to File a US Patent

Jun — Mon, 08 Jun 2026 06:18:03 +0000

This is the story of how a mundane complaint — "the VPN is slow" — turned into a US patent application. Not a granted patent. An application. I want to be precise about that from the start, because the distance between the two is the whole point of this post.

It started with a slow VPN

The company I work for had an internal VPN that everyone routed through. It lived in the Tokyo office, it was old, and it was not something I built. Then the complaints started arriving — from a lot of people, all saying the same thing: it's slow.

I work from Thailand most of the time. That detail matters. If that aging box in Tokyo had fallen over, I would have been the person furthest from the power button, in the worst position to fix it. A slow VPN is annoying. An unreachable VPN, when you're a few thousand kilometers away, is a real problem.

So I started moving it to the cloud. I stood up a WireGuard VPN — modern, fast, and something I could actually reason about and operate remotely instead of inheriting a black box.

Down the WireGuard rabbit hole

Around that time I was deep into building my own iPhone apps. So the cloud migration turned into a personal project on the side: I built my own server and wired WireGuard into an iPhone app of my own. And to do that properly, I started studying how WireGuard actually works under the hood — the Noise protocol, the handshake, the key exchange.

That study is where everything else came from. I wasn't trying to invent anything. I was just trying to understand the thing I was now responsible for.

The SYN flood that primed my brain

Not long before, the same company had been hit with a SYN flood attack. If you've dealt with one, you know it lodges the mechanics of connection handshakes firmly in your head — the back-and-forth, the round trips, the cost of every "hello" before any real data moves.

So I had handshakes on the brain. And then, reading through how WireGuard establishes a session, a thought stopped me:

Wait — does it really handshake every single time?

The club-stamp idea

Here's the analogy that made it click for me.

Think about getting into a club. The first time, there's a whole process: they check your ID, you pay the cover. But once they stamp your hand, you can walk back in again and again — no re-checking every time — until the stamp wears off.

HTTPS already does something like this. The first connection does the expensive handshake; later ones can resume more cheaply. So I wondered: why can't a VPN handshake work the same way? Do the full handshake on the first connection, and from the second connection onward, present a kind of token — a stamp — and walk straight in. With an expiry, of course.

That's the essence of it: a zero round-trip (0-RTT) handshake. The first session sets things up and hands the client a one-time "re-entry" credential. The next session uses that credential to establish a provisional session key on the very first message, instead of paying for another full round trip. After it's used, the server destroys it, so the stamp can't be replayed.

I'm keeping the cryptography deliberately light here — this is a story about a journey, not a spec. But that "club stamp for VPNs" was the idea.

"Wait... can I patent this?"

The first thing I did was check whether someone had already done it. I went looking for prior art: QUIC's crypto, TLS 1.3's 0-RTT, NoiseSocket, and a pile of academic work. I searched patent databases for 0-RTT key exchange on WireGuard and Noise.

I found nothing. Zero prior patents for a cached-ephemeral-key 0-RTT handshake on WireGuard.

That's the moment the question shifted from "is this a neat idea?" to "wait — could I actually patent this?"

Filing it myself, solo

I expected the answer to be: hire a patent attorney, spend a small fortune, wait. The quotes I gathered for the full attorney route ran into the thousands of dollars, easily five figures by the time you add drafting and prosecution.

I went a different way. I filed it myself, without hiring a patent attorney. A few things made that possible:

The design was already done. I had written up the full cryptographic flow while studying WireGuard, so the hard intellectual work — the part you'd normally pay an attorney to extract from you — already existed in my own documents.
Multi-LLM review. I used several different LLMs (Claude, ChatGPT, Gemini, and others) to review and stress-test the specification and claims from different angles, instead of a single human reviewer.
Micro-entity status. As a solo inventor under the income threshold, USPTO fees drop to a few hundred dollars rather than thousands.
Direct non-provisional. I initially planned to file a cheap provisional first, then convert it within 12 months. In the end I filed the non-provisional directly, since the spec and drawings were ready.

The identity verification was its own small adventure. I went through ID.me and ended up on an online meeting with a US-side representative to confirm I was who I said I was. It cost real money along the way, and the realistic timeline I was warned about is long — examination and a potential grant are measured in years, on the order of two and up.

In March 2026 I filed it with the USPTO — "Zero Round-Trip WireGuard Handshake Method and System Using Cached Ephemeral Keys." Sole inventor. Filed by me.

What I actually learned

The thing I want to leave you with isn't the cryptography. It's this: filing a patent is something one person can do. I assumed it required a firm, a budget, and permission. It required a real idea, documentation I'd already written for my own understanding, and a willingness to read the rules carefully.

And the second thing: filing is the start, not the finish. An application is not a granted patent. Mine is sitting in the queue at the USPTO, and it'll be years before I know whether it becomes a real, granted patent — or gets rejected. I haven't "gotten a patent." I've filed one. That distinction is easy to blur and worth keeping honest.

It all started because a VPN was slow and I happened to be the wrong distance away to ignore it.

Create an ECS Fargate Service Step by Step

Jun — Sat, 06 Jun 2026 01:40:34 +0000

Prepare Docker Image at ECR

If you don't have an image at ECR, please check this article and get it.

Push Docker image to AWS ECR
In this article, I use React app image.

About ECS

AWS Elastic Container Service
It's a highly scalable and fast container management service.

Terminologies in ECS

Task / Task Definition: For setting container
Service: For setting tasks, auto-scaling, VPC, etc
Cluster: The cluster of services

Hands-On Steps

Create ECS Cluster
Create ECS Task Definition
Create ECS Service
Confirm ECS Fargate running

1. Create ECS Cluster

ECS Cluster is a cluster of services that is EC3 instances. But no one can control the EC2 via SSH access because each EC2 instance is hidden.

Select "Create Cluster" at the ECS console
Select "Only net-working (Fargate)"
Name cluster
Create VPC (optional)
Select "Create"

※ Wait 1 or 2 minutes.

2. Create ECS Task Definition

Task is like a Docker container. In this configure console, you can configure the container. So it's like a docker-compose.yml.

Select "Task Definitions" at the ECS console
Select "Create new Task Definition"
Select "Fargate"
Name task definition
Select "ecsTaskExecution" for task role
Select "Linux" for Operating system family
Select "0.5GB" for Task memory
Select "0.25vCPU" for Task CPU
Add container
- Container name: Insert name
- Image: Copy ECR Image URI including tag
- Port mappings: "3000"
Create

3 Create ECS Service

ECS Service is the collection of ECS Tasks and it's related to ALB and AutoScaling Group. ECS Service needs ECS Task when created, but it's technically not a subordinate of ECS Task because you can assign ECS Task to ECS Cluster without Service setting.

Configure service
Select "Cluster" at the ECS console
Select the cluster you created
Select the "Service" tab
Select "Create"
Launch type: "Fargate"
Task Definition: Select the task you created
Service name: Insert name
Number of tasks: 1
"Next step" and skip other items
Configure network
Cluster VPC: choose your VPC for ECS (If you created VPC at "1. Create ECS Cluster", use it )
Select Subnets as many as you need
Click "Edit" for Security groups
- Add Inbound rules： custom TCP / Anywhere / port 3000
"Next step" and skip other items
Set Auto Scaling
Select "Do not adjust the service’s desired count"
"Next step"

⇒ Check all items again, and "Create Service"

4. Confirm ECS Fargate running

Select "Cluster" at the ECS console
Select the cluster you created
Select the "Tasks" tab
Select task running
Copy public IP
Access to public IP with :3000

Good job.
Please make sure you deleted the cluster.
It's better to delete any resources in AWS if you don't need to operate it for a long time or if you just created it for learning.