We did it again, and we are getting better at it. Last Thursday, May 7th we hosted the 7th Open Source Jam in Zurich. It was probably our largest event, with close to 50 participants!
It was a bit more than 3 hours of event, and 10 projects were presented: EVMS (Enterprise Volume Management Software) which promises to be a new model of volume management for Linux, My paint - very interesting software to create images from scratch, RTEMS - a real time operating system for multiprocessor systems, Solid State Drives, Monitoring Systems, Gurtle - an issue tracker integration for TortoiseSVN, RDKit - cheminformatics and machine learning software, a very nice overview on the development model and features of Drupal, SQL for Google App Engine, and OSGi, the dynamic module system for Java.
We would like to thank you all again for participating and sharing the interesting projects you are working on, and also invite you to subscribe to our Open Source Jam Zurich Group to stay informed about other events in Zurich.
Unfortunately, our official photographer was out of town, but we promise pictures for the next Open Source Jam!
Google Update Releases Update Controls
Thursday, May 14, 2009
Whenever we build out new products and features at Google, we try to ensure that we provide users with two key components: transparency and control. About a month ago we released the Google Update source code to give users and developers transparency into Google's update mechanism. Today we hope to fulfill this second component by providing advanced users the ability to control the installation and updating of Google products via Google Update. Thanks to automatic updates, most users should already have this version of Google Update.
The update policy is controlled via Windows Group Policy, allowing network administrators to apply policies to all computers on their domain and power users with administrative privileges to set the policy on individual machines. We provide an Administrative Template file that allows selection of policies using standard graphical user interfaces such as Group Policy Editor.
The new Group Policy support allows an administrator to specify which Google applications can be installed and how they should be updated. You can select from one of three update options: automatically, manually, or not at all. Administrators can also control how frequently Google Update checks for software updates.
Mac users have similar controls over Google Software Update. Mac users are able to change how often update checks occur or disable update checks all together. See the Managing updates in Google Software Update Help Center article for details.
We work hard to keep our users safe and secure when using our applications, and we believe that making sure users have the latest software available using automatic updates is a key component of that. However, we realize that there are situations where automatic updates may not be desirable so we wanted to provide the ability to control updates when necessary.
To get started, take a look at the Google Update for Enterprise documentation.
Spreading the Summer Love in Chicago
Tuesday, May 12, 2009
There are many ways to get the word out about Google Summer of Code™, and one of the most fun ways is the Google Summer of Code meetups that participants organize around the world. After a successful meetup last year for University of Chicago students, the University's ACM student chapter decided to organize another meetup this year, open to other universities in the Chicago area and again hosted by Google. Thus, on April 30th, around 70 students from The University of Chicago, Northwestern University, DePaul University, the Illinois Institute of Technology, and the University of Illinois at Chicago converged upon Google's offices in downtown Chicago, who happily allowed us to use their space, eat their food, and consume their caffeinated beverages.
Like last year, the event revolved around a series of lightning talks where Google Summer of Code students and mentors in Chicago talked about their upcoming work, and Google engineers talked about cool stuff they are involved in. Among the evening's highlights, there was mingling:
Whereas last year we were greeted by the Tower of Hanoi of Chinese Food, this year we were met by the Mexican Food Buffet of Awesomeness:
The talks took place in Google's offices on the 17th floor of a downtown building, with stunning views of the city:
(That tall black building is the John Hancock Center )
Our Google Summer of Code speakers were (left to right, top to bottom):
Not pictured are a couple other Google Summer of Code students from Chicago who couldn't make it to the meetup or did not give talks: Joe Doliner (University of Chicago, student for BRL-CAD), Caden Howell (DePaul University, student for the Electronic Frontier Foundation), Chandra Ramachandran (University of Illinois at Urbana-Champaign, student for the National Center for Supercomputing Applications ), and Ori Rawlings (Illinois Institute of Technology, student for the Natural User Interface Group).
Our Google speakers were (left to right) Nathaniel Manista, Jon Trowbridge, and Jacob Lee, who provided us with a steady supply of very amusing slides.
Oodles of thanks go to Google for hosting this event (specially to Jon Trowbridge, organizer extraordinaire) and congratulations to our Chicago-area students for making it into Google Summer of Code!
Like last year, the event revolved around a series of lightning talks where Google Summer of Code students and mentors in Chicago talked about their upcoming work, and Google engineers talked about cool stuff they are involved in. Among the evening's highlights, there was mingling:
Whereas last year we were greeted by the Tower of Hanoi of Chinese Food, this year we were met by the Mexican Food Buffet of Awesomeness:
The talks took place in Google's offices on the 17th floor of a downtown building, with stunning views of the city:
(That tall black building is the John Hancock Center )
Our Google Summer of Code speakers were (left to right, top to bottom):
- Derek Schaefer (DePaul University), who will be working for MySQL to improve the import functionality of phpMyAdmin
- Chelsea Bingiel (University of Chicago), who will be adding support for the Atom Publishing Protocol in Plone .
- Dev Ghosh (Northwestern University), who will be adding a new "mosaic mode" for Hugin/Panotools .
- Dirk Eddelbuettel (R Foundation, mentor), who told us all about the cool Google Summer of Code projects the R Foundation has mentored and will mentor this year.
Not pictured are a couple other Google Summer of Code students from Chicago who couldn't make it to the meetup or did not give talks: Joe Doliner (University of Chicago, student for BRL-CAD), Caden Howell (DePaul University, student for the Electronic Frontier Foundation), Chandra Ramachandran (University of Illinois at Urbana-Champaign, student for the National Center for Supercomputing Applications ), and Ori Rawlings (Illinois Institute of Technology, student for the Natural User Interface Group).
Our Google speakers were (left to right) Nathaniel Manista, Jon Trowbridge, and Jacob Lee, who provided us with a steady supply of very amusing slides.
Oodles of thanks go to Google for hosting this event (specially to Jon Trowbridge, organizer extraordinaire) and congratulations to our Chicago-area students for making it into Google Summer of Code!
Introducing WebDriver
Friday, May 8, 2009
WebDriver is a clean, fast framework for automated testing of webapps. Why is it needed? And what problems does it solve that existing frameworks don't address?
For example, Selenium, a popular and well established testing framework is a wonderful tool that provides a handy unified interface that works with a large number of browsers, and allows you to write your tests in almost every language you can imagine (from Java or C# through PHP to Erlang!). It was one of the first Open Source projects to bring browser-based testing to the masses, and because it's written in JavaScript it's possible to quickly add support for new browsers that might be released
Like every large project, it's not perfect. Selenium is written in JavaScript which causes a significant weakness: browsers impose a pretty strict security model on any JavaScript that they execute in order to protect a user from malicious scripts. Examples of where this security model makes testing harder are when trying to upload a file (IE prevents JavaScript from changing the value of an INPUT file element) and when trying to navigate between domains (because of the single host origin policy problem).
Additionally, being a mature product, the API for Selenium RC has grown over time, and as it has done so it has become harder to understand how best to use it. For example, it's not immediately obvious whether you should be using "type" instead of "typeKeys" to enter text into a form control. Although it's a question of aesthetics, some find the large API intimidating and difficult to navigate.
WebDriver takes a different approach to solve the same problem as Selenium. Rather than being a JavaScript application running within the browser, it uses whichever mechanism is most appropriate to control the browser. For Firefox, this means that WebDriver is implemented as an extension. For IE, WebDriver makes use of IE's Automation controls. By changing the mechanism used to control the browser, we can circumvent the restrictions placed on the browser by the JavaScript security model. In those cases where automation through the browser isn't enough, WebDriver can make use of facilities offered by the Operating System. For example, on Windows we simulate typing at the OS level, which means we are more closely modeling how the user interacts with the browser, and that we can type into "file" input elements.
With the benefit of hindsight, we have developed a cleaner, Object-based API for WebDriver, rather than follow Selenium's dictionary-based approach. A typical example using WebDriver in Java looks like this:
// Create an instance of WebDriver backed by Firefox
WebDriver driver = new FirefoxDriver();
// Now go to the Google home page
driver.get("http://www.google.com");
// Find the search box, and (ummm...) search for something
WebElement searchBox = driver.findElement(By.name("q"));
searchBox.sendKeys("selenium");
searchBox.submit();
// And now display the title of the page
System.out.println("Title: " + driver.getTitle());
Looking at the two frameworks side-by-side, we found that the weaknesses of one are addressed by the strengths of the other. For example, whilst WebDriver's approach to supporting browsers requires a lot of work from the framework developers, Selenium can easily be extended. Conversely, Selenium always requires a real browser, yet WebDriver can make use of an implementation based on HtmlUnit which provides lightweight, super-fast browser emulation. Selenium has good support for many of the common situations you might want to test, but WebDriver's ability to step outside the JavaScript sandbox opens up some interesting possibilities.
These complementary capabilities explain why the two projects are merging: Selenium 2.0 will offer WebDriver's API alongside the traditional Selenium API, and we shall be merging the two implementations to offer a capable, flexible testing framework. One of the benefits of this approach is that there will be an implementation of WebDriver's cleaner APIs backed by the existing Selenium implementation. Although this won't solve the underlying limitations of Selenium's current JavaScript-based approach, it does mean that it becomes easier to test against a broader range of browsers. And the reverse is true; we'll also be emulating the existing Selenium APIs with WebDriver too. This means that teams can make the move to WebDriver's API (and Selenium 2) in a managed and considered way.
If you'd like to give WebDriver a try, it's as easy as downloading the zip files, unpacking them and putting the JARs on your CLASSPATH. For the Pythonistas out there, there's also a version of WebDriver for you, and a C# version is waiting in the wings. The project is hosted at http://webdriver.googlecode.com, and, like any project on Google Code, is Open Source (we're using the Apache 2 license) If you need help getting started, the project's wiki contains useful guides, and the WebDriver group is friendly and helpful (something which makes me feel very happy).
So that's WebDriver: a clean, fast framework for automated testing of webapps. We hope you like it as much as we do!
For example, Selenium, a popular and well established testing framework is a wonderful tool that provides a handy unified interface that works with a large number of browsers, and allows you to write your tests in almost every language you can imagine (from Java or C# through PHP to Erlang!). It was one of the first Open Source projects to bring browser-based testing to the masses, and because it's written in JavaScript it's possible to quickly add support for new browsers that might be released
Like every large project, it's not perfect. Selenium is written in JavaScript which causes a significant weakness: browsers impose a pretty strict security model on any JavaScript that they execute in order to protect a user from malicious scripts. Examples of where this security model makes testing harder are when trying to upload a file (IE prevents JavaScript from changing the value of an INPUT file element) and when trying to navigate between domains (because of the single host origin policy problem).
Additionally, being a mature product, the API for Selenium RC has grown over time, and as it has done so it has become harder to understand how best to use it. For example, it's not immediately obvious whether you should be using "type" instead of "typeKeys" to enter text into a form control. Although it's a question of aesthetics, some find the large API intimidating and difficult to navigate.
WebDriver takes a different approach to solve the same problem as Selenium. Rather than being a JavaScript application running within the browser, it uses whichever mechanism is most appropriate to control the browser. For Firefox, this means that WebDriver is implemented as an extension. For IE, WebDriver makes use of IE's Automation controls. By changing the mechanism used to control the browser, we can circumvent the restrictions placed on the browser by the JavaScript security model. In those cases where automation through the browser isn't enough, WebDriver can make use of facilities offered by the Operating System. For example, on Windows we simulate typing at the OS level, which means we are more closely modeling how the user interacts with the browser, and that we can type into "file" input elements.
With the benefit of hindsight, we have developed a cleaner, Object-based API for WebDriver, rather than follow Selenium's dictionary-based approach. A typical example using WebDriver in Java looks like this:
// Create an instance of WebDriver backed by Firefox
WebDriver driver = new FirefoxDriver();
// Now go to the Google home page
driver.get("http://www.google.com");
// Find the search box, and (ummm...) search for something
WebElement searchBox = driver.findElement(By.name("q"));
searchBox.sendKeys("selenium");
searchBox.submit();
// And now display the title of the page
System.out.println("Title: " + driver.getTitle());
Looking at the two frameworks side-by-side, we found that the weaknesses of one are addressed by the strengths of the other. For example, whilst WebDriver's approach to supporting browsers requires a lot of work from the framework developers, Selenium can easily be extended. Conversely, Selenium always requires a real browser, yet WebDriver can make use of an implementation based on HtmlUnit which provides lightweight, super-fast browser emulation. Selenium has good support for many of the common situations you might want to test, but WebDriver's ability to step outside the JavaScript sandbox opens up some interesting possibilities.
These complementary capabilities explain why the two projects are merging: Selenium 2.0 will offer WebDriver's API alongside the traditional Selenium API, and we shall be merging the two implementations to offer a capable, flexible testing framework. One of the benefits of this approach is that there will be an implementation of WebDriver's cleaner APIs backed by the existing Selenium implementation. Although this won't solve the underlying limitations of Selenium's current JavaScript-based approach, it does mean that it becomes easier to test against a broader range of browsers. And the reverse is true; we'll also be emulating the existing Selenium APIs with WebDriver too. This means that teams can make the move to WebDriver's API (and Selenium 2) in a managed and considered way.
If you'd like to give WebDriver a try, it's as easy as downloading the zip files, unpacking them and putting the JARs on your CLASSPATH. For the Pythonistas out there, there's also a version of WebDriver for you, and a C# version is waiting in the wings. The project is hosted at http://webdriver.googlecode.com, and, like any project on Google Code, is Open Source (we're using the Apache 2 license) If you need help getting started, the project's wiki contains useful guides, and the WebDriver group is friendly and helpful (something which makes me feel very happy).
So that's WebDriver: a clean, fast framework for automated testing of webapps. We hope you like it as much as we do!
O BSDCanada!
Thursday, May 7, 2009
BSDCan 2009, an annual BSD conference at the University of Ottawa in Ontario, Canada will be held this year on May 8th and 9th, 2009. The Open Source Team's Leslie Hawthorn and Cat Allman will be there to mingle with the Open Source community and present a talk on Getting Started in Free and Open Source on May 8th at 11 AM local time. This talk is a fantastic introduction to the Open Source community for those who are new and want to get involved. In addition, Open Source veterans will discover insights into the concerns of newbies and learn ways to improve retention and make their projects more welcoming. By running projects such as Google Summer of Code™ and the Google Highly Open Participation™ Contest, Leslie and Cat have gathered a huge amount of experience working with Open Source newcomers, and they are excited to share their knowledge with the rest of the community.
This will mark Google's third year at BSDCan, with Brian 'Fitz' Fitzpatrick and Ben Collins-Sussman speaking there in 2007 and Leslie presenting in 2008. If you are in the area, make sure to attend this year's talk, and feel free to say hello or introduce yourself afterward!
This will mark Google's third year at BSDCan, with Brian 'Fitz' Fitzpatrick and Ben Collins-Sussman speaking there in 2007 and Leslie presenting in 2008. If you are in the area, make sure to attend this year's talk, and feel free to say hello or introduce yourself afterward!