UNIX Zen

You know you’re in UNIX zen when you are looking at pictures for an apartment you are interested in, and you think to yourself, “Man, I’d really just like to download all 8 photos of this apartment at once.” So you realize they end in numbers 1-8, and you open up a terminal and write:

for i in `seq 1 8`; do 
  wget http://www.livinginbaires.com/imgs/departamentos/46-$i.jpg; 
done

And that’s it, you hit enter and *vroooooom!* You see progress bars fly across your terminal as wget snappily fetches your photos, and suddenly, all eight photos are downloaded, and you get back to work. That’s empowering.

I don’t often quote Bill Gates, but…

Early in the history of Microsoft, our view was, if you were very smart then you could learn how to manage people, how to do business, how to do marketing.

It turns out that talent isn’t that fungible. Somebody who is great at doing software in many ways is often not the right person to manage people. I think the thing to recognize is these different kinds of ability, and to think through, as you build a team, “How do you get the right mix?”

Although I probably wouldn’t have used the word “fungible” myself, I agree with Bill’s sentiment. Programmers are not developers. And developers are not managers. But, I would add something else to this:

A manager who doesn’t know what it’s like to be a programmer or a developer cannot be a manager of programmers or developers! Management is a special combination of leadership ability and empathy. Your manager needs to be able to stick his neck out for you, because he knows you. And he needs to be able to provide wisdom — not because he’s smarter, or because he’s more mature, but because that’s now his role. Managers are the guys who protect you from everyone not on your team, who make sure you have everything you need to innovate, and who provide wisdom because their job description includes, “must be able to dispense timely wisdom at all the critical moments.”

Management also includes vision. Some software developers become managers and their vision alone leads their team. Where that kind of energy isn’t possible, lots of empathy, planning, and wisdom are necessary.

Getting the troops mobilized

I gave a talk last Tuesday called “Open Source Development: A Rapid Introduction.”

Here’s the blurb I sent out when I advertised the talk:

Have you wanted to work on open source projects, but just don’t know how to get started? This talk will provide the basics you need to start working on open source software the next time you sit down at your computer.

In particular, this talk will cover:

(1) A brief overview of open source development in the industry and press.

(2) The UNIX development platform. A brief and whimsical overview of the UNIX shell, its surrounding tools, and the power of shell scripting. (Useful to anyone wanting to learn more about UNIX tools.) Learn how to do in a few lines of shell script what you only thought was possible with a big, extravagant hundred- or thousand- line program, and learn why so many of the world’s best hackers hack on a *nix system.

(3) The basics you need in order to hack on open source project: how mailing lists, wikis, bugzillas, source code revision systems all come together to form an organic code management process, and how to get started using those tools and others to learn about a project and what parts need development work done. This will include a brief introduction to CVS.

(4) The last part of the talk will involve actually watching open source development in action. In particular, the speaker will checkout some code from a source repository, make a change to it, create a patchfile from that change, then track down the mailing list or bugzilla related to the project and submit the patch to the maintainer. You will actually get to see open source “in action,” and will want to do it right when you get home!

If you’re a Windows or Mac OS developer who has always wanted to learn more about *nix systems, or if you’re a developer who wants to either take his own project open source or work on existing open source projects, this talk is for you.

Of course, if you’re someone who is just interested in the concept of open source, this talk will give you an inside look at “how things get done” in this community.

This talk was at least partially inspired by Nat Friedman’s blog post, check it out here:

“How to be a Hacker”

The talk was a general success, I think. About 12 people attended. You can see the talk in PDF or ODP formats, and you can also download the patches I wrote specifically for the talk to illustrate “open source development in action.” The patches are pretty stupid, but do illustrate the point, at least. Plus, each of the three patches served one of my own goals (hacking my CPU frequency scaler, fixing a gnome-terminal bug, and hacking galeon “for fun”), so that’s that. I think it’d be cool to give this talk again (maybe a little refined to include less basic UNIX tools and more hacking stuff) at a later date. We’ll see.

What’s better, small or big?

To start out at a small software firm, or to go with one of the big guys? I’m wondering myself what the right decision is, what advice I’d give someone.

On the one hand, big guys mean bigger projects, more formally managed projects, and at least from that point of view, harder “software engineering” problems.

Small firms are less formally managed, but you may be pushing some technology to the limit, rather than just providing some service (however essential it might be) to the company. It’s the software that matters, not “the System.” And you’ll probably be working with better coders. (The best coders fill up the small shops, whereas they are just diamonds in the rough at the bigger shops).

In either case, this is turning into one of those things your parents always warned you about. You know, when they say it isn’t about the company, but it’s about you and what you put into it. Just like college was. I honestly could have gotten just as much out of college with a library card and Internet connection, and lots of free time.

Now that I’m moving up to the “real world,” I keep thinking: no matter what I do, it’s gonna be my responsibility to grow my skills and knowledge, and no one else’s.

It’s definitely going to be an interesting year…

Site cross-pollination – check out h2h

I just wanted to mention that earlier today I finally got hand tracking working on my final project for my Motion Capture / Computer Vision class. You can now connect a webcam to your computer, load up my GTK+ program, and watch boxes with crosshairs follow your hands accurately as you move them across the screen.

Pretty awesome, no? Check out the project if you haven’t yet, its MoinMoin wiki is here. I might post up a video of it in action soon.

It uses a clever skintone detection algorithm across the RGB colorspace, along with clever segmentation of the regions of interest to determine the cardinal direction a hand is moving in and retargeting the box to the new area and running the algorithm again. I am quite happy with the results. It can only get better, but it’s already pretty fun to play with.

Slashdot comes through for once: on the viability of open source “business”

There’s also a larger problem with this approach – it sucks for small companies trying to become bigger.

If you are only able to profit off of service contracts, you can’t ‘write once, reach many’ like you can with COTS software. Moreover, companies like IBM and Novell which have large established sales and service teams will win all the larger contracts.

If you write a great peice of software, and then have to sell, educate the customer AND hire/train all the workforce, how much time are you going to have to devote to Rev. 2 of your world beating product?

Whenever folks talk about OSS in the context of markets, I think it should be with a jaundiced eye towards our “helpmates” at IBM, Novell, SAP/MySQL and Sun.

Ultimately, IBM et al are about making money for shareholders, if they didn’t see that as the likley outcome, they would not be out there pimping OSS.

I think a world where software is only ‘sold’ in the context of a service contract is bad for the next great idea. OSS is great in its place, but to preclude software for sale isn’t the answer.

The truth hurts for Free Software zealots, but it’s the truth.

Free Software isn’t about eliminating proprietary software, at least it shouldn’t be. It should be about developing a free system for development, learning, and sharing, because we can.

The MDI Plague and Window Management Woes

There is a nice article on Wikipedia that discusses the multiple document interface, a horrible hack that took hold in the Windows world to deal with the fact that Microsoft’s default window manager was inadequate to handle multiple windows existing under the same application.

I think Mac OS/OS X handles the MDI plague best by simply grouping all application windows under a single application class, with a single menubar. But usability experts have debated whether that makes the most sense, since the menubar can change, for example, depending on what window is in focus. I think users get used to that, and it also allows the menubar to be as long as necessary while the window can remain as small as necessary. That’s a nice win.

However, given our current model on *nix/Windows of menubars for every reasonably complex window, and given the lack of the MDI hack in GTK+, we do have a mess for applications that need more than one window to operate properly, i.e. Glade and The Gimp.

What I’ve been doing is giving these programs their own workspace as a workaround. That seems quite greedy of them, and indeed it is. What’s more, however, is that it’s unusable. Even when I switch to my Glade workspace, I see 4 windows in my taskbar, each with the same icon and with the following names: “Glade: h2h”, “Properties: image95”, “Widget Tree”, “h2h”. The first three are actually part of the Glade window class, and if I enable Metacity’s taskbar grouping, I see them as part of the same group. The last one, however, is just my actual window, and so is separate.

This is good–but I only get some form of usability when I actually enable window grouping. The thing is, in Metacity you can’t enable window grouping on a per-application basis. It’s all, sometimes, or nothing. Sometimes means metacity only groups windows when I’m running out of space. Otherwise it’s either on or off.

The thing is, grouping isn’t just about space saving. It’s about being able to perform window manager operations on a group of windows, i.e minimize all and maximize all.

This doesn’t even solve all problems: alt+tab still shows me all 4 glade windows, which can be quite confusing since only one comes into focus at a time. But that’s a separate issue, separate debate.

Wouldn’t it be nice if instead of Metacity just “figuring out” when to group my windows together, it let me just press a hotkey “Group all X windows on this workspace”, where X is the application I’m currently in?

I’ve decided this feature is so valuable, I may just hack metacity to add it. It will at least provide a path for solving the MDI nonsense.

Update: check out these screenies of a “different” approach to MDI written in GTK. It’s called GTK ADI.

Met Runar, Discussed Software

I met with Runar (he’ll have a blog soon, I swear) today, and we discussed open source, Python, and all related goodness over coffee and vegetarian lunch free-riding on the ‘sNice wireless network.

We spent about 3 hours there, just talking about Runar’s project, “sqlstring”, my ideas about inferred typing and static source code analysis in Python, Python’s niceness in general, user interface toolkits, AJAX being a big, nasty hack, and web application frameworks in Java and Python. Our discussion really degrenerated into praise of vim once we discovered that we were both happy users. Text editors really bring people together.

Runar kind of convinced me that trying to infer all the types of objects is very “unpythonic,” which I guess is true since it discourages the crazy stuff you can do with Python. Maybe the best thing to do is judiciously eval code, as was my original impulse for getting nice completion out of Python? Not sure.

Or maybe I should just give up the idea and accept the fact that vim plus ipython is just about as good as it gets. That seems like a cop-out, though.

Regardless, Runar seemed somewhat willing (only half-willing) perhaps to give a small talk for Free Coders on Python, I’ll see if I can convince him that it’ll be fun. I suppose I could give the talk myself, but I already do all the talkin’.

User interfaces with GTK+ and Glade

I’ve been hacking up a user interface for my motion capture/computer vision project called “Hand2Hand,” found here.

At first I was gonna do the user interface in Python and have the image processing done in C, but then I decided that the user interface was simple enough that I should just give GTK+ in “pure C” form a try. Of course, I used Glade, which drastically reduces the amount of annoying code for things like Vboxes and Hboxes and Containers you have to write. In fact, using Glade, interface design becomes somewhat straightforward in C. Which is weird, because C seems like it was never built for user interface design, but the g_signal system makes it easy to catch events that occur in your program, and GTK+ is high enough abstracted that you can do pretty well. I don’t know how well GTK+ scales for large programs (i.e. many dialogs, many lists, etc.)–in that case, I think I’d definitely pick a higher level language.

Looking forward to how this application may turn out. OpenCV looks like a pretty awesome library.