Geek Time with Josh Bloch

In addition to being known as “The Mother of Java,” Josh Bloch is also the Chief Java Architect at Google. Josh sat down with fellow Open Source Programs Office colleague Jeremy Allison to chat about APIs, the importance of openness, and the successes and failures of Java.

Some highlights from their conversation:

(0:45) Josh describes what he does for Java and at Google.

(1:59) Jeremy expresses his disappointments with Java, based on the early potential that it showed. Josh responds with an explanation of some of the difficulties that Java faced.

(4:48) Josh and Jeremy talk about some of the factors that contributed to Java’s successes.

(9:51) Josh’s explains his philosophy towards creating APIs.

(14:30) Josh talks about the APIs that he’s most proud of.

(19:45) Josh and Jeremy discuss the importance of reading other people’s code, and the impact of Sun’s decision to put the code and bug database for Java on the web.

(24:00) Josh explains how he came to be in his current position and gives advice for others who are looking for ways to get started programming.

(27:32) Josh wrote the standard Java best-practices guide, Effective Java, and co-authored two other Java books: Java Puzzlers, and Java Concurrency in Practice. As a special treat for this blog’s readers, Josh is offering signed copies of his books for the first two people with correct responses to the following puzzle. Submit your answer as a comment on this post, then use the same Blogger ID to leave a separate comment with your contact info and inscription request (for your privacy, the comment with your contact info will not be published).

Josh’s Puzzle: “The Story of O”

The following Java program is not quite complete; it’s missing a parameter declaration for o. Can you provide a declaration that makes the program print “O noes!”? (The program must compile without generating any warnings.)

public class Story {
   public static void main(String[] args) {
       Object o = null;
       story(o);
   }

   private static void story(<you provide the declaration> o) {
       if (o != null)
           System.out.println("O noes!");
   }
}

Remember to leave your answer and contact info as two separate comments!

By Ellen Ko, Open Source Team

Introducing CityHash

We’re pleased to announce the new CityHash family of hash functions for strings. We’re releasing two functions today: CityHash64 and CityHash128. They hash strings to 64- and 128-bit hash codes, respectively. These functions aren’t suitable for cryptography, but our experience so far shows that they’re great for, say, hash tables.

We tried to optimize for CPUs that are common in Google’s datacenters, but it turns out that most PCs and laptops have the relevant features as well. The important ones are 64-bit registers, instruction-level parallelism, and fast unaligned memory accesses.

We were greatly inspired by previous work on hashing, especially Austin Appleby’s MurmurHash. The key advantage of our approach is that most steps contain at least two independent mathematical operations. Modern CPUs tend to perform best with this type of code.

The disadvantage of our approach is that the code is more complicated than most popular alternatives. We decided to optimize for speed rather than simplicity and even included special cases for short inputs.

Overall, we believe that CityHash64 and CityHash128 are exciting new ways to solve a classic problem. Under real-life conditions we expect CityHash64 to outperform previous work by at least 30% in speed, and perhaps as much as a factor of two. Also, as far as we know, these functions’ statistical properties are sound. Please don’t hesitate to try this fast new code!

By Geoff Pike and Jyrki Alakuijala, Software Engineering Team

Final hours to submit your Google Summer of Code student applications!

The student application period for the 2011 Google Summer of Code is almost over. All applications must be submitted into the Google Summer of Code site by Friday, April 8th at 19:00 UTC to be considered for this year's program. Don't wait until the last minute!

By Stephanie Taylor, Open Source Team

Linux Foundation Collaboration Summit 2011

This week marks the fifth annual Linux Foundation Collaboration Summit, which will be held from April 6th to 8th in San Francisco, CA. Many Googlers will be attending, and several Googlers are presenting at the Summit as well.

Andrew Morton will be in a panel discussion on The Linux Kernel: What's Next at 11 AM on Wednesday April 6th.

Michael Rubin, Technical Lead for Google's Kernel Storage team will be presenting a keynote on File systems in the Cloud at 3:30 on Wednesday.

Ian Lance Taylor will be discussing the Go Programming Language at 2:15 on Thursday the 7th as part of the Tools track.

Later on Thursday, Jeremy Allison of the Open Source Programs Office will explain Why Samba Switched to GPLv3 at 4 PM.

Although the event is invitation only, live video streaming is available for free, so everyone can watch the keynotes and panel discussions. Tune in to the video stream, or if you’ll be attending, introduce yourself after any of the talks!

By Ellen Ko, Open Source Team

The DOs and DON’Ts of Google Summer of Code: Organization Administrator Edition

This is the second in a series of three posts on DOs and DON’Ts for Google Summer of Code students, mentors, and organization administrators. The first post dealt with students while this post features mentoring organization administrators. Organization administrators (org admins) oversee the overall progress of a mentoring organization and its students throughout the program. Based on our experience with Google Summer of Code, we’d like to share these tips and antipatterns with you to raise awareness and help other org admins avoid the same mistakes we’ve made. For even more advice, check out the mentor/admin guide.

DO	DON’T
Track the timeline and projects closely. Most mentors and students need a helping hand, and you can only provide this if you’re aware of the deadlines yourself. Be sure both mentors and students are aware of their next steps. Also, keep track of the progress of each project, perhaps with a spreadsheet filled in by the mentors—this gives you time to deal with major problems before midterms/finals, when little choice exists besides failing the student.	Fail to follow up on mentors and students. It is easy to lose your perspective of deadlines and progress. If you don’t stay on top of them and make sure they are aware of their responsibilities it can result in unnecessary failure of students or embarrassment for your organization.
Start small. Everyone gets the most out of Google Summer of Code when the orgs are on top of everything and everyone knows what’s going on. You can achieve this most easily with only a small number of mentors and students. Successful orgs tend to be invited back, so plan for success; there is time to grow later. It’s much better to have a few overwhelming successes than many borderline cases and failures.	Take on too many students. Most new organizations try to get as many slots as they can. This is, however, rarely a good idea. They greatly underestimate the resources needed to mentor a group of students in a program like Google Summer of Code. Taking on too many students almost always leads to a poor project outcome and integration of the students in the community and thus low retention rates.
Ensure you can support the number of students you request. The requirements for project voting and ordering become much more severe as the number of students, mentors and projects increases; it’s nowhere near a linear scale. After coding starts, you still need to track projects to make sure your overall program is running well. Avoid methods that rely on significant time commitment from you, and instead distribute the effort to mentors and students.	Grow too quickly. Once you’ve succeeded with a couple of students, it can be tempting to think you’ve figured everything out. But things that work great on a small scale can fail wretchedly when scaled up. For example, asking every mentor to read every proposal might work fine when there are only 10 proposals, but it doesn’t function nearly as well when there are 100.
Plan for communication throughout Google Summer of Code. There are times throughout the program when you need to let the mentors and/or students know about certain things, like deadlines. Plan for this from the start of the program by, for example, subscribing everyone to a dedicated mailing list. Make it clear from the start that mentors and students can approach you to discuss nontechnical problems, so they know they can rely on you as a resource. Overall, you need to be visible and keep people motivated throughout the process—and follow up with students afterwards to encourage them to become long-term contributors.	Forget to keep clear lines of communication with the mentors and students. Discovering you need to get in touch with a student or mentor and finding you can’t reach them is trouble in the making. If you don’t have backup contact details for mentors, it’s easy for them to disappear—particularly if your primary method is an online chat like IRC or XMPP.
Work out your responsibilities in advance. If you’re a new org, it may not be obvious what you need to do to support the mentors and the students. Make sure both you and your mentors have the same idea about your role. Particular things could be: If your organization has IRC meetings, you need to make sure they run smoothly. If your organization requires blog posts, or mailing list updates, you have to make sure these happen. Once the program starts your enthusiasm needs to continue because it feeds mentors and the students. To maintain your excitement, think about the benefits your organization receives at the end of the program for every successful project: new code and new contributors!	Be enthusiastic in the application stage but stop when the projects start. It’s relatively easy to keep enthusiasm high when it’s early in the process as your tasks are obvious (apply for Google Summer of Code, get the ideas page sorted, get the mentors lined up, set up mailing lists, etc.). If mentors or students sense you are distracted or no longer dedicated to your role as organization administrator, their enthusiasm for the project will likely decrease. You are the glue that holds everything together and everyone will look to you to keep things moving forward.
Coordinate mentors early to get a high-quality ideas list. At the meetings for rejected orgs, the most common theme by far is “you can improve your ideas page.” Look at other orgs’ ideas pages for this year and for last year, as well as the mentoring guide. New organizations often ask whether their ideas are too long, but they usually aren’t; clarity and detail are highly desirable. To maximize student interest in your organization, you should have an ideas page well in advance of the deadline for org applications. Also be sure to give the students what they need to get excited about the projects and contact you; provide enough context to convince them why this idea matters. If there are specs for the projects, link to them and be sure to provide contact details for each idea. Handling student interest in the run-up to applications can be very time-consuming, plan accordingly.	Construct your ideas page at the last minute. Students look at the ideas pages long before orgs are selected; they’ll pass your organization by if you don’t have ideas ready when they first start researching the orgs. Failure to prepare early has particularly large consequences for umbrella orgs, where there is a logical disconnect between several developer communities, but it also holds true for individual projects. To avoid “writer’s block,” you can start with a high-level idea of what types of projects your org wants to sponsor and work from there.
Arrange infrastructure in advance. Most projects will require some infrastructure to be in place for students to work effectively—whether it’s a committer account, repository creation, students knowing where they should post their code, or simply getting them subscribed to relevant mailing lists and taught the proper protocols. Everything should be in place for students to make their first commits as a true member of your organization’s community on the initial day of coding. There’s also a brand-new mailing list for supporting new org admins called gsoc-veterans that you can turn to for advice (new organizations will be invited soon).	Block projects from starting on day one of the coding period. If technical difficulties prevent students from being productive when coding should have started, it instantly lowers the scope of what they can accomplish during the summer and may prevent them from finishing their projects. For example, if they don’t know how to use your version-control system or don’t have commit access, they’ll be mired in tangential problems instead of coding.

Making Google Summer of Code the best possible program requires a commitment to excellence and preparation from participants at every level. In this post we’ve provided suggestions for org admins, and in the last post in this series we’ll cover mentors. Whatever role you would like to play in Google Summer of Code or a similar program, read everything you can find so you know what you’re getting into. Good luck, and have fun this summer!

By Donnie Berkholz, Lydia Pintscher, and Kevin Smith, Google Summer of Code Administrators for Gentoo & X.Org, KDE, and XMPP Standards Foundation, respectively