340 karma · joined October 15, 2015
I would personally recommend: Secret, On Children, A Sun, Light the Night, Office Girls, Scissor Seven, Ancient Detective, Back to 1989
Adding too many words to Pleco SRS over a short time doesn't work well, you will get overwhelmed with reviews quickly. So if I decide to study the words for a tv show I take some time between the episodes to prepare for the next ones, depending on how many words I have to learn it could be days or weeks.
Which searches are you referring to?
For people learning Mandarin I provide some information including word lists for a lot of shows on Netflix here:
It's not just yak shaving though, some programming skills can be really useful when dealing with vocab lists etc..
The method works but has some problems. Maybe the biggest problem is that it completely ignores pronunciation. It does not help you remember the pronunciation and it does not make use of the sound components of the characters. Most characters are composed of one component which hints at the meaning and another which hints at the sound, e.g. 青 is the sound component in 情清輕請, all of those are pronounced qing (with different tones). Usually it's not that obvious, this is just a good example. The left component in those characters would hint at the meaning.
The Heisig method instead creates a mapping between a keyword, which is derived from a single meaning of the character or invented for components which don't have a meaning, to the written form of the character using mnemonics. This works well in the beginning but once you reach a more advanced stage where you know how to say something in Chinese but maybe forgot how to write the characters this doesn't help you much since the pronunciation is not incorporated into the mnemonics.
When you are just starting out and learning all those characters seems like an unmanagable task, the Heisig method can provide a good structure to quickly "learn" many characters (keyword<>writing). It's also fun to come up with stories and images. But in the end it can only provide a basic scaffold for learning more meanings, pronunciation, words etc.
I even made a small game once using those character decompositions: http://www.jiong3.com/pinzi/
Also useful for this kind of analysis: https://www.chinesetextanalyser.com/
I'm doing something similar but instead of reading native books I'm still sticking to readers with increasing difficulty so that I don't have to look too many words up while reading. Since the readers also include word lists I can learn almost all of the words beforehand.
My reading list (traditional characters) is here: https://www.chinese-forums.com/forums/topic/44336-graded-rea...
# Getting familiar with a new codebase
### Use the right tools
- grep, ack, ag, global search (Visual Assist)
- doxygen, javadocs
- sourcegraph, pfff (facebook), open-grok, SourceInsight
- Proper IDE, REPL
- chronon (dvr for java)
- SWAG (Software Architecture Group)
- Static code analysis
### Use the repository
- Find most relevant (frequently, recently edited) files
- Find dependancy graphs
- Get basic information like which languages are used for what
- Use good source control so that you don't have to worry about breaking things
- Look at commits, in general or for specific issues
- Browse the directory structure, packages, modules, namespaces etc.
- Use "blame" to see when things changed
### Ask questions
- Talk to the customer, find out the purpose of the application
- Pair up with another developer who is more familiar with the code
### Read the documentation
- Look at use cases, diagrams describing architecture, call graphs, user docs
- Understand the problem domain
- Add more documentation as your knowledge grows
- Comments and docs might be wrong!
### Browse the code
- Skim around to get a general idea and a feeling for where things are
- Look at public interfaces, header files first
- Find out which libraries are used
- Take some important public API or function in the UI and follow the code from there. Find implementations of functions, dive into related functions and data structures until you understand how the it's done. Then work your way back out.
- Use tools to quickly find declarations, definitions, references and calls of variables/functions/etc., usage patterns
- Find the entry point of the program
- Figure out the state machine of the program
- Focus on your particular issue
- Use a large, vertical screen with small font size with a pane to show file/class structure
### Take notes
- Use pencil and paper to write down summaries, relationships between classes, record definitions, core functions and methods
- Write a glossary: Function names, Datatypes, prefixes, filenames
- Document everything you understand and don't understand
- Use drawings to create a mental model
### Look at the data
- Find out how the data is stored in the database
### Build the project
- First make sure you can build it and run it
### Use the debugger, profiler and logging
- Set breakpoints, poke around the code, change variables, inspect local variables, stack traces, ...
- Watch the initialization process
- Start from main() and see where it goes
- Find hotspots with the profiler
- Set logging level to max/add logging and use the output to go through the code
### Edit the code
- Adopt the existing coding style
- Try to recreate and fix small bugs, make sure you understand the implications of the fix to the rest of the program first
- Tidy up the code according to the common standard after talking with the team
- Make the code clearer (best with tests)
- Add TODO comments
- Add comments describing what you think the code does
- Hack some feature into the code, then try to not break other stuff, build up a mental model over time, re-write the feature properly
### Use Tests
- Run the tests, make sure they are all passing
- Create new tests
- Browse the tests as an examples reference
https://www.visitberlin.de/en/tempelhofer-feld-tempelhof-fie...
-> À trois heures et demie
-> 14 h 30 du soir,
-> À 14 h 30,
-> On va au cinéma à 14h30.
Correct for everything but the first, not sure why it added "du soir". For the a complete sentence "Um halb drei gehen wir." it's also correct ("On part à 14h30.").
Um halb drei gehen -> Aller à deux heures et demie
Um halb drei gehen wir -> A quatre heures et demie nous partons
Um halb drei gehen wir ins Kino. -> A trois heures et demie nous allons au cinéma.
"And if thou wilt not, I shall need violence."