hackergotchi

treitter

Let's Push Things Forward

Maximizing social utility for fun and (modest) profit


hackergotchi
treitter

Folks building and passing tests consistently

In the Folks project, we've managed pretty good buildability as we've been developing the project. So far, that's mostly been through us checking buildability of patches during reviews and fixing any build breaks immediately when we hit them on our own machines. As I said in my FOSDEM talk, I don't think this "spot checking" is sufficient for the kind of reliability GNOME projects really need given our reliance upon jhbuild (which, by its design, does not cope well with unbuildable master branches).

A couple weeks ago, Martin Pitt announced the jhbuild continuous build server he has been working on. It's a great setup and clearly details which modules are failing to build and why. It also keeps useful metrics like "time of last successful build", "time of last failed build", and runs and reports on the results of "make check".

This is a great safety net for GNOME as a whole, since it continuously checks our entire stack in a common environment. Once maintainers get reliably notified about any breaks, I think we'll see broad benefits. When our code reliably builds and passes its unit tests, it's a lot more attractive to outside (and inside!) developers.

With, thankfully little work, Folks is now reliably building and passing its unit tests on this server, and I intend to keep it that way :)

I'd like to thank Martin for setting this all up and him and Jean-Baptiste Lallement for helping debug some LXC-related issues which were causing some of our tests to fail on this server (but not for us maintainers, making it hard for us to help).

In the process of fixing these issues, the build server proved its usefulness for our project already because it caught a build break I didn't hit on my own system (because I had an older version of EDS build). Normally, this could have taken days or longer for me to notice because I tend not to re-build the stack below Folks very often. If I'm working on a large feature, I want to get it all working before I potentially break my build environment with unstable changes in our dependencies. A continuous integration system should also make frequently updating dependencies less of a risk (which is just more good news for everyone).

hackergotchi
treitter

Decisions

I coincidentally stumbled across this on my flight back from FOSDEM:

The word decision, closely related to incision, derives from the meaning 'a cutting off'. Making effective decisions—and learning effectively—requires massive elimination and the removal of options.
—Tim Ferriss, The 4-Hour Chef

hackergotchi
treitter

Answering the question: "How do I develop an app for GNOME?"

During the GNOME Developer Experience Hackfest this week, one of the major goals we identified was the need to pick a single language to give a simple answer to "how do I write a GNOME app?".

Right now, if you ask that question, you'll get about 8 different personal-preference answers, which drives people away from our platform. Having to potentially evaluate several different languages and their stacks gives potential developers a lot of unneeded extra work.

There was broad consensus in the hackfest for this goal because it allows us to:
  • It allows us to focus when we write developer documentation, fixing bugs in the development environment and the development of tools. This reduces our maintanence costs and enables us to be vastly more efficient.

  • It enables code and knowledge sharing to occur, so that people can easily copy and paste code from existing applications, or find information about common problems and challenges.

  • It provide a coherent and easy-to-follow path for new developers.

  • It allows us to include the full GNOME framework within the language itself.

We spent a long time discussing the different options that are available to us, and there were a variety of opinions. However, at the end of the day, we had to recognize that no language is perfect and there will always be disagreement. The important thing was that we had to make a decision.

It's critical that everyone understands this decision as a plan to elevate the language, bindings, tools, and documentation to a level of quality we have not yet achieved. It is not a decision to abandon any other language bindings. We will continue to distribute other bindings and documentation as we do now and compatibility for the other languages will continue to be developed as they are today by the developers involved with those modules.

Our decision is to support JavaScript as the first class language for GNOME application development. This means:
  • We will continue to write documentation for other languages, but we will also prioritize JavaScript when deciding what to work on.

  • We will encourage new applications be written in JavaScript.

  • We will be working to optimize the developer workflow around JavaScript.

C will remain the recommended language for system libraries.

Why JavaScript?
  • Our language of choice needs to be dynamic and high level.

  • There is already momentum in the GNOME Project for JavaScript -- it's used in GNOME Shell and GNOME Documents.

  • There's a lot of work going into the language to make it especially fast, embeddable, and framework-agnostic.

  • JavaScript is increasingly being seen as a first class desktop programming language -- it us being used in Windows 8, mobile platforms, and for local web applications.

  • JavaScript is self-contained -- it doesn't come with its own set of core libraries, which makes it more convenient for us when integrating it into the platform.

This is the start of a process and there's obviously a lot of work ahead of us. However, prioritizing a single language will enable us to turn GNOME into a compelling platform for application developers in a much more effective and efficient manner.

hackergotchi
treitter

Inbox Zero and GTD: a personal success story

After years of attempting to apply the philosophies of Inbox Zero and Getting Things Done (including, appropriately, failing to finish the GTD book twice), my personal and work inboxes are empty and I've never felt so on-top of my tasks. In no particular order, here are some changes I've made that have helped me out:

On top of Slogen
Forget what you're standing on and focus.

I read The 4-Hour Work Week, which touches on Inbox Zero and adds some interesting productivity-increasing ideas, including giving up on boring articles and the controversial "don't waste time reading news". I haven't stopped reading news, but I feel like I've gotten a little more efficient at it. I mostly ignore mailing lists (except those for my immediate projects). The only reason I'm subscribed to some is so that I can reply to them on the occasion I'm CC'd or someone brings up a specific discussion to me.

Along the line of distractions, I've been training myself to catch them before they happen. Because there's increasing evidence that multi-tasking reduces productivity (and it seems obvious to me anyhow), I push myself to not switch tasks unless I absolutely have to. And I actively ignore anything that I know will needlessly steal my focus. This includes only checking up on IRC periodically (and mostly just to check for messages that have been highlighted for me). If it's urgent, people will send me a direct message (and Gnome Shell will give me a nice notification).

I believe the author of 4HWW intentionally mentions keeping only calendar events, not tasks. I've always liked the idea that you will remember anything important and anything minor will come up again (particularly because I've struggled with far too many tasks in my GTD system). But that seems too extreme/unworkable for me, so the key has just been being much more aggressive in deleting tasks that sit too long (knowing I'll never get to them) and doing periodic sweeps through each list. If you have trouble with that, you might want to create a "some day" list to move neglected tasks to. Then, just make a point to ignore that list. I think I'm nearly ready to delete mine.

Another part of minimizing mental burden has been closing application tabs and windows and conversation notifications as soon as I can. When I finish a task, I close everything related to it (even if I think I'll use some of them later). The stress saved by this reduction in visual noise is much greater than occasionally having to re-open something sooner than expected (which is incredibly rare, as you might imagine).

SandyBridge_Die
Your screen should not look like this.

And the latest change I've made, just before reaching inbox zero/GTD zen, has been to batch process my inboxes. I had a terrible habit of glancing at mail, flagging it important and unread, then moving on. It turns out that I subconsciously skip over bold, red lines of text. This was a horrible priority inversion that lead me to sporadically clearing out the simple mail while ignoring the high-priority, difficult tasks.

Now, when I do my few daily mail passes, I do two quick passes (always in oldest to newest order, never skipping any):
  1. Add tasks, file mail
    1. parse out new tasks to my GTD system (setting due date and priority appropriately)
    2. if it needs a trivial or no response, give it immediately, then file
    3. otherwise, move on to the next letter
  2. Give non-trivial responses
    1. Read the letter in detail
    2. Respond to each point necessary

Now, with an empty inbox, I can get work done by just drilling through items in my work or personal task list in order from highest to lowest priority. It's a lot harder to skip around, ignoring the important tasks, when they're sitting in front of you, in the exact order you've chosen yourself.

I still have things to improve (I really wish I had one place to manage all my tasks, not several), but I finally feel in control of my day-to-day goals!

hackergotchi
treitter

Conferences and anti-harassment policies

Valerie Aurora posted a very insightful article about harassment at conferences. She focuses largely on "hacker"/security conferences, like DEFCON, but the general principles apply to all conferences. And I've personally seen related bad behavior (though to a much lesser degree) at conferences I've attended (which have all been based around open source software, not "hacking"/security).

The work that Valerie's Ada Initiative is critically important for the technology industries, which still have a lot of work to do on being inclusive (particularly to women).

As some personal anecdotes, most of the best conferences I've attended have had strict anti-harassment policies/codes of conduct (including Linux.conf.au and GUADEC). They help make the conference a more-welcoming place by clarifying unacceptable behavior, which brings in more participants from a wider variety of backgrounds, which makes the conference better for everyone.

Specifically, GUADEC's and Gnome's work to include more women has really started to pay off. The official count this year was that 17% of the attendees were women, and it was obvious. And it was especially for anyone who's been attending since Vilanova in 2006, like me, where I can honestly only remember a few women attendees. The Gnome Outreach Program for Women certainly deserves a fair amount of credit here, as do the Gnome community's clear and consistent enforcement of the Code of Conduct.

Codes of Conduct/anti-harassment policies/many laws should not be necessary. But they clearly are because some people otherwise don't understand or refuse to comply with common decency. These policies really require a fairly minimal amount of effort to create and enforce, open attendance to a much wider and diverse audience, and benefit everyone as a result. Everyone wins!

hackergotchi
treitter

Folks discussion / hackfest on Tuesday

We're going to have a Folks & Friends hackfest and discussion at the Desktop Summit on Tuesday at 10:00. Meet in front of Kinosaal and we'll re-locate to a room with tables.

Topics include (but are not limited to):

  • User input. We'd really like to hear what you think about Folks and its Empathy and Gnome integration.

  • Constructive compliments

  • A follow-up on progress on the tasks we set at the Social IM/Contacts hackfest in Cambridge

  • General discussion/questions/requests


hackergotchi
treitter

Talking about Folks at the Desktop Summit

Saturday at 11:20 in Rm2002, I'll be giving a talk on Folks, covering exciting topics like:

  • What is Folks?

  • What isn't Folks?

  • Folks in Gnome 3.2, MeeGo, and Qt Applications

  • How Folks can help you be a more-complete person*

A lot has been going on in Folks lately (including the 0.6.0 release, which will be happening shortly), so you really won't want to miss it!

I'm going to the Desktop Summit

*This may or may not require subterfuge

hackergotchi
treitter

IM, Contacts, Social hackfest successful

I just got back from the highly-productive and thoroughly-enjoyable IM, Contacts & Social hackfest.

We discussed a number of issues related to chat, video/audio calls, contacts, and social web service integration into Gnome. After each session, we filed all the necessary bugs to make sure we don't lose track of anything. Check out the session pages for notes and links to the related (mostly new) bugs.

It was especially good to have usability people Nick Richards and Allan Day on hand for our user-facing discussions. In general, I'm very happy to see Gnome continuing to move toward an interaction-design-driven development methodology. I'm quite confident that having a strong, consistent design-first, code-second process is the way we can (more than) close the usability gap that all-too-often exists between open source projects and their closed source counterparts.

Gnome 3.2 is going to have fantastic chat and contacts integration with the appearance of Gnome Contacts, Folks getting an EDS backend, Folks/Gnome Shell integration, and a number of other integration points. And it will only get better from there!

I would like to thank my employer, Collabora, for sponsoring the hackfest with a venue and especially the time of so many relevant developers (and to Guillaume for organizing the hackfest). Thanks also to the Gnome Foundation for additional sponsorship and Intel and Red Hat for sending along a few people each. This type of collaboration will help ensure that Gnome (and related platforms) not only keep up with our closed-source friends but begin to surpass them in ways we traditionally haven't (particularly usability).

hackergotchi
treitter

Updated Folks/QtFolks roadmap

We've focused the plans for Folks for the next few months and beyond in our much-revised Roadmap.

Some highlights:

  • Finishing the Evolution Data Server backend and making it the default primary backend

  • Adding search-based contact retrieval

  • Lazy-loading of attributes (to avoid a performance crunch as we've added a lot of attributes)

The Tracker backend will be the default primary backend for MeeGo until it officially switches to EDS for local contact storage. Around that time, we'll spin it off into its own module to make sure Folks can play well with out-of-tree backends.

hackergotchi
treitter

New features in Folks 0.4/0.5

A lot has been going on in the world of Folks lately, so it's time for another update. There have been a ton of fixes and clean-ups in the code (including some well-documented API breaks). We're narrowing down on another set of API breaks in our unstable 0.5.x branch before starting the stable 0.6.x branch. Our goal is to have very few (if any) API breaks after that.

Perhaps more importantly, we've added a lot of great features in the last few months. Read on for more (heavily-summarized) details.

I'd like to thank Intel for both sponsoring most of this work and understanding open source development. We were able to work in the open very early on and keeping things upstream was a goal, not a challenge. All the work is LGPL 2 or 2.1 and none of it requires copyright assignment.

New Fields

One big focus in 0.4.0 was adding a number of address-book-type fields, like:

• Role (within an Organization)
• Birthday
• Notes
• Postal address

In all, contacts from Folks support most of the generally-useful fields you'd find in a typical address book.

The remaining features are new as of version 0.5.0.

Primary backend

A design goal of Folks, since the beginning, has been to simplify the way writes happen. There is, at most, one (primary) backend which provides contact linking hints to the aggregator and which stores address-book-like contacts (which are generally fully-writable for all supported fields). This has historically been (hard-coded as) our simple key-file backend but it is now configurable.

Tracker backend

The new Tracker backend acts as an address book and supports both reads and writes. Creating this help fill out our support for local, address-book-like contacts, so that portion of Folks is in decent shape now. It can be set as the primary backend, though the default remains the key-file backend. My colleague, Raúl, did a great job putting this and a sizable set of tests together.

libsocialweb backend

We've also added a backend for libsocialweb which lets us expose contacts from various web services through Folks. This required a little work on libsocialweb itself to add a Contacts interface and implement it for a handful of services (so far, Facebook, Flickr, Twitter, and Last.FM). Alban picked up on Marco's work in this area, added the last three services and implemented the newer Folks interfaces for the libsocialweb backend.

I think this area is especially exciting, since it lets us include contacts' details from a very wide range of services in the future, just by adding more services to libsocialweb.

Potential Matches

A long-requested feature has been the ability to hint matches between various contacts within Folks (since it's tedious to have to manually discover them all yourself). This clears the way for us to make linking nicer in Empathy.

In the future, we'll be looking into making this process even easier.

folks-inspect

Our handy folks-inspect utility has gotten a bit of attention to support the fields added since 0.4.0, making it even more useful for debugging.

QtFolks

I've followed up on Marco's initial QtContacts bindings for Folks (QtFolks) by adding additional fields and supporting contact adds, edits, and removes. The git respository is here and release tarballs here (for now).

I hope we can get our KDE-using friends interested in Folks now that we've got some decent Qt bindings!

Demos

The moment everyone has been waiting for:


(In case your browser can't play WebM: download here; YouTube version here)

The demos in the video are done through the QtFolks demo program because Empathy filters out non-IM contacts (at least as of this writing). But we'll certainly be supporting all Folks contacts in the Gnome 3.2 contacts features.

You are viewing treitter