Even if the translation is perfect and "real-time", it comes with a significant latency that will make any conversation less natural. Good for some situations while traveling, not something you would want to rely on for everyday life.
I'm also guilty of this. Related to this thread, some years ago I made a puzzle game with Chinese characters where you get a bunch of components and try to combine them to as many characters as possible: http://www.jiong3.com/pinzi/
It's not just yak shaving though, some programming skills can be really useful when dealing with vocab lists etc..
I've also learned the first 1500 characters using this book, not in one month though.
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.
The big advantage of flashcards in Pleco is the integration with the whole app. If you use the Pleco Reader, you can add new cards directly from the Reader. You can also create cards from dictionary entries and during studying check other dictionaries for each card, play the audio etc.. Some people prefer Anki, but personally I would recommend the Pleco Flashcards for learning Chinese.
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.
I learned a lot about aviation as a kid/teenager playing the Microsoft Flight Simulator. All the important instruments, flight control, radio navigation, flight patterns etc. Good times on Meigs Field.
- 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
I was only referring to the time. "halb drei" is two thirty, which usually means 14:30 unless you specifically say "in the morning". The action in [2] would probably be added if you add a full stop.
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.").
Unfortunately they don't provide any details about the model or the training. Would be nice to have an example as a baseline for real-time performance on iOS devices.
I agree that it works well in the Espace, however my impression is that while in the Model 3 the display is in the center like in the Espace it's also closer to the driver, making the viewing angle larger...