BlogicBlog: View from the trenches

The blog about Java and XML with focus on troubleshooting issues and tools.

Monday, July 25, 2005

Two takes on culture clash of Mainframe vs. Modern skill sets

Permanent article link

C|Net News has an article talking about Legacy (mostly mainframe) skills and how they contrast to the skills developed in the modern world of Linux, Web, Java and .Net.

It is a typical high level article where each word is important, but the whole passage is hard to read.

On the other hand, we have a Slashdot discussion on the same topic from only a couple of days earlier. In there, deep comments are mixed in with just as deep geek humor with the end result of being much more entertaining end educational at the same time.

But only by reading both articles, one gains a good understanding of what the issue is actually about.

BlogicBlogger Over and Out

Sunday, July 24, 2005

Re: Open Source Applications for IT You've Never Heard Of

Permanent article link

Alan Williamson is planning to present about Open Source application that most of people don't know about.

He is also asking the community to contribute their lists. Well, I have three tools that I like enough to mention (again).

Whenever you have to troubleshoot an application with a lot of network traffic, Ethereal is a good tool to keep in mind. It allows to see the network traffic on both high and low level and is flexible enough to narrow down exactly to the information subset needed. And it keeps getting better.
If you are trying to extract some information from an XML file, XMLStarlet is a great way to quickly try several approaches without having to type a lot of XSLT. I have written about it before , but there were some bigger introduction articles written about it later here and here
This is a visualization tool that allows you to build complex graphs (directed or otherwise) from a very simple description language. I talked about it in depth before as well.

All of these tools have just enough of a learning curve, to need an effort to learn them. But once you get over that initial hump, the tools are suddenly very applicable nearly at the daily basis. From my experience, I really would recommend to have a look at them, so that later, when the actual needs arises, you would know that the powerful, open source tools exist to help you out.

BlogicBlogger Over and Out

Friday, July 22, 2005

Link: Users hate apache server

Permanent article link

Ok, so they don't. But there are some bits they do hate and Rich Bowen goes through big issues present in apache's configuration file. Warning, it is a PDF file.

What I find interesting is that we see the full circle feedback in action here. Because the people supporting apache are mostly the same people who are developing (or documenting) it, they have credibility and strength of getting things done. Sometimes, within days....

On the other hand, in a big company the support is done by a separate team, whose only channel of communication is via bug fix requests. From what I have seen, there are no easy channels for a support person to suggest a feature to the developer just because it drives customers crazy. It has to come forth from the developer himself/herself, from customer surveys created by marketing, or through osmosis process where each layer from support upwards feel enough pain to finally pass it on unofficially.

I would love to be proven wrong here. I really would. I have even tried checking all the Safari books on 'customer support practices' to see what they say about such suggestion channel. Big nothing. The support is at the end of the chain and their opinion is not worth listening to.

In the best case, support people can create their own documentation and FAQs to help customers, but nobody would look at it and see whether there is a simple developer level fix to stop a lot of annoyance level issues.

BlogicBlogger Over and Out

Thursday, July 21, 2005

Link: Socket + XML -> hard to troubleshoot issue

Permanent article link

Kohsuke Kawaguchi (Sun engineer working with XML) writes about what happens when you try to read XML directly from a socket stream with expectations of actually writing back to that socket. Specifically, a big nothing. The connection either hangs or dies without sending the response.

Kohsuke gives a clear step by step explanation of why that happens and how to prevent it in the future. If you work with XML, read this article just in case you will run into this in the future. It will save you a lot of troubleshooting time.

Now - after reading the article - the question is how would one figure this out without knowing the XML code backwards?

Since the issue is network related, I would probably start with my favourite multi-tool Ethereal. With the tool running, doing the test case should show that the connection is closed too early by the server. From that point, I would start tracing which bit of code is calling InputStream.close(). Or I would instrument/substitute/wrap the InputStream implementation and do a stack trace dump when its close() method is called.

That's what I would do. I wonder though how Kohsuke did it himself.

Update: I posted this as a question in the original article's comments and Kohsuke answered it.

BlogicBlogger Over and Out

Thursday, July 14, 2005

Some java technical support patterns

Permanent article link

I while ago I was asking whether there are any technical support patterns out there. After all we have architectural patterns and design patterns already.

Turned out that BEA - the company I used to work for - has put together a number of the technical support patterns related to its products. But since BEA products use a great number of base technologies also used elsewhere, the patterns are useful to more than just BEA customers.

Unfortunately, they had put it behind a really long and ugly URL (*cough* BEA Portal *cough*), so nobody knows about. If you ever have to troubleshoot complex java problems, check it out and you may well find it rewarding. There are even some viewlets, or as it is popular to call them now screencasts.

BlogicBlogger Over and Out

Wednesday, July 13, 2005

Link: To blog or not to blog, is there a danger?

Permanent article link

The Chronicle of Higher Education has published an article which argues that a blog is often a bad thing to put on your resume or even to have within a google reach of your name. As a proof, they show a lot of negative things they found out about interview-ready people whose lives turn out to be more complicated than expected.

Perhaps when the person in question is an education professor with plenty of publishing opportunities and the blogs are only for personal aspect of their life, they should not have it listed (or searchable by their name).
On the other hand, for technical people a blog is often the best way to show what we know, what we care about, the problems we solved that might be useful for other geeks to know. And we have enough strange people in our midst with or without blogs that even some technical bile does not change our opinions of people.

At the same time, the article has some strong points about political views, etc. Putting them into the name-identifiable blog is like tattooing your affiliation on a forehead, bound to cause issues. One's choice of course, but a much bigger choice than people seems to realise.

I have my political views, but they are not in the blog. Nor are my food preferences or pet love/hates. On the other hand, if somebody decides to judge my English from the blog, I might be in trouble..... :-)

BlogicBlogger Over and Out

Disk Fragmentation is becoming a bigger threat than viruses? You must be joking!

Permanent article link

In the latest eWEEK paper edition, there is an advertisement that starts with the following: Why disk fragmentation is poised to outpace the virus as the biggest threat to productivity.

And it tries to prove this point by saying that viruses make our computers slower and making users frustrated and that so does the disk fragmentation.

Furthermore manual defragmentation (as bundled in at least 3 versions of Windows) is not good enough because the damage is already done. While can't link to the eWeek's ad, I found an online copy of it.

Now, I don't know about other people but I hate viruses because they

  • Slow down my computer (ok, I may grant disk fragmentation that one)
  • Actively resist uninstall attempts (hmm, defragmentation is never 100% complete either)
  • Can destroy my files or even entire hard drive (disk fragmentation does not)
  • Try to attack other computers (nope)
  • Can steal my data and pass it on to the virus creators (nope, disk fragmentation does not cause this one either)

So basically, the Diskeeper Corporation/Executive Software (because that is who the ad is for) tries to scare people into buying full version of their software for something that is a minor annoyance. And with the ever-increasing hard drive sizes, the issue is becoming smaller and smaller.

I wonder if their sales are falling so low that they are starting to get desperate enough to use these scare tactics. Or is this just a normal part of their Scientology methodology?

Oh yeah, and if you expect any support from the company for the product, you may just find an unexpected complication. Worse than that, in the age of the automated web update, would you actually trust them? After all Germany does not.

BlogicBlogger Over and Out

Monday, July 04, 2005

Viva the solaris 10 supportability

Permanent article link

It looks like Sun is really serious about making Solaris 10 well supported. I am talking about DTrace facility that allows scripting what previously had to be done with truss/strace and a lot of strategic greps.

Better yet, DTrace can hook into Java and trace the function calls across Java and native code alike.

Adam Leventhal talks about this issue and has even presented at JavaONE 2005 with this information.

I am really looking forward to this technology maturing and hope it will be adopted by the Java support teams everywhere.

BlogicBlogger Over and Out

Sunday, July 03, 2005

Links: How to get good customer support

Permanent article link

Couple of articles discussing the customer support and what both sides could do to make it better.
  1. An article from the Mobile Magazine where they called a number of support lines and compared their processes and results from the user's point of view. What is good about this article is that the problems were known and the same for each call, so you could judge for yourself who went through a troubleshooting process and who only had a decision tree to rely on.

  2. A blog entry from Jason Fried, who supports Basecamp, Backpack and Ta-da list. He writes how to get a good customer support by being nice to the support person and providing them with the relevant explanation. The entry also has more than 50 replies elaborating on the issue and providing additional links.

  3. MySQL support page for technical level examples and for additional couple of links to other detailed descriptions.

  4. Finally, if you want to make your own mark, there is a Wikipedia page with the basic information that is crying out to be fleshed out.

For myself, I am starting to wonder if the only people who really get what the suggestions mean are those who had to do some customer/technical support themselves. Until then, it is often hard to understand why you are being asked for the configuration file every time, even if you believe that nothing was changed. (Answer: Often people will change something to try fixing a problem and then change it back but not completely. Everything looks like before to them, but is not anymore.)

BlogicBlogger Over and Out

Saturday, July 02, 2005

Discussion: How should an application's log work

Permanent article link

An oldie but goodie discussion on slashdot about what needs to be done to make sure that application logs are useful to actually troubleshoot problems.

At reading level 4 (as linked), the suggestions actually make sense.

Try a quick test. If you are developing a software which produces a log file, or better yet many log files, how long would it take to extract all events produced by user X between 2pm and 3pm of July 30th?

You need to quickly locate files (where is the location encoded?), extract a regexp defined subset of time (do your log messages split over multiple lines and therefore not greppable?), and narrow it down to a specific user (do you even record that in the logs?).

And that's a basic task. With Java, you also have to deal with multiple threads, which most applications don't bother identifying. If you don't log it, even the most clear event sequences under single thread condition start looking very confusing when multiple threads are running similar tasks at the same time.

BlogicBlogger Over and Out