Tasty and del.icio.us

I'm riding a wave of hipness as I have switched my bookmarks to del.icio.us. I looked at del.icio.us before, but couldn't make the switch from my Yahoo! bookmarks. One of the things that made the difference this time was the Firefox add-on that replaces Firefox's bookmarking with del.icio.us. The add-on comes with a handy toolbar that provides me quick access to my bookmarks. You can organize by bookmark (most recent or most used) or tags. I like using the tags. Here are my shared bookmarks...

jrehfeld's bookmarks on del.icio.us

Almost as cool as a Mac user...

Because I now own a Nintendo Wii, I feel like I am so counter-culture. PS3? Bleh! XBOX 360? Pweh! My son and I were 48th of 69 in line at Super Target at 6:30 Sunday morning. By 8:42 am, we were proud owners of a Wii, and we spent the next 10+ hours playing tennis, bowling, and fishing (Zelda).

So my coolness factor increased, in my mind, to a level below a Mac user, in his mind.

Sticking it to the Man!

The client I am at blocks all IM and external email so staying in touch with friends and family is quite difficult, considering I don't like talking on the phone. Google Talk worked for a while, but was recently shut down (I cried myself to sleep that night).

In my constant fight for human (IMing) rights, I am resorting to using a shared Google document (i.e., Writely). This solution cannot be declared a success yet as the adoption rate from my friends is quite minimal. Ok, its zero.

By the way, I wrote this blog entry using Google Docs. The shared features are "pretty slick" as Brian commented. Give it a try ==> Google Docs

Java build scripts to build Java?

Dr. Dobb's Java Blog had a post about a Java-based approach to Ant build scripts. The author suggests that writing Ant scripts in XML is too challenging and complicated since XML isn't really a programming language, but the example in the post of the Java programmed scripts seems much, much harder to read.

Personally, I like the declarative nature of XML Ant scripts, and writing build scripts in Java seems over-engineered. However, I am open to alternatives to using XML for scripting, and a true scripting language may be better suited.

One of the comments mentions using Groovy for build scripts, which seems interesting, and needs more investigation.

This is slick...

...and also not related to development, Dr Lunch or anything else. But having said that, if you are one of the 6 people in the world that has a) all of your music stored in iTunes on a Mac, and b) you have an XBox 360, then run, don't walk, over to pick yourself up a copy of Connect 360 from nullriver. In literally 3 minutes you'll be streaming all your music and photos from your Mac to your XBox 360. As someone famous once said "It just works". Your music shows up, all of your playlists that you've built in iTunes are right there on your Xbox, and everything works beautifully (which the exception that you can't play FairPlay protected AAC files you bought from the iTunes Music store, but hey, that's a suckers game anyway, right?) Pay 'em their $10 registration fee and you have yourself the very functional equivalent of a Squeezebox for a fraction of the cost. (Assuming, you know, you already blew your kitty on the Xbox and the Mac and the nice receiver, and some nice B&W speakers. Slick as hell. I'd like to find the guys who wrote this and give them a big hug.

Primadonna

If we ever want to give Drake his google maps mash-up, we're going to have to store addresses with restaurants (also zip codes). Which raises two issues:

1. How do we get addresses? Obviously we don't ask the user for them, 'cause if someone asked me to find and key in addresses for 12 restaurants before I could start using their system, I would fall out of my chair laughing. And if I hit my head on the corner of a desk on the way down, I'd sue. The only approach I can see is to do a yahoo search everytime a restaurant is created (using the restaurant name and group zip) and then prompt with "Do you mean X (at 12345 Y Street)?" And that has risks, too.
   
2. A lotta people like these here chain restaurants. So we run into an issue when "The Lunchtastics" in MI and "The Lunchmatics" in OH both want to include Chili's in their list of restaurants. Obviously there are about 12 million ways to solve this one, but all of them add more data. Plus if we're really moving to the tag model, it would be nice to know that the Chili's in MI and the Chili's in OH are both "crappy" "chains."

Whatever solution we come up with, I think Drake better start looking into the best practice way to parse the response data from Yahoo's Local Search Web Service in Ruby -- there's gotta be some way to dynamically create objects once you figure out Yahoo's XML-style.

It's True! We're So Lame!

So, apropos of nothing, an amusing excerpt:

XML is not the answer. It is not even the question ... "Some people, when confronted with a problem, think “I know, I’ll use XML.” Now they have two problems."

Well, maybe not apropos of absolutely nothing. The article I snipped it from is moderately amusing (if unnecessarily abusive) for those <shudder>Java</shudder> developers among us who are currently checking out flavor-of-the-month languages like Python (underhanded dig at Python intended solely to offset Java abuse).

In our defense, though, I think there are plenty of Java developers out there just as appalled by the disgusting sprawl of XML as any other right-thinking human being -- things like this wouldn't exist if there weren't. That said, in some ways the situation is even worse than dirtSimple knows.

In Java, XML can be your savior because it lets you implement domain-specific languages and increase the flexibility of your application "without coding". In Java, avoiding coding is an advantage because coding means recompiling.

The sad fact is that you don't even always avoid a recompile. I mean, change the XML in your deployment descriptors and you're ejbc'ing again. Thank God I work for an organization enlightened enough that they never went down the entity bean path.

I mean, really...

Fourth Place is Just the Third Loser

Many thanks to the blogger behind rock and roll lifestyle for including us in his/her "Four sites I visit daily" list. Lord knows you can't challenge the taste of anyone who watches Project Runway. I tell you what, the temptation to go back and retitle Drake's oh so boringly named "Java 1.5 by default from the command line on a Mac" to "Make it work" in honor of the lovable Mr. Gunn is almost overwhelming.

Keep spreading the word and keep the Dr. Lunch dream alive!

One of These Days I Gotta Get Myself Organizized

So James and I were talking the other day about the need for some kind of formal defect/enhancement tracking, and it was all abstract and "wouldn't it be nice"-ish. Then in the shower this morning I had 6.8 million ideas and nowhere to put them, and I realized there was no way I would ever be able to hold them all in my head, let alone prioritize them, and all the sudden the walls were closing in and next thing I knew I was curled up in a little ball on the floor sobbing softly to myself...

So I think we need to accelerate our plans in this department...

I suppose if we really want to be all Web 2.0-y, we could use the free version of Basecamp (allegedly perfect for people with 1 project). We don't really need file sharing, since any files we're sharing ought to be in SVN anyway, but Bugzilla is probably more appropriate. This just in -- Drake says Bugzilla is a nightmare, so I guess we're back to square one. Suggestions are more than welcome.

Anyway since we don't have a better space right now, a few strategic initiatives:

• The central stumbling block to the Dr. Lunch experience (IMHO) is the effort involved in starting things up. You have to create a user account, create a group account, invite other people to join your group (all of whom have to create user accounts), then everyone adds restaurants, then you get to the "fun" part. I started to try to address this issue with the concept of "public" groups which allow outsiders (presumably outsiders new to Dr. Lunch) to request invitations to the group. Not only do you not have to create a group in this case, you don't even have to have any friends. I really like this, particularly the social aspect of it all, but I think we need to pursue simplification further. "Group-less" searches were one of the things I came up with -- if we had a zip code from a user, we could use average restaurant ratings to suggest some place nearby (also would be great for Dr. Lunch users on the road). Drake is a big fan of pulling restaurants from some sort of external source to eliminate the need to type things in (and maybe find some places users didn't know about before), and I definitely think we should be incorporating this. Finally, we need to make signing in and starting up a group seem simpler. More like a single step.
• Clearly Dr. Lunch was Web 2.0-ish before Web 2.0 was even called Web 2.0 (I'd like to remind new readers that my tongue is always at least 3/4 in cheek when I use the term Web 2.0), we let users control their data from the start. Users create and rate restaurants, add styles, etc. One thing we missed tho' is the whole concept of "Tagging," which I think has real applications here. My initial thought is that we take all the style data we have in our database right now and turn it into "tags". Then we let people add all sorts of non-style related tags. So instead of having an "Italian" restaurant, you'd have an "Italian" "Fast" "Expensive" restaurant and an "Italian" "Slow" "Cheap" restaurant. This kind of information would allow us to provide much better choices -- obviously some days you need a quick lunch, and Dr. Lunch should be able to adapt to those days.
• We're getting some near duplicate restaurants and styles. Like "Rudys BBQ", "Rudys" and "Rudys Country Store & Bar-B-Q" (all in Austin). This is a problem when we're trying to display a list of nearby restaurants. I don't know how to solve it, but I know we can't be the only ones with this issue. Suggestions?

And a few tactical issues:

• I need to make tables that page -- searching for nearby restaurants in some zip codes provides ridiculously long lists, they should fit on a page if they're going to be manageable.
• We have email addresses for our users, once a decision has been made, we should let people email it to everyone else who is going to lunch, along with a meeting place and a time.
• We need more flexible distances when searching for nearby restaurants. 5 miles is a long way in urban settings.
  

Ok, I feel a little better now...

Tightness in my chest is slowly loosening...

But if we don't figure out a better place to put these things than on our blog, I know it's just going to come back...

Java 1.5 by default from the command line on a Mac

Maybe someone else will find this useful, it was sure a head-scrater for me for a while. The good ol' Mac with its "oh, we have to have a non-standard UNIX file layout" was giving me quite a puzzler on how you are supposed to set your preferences for what version of Java to run from a command line. If you have the Java 5.0 Release 1 from Apple it comes with a little utility which lets you decide what order to use the JVMs on your machine. Setting it to use 5.0 before 1.4.2 does not affect items run from Terminal or any other command line application. Thanks for nothing Apple.

So to make this work (maybe this is intuitive for some people, but I'm not a big Mac developer or anything). Create or update the .profile in your home directory with the following:

PATH=.:/System/Library/Frameworks/JavaVM.framework/
Versions/1.5/Commands:$PATH
JAVA_HOME:/System/Library/Frameworks/JavaVM.framework/
Versions/1.5/Home

Presto! Anything you run from the command line goes via Java 5, or 1.5 or whatever the hell they are calling it these days. Simple, easy, and doesn't involve messing with any system links which some people seem to think is evil for some reason or another.

Hopefully one of these days Apple switches all machines over to run Java 5 by default. Sure would be nice for those of us who run Tomcat 5.5 and don't want to mess with the Java 1.4 compatability library.