I like giving maps descriptive names, usually of the form keyToValue, such as "userToStatus" or "blogIdToUrl".

http://en.wikipedia.org/wiki/Law_of_Demeter

Keep your methods simple. If they get too complicated, break them into smaller methods. This improves readability and testability. As an added bonus, stack traces become more specific and more useful!

You can write literal longs by just using the 'l' or 'L' suffix. "long val = (long) 42;" is uglier than "long val = 42L;", although the compiler is probably smart enough to sort this out.
Don't iterate a maps keys, then look up each key in the map. Using the for-each loop on the entrySet is cleaner and faster.
I'm a big "final" fan. Use it everywhere you can.

I'm not fond of the PacMed cafe. After staying home sick for two days after one particularly bad meal, I'm wary of it. That being said, the cafe here does give me one thing that has never been provided to me by any Bellevue employer: a view of the Olympic Mountains and Puget Sound. For me, "mountains over water" is pretty much the definition of scenery. My new office will be West-facing, so I should have a pretty good view of the clouds rolling and oozing over the mountains with a simple comforting elegence, like a blanket that wants to crawl over your sleeping form and wrap you, cozy and comfortable.

There's a certain simple beauty in clowds and storms, a combination of power and elegence that makes the blue-sky "beautiful" day look as boring as a blank canvas. I can enjoy natural or computer-generated complexity and chaos, but these things in human-crafted art tend to annoy me; if I wanted to rely almost entirely on my own intepretation to imbue structure and meaning onto an external medium, why should I waste time with art?

I've enjoyed Final Fantasy XII a LOT, but the fun is starting to pale a little, now that I'm at the last savepoint stage where you run around doing all of the sidequests and hunts. Perhaps I should just finish it off so that I can spend more time on projects, like finally getting a caprenter to cover the furnace or swapping out the "server" machine or doing something useful with my website or ...

Yeah, I'm pretty close to my manic phase again.

My pudge is fading and Kyna says that my butt is less flat; this urban "walk or take the bus, but hardly ever drive" lifestyle is good for me. The Stranger had a link to this article about links between urban sprawl and obesity.

Did anybody else hear about the Boy Scout Troop being blamed for a wildfire in Utah. This article makes their behavior sound irresponsible, unjustifiable, remorseless ... exactly like adolescent boys. They were campling without adult supervision: "17 Scouts, ages 12 to 14, being supervised by two 15-year-olds".

I don't remember any major outings without any adult leaders. Honestly, I'd be surprised to discover that this wasn't an egregious violation of many, many official Boy Scout policies. You don't leave 15-year olds as the only supervision for 12-14-year olds when they are outnumbered 8-1 - that's how you end up recreating Lord of the Flies.

Finally, the best political rant I've seen about Bush's "surge" Bush exercises the Cambodia option in Iraq.

I, like many other developers used to more dynamic languages, have often been frustrated with code that first initiales something, then goes through a long sequence of steps to get it into the initial state.

Map data = new HashMap();
data.put("Hello", "world");
data.put("Spam", eggs");

In Python, Perl, Ruby, JavaScript, and many other languages you can logically create a mapping and set its values in a "one-liner". Even if this actually spans several lines, this "initial state" code is cleanly separated from any business logic within the same method. Inline definition also helps for setting up complicated objects as static values or class properties, without relying on a constrcutor or other bootstrapping at a separate location in the code.

One interesting solution for Java I recently saw on a mailing list uses a feature that has been present in Java since 1.2: anonymous inner classes. Our example now becomes:

Map data = new HashMap() {{
put("Hello", "world");
put("Spam", "eggs");
}};

Note that this technique works for almost any Object, so it is also useful for "initializing" a Java Bean:

Example e1 = new Example() {{
setHello("world");
setSpam("eggs");
}};

Once you are familiar with the recipe, this is actually much more clear and informative than multi-argument constructors in Java.

This actually works by defining a new class inline as a subclass of HashMap or Example or whatever. Within the anonymous subclass you can override the contents of that class - usually by overriding methods. This technique is usually used in AWT programming to create event handlers.

Additionally, you can provide "initializers" - which is where the extra set of curly braces come from. Initializers are rarely used in Java - they are anonymous blocks of code within a Java class that are executed AFTER the class constructor but BEFORE the class instance is returned to the caller. Theoretically, any constructor code that is not dependant on Constructor parameters can be moved out into an initializer, allowing that code to be reused for every constructor, but I hardly ever see Java code use this feature.

I wish I had seen this a year or two ago. It probably would have saved Lana from trying to maintain some of the hacks I wrote at Pharmacy OneSource.

We're going to go see the Nightmare before Christmas 3D at the Supermall theatre this afternoon at 2:35. Is anybody interested in coming along?

So, the first D&D game I've tried to run since Junior High is wrapping up, after a little over two years. The current estimate is two or three more sessions, which might take us into mid-December. There doesn't seem to be a consensus yet which potential game is going to be "taking over the slot". I've learned a lot, and I think the next time I run a game I'll be able to do it with a bit more feel, and a lot less "roll for initiative".

I have a few other projects going on that can use some of the time I've been shunting into "preparing game", and I've ordered myself a copy of the latest Final Fantasy game. I'll also be taking a class at the U again this fall, so that will eat a few more hours out of my week come New Years'.

I'm starting to notice the side effects of walking to work and eating better; my legs are regrowing muscles and regaining definition, and my waistline is starting to shrink. I'm definitely to the "I must wear a belt" stage, and am pretty close to the "I need new pants" stage.

Kyna and I are still doing the tango thing. It's hard, and sometimes it's hard to get motivated - especially when she doesn't have quite enough energy and enthusiasm to push me into going out. Still, it's getting a little less overwhelming, and is more fun than I expected. There is a vague worry in the back of my head that I won't have enough time for Tango once I start going to school again, but that sounds a little silly when Kyna makes it work with her work, skating, and ballet schedules.

The good: Wil Wheaton's most recent sermon on The Real Revenge of the Nerds. Well worth a read.

The bad: Karl Rove's "October Surprise" will be sentancing Saddam Hussein Monday, November 5th. Unfortunately, they probably won't get much backlash from people that consider a hangin' to be grotesquely inappropriatte.

Of course, my biases are well-docucumented here, but I saw this post entitled Why has Microsoft babandoned the Power User. It's an interesting claim, especially the portion where he claims Microsoft targets a fairly clueless model user named "Abbie". Does this match your perceptions?

You know that feeling of energy when you are nearing a toxic overdose of sugar? The buzz where you know you have to do SOMETHING, preferable something COMPLICATED, or your head will collapse into a massive headache, as if some unnamed gods are punishing you for not using this gift? That special state of mind where you start to imagine in a thousand horrid directions if you don't keep busy with a problem?

I'm not much of a manic depressive, but I sure feel it on these days where I'm at one extreme. I ended up putting in nearly eleven hours at the office today, with one short break. I love having interesting problems.

Sill no good costume ideas for the party this weekend.

One of the larger projects I use at Healthprolink is a Java web application where much of the logic is in an embedded Jython interpreter. In many ways, this is beautiful. The edit-compile-debug loop is much smaller, allowing me to test and implement new features and bugfixes with remarkable speed. In practice, I tend to think in Python and translate into whatever language I am working with. Also, the Jython syntax often expresses business logic that in a way that is significantly more terse than the corresponding Java code, while still increasing readbility.

Unfortunately, I am starting to run afoul of the problems in this solution. I've made the mistake of implementing some incredibly useful APIs entirely in Jython, so these libraries are entirely unavailable when I have to work in pure Java, meaning that there are often two completely different days of doing what is effectively the same thing. Using an additional programming language raises the barrier-to-entry for any developers joining our team, making the source code as a whole substantially more obscure. Finally, we have run into some strange issues under heavy load that may be partially attributal to the classes dynamically generated by a long-running scripting interpereter. I'm not sure whether anybody has used this interpreter like I am.

The Java memory model uses a special section of memory called "Permanent Generation Space" for JVM and dynamically generated classes. It is noted that tools which dynamically generate a lot of classes (like JSP containers and NetBeans) should tune the size of this memory region to be larger than the standard default of 32 MB. I am not certain that this is an issue with Jython, but it sounds likely.

"Runtime stability" is a higher priority than "uses kewl technology"; "accessible to all developers on the team" might outweigh the "Sean can develop extremely rapidly" factor.

Recoding everything into Java in a month-long hacking run seems like a bad idea, but it might be worthwhile to at least migrate the libraries so that I at least overcome the "fractured API" problem. Once I take care of all Jython modules that are called from other Jython modules, I should be able to compile the remainder with invocations to jythonc, which will get us around the dynamically-generated-classes problem. I am willing to tolerate the barrier-to-entry problem; ability to pick up new languages quickly is one criteria I require of developers to earn the title of "competent". Any reduction in the number of classes we define in Jython should help with the PermGen Space issue.

Goal: spent less time fixing old code, more time writing new code.

Why monitor? J2EE is ridiculously complex. Over-engineered solutions can be very slow.

Brief history of tools:
log-based analysis: flexible, fast, human resource intensive, limited application visibility.
code profilers: Great visibility, resource intensive, not designed for production use, deluge of data, no multi-tier visibility.
Synthetic transactions: solid uptime infrastructure, automated test cases, cannot monitor production.
Byte-code instrumentation, flexible, fast, tedious, limited multi-tier.

Goal: monitor production without affecting production. Bytecode instrumentation is the tech of choice, but needs better manageability.

Heisenburg. If you add too much monitoring, you can easily affect production. Visibility vs. Overhead dilemna.

Instrumentation tends to be a manual, iterative process.
Instrument everything and scale back.
Instrument everything and scale up.

Desire: base instrumentation on real usage patterns, minimize developer time, adjust without constantly having to bounce application.

Adaptive instrumentation: collect real, meaningful usage information, adjust as needed without restart.

Instrument slow methods, service requests, frequently used components, methods that do a lot of owrk, things that acces external resources, and frequently-used custom code.

Avoid all methods that will add significant overhead without real analytical value.

JSR 223 implemented in Mustang.

Javax.script in mustang.
Javax.script.http depends on servlet so not in Mustang.
PHP extension. Wrappers for Java objects. Embed PHP in servlet container. Availabilty TBD.

JavaScript included, based on Rhino, with Third-party implementations, BeanShell demonstrated. Snapshot build 40 and later.

Use cases
stand-alone script interpreter
script uses Java objects
java calls script engine.
Scripting framework.

Scriptin frameworks:
BSF, ActiveX, JSR223. Jsr241 Groovy JSR273 BeanShell.

ScriptEngine: ScriptEngine, invocable, compilable.
ScriptContext: bindings, stdout, stderr, namespace
ScriptEngine: metadata, threading, script generation.
ScriptEngineManager

Command-line script shell jrunscript. Rhino has no Java bytecode compilation. Needs JavaAdapter to implement Java interface.

The Google lesson: advanced UI concepts work best with clear, minimal applications. Combining the level of hackery that goes into Google maps with a substantially larger application would result in a steaming, unmanageable, mess.

Autogenerated UIs become ugly messes of code you never want to touch, that get in the way of cool algorithms. If you want to do somethign the code-generator didn't intend, you often have little recourse.

Model-View-Component is a good idea in theory, but people cut corners and mix MVC layers, putting everything in the View.

UI code grows out of hand. When project managers/salespeople/customers see soemthing they want to change about the product, they describe what they want to change in terms of the UI. These revisions are often implemented as quick hacks in the UI layer that break clean MVC separation. Changes in flow and layout often impact application layer.

One way to avoid (or at least minimize) this trend is to err on the other side during the initial design phase: build large, generic Controls. Use a solid data model. Keep the view logic as minimalistic as possible.

UI packages have screens, widgets, threads, and events.

HTML has response/request, forms on a per-page basis. Linear, coarse, synchronous flow.

HTTP heavy, stateless.

Classic UI: many paths, each screen only needs to know it's own data.
Web UI: each page needs to understand every path.

Each request contains WHERE to go and information about the screen that you just left.

Oject-oriented UI model more intuitive for design, management.

Model DOM objects as server-side Widgets with subclassable event listeners. Provide a way to plug these event listeners into the form handler.

His implementation has a Processing Thread for each user session, with which the event handlers are registered. Doesnlt allow parallel browsing of multiple screens, doesn't scale well. Works on embedded devices.