Metacity (the window manager for GNOME) has this annoying and ugly minimize animation that looks like a bunch of cascading rectangles flying at your taskbar. I’ve always hated it, but dealt with it for awhile.

Today, I did some digging on the Metacity bugzilla to see if it was fixed, and found this bug.

Over the course of 3.5 years, this bug has sat on the bugzilla, and still isn’t satisfactorily resolved. There is now a reduced_resources flag in gconf, but this flag only disables the minimize animation at the expense of forcing you to use an ugly wireframe window dragging animation. (Complete, utter insanity.)

Read the rest of this entry »

A surprisingly articulate post on OSNews about Free Software:

Asking me to get off my a$$ and code drivers for this baby is what I consider elitist and a very unreasonable demand on the end user. It’s one thing that gives GNU/Linux zealots a very bad name in the real world.

I have sneaking suspicion that you get this response from the Linux community because we feel you’re placing unreasonable demands on us. Your points are valid, but your energy is misdirected. Unfortunately for those who don’t like to code, that’s how software is created and improved. We invite you to participate in our projects in a variety of capacities including but not limited to programming, but of course participation is not required.

I think that Linux “zealots” get a bad name because much of the “real world” believes in a culture of entitlement. Look at everybody living life with a chip on their shoulder, blaming everyone else for their problems and scoffing at the notion that they take responsibility for their own situation. Somewhere along the line we stopped believing in opportunity as a means of realizing our dreams and began to foster the idea that we’re entitled to our expectations. In “Linux land,” we believe that the opportunity to participate in our information society is fundamental to our inherent desire as human beings to better our situation and control our own destiny.

Of course, money can make just about any dream come true. Mark Shuttleworth, for [example], invested $10 million to help make the Ubuntu project a reality. But years ago my great-grandmother told me the story of how my family came to America with nothing but the promise that here they would find a land of opportunity. This is the same promise we make with free software. This isn’t elitist, this is egalitarian.

I have to say, this is part of what makes me love Free Software.  It’s this idea of widespread opportunity.  Sure, F/OSS has power structures and means of coercion/control built into certain parts of it, but for the most part, it’s based upon a very simple, powerful, and egalitarian idea.  “Anyone can improve this, anyone can make it better.”  It’s that kernel of an idea that makes any process — whether software production, book editing, encyclopedia editing, or even beer brewing, more enjoyable to those involved, and, as a side effect, better for the general public.

Lately, I’ve been very diligent about catching up on my reading.

I have been perpetually delaying a review of Capitalism 3.0 and Dreaming in Code, both of whom deserve it. But I promise one soon. I use Hofstadter’s Rule of Thumb lately for estimating time: however long you think it’s gonna take, double it and add a unit of time. So if you think it’ll take two hours, it’ll really take four days. If you think it’ll take five days, it’ll really take 10 weeks. And so on.

In the meanwhile, I’ve been busy at work — actually working on some cool stuff from a technology standpoint, mainly in the realm of hacking with pieces of the Eclipse Modeling Framework, and its related projects like GMF, RCP, Eclipse Core, etc.

On my commute, I’ve been enjoying reading Making Globalization Work by Stiglitz. Although one of my friends mentioned to me that this book would be quite boring, and for the most part he was right. Not the lofty stuff of Barnes in Capitalism 3.0; but perhaps Stiglitz’s recommendations are much more practical for ways to improve the current system.

The other book I started recently is a long, written interview with John Kenneth Galbraith (much in the style of Socrates) which is entitled, Almost Everyone’s Guide to Economics. What’s amazing is to see Galbraith, this towering (literally) Keynesian economic thinker, speaking in the 70s of the growth of corporate power, the undermining of labor, and the insidious nature of market fundamentalism. And yet, here we are, 30 years later, heeding none of his warnings, and entering into the new “global age” of “The World is Flat”.

Oh yes indeed, I do need to write some reviews very soon.

Overall, Dreaming in Code was an interesting book. For programmers who already are obsessed with the classics of software engineering (Mythical Man-Month and friends), you probably won’t learn much new stuff in this book. However, the personal illustrations using OSAF did lead me to some self-evaluation of the work I do. It was also interesting to see the internal workings of an organization which seems to be set up ideally for programmers — a good mission, an open source project, no real deadlines or users in the beginning, design-focused, etc. — and still see it run into the same issues traditional software shops run into.

I’d post a longer review, but I’m headed down to New Orleans today. Will post a longer review when I get back, hopefully also of Capitalism 3.0, whose ideas have been swimming in my head the last few days of commute.  I think they really deserve to be summarized and presented here.

In the meanwhile, I’ve started reading Making Globalization Work by Joseph Stiglitz. This book, in particular, has been a kind of catharsis for most of my armchair ideas in economics, at least so far.  It’s a very strange feeling to read the ex-Chief Economist of the World Bank explaining his own ideas about overcoming the zealousness of “market fundamentalism” prevalent in economic circles, while I, who never studied economics formally, think, “Why would anyone trained in this discipline actually believe that markets are a magic force that work on their own?”  But I guess ideology always trumps rationality.

I just picked up a copy of Dreaming in Code from Barnes & Noble. Will probably devour it in the next couple of days.

Google has an interesting talk about “How Open Source Projects Survive Poisonous People” at Google Video.

On February 13, they’re going to have the creator of VIM, Bram Moolenaar, giving a talk on VIM7.  What’s funny is that Bram, who has been working full-time on VIM for the past few years (living entirely on donations and money votes for VIM features) has now been hired by Google.  Smart move.

I got fired up by the evidence coming out of Microsoft from yesterday, and decided to write a post to Miguel de Icaza’s blog.

Here’s what I wrote:

Hi Miguel,

It looks like a new set of “Halloween Documents” have come out, thanks to a case in Iowa, Comes et. al. v. Microsoft (http://iowaconsumercase.org/index.html). I’m wondering if you have any comments on this document in particular, which suggests that Microsoft management knew full well they were “stealing Java” to intentionally marginalize the cross-platform language issue.

A select quote from the document, “Screw Sun, cross-platform will never work. Let’s move on and steal the Java language.”
Here’s the e-mail archives, which was submitted into evidence:

http://www.iowaconsumercase.org/011107/PX_2768.pdf

I’m wondering, given these thoughts from within Microsoft management, and given the recent news of Sun open sourcing the Java language under GPL terms, how is it that you can still push for the Mono project on Linux? Aren’t we always going to be fighting an uphill battle against a monopoly company protecting its biggest cash cow: the Windows platform?

Although my question was more “devil’s advocate” and meant to rile him up, Miguel provided some of the strongest and most cogent arguments for Mono that I’ve seen on record.

I just want to say great work to Miguel and the Mono team, and that if you ever doubted your raison d’etre, all it would take is reading this thread to be convinced! You’ve certainly convinced me!

Update: it’s really this kind of dependency on Windows I’m worried about in .NET. I think it’s just that the culture of the Java runtime is one of platform independence, whereas .NET from Microsoft is one of “platform dominance,” and Mono is some sort of stepping stone between Microsoft’s single-platform vision and those of us who want to write cross-platform apps using .NET.

Just saw this on Salon.com, in a letter to the editor about Scott Rosenberg’s new book, “Dreaming in Code”:

There are three options you have when developing software:

1. Quality

2. Lots of features.

3. Low cost

Pick any two.

When you actually go through the combinations, it’s quite funny, and poignant.

Also, check out this excerpt from Rosenberg’s book, called “Words fail us.”  I’m currently working on a software project and we’re doing lots of new and innovative stuff, and I can’t even express how much I connect with this article.  Choosing the right vocabulary may be the single toughest thing in working on software team projects today.

The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures. Yet the program construct, unlike the poet’s words, is real in the sense that it moves and works, producing visible outputs separate from the construct itself. It prints results, draws pictures, produces sounds, moves arms. The magic of myth and legend has come true in our time. One types the correct incantation on a keyboard, and a display screen comes to life, showing things that never were nor could be. … The computer resembles the magic of legend in this respect, too. If one character, one pause, of the incantation is not strictly in proper form, the magic doesn’t work. Human beings are not accustomed to being perfect, an few areas of human activity demand it. Adjusting to the requirement for perfection is, I think, the most difficult part of learning to program.

Frederick Brooks, author of the The Mythical Man-Month, disinguished between two problems in software development: the accidental problems and the essential ones. (Read Brooks’ watershed article, “The Silver Bullet“.) The industry likes to argue that we have made huge leaps in terms of the accidental in recent years. Programmer productivity is better with the help of better software revision systems, but more importantly there are RAD tools like GUI designers, powerful IDEs like Eclipse/VS.NET. Do I think we’re headed in the right direction?

In a sense. I think those tools are useful, but only because I think all we can do is shrink the accidental problem as small as possible, and then do our best to tackle the essential. The major win in terms of the accidental and even the essential is high-level programming, and I mean really high level, like Python. Why is this important? Well, Brooks once talked about how PL/I was a great software engineering language because the statements written to the compiler are “pretty close” to the “thought stuff” the programmer is working with in his head. But PL/I is nowhere near there (neither is C++, or even Java or C#). However, Python heads in that direction.

In my head, unless I really am immersed in C code all the time, I don’t think of things like types, memory management, or, God, pointer arithmetic. When we solve problems, we solve it in something computer scientists have used for years: pseudocode. Pseudocode is nothing more than code that expresses an algorithm or approach without worrying about the gory details of the underlying hardware.

Python isn’t quite pseudocode, but it’s closer than anything else I’ve seen. And that’s a huge help to productivity not just from the point of view of the single developer, but, I’d argue, also from the point of view of a team of developers. Code readability is hugely important in team environments. C and Perl can be very unreadable, which makes them ill-suited to team development. Java and C++ are better, but even they suffer from some readability problems (where the actual solutions can be masked by “best practices” and strange ways of exploiting constructs of the language). Python can be hacked too, but it tends not to be, and it tends to have very high readability.

But what about the tools mentioned above (Eclipse/VS.NET)? I often wondered about all the *nix programmers (including many of my Computer Science professors) who still load up X11 and dump into vim or emacs for their programming needs. Wouldn’t they benefit from the latest and greatest in IntelliSense, Refactoring, CallTips, SaneOnlineDocumentation, and any other CamelCase ideas I can think of for a development environment? Most *nix users would say that stuff is unnecessary–and in many senses, they are right. The essential problem remains, no matter how fancy your IDE is.

A lot of *nix developers shrink their accidental problem on a “as-needed” basis, by coding plugins or complex configurations for their highly-extensible text editors. But nowadays, productivity is starting to be a concern even in the OSS world, where things have traditionally stuck with the old “mortar and pestle,” or, should I say, “gcc and gdb”. That’s why we see projects like Mono gaining a lot of popularity.

But Python offers a nice, alternative path, I think. The accidental problem is worth shrinking, and I think it can be done simply by one major refocus:

(1) make the language usable, not the tool. (IMO, already done with Python)

and

(2) create source code analyzing tools that integrate with development environments to make the language-bearer more productive.

You can see enormous success in (2) with the Eclipse IDE project. My main problem: Eclipse’s focus is on a language that isn’t very usable. Java is certainly better than C, but still, it has significant problems that stop it from connecting me (the programmer) with my problem-solving ideas (the thought-stuff of programming).

At my new job, I work with Java eight hours a day, but my code just doesn’t read and work like my Python code, which is much closer to the underlying algorithms and approaches. Java certainly pushed forward OO on the masses of computer programmers, but it did so without learning non-OO but very handy scripting language concepts, like having Lists and Hashes be built-in types, with tons of syntactic sugar, for crying out loud. Most problems break down to List and Hash problems, after all. What’s more, OO on its own isn’t a panacea: I’ve seen many convoluted OO designs that I wish were written procedurally, and which might have been more performant if they had been. The software engineering community thinks that there will be a silver bullet (OOP! AOP! XP! MDE!), but I think just getting programmers closer to the “thought-stuff” will be an effort with better rewards.

There is a great article posted by a developer of the open source FreeMarker project on a proposed “third” role for web development teams — something between a backend application developer and a frontend web designer.

Check it out.

I have to say, so much of this article rang true for me. I just finished a web application in which we had four developers but two main rules: backend developer and frontend designer/developer. Due to the type of project it was (and the skillsets of the people involved), backend work was done by 3 of the 4 team members, and frontend work was done by a sole designer.

The issues we had were that:

• The backend developers could only make guarantees about what kind of object to pass to the view. But often, in order to get access to other “global” objects, the frontend designer would have to hack controller code as well. (Luckily, data services were tiered off out of the controllers, so at least the designer didn’t have to muck about with SQL.)
• The designer hated the idea of pushing some logic “back” into application code. So, though we as backend developers proposed a layer for configuring things like which menus to display on each page, etc., the frontend designer preferred to engage in the copy-paste-modify antipattern instead, so that it could just “get done.” I can see why: it’s a pain to context switch from JSPs, HTML and CSS to Java POJOs that then will have to be checked using JSTL anyway!

If, early on, we had decided to use FreeMarker instead of JSTL, perhaps the frontend designer could have had access to more powerful macros, and wouldn’t have done the copy/pasting. But I think overall, the two tiers are too few; I agree that you need someone to sit in between and think about how to cleanly integrate backend logic and frontend design.