Tips for Studying

Here are some random tips for being more productive with your time, especially studying, based on all my experience as a college student, and now a grad student:

1. Try to do things in natural lighting conditions. I.e., study in the sunshine (or if it’s too bright, indirect sunlight will do just fine). Your eyes will feel much better.
2. Never study more than 1-2 hours without taking a break. Breaking up your study session into smaller increments is a huge bonus. It gives you an opportunity to relax your eyes (look around your room, or even outside your window for a while), and you can also stretch around your body to get the blood flowing around again. You never want your bloodflow to come down to a crawl when studying. So stretch, walk around, and even do some pushups.
3. Change whatever you’re working on to something completely different, then come back to it for review. A good example: if you’re studying a piano piece by Bach, change to Beethoven or something else immediately after you reach one of your milestones. Or, do something completely unrelated. For me, this kind of randomization helps me retain more information when I come back later for review. The idea is to force your brain to rely on longer-term (longer than, say, your 5-minute memory bank) memory for whatever you were working on originally, when you come back to it later. I.e., what you’re doing is overriding any short-term memory you have on subject 1 with subject 2. This way, you’ll immediately notice any portion of subject 1 that you overlooked or didn’t really cement into your head when you come back to it later. As mentioned above, it works especially well for piano practice.
4. Repeat learned information numerous times. Use flashcards. Use Anki if you want to use flashcards on your computer or laptop.
5. Repeat learned information in different ways (the more different from the original, the better). I.e., do the same thing you learned — but do it differently. E.g., try playing a piano piece from the middle to the end, and then from the beginning to the middle. The idea is to program new neurons to redirect you to the same information. So if you have a math formula memorized, try repeating it aloud instead of writing it out. Write a haiku on it — it doesn’t even need to reflect with 100% accuracy what you learned. Draw a picture. The possibilities are endless.
6. Repeat information in various conditions, and not always when you’re in your “comfort zone.” E.g., repeat what you learned when you’re hungry. And when you’re full. When you’re tired, and when you’re not. It doesn’t have to be just emotional or physiological. It can be physical — e.g., repeat information while having cigarette smoke blown to your face. Repeat information when you’re drunk. Or when you’re on a caffeine rush. The idea is to force your brain to recall information even when in a real, significant state of stress. This is essential if you’re planning on becoming bulletproof in your recall of information in a high-stress environment, such as a final exam.
7. Try to draw connections between what you learned, and what you already knew beforehand (the more different, the better). A good way to do this is to draw as many analogies as possible. E.g., you read a book about a Roman Emperor. Was his life like mine? At which points? Maybe he resembles someone I know. This point is a variation of #5, but with a twist: this focuses more on bringing what you learned together into a more central location in your brain. I.e., if your brain is a statistical chart, what we are trying to do here is to remove any “outliers” and put them closer to where your existing information is. The idea is to remove strange or obscure information, and re-learn them as something familiar. This tip really shines for your most difficult and complex study material, and not so much for easy/less difficult material.
8. Stay healthy — eat right, and exercise regularly. This is the only way of ensuring that your body is giving good, rich bloodflow to your brain for your precious study sessions.
9. Sleep regularly! Sleep defragments your brain. There is NO workaround. Sleep, and even go for naps. More sleep = more retention of information.

That’s all I have for now. You should be well on your way to memorizing things by heart, “forwards and backwards,” if you use the tips above. They worked very well for me, and still do.

UPDATE October 31, 2008: Here are a couple more tips:

1. Break down complex material into its component parts. For example, before embarking on learning something, always read a summary of it first. By reading a cliff notes article, or even scanning the Table of Contents of a particular chapter, you begin the process of breaking down the material into easily-digestible components, even before you actually start “studying”. Just as a top notch mechanic knows every little detail of a motor engine, you need to make sure that you know every single component of a complex idea. Another way of saying the same thing is — chew before you swallow.
2. Explain what you’ve learned to someone who knows nothing about it. If you can do this easily, then you’ve essentially mastered the material. The person you’re explaining it to should be as ill-informed about your subject matter as possible. A skeptic is even better. The idea is to make that other person point out every single imaginable flaw in your understanding of the material. It’s like a torture test for your overclocked CPU. Can you handle the pressure, while maintaining coherence and integrity of your newly acquired data?

Standalone Developer and Git: How to Sync Your Local Repo Across Multiple Machines with a Remote Repository and SSH on Linux

You are a programmer, and you’ve been using git recently after you watched Linus Torvalds speak bitterly against CVS and SVN at Google’s Tech Talk last year. And, although you have git working nicely on your main box, you have multiple computers at your disposal (in your home), and you would like it if you could sync your main git repo from your main box.

Enter the remote git repository. (From now on, I’ll call my main box the remote box, and all newly to-be-synced machines local box.)

First, the requirements: apt-get install ssh. Do this on all your local boxes. To work without passwords every time you invoke ssh with git in the future, follow these steps. When it tells you to do ssh-keygen -t dsa, realize that you have to run this command on your local box (not your remote box), and NOT while logged into an SSH session. I.e., run the ssh-keygen command from your terminal. Also, you only need to follow the instructions until it says “OpenSSH to Commercial SSH”.

So now that you got SSH working smoothly across all your local boxes, it’s time to set up the git repository (“repo”) on your remote box.

1. Either get your hands on the remote box, or use your newly-acquired SSH powers to log into it, and create two new directories, /home/<username>/git, and /home/<username>/git/myappname.git. Do it in Thunar or a terminal or wherever.
2. Now, go into the myappname.git directory. Now type git init –bare. This will create a “bare” repo, that will eventually track all the changes. Think of it as the new “head” or “master” branch, from which all of your machines will eventually pull from. I will call this the remote repo from now on.
3. I’ve thus far assumed that you only have 1 repository for your 1 application that you have been developing, alone, on your remote box. So before we do anything, make sure you and I are on the same page: you have the newly created bare repo from step #2, and you also have a local folder with all your source code (which served as your one and only git repo before reading this blog post). So far, so good. Now, go to this folder containing the existing git repo for your project. From here, you need to tell git that you’d like to sync this local repo with your newly created remote repo (myappname.git from step #1). The idea is to make the remote repo updated with all the changes thus far you’ve made on your local repo, with git-push, and then, from all your local boxes, do a git-pull. So from your local repo containing all your source code, type git remote add origin /home/<username>/git/myappname.git. If you decided to go the SSH route in step #1, the command would be git remote add origin ssh://username@serverURL/home/<username>/git/myappname.git. Here, origin is the nickname of the remote repo, and will be used later on with git-push and git-pull.
4. Now, let’s actually get this remote repo up-to-date with our local repo! First, make sure that you’re on the master branch (or any other branch that’s nice and clean). We will push this branch to our remote repo. Type git-push origin master (or git push origin master if you don’t like hyphens).
5. Almost there! Right now, your remote repo has everything you need to create a copy of the just-pushed-repo-from-step-4 on all your local boxes. Let’s do that now. From your local box type git clone ssh://username@serverURL/home/<username>/git/myappname.git. This will create a directory named myappname from your current directory, with all the source code and goodies!
6. Lastly, let’s edit our .git/config file on ALL MACHINES (both remote and local boxes), by adding the following lines:

   [branch "master"]
       remote = origin
       merge = refs/heads/master
   

7. That’s it! Now, from your local box, work and commit away!! When you’re done, be sure to push to the remote repo with git push origin master (or whatever branch name you are working on). For more info, type git remote show origin, and git will tell you which branches are tracked remotely. For our scenario, it would show the master branch as being tracked remotely. And, don’t forget to do git pull when you’re on a different box, to make sure you’re starting your work from the most recent changes.

So there you go. I read these links to write this post: ssh, git remote repos, default git push and pull. Now, all of your local boxes will function as essentially 1 repo, as long as you git push from 1 local box, and then immediately git pull from all the rest of your boxes. You also get the added benefit of having your source code copied across many machines — a good way of preventing data loss. You could probably even write a bash script so that, from 1 machine, you could execute git pull across all your other boxes to get updated, using SSH.

UPDATE October 27, 2008: Here is a transcript of the speech that Torvalds gave at the Tech Talk, for those of you who hate flash movies (like me).

FYI: Text Files from Linux to Windows XP Notepad

Sometimes when you open up in Windows XP a text file that was created by someone using Linux (e.g., an open source project developer), you’ll get a really ugly block of solid text, with the lines all wrapped around each other. For a long time, I used to get ticked off at whoever had created this file. Well, now that I’ve gotten into programming (Ruby a while back, and now, C++), I’ve now realized that it’s really Windows’ fault, not Linux’s.

In Linux, if you press ENTER to type text on a new line, the program inserts an invisible character called a newline character. This character is represented as ‘\n’ by the program. When you open up the text file later, the text editor will look at all the newline characters, and create a new line each time it finds them.

In Windows XP, and for example in Notepad (and other simple applications), the program expects two characters to denote a newline — the regular ‘\n’ AND another character, the carriage return character, or ‘\r’. Isn’t this redundant and unnecessary? If we’re editing a text file — the only thing we need is a newline character, not a newline AND a carriage return, to denote the beginning of the next line of text.

So take your frustration to Windows. Linux wins once again.