Pell-mell to Hell

I just checked Google News before heading to bed and was confronted with this:



It reminded me of Collapse: How Societies Choose to Succeed or Fail by Jared Diamond.

Will we destroy the biosphere to the point where it can't sustain us before we learn to appreciate the consequences of our actions?

I fear we will.

Macintosh: Apple and O'Reilly Safari Bookshelf team up

Well, Apple has teamed with the O'Reilly folks to offer a Safari-style subscription service for searching and reading 1000 Mac-related books online.

Brad Shuler told me about nine months ago he thought such 'online bookshelves' were the wave of the future. I mostly dismissed the idea at the time, probably because I like reading a physical book and find I absorb the material better that way. I think I was wrong. Given the high cost of printing and the speed at which the software market is changing, I think this is the wave of the future, even if I don't want it to be.

Walking: Full keyboard access on a Macintosh

So, a number of people have commented about the inability to navigate GUI's completely via the keyboard (without having to use the mouse). I don't find using the mouse that much of a burden, but there are times (especially when filling out forms in websites) that I'd like to do things like pick my state from the choice/combobox without having to go to the mouse.

It turns out you can turn on "full keyboard access" on the Mac and do this. It's available in Mac OS X 10.3 and for all I know it was there in earlier versions as well. If you open the System Preferences and choose "Keyboard & Mouse", there are three sub-panels labeled "Keyboard", "Trackpad", and "Keyboard Shortcuts". If you navigate to "Keyboard Shortcuts", there is a checkbox at the bottom that says "Turn on full keyboard access". If you check this, you can navigate menus, lists, etc. using the keyboard.

Brad Shuler told me that Weiqi Gao blogged about wanting this but I couldn't find the relevant blog entry. Brad also told me there are more fine-grained control options available under Tiger (10.4). Maybe he'll describe them in his blog.

Society: Can you pay for your health care?

A study (published by Reuters in the U.K. but not in the U.S. as far as I can find) shows that a patient's success getting follow-up care after an emergency room visit for a serious condition was determined primarily by the quality of their health care plan.

So if you thought that America has great health care, it depends on how much money you make and the job you have. The 45 million (>15%) people without health care insurance get a raw deal. Those with Medicaid don't do much better.

History: What a Day

Today is a very diverse history day. For example:

It was on this day in 1638, a young clergyman, just 31 years old, died in Massachusetts, and in his will, left his library and half of his estate to a local college. To honor his memory, the college changed its name. The clergyman was named John Harvard, and the college changed its name to Harvard University, and it's the oldest in America.

And that's just the start. Go. read

Walking: Paper-like displays

I've been following the research into "paper-like" displays for at least ten years now. My dream is to have a display that is essentially an unrollable scroll. It would be like paper or thick plastic, have a high contrast display, allow for large 'paper' sizes (e.g. a 17-20 inch high-definition display) and consume little power (to make portable computer batteries last as long as possible).

This article suggests that we are finally getting to the point where the very first of these sorts of devices will be practical. It's quite a bit smaller than I'd like, and it's only 4-gray monochrome, but if it actually makes it into production it would be a good start.

Of course, I've seen predictions of commercial products like this coming "in one or two years" for at least the last ten, so I'm not holding my breath.

Admin: Getting a picture again

It turned out to be much more difficult than I expected to get my picture back on the blog profile. It's done now, but it wasn't straightforward. I had to dig through HTML source and find the 'true' URL for the image stored on Flickr. Flickr uses JavaScript to obfuscate (perhaps unintentionally) the image so Blogger doesn't like it. You have to dig and find the 'normal' .jpg URL.

Admin: Trying to get a picture again

BrianSmiling.jpg
Originally uploaded by icebrg.

I lost my picture. So I'm trying to use Flickr to get a photo online that I can use in my blogger profile.

A Belated Mother's Day Offering

I am only mediocre when it comes to being a good person. I don't think I'm a bad person, and I think I've never done anything particularly terrible, but since even sociopaths feel that way I know that's no compass for moral values. My wife, on the other hand, is an amazingly good person. How she manages to see through the frustration and temptations of life on a day-to-day basis I find unfathomable. She knows she's not perfect, which I am constantly forgetting, and still manages to see the best in others, despite the pell-mell pace of our lives and the concerted efforts of fools to find her last nerve.

That doesn't mean she fails to spot the fools; she just manages to view them as human despite their (sometimes considerable) flaws, while I tend to write them off and continue my blissful and fruitless search for moral fortitude in the modern world. And I know that she would credit much of her world view to her upbringing, in particular to her mother.

I have to agree with her. My mother-in-law is one of the most nurturing, kind-hearted people I know. She has a bedrock of morals that amazes me, and I'm rather too jaded to be easily amazed (okay, 'cynical' is more appropriate, since I'm not nearly experienced enough to call myself jaded). I know it's my duty as son-in-law to hate her, and while I might have been inclined to skip it just because I'm contrary, I didn't need to.

I know I'm incredibly lucky to have fooled my wife into marrying me, and just as lucky to have a mother-in-law I love and who I believe loves me in spite of myself. I suspect I'll not live up to the love and devotion of either of them, but they inspire me to be the person they see in me.

Tinkering: Bash and Subversion 2

It turns out that just doing -W with the names of the options to svn ends up disabling the normal file name completion. This is rather painful when you want to do things like type 'svn add ' and hit tab to get a list of files you might want to add to the repository. To fix this, you have to specify the -f option after the -W option, like this:

complete -W 'add blame praise annotate cat checkout co cleanup commit ci 
copy delete del remove rm diff di export help h import info list ls log merge 
mkdir move mv rename ren propdel pdel pd propedit pedit pe propget pget 
pg proplist plist pl propset pset ps resolved revert status stat st switch sw
update up' -f svn

This turns file/directory completion back on, which is good, but leaves all the svn commands (like help, diff, etc.) still in the list of completions even after you've provided a command to svn, which is bad. If anyone knows how to make bash only list file/directory completions when I've already specified the command for svn to use, I'd love to know.

One other handy thing in bash is the FIGNORE environment variable. This variable is a colon-separated list of names to ignore. So, setting it to ignore the .svn directory is as simple as:

export FIGNORE='.svn'

Of course, if you already have things in FIGNORE (e.g. the .ssh directory, the CVS directory, etc.), you will need to append .svn to the list.

I'm really looking forward to full integration of Subversion with IDEA, but even after that comes about, some things are just easier on the command line and this makes them even easier.

Tinkering: Bash and Subversion

Bash has a very handy and (as far as I'm concerned) obscure feature that allows you to specify completion words for commands. This is useful for providing some brief feedback when typing a command line. For example, you can specify the completions for the 'svn' command like this:

complete -W 'add blame praise annotate cat checkout co cleanup commit ci 
copy delete del remove rm diff di export help h import info list ls log merge 
mkdir move mv rename ren propdel pdel pd propedit pedit pe propget pget 
pg proplist plist pl propset pset ps resolved revert status stat st switch sw
update up' svn

This is great when you type 'svn' and then hit the TAB key to get a list of possible completions.

I wish you could specify completions for secondary commands. This would allow me to specify the options for the 'svn commit' versus 'svn diff' versus every other svn command. I hope I've just missed how to do this (despite trying some of the more obvious possibilities). If so, please let me know how it works.

Thinking: Runtime Geography of a Java VM

Alex Miller read about my notion of runtime geography and posted some excellent analysis. As I've thought about it more, I agree that the notion of runtime geography is more intuitive and feels more general than the notion of an ontology, so let's run with it and see where we end up.

If we think about locating things on a map, there are numerous types of things, and their locations can be specified in a variety of ways. For example, we have towns and cities, which have a name (not always unique) and occupy a particular area centered on a point that we can specify with a longitude and lattitude. We can also talk about things in a relative manner ("Chicago is about 350 miles north-northeast of St. Louis). We sometimes want to find things based upon nearness (Where's the nearest pizza place that delivers?). We can also talk about roads, rivers, right-of-ways, etc., all which follow a route (which is usually specified by a width and a series of points specifying its path).

So, if we're going to have a runtime geography for the objects in the VM, we have to solve several problems and answer a number of questions:

• What are the various dimensions used to create the space? Anything that might be a dimension must be something for which we can directly assign a value to an object, or one for which we can derive a value for an object based upon some affiliated/associated object.


• How do we make the geography available to Java code? Once we've come up with some definition of the runtime location of objects, we need to be able to assign a location to an object and we then need to be able to specify a location or region to locate one or more objects.


• How do we avoid conflicts with other ways of organizing objects in the VM? There are at least two ways to define a 'location' for an object at runtime today: the ClassLoader that loaded it's class and the package it is defined in. We might be tempted to include the Thread(Group} which is executing code of this object, but this has the problem that (a) it is transient and (b) it can result in multiple locations for the same object. We should leverage these if possible or at least not clash with them.


• How does our solution fit into a distributed system? There are many situations where multiple Java VMs communicate with each other. Should the runtime geography be a purely internal thing which is never exposed outside a VM, or should we expose it and use it across VMs?

To make the whole discussion concrete, I'm going to focus on two particular uses of a runtime geography that are fairly different from each other. While I hope a well-conceived runtime geography will be applied to many problems, these two seem like a good start:

• Dependency injection at object construction time - finding objects required by the constructed object based upon where in the program the object is created


• Location-dependant logging - specifying different logging levels for the same kind of object used in different locations in the program. For example, assume StringTokenizer produced logging messages for your favorite logging API. If a JDBC driver and some user-written piece of code in the same program use a StringTokenizer and you want to crank up the logging messages for StringTokenizers 'inside' the JDBC driver but not 'inside' the rest of the program, how can we use runtime geography to do this? What if we want to crank up all logging inside the JDBC driver?

In addition, we should meet some design goals:

Make things as simple to use as possible.

Make the description and use of geography easy to understand - in particular, draw upon the analogy of real-world geography as much as possible.

Put information in as few places as possible - avoid multiple configuration files that all depend upon each other and which depend upon magic strings or magic numbers. Of course, this can compromise the utility of things if we overly restrict the facility, so we need to 'right-size' it.

Geography locations should be defined at compile-time, just as in real-world geography. This is essentially saying that objects won't change their location during runtime. This might conflict with use in a distributed manner, but seems like a good simpifying assumption, at least for now.

It should be possible to specify the 'query' used to navigate the geography both at compile-time and at runtime.

Don't conflict with other ways of defining object location.

This feels like enough to start mashing ideas together. Now it's time to do the serious thinking... :-)

Thinking: Dependency Injection and Runtime Geography (2)

A friend of mine responded and asked how I envisioned solving the problem of runtime geography. I don't have an answer yet. To me, identifying the 'true' problem is valuable because now I can search for solutions to the problem and know what I'm looking for, instead of just having a vague sense that something is wrong.

I don't think annotations are the right thing to do, because they are also compile-time entities. That might be somewhat helpful compared to the Java package/name hierarchy, but probably not by much. Instead, I think we need a way to categorize objects and group them at runtime. ThreadGroup is an example of doing this for threads, and that might be useful in some manner here (perhaps using annotations to instantiate thread(group)s which are marked differently). But that is focusing on the geography of the execution threads. I think we also need the means to map the geography of the objects and their state and references.

Annotations in 1.5 don't let you assign annotation values at runtime. That's essentially what we need. We need the means to annotate information on objects independently of their class at runtime.

I haven't found a means to do what I want yet. I'm looking for it. It may not be possible in Java as it exists today (though I'm going to keep looking in hopes of finding a means to do this). I am not a fan of Aspect-oriented programming, but AOP might provide a means to augment normal objects with this runtime capability.

Of course, there are two parts to the problem: (1) how to annotate objects in a manner that creates a runtime geography and (2) how to utilize that runtime geography to solve a particular problem, like dependency resolution.

Thinking: Dependency Injection and Runtime Geography

I recently attended a St. Louis Java User's Group meeting where Alex Miller discusssed the various forms of dependency injection. It was a great talk, and it got me to thinking.

I believe the problems we have with dependency resolution (which dependency injection attempts to solve) are not the real problem, they are the symptom. The real problem is that we have no ontology* for a running Java program except for the static package/class hierarchy. There is no practical mechanism for identifying objects within a running JVM, such that we could then describe how those objects should find things they depend upon (for an example of a failed attempt to do this, check out the Java Beans Activation Framework).

When I instantiate a "Widget" object, there is no notion of geography in the JVM. As a result, there is no way for me to say that the Widget instantiated "over here" should use the "Cog" object "over here", while the Widget instantiated "over there" should use the Cog object "over there". The problem is that there is no notion of "over here" or "over there" within the JVM. The general problem of no geography leads to specific problems like dependency resolution, when you want to reuse the Widget class and need to resolve dependencies the Widget has when instantiated. It's particularly difficult when you might have more than one Widget in the same running JVM and need them to use different dependant objects.

Essentially, we need a good ontology for objects in a JVM, and the one we have, the fully qualified class name, is completely inadequate since it is a compile-time characteristic.

We don't need dependency injection solutions. We need ontologies to describe the objects in a running JVM. This will make solutions to dependency injection trivial. It will also facilitate lots of other useful things, because it will give us a runtime geography that allows us to describe (and therefore group) objects based upon their 'location' in the JVM at runtime.

Now all we have to do is figure out the right runtime geography/geographies to support.

*The hierarchical structuring of knowledge about things by subcategorising them according to their essential (or at least relevant and/or cognitive) qualities. --The Free On-line Dictionary of Computing, © 1993-2004 Denis Howe

Walking: Java Object Persistence

I went to a presentation of the St. Louis Java User's Group tonight where Patrick Linskey of Solarmetric talked about advances in object persistence and some things coming soonish. He gave an overview of issues surrounding object persistence, discussed Java Data Objects, and went on to discuss the current collaboration between the Enterprise JavaBeans 3.0 working group and the Java Data Objects (JDO) 2.0 working group.

I've worked on this problem in the past, but it's been years since I took a serious look at the state of the art. Things have gotten much nicer than they used to be. It's time to go tinker...

Walking: Social Security (4)

Well, for a clearly reformist website you can check out the Heritage Foundation's 'Social Security Reform Center'.

It's amazing to see how much spin this issue is generating. Everyone is busy pushing their agenda and using inflammatory statements. For example, many people describe Social Security as bankrupt because in thirty or forty years it can't pay benefits as paid today. This is a rather interesting definition of bankrupt. Similarly, some of the retirement-oriented websites are squawking about how there is no crisis and there's plenty of time to reform things later (especially since the audience they are targeting will be dead by then, I suppose).

Sigh.

Walking: Social Security (3)

Over on Brad's World, Brad Shuler expresses skepticism about some of the plans being discussed for private savings accounts as a reform for Social Security. I agree with Brad's assessment that these plans seem to assume it's okay to rack up additional deficits in order to get people off of Social Security. The basic premise seems to involve a two-pronged approach to the problem:

1. Get people off of Social Security - this is generally via private accounts
2. Cover the future shortfall for Social Security (due to all those people not paying into it any more) by deficit spending

I think it may be possible to avoid the deficit spending if we reduce benefits in some minor ways. For example, if we change things so you begin receiving Social Security 10 years prior to your life expectancy (instead of at age 65), it would greatly reduce the Social Security shortfall for the future. No one seems to be talking about this though, probably because they don't want some retiree advocacy group to drop a cluster bomb on them...

Even more troubling are the recommendations in some of the plans to tie increases in Social Security benefits to cost-of-living increases instead of wage increases. At first, this seemed like a reasonable idea to me. Then I read an article (which I now can't find) which pointed out the problem: if the creator's of Social Security had tied increases in benefits to cost-of-living instead of wage increases, Social Security today would not provide enough money for its recipients to have electricity or a telephone. Yes, it's true. Most people had neither when Social Security was formed. And a cost-of-living index would not have adjusted for the change in living standards that has occurred in the last 70 years. Imagine living without electricity or a phone today, and you can see why a cost-of-living metric is a built-in problem for the future.

Walking: Social Security (cont)

Well, the information about Medicare is on a completely different website. I still need to peruse the documents from the trustess describing the state of Medicare.

This business of predicting how the finances of these programs will fare in the coming years is becoming more and more murky. Everyone has their own set of estimates and simplifying assumptions. I think I'm going to stick with the offical numbers and estimates from the government websites when coming up with my estimates.

Walking: Social Security

Well, the Internet is clearly still a work in progress. I've been researching Social Security and trying to educate myself on the various proposals starting to fly around for reforming it. Google is my friend of course, but there are so many sites that get hit with only slightly different queries. I hope to publish something a bit more formal over on The View From the Fringe soon.

In the mean time, here are a collection of links related to Social Security I've found interesting and useful:

• The Social Security Administration. Of particular interest are the 'Actuarial Resources' (e.g. what does the financial future for Social Security look like?)
  
• A rather interesting article describing just how poorly many Americans are saving for retirement.
  
• The Century Foundation has a site dedicated to Social Security reform. I can't yet tell where they fit into the political landscape but they make some intersting points. Still trying to figure out the types of charged particles here.
  
• I haven't yet read President Bush's position on Social Security, Retirement Security, and Medicare
  
• The Cato Institute, a conservative thinktank, always seems to have something to say. So it's no surprise they have a big site about Social Security reform. Lots of charged particles that are useful, as long as you account for their spin.
  

I'm sure I'll find many more.