.::output >> /dev/null::.

What if you made some changes to the data from one source? How would you resolve potential conflicts? Since you should be the only one accessing the information, you might be able to avoid this problem if you have an always-available repository. But what if you have devices like a Palm? Changes made to it are not reflected until you perform a sync. And if you were to modify the dates on the computer before synching with the palm, currently you can only accept changes from the computer or the palm (an exclusive or); there is no merge functions yet. Would subversion (or CVS) be the answer? But how would you get the masses to understand concepts such as commit, revert, merge, ignore (even I have problems resolving conflicts within CVS)?

If you think that is hard, what about trying to glue physical to digital? What if you write something with pen and paper (contrary to popular belief, the most ubiquitous form of recording information would still have to be the pen and paper)? How would you digitize that information? And if you have digitized it, then would you render your pen and paper version obsolete and throw it away? I do not think there is a way to resolve physical to digital conflicts. Ubiquitous computing can only happen between digital products.

Probably the most powerful computing equipment that you own would be you own PC. And it lies in your house. What level of computing power would you need when you are on the road? How much is too little, and what level would you define to be overkill? Why not just bring around a little device that can access your PC at home? Use some form of wireless connection to retrieve files that you need on the fly. If we do that, then how much information should the device be capable of displaying? Will it be able to support pictures, sound, movies? Who decides what it needs to support? And once someone determines what files it will support can you, as the user, ever change it according to the your needs? Must the user carry around his iPod to listen to music, his Palm for writing data, his notebook PC for programming tasks, his cellphone for communication?

Chris says: "There's an important lesson, in that monolithic solutions aren't that useful any more. Products need to be extensible and open at the edges to be useful". Again how extensible? More importantly, I believe since products will become more capable (but not necessarily better), the issues of migrating and upgrading should not be taken lightly. Migrating your files from an old machine to a new one can be more complicated than you think. What if you just found a better program? How are you going to migrate all your files in the old format over? Or how can you share existing files that have been written in non-standard schemes? Will we forever be limited to storing unicode text?

The main thing I am trying to emphasize here is that for me, there are so many more issues with ubiquitous computing. Would it be possible to implement some protocol that satisfies everyone? How many people do you have to be able to pleased before that product is marketable? I do not have the answers. We will have to see what this year holds for ubiquitous computing.

The glue might be becoming more of a reality. As The Tao of Mac puts it, SyncML is a realistic standard that should be adopted. This .pdf file does a fairly good job of providing an overview of what it is. In the end, standards are just standards and nothing prevents some company from inserting something into the XML schema that will break everything.

For some of the available toolkits please check out SyncML toolkits. For a more elaborate description of SyncML, these two links are very readable:

• XML Watch: Have data, will travel
• XML Watch: WMXML and basic SyncML requirements

1. Learn how to write before graduating.
   Indeed this is something that I believe it true. In fact all the general education classes here in this university mandates some form of written assignments. Written assignments are good because they force you to think of things in a more complex manner that reflects your thoughts and not just recitation of the information from the book. Writing is not something that you can just do at the spur of the moment. Well, sometimes spontaneous writings do convey your feelings more vividly but most of the time it just reads like it was written by some kid. I know a few people who try to avoid taking classes that require writing, preferring classes that have more exams instead. I find this a bit disturbing because in an exam, especially an MCQ one, you do not have the choice of bringing in your own reasoning--your choices are limited. This, to me, does not lead to any form of creative thinking.
   Anyway, Joel also mentions that being a good writer means that you are able to convey the message across to as many people as possible. He is not the first person to tell me this. My Physics 111 teaching assistant has also convey this fact, as has my Physics 114 teaching assistant. So has my ECE 390 professor for whom I was a teaching assistant for the class. Smart "enlightened" people agree that writing properly is important. I try to write most of the things on this weblog using non-technical nomenclature so that in the rare event that some person stumbles by, he or she need not be a CS major to understand. Just as it is important to be able to write, it is also important to me to write with simple sentences especially when the subject being discussed is complex enough. Older textbooks suffer from this mistake as do modern ones when they generalize: "... thus it is simple to see how this can applied to the converse." For a person reading the textbook for the first time as the primary source of learning it is not simple. Maybe when you finally get it and refer back to this book then it is simple, but never before that.
   The motivating news is that Joel encourages people to write so that it becomes almost secondary. And he suggests doing so through a weblog. One more thing: If you write it down, you would not lose it!
   Writing also requires reading I presume so these two activities must go together.
2. Learn C before graduating.
   Been there done that? I do know C; at least enough of it to write fairly large programs and to understand a fairly complex ones. In fact I learned C on my own before learning C++. I doubt that any class here uses it exclusively. Nevertheless, I agree that learning C would be beneficial since Tanenbaum (Modern Operating Systems) claims that all real operating systems are written in C. And C will remain one of the most powerful languages in the world. It may let you shoot yourself in the foot but it is still able to do a lot of things that Java or Python cannot do. And it is the closest that you can get to the hardware level without actually using assembly (I program in x86 assembly).
3. Learn microeconomics before graduating.
   I have no comments for this since I have no understanding of what microeconomics is. Hence it shall be one of my projects to actually find out what it is.
4. Don't blow off non-CS classes just because they're boring.
   I guess for me it should read: Don't blow of ECE classes just because they're boring. Point taken. Maintaining a good CGPA shows that you are able to commit to your studies no matter how boring it is. So unless you think you are going to be Bill Gates and drop out of college (a fact that he kind of laments now) you might as well make the best of it.
   In other words, spend as much time as necessary on those classes as you would on a technical class. Most of those classes (the general education ones, not the ECE ones) do give you a broader perspective of life as mentioned in my semester-end reflections. And as my girlfriend keeps telling me, there is more to life than just bits and bytes.
5. Take programming-intensive courses.
   The same advice was given to me by the Apple programmer who came to interview me for an internship. If you really like programming then you would enjoy a class that has a lot of programming assignments. Especially if you get to build a real application and not some command-line thing. My Software Engineering class has been enjoyable because of that.
   Theory classes are important but hands-on programming is still more fun. And theory is something that you can refer to from the book but applying those theories in a effective manner takes perseverance and lots of practice.
   Leave the theory to the mathematicians--they do a very good job at it. When you are seeking a job, programming skills matter more. As long as you have some background in mathematics (which I believe I do since the Computer Engineering curriculum mandates at least 6 math classes) you should be able to read and understand the math should the theory arise. Getting bogged down with the details of how a hashtable works and not actually being able to use it is bad.
6. Stop worrying about all the jobs going to India
   I don't. Only cheap companies outsource all the jobs to India because of the cheap labor. There are of course good Indian programmers but trying to send more projects over to India just because it is cheap is not the smartest move.
   Cheap does not imply efficiency. And when you have a good programmer you can expect your project to at least stay on track. But when you have a bad programmer, you can expect to see negative growth. If I recall correctly, it was mentioned in my Software Engineering class.
   For a better discussion of this matter head over to Wired Magazine: The New Face of the Silicon Age.
7. No matter what you do, get a good summer internship
   Will work on this since I am an international student and they are not too keen on hiring us.
8. Joel: unless you're gullible enough to do all that stuff just because I tell you to, in which case add: 8. Seek professional help for that self-esteem thing

Do not follow all advice given to you.