Indexing removable media with Google Desktop

A bit over a year ago I took over maintainership of two open source software packages, which I have been using for a few years before:

• Spindle Search. It integrates with Google Desktop to provide indexing and search over removable media: you type a (part of) file name and it says which of your DVD-Rs (or USB keys etc.) the file sits on. Very useful once you have burnt 10+ DVD-R with large file collections on them.
• .NET Wrappers for Google Desktop. It is a supporting library for Spindle Search providing a mappings from Google Desktop API, exposed through COM, to .NET.

Today I have made new releases of both these packages.

Thanks to Manas Tungare, original maintainer of both Spindle Search and Wrappers, for creating them in the first place and trusting me to continue to maintain them, and to beta testers of Spindle Search who have been very, very helpful!

Summer of Code: Conclusion

(Summer comes)

Originally I have planned to write a "things not to do" post, but now I've dropped the idea. Positive advice is better than negative one, and people that do those things are not going to read it anyway.

So let's conclude Summer of Code posts. If I had to sum up everything with one word, it'd be "communicate."

This blog is going to take a break, until I get a new idea what to blog about. That might be my Ph.D. topic – efficient spatial indexing. Or something else.

Good luck with your applications!

Summer of Code: Summer comes

(CV and qualifications in the application)

So the application is completed and submitted and, a few weeks later, the acceptance notification day comes. Then one of two things happens: either your application was rejected, either it was accepted.

It it was rejected, do not let these news sadden you too much. The positive thing you are carrying away from all this effort is the practice in writing technical project applications. This is a very useful skill and makes you much better prepared for the next such contest.

If it was accepted, congratulations; now get busy with the project! Some advice for the summer:

• So this is your full-time job now, just with very flexible hours. See [4] for an example of time commitment requirement.
• Communicate with your project. Hard to overstate, hard, although possible, to overdo. In particular, do not write to mentor only when it's more appropriate to write to the mailing list – most of the technical questions should go there.
• Communicate with your mentor, especially if something went wrong or you have doubts about the project:
• If you feel that project scope is too big.
• If you think that the project deliverables need to be adjusted.
• If you experience some strange difficulties involving the organization, for example, if getting source code repository access takes ages.
• If you feel that discussions with other project developers are unproductive in some, maybe even bad, way.
• Don't be afraid to do so. Remember that your mentor wants you to succeed and will do what he can to help you.
• Check-in code often to your branch. It's much better to post small incremental patches than to work silently for two months and then de-lurk with one big code change. In addition to the usual source code version control advantages, the organization will see your progress and you will get feedback earlier - when you actually can act on it.
• Do not expect to follow your project plan to the letter. It is almost guaranteed that things will change. When you see it coming, discuss the necessary change with your mentor and make it. Repeat as needed. Do not stick to the original plan just for plan's sake.
  

That's almost it! Conclusion next.

Summer of Code: CV and qualifications in your application

(Writing the application)

An important part of the application is the one where you talk about yourself instead of your proposal. Here your goal is to show that you are actually able to do what you promise to do.

• If you do not have previous experience with the project codebase, suggesting that you will "work really hard" or that the feature "will be totally awesome!" might not cut it [1]. In such case playing with the code (see above) is important.
• In similar spirit, "I use this application every day!" is not enough, especially if the application in question is a very popular one, (e.g. Firefox) [1]. There is nothing wrong with stating that, but make sure that this is not your only qualification.
• Good personal references/recommendations help.
• Previous projects help, especially in the related area.
• Do not copy paste your CV from some other application if you fail to tailor it for the one you are applying for [1].
  
• Be prepared to back your experience claims in CV with specific examples and descriptions, for example, of the projects done.
  
• Needless to say, lying and padding is bad.

Yet your effort to write the application is ultimately more important than your CV. If you have limited time and have to choose between gathering personal references and spending time on a technical part of the application, choose the latter.

Next: summer comes.

SoC GCC podcast

When Leslie Hawthorn learned that I'm doing internship at Google, she made me and Ian Lance Taylor record a podcast about Summer of Code and GCC. Daniel Berlin, my mentor from the last summer, was also invited, but managed to escape.

The result is here.

Thanks to Leslie and Ian! And Danny too :) The SoC posts will resume now.

Summer of Code: Writing an Application

(Introduction and table of contents)

By now the preparations are done and it's time to write. Here is a list of assorted writing tips, in no particular order.

• Copying project description from proposed project list does not cut it.
• Choose a short but descriptive title, that will create enough interest to read the whole proposal.
• Whatever the idea, make sure to state it briefly and clearly (surprisingly, some people fail to do so [1]).
• List deliverables clearly and specifically, both optional and required, and designate them as such.
• Read dev docs, code, play with the code, try to actually implement something in order to help fill in technical details of your application.
• Some projects might require you to provide a specific schedule, even though you might have only a vague idea here (But how do you know that your project is going to take three months then?). Playing (see above) with the code should help there, and don't be afraid to change timeline later as needed. Make sure to communicate that!
  
• Do not leave template text in [1]. If you want to give credit to template author, do it clearly in your own words.
• Use the provided form for application as much as possible. Do not just include a link to external web page here. If 7500 symbols are not enough, shorten [1].
• Include brief references to support your claims - links to e-mail archives, specific chapters in the development documentation, etc.
  
• Should be obvious, but check your spelling and grammar.
  

The part of application that outlines your qualifications, including CV, deserves separate treatment. That's coming next.

Summer of Code: Planning to write an application

(Introduction and table of contents)

So, by now you have a rough idea what your project proposal will be about. Here are a few things to consider before you start writing. First, expect to commit significant time for it (I spent about a week full-time) and it's best to start early. Starting writing early means more iterations, more feedback that is more thorough – it's all good for you.

Does that seem like a lot of work? That's the whole point – in summer you are going to have even more work, after all [5]. Also that means that you should go for quality, not quantity: do not try to write three or more applications that are actually good. It might be possible, but it's very hard to pull off.

Before you start actual writing, it is helpful to look at previous accepted applications. Search for them with Google, or follow the links from [7].

Also it'd be very helpful if you arranged with somebody to review your application once it's written. Usual ways to seek help here involve talking to staff at your faculty, in the case they know you and have time to spare, or at any NGOs you are affiliated with or have friends at – usually they are very good at this sort of thing. The reviewers do not have to be familiar with your project area, and it even might be better if they weren't - an outsider's perspective can be very valuable.

Next: writing tips.

Summer of Code: Choosing an interesting project idea

(Introduction and table of contents)

First of all you have to choose an organization you want to work to with. I don't have much to say here. I guess you just have to go to the list of organizations and pick the one you like the most.

After that you have to choose a project idea to work on. For that, it's best to start early: you will have to do a lot of iterative communication, and the more iterations you will complete, the better your application will be.

Now what to look for in idea itself? First and foremost, ambitious ideas are good, especially if they are not in the proposed project list. Tell it to the project and it may even end up on that list [3]. That's a strong case for your application, and you haven't even started writing it yet. Second, original ideas, outside the current "hot" thing, show that you are an independent thinker. Furthermore, your idea should be not merely "nice", but something that the project genuinely needs.

At the same it's a good idea to start reading development docs and some code for the project. This will help to see if the idea is feasible - especially if it's not in the list of the suggested projects - and to get general feel about the project. Even more important is to contact project developers: ask for feedback for your project idea, find yourself a mentor, file a bug, submit a simple patch - get involved!

Finally, learn about organization specific things: see if there are particular requirements for applications in you organization. And do not be afraid to ask how one or another option would be evaluated and which route you should pursue. Organization might have a sound reason to prefer one perfectly good approach over another perfectly good one, so don't get burned just because both approaches seemed good to you.

Next: planning to write the application.

Summer of Code: The Big Picture

(Introduction and table of contents)

The idea of Summer of Code is simple. Students choose open source projects they would like to work on and write applications, the open source projects evaluate those applications, the selected students spend their summer working on what they wanted to and Google pays everybody. Everybody wins. The students get experience with application writing and open source development, attention and help with their projects, potentially useful contacts for the future and some money. Organizations get new developers - their lifeblood - and some money. Google gets opportunity to help FOSS developement (FOSS is used a lot in Google), positive publicity and some (very little) recruiting done for themselves.

Note that in the long list of the benefits for students (that means you), money is just one thing, even if it is the first thing you hear about in relation to the program. And in the long run, it's probably the least important benefit. Think of it as a necessary means for Google to win your time away from other potential summer employers. That's it. The really important benefits you get are the skills and contacts, these will serve you well into the future. Funnily, mentioning in your application that you are doing this just for money will surely fail it. And no, I'm not suggesting lying about it – if you do, your application will show it in thousand other ways, with the exactly the same end result. But more on application writing later.

What's more? If you ever wanted to join an OSS project but it seemed daunting and complicated, here is your chance, with added bonus that the project developers will be extra-nice to you. If you have never participated in a successful team OSS project, or any team software project for that matter, this will be a very interesting and useful experience. There is a major difference between coding an application alone and doing a project in a team. So you are going to learn a lot of exciting stuff about having to deal with other developers, how and when to communicate with them, what kind of support infrastructure every project needs and many other things. Again, what you learn is for lifetime.

This concludes the big-picture benefits of SoC for you. The other big-picture thing which you have to be aware of is the time planning. If you are accepted to SoC, do not plan any other full-time commitment for the summer. The project will expect you to commit about full-time worth of effort. This is a perfectly reasonable requirement, since three months of single developer time is not much in the software world. You will need all of this time to create something substantial. But don't get upset – the "working hours" are extremely flexible and you will be able to plan some time for holidays as well.

Next: on choosing an interesting project idea.

SoC Experience: Introduction

Hello world again. Just almost a year behind the schedule, this is the first post in series offering some advice for SoC participants, that, very hopefully, will be at least a bit useful to somebody.

SoC has changed my life, in a sense. In summer 2006, I applied to work on the GCC with this project. I was accepted and successfully completed my project, although at a significantly reduced scope. Then I got to travel a little bit, to see how Google is doing in London. And a year later, this has helped me to land an internship position half a world away at Google. And my work here involves continuing my old SoC project. What more could I ask for right now?

That's why I want to share some of the things I learned. While searching for advice a year ago, I have found many excellent resources on how to write an application (all of them linked to below), yet there are some things which I want to emphasize more. Most important of them is the need to communicate early and often – in general communication, soft skills, etc. is something that us engineers tend to dismiss and this is a big mistake.

So I am writing down advice based on my personal experience, with added advice from other sources that I can relate to. Of course, it is very subjective and in no way I can guarantee that it is correct and true in all (or any) situations. Also, parts of it will seem like a very common sense. That's because it is. But common sense tends to be forgotten or vary person to person, so I feel I should include "very obvious“ stuff as well.

Here is the table of contents for easier navigation. I will convert it to links as I add new material.

1. Introduction (this post)
2. Summer of Code: the big picture
   
3. Choosing an interesting project idea
4. Planning to write an application
5. Writing tips
6. CV and qualifications
7. Summer comes
8. Conclusion

Finally, if nothing else is useful, then at least this part will definitely be. This is a list of links to other SoC participation advice, written by much smarter people than me, with SoC mentors among them, whose advice matters much more directly than mine.

1. http://weblogs.mozillazine.org/gerv/archives/2006/05/how_not_to_apply_for_summer_of.html
2. http://groups.google.com/group/google-summer-of-code-discuss/browse_thread/thread/4cccd94e0b9aefc9
3. http://alex.dojotoolkit.org/?p=604
4. http://summer.cs.pdx.edu/propose
5. http://shlang.com/writing/soc2005.html
6. http://venge.net/mtn-wiki/SummerOfCode2006
7. http://drupal.org/node/59037
8. http://code.google.com/p/google-summer-of-code/wiki/AdviceforStudents
9. http://www.postgresql.org/developer/summerofcodeadvice.html
10. http://shlang.com/writing/soc2005.html

Good luck!
Next: The big picture of SoC

Google London Office Visit

I was quite excited to hear about opportunity to visit a Google engineering office to meet fellow students and Googlers[*]. Thus immediately I started thinking which office I would like to visit. Trondheim seemed (and still seems) like a very nice destination. It is relatively close to my current home (Currently I study in Denmark, Aalborg). I like the beautiful Norwegian scenery and the fact that Google there is doing research projects which might be actually related to my own university project. But the travel costs turned out to be prohibitively high. So, London. A big engineering office, lots of fellow students participating, and Chris DiBona himself coming here. I bought tickets without giving a second thought.

I flew there a day before Google event. I've never been before in London, so the city overwhelmed me. Sadly, I had only half of day on Thursday to actually explore it. Hopefully soon I will return here to spend at least a week.

On Friday it was time for the Google visit. The provided directions were very clear and I found myself in the front of a big office building near Victoria Station. Must be pretty expensive to rent. Although I came some 10 minutes early, most of the students were already there. Couple of things attracted our attention in the reception: there is a live running Google search log projected on one wall and on another Google Earth was zooming in and out of famous landmarks. Sadly, they have a "no-photo" policy which I was unlucky enough to familiarize with by trying.

At 12:00 came Zaheda Bhorat, took us to the conference room where we had some small talk and free food. Exactly what a travelling student needs! Then Chris joined us and we had a round of introductions, followed by round of lightning presentations by students. There were two major types of talks. First, there were talks that discussed technical side of the project, architecture and implementation details. On the other hand there were talks which discussed organizational, communicational aspects, gained experiences and just briefly skimmed over the technical side of the projects. Yet they all had one thing in common - that the presenters were passionate about their projects and were happy to do what they did.

Next we had a round table discussion on variety of topics. First of all, how could Summer of Code be improved. This year was the second year for this program, so a lot of things were already sorted out, but on the other hand the program is still relatively young. The outcome of the discussion is here. During the general discussion I was able to finally get answer to the question - why Google created this program in the first place? If Google wants some of the open source projects have more manpower, then why not just directly hire experienced developers? On the other hand, if Google wants to hire new hackers, then, to quote Chris, there are more effective ways to spend 3 million US dollars. And the correct answer is that one of the Google founders wanted to give CS students opportunity to earn some cash during summer in a way that does not involve flipping burgers. Moreover, it is useful for both the student and community. Fair enough. Of course, some recruitment does happen as a side effect of the program.

Later we were joined by a local Googler which answered questions about what is it like to work for Google. It goes without saying that you get to work on truly world-class projects and they try to create environment so you do not want go home. And we could see afterwards if the latter is true, as we had an office tour. No expense is spared and attention to the detail and wishes of employees is everywhere. A big rest lounge with armchairs, big soft toys to rest on, a mic and loudspeakers - I sincerely hope that they have banned singing for people who can't. A couple of small bars stocked with fruits and soft drinks. A balcony where you can have BBQ in summer. A fridge of beer and all major gaming consoles. A canteen where all menus are so elaborately marked, so that if you are vegan on Tuesdays and do not eat salad on Thursdays, you can immediately find what's here for you today. A pool table which says "Bilijardai" on its side in Lithuanian - this one I liked the most. Virtually all walls are covered with whiteboards, I guess they rarely run out of space to discuss their ideas for world domination. However, the developers do not have offices with a door that closes, so there is still some room for improvement.

After the office tour we were given gifts: sets of T-shirt, notepad, mouse pad, pen etc. But the best thing in there was this magnetic constructor toy.

Then it was time to thank the hosts and part. Some of the students, me included, decided to go out try some English beer in the pubs. Which we did, and had a lot of fun. Later somebody got a poster inviting to a "Greater London Linux User Group emergency pub meeting with Jon 'maddog' Hall" at the same day. Emergency is an emergency, so we didn't think for long about it. More beer was consumed and many new interesting people were met. At around midnight I left, because I didn't want to miss my flight early next morning.

To conclude everything, the visit did not exceed my expectations - but only because they were very high in the first place. I was amazed at how enthusiastic the students were about their projects, how much effort was put into running the SoC program by Googlers and how nicely they had arranged our visit. Keep up the good work!

Here are a few pictures of mine of the whole evening. And more photos from the GLLUG meeting are there. UPDATE: couple of new photos: maddog at GLLUG meeting by Uros Trebec and us at Google by Zaheda.

[*] - Dammit, it sounds like a sentence from some corporate blog written by marketing.

Introduction

Hello, world. This blog is going to be a place where I will document my Summer of Code participation experiences. The main reason is that I want to have a list of things to consider next time I write an application and because, hopefully, that might be useful for somebody else too.

First of all I plan to write a report about Google London office visit for GSoCers. Then I will write down things, tips, advice, good examples, bad examples I've seen and learned during application submitting process and during the course of project. And later, well, I don't have any further plans, so don't expect frequent (or any) updates afterwards. I think that it is much better to have good, even if old and little, content, than to write updates regularly.

For a year already I have a blog in Lithuanian, so if you're fluent in this language, want to learn some Danish and are interested in incoherent ramblings about day-to-day student's life in Denmark, please head straight over there.

Last but not least, since I'm not a native English speaker, all corrections of style, grammar and so on, are very welcome by those who know better.