Ethereal (network protocol analyzer) 0.99 is out

Ethereal is a tool I always use when I have any kind of network related problems. Be it a firewall dropping packets, a server that incorrectly sets cookies or even an overly clever application that tries to obscure the exact network resources it uses. Ethereal collects that network data all the way up and down the network stack and all the way into file formats, such as GIFs and XML. And it allows to filter on any of the fields it understand.

Usually Ethereal is updated every couple of months or so, but this time it was nearly 4 months. But the wait was worth it. They fixed a number of problems, made Windows experience just that tiny bit nicer and started to integrate a real scripting engine. They chose Lua.

This last one is a biggie. Ethereal has a lot of capabilities, but people always ask for just one more. Mine was to be able to extract all files of a particular mime-type out of the captured HTTP stream without having to click the payload packets one-by-one.

I have not looked in details yet, but from the example given it looks like it can plug into the menus and have a full interface presence as well as low-level procedure hooks.

Even with Lua being only an experimental addition, I really like the direction Ethereal team is taking. I only wish they actually explained the changed them made to the protocols. It is always nice to see more and more features in the HTTP dissector, but it would be nice not to have to actively hunt for them.

BlogicBlogger Over and Out

The Art of _Technical_ Customer Service

Guy Kawasaki writes about the art of customer service. While all of the points are applicable, he did not take the one about integrating customer service into the mainstream far enough.

He talks that customer service people receiving accolades as much as sales, engineering and marketing. That's great. But what about actively helping them to do their jobs better. Sales have fancy tools to track customers' pipelines, marketing get party budgets, engineers get multiple-monitors and fancy tech toys. Support is lucky if they get headsets that do not suck.

So, what can be done to increase the productivity for technical support people?

• Are all communications with customers logged with specific cases? Usually this is true. But does that case tracking system allows to have files/attachment linked to it? Does it have web view so that both customer and the support engineer have a common history to discuss if the issue gets hairy? Does the case tracking system records every email sent out to the customer or is it an extra burden to record what's happening?
  
• Are there tools/training that would make common tasks easier? For example, what text editor is being used to look at all those log files? Notepad? Shareware textpad? Or has someone actually introduced a feature rich editor (I like Vim) and trained people in how to use it.
  
• Is there a backchannel from support to engineering and/or customer service advocate? This one is extremely important, as there are many things engineers do not have time to think of when the product is rolled out or updated. Small things like visible versioning of release and patches, like locations and types of configuration and log files, like whether the log files produced by the application miss correlation information such as thread id. Similarly, is there a checklist from support to engineering, QA and doc groups on what kind of things the product needs to have/explain so the new functionality is immediately supportable.
  
• Is there a communication forum (mailing list, IM group, wiki) for the support people, especially if they span multiple locations? Given enough pain, support groups will collect the knowledge themselves, but it will be delayed, fragmented and not universal.
  

These things taken together are a pie in the sky, but each one individually is actually within an easy reach with a strong return on investment. I am presenting at JavaONE this year on a similar topic, so if anybody is interested to chat with me about it, I would be happy to meet.

BlogicBlogger Over and Out

Thread: More data, more tools or more answers?

One of my conversations was commented on by Dr Anton Chuvakin. I had replied to him in his comments, but unfortunately he keeps reposting the article to new services without bothering to address the reply, so I am putting it here as a central reference.

Basically, Anton (if I may call him this) thinks that the universe of choices around log file discussion is not just
1. More data
2. Better formatted data
3. More tools to mangle the data

But must also: include
4. More answers to their issues-of-the-moment

He favours the last point much stronger than others and says:

Thus, I think the focus should be on more intelligence and giving answers, not tools.

I happen to think that while his 4th point is great, it is not a concrete, actionable step forward and therefore does not really help the discussion.
Specifically (from my original comment):

...The whole point of tech support is that the answer is not easy to find. Certainly on the 2nd/3rd level of support it is so.

Therefore, what you instead get is a lot of data that _probably_ can lead one to the answer. Unfortunately, if the data is not coherent (parsable, timestamped, thread-stampted, etc), it is next to impossible to find the answer even if one is known to exist.

One of the real examples I had was trying to prove that a particular access did _not_ happen based on 2 Gigabytes of badly formatted, mismatched log files. I have managed to do that but only because I wrote some tools for the task. And even with the tools, it was still up to me to interpret the results correctly and explain them to the customer.

In summary, your fourth point is a goal, while first 3 are possible ways of getting there. Just asking for that 'give answers' solution is like looking for silver bullet.

I would love Anton to comment on this specifically. Maybe he can give a concrete support to his point, as I did before for the point 2).

BlogicBlogger Over and Out

I am now on JavaOne's EventConnect tool

I am presenting at JavaOne again this year, My session is TS-1669 entitled " Unhappily ever after: support, maintenance and troubleshooting of Java applications in production environments "

It covers more topics than the one I did in 2004. It also seems to have been marked as more interesting by Sun. Last time I remember having about 300 people in the room. This time, the earmarked room is for 700 people. I will believe it when I see it. I think they might change it once they had a chance to compare all the presentations.

In any case, I will be happy to push the message out to however many people will show up. But if I catch the interest of any techie managers having to provide technical support for Java applications in the field, I will be very happy. I think there is not enough thought put into making technical aspects of support easy. There are some low-hanging fruits out there for the taking with the results better for both support and developer side of the problem solving proces.

If anybody is coming to JavaOne, I am now on the Event Connect tool and will welcome the introduction/meet requests.

BlogicBlogger Over and Out