Reprint: The authentic and wild way of technology

*

Reference article: http://mp.weixin.qq.com/s?__biz=MzA4NTg1MjM0Mg==&mid=2657261357&idx=1&sn= Ebb11a1623e00ca8e6ad55c9ad6b2547#rd

*

In the face of a new technology, how can we learn in order to be gradual and ultimately understand deeply?

Let us first list the data available for self-study and analyze:

• Tutorial (Getting Started tutorial). Provided by the official website of the technology. It's usually in English. This information is for the first contact with the technology of the people to see, generally, step-by-step to teach you to complete some examples. When we say that a technology is not very friendly to novices, it is generally because the tutorial part of the technology is not doing well enough.

• Specification, referred to as spec. This is something that concentrates on the design ideas of the technology and is a highly abstract description. This is generally a complete, systematic description, including all aspects of the technology involved. This information is different in different places, it may not be in a relatively simple technical project, in other cases, this part of the information is mixed in other documents; It may also appear as a paper (paper).

• API Reference. Chatty's API index and documentation may provide multiple copies for different language interfaces. When we use this technology to program, API reference is a natural, and always need to constantly query a data.

• Technical blogs written by others. Quality is mixed, in the end there is no value, we have to learn to distinguish.

• Technical books. Similar to technical blogs, quality is good and bad. We'll put together a technical blog to analyze it later.

• Source Code. If the technology we want to learn is open source, then fortunately, we can get the source code. This is a final piece of information.

So here's a selective question: which part of the knowledge do we choose to load into "memory"?

Obviously, priority should be given to choosing the most important information that is most useful to us.

For those core technologies, we should:

• Read through Spec. After reading it is no longer confused.

• Important part of the API Reference to read through. It contains a lot of information about implementation.

• You may also need to read Source CodeIf you need to work. Especially for the usual use of the SDK, do not necessarily read the source from beginning to end, so the workload is too large and inefficient, but must be set up your development environment to a click on a call method can jump into the source code implementation . Only in this way, you can use the usual development time, at any time with the point of the past to see the source code.

For the remainder of the 80% of the knowledge, you should at least understand the spec hierarchy. Only in this way can we use it with ease.

Read through the important spec, in many cases, in fact, it is very difficult. It takes perseverance, and a little bit of English Foundation.

According to the example mentioned earlier in this article, who did Java read the Java Spec? Do android people who put developer.android.com on the API guides can read it down? And the people who do iOS, developer.apple.com on the various programming Guide to read a complete number of? For frequently-invoked SDKs, will you plan to read through the important parts of API reference?

Is it possible not to be a technical bull if you can do this?

*

Reprint: The authentic and wild way of technology