I must be late to the party, but Gears finally works on Firefox 3, which is a Good Thing considering that RC3 has just been released. Yay! On the downside, Google Reader isn't showing up properly when I access it offline. Oh well, I'm sure that it'll be fixed soon.
On a related note, I've had the opportunity to delve into the Gears codebase. There's some pretty cool stuff in there, and if it wasn't Open Source it wouldn't have been so easy to use it as a learning tool. It's a pretty hefty amount of code, which makes getting to grips with it a slightly intimidating experience, but it's organised well and once you've started it starts to make more sense.
I find myself wondering how easy it is to attract new developers to the project: I know that the number of languages used in WebDriver puts some potential contributers off, and we've got far less "mass" to deal with. I'm working on the theory that the modularisation of both projects helps make getting started easier, and once people are involved it becomes less daunting to tackle the areas that seemed too hard to even look at.
I'd like to announce that we've made some new binaries of WebDriver available. What does this cornucopia of goodness bring you?
That last feature may need a little explanation, so perhaps an example of how to create a new Firefox profile on the fly would help:
FirefoxProfile profile = new FirefoxProfile();
profile.addExtension(new File("/path/to/an.xpi"));
WebDriver driver = new FirefoxDriver(profile);
I use this to install Firebug because it's sometimes useful to have it around when debugging. You can probably imagine a host of different extensions you'd like to use too.
The binaries are available from the Google Code site. If you'd like help getting to grips with them, the wiki may help and there's also a mailing list and group available: we're a friendly bunch, and new users are welcomed!
This is the reason why you want a code review of anything that goes into an Open Source project. Leif's comment towards the end seems well balanced and polite.
To whom it may concern,
I note with consternation that there appears to be widespread abuse of java.util.List and java.util.Set, and I believe it best to set the record straight forthwith.
The most important issue to bear in mind when choosing between the two aggrieved parties is whether duplicates are important. If they are, then I humbly concur that "List" is the correct choice. If, however, it is deemed that duplicates are not desirable, then "Set" would be a more apt choice.
Consider also whether the ordering of elements within the collection matters to you, and in particular whether insertion order is maintained. Lists typically maintain their elements in insertion order. Sets tend toward ordering the elements by their natural ordering, though as with the case of that red-headed step-child, the LinkedHashSet, this need not be the case.
Bearing these points in mind, it is with the greatest hope that I await the improvement of java.util.Set and java.util.List's situation.
Your humble servant,
Simon
I've had a couple of reports that my atom feed was broken. It was because of XML parsers doing what the spec says and choking on poorly formed XML (unbalanced tags in this case, where XML states that "a" and "A" are different)
I've now run the thing through the quite wonderful feed validator, so here's hoping that everything continues to work!
This is, quite possibly, the best piece of code I've seen all day: httpd.js. This is going to save me a huge chunk of effort as I work on updating the Firefox driver to be easier to use remotely.
The first public commit to the WebDriver repository was on 31st December, 2006. Some 280 revisions and 421 days later, it looks like its days are numbered. It's achieved far more than I thought it would; there's support for Firefox, various versions of IE and some basic support for Safari. I've written proof-of-concept bindings of the IE driver in C#, Python and Ruby, and I'm told that people have bindings for the Firefox driver that sink support for it into the Ruby on Rails testing grammar. Better yet, people are presenting about it at conferences and the community behind it is starting to grow.
Why, if it's all going so well, are its days numbered? The answer is that "WebDriver" won't be around for too much longer because it's going to become part of the Selenium 2.0 effort.
The original version of this post posed the questions "why do that?" and "what does it mean?", but you know what? I'm going to answer those in a different post. For now, I think the most important thing to remember is that this is going to make Selenium even better. It's going to be great!
The official announcement was at the recent Selenium User Open Evening. I have to say "thank you" to the Selenium development team for even thinking about this, and to all the people who have had a hand in making WebDriver as complete as it is. More so, I should thank the early adopters for their feedback and comments, both on the project page and the mailing list. Thank you!
Firefox 3 is coming, and it's about time I started looking at updating the WebDriver extension so that it works with it.
It's pleasing to see that the first page that shows up when you start beta 3 is a "help sheet", containing links to a bunch of useful information. There's also a helpful page on the Mozilla website containing information for XUL and extension developers. Notable for WebDriver is the fact that FUEL appears to be far more advanced than it was, and that there's native support for encoding and decoding JSON strings, which should give a small speed boost. Now, if only there was an embedded HTTP server!
I've yet to see if Firefox 3 is a XULRunner app, but if it is then there's a new avenue for automation that is opened up: JavaXPCOM.
From my initial explorations, this looks like it's going to be relatively painless. I'll keep you posted.
On Monday, 25th February, I'll be at the Selenium Users Open Evening. I'll be doing a Lightning Talk on the relationship between WebDriver and Selenium, which will be a (very) swift overview of what WebDriver is before delving into the meat of the matter. There probably won't be a duel this time!
There will Selenium developers from as far apart as Tokyo, London and the US attending, so it's a great opportunity to meet up with these guys. Better yet, the event is open to the public, so it's the perfect chance to meet Selenium users and talk about next generation web testing. It's being run at the main Google campus in Mountain View from about 6pm. I'm sure that someone, somewhere will post more comprehensive details and I'll link to these when they're posted, but I hope to see you there!
Update: Details are up here on the OpenQA site now.
Time for an update about my experiment about moving into the cloud. The original plan involved importing my email into Mail.app and copying from there into gmail. It turns out that this is an appalling idea for two reasons.
The first is that it'll take until approximately the heat death of the universe to copy my emails up this way. When the connection drops, which it does from time to time, Mail.app displays a friendly error message and stops. This sub-optimal behaviour means emails must be ferried up to the server in batches of about 200-400. Given that there are several tens of thousands of emails, this is a tedious process at best.
Secondly, gmail gets the wrong dates attached to the messages; using the date on which the message was uploaded rather than the date in the email itself for the "Date" column. Without sniffing network traffic, I suspect that what's happening is that either Mail.app isn't setting the date right in the APPEND command, or it's omitting it and gmail is guessing the date wrong, possibly because it's not parsing the incoming message. Or it might be both. Who knows? Either way, the wrong date is being displayed.
I think what we need here is a decent dose of automation. What's the point of being a geek if I don't take advantage of the awesome power of the computer? If the emails were appearing in gmail with the correct date, I'd suck up the pain of the one time import from mbox into Mail.app and use the wonder of Applescript to automate the upload, but since it's not and the JRuby 1.1RC2 has just been released, now's as good a time as any to see whether I put together a little ruby script to do the hard work.
Initial poking around suggests that this won't be too hard. There's a nice Net::IMAP module in the core Ruby distribution, and a tinker with irb quickly shows that it's possible to connect successfully and get some basic information out of gmail. Now, here's hoping that my mbox file and Maildir files are in RFC 822 format (or that gmail isn't too fussy about its inputs) I wonder if there's an implementation of the IMAP Multiappend extension?
If this doesn't work, then I may have to follow the advice of my friends and do the decent thing: set up an IMAP server somewhere and just do a straight copy. That plan reeks of "sounds easy, but isn't" to me, but that's because I'm a wimp when it comes to things like this. I'd use Google's email importer if it supported standard gmail accounts.
Right, time to throw some scripts together. How hard can this be?
Update: Ah! The wonders of Google. With the aid of this script, it looks like this won't be too bad. I've done a quick experiment with Maildir and mbox format folders and it looks like we're good to go. Wish me luck.