Opera Mini 5 Beta, character map, and Nokia phones

     I am really impressed with what Opera has managed to do with what they proudly claim “the next generation of mobile browsing” in the form of Opera Mini 5 Beta. It is as good a browser as I have never before used on a mobile device. Any words that I could concoct to describe how great it is won’t by any stretch of one’s imagination do justice to the product.

     I am using it exclusively on my Nokia E61 mobile phone. The E61 features a QWERTY keyboard with a limited set of special characters available on top of the alphabets as function keys. These include characters such as hyphen, exclamation mark, double and single quotes, parenthesis, etc, among others. However, these are not all of the commonly used special characters, and in order to get to a full list, a “chr” key is provided on the keyboard, pressing which brings up a character map.

     While Opera Mini 5 Beta is still fairly robust and stable for a beta software, there is one issue I’ve found that I feel has a rather inconspicuous solution. On the keyboard of E61, the rather common underscore character is not available as a function key. In order to use that character, you have to get to the character map, and select it from there. The underscore character becomes even more common on the web, where you may tend to have it as part of usernames, passwords, or email addresses, in particular. I do. And here’s where Opera Mini 5 Beta gets a trifle quirky: If you’re editing any text box within the browser, you cannot access the character map, not through the “chr” key, not through any other key or combination thereof. When I initially bumped into this quirk, I was both sorely disappointed and pissed. I couldn’t log in to any of the websites where I had a username or email address with an underscore in it. And for a while, it kept me apprehensive about using Opera Mini 5 Beta frequently.

     However, after toying around in Opera’s settings, I was able to finally find a workaround. Inside “Advanced” options inside “Settings” menu for the browser, there is an option, turned off by default, for “fullscreen edit”. Once enabled, you can edit all text boxes in a native, Symbian-esque text editor, where the character map is easily available via a press of a key.

     Bliss!

Carbide needs a rebuild option

     By and large, Carbide is the best IDE for Symbian development available today. Working on the shoulders of Eclipse, Nokia has spent considerable time and effort into customizing Carbide to a point where it makes Symbian development convenient for developers. Having said that, I should also point out that Nokia and Carbide both have a long way to go to provide as great an experience for Symbian development as, for instance, Apple and Xcode have for iPhone development.

     Under the hood, the Carbide camp has adopted what has become second nature for Unix and Linux developers: the “Keep It Simple, Stupid” (KISS) philosophy. Carbide heavily uses a tool-chain to perform a lot of different yet important tasks. That tool-chain includes interpreters such as Perl, compilers such as gcc, build configuration utilities such as make, powerful debuggers such as gdb, etc. When a project is built, or even cleaned, Carbide actively relies on this tool-chain to perform a set of very crucial tasks. And in the traditional Unix/Linux style, those disparate tools are linked together by the use of pipes. So, one tool performs one task that it is designed to do best, spewing its output to another tool to perform another task. This is a great philosophy to follow, I believe, because some of the best open source softwares are utilized. In other words, Carbide, among many other things, does two things in particular: it provides a polished, snazzy front-end that lives on top of powerful, command-line open source tools; and it links together a set of tools to make possible different things. If you have used Linux extensively or programmed on it, you will feel at home as this methodology is not uncommon there.

     Admittedly, I have a plethora of pet peeves with Carbide in general and Symbian development in particular. However, I have decided to gripe about one such annoyance that I have with Carbide. Carbide doesn’t have a “rebuild” option. Anyone reading this may think I am whining about a very trivial thing, but it isn’t trivial at all. Consider the fact that Carbide relies largely on piping together different command-line utilities to perform a disparate set of tasks, and presenting the results on the front-end. While Carbide does it mostly right, it falls short at many places when it comes to clearly showing what went on in the background, when, say, a project build fails due to errors. Building of a Symbian project can be divided into several parts, which Carbide abstracts under the “build” operation. These parts include, but are not limited to, compilation of resource files for UI elements, compilation of source files and linking of resulting object files, creation of binaries, packaging of binaries and resource files, creation of SIS files, signing of SIS files, etc. Carbide tries really hard to keep the user aware of anything that goes wrong at any of those steps during a project build. However, Carbide is not perfect, and as such leaves itself open to subtle problems that can become a cause of increased annoyance for the developer.

     Now, Carbide does have a “clean project” option, which is what I use before building a project every time. But I don’t know how many other developers do so — I did not use to routinely in the past, for example. If you are a Symbian developer, you must have been bitten at least once by the problem that arises from not cleaning your project before every build. Because the build process is divided into a number of different steps, with some steps producing concrete artifacts that are used by the following steps, there is a subtle, ugly problem lurking in there. Consider the step where resource files for the UI elements are built, and also the step where the package for the application/project is built. The latter has to incorporate all pertinent compiled resource files as well as binaries into one final package. And here lies the subtle problem: the tool that is used to create the package does not look at the previous steps to ensure that everything went ok. It can’t. All it does is that it looks into some directory for the presence of the compiled resource files and binaries it is looking for, picks them, and packages them up without thinking about whether the current build failed to produce any resource files or binaries, and that those that it picked are actually not from a previous, now out-dated build (which were left behind from the previous build because the build data wasn’t cleaned). This hideous problem surfaces when, after making adjustments in the UI elements and resource files, any compile time errors are introduced. Now, Carbide gets below par when it comes down to catching some of those errors. For example, for some hideous errors that crop up during resource compilation time, Carbide is only able to catch them when at the far end of the build process, the package manager fails to find compiled resource files because those didn’t compile from earlier. However, if there are older compiled resource files available, and an error is introduced in the resource files which precludes new resources from being built, those errors will be quietly lost because the package manager will quietly and happily pick up the old resource files (as it can’t tell which are new or old, or whether any of the steps that came before it actually passed). As a result, the developer will be left scratching their head for a long while, trying to figure out just why is it that their changes are not being picked up when they run their application. But, it could easily get worse than that.

     So, if you are a developer, and you are not in the habit of cleaning up your projects before compiling every time, you will one day or another get bitten by this hideous bug. And when you do, it will hurt for a long while before you are able to realize where it is hurting and band-aid it.

     This is the reason why I am in favor of Carbide having a “rebuild” option.

Why does wi-tribe connection shut off on the first of every month?

     I have been noticing that on the first of every month, the wi-tribe connection that I am using stops working as soon as I receive the invoice email. Browsing stops. Replies to ping requests stop. All Internet activity comes to a halt.

     When this happens, I get in touch with a customer support rep and describe my problem to them. After a while, they figure out what is wrong, tell me to try again after a brief moment, and take their leave. They never clearly explain the cause of the problem, beyond it being due to some glitch in their systems. But whatever it is that they do, works and makes me happy.

     In the early afternoon on the first of January, my connection stopped completely soon after I received the invoice over email. From that point on till an hour before midnight, I tried relentlessly to get some human to pick up the phone at the customer support site — I had the impression that the support staff got drunk and passed out over the new year’s eve, and didn’t come to work the next day. And when someone finally did, they were not able to fix my problem, promising me that a complaint was lodged and my problem will be resolved shortly.

     However, one question that they asked me during my brief conversation with them on the phone, gave me an idea about what could be wrong. Because I have come not to trust DNS resolvers that local ISPs use, I always use either OpenDNS or, recently, Google DNS resolvers. With that little detail in mind, I edited the network settings on my computer to not use any external DNS resolves but the local ones. My mail didn’t still work, nor did replies to ping requests show up. But what did half-work was any attempt to access any webpage on the browser. The browser redirected automatically to a wi-tribe internal page which told me that my invoice has been released, and this or that will happen if I don’t pay beyond the due-date. However, what caught my attention and also made me feel extremely silly was a big button in the middle of the page that read to the effect, ‘Click to continue browsing’. And clicking on that button did as advertised. I felt extremely stupid.

     So, what was the problem? The problem was that, since I was using external DNS resolvers, wi-tribe was not able to redirect me to their internal page on the first of the month when the invoice was generated. When I switched to their local DNS resolvers, I was able to see that page, click on the big button, and continue using the Internet.

     To think that I wasted a lot of money in calls to customer support, torture myself from being pissed at not being able to both use Internet and get someone at customer support to pick up, only due to a thing as silly as I’ve described, I feel an uncontrollable urge to curse out loud.

Does your Symbian phone take a long time to send SMS?

    I have possessed close to four Nokia S60 smart-phones in the last couple of years: an E50, E61, N80, and an N95. Beyond testing Symbian applications, I have never seriously used any of those phones as personal phones. I don’t despise Symbian phones, nor do I find the UI difficult to live with. My reluctance to use Symbian phones for my personal cellphone needs is largely because of an annoying problem I have faced on the phones that I have mentioned. The problem is that sending of SMS would become pathetically slow on the phone after a short period of use. If the phone was reset to factory settings, it would send SMS with the acceptable two to three seconds delay, but after a short while, the delay would start to gradually increase until it would get to a point where it would become painful to send SMS. Not only would the phone take anywhere from one minute to three minutes to send a single SMS, but would also freeze the phone until the process finished, leaving the phone inoperable during that time.

    Until very recently, I had no clue as to what caused those phones to exhibit such behaviour. Suspecting installed third-party applications of being the cause, I tested by keeping the phone clean after a factory reset (which wipes out all installed applications), but in vain as the problem described showed itself again. I tried resetting the phones in a number of different ways to get rid of the problem, but couldn’t. Every time that would happen, I would give up and move back to using the Sony Ericsson phone that I have.

    Pissed at not being able to figure out the cause of the problem, I decided to upgrade the firmware on one of the Nokia phones I have: the E61. The firmware update process, as painful as it was for me, will be described elsewhere in future. The firmware update upped the firmware version from 2.x to 3.x, which constitutes a major change. Reading through the number and type of things that the firmware changes and fixes, I did not find any mention of any “SMS sending slowness” issue. Dejected, I ran over Google to find something to console me. And find I did.

    I found that, after all, I was not imagining the problem I had been having. Other, real people were having similar issues with similar Nokia phones. And it was not a problem brought about by any third-party application installed on the phone. It was a bug in some models of Nokia phones, including the ones I unfortunately have. That was a relief. But, what were these people doing to circumvent the problem? Anything?

    Yes. As it turns out on a happy note, Nokia released a patch for the bug. They call it the “SMS Accelerator”. It is available lower down on the page here. It is a standard Symbian SIS file that installs an application inconspicuously in the background. This application strikes at the heart of the problem causing extremely long delays in sending of SMS. I have it running on my E61, and I can affirm ecstatically that it works. :)

CoreText rendering on MacVim

On thakis’s unprecedented reply to my tweet about hating the fact of MacVim not having the same style of font rendering and background combination as does Terminal, I got to know that the latest snapshot of MacVim supports an experimental ‘CoreText’ rendering feature. I immediately downloaded the snapshot, and was happy to find that ‘CoreText’ rendering takes care of my biggest pet peeve with MacVim. Now, with a dark background, the default ‘macvim’ colour scheme, and with transparency set to a count of 5, I am ecstatic with what I see as being rendered by MacVim.

I have to say, I am smitten with it. For what it is worth, here are the relevant Vim settings:

set guifont=Monaco:h11.00
colorscheme macvim
set background=dark
set transparency=5

Oh, and, if you get around to trying it out, don’t forget to enable ‘experimental rendering’ feature from within the ‘Advanced’ tabs in the preferences pane for MacVim.

The console that burns

In part on a friend’s insistence, I bought the Xbox 360 console a little less than six months ago. I knew before buying it that the Xbox 360 suffers from a scary problem that is notorious by the name of “the red ring of death.” If your Xbox console is unlucky to have the red ring, it will likely stop working forever. There are no fixes, none whatsoever from the console’s manufacturer, Microsoft, to this problem. There are also no reliable precautions to take to avoid having the problem.

A simple search for “xbox” and “the red ring” will lead the curious reader to finding, among other information, the cause of the problem. It is a design fault: a glitch in the hardware which results in desoldering of electrical joints on a particular chip inside the console in the face of persistent heat, heat that the console generates during its normal operation. When the console cools off enough for the solder to settle back, short circuits ensue. If you are lucky, your console may still work.

The red ring problem in the Xbox has caused distress to countless owners. It has single-handedly achieved the greatest console return rates (the return of faulty consoles back to manufacturer after purchase) to date (as I know of, but may likely be off base here). Microsoft acknowledge the problem and the surmounting dissatisfaction caused to its customers, but have done little to solve the problem. They have shipped subsequent models of the Xbox that they tout fix what is a design oversight, but in reality, they have only been able to dampen the problem slightly: the red rings are not gone, but are a tad bit infrequent — a dampening effect that is for the most part too small to notice. In other words, the problem persists by and large.

A precaution to dodge the problem from happening [sooner] that I read as suggested often, and that I follow myself, is to restrict continuous use of the console to less than three hours. This is preposterous. The Xbox is a hardcore gaming console, something that in contrast the Nintendo Wii is not as you are not likely to play games for a long stretch of time in one sitting, and as is characteristic of all hardcore gaming consoles and the hardcore games that are made to be run on them, players play for hours at ends. If you find this fact hard to believe, hunt down a serious gamer (an individual, mostly likely in their teens but not necessarily so, who is mad about playing console games), and spend a day with them, provided that they spend the day playing games and not sleeping through the day. It is not hard to understand how important prolonged gaming, despite the health hazards it carries with it, is to serious as well as mildly serious gamers. Even if this fact is set aside, to not be able to play games on a console for longer than roughly three or so hours from risk of blowing up the console is ludicrously absurd, for a severe lack of a better phrase to describe it. What sort of a console will that be, you may likely ask.

I winced when I heard about Project Natal. My immediate outburst at that was to the effect, “Shouldn’t Microsoft be focusing on fixing the catastrophic problem in their bloody console as their first priority, instead of on introducing, as they tout, revolutionary controller-free gaming to the Xbox?” It makes absolutely no sense to me why they would do that. The inner gamer inside me is crying for a longer, more involved and more persistent gaming experience, as are many, many other gamers who owned or have owned the Xbox. The Xbox is a great gaming platform, with popular game developers committing to releasing awesome games, with an almost robust mechanism for live community play — if only Microsoft would get serious, smack themselves on the back of the head, and set themselves to chasing out from the root the console burn-out issue.

Saved on a technicality

If your god is forever forgiving, provided that you bow only before him and consider him unparalleled, unchallenged, and single, would you indulge in petty (and non-trivial but non-cardinal) sins and deeds on the belief that at the end of your day you will be forgiven if you so seek forgiveness for your sins from your god?

Would you, then, intensify your indulgences as well as your acts of supplication in the holy month of Ramadan, a scared period of thirty (or more, or less) days where your god is known by you to be at his most merciful and forgiving demeanour?

Would you not think, on reflection, that what is a trivial lie, a dishonest dealing in trade, but a small mistake that your god will not only not mind but also exonerate you from if you spread your arms and submit to him with all your heart?

Are Google Mail and Chat becoming an annoyance?

Is Google Mail faltering under its load?

Its webmail user experience appears to be degrading with respect to response times. It becomes appallingly slow often. I despise webmail interfaces, and therefore much prefer to use IMAP4 (or POP3). I have been content with Google Mail’s IMPA4 access until recently when I started to face a class of problems that have persisted across two different providers I have switched between. Occasionally connections to their IMAP4 servers would time out; frequently, connections would get rejected with a “too many simultaneous connections” response. Google Mail has been thoughtful enough to share mitigation instructions to work around the latter problem, but sadly, those have not worked for me.

Google IM has been having a set of problems of its own. If you have not been paying close attention to your IM client, you would have missed the cycle of disconnects and reconnects Google IM service tends to fall into occasionally. This behaviour is not limited to using third-party IM applications or Google’s Talk IM application, but also prevalent in the webmail-based chat interface. When it is not an issue with the SSL certificate being erroneous, the file sharing functionality would start acting up. In fact, file transfer is almost elusive with Google’s IM services. As far as I know, file transfer support is solid in many Jabber implementations; I cannot understand why Google has not been able to get it right with its IM services.

I am happy that Google is busy integrating and introducing new features frequently into their Mail and Chat services. But are they doing that at the expense of letting the basic functionalities fall apart every now and then?

Of logic and conscience!

Inspired by The Value of Logic in Pratical Life, by JayWalker, I decided to rant about logic.

Logic, in practical life, is, more often than not, what we want it to be. As Taleb underlines repeatedly in his book, The Black Swan, people tend to only look for instances that corroborate what they want to believe in. They almost never look for instances that challenge or invalidate their reasoning. And as Taleb says, “these instances are always easy to find.”

It is a natural tendency in humans. It is extremely difficult to, once you have come up with a theory for, say, doing something, go out and strenuously look for instances that prove your theory wrong. It is even difficult to continually be on a prowl for such instances. And when faced with such an instance that debunks our theory, we find it hard to accept the fact head-on, and tend to ignore it — after all, enough other instances have confirmed our theory. We also forget, or don’t want to accept, that all it takes to disprove a theory is a single instance that invalidates it. Do we know, at any point in our lives, about all such instances that invalidate something we have come to rigorously believe in? Do what we know, give us an edge over what we don’t know?

Is it, then, even conceivable to apply logic in its entirety to our day to day lives? For all we know, there may be that single instance hiding somewhere that will be discovered some day, shockingly so, that will debunk our reasoning. Can we even affirm with certainty what is conceivable and what is not? The strict principles of validity that form a crucial part of determining logic, could be invalidated at any point in time. That we do not know of any such argument or fact that does, does not mean that such an argument or fact does not exist. We really don’t know what we don’t know.

Conscience forms from having infused a fear, by religion perhaps, of the consequences of committing actions that do not comply with what is considered morally ethical, just, or right — I say, “by religion perhaps”, because atheists tend to exhibit a heavy conscience too. A person with a heavy conscience does not succumb to the reasoning that, “just because everyone else is doing it, so should I”. The resulting burden, if they did, is immensely unbearable. But can what is considered morally ethical, just, or right, be some day proven to not be morally ethical, just, or right? On a given day, you would be given to acknowledge that religious beliefs, perhaps some or perhaps a lot, are really similar in nature to logic: strict principles of validity applied to reasoning to come to some sort of a conclusion. They tend to be.

So, when confronted with an opportunity to break a traffic signal, I hesitate, perhaps not immediately because of fear of being accountable in front of the deity I believe in, but because of the risk of hastily causing an accident (or even causing someone to lose their life). Another individual may exploit the same opportunity without thinking as far ahead. For them, the surety that they would not end up in an accident and also get pulled over, is enough to convince them to do it. If the fear of being accountable to the deity is ignored for a while, the only difference between the two processes of applying logic is that of being sceptical and of not being sceptical. Sure, I may not run into an accident every time I break a signal, but I can, one day. And the more times I don’t run into an accident, does not minimise the probability that I will some day. For the other individual, it probably likely does minimise, or even, eradicate that possibility.

I will continue my rambling another time in another post. For all it is worth, what I have written may come across as nothing more than senseless to someone reading it — it probably is.

Switching over to Wi-Tribe WiMAX Broadband service

Last week, I hastily switched Internet service provider to Wi-Tribe. They are new in town, and provide Wireless Broadband Internet through the WiMAX technology.

Faithful readers may remember that I had already been using Wireless Broadband Internet services from Wateen Telecom. They also offer a similar, which I had been using, WiMAX service.

I switched because I had been having issues with Wateen’s service. I faced no problems as far signal strength or area coverage is concerned. However, the latency in their network, which is introduced by their outrageously, needlessly complex NAT configuration, directly impacted the overall Internet experience. Also, their occasional, unannounced down-times, though bearable earlier on, started to become an annoyance. Additionally, the requirement of verifying credentials every time the CPE powers up and connects with a nearby base station, in order to be able to use Internet, did not sit well with me (I have heard that for an additional cost, one can apply for a static, public IP address, which gets rids of the fore-mentioned requirement).

With Wi-Tribe, I am currently using a 512-kbps package with an 8-GB modest cap. The tariff prices are almost comparable to those offered by Wateen. The latency is considerably lower. I do not have to verify or log in at all in order to use Internet. The Motorola CPE is slim, and almost completely silent. In contrast, the Motorola CPE I have for Wateen WiMAX groans like a Boeing 747 engine during take-off.

Though secondary, but with my previous provider, I had been having issues with Mail.app and my various IMAP accounts playing well together. Almost all of the day, I would have the email client cry at me about how it couldn’t fetch email, or synchronise the mailbox. It had started to get on my nerves. Thankfully, with Wi-Tribe, I am facing no such annoyances.

Wi-Tribe touts a 67% area coverage in Karachi. Luckily, my area is thoroughly covered. The CPE in one corner of my closed room registers 100% signal with excellent strength. The customer care and sales representation who I had dealt with at the franchise and later met at my home where he had come to install the service, was absolutely benign and fun to chat with. My experiences with Wateen in that respect were utterly unpleasant. The Wi-Tribe outlet, at a walking distance from my home, is nothing short of being haute — it won’t probably do justice to not make a passing mention of the rather hot staff they have there.

It has hardly been over two weeks since I got the service. I am content with it so far. I am keeping my fingers crossed that things only see the prettier side of the coin from here on.