Advogato blog for dobey

SOPA MUST DIE

Sat, 17 Dec 2011 22:24:46 GMT

If there is one big thing about the SOPA bill currently being discussed, in Congress and pretty much everywhere else as well, it is that almost nobody in Congress understands a damn thing about the Internet; or even how everday businesses function. A bunch of engineers and FOSS/IP lawyers writing up an open letter, discussing freedom and rights, may not be the best way to get the attention of a Congress who are obviously so willing to put such things aside, for the benefit of their corporate lobbies. People like Rep. John Flemming, may not quite understand such vague concepts as freedom, and rights. So, I thought maybe I could help people out when trying to tell their Congressmen to vote against SOPA/PIPA bills, by providing an analogy they might understand. One that is based on money, and classic businesses.

So, if you want to know why SOPA/PIPA are bad, here is why. Imagine for a moment, that you own a business; one which provides people with tasty sub sandwiches. Now imagine that you have 30 million customers, and serve up to 20,000 of them every day. Your business is unique, and flourishing, because you also have a feature which allows customers to create their own sandwiches, and share the recipes with everyone else. About 60% of your customers, all peruse this feature, and their custom recipes get posted into the electronic menu system at your shop. Now, imagine that a competing store, has a special recipe, which they pride themselves on. Several of your customers posted this same recipe to your menu system, with slight alterations, to fit their own tastes. The competing store finds out, but says nothing to you, or the customers who posted the altered recipes. Instead, they report that your store is violating their Copyright on the recipe, to the Department of Justice. The Department of Justice issues a court order to the city, to remove the road which is allowing all of your customers, to reach your store. You wake up the next day, to go and open your store, but the road is gone, and you can no longer get to it. Nor can any of your 30 million customers. Any money you would make from having that store, is gone. You can't really move it to any other location, anywhere in the United States, as you have been put on a blacklist, and no cities are allowed to have roads leading to your store. You can move out of country, but all your customers would have to travel much further to get to your store. You will no longer make any money from having that store.

Do you really want anyone to be able to shut down your entire business, without any warning, whatsoever? I doubt it. This is exactly what SOPA/PIPA would be like for businesses, of any size, on the Internet. We must not allow this completely idiotic set of bills to pass. They are a complete and utter violation of the Constitution of These United States of America.

Tell your Representative, and Senator, to throw this garbage in the trash, where it belongs.

Goodbye World

Thu, 13 Oct 2011 14:03:25 GMT

#include <stdio.h>

int main (int argc, char * argv[]) {
    printf ("Goodbye, world.\n");

    return 0;
}

Goodbye, Dennis Ritchie.

Uplink Icons

Fri, 17 Jun 2011 02:03:07 GMT

Started working on finishing up some icons I'd started drawing a while back, to get some more practice in Inkscape. Finished up the app icon for Uplink, which is available in the Ubuntu Software Center.

Encompass Progress

Thu, 10 Feb 2011 15:08:04 GMT

Have been working a little bit in the evenings and weekends over the past month, to rewrite Encompass in Vala, using WebKit. It's coming along slowly, but surely. Here is a screenshot of what I currently have it at, almost up to par with the last code I have for the GtkHTML2 version.

Bringing it Back

Mon, 17 Jan 2011 23:13:51 GMT

If you know me, you probably know I once wrote a web browser using the gtkhtml widget for rendering pages, called Encompass. Well, after many years of not touching that code at all, I've decided it's time to bring it back from the dead. Web security has been an ever-growing issue over the past few years, and browsers haven't really done anything to improve it. Rather, they seem to only rapidly add very resource heavey features, and only deal with minor security flaws in their own code. Nor have any really sought to make drastic leaps in usability. Most all the UI differences across browsers is all for the sake of being different from the others. Why is it so hard to find a secure and usable browser, that integrates into the system?

Well, that's exactly what the new Encompass will do. Sadly, the gtkhtml engines have fallen drastically behind, and aren't up to the task of dealing with the modern era web. So I will unfortunately be required to use the webkit engine, as I am not interested in building a new rendering engine right now. Hopefully I will be able to build the browser how I want to, without having to make many changes to webkit itself; though I suspect some will be required. And hopefully it won't take too long to get a working version, as I am rewriting in Vala, to speed things up and simplify the code.

Two for the road

Wed, 20 Oct 2010 19:10:44 GMT

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.

Development vs. Design

Sun, 28 Mar 2010 20:09:04 GMT

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.

Web of Old

Tue, 20 Oct 2009 03:08:36 GMT

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.

Sexism, Generally

Sun, 27 Sep 2009 16:10:30 GMT

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.

Hacking Launchpad

Mon, 10 Aug 2009 02:06:37 GMT

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.