Effective strategies for studying structure / libraries in part

Question

I remember the old effective approach to studying the new structure. This is always the best way to read a good book on this subject, say, MFC. When I tried to skip a lot of material to speed up the coding, it turned out later that the whole book would be read first. There were no good ways to study structure in small parts. Or at least I didn’t see them.

In recent years, a lot has happened: search results from Google, programming blogs, much more people participating in discussions on the Internet, many open source frameworks have been improved.

Right now, when we write software, we often depend on third-party (usually open source) frameworks / libraries. And many times we need to know only a small amount of their functionality to use them. This is just finding the simplest way to use a small subset of the library without unnecessary pessimization.

What do you do to study the structure as little as possible and use it effectively?

For example, suppose you need to index a collection of documents using Lucene . And you need to highlight the search fragments. You don’t care about stem cells by storing the index in a single file compared to several files, fuzzy queries and a lot of other material that will occupy your brain if you carefully study Lucene.

So what are your strategies, approaches, tricks to save your time?

I will list what I would do, although I feel that my process can be improved.

• Search for "lucene tutorial", "lucene highlight example" and so on. Try to evaluate the credibility of the accounts of unofficial articles (blog posts) based on the publication date, number and tone of comments. If there is no definite answer, collect new keywords and links to search the landing page.
• Search for really quick tutorials for beginners / tutorials on the official website.
• Check out how valuable javadocs are for newbies. (Read Lucene Package Summary )
• Find simple examples that come with a library related to what you need. (Study "src / demo / org / apache / lucene / demo")
• Ask about the "Lucene search simple search example" on the Lucene mailing list. You can get an answer or even get a bad reputation if you ask a stupid question. And often you don’t know if your question is stupid because you have not studied the depth of the structure.
• Ask about it in Stackoverflow or another QA service: "Can you give me a working example of search keywords highlighted in Lucene." However, this question is very specific and cannot receive any answers or a poor grade.
• Evaluate how easy it is to get an answer from the structure code if it opens.

What are your search / search routes? Write them in priority, if possible.

Answer 1

I use the three phase API assessment method.

1) Discovery. At this point, I browse through StackOverflow, CodeProject, Google, and Newsgroups with the largest possible combination of search phrases and add everything that might fit my needs into a huge list.

2) Filter / Sort - for each item that I found in my collection phase, I try to find out if it suits my needs. To do this, I go directly to the API documentation and make sure that it has all the necessary functions. The results of this go into a balanced list with the best solutions at the top, and all the breaks are filtered out.

3) Prototype - I accept the best rivals and try to make a small implementation, striking all the important functions. Everything that fits, the best project wins here. If for some reason the problem arises with a better choice during implementation, it is possible to fall away from other implementations.

Of course, a huge number of factors depend on the choice of the best API for the project. Some important ones:

• How much will this increase the size of my distribution?
• How well does the API match the style of my existing code?
• Does he have high quality / any documentation?
• Is it used by many people?
• How active is the community?
• How active is the development team?
• How quickly does the development team respond to bug fixes?
• Will the development team accept my patches?
• Can I renew it according to my needs?
• How expensive will it be realized overall?

... And, of course, many more. It all depends on the project.

As for saving time, I would say that trying to save too much here will just come back to bite you later. The time taken to select a good library is at least as important as the time taken to implement it. In addition, come up with a way, in six months you would rather be happily coded or you would rather argue with a team of xenophobic developers :). Spending a couple of extra days doing a thorough assessment of your options can save you a lot of time later.

Answer 2

The answer to your question depends on where you get on the continuum of community / specificity. Do you want to solve an urgent problem? Do you want to develop a deep understanding of the library? Most likely, you are somewhere between these extremes. Jeff Atwood has a message about how programmers move between these levels based on their needs.

When you first start, read something on the high-level design of a framework or library (or language or any other technology), preferably by one of the designers. Try to determine what problems they are trying to solve, what are the organizational principles of design, and what are the main functions. This will form the conceptual framework from which future understanding will hang.

Now go to it. Create something. Do not copy and paste the code . Instead, when something is not working, carefully read the error messages and the help for these error messages and find out why this error occurred. It can be frustrating when something is not working, but it makes you think, and this is when you study.

Answer 3

1) Google search for my task

2) look at examples with several different libraries , there is no need to bind to Lucene, for example, if I do not know what other parameters I have.

3) Look at the date of the last update on the main page, if it was not updated after a 6-month vacation (with some exceptions)

4) Find a sample library task (don't read the tutorials yet)

5) Can I understand what happens without a tutorial? If yes, continue if not start at 1

6) Try to complete the task

7) Take care of yourself.

8) Read the tutorial

9) Try to complete the task

10) Make sure I refuse and ask StackOverflow or email authors to post to a user group (if they are friendly)

11) If I could complete the task, I would consider a framework worthy of study and read out the main guide for 2 hours (if it doesn’t work after 2 hours, I just ignore what remains until I need it)

Answer 4

I don’t have a recipe, in the sense of a set of steps that I always follow, which is largely because everything I learn is different. Some things are radically new to me (Dojo, for example, I don’t own a Java script, so it’s a big task), some are just improvements in previous knowledge (Iknow EJB 2 is good, therefore studying EJB 3 on the surface is new with all its annotations, building it on concepts.)

My overall strategy, although I would describe it as "Spiral and Park." First, I try to circle the landscape, understand the general form, the Park concept, which I have not yet received, do not let this worry. Then I go a little deeper into some areas, but again try not to get one, Spiraling down into the subject. Hopefully I'm starting to make out and understand, but also need to park more things.

Initially, I want to get answers to questions such as:

• For what?
• Why should I use this and not the other that I already know.
• What is possible? Any interesting sweet spots. "For example, look at this wonderful AJAX update."

I read a lot.

Then I want to explore more on how. I'm starting to look for gotchas and good advice. (For example, in java: why is "wibble" .equals (var) a useful construct?)

Specific methods and sources of information:

• The most important thing: to do! As early as possible, I want to work with a textbook or two. I probably should get the first spiral pattern, but then I want to touch and experiment.
• Document Overview
• Product docs
• Forums and discussion groups, studying the answers to questions, are my favorite technique.
• If at all possible, I'm trying to find a guru. I was lucky that my closest colleagues had a lot of knowledge and experience.

Answer 5

• Quick Start Guides.
• Quickly view API documentation, if available.
• Reading code samples.
• Ruthless YOU CAN MEDIATE THE QUESTION (sorry for the caps).

If it is a small library / API with a small or no community, you can always contact the developer himself and ask for help, because he will probably be more than happy to help you; he is happy that another person is using his API.

Answer 6

Mailing lists are a great resource if you do your homework first before asking questions.

The mailing list archives are invaluable for most of the questions that I had on CoreAudio related materials.

Answer 7

I would never read javadoc. How often are they not. And when there is, most likely, this is not relevant. So you are confused at best.

Start with the simplest possible tutorial that you will find in a few minutes. Often a textbook will lead you to further sources at the end, so most of the time it is on a path that goes on and on, deeper and deeper.

Answer 8

It really depends on what the topic is and how much information is on it. Case study is a good way to start a new topic, especially if you are knowledgeable about other similar libraries or languages. You can take a topic that you are familiar with and say, "I understand how to implement it with X, let's see how it is done with Y."

Answer 9

So what are your strategies, approaches, tricks to save your time?

Ok, I'm looking. I never ask questions at all, preferring to research myself. If it gets worse, I will read the documentation. In some cases (for example, when I was working with SharpSVN) I had to look for a source, in particular, test cases in order to get some information about how the API works.

In general, I have to be honest, most of my “research” and “training” happens by chance.

For example, just a few seconds ago I found out how to get the “recent” folder in C #. I had no idea how to do this before asking a question, considering it interesting, and then searching.

So, for me, the real "trick" is that I stay on the forums, answer questions and accidentally take knowledge. Then when it comes time for me to explore something; Most likely, I know a little about this, and the search is easier, and I can focus on the implementation [usually implementing the first test program] and moving on from there.