Open Source Blog

Archive for the ‘Google Open Source’ Category

Here at Google, we believe programming should be fast, productive, and most importantly, fun. That’s why we’re excited to open source an experimental new language called Go. Go combines the development speed of working in a dynamic language like Python with the performance and safety of a compiled language like C or C++. Typical builds feel instantaneous; even large binaries compile in just a few seconds. And the compiled code runs close to the speed of C. Go lets you move fast.

Go is a great language for systems programming with support for multi-processing, a fresh and lightweight take on object-oriented design, plus some cool features like true closures and reflection.

Want to write a server with thousands of communicating threads? Want to spend less time reading blogs while waiting for builds? Feel like whipping up a prototype of your latest idea? Go is the way to go! Check out the video for more information or visit golang.org.

By Robert Griesemer, Rob Pike, Ken Thompson, Ian Taylor, Russ Cox, Jini Kim and Adam Langley – The Go Team

Go to Source

We held the 14th Google London Open Source Jam at our Victoria HQ on September 24th. The topic this time was “Video and Sound”, and our Jammers had some real treats to share.

Steven Goodwin told us how his open source SGX 3D graphics engine deals with three key problems of other computer game engines. On a similar theme, Themis Bourdenas discussed the vine engine, a modular game engine for 2d and 3d games.

Borys Musielak presented Filmaster, an open source film recommendation engine. Neil Harris told us about an attempt by the Kendra Initiative to foster a common meta data format for content discovery on the semantic web.

In an Open Source Jam first, Jagannathan gave a performance of his Din software musical instrument. Din is designed for playing live Indian music, is based on Bezier curves and really has to be heard to be fully appreciated.

Sam Mbale gave us an update on his projects to help Africans build online communities using open source. Mike Mahemoff discussed some web tools frameworks for intranets, bookmarklets and trails in Scrumptious.

The UK government has plans to introduce a law to allow content-owners to force ISPs to disconnect the internet connection of users suspected of file sharing, without any proof. Glyn Wintel gave us an overview of how the proposed law will affect us, how the Open Rights Group is campaigning against it, and how we can help.

Douglas Squirrel talked about the difficulty blind people have in finding information on websites, and presented BlindPages.com – a new project to reformat the web in a screen-reader friendly way. He also demoed a prototype telephone interface to the service.

Much pizza was eaten and free beer drunk, and we all ended up in the pub next door to continue our discussions. A big thank you to all our speakers and attendees, and we hope to see you at the next Jam!

By Matt Godbolt, Mobile Engineering

Go to Source

Photo Credit: John ‘Warthog9′ Hawley

This past weekend, approximately 250 Open Source developers from around the world gathered at Google’s headquarters in Mountain View, CA for the fourth Google Summer of Code™ Mentor Summit. These developers who mentored students in this year’s Google Summer of Code program gathered “unconference” style to discuss ways to improve the program, share their experiences, and learn about each other’s projects.

One of the recurring comments about what makes the Mentor Summit special was that it gathers developers from a diverse range of projects (all 150 organizations participating in this year’s Google Summer of Code were invited to send two delegates). This allowed for a cross pollination of ideas that isn’t usually found at conferences dedicated to one specific platform or language. In addition, the summit was an opportunity for developers who usually collaborate online to meet face to face. In fact, some of our attendees met colleagues they had been working with for several years in person for the first time at the summit!

Most of all, the summit was a great place to meet like minded Open Source developers who are passionate about bringing in new contributors to their communities. Check out photos from the event or read through the session notes to find out more about what happened at this year’s summit.

by Ellen Ko, Open Source Team

Go to Source

The leaves are turning here in Mountain View, but they are not the only ones blazing away. It’s a busy time of year for open source for Google, with lots of talks and events going on.

Recently:
- Ben Collins-Sussman and Brian (Fitz) Fitzpatrick gave their “Myth of the Genius Programmer” talk as part of the Opening sessions at “Reflections / Projections”, the 15th ACM@UIUC Student Computing Conference at the University of Illinois Urbana-Champaign.

- They were joined by Googler and Python maintainer Alex Martelli, who spoke on “Python and the Programmer”.

- Chris DiBona, head of the Open Source Programs Office at Google gave a keynote at AstriCon in Glendale, Arizona.

Currently:
- Earlier this week Leslie Hawthorn, manager of the Google Summer of Code program, was part of the amazing team that completed a new “Manual on GSoC Mentoring” in 2, count them, 2 DAYS, finishing up late last night. You will hear more about this feat in a later post after the…

- Google Summer of Code Mentor Summit 2009, being held in Mountain View this weekend, October 24th and 25th. This invitation-only gathering of mentors from each of the participating mentoring organizations in this year’s GSoC gives the projects a chance to come together to compare notes on the mentoring process and cross-pollinate their projects. A good time promises to be had by all, and a full report will be forthcoming.

Coming up:
- Jonathan Blocksom will be speaking on Google App Engine and the All For Good project at the DC edition of Stack Overflow Dev Days, October 26th.

- On October 4th the LISA Conference in Baltimore, Maryland will feature a talk by Daniel Berlin and Joe Gregorio on the Google Wave Federation Protocol, the underlying open network protocol for sharing waves between wave providers. Interested attendees of LISA will be able to sign up for a developers Wave Sandbox Account. They will also have a chance to win Googley prizes at the Google Birds of a Feather session the next evening, hosted by Cat Allman and Tom Limoncelli.

By Cat Allman, Open Source Programs

Go to Source

Earlier this year, we blogged about project Eyes-Free — a collection of Android applications that enable efficient eyes-free interaction with your mobile phone. Since then, one of the questions we have received most often is about a complete access API to enable general purpose adaptive technologies such as screenreaders.

We are happy to announce the first version of such an API as part of the latest Android release (Donut). This new API is now available within the Android 1.6 SDK , and we welcome developer feedback. The Android Access framework generates android.view.accessibility.AccessibilityEvent in response to user interaction events; the event payload contains additional details about the event, e.g., the user interface control that received focus. This access framework enables the creation of general purpose screenreading applications that make all of Android’s user interface, as well as native Android applications built with standard Android widgets usable without looking at the screen.

You can see this API in use within our Open Source Android screenreader TalkBack. With TalkBack installed, standard Android user interface elements such as ListView produce spoken feedback during user interaction. Applications SoundBack (for producing non-spoken auditory feedback) and KickBack (for producing haptic feedback) generate additional augmentative output and demonstrate how multiple access applications can be active simultaneously.

What This Means For Developers

If you are interested in developing innovative access solutions on Android and have been eagerly waiting for our access APIs, the Donut SDK contains what you have been waiting for — including a set of free voices for English (US and UK), French, Italian, German and Spanish. You can use TalkBack, SoundBack and KickBack as a starting point for designing your own access innovations.

If you are an Android developer interested in making your applications more widely usable, you can use TalkBack and friends to quickly verify whether your applications remain usable when not looking at the screen. In this context, here are a few coding tips to ensure that your applications work out of the box with these tools:

1. Ensure that all visually drawn UI controls have meaningful textual labels.
2. Ensure that users can navigate to all controls in your application using the trackball.
3. Ensure that navigating controls in your application with the trackball results in a meaningful traversal order.

What This Means For End Users

End-users of Android 1.6 (Donut) can enable TalkBack, SoundBack and KickBack via the Accessibility section of the Settings menu. You need to do this only once i.e., once enabled, these access applications remain active across restarts. Note that depending on your Android device, you may need to install these applications from the Android Market; we will post videos that demonstrate step-by-step instructions for specific Android devices in the Eyes-Free channel on YouTube.

Providing Feedback

We (T. V. Raman, Charles L Chen, and Svetoslav Ganov) will be continuously improving the underlying APIs and access tools, and we look forward to your questions and feedback on the Android Developers Group.

By Charles Chen and Svetoslav Ganov, Software Engineering Team and T.V. Raman, Research Scientist

Go to Source

On Saturday, October 10, the Front Range Pythoneers had a Python “unconference” at the Google facilities in Boulder, Colorado, USA. An “Unconference” is a conference organized around the principles ofopen space technologies, which tries to provide many of the benefits of traditional conferences without the associated ceremony. We still got to enjoy some delicious pizza, though.

Introducing the Pycon Boulder Attendees to Principles of Open Space

Photo Credit: Matt Boersma

It was unseasonably snowy and cold Saturday morning, but in spite of the weather, almost everybody that signed up in advance was there, along with a few last-minute registrants. We had nearly 40 attendees join us for 15+ sessions, plus the always loved “hallway track.” Many thanks to the three Googlers who came out to shepherd our group and facilitate the meeting.

You can find more information about the event and sessions on our wiki, Tweets about the event and this great post-conference write up. You can also check out some more photos of the participants and our scheduling process. We discussed the following topics, among others:

• Intro to Python
• ctypes tips & tricks
• Python extensions
• matplotlib
• Web development frameworks, including Django
• Database access
• Concurrency & pre-emptive multithreading
• Event-based/actor development (e.g., Twisted & Kamaelia)
• Cooperative multithreading (stackless/greenlets)
• pyprocessing
• Game development with Pyglet/OpenGL
• Jython
• RPC using Twisted/Foolscap
• Desktop Application Development (PyQT/QT, wxWidgets, GTK)
• IPython
• Google’s office decoration contest, “Pimp My Cube”

The best surprise of the event? Bruce Eckel, the author of Thinking in Java, was among the participants. Thanks again to Google for hosting the unconference; it worked really well for our purposes. The Google Boulder facility is gorgeous.

By Greg Holling, Front Range Pythoneers

Go to Source

We’ve just released Stressful Application Test (or stressapptest), a hardware test used here at Google to test a large number of components in a machine. The test tries to maximize random traffic to memory from processor and disks with the intent of creating a realistic high load situation. The source code is available under the Apache license.

stressapptest may be used for various purposes:

• Stress test for machines.
• Hardware qualification and debugging.
• Memory interface test.
• Disk testing.

stressapptest is a user space test, primarily composed of threads doing memory copies and direct I/O disk read/write. Since many hardware issues reproduce infrequently, or only under corner cases, the idea behind the test is that by maximizing bus and memory traffic, the number of transactions is increased, and therefore the probability of failing a transaction is increased. It loads the memory with specially-designed patterns that cause the signal lines to rapidly switch between 1 and 0, drawing the maximum amount of power and cause maximal noise on the nearby voltage rails. Noise on voltage rails and coupling with other nearby lines is likely to cause signaling problems on marginal lines. Also, given a probability of any signal level transition failing, these patterns have the most memory transitions per period of time, and are thus more likely to exhibit a failure.

This test was designed to test all memory available on a machine, which is not guaranteed with the execution of a CPU-intensive application (for instance, compiling the kernel on multiple threads). Moreover, it is focused on testing the memory interface and connections, not the memory internally, like memtest86. As a consequence, Stressful Application Test will detect errors not detected by regular memory tests or extended executions. A comparison with some other memory reliability tests showed that about 20% of the DIMM-related failures detected on the machines tested were only detected by Stressful Application Test, and it was capable of reporting 70% of all DIMM errors detected by all tests.

We hope this software will be useful to system administrators who need to diagnose and repair DIMM or other components. We look forward to your questions and feedback in our discussion group. Happy hacking and may your testing be less stressful!

By Raphael Menderico, Software Engineering in Test Intern, Platforms Team

Go to Source

Can you spot the bug in the following piece of Java code?

(Hint: the method setNames() is synchronized on the names field, but that field is then modified to point to a new object.)

Thread Weaver is released as an open source project under the Apache license, and is available on Google Code. Many examples can be found in the initial documentation. If you have comments or questions, please see our discussion group. Happy testing!

Go to Source

We at the MoinMoin Wiki software development team had a wonderful time with our participation in Google Summer of Code™ 2009. We greatly enjoyed collaborating with our students, hacking Python and Javascript code for the wiki engine. Thanks to Google’s support, we had four student projects total, and three of them were successfully completed:

Christopher Denter, whom I mentored, worked on making MoinMoin’s modular storage code production-ready by adding an access control middleware. Christopher’s work in this area made MoinMoin safer and more flexible. He also worked on a router middleware – think of it as a kind of a wiki
“mount/fstab” – and a SQLAlchemy backend. Our users can now enjoy MoinMoin with MySQL, PostgreSQL, SQLite, etc. Christopher’s work was done directly in the repo that will become the 2.0 release of MoinMoin.

Alexandre Martani, mentored by Bastian Blank, worked on a realtime collaborative wiki editor based on Google’s mobwrite. Multiple people can now choose to edit the same wiki page at the same time and they all see each other’s changes shortly after typing. We hope that we can merge his code into the MoinMoin 2.0 repository soon.

Dmitrijs Milajevs, mentored by Reimar Bauer, worked on groups and dictionary code with modular backends. You can now fetch group definitions from wiki pages or a wiki, and preparations have been made to make an LDAP group backend possible as part of future development. Dmitrijs also refactored the search code to get rid of the unmaintained xapwrap library and use the new xappy library. All his work has already merged into the MoinMoin 1.9 main repo.

Thanks also to Alexander Schremmer for his contributions as a mentor. Unfortunately, his student’s project did not work out, but in true community fashion he provided valuable help and feedback for the other students.

In case you’re curious about when all this nice code will be released:

MoinMoin 1.9 will be released later in 2009 (likely in November). Please help us beta testing, translating and generally making the release ready.

MoinMoin 2.0 will not just 1.9 + 0.1, but a major rewrite of big parts of the code base. Right now, it’s like a big construction site, so it’ll naturally take some time until the release will be ready, likely 2010 or 2011. We’d be happy to have your help with it; if you enjoy coding in Python, playing with new features, cleanly refactoring code and working with a fun team, then do join us to make MoinMoin an even better wiki. Check out the MoinMoin 2.0 page for more details.

Many thanks to all the students and mentors as well as everyone in the community who helped or supported the process. It was a very productive summer and we are greatly looking forward to continued work with our new contributors!

By Thomas Waldmann, Google Summer of Code Mentor and Organization Administrator

Go to Source

Ed. Note: You may recall that last week we published the first installment of Emil Ivov’s report on SIP Communicator’s participation in Google Summer of Code™. This week, Emil shares more of the project’s 2009 success stories and lessons learned by the project over the past three instances of the program.

Geek Communicator

Linus Wallgren from Sweden completed a task that many of us have been dreaming about for a long time now: handling SIP Communicator entirely through the command line. So what exactly does this mean? Well, now, you can exit the application, hide or show it, send or receive messages, make or answer phone calls and open or close chats, entirely through the command line. So, you remember that super script that you always wanted to do? The one that sends a message to all your online friends at 3 o’clock every morning? You can now do it thanks to Linus! His work is going to be integrated into SIP Communicator some time this year so stay tuned!

Geek Communicator: Using SIP Communicator through the Console

Setting Your Own Avatar

Shashank Tyagi from India was accepted for the “Dude, checkout my photo!” project. His work consisted of making sure that it was possible for SIP Communicator users to upload a new photo/avatar with popular protocols like XMPP, MSN, Yahoo! Messenger, ICQ and AIM. He first started by exploring the mechanisms supported by the various protocol stacks that allowed this, discovering a few glitches on the way. He then worked on the glue that allows the SIP Communicator protocol modules to export this functionality to the rest of the application, and the GUI. Finally, with some help from his mentor, he also managed to wrap up a module that allowed users to take a picture of themselves using their webcam right before uploading it. Cool, isn’t it?

Shashank’s work is definitely going to get integrated into our trunk as soon as possible. However, until then you can either test it through his SVN branch or at least sneak a peek here:

Setting Your Own Avatar via SIP Communicator

DTMF with RTP

Romain Philibert from France worked with us on the project “DTMF with RTP” which had the goal of providing an alternative transport for DTMF tones in audio RTP streams in addition to the existing SIP INFO method. The first phase of the development consisted of research on the possible approaches to solving the problem and the viability of each of the approaches was explored with proof-of-concept implementations. The second phase was the actual implementation of the chosen solution and involved refactoring existing source code to generalize it enough to also serve the goal of the project, employing the rearchitected design for the sake of sending and receiving DTMF tones as part of audio RTP streams, writing new UI to allow switching between the alternative DTMF transports, and creating unit tests to assure the correct operation of the functionality. Romain was exposed to communicating on our development mailing list where he reported his progress throughout the program, gathered feedback from members of our community and helped another contributor in resolving a common problem related to the unit tests. The source code he produced has been reviewed and currently awaits for a major redesign of the media service of our project to be finished in order to be updated and integrated into trunk.

DTMF with RTP

Impressive list, right? We’re quite happy with it

So, let’s now get to the final part and look through the three most important lessons we’ve learned throughout the past three years.

Lesson 1: You’ve Got to Have the Time

Google Summer of Code is a two-way process. Really! You take a lot so you have to be prepared to give as much. This is not a subcontracting deal where you could simply expect work to get done by itself because it is being paid for (not that this ever happens in subcontracting, anyway). Having a dedicated mentor for a student’s project is almost as important as having a dedicated student. I’ve seen very few exceptions to this and it actually comes down to the following:

1. We are dealing with students who are still learning. As eager as they are to get things done, most of them have little development experience. Therefore if left to themselves, students would tend to over-engineer, go for a dirty hack, overlook existing documentation, misunderstand the goal of the project or a bunch of other things that seem so natural to experienced project developers.
2. Three months is hardly enough time even for experienced developers to fully grasp the internals of a mature project that they’ve never seen before. It is therefore naive to expect that a student would be able to come up with a usable and integratable contribution without a fair amount of guidance.

I am far from saying that you should be spoon feeding your student or do their work for them. To make things a bit more specific, I’d say that according to our experience a mentor should be ready to spend an average of about 45-60 minutes per day working with their student. Time is rarely equally spread across the summer. Our mentors would often find themselves spending up to two or three hours a day in the beginning of the program while 15 minute chats would be enough to resolve issues toward the end of the term.

Lesson 2: Less is More

I know, I know … what a cliché! Still, it took us some time to actually realize it so I think it’s important to note this lesson. I already mentioned that in 2008 we took 15 students and that this was not our best year. Mentoring resources were of course part of the issue. We had 4 of our most active developers take up two students each. First, this proved to be quite hard for the mentors themselves. Dedicating two hours a day to mentoring may turn out to be an issue when this is not part of your day job. Second, it was also a problem for the other students and their mentors. Given that our most active mentors had their hands full with their own students, they had little time to spare giving advice to other mentor-student pairs when they needed it. This turned out to be a blocking factor on more than one occasion and there was no one happy with the situation.

In addition to mentoring resources, a higher number of students are also hard to handle by the community itself. This means that people would be less aware of the progress of every project, there would be hence less interest, less encouragement, less acknowledgment and community integration for the students.

At the end of the day, we did manage to handle things and we only had a single failed project in 2008. However, the experience was far from the pleasing memories we had from 2007. It was therefore a good lesson to learn because taking less students was one of the main reasons for a successful 2009.

Lesson 3: One Committer per Student

I believe the one-mentor-for-one-student ratio is now commonly accepted practice for Google Summer of Code and that most projects are striving for it. We definitely have done our best to avoid mentor sharing since 2008. Having more than one (non-shared) mentor per student is even better but unfortunately not always possible. Another ratio that is just as important, and probably not that popular, is the number of committers involved as mentors. Code integration represents a significant part of the effort that projects spend over Google Summer of Code. It is quite obvious that if the developer committing the work of a particular student is also their mentor, integration is going to be a lot easier than if it were someone else.

For example, we had some very valuable stuff written during 2008, like support for proxies from Atul Aggarwal. Atul did a good job, but, his only mentor, despite being very technically savvy and knowing the project quite well, did not have committer access. Proxy support is quite important for SIP Communicator, although not necessarily critical. Committing Atul’s work however, would require an existing committer to study all his work, and there always seems to be something in the critical path for development that must be reviewed. Things would have been a lot easier if one of the people that were expert in this field had been following the project right from the start.

We therefore decided to add pair each student with a committer in 2009, and each committer only had to take care of one student. The results were excellent, and as I already mentioned, we already have approx 30% of the GSoC code committed barely a week after the end of the program!

Lesson 4: Specific Tasks and Clear Conditions (Learning in Progress …)

Ok … this case is not really that straightforward and we have more learning to do before we really get it. Here’s the problem:

In 2007 and 2008, we had a couple of students who would get to 50% or 60% of their work and then get distracted with unimportant stuff or simply disappear for a while. At a point their mentors would remind them that they have more to do and this would cause the students to feel uneasy, panic, or start arguing about things, such as:

“Oh, I didn’t know I had to do unit testing!” or “I was never told this feature was part of the job!”

The statements weren’t completely false. It could indeed happen that a task would seem obvious to a mentor and in the same time feel utterly unnatural to a student. In one case, it was actually the mentor who didn’t request a task that was considered important by other community members.

So either way, in order to try and limit the surprises we decided that we needed to start every project with a list of clearly defined sub-tasks. This way, we thought, students would know exactly what they need to do and organize better. It would also help make sure that everyone on our side was well aware of the “official” project vision. Sounds neat, right?

Well, it didn’t really work out that way.. Most of the students didn’t have a problem with the new system, but then again, most of the students didn’t have problems without it either. One of the students we failed, however, claimed the requirements list had been misleading and had made them believe they could plan a few weeks off. When we told them that this would be risky they complained it was too late to cancel the reservations, so they didn’t listen … and eventually failed.

So it appears that a list of what we believe to be specific requirements doesn’t seem to change much in terms of understanding the goals of a particular project since there’s always something that could be misunderstood. Clearly, continued mentor-student communication is crucial here but it seems that we’d also need explicit there-may-be-more-to-this-than-you-think notes.

Phew, that sums it all up! Hope the lessons we’ve learned above would help others in similar situations. Good luck to all of you future Google Summer of Coders!

Go to Source