Archive for the ‘Classic’ Category
Hard Drive Hygene: Downloads Zero November 24, 2009 | 11:54 am

I recently blew my computer away and re-built everything from scratch. IA lot of cruft had built up, and instead of trying to scour my computer, I just punted and started all over.

One of the things I’ve done is adopted a kind of “Downloads Zero” approach (akin to “Inbox Zero“): I had built up a lot of crap in the Downloads folder, and I had become afraid of what to throw away and what was important. This ate up a bunch of hard drive and was generally a source of low-grade anxiety that I didn’t need. So I’ve implemented a new plan: each I log into my computer, I wipe the Downloads folder completely. This means that if something’s important in Downloads, I have to consciously move it out of that folder and into someplace else. So far, it’s going great: there’s a surprisingly refreshing feeling when I see an empty Downloads folder!

To implement this on OS-X, create a folder named ~/logs and a file named ~/bin/cleanup_downloads.command with the following content:

name=cleanup_downloads
rm -PRf ~/Downloads/* 1> /dev/null 2> /dev/null

Then, in System Preferences > Accounts > Login Items, click the little + and select ~/bin/cleanup_downloads.command.

My question on Go November 22, 2009 | 11:27 pm

So, Google has released a new programming language, which turns out to be a slightly cleaned up version of Algol-68. While depressing, this doesn’t come as a large shock to me- if your prime requirement for a new language is that it doesn’t force you to learn something new, as it seems to be for most programmers, than the ability of the industry as a whole to move forward is limited at best. Radical advances require radical changes.

I’ve taken a couple of swings at writing about Go before this, but nothing stuck. Most everything I had to say I’ve said before, and when even I am bored with my ranting, it’s time to change the subject or shut up. But I’m left with one outstanding question I’d like an answer to, before I move to blissfully ignoring Go:

Why is it that still, today, it’s considered an advantage if not a requirement for a new language to be capable of writing an operating system?

Read the rest of this entry

Consumer-Developers and Contributor-Developers October 5, 2009 | 02:39 pm

Although my reputation is primarily tied to Grails, I straddle both the Ruby and JVM communities. Going to Ruby.MN kept me on the cutting edge: many ideas that surfaced in that context would hit the mainstream developer awareness about a year or two later, including CouchDB, polyglot programming, and behavior-driven development. For someone whose livelihood is based on knowing the cutting edge of technology, following the Ruby community is the way to go.

One of the unique things about the Ruby community is that they have positively no fear about diving into the bowels of the libraries they use. Partially, I think this is because of the borderline insanely dynamic nature of the Ruby language, which is why I satired that functionality in Ruby is the Future0. Whatever the reason, though, Ruby developers seem motivated to really explore and grok and push the boundaries of libraries, and that is awesome: that kind of adventuresome development drives new innovation and pushes people to become better developers.

0 If you read that April Fool’s Day post, be sure to read the follow-up at April Fails or April Fools Epic Win? On “Ruby is the Future”.

Leaving that context and going into the JVM environment, though, is some serious culture shock. Java developers have a conception that libraries are black boxes, and if you have to go reading into the library’s source, that means the library is in a certain sense broken. The idea is that the API of the library is the thing you should be coding to, not the implementation. Given that, reading the implementation is bad form, because all it can tell you is non-guarantied functionality which may well break in the next release of the library. Coding in a way that breaks your upgrade path is incurring technical debt, and therefore to be avoided if you want to stay agile/lean/whatever and be able to leverage the up-to-date library functionality.

Both of these approaches have dark sides, however. The Ruby approach encourages under-considered APIs and “works-in-my-case” libraries, which probably accounts somewhat for the Ruby community’s tendency to throw off a multitude of gems to solve the same general problem. The Java approach encourages a sense of helplessness if the library doesn’t work precisely as expected: since there is such an emotional barrier (not to mention technical difficulty) in cracking open the library, contributions to that library tend to come in the form of helpless, pleading bug reports.

Now, this portrayal of the distinct communities is obviously a gross generalization, but it is interesting to consider these alternative approaches to open source. Once upon a time, open source required a level engagement with the source which made all the users of a project de facto developers on that project. Now, though, many developers can consume an open source library without ever having to know anything about its inner workings. Not finding existing nomenclature, I’ve referred to these two different approaches as Contributor-Developers and Consumer-Developers1, respectively.

1 I dislike the terms users vs. devs for an open source project, although that’s one distinction that’s somewhat related. The issue is that “users” is an ambiguous term in open source projects: it’s easy to see the confusion with projects like WordPress, which have non-technical end users, middle-tier consumer-developers, and contributor-developers. The “devs” side is blurred on projects like Grails and Rails, where the innards of the system are wide open and there is an expectation that anyone but the most novice users will be comfortable taking a look.

There’s a tendency among some open source enthusiasts to try to blur this distinction—to say that even consumer-developers are contributing in a sense, because their helpless and pleading feedback is at least some feedback, and therefore positive for the project as a whole. While it’s true consumer-developers are contributing to the product when they provide useful feedback, there’s a more fundamental difference in approach which needs to be respected. Consumer-developers and contributor-developers have different understandings of what open source is, and therefore they expect different things out of their open source library.

To the consumer-developer, open source is a solution to a problem. It’s a product. This kind of mindset is demonstrated by Burt Beckwith’s “Free Toilet” response2. You can really hear the voice of the consumer-developer mindset in these snippets:

We use or buy it because we don’t want to, don’t have the time to, or can’t implement it ourselves. It’s disingenuous and selfish to claim that since you gave it away for free, you have no further obligations unless that’s made explicit from the beginning.

I’ve talked to other Grails users about writing and supporting Grails plugins and I half-jokingly caution them to not release them. It’s work. It’s a product.

Another Grails plugin developer who has been rather prolific (although not so much lately) stated with the release of a couple of his plugins that he wouldn’t be doing any further work on them. I’m fine with that – it’s honest. It’s somewhat annoying – support yer damn product

2 Here’s the original “Free Toilet” post, and my response to Burt’s post.

If you are developing open source software for consumer-developers, you are committing to providing a high degree of polish, documentation, and support, and you can’t expect to get help. Note that right of the bat, Burt equates software usage with “use it” and “buy it”, and that’s the key idea: you are a vendor, and the users are your customers, so the flow of work is basically unidirectional. That’s taking a lot on yourself, but these projects are the ones that get the widest adoption because they have the lowest barrier to entry, and so if you are developing open source because you want to improve your reputation or get the warm-fuzzy of being an altruistic3 contributor to other people’s success, then this is your target audience. And if this is your target audience, you shouldn’t release a project unless it is already fully polished and if you’re willing to make maintaining it your hobby.

3 Read: “uncompensated”

Developing for contributor-developers, however, is different. When you develop for contributor-developers, you’re just sharing code. You’re saying, “Hey, here’s a hunk of my code which is tangential to the business logic of the project. If you find it useful, feel free to use it.” This was the conception behind JConch and GORM Labs and all my CPAN stuff. None of these solve a particular problem, but they contain tricky code in a related topic area.

The important thing to realize is that sharing code is a substantially more limited relationship than providing a solution: if you are sharing code, you’re simply saving development time and providing a way for people to model future code. Since cracking open the codebase is expected, extending it and contributing to it is also something’s that is expected. Conversations among contributor-developers about how and why things work should be standard, whereas the consumer-developer is only going to be interested in what APIs are provided and when extension/fixes will be ready.

When I wrote the “Free Toilet” post, I was partially responding to the culture shock of contributing to perl’s CPAN and being engaged in Ruby’s gems: when I got involved in Grails and started contributing, I expected it to be more akin to Rails, but I was instead getting flak for providing an under-polished product. I thought I was contributing code to a communal pool, and then being faulted for not contributing enough into that pool. It struck me like I was putting stuff out there for fun, but getting nothing back except feedback saying I wasn’t doing enough or not doing it right or whatever. What I was really being told was that I was trying to establish a contributor-developer relationship with a consumer-developer community, and that dissonance left both sides feeling slighted.

Now, I’m not here to say matter-of-factly that the contributor-developer approach is the only one that’s valuable: I am a consumer-developer of postgres, Open Office, Linux, GMP, Felix, Apache Commons, and a variety of other open source projects, and so it would be wildly hypocritical of me to knock that approach. But it is important to have space for the contributor-developer open source projects, because that approach saves developers a lot of time and the low barrier to entry brings out a lot of open source contributions which might later evolve into more product-style offerings. Consumer-developer projects may be where the adoption is, but the innovation is in contributor-developer projects.

Ruby Can’t Be Parsed? August 17, 2009 | 09:02 am

Is this valid Ruby code? (Syntax highlighting skipped because it obscures the point.)

whatever  / 25 ; # / ; raise SystemExit.new;

Is it possible for whatever‘s arity to be either zero or one arguments, and unknown at the point when it’s parsed? (Pretty sure this is “yes”: after all, Ruby has to parse the code assuming that whatever may be added at runtime. If it’s added at runtime, it may be given an arity equal to the next bit off /dev/random.)

[EDIT: See the comments for extensive conversation on what’s going on with Ruby.]

If so, then parsing Ruby is equivalent to solving the halting problem. The proof is the same as Perl Cannot Be Parsed: A Formal Proof, with appropriate translation of the code. Notably, this proof is thwarted by the use of perl prototypes (unless you have optional arguments): more on prototypes at A Defense of Prototypes, or, Why Does Tom Christiansen Hate Perl?.

Groovy avoids it purely accidentally: since the comment character in Groovy always begins with a right slash (/), there’s no way to sneak the comment character into the regex.

“What is a BarCamp?”, Featuring BarCampRDU 2009 August 11, 2009 | 05:49 pm

The newest podcast episode: an introduction to BarCamps.

This podcast explains what a BarCamp-style conference is and how it works (at least, how BarCampRDU works), and then goes through the sessions that were pitched. There was a lot of feedback from BarCampRDU that centered around nervousness or confusion about pitches: people thought they had to do something ahead of time or have a pre-rehearsed presentation or be an expert in the field in order to make a pitch. And some people just didn’t get it until it was too late. I really hate hearing, “I would have made a pitch, but I wasn’t sure how to.”

So I created this podcast, which goes through BarCampRDU’s pitch process and then runs through the pitches that were made at BarCampRDU 2009. It features Matt Frye and Tanner Lovelace as unwitting co-hosts, and background music from Durham’s own Permanent4 (a.k.a. Dave of Dave’s Lounge, which I love).

Hopefully this helps people make sense of what’s going on and gets more people involved next year.

A Failure of Understanding August 9, 2009 | 09:00 am

I just stumbled across a link to an article which made me cry a little bit. The article is The Start-Ups We Don’t Need, and basically argues that start-ups aren’t beneficial to the economy. It’s written by a Professor of Entrepreneurial Studies at Case Western, but it’s just…bad. Read the rest of this entry

We Aren’t Too Stupid for Polyglot Programming August 7, 2009 | 09:00 am

As those who listened to my WebDev Radio interview know, I am working on a book on polyglot programming. This has me asking smart people what they think about polyglot programming, and one of the most surprising pieces of feedback I’ve gotten (from Grails podcast, among others) is that polyglot programming is somehow “too hard”: that developers aren’t smart enough to handle it. This strikes me as an odd complaint.Bible Polyglot

Polyglot programming, defined most simply, is the use of multiple languages in software development. Although Neal Ford claims to have “accidentally coined” the term, the term predates Neal Ford’s Dec 2006 blog entry: for evidence, see a 2002 Dr. Dobbs article on .Net polyglotism, and a 2004 DARPA presentation on the Babel polyglot support system, which has whitepapers dating back to 1998. So the term itself has been around for a while.

The idea that underlies the term has been around in some form or another since C became the Universal Assembly Language: interoperability with C has always been critical for projects like mod_* (perl, php, rails, caml), which bring non-C code into the Apache web server. Now we’re rediscovering interoperability by having languages interoperate on the JVM. This opens up a new freedom to pick the right language to solve the problem at hand for Java development.

The reality, though, is that we all do polyglot programming all the time. Read the rest of this entry

Open Letter to Burt Beckwith August 4, 2009 | 10:14 am

Burt Beckwith, one of the major contributors to the Groovy/Grails community, posted a rather serious critique to my Dear User of My Open Source Project post. It’s definitely worth a read. Although I didn’t see it (I haven’t read any RSS feeds since starting my next book), the post was good enough that the Grails podcast picked it up, and I found my way over to it through their show notes.

Since he’s apparently not even deigning to link to the post or call me out by name (maybe he’s trying to be nice, maybe he’s trying to keep the Google juice from flowing my direction, maybe he’s trying to be sneaky, whatever), I figured I would post a response here instead of there. Read the rest of this entry

Dear User of My Open Source Project July 24, 2009 | 09:25 am

NOTE: See Consumer-Developers and Contributor-Developers for a more carefully thought out exploration of the problem underlying this post.


I fear there’s been a misunderstanding.

Judging from your comment, I see that you [read my email/looked at my source code/downloaded my library]. I’m glad to hear you’ve taken an interest in what I’m doing: it means that I’m probably doing something interesting or useful, which is good. But the [demand for a fix/unconstructive feedback/derogatory discouragement/flame] you sent me implies that you don’t really get our relationship. Read the rest of this entry

The @WithLog Annotation and Groovy ASTTransforms July 23, 2009 | 05:47 pm

I’ve just released a @WithLog annotation to GitHub under RobertFischer/Groovy-WithLog. The goal of @WithLog is to reduce the boilerplate associated with using Log4J.

Normally, using Log4J looks like this:

import org.apache.log4j.Logger
 
class Foo { 
  static log = Logger.getLogger(Foo)
  /* ... */
}

I’ve now said Logger three times and my class name twice. And there’s absolutely no useful value to having it clogging up the body of my class. This burns my eyes, and needs to stop. Read the rest of this entry