At 7:30, I attended Karsten
Lentzsch's JavaTM Foundation
Classes (JFC/Swing) Technology Data-Binding Techniques.
Kartsen knows Swing probably as well as anyone here, and he's spent a
lot of time thinking about Swing in all areas, from how to create
cross-platform
forms easily to better data-binding approaches. This
session was focused on the latter. He started with an overview
of the history leading to MVC, then he talked about the MVC variant
Swing uses. He then discussed his proposal for a replacement
for the MVC approach within Swing. In order to keep the Model
and View in line without synchronization issues, he recommends a
PropertyChangeAdapter that sits between the model and view,
translating the PropertyChangeEvents to bean calls on the model.
It seems an interesting approach, but I'll need to play around with
it a bit myself before I could recommend it further.
Interestingly, Karsten explicitly warned us not to run out and apply
his pattern. He emphasized that developers should study the
pattern before use, and each team needs to have one expert on the
pattern. Maybe I'll be that expert, and maybe Scott
will.
Next, I went to Sun's 10,000 Classes, Five Databases,
Three Operating Systems: Techniques for Multiplatform Enterprise
JavaTM Technology Testing BOF with
a couple teammates. The session what almost identical to what
one of my teammates
submitted (Scott Gelb is the one wearing the yofoshizzle
shirt). I guess Sun gets priority. Our system is a bit
smaller, but it's more complex. We have 1500 classes, three
databases, three operating systems, and three app servers. The
presenters didn't have the complexity of multiple app servers because
they worked on the Sun Application Server team. I'm not sure I
envy them for that or not.
Their approach is similar to ours
in many (seemingly obvious) ways: keep the coding workspace in source
control, make sure the workspace works on all platforms, have a
logical irectory structure for your workspace, etc. There were
a couple things we found curious, though. They packages their
test suites (15-20 tests apiece) in ears for nightly testing.
That means about 1500 ears generated nightly. We just don't
bother with packaging all that test overhead. Also, they have a
set of core tests that take 15-20 minutes to run, and they require
developers to run that set (the "Pulse Tests") before every
single commit. Well, we follow the philosophy of many small
commits, so this would kill 2 or three hours of productivity for all
our developers every day. We'd like that for blogging time, and
it would probably help keep bugs out, but I'm not convinced they're
on the right side of the balancing act.
It was frustrating
being at a session we essentially proposed and could have presented.
Oh well
No comments yet:
