1. Why does this blog exist?

Actually, looking back at this blog now, I feel a sense of disbelief myself.

I've always considered myself a rather lazy person. When it comes to website building knowledge, such as various codes, databases, and server configurations, I'm basically clueless—I know nine-tenths of the tricks but not the rest. Although I've tinkered with quite a few things in the past for work, such as Linux, Kubernetes, and OpenStack, those were mostly experiments and practices within the work environment. Building and maintaining a personal website from scratch long-term is a completely different matter.

Of course, it's not that I have absolutely no interest in having my own website; it's just that I've always known that starting a project from scratch isn't difficult, but the real challenge lies in consistently investing time and energy to maintain it. Without a sufficiently clear reason, it's hard to commit to doing something long-term.

The initial reason for this blog was actually quite simple: I realized that the things I had struggled with in the past, even though I had spent a lot of time researching and successfully solved the problems, had not truly been retained over time.

Often, when faced with similar requirements again, only vague memories remain. The specific implementation process, key configurations, and problem-solving strategies are difficult to recall. Even more troublesome is that some articles referenced back then, though added to bookmarks, may be inaccessible years later, or the original website may have ceased maintenance or changed domains, making it difficult to find the content again.

Therefore, some problems that had already been solved had to be revisited, requiring me to search for information and explore solutions all over again. After going through this process many times, I gradually realized that if these practical experiences only remained in my memory or relied on constantly changing information on the internet, they would eventually be lost. So I started thinking, since these things are likely to be encountered again in the future, why not record the process?

Initially, it was simply for my own future reference, like leaving a detailed memo for my future self. Unexpectedly, after actually starting to record things, I discovered I was quite a writer. Many experiences that were previously just in my mind, when organized into words, forced me to re-examine the logic and further understand why things were done a certain way, rather than just memorizing a few steps.

As I kept more and more records, another idea came to me: since I've already organized all this stuff, why not just create a website and put it out there? That way, I can also make myself look really awesome.

Of course, at that time I didn't even know what a personal blog was, nor what WordPress was, let alone that there were so many things to consider behind a website—from domain name and server to website structure and theme selection, and then to various plugins, code modification, and performance optimization. I was learning as I went along, researching and figuring things out.

That period was a bittersweet experience. There were many things I had never encountered before, so I had to learn little by little and try and fail. Fortunately, I eventually got through the most difficult initial stage of being a beginner, and at least I went from someone who knew nothing about website building to someone who could independently maintain a personal website—a "half-baked" person.

As the blog content grew, I gradually realized that its significance went beyond simply recording some operational steps. These scattered records began to connect, and I rediscovered that recording is not just about preserving the past, but also about constantly organizing and refining one's understanding.

Thus, this blog, which was initially created as a personal record to "prevent forgetting," gradually transformed into a place for continuously recording the process of learning, practice, and reflection.

And this is why this blog has been able to continue to grow to this day.

2. The direction this blog truly explores

Many first-time visitors to this blog may have a question: why does it include Cloudflare, Docker, home data centers, AI, as well as singing, voice recognition, and even some content about knowledge organization and cognitive methods? These things seem to belong to completely different fields, making it difficult to see any connection between them at first glance.

In fact, I didn't deliberately plan this content at the beginning. Initially, I was just recording what I was tinkering with and learning at the time: whatever problems I encountered, I would research them; whatever interested me in life, I would try them. So, the content in the blog continued to increase with my interests and practices, gradually forming what it is today.

But as I read more and more articles, I gradually realized that what truly attracted me was not a specific technology or hobby, but rather the common question they all pointed to:How can an ordinary person truly understand a complex system?

The "complex system" mentioned here does not only refer to computer systems—it can be a home data center, an entire Cloudflare network architecture, how AI understands language, how the human body makes sounds, or even a constantly evolving knowledge organization system.

These things seem completely different on the surface, but as I really started to study them in depth, I found that they all have one thing in common: they cannot be truly mastered by simply memorizing a few operating steps. Instead, it requires constantly understanding why they are designed this way, why they can work this way, and how the different components influence each other.

That's why, when I write articles, I'm usually not satisfied with simply recording "what to do in the end"—if it's just about getting a copy-and-paste solution, there are already plenty of excellent articles on the internet for reference. What I prefer to record is how a problem is understood step by step, and how a conclusion is derived. Even if the final solution changes with software updates, this process of understanding the problem is often more valuable than the final few commands.

Therefore, many articles on this blog are a bit more "wordy" than typical tutorials. I often spend a considerable amount of time explaining why a problem occurs, what common misunderstandings existed in the past, why there are differences between different solutions, and why the current implementation method was ultimately chosen.

For those who just want to complete the configuration quickly, this syntax might seem a bit convoluted; but for those who want to truly understand the underlying principles, this is often the part that is most worth keeping in the long run.

As my blog content has gradually increased over the years, the areas I focus on have also continued to expand, but the underlying way of thinking has remained unchanged: whether it's home data centers, Cloudflare, AI, WordPress, or sound cognition, these seemingly different fields are essentially about observing the laws governing how things operate from different perspectives. What I really want to record is how an ordinary person gradually forms their own understanding through long-term practice and reflection, and how they solidify these understandings into their own knowledge system.

For this reason, this blog is less of a technical blog and more of a long-term record of the learning, practice and understanding process.

And I hope that many years later, when I look back at these articles, I will see not only what problems I solved back then, but also how I got to where I am today step by step.

3. The Evolution of Blogs

On the surface, the development of this blog seems simple: keep writing articles and keep accumulating content.

But looking at it more deeply, this blog has actually undergone a series of changes in understanding.

Phase 1: From Problem Solving to Recording Experience

The initial purpose of creating the blog was actually very simple: to avoid repeating the same mistakes I made in the past.

The initial notes mostly came from real-world problems. For example, how to deploy a service, how to configure an environment, how to ultimately solve a problem, and what pitfalls were encountered along the way.

At this stage, the blog posts were more like publicly available personal technical notes. The focus wasn't on whether the posts were complete or systematic, but rather on preserving the problem-solving process as much as possible.

Because for many technical problems, what's truly valuable isn't just the number of commands executed, but the analysis, judgment, and trade-offs involved in the process of solving them. If these processes aren't documented, even if you remember "I've done this before" years later, it's very difficult to reconstruct the thought process from that time.

So at this stage, blogs address a fundamental question: how to make past experiences available for future self-discovery.

Phase Two: From Recording Experience to Understanding Patterns

As I recorded more and more content, I gradually realized that simply saving the operation process was not enough, because many problems, although occurring in different fields, often have similar underlying patterns.

For example, topics such as home data center architecture design, Cloudflare-related network optimization, WordPress system modification, and AI knowledge index building may seem like completely different fields, but upon closer examination, they often involve some common questions: How to understand a complex system? How to identify the key factors influencing the outcome? How to design more reliable solutions with limited resources?

Therefore, I began to move beyond simply recording "how to do it" and wanted to further record "why to do it this way." This gradually transformed the articles on my blog from simple operation tutorials into complete summaries that included background, principles, design ideas, and practical experience.

The blog started as a "problem-solving record" and gradually evolved into a "record of the understanding process".

Phase Three: From Knowledge Accumulation to Knowledge Structuring

As my blog content grew, I encountered a new problem. When I first started recording this content, my focus was on a very simple goal: to be able to quickly find solutions to similar problems in the future. At the time, it was enough for me as long as these experiences could be re-located through searching, categorizing, and other methods.

But as I accumulated more experience, I gradually discovered that...Finding a specific answer does not mean you truly understand a field. Because a technological field is not composed of isolated problems, but rather contains multiple interconnected layers: there are basic concepts, practical solutions, optimization processes, and solutions that evolve with technological development.

If content is simply organized by publication time, category, or tag, while the knowledge is preserved, the inherent relationships between the pieces of information are not reflected. Visitors may find answers to specific questions, but they will struggle to understand where that answer fits within the broader field or what to explore next.

This made me realize that the problem that blogs need to solve is no longer just "how to save more content", but "how to make the saved content form a structure".

So I started trying to reorganize the knowledge system in my blog: using knowledge maps to show the overall framework of different fields; using series of articles to organize the development process of continuous topics; using content structure prompts to allow individual articles to return to a larger knowledge system, and gradually exploring how to enable visitors to understand and learn this content according to a certain path.

During this phase, the focus of blogs gradually shifted from "recording knowledge" to "organizing knowledge." Blogs also began to evolve from a simple collection of articles into a structured knowledge system.

Phase Four: From Knowledge Structuring to Exploring Knowledge Connections

As the knowledge structure gradually improved, I discovered another new problem. Even with organizational methods such as classification, series, and knowledge maps, the connections between a large amount of content still could not be expressed because traditional information organization methods essentially rely on manually defining relationships in advance.

For example, an article about Cloudflare network architecture, an article about AI Embedding, and an article about sound resonance mechanisms might belong to completely different fields according to traditional classification methods.

However, a deeper analysis reveals that they all likely address similar underlying issues: how to understand key variables in complex systems, how to establish more efficient information transmission methods, and how to improve the final outcome by adjusting underlying mechanisms. These connections cannot be reflected by simple classifications and labels.

Therefore, I began to try to use AI-related technologies to further process blog content. For example, I used Summary to extract the core information of the articles, used Embedding to convert the articles into semantic representations that can calculate relationships, built semantic indexes to enable new connections between articles, and explored the topic space to gradually reveal hidden connections between different fields.

At this stage, the blog no longer explores just "how to organize existing knowledge", but further considers: how to discover the relationships between knowledge that were not previously noticed?

Now: A continuously evolving personal knowledge system

Looking back, the development of this blog is actually a reflection of my own evolving understanding of knowledge. Therefore, this blog is no longer just an article publishing platform, nor simply a personal technical notebook. It's more like a constantly evolving personal knowledge system: articles preserve specific practices, summarize and extract the underlying patterns, knowledge maps organize the domain structure, and AI semantic technology helps explore the hidden connections between different pieces of content.

In the future, as content continues to accumulate, this system will continue to evolve. Because what is truly valuable is not just the number of articles stored, but the continuous generation of new understandings, new connections, and new possibilities through long-term practice.

4. The qualities I hope my articles will possess

As blogs have continued to develop, I've gradually realized that what's truly changing isn't just the content and structure of blogs, but also my own writing style.

It was through continuous writing and practice that I gradually formed some writing principles that I still adhere to today. These principles were not conceived at the beginning, but rather gradually formed through repeated practice, writing, and continuous revision and understanding.

First, I hope that the practical content in my blog is something I have actually verified myself.

Most of the articles on deployment, configuration, and various practical experiences in this blog come from my own actual tinkering process. Some solutions were even run in my own environment for a long time before being compiled into articles and published. This is not to prove anything, but because this blog is also written for my future self. If I haven't actually practiced them myself, then when I look back at these contents a few years later, they will be of no reference value.

Of course, software versions will be updated, and environments will change, so many articles will be continuously supplemented and revised as new practices emerge. I don't aim for "one-time completion that is always correct," but rather hope that it can truthfully record my understanding and practice at different stages.

Secondly, I prefer to explain "why" rather than just "how".

Many technical articles directly provide the final configuration method, which can certainly solve the problem quickly. However, I always feel that what is easily forgotten are often the specific operational steps, while what truly endures is understanding the reasons behind those steps.

Therefore, in many articles, I spend a considerable amount of time explaining why a technology emerged, what problem it solved, and why it gradually evolved into its current form. Sometimes, to explain a principle, I even start with a lot of seemingly unrelated background knowledge.

This approach is not intended to increase the article's length, but rather to ensure that once readers truly understand the underlying logic, they can find new solutions based on their own understanding, even if future software versions change, rather than mechanically following the tutorial step by step.

In addition, I hope this blog can truthfully record my understanding process, rather than deliberately packaging myself as someone who "knows everything".

After publishing many articles, I continue to revise, supplement, and even overturn some of my previous understandings. As I gain more and more practical experience, my understanding of the same issue will constantly change, and I believe that these changes themselves are a very valuable part of the knowledge accumulation process.

Therefore, many of the articles here are not the final answers to a particular question, but rather more like a continuously updated learning log. It records not only the final conclusions reached, but also how I arrived at those conclusions step by step.

Finally, I increasingly hope that these articles will become more valuable over time, rather than becoming increasingly outdated. Technology develops rapidly, and many specific configuration methods may be completely different a few years later. However, the real reasons that drive technological development, the evolutionary relationships between different solutions, and the ways of thinking formed when solving problems often remain for a much longer time.

Therefore, in the past year, I've started paying more and more attention to these aspects when writing articles. I hope that even if a command changes or a software is updated in the future, readers will still be able to understand why the technology has evolved to its current state through my articles, and use that understanding to continue exploring new topics.

This is why I hope this blog can continue for a long time—it not only records what I have done, but also why I understand these things in this way.

5 My way of thinking

If the previous chapters explained why this blog exists, what it focuses on, and what characteristics I hope the articles will ultimately present, then there is a deeper question: why have these articles gradually developed into their current style?

The answer actually comes from some habits I've developed over time when facing problems. These habits weren't deliberately designed from the beginning, but rather gradually formed through continuous practice, learning, and summarizing. As I've been blogging for longer, I've gradually discovered that what truly interests me isn't just the solutions to specific problems, but rather the reasons, patterns, and evolving processes hidden behind these problems.

I prefer to understand "why" first, rather than just memorizing "how".“

Many technical problems ultimately boil down to specific actions: executing a few commands, modifying some configurations, deploying a service, or choosing a solution. These steps are important because they help solve the problem.

However, for me, simply memorizing a few steps isn't enough to truly master the problem. As software versions and technologies change, methods that were once effective may gradually become obsolete. Without understanding the underlying reasons, it's easy to fall back into a cycle of endlessly searching for answers.

Therefore, when writing articles, I usually try to keep asking questions: Why did this problem occur? What limitations did this solution solve? Why did new solutions emerge later?

Often, the real value lies not in the last few lines of configuration, but in understanding why things should be done the way they should be after comprehending the entire process.

I am used to understanding things through evolutionary processes.

I'm increasingly convinced that much knowledge doesn't exist in isolation. A technology, tool, or solution we see today is often the result of accumulated problems from the past. For example, the development of web technology, from early static pages to dynamic websites, then to front-end/back-end separation, server-side components, and various new rendering modes, is essentially not a simple replacement of existing technologies, but rather a continuous process of solving problems encountered in the previous stage. Similar situations exist in areas such as network architecture, storage technology, and artificial intelligence.

If you only focus on the final answer, it's easy to understand knowledge as a bunch of scattered conclusions; but if you put it back into the process of development, you can see why it appeared and where it might continue to develop in the future.

Therefore, when I write articles, I usually focus more on the development logic behind a technology or concept, rather than simply introducing what it is now.

I am used to looking for common structures between different fields.

As I've explored more and more fields, I've gradually discovered that many seemingly disparate problems actually share some similar underlying patterns. For example, knowledge organization in blogs, semantic vectors in AI, data transmission in networks, and architectural design in software systems, while appearing to belong to different domains, often involve similar questions upon deeper analysis: How is information organized? How is complexity reduced? How are relationships established between different objects? How does the system evolve as it grows in scale?

That's why I later started trying to build knowledge maps, learning paths, semantic indexes, and topic spaces. These attempts weren't simply about adding features to the blog, but rather about exploring a better way to structure previously scattered information into a clearer framework.

I prefer to let practice drive my understanding rather than just staying at the level of theoretical learning.

Many of my articles are not the result of pre-planned topics and systematic learning. More often, they stem from real-world problems encountered: generating a need → attempting to solve it → encountering difficulties → researching → practical verification → summarizing experiences.

This approach has one key characteristic: it forces you to confront the various details of a real-world environment. Many problems may seem very simple if you only stay at the theoretical level; however, once you start practicing, you'll discover a large number of hidden issues, and these issues are often the true gateway to understanding a technology.

Therefore, this blog does not simply record the process of learning a certain knowledge point, but rather the process of continuously building understanding through real-world practice.

Looking back, these ways of thinking have also influenced the development direction of this blog. For a personal blog that has been developing for a long time, what can truly generate value continuously may not be a specific answer, but rather a method that can still help oneself and others understand new problems in a constantly changing environment.

6. About the author

I have been working in IT for over twenty years, experiencing several stages of the continuous development of internet technology. Initially, I was primarily responsible for network infrastructure, from building small to medium-sized networks to deploying more complex network environments, accumulating extensive practical experience in low-level networking. Later, I joined the general distributor system, where I began to work with more enterprise-level products and solutions, participating not only in pre-sales technical communication but also handling post-project implementation and delivery. Subsequently, I joined the original equipment manufacturer (OEM) system, working as a sales engineer, where I was more involved in technical solution design, product technical communication, and project implementation support from the manufacturer's perspective.

These experiences at different stages have also allowed me to understand the ever-changing ways technology works: from initially focusing on device configuration and network connectivity, to later focusing on actual enterprise needs, overall solutions, and the design philosophy behind technology products, my focus has gradually expanded from a single implementation level to solution design and system understanding.

It was through these different stages of practice that I gradually realized that technology is not just a set of tools or operating methods, but needs to be understood in conjunction with actual scenarios, changing needs, and industry development. What is truly worth paying attention to behind technology is not just how to use a certain tool, but why it appeared, what problem it solved, and why it continues to evolve with changes in the environment.

This understanding of technology has gradually extended from my work experience to my daily life. Even after leaving the technical environment of my daily work, I have maintained the habit of exploring, practicing, and summarizing, and I have gradually accumulated these experiences in this blog.

Therefore, for me, maintaining this blog is not about showing off how much technical skill I've mastered, but rather about recording the experiences I've truly verified in practice, the problem-solving approaches I've developed, and the understanding I've accumulated. It's convenient for future reference and hopefully can also help others who encounter similar problems.

Besides technology, I also have some long-standing interests.

One of my most important interests is collecting and organizing film and television resources. This process may seem like simple collecting, but it actually requires long-term accumulation, continuous maintenance, and constant optimization of the organization methods. From discovering new content to establishing a categorization system, and then being able to quickly find the resources you need even years later, this process has many similarities to maintaining a blog.

Another long-term interest I've pursued is singing. Initially, it was simply because I loved music, but through continuous practice and learning, I gradually discovered that the voice itself is a system worth exploring over the long term. From physical condition and vocal techniques to auditory feedback and training methods, each aspect has its own underlying principles. This has made me realize that many things that seem to rely on experience or talent can actually be developed through continuous practice and understanding, allowing one to gradually build their own understanding.

Technology, music, knowledge organization, and even some later reflections on cognition and life—these seem to belong to completely different fields, but they actually share a common thread:We continuously explore the laws governing how things work, and try to organize and solidify these understandings.

Therefore, this blog ultimately becomes not simply a website for recording technical articles, but a place to record my long-term learning, practice, and reflection process. It contains technology, music, knowledge organization, and explorations about cognition and life. Together, they form part of my ongoing journey of understanding and learning about the world.

7. Contact Information

If you have any questions or suggestions about the content of this blog, or if you would like to discuss certain technical or knowledge-related topics, you can contact me through the following methods.

Mail:

[email protected]

My Telegram group:https://t.me/tangwudiblog