MudLog

Starting tomorrow, the PLW team will be hanging out at SIGGRAPH. I’m specifically curious about discussion panels surrounding Digital Rights and Licenses, since I’m currently working on PLWicense: an online license creator. More on that in a future entry, but the initial release is ready to go.

Hopefully I’ll have images from SIGGRAPH here during the week, but I’m not much of a picture taker, so who knows. I’ll be at the fashion show for sure. Here is the website I made for it. See you at the bar.

I finally got a summer haircut. I cut my hair above my eyebrows when summer arrives, and I repeat that process after a year when it grows down past my chin. It gave me a sense of time during my “working years” after my first grad school, since I no longer had the academic calendar to rely on.

I hate how my hair looks when I cut it that short. It looks just like the picture above. Total helmet-head. It’s a functional hair cut, since hair doesn’t get in the way and it just feels good. Usually I choose aesthetics over function, but every summer when the sticky disgusting tropical storm weather comes along, I opt for the functional.

This is the same with web applications. There are so many web applications out now, but most of them are purely functional and completely ugly. Google’s numerous services are good examples of where function dominates over aesthetics. Just look at the mess they call froogle.

The thing I like about all the Web 2.0 hype is that there is a concious effort to make things look good (and to make things move fluid and smooth.) For instance, Burak showed me Vimeo, which is basically the same thing as YouTube, except unlike YouTube, it doesn’t look like vomit. Also, they use Prototype.js, so they get a thumbs up just for that. The more I compare the two sites, the more I wonder why anyone will tolerate YouTube’s complete lack of aesthetics. I thought consumers where much more demanding of visual goodness ever since the iPod craze, but it still doesn’t translate over to the web world.

Maybe function always wins over aesthetics…I think I like my haircut now.

It’s been a fun week but I didn’t get much work done because we had SIMPLICITY events to attend. I did however start working on the new PLW website, which should be completed by SIGGRAPH2006. The PLW team will be there, so I think it’ll be fun and a nice break out of the lab.

It’s new logo Saturday! Here are new logos for OpenStudio (of course I haven’t gotten everybody’s OK) and PLWire (which will be the name of the new PLW service) that I worked on this week.

I heard about JSON a while ago, but I never looked closely at it until this past week. I was looking for a way to communicate between JavaScript and a Servlet (or anything cgi-like) with an AJAX call. Normally I would construct an XML file, parse through and construct HTML chunks and use innerHTML to update a section of the page. The problem with this is, XML is kind of a pain in the butt for a lazy programmer, and why bother constructing an XML file if you’re going to have to parse it back to something else?

You can’t spell XMLHttpRequest without XML. But you can sure go without using it. I make a lot of AJAX calls on websites these days. I know it doesn’t degrade with browsers running without JavaScript enabled. That’s not my problem. I really don’t care for people who turn JavaScript off. JSON is a much better way to publish data into JavaScript, because JSON is written as a plain old JavaScript Object, which looks like a simple hash table.

There’s nothing for you to do, all you have to do is grab it from the server (which would show itself as a string in JavaScript) and run eval on it to turn it into an object. In Ruby on Rails, there’s a simple helper method called: .to_json which makes constructing a JSON object simple…but Rails makes everything simple, and you spend less time programming brainless things like parsing XML.

Documentation is always a painful task: especially with software, since programming is hard enough. I tend to slack off on commenting code, and I rarely document anything I do. As long as I wrote it, no matter how old, I can usually figure out how everything works. If I give out code, I usually let other people figure out everything, but who does that really help? I guess people that are competent programmers that are just too lazy to write their own.

This article about community documentation was interesting. I think documentation would improve greatly if users write their documentation. The user comments on PHP.net and the Ruby on Rails wiki are good examples. Active users become more knowledgable than developers a lot of times, and developers don’t necessarily see things from the users perspective. Just look at the horrible UIs employed by some of the biggest software. I don’t know any one that has ever said they love Flash’s UI.
But, back to getting users to write documentation. How do you get them to do it? Do you ask them nicely? I don’t know…I think that’s a challenge all on it’s own. But people like free things, like free software. Why not come up with a new license where you would give out free licenses for contributing documentation while you can choose to opt-out if you just want to buy it and save the trouble of writing.

We’ve been working on OpenCode, our first new tool for the upcoming OpenStudio 2.0. The blog entry can be found here, as well as a brief screen cast.

Good thing bp stands for “beyond petroleum.”

I recently came across a problem of having to get Ruby on Rails running on Apache (port 80) communicate with Tomcat (port 8080.) I learned that there are numerous ways to get this done. The first approach was to use a connector, and Kyle got mod_jk set up and running so that Apache would connect to Tomcat with a particular URL. That all worked well, until I took the static HTML prototype and got it under the control of Rails.

I set up a virtual host running on port 80 to go to my Rails public directory, which worked fine. But once Rails takes control, the connector set up with mod_jk no longer worked; instead I just get a Rails error. Boo hoo.

I gave up on the connector approach. It seemed kind of flaky anyway. I really wanted to centralize where all this configurations were happening, and I wanted it out of the httpd.conf file, since I never feel comfortable modifying it. The best place would be inside the .htaccess file with the public directory, where all the other rewrite rules live.

I thought about having to create a webservice or some sort of proxy, but I learned about mod_proxy. It’s really easy to use, and gives you a new switch [P] in your rewrite rule. Enable it in httpd.conf and you can use it within the .htaccess file.

Your rewrite rule would look something like this:

RewriteRule ^tomcat-dir/(.*)$ http://localhost:8080/tomcat-dir/$1 [P]

My job here is done…