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.

Omelette paratha, and cold coffee

Omelette paratha, and cold coffee.

Not a perfect combination of drink to go with the snack, but nonetheless pleasingly savoury.

I was sitting next to a table occupied by three young guys dressed resplendently in haute kameez and kurta. They were conversing in Sindhi. I thought I had heard them talk more about politics than anything else, but in times such as we live in, anyone can be found talking about politics.

My friend pulled over, wincing that his company has to launch before the elections. I asked, twice, what they want to launch. Before he could answer, the guy nearest to me on the table next to ours was rattled at the word “elections”, and asked “which elections?“. I had not noticed that all of them had taken interest suddenly. When my friend said, “elections in Afghanistan“, they all let out a sigh followed by a good, heavy laugh. The one who had asked the question quipped, when my friend stated that in Afghanistan there are over forty presidential candidates fighting for a single position, about our Great President being practically the only candidate over here and joked about him being an unbearable burden on everyone. They all burst into mirth. I remained quiet, for some reason. My friend felt like carrying on the conversation, something I thought exceedingly needless.

We were the only two customers left in the cafe. It was half past one in the dead of a humid night. As we walked out, we saw a flashy Parado parked outside, with a heavy police escort waiting next to it. There could have been no doubt it was theirs.

They spoke in Sindhi, got nervous at hearing the word elections, and made fun at the expense of the president. The road outside was deserted, and it was late at night. And the men waiting outside glared straight at us as we strapped our seat belts and drove off.

Creating click-able hyper-links in CSV files programmatically

If you are programmatically creating CSV files intended for Microsoft Excel users, and cannot figure out how to make URL data in the CSV files behave like click-able hyper-links for your users, this tip is for you.

There is a special format in which URLs should be formatted, that is used by a number of spreadsheet applications to interpret URLs as click-able hyper-links. The format is this:

=HYPERLINK("URL")

The URL must be enclosed in quotes for the format to be interpreted properly (without which, at least, Microsoft Excel complains).

Resize images with Preview on Mac OS X

Thinking that there’s no way built into Mac OS X to resize images, I have been for a long time hunting down free third-party image resize applications. What I did not know and could not find until today is that the Preview application, which is used to preview images by default on Mac OS X, has a convenient resize feature built right into it. It is found under the Tools menu, aptly named “Adjust Size“.

One apparent gotcha that can bite you crazy about resizing using Preview is that after adjusting the size for an image, the preview of the image will shrink considerably to a size smaller than you would expect. Don’t let that mislead you. Once you save the image, Preview will re-display the image in the proper, expected size.

Short and useless commit messages

I have been guilty of writing short, pointless, and completely useless commit messages [before]. Stoked by a recent thread on StackOverflow about the worst commit message that one has ever authored, I looked into the commit log for a project I have been working on and subsequently maintaining for the last one year. I had to learn git as it had been decided that git would be used for version control for the project. Git indeed has been used since the onset of the project, but during the first three quarters working on the project, due to my unfamiliarity with working with distributed version control and shameful lack of knowledge of how git worked and a growing misperception that git is overly complicated for beginners to distributed version control, I used git sparingly (in the sense that I did not commit regularly, nor did I use any of its more than simple features) and ham-handedly. Nevertheless, skimming through the commit log from since the very initial commit, I found the following gems:

• minor changes
• some brief changes
• assorted changes
• lots and lots of changes
• another big bag of changes
• lots of changes after a lot of time
• LOTS of changes. period

Of course, the ever notorious “bug fixes” is also to be found at a lot of places.

On a happier note, since then, I have come to understand and utilise the full potential of git. And I no longer blurt out when authoring commit messages.

Debugging Django applications!

When developing Django applications, there can be many times when you would want to roll up your sleeves and get your hands dirty. You may want to know, for example, why the control isn’t falling into a certain block of code, what values are being returned to the view from the browser or test client, why a certain form is bailing out on you, or any manner of possible problematic scenarios. For these and many more, there are a number of things you can do to help yourself and your code. I am going to describe a couple of those that I frequently employ.

1. Quick and dirty debugging

Yes! It is the quickest, dirtiest, and easiest form of debugging that has been around since who knows when. Like with many other programming languages, it takes the form of Python print statements for Django. It is really helpful when you are running your Django applications off of the Django development server, where the print output make their way to the console from which the development server is run.

2. Python Logging framework

The Logging framework for Python is as easy to use as they come. The use of the logging framework resembles to some extent quick and dirty debugging, but goes much further in terms of the flexibility as well as the levels of sophistication it provides. The simplest and quickest use is to import the logging module in the file carrying the code you want to debug, and use any of the available log message creation methods: debug(), info(), warning(), error(), etc. The output from these methods will make their way to the console where the development server is running.

With the default settings, however, the logged messages do not provide useful information beyond what you tell them to print. Also, you have no control over where the messages end up showing. So, say, if you are running your Django project over Apache with mod_python or mod_wsgi, you may be up a stump trying to locate where the messages go, or you may want to keep the messages aloof in a different file, but will find that the default settings for the logging framework won’t be able to lend you much room to breathe.

However, that is where the Logging framework really shines. It is configurable to a great extent. The docs for the framework give detailed information about the different nuts and bolts of the framework and the different ways in which it can be tuned. For the sake of this article, I will briefly brush over a slightly basic configuration that I use the logging framework in when debugging Django applications. I simply create a basic configuration setting for the logger, and move it into the settings.py file for the Django project. It looks like this:

import logging
logging.basicConfig(level=logging.DEBUG,
  format='%(asctime)s %(funcName)s %(levelname)-8s %(message)s',
  datefmt='%a, %d %b %Y %H:%M:%S',
  filename='/tmp/project.log', filemode='w')


Not only does this separate the log messages to the file /tmp/project.log, it also adds useful debugging information to the start of each logged message. In this particular case, the date and time, the name of the function from which the logging method was called, the logging level, and the actual message passed are displayed. All these and much more are thoroughly documented with elaborate examples in the documentation for the logging module.

3. The Python Debugger (pdb)

You may probably already have used the pdb module before for debugging Python scripts. If you have not figured out already, you can just as easily use pdb to debug your Django applications.

If you are like me, you may have got into the habit of writing unit tests prior to writing down Django views that the unit tests test. It is a wonderful habit, but it can get unnerving at times when you are writing your tests first. This is primarily because of the way the unit tests interact with your code: Once written, they run in their entirety without any form of interaction from the user. If any number of tests fail, the fact is made clear at the conclusion of the test runner. What I want to say is that there is no easy way for you to interact when the tests are being run.

With pdb, you can have a moment to sit back and take a sigh of relief. By importing the pdb module, and calling the pdb.set_trace() method right before the point where you want to start to debug your code, you can force the test runner to freeze itself and drop to the familiar, friendly pdb prompt. This helps immensely when you want to find out, for example, why a form that you are unit testing is not validating, what error messages it is receiving, what errors or outputs it should produce so that your tests can simulate those, etc. Once at the pdb prompt, you may use the usual lot of pdb commands to inspect and step through the code.

The use of pdb, however, it not restricted to unit testing. It may equally well be used when serving your Django applications over the development server. However, there is one little detail that needs to be accounted for. When you want to debug your Django applications over the development server with pdb, you must start the development server with these additional switches:

$ python -m pdb manage.py runserver --noreload

The -m pdb switch is documented in the documentation for the pdb module. Simply, it makes sure that if the program being debugged burps and crashes (either owning to an error, or when stimulated such as by calling the pdb.set_trace() method), the pdb module automatically falls flat on its face and activates the post-mortem debugger. This is very convenient, because what it means is that the friendly pdb prompt shows up, and you can dissect the code from that point onwards.

The --noreload switch to the runserver command, however, is crucial. The Django development server is designed to automatically reload the Python interpreter if there’s a crash or error of some sort, or to reread all the Django files if there has been a change in any one of those. One fallout of this default behaviour of the development server is that since the Python interpreter is reloaded, all previous context is lost, and therefore, there is no way for pdb to save face. The --noreload switch, therefore, forces the Django server to stray off of its default behaviour.

With the development server running with these switches, all you have to do is make sure you have placed calls to pdb.set_trace() method in your code where you want to break out. And that’s as easy as it gets.

I hope that what I have described finds its way into the useful bucket of my readers. For now, that’s all. I hope you do enjoy, if you did not before, debugging your Django applications after reading this article. Please, stay safe, and good bye!