The War - No Place for Children

Monday October 01, 2007 01:47 | 0 Comments

• Tags:

I watched 6 hours of Ken Burns’ The War on PBS this past week. The documentary focuses on the effects of American towns during World War II; specifically Sacramento (California), Mobile (Alabama), Waterbury (Connecticut), and Luverne (Minnesota).

Using in depth interviews with residents of the towns and soldiers from the town, the documentary brings the war, which is a huge conflict in losses and scope to a more personal level. It’s gripping and exhausting at the same time, especially after doing a marathon of 6 hours and not taking a break. I almost feel that one needs to watch it all (all 14.5 hours of it) in one sitting to get the full effect of the series. By being fully immersed in these people’s lives and not taking a break you start associating the length of the movie with the length of the war. By the time that the soldiers are exhausted from fighting as the war draws to and end you will be too.

In one the episdoes, I heard a quote that I absolutely love. During the constant shelling at Anzio, a soldier exclamied, “God help us! Come yourself, don’t send Jesus. This is no place for children.”

Street Fighter IV Trailer

Wednesday October 17, 2007 21:32 | 2 Comments

• Tags:

I love me some Street Fighter.

Here is the link just in case the embedded player doesn’t work: Street Fighter IV Teaser

Ta-da List Widget Password Fix

Monday October 22, 2007 17:46 | 0 Comments

• Tags:

A few months ago, I started looking for a to do list manager for my Mac. My requirements were few: It needed to be mobile (I could access it from anywhere), and it needed to be free.

I could have very well built my own web application to do this, but I didn’t want another project on my plate. With that in mind, I settled on 37Signals’ Ta-da List. It’s easy to use and it’s free. Most importantly, since it’s web based, it’s completely mobile. However, the web based feature is a two-edged sword.

It’s mobile, but I’m tied to a web browser every time I want to run the application. Sometimes, I just want to open a widget and see what tasks I have left to do for what projects.

Enter the Ta-Da List widget for Mac OS X. The software allows you to get and post information to the Ta-Da List web application without launching your browser. Just what I needed. Except it didn’t work.

I would login using the web application and it would work fine but when I tried to login using the widget, I would get an authentication error. Unfortunately, the widget (like most widgets) don’t have any debugging functionality built into it so I couldn’t tell why my authentication information was being rejected.

Last night, I was determined to solve this issue. I fired up tcpdump (tcpdump -i en1 -vvv -n -s 0 -w ~/Desktop/DumpFile.dmp) and then logged into tadalist.com using the browser. Once I logged in successfully, I stopped the packet capture.

I then fired off another tcpdump (same command as before with the exception of the file name: (DumpFile2.dmp)) to analyze what the Ta-da List widget was sending back and forth.

I found that the difference between the two was the way that the widget was sending the password to the server. With the web application, the password was URL Encoded so that it properly translated symbols for web use. With the widget, they weren’t. Since my password has has symbols in it, this was making the authentication check fail (numbers and letters don’t need to be translated).

Luckily, the Ta-da List widget isn’t a compiled application and most of the code is in Javascript files that you can freely access and modify.

The code for the widget is stored in /Users/[your login name]/Library/Widgets/Ta-Da Lists.wdgt/scripts/. If you want to view the files in widget, right click on the Ta-Da Lists icon and select Show Package Contents.

The file that needs to be fixed is tada.js. I URL encoded the password right before it’s sent to the server with this line:

conn.connect(url, "POST", "username="+getUsername()+"&password="+escape(getPassword()), loggedIn);

But you can encode it directly in the getPassword function like so:

function getPassword() { return escape(widget.preferenceForKey("password")); }

After, I made this change, the widget started working correctly. According to the tcpdumps, the password being sent in it’s URL encoded form to the server (as one would imagine).