Writing a blog on the blockchain is a challenging task. Its transparent operations and irreversible nature make me hesitant to click the "publish" button in front of the article editor interface.
The Surfing Guide (this blog) is like a networked reference book, with content roughly divided into two parts. The first part tells you what I know, which may be mature projects or patterns, or fresh things, exploring the richness and fun of the Internet. These contents are summarized as the Surfing Guide. The second part leans towards practical hands-on operations, ultimately solving or achieving a problem. You can understand it as a form of tutorial. These contents are summarized as the Operation Manual.
I used a blockchain project called Press.one extensively in the early years. The two are similar in terms of their models, but the solutions are completely different. I can't remember the relevant details here. But personally, I prefer xLog, just like the current version of the official website describes it as "xLog is the best open-source blog community on the chain for everyone." No code is my gospel. As for transparency and other things, I check for typos multiple times before publishing to reduce my OCD and overcome the barriers to publishing.
In an article by Tim Stoddart, he mentioned the concept of "publishing barriers," which inspired me.
I am not suffering from writer's block. I am suffering from publisher's block. I am suffering from the fear of putting myself out there to be scrutinized and judged. It’s not that I have nothing to say, it’s that I think what I have to say isn’t any good.
Supplementary explanation about the "Operation Manual".
Internet users have different standards for the quality of tutorial materials, and I am a typical example. (It's a bit like some programmers' first wheel being a website navigation or note-taking tool.) Most tutorials are initially developed by developers (here comes the value) and serve as project documentation to inform users of some important considerations and operational steps. People with strong hands-on abilities and the ability to understand code can experience it immediately. Whenever I encounter such a situation, I envy programmers. There are so many magical and interesting things, great open-source communities. Where do they come from?
Because of my self-abandonment in programming, some documents and project introductions are like decryption games to me, except that I understand the meaning of Chinese characters and English. There are some basic technical accumulation issues here, and some things don't need much explanation for a certain group of people (I guess it's similar to some websites sharing keywords for benefits. When they say "open XX search," experienced users know how to do it, but novices may not understand how to open XX search. Do they need to download software? In fact, what they mean is: the first step is to open the XX browser or any browser on the computer, and the second step...).
Here, I have to mention, it's also my personal complaint. Some programmers and developers are indeed very skilled, but their expression abilities are a bit awkward. When I bother them with such trivial matters, I can only find solutions through search engines (the wisdom of reading questions). The Internet is indeed great, and many people share tutorials. Some may come from a background in new media, with good expression abilities and well-designed websites. After looking at several search results, I found that they are just copying and pasting without any changes. So I have to spend more time "decoding" the documents, gradually understanding some methods through a little trial and error, and writing them down in a local Word document. Why not publish them? That's how the Operation Manual came about.
I originally wanted to write a simple "hello, world" and end it, but unexpectedly, I wrote so much in one breath. It seems that my love for independent blogs is still alive...
Finally, I will answer some questions that friends may raise when they see this. "Why don't you learn to code if you envy programmers?" Because I am a product manager. (I have a feeling of contradicting myself. A voice in my mind says, "Learn a programming language. It can solve a lot of problems and make it more exciting to tinker with." Another voice says, "Don't learn it. You definitely won't be able to learn it. You have been exposed to the Internet so early. If you were going to learn, you would have learned it long ago. Why haven't you learned it... When it comes to coding, I tend to lean towards sketches + wireframes + high-fidelity mockups.)