Skip to content

Book Review: Afghanistan

Updated 2/25/2007: Added amazon link.

Afghanistan: A Short History of Its People and Politics, by Martin Ewans, is a fantastic book. This fascinating account of this plucky country was chock full of facts that have immediate relevance. Covering from ancient times to 2002, this book provides a traditional history–no stories of the working classes or women. But it covers the byzantine regime changes of Afghanistan very well. It als does a fine job of explaining how the Afghanistan state was in constant tension between the local tribal powers and the more modern central authority of the king. The foreign situation was also an exercise in balance, with the Afghans depending on money, guns and expertise from British India to fend off the Russian Empire. However, the relationship with the Brits wasn’t entirely golden, as the three Anglo-Afghan wars suggest.

While the history was intensely interesting, the last chapters of the book, which cover the politics and battles of the last two decades which have left Afghanistan such a mess, were the most relevant for me. If you want to know how mcuh the CIA spent supporting the Taliban, it’s in there. If you want to know which external nations supported which of the warring factions, it’s in there. If you want to know why Afghanistan grows the majority of the world’s opium, it’s in there.

I won’t say this book was easy to get through. The writing is quite dense. The frequent re-appearance of characters was at times confusing, but I fear that is more a feature of Afghan history than a shortcoming of the book. For a concise political history of a nation that we’re becoming more and more involved with, check it out.

Link to the book on Amazon.

Amazon Web Services

I remember way back when, in 2000, when EJBs were first hot. Everyone wanted to use EJBs in projects, mostly for the resume value. But there was also a fair bit of justified curiosity in this new technology that was being hyped so much. What did they do? Why were they cool? How did they help you?

I did some reading, and some research, and even implemented one or two toy EJBs. I remember talking to a more experienced colleague, saying “Well, all EJBs provide you is life-cycle assistance–just automatic pooling of objects, a set of services you can access, transaction support, and maybe SQL code generation.” Now, I’m young and inexperienced enough to never have had the joy of doing a CORBA application, but my colleague, who I believe had had the joy of doing one or three of those, must have been rolling her eyes when I said this. ‘Just’ life-cycle assistance, eh?

I just looked at Amazon’s web services, and I’m beginning to understand how she felt. Sure, all web services provides you is easy, (relatively) standardized access to the resources and data available in a web application. Sure, I could get the same information by screen-scraping (and many an application has done just that). But, just as EJB containers made life easier by taking care of grimy infrastructure, so do web services make life easier by exposing the information of a web application in a logical format, rather than one dependent on markup.

Using perl and XSLT (and borrowing heavily from the Developer Kit, I built an application using Amazon’s web services (the XML over HTTP API, not the full SOAP API). I was amazed at how easy it was to put together. This was partly due to the toy-like nature of the application, and how much it leveraged what Amazon already provided, but it was also due to the high level of abstraction I was able to use. Basically, Amazon exported their data model to me, and I was able to make small manipulations of that model. It took me the better part of three hours to put together an application which allows you to search on a keyword or ISBN and gives all the related books that Amazon has for that book. You know, the ‘Customers who bought this book also bought’ section.

I’ve always felt that that was the most useful bit of Amazon, and a key differentiator. This feature, as far as I can tell, leverages software to replace the knowledgeable bookstore employee. It does this by correlating book purchases. This software lends itself to some interesting uses. (I wanted to have a link to an app I found a while ago, where you entered two different artists/authors and it found the linkage between the two. But I can’t find it!)

I like this feature, but it also sucks. The aforementioned bookstore employee is much better than Amazon. Buying a book doesn’t mean that I’ll enjoy it–there are many books I’ve purchased that I wonder why I did so, even one hour after leaving the store–so that linkage isn’t surefire. In addition, purchase is a high barrier, and will probably cause me to not branch out as much as I should–rather than waste my money picking a random book, I’ll pick a book from an area I know. The book store employee, if good, can overcome both of these faults, because the process is more interactive, and the suggester has intelligence. But he doesn’t scale nearly as well as cheaply, nor does he have the breadth of Amazon’s database. (And he hates staying up all night responding to HTTP requests.)

Yahoo! mail problems

One of my clients had a problem earlier today. I helped them choose a new email setup, and they went with Yahoo Business Edition Mail. It’s worked like a charm for them until today. Oh, sure, they’ve had to adjust their business processes a bit, but it was a vast improvement over their previous situation, where only allowed one person in to view his or her mailbox at a time. And it’s quite low maintenance and fairly easy to learn, as it was entirely browser based.

But today, the web client for Yahoo! was busted. New layouts, new colors, old functionality gone, intermittent changes in the GUI, the whole bit. I got on the phone with Yahoo! support, and they assured me it was simply a webmail client problem. No mail was being lost. But, as Joel explains, for most folks, the interface is the program. You try explaining the difference between SMTP and POP and mail storage and local clients to an insurance agent who just wants to send her customers an application.

One of the worst bits is that, other than getting on the phone with Yahoo! support, there was absolutely nothing I could do to fix the problem. Alright, this isn’t entirely true–I could have worked on migrating them off the web client, and perhaps off Yahoo! entirely. And, had the outage continued, I probably would have begun that process. But fixing the web client was entirely out of my hands. That’s the joy and the pain of outsourcing, right? The problems aren’t yours to fix (yay!) but you can’t fix the problems yourself (boo!). Also, chances are the outsourcing provider is never going to be more enthusiastic than you about fixing your problems, and might be significantly less.

Put the pieces together: A Linux Small Business Server

I noticed an article on InfoWorld about Microsoft Small Business Server (SBS). This software package brings together important software packages for small business organizations in an easy to configure and install bundle. The primary features of SBS are, according to this article, email and calendaring, file and printer sharing, and file backup. There are additional features that you can plug in, including email clients, a fax server, remote access via the web, and possibly integration with a back end database.

All this software exists for Linux. For email, you have qmail and imap (we aren’t concerned about the client, because they’ll use Outlook, if they have Office). For calendaring, I haven’t found anything quite as slick as Outlook, but Courier promises web based calendaring, and Mozilla Calendar, when paired with a WebDAV enabled web server, like Apache with mod_dav, allows you to share calendars (it does require you to install the Mozilla browser on every client, though). For file and print sharing, there’s Samba and for backups, there’s the super stable Amanda. Remote access can be handled via VNC and fax server solutions can be built, although the author of the InfoWorld article prefers a fax over IP service which should work fine as long as you have MS Office. As for back end databases, you’d probably want PostgreSQL, probably managed via MS Access. Wrap it all up with Webmin for administration. (Full disclosure–I haven’t used all this software, just most of it.)

So, I set out on the web to see if anyone had gathered all these components together, tested them, and made it easy to install and configure. Basically, an SBS competitor that could compete on features, with the added bonus of Linux’s open nature and stability.

First, I checked out what Redhat and SuSe (1, 2) had to offer. While they had standard servers that were cheaper than the $1500 quoted for SBS, the Linux packages didn’t have all the features either. Then, I did a web search, which didn’t turn up much, except for a LUG project: the Windows Replacement Network. I’m not sure how active this project is, but at least it’s a start. I checked on SourceForge, but didn’t see anything that looked similar.

I really think that there’s an enormous opportunity for the open source community to piggy back off of MS. They’ve already done the market research, they’ve already determined the feature set that will sell to small businesses. And almost all the software is written for the Linux version of the SBS–all that really needs to happen is some configuration and documentation to make all these features work together. Cut it to a CD-ROM and start passing them out at LUG meetings. This would provide one more option in a consultant’s toolbox and give consumers one more choice.

Book Review: A Farce To Be Reckoned With

I just finished ‘A Farce to Be Reckoned With’ by Roger Zelazny and Robert Sheckley. I’ve read a fair bit of Zelazny–the Amber novels and Lord Of Light and some others. This book looked more light hearted, but I figured I’d give it a try.

I was sorely disappointed. There’s no plot. Or, rather, there is a plot, but it makes no sense. Plot turns are introduced (like the Greek gods getting free) and then dropped, willy nilly. There’s a character called Peter Westfall who gets Pandora’s Box at the beginning, but we never hear from him again. And at the end, we have a fight scene that is a total deus ex machina–the end of the book comes with no explanations.

Normally, you expect characters to have reasons for things they do. They can do weird things, but they should justify it to themselves, and have the actions be a natural outgrowth of their past. This is called characterization. Characters in this book have one sentence justifications for absurd actions. We have a nun who decides to deal with the devil, and an angel who is ordered to spy. There’s a set of religious pilgrims headed toward Venice during the Middle Ages. A demon joins them, proves himself to be a demon, and they don’t even run from him.

The dialog is wretched. Everyone converses in a stilted manner. The description is campy; the authors apparently decided to focus on the clothing of women–there are attractive wimples and red low cut blouses galore.

It feels like this book has been subjected to random editing. Or perhaps worse than random, as I feel that there may have been malicious intent at confusing the reader. Characters pop up, disappear for a while, then pop up again with no explanation (an example is the young lady named Priscilla [or Puss]).

But you know what? All of the above flaws could have been forgiven if there had been any scene, any scene at all, that was funny. I wanted to forgive the flaws–I wanted to laugh–I read the entire book, didn’t I? But I didn’t even crack a smile the entire book. There were times I put it down and thought to myself, ‘Why are you wasting your time?’ I will admit, I finished the book (I think for the same reasons that folks slow down to look at a wreck on the highway).

Don’t buy this book. If you want some funny fantasy, read ‘A Night in the Lonesome October’ (which is great!) or anything by Blaylock. Don’t buy this book.

Sending Binary Data Via Struts

Struts is a MVC web framework. It allows you to specify the paths through a web application in an XML configuration file, and provides some nice tag libraries for JSP manipulation. The views for the states are usually JSPs, and the controller is a servlet provided for you.

This standard setup is fine, most of the time. But I’ve run into situations, as have others (1,2), where you need Struts to output a binary file. In my case, I’m sending a dynamic image to a non browser client, and I basically need to write a ByteArrayOutputStream to the response output stream.

Now, you’d think I’d be able to do this with a JSP. After all, a JSP is just a servlet turned inside out, right? Well, according to the specification, you’d be right. From page 42 of JSP 1.2 spec:

—————-
The JSP container should not invoke response.getWriter() until the time when the first portion of the content is to be sent to the client. This enables a number of uses of JSP, including using JSP as a language to glue actions that deliver binary content, or reliably forwarding to a servlet, or change dynamically the content type of the response before generating content. See Chapter JSP.3.
—————-

But, according to Tomcat 4.1.24 on the Linux platform, you’d be wrong. When calling ‘java.io.OutputStream rs = response.getOutputStream();’ in my JSP, I get this code generated:

—————

....snip...
      application = pageContext.getServletContext();
      config = pageContext.getServletConfig();
      session = pageContext.getSession();
      out = pageContext.getOut();
      _jspx_out = out;
java.io.OutputStream rs = response.getOutputStream();
....snip...

—————

The JSP is taking my stream before my code has a chance. Therefore, I get an “getOutputStream() has already been called for this response” error. The weird bit is that this doesn’t seem to happen on Tomcat 4.1.24 on Windows (same version of struts).

So, what do you do? You write a servlet instead. That way you have utter control over the output stream:

—————

import javax.servlet.http.*;
import javax.servlet.*;
import java.io.*;

public class BinaryStreamServlet extends HttpServlet {

   public void service(HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException {
      String contentType =
(String)req.getAttribute("contentType");
      if (contentType == null || "".equals(contentType)) {
         contentType = "image/png"; // default
      }
      res.reset();
      res.setContentType(contentType);
      OutputStream sos = res.getOutputStream();
      ByteArrayOutputStream baos = (ByteArrayOutputStream)req.getAttribute("baos");
      baos.writeTo(sos);
   }
}

—————

I set up my action classes to cache the ByteArrayOutputStream in the request, with the name “baos.” I added these lines to my web.xml:

—————

<servlet>
      <servlet-name>binaryFileServlet</servlet-name>
       <servlet-class>BinaryStreamServlet</servlet-class>
  </servlet>
....snip...
  <servlet-mapping>
    <servlet-name>binaryFileServlet</servlet-name>
    <url-pattern>/binaryFile</url-pattern>
  </servlet-mapping>

—————

and this to my struts-config.xml for any actions that needed to be able to send binary data:

—————

<forward name="success"         path="/binaryFile"/>

—————

Works like a charm. Leave the JSPs to the character data, and use this simple servlet for binary delivery.

J2ME considerations

I’m working on a project that uses J2ME to display and interact with data from a remote server on handheld devices, specifically cellular phones. We are coding to the MIDP 1.0 specification, because that’s prevalent right now. The MIDP 2.0 will have some nice additions, and I’m looking forward to its widespread implementation. J2ME is nice because it has a lot of the same capabilities as java on the PC (J2SE). The specification states that J2ME is a strict subset of J2SE, that is, any class that is in the J2ME spec has to have all the methods of the J2SE class. The user interface of J2ME is also similar–there are forms, with various items that are added to them (choice groups, which are like radio buttons, and text fields are the main user input controls). In addition, a developer gets all the niceties of java–garbage collection.

While the transition from ‘normal’ web development (servlets, jsps) has been fairly painless, there have been a few hiccups. I wanted to cover some of them. This isn’t a colossal project, but we do have about 60 classes in 10 packages on the client communicating to ~150 classes on the server, so it’s not a stock ticker either.

Handheld devices, and particularly cell phones, are different than the browser. They are much more under the control of the folks who build the devices and install the initial software on them. If you thought it’s difficult to install the new JVM on your PC, try installing any kind of JVM on your cell phone. This means that the carrier (AT&T, Verizon, etc) matters in a fundamentally different manner than the OEM of your PC. This immediately jumps out when deciding on a platform. There are two main platforms out there for cell phones: BREW and J2ME. I don’t want to go into what BREW is here; Colin Fahey does a good job of covering the differences. Suffice it to say that, for both non technical and technical reasons, we decided to pass on BREW for a while. This means that Verizon, the largest US carrier, is off limits to us, as they only support BREW. We’re in the unenviable position of telling paying customers that they have to switch cell phone service if they want to use our app. Luckily, there’s hope for the future. J9 is a plug-in for BREW that will allow J2ME apps to run on BREW devices. However, it’s my understanding that we have to wait until BREW 2.0 is widely deployed to use this capability.

In addition to dealing with different support from different carriers (even with the same handset), developers of J2ME apps also have to deal with developing on a different platform. Only the foolish actually compile applications for a cell phone on a cell phone. They have slow processors, limited memory, no floating point support, etc. The MIDP 1.0 specification only requires you to have 128KB of memory and 8KB of persistent storage! This lack of resources means that you are going to cross compile: work and compile on your PC, download and test on your device. There are a couple of different solutions for this: IBM WebSphere Device Developer [WSDD] (which is based on Eclipse) and Sun’s Wireless Toolkit [WTK]. Each of these also provide an emulator so a developer is not continually downloading to their phone. I happen to have a non J2ME capable phone, so an emulator was a must for me. But, as ever, there are complications. Emulators aren’t perfect, as we discovered the first time we downloaded the application to a real phone. Our application makes a number of network hits to get information. This was working fine on IBM’s emulator, but when downloaded to the phone, the application locked up. After some investigation, it was determined that this was because the phone was asking for user permission to access the Internet, but our application wasn’t well enough behaved to let the phone have the system thread to ask the question. Luckily, this article set us straight. The Sun emulator was less forgiving. So, what I’ve ended up doing is using the ‘best of breed’ solution for each problem. I use vi to edit the source files, WSDD to compile and build that jad (WSDD makes it much easier than WTK), and the WTK emulator to test.

Information architecture is also a different beast on mobile devices. Rather than having 1024×768, 800×600, or 640×480 pixels, a developer has a 150×150 screen (of course, this depends wildly on the phone, but none of the phones I know of get anywhere close to the PC screen). This means that each piece of information must be carefully chosen. If there’s a ton of information, this also means that sometimes one has to break it up across screens. But, one should also minimize network hits and the amount of clicking around a user needs to do. Have you ever text messaged someone? Wasn’t entering text tedious? So, there’s this constant tension between having the application displaying useful information and minimizing the user input needed to get that information. Add to this the fact that we don’t really know how folks are going to use our device, and you have a coding headache. This article has some good suggestions. Of course, Jakob Nielsen has an answer–test it! Put it in front of some actual users and see what they do. And we will. But, when coding for a handheld device, I hold it as a general principle to minimize user input. In addition, there isn’t the nice MVC framework that I’ve grown used to. Instead of having an explicitly defined state machine, our application has a stack of previously visited screens. This works well currently, when information traversal is fairly linear (take me to the information I want!) but I’m leery of what will happen when the application grows more complex. Having each screen ‘know’ where it should go next doesn’t seem to scale very well.

Versioning for J2ME applications is new for me. It is similar to versioning for desktop applications, rather than web applications. I guess I’m spoiled–I’m used to being able to change the application at the server, and have those changes ripple out to all the dumb clients. J2ME is different–since you’re downloading a client to the user, changes to the server need to be coordinated with changes to the client. Not all changes, just those in the interface (which in our case is get parameters and XML over HTTP). But still, when you change that interface, you have four options: leave the old server up and running, break the older apps, have the features of the new server be a strict superset of the old one, or forcibly upgrade the older clients. This is a problem we haven’t faced yet, because we’re still in development. But, I can see it looming on the horizon. And as far as I can tell, this problem hasn’t been solved for the desktop (DLL hell, anyone), and they’ve had a heck of a lot more time and money to throw at it than I will.

The last concern about J2ME that I’m going to touch on today is performance. We haven’t gone through any kind of performance testing, and are still green enough to not have any experience that might guide us. So this section is just questions you should think about, rather than any kind of answers. There are several different types of performance, and they obviously aren’t orthogonal: number of threads, storage, memory, and network trips, and, perhaps most importantly, perceived. What are the limits on the number of threads on a mobile device? What is the cost of the context switches that happen? Should you keep a thread around, or dispose of it when you’re done? What should you store? How often should you verify it hasn’t changed on the server? MIDP 1.0 gives you the ability to store raw bytes–how do you want to abstract this for your application? What’s the speed of reading from ‘disk’? How much memory does your application use? Is it constant, or does it spike? How many new objects do you create? What’s the effect of this on the user experience? How many network trips do you make? What is this costing your user (both in dollars and in time)? How robust is it? What happens when you don’t have a crystal clear connection? How are you communicating with your server? How can you minimize your network connections? What feedback do you give a user when the device is waiting? What can you cache to speed up their experience?

J2ME is very cool, and I’m really enjoying learning more about it. As you can see from above, I’ve plenty to learn. There are several differences that you need to be aware of when doing mobile development in java, and I hope I’ve outlined some of them.