Sunday, November 15, 2009

How to get a reputation on StackOverflow

A little while ago, I noticed that people were posting questions about Apache CXF on stackoverflow.com. It's easy enough to answer questions, but I wanted more. I wanted to be able to herd the sheep: clean up tags, edit confused questions, and generally improve the quality of the resulting knowledge base. This would require a significant store of reputation, in StackOverflow parlance, so I set out to accumulate it.

It doesn't take much observation of the site to learn that reputation comes from answering questions. Sure, if you ask really good questions, people will vote them up and your reputation will advance. However, most questions don't get upvoted, and who has time to sit around thinking of questions?

But it's not enough to answer questions. Adding the 3rd or 4th answer to a question is not going to get you votes, and votes are what you need. You have to get in there and be one of the first two to post a concise, helpful, answer.

Visiting the site, I found that it was not so easy to take a timely snipe at questions I could answer. The good candidates were buried in the giant mass of questions on subjects where I knew nothing, cared less, or both.

The first solution lept out at me: set up some 'interesting tags'. Then click on the tab that shows only unanswered questions in those tags. Seemed simple.

It didn't work. That tab is nearly entirely populated by questions that have three or four answers. They are still there because no one voted for, or accepted, any of them. In theory, that means that these are mediocre answers, and I could add a superior answer and get some votes.

No such luck. Usually, these are perfectly sensible answers. It seems as if there are not enough site users who bother to vote, and nowhere near enough question-posters who bother to accept answers. The result is usually an impenetrable clutter.

That led me to my second strategy. I started collecting a very large set of 'ignored tags'. To filter out what I didn't want to see, I had to add many, many, tags. Why? StackOverflow uses a flat taxonomy. To avoid seeing Visual Studio questions, you need to exclude about 10 different tags for 10 different versions or aspects of Visual Studio. Repeat this for all the other subjects of disinterest, and soon enough you, like I, will have a long list of ignored tags.

The reward for this labor is that the 'recent' tab under the unanswered questions is suddenly useful. Now, the most recent questions of possible interest appear at the top of the page, just waiting for a quick answer.

Sure enough, this allowed me to pile up over 500 points of reputation in a few days of visiting the site at spare moments.

My points are nothing like evenly distributed over my answers. I posted plenty of answers that collected no votes, and thus no reputation. Many got a vote or two. The big winners were two very simple answers to simple questions: A brief lesson on logarithms and quick reminder of an option to the linux mkdir command.

Go figure!

Anyhow, I've now got the privilege of fixing bad tags, and if this keeps up, I can look forward to permission to edit other people's questions.

One final hint: stay away from meta.stackoverflow.com, unless you are suffering from insomnia or have an urge to count the angels dancing on Zippy.

Thursday, January 29, 2009

Mysteries of Maven

Maven is a very interesting beast. It seems well-established as the successor to ant as the best practice solution for java builds. It has the cardinal virtue of doing simple things simply. Very large ant build files can collapse to very small maven pom.xml files.

It does simple things simply, and the complexity curve is not far from linear as you try more complex things. However, there's a knee in that curve, and I spent this morning with it firmly planted in a sensitive part of my anatomy.

Consider the maven-antrun-plugin. It's typical of maven that it handles the special capabilities of its competitors by absorption rather than religious argumentation. The antrun plugin allows you to embed ant build tasks in your maven build. If you don't feel like figuring out out to reexpress them in purely maven terms, you can just keep them as-is.

Now, I happened to have a multi-directory structure to move to maven, and there happened to be two places in the structure where antrun seemed the better part of valor. The first one worked fine. The second one did not. After much hair-pulling, I was able to demonstrate to myself that the dependencies that I had listed in the second case were ignored.

"Dependencies?" you ask? Maven plugins, like maven-everything-else, come with a list of dependencies that are added to their classpath. If you want to use ant facilities that aren't in the core of ant, or custom tasks, you have to package them up as maven artifacts and list them as dependencies.

Skipping to the end, there's a bug in core maven that causes all but the first set of dependencies on a plugin to be ignored when multiple projects are evaluated together. Fair enough. Things have bugs. What seemed interesting to me was how wildly opaque this bug turned out to be.

The maven-dependency-plugin didn't reveal much, since it doesn't seem interested in plugin dependencies, only module dependencies. The debug log (-X) didn't add anything to the situation. Like many debug logs, it is a compendium of things that seemed interesting to a developer chasing a particular issue at a particular time. I found myself wondering, "what would fail-soft consist of in this case? Could there be some other medium-level debug output more adapted to people debugging their POMs than to people debugging the inside of maven itself?"

Debugging is a understudied problem.

And there turn out to be two open bug reports on this against the plugin, even though it isn't the plugin's fault.

Saturday, January 17, 2009

Another Voyage Through Eclipse

I spend a significant fraction of my working time staring at Eclipse. I fear that I'm a lifer. Even though rumors reach my ears that Netbeans has become usable, I just can't motivate myself to consider an alternative.

Some years back, I did some development in Eclipse. I was able to convince a client of ours that the best way to set up a linguistic workbench was Eclipse. We built a set of plugins. We submitted a raft of bug reports. Even a few patches. It worked. Sadly, the client decided that they preferred .NET, so off they went. Given the problems we had getting Arabic and Hebrew text to work right in Eclipse, and my recent discoveries, I'm not entirely sure that they were crazy.

All that is background. In the last week, I set out to build a simple tool for linguistic annotation. That is, display some text, and give the user very convenient, keyboard-based, tools to mark words.

I found http://www.vogella.de/articles/RichClientPlatform/article.html, which looked to be a good solution to the fact that the books can never keep up with the ongoing redesign.

And then the fun began.

The fundamental thing I wanted in my program was an editor. Historically, Eclipse editors have tended to be more entangled with the full IDE than other kinds of components. This problem turned out not to be solved in 3.4.

The turorial explains how to use the most recent Eclipse mechanisms for setting up the File menu and all of that. Unfortunately, the tutorial does not mention that as soon as you add an editor, the simple prescription fails.

To add an editor to an RCP application, you add an extension under org.eclipse.ui.editor. And, the next thing you know, you have a file menu, whether you want one or not. Before you can add the File Open that you want, you have to get rid of the old one. All this is complicated by the transition from 'actions' to commands. Under the 'new administration', things are supposed to be organized around commands, but there remains, not surprisingly, a mountain of code, examples, and documentation from the old universe.

Thankfully, a bit-o-googling revealed a recipe for this.

Next? Make Arabic look right.

When I last worked in this environment, the top of my lap was a Windows box. (I've since spent some time chained to a copy of Ubuntu and moved on to a Macbook Pro.) There were some problems with Arabic; the SWT people hadn't thought all that much about an application running with an overall English locale that needed to do a clean job of displaying some RTL text. However, we got reasonable results on Windows.

Mac OS X? Uh, oh. SWT, it seems, has some fundamental assumptions about how systems will support RTL languages. Even though RTL languages (in general) work fine on Mac OS, there is an impedance mismatch with SWT. Net result: there is no simple way to set up a StyledText component to display Arabic or Hebrew correctly. Luckily for me, I don't absolutely need this tool to look beautiful on MacO OS.

Analytics