UrlBlogGrey

I've been using a compact Samsung flip-phone with my Cingular wireless service (formerly AT&T wireless) for the last two years. Service has been good, though I've encountered occasional billing calamities that I'm sure everyone has at some point. However, I need a new phone. Badly.

There is only one defect in my current phone worth mentioning. Here's the sequence of operations to produce the defect:

1. Power-on the phone
2. The display is lit and I can use the phone perfectly
3. Close the flip-phone
4. Open the flip-phone
5. The display is black. It shows evidence of being powered, but there is nothing displayed
6. Power-off the phone
7. repeat.....

As you can imagine, this is a big nuisance. I have to power-cycle my phone every time I make a call, and the only way for me to distinguish who's calling me is by assigning custom ringtones to each entry in my phonebook. "Ok, that's the electro-disco ringtone. Natalie must be calling me."

A couple of days ago, Natalie and I chose to purchase a new cell-phone plan and phones. Natalie went for a pink Motorola Razr ("Rays-her"). I went for the Nokia 6682. Both are camera-phones, Bluetooth-enabled, and support PC (or Mac) connectivity.

I am most excited about being able to set-up a mobile blog ("moblog") using Flickr and this site. Using the messaging service (text/IM/pictures) provided by Cingular, I can e-mail photos to an e-mail address. Flickr has provided me with an e-mail address that is specific to my blog, and any photos sent to that address will be posted to Flickr and, optionally, to my blog.

I love taking photos, but carrying my digital SLR slung over a shoulder isn't always an option. And posting photos that must be first be transfered from a camera to a computer and then uploaded using a desktop application can be time-consuming. It discourages me from uploading photos more frequently. I think that being able to capture and post photos from my cell-phone, regardless of my location, will be a lot of fun!

Posted by Scott at 8:23 AM | Permalink

Natalie and I watched a segment on the television program "60 Minutes" regarding the trend of longer work-weeks in the U.S. To summarize, Americans have longer work-weeks than any other "civilized" country, yet we have the lowest level of output per hour worked. So, we spend more time working inefficiently than anyone else.

This got me thinking about the Getting Things Done (GTD) mantra I've subscribed to for the last 1.5 years. Unlike most business books which seek to make a person more productive only in the context of work, GTD seeks to make a person more productive and efficient in all aspects of their life. The most profound piece of advice I drew from GTD is to have a simple and effective system for tracking responsibilities so that I can focus on just one task at a time. The most critical element is that the system must be simple, reliable, and fast. Hesitation to use the system leads to distrust and fuels the distraction that it is intended to squelch.

The 60 Minutes program showed working professionals juggling cell-phones and PDAs while driving in rush-hour traffic, and married couples who hardly know each other. Why is this so? "Because they're so productive!" Well, not really. In my opinion, the tools are so ineffective that many hours of extra work are required to achieve a fraction of the goals of their users.

It's human nature to look for the "silver bullet" that will solve all your problems. But there is none. The real solution is to not take on so many problems, and to maximize the attention devoted to the problems you have accepted. Interestingly, the only way for me to become more productive was to acknowledge my inability to track tasks in my memory, and to reach out for help. In my case, help came in the form of a pile of 3"x5" index cards that I carry in my pocket at all times. I immediately capture a task on an index card once it enters my mind. The sooner I dump the idea to an index card means the sooner I can get back to whatever task I had been working on prior.

Posted by Scott at 12:51 PM | Permalink

I have a Linksys WRT54GS wireless access point at the center of my home network. I've installed the OpenWRT firmware on the access point to take advantage of some capabilities not present in the off-the-shelf firmware (see my post "OpenWRT on our Linksys WRT54GS"). Since the access point is powered "on" all the time and it has direct access to the WAN (Internet) interface of the network, it seems like an ideal place to run a program capable of maintaining my dynamic DNS entry.

There is a program called 'inadyn' that can publish an IP address to the Dynamic DNS Service. I needed to install 'inadyn' on my OpenWRT access point. This was done by editing the /etc/ipkg.conf file on the OpenWRT system to contain an entry for the URL of the package list that includes inadyn (http://www.syslinx.org/wrt54g/openwrt). Here's some output from my secure shell session:

root@OpenWrt:/etc# more ipkg.conf
src whiterussian http://downloads.openwrt.org/whiterussian/packages
src non-free http://downloads.openwrt.org/whiterussian/packages/non-free
src phil http://www.syslinx.org/wrt54g/openwrt
dest root /
dest ram /tmp

Then, I installed the inadyn program using the web interface provided with OpenWRT. Next, I created a configuration file that is used by inadyn to determine how it should connect to the Dynamic DNS Service and update your entry. Again, here's some shell output indicating the contents of my configuration file (located in /etc/inadyn.conf):

root@OpenWrt:~# more /etc/inadyn.conf
--username foo --password bar --update_period 60000 --alias foo.dyn-o-saur.com

Lastly, I created an initialization script that will be run when the router restarts. Since the inadyn program will run continuously, this initialization script should keep us in business indefinitely. I named my script S50inadyn, which indicates the order (once the network facilities are active) in which the script should be run during start-up. Here's some shell output indicating the contents of the file:

root@OpenWrt:/etc# cd /etc/init.d/
root@OpenWrt:/etc/init.d# ls
S05nvram     S41wpa       S50dropbear  S50telnet    rcS
S10boot      S45firewall  S50httpd     S60cron
S40network   S50dnsmasq   S50inadyn    S99done
root@OpenWrt:/etc/init.d# more S50inadyn
#!/bin/sh
/usr/bin/inadyn --input_file /etc/inadyn.conf &

You should be able to restart the router and see that the inadyn program is running. Simply login to the router and get a list of processes:

root@OpenWrt:/etc/init.d# ps -ea | grep inadyn
  513 root        332 S   /usr/bin/inadyn --input_file /etc/inadyn.conf

Now you can access the WAN port of your access point using a convenient DNS name. You'll probably want to configure some port-forwarding rules in order to access computers within your network. However, I recommend using port-mapping in order to lessen the obviousness of your open ports.

Posted by Scott at 9:59 AM | Permalink

Recently I've been working on porting some code that used a home-grown HTTP client connector to use the HTTP client connector facilities present in Java 1.4+. Some of the outstanding advantages of using the built-in HTTP client connector is that transport encoding (chunked streaming versus fixed-content-length transfers) and forward-proxy authentication is handled automatically behind the scenes.

During my development, I've been using our suite of unit tests to verify the correctness of my work. The tests are implemented using the JUnit test framework and can be run from within my IntelliJ development environment. I've been using the Jetty Servlet container to host our server-side application during testing. Jetty includes a light-weight HTTP server.

At one point, I had all of the unit tests passing and decided to perform functional testing using the full-blown web application in the Tomcat Servlet container. I quickly learned that something was wrong when I began seeing an EOFException reported in the Tomcat server log. I had been using Java's default HTTP Content-Type header field value (application/x-www-form-urlencoded), which the Tomcat Coyote HTTP connector recognized. Tomcat attempted interpret our proprietary communication protocol rather than simply pass it through. I then specified that the Content-Type should be application/octet-stream (the default type according to the HTTP 1.1 RFC) and was successful in testing against Jetty and Tomcat. The problem was that Jetty had ignored the Content-Type HTTP header in our requests, while the Tomcat Coyote HTTP connector did not. Tomcat was correct in this case and has honored the HTTP 1.1 specification more closely than Jetty, in my experience.

Most developers are encouraged to distrust user input because it introduces unpredictability into the execution of a software program. But what I've learned in this and other projects is that no software program works in isolation. If you're writing software for Windows, then you're dependent on the behavior of the Windows Operating System (OS). And the Windows OS is dependent on the third-party hardware drivers and firmware it uses to interact with the computer's hardware devices. And if you're working on software that communicates over a computer network (i.e. the Internet), then anything can happen.

So, simply distrusting user input is not enough to ensure correct operation of a software program. The vagueness of relatively simple communications protocols like HTTP still provide a lot of room for interpretation. The only way to ensure a high degree of compatibility is to test as many hardware, software, and input permutations as possible. An EMC VMWare virtualization appliance is an excellent platform for such testing, in my opinion :)

Posted by Scott at 10:10 AM | Permalink