Welcome to haotianblog: what this bilingual technical site covers

haotianblog is a public place for long-lived technical writing, engineering experiments, and implementation notes. It is not a placeholder page and it is not meant to be a collection of empty links. The main pages are organized around reviewable articles, runnable code, downloadable companion files, and engineering decisions that can be inspected later.

The site is currently strongest in Chinese while keeping English topic hubs and selected English articles. That structure lets the Chinese side carry detailed explanations and lets the English side expose the themes, keywords, project routes, and future translation paths more clearly.

Content scope

The writing is centered on three technical areas. The first is machine learning and deep learning: datasets, feature engineering, training and evaluation, matrix calculus, backpropagation, convolution, attention, and small CNN projects. The second is algorithms and C/Python implementation: eight queens backtracking, bitmask optimization, K-means clustering, CSV parsing, and visualized output. The third is network protocols and engineering security: DNS, TCP, TLS, HTTP/3, proxy boundaries, cache revalidation, AI security threat modeling, and defensive experiments.

The goal is to avoid short summaries that only state conclusions. A useful technical article should explain why a method is used, how to verify it, what can go wrong, and whether the code output supports the claim. Pages that are mainly tools, surveys, share actions, or resource indexes remain accessible, but they are not treated as the core editorial content of the site.

Where to start

If you are starting with machine learning, begin with Machine Learning Workflow, then continue into Model Training and Evaluation, Python AI Mini Practice, and the K-means Iris C implementation. That path connects data, features, models, and evaluation instead of jumping straight to library calls.

If you want lower-level implementation practice, start with eight queens backtracking and the bitmask version. These two articles use the same problem to compare recursive search with compact bitmask state, making recursion, pruning, and complexity easier to inspect.

If you are interested in networking, open Network Fundamentals Visualized and continue through DNS, TCP, TLS, HTTP caching, and proxy trust boundaries. The networking material uses local models or deterministic scripts by default and does not provide an external proxy service for bypassing access controls.

Code, data, and companion resources

The C/Python code, CSV samples, diagrams, and lab bundles on this site exist to support the articles. They are appropriate for education, academic study, course practice, and personal reproduction, but they should not be copied into production systems without review. Each resource is tied back to the article context so that a download is not separated from the assumptions behind it.

Companion files are intentionally small and inspectable. A file is useful when it reveals data layout, algorithm state, evaluation metrics, or visualization output. Large datasets, real attack environments, and configurations that could be misused are handled with additional boundaries and are represented with safe toy examples or defensive analysis instead.

Editorial Evidence Map

The core articles are designed to leave reviewable evidence. A reader should be able to see not only what the conclusion is, but how the conclusion can be checked.

The editorial standards this site actually applies

“Checkable” above is not a slogan; it corresponds to a few concrete checks run before every post. Stating them here lets readers know what to expect, and makes it easier to call me out when I fall short.

• The same thing does not get published twice. Every new article is compared for similarity against everything already on the site before it goes live (character n-grams for Chinese, word n-grams for English). This check has genuinely stopped a post: a draft about TLS debugging turned out to share almost its entire framing with an already-published article, and it was deleted rather than published.
• Errors are corrected in place, with the correction stated. Technical writing goes out of date and sometimes it is simply wrong. My approach is to fix the article rather than publish a separate correction, because readers generally see only one of the two. An example: an article on multimodal deployment described KV cache memory as growing “quadratically” when the growth is linear, and in the same piece the token count for a 4K image was overstated by 3.7×. Both are now corrected in the text.
• Numbers in an article should be recomputable. Formulas, estimates and measurements come with the computation or the command where possible, so a reader can verify rather than take a conclusion on trust.
• The limits of a method are stated. The conditions under which an approach stops working are frequently more useful than the conditions under which it works. Known issues left unfixed are written up with the reasoning and a risk rating rather than passed over.

Correspondingly, a few things this site does not do: publish short conclusion-only pieces to maintain a posting cadence; republish the same material under a new title; or sacrifice readability to keyword density for SEO.

Maintenance principles

This blog will continue to change, but it should not publish low-information pages just to look active. The stronger goal is to make the articles connect into clear knowledge routes: concepts, runnable code, experiment results, error analysis, and next reading steps. When a new page is published, it should have enough body content, a clear editorial purpose, and evidence that a reader can independently inspect.

If you find a problem in code, downloads, terminology, or bilingual page mapping, use the contact page or email [email protected]. The long-term aim is a maintainable technical knowledge base that is useful to readers, not a thin collection of search landing pages.