Wednesday. The first day was a little rough (I was jetlagged for most of it anyway) I thought. The large groups didn’t work out terribly well and weren’t conducive to getting work done. Although we got a lot of stuff for Google Summer of Code discussed (sidebar: our 2010 projects have been announced. Congrats to the 6 awesome proposals we’re working with this year), there were a lot of other things we needed to talk about too and everyone who attended wasn’t necessarily interested in GSoC. Spent the rest of the day hacking, trying to beat jetlag, and hitting up “Fashion Meets Tech” with Andrew.

Thursday. I have to say the small group structure we adopted on day 2 worked incredibly, and I think we should continue to use that model from now on. Having small groups allowed really focused discussions on things that could really interest you. For example, I was able to work with some people in discussions regarding long-term planning for Bugzilla and Code Review or file metadata–subjects that don’t interest a lot of people–and was able to skip the sessions on OpenID or the Toolserver. It gave you a group of really interested people all very focused on the same task at hand. All of the sessions I attended were fantastic, but I’d like to summarize my two most productive ones below:

New-installer – I led this session in one of the upstairs room just after lunch on Thursday. I was a little hesitant to show it off in the state it’s in, but I have no regrets after doing so. Everyone really seemed to like where it was going, and I got a lot of solid feedback (most of it should be at [[mw:New-installer issues]], feel free to add items if something’s missing). Also began working with Siebrand on the localization aspects. The installer’s i18n has been split into its own file, loaded like an extension, and he completed the Dutch translation so we could start debugging. Roan also took the time to clean up the Javascript and jQueryify it. I think everyone liked it though

Organizational issues – On the first day we mainly talked about GSoC. The second day covered a lot of really important subjects such as bugtracking, code review, release management, the Mediawiki roadmap and volunteer outreach. It was largely a consensus over our known trouble spots and single points of failure. Our new CTO, Danese, informed the group that these issues are known and that specific plans are in place to fill these gaps (contingent on new budgets, et cetera). This is welcome news for a lot of us in Mediawiki/Wikimedia development. The notes of all this are on meta.

Friday. Friday was mostly spent bugsquashing and bouncing ideas off one another. And the day we all started getting very worried about a volcano from Iceland that we couldn’t pronounce. So a bug was filed (and quickly took a life of its own).

The next several days were spent booking and rebooking flights. Changing hotels. Searching for laundromats. Trying to find places for free or cheap wifi. The whole conference wasn’t there (luckily), but the group who were an awesome group of people who made being “stranded in Berlin” a more enjoyable experience. I got to eat great food and talk wikis and tech for days on end. I couldn’t ask to have been stuck with a better group of people. Bonded by our ‘travelupdate’ list and FlightRadar24.com, we managed to all stick it out in Berlin and keep the wikis running.

I’m glad I got to see some familiar faces, some faces I had not seen, and entirely new faces I didn’t know. I won’t be in Gdansk this summer for Wikimania, but hopefully we can manage to pull together the “East Coast Hackfest” for sometime this winter.

Maybe the new job will get slightly less busy soon :-\

So I wrote AndCache this weekend. Fellow Android developers, object caching just got a whole lot easier for you. There’s only 3 things you’ll ever (need to) call, so I’ll explain each one of them.

AndCache.setContext( ctx );

Android SQLite databases require a context so they know where to save the data. I give a static interface for projects to set the context and leave it be, throughout their application. This serves two purposes: firstly, the cache doesn’t have to have its own context, and secondly: by having the context tied to the calling application and not tied to the cache itself, we make it work independently of other applications, securing your data.

AndCache.get( "someKey" );

To get something from the cache, just call get() Given a String, it will check the cache for whatever is stored with that key. It returns as a generic Object, so you can cast it to whatever you need. Returns null if nothing found or expired, so you can easily see if you got a cache hit (all exceptions are handled internally, so you have a clean interface).

AndCache.set( "someKey", someValue, timeToLive );

To put something into the cache, call set() with a key name, some object you want to cache, and how long to keep it in the cache (in seconds). The passed object will be serialized and stored as a blob for later retrieval (this is all handled transparently). We return true/false on a successful save to cache.

This is released under the GNU General Public License, version 2 or (at your option) any later version. Enjoy.

I wonder if this is some feedback on our own output for mobile browsers. Perhaps this could get used upstream

I really haven’t had the time to delve into the source yet, but the premise is what’s intriguing me. Typically, rich apps can only go but so far in interacting with the user’s computer unless you start using Java. This is doubly true for smart phones. Especially with newer models, we’ve got devices that are fully capable of rendering whatever Javascript and CSS you throw at us (WebKit ftw!). However, we’re not able to tap the potential just yet of these devices. Imagine clicking “upload a picture” on a web site and having the camera kick in for a quick take-and-upload session. OilCan seems able to do this. The built in demo shows an Amazon search page where you’re prompted to scan a barcode in directly from the camera; OilCan comes from the same developer as CompareEverywhere (the app where you can scan the barcodes and it searches for other places you can buy it).

There’s also a similar project called Mosembro that I haven’t touched yet. Although, it seems to be more about reading your web pages and finding data that it can attach handlers to (auto-linking to maps, contacts, that sort of thing).