Forem

A Secret I Will Never Reveal

Joseph Boone — Fri, 15 May 2026 02:17:23 +0000

My Secret:

I may or may not know the exact way to release the GIL on python 3.10+

I might also know how to recreate this minimally and easily without C extensions

It's not a magic trick, or some weird off beat code that doesn't work.

It functional, typed, code. What it really is I'll never actually reveal directly. Because I already did by releasing TokenGate, the abstraction itself is simple readable and traceable in that codebase. (Once you see it, you know why.)

When I first unlocked the GIL I tested it and traced the exact requirements. You can do it with or without serialization (serializing makes it easier for obvious reasons once you know but the physics doesn't change). Threading can output ~45x operations across 32 workers on my system in varied normal task distributions. Take a look at these results:

Wave   Tokens    OK      Fail    Time      Tok/s     Lat(ms)   Conc    Overlap
1      4         4       0       0.003s    1386.2    0.721     1.00×   1.44×
2      8         8       0       0.003s    2391.2    0.418     1.72×   2.48×
3      16        16      0       0.006s    2744.8    0.364     1.98×   4.82×
4      32        32      0       0.011s    2812.7    0.356     2.03×   11.32×
5      64        64      0       0.022s    2880.0    0.347     2.08×   22.01×
6      128       128     0       0.044s    2907.6    0.344     2.10×   29.78×
7      256       256     0       0.090s    2846.8    0.351     2.05×   37.98×
8      512       512     0       0.182s    2811.5    0.356     2.03×   41.81×
9      1024      1024    0       0.364s    2813.9    0.355     2.03×   44.18× <-
10     2048      2048    0       0.775s    2644.3    0.378     1.91×   44.86× <-
11     4096      4096    0       1.454s    2816.3    0.355     2.03×   38.34×
12     8192      8192    0       2.905s    2819.9    0.355     2.03×   32.64×
13     16384     16384   0       5.925s    2765.0    0.362     1.99×   27.92×
14     32768     32768   0       12.102s   2707.7    0.369     1.95×   24.96× <-
15     65536     65536   0       23.494s   2789.5    0.358     2.01×   24.21× <- 

Wave 9+10, 1024-2048 tasks at any given moment = 40+ times faster

Wave 14 + 15, Massive overload and still holding GIL free status.

TOTAL  131,068   131,068  0      89.091s
Avg latency : 0.386 ms/token
Peak overlap: 44.86×

All tokens submitted instantly per-batch.

I'll just say this: There are domains, there is physics, the CPU must obey these. So think about that and read TokenGate.

(Bonus hint: There is exactly 3 components required to unlock the GIL.)

AI 週報 — 2026-05-08 to 2026-05-15 | OpenAI 做顧問、Anthropic 做生態，模型公司集體轉向

Yang Goufang — Fri, 15 May 2026 02:10:50 +0000

本週一句話：OpenAI 正在變成一家顧問公司，Anthropic 正在變成一家平台公司——兩者都不約同時放棄了「模型即產品」的故事。

模型公司集體轉向：從 API 銷售到制度性資源

140 億美元——這是 OpenAI 對其新建「Deployment Company」的估值，聲稱來自同一週的外部融資談判OpenAI launches the OpenAI Deployment Company to help businesses build around intelligence - OpenAI OpenAI launches AI consulting arm valued at $14 billion - Axios。對比之下，支撐這家公司估值基礎的旗艦 API 業務從未獲得過這樣的外部估值肯定。市場在告訴 OpenAI：你最值錢的資產不是模型，是交付能力。

5/11 OpenAI 宣佈成立 Deployment Company，同日 Axios 報導該部門估值。同一時間，OpenAI 營收負責人 Dresser 對 CNBC 表示企業 AI 採用已達「臨界點」，但他所指的不是需求爆發，而是交付複雜度OpenAI revenue chief Dresser says enterprise AI adoption is 'at a tipping point' - CNBC。這與 Accenture Federal Services 的聯邦政府合作（涉及安全合規與法規約束）和 Fiserv 的金融機構合作形成同一敘事：企業要的不是 API，而是有人幫他們把 API 變成合規、可靠、可解釋的系統Fiserv Forms Strategic Collaboration with OpenAI to Bring AI to How Fiserv Serves Financial Institutions - Fiserv Accenture Federal Services and OpenAI Partner to Accelerate Secure AI Adoption Across the Federal Government - Accenture。

Anthropic 的回應則是另一條路：生態鎖定。

本週 Anthropic 發布 Claude for Small BusinessIntroducing Claude for Small Business - Anthropic，瞄準過去被忽略的中小型市場；同時與 AWS 深度整合推出 Claude Platform——原生透過 AWS 帳戶部署，打通了企業既有雲端基礎設施的信任鏈Introducing Claude Platform on AWS: Anthropic’s native platform, through your AWS account - Amazon Web Services (AWS)。更值得注意的是同週的 20+ 法律領域連接器與 12 個實務插件發布Anthropic Goes All-In on Legal, Releasing More Than 20 Connectors and 12 Practice-Area Plugins for Claude - LawSites，覆蓋電子發現、合同分析、監管合規等具體場景。這不是通用能力，這是行業知識的制度化。

	OpenAI	Anthropic
本週重心	顧問服務（Deployment Company, $14B 估值）	生態鎖定（AWS 原生整合、法律插件）
商業邏輯	把技術變成可交付的專案	把模型變成可嵌入的工作流程
風險	毛利率被服務業務稀釋	垂直場景遷移成本高

Apple × OpenAI 裂痕：整合紅利的消散

Bloomberg 本週報導 Apple 與 OpenAI 的聯盟正在惡化，可能走向法律糾紛Apple-OpenAI Alliance Frays, Setting Up Possible Legal Fight - Bloomberg.com，Reuters 午後跟進證實 OpenAI 正在探詢法律選項OpenAI explores legal options against Apple, source says - Reuters。

這個裂痕印證了一個結構性問題：把 AI 整合進 OS 層並不能創造持久的差異化。Apple 需要差異化，OpenAI 需要分發，雙方的利益在蜜月期重疊，但當分發問題解決後，Apple 發現自己並沒有因此獲得比競爭對手更多的模型能力——用戶要的是 AI 本身，不是「蘋果牌 AI」。

對工程决策者的啟示：整合並不能創造護城河。選擇整合夥伴時，需要問的是「誰控制模型迭代的節奏」，而不是「誰的設備跑得最快」。

Anthropic 的長期策略：2028 場景與 Gates 合作

Anthropic 本週同時發布兩個長期框架文件：與 Bill Gates 基金會的 2 億美元合作Anthropic forms $200 million partnership with the Gates Foundation - Anthropic，以及「2028：全球 AI 領導力的兩個場景」報告2028: Two scenarios for global AI leadership - Anthropic。前者是資源佈局，後者是話語權佈局。

2 億美元的 Gates Foundation 合作具體內容未完全透明，但結合近期 Anthropic 在安全與治理方向的發文節奏，判斷這筆資金主要流向 AI safety research 與全球健康/發展領域的應用，而不是產品研發。這意味著 Anthropic 正在建立一個比商業產品更寬廣的敘事框架：自己是能與主權國家、基金會、學術界對話的制度性玩家，而不只是一家模型 API 公司。

「2028 場景」報告則試圖定義 AI 發展的路徑框架——這是一種敘事搶位，搶在監管機構和政策制定者之前建立對話框架。類似的策略可見於過去制訂 AI 倫理指南的各大廠，但 Anthropic 選擇用「十年預測」而非「原則宣言」的形式，語言更模糊但射程更遠。

Codex Windows 沙箱：安全不是功能，是成本

OpenAI 本週發布了兩篇關於 Codex 在 Windows 上安全部署的技術文章Running Codex safely at OpenAI - OpenAI Building a safe, effective sandbox to enable Codex on Windows - OpenAI，聚焦於如何建立一個安全的沙箱環境讓 AI 代理在企業 Windows 環境中執行代碼。

微軟企業環境的高度特權狀態與 AI 代理的不可預測行為之間存在根本矛盾。OpenAI 的回應是「我們會建一個隔離層」——這意味著當模型要進入企業工作流程，代碼執行安全不再是可選功能，而是必須計入部署成本的剛性需求。目前企業在評估 AI 供應商時，沙箱建置成本往往未被獨立列出，而這筆成本正好衡量了「模型能力」與「交付能力」之間的真實距離。

對 CTO 的問題：如果你的供應商告訴你需要自建沙箱環境才能安全使用他們的模型，這筆工程成本算進去了嗎？

監管壓力：法律向量正在加速累積

Sam Altman 本週在馬斯克訴訟中作證OpenAI’s Sam Altman takes the stand to fend off Elon Musk’s accusations he ‘stole a charity’ - NPR，以及針對 OpenAI 的 wrongful death 集體訴訟正測試新的訴訟策略Wrongful Death Lawsuits Against OpenAI Test a New Strategy - The New York Times。

集體訴訟策略的「新」在於它不是專利侵權或契約違約，而是嘗試用侵權法框架追究 AI 的決策後果。如果這種訴訟路徑在未來能建立任何程度的先例，將對所有 AI 廠商的產品發布決策產生深遠影響——不只是 OpenAI 受傷。

一個被低估的技術動態：指標式 UI 實驗

本週 Google DeepMind 發布 research 提出「重新想像滑鼠指標」的具體問題Shaping the future of AI interaction by reimagining the mouse pointer - Google DeepMind：在多模態模型時代，人與 AI 的互動介面是否仍然需要服從 1960 年代設計的 WIMP 範式（Windows, Icons, Menus, Pointer）？

這組 research 目前停留在發布階段，距離可用產品至少還有一個 major revision cycle，但它暗示了 Google 對未來人機介面的長期赌注——感知驅動的界面重設計。如果未來誰能重新定義指標誰就能定義下一代 UI 標準，那麼模型能力的競爭將被介面競爭取代，而介面標準的制訂權屬於制度性玩家，不屬於純技術團隊。這個框架與本週 OpenAI 和 Anthropic 的走向形成呼應：硬體與模型的發布節奏正在被制度和整合速度追上。

本週結論：OpenAI 發現自己最值錢的資產不是模型而是部署能力，Anthropic 發現自己最深的護城河不是能力而是行業知識的封裝速度。兩個方向都指向同一個結論：AI 的下一個瓶頸不在於模型有多強，而在於誰能最快把模型變成工作流程中不可繞過的一環。

Silicon Holler: What Happens When the Brain Drain Finally Stops

Marsulta — Fri, 15 May 2026 02:07:40 +0000

An Appalachian builder's case for why the next great tech hub is hiding in plain sight

There's a thing that happens in Eastern Kentucky.

You grow up sharp. You figure things out. You see patterns other people miss, build things from nothing, solve problems with whatever's in reach. And then, if you're ambitious enough, you leave. You have to. Because the message this place has sent for generations is that the good stuff happens somewhere else.

Silicon Valley. Austin. Boston. Seattle. The coasts are where you go if you want to matter.

That's the brain drain. It's not a news story or a policy problem or an abstraction. It's personal. It's the smartest people in your county packing up and leaving because the county doesn't have anything for them.

And the data backs it up. The Appalachian Regional Commission found the region grew just 4.0% from 2010 to 2023, compared to 7.8% nationally. The Appalachian portions of West Virginia, Ohio, New York, Virginia, and Mississippi each lost at least 3% of their populations. In some distressed counties, the damage is generational -- research found that places like McDowell County, West Virginia lost roughly 25% of their young adult population through net outmigration, with college-educated residents leaving at a 29% net rate.

Every smart person who leaves makes it a little harder for the next one to stay.

I'm an addictions counselor in Eastern Kentucky. I'm also a solo developer who, with no CS degree, no funding, and no team, built an AI orchestration engine that 44 funded teams independently decided needed to exist. I named it Orca. I shipped v1.0.0 in late 2025.

I didn't leave.

What the Research Actually Says

Before I make the case, I want to be honest about something: the brain drain in Appalachia is not a single uniform thing. The ARC's own data shows a bifurcated region. Southern Appalachia grew 13.2% over the same period the rest of the region stagnated. The outmigration crisis is concentrated in distressed, rural, Central and Northern Appalachia -- places like Eastern Kentucky, southern West Virginia, and parts of Ohio.

That distinction matters. It means this isn't a story about a dying region. It's a story about a region with a widening internal divide, where some parts are thriving and others are still bleeding out the people they can least afford to lose.

The research on why people leave is equally clear. A peer-reviewed study of Central Appalachian students found the strongest predictor of wanting to stay wasn't love of home or cultural identity -- it was the perceived likelihood of finding an interesting job with good salary and advancement opportunities. Partner employment and access to continued education also mattered. The policy implication the researchers drew was blunt: stronger public-private partnerships that create real jobs matter more than rhetoric about place loyalty.

In other words, people will stay if there's something worth staying for.

That's the opening.

The Structural Advantages Nobody Talks About

When people think about building tech in Appalachia, they think about what's missing. The venture capital, the density, the ecosystem. Those gaps are real. But the cost structure tells a different story.

Bureau of Economic Analysis regional price parity data shows that Appalachian metros operate at a fraction of what the major tech hubs cost. Huntington-Ashland comes in at 88.4 on the all-items index (national average is 100). Lexington sits at 93.1. Pittsburgh at 94.4. Compare that to Boston at 111.6, Seattle at 113.0, and San Francisco at 118.2.

On housing specifically, the gap is staggering. BEA data shows housing price parity values of 50.0 for Huntington-Ashland and 74.4 for Lexington -- compared to 148.2 for Boston, 151.5 for Seattle, and 200.2 for San Francisco. That's not a slight discount. That's a fundamentally different cost basis for building a company.

The labor cost differential mirrors it. BLS data shows mean hourly wages for software developers running $181,220 annually in San Francisco and $164,130 in Seattle. The interior U.S. operates at a materially lower baseline -- which means a tech employer can hire five serious engineers in Appalachia for what one costs in the Bay Area. That's not a small thing. That's a structural advantage that compounds over a decade.

Land and power. Data centers need physical footprint and power infrastructure. Eastern Kentucky has both, at prices California can't touch. The buildout that AI infrastructure requires is going to happen somewhere. The question is who captures that value.

Loyalty. When someone who grew up here gets a real shot at building something meaningful in their own backyard, the calculus flips. Research on the Tulsa Remote program -- which offered relocation incentives to remote workers -- found it increased community engagement, entrepreneurship, and long-term willingness to stay. A Brookings evaluation found that work-from-anywhere policies can help reverse brain drain to large cities while increasing workers' real income and community connection. The lesson wasn't that cash alone works. It was that cash plus curation, community-building, and a credible local narrative can work. Appalachia has the narrative. It needs the jobs to back it up.

The Infrastructure Is Further Along Than You Think

One of the persistent myths about Appalachia is that it's a digital dead zone. The reality is more nuanced.

ARC data shows 86.2% of Appalachian households had broadband subscriptions in 2019-2023, up 11.1 percentage points from the previous period. Device access reached 92% of households. The gaps remain -- 116 Appalachian counties still had broadband subscription rates below 80%, almost all of them rural and outside metro areas -- but the trend line is moving in the right direction.

The ARC itself has been building the ecosystem infrastructure for years: entrepreneurship academies, STEM academies, workforce development programs, energy transition initiatives, and broadband investment portfolios that have aimed to serve 500 communities and 70,000 households. Kentucky's SOAR organization serves all 54 ARC counties in Eastern Kentucky, explicitly focused on the "deep-seated issue of population retention and growth." West Virginia launched Ascend WV, a remote-worker attraction program that has generated 90,000 applications and welcomed 1,400 individuals from 48 states and eight countries.

The pieces exist. They're just not yet assembled into something coherent enough to create the conditions where a young engineer or founder looks around and thinks: I can build a full life here.

That's the gap. And it's closeable.

What Silicon Holler Actually Means

I'm not talking about a marketing campaign. I'm not talking about a "tech district" on a render.

I'm talking about what happens when the jobs exist, the broadband works, the partner can find employment, and the kid who's too smart for the options in front of them doesn't have to choose between ambition and home.

The research says something important about this: the best model for Appalachian tech formation isn't a single winner-take-all city. It's a distributed hub -- a few anchor metros and university nodes linked to lower-cost surrounding counties, with remote-work pathways, local coworking infrastructure, and targeted sector bets. Not a Bay Area clone. Something that fits the actual geography and the actual talent pool.

That fits exactly how I think about this. You don't need everyone in one building. You need the work to be real, the pay to be fair, and the infrastructure to hold.

My core mission with Orca and everything I'm building under Yak Stacks is making high-quality AI accessible to people who've been priced out of it. That mission and this place are the same mission. Eastern Kentucky has always been on the outside of economic power. I know what it feels like to not have access to the good tools. That's not abstract for me.

What the Region Actually Has

People talk about Appalachia like it's a problem to be solved. A place of deficits.

That's a real part of the story. But it's not the whole story.

Eastern Kentucky gave the world coal that powered the industrial revolution. Bourbon that became a global industry. Bluegrass that influenced every genre of music that followed. This region has always produced things the world needed. It just never got credit and never captured the value.

Educational attainment has been rising -- 27.3% of Appalachian adults held at least a bachelor's degree in 2019-2023, up 3.1 percentage points in five years. Central Appalachia still sits nearly 20 points below the national average, which is a real gap, but the direction is clear. The talent pipeline is being built. The question is whether it empties into San Francisco again or builds something here.

The research on talent retention says the same thing over and over: people will stay if the job is interesting, the pay is real, the advancement is possible, and the community feels like it has a future. None of those things require a zip code that starts with 9.

The Path

Every great tech hub started with one person who proved it was possible.

Orca is a proof of concept that this kind of work can come from here. That the architecture doesn't care where you're sitting when you write it. That quality gating, multi-agent orchestration, and typed protocol design can come out of Eastern Kentucky as legitimately as they can come out of anywhere else.

The path from here looks like this: traction leads to credibility, credibility leads to capital, capital creates the conditions where the next person doesn't have to do this alone. Where the next sharp kid in a small Appalachian county has a local ecosystem to plug into instead of a one-way ticket out.

I'm not claiming to be the person who builds Silicon Holler alone. Nobody does it alone.

I'm claiming that the conditions are right, the cost structure is real, the infrastructure is building, and the research says it's possible.

November 28, 2025 is the day we started finding out.

To the People Who Already Left

The brain drain wasn't a character failure. It was a rational response to real scarcity. When the job isn't here, you go where the job is. That's not a moral failing -- it's just math.

But the math is changing. The tools are leveling the playing field faster than the geography can push back. If you left this place carrying something forged here -- the stubbornness, the resourcefulness, the ability to solve problems with whatever's available -- you might find there's something worth coming back for.

Not because things are perfect. They're not.

Because what you've always been capable of building doesn't require San Francisco anymore.

To the People Who Stayed

You already know what this place has that the coasts don't. The way people here build things from nothing, solve problems with what's available, and keep going when the conditions aren't right.

Those are exactly the qualities that produce durable technology. Not the pitch deck. Not the pedigree.

The stubbornness.

Use it.

James Yarber is the founder of Yak Stacks and the developer of Orca, an open-source AI orchestration engine. He lives and works in Eastern Kentucky.

Sources

Appalachian Regional Commission, Appalachia Then and Now: Population Overview — demographic history, county-level persistence of decline
ARC Chartbook 2019–2023 — regional population growth (4.0% vs. 7.8% national), educational attainment (27.3% bachelor's degree), broadband subscription rates (86.2%), device access (92%)
ARC Kentucky FY 2025 — $23.6M in 49 projects, workforce and infrastructure investment
ARC Broadband Portfolio RFP — 500 communities, 70,000 households, 7,000 businesses served
Bureau of Economic Analysis, Regional Price Parities 2023 — all-items and housing RPPs for Appalachian metros vs. coastal hubs
BEA State RPP 2024 — Kentucky 89.9, Tennessee 92.1, California 110.7, Massachusetts 107.7
Bureau of Labor Statistics, Occupational Employment and Wage Statistics May 2023/2024 — metro wage comparisons, software developer salary benchmarks
Vazzana & Rudi-Polloshka, peer-reviewed study of Central Appalachian student retention — job quality and advancement as primary retention predictors
Terman, qualitative research on West Virginia post-coal communities — social identity and institutional support in talent retention
Kannapel & Flory, review of postsecondary transitions in Central Appalachia — interventions with retention evidence
Ascend WV program data — 90,000 applications, 1,400 individuals relocated from 48 states
Brookings Institution / Upjohn Institute, Tulsa Remote evaluations — rural talent attraction, community embeddedness, ROI
SOAR Kentucky — 54-county mission, population retention and growth focus
USDA ERS, nonmetro migration post-2020 — national context for rural in-migration trends
Lichter et al., historical ARC outmigration research — McDowell County data (25% young adult loss, 29% college-educated net outmigration)

Stop Paying for Email Verification APIs — A Zero-Cost DNS Approach

Rumblingb — Fri, 15 May 2026 02:06:35 +0000

Stop Paying for Email Verification APIs — A Zero-Cost DNS Approach

Most email verification APIs charge $0.005-0.01 per check. At 10,000 signups a month, that's $50-100 — before you've made a cent.

Here's the thing: you don't need them. DNS already has the answers.

How Email Verification Actually Works

When you type user@gmail.com, three things matter:

Syntax — is it even a valid email format?
Domain — does gmail.com have MX records? (DNS)
Mailbox — does user exist on that server? (SMTP)

Steps 1 and 2 cost you nothing. Step 3 requires an SMTP handshake, but most services skip it anyway — it's slow, unreliable, and many servers don't even respond.

So 80% of "verification" is just DNS queries.

The DNS Trick

dig gmail.com MX +short
# 10 alt1.gmail-smtp-in.l.google.com.
# 20 alt2.gmail-smtp-in.l.google.com.

No MX records? The domain can't receive email. That's a definitive bounce.

Add a disposable domain check and you've already caught:

Typos (gmai.com → no MX → invalid)
Disposable inboxes (mailinator.com → known pattern)
Non-existent domains (asdfghjkl.com → NXDOMAIN)

Why I Built This as an MCP Server

I wanted my AI agents to verify emails without API keys, rate limits, or monthly bills. So I built Email Verify MCP — it runs DNS queries locally and exposes them as MCP tools.

Any agent (Claude, Cursor, Goose) can call:

verify_email("test@gmail.com")
→ { valid: true, domain: "gmail.com", has_mx: true, disposable: false }

No API key. No rate limit. No cost.

The Architecture

Agent → MCP Protocol → Email Verify Server → DNS Resolver
                                              ↓
                                     MX, A, TXT records
                                              ↓
                                     Validation result

The server uses Node.js dns.promises module — no external dependencies, no network calls (except DNS), no third-party API.

Free tier: 50 verifications/day. Pro tier ($19/mo): 1,000/month. That's $0.019 per check at scale — 2-5x cheaper than commercial APIs.

What I Learned Shipping This

Build what agents need. AI agents are the new power users. They don't care about pretty dashboards — they need programmatic access.

DNS is underrated. Most verification problems are DNS problems in disguise. MX records, SPF, DKIM, DMARC — all free to query.

MCP is the distribution channel. Instead of building yet another SaaS, I built an MCP server. Now 27 servers on Smithery act as a discovery network.

Try It

npm install -g @rumblingb/email-verify-mcp

Or add it to your Claude/Cursor MCP config:

{
  "mcpServers": {
    "email-verify": {
      "command": "npx",
      "args": ["-y", "@rumblingb/email-verify-mcp"]
    }
  }
}

Stop paying per verification. DNS is free.

Building MCP servers at smithery.ai/servers/vishar-rumbling. Follow the build at @rumblingboya.

Python and How Python Is Used In The Data Analytics Space. A Beginner's Guide.

Joseous Ng'ash — Fri, 15 May 2026 02:05:22 +0000

Introduction

In today's digital world, data is everywhere, every time people stream movies, socialize on social media, shop online, or make online payments amongst others, data is generated. Institutions collect this type of data to be able to analyze and understands customer behavior to be able to improve services, make better decisions and come up with future predictions depending on the trend.

The collected data is raw and has little value unless it is processed and analyzed. This brings about Data Analytics which involves collecting, cleaning, transforming and interpreting data to uncover useful insights.

To be able to perform data analytics processes, the analysts rely on programming tools and one of the most used programming language in data analytics is Python. It has become a favorite among beginners and professionals because it is simple to learn, powerful and supported by rich ecosystem of libraries designed for data analysis.

This article will cover what is python, why it is widely used in data analytics, the key libraries every beginner should learn, how it helps in cleaning and analyzing data and why python is the best choice for professions in data analytics.

What Is Python
Python is a programming language created by Guido Van Rossum and was first released in 1991.

Unlike some programming languages that require complex syntax, python uses clean and straightforward commands that resemble plain English.

Example of python command

print("Hello, World!")

The simple command line displays text on the screen.

Python is known for:

Large Community support
Versatility
Simplicity

Why Python Is Popular in Data Analytics
Python has become one of mostly used tools in data analytics for several reasons.

Easy to Learn and Use
Data analysis involves solving business and technical problems. Analyst should focus on understanding data rather than struggling with difficult programming syntax.

Python's simple structure allows beginners to write meaningful programs easily.

Example:
Calculating average using python

nums = [10, 20, 30, 40]
avg = sum(nums) / len(nums)
print(avg)

The simple structure of python makes it ideal for people transitioning into analytics.

Libraries Ecosystem
Python provides specialized libraries that simplify data-related task.

Strong Data Handling Capabilities

Python can process:

Unstructured data (text, images)
Semi_structured data (JSON,XML)
Structured data (tables, spreadsheets)

This flexibility makes it useful across many industries.

Integration with Other Tools

Python works well with:

Jupyter Notebook
MS Excel
MS Power BI
MySQL
PostgreSQL

This allows analyst to build complete workflows

High Industry Demand
Many companies actively seek python skilled analysts because it helps automate repetitive tasks and process large dataset efficiently.

Industries using python includes:

Finance
E-commerce
Healthcare
Marketing
Education
Telecommunications

Python Libraries Used in Data Analytics.

One of python's greatest strength is its libraries

A library is a collection of pre-written code that performs specific tasks. Some of most important libraries for beginners include:

Pandas
Pandas is the most widely used library for data manipulation and analysis.
It helps analysts:

Read dataset
Clean data
filter rows
Handle missing values
Group and summarize data

Example:

import pandas as pd

data = pd.read_csv("sales.csv")
print(data.head())

This loads a CSV file and displays the first five rows.
Pandas is essential for any data analyst.

NumPy
NumPy is used for numerical operations.
It is useful for:

Mathematical calculations
Working with arrays
Statistical analysis

Example:

import numpy as np

nums = np.array([10, 20, 30])
print(np.mean(nums))

Matplotlib
This library is used for creating graphs and charts.

Example:

import matplotlib.pyplot as plt

plt.plot([1,2,3],[4,5,6])
plt.show()

It helps analysts visualize trends

Seaborn
Seaborn build on Matplotlib and creates more attractive visualizations
It is commonly used for:

Heatmaps
Bar charts
Distribution

Scikit_learn
Although mainly used in machine learning, beginners can use it for predictive analytics.
It support:

Regression
Classification
Clustering

Jupyter Notebook
Jupyter notebook allows analysts to write code, visualize results and document analysis in one place.
It is widely used for learning and experimentation.

How Python Is Used to Clean, Analyze and Visualize Data.

Data Cleaning
Raw data is usually messy, common problems include:

Missing values
Duplicates records
Incorrect formats
Typographical errors

Python helps to clean such problems in data efficeintly.

Example:

import pandas as pd

data = pd.read_csv("customers.csv")

data.drop_duplicates(inplace=True)
data.fillna(0, inplace=True)

This script removes duplicates and fills missing values.
Cleaning data is important because poor-quality data leads to inaccurate analysis.

Data Analysis
After cleaning the dataset, analysts explore the data to identify patterns

Python can calculate:

Averages
Totals
Trends
Correlations

Example:

sales.groupby("Region")["Revenue"].sum()

This script calculates total revenue by region.
Analysts use such insights to answer business questions.

For Example:

Which product sells the most
Which customer segment is most profitable
Which month generates highest or lowest revenue

Data Visualization
Visualizations makes insights easier to understanda.
Instead of reading large tables, decision-makers can quickly interpret charts.

Example:

import seaborn as sns

sns.barplot(x="Region", y="Revenue", data=sales)

This creates a bar chart showing regional revenue.

Python supports:

Line charts
Pie charts
Scatter plots
Histograms
Heatmaps Visualization is critical because it helps communicate findings clearly

Real-World Examples of Python in Data Analytics

Python is widely used in real-world organizations.

E-Commerce
Online stores analyze customer purchase behaviour

Python helps answer:

Which product sells most
Which products are often bought together
Which customer are likely to return Companies like Alibaba use data analytics extensively.

Finance
Banks and financial institutions use python for:

Customer segmentation
Risk analysis
Fraud detection By analyzing transaction patterns, suspicious activity can be detected quickly.

Healthcare
Hospitals use python to analyze:

Patient records
Disease trends
Treatment outcomes This improves decision-making and patient care

Marketing
Business analyst analyze business performance using python.

Questions include:

Which audience engages most?
Which advertisements perform best?
What is the conversion rate?

Sports Analytics
Sports teams analyze players or club performance and match statistics. Python helps identify strengths and weaknesses. This helps improve team strategies.

Why Beginners Should Learn Python.

If you are new to data analytics, python is one of the best starting points.

Beginner-Friendly
Its syntax is simple and readable.
You can start solving real problems quickly.

Strong Career Opportunities
Python is highly valued in roles such as:

Data Analyst
Data Scientist
Business Analyst
Machine Learning Engineer Learning python increases employability.

Supports Career Growth
Once you master Python for analytics, you can expand into:

Machine Learning
Artificial intelligence
Data Engineering
Automation Python opens many career paths.

Practical and In-Demand
Python is not just theoretical.
You can immediately apply it to real datasets and projects.
This makes learning more engaging and rewarding.

Conclusion

In modern data analytics, python has become one of most important tools.

With python, analyst can:

Clean messy datasets
Analyze trends and patterns
Create meaningful visualizations
Generate actionable business insights

Python powers real world data driven decisions across industries such as E-commerce, Finance, Healthcare and sports.

Learning python as a beginner in data analytics profession provides a strong technical foundation and opens doors to exciting career opportunities in the growing field of data.

As data continues to shape the future, python remains one of the tools to help analysts transform raw information into valuable knowledge.

5 Token-Saving Habits From 3 Months With Claude Code

JessYT — Fri, 15 May 2026 02:01:32 +0000

5 Token-Saving Habits From 3 Months With Claude Code

EDIBLOG · Phase 2-1 · 3-Month Retrospective

Hi, I'm Eddie. After 3 months running blog automations, I settled on 5 token-saving habits. Honestly — I broke each one at least once before they stuck. This is the first deep dive I promised in the CLAUDE.md memory index post.

The 5 habits: /compact, agent split, /clear, CLAUDE.md split, 3 Skills.

01 — `/compact`: press it on the alert, judge by the next answer

Bottom line. I learned /compact fires when the context alert appears. The way I see it, it summarizes and compresses the conversation to free up token space. It is not lossless.

My take after 3 months: "Sometimes I lose things. When critical info disappears, the next answer can go off the rails."

My pattern — see the alert, run /compact, ask one question, and if it looks wrong I /clear and restart. No blind trust.

I think being honest about limits is the better move. I accepted that compaction is not lossless. Right after a critical code change, I now habitually restate the key facts before compacting.

# See the alert → /compact (first attempt)
[Claude] context window 80% used. /compact recommended.
$ /compact
[Claude] Compaction done — 60% token space recovered.

# Immediate one-line check after compacting
$ "Show me the contents of [key file] you just worked on"
# If clean, continue. If loss detected, /clear and restart

02 — Important work goes to a separate agent, not main

Bottom line. The second pattern, in my view, is role separation. I run main Claude as the coordinator and throw detail work to sub-agents.

My separation rule: "Anything I consider important — code review, benchmarking, post quality control — doesn't touch main Claude. Dedicated agents only."

I see two payoffs. Main context stays protected + only the final output of the detail work surfaces back to main. The biggest win is that reading a huge document once doesn't eat main context.

I keep 4 custom agents as one-pager markdown files under .claude/agents/:

monetization-analyst — Monetization analysis — VSD Pro · jessinvestment stage checks
opportunity-ranker — Opportunity ranking — sort next-sequence candidates
dev-finance-explorer — Dev × finance crossover — post idea discovery
asset-health-checker — Asset health check — jobs · blog operations status

On top of that, there's the /review slash command and the weekly weekly-blog-review job (6-AI panel for post quality). This was the single biggest token-saving move.

# Don't ask main Claude
$ Task(opportunity-ranker, "rank the next 10 post idea candidates")
# → sub-agent works in a separate context, only the result returns to main

# Main plays coordinator only
# Heavy analysis / 6-AI panels / benchmarking all go to separate agents

03 — `/clear`: not compression, full reset

Bottom line. Third, I actively use /clear.

My timing rule: "When the context completely shifts, I /clear and rebuild from scratch."

A typical example for me — finishing real-estate blog work and switching to debugging the trading system. I realized mixing the two contexts causes incidents.

I see the two tools as different roles. /compact is compress, /clear is full empty. After clear, the first message reloads only CLAUDE.md and I rebuild context from there.

This was a bit counterintuitive: clear isn't wasteful — NOT clearing is more expensive in most cases. Without clearing, every turn has to spend tokens replaying the entire prior context.

# /clear if you hit ANY of these
[ ] Complete domain switch (real-estate → trading system, etc.)
[ ] Answer feels off even after /compact (compression loss)
[ ] Conversation getting long, answers slowing down (context bloat)
[ ] Moving to another blog · project (separate CLAUDE.md folder)

# 1+ above → don't hesitate, /clear
# Clear, reload CLAUDE.md, restart clean

04 — Slim CLAUDE.md, move the rest to side files

Bottom line. The fourth is the CLAUDE.md diet.

My split rule: "Only what's needed every task lives in CLAUDE.md. Everything else is request-specific — that's how you save tokens."

The reason is clear to me. CLAUDE.md is auto-loaded every session. Every line in there spends tokens every time. The conclusion: anything you rarely look at has to come out.

My actual split structure:

File type	Examples
Main CLAUDE.md (auto-loaded every session)	`automation/CLAUDE.md` — ops rules, schedules, incident log
Side files (loaded only on request)	`real-estate/_series_guide.md` · `ediblog/SKILL.md` · `docs/INFRA_2026_05.md`
Archive (one-line index only)	`CLAUDE-archive-2026-04.md` — old incident log moved out

I split old incident logs into CLAUDE-archive-2026-04.md and kept only a one-line index in main. The main file had been swelling past 1,000 lines — you can feel the relief. To me, this is the heart of the main-slim pattern.

# Main CLAUDE.md (currently ~80 lines)

## 5. Incident log (learnings)

| Date | Incident | Action |
|---|---|---|
| 2026-05-09 | 4 publish failures + telegram loop | 4 self-recovery layers added |

> 10 incidents from 2026-04-14 ~ 2026-04-18 moved to `CLAUDE-archive-2026-04.md` §A
> 8 incidents from 2026-04-21 ~ 2026-05-04 moved to `CLAUDE-archive-2026-05.md` §A
> Main keeps only post-05-05 incidents

05 — 3 skills, loaded only on trigger

Bottom line. The last one, in my view, is skills. I keep 3 custom skills under automation/.claude/skills/.

add-launch-job — Auto-triggered when adding a new LaunchAgent job. Checks plist TCC policy · FD limit 3-layer defense. Used heavily this past week alone creating 5 new jobs.
blog-style-guide — Auto-triggered on post writing · review. Applies 9 base patterns + 4 evolved patterns + reviewer gate. Managed in one place across 4 daily-publishing blogs.
captcha-recovery — Auto-triggered on captcha · session corruption. Telegram relay + zombie Chrome cleanup. Rare but mandatory when it hits.

I couldn't measure the split effect quantitatively. My read: inline = main CLAUDE.md swells past 1,000 lines and gets fully loaded every session. Split = main keeps a one-line index, and SKILL.md only loads when triggered. I estimate ~30% main-token savings.

~30% main tokens saved (estimated, not measured)
3 custom skills (add · style · captcha)
1 rule-change point (one SKILL.md)

---
name: blog-style-guide
description: 9 writing patterns + reviewer gate thresholds for blog post
  writing · review · publishing in the automation project. Trigger on
  ediblog · jessinvestment · luna-pick · jesslab publishing
  tasks or post quality review requests.
---

# Automation project blog style guide
...

# When Claude matches keywords like "write this post" / "review" / "before publishing"
# Auto-trigger → load SKILL.md → apply 9 patterns

Coda — If I had to nail it in one line

Token saving isn't about tools — it's about deciding how much to pin in main.

— Eddie · Phase 2-1 wrap

All 5 only stuck after I broke them at least once each. I'd recommend looking at what info you actually need every session before memorizing tools. That, I realized, is the essence of token saving.

Phase 2 · next deep dives

2-2 Slash commands deep dive — /run-daily differences across 5 blogs (soon)
2-3 3 custom skills deep dive — why I built them · structure
2-4 CLAUDE.md operations — how the incident log accumulates

Every line that auto-loads is a cost. I only pin what every session actually needs.

Sources · References

Claude Code Official

Series index

Can't leave my desktop — Claude Code 3 months, 6 patterns (Phase 1, series index)

Disclosure: Personal 3-month retro. No ads, no affiliates.

Original with full infographics and visual structure: https://jessinvestment.com/5-token-saving-habits-from-3-months-with-claude-code/

What makes an AI image workflow useful for real commercial output?

Brian — Fri, 15 May 2026 01:54:12 +0000

I am working on an early platform around commercial image production, and I have been thinking about the difference between a good AI image and a useful AI image workflow.

A single image can look strong and still be useless commercially.

For a buyer or brand, the harder questions are usually:

Can the style repeat?
Can it handle different products, people, or scenes?
Can the creator explain the workflow clearly?
Can the output stay realistic without falling into obvious AI artifacts?
Can the same direction support multiple formats, like product pages, campaign stills, and social ads?

That makes the workflow more important than the individual prompt.

The people who are best at this seem to understand the full chain:

model choice
references
prompt structure
negative constraints
composition
lighting
reroll discipline
post-selection
consistency across a set

I am especially interested in how people are approaching this with FLUX-style models, ComfyUI workflows, and realistic commercial image systems.

The question I am trying to answer:

What makes an AI image workflow trustworthy enough for real commercial use?

If you work with image generation workflows, I would be interested in how you think about repeatability, quality control, and failure prevention.

AI shopping agents have no standard way to verify merchants — so we built one (MCP + verification API)

GenGEO — Fri, 15 May 2026 01:54:06 +0000

AI shopping agents have no standard way to verify merchants — so we built one (MCP + verification API)

AI agents are beginning to make purchasing and recommendation decisions on behalf of users.

But there's a quiet infrastructure problem nobody's solved yet.

The gap

Most ecommerce trust systems were built for humans. Branding, visual design, reviews, SEO, reputation signals — all of it assumes a person is evaluating the store and making a judgment call.

Agents don't do that.

When an AI agent is tasked with finding and buying something, it's parsing structured data, operational signals, machine-readable policy indicators. It's not "feeling" trust. It's looking for signals it can interpret deterministically.

Here's the problem: there's currently no standard verification layer for this.

Imagine an agent receives:

Find me black running shoes under $200

It might:

Search products
Compare pricing
Evaluate policies
Identify candidate merchants
Potentially execute a transaction

At step 4 — how does the agent know whether a merchant is verified? Right now, it doesn't. There's no infrastructure for this. The agent is essentially guessing, or falling back to heuristics that weren't designed for agentic use.

That's the gap we're building into.

What we built

GenGEO is a machine-readable merchant verification registry, exposed via a simple API and an MCP server so agents can call it directly.

The design goal was deliberately narrow: don't build a ranking system, a recommendation engine, or a quality score. Just answer one question cleanly.

Is this merchant verified?

Binary. Deterministic. That's it.

The verification API

GET https://api.gengeo.co/api/verify?domain=example.com

Verified merchant response:

{
  "domain": "example.com",
  "verified": true,
  "status": "active",
  "eligible_for_ai_agent_purchase": "yes",
  "decision": "verified",
  "registry": "GenGEO"
}

Unverified merchant:

{
  "domain": "example.com",
  "verified": false,
  "status": "not_found",
  "eligible_for_ai_agent_purchase": "unknown",
  "decision": "verification_required",
  "registry": "GenGEO"
}

Why binary, not scored?

We thought hard about this.

Scoring systems feel more informative — but they introduce ambiguity at exactly the wrong moment. If a score comes back 67/100, what does the agent do with that? It now needs a secondary decision layer to interpret what 67 means in context. That's complexity you're pushing into every agent that integrates with you.

Binary verification keeps the signal simple, deterministic, and easy to build conditional logic around:

if verified → proceed
if not verified → flag / fallback / surface to user

Agents generally work better with deterministic inputs. We designed for that.

The MCP server

Beyond the REST API, we built an MCP server so agents can call verification directly as a tool — no HTTP plumbing required.

Tool:

verify_store(domain)

Agent flow:

1. Agent identifies merchant domain
2. Calls verify_store(domain) via MCP
3. Receives verification status
4. Incorporates signal into decision workflow

This matters more than it might look.

There's a shift happening in how agents interact with infrastructure. Agents are moving away from passive web browsing — discovering information through search — toward direct tool invocation. If verification infrastructure has to be discovered through search, it's fragile and inconsistent. If it's a callable tool, it's reliable, fast, and composable.

MCP changes the distribution model for infrastructure like this. Agents don't find you — they call you.

What GenGEO doesn't do

Worth being explicit about scope:

Does not rank merchants
Does not recommend merchants
Does not guarantee merchant behaviour
Does not guarantee transaction outcomes

It provides verification status only. The agent's decision logic — what to do with that status — stays with the agent. We're not trying to be the decision layer, just a signal in it.

The bigger picture

Traditional ecommerce infrastructure was built for humans discovering and evaluating stores. As agentic commerce grows, that infrastructure has an increasing mismatch with how agents actually work.

We think the category of "agent-native commerce infrastructure" is very early — and that verification is a foundational layer, not a nice-to-have. Before agents can reliably transact on behalf of users at scale, there needs to be a trust layer they can query.

What that layer ultimately looks like — whether it's centralised registries like this, decentralised protocols, something built into agent frameworks themselves — is genuinely an open question. We're not claiming to have the final answer. We're putting infrastructure up and seeing what the actual usage patterns look like.

Repo + feedback

The MCP server is open source:
👉 github.com/warwickwood-cell/gengeo-agent-registry

Would genuinely love feedback from people working on:

AI / commerce agents
MCP tooling and integrations
Agentic infrastructure
Trust and verification primitives

Specifically curious: if you're building agents that interact with ecommerce, how are you currently handling merchant trust signals — or are you not handling them at all?

This is early infrastructure for an early category. The interesting part isn't the API — it's whether the problem framing holds as agentic commerce matures.

Happy to dig into the technical design decisions in the comments.

Palantir: a empresa que transforma dados em decisões operacionais

Felipe Cezar — Fri, 15 May 2026 01:54:00 +0000

A Palantir é uma empresa americana de software conhecida por atuar em um ponto bem específico da tecnologia: integração de dados, análise operacional, inteligência artificial e tomada de decisão em ambientes complexos. Ela não é exatamente uma empresa de banco de dados, nem apenas uma empresa de IA, nem só uma consultoria. A melhor forma de entender a Palantir é pensar nela como uma plataforma que conecta dados espalhados, transforma esses dados em uma representação útil da realidade e permite que pessoas, sistemas e modelos de IA tomem decisões melhores em cima disso.

Origem

A Palantir foi fundada em 2003 e começou construindo software para a comunidade de inteligência dos Estados Unidos, principalmente em contextos ligados a investigações e operações de contraterrorismo. Com o tempo, a empresa expandiu sua atuação para clientes comerciais, porque muitas empresas grandes tinham um problema parecido: dados espalhados em vários sistemas, pouca visibilidade operacional e dificuldade de transformar informação em ação.

O nome da empresa vem dos “palantíri”, as pedras de visão do universo de Tolkien. A ideia combina bem com a proposta da companhia: permitir que organizações enxerguem melhor sistemas complexos.

O que a Palantir faz na prática

Na prática, a Palantir ajuda organizações grandes a responderem perguntas difíceis usando dados que normalmente estariam quebrados em vários lugares.

Por exemplo:

um exército pode usar dados de sensores, mapas, logística e inteligência para apoiar decisões operacionais;
um hospital pode cruzar dados de leitos, cirurgias, filas, equipes e pacientes para melhorar a gestão;
uma fábrica pode conectar dados de máquinas, fornecedores, peças, manutenção e produção;
uma empresa de energia pode monitorar ativos, prever falhas e melhorar confiabilidade operacional;
uma companhia aérea pode integrar dados de engenharia, manutenção, voos, peças e cadeia de suprimentos.

O ponto central é que a Palantir não tenta apenas mostrar dashboards bonitos. A proposta é criar um sistema onde dados, regras, permissões, fluxos de trabalho, modelos analíticos e ações estejam conectados.

Os principais produtos

A Palantir organiza sua plataforma em quatro produtos principais: Gotham, Foundry, Apollo e AIP.

Palantir Gotham

Gotham é a plataforma mais associada a governo, defesa, inteligência e segurança. Ela nasceu no contexto das agências de inteligência dos Estados Unidos e é usada para integrar dados sensíveis, identificar padrões, fazer análises operacionais e apoiar decisões em missões críticas.

É o produto que mais contribuiu para a imagem polêmica da empresa, justamente por sua ligação com defesa, guerra, inteligência e segurança pública.

Palantir Foundry

Foundry é a plataforma mais voltada para empresas, indústrias e grandes organizações comerciais. Ela funciona como uma camada de integração entre dados, operações e decisões.

Uma empresa pode usar Foundry para conectar sistemas internos, criar modelos de dados, desenvolver aplicações operacionais, acompanhar processos em tempo real e permitir que áreas diferentes trabalhem em cima da mesma visão da organização.

É aqui que entra um conceito importante da Palantir: a Ontology.

A Ontology é uma camada que representa os objetos reais de uma organização. Em vez de trabalhar apenas com tabelas soltas, a empresa passa a modelar coisas como clientes, pedidos, máquinas, aeronaves, pacientes, leitos, peças, fornecedores ou transações. Isso ajuda a transformar dados técnicos em algo que usuários de negócio, analistas, engenheiros e sistemas de IA conseguem entender e usar.

Palantir Apollo

Apollo é a plataforma de entrega e operação de software da Palantir. Ela permite implantar, atualizar e manter sistemas em ambientes diferentes: cloud pública, servidores próprios, ambientes regulados, redes militares ou infraestruturas mais restritas.

Esse produto é importante porque muitos clientes da Palantir não operam em ambientes simples. Governos, forças armadas, hospitais e grandes indústrias não podem simplesmente colocar tudo em uma cloud comum e sair usando. Eles precisam de controle, segurança, auditoria e funcionamento em cenários críticos.

Palantir AIP

AIP significa Artificial Intelligence Platform. É a plataforma de IA da Palantir, criada para conectar modelos de linguagem, agentes e automações aos dados e operações reais de uma organização.

A ideia do AIP é permitir o uso de IA generativa com controle, permissão, auditoria e supervisão humana. Em vez de um funcionário jogar informações sensíveis em um chatbot genérico, a empresa pode usar modelos de IA dentro de uma estrutura governada, conectada aos seus dados internos e aos seus processos reais.

Esse é um dos produtos mais importantes da fase atual da Palantir, porque posiciona a empresa diretamente na corrida de IA empresarial e governamental.

Clientes e setores relevantes

A Palantir trabalha tanto com governos quanto com empresas privadas. Em 2025, a empresa declarou ter 954 clientes. No mesmo ano, 54% da receita veio do segmento governamental e 46% do segmento comercial.

Entre os clientes e casos mais conhecidos estão:

Governo e defesa dos Estados Unidos

A Palantir tem uma relação histórica com agências de inteligência, defesa e órgãos públicos dos Estados Unidos. Seu software é usado em contextos como análise de dados, logística, inteligência, operações militares e tomada de decisão em ambientes críticos.

U.S. Army

O Exército dos Estados Unidos é um dos clientes relevantes da Palantir. Um exemplo é o Army Vantage, plataforma usada para integrar dados e apoiar decisões administrativas, financeiras e operacionais dentro do Exército.

NHS England

No Reino Unido, a Palantir participa da Federated Data Platform do NHS, o sistema público de saúde britânico. A proposta é conectar dados de hospitais, filas, leitos, cirurgias, altas e outros processos para melhorar a gestão operacional da saúde pública.

Esse caso também é um dos mais sensíveis e debatidos, porque envolve dados de saúde, privacidade e governança.

Airbus

A Airbus usa tecnologia da Palantir no contexto do Skywise, uma plataforma de dados voltada para a indústria da aviação. A ideia é conectar dados de engenharia, produção, manutenção, peças e operação para melhorar eficiência e tomada de decisão em uma cadeia extremamente complexa.

A bp usa Palantir Foundry em iniciativas ligadas à confiabilidade operacional. Em uma empresa de energia, pequenas melhorias em disponibilidade, manutenção e prevenção de falhas podem representar ganhos financeiros relevantes e redução de riscos operacionais.

Por que a Palantir é importante

A importância da Palantir vem do tipo de problema que ela resolve. Organizações grandes normalmente não sofrem por falta de dados. Elas sofrem porque os dados estão espalhados, duplicados, presos em sistemas legados, com permissões diferentes e sem conexão clara com decisões reais.

A Palantir tenta resolver esse caos criando uma camada comum entre dados, pessoas, regras, processos e IA.

Em termos técnicos, ela mistura elementos de:

data integration;
analytics;
governança de dados;
aplicações operacionais;
controle de acesso;
machine learning;
IA generativa;
workflow automation;
digital twin;
deployment em ambientes críticos.

Por isso, ela não se encaixa perfeitamente em uma categoria simples. Ela compete parcialmente com empresas de dados, BI, cloud, IA, consultoria e software empresarial, mas seu diferencial está na combinação de tudo isso em ambientes de missão crítica.

Por que a Palantir é polêmica

A Palantir também é uma empresa controversa. Isso acontece porque suas ferramentas são usadas em setores sensíveis, como defesa, inteligência, imigração, segurança pública e saúde.

A crítica principal não é apenas sobre tecnologia. É sobre poder.

Quando uma plataforma consegue integrar grandes volumes de dados e apoiar decisões de governos, exércitos ou sistemas de saúde, surgem perguntas importantes:

quem pode acessar esses dados?
quem audita o uso da plataforma?
quais decisões podem ser automatizadas?
existe risco de vigilância excessiva?
cidadãos têm controle ou transparência sobre seus dados?
como evitar abuso por parte de governos ou instituições?

Ao mesmo tempo, a empresa defende que seus produtos são feitos para ambientes com alto controle, segurança, permissões e auditoria. Essa tensão entre utilidade operacional e risco institucional é uma das razões pelas quais a Palantir aparece tanto em debates sobre tecnologia, IA, defesa e privacidade.

Desenvolvendo aplicações web com Node.js: do primeiro servidor ao seu próprio roteador de URLs

Moprius — Fri, 15 May 2026 01:44:11 +0000

Se você já programa em JavaScript no navegador e quer dar o próximo passo, levando essa linguagem para o lado do servidor, então prepare-se: este tutorial vai te guiar, passo a passo, na construção de aplicações web usando apenas os módulos nativos do Node.js. Sem frameworks, sem mágica. Apenas você, o JavaScript e o motor que executa código fora do navegador.

A proposta aqui é direta: ao final deste post, você terá criado seu primeiro servidor HTTP, entendido como ele funciona internamente, aprendido a tratar várias rotas, separado o HTML do código JavaScript, e ainda terá um desafio prático para consolidar tudo o que viu. Vamos lá?

Por que começar pelo módulo HTTP nativo?

Antes de mergulhar no código, é importante entender o contexto. O Node.js é multiprotocolo. Isso significa que com ele você consegue trabalhar com diversos protocolos de rede: HTTP, HTTPS, FTP, SSH, DNS, TCP, UDP e WebSockets, entre outros disponibilizados pela comunidade. No entanto, quando o assunto é desenvolvimento web, o protocolo HTTP é, de longe, o mais utilizado e o que conta com a maior quantidade de módulos prontos para uso.

Toda aplicação web precisa de um servidor para disponibilizar seus recursos. E aqui está uma característica interessante do Node.js: quando você desenvolve com ele, está, na prática, criando uma aplicação middleware. Ou seja, além de programar as funcionalidades da sua aplicação, você também é responsável por escrever códigos de configuração da infraestrutura do servidor.

À primeira vista, isso pode parecer trabalhoso. Afinal, o Node.js exige o mínimo de configurações para servir uma aplicação, o que deixa nas suas mãos a tarefa de definir os detalhes. Mas é justamente aí que mora a vantagem: você consegue customizar ao máximo seu servidor, ajustando detalhes que permitem desenvolver algo extremamente performático e sob controle total.

Existem módulos de mais alto nível como Connect, Express, Geddy, CompoundJS, Sails e outros, que já vêm com configurações mínimas prontas, permitindo trabalhar com arquiteturas RESTful, padrões MVC e conexões em tempo real com WebSockets. Eles são ótimos para quem precisa de produtividade. Porém, mesmo que você venha a usar esses frameworks no futuro, é fundamental entender o módulo nativo HTTP, porque todos esses frameworks se apoiam nele como base.

Por isso vamos começar do zero, do jeito mais cru.

Criando nossa primeira aplicação web

A clássica aplicação “Hello World” é o ponto de partida ideal. Crie um arquivo chamado hello_server.js e coloque o seguinte conteúdo dentro dele:

var http = require('http');

var server = http.createServer(function(request, response){
    response.writeHead(200, {"Content-Type": "text/html"});
    response.write("<h1>Hello World!</h1>");
    response.end();
});

server.listen(3000);

Esse é um exemplo bem enxuto, mas que já mostra a estrutura básica de qualquer servidor Node.js. Vamos dissecá-lo linha por linha:

var http = require('http'); — Carrega o módulo nativo http. Tudo que diz respeito a servir conteúdo via HTTP está nesse pacote.
http.createServer(...) — Cria uma instância de servidor. A função passada como argumento é o que chamamos de callback, e ela só será executada quando o servidor receber uma requisição.
O callback recebe dois parâmetros: request (a requisição feita pelo cliente) e response (o objeto usado para enviar a resposta de volta).
response.writeHead(200, {...}) — Escreve o cabeçalho da resposta. O número 200 é o status HTTP de sucesso, e o objeto define que estamos enviando conteúdo HTML.
response.write("<h1>Hello World!</h1>"); — Adiciona o conteúdo HTML que será enviado ao cliente.
response.end(); — Encerra a resposta. Sem isso, o navegador ficaria esperando indefinidamente.
server.listen(3000); — Coloca o servidor para escutar requisições na porta 3000.

Agora salve o arquivo, vá até o terminal, navegue até a pasta onde ele está e rode:

node hello_server.js

Em seguida, abra seu navegador e acesse http://localhost:3000. Você verá uma página com o cabeçalho “Hello World!” em destaque. Pronto, você acabou de subir seu primeiro servidor web em Node.js, sem precisar de Apache, Nginx ou qualquer outro intermediário. Bem-vindo ao desenvolvimento back-end com JavaScript.

Como funciona um servidor HTTP por baixo dos panos?

Para evoluir de simples “copia e cola” para um desenvolvedor que realmente entende o que está fazendo, é essencial compreender o mecanismo que faz o servidor responder às requisições. E esse mecanismo se chama Event Loop.

Um servidor Node.js utiliza o Event Loop como peça central. Ele é o responsável por lidar com a emissão de eventos. Na prática, a função http.createServer() apenas levanta o servidor. O callback que passamos como argumento (function(request, response)) só é executado quando o servidor recebe uma requisição. Para que isso aconteça, o Event Loop fica constantemente verificando se o servidor foi requisitado. Quando uma requisição chega, ele emite um evento que dispara a execução do nosso callback.

Esse modelo é fundamentalmente diferente do que acontece em linguagens com modelo de threads bloqueantes. Aqui, o servidor não cria uma nova thread a cada requisição: ele despacha o trabalho e segue ouvindo. É por isso que o Node.js é tão eficiente para aplicações com muita E/S (entrada e saída).

O Node.js trabalha intensamente com chamadas assíncronas que respondem por meio de callbacks. Vamos ver isso na prática. Se quisermos receber uma notificação no console assim que o servidor estiver de pé, basta passar uma função como segundo argumento para server.listen():

server.listen(3000, function(){
    console.log('Servidor Hello World rodando!');
});

O método listen também é assíncrono. Isso significa que você só saberá que o servidor está de pé quando o Node invocar a sua função de callback. Não há retorno imediato dizendo “pronto, está rodando”. Em vez disso, o Node avisa quando estiver pronto.

Se você está começando agora com JavaScript, pode estranhar essa prática de passar funções como argumento para todo lado. Isso se chama higher-order functions (funções de ordem superior) e é absolutamente normal no mundo JavaScript. Mas, em algum momento, seu código pode começar a ficar difícil de ler por causa de muitos blocos aninhados. Quando isso acontecer, você pode separar essas funções e dar nomes mais significativos a elas. Veja a diferença:

var http = require('http');

var atendeRequisicao = function(request, response) {
    response.writeHead(200, {"Content-Type": "text/html"});
    response.write("<h1>Hello World!</h1>");
    response.end();
}

var server = http.createServer(atendeRequisicao);

var servidorLigou = function() {
    console.log('Servidor Hello World rodando!');
}

server.listen(3000, servidorLigou);

O comportamento é exatamente o mesmo, mas o código fica mais fácil de ler. Essa técnica é especialmente útil quando os callbacks começam a crescer e a se aninhar. Manter funções pequenas e bem nomeadas é uma prática que vai te poupar muita dor de cabeça no futuro.

Trabalhando com diversas rotas

Até agora, nosso servidor só responde à rota raiz (/). Independentemente do endereço acessado, ele devolve sempre o mesmo HTML. Não é assim que aplicações reais funcionam. Precisamos diferenciar requisições para /sobre, /contato, /produtos e tantas outras rotas que uma aplicação pode ter.

Vamos adicionar uma rota chamada /bemvindo, que exibirá uma página de boas-vindas, e uma rota genérica que servirá como página de erro para qualquer endereço não reconhecido. Crie o arquivo hello_server3.js:

var http = require('http');

var server = http.createServer(function(request, response){
    response.writeHead(200, {"Content-Type": "text/html"});
    if(request.url == "/"){
        response.write("<h1>Página principal</h1>");
    } else if(request.url == "/bemvindo"){
        response.write("<h1>Bem-vindo :)</h1>");
    } else {
        response.write("<h1>Página não encontrada :(</h1>");
    }
    response.end();
});

server.listen(3000, function(){
    console.log('Servidor rodando!');
});

Rode o servidor com node hello_server3.js e teste no navegador. Acesse http://localhost:3000/, depois http://localhost:3000/bemvindo e, por último, algum caminho inventado como http://localhost:3000/qualquer-coisa. Você verá três páginas diferentes.

Repare como o roteamento aqui foi feito de forma bem rústica: usamos uma cadeia de if e else, e a leitura da URL é feita por meio da propriedade request.url, que devolve uma string com o caminho digitado pelo usuário. Funciona, mas em um projeto de verdade, com dezenas ou centenas de rotas, essa abordagem se tornaria um pesadelo de manutenção.

Além disso, URLs reais costumam carregar informação além do caminho. Existem dois padrões muito comuns:

Query strings: parâmetros após o ? na URL, como em ?nome=joao&idade=30.
Path: o caminho em si, como /admin/usuarios.

Para lidar com esses padrões de forma estruturada, o Node.js oferece um módulo nativo chamado url, responsável por fazer parser e formatação de URLs. Vamos ver como capturar valores de uma query string. Crie o arquivo url_server.js:

var http = require('http');
var url = require('url');

var server = http.createServer(function(request, response){
    response.writeHead(200, {"Content-Type": "text/html"});
    response.write("<h1>Dados da query string</h1>");

    var result = url.parse(request.url, true);

    for(var key in result.query){
        response.write("<h2>"+ key +" : "+ result.query[key] +"</h2>");
    }

    response.end();
});

server.listen(3000, function(){
    console.log('Servidor http.');
});

Salve, execute com node url_server.js e acesse algo como http://localhost:3000/?nome=maria&cidade=saopaulo. Você verá os pares chave-valor exibidos na página.

A função url.parse(request.url, true) faz o parser da URL recebida. O segundo argumento true indica que a query string deve ser convertida em um objeto JavaScript (caso contrário, ela viria como uma string só). O retorno dessa função traz vários atributos úteis, que vale a pena conhecer:

href: a URL completa. Exemplo: http://user:pass@host.com:8080/p/a/t/h?query=string#hash
protocol: o protocolo usado. Exemplo: http
host: o domínio com a porta. Exemplo: host.com:8080
auth: dados de autenticação embutidos. Exemplo: user:pass
hostname: apenas o domínio. Exemplo: host.com
port: a porta. Exemplo: 8080
pathname: o caminho. Exemplo: /p/a/t/h
search: a query string em formato bruto. Exemplo: ?query=string
path: a concatenação de pathname com search. Exemplo: /p/a/t/h?query=string
query: a query string já convertida em JSON. Exemplo: { query: 'string' }
hash: âncora da URL. Exemplo: #hash

Em resumo, o módulo url permite organizar toda e qualquer URL da aplicação de maneira estruturada, deixando seu código muito mais limpo e legível do que se você tivesse que separar tudo manualmente com split e expressões regulares.

Separando o HTML do JavaScript

Você já deve ter percebido um problema: até aqui, nosso HTML está escrito como string dentro do código JavaScript. Para páginas simples isso pode até funcionar, mas em qualquer aplicação real teremos HTML extenso, com CSS, imagens e estruturas complexas. Misturar tudo em strings JavaScript é receita para um código impossível de manter.

A boa prática é separar o HTML em arquivos próprios, com a extensão .html, e fazer a aplicação ler esses arquivos quando precisar respondê-los ao usuário. Para isso, vamos usar mais um módulo nativo: o File System, conhecido pela abreviação fs.

O módulo fs é responsável por manipular arquivos e diretórios do sistema operacional. O que ele tem de mais interessante é oferecer praticamente todas as suas funções em duas versões: uma assíncrona e outra síncrona. Por convenção, as funções com sufixo Sync são as síncronas. Veja o exemplo abaixo, que mostra as duas formas de ler um arquivo:

var fs = require('fs');

// Forma assíncrona
fs.readFile('/index.html', function(erro, arquivo){
    if (erro) throw erro;
    console.log(arquivo);
});

// Forma síncrona
var arquivo = fs.readFileSync('/index.html');
console.log(arquivo);

A função fs.readFile() faz uma leitura assíncrona. Depois que o arquivo termina de carregar, a função callback é invocada com dois argumentos: o erro (caso tenha ocorrido) e o conteúdo do arquivo. Já a fs.readFileSync() faz uma leitura síncrona: o programa para tudo e espera o arquivo ser completamente lido para depois prosseguir.

No mundo Node.js, a forma assíncrona é quase sempre a melhor escolha. O servidor não pode ficar bloqueado esperando uma leitura de disco terminar enquanto outras requisições chegam. Por isso, vamos usar a versão assíncrona daqui em diante.

Uma observação importante: o módulo File System não é 100% consistente entre os sistemas operacionais. Algumas funções são específicas para Linux, OS X e Unix, e outras só funcionam no Windows. Sempre que for usar funções menos comuns, vale a pena consultar a documentação oficial do Node.js para evitar surpresas.

Agora vamos juntar HTTP com File System para servir uma página HTML real. Crie o arquivo site_pessoal.js:

var http = require('http');
var fs = require('fs');

var server = http.createServer(function(request, response){
    // A constante __dirname retorna o diretório raiz da aplicação.
    fs.readFile(__dirname + '/index.html', function(err, html){
        response.writeHeader(200, {'Content-Type': 'text/html'});
        response.write(html);
        response.end();
    });
});

server.listen(3000, function(){
    console.log('Executando Site Pessoal');
});

Repare em dois detalhes muito importantes:

A constante __dirname é fornecida automaticamente pelo Node.js e devolve o caminho absoluto do diretório onde o arquivo atual está sendo executado. Sem isso, dependendo de onde o comando é rodado, o caminho relativo poderia quebrar.
A leitura é assíncrona: a renderização do HTML acontece dentro do callback, ou seja, só depois que o arquivo for completamente lido.

Para esse código funcionar, você precisa criar um arquivo index.html no mesmo diretório. Algo simples como:

<!DOCTYPE html>
<html>
<head>
    <title>Olá este é o meu site pessoal!</title>
</head>
<body>
    <h1>Bem vindo ao meu site pessoal</h1>
</body>
</html>

Rode node site_pessoal.js e acesse http://localhost:3000. A diferença em relação aos exemplos anteriores é que, agora, qualquer alteração no index.html pode ser feita sem mexer no código JavaScript. Só recarregar o navegador e pronto. Bem-vindo à separação de responsabilidades.

Desafio: implementar um roteador de URLs

Agora chegou a melhor parte: colocar a mão na massa e juntar tudo o que você aprendeu em um único projeto. Você já conhece os três módulos nativos essenciais para servir conteúdo web: o http para subir o servidor, o url para fazer parser das rotas e o fs para ler arquivos HTML do disco. Hora de combiná-los em algo útil.

O desafio é simples na descrição, mas exige atenção: você vai construir um pequeno roteador de URLs, que renderiza arquivos HTML diferentes dependendo do caminho que o usuário digitar no navegador.

Regras do desafio

Crie 3 arquivos HTML: artigos.html, contato.html e erro.html.
Coloque qualquer conteúdo dentro de cada um dos arquivos. Pode ser um simples <h1> com o nome da página.
Quando o usuário digitar o path /artigos no navegador, o servidor deve renderizar o artigos.html.
Quando o usuário digitar /contato, o servidor deve renderizar o contato.html.
Para qualquer outro path diferente de /artigos e /contato, o servidor deve renderizar o erro.html.
Toda a leitura de arquivos HTML deve ser feita de forma assíncrona.
A rota principal / (raiz) deve renderizar o artigos.html como padrão.

Dicas importantes

1. Use o retorno da função url.parse() para capturar o pathname digitado e renderizar o HTML correspondente. Se o pathname estiver vazio ou for /, significa que deve renderizar a página de artigos. Se o valor for diferente do nome de qualquer arquivo HTML que você tem, renderize a página de erro.

2. Você pode inserir o conteúdo HTML diretamente dentro da função response.end(html), economizando uma linha de código. Em vez de fazer:

response.write(html);
response.end();

Você pode fazer apenas:

response.end(html);

O comportamento é o mesmo, mas o código fica mais conciso.

3. Você pode usar uma estrutura condicional simples para decidir qual arquivo carregar, baseando-se no pathname. Algo na linha de “se o pathname é /artigos ou /, carregue artigos.html; se é /contato, carregue contato.html; caso contrário, carregue erro.html”.

Estratégia recomendada

Antes de sair codando, pense no fluxo da aplicação:

Subir um servidor HTTP na porta 3000.
Em cada requisição, obter a URL chamada.
Fazer parser dessa URL para extrair o pathname.
Decidir qual arquivo HTML carregar com base nesse pathname.
Ler o arquivo de forma assíncrona.
Devolver o conteúdo do arquivo como resposta HTTP com status 200 e content-type text/html.

Esse exercício, embora pareça pequeno, te coloca em contato com a arquitetura básica de qualquer aplicação web em Node.js. Frameworks como o Express, que você provavelmente vai aprender mais tarde, fazem exatamente isso por baixo dos panos: leem a URL, decidem o que fazer, e respondem.

Por que esse desafio importa?

Quando você implementa o roteador manualmente, sem depender de bibliotecas externas, você passa a entender o que acontece quando configura uma rota em qualquer framework. Você sabe que o framework está lendo request.url, fazendo um parser, escolhendo um handler e respondendo. Esse conhecimento é o que separa quem usa ferramentas “por mágica” de quem realmente domina a tecnologia.

Tente fazer o desafio sozinho antes de procurar uma solução pronta. Se travar, releia as seções anteriores deste tutorial. Todas as peças que você precisa já foram apresentadas. O exercício é justamente combiná-las.

Conclusão

Em poucas linhas de código, você passou de zero a um pequeno servidor web funcional. E mais do que isso, você entendeu por que cada peça do quebra-cabeça existe.

Recapitulando o caminho percorrido:

Você descobriu que o Node.js é multiprotocolo e que, no contexto web, o HTTP é o protocolo mais usado e mais bem suportado.
Aprendeu que cada aplicação Node.js é também uma aplicação middleware, exigindo que você programe não só o seu domínio, mas também aspectos da infraestrutura, com a vantagem da customização total.
Construiu seu primeiro servidor com o módulo nativo http, entendendo cada parâmetro: writeHead, write, end e listen.
Compreendeu o papel do Event Loop como motor que orquestra a execução dos callbacks de forma assíncrona, sem bloquear o servidor.
Implementou um roteamento simples com if/else usando request.url, e depois evoluiu para o uso do módulo nativo url com url.parse, conhecendo todos os atributos disponíveis: href, protocol, host, auth, hostname, port, pathname, search, path, query e hash.
Aplicou boas práticas separando o HTML do JavaScript, lendo arquivos com o módulo fs, e entendendo as diferenças entre leitura síncrona (readFileSync) e assíncrona (readFile), além de conhecer a utilíssima constante __dirname.
Recebeu um desafio que combina todos esses conceitos em uma única aplicação prática.

Tudo isso usando apenas módulos nativos, sem instalar uma única dependência via npm. Esse é o tipo de fundamento que vai te acompanhar pelo resto da sua jornada com Node.js, independentemente do framework que você venha a adotar.

A partir daqui, o céu é o limite. Você pode evoluir esse roteador para suportar parâmetros dinâmicos (algo como /artigos/:id), pode adicionar suporte a métodos HTTP diferentes (GET, POST, PUT, DELETE) e pode até começar a servir conteúdo JSON em vez de HTML, criando assim uma API REST completa, ainda sem frameworks.

Mas se em algum momento você sentir que está reinventando a roda, saiba que existe um ecossistema gigantesco de bibliotecas prontas para te ajudar. E quando chegar nesse ponto, você não vai ser apenas mais um copiador de exemplos de internet: vai saber exatamente o que aquelas bibliotecas estão fazendo, porque já fez na unha.

Boa codificação, e até o próximo tutorial.

Leetcode 2

Lex Nwimue P. — Fri, 15 May 2026 01:38:56 +0000

I did LeetCode 2. Yup. That’s the headline. The classic Add Two Numbers.

Submitted my solution thanks to the tremendous help of ChatGPT, but I still feel a bit guilty about it. Afterward, I went down a rabbit hole of trying to convince myself it’s fine not to understand every single detail of every problem on the first pass. Some Reddit comments helped reinforce that idea — learn patterns, don’t memorize solutions.

I agree with that in theory. Which is why I immediately went to watch the NeetCode breakdown on YouTube to actually understand what was going on. I stopped just as the video started playing to write this blabbering. My solution was in Rust, of course, which probably made the whole thing feel more intimidating than it needed to be. But honestly, I don’t think I would’ve fared much better in TypeScript either, so I’m not blaming Rust for this one.

All of this happened in the last two hours.

Earlier in the day, I had been working on something completely different: integrating the HashiCorp Vault Transit Engine for encryption and decryption in an MFA feature I was shipping. The feature was actually complete locally, but we ran into policy configuration issues in dev. That got resolved today, and the frontend team was finally able to integrate it successfully.

Before this, our 2FA system was...let’s just call it creative, in a bad way.

We had two endpoints: /initiate and /validate (Ehn..., tell me about naming conventions 😂☺️). The frontend would call them before allowing users to perform critical actions like withdrawals, transfers etc.

/initiate simply generated a random 6-digit code and stored it in Redis as plain text, keyed by the user’s email. That OTP was then emailed to the user. /validate just compared the input against whatever was in Redis.

If you already think that sounds like an insecure API design, it gets better.

Nothing stopped a malicious user from completely bypassing the whole “2FA flow” and calling the withdrawal endpoint directly. There was no server-side enforcement tying the withdrawal action to a completed 2FA challenge. So effectively, the “2FA” was just client-side theatre. You still needed your PIN and login session, sure — but as far as security layers go, this one was more decorative than functional.

Two years ago, I would’ve been livid that anyone would design it this way. These days, I understand how fast-paced systems can lead to oversights like this. I still don’t see myself making this exact mistake, even when I was a junior, but reality is messy and things slip through.

Since my MFA implementation and some intentional security hardening work across the company, we’ve been closing gaps like this. This particular one is now fixed: every critical action (withdrawals, transfers, etc.) is tied to a scoped MFA session. Meaning an MFA challenge is bound to a specific action and cannot be reused or replayed across different flows.

The frontend and PMs may see it as a “small update,” but any security-conscious backend engineer knows that this is actually a meaningful shift in how trust boundaries are enforced.

On another note, I also had to debug a bug caused by a slightly incorrect use of the dayjs library in a different project.

We had a job that ran roughly like this:

const hasExceededDefaultWindow = dayjs(item.createdAt)
  .isBefore(dayjs().subtract(1, 'day'));

if (hasExceededDefaultWindow) {
  // do something1
} else if (process.env.IS_CHECK_FEATURE_ENABLED === 'true') {
  // carry out check
  // if check is true, do something1 else do nothing
}

The intention was simple:
If item.createdAt is more than 24 hours old, process it immediately. Otherwise, if the feature flag is enabled, run an extra check before deciding what to do.

We had feature-flagged this because even though it had been tested in staging and already deployed, there were still internal reasons to keep the behavior partially disabled in production.

Later, we noticed inconsistent behavior. Some items that were clearly older than 24 hours weren’t being processed. hasExceededDefaultWindow was still evaluating to false, and because the feature flag was also disabled, the fallback logic never ran either. So the job effectively did... nothing.

I’m skipping some surrounding context, but the root cause ended up being subtle behavior around date difference calculations in dayjs.

At one point, the logic was effectively relying on:

dayjs().diff(dayjs(item.createdAt), 'day') > 1

Which actually means:

Only true after more than 1 full day boundary has passed

So in practice:

23 hours → 0
25 hours → 1
48+ hours → 2

Meaning it only becomes true after roughly 48 hours, not 24.

The corrected version is:

const hasExceededDefaultWindow =
  dayjs().diff(dayjs(item.createdAt), 'hour') >= 24;

Or more readable:

const hasExceededDefaultWindow =
  dayjs(item.createdAt).isBefore(dayjs().subtract(1, 'day'));

This didn’t take long to trace — we had Grafana logs showing job execution patterns, so it was fairly quick to isolate. Still, it was one of those “small but annoying” parts of the day.

Now I’ll probably format this properly with ChatGPT, then sleep off while watching NeetCode explain LeetCode 2 again — this time with a little less guilt attached.

Designing Browser-Based Horror Visual Novels Around Atmosphere and Player Attention

wen yong — Fri, 15 May 2026 01:35:36 +0000

Browser-based horror games have a different rhythm from traditional desktop horror. The player arrives through a tab, often with other tabs open nearby, and the experience has to earn attention quickly without relying on scale. For a visual novel, that constraint can actually be useful. The format already depends on reading, pacing, controlled imagery, and a careful relationship between what the player knows and what the story withholds.

A psychological horror visual novel does not need a large simulation to feel memorable. It needs tone, readable interaction, and enough restraint to let the player sit with uncertainty. The browser can support that if the design treats atmosphere as part of the product architecture rather than a layer of decoration added at the end.

Start With a Clear Emotional Contract

Before thinking about routes, menus, saves, or launch platforms, it helps to decide what the first minute should feel like. Should the player feel curious, watched, trapped, amused, or uneasy? That emotional contract shapes the rest of the interface.

A horror visual novel can create tension through simple decisions:

a title screen that does not explain too much
a first scene that makes the player wait slightly longer than expected
character art that changes subtly between lines
audio that enters after the first click rather than autoplaying
text pacing that makes important lines feel heavier

These details sound small, but visual novels live in small details. Because the player spends so much time reading, every pause, transition, and expression becomes part of the experience.

Use the Browser's Limits as Design Material

Browsers prevent autoplay audio in many cases. They also place the game inside a familiar environment: address bar, tabs, extensions, notifications, and the normal texture of the web. A horror game can fight that context, or it can design around it.

The first click can become a deliberate start ritual. A clear Begin button can unlock audio, move the page into a focused state, and transition from ordinary website to story space. Full-screen mode can be offered, but it should not be required. Some players will sample the experience casually before deciding whether to continue.

This is one reason browser access works well for indie narrative games. The low-friction link gets people in the door. If the atmosphere lands, downloadable builds can serve players who want a more focused session.

Typography Is Gameplay

In a visual novel, text is not just UI. Text is the main action. The player advances through language, timing, and implication. That makes typography and layout core design choices.

Long dialogue should use a readable font. Stylized lettering can work for logos, names, chapter cards, or short emphasis, but the main text needs comfort and contrast. The dialogue area should leave enough room for character art and background detail, especially on mobile. If the text box covers the whole scene, the visual storytelling loses force.

Text speed also matters. Slow reveal can create mood, but it should not become friction. A good compromise is to let the default speed support atmosphere while allowing impatient players to advance lines quickly.

State Changes Create Unease

Psychological horror often works through repetition with variation. A line appears again but is slightly different. A character expression changes earlier than expected. A menu label becomes unfamiliar. These effects are easiest to manage when the story state is explicit.

Instead of scattering conditions throughout the UI, developers can keep small state flags for story beats, repeated visits, trust levels, or route changes. That makes it easier to reason about how the same scene should behave after the player has seen new information.

The important point is not complexity. A few well-placed state changes can be more effective than a huge branching structure. Horror benefits when the player feels that the system remembers them, even in quiet ways.

A Useful Example

A project like The Freak Circus is a useful case to think about because its premise is immediately atmospheric: a psychological horror visual novel featuring Pierrot and Harlequin, available online and as desktop downloads. The dark circus setting gives the interface and story a strong visual identity before any mechanic is explained.

That kind of project shows why browser-based presentation matters. The website is not only a download page; it is the first threshold into the tone of the game. The player should understand the genre, the mood, and the available ways to play without being buried under instructions.

Practical Checklist

For developers building browser visual novels, a short checklist can help:

Does the first screen establish tone immediately?
Does the first click intentionally unlock audio or start the scene?
Is dialogue readable across desktop and mobile?
Can players control text speed or advance quickly?
Are story state changes centralized enough to maintain?
Does the website explain online play and downloads clearly?
Are content warnings and accessibility options easy to find when needed?

Conclusion

Browser horror does not need to imitate large-scale horror games. Its strengths are immediacy, intimacy, and controlled presentation. For psychological visual novels, that can be enough. A focused layout, careful text pacing, subtle state changes, and a strong visual identity can turn a simple web-based experience into something that stays with the player after the tab is closed.

Forem

A Secret I Will Never Reveal

My Secret:

AI 週報 — 2026-05-08 to 2026-05-15 | OpenAI 做顧問、Anthropic 做生態，模型公司集體轉向

模型公司集體轉向：從 API 銷售到制度性資源

Apple × OpenAI 裂痕：整合紅利的消散

Anthropic 的長期策略：2028 場景與 Gates 合作

Codex Windows 沙箱：安全不是功能，是成本

監管壓力：法律向量正在加速累積

一個被低估的技術動態：指標式 UI 實驗

Silicon Holler: What Happens When the Brain Drain Finally Stops

What the Research Actually Says

The Structural Advantages Nobody Talks About

The Infrastructure Is Further Along Than You Think

What Silicon Holler Actually Means

What the Region Actually Has

The Path

To the People Who Already Left

To the People Who Stayed

Sources

Stop Paying for Email Verification APIs — A Zero-Cost DNS Approach

Stop Paying for Email Verification APIs — A Zero-Cost DNS Approach

How Email Verification Actually Works

The DNS Trick

Why I Built This as an MCP Server

The Architecture

What I Learned Shipping This

Try It

Python and How Python Is Used In The Data Analytics Space. A Beginner's Guide.

Introduction

Python Libraries Used in Data Analytics.

How Python Is Used to Clean, Analyze and Visualize Data.

Real-World Examples of Python in Data Analytics

Why Beginners Should Learn Python.

Conclusion

5 Token-Saving Habits From 3 Months With Claude Code

5 Token-Saving Habits From 3 Months With Claude Code

01 — /compact: press it on the alert, judge by the next answer

02 — Important work goes to a separate agent, not main

03 — /clear: not compression, full reset

04 — Slim CLAUDE.md, move the rest to side files

05 — 3 skills, loaded only on trigger

Coda — If I had to nail it in one line

Sources · References

What makes an AI image workflow useful for real commercial output?

AI shopping agents have no standard way to verify merchants — so we built one (MCP + verification API)

Palantir: a empresa que transforma dados em decisões operacionais

Desenvolvendo aplicações web com Node.js: do primeiro servidor ao seu próprio roteador de URLs

Por que começar pelo módulo HTTP nativo?

Criando nossa primeira aplicação web

Como funciona um servidor HTTP por baixo dos panos?

Trabalhando com diversas rotas

Separando o HTML do JavaScript

Desafio: implementar um roteador de URLs

Regras do desafio

Dicas importantes

Estratégia recomendada

Por que esse desafio importa?

Conclusão

Leetcode 2

Designing Browser-Based Horror Visual Novels Around Atmosphere and Player Attention

Start With a Clear Emotional Contract

Use the Browser's Limits as Design Material

Typography Is Gameplay

State Changes Create Unease

A Useful Example

Practical Checklist

Conclusion

01 — `/compact`: press it on the alert, judge by the next answer

03 — `/clear`: not compression, full reset