About haotianblog

haotianblog is a bilingual technical blog maintained by Zhonghaotian. It collects long-lived writing about machine learning, algorithm implementation, C/Python programming, network protocols, and engineering security. The site is not a temporary portfolio page or a directory of empty links. Articles, code, experiment output, downloads, and project notes are organized so that readers can inspect them later.

The writing style is implementation-oriented. A strong article should introduce the problem, explain the implementation choices, show runnable code or measurable output, and discuss common errors or boundary conditions. Readers should be able to reproduce the experiment or understand why the conclusion is justified.

Main topics

• Machine learning and deep learning: feature engineering, model evaluation, neural networks, backpropagation, convolution, attention, and small CNN projects.
• Algorithms and low-level implementation: eight queens backtracking, bitmask optimization, K-means, the Iris dataset, CSV handling, and C/Python comparisons.
• Network protocols and engineering security: DNS, TCP, TLS, HTTP/3, proxy boundaries, cache revalidation, AI security threat modeling, and defensive experiments.
• Public resources: small datasets, source code, flowcharts, visualizations, and lab bundles that belong to published articles.

Editorial standards

Each core article is intended to have a clear question, original explanation, and verifiable material. For an algorithm post, that evidence may be complete C/Python code, complexity analysis, or a visible execution process. For a machine learning post, it may be data processing steps, model metrics, and error analysis. For a networking post, it may be protocol fields, latency breakdowns, cache headers, or local experiment output.

The site also includes tools, surveys, resource pages, and share pages. Those pages support reader workflow, but they are not the main indexed editorial content. The durable value is in readable articles and topic hubs that explain technical details and can be checked independently.

How articles are organized

The site is organized around routes rather than isolated posts. A route starts with a practical question, such as how K-means changes its centroids, how a TLS 1.3 handshake separates secrets, how a CNN calculates receptive field size, or how an AI security review turns a model failure into a risk entry. Topic hubs collect those posts with the code, diagrams, downloadable files, and follow-up reading that belong to the same problem.

This structure matters because a short code snippet by itself is rarely enough. A useful technical article should preserve the context around the snippet: input assumptions, environment, parameter choices, expected output, failure cases, and the reason a reader should trust the result. When a page links to a dataset, figure, or script, the surrounding article should explain what that resource proves and what it does not prove.

What is original here

The original work on haotianblog is the implementation path, the explanation around the implementation, and the connection between small experiments and broader engineering judgement. Some posts use well-known public datasets or standard algorithms, but the value comes from rebuilding the workflow, exposing intermediate states, and documenting why a specific design choice was made. For example, an Iris K-means article is not valuable because the Iris dataset exists; it is valuable when the article shows initialization, distance calculation, assignment, center updates, SSE interpretation, and common mistakes in a reproducible way.

The same principle applies to network and security notes. Public protocol documentation already exists, so the site focuses on concrete observations: which header proves cache behavior, which boundary changes what a proxy can see, which metric shows a poisoned model, and which simplification makes a lab safe for education but unsuitable for production. Those details are what separate a durable technical note from a generic summary.

How to judge a page

A strong page should make its value visible without private context. It should tell the reader what question it answers, which assumptions it uses, which files or articles belong to the same route, and what evidence supports the explanation. A hub page is useful when it helps a reader choose the next article and understand why the route exists. A code article is useful when it lets the reader inspect input, transformation, output, and failure cases.

Pages that do not meet that standard are candidates for expansion, merging, redirection, or noindex treatment. This is especially important for pages that contain tools, downloads, or short bilingual summaries. The goal is not to maximize the number of indexable URLs. The goal is to keep public pages clear enough that a new visitor can tell whether the page is an explanation, a project hub, a utility, a legal document, or a support workflow.

The site intentionally keeps some account, mailbox, survey, and workflow pages outside the main editorial value proposition. Those pages can be useful to returning visitors, but the indexed core should remain the technical writing itself: articles, topic hubs, reproducible experiments, project resources, and explanatory routes that stand on their own.

Maintenance approach

The site is maintained as a living technical archive. Older articles may be updated when dependencies change, commands stop working, a downloadable file moves, or a topic needs a safer boundary note. When a page is superseded by a stronger article, the old route should redirect or point clearly to the newer explanation instead of creating several weak pages around the same subject.

Quality work also includes navigation and discoverability. A reader should be able to move from the home page to a topic hub, from a hub to a specific article, from an article to its code or dataset, and back to related material without guessing. That structure helps human readers and also reduces the risk that the site looks like a collection of unrelated thin pages.

Current improvement focus

The current maintenance focus is to make the public site easier to evaluate from the outside. That means keeping the indexable pages centered on articles, topic hubs, reproducible experiments, and policy pages that explain the site clearly. Utility pages such as account, mail, survey, downloads, and share workflows remain available to visitors, but they are treated as support surfaces rather than the editorial core of the site.

For new material, the preferred pattern is a complete route: a hub page explains the topic, article pages carry the technical reasoning, download pages provide only the supporting files, and contact or survey pages collect corrections. This separation helps avoid a common quality problem where a site has many URLs but very little explanation on each one.

Why bilingual

The Chinese side carries the most complete explanations, derivations, and code details. The English side provides entry points, summaries, topic routes, and selected full translations. The bilingual structure is not meant to duplicate pages for volume; it is meant to make the same technical material discoverable for readers with different language backgrounds while keeping page relationships clear.

Updates and contact

haotianblog will continue to be maintained, but low-information pages are not the goal. New work will mainly deepen the machine learning, networking, AI security, and low-level implementation routes. To report a code issue, broken resource, terminology problem, or bilingual link mismatch, use the contact page or email [email protected].

Maintenance work is also part of the editorial process. Older pages are reviewed for broken downloads, outdated commands, unclear diagrams, and missing boundaries between learning examples and production use. When an English page is only a route or summary, it should point to the strongest available article and make the current translation status clear instead of pretending that every language version is equally complete.

The long-term direction is to make each public topic easier to audit: a reader should be able to find the central question, the related code or dataset, the expected output, the known limitations, and the next page in the route without depending on private context. That is the standard used when deciding whether a page should remain indexable.