Skip to content

Monthly Archives: August 2004

Freecycling, couchsurfing and easy information transfer

One of the most amazing things about the internet is the manner in which it decreases the costs of information exchange. The focus of this decreased cost is often the business world, because that’s where the money is. However, I’m fascinated by the other forums for information exchange that simply wouldn’t exist without extremely cheap publishing and distribution of information. In the past, I’ve taken a look at the web and government budgets, but I recently came across two other activities that I feel are impressive, and exhibit just what the web can provide: freecycling and couchsurfing.

In the past, when I had something (an excess of garden crops, for example) that I didn’t want anymore that was of negligible value, I had a few options for getting rid of it. In decreasing order of personal preference:

1. Foist it on a friend or family member.

2. Put it on the street with a ‘free’ sign.

3. Give it to Goodwill/Salvation Army.

4. Save it and have a garage sale when I had enough items of negligible value.

5. Give it to a thrift store.

6. Throw it away.

Well, now the internet gives me another option: post to a freecycle email list. There are thousands of these groups. I joined the Boulder list, and it has a simple rule: no trading, just giving. 876 people are subscribed to this list. Freecycling is similar in nature to option #2, except many more people will probably find out about your surplus rutabagas via an email than will drive by your house before they turn into a rotting mess (less effort, too–you can send emails from the comfort of your computer chair, as opposed to hauling produce to the curb). In addition to helping you get rid of stuff, these lists also let you accumulate more crap, easily, and without requiring new production. (I don’t know, there may have been freecycle newsletters circulating around yoga studios and health food stores before email took off. Again, the sheer number of people, who by self-selection are interested in giving and getting new stuff, and the ease of posting and receiving the information, means that email freecycling is a better way.)

Speaking of free stuff, a few years I was bumming around down under, and ended up staying with a friend of a friend of a friend of a friend. The free place to stay was sweet, but so was the local knowledge and a friendly face in a strange land. Upon returning to the USA, I decided it’d be great to build a website dedicated to these concepts. Friendster and the other social networking sites give you some of the needed functionality (who’s connected to me, where do they live) but not all of it (search by locality, meet random people). I wanted to call the website ‘findalocal’ and even threw together a PHP prototype before I got sucked into other projects. Well, I was browsing Wired a few days ago, and came upon Couchsurfing.com, a site which does almost exactly what I want, has been around for since 1999, and is much more professionally done than what I would have whipped up. The basic premise is, you offer up your local knowledge to anyone who is a member. You can also offer up other services, not least a place to crash for a few nights. For more info, check out the couchsurfing FAQ. Again, this is a service that would have a hard time without the easy dissemination of information provided by the web.

In short, I think that, although a lot of excitement revolves around the portions of the internet where you can make gobs and gobs of money, plenty of interesting stuff is going on with no money involved. In fact, the ease of information transfer is even more important when there is no explicit economic value. Invoices are going to be sent to suppliers, whether via carrier pigeon or extranet, but getting rid of my old bicycle by giving it to someone has to be easier than just trashing it, or, nine times out of ten, I’ll throw it away. And couch surfing is even more dependent on free information exchange, due to the dispersed geographic nature of the activity.

Technology and Society | moore |

Book Review: Dancing with Cats

If you have a chance to read Dancing With Cats by Burton Silver and Heather Busch, don’t bother. However, pick it up and glance through the photos. For it’s in the pictures, of cats and humans cavorting, of almost impossibly resonant images, that this book shines. (Visit the Museum of Non Primate Art for more.) The text is a bit much, using words like ‘aura’ and negative energy, and apparently meaning it. But, if you like cats and have a sense of the absurd, oh the pictures–check it on Amazon.com. I chuckled and chortled through the entire book.

“Dancing With Cats” on Amazon.

Books | moore |

OJB and object caching, pt II

Well, I was wrong, when I posted that OJB rc4 didn’t support caching. Because of the way the application is architected, there are two places where we grab data from the database. I know, I know, don’t repeat yourself. But when you’re using free JAAS modules and free O/R mapping tools, you can’t be too picky.

The upshot is, when I actually look at SQL statements for a typical two user session, I see 21 of a certain select statement for when caching using the org.apache.ojb.broker.cache.ObjectCacheEmptyImpl class, and only 6 when performing exactly the same user actions with the org.apache.ojb.broker.cache.ObjectCacheDefaultImpl class. Don’t ask me why it’s not a 2 to 1 ratio; I’m looking into it. (Deep are the ways of object caching.)

Java | moore |

Wireheads and depression

I re-read the first two books of the Ringworld series a few months ago. Great science fiction–cool technology, interesting aliens, cardboard characters, decent plot. In the second one, The Ringworld Engineers, one of the main characters is addicted to electricity. Seriously–he has a device that directly stimulates the pleasure center of the brain. Niven calls this ‘addicted to the wire.’

Recently, however, I ran across this article: Shocking Treatment for Depression. Sure, sure, it will require a prescription, and it only helps “lift [your] mood.” It’s only for folks who are depressed. And Viagra is only for older men with erection problems.

Technology and Society | moore |

Book Review: Deadly Feasts

Deadly feasts: tracking the secrets of a terrifying new plague, by Richard Rhodes, is one scary book. It tracks the discovery of prions, the mishapen proteins responsible for mad cow disease, scrapie, and Creutzfeldt Jacob disease. Following human cannibals in the jungles of New Guinea in the fifties, bovine cannibals of the British Isles in the eighties, and the bizarre history of sheep scrapie from the 17th century on, Rhodes does a great job of presenting the history and discovery of this bizarre group of diseases. I especially enjoyed the characterizations of the scientists, from the Noble Laureate who so enjoyed the New Guinea that he often regretted rejoining civiliziation, yet brought thirty natives back to the USA and helped them through school, to the hyper-competitive scientist who named the molecules even though he wasn’t quite certain what they were.

But this isn’t just a story of scientific discovery. As the foreboding subtitle blares, Rhodes explores some of the scarier aspects of prions. These include spontaneous formation, responsible for the known early cases of Creutzfeldt Jacob disease, trans-species infection, including mad cow disease and scrapie, the long long incubation period and lack of immune system response, and hardiness of the disease. One scary factoid: a scientist took a sample of scrapie, froze it, baked it for an hour at 360 degrees (celsius), and was able to re-infect other animals from this sample.

For all the uneasiness this book inspires, it certainly doesn’t offer any answers. A condemnation of industrial agriculture, a warning that it’s unknown whether vegetarians are even safe, and a caution against using bone meal for your flower garden do not make a recipe for handling this issue. To be fair, it was printed in 1997–perhaps things are under control now.

Books | moore |

Book Review: Java Transaction Processing

Since many financial institutions have standardized on it, I hear Java is the new COBOL. Whether or not this is true, if Java is to become the business language of choice, transaction support is crucial. (By ‘transaction,’ I mean ‘allowing two or more decisions to me made under ACID constraints: atomically, consistently, (as) in isolation and durably’.) Over the last five years, the Java platform has grown by leaps and bounds, not least in this area.

Java Transaction Processing by Mark Little, Jon Maron and Greg Pavlik, explores transactions and their relationship with the Java language and libraries. Starting with basic concepts of transactions, both local and distributed, including the roles of participant and coordinator, and the idea of transaction context, the book covers much old but useful ground. Then, by covering the Java Transaction API (JTA) as well as OTS, the OMG’s transaction API which is JTA’s foundation, this book provides a solid understanding of the complexities of transactions for Java programmers who haven’t dealt with anything more complex than a single RDBMS. I’d say these complexities could be summed up simply: failures happen; how can you deal with them reliably and quickly?

The book then goes on to examine transactions and the part they play in major J2EE APIs: Java Database Connectivity (JDBC), Java Message Service (JMS), Enterprise Java Beans (EJB) and J2EE Connector Architecture (JCA). These chapters were interesting overviews of these technologies, and would be sufficient to begin programming in them. However, they are complex, and a single chapter certainly can’t do justice to any of the APIs. If you’re new to them, expect to buy another book.

In the last section, the authors discuss the future of transactions, especially long running activities (the Java Activity Service) and web services. This was the most interesting section to me, but also is the most likely to age poorly. These technologies are all still under development; the basic concepts, however, seem likely to remain useful for some time. And, if you need to decide on a web service transaction API yesterday, don’t build your own, read chapter 10.

There were some things I didn’t like about Java Transaction Processing. Some of the editing was sloppy—periods or words missing. This wasn’t too big a problem for me, since the publisher provided me a free copy for review, but if I were paying list price ($50) I’d be a bit miffed. A larger annoyance was incorrect UML and Java code snippets. Again, the meaning can be figured out from the text, but it’s a bit frustrating. Finally, while the authors raise some very valid points about trusting, or not, the transaction system software provider, I felt the constant trumpeting of HP and Arjuna technologies was a bit tedious. Perhaps these companies are on the forefront of Java transactions (possible); perhaps the authors are most familiar with the products of these companies (looking at the biographies, this is likely). The warnings—find out who is writing the transaction software, which is probably at the heart of your business, and how often they’ve written such software before—were useful, if a bit repetitive.

That said, this book was still a good read, if a bit long (~360 pages). I think that Java Transaction Processing would be especially useful for an enterprise architect looking to leverage existing (expensive) transactional systems with more modern technology, and trying to see how Java and its myriad APIs fit into the mix. (This is what I imagine, because I’m not an enterprise architect.) I also think this book would be useful to DBAs; knowing about the Java APIs and how they deal with transactions would definitely help a DBA discuss software issues with a typical Java developer.

To me, an average Java developer, the first section of the book was the most useful. While transactions are fairly simple to explain (consider the canonical bank account example), this section illuminated complexities I’d not even thought of—optimizations, heuristic outcomes, failure recovery. These issues occur even in fairly simple setups—I’m working at a client who wants to update two databases with different views of the same information, but make sure that both are updated or neither; this seems to be a typical distributed transaction. The easiest way to deal with this is to pretend that such updates will always be successful, and then accept small discrepancies. That’s fine with click-throughs—money is a different matter.

However, if you are a typical web developer, I’m not sure this book is worth the price. I would borrow it from your company’s enterprise architect, as reading it will make you a better programmer (as well as giving you a sense of history—transactions have been around for a long time). But, after digesting fundamental distributed transaction concepts, I won’t be referencing this book anytime soon, since the scenarios simply don’t happen that often (and when they do, they’re often ignored, as outlined above).

Books Java Programming | moore |

Decreasing the size of a midlet jar

The J2ME application I have been working on has been ready for testing for quite some time, but I didn’t want to get a new AT&T phone. For J2ME, you really need a GSM phone–I don’t think any of the older TDMA models support it. But the GSM network coverage doesn’t match the coverage of the TDMA network–especially out west (aside: isn’t that magnifying glass pretty cool?). So I put off buying a phone until my summer road tripping was done.

I’ve had a Nokia 6160 for almost 4 years. Even though friends mocked the size of it, it was a great phone–durable, good talk time. I thought I’d try another Nokia, and got one of the lower end GSM phones, the 6200. This supported J2ME, and weighed maybe half as much. I was all stoked to try the application on my brand new phone.

I started download the jad file, and was getting ‘File Too Large’ errors. A couple of searches later, I found Nokia’s developer device matrix which is much more useful than the User Guide or the customer facing description of phones. Whoops. Most of the Series 40 (read: affordable) Nokia devices only supported J2ME applications which were, when jarred up, less than 64K in size.

Our application, however, was about 78K. This highlights one of the differences between J2ME and J2SE/J2EE. When coding in the latter world, I was never concerned about code size–getting the job done quickly was paramount, and if I needed to use 13 libraries which bloated the final size of my application, I did. On a cell phone, however, there’s no appeal to adding memory or changing the JVM configuration to optimize memory use. If the Nokia phone only accepts jars of 64K or less, I had three options:

1. Write off the Nokia Series 40 platform. Ugh–I like Nokias, and other folks do too.

2. Do some kind of magic URL classloading. This seemed complicated and I wasn’t sure how to do it.

3. Decrease the size of the jar file.

Now, the 78K jar had already been run through an obfuscator. I wasn’t going to get any quick and easy gains from automated software. I posted a question on the JavaRanch J2ME forum and received some useful replies. Here’s the sequence I went through:

1. Original size of the application: 79884 bytes.

2. Removal of extra, unused classes: 79881. You can see that the obfuscator did a good job of winnowing out unused classes without my help.

3. Changed all the data objects (5-6 classes), which had been written in classic J2SE style with getters and setters for their properties, to have public variables instead: 79465

4. Combined 3 of the data object classes into one generic class: 78868

5. Combined 5 networking classes into 2: 74543

6. Removed all the logging statements: 66044. (Perl to the rescue–$ perl -p -i -e 's!Log\.!//Log.!' `find . -name "*.java" -print |xargs grep -l 'Log\.'`)

7. Next, I played around with the jode obfuscator which Michael Yuan recommended. I was able to radically decrease the size of the jar file, but, unfortunately, that jar file didn’t work on the phone. I also got a ton of exceptions:

java.util.NoSuchElementException
        at jode.bytecode.BytecodeInfo$1.next(BytecodeInfo.java:123)
        at jode.obfuscator.modules.LocalOptimizer.calcLocalInfo(LocalOptimizer.java:370)
        at jode.obfuscator.modules.LocalOptimizer.transformCode(LocalOptimizer.java:916)
        at jode.obfuscator.MethodIdentifier.doTransformations(MethodIdentifier.java:175)
        at jode.obfuscator.ClassIdentifier.doTransformations(ClassIdentifier.java:659)
        at jode.obfuscator.PackageIdentifier.doTransformations(PackageIdentifier.java:320)
        at jode.obfuscator.PackageIdentifier.doTransformations(PackageIdentifier.java:322)
        at jode.obfuscator.PackageIdentifier.doTransformations(PackageIdentifier.java:322)
        at jode.obfuscator.PackageIdentifier.doTransformations(PackageIdentifier.java:322)
        at jode.obfuscator.ClassBundle.doTransformations(ClassBundle.java:421)
        at jode.obfuscator.ClassBundle.run(ClassBundle.java:526)
        at jode.obfuscator.Main.main(Main.java:189)

I'm sure I just didn't use it right, but the jar file size was so close to the limit that I abandoned jode.

8. Instead, I put all the classes in one file (perl to the rescue, again) and compiled that: 64057 bytes. The jar now downloads and works on my Nokia 6200 phone.

When I have to do this again, I'll definitely focus on condensing classes, basically replacing polymorphism with if statements. After removing extraneous Strings and concatenating all your classes into one .java file (both of which are one time shots), condensing classes is the biggest bang for your buck.

Java Programming | moore |

Book Review: Divorce Your Car

Divorce Your Car, by Katie Alvord, is thought provoking. In the United States of America, an automobile is many things to many people: transportation, status symbol, hobby, money pit. Alvord takes apart the place of the car in modern society (the focus of the book is on North America, though she does refer to Europe and the Third World in places) and roundly condemns our dependence.

Her book is split into three parts–the first covers the history of the automobile and other forms of transport. She legitimizes what I’d often heard and dismissed as a myth–the car industry bought up the transit systems of cities in the US early in the 20th century and replaced them with buses. The second is a laundry list of the negative effects of the car (which, I must confess, I didn’t finish–too depressed after the first thirty pages). The final section covers alternatives, including walking, biking, mass transit, non-gasoline cars, and telecommuting.

I found the book to be quite good in outlining the problem and highlighting solutions. The dependence of modern life on the car is a dependence on convenience. But, to some extent, it’s a matter of inertia. Automobiles are so prevalent and easy that many of us never try the alternatives, let alone use them in preference to our car. A strong point is that she realizes that car-free living isn’t for anyone, and makes a point that going car-lite can have a positive effect as well. She also touches on the far reaching implications that technology decisions have had on our society, our cities and our lives–from subsidies to the development of advertising. It would have been interesting to read more about that, but what she did say was definitely thought provoking.

However, I do have three quibbles. Alvord cites sources extensively, but her arguments would be more compelling were the sources less biased (as you can tell by titles like Asphalt Nation) and more first hand. She ignores two factors that would affect my divorce. Giving up your car, or at the very least being aware of alternatives, makes driving after drinking less likely–a good thing! On the other hand, if you don’t have a car, you suddenly have a dearth of available camping and hiking activities. But these concerns aren’t everyone’s, to be sure.

Overall, a book well worth reading, especially if you commute a lot. Too bad they don’t sell it as a book on tape!

Books Technology and Society | moore |

XML for data transmission

I was using XML as a file format for a recent project. Not a standardized dialect, just an ad hoc, custom flavor whipped up to hold the data of particular interest. Now, I’ve used many file formats and always thought XML was a bit hyped up. After all, it’s bulky and angle brackets can be a bit tedious to wade through. In addition, parsing it is hard (creating it is difficult too, if you want to do so by creating a DOM tree). Not too hard, you say. Well, compare the joy of a StringTokenizer parsing a pipe delimited line to the pain of traversing around a DOM tree (to say nothing of the “if” hell of a SAX handler).

However, XML does have strong points. Storing hierarchical data in XML is easier. And, as far as I’m concerned, XML’s killer feature as a file transport format is its self-documenting nature. Sure, you can put headers at the top of a pipe delimited file, but it’s easy enough to forget them. Omitting the XML tags isn’t really possible–you can choose obscure names for the tags that cloud the meaning of the data, but that’s about the worst you can do. Using a custom flavor of XML as a data transmission format can be a really good idea; it just means you’ll have a helper class to do the node traversing contortions everytime you want to read it. (I’m purposefully ignoring the technologies like JAX because I haven’t used them.)

Programming | moore |