Who's Being Schooled?
Monday, October 31, 2011 | 10:41 AM
Labels: gsoc
Monday, October 31, 2011 | 10:41 AM
Labels: gsoc
Friday, October 28, 2011 | 5:00 PM
Labels: android, selenium, webdriver
Mobile testing has come a long way since the days when testing mobile web applications was mostly manual and took days to complete. Selenium WebDriver is a browser automation tool that provides an elegant way of testing web applications. WebDriver makes it easy to write automated tests that ensure your site works correctly when viewed from an Android or iOS browser.
For those of you new to WebDriver, here are a few basics about how it helps you test your web application. WebDriver tests are end-to-end tests that exercise a web application just like a real user would. There is a comprehensive user guide on the Selenium site that covers the core APIs.
Now let’s talk about mobile! WebDriver provides a touch API that allows the test to interact with the web page through finger taps, flicks, finger scrolls, and long presses. It can rotate the display and provides a friendly API to interact with HTML5 features such as local storage, session storage and application cache. Mobile WebDrivers use the remote WebDriver server, following a client/server architecture. The client piece consists of the test code, while the server piece is the application that is installed on the device.
public void testGoogleCanGiveWeatherResults() {
// Create a WebDriver instance with the activity in which we want the test to run.
WebDriver driver = new AndroidDriver(getActivity());
// Let’s open a web page
driver.get("http://www.google.com");
// Lookup for the search box by its name
WebElement searchBox = driver.findElement(By.name("q"));
// Enter a search query and submit
searchBox.sendKeys("weather in san francisco");
searchBox.submit();
// Making sure that Google shows 11 results
WebElement resultSection = driver.findElement(By.id("ires"));
List<WebElement> searchResults = resultSection.findElements(By.tagName("li"));
assertEquals(11, searchResults.size());
// Let’s ensure that the first result shown is the weather widget
WebElement weatherWidget = searchResults.get(0);
assertTrue(weatherWidget.getText().contains("Weather for San Francisco, CA"));
}

WebElement toFlick = driver.findElement(By.id("image"));
// 400 pixels left at normal speed
Action flick = getBuilder(driver).flick(toFlick, 0, -400, FlickAction.SPEED_NORMAL)
.build();
flick.perform();
WebElement secondImage = driver.findElement(“secondImage”);
assertTrue(secondImage.isDisplayed());
assertEquals(landscapeSize, secondImage.getSize())
((Rotatable) driver).rotate(ScreenOrientation.PORTRAIT);
assertEquals(portraitSize, secondImage.getSize());
// Get a handle on the local storage object
LocalStorage local = ((WebStorage) driver).getLocalStorage();
// Ensure that the key “name” is mapped
assertEquals(“testUser”, local.getItem(“name”));
File tempFile = ((TakesScreenshot) driver).getScreenshotAs(OutputType.FILE);
Thursday, October 27, 2011 | 3:00 PM
Recently, I had the rare privilege of attending the annual Implementers meeting of OpenMRS, my Google Summer of Code mentoring organization. Thanks largely to the conference sponsorship by Google, OpenMRS was able to fund my week-long visit to Kigali, Rwanda. I traveled over 4,500 miles to meet with core OpenMRS developers, other volunteers, implementers (people with both IT skills and health care experience who work to deploy OpenMRS in their hospital, clinic, laboratory, etc.), service providers and researchers who had gathered there for the conference.

Wednesday, October 26, 2011 | 1:15 PM
Labels: Coverage, gtac, javascript, ScriptCover
We are pleased to announce the open source release of a Javascript coverage analysis tool called ScriptCover. It is a Chrome extension that provides line-by-line Javascript code coverage statistics for web pages in real time without user modification of the site. Results are collected when the page loads and continue to be updated as users interact with the page. These results can be viewed in real time through a reporting tool which highlights the executed lines of code for detailed analysis. ScriptCover is useful when performing manual and automated testing and in understanding and debugging complex code.

Sunday, October 23, 2011 | 6:00 PM
Labels: gsoc
We are pleased to announce the final results of this year's OpenICC participation in the Google Summer of Code program. OpenICC mentored two students directly and one student through collaboration with the openSUSE organization. All three of our students successfully met their project goals and completed their colour management projects.
Yiannis Belias worked on the API stabilization for Oyranos Colour Management System II project. The new classes, code generator improvements, and tools he worked on will be integrated into the Oyranos master branch in upcoming months. This project helps in stabilizing the CMS core, which covers a great foundation of functionality.
Monday, October 17, 2011 | 5:00 PM
Labels: data transparency, hackathons
Friday, October 14, 2011 | 1:25 PM
Thursday, October 13, 2011 | 12:00 PM
Labels: Eclipse
Wednesday, October 12, 2011 | 11:30 AM
Labels: django
Monday, October 10, 2011 | 10:00 AM
Thursday, October 6, 2011 | 10:00 AM
Labels: app engine, chrome, open source release
Are you a website developer that wants to know if Chrome updates will break your website before they reach the stable release channel? Have you ever wished there was an easy way to compare how your website appears in all channels of Chrome? Now you can!
QualityBots is a new open source tool for web developers created by the Web Testing team at Google. It’s a comparison tool that examines web pages across different Chrome channels using pixel-based DOM analysis. As new versions of Chrome are pushed, QualityBots serves as an early warning system for breakages. Additionally, it helps developers quickly and easily understand how their pages appear across Chrome channels.


Tuesday, October 4, 2011 | 6:00 PM
Labels: gsoc
Monday, October 3, 2011 | 10:00 AM
This year HelenOS, an operating system based on a multiserver microkernel design originating from Charles University, Prague, had the privilege of becoming a mentoring organization in the Google Summer of Code program. Our preparation began a couple of months before mentoring organizations started submitting their applications, but the real fun hit us when we were accepted as a mentoring organization and when the students started sending us their project proposals.
We put together about a dozen ideas for student projects and received about twenty or so official proposals. HelenOS had three mentors and we were thrilled to be given three student slots for our first year in the program. During the student application period we received a lot of patches from candidate students determined to prove their motivation and ability to work with us. It was no coincidence that the three students we chose submitted some of the most interesting patches and did the most thorough research. Two students sent us enough material to seriously attack the first milestones of their respective projects and the third student fixed several bugs, one of them on the MIPS architecture.
The three selected students were Petr Koupy, Oleg Romanenko and Jiri Zarevucky. Petr and Jiri worked on related projects focused on delivering parts of the C compiler toolchain to HelenOS while also improving our C library and improving compatibility with C and POSIX standards. Oleg chose to further extend our FAT file system server by implementing support for FAT12, FAT32, long file name extension and initial support for the exFAT file system.
When the community bonding period began and we started regular communication with our students, all three mentors, Martin Decky, Jiri Svoboda and Jakub Jermar, noticed an interesting phenomenon. Our students seemed a little shy at first, preferring one-on-one communication with their mentor, as opposed to more open communication on the mailing list. This bore some signs of the students expecting the same kind of interaction a student receives while working on a school project with a single supervisor and evaluator. Even though not entirely unexpected, this was not exactly how we intended for the students to communicate with the HelenOS team but we eventually managed to change this trend.
In short, all three of our students were pretty much technically trouble-free and met their mid-term and final milestones securely. To our relief, this was thanks to the students’ skills rather than projects being too easy. Two of our students were geographically close to their mentors so Jiri and Petr attended one or two regular HelenOS onsite project meetings held in Prague.
Besides the regular monthly team meetings, the HelenOS developers met for an annual coding week event called HelenOS Camp. This year the camp took place during the last coding week of the program and we were excited that one of our Google Summer of Code students, Petr Koupy, was able to join us for the event and hack with the rest of the HelenOS team.
Shortly after Google Summer of Code ended we merged contributions of all three students to our development branch, making their work part of the future HelenOS 0.5.0 release.
Below is a screencast showing HelenOS in its brand new role of a development platform, courtesy of Petr Koupy.
By Jakub Jermar, HelenOS Org Administrator and Mentor for Google Summer of Code
©2010 Google - Privacy Policy - Terms of Service