preface

Only a bald head can be strong.

Star: github.com/ZhongFuChen…

I have always advocated that you can write a technical blog to accumulate your knowledge, because there are too many knowledge points. Through your blog, you can quickly review what you have learned.

When I started, I just took notes and thought I could understand them. But if you want to see if you understand, you can write a tech blog. If you’re writing a tech blog, you’re going to find yourself saying, “I don’t know this yet.”

From the process of combing/writing, I will also grow a lot

Many friends have asked me:

  • “3Y how do you take notes? I was watching the video and taking notes, not thinking about my head.”
  • “How do you think about your blog? I can’t blog.”

Here are some of my (personal/subjective) opinions, everyone has their own methodology and my opinion does not apply to everyone.

Start with a picture, all edited:

How to write a technology blog

First of all, I think we should think of ourselves as a sharer and the reader as a white man. Then simulate the scenario: what would you need to do if you were to share the skills you have learned with white.

Following my thinking, I might do something like this:

  • First of all, you have to tell him what the technology is.
  • Then, why do you want to learn this technology, what are the benefits of learning this technology. Is there any previous technology similar to this one? Why do I need to learn a new one instead of the previous one? (This is very, very important)
  • Then, what is the core use of this technology, give some small cases, let the small white experience this technology.
  • Finally, what are the possible problems with this technology? Is there any official solution? If not, what are the possible solutions?

In plain English, this means:

  • What is the
  • why
  • How to do

Generally speaking, I will focus on the why, because I have always believed that learning a skill requires knowing: why to learn.

For example, I wrote the idea of a message queue:

  • To review what queues are, Java already supports various types of queues, as opposed to message queues.
  • Why message queues? Why not? What are the benefits of using message queues
  • Possible problems with using message queues

If the logic may be more complex, or think that the reader will not understand, you can draw a picture to describe, so that the whole article will not be too boring.

In fact, I write articles according to their own learning ideas to write. If I get stuck somewhere in the middle of a study, I assume that the reader will probably have the same problem in the study. So, I will write down my understanding and draw pictures if necessary.

I have written more than 200 Java technology blogs, students in need can follow me on GitHub, welcome to learn and communicate with me: github.com/ZhongFuChen…

Second, the article needs to have its own style

Everyone has their own style of writing a blog.

For example, there are comic books:

For example, there are stories:

For example, there are slutty type:

For example, there are pure dry goods:

Having said all that, what I really want to say is: Blogging should have your own style. Instead of copying and pasting the information on the Internet, there is no emotion and no soul. (Of course, you can do this if it’s possible to do it well online, but it can’t all be the same.)

Third, about typesetting

A good technical article, its typesetting is generally not bad. I think there are a few things about writing technical articles that can improve the reading experience:

  1. Don’t write 90% of your article as code. Reduce the code and stick to the key parts. (The full code can be uploaded to GitHub)
  2. Multi-section technical articles can be relatively boring, and if the technical instructions are crowded together, it may not be a good reading experience
  3. Add graphic description or insert related picture

Programmers use Markdown syntax to write their articles, and if you use it properly, the layout of your articles won’t be too bad. So for those of you who don’t already use Markdown syntax, it’s really easy to learn and use in a matter of minutes.

  • I even had a resumeMarkdownGrammar…

Iv. Tools

For the Markdown editor, I recommend Typora, which works well on both Mac and Windows. When using Markdown, there’s definitely one question to consider: Which one do you use?

No matter which map you use, it’s probably safer (and relatively troublesome) to build your own chart bed, I use the gold digger chart bed myself. My posts are often distributed to several blog sites, such as Jianshu/Zhihu, which upload images to their servers separately.

So, from my personal use point of view, will not worry about graph bed will hang problems. If you are sending articles to only one platform, you still have to be concerned about the possibility that the bed will fail.

As for which platform you post on, I once wrote an article on “Which platforms can Programmers choose to blog on?” , summary at that time:

  • If you don’t mindBlog gardenStyle, you can chooseBlog garden. Otherwise, you are advised to select:The Denver nuggets/SegmentFault.
  • Just want to manage the articles you’ve written, choose:GitHub/GitBook
  • Like to toss:Hexo+GitHuborWordPress

Simple flow chart/mind map /.. This can be done by using ProcessOn.

The last

Some did not pull some, hoping to “there are students who want to write technology blog, but do not know how to start” some help.

This has been included in my GitHub featured articles, welcome to Star: github.com/ZhongFuChen…

Happy to export dry Java technology public number: Java3y. The public account has more than 300 original technical articles, massive video resources, beautiful brain map, attention can be obtained!

Thank you very much talent can see here, if this article is written well, feel “three crooked” I have something to ask for praise for attention ️ to share 👥 to leave a message 💬 for warm male I really very useful!!

Creation is not easy, your support and recognition, is the biggest motivation for my creation, we will see you in the next article!