Browsing on the BlackBerry simulator

     I am not a big fan of BlackBerry smart-phones. I realize that there are a lot of people who can’t seemingly exist without access to their emails virtually all the time, and for those lot, BlackBerry, with its prominent push email feature, is perhaps a better fit than any other smart-phone platforms out there. When it comes to me and my smart-phone usage, I would not go so far as to say that I can’t live without my phone. I can. By every measure, I consider myself a hardcore geek, perhaps more hardcore than most others, but I am by no means a gadget freak. While it will be unfair to say that I absolutely abhor typing on small (semi-) keyboards, I don’t also quite enjoy the experience. When it comes down to typing, I would much rather prefer a full-fledged keyboard. That is why to me a compact laptop is many times more important than a fully equipped smart-phone. (For the curious reader, I own a Nokia E72.)

     For a recent mobile website project that I worked on, I had to face a complaint from the client where the layout of certain pages on the site didn’t look quite as expected on BlackBerry devices. Naturally, I didn’t have a BlackBerry handset nor an easy equivalent to test the issue for myself, so I did what anyone stuck in the same corner as I would do: I went over the BlackBerry developer portal online to look for BlackBerry simulators.

     Unlike the Epoch simulator for Symbian/Nokia phones and the iPhone simulator, the BlackBerry simulators were spread out such that for each possible BlackBerry smart-phone model in existence, there was a simulator available for it. And each one of the download was anywhere from 50 to 150 MB in size.

     I chose the simulator for one of the latest BlackBerry handsets, and downloaded it. Like the Epoch simulator, BlackBerry simulators are Windows-specific, in that, they are available in the form of Windows executable binaries. I didn’t have Windows anywhere in my study, so I had to set up a Windows guest inside VMware Fusion in order to set up the simulator. To cut a long, painful story short, I was able to install the simulator after tirelessly downloading a big Java SDK update, without which the installation wouldn’t continue. And then, I powered up the simulator. I was instantly reminded of the never-ending pain I had to suffer through the hands of the Epoch simulator in my previous life where I used to be a Symbian developer. The BlackBerry simulator took ages to start up. I almost cursed out loud because that fact alone opened up old, deep gashes that I had thought I had patched up for good. I was mistaken. Never in my dreams had I thought of having to deal with such monstrosity ever again. And, to my utter, absolute dismay, here I was.

     Eventually, after what seemed to have been ages since I booted up the simulator, I was able to navigate my way to the BlackBerry browser. I let out a deep sigh and thought that I could now finally concentrate on the problem I set out to tackle. But, no! I couldn’t browse on the BlackBerry browser at all. No amount of fiddling with the 3G and WiFi settings all over the BlackBerry OS got browsing working. From what I could tell, both the 3G and WiFi networks were alive, but there was no traffic flowing through. I almost gave up.

     After groping on the Internet with a wince on my face, I was finally able to find out why. Apparently, by default, the BlackBerry simulator are unable to simulate network connections. In order to do this, you have to download and install an additional, supplementary BlackBerry simulator that is called the BlackBerry MDS Simulator. Once this simulator is up and running, your actual BlackBerry simulator will be able to simulate network connections, browse, and do all sorts of network related functions. Who knew!

     As an aside, there’s also the BlackBerry Email Simulator that simulates messaging functionality.

Front Row glitch with Apple external keyboard

     MacOS has this application called Front Row. When activated, it takes over the entire screen, displaying what is known as the “10-foot user interface” to allow the user to kick back, relax, and watch and listen to videos, podcasts, music, or media content of any kind. If you’ve got a big screen, such as an Apple TV or an Apple cinema display (which if I may add are crazy expensive), with the aid of the Front Row application, you can enjoy a great media centre-esque experience.

     On MacOS, this application, Front Row, is tied to a keyboard shortcut: Command + Escape. Once activated, you can use the arrows keys to navigate your way through the 10-foot interface, selecting whatever media content you may want to look at. A really convenient feature of the Front Row application is its integration with the Apple remote. Essentially, you can sit back and navigate the media centre through nothing but the wireless remote.

     I’ve owned a MacBook for over two years now. Having used the keyboard on the MacBook for nearly all this time, I now find that I can barely type on it without causing myself a great deal of agitation. I’m a touch typist, and naturally when I cannot type both fast and accurate, and when I know for a fact that I can’t not because I don’t have the capacity to do so, but because the keyboard is being the bottleneck and standing in the way, I get frustrated very easily. This unfortunately happens to be the case with the MacBook keyboard now. In order to work around that temporarily, I recently dived without a clear head into a shopping spree and emptied my wallet into buying the Apple extended external keyboard. While it is not really conducive to touch typing (something I find it appropriate to elaborate on in a different article altogether), I am able to get by and get my work done without getting close to having a nervous breakdown.

     Now, here, I should point out that I don’t have substantial evidence to prove this (and to that end, I am groping around for it), but I suspect that the Front Row application and the external Apple keyboard don’t quite play nicely together. I am not a very media-centric person, in that, I am not altogether fond of watching movies so often as many of my friends do, for example, so I have little to no use of the Front Row application. However, since I do use all sorts of keyboard shortcuts to perform different functions across many esoteric applications (including Vim, use of which puts a lot of emphasis on the use of the Escape key), I somehow end up pressing the wrong key combination and activating Front Row unwittingly. But, that’s fine, you may say, because all I then have to do is close Front Row. Yes, well, sort of. My problem is that, with the external keyboard attached, if I accidentally start up Front Row and let it take over the screen, I am unable to exit it. And because the application itself does not have any UI elements that can be clicked at to command the application to quit and because the only keyboard shortcut that happens to be the only known (to me) means of exiting the application stops working in the presence of an external Apple keyboard, because of all that, I get a big problem in my hands. I get stuck with an application that essentially takes over my computer, and I can’t do anything about it. I’ve tried waiting for the screen saver to kick in, hoping that when I make the screen saver go away, I would get control back of my system; I’ve also tried letting the MacBook sleep and wake-up subsequently, but all in vain. The Front Row application simply doesn’t go away, until I am left with no other option but to forcefully reboot the MacBook, losing all my data inside all my running applications, which, I should mention, are functioning normally behind the nauseating Front Row screen.

     I’ve had this happen inadvertently far too many times for me to continue to ignore it. So, I eventually did the first thing I could think up of: Find a way to disable the keyboard shortcut. It turned out to be pretty easy to do. Most of the common keyboard shortcuts, as it turns out, linking to different common applications and actions are defined under the Keyboard Shortcuts section in Keyboard inside Preferences. The shortcut for the bloody Front Row is somewhere in there.

     I am pretty sure there’s something amiss with Front Row and its associated keyboard shortcuts when an external keyboard is attached, but as I said before, I’ve nothing to substantiate that claim. Right now, I am happy and relieved to be able to disable the shortcut.

Ranting about Mercurial (hg) (part 1)

     The day I got a grip of git, I fell in love with it. Yes, I am talking about the famous distributed version control application: git. I was a happy Subversion (svn) user before discovering git. The day to day workflow with git and the way git worked made me hate Subversion. I was totally head over heels in love with git.

     I have come to a point where the first thing I do when I am about to start a new project is to start a git repository for that project. Why? Because it is so easy and conveneient to do. I really like the git workflow and the little tools that come with it. I know that people who complain about git often lament about its lack of good, proper GUI front-ends. While the state of GUI front-ends for git has improved incredibly and drastically over the years, I consider myself a happy command-line user of git. All my interactions with git happen on the command-line. And, I will admit, it does not slow me down or hinder my progress or limit me in any way in what I do. I have managed fairly large projects on git from the command-line, and let me tell you, if you are not afraid of working on the command-line, it is extremely manageable. However, I understand that a lot of people run away from the command-line as if it were the plague. For those people, there are some really good git GUI front-ends available.

     I have to admit that for someone coming from no version control background or centralized version control background (such as Subversion or CVS), the learning curve to git could turn out to be a litle steep. I know that it was for me, especially when it came to getting to grips with concepts involving pushing, pulling, rebasing, merging, etc. I don’t think I will be off-base here to think that a good number of people who use version control software for fairly basic tasks are afraid of merge conflicts in code when collaborating code. I know I was always afraid of it, until I actually finally faced a merge conflict for the first time. That was the last time I felt afraid of it, because I was surprised to find out how easy it was to deal with and (possibly) resolve merge conflicts. There’s no rocket science to it.

     I have been plenty impressed with git that I wince when I am forced to use any other version control. In fact, I refuse to use Subversion, as an example, and try my best to convince people to move to git. Why? Because git is just that good. I should probably point the reader to this lovely article that puts down severals reasons that explain why git is better that a number of other popular version control applications out there.

     Recently, at work, I have had to deal with the beast they call Mercurial (hg). Yes, it is another famous distributed version control system out there. I was furious at the decision of my peers to select Mercurial for work-related use, and tried my best to convince them to use git instead, but they didn’t give in to my attempts to persaude them. I had no choice but to unwilling embrace the beast and work with it.

     Instantly, I had big gripes with the way Mercurial worked as well as its general workflow. Where I fell in love with how git tracked content and not files, I hated the fact that Mercurial only tracked files. What I mean by that is if you add a file in a Mercurial repository to be tracked and commit it, and then make any changes to the file, Mercurial would automatically add it to the staging commit. Yes, it wouldn’t let you specify manually which files that were changed should be part of the staging commit, something that git does. A staging commit is a staging area where files that have been changed and have been selected to be part of the next commit are loaded to be ready for commit. With git, you have to manually specify which file to add to the staging commit. And I loved doing it that way. With Mercurial, this was done automatically. This in turn brings me to the second big gripe I had with Mercurial: incremental commits. Git workflow places an indirect emphasis on incremental commits. What are incremental commits? In the version control world, it is considered best practice to perform a commit that is as small as possible and that does not break any existing functionality. So, if for example, you have made changes to ten files to add five different functionalities, that may be independent of each other, but would only like to commit one functionality at a time. That is where incremental commits come in action. With incremental commits, you specify only the files you want to be committed and commit them, instead of committing all the changed files in a bunch and add a general purpose commit message. Incremental commits is a big win for me, and I adore that feature. Because with git you had to manually specify which of the changed files you wanted in the staging commit area, incremental commits came easily and naturally. With Mercurial, where it automatically added all changes to tracked files into the staging commit area, it did not.

     So I asked the obvious question: How do we do incremental commits with Mercurial? Aftering sifting through the logs, I found out that it was indeed possible, but in a very ugly way. The Mercurial commit command takes an extra parameter, -I, that can be used to specify which files explicity to make part of the commit. But that wasn’t it. If you had, say, five files of the ten changed files you wanted to commit, you would have to tag the -I switch behind each of those files, otherwise, Mercurial will fail to include the files in the commit. To this day, this little quirk bites me every now and then.

     I will admit that the one thing I really liked about Mercurial was the built-in web server it came with that could provide a web-based interface to your Mercurial repositories for viewing. This was something that was missing from or quite difficult to do with git. And, this was also one of the biggest reasons why my peers at work decided to go with Mercurial for. They all wanted a convenient way to access the repositories over the web.

To be continued.