JavaOne 2006 Submission: Logging with java.util.logging

Since I spent sometime a couple months ago putting together a presentation on logging in Java, I thought I’d submit a proposal to JavaOne this year. Here’s the proposal I wrote up:

Title

Logging in Java ™ with java.util.logging

Abstract

This presentation shows you how and why to use the logging API that’s
bundled in the core J2SE library. You’ll learn the basics of logging
and configuring, advanced logging and configuration, how to tailor
logging to your needs, and best practices for logging.

We’ll go beyond the standard documentation available in the J2SE and
on the web, using plenty of examples to explain pragmatic ways to
quickly and effectively use the logging API in your code.

The built in logging API has been available in the J2SE for several
years, but consistent and knowledge use of this API is sparse. This
despite both the richness and simplicity of logging, not to mention
the consistency and portability benefits of using the bundled logging
API.

Logging is vital for both quick debugging during development and once
your software has been deployed onto hosted servers or in the field to
customers. Oftentimes all that stands between you and hours of
debugging over the phone is the ability to quickly use logging to
diagnose problems remotely. Attending this session will help save you
from those tedious and costly hours, keeping you and your customers
happy.

Presentation Summary

The presentation follows the outline below:

What logging code looks like

A quick dive into what logging with the logging API actually looks like in
code and as output.

When and why to log

Why programmers should bother to thoroughly put logging in their applications:
the primary reason being that once your application is run in a non-developer
environment, in production, it becomes almost impossible to debug. As a result,
customers get frustrated as problems take “forever” to fix, and companies spend
too much time and money diagnosing problems in the field.

The Logging API

This section introduces the different concepts in the logging API: log
levels, the different log messages, handlers, formatters, etc.

It also covers best practices in logging, such as when to double check
the logging level for performance, using argument’ed messages, logging
exceptions, and how to determine where in the code to log.

Finally, this section covers how to configure logging using the
default flat files, at runtime, and with the newly available logging
MBean. Knowing how to properly configure logging, especially during
runtime is an invaluable skill.

This section contains many code examples that illustrate the points.

Customizing Logging

This section covers the customizations that can be made in the logging
API, such as custom handlers and formatters, as well as some
extensions to logging, such as context loggers that take care of
logging tedious to code, but vital to debug, information.

A brief section covers using Aspect Oriented Programming to help weave
logging in; pit-falls of an AOP approach are also covered.

Logging Grab Bag, Tip and Tricks

The last section collects together a “Top 10” style list of tips and tricks
with the logging API.

If you’re interested in taking a look at it, there’s a draft of the presentation available.

And, of course, if you’re interested in me giving the presentation, feel free to contact me and we’ll work something out: I’m sure it’d be fun ;>

Tags: , , , .

Opportunity

It turns out “opportunity” has only positive connotations. I was joking around about the econobonics/biz-slang use of opportunity — e.g., “every bug we get is an opportunity to improve our code!” — saying something like, “that assumes every opportunity is positive.” Meaning, there could be some negative opportunities, like the opportunity to jump off a bridge.

But, hold on, Skip, old m-w.com says that “opportunity” means:

1 : a favorable juncture of circumstances <the halt provided an opportunity for rest and refreshment>
2 : a good chance for advancement or progress

So, you see, opportunities are always good. Now I need to figure out some antonyms for opportunity. Anyone got some good ones?

Tags: , .

Who is this Mike Guy?

As many of you, dear readers, probably know, I go by the name “Coté.” Most people who meet me for the first time don’t know this, and they favor calling me “Mike.” Now, before the big name switch over (back in the FX days), I used to go by “Michael” (my first name). I’ve never gone by “Mike.”

35,226 Michael’s Agree…

Oddly enough, and pointing to the reason I go by Coté instead of Michael, my uncle’s name is Mike. So, you see, Mike was never an option in the family ’cause then there’d be two of us. To make it worse, I’m a junior, so my dad’s name is Michael. And, since Michael was the most popular first name in the 70’s, in any room full of Americans, you’re likely to find a few Michael’s.

That’s why I go by Coté: there aren’t many of those running around…used as the “first name” that is.

Name Meta-info

As I’ve pointed out to a couple people, all this leads to some interesting meta-info you can get from what people call me:

  • People who call me Michael are generally people I’ve known all my life like people who’ve known since junior high or high school, or my family. They started out calling me that, and they don’t really call me by our last name. That’d be kind of weird, not to mention, confusing.
  • People who call me Mike either (a.) don’t know me, or, (b.) are named Mason Carroll or Kim Skotak (the one who’s my wife). Kim does it ’cause it’d seem kind of weird, I’m told, to call me by my last name. I have no idea where Mason picked it up. It must be some West coast thing.
  • Interestingly, most people who don’t know me don’t call me Michael. There must be some assumption — or unconscious drive for verbal efficiency — that the short hand of Mike is what most Michael’s go by.

Tags: , , .

Paperful Offices

This 2002 piece from Gladwell about the paperful office is fascinating. The master of the counter-intuitive lays out why piles of uncomputerized paper are better than computerized paperlessness. The key is that the original content on paper is only part of the knowledge you’d need to capture. Much of the rest of it is locked up in the margin, in the way the paper is organized, how old it is, what it’s filed with, and what memories the actual physical papers evoke in people’s heads:

The correspondence, notes, and other documents such discussions would produce formed a significant part of the documents buyers kept. These materials therefore supported rather than constituted the expertise of the buyers. In other words, the knowledge existed not so much in the documents as in the heads of the people who owned them — in their memories of what the documents were, in their knowledge of the history of that supplier relationship, and in the recollections that were prompted whenever they went through the files.

(Via Koranteng‘s bookmarks.)

Tags: , , .

Re: Of Everything You Know to be Right and True, Only Some Is

That’s a nice post: it ads variety to the blog. If there’s one thing refreshing to encountering in The Industry, it’s when someone connects out to The Rest of the World, instead of staying all clogged up in Bytelandia.

Wasting Time With Truth

Here’s one thought I was having:

No, the problem is rather the degree of conviction – the inability to take that step back, evaluate a given argument thoughtfully, rationally, and – should worst come to worst – concede a point lost.

The end result of all my philosophy studying in collage was an extreamly strong conviction that beyond “physical truths” (gravity, chemistry, and what we call “natural sciences”) there really isn’t much truth to hang things on. Point being, that spending your time fretting and arguing about what you should do based on The Truth of the Matter is time wasted, because there is no truth of the matter: there’s just the context that feeds into that process where you “take that step back, evaluate a given argument thoughtfully, rationally.”

Some people get all uppity at this point and start flailing about with words like “moral relativism” and, when they get real desperate, Hitler.

To all that, I pretty much say, “yeah, when you fall off a sky-scrapper, gravity sure does suck, doesn’t it? But it’s not like you getting all upset and trying to argue that it doesn’t exist as you’re hurtling towards the pavement is going to save your head from turning into pumpkin pie.”

That is, to me, the fact that there are no moral truths is an inescapable truth, regardless of the consequences. Instead of worrying about the consequences, it seems more reasonable to start figuring out how to go on living life, e.g., by metaphorically putting fences up around sky-scraper roofs so people don’t fall over them.

Absurd Rationality

Being overly rational can, of course, lead to as much zelotry as being overly-supernatural. One of my friend’s father’s was for barring gay marriage because:

  1. people should be producing off-spring.
  2. the point of marriage is to produce off-spring.
  3. thus, the government and society provide incentives for people to get married.
  4. providing incentives costs all of us money.
  5. thus, supporting marriage between people costs us money. But, because they’re producing off-spring, it’s worth the money.
  6. Two people of the same sex cannot produce off-spring.
  7. Thus, if two people of the same sex were married, no off-spring would be produced.
  8. And yet, these two people of the same sex, when married, would benefit from all the incentives the government and society give married couples.
  9. But, the two people of the same sex can’t produce off-spring, so they’re cheating the system: they’re not living up to their part of the deal.
  10. We can’t have people cheating the system.
  11. Thus, two people of the same sex should not get married.

As with all well laid out arguments, the logic connecting the ideas is just fine. Logic is a slippery-fuck in that regard: it’ll easily lead to whatever conclusions you set up for it. The problem is with all the parts between the logic. Thankfully, the argument at hand is weird enough that you can rely on your Blinkstincs to figure out it’s silly, and move on without much more though.

Unfortunately, other complex systems of morals, derived from rational thought aren’t so simple to disentangle. And some of them front-load on rationality, luring in converts, and then go all nutty.

Technorati Tags: ,

[DrunkAndRetired.com Podcast] Episode 30 – Intuition, Java Profiling, Austin Straight Razor Barbers

In this episode, we talk about Charles’s intuition experience of late, java profilers, and getting a good shave in Austin.

If you’d like to leave a voice comment, please call +1-512-879-6339 (it’s a US number) or Skype us at drunkandretired, and leave some voice mail. Otherwise, you can email comments to comments@drunkandretired.com, in the comments field below, or by talking directly to one of us bozos.

Also, check out the new episode of the quick and dirty DrunkAndRetired.com podcast: Gravy.

(This episode edited by Coté)

Tags: , , , , , .

J2SE 5.0 Upgrade on OS X Breaks XSLT

I updated to the new Java release on OS X today, and it broke my use of XSLT in Java. From what I’ve read, J2SE 5.0 no longer sets the system property that tells JAXP which TransformerFactory to use. This, of course, seems kind of silly. I’m sure there’s some long, drawn out explanation of why: the upshot is that shit don’t work for me.

To get around this, you have to pass in the following system property to all your Java processes that are going to be running XSLT:

-Djavax.xml.transform.TransformerFactory=com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl

This bug report from maven has some more detail.

Tags: , .