Older blog entries for dobey (starting at number 285)

Two for the road

Today marks my second anniversary of working at Canonical. It has been an amazing two years, and I'm looking forward to seeing so many of my brilliant coworkers and the Ubuntu community members next week, at UDS. And here's to the next two years being even better than the previous two.

Syndicated 2010-10-20 19:01:48 from dobey's blog

Development vs. Design

In software, design and development are both things I am passionate about; and have been actively doing for a very long time now. In fact, it should be said that one cannot exist without the other. Even if you are writing software with an intended user base of one, you are still going to design the interface around how you want to use the application. So, it is probably no surprise that I find it rather troubling that so many businesses still keep these two vital pieces of their company, so separated. There is a fascinating quote, which I feel embodies the spirit of my feelings about design and development, from the book Hagakure:

Our bodies are given life from the midst of nothingness.
Existing where there is nothing is the meaning of the phrase, “form is emptiness.”
That all things are provided for by nothingness is the meaning of the phrase, “Emptiness is form.”
One should not think that these are two separate things.

Design is Dead by i-marco

Defective by Design

Unfortunately, businesses tend to continue to put design departments under the marketing business unit, rather than engineering. I can only imagine that the common reasoning for this, is that designers make pretty things, and pretty things are needed to sell products, so therefore designers are marketing. Unlike the heady days of the early industrial revolution, however, design and product are now much more tied together than ever before. With the lower barriers to entry for using both developer tools and graphics design, user testing, and other design related tools, it's easier than ever for developers and designers to work together toward the same end. If your business is maintaining the business unit separation by having design as part of marketing, it's hurting both teams. Developers no better like having designs thrown at them, which aren't fully implementable, than designers like being told to make applications pretty, after they're built and shipped. Good visual design is important, but being visually different is much less so. Yet, so many companies strive for the latter as an attempt to achieve the former.

Burning Bridges

The best way to build a new bridge, is to burn down the old one first. If it doesn't come crashing down, you probably don't need to build anew. If you're a developer or designer, or have ever seen a thorough discussion betwixt, you can probably see how those bridges would fall in a blaze of glory. Often, design is more an afterthought, and developers don't have the time to take the new design considerations to heart; or the designs lack in what they could change, coming so late in the game. Sometimes design is a primary thought, done completely outside the realm of engineering. There is no interaction with the developers who would be implementing the design, until the majority of the design is complete. This often leads to software which can't be completed as designed. The application will sit in a state of limbo, partially complete in both functionality and design. If your software is to be successful, these bridges must be burned.

Phoenix by jurvetson

Rising from the Ashes

So the pyres of a thousand bridges are burning in your wake. How do you build successful applications, and integrate design and development? Many steps will lead to a better ecosystem for both, but the first thing that needs to happen is for design to be totally under the engineering unit in a business. Get your designers and developers sitting next to each other all the time, and talking about their projects together, on a regular basis. Bring your designers to development sprints and conferences. Don't bring the whole design team though, and have them all sit off to the side drawing pretty pictures. Get them in the middle of core development discussions. If you're a FOSS company, make sure they are as involved in Community as the developers are. Design is an engineering resource; consumable by both the software engineer and marketing resources. Never devote more than 30% of the designers to a single project, now matter how large the project. If you think it needs more designers, you need to scale your project back; or you've got way too few designers in the first place. If you want designers who just do R&D all the time, put them on an R&D team with a few developers who will also be doing only R&D full time. Everyone will be happier; designers and developers will both be more productive. Beyond simply making the design team part of the engineering unit, there are several additional things you can do, to improve their situation further:

* Train your designers with basic development principles and tools
  - Get them working inside the application's source repo.
  - Get them submitting patches/branches to change artwork and text.
  - Get them to understand developers don't need a visual design for every little thing
* Train your developers with basic design principles and tools
  - Get them to understand the basics of the HIG for the platform their developing against
  - Get them in the habit of referring to the HIG for more complex matters
  - Get them in the habit of testing for behavior, layout, and other aspects of design
* Train designers and developers to handle Customer Feedback Loop better
  - Get developers to understand higher level customer issues with design, beyond crashing
  - Get involved and communicate to truly understand where the confusion lies
  - Give everyone time to deal with customer issues when planning a project
* Avoid trying to push Visual Design as your Brand
  - Visual Different is not always good
  - Can lead to sometimes breaking intrinsic features from upstream
  - Before changing Visual Design, get everyone involved in understanding why it should change

This is primarily a problem in software, and is where my experience with these problems lie, but this advice may be applicable to other industries suffering similar issues, as well.

Syndicated 2010-03-28 20:07:51 from dobey's blog

Web of Old

I miss the web, when it was the web, and not a platform for building giant applications that require a more expensive computer to use, than to play a very complex 3D massively multiplayer adventure role playing shooter. Then, all I needed to find some information was a keyboard, a screen, and average cheap hardware. Now I need a multi-core CPU with 8GB of RAM, just to load and render some pages. REST feels sort of in the same boat as RISC was 10 years ago, right now.

Syndicated 2009-10-20 02:49:53 from dobey's blog

Sexism, Generally

Really. People. Get over yourselves.

Sexism is a two way street. And every time someone says "girls" it's not sexist. And no, I'm not defending one way or another. This latest stink about someone saying "I've a hard time explaining to girls what we do" was almost certainly not sexist. It was a generalization. Everyone makes generalizations, even girls. As software developers, it's a pretty simple fact. Out of all the people we meet in our line of work, the majority of females are less inclined to understand what we do exactly, than the majority of males. Is that sexism? No. Would it be called sexism by girls, were it to be stated by a female? No. Is it being called such because it was stated by a male? Yes. But in the end, it was a simple generalization based on the same experience we all have to deal with. And you know what... we need quit crying wolf, and deal with it.

But we don't all need to walk on eggshells every day of our lives, in every interaction we post on a blog, or every line we speak when giving a talk. That will never solve the problem. It will only cause more and different problems. Because the world isn't androgynous. It's not how the world works. So get used to it already. If someone does say something that you personally have taken offense to, then you need to deal with it in an appropriate manner. We're all adults here (well, mostly anyway). You should contact that person privately, and discuss the matter in a rational manner. Blogging and making a fuss about every little instance of the word 'girl' on the internet isn't appropriate, nor is it going to help. If either party cannot discuss the matter rationally, then perhaps the issue needs to be escalated in an appropriate manner. Twitter, blogs, or whatever other widely published means, are probably not appropriate, because they are inherently irrational. If you truly want to help put an end to sexism, then being sexist isn't the way to go about it.

Out of all the sexist people I've met in my life, the majority were female.

Syndicated 2009-09-27 15:57:33 from dobey's blog

Hacking Launchpad

A couple weeks ago, I wrote a quick hack for myself and the Online Services team at Canonical, to help make doing reviews on all the projects we manage, much easier. It pulls the list of branch merge proposals for each project from Launchpad, and sticks them all in a nice list in a GtkTreeView, along with the number of votes, and what type of vote. As there was a lot of immediate interest in the tool from other people, I ended up creating a new project on Launchpad, and pushing the code to a public branch there, under the GPLv3. You'll find it at http://launchpad.net/lptools. I will probably be adding other tools soon as well, as every time I have to use a web browser, it slows my progress, and interrupts my ideal workflow. If anyone else has tools they'd like to have included here, or ideas for tools, feel free to propose branches which add them, or send me mail.

I'm not a fan of Python. But I chose to write this tool in it anyway, as I wasn't intending to make a real project out of it. It was just a quick hack to make part of my life much easier, until I can get around to writing something much better and more deeply integrated with the desktop. But the GTK+ bindings, and python-launchpadlib, made it very easy to hack this script up very quickly. I do wish there was a better way to do the authentication though. Opening a browser, and requiring the user to press "Enter" in the console, is an awful experience. But it works, and I only have to do it once...

Frankly, launchpadlib makes it very easy to not have to use the web... and in some cases, makes it better, since the Launchpad web UI doesn't expose all the features that are in the API.

Syndicated 2009-08-10 01:39:10 from dobey's blog

Central Services

We do the work, You do the pleasure

Hi there. I want to talk to you about ducts. Do your ducts seem old-fashioned? Out of date? Central Services' new duct designs are now available in hundreds of different colors, to suit your individual taste. Hurry now while stocks last, to your nearest Central Services showroom. Designer colors to suit your demanding taste.

A lot of people have talking about the social desktop, networked services, and similar stories lately. I guess the integration between computers and network services, which I had been talking about over 11 years ago, is finally catching on. Thanks to all the new smartphones, netbooks, and similar devices, designed to be on-line all the time, and the services people are providing for those devices, we're now trying to wedge the same integration into our outdated desktops. And it seems like nobody really wants to do what's best for everyone here. Having all the apps just use the same libraries to access the same data, and parse it separately, and have the user add their account to all the apps N times, just isn't going to make a good or useful experience.

This is where Central Services would come in. I've talked a little bit about it before, to a few people at UDS, and on IRC. I haven't had a lot of time to work on getting the ball rolling though. But I really want to get things going now, so that we can build a really awesome experience in the desktop, around all the services available, and that everyone uses daily. The goal is to provide a central system where all the plug-ins and configuration live. The user would then only have to add their account for any particular service once. The system would also provide transcoding features for data, taking the XML or JSON for example, and converting it to a common format that all the apps which are designed to display the data only have to actually deal with a single, defined, common format. Central Services however, would not be a data store. Rather, it is a central place for accessing your data from wherever it is stored. There would be a small, optimized local cache, perhaps, and we could integrate with indexing solutions, which may store the data, to provide more feature-rich search capabilities in the desktop as well. But the overall goal is to provide a simple, consistent means for accessing and managing your data. I've been thinking a lot about the problem over the years, and I think a modular, centralized system is the best way forward on the desktop with it. I've been trying to think of a nice way to design the API, with a good balance between being generic, yet powerful. The main API access will be via DBus, but there will be some C and Python convenience libraries as well. I'm not entirely sure what the best way to document the API, and get stuff rolling there is, but I'd love some help and feedback with it. If you're interested in making the desktop awesome, and helping define the API, and getting some working code up and out in the wild, please e-mail me and let me know, or poke me on IRC. You can e-mail me at the usual dobey on gnome.org or dobey on wayofthemonkey.com to get my attention.

A common API, accounts interface for users, and cross-service integration all over the desktop would be a huge win for everyone. Let's get together and make it happen.

Syndicated 2009-08-04 02:17:10 from dobey's blog

30 Jul 2009 (updated 30 Jul 2009 at 17:08 UTC) »

The System Is Down

Last night, Stuart and I were having a little argument about the merits of OAuth and whether it is actually suitable for what we are using it for (authenticating destop applications to access a service), as I am not particularly fond of it, and I was working on support for OAuth 1.0a. Stuart's argument is that user's trust the browser, and we need some piece of trust in the system, and OAuth provides that as it pretty much requires a browser to use it. But I don't really think users trust their browser (as so many don't even know what a browser is), but instead, what they trust is the site they're looking at. The browser doesn't even exist. It's just this inherent part of the system that you have to use. To most people it's The Internet, or the giant blue e, or a compass. The browser has no real meaning to them. It's the place they have to go to search for things, and access information. And Humans have two very important attributes. They are both very prone to error, and very resilient. People will keep going to the web, despite all its problems with poorly designed sites, and crashing browsers, and broken plug-ins, because they need to get at the information they're looking for. And they will very often type their password in the wrong place, or mistake a phishing site for a real site. No amount of code will fix this. And nothing that requires a Human to do something will guarantee security and authenticity. It will only create annoyances that Humans will optimize around.

As a specific example. I received a PayPal phishing mail in my Inbox this morning. It's a pretty nifty attempt at getting credit info, too. It includes an HTML form attachment, which POSTs to PHP script that was implanted on http://ag-exchange.com/, presumably by compromising either Apache, PHP, or some other module their server is using. It appears to be a simple script which just reads the POST data, and redirects the user to the PayPal About Us page. The HTML form requires javascript and has a little card number validation method it seems, to avoid getting bad data. The mail was sent to my alias on gnome.org, and apparently got sent by taking advantage of an SMTP relay with a broken configuration. Of course, the SMTP server may have also been compromised and just had the configuration changed to allow open relay as well, but I suspect it was probably just open already. And that mail server belongs to

Syndicated 2009-07-30 15:09:16 (Updated 2009-07-30 17:08:52) from dobey's blog

Things Goin' On

I meant to make an announcement last week, but have been too busy to write up anything... The new version of intltool, 0.41.0 was released last week, with several bug fixes. It's available on Launchpad. This release also gets rid of the long-standing and annoying multi-line quotes warnings in Python files. So get your distros upgraded!

Speaking of annoyances, another one that's be cropping up quite a bit lately, due to the fact that the Ubuntu One client code wants to launch a browser for acquiring an OAuth access token, is how obviously un-usable the Default Applications concept really is in our desktop, as so many people have been filing bugs about the browser failing to launch. And the logs show exactly what's wrong, the configuration is broken, and pointing at an executable or path that no longer exists, and probably hasn't for some time. I'm surprised anything in the desktop can open a browser on these machines. This is of course, because we call the xdg-open script to launch a browser, so that our client will work on all the XDG desktops. Calling the GTK+/GNOME API directly would probably result in a different key being used, and the browser loading fine. I wonder if we can somehow make this better, because having multiple different configuration keys to launch the browser is doomed to fail at some point (which is of course what is happening right now for us).

I'd say something about RMS, but I know a bunch of you would take the time to write me some fiery e-mails. But the Michael Jackson bits in the South Park episode "Mexican Staring Frog of Southern Sri-Lanka" were great.

Syndicated 2009-07-20 20:27:16 from dobey's blog

Tarmac Mini-Sprint

Today we are having a mini-sprint via the ether for Tarmac, the most awesome piece of branch landing code using launchpadlib and bzrlib, to land approved branch merges automatically. Join us in #tarmac on freenode and help us make it even more awesome.

Syndicated 2009-07-10 13:55:11 from dobey's blog

Ubuntu One 0.90.2

We've been in a controlled beta of Ubuntu One now for a little more than a month. Recently, I've been hacking on the client a fair bit, porting our Nautilus extension to C, to avoid the dependency on python-nautilus, and for the extension to perform better, and not slow down desktop start up times by loading up Python. As part of this, the build system for ubuntuone-client was switched over to autotools for most stuff. We still generate a setup.py, and use it to perform a few tasks, but that should be going away soon as well. Keeping it around requires some funky magic in the build system, to pull all the necessary pieces into a release tarball correctly, and get Python pieces installed to the system. But now we have a way to build reproducible tarballs, and should be doing regular releases on Launchpad. You can find them here:

Ubuntu One Storage Protocol

Ubuntu One Client

We encourage people to build packages for their favorite distros as well, and are glad to answer any questions about how things should be packaged. If you have any questions, feel free to come bug us in #ubuntuone on FreeNode (irc.freenode.net). Enjoy!

Syndicated 2009-06-19 04:16:04 from dobey's blog

276 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!