Link: The BileBlog, without the Bile

I read Hani's BileBlog incidentally. I used to have him in my RSS reader, but the language makes it hard to concentrate on the arguments (valid as they often are). I still get him through search or topic aggregators occasionally.

So, when I saw Greg Luck's deBilefication and further discussion of the Hani's entries, I read them very carefully and empathised much more with the topic than when I read the original articles.

Perhaps Graig could setup translating service for those of us who do not require our content covered with a colourful language gravy.

I would also love to know where did the 100 types of tests chart came from. I wouldn't mind having one myself. Was it from the linked book?

BlogicBlogger Over and Out

Link: A revenge Zombie is still a Zombie

Frank Carver is not impressed with anti-spam screensaver. I think there is an additional danger beyond just handling the control over to the corporation.
And that is a danger of somebody hacking the communication/update protocol and substituting the list of hosts. And since the screensaver was installed on purpose, user will ensure that all the firewalls are cleared and will ignore any warnings regarding the program.

On the other hand, the download website already seems down. Did someone perhaps repointed their program back at them? Or was it the Slashdot Effect?

BlogicBlogger Over and Out

ReRe: support's view on customers

The internet could be a very small place. One of my clued-up customers is aparently also my subscriber (and vice-versa).

He was wondering why questions from 'intelligent customers' do not go straight to Backline (tier-3) support.

There are several reasons.

First one is that Backline (BL) and Frontline (FL) support (as BEA names tier-3 and tier-1 correspondingly) actually have different strength.
Frontline support is very good on collecting initial information, checking documentation and internal support databases. They may seem a bit information greedy, but often missing a configuration file at the start may lose a lot of time later. Essentially, FL DREs are very good at connecting the 'known' dots.

Backline support engineers on the other hand are much better at the hard problems and at problems with hidden variables. We are also the ones familiar with non-BEA technologies and other developer land tricks.

When I (a BL support) had to do a Frontline engineer's job, I sometimes find out that I miss basic information nugget that would have been collected by a FL support and matched against a known issue. I would get to the same information via replication or source code search which is more general technique, but may takes longer.

In most of the cases, leaving the case to FL DREs until they are ready to escalate is really the best way. Especially, since FL will often bring in a BL engineer behind the scenes to just get a read of a case and confirm the direction taken. That way, the customer still deals with one person, but gets the expertise of two (or sometimes even three) engineers.

The second reason is to do with a field of expertise. A JMS specialist may not know much about certificate signing; an EJB guru is fairly unused to the network issues cases by firewall for remote clients. Support engineers (FL and BL) are trained to be jacks of all trades and even FL engineer is more than enough support presence for a customer working out of his/her depth.

The final reason is simply financial. Higher priced support offerings allow a faster access to senior DREs (FL or BL). Some offerings even have dedicated DREs (at least in their own timezone). Also, the more money goes into the support. the more company is willing to hire additional people to do it.

Finally, just to comment on the support question Dim was writing about, I looked it up. If I found the correct case (from mid 2003), it was actually resolved by me via replication and turned out to be the correct - if not obvious - behaviour with the given configuration.
Customer was frustrated because it took a while to figure the problem out. Why did it take so long? Well, it turned out that I was missing customer's configuration file (config.xml). In absence of it, I followed written down configuration instructions, which turned out to be incorrect on one tiny, but crucial point of JMS file store configuration. A frontline support engineer would have ensured that the config.xml was collected as a compulsory first step.

In conclusion, I am sure that there are good and bad cases. BEA's near future goal is to actually concentrate on making the support better, faster and more proactive. In fact, I have some visibility and influence into the process. If you are a BEA customer and have a real suggestion on how BEA support could be better, put it in the comments.

BlogicBlogger Over and Out

Link: What a difference .1 makes: HTTP 1.1 Persistent Connections

Subbu Allamaraju has written a very good description of the tricks HTTP 1.1 goes to utilise connections more efficiently.

Reading his article makes very clear that persistent connections are quite tricky and developing new code dealing with the topic requires careful thought.

And, of course, troubleshooting persistent connections is quite hard. Ethereal comes quite handy in here, but even that does not know how to extract individual parts of conversations. Does anybody know free tools that work in a network sniffing mode (not proxy mode)?

BlogicBlogger Over and Out