Tuesday, May 26, 2009

My vimrc, Let Me Show You It

Short but sweet...

syntax on
set wildmode=list:longest,full
set autoindent
nnoremap :bnext
nnoremap :bprevious
set number
set guifont=Anonymous:h9:cANSI
set ts=4



The "set guifont" is for gVim. Anonymous is a nice, free programming font.

"Bing"?

Microsoft has announced that the name of their latest-iteration of search is going to be named "Bing".

I get it. Search is important. Of all the different things you can do online, search is probably the most lucrative, directly and indirectly.

I'm sure a lot of thought went into the name. It's catchy, has a good vibe, without actually meaning anything. Of course, it won't work. People will go to Google for the same reasons they have been. It hasn't let them down. It is predictable. It isn't perfect, but people are used to the imperfections, and work around them.

No, Microsoft, you actually have to do a magnitude better than Google to take over search. Look at the effort put into trying to push Microsoft off the desktop. Tons. After spending millions of dollars and man-hours, between Apple and the OSS community, they've shaved off a few percentage points of the desktop share.

Google does a lot of things: gmail (for domains, even), this site, search, photo sharing. A whole bunch of stuff, but it doesn't work together all that well. Didn't Microsoft get in trouble for trying to make stuff work well together just a little too well? What happened to that attitude?

Maybe this time is different. Heh.

What makes this worse is that if/when it fails, it will reinforce the belief that Microsoft is in its waning years. That could easily become a self-fulfilling prophecy.

Sunday, May 24, 2009

Git Workflow For Agile Teams (link)

ReinH has a nice long post detailing the way they use git in their workflow.

Wednesday, May 20, 2009

Shortcuts are Debt

A theme that you'll hear me spouting (and sometimes see me ignoring) is that shortcuts are dangerous. It is hard to convey that, so I keep trying to find new ways to express it.

My latest is that taking a shortcut - whether designing, implementing, maintaining, or troubleshooting an app - is the same as incurring debt.

It's certainly okay to have debt. Houses and cars would be much harder without debt. There's nothing wrong with having some on your credit card, either.

Just as long as it doesn't get out of hand.

Sure, rebooting the server may solve the problem for now, but that isn't a solution, that's a fix. If it is a quick way to get things going, okay. That doesn't mean you're done - you've acquired some debt. There's a chance it will "go away" (rebooting the server is like borrowing $20 from a friend - you may both forget), but you'll probably have to pay it back.

Just like monetary debt, it is better to control when it is paid, rather than wait for the bill collector. Reboot the server tonight, go through the logs tomorrow. That's fair, and you're doing what you should've done to begin with, in a timely manner.

I'm using the very trivial example of rebooting, but that goes for a lot in IT. A developer may take a syntatic shortcut to get the product out the door, but time should be allotted to repair that shortcut - don't wait for it to crop back up.

In summary, I'm not against taking shortcuts, but they should be tracked as bugs, just like anything else. The bug database acts as a "balance sheet", and it should reflect all debts.

Open Source and the Enterprise - Invest in the Community

When open source software is talked up in the enterprise, one of the debates falls along these lines:

"Open source is free - no licensing costs"
"But there's no support, either"
"The mailing list and forums are very active"
"We don't have a way to make them help us"
"Our vendor support sucks"
"So does your momma"

The support question, i.e., how to get quality support for an open source application, is a valid question. Sure, the source is available, but then you have to ramp up on the source, and if you modify it, managing a fork.

It is true that the quality of support for any application, proprietary or open source, is uneven. You really don't know what you're going to get. The "nice" thing about proprietary software is that there is has been a readily quantifiable measurement for how effective the support "should" be: how much you are paying.

With some exceptions, the open source model doesn't offer the same so-called assurance. In typical enterprise binary fashion, since you can't pay for support, support isn't available.

The misconception for open source first-timers is that they should be able to post to a mailing list, and get a good reply. Heh. Let's just say that first impressions can be varied.

Support in the open source world isn't purchased with money, it is purchased with credibility. For a large chunk of the open source world, it is very much about community, and credibility is the only currency that any community respects.

There's a flip side to support for proprietary software, too. Once you stop paying for support, you stop getting it, just as quickly. The investment in a community is cumulative and durable; the more you participate, the more you benefit, and the longer you benefit. Look at IBM: from considered as evil as Microsoft to "not so bad".

Contributers to open source projects get more respect from the community. This doesn't necessarily mean contributing source, although that is significant. Writing documentation, being an active helper in the forums, contributing hardware, and outright donations are all valid means of building one's reputation.

It doesn't even need to be for the same project for which you are asking help. The more active your organization is the overall community, the more credibility you have across open source projects.

The hard part about this is that there's no real faking it. You can buy immediate attention from a community, but maximum effectiveness requires regular participation over time. Not just the big things, the little things. You really have to be a part of the community for the community to be effective.

Okay, so how should your typical enterprise go about this?

Well, first commit to a long-time goal, and recognize from the very beginning that the effect will be hard to quantify. It is a lot like marketing, and in fact, it may be appropriate to involve marketing (but not too much).

Pick an open source project in which to participate. The size of the project doesn't matter, although there will be an optimum proportion of project size and influence within that project (if you can make major contributions to the Linux kernel, the payoff is significant). Better yet, take over a "stale", but still useful project.

Hire somebody to act as the "face" of your company. It isn't enough to say that "Bob will take care of it in his spare time", it has to be part of the job description. If there isn't much going on, it would be "Bob's" job to make something happen. They should be able to write to a technical audience.

Then, participate! Actually participate, no fakeys. Treat the members of the project as what they are: a part of your world. You may not control them, but that isn't necessary for them to contribute to your own success.

Thursday, May 14, 2009

The Future of DRM - Flexibility

I was just over at Slashdot, reading the usual bitching and moaning about DRM, this time about something that may or may not be going on with Amazon's Kindle. The hubbub revolves around the text-to-speech function of the Kindle, and Amazon's ability to disable it on a book-by-book basis.

The summary speculates
But what no one at Amazon will discuss is what other flags are lurking in the Kindle format: is there a "read only once" flag? A "no turning the pages backwards" flag?"
Maybe there is, maybe there isn't. The only problem I have with this is that it isn't transparent enough. If I can pay less for something that I will only read once, a "read once" flag seems like a pretty good idea.

To me, that's the crux of it. I don't think I really differ from Joe Average in this regard. If I know what I am buying, and I think it is a good deal, then I'll buy it. Once I've bought it, the rules shouldn't be changed - if I purchase a Kindle book with any reason to believe that text to speech will work for that title, then it should work.

As awareness of DRM and the consequences increases, people will simply adjust their expectations, and their consumption patterns will follow. iTunes showed this quite well. Apple has started providing non-protected music, but they haven't tried offering protected music at very reduced rates, either. Tracks for 10 cents, or even free? Why not?

Assuming that the media companies got their heads out of their collective asses (ha!), what would people pay with what kind of restrictions? $1 for unprotected, reasonable quality is the standard right now. How about five cents for a high quality track bound to one device? Fifty cents for a track you can play on one device at a time (transfer the license)? Hell, if I could buy a player pre-loaded with my music, built from a list of licenses I own, that's a value-add.

It is to the media companies' detriment that they are handling this so poorly, and creating so many bad experiences for the early adopters who might not have otherwise cared. They're further shooting themselves in as many feet as they have by worrying too much about whether DRM can be broken. They should be watching people who go through the trouble of hacking it, and seeing what is done with it. That's free marketing research, tons of it. Take those ideas, package them up in an easy-to-use package, and sell it to everyone else.

From an IT perspective, oh yea it's coming (already here, in some places). Count on it. I've spent too much of my life putting permissions on files to believe that DRM won't be eventually be pervasive. I wouldn't be surprised if that bled over into the consumer market: "Your email can't be forwarded" is pretty compelling.

The timeline for all of this? Beats me. I'm just a goon.