Thursday, August 30, 2012

How to transfer iPhone contacts to gmail contacts for Android

I got a new Android phone, galaxy nexus, and was wondering how I can transfer all my contacts from my old iPhone. Those contacts are in iCloud, which makes it pretty easy, through .vcf format export and import.


1. Go to icloud.com and login using iPhone account
2. Click Contacts
3. Choose all contacts, using Ctrl-A (command-A in mac)
4. Click gear box, and choose "Export vCard"
5. It should download one .vcf file with all contacts
6. Go to gmail contacts (in gmail's left top, click "Gmail" and choose "Contacts")
7. click "More" and choose "Import"
8. click choose file, and choose the .vcf file created above
9. Click import, and you're done!

Tuesday, February 24, 2009

CUE DBMS

Some day, I'd like to build a DBMS with the following three properties, called CUE properties:

1. Cheap (or Cost-effective)
It should be cheap. Or, users should be willing to pay for what they get. In other words, work-done-per-dollar should be high. Pay-as-you-grow or SaaS model may also nicely fit for this, but in-house DBMS should also have a low cost to own, to administer (see Easy-to-use as well). Increase in cost should be justified by the increased output of the system. To realize it, DBMS will have to be built on commodity HWs, without any special interconnect or processing unit. More research will be needed to optimally exploit next-generation commodity HWs, such as many-nodes and flash memory.

2. Useful
It should be useful. It's more like a constraint that should be met, rather than an optimization objective, I believe. Below are vague specification of possible usefulness criteria.
- reasonably expressive: somewhere between key-value storage and SQL?
- reasonably fast: rather than being super-fast, certain hard-bound time limits should be met
- reasonably consistent: query answer should make sense (yup, it's a very unclear statement)
- highly available: it should serve requests at most of times. (how many nines?)
- highly scalable: it should adjust to the dynamic workload in an incremental fashion

3. Easy-to-use
User should not need to know too much about DBMS. It should be:
- nice user interface: HTML-based GUI
- self-tuning: physical design automatically done, continuously re-tuned in incremental fashion
- self-monitoring
- self-healing

Friday, February 20, 2009

Train incidents

I take Capitol Corridor between Berkeley and Silicon Valley for my daily commute. It takes about 1hr 15min on the train for one-way. Including the walk to Berkeley station and the driving to the work, it takes about 2hrs in total, for one-way.

Yesterday, there were TWO train incidents: one in the morning, and another in the afternoon. It was my first experience since January, and it was a very bad one. I later found out that one person died in the morning one, which seems to be suicide, by the train that I was about to ride, about 5 mins before I ride it.

It also took 3 additional hours on the way to work, and 2 additional hours on the way back home. Total, I spent 9 hours on the way yesterday!

Lessons learned
- Train can kill people.
- My commute may not be as smooth as I expected.

Thursday, February 19, 2009

Learning Web 2.0

I recently began to work on a new database system, Cloud DB. It will support, among others, Web 2.0 applications, such as social network. I know what they are (I think), but to better understand them, I decided to have some first-hand experience on them -- the feel, features, real-time performance, gadget applications, and so on. Below are my first Web 2.0 applications.

- Blogger (this site)
- Dopplr: social travel log

Wednesday, February 7, 2007