Google Reader Reader Robot

How about a project that downloads your unread feeds from Google Reader, uses a speech synthesis program to convert them to mp3, adds the mp3s to a podcast server, which you then script to sync to your portable device? Then you can listen to all of your news on the way to work, as read by your choice of a feminine or masculine robot.

If you like that one, wait until you hear about my idea for Google Reader Printer for my poor friends that have no internet connection at their desks.

Hopefully someone else is working on a good Podcast transcriber, like Podzinger. Once there is a great speech to text solution, I can come up with a convoluted name for that.

Okay, these are lame ideas, but someone's got to pick up for that Techquila Shots guy.

Reporting and OR/M

Just an off the cuff thought about using Object Relational Mapping (Hibernate, TopLink, ActiveRecord, etc.) when doing reporting: Does it make sense to have objects corresponding to specific reports that result in denormalized data, so as to hold the results of the query? It makes it a little more sense if you have a view corresponding to the report, and then a object corresponding to the view. At some point it does seem to cross a line of excessive abstraction and an overgrown data model.

Simple

I think this is the route I am going to go when I have to do another Java web application. I have become improbably enamored with horizontal scalability. The primary downside is that they started using xml configuration files. Curse you XML configuration. The XML config is just there to compensate for the lack of dynamic language features...

Seriously though- the old way of building Java web applications is seriously threatened by the latest .Net stuff on one side, and the dynamic language stuff on the other side. I think the .Net 3.0 is not helping much on the complexity angle.

It makes me laugh to think how much the REST architecture resembles the Java Servlet Spec. All of these frameworks to abstract away HTTP verbs, when that was what really needed to have application structures that are concordant with the architecture of the web itself.

Ruby Community

I don't know who "Dan" is, but I like the way he rolls.

"I have no idea what the "Ruby Community" is. How do you define
membership in this community?"

No, no, the "Java Community" has a defined static membership, but the
"Ruby Community" is more dynamic. As long as you respond to the right
messages, you're just assumed to be a member.

Productivity tip?

I am considering switching back to using Lynx as my primary browser. My theory is that it makes the web so much less compelling that I won't be as distracted by it. Slightly easier in terms of keyboard navigation so I don't have to touch the mouse. Runs great in cygwin too. The biggest downside I am seeing so far is that Google Maps doesn't run very well.

I don't see them doing much to fix that. Oh well, back to 9 tabs of FireFox I suppose. Apologies for the mind drip.

Language Games

I've been following with great interest Jeff Atwood's series of posts on Alistair Cockburn's work on software development as a cooperative game.

I was wondering if he was going to dig down to the philosophy level on this, and he may, but this concept of the cooperative game is an extension of Wittgenstein's concept of language games, first outlined by Pelle Ehn. Reading Wittgenstein, more than anything else, really opened my mind to an incisive type of analysis that attempts to dissolve a seemingly unanswerable question by proving that it is nonsensical out of the context of the particular language game that gives it sense.

The digression between the purported "process" that underlies a project and the actual intuitive set of rules that guide the behavior of and between individuals are clearly different things. It's obviously important to pay attention to both. This is why Cockburn's approach to agile "method shaping" is so important, every strict process must itself have a meta process by which it is applied to any particular collection of individuals.

I really like Alistair's interview with Bob Payne (especially the parts where Mr. Cockburn is speaking) on the Agile Toolkit podcast.

Mingle- ThoughtWorks hotness?

Wow, the high priced consultants @ ThoughtWorks have broken into commercial product development. This is going to be interesting.

Mingle is apparently an agile project management tool. We've looked at VersionOne and Rally in that space (not to mention Team Foundation Server), but we're actually using Trac, which is hard to beat for the svn integration and price. I wonder how how much this pup is going to cost?

Communication Cost

Just caught this great post from Lisa Haneberg that echoes some ideas I have had in the past, like a running clock that shows the running total cost of a meeting as it "progresses".

Top level costs: the cost of time for people to receive (hear, read) the communication and the cost for creating/delivering communication. If you send an email to your entire team of 50 people. And if the email takes 3 minutes to read, and 15 minutes for you to write - the top level costs are of people's salaries for the 3 minutes and your 15 minutes. Plus the costs of the email server time and space, etc... But the time is the largest cost. You may think this is a small amount, but multiply this times 100s of emails we deal with each day, and the costs add up.

If you book a two hour meeting with 15 people - the top level costs are huge.

But that's the just start of the costs. There are two other important types of costs...

I have thought about this in terms of meetings quite a bit. I've had lots of extremely expensive meetings to sit through. Meetings where our tax dollars were being consumed at unhealthy rates. Now, there are the people where having them in a meeting is actually more productive than having them cause damage through their other work, but it's hardly the optimal solution. However, applying this thought to email and phone calls is interesting.

Think before you send...I've been doing the whole "Inbox Zero" thing. It's really great that I don't have a huge unprocessed morass of email to look at it. I do have to get better about keeping up with my todo lists though. It's still easier for me to forget those because I don't have a blinking light telling me to look at them every time a new one shows up. Maybe it's not as fun to look at, because, unlike email, I already kind of know what is on my todo lists.

Jeffrey Veen and Merlin Mann were talking about how Google is a no phone call culture to some degree, everything is email, IM, with a definite preference for the asynchronous communication. Not sure how much of that is introvert culture and how much is efficiency, but it sounded like they were positively bombarded with email information there.

Maybe there is a real economic benefit to parsimonious communication, learning to be clear concise and brief saves money. Maybe this should apply to bloggers as well, I know there are people out there struggling to keep up with their feeds...on that note, I'll be signing off.

Treat Contractors Well (please)

I like this post from Scott Berkun. (of the Art of PM book)

One habits many managers have is to dump the boring, unpleasant work of their team onto contract workers. The thinking is that full timers deserve the best treatment and contractors are mercenaries: they deserve whatever they get since they won’t be around long.

It’s a mistake - good managers finds a way to treat everyone well. And there are some reasons contractors deserve special attention

I don't think it applies 100% to government contracting, but it does make a lot of sense. Please treat my team well government overlords!

Wiki Patterns

I have been trying to get a good collaborative space set up for my company forever now. It just has never risen up high enough in the priority chain to really become a collaborative effort...although I have had some very good support from a couple of people that really get it.

Anyway, I happened across this link to Atlassian's wikipatterns site at Web Worker Daily. So far it's a pretty basic set of patterns, but I plan on adding a few of my notes.

Here are some random things that I think are decent ideas for a making a wiki well used with the audiences I have been dealing with.

1) WYSIWYG editing. Most people don't want to learn a markup langauage. It really lowers the barrier to creative usage.
2) Make it the authoritative source. No one wants to look at or update data that might be wrong, if there is another place where it is definitely right. If the wiki isn't the authoritative source, link the other content in, don't make copies that will get out of sync.
3) Fun stuff. It's absolutely worth having a few pages where people can post silly stuff when they feel frustrated.
4) RSS Feeds or change summaries. Crucial if you are using it for anything new-sy, as opposed to reference.

I have set up MediaWiki and many others. MediaWiki looks like a really ugly piece of code. I had problems with it on some customer networks with strange proxy behavior. Instiki and most of the Ruby on Rails wikis are missing crucial features- like security models. I actually like the Trac wiki for development projects, even though the wiki isn't really the crucial feature. I am extremely disappointed Google snapped up JotSpot right as they were about to release a self-hosted version. As convenient as Software as a Service things like Blogger are, I just would easily prefer hosting the app myself. JotSpot, while also being vastly more than a wiki, really benefits from being the engine behind dojo.js development. Dojo is a great ajax lib, and makes Jot cool.

I never thought the Atlassian Confluence stuff was worth the price, but the patterns site is a good idea. In fact, I suppose that was the origin of the wiki concept in the first place, Ward Cunningham's c2 wiki for the portland patterns group is still the canonical example. How far we haven't come: web 2.0 v. Web 1995.