Nokia: A great company producing great little apps (and phones!)
Most Americans I know settle for a Motorola cell phone. I personally think that Motorola phones have one of the worst user interface designs ever. True, their Razr V3 series look really slick on the outside but the embedded operating system is still pretty primitive.
Anyway, in countries in Europe and Asia, most people use a Nokia. Cell phones might be the one area where people in Asia are more technologically advanced compared to their American counterparts. In fact, Nokia notices this too: Asian denizens are more likely to buy new cell phones (or hand phones as they are called there) even if the cost of one is about 2000 dollars in local currency!
What about smartphones? Treo 650's and the rest. Yeah, sure America's wireless companies support smart phones. Hmmm... aren't they just some niche market just like what the Tablet PC is in the computer industry? Heck, don't take my word for it, listen to this guy:
Russell Beattie Notebook - Smart Phones Are One Handed Devices: "Hey, okay. So I can see the new browser is pretty neat, and hell, Palm as a real multi-tasking OS is something to get a little jazzed about. But judging from the pics of the Qool Palm phone there's some disconnect in what I'm reading. Here's a little lesson in mobile nomenclature: If you can't use the phone with one hand, it's not a smart phone. Got it? It's pretty simple. It's a PDA Phone or a Communicator or something. Whatever it is, it's not a smart phone. It's a relic. An elecronic organizer with an antenna. An anachronism. A soon-to-be market failure. Get the idea?"Let's go over this again: If it doesn't have a keypad? It's not a smart phone. If you have to use a pen? It's not a smart phone...
And because Nokia is smart enough to use the Symbian OS on most of their high end phones, they can get other people to develop software for their phones. Forget Java MIDP applications, those are really slow and contrary to what people advocate, they do not follow the write once, run anywhere mantra. What I would really like to see would be Irb running on a Symbian phone.
Well, the program that I am most intrigued with now is Nokia Lifeblog. It lets you take photos and videos on your Nokia cell phone and then upload it to your blog, complete with text as well. This is really what having a camera on your cell phone is all about. I think it is really neat to be able to go on some trip and post live photos of what you are doing to your friends and families. Someone should hold a competition for this. Remember, if there is indeed a competition for cell phone photo blogging, you heard it here first. If you want a more down to earth review of LifeBlog, read this article.
Well, what else can a Nokia do that other cell phones cannot? Actually, cell phones that run Symbian OS can do what Nokia phones are capable of. How about ssh on your cell phone? Unbelievable? Believe it. David Heinemeier Hansson has a list of his applications that he runs on his Nokia 6630. Want another list? Try Russell Beatie's here.
What about my cell phone? Don't have one yet. I am still waiting for the FCC to approve the N90, the new Nokia cell phone with a 2 mega-pixel camera. That will certainly keep my fingers snapping like crazy.
Update: By the way, I forgot to mention, there is also an increased risk for viruses to attack Nokia Series 60 phones. Engadget (Aug 11, 2005) reports that there is a mass outbreak of the Cabir virus in Finland infecting Nokia Series 60 phones via bluetooth. Also, for a more comprehensive review of some of the other malicious code that attack cell phones, read Mobile Phones: The Next Frontier for Hackers? published in IEEE Computer Magazine in April 2005. So, there might be some advantage to sticking with lesser known brands.
Posted in paradigm, software, web pages | no comments |
Some Ruby programming
Below is one of my bigger ruby projects that I did for fun. The other projects that I have done mostly involves Ruby on Rails. And so far the biggest and most formidable project is getting Typo to work properly with Apache and FastCGI.
This problem was proposed on RubyGarden's StarterProblems page. Since I had nothing much to do tonight, I decided to try it out. I have a vague idea on how to solve the problem after reading it. It involves using some form of depth-first or breadth-first search since you are trying to find a path. Because the problem only requires one solution, and not all the possible paths, the answer is much simpler.
So, the first thing I did was run through Irb to figure out what methods were available for Strings and Arrays. My original plan was to treat the maze as a String but be able to access each character as though they are part of an Array. Runnning Ri and Irb over and over was getting a bit tiring. Fortunately, I realized that I have a copy of the PickAxe book with me. The documentation for the standard Ruby library is fantastic!
So playing with the syntax of Ruby took me about an hour. In that time, I discovered some very useful features of Ruby. First, if you have an Array that has only 50 elements and you call array[51] on it, you do not get a horrible exception like in Java but you get nil. This is nice because it lets you traverse the maze without worrying too much about null pointer exceptions. Secondly, you should be a little cautious when using the built-in String and Array methods. For instance ["a", "b", "c", "d"].delete("a") returns "a" and not ["b", "c", "d"]. There is of course an advantage to returning the deleted element, but you do have to be careful about such things. Thirdly, you must remember that Ruby passes things using references so if you want a copy, make sure you explicitly create one.
What really threw me off was not my code, but a typo I made while copying Gushi's version of the maze off the website for testing. Somehow, I added an extra space past the newline and that affected all the offset so my recursive function just terminated without reaching the end of the maze. This carelessness of mine wasted 1 hour of my time analyzing my algorithm. But it did at least convince me more that the algorithm does work. Like I said, my algorithm utilizes some form of depth-first search. At each position, I have two sets: one of the potential positions to go, and the other of the positions that I have already visited. To prevent infinite recursion and also to optimize a bit, I never visit the positions that I have visited prior to the current node. The code shows this more explicitly.
I did two iterations of the program. The first one being using functional programming. And the second time around, I refactored it to be more object-oriented. Nonetheless, there was not much point in making it object-oriented.
Here is my code, made beautiful through the use of Vim by following the instructions here. Of course, I would have preferred TextMate's coloring but Vim is good enough.
Posted in development, web pages, ruby | no comments |
On Trusted Platform Module and Apple
I do not know enough to say anything intelligent, nor would I say anything to speculate on something that clearly is beyond my control. Therefore, I am grateful that John Gruber has produced such a fantastic piece discussing this issue that was sparked from two separate articles from Cory Doctorow and Slashdot.
Here is what I think:
- Apple would not do something stupid to jeopardize itself right after hitting the sweet spot with so many developers.
- I doubt that Apple or Intel or whatever can force developers to write programs that will utilize this evil technology
- Even if there were, there will be definitely some where to crack it.
- Why fret over something that you know nothing about? Apple has not even released Leopard yet!
Posted in paradigm, web pages | no comments |
Goodies from OSCON
In case you have not noticed, there is a whole plethora of resources for the presentations that were made during OSCON 2005. Here is the link to get your hands on those resources.
Unfortunately, the best stuff might not be on that page. Why the lucky stiff has been kind enough to provide some links to other presentations here. Of course, he has been too modest and conveniently forget to include his own wonderful presentations. So, to grab why's unorthodox presentations, which befitting that term, head over to redhanded and enjoy some truly hilarious fun with his videos.
My personal recommendations as of today are:
- 10 Things Every Programmer Should Know About Ruby I cannot believe that Weirich actually mentions the Sapir-Whorf theory! Shows that what you learn in Anthropology does come in useful sometimes.
- All of Why's Stary Afternoon Torrents
- Metaprogramming Ruby
As mentioned in my previous post, I cannot wait to see what why did with drb. He might really be onto something here: a new, more fun way to teach programming in a new and more fun language. A language that is not designed to appease corporate managers, but one to get hackers together.
In case anyone is wondering, I am posting these links not because there is a dearth of web blogs writing about how awesome OSCON was, but because I really think these presentations are interesting. And I would really loved to be there too.
Posted in paradigm, software, web pages, ruby | no comments |
FOSCON: Some people have all the fun
From comp.lang.ruby on why the lucky stiff's presentation:
"He had people fire up irb and then displayed some code they would need to log into his drb server running on his laptop. As each person logged in the colors on the projected screen changed and it would divide into different regions so you could tell how many people were logged in. Audience members could change colors on Why's display by changine their code in irb. It was very cool... though some wise guy changed part of the screen to white-on-white which made it impossible to read the code on that section (but Why got some jokes out of this too).
Why's talk was extremely funny so it can be easy to overlook the fact that this was a very innovative idea for creating an interactive presentation. Most presentations are all one-sided: A speaker delivers some information to an audience - there may be a Q&A session afterwards, but other than that it's not interactive at all. What Why did last night, I've not seen before: He invited the audience to directly participate and even effect his presentation. This aspect deserves a lot more examination.
One can imagine variations on this theme: For example you could run a webrick server on your laptop and allow audience members to interact with (and potentially effect) your presentation through their browsers. Lots of potential uses: audience voting in real time, for example. Code contests with the audience. It's great for tutorials (This is how Why used it): you get people to actually try out the code you're talking about with some kind of feedback to the speaker. Nobody gets bored.
I think that Ruby historians and sociologists will look at this event as a seminal development in the direction of interactive teaching.
Oh, and two shadow puppet birds debated teaching methodologies just prior to this part of the show - that was no accident."
More photos are available on flickr. I really wish that I was there. It would be interesting to see how to teach ruby with puppets and such. Right now I hope that why releases his irb thingy for public perusal. Why is definitely one creative fellow. He is right up there on the list of people I look up to; right along with David Heinemeier Hansson.
Posted in web pages, ruby | no comments |
O'Reilly CodeZoo
O'Reilly CodeZoo: "After our launch in April, we received requests for many languages, but no language got more requests than Python. We're happy to have Python represented on CodeZoo, and will be adding still more components to the Python tab over the next few weeks. Visit python.codezoo.com to get right to CodeZoo's 'Reptile House.'
Seeing all the excitement around Ruby, particularly Ruby on Rails, we felt it would make an excellent addition to CodeZoo. Whenever possible, we're providing a RubyGems-format download as the default (and we'll start up a Gems server shortly). Check out ruby.codezoo.com and see what all the fuss is about."
(Via @lesscode.)
Though I am neutral for the inclusion of Python as part of codezoo, I am really excited about Ruby's inclusion. Maybe people have really seen what a great language it can be.
Posted in web pages, ruby | no comments |
Sometimes this is so true...
Sometimes I feel this way. Except I don't drink coffee, I drink Boh Cameronian Gold Blend Tea.
Boing Boing: Apple to add Trusted Computing to the new kernel?
Boing Boing: Apple to add Trusted Computing to the new kernel?: ""
(Via ODx86.)
What does this mean? Right now nothing much, but if it turns out to be true, this will probably become a big deal. Rather than speculating what will happen, it is best just to see how things go. I am pretty sure Apple would not be so audacious to piss off all its users just to satisfy Intel or the music industry that is bent on keeping a tight lease on licensing issues. Anyway, even if this were true, I think we could always count on honest developers not to abuse it.
Worse case scenario, fall back to text files, just as what the Pragmatic Programmers suggested in their book: From Journeyman to Master and rely on real editors like Vim and Emacs.
Posted in paradigm, web pages | no comments |
Holy shit: Google Print!
Google keeps coming up with all these cool ideas! Now they have Google Print. It allows you to search for text inside PRINTED books. That is right, printed books! Those kind that you cannot read of a web page.
It is even faster than bringing that book out from your shelf, looking through the table of contents and the index to find what you need. Just go to Google Print and if you are lucky, they have already archived that book.
Being the smart people that they are, Google has of course not provided an easy way to browse through all the pages from beginning to end. Instead you get to only view pages that match your search criteria. But, bare in mind, this gives you the best of both worlds! You can read your book in its printed format, and then search through it using Google!
Excellent! Especially for books that do not have electronic versions.
Posted in paradigm, web pages | no comments |
GTD: the good and the bad
In my previous post on GTD: Getting Things Done, I mentioned that I will be following up with a more thorough article about how my method of doing things compared to David Allen's. Well, suffice to say, my personal techniques so far are adequate but after being polished by the techniques advocated by David, they have become even more effective. My previous method of getting things share similar traits with David's: reviewing, keeping things all in one place, doing, thinking before doing.
Warning: lots of words ahead.
If there is one thing that I particularly liked about David's book is the fact that he relies on the simplest thing possible; simple but not simpler! As Einstein said: "Everything should be made as simple as possible, but not simpler". David does not try to enforce only one methodology of doing GTD. In fact he suggests a few that might work. When you read a book and realize that the author is not limiting his methodologies to just those that can be exercised under some rigid subset of tools, you begin to tell yourself that this guy might actually know what he is talking about and is not merely out there to sell you his tools for hundreds of dollars. His writing is clear and each page is embellished with relevant quotes from other sources. Moreover, his writing is easy to read. He knows when to be forceful and he knows when to be suggestive. There is a lot that one can re-learn as I discovered for myself while rereading certain chapters over so that I may present a more realistic view of GTD in this article.
Because David's GTD method is so simple, you can actually just begin practicing it by reading chapter 2 and 3 of his book in the bookstore. As a matter of fact, you might not even need to buy his book! However, do buy his book to read the rest of the chapters as he expounds into how to maximize success within each step. The end chapters are more of his own personal experience with the methods which he advocates. In addition, this .pdf file might help you jolt your memory. I keep one on my desk to refer to. Realistically, if you are interested in learning more about GTD, these two links are recommended:
- A summary of how to do GTD: http://pigpog.com/michael/blog/2004/07/productivity-gtd-getting-things-done.php
- A personal account of success with GTD: http://www.marktaw.com/blog/GettingThingsDone.html
For the rest of this article, I would just be going over the major steps of GTD and why I think that these steps actually work. At the end, I present some examples of things that you should avoid while doing GTD--expect somewhat of a personal caveat. Before continuing, if you are not familiar at all with GTD, at least read the .pdf file that I recommended.
- Collect
By collecting all the "stuff" that you know you have to do and everything else that seems to exert some form of interest to your brain, you help caulk yourself from missing anything. Collecting everything that is even superficially important to you is important because it is the first step of trying to get things done. You cannot get things done if you do not even know what things you have! Collecting all these "stuff" also has the added benefit of being to measure how much things you have to do.
If you are able to amass everything into a box that would be excellent. Of course, as David suggests, if the item is too big to go into a box, just write down a representation of that item on a piece of paper and toss the paper into the box. Moreover, collecting everything and putting them into one place will always let you know where your stuff is. Henceforth, we shall call that collection box the inbox: the place where anything that is even remotely useful must go in there.
As a fringe benefit, if you are extremely religious when doing this for the first time, you will also be able to collect things that you thought you had forgotten. By putting them all in front of you, you begin to realize that you have even more things that needs to be collected. Just go ahead and collect them. However, avoid things such as supplies, decorations, etc; things that you do not need your active participation in changing the value of their existence. - Process
Processing is simple when you know how. By taking one and only one thing out of your inbox each time, you will be able to focus your energy on processing this item. Moreover, by not choosing which item to process first, you ensure that you do not neglect any item in the inbox. This is important because as of this moment onward, all those items are equal, none are more equal than the rest. All of them deserve your attention. You will get to decide how much of your attention soon enough.
David's key to the successful processing of any item would be the ability to identify what you are going to do next with this thing. In fact, the first thing you do is determine whether you can tie any action to this item. If it is just something that you think might be useful as a reference to you, then there is no action associated with it. However, if it is an article that you want to read, then there is the "read" action tied to it. Items that have no action assigned to them will be kept as reference. What if the item is both "unactionable" as well as unusable as reference? Throw it away! The rationale behind this is of course that they will always be things that need to be disposed of. The faster you do so, the quicker you can focus your mind on more important things.
One of David's only mandate of deciding the action that is going to be associated with this item is that the action must be the very next action that you can perform that will spur this thing forward to completion. It must be the very next thing that you can do. It must be clear and it must be visible. If it is not visible, then it is probably not being specified the right way. Taking a vacation is not really the next action; maybe calling the travel agent for the tickets is a better next action. Because next actions also lead to completion of the current task, spending time thinking of them is not wasteful. As a matter of fact, by just spending some of your gray cells on them might help you uncover more actions that need to be done before completing this task.
Furthermore, by thinking of the actions, you also get a clearer picture of who is supposed to do it. You might not be the person that should be doing this, or you might need someone else's input before you can even proceed. By determining the next action, you are able to tell whether you should be doing it or not. In addition, if you determine that the next actions that must be performed require a lot more steps than you anticipated, then you will want to organize those steps as described later on.
Also if that action is only going to take 2 minutes of your time, why don't you just do it? Simple tasks should be done the moment they appear whenever possible. If you do not do them now, it is likely that you will not do them later.
In my opinion, processing the information as well as you can would be the most substantial step in GTD. Whenever possible, identify what is your own gain in doing this action. As Bobbi Depoter puts it in her book Quantum Learning, we should always identify the WIIFM factor: the What's in it for Me? factor. If we can see the benefits of doing so for ourselves, it might just motivate us to go further. - Organize
Once you have all your next actions defined, it is time to organize them. David is not very forgiving of to-do lists. To-do lists, to him, are not going to provide enough information on what to actually do. So he suggests putting tasks that need to be done at an exact day and time into your calendar. Those are your specific-time tasks. And if you are able to determine that you need to do some tasks on certain days but you can be flexible with the time, then jot that down in your calendar as well but list is as an all-day event. Finally, respect your calendar. Thou shall view the calendar as sacred. Put things that have a specific day or time associated with them into the calendar and nothing else. Not only does this reduce clutter, it also prevents you from feeling stressed over things that need not be completed on that day itself.
What about the other tasks that do not have a specific time associated with them? These are the next actions that you put into list--not just any list, but list that have triggers associated with them: @someday/maybe, @waiting for, @next action, @call etc. Incidentally, the @ in front is used in Perl to let you know that the variable is a list! I bet David does not know that, he uses the @ so that when you sort those files in a folder, it ends up at the top. These lists have specific triggers to them. For instance, @call. When you have a bit of time left and a cellphone at hand, you can quickly browse through that list and get a few phone calls done! Imagine if you have one gigantic to-do list instead; it would be hard to actually filter out the calls that you need to make. And that is what I like about David's list. Organizing them will help you determine which actions can be done under different circumstances. - Review
A simple but quintessential step to the success of GTD. If you do not review, you will sink slowly but surely into the mess that prevented you from getting things done in the first place. Reviewing is a good thing to do: it refreshed your memory of the things to do. It triggers your brain and jolts it so that it knows that they are things to be done. And if you review enough, you will also consciously notice that you have done some of the actions already and can mark them off. This gives some sense of accomplishment and psyches you up for the next task that comes your way.
Reviewing is not limited to reading your action lists only. There is a lot more to it. Review shallow and review deep. Review deep when you need to go into the details. Review shallow when you want to focus on the big picture: how are all these actions going to help me accomplish this task?
Reviewing helps you find more things that you might have missed as well. - Finally,... do!
This is the single most important step. All those previous steps are just to prepare you for this one. You know what you need to do, when you need to do it, so now just go for it and get it done!
If only life were that simple. Fortunately, David has some suggestions to help you decide what to do:- Context: what resources do you have at your disposal now?
- Time availble: how much time do you have at hand?
- Energy availble: on a scale of 10, how much energy can you devote?
- Priority: is this really what you should be doing now?
- And my personal own: Celebrate!
After you have done something that has been nagging at you for a long time, you really deserve some celebration.
You might be thinking to yourself after reading those paragraphs (and also the recommended readings like I suggested, I hope) that David's GTD method is really simple and effective. Indeed it is. GTD is meant to be a no hassle, freely doable form of getting things done. Which brings me to my next point: why do people complicate it? Why must they even bring up the issue of what tools to use? And devote whole forums talking about it?
Consider this thread here. I am glad that someone has the audacity to suggest just going cold turkey and implement GTD however you find that you like it. David never mentions what is the best way to do it. You do not need to user a PDA if you do not have one. If you like using pen and paper then so be it. Personally, I am glad that David does not take part in these kinds of forums. In fact, because it is so relevant, I am going to quote that person:
All right. This has been an extremely long entry. I feel good about letting it all out though. GTD is a good methodology. And it shall remain as that. It is not the end of the world if not one uses it. In fact many other people do not even practice it. However, if you have nothing else to try, why not just try GTD? The results might be rewarding.
Posted in paradigm, readings, web pages | no comments |