Joe's Jottings

Tag: Chrome

  • If it ain’t on your machine, it ain’t yours.

    Yesterday I found out that Yahoo had pulled the plug on the Delicious application, amongst a few other APIs and services.  There will no doubt now be a spate of articles about how to move your content from these applications to somewhere else, and it may be that new services spring up out of the Internet eco-system to fill the gap.  But hopefully the users of these systems will have learnt a valuable lesson:

    If it ain’t on your machine, you cannot rely on it being there.

    This isn’t rocket science for those of us who cut our computing teeth in a pre-Cloud, pre-WWW world, but it was pointed out to me the other day that there are now large numbers of children and teenagers who have never lived in a world without the WWW.  Scary.

    A couple of years ago a Forum that I was an occasional contributor to shut up shop in a sudden and pretty final manner – the owner simply closed the shutters with little warning.  For me this was vaguely annoying but no biggie, but for other users of the Forum who’d committed some pretty large articles and intellectually robust commentary over a period of time, it was almost the equivalent of Edmund Blackadder having his novel burnt by Baldrick.  Of course, the site owner was perfectly within his rights to do this – free forum and all that.  But the general feeling was that a form of social contract had been broken.  However, one could easily say that the authors had not taken backups of their content…

    I mothballed a forum myself a year or so back – it’s still online, all content there, but posting has been disabled.  I have to say that in these times of almost limitless server space and cheap hosting it almost seemed churlish to pull the work of others. 

    But there may well be a point at which I let the domain go or re-use it for something else.  It’s perfectly within my rights to do so, and that content will then exist only as a zipped up backup on a DVD somewhere, and anyone who posted anything there, who wants it back and didn’t take a copy will have to whistle.

    And there is the issue; the ‘universal availability’ offered by browser based applications, the Web and the Cloud means that many people no longer own their own data, in anything but an intellectual property sense.  They don’t know where it is stored, they don’t know who gets to look at it, search it or mine it.  They don’t know how often it’s backed up, and have an assumption that ‘smeone’ will be taking care of it.  The increasing focus of Operating Systems on hiving off document and data storage to servers ‘out there’ in the Cloud or on the Internet (like Google’s new Chrome OS) is regarded as a great positive for those involved in Internet service related businesses – after all, it could well be the next big thing in what you can be charged for – always something folks like. 🙂

    There is something rather neat, in my opinion, about having your data on your hardware, under your control.  Yes, it’s your responsibility, but we need to start regarding personal or household data in the same way previous generations have looked after old letters and photographs.  If you need to work on stuff whilst away, then why not just put the files in question on USB sticks?

    And finally, data ‘out there’ is under the legislation and jurisdiction of whatever country the servers lie in.  You might want to look at things like the US PATRIOT act before saving your data anywhere that crosses US jurisdiction.  Whilst you might not think you’re a terrorist or a troublemaker, the definitions these days are flexible.

    Ultimately, there is something rather reassuring about having your data at home, under your roof, where the only way it can be seized or searched is when the stormtroopers kick the door in.

  • Chrome – the prissy Maiden Aunt of browsers….

    I’m currently involved in developing a web application of moderate complexity using Ext to provide a ‘Web 2.0’ front end on a PHP/mySQL application.  We’ve endeavoured to make it work across a range of browsers – Firefox, IE, opera and Chrome.  And this is the blog article in which I vent my spleen about Chrome.

    Because, you see, there are some occasions when Chrome is an absolute bag of spanners that behaves in a manner that just beggars belief, and it worries me immensely.  If IE behaved in the same way that Chrome does under certain conditions then the Chrome / Google Fanbois would be lighting their torches and waving their pitchforks as they headed out towards Castle Microsoft.

    Giving Chrome it’s due, Chrome renders CSS well against standards, and is frequently faster than Firefox and IE in terms of delivering pages; where it does seem to be lacking is in it’s sensible handling of JavaScript. The general impression I’ve had over recent days with Chrome and JavaScript is that it’s incredibly picky about how it handles JavaScript that is less than perfectly formed – hence the ‘Maiden Aunt’ jibe.  It requires everything to be very right and proper.  I understand that any browser should be expected to deal with properly structured script, but in recent years I’ve found that the major browsers tend to behave in a pretty similar manner when processing JavaScript and tend to vary in behaviour when rendering CSS – hence the fact the some sites look different in IE than they do in Firefox or Chrome.

    But I’ve encountered some horrendous differences in the way in which Chrome on one side and Firefox/IE on the other handle JavaScript.  Chrome seems to be very ‘tight’ in it’s handling of two aspects in particular; white space and commented out code.  I hope that following comments might prove useful to anyone doing JavaScript development – particularly with libraries such as Ext.  Note that these issues don’t occur all teh time with Chrome, but have occurred often enough to give me problems.

    Watch the White Space

    Chrome seems particularly sensitive to white space in places where you wouldn’t expect it to be.  For example:

    • Avoid spaces following closing braces ( } )at the end of a js source file.
    • Avoid spaces around ‘=’ signs in assignments. 
    • Avoid blank lines within array definitions – don’t put any blank lines after an opening ‘[‘ before data.

    Watch the comment lines

    The // construct used to make a line in to a comment line needs to be handled with care with Chrome.  Don’t include it in any object or array definitions – whilst it works OK in IE, it can cause major problems in Chrome.

    Indications of problems

    If you’re lucky you may get a straight forward JavaScript error – in this case you will at least have an idea of what’s what.  If you’re unlucky you may end up with either an apparent ‘locking up’ of Chrome or a 500 Internal Error message from your Web server.  The ‘lock up’ will frequently clear after a few minutes – the browser seems to be waiting for a timeout to take place.  When the errors do take place, I’ve found that the loading of pages featuring JavaScript errors is terminated – it can give the impression that a back end PHP or ASP.NET script has failed rather than client side script.

    In summary, just be aware that Chrome may not be as well behaved as one would expect.

    And that’s my whine for the day over!

Personal StuffTechnologyThe MediaPoliticsPersonal DevelopmentSoftware DevelopmentpsychologyphilosophyBlogs and BloggingEntrepreneur IssuesPrivacy IssuesUncategorizedChristianityLiteratureCommunity BuildingPersonal and Group NetworkingOnline CommunitiesScience FictionSocial MediahumourMusicWordpressScienceManagementRadioEntertainmentenvironmenteducationFilmWriting