Hot House Cucumber and Daikon Radish Salad

5 Hot House Cucumbers
1 Shallot
3 Daikon Kimchi radishes with leaves
1 Tablespoon red pepper flakes
1/2 cup of salt
1 teaspoon sesame seed oil
1/4 cup apple cider vinegar

  1.  Cut cucumbers into squares
  2. Thinly slice the shallots
  3. Put cucumbers and shallots in a bowl
  4. Throw in the salt and mix it.  Let the cucumbers and shallots stand in the salt for 15 minutes
  5. Rinse the cucumbers and shallots in a sieve to remove all the excess salt, and return to the bowl
  6. Add the sesame seed oil, red pepper flakes, and apple cider vinegar to the bowl. Let this sit for 10 minutes or more.
  7. Sieve the cucumbers and shallots, but do not rinse!  You just want to dispose of the excess moisture.  Return the cucumbers and shallots to the bowl
  8. Dice up your daikon kimchi radishes and the leaves and put it in the bowl
  9. Fold in the kimchi and serve

Studying Resources

A great studying resource from Dartmouth’s Academic Skills Center

Dartmouth’s ASC handouts

Effective science reading

How to read a paper

Memorization skills

6 Reading Myths

Joshua Bloch’s API Design Bumper Sticker

The maxims were taken from

All programmers are API designers. Good programs are modular, and intermodular boundaries define APIs. Good modules get reused.

APIs can be among your greatest assets or liabilities. Good APIs create long-term customers; bad ones create long-term support nightmares.

Public APIs, like diamonds, are forever.You have one chance to get it right so give it your best.

APIs should be easy to use and hard to misuse. It should be easy to do simple things; possible to do complex things; and impossible, or at least difficult, to do wrong things.

APIs should be self-documenting: It should rarely require documentation to read code written to a good API. In fact, it should rarely require documentation to write it.

When designing an API, first gather requirements—with a healthy degree of skepticism.People often provide solutions; it’s your job to ferret out the underlying problems and find the best solutions.

Structure requirements as use-cases: they are the yardstick against which you’ll measure your API.

Early drafts of APIs should be short, typically one page with class and method signatures and one-line descriptions. This makes it easy to restructure the API when you don’t get it right the first time.

Code the use-cases against your API before you implement it, even before you specify it properly. This will save you from implementing, or even specifying, a fundamentally broken API.

Maintain the code for uses-cases as the API evolves. Not only will this protect you from rude surprises, but the resulting code will become the examples for the API, the basis for tutorials and tests.

Example code should be exemplary. If an API is used widely, its examples will be the archetypes for thousands of programs. Any mistakes will come back to haunt you a thousand fold.

You can’t please everyone so aim to displease everyone equally. Most APIs are overconstrained.

Expect API-design mistakes due to failures of imagination. You can’t reasonably hope to imagine everything that everyone will do with an API, or how it will interact with every other part of a system.

API design is not a solitary activity. Show your design to as many people as you can, and take their feedback seriously. Possibilities that elude your imagination may be clear to others.

Avoid fixed limits on input sizes. They limit usefulness and hasten obsolescence.

Names matter. Strive for intelligibility, consistency, and symmetry. Every API is a little language, and people must learn to read and write it. If you get an API right, code will read like prose.

If it’s hard to find good names, go back to the drawing board. Don’t be afraid to split or merge an API, or embed it in a more general setting. If names start falling into place, you’re on the right track.
When in doubt, leave it out. If there is a fundamental theorem of API design, this is it. It applies equally to functionality, classes, methods, and parameters. Every facet of an API should be as small as possible, but no smaller. You can always add things later, but you can’t take them away. Minimizing conceptual weight is more important than class- or method-count.

Keep APIs free of implementations details. They confuse users and inhibit the flexibility to evolve. It isn’t always obvious what’s an implementation detail: Be wary of overspecification.

Minimize mutability. Immutable objects are simple, thread-safe, and freely sharable.

Documentation matters. No matter how good an API, it won’t get used without good documentation. Document every exported API element: every class, method, field, and parameter.

Consider the performance consequences of API design decisions, but don’t warp an API to achieve performance gains. Luckily, good APIs typically lend themselves to fast implementations.

When in Rome, do as the Romans do. APIs must coexist peacefully with the platform, so do what is customary. It is almost always wrong to “transliterate” an API from one platform to another.

Minimize accessibility; when in doubt, make it private. This simplifies APIs and reduces coupling.

Subclass only if you can say with a straight face that every instance of the subclass is an instance of the superclass. Exposed classes should never subclass just to reuse implementation code.

Design and document for inheritance or else prohibit it. This documentation takes the form of selfuse patterns: how methods in a class use one another. Without it, safe subclassing is impossible.
Don’t make the client do anything the library could do. Violating this rule leads to boilerplate code in the client, which is annoying and error-prone.

Obey the principle of least astonishment. Every method should do the least surprising thing it could, given its name. If a method doesn’t do what users think it will, bugs will result.

Fail fast. The sooner you report a bug, the less damage it will do. Compile-time is best. If you must fail at run-time, do it as soon as possible.

Provide programmatic access to all data available in string form. Otherwise, programmers will be forced to parse strings, which is painful. Worse, the string forms will turn into de facto APIs.

Overload with care. If the behaviors of two methods differ, it’s better to give them different names.

Use the right data type for the job. For example, don’t use string if there is a more appropriate type.

Use consistent parameter ordering across methods. Otherwise, programmers will get it backwards.

Avoid long parameter lists, especially those with multiple consecutive parameters of the same type.

Avoid return values that demand exceptional processing. Clients will forget to write the specialcase code, leading to bugs. For example, return zero-length arrays or collections rather than nulls.

Throw exceptions only to indicate exceptional conditions. Otherwise, clients will be forced to use exceptions for normal flow control, leading to programs that are hard to read, buggy, or slow.

Throw unchecked exceptions unless clients can realistically recover from the failure.

API design is an art, not a science. Strive for beauty, and trust your gut. Do not adhere slavishly to the above heuristics, but violate them only infrequently and with good reason.

Learning and Productivity

Randy Pausch Lecture: Time Management

How to Use Your Mind A Psychology of Study

How to Read A Paper

6 Reading Myths

Effective science reading

A great studying resource from Dartmouth’s Academic Skills Center

Memorization skills

Summer Reading List

Now that school is over I have time to catch up on my Summer reading list. I am fortunate my school’s library has a very nice selection of books and if I can’t get it there, the Kindle and iBooks stores will.

I seriously doubt I’ll finish even half this list between now and the beginning of the Fall semester, but I wanted to share this with my few blog readers, i.e. friends I tricked into reading my blog.

Thank you to Aaron R, Daniel D, Dan S, Matt K, Rose L, and David F. for their book suggestions.

I will provide links to the rest of the books tomorrow. It’s late and I need sleep :)






  • The Madman by Khalil Gibran

Computer Science


Design & Usability

  • The Design of Everyday Things by Donald Norman


  • Philosophy and the Young Child by Gareth Matthews


  • Zinn & the Art of Mountain Bike Maintenance by Lennard Zinn

OSX Lion Helpful Links

A comprehensive and long review by John Siracusa. *I haven’t read it all yet *

Tricks and workarounds:

Lion security and now with full ASLR support:

Wait, what’s ASLR?

~/Library folder is invisible in finder for Lion. Here is how to make it visible

Macports compiled for Lion

Posted in Mac

OSX Lion First Impressions

I’ll update this list as I go along or become too lazy to continue. Please forgive my stream of consciousness and whining. For an exhaustive list of the new features, go here:

July 20, 2011 12:09 PM
First Impressions

  • My system seems slower
  • I don’t care for the reverse mouse scrolling. I changed that in Settings
  • Spaces is replaced by Mission Control. Instead of a “spaces” like Gnome, you now have “screens”.
  • Maybe it’ll take a while for me to get used to Mission Control, but I prefer how I could view everything easier in the old Spaces. I do like how you can swipe between screens with the mouse in Mission Control.
  • Mail looks much like the iOS version which I love on the iPad and iPhone. It’ll take me a bit to get used to it on a non-touchscreen computer
  • Praise ze gods, Safari has fullscreen mode, but it puts it in its own “space”. If you are on a dual monitor setup, your other monitor is useless. So far this is only in Safari.

edit: I called them “spaces”, but I believe the correct term is “desktops”

Mission Control & Fullscreen Mode
Ok, I get Mission Control now. You two finger double tap on the Apple mouse to go to Mission Control to see everything open on one screen, then you two-finger horizontal swipe to see what’s open in your other screens. The advantage over the old Spaces + Expose way is bigger thumbnails. Personally, I prefer the old version for now, but once I have two browsers, two IDEs, iTunes, Adium, 3 terminals open at the same time, I may change my mind.

Hmm, you can have multiple apps open in fullscreen now. That is cool!

Chrome Navigation
Aww, man, backward and forward navigation is broken in Chrome. Previously, the two finger horizontal swipe was back and forward navigation; now it’ll change to a different “screen”. Well, at least I installed the mouse gestures plugin for Chrome.

Launchpad & Airdrop
Launchpad is pretty awesome! You can group applications together and rename the groups in Launchpad. You can also change the order of the application list. This function is very much like the iOS version. If you prefer to view your applications in the traditional list view, you can still go to your ~/Applications directory.

Airdrop looks pretty cool! I want to try that out as soon as I can.

Something’s Wrong with Macports and Xcode
I think the upgrade did something to macports and Xcode. My vimrc file was also overwritten. Luckily, I had a copy in Devonthink.

The New Gestures & Lion Annoyances
If some of the gestures and options annoy you, you can look here for some tips to revert: I agree with Lifehacker on the new look for iCal. Address Book resembles the iOS version, so it doesn’t bug me so much. I also agree that fullscreen mode bogarts your dual monitor setup, and it’s fun to say “bogart”.

Lion Security
Lion supports full address space layout randomization according to The Register:
Find out more about ASLR here:

July 21, 2011 7:16 PM
My ~/Library disappeared in Finder
Your ~/Library folder is hidden in Lion. To unhide it, type “chflags nohidden ~/Library” in the terminal. The write up is here:

Update to Xcode 4
Xcode 3 does not work in Lion so you’ll have to get it from the App Store for free. I thought it installed last night, but for some reason it didn’t. Go to the App Store and download Xcode 4 for Lion. If it doesn’t start to install after the download, go to /Applications/Install and click on that

Macports for Lion
Whenever you migrate to a new OS, you’ll need to also update Macports. Unfortunately, I had to pretty much reinstall everything to ensure stability.

Here is what the ports site suggested for migrations:

Unfortunately, the migration didn’t work for me so I had to force uninstall after I created my “myports.txt” in step one of the migration tutorial above. It’s very important to get that list of the ports you already have. When you reinstall don’t bother getting the dependencies. Just cherry pick what you actually want and install those programs only.

Here is what I am doing for the uninstall:

To reinstall Macports, refer to the link below. I was able to use the packaged file for Lion. As soon as Macports installed, I ran “sudo port selfupdate”

Some folks claimed that didn’t work, but this one using svn does. It wasn’t necessary for me:

Final Thoughts
The UI improvements are great. As Dr. Chao said, “It’s remarkable the good job Apple did considering they’re merging with a mobile OS”. Aside from the inconvenience of reinstalling Macports, I’m happy as a clam. There may be a less painful way to get ports and Lion to work, but after my recent experience with a fresh, flawlessly working install, I wanted to continue my command-line honeymoon.

For those who are hesitant about migrating to 10.7 Lion, you will be perfectly fine working in Snow Leopard at least for the next couple months. Save your thirty bucks and donate it to Haitian relief, Japanese Tsunami victims, or buy your mother some roses. Do good deeds and make the world a better place, or be like me and drink some decent beer for a change :P

Posted in Mac

Japan Earthquake and Nuclear Reactor Links

Getting organized

Current Status
I’m currently using DevonThink to help me keep track of all my important files and notes. I also use Omnifocus for task management. I use a calendar for time sensitive information. My other tools are more low-tech. I have a small notebook and a legal pad for notes.

Changes since my last great organization
I finally parted with my paper planner. I’ve had a planner or paper calendar of some sort since grade school. I’m on the computer so much that I do most of my time-sensitive entries digitally on a computer.

I would use the paper calendar for a couple weeks, then I would get tired of the double entries and discontinue writing things down by hand. Then several weeks or months later I would feel guilty and go back to the paper calendar. I swear I’m not insane or that stupid, but I was mentally stuck in a habit that I thought I had to maintain or else my entire world would be disorganized. Well, what really happened is the duplication of exertion just made me give up putting minor things on the calendar all together.

Things that weren’t earth-shatteringly important were not entered in the calendar and with all the other things I jot down in notebooks and keep in my head they fell by the wayside. These little pieces of information flotsam & jetsam eventually accumulated into a huge mountain of missed to-do’s that burdened me greatly.

My system is less mentally taxing today. Now I use Google Calendar which is also synced with iCal. DevonThink acts as my inbox and information storage medium. The tiny pocket notebook I carry is also an inbox for little notes and reminders. I also keep a very short to-do list on it.

Plans for the End of Summer

The end of Summer doesn’t really have that much significance to me.  Perhaps, it’s because there’s not much seasonal variation here or maybe I’ve grown into a cynical bastard.  This year I’m bucking the trend and I have a few easy short term goals that I want to see accomplished.

  1. Save some money
  2. Upgrade my computer
  3. Get some road tires for the mountain bike
  4. Work on a couple side jobs
  5. Exercise and eat healthier
  6. Take lots of pictures
  7. Manage my time better