<html>

<head></head>

<body>
    <div class="item">
        <div class="item-header">



        </div>

        <div class="item-body">

            Every once in a while I get fed up with Firefox and switch to <a href="http://www.konqueror.org/">Konqueror</a>, only to return a few days later. The latest annoyance with ff is an old one; when you type in a text into the search box, an error pops up.
            <p style="padding-left: 60px;"><span style="color: #800000;">ASSERT: *** Search: _installLocation: engine has no file!
                    Stack Trace:
                    0:ENSURE_WARN(false,_installLocation: engine has no file!,2147500037)
                    1:()
                    2:()
                    3:SRCH_ENG_getSubmission(wad,application/x-suggestions+json)
                    4:getSubmission(wad,application/x-suggestions+json)
                    5:(wad,searchbar-history,null,[xpconnect wrapped nsIAutoCompleteObserver])</span>

                Fortunately it's not very serious and can be made to go away by just restarting FF. On this occasion, I was too lazy to do even that and continued with my work until some JavaScript started to misbehave. Then I tried to view source, only to run into this error:
            </p>
            <p style="padding-left: 30px;"></p>

            <p style="padding-left: 30px;"><span style="color: #800000;">XML Parsing Error: undefined entity
                    Location: chrome://global/content/viewSource.xul
                    Line Number6, Column 1:&lt;window id="viewSource"</span>
            </p>
            <p style="padding-left: 30px;"></p>

            This time though, I am not going to switch back to Konqueror, cause I know that the culprit here isn't Firefox but yum!. That's right, you see this sort of error most often when the system has been updated. When firefox is updated it has to be restarted but when you do the update with yum it doesn't happen automatically.
            <p style="padding-left: 30px;"></p>

        </div>
    </div>


</body>

</html>

Wierd Firefox Errors

<html>

<head></head>

<body>
    <div class="item">
        <div class="item-header">



        </div>

        <div class="item-body">

            On August 8th I left for a well deserved ten day vacation (working vacation mind you) so it was only natural that my Macbook hard drive died shortly before that. I am thankful that the drive didn't roll kick the bucket on the first day of the vacation. That would have forced an immediate return to Colombo and force me to lug my desktop (monitor and all) back with me!

            It all started when the Macbook suddenly froze up while I was browsing and wouldn't respond at all and had to be shutdown with a long press of the power button. When I tried to start it up again, a screen with a flashing folder + question mark icon popped. Immediately I knew this had to be a toasted hard drive. This was confirmed in 2 seconds by Google.
            <p style="text-align: center;"><a title="A question mark" href="http://images.raditha.com/blog/images/apple-question.jpg"><img class="aligncenter" src="http://images.raditha.com/blog/images/apple-question-t.jpg" alt="A question mark with a folder icon"></a></p>

            I was pretty sure my backups were up to date but having once tossed out a dead hard drive thinking the backups were upto when they were not, I was really determined to take a close look at the drive's contents before tossing it. That meant buying a firewire cable to attempt to connect the macbook to another in target mode. I knew the chances of it working were remote so I bought a hard drive enclosure as well. The idea was to freeze it and put it in the enclosure. Obviously you cannot put in a frozen drive back in the macbook because it would cause condensation and cause more damage. If it condensates in the enclosure you will probably be able to dry it out with a blower and still manage to reuse the enclosure later on.

            You might our read that freezing a drive to recover data is a myth&nbsp; or an urban legend. I can assure you that it works, when one of the hard drives on our company's server died, the hosting company (<a href="http://www.webquarry.com">The Webquarry</a>) admin put the drive in the freezer and managed to recover quite a bit&nbsp; of the data.

            Much to my chagrin I found that I need not have bothered with any of this. The problem was with the contacts. The SATA connector appeared to have shaken itself lose. I discovered this after taking out the hard drive and putting it back in (with fingers firmly crossed of course) and it just worked!! So it was the new drive that went into the enclosure. Then I used superduper to clone the old drive into a partition on the new drive ( The old drive is only 80GB but the new one has 320GB). Then I swapped the drives and booted up with the new one. Thanks to <a href="http://www.shirt-pocket.com/SuperDuper/SuperDuperDescription.html">superduper</a> the process was painless.

        </div>
    </div>


</body>

</html>

Macbook Hard drive toasted

<html>

<head></head>

<body>
    <div class="item">
        <div class="item-header">



        </div>

        <div class="item-body">

            <p></p>
            <p>If you want to write good , fast, memory efficient code (pick any three) you need to start off with good fast memory efficient algorithms. Using fprintf instead of fwrite or&nbsp; java.util.ArrayList instead of java.util.Vector or $.ajax instead of $.get doesn't really make any difference at all. If you spend your life trying to figure out which is faster or takes up less memory you will never get anything done. Sometimes <a href="readfile-vs-include-echo-vs-print-dont-bother.html">people who ought to know better even shout from the rooftops</a> that you should waste your time trying to shave off a few milliseconds here and there but fortunately there are more wiser heads to shoot them down.</p>
            <p>Since PHP added support for JSON encode and decode a lot has been written about how it's more efficient than serialize / unserialize and the have got the numbers to proove it too. In one study it was pointed out that json_encode takes 0.63 milli seconds to convert a certain object to text while the serialize function took just 0.41 milliseconds however that author suggests that all existing code that uses serialize/unserialize should be changed to json_encode/json_decode because decode/unserialize more often than encode/serialize and json_decode takes just 1.42ms vs 2.28 ms for unserialize. Another mutt had reproduced the same sort of results on eight different servers. Sure that's about a 50% improvement in speed. And if your script just happens to be executed 1,000,000 times you will save a whopping 860 seconds! you will probably get a 100% increment at your next evaluation too.</p>
            <p>Most often you want to convert and object to a string because you want to send it over the wire or save it in a database. If your applications appears to be slow it's probably because the database query is slow or it takes a lot of time to retrieve the data from the remote server. If it takes two seconds to retrieve/store&nbsp; the data what difference does it make to shave of 0.0005 of a second by changing from json to php serialize?</p>
            <p>I am not saying you should not make any effort to optimize your code at all. Wordpress and Windows OS are examples that scream out for optimization. What I am saying is that you should write your code with a decent algorithm (but don't rupture yourself looking for one), then test your app. If you find it's slow and doesn't scale well, run it through a profiler to find the bottleneck. You will usually find that about 20% of the code takes up about 80% of the execution time sometims it's worse. All you need to do is to look at that part of the code and optimize it or perhaps even change the algorithm.</p>
            <p></p>

        </div>
    </div>


</body>

</html>

Monthly Archives for 2009 08

Wierd Firefox Errors

Macbook Hard drive toasted

json_encode/json_decode vs serialize/unserialize and fools vs idiots.