Planet Bazaar

July 02, 2009

Ian Clatworthy

Bazaar Explorer by Pictures

While building a GUI application is pretty easy these days, designing a good one remains a difficult problem. It took many years before I found GUI emails clients more productive than pine and just as long before programming in an IDE was more productive than the best editors around. As a dedicated fan/developer of Bazaar, [...]

by Ian Clatworthy at July 02, 2009 03:02 PM

July 01, 2009

Javier Derderian

qbzr: qsend dialog

Here I’m sharing a screenshot of the new qbzr Send dialog! The GUI is ready, now I have to make it to work… The GUI design was made by Alexander Belchenko, thanks!

by javierder at July 01, 2009 09:11 PM

Jonathan Lange

Twisted huh?

One of the hallway conversations I've had a few times so far at EuroPython goes like this:

A: Twisted's got some good stuff going for it, but I don't like the way it forces me to use Zope interfaces. It's too heavyweight?
B: Huh? What do you mean? It doesn't make you do that.
C: Yeah, there's lots of deep inheritance, which just feels really wrong.
A: Right, I have to write too much code to get something simple working.
B: Sorry, I have no idea what you mean. Can you give a concrete example?
A, C: I can't think of one right now.

To me, this is a very intriguing beginning to a real conversation. Do you know what A and C might mean here? I'd love to understand their points so that I can form an opinion.

by jml (noreply@blogger.com) at July 01, 2009 02:23 AM

June 30, 2009

Bazaar Developers

Scalability benchmarking: packs vs 2a on OpenOffice.org

Over the last few weeks, I’ve been converting a snapshot of OpenOffice.org to the various candidate formats and using bzr-usertest to get an overview of performance on common operations. OOo is 75K files and 260K revisions – at least an order of magnitude bigger than most other “huge” projects (like Emacs), so it’s an ideal [...]

by Ian Clatworthy at June 30, 2009 05:16 AM

June 25, 2009

Jonathan Lange

Argh!

I upgraded karmic, and now Do & Banshee are broken. :(

by jml (noreply@blogger.com) at June 25, 2009 05:47 PM

June 24, 2009

Robert Collins

24 Jun 2009

[edit: a home has been found]

Free to good home, one Intel 510T 22 port switch. (There are a couple of dead ports but its otherwise fine - no glitches or anything).

I've just replaced my home ethernet switch - I was using 5 ports, and most of my wired machines have gigabit now. Yay.

So, if you need a 22 port network switch, let me know. If I don't hear from anyone, it'll go into next months local recycling pickup.

This will be a 'come pick it up' arrangement, unless you're going to be at the same place I am for some other event - in Sydney, if thats not obvious.

intel 510T photo

June 24, 2009 09:07 AM

June 21, 2009

Robert Collins

21 Jun 2009

What is it with pc vendors that they make selecting machines by fairly useless things like model number (e.g. shuttle), or a hacky fugly hierarchy (e.g. auspcmarket) easy, but by attributes (e.g. '2 ethernet ports, no fans, small chassis') terribly hard.

They should take a leaf out of the way people ask each other for recommendations. auspcmarket /kindof/ does that with the systems hierarchy - but only for a few categories.

What I want I guess, is a menu of tags/attributes I can search for on a vendors site (and/or review sites like CNet's and, google shopping and so on). Doing a google shopping search for my interesting attributes above is a pretty epic fail.

June 21, 2009 12:56 AM

June 18, 2009

David Timothy Strauss

Tim Penhey

You're doing it wrong!

Just yesterday I found a missing feature in one of the apps I just started using. My thought processes were something along the lines of “hey, I could add this feature and it would be good”. So I went to the project's website, found their source code repository, and got blown away by the comment that was with it:

Please note that code you get from this repository is not intended for productive use (unless it's tagged as a released version, of course, in which case the usual alpha/beta disclaimers apply ;-)). We like to break our codebase, config files, database schemas and all kinds of stuff. We sometimes commit non-compiling revisions to facilitate collaborative development. Running such an unstable version might trash your settings, your backlog and maybe your computer. You have been warned!


Eh? OK, I get the first sentence. It is even a good disclaimer. Tagged releases are more stable. People regularly commit code that is unpolished. Sometimes even with some known bugs or issues.

The second sentence has me going “NO!?! What are you doing?

The third sentence just blew my mind. This project is using a DVCS. Not my DVCS of choice, but really that doesn't matter. All DVCSs are made to have good merging and sharing of code between developers. Saying “We sometimes commit non-compiling revisions to facilitate collaborative development” is just a lack of understanding of how to use the tools. You are using a DVCS to facilitate collaborative development! This is centralised version control thinking.

Try this for a code to work by:
Trunk should always at least compile, run, and pass all the tests.


This hasn't stopped me wanting to work on the code, but it has raised my caution levels.

by Tim Penhey (thumper) (noreply@blogger.com) at June 18, 2009 10:03 PM

June 16, 2009

Tim Penhey

kiwipycon

Today NZPUG held yet another organisation meeting for the first kiwipycon. Organising conferences takes a lot of effort by many dedicated people. The Christchurch python user group has volunteered to host the first PyCon in New Zealand. Personally I suggest things from time to time, but a big thanks goes out to those guys for the hard work that has gone on even before the call for papers.

The dates have been set as Saturday the 7th and Sunday the 8th of November 2009. A weekend was chosen to allow those working or studying who can't get leave to attend. As I understand it they are still working on pricing. The call for papers will probably go out next month some time.

Should be interesting...

by Tim Penhey (thumper) (noreply@blogger.com) at June 16, 2009 11:09 PM

June 15, 2009

Tim Penhey

launchpadlib updates for branches

Just a quick note to yet you know of a few changes to launchpadlib for branches. Mainly because I've removed a method that I know someone is using.

You used to be able to get to the branches for a project by saying my_project.branches, but I've removed this. It would have been nicer to deprecate it but we don't have a nice deprecation method right now for launchpadlib, and since it is still in beta, I didn't feel too bad.

The branches of a project was an attribute, now we have a getBranches method. The old attribute would give you all the branches of the project, including the merged and abandoned ones. The method defaults to give you the active branches, and allows you to pass in the statuses that you'd like to get.

Also with this change you can now get the branches for a project group, or the branches owned by a person using the same getBranches method call.

Project groups also grew the method getMergeProposals in the same way that the method was already available for people and projects.

Please file any bugs on the launchpad-code project on Launchpad.

by Tim Penhey (thumper) (noreply@blogger.com) at June 15, 2009 06:12 PM

June 08, 2009

James Westby

Merging file descriptor output

I have a problem that I believe will be easy for someone with a bit of UNIX coding knowledge to solve, so I appeal to those that can to help.

I'm trying to write a DBus service that will spawn a command, and provide the output to the user. The service runs on the system bus as root, and so it is a form of privilege escalation. However, the command may be long running, and produce a lot of output as it works, so I want to allow the calling process to get this output before the command completes.

My current approach uses gobject.spawn_async and so gets file descriptors back, one for stdout and one for stderr. I currently have a thread that uses select to wait for output, and then uses DBus signals to allow the client to access it. This works great, except that stdout and stderr can become interleaved in the middle of lines.

I believe that I can't just wait for full lines before signalling, as a command might do something like print "Username: " and then wait for input. I could normally do full lines, and then if the child blocks on stdin send whatever it has written so far, but that doesn't seem ideal. (I haven't implemented anything about proving input on stdin so far, but I don't want a solution that makes it difficult to do so).

It seems to me that this is something that will be implemented somewhere, for instance my shell can run commands and then interleave the output in a desirable manner, but I haven't found how yet. Any suggestions are welcome, but this is from python, so system calls that I can't make directly from python would be a pain, though I'm not that bothered about portability.

June 08, 2009 11:38 PM

Robert Collins

8 Jun 2009

Latin (As in church latin, not latin character encoding) in Ubuntu Karmic will work better than it did in Hardy/Intrepid. I had missed one of the packages that want hard coded locale data when I did the initial enablement patch.

For reference, when adding a locale:

  • xlib (wants to know what locales are actually UTF8 and what compose sequences to use)
  • gdm (wants to know what locales to display)
  • glibc-locales (has the actual definition

June 08, 2009 12:58 AM

June 07, 2009

James Westby

Free Music

I came across Anthony Raijekov the other day, and was treated to some of his Trip-Hop, which is outstanding. That was an added bonus though, as I sought him out to download his Piano track: "Photo Theme: Window Like". You can find him on Jamendo and on ccmixter. I would highly recommending going to listen, and donating via Jamendo if you like what you hear.

This also led me to go back and listen to some new stuff from Amether, who I found a few years ago thanks to Rob Da Bank. Definitely worth checking out, especially their remix of "Artisan - Hold my breath".

On the freely available, if not freely licensed side I noticed a new station from the excellent SomaFM today: Lush. It is said to be "Sensuous and mellow vocals, mostly female, with an electronic influence," and so far I am enjoying it though it is rather similar to Groove Salad. I find that I can't keep SomaFM on all day every day while working though, as I find that it repeats tracks just a little too often.

I've also been listening a lot to Ombilikal which covers the harder edge very well, with some breaks, drum and bass, and dubstep amongst other things.

While in Barcelona I had the pleasure of meeting Karl Fogel (and hearing him play, which was a treat), and talking a bit about free content. He explained to me some of the things that they are trying to do with QuestionCopyright.org, and some of their methods. It's great to see more projects working on the issue in a very constructive manner, and I hope that they succeed. So that we can have many more artists like Anthony Raijekov that I can discover and reward for their work more directly.

June 07, 2009 09:49 PM

June 04, 2009

Jonathan Lange

pyflakes now warns about unused local variables

I finally got around to finishing my fix for Divmod bug #2718 -- Warn about unused variables in methods in pyflakes. Last night, the magnificent Jean-Paul Calderone reviewed and landed my patch. This means that if you are using pyflakes trunk (either from Subversion trunk or from the Launchpad Bazaar import), pyflakes will spot code like:
def foo(bar):
baz = bar + 2
return 12
and generate a warning like:
example.py:2: local variable 'baz' is assigned to but never used
I use pyflakes hooked up to flymake, so it's always running all the time on every Python file I'm working on. Relying on it has become as second-nature as relying on syntax highlighting. There's a whole class of mistakes I don't make any more, simply because it's on.

However, the main way it helps me is when I'm refactoring code. When extracting a function or changing a variable name, pyflakes acts like a sort of todo list for me. Now that it shows unused local variables, it's getting dangerously close to perfect.

To get pyflakes quickly, bzr branch lp:pyflakes.

(Edit: Grammar fix)

by jml (noreply@blogger.com) at June 04, 2009 09:54 AM

May 27, 2009

Elliot Murphy

barthelona marina




barthelona marina

Originally uploaded by Elliot Murphy

reminds me of home


Elliot Murphy

by Elliot Murphy at May 27, 2009 07:33 PM

lobby of hotel juan Carlos in Barcelona

this hotel is fantastic, it has a piano bar, a scotch bar, a spa and
juice bar, and a helipad.


Elliot Murphy

by Elliot Murphy at May 27, 2009 07:30 PM

May 26, 2009

Paul Hummer

Thoughts, Impressions, Feelings, and Notes from AllHands in Barcelona

I spent this past week in Barcelona with all the other Canonical employees at a meeting we call AllHands. I have the opportunity to travel to all sorts of nice places with Canonical, and experience lots of conferences. None of those other experiences hold a candle to last week's events in Barcelona. I'd like to share my experiences, notes, feelings, and overall energy in this post (and try and start a new flow of regular interval posts).

A Plug for Moleskine

First off, I need to say something about my method for taking notes here. Prior to leaving for my trip, I picked up two Moleskine notebooks that have unlined pages in them. I'd seen them used by many of my colleagues and friends, but never really saw why they had such hype behind them. After looking through my notes, there was something about the Moleskine that absolutely changed the way I write notes. The diagrams, blurbs, and quotes I wrote down last week were in a completely different and amazing format that allowed me to actually capture a lot of the thoughts I usually just try to reference and hope I remember.

On Collaboration

Collaboration has been on my mind for a while, and there are a lot of thoughts I have that are arranging themselves into blog post as we speak. I'm amazed at how much Canonical and its employees are thinking about collaboration. There was an overwhelming amount of questions like "How can we make X better?" and "What if we did Y like this? Would it be easier?"

Launchpad and Bazaar are two humongous examples of us trying to make collaboration easier. Launchpad has created this workflow for handling your code, doing merges of other people's code, getting bugs fixed, getting your code translated, releasing tarballs, and allowing people to easily install software into Ubuntu based machines. Launchpad has a rich code review system, which I am convinced is the best way to make open source software better.

The Ayatana Project excites me beyond my ability to express. Free software is generally written, tested, and (unfortunately) designed by geeks. This usually means that to find a tool with great design and usability is a gem. To have a team that is completely and totally devoted to making free software easy to use for my mother is amazing. Take your app (you know, the one you think is just amazing), get someone's attention in #ayatana on Freenode, and ask them (ever so nicely) what you can do to make it stellar. Do it. Do it now.

UbuntuOne is going to end up being a great service, and I would venture to say it will be a reference guide to the web services of the future. No data lock-in, open protocols, standards-based implementations, and the sky is the limit. UbuntuOne isn't about file sharing (although that is a cute first feature). It's about sharing data in any form, and as it fills out, it really will make collaboration even more social.

Finally, I wrote an open ended question to myself to think about, and thought that maybe I'd throw it out here as well. For context, Jono Bacon was talking about community (y'know, plugging his book and all that :), and I wrote "Open source thrives on a meritocracy - how can we prevent feelings of entitlement?" I see this a lot in open source communities: people earn their "commit rights" and then start behaving like everyone owes them something. Collaboration is about peers, not about hierarchies.

Getting Organized

A highlight of the talks I attended was a talk by Jono Bacon on recognizing and avoiding burnout. It was on eye opener for me. I spend a lot of time writing code, and I have now recognized that at some level I'm getting burned out by it. I'm doing a lot of things at the same time, and doing them absolutely terribly.

The biggest thing that hit me was that my methods for staying organized are terrible, and they aren't working. When this happens, one may be working hard, but not accomplishing much of anything. I've since restructured what my daily planning is like, and will report when I have data on its success or failure.

The Culture of Canonical

This was my greatest experience at AllHands. The nature of Canonical is that most of us work from home. This means that we can easily miss out on the social aspects of co-located work, like going out for a beer (Coke for me thanks) after work, shooting Nerf guns at each other, etc. However, because we work with these people on a daily basis, we form these incredibly strong bonds, so much that when we actually meet on this physical plane, we're old friends that would bend over backwards for one another.

Daniel Holbach epitomizes the Canonical culture at the very core with his hugs. I think of my direct manager more as my friend than as my manager. I enjoy seeing the rest of my team in person, because they are all really great people. There is absolutely no difference in social status between Mark Shuttleworth himself and the newest hire. We all work together. There isn't this idea of "What I do is more important than what you do" but more that "What you do is so helpful that I want to make sure what I do is helpful in return" Canonical is really about Ubuntu, the product, and the meaning of brotherhood and working together.

May 26, 2009 05:40 PM

May 25, 2009

Jonathan Lange

Landscape on Code Review

The Landscape guys mentioned three things that I've missed in Your Code Sucks and I Hate You.

  • The important thing about code reviews is that they are a conversation. Emphasise this in your team's code review culture.
  • Don't speak to the person, speak to the code. "Why does the code do this?" rather than "Why did you do this?".
  • Remember that the person who wrote the patch is an expert in that patch.

by jml (noreply@blogger.com) at May 25, 2009 06:15 PM

From the Hands

Just starting at UDS after a week at Canonical's Allhands event. Allhands was great, but one of the highlights for me was the Landscape team's presentation on their development process:
We optimize for fun. If something works really well in theory but it makes things less fun, then we don't do it.

by jml (noreply@blogger.com) at May 25, 2009 06:01 PM