Inspirated

The Program

And with the final code submission uploaded at Google Code, Summer of Code 2010 officially draws to a close. What a ride it has been!

My first post on Inspirated regarding Summer of Code took place all the way back in March 07 when I submitted a proposal for Fedora. Three and a half years later, I finally appreciate the fact that GSoC is about much more than just the code. In fact, “Summer of Open-Source” would probably be a more suitable title for the program despite sounding half as sexy. When my proposals got rejected I had to learn, contribute and integrate more with the open-source crowd. When one of the applications finally made it beyond the selection process, I had to “bond” with the organization I was going to be working with. During the coding weeks, I had to communicate regularly with my mentor and Ubuntu community in order to ensure that I was progressing in the right direction. To summarize, becoming a part of the open-source universe is as important an aspect of GSoC as producing open-source code.

The Code

Here’s a quick rundown of the code produced for the program (without including the intermediate branches and patches):

Attachment Search

• Merge Revision: Expot API call for listing the source packages a team has subscribed to.
• Branch: Search attachment files using Horspool’s algorithm. The branch eventually didn’t make it upstream as it was decided that with the existing implementation the searches would be too expensive for Launchpad, essentially requiring a solution with a different design approach.

Arsenal and python-launchpadlib-toolkit Modifications

• Package, Package, Package: These libraries had to be modified extensively in order to provide support for the Arsenal scripts developed during GSoC. Classes like LaunchpadApplication, LaunchpadBugzillaApplication and BugzillaAdapter perform regular chores for these applications e.g., authentication, web-scraping and keyring manipulation.

Attachment Upstreamer

• Script: Command-line script for upstreaming attachments from a Launchpad bug to a remote Bugzilla.
• Script, Template: CGI script for demonstrating the capabilities of Arsenal library and python-launchpadlib-toolkit.

Bug Matchmaker

“Incompatibility: In matrimony, a similarity of tastes, particularly the taste for domination.” — Ambrose Bierce

Fortunately, matchmaking across different bug trackers was easier.

• Script: Command-line script for searching a remote Bugzilla for similar entries to a given Launchpad bug.

Automatic Patcher

• Script: Command-line script for automatically generating patched Debian packages for a given Launchpad bug using diff files found in its attachments.

The Nutshell

The processes of collaborating, getting code reviewed and improving accordingly has gone a long way in instilling more confidence in me as a FLOSS developer. On the technological side of things I’ve had to deal with REST APIs, Zope Interfaces, OAuth procedures, web-scrapers based on Curl, Debian patch systems, a plethora of Python and a good-bit doze of different development paradigms.

It has been awesome working with the Ubuntu community and Bryce’s guidance has been absolutely crucial for ensuring that something useful was produced by my project. I’d like to thank everyone involved in the program for making it so much fun. I Know What I Did This Summer.

Tags: AJAX, API, Arsenal, Bugzilla, Code, Curl, Debian, GSoC, Launchpad, Open Source, Python, REST, Ubuntu, XML-RPC

As eleven weeks of the-best-summer-ever draw to an end, here’s the final coding report for GSoC 2010.

Related Links

Summer of Code Archive	Inspirated Code
Report Guidelines	Ubuntu Wiki
Original Proposal	Ubuntu Wiki

Time Spent

60 hours.

Highlights

The week was spent mostly cleaning and packaging the code accumulated over the summer. To demonstrate some of the aspects of the Arsenal library, I also created a proof-of-concept CGI script which upstreams Launchpad attachments for a bug to a remote Bugzilla. The task was fun, as the efforts put into refactoring things into launchpadlib-toolkit and BugzillaAdapter finally paid off and it took only a few hours to get the script working (that too with most of the time spent learning AJAX).

Concerns

None.

Waiting Items

None.

Stalled Items

None.

Accomplishments

• Branch, Merge Revision:
  • Revision: Added support for quilt.
  • Revision: Added support for using patch utility for quilt packages where the diff files update debian/* stuff themselves.
  • Revision: Cleaned up the library to provide LaunchpadApplication and LaunchpadBugzillaApplication.
  • Revision: Fixed BugPatcher to use LaunchpadApplication as base class.
  • Revision: Cleaned up LaunchpadBugzillaApplication to take username password as arguments instead of modifiers.
• Branch, Merge Revision: Fixed packaging issues to release debs for Karmic and Lucid.
• Branch: Implemented a CGI script demonstrating the upstreaming capabilities of Arsenal library. An example run can be seen in this screencast.

Minor Tasks

• Revision: Some more code cleanup.
• Revision: Check launchpadlib version before appending ‘/beta‘ during API URL detection.

Actions for the Following Report

• Fill the final evaluation.
• Write a summary of the overall GSoC experience.
• Start waiting for the t-shirt.

Tags: AJAX, API, Arsenal, Bugzilla, Code, Curl, Debian, GSoC, Launchpad, Open Source, Python, REST, Ubuntu, XML-RPC

Here are the facts:

• Facebook introduced a complete makeover of its website design some seven weeks ago. The new design relies heavily on AJAX. Which is the technology that makes webpages “dynamic”, i.e., information on these pages changes without requiring a complete reload, just like in Gmail.
• Currently, users are being given a choice to choose between the old and the new designs. But this liberty is set to be scrapped soon.
• Inertia of the masses, desire to preserve status quo, confusion over the new interface; for whatever possible reason, quite a lot of people (close to a million according to BBC — 1% of the entire user base — even though I couldn’t find any such group myself) are really p***** off about the new design.
• The new design itself can be summed up in two words: buggy & promising.

When Orkut did something similar a few months back, I was visibly annoyed. This time, I actually think the change can be for good as Facebook actually improved their experience with AJAX. Orkut’s redesign was merely the old one loading dynamically. To the end user, the difference was largely unnoticeable (evident from the fact that no one even bothered to complain about it). Facebook’s redesign, on the other hand, is a complete revamp of the end-user experience. Here’s a list of stuff that was refined as I see it:

• The profiles are less bloated now because of the clutter being divided into separate tabs now. I unreservedly despise profiles which contain 200 applications. Obtuse folks like this … :

  

  “I have so many applications I can make you feel like you’re living in the 90’s despite being on broadband. If you’re on dialup, go kill yourself. And oh, by the way, I need to get a life.”

  … are properly taken care of in the new interface. On a side note, it is entirely plausible that decent profiles is exactly what makes some people react against the new Facebook.

• The comments on Wall posts appear instantaneously when you click the Post button. This is in contrast with Orkut’s AJAX-ified interface where you still have to wait for the whole page to reload.
• And if you are so insistent on checking all the tabs of a profile, again, it won’t require a full reload of the page.

The interface is still buggy, yesterday night I couldn’t navigate as all the links started mysteriously appending to my current address in the address bar. In preliminary days of the new design, even basic stuff like tabs didn’t work properly. Nevertheless, the initial premises are, as I said before, promising. The bugs are getting fixed and at least they got the basic idea of an AJAX-ified interface right.

“Everything is in a state of flux, including the status quo.” — Robert Byrne

Tags: AJAX, Design, Facebook, Orkut, Social Networking, Technology, Web, Web 2.0

Google is obsessed with AJAX.

No, really. It’s starting to get on my nerves now. For those who’re unfamiliar with the term AJAX, it’s a combination of technologies (like Javascript) that, in essence, allow you to navigate on a web-page quickly without reloading the whole thing. The most prominent example people may recall is of Gmail’s interface.

So, why is it such a bad thing? Here’s the answer: it isn’t. When used properly, it can be great. Gmail, once again stands out as one of the leading examples here. Nevertheless, like any other technology, it has the potential of being abused. And, AJAX, when abused, can only be surpassed in terms of pure annoyance by Flash and Java. Quite surprisingly, the most effective example of “what not to do with AJAX” is also provided by Google, with its recent redesign of the social networking website Orkut.

In my opinion, Orkut is already a lost cause. No, not because Facebook is better. When Facebook started taking Orkut’s share, it wasn’t because Facebook was technologically superior to Orkut. And until just yesterday, I considered Orkut to be superior in at least that regard.

But now, Google decides to make all of Orkut’s pages empty. That’s right. Empty. All stuff would be loaded in those pages using AJAX and here’s the insane thing: they’re uniquely identified by anchors. That’s batshit insane. From a browser’s point of view, all of Orkut is a single page now. Stuff is just loaded on it dynamically using identifiable anchors like #Home.aspx. And no, there isn’t any fallback version. You just can’t use Orkut without Javascript now. All CGI-proxy access to Orkut (using sites like KProxy) is also broken now. My Orkut login frequency, thus, has taken a considerable hit and I really don’t think I’ll be using it even on weekly bases.

Aeternum vale, Orkut.

Tags: AJAX, Networking, Orkut, Overuse, Stupid, Technology