Nelz' Blog

Ruminations on Development


Main | Next page »
Wednesday May 14, 2008

GMail has MUTE!

Thanks to my fantastic girlfriend, I now know an awesome trick!

If there is a threaded discussion in GMail that you want to stop hearing from (think flamewars, or a specific discussion you are not interested in on some list that you usually do want to follow...), you can "mute" that discussion. (Supposedly, if you are directly addressed in this thread, it will still deliver the message. S-M-A-R-T!)

There are keyboard nav bindings for it, but I know it is also in the "More Actions" dropdown box at the top of the screen.

What a GREAT feature! It has been saving my attention span immeasurably today!

GIT on Leopard

I had to install the 'git' utility on my OS X (Leopard) box.

I found this blog post to be really helpful... (I just copied and pasted the command-line script, and it just ran and installed fine!)

Compiling Git for Mac OS X Leopard (10.5)

Tuesday May 13, 2008

Revelation of the Day

This revelation hit me (and my coworkers) today: Caching is a cross-cutting concern...

You many not understand the implications of that phrase, but it leads to some interesting stuff...

Monday May 12, 2008

JavaDocWiki

I had this idea a while ago, but it popped back up into my brain when working on my "Participation Culture" entry...

In the past I have felt that JavaDoc is just too... one-way.

The format is great as a one-way, generated-from-code outlet for programmers... But this ignores the benefits of the population at large. If some people spend their free time working on entirely new frameworks, I'm sure there's a larger section of people who are willing to share in the enrichment of the documentation as well.

So, why not change the one-way broadcast to a two-way conversation?

My original thought was to have a JavaDocWiki site, where I'd enable some type of processing against a given JavaDoc set. This processing would decorate the pages with whatever 'dashboards' would be helpful, and links to an interactive Wiki-stle page for each class/method/variable...

But, the fault with this course of action is that the interactivity is at a brand new site. Yes, this site could still serve the basic documentation needs just as well as the originating sites, but it would still be a whole new site that people would have to reference.

I got to thinking... Why not just 'decorate' the original source files?

Maybe a GreaseMonkey script would be able to decorate the original source codes, slurping in the interactive dashboards and linking out to a host site for the interactive elements? (I haven't audited GreaseMonkey≈'s capabilities to see if this is even possible yet, but it offers some intriguing possibilities...)

I guess in either case you would end up depending on host sites for the interactive bits, and you might end up with a busy ecosystem of different hosts being the 'authority' for different versions or sections of the code. Another concern would be migrating from version to version.

Ideally the documentation would end up with high enough quality that the original source developers would be able to slurp up the added doc for inclusion in the actual source code.

I also think this model might work for other auto-generated code documentation. Example: RDoc.

UPDATE (16 May 2008): It turns out, someone else had this idea too. Check out JDocs.com.

Sunday May 11, 2008

Participation Culture

Gin, Television, and Social Surplus

WOW! This article is fantastic! I was so psyched after reading this article that I even sent it to my Luddite-ish mother. (After printing the article out and reading it, she said it was 'cute' and reminded her of me... <sigh!>)

I have so much to say about this article, it will probably come out all jumbled... But I hope the reader will be able to pull out some salient points.

Participation

In the vein of where I am going with my ruminations I had actually named this blog post "Participation Culture" before re-reading the article and seeing that "Tim" (O'Reilly, I'm assuming.) has some concept called an "architecture of participation".

Participation has been a big theme in my life in recent years. About 6 year ago I fell in with the Burning Man community, whose 10 Principles specifically address participation as a founding pillar. A little over a year ago, I came to the Bay Area and was immediately impressed by all the Makers, teachers, and BarCampers. (As I write this, I am impressed that I continually fall in love with ideas that are only a degree or two away from Tim O'Reilly...)

History of the Participatory Audience

While reading the "Gin, Television, and Social Surplus" article, you might be lulled into thinking that audience's radical demand for participation' is an artifact of recent past. Then I got to thinking about the history of our culture's move towards encouraging participation and how little bits of interactivity have made themselves known before the current incarnation of internet culture.

Yeah, I agree magicians have been pulling people up on stage forever, but this doesn't count. These types of stage shows are more of an exercise in social engineering than in interactivity.

But, think back to the late-70's. There was a very persistent subsection of our culture who were not willing to sit back and passively watch a show. These people, considered "crazy" by some, would don fishnets and garters and high heels and feather boas to go to a theater to throw bread and yell at the screen and sing along to the music, and some of these people even tromped right up to the front of the theaters to re-enacted exactly what was happening up on the screen at the exact same time. There were, and still are, entire communities built around the pomp and circumstance of late-night showings of "The Rocky Horror Picture Show".

It tickles me pink that Dr. Frankenfurter, the "sweet transvestite from transsexual Transylvania", could be a material ancestor for every tweet I Twitter or every Yelp review I post in this "participatory internet".


Epilogue

The Dr. Frankenfurter bit from above is about where I wanted to end up for this post. However, in writing it, I came up with a couple more links for events or shows that I think are incredibly relevant to the article above or to the rest of this post.

One of the first shows I ever saw that took a fun step out of the passive-audience experience was the Blue Man Group. My family went to one of their shows in Boston during Christmas time, and I was blown away! At the end of the show, they start unrolling streamers off of toilet paper rollers, covering the audience, getting them to move the streamers forward while strobe lights flash and loudly blaring techno music surrounds you. You are covered and involved in a moving black-lit sea of white streamer paper. I have a distinct memory of jamming out in my seat, looking to my right with the biggest grin on my face and seeing my grandmother get all tangled up in the streamers as they were moving forward. It was a sensory overload, but still one of my most fun memories from my teen years.

I dabbled a little bit in Dungeons and Dragons but it never really 'stuck' with me. However, I don't think anyone can debate that it totally serves as the ancestor of the phenomenon described in the above article as 'sitting in your basement and pretending to be an elf'.

Since I've been in San Francisco, I have totally fallen in love with The Extra-Action Marching Band. Though the Blue Man Group involves the audience at the end of the show, Extra-Action not only breaks, but DEMOLISHES the fourth wall. Through an incredible alchemy of sounds, sweat, and audacity they involve the audience as an integral part of the show. (Disclaimer: not for the claustrophobic.) To friends, I have described the experience of being right up in the front row as being in a mosh pit without any of the anger.

Tomcat ROOT Context

I've been fighting with Tomcat a bunch this week.

My specific challenges have been around configuring a webapp to have the context root of "/", without having to name it ROOT.war...

The documentation page on context configuration says that "Context elements may be explicitly defined":

  • in the $CATALINA_HOME/conf/context.xml file- the Context element information will be loaded by all webapps
  • in the $CATALINA_HOME/conf/[enginename]/[hostname]/context.xml.default file- the Context element information will be loaded by all webapps of that host
  • in individual files (with a .xml extension) in the $CATALINA_HOME/conf/[enginename]/[hostname]/ directory. The name of the file (less the .xml) extension will be used as the context path. Multi-level context paths may be defined using #, e.g. context#path.xml. The default web application may be defined by using a file called ROOT.xml.
  • if the previous file was not found for this application, in an individual file at /META-INF/context.xml inside the application files
  • inside a Host element in the main conf/server.xml

In my experience this week, the option of creating the file $CATALINA_HOME/conf/[enginename]/[hostname]/ROOT.xml didn't work for me.

But, one of my coworkers (Chris) found some other resource somewhere that said you could create a $CATALINA_HOME/webapps/ROOT.xml that looked like this:

<?xml version='1.0' encoding='utf-8'?>
<Context docBase="/absolute/path/to/your/webapp/dir">
</Context>

Chris tried this setup, and it seemed to work for him. Here's my caveats:

  1. I haven't verified this myself yet.
  2. I'm not sure if it has to be an exploded WAR file structure, or if it can be a WAR file itself.

I will update if I find that this actually does work.

Burn My Brain

Well, it has been a week or so since I've posted anything to this blog. My excuse is that I've been moving and haven't had time to post anything.

But, over the past day or two, I've had a couple of these ideas burning my brain a bit, keeping me up a bit as well.

I'll throw out the caveat that I haven't done *any* research on these ideas to see if they already have implementations... But, I'll throw them out as my own ideas anyways.

Calendar-Oriented Natural Language Parsing

It occurred to me that it would be a cool project to create an open-source library that would do the same (or similar) natural language parsing that Google Calendar does.

If you're not familiar with it, Google Calendar's parsing is pretty cool. You can type in "tomorrow 10am call mom" and you'll get an entry in your calendar for the current day plus 1 at 10AM that says "call mom". I believe it even does things like "next Wed" and "tonight" and "4 to 6 pm".

Creating a free library to do this kind of parsing would be cool, if it doesn't already exist.

Twitter 4 Roller

As you can see, I am using Roller hosted on my own site for this blog. I think it would be fun to develop a plugin for Roller that would enable the system to automatically post a title and a URL to a specified Twitter account when a post is published. I also think a similar thing for other blogging platforms would be cool as well.

JavaScript Animation Platform

I object to monopolies in computing on general principle. I didn't like MicroSoft's stranglehold in the past, and I'm uncomfortable with the Adobe/Flash monopoly on 'rich media' going forward. (Sorry, I was unable to find the blog post that got me thinking about this a couple of months ago...)

After seeing Ned Batchelder's animation of Román Cortés' CSS Homer I got to thinking that someone could probably write some kind of suite that would spit out open-standards-compliant CSS and JavaScript that could achieve some of the basic functionalities that Flash presents.

I do think this would probably stretch the capabilities of these browser technologies, but stretching capabilities has an interesting habit of expanding possibilities when it gets into the spotlight. (I am specifically thinking of the JavaScript evolving into AJAX phenomenon... I had avoided JavaScript like the plague for many years, only to have it come out on top as a hugely functional way to change the post-update-get paradigm of the web.)

Thursday May 01, 2008

Quick One - Documentation Answers

As an update to one of my previous posts...

In the Spring documentation, I found the following in "3.9. Glue code and the evil singleton": "... the preferred approach when there is only one web-app (WAR) in the top hierarchy is to simply create one composite Spring IoC container from the multiple XML definition files from each layer"

The documentation was there, but I guess I was using conflicting language when searching for the answer.

Wednesday Apr 30, 2008

Helpful Maven Command: "mvn dependency:tree"

Sometimes you need to peruse the dependencies (and transitive dependencies) within your Maven project. The "mvn site" command generates a pretty nice version of this in HTML. (Example: Jetty Maven Plugin - Depenencies Report.)

Well, the good news is that you don't need to go through the whole "mvn site" generation to find out this information, as the "dependency" plugin can provide this information to you via the command-line.

% mvn dependency:tree

Here is (a part) of the output from one of the projects I'm working on:

[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'dependency'.
[INFO] ------------------------------------------------------------------------
[INFO] Building SomeCompany :: Main Webapp
[INFO]    task-segment: [dependency:tree]
[INFO] ------------------------------------------------------------------------
[INFO] [dependency:tree]
[INFO] com.somecompany:somecompany:war:1.0-SNAPSHOT
[INFO] +- com.somecompany:backend:jar:1.0-SNAPSHOT:compile
[INFO] |  +- mysql:mysql-connector-java:jar:5.0.4:runtime
[INFO] |  +- antlr:antlr:jar:2.7.6:compile
[INFO] |  +- commons-codec:commons-codec:jar:1.3:compile
[INFO] |  +- commons-dbcp:commons-dbcp:jar:1.2.1:compile
[INFO] |  |  \- xml-apis:xml-apis:jar:1.0.b2:compile
[INFO] |  +- commons-httpclient:commons-httpclient:jar:3.0:compile
[INFO] |  |  \- junit:junit:jar:3.8.1:compile
[INFO] |  +- commons-lang:commons-lang:jar:2.3:compile
[INFO] |  +- commons-logging:commons-logging:jar:1.0.4:compile
[INFO] |  +- commons-pool:commons-pool:jar:1.3:compile
[INFO] |  +- dom4j:dom4j:jar:1.6:compile
[INFO] |  +- net.sf.ehcache:ehcache:jar:1.4.0:compile
[INFO] |  |  +- net.sf.jsr107cache:jsr107cache:jar:1.0:compile
[INFO] |  |  \- backport-util-concurrent:backport-util-concurrent:jar:3.1:compile
[INFO] |  +- org.hibernate:hibernate-annotations:jar:3.2.0.ga:compile
[INFO] |  |  +- org.hibernate:hibernate:jar:3.2.0.ga:compile
[INFO] |  |  |  +- javax.transaction:jta:jar:1.0.1B:compile
[INFO] |  |  |  +- asm:asm-attrs:jar:1.5.3:compile
[INFO] |  |  |  +- cglib:cglib:jar:2.1_3:compile
[INFO] |  |  |  \- asm:asm:jar:1.5.3:compile
[INFO] |  |  \- javax.persistence:persistence-api:jar:1.0:compile
[INFO] |  +- jdom:jdom:jar:1.0:compile
[INFO] |  +- ognl:ognl:jar:2.6.7:compile
[INFO] |  +- rome:rome:jar:0.9:compile
[INFO] |  +- org.springframework:spring:jar:1.2.7:compile
[INFO] |  +- net.sourceforge.stripes:stripes:jar:1.4.3:compile
[INFO] |  +- velocity:velocity:jar:1.5:compile
[INFO] |  |  \- oro:oro:jar:2.0.8:compile
[INFO] |  +- org.json:json:jar:20070829:compile
[INFO] |  +- org.htmlparser:htmlparser:jar:1.6:compile
[INFO] |  +- javax.mail:mail:jar:1.4:compile
[INFO] |  |  \- javax.activation:activation:jar:1.1:compile
[INFO] |  \- org.safehaus:jug:jar:2.0.0:compile
[INFO] +- javax.servlet:jstl:jar:1.1.2:compile
[INFO] +- taglibs:standard:jar:1.1.2:compile
[INFO] +- javax.servlet:servlet-api:jar:2.5:compile
[INFO] +- com.oreilly.servlet:cos:jar:1.0:compile
[INFO] +- c3p0:c3p0:jar:0.9.1.2:compile
[INFO] +- jaxen:jaxen:jar:1.1-beta-7:compile
[INFO] |  +- xerces:xmlParserAPIs:jar:2.6.2:compile
[INFO] |  +- xerces:xercesImpl:jar:2.6.2:compile
[INFO] |  \- xom:xom:jar:1.0b3:compile
[INFO] |     +- com.ibm.icu:icu4j:jar:2.6.1:compile
[INFO] |     +- xalan:xalan:jar:2.6.0:compile
[INFO] |     \- org.ccil.cowan.tagsoup:tagsoup:jar:0.9.7:compile
[INFO] +- javax.sql:jdbc-stdext:jar:2.0:compile
[INFO] +- org.apache.lucene:lucene-core:jar:1.9.1:compile
[INFO] +- quartz:quartz:jar:1.5.1:compile
[INFO] +- commons-collections:commons-collections:jar:3.2:compile
[INFO] +- org.apache.avalon.logkit:avalon-logkit:jar:2.2.1:compile
[INFO] +- jgroups:jgroups-all:jar:2.6.1:compile
[INFO] \- log4j:log4j:jar:1.2.11:compile
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 4 seconds
[INFO] Finished at: Wed Apr 30 16:40:42 PDT 2008
[INFO] Final Memory: 12M/508M
[INFO] ------------------------------------------------------------------------

Monday Apr 28, 2008

Leopard and the GIMP

On Friday, I spent the majority of the day banging my head against my laptop.

I wanted to install GIMP (the GNU Image Manipulation Program) to do some image creation for my new Widgetbox widget...

I tried several different ways to install the GIMP (and even GIMPshop), but it kept failing every time I tried to run it.

Eventually, I saw the cautionary warning on the site that hosts pre-built Mac OS X versions of the GIMP.

I will repeat the cautions here: The X11 package you can find on a OS X 10.5.0 install disk is too old to run GIMP (it will crash), and it can't be updated through software update.

There appears to be several different ways to address the problem, but the one that worked for me was to download and install the latest version of the XQuartz project.