SQLPlus options

So, for the truly geeky, you can "pass" in parameters to alter the default environment/behavior of sqlplus. The orafaq page helped me figure this out:

• create a login.sql file for all your commands
• add the directory to the $SQLPATH env variable (on most client machines, you'll need to create the env var)
• launch sqlplus, and you should have all your options setup

My current login.sql looks like this:

define _editor=emacs

set timing on

set serveroutput on

set colsep '|'

set linesize 120

Like I said, for the geeky, but damn handy when you don't want to muck with and IDE like TOAD.

IBM J9 Diagnostics

Here at $DAYJOB we're using the IBM J9 JVM for our test and production deployments. I've had some performance and memory problems recently, so here's a quick entry about some of the things the J9 JVM provides for diagnotics.

First up: the diagnostics documentation summary.

Next, here's a series of things you can get the J9 JVM to give you:

• GC log - use the standard -verbose:gc command line option to get an XML file dump of garbage collection activity. You can set the output directory,
  
• Heapdump log - generated when you call it explicitly in your app, or more likely, automatically when you have an OutOfMemory condition. *.phd files are created which are not human-readable
• Javadump log (a/k/a javacore or thread dump) - contains human-readable data on the the operating system, the application environment, threads, stacks, locks, and memory. Creates files starting with javacore...text
  
• System dump (a/k/a core dump) - typically only produced when the jvm fails unexpectedly. Log contains active processes, threads, and system memory. Creates files named Snap*.trc

Regex for parsing HTTP query string

Instead of using lame-ass StringTokenizer looking for an ampersand, here's a regex I found handy:

((\w*)+)(=)[\w\d]*[^(\&)]

The extra parens around the first part token allow you treat the parameter name as a group by iteslf. Could've added it it to the value, as well, I suppose .... but clearly I don't need that now!

Erlang records

Erlang progress update: I've been sidetracked by working on some Java reflection for $DAYJOB (not bad/unfreindly stuff, just needed to work through it), so I'm now back on my side project. Working through Joe Armstrong's book, I'm now looking at Erlang records (pg 69+). Records seem like a cool to add names to tuples so you end up with something that feels like a name-value pair map or, if you take the analogu further, almost like an object. Granted the tuple is just a linked list, and I'm not sure of the implementation of a record, if it keeps an index of pointers to each named tuple 'field', or anything like that (yeah, I coulda google'd - its still early though), but still, a handy feature for OO folks.

Java Annotations and Proxies

Just discovered this: If you create a class with annotations of any kind, those annotations (and any other metadata) is lost when the object is proxied. Google searching didn't turn too much on the subject, but I did find this post about one work around (but it only relates to Hibernate). This seems sort-of innocuous on the surface (from a language/API level), but with every framework under the sun using reflection/proxies to add real value, this really does suck.

Any suggestions would be greatly appreciated. So would free cocktails....

UPDATE: OK- here's what I've now uncovered. In my original case, I was getting a bean via Spring and was trying to get the annotations by simply reflecting on various methods - no dice. In my real world case, however, I am looking at the target object via an aspect (meaning, I am inspecting the invoked object while in the aspect code). From the ProceedingJoinPoint object that is a parameter into my aspect method, I can see all the annotations.

I think I still need a cocktail...

Erlang "processes" clarified

Now that I'm into erlang, I've been going through the Getting Started guide on the erlang.org site, and I found this little nugget:

the term "process" is usually used when the threads of execution share no data with each other and the term "thread" when they share data in some way. Threads of execution in Erlang share no data, that's why we call them processes.

I was always confused about erlang "processes" - if they were full-blown executable VM and OS-level processes or what have you. It's getting clearer now...

New Project - Erlang E-commerce

Well, now that we've moved to California (Sept 2008), and things are finally settling in, I'm looking for a new project to play with. At the end of long conversation with a current coworker, Steve Atkinson, about concurrency and the bear that it can be to wrestle with (especially in regards to shared state) I admitted that I'm interested in seeing how the new crop of functional programming languages deal with these types of issues.

So, to jump on a bandwagon (that's probably already left the station), I've decided to started exploring Erlang. What I want to do is create a small e-commerce style of application to see how the non-shared state model deals with the state of objects/entities like "customer", "order", and "product" over the lifetime of the application. I suspect my point of departure will look like a typical Java web-app (it's how I pay the rent), but am hoping to divert into something more or a true erlang app (whatever that may be). Further, since I have absolutely no background in functional languages, this should be a good learning and growing experience.

I'll try to jounal as much of the interesting details, thoughts, and ideas as I go along. However, we're expecting our second baby in about six weeks (holy cow!), so I'm not sure how much progress I'll make in the spring or summer. Either way, I'm hoping to gain another perspective on this whole programming thing...

Creating a Java annotation

So I created a new (method-level) annotation that basically just takes a string, and when the target method is invoked, via aspect I get that string. The annotation looks like this (name changed to protect the innocent):

public @interface Annotatable { String value(); }

After a few hours of banging my head, trying to figure out why everything compiled correctly, yet when testing I could never get the find the annotation on the target method. Turns out, this was soooo poorly documented by Sun/Java gods, you need to annotate your annotation, like this:

import java.lang.annotation.*;

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
@Inherited


The RetentionPolicy enum tells the compiler to keep the annotation around AFTER you compile, instead of throwing it away (like it does by default). The Target annotation tells the compiler which types of elements your annotation can apply to (classes, methods, params, all, etc.). The long and short of it is: don't forget to annotate your annotations.