Of course there are other alternatives in the Desktop Linux scene; offerings such as XFCE, LXDE and KDE all have their place. I personally don't have the time to familiarize myself with yet another desktop environment, especially given that my goal is to be running a Mac at work and at home. I had grown quite fond of GNOME 2 in previous releases of Ubuntu, so my next logical step was to use GNOME 3.

The problem with GNOME 3 is that of immaturity. It's still pretty rough around the edges (it crashes at least a couple of times a day for me under regular use), has very poor display driver support, and doesn't quite have the community momentum for themes and plugins like its predecessor had.

I've been using GNOME 3 for the past few months (at work and home) with the hopes that my gripes with it would be addressed shortly but unfortunately I'm yet to observe even incremental improvements in stability or performance. My work machine (which I'm using 8 hours a day) constantly needs gnome-shell restarts, and sometimes it locks up so bad I actually have to kill the whole session and lose everything I had open. Recently my patience has worn thin enough that I started conspiring to try something (anything, really) new on my machine at work. The proverbial straw was broken when somehow my NVIDIA display drivers (custom installed in order to address a host of issues with gnome-shell) was broken so badly by an Ubuntu update that I had to boot into recovery to fix it. But wouldn't you know it, recovery console isn't working with my setup for some reason - it wouldn't detect my keyboard!

I had read about the MATE project on the Linux Mint blog a few months back, so today I wondered how it had come along. The prospect of a pure GNOME 2 environment running in the latest Ubuntu sounded very promising indeed. I decided it was finally time to make the jump.

With a small amount of tinkering, I had a fully functional MATE session up and running in Ubuntu 11.10. It took a whopping 10 minutes to get MATE fully operational. All I had to do was the following:

• sudo bash -c 'echo "deb http://tridex.net/repo/ubuntu/ oneiric main" >> /etc/apt/sources.list'
• sudo apt-get update
• sudo apt-get install mate-archive-keyring
• sudo apt-get install mate-core
• Logout, select MATE from the session list and log back in

The thing that struck me immediately is HOW INSANELY FAST IT IS. Especially compared to GNOME 3/Unity. After getting Compiz up and running and using the desktop for an hour or two, I suddenly realized just how sorely I'd missed the polished and refined awesomeness that is GNO- er, MATE.

I am in the process of installing MATE on my home machine now so I can get as much exposure to MATE as possible over the coming weeks. I will be documenting my experiences here, and sharing all the gotchas I find as I go.

I have a page accepting uploads (using Yahoo UI uploader) for large files. I had it working a while ago but then I modified the whole design quite alot recently. All of a sudden when testing the uploader would randomly stop uploading after a couple of seconds, with absolutely no warning. I went so far as to trace the Flash logging output coming from the YAHOO uploader.swf to see what was going on - sure enough, it was spamming to the console the current upload status, and then randomly stopping out of the blue. No error messages. No warnings. No nothin'.

So it turns out I had the browse button sitting in a div with some text, and when the upload button was clicked, I was calling jQuery("#browseContainer").slideUp() to hide the text and browse button. Boom, that's what was causing it. No shit.

Turns out jQuery's slideUp() will put display:none on the animated element when it's done ... slideUpping it. Awesome story though - Flash plugins decide they shouldn't be running anymore when their parent element has display:block on it. No shit. This might be documented somewhere, but I'll be damned if it's common knowledge. Maybe I'm a total retard ...

Hope this helps someone.

I'm a little slow on the uptake here, the blog update I'm referring to is now 10 days old. I haven't been in the Facebook dev world of late, so I hope you'll forgive me for regurgitating old news.

The big update for me is in the 4th paragraph:

We are also moving toward IFrames instead of FBML for both canvas applications and Page tabs. As a part of this process, we will be standardizing on a small set of core FBML tags that will work with both applications on Facebook and external Web pages via our JavaScript SDK, effectively eliminating the technical difference between developing an application on and off Facebook.com.

This is excellent! I have actually been holding my breath for something like this for a while now. The restriction of FBML only content for tabs has been extremely restrictive, here are a handful of reasons why:

• Very strict HTML parsing - because the Platform was rendering tabs inline previously, it of course had to be VERY careful in how it handled offsite data, to protect users from all manner of scams/attacks. Now full flexibility is available because your iFrame is yours to control.
• Insanely strict JS parsing - same as first point, application tabs could only leverage basic Javascript and the unwieldy, poorly documented FBJS (Facebook Javascript). Now, you're free to access manipulate your IFrame document/window objects, DOM manipulate, include third party JS libs, etc, all to your hearts content.
• Embedded media was a pain - Granted, the tab FBML *did* allow you to embed Flash and AIR apps etc, but there were countless threads on the forum outlining issues they were having interacting with the host page, etc.
• Tab activation policies - There were some extremely frustrating rules with the way tabs were allowed to be "activated". No JS/FBJS was allowed to execute until the user had interacted with the tab in some manner, such as focusing a form element or clicking somewhere. This made it very cumbersome to implement any meaningful interactions with the user; alot of obnoxious boilerplate code had to be written for various ways in which you may actually start doing anything meaningful from JS, like AJAX requests.
• ... and lots more Everything from CSS parsing to the occasional time where the tab would just sit in an endless loading display when clicked. When I was writing a tab page I remember bashing my head against the wall trying to get some content to sit nicely in a cross browser fashion... it would have been easy under normal circumstances, but the Platform tab flavour was refusing to accept the *display: inline IE hack in the CSS. Joy.

This is going to really open up some great possibilities for interactive, rich web applications. I really cannot wait for this feature to be rolled out.

This news does come with some disappointment however; the sixth paragraph on the developers blog states the following:

Finally, due to low usage rates, we will remove application tabs from user profiles in the next couple months. Application tabs will continue to be supported on Facebook Pages.

There are plenty of great use cases to have application tabs on a user profile page. My personal Facebook profile has a tab that displays my latest last.fm scrobbles, my latest blog posts, etc. Personally, I believe that if the adoption rate for user profile tabs is low, the Facebook team should be coming up with ways to increase user acceptance of this feature, rather than removing it all together. Besides, the functionality in Facebook Page tabs is pretty much identical to the user profile equivalents... Why not support both?

There's other goodies in the developer blog update too, such as cleaning up the REST API considerably.

All in all, exciting changes coming to the Facebook platform in the coming months!

Step 1 was to play around with Chrome extensions. I haven't worked with plugins/extensions in any other browser, but I have to say.... Google NAILED this. It's so intuitive and straightforward. So easy to debug, so much power. I love you Google.

Anyway. Step 2 was where things got interesting - connecting to Facebook via the Javascript API and Facebook Connect. This proved to be quite complex. Facebook Connect has this fascination with the whole cross domain communication channel (XD for shortness) nonsense. Basically, this requirements essentially means to use the Javascript API you need to be hosting it on a standard web server to be able to add the xd_receiver.html file in a public-facing area where Facebook can see it.

After digging around the site for a while, I came across their fancy new Open Source Javascript SDK, I couldn't help but notice this didn't make a mention of the XD setup anywhere, so I assumed perhaps I might be able to work with this system better. As it happens, my suspicions were correct. The new JS library has some crazy voodoo magic set up so that an XD file isn't required, there's some kind of "XD proxy" running on the Facebook servers which will send login session data along the line to the JS library, using either document.postMessage or some Flash workaround thingy (not really sure how that works, don't particularly care.)

I immediately tried to use it in a Chrome extension, but alas! There was a few issues. I came up with workarounds for both though.

Issue #1 - the API does the following in the constructor:


_domain: {
api : window.location.protocol + '//api.facebook.com/',
cdn : (window.location.protocol == 'https:'
? 'https://s-static.ak.fbcdn.net/'
: 'http://static.ak.fbcdn.net/'),
www : window.location.protocol + '//www.facebook.com/'
},


Great! That would be fantastic if our chrome extension was running on http, but the protocol when running from options or background.html pages is "chrome-extension://". So when the API went to make with the server side communications, it was trying to remote to chrome-extension://api.facebook.com, which of course is not really gonna work.

My solution to this was to just fudge it by putting the following snippet in before using the FB lib anywhere:


FB._domain = {
api : 'https://api.facebook.com/',
cdn : 'https://s-static.ak.fbcdn.net/',
www : 'https://www.facebook.com/'
};


With that change, the API won't have any more tantrums when trying to phone home. Easy!

Issue #2 - Facebook Connect is still broken.

This one was the biggie. Essentially, even though the new API does some cool hocus pocus with XD, it's still referencing the "origin domain" in the request, this original domain is of course just going to be the extension URL, which is not terribly useful, as Facebook will freak out when it gets a request coming from an invalid URL. I tried fudging the origin to a valid domain (dodgy I know, I was getting desperate). Interestingly, Facebook was fine with this, but of course when the request came back to the browser and the XD proxy tries to postMessage() the session data back, the browser freaks out as it looks like an XSS attack.

There might be other ways around this drama, but I opted for what I feel to be a fairly elegant solution.

Essentially, I opted to "pretend" I'm something of a desktop application trying to authenticate with Facebook application (which is true in a sense, I suppose). This Developer Wiki page gave me some insight into how to authenticate my application with the FB user the old-fashioned way.

The idea is this: popup the login/app-authenticate page manually with a special URL, setting the return URL to a random dummy Facebook page they have running for desktop app clients: http://www.facebook.com/connect/login_success.html. When the user visits the login page, once they have logged in and allowed the app access (or if they are already logged in and have already allowed the app), they are redirected to a page that has the session data in the querystring encoded in JSON. Login achieved.

So I set about doing this in my extension, simple enough to start with:


var win = window.open("http://www.facebook.com/login.php?api_key=&connect_display=popup&v=1.0&next=http://www.facebook.com/connect/login_success.html&cancel_url=http://www.facebook.com/connect/login_failure.html&fbconnect=true&return_session=true&session_key_only=true", "fbconnect", "width=400,height=400");


Great! If I was a *real* desktop application and I was running a Webkit/IE/whatever browser instance as some kind of evil overlord, I could just detect when the browser redirects to login_sucess.html, grab the querystring, parse the session data out of it, and be on my merry way! I'm running in a browser though, so how about I just access the child window that I opened with window.open, access the location.search property and parse that? "NO", says the magical little pixies living inside the browser, "That would be against my strict Same Origin Policy (SOP, kinda like ... sop story, teehee)!!!".

Fair enough. There was an easy enough workaround though, I just embedded a content script via the Extension to sniff out the session data when it became available, and send it to the main extension. Like so:

Add the trigger for the content script to the extension manifest.json file:


"content_scripts": [
{
"matches": ["http://www.facebook.com/connect/login_success.html*"],
"js": ["prototype.js", "intercept_session.js"]
}
],


I threw prototype in there just for convenience sake, as you'll see in the next step.

Then intercept_session.js looks like this:

var params = window.location.search.toQueryParams();

chrome.extension.sendRequest({message: "setSession", session: session}, function() {
window.close();
});

What this code does is parse the querystring (using Prototype), then check if the session data is present. If it is, parse the JSON into the session object and send it off to the extension Background Page via the extension message passing system to be saved.

The background page simply has this:


var session = null;
if(localStorage.session)
{
session = JSON.parse(localStorage.session);
}

switch(request.message)
{
case "setSession":
{
localStorage.session = JSON.stringify(request.session);
session = request.session;
sendResponse();
break;
}
case "getSession":
{
sendResponse(session);
break;
}
}
});


Again, pretty straightforward stuff. I'm using the groovy new HTML5 local storage to remember the session data even if the browser is closed. The message handler simply listening for a session to be passed to it. When a session is provided, it will save it to local storage and a local variable. The getSession functionality is so other areas of your chrome extension can retrieve the session as needed (for example if you have a popup and want to query FB from there or something). You could obviously use this session anywhere as needed.

And that's that! From here you can make API calls to your hearts content. There's obviously some important things left out here, stale checking of the session when the background page loads up for example. Also, requesting extended permissions is not covered here, but it's pretty much the same as how the login deal works anyway. You would just update the login_success.html intercept script to check if this was a response for extended permissions, and check the querystring to ensure the permissions were supplied.

I've cooked up a quick little demonstration of this stuffs. Click here to install a demo extension that will add a button to the right of your address bar, which will show some clickable icons of 5 of your friends in a popup. You can also see the code for this extension here.

Time for me to go finish this extension!

One must wonder why. Why must a browser that is going on 8 and a half years old, superseded by no less than two newer versions in its product family, be installed on 20% of end users machines still? A browser with so many horrific DOM, CSS, and JS quirks that it eats up a grossly disproportioned amount of development time/money budget just making sure even the most basic of web apps works on this clunky piece of trash?

It's WELL past time for IE6 to slip into obscurity. Please. God.

Personally, when I develop websites, even basic ones with little to no JS, I target IE7+ now. I work in the smaller-scale end of the web market so I'm blessed with not usually needing to worry about larger organizations with a persnickety IT board who force ridiculous things like IE6-compatibility on me.

However, one of the organizations I work for has a contract for a fairly large government-initiative website. The website has been "completed" for a good year and a half now, with many further additions and changes since then. The initial contract *did* stipulate that the website should be presentable and operational on IE6, and it was. However as the website evolved and many things were added ad changed, little thought was given to IE6, as a result the site today is fairly broken in IE6.

My question is, where does the buck stop? Where should the line be drawn? Sure, maybe in the initial contract you stated the website would be compatible with IE6... But my belief is that unless your contract/maintenance agreement states something to the effect of: "IE6 will be supported, even when its obsolescence surpasses the point of ridiculous" then you should not be bound to sacrifice your soul on the altar of IE6.

Thankfully, IE6 was implicated in the hackings of some big corporations, with big names like Adobe and Google in the list, so its days are truly numbered now. Google Docs and Youtube are now displaying big ugly warning messages to IE6 users, urging them to upgrade. There are also movements like http://www.bringdownie6.com/ fighting the good fight.

IE6, may you die a painful, cancerous, leprous, acid-poured-down-the-throat-erous death.

From a hardware perspective the unit is rock solid, I haven't had any issues with the performance of the device. The battery life, or rather the shortness of it, took me by surprise somewhat. However this being my first smartphone I'm probably just not used to the demands constant 3g connectivity and a large touchscreen have on the poor battery.

The OS and general usability of it are nothing short of fantastic. I didn't need to read any kind of manual or even a "Get Started" guide to get the hang of everything. Initially the onscreen keyboard vexed me, but I wasn't fully aware of how it worked. After getting the hang of it my typing speed went through the roof, to the point where I'm already typing faster than I do with t9 input.

Of course my favourite aspect of the iPhone is the third party apps. I've got apps that let me connect to my windows work pc using RDP, translate text, convert currencies, do my net banking, and the list goes on. As it happens, I'm writing this blog entry using the fantastic WordPress2 app.

With all the exciting cloud based apps popping up and the steadily increasing support developers are affording mobile devices, I can't wait to see what 2010 brings for my iPhone to tickle my nerd fancy. As much as I hate you Apple, thanks for a device that just works!

I'm looking forward to Google bringing this app a bit closer to home, I can't wait to map the buildings in my local neighborhood!!

What I have is a project I've been working on for a while, it's a PHP site. I have it sitting in an SVN repository and it's basically just been me working on it. Currently I was just making changes then updating them via FTP on the server. It's a fairly complex site so now it's gotten to the point where there's plenty of pitfalls to doing this (breaking permissions, etc etc). Oh did I mention I was just pushing stuff directly to production site?

So I'm about to bring some contractors in to work on the site, I decided I obviously need a staging server. But that's not enough - I need it to update automatically! The complication? The SVN server and the staging server are two physically different servers. The traditional solution found from most Google searches is the post-commit hook executing a small binary to update a working copy elsewhere in the filesystem.

What I devised is a simple PHP script sitting on the dev server, when post-commit hook is called on SVN server it executes this script via cURL commandline.

The tricky part was getting the svn update php script to work. In the end I figured out a pretty decent solution. The trick was to set up sudo on the server and execute SVN commands via sudo in PHP.

I'm using Plesk, so when I created the dev server vhost a dev user was created. So what I did was edited /etc/sudoers and added the following:

apache ALL=(dev) NOPASSWD:/usr/bin/svn

What this does is allow apache (remember that PHP scripts execute under apache user and group) to execute svn under the dev user. The NOPASSWD is important, sudo only accepts input from interactive shell (there are some hacky ways of injecting cleartext but I found them to be somewhat hit and miss). NOPASSWD ensures that sudo does what we ask it to do, no questions asked.

So from the PHP script I had something like the following:

$sudoCommand = "/usr/bin/sudo -u dev ";
$svnUpdateCommand = "{$sudoCommand}/usr/bin/svn update --username devserver --password blah --non-interactive 2>&1";
$svnCleanupCommand = "{$sudoCommand}/usr/bin/svn cleanup 2>&1";

The rest is pretty self explanatory! Redirecting stderr to stdout, setting authentication details, blah blah blah. exec()'ing the command above does the trick.

Hope this helps someone!

Anyway heading into work today, will be working on PEGG stuff (Private Equity Gateway Group, mob I work for). Today I need to wrap up a project I've been working on for a while. It's a .NET system that maintains repositories of documents on a server, facilitates purchasing instances of these repositories, and synchronizes them to a client. It's going to be used to serve up informative documents for a couple of different industries.

Anyway, I took over the project a few months ago from another group. The source base was messy, spaghetti VB.net code (ugh!). I've cleaned it up to a production ready state, but I still feel dirty every time I boot up Visual Basic Express.

THe system we devised for this project has marketable worth, we might be taking it to other groups and looking at reselling it. For that reason as soon as this initial project is released I'm going to be redoing the entire codebase in C#. While I've always been a Java man I can't ignore how great .NET is.

This week I need to chug through a fair bit of work, got a couple of projects I'm being contracted to develop, deadlines are fast approaching. Maybe I shall blog on them later (they're fairly interesting!).

For now I'm gonna go back to Eclipse and play with Google AppEngine for Java a bit more.

...

Anyway. I has a blog. I'm going to post things to it as I see fit. I find it easier to think things through if I write them down as if someone else is reading them.

I'll probably be posting things here related to the work I am doing currently (general technology stuff, web technologies, etc). And maybe personal stuff when I'm feeling down and need to pretend people are reading and caring.

So I guess now I need to go play around with WordPress settings and make categories and stuffs.