JavaOne: Quick Thursday Notes

The technical sessions are over for today, so it’s that odd time between them and the BoFs. There’s a couple BoFs here at the Mascone I want to be sure to get into tonight — Metadata for Java (as was demo’ed in the keynote, this is something like XDoclets on steroids) and How Tiger [J2SE 1.5] Language Changes Affect Your Favorite APIs. Both have Joshua Bloch involved, so it should be worth it just for that.

The problem, then, is what to do about dinner…

Eclipse T-Shirt

I decided I should go check out the competition, so I went over to the HP booth and listened in on an a booth guy talking to a Sun person about OpenView; later I got him to show me a little demo, though, they were only showing the Java related stuff. It was pretty snazzy, actually. While I was waiting there, an HP person came by and handed me a black Eclipse t-shirt. It’s pretty nice, esp. as it doesn’t have a bunch of weird marketing stuff on it: just the Eclipse logo and the list of Eclipse members on the back. I don’t really wear t-shirts, but it’s always good to have more dorky t-shirts.

As Kim once said, long ago after looking through my laundry, “Hmmm…most people have old high school or college sports shirts…but you have programming shirts…you’re such a dork!”

Tech Sessions

Generics

I went to Adding Generics to the Java Programming Language first. Gilad Bracha is a suave presenter: he’s got that vague European accent and that well-cut suit thing going along with subtle sarcasm spontaneously laced throughout his presenting. Most of the info given is probably available on-line, e.g., the syntax, but it was fun to hear Bracha’s commentary as he presented Generics, e.g.,

If I’d have known how long this’d take [to get into production Java], I’d never have got into it.

I have my notes about halfway typed up; hopefully tonight I’ll be able to polish them off.

JXTA on J2ME

With my new like of JXTA, I thought I’d check out another facet of it:
JXTA for Small Devices Using the J2ME
. Eh…it was interesting, but not worth talking too much about. The main point was that there’s an incredibly small (which is good) and easy to use J2ME API for JXTA. However, the “trick” is that you need a proxy running on a real machine to do all the “heavy lifting” (another phrase people like using around here).

I’m interested in the idea of using JXTA to link up embedded and other small devices, but as I’m not an eeky type of hardware guy, playing around in that sphere could start to get expensive. I do wonder, though, if J2ME could be used to create small footprint apps running on desktops: putting that together with JXTA could start to get interesting. But until the small device market can do more than take pictures of toilets in Hong Kong, I’d rather stick with desktops.

JMX

I really liked JMX: Recent Changes and Ongoing Applications. There’s mucho notes to type up. As Eamonn McManus, the speaker said, most JMX books out there are about JMX 1.0, so his overview of the new features in JMX 1.2 was interesting. As with the Generics presentation, his commentary on design decisions and constraints in the API was interesting too.

The best feature — from a coding perspective — in JMX 1.2 was the use of Proxys to get rid of the need to do crappy shit like,

mBean.invoke(mBeanServer,"methodName",new String[]{arg1,arg2},...);

That is, coding reflective invoking manually. With the use of Proxys, you can just do something more like,

mBean.methodName(arg1,arg2);

You still have to get a hold on the MBeanServer, but it makes calling operations much cleaner to code and easier to read.

Still, there wasn’t a good, concrete example of using JMX. I’ve been thinking of stopping by the Quest both to see if they have something; maybe Mercury — I could kill two birds with one stone, check out the competition and all.

This session was packed: I think JMX is one of the big interests in JavaOne this year, but there’s only 2 or 3 sessions about it. I bet developers are going to be wanting lots of JMX in the upcoming year: it has a good sales pitch; we’ll have to see how well it delivers.


Brazillian National Health Card System

It seemed like a boring topic, and I only went into it to make sure I could get into the OS X session after it, in the same room, but this session was quite enlightening.

The pilot project covering 44 cities in 11 states of the federation with a population of almost 13 million inhabitants and about 2,200 health care providers, most of them primary care units are presented emphasizing the actual implementation status.

That’s damn impressive.

Java on OS X

I thought I’d treat myself to something non-work applicable, so I went to
Doing Serious Java Development on Mac OS X
. It was mostly just a laundry list of development tools the speaker had tried out. He had a list of all them in the PowerPoints which will be online sometime somewhere, so I won’t bother to list them.

There wasn’t anything about actual programming, just tools and IDEs. Kind of disappointing on that account, but I guess if I’d have read the description I’d have found out: going off the titles of these things isn’t the best way to select ’em.

Well, it’s 7:27 PST here, the BoFs begin at 8:30…I better round up some grub before my mind starts to go nutty.

Yeti the Dog Miscellany


I’m sure all of you are thinking, “JavaOne, yeah, yeah, but what about that damn fine lookin’ dog of yours?”

Well, thanks to the wonders of e-mail (have you heard of it?), I have these updates from the lovely Kim Skotak:

  • Yeti likes peanut butter. He likes apple slices. He likes peanut butter on apple slices!
  • Yeti is getting to like The Crate better. Kim went out tonight, so it was crate time. When she came back, he was asleep in the crate. We’ll see how receptive he is to getting into it next time. The crate’s good as he’s a 4 month old puppy who’d probably rip a bunch of stuff when we’re gone. We’ve also been lead to believe that dogs kind of like crates: it’s their own personal space.
  • Kim and Yeti went to the Crown and Anchor and he was quite sociable and nice. He made friends with a Golden Retriever. Apparently, he’s quite the babe magnet. Tom has already made plans to “baby sit” him sometime. A fellow large dog owner — who said his Mastiff loves those orange constructions cones — said, “seeing [yeti] is the best thing that’s happened all day.” People like the dog.
  • The vet says he looks OK. He’s probably loosing some teeth, which makes eat his kibble painful.

JavaOne: Other Bloggers

JavaOne: JXTA


Project JXTA: Open P2P Architecture Platform (TS-2915)
, Tuesday

As I said earlier, JXTA has been
the most interesting thing so far. The Tuesday session was presented by
Bernard Traversat; I believe he’s the JXTA bigwig at Sun.

As a pronunciation note, everyone seems to say “Jux-tah,” not
“J-X-T-A.”

What is JXTA?

In short, JXTA is a framework and standard
for creating virtual peer to peer networks. Put another way, it’s an
abstract network layer to drape over other, physical networks to
enable networkable devices to talk to each other and manage their own
network interactions.

Sounds pie in the sky, right? Well, here’s a concrete example from
one of today’s (Wednesday) sessions, Building
Robust Distributed Applications with JXTA
.

Soft Teams of Sensors

BBN, the TS-1297
speakers (see below for more on that session), work with/for the US DoD. The DoD wants to reduce the human
involvement in “soft teams,” and use a bunch of robots instead. “Soft
Teams,” now are largely special ops folks, like SEALs, that go behind
enemy lines, setup a bunch of monitoring equipment, and then stay
there for days maintaining the sensor network, filtering the data (?),
and sending it back.

Loosely quoting the speakers, “the DoD wants to just drop in a
bunch of sensors, let them sort out networking with each other,
gathering information, and nominate one of them [or several] to send
the data back to the satellite.”

So, in this example, you have bunch of networkable devices that
need to talk to each other – in the most simplistic example, comparing
notes about what they’re sensing to double check each other – and we
certainly don’t have a physical network pre-installed and ready to
plug into.

You have the need, then, for an ad hoc peer to peer network:
you need the devices to discover each other, share
information, establish their own network, and provide fail-over
handling should any peer go down.

These are essentially the requirements that JXTA satisfies. It
doesn’t provide the implementation of the network (the underlying
layers do that), but it provides the structure of the network and
services the peers use for access to the network.

The astute among you, dear readers, will immediately recognize this
as the Sun pattern for design: don’t create the implementation,
create the design and framework to layer on top of the
implementation. From what I’ve seen, though, this is a choice one.

Comparison to Traditional Networks

The traditional
(current) network is basically hubs/routers and clients (compared to
the first generation, client-server): clients talk to each other, but
all their traffic goes through routers. At home, if I want to print from my
laptop I have to send the print job through my
router, which sends it to the printer. If the network was peer to
peer, the laptop would just talk directly to the printer.

The hubs-clients network, as the internet has proven, is actually
very good for many uses like web browsing, email, simple desktop apps, etc.
The problem, however, is that you must have your
network planned out a priori (some old philosophy speak that
several speakers like using which, in this context, basically just means “before hand”).

Using the example above, if I just put my laptop, my printer, and a
router in a room together, they still won’t be able to talk to each
other: they need me (or some really smart software) to tell each of
them how to talk to each other (usually over Ethernet/WiFi and
TCP/IP). Each device also needs to be told about each other.

JXTA networks don’t need this additional setup: devices
discover and figure out how to talk to each other. Of course, on a
deep code level, you’re really just auto-magic’ing all the
things you were doing in the hubs-client model. As Mark Pilgrim says, “a lot of
effort went into making this effortless.”

Enough with all that explanation. All of you probably know what a
p2p network is anyway.

Back to JXTA

First, JXTA is free and open source. As
Traversat said several times and emphasized over and over, Sun
realized that anything that’s going to be an infrastructure technology
(networking) must be free and open to be successful.

JXTA, like many things now-a-days, has an XML protocol; which is to
say that unlike, for example, SNMP which BER encodes data (making the
data unreadable to humans until it’s decoded), the
data is in “plain text.” Though, as many of you know, XML protocols
are often unreadable themselves.

Key JXTA Abstractions

  • Peers – the networkable devices.
  • Virtual Networks – the network, which doesn’t have to be
    “physical,” that the peers form through JXTA. One important point
    about the virtual network is that peers are given logical

    addressed, not physical. addresses. I take this to mean that a
    peer can move from device to device. Through this, peers could
    something along the lines of the anthropomorphic idea of viruses and
    worms
    : a piece of software/application that moves from machine to
    machine.

  • Advertisements – XML descriptors of the peers and what services
    they provide. I assume that these “adverts,” as one of the BBN people
    said, can also serve as generic envelopes for any
    type of meta-data. Every ad is assigned a lifetime, and there’s some
    grounds keeping handling for dead ads.
  • Decentralized Resource Discovery – there are several types of
    peers (see below); those that help route traffic are called Rendezvous
    peers. These “RDV”‘s facilitates looking up other peers; that is, they
    act as “ad servers,” do caching, and even provide indexes. RDV’s help
    keep track of “where” edge peers are, and what they provide. Even
    better, if the RDV doesn’t know what you want, it helps you find
    other RDV’s.
  • Ad Hoc Peer Groups – peers can be grouped together to
    create logical sets. Peer groups are used to established different
    policies (about routing, searching, access, etc.). If I recall and
    understood right, the policies are represented by ads.
  • Pipes – “very similar – in concept – to UNIX pipes.” A JXTA pipe
    is just a generic conduit for peers to exchange data. If I
    understood right, a pipe will follow a peer through it’s logical
    address. That is, if peer A is talking to a peer through a pipe, and
    peer A switches to a different machine, the pipe will follow the peer
    to it’s new physical location.

Tyes of Peers

  • Edge Peer – the classic client that produces and consumes data.
  • Relay Peer – virtual routers; “landmarks,” that is, other peers use Relay Peers as known points in the network, e.g., “If you want to talk to me, talke to the landmark Relay Peer X.”
  • Rendevous Peers – ad servers, caching, and indexing. This is different than Relay Peers in that actual network topology and information is stored in these peers…I think.

Those are essentially the main points. Despite my disjointed
writeup, it’s actually quite simple. JXTA doesn’t seem like much at
first, but it opens up new ways for apps to use networks and interact
with other apps over the networks (like BBN’s self organizing and
co-operating “soft team” of sensors above).

JXTA 2.1

As a final note, JXTA 2.1 was released not too long ago. It’s
“primarily a bug release,” but there’s some new “metering and monitoring”
features as well.


Building Robust Distributed Applications with Project JXTA (TS-1297)
, Wednesday

This was presented by some folks from BBN who’d been doing research and implementations for the DoD, the Coast Guard, Homeland Security, and a “Western regional airport.” Their main interest was using sensors to do security and detection, which makes their “clients” interest obvious. Their jobs sounded real fun, despite the chill of Big Brotherism that could sneak up on you.

For those not working on perimeter security, it’s important to think of “sensors” more broadly: anything that collects data and (to be useful) provides collected data to clients can be thought of as a “sensor.”

The core nugget of this session is summarized above with the “soft team of sensors” example. Here’s some interesting notes and quotes:

  • Dana Moore recommended WorldOfEnds.com and “The Rise of the Stupid Networks”, which was cool to hear at such a big conference. I thought they were just obscure, late night surfing reading. He recommenced them, I’m guessing, because they help you get an idea of the type of “world” that peer to peer networking could enable and the business rules that exist in it, e.g., “All the nets value grows on it’s edges.” They’re good essays: read ’em!
  • Along the lines of the stupid networks, Moore said, “transport is guided by the needs of the data, not the network’s assumptions.”
  • JXTA is quite interoperable: there’s C implementations, Perl, Python, Java, etc. The protocol is in XML, so interoperability is possible, vs., for example, RMI.
  • Traditional sensor either send too much dumb data, burying the info you’re interested in, or send too little data. Moore gave an example of too much dumb data: net admins looking at system output on 10 vt100’s trying to detect a network intrusion.
  • “Hypotheses” – it took me awhile to figure out the exact meaning of this old term in the JXTA context. The sensors/peers in the network have hypothi that roll up to global hypotheses. A “hypothesis” is something that a sensor thinks is true (according to the input it’s getting), e.g., “a vehicle just drove past me.” Each sensor/peer creates tons of these hypothesis, and tells it’s peers about them. Then, at a higher level, you programmatically compare all the hypothesis, and verify which ones are true; presumably, you run some business rules like, “70% of the sensors must have the same hypothesis for it to be ‘true.'” This was an interesting concept for verifying multi-source data about one event.

p2p Inseption and Elaboration Design Considerations

Lastly, here are some architectural considerations to sort out when doing p2p network/app design:

  • Deployment constraints – e.g., physical terrain, like mountains and expected up time, drive requirements for hardware and power. In a more applicable setting, the type of network you’re deploying into might drive the policies and practices you establish: can your peers roam around the network as they please? Is the network reliable and stable? Does data need to be real-time? Etc.
  • Anticipated operation sequences – though JXTA can enable a lot of synergistic interactions and lifecycles for your apps/peers, it’s still good to plan for chains of events that will commonly happen and what you’ll need to put into your peers, or even the way the peers interact to enable those “operation sequences.” For example, I’d think, if you were going to have a bunch of DB access, you might assign some peers the role of DB accessors, and you might make a policy that RDVs always know where a DB accessor peer is so that looking them up is fast. In the OO sense, this is the behavior of your network.
  • Info processing paths – synchronous or asynchronous? That is, how will the information flow through your network? In the same way that anticipated operation sequences can drive the design, the how/where/what of the data can drive design. As always, from a high level, data and behavior are not so different.
  • “Scalability, Scalability, Scalability.”

JXTA URLs

  • JXTA.org – main JXTA site.
  • SPIDAR – the BBN JXTA application.
  • COUGAAR – recommended, and used, by the BBN guys.

As with an earlier
post
, here’s a fun quote to end with:

“Is there going to be a way to do all that Web application descriptor
crap [in RAVE]?”
“‘Web application descriptor crap’…I love that phrase.”
–Q&A at TS-3730

Mac vs. PC Style HTML

I have this theory that the design of your HTML is largely driven by the platform you code your HTML in. Now that I have a Mac, I’ll see if my style subtly changes over time. My pages definitely render differently on my PowerBook than my PC’s.

JavaOne: Wednesday Quick Notes, Cont.

I couldn’t get into Measuring J2EE Application Performance in Production, it was packed. I guess that’s a hot topic. Instead I popped into
Performance Monitoring for the Java HotSpot Virtual Machine, which was basicly an overvierw of using and interpreting data from several tools available from Sun. As performance monitoring and management is essentially the raison d’etre of BMC, I figure I should goto as many of these as I can.

I also went to
Building Robust Distributed Applications with Project JXTA
and The Commons Inside the Firewall: Lessons Learned from Large Enterprise Development, which were both quite good.

The Cifreo’s and I are probably going to goto to dinner somewhere. I might skip the BoF’s tonight, though there is an interesting looking one of JMX and then a Joshua Bloch one on collections.

JavaOne: Wednesday Quick Notes

I’m inbetween sessions, so I thought I’d post a couple remarks. I had to skip the last half of a JXTA session to eat the sandwhich I got earlier. As Kim would say, I’m Starvin’ Marvin. I still have pages and pages of notes to type up, but I’ll just pull out some interesting info.

. . .

I just chatted with a guy who sat down at my table about the G4 laptop — there’s no way to do page down without holding down the Fn key, damn! — so I have no time now: I gotta dash to the “Monitoring the Performance of J2EE apps” thingy.

What I wanted to say is this: JXTA is by far the coolest and most applicable to my job thing I’ve learned about. It’s fucking awesome, I never realized p2p stuff could be so cool and have so many uses beyond MP3 stuff. It’s definitly something I’ll have to spend lots of time fiddling with…

Oh, I just overheard a commander cell phone type yell something about PATROL, that’s kind of nifty.

Well, more later, dear readers.

More JavaOne Bloggers

JavaOne: Tuesday Technical Sessions and BoFs

Well…the first day of technical sessions is over. I think my
brain has melted to a little black nugget with the influx of
information that went through it…abstract…enterprise…abstract…API…

The first day has been good: the content of the presentations is interesting, and each presentation has a theme of
“we’re here to make the developer’s life easier” running through them
that’s refreshing after having dealt with Java for so long. (See
Bruce Eckel comments on why he likes Python in part one of that Artima
interview
).

Here’s a writeup of my notes and my own scriblings on the first session I went to. It’s about 1:05AM here in SF, so I think I’ll skip typin’ up the other 3 sessions and the two BoFs I went to until tomorrow, or later…


Introduction to Java BluePrints

I’m always nuts for 3 things when it comes to programming: frameworks,
methodologies, and best practices. Admittedly, my first choice for this
time slot was the JSF (JavaServer Faces) Intro, but it was
fire
marshal packed
; but, “TS-2473” proved interesting (actually, I
did see the last 20 minutes of the JSF one, see below for more).

Local vs. Distributed.

In the J2EE world, one of the first architectural requirements you
have to iron out is if your code will need to be distributed, or if it
can all be done locally. By “locally,” of course, we mean that your
app will run on one box, in the same memory, and probably all in the
same VM.

If it’s all local, you don’t need to worry about
networking up your app, or really anything that might fall under the
category of J2EE. The advantages, of course, are that you don’t need
to spend time designing and implementing distributed stuff into your
app. This means you can (usually) have a more simplistic
design).

An interesting corollary (?) to this is that it tends to promote the writing of non-reusable code. That is,
because you’re not “forced” to layer your application or spend lots of
time designing how all the components would communicate with each
other over the network (the presumption being that for distributed
apps you need all this), you can get lazy and not do enough design to
help enable re-use.

The main draw back of distributed systems, then, is that it
increased the complexity of your app from initial development, to
deployment, to maintenance: there’s more moving parts, so it gets more
complex. Presumably, from the re-use comment about localization, it
promotes more re-use.

At this point, the speaker gave the “highlight piece of
advice” (all the conferences tend to have one piece of advice that,
when they give it, is prefixed by “if you remember only one thing from
this presentation, remember this…”): when in doubt about doing local
or distributed, go for the simpler design.

This is Ockham’s Razor and all that, but it’s recently been
re-expressed best by the XP folks, “do the simplest thing that could possibly work,” the last part being the most important.

Advice on the Web Tier.

Use MVC (JSF, Struts). Use JSTL. If you don’t need overly complex DB
wrapper — EJBs — use RowSets. Again, “when in doubt, go
for the simpler design.”

There was an overview of MVC, with the most interesting thing being
the phrase “user gestures” to describe user input.

More on RowSets.

“in memory representation of
the DB.” Not part of J2EE 1.3, but available.

Tools.

“It’s really tempting to use command line
tools…but an IDE really helps you a lot.” I liked that he used
“tempting.”

Web Services Blueprint.

The blueprint is, in a way, very
similar to MVC:

  [Client]
   |    |
 [Interaction]
  |     |
 [Processing]

The client uses SOAP (that’s really what everyone means when they
say “web service” around here) to do something, like get a customer’s
information. The Interaction layer is part of “your system,” and it
handles all the SOAP requests, delegating to the Processing
layer. That is, the Interaction layer translates the SOAP stuff into
the Processing layer, and translates the response into SOAP for the
client. The Processing layer is just your business logic: Java code.

The goal, of course, in classic Sun abstractionism, is to make the
layer that does the crunching not have to know anything about the
client that’s requesting the crunching. This makes everything
flexible, agnostic, and not susceptible to changes in other
layers, blah, blah, etc., and so forth…

“Keep the processing layer independent of the interaction
layer.”

More importantly, as we’ve long learned in GUI and then
web app development, you want to get your business logic as far away
as possible from your presentation logic. At least, you want to try to
keep it as far away as possiblem, to re-purpose the XP saying.


JSF

I saw the last 15 minutes of this one, basically the Q&A. I believe
Craig McClanahan answered all the questions.

Struts and JSF.

“JSF will replace where Struts is now, but
not where it will be.” Which, of course, is interesting, because it means there’ll be more Struts development, but what?

“…likely to look at templating in JSTL 1.2 time frame.”

He says that one of the big problems with Struts is that there’s
just “one big configuration file.”

Should we use JSF, or Struts?

If you’re going to be deploying
(deadline) in less than 6 months, just use Struts. If it’s greater
than 6 months, consider JSF. More importantly, the license you
download JSF with/under is for evaluation purposes only.

I also went to
Servlets 2.4 and JSP 2.0
,


Project JXTA: Open P2P Architecture Platform
,


Optimizing Web Services Performance
,


Real-Time Information Integration with J2EE and XML

and,

J2EE-Based Projects That Fail: What Can We Learn from Them?
…but I’m too tired to write all that up, much less make it coherent.

JavaOne: Tuesday General Technical Session

I just walked out on the first technical session to get me some
wireless access upstairs in the “game area.” There’s a bunch of old
video games setup here, and some bean bag chairs and, finally, a
wireless network that doesn’t require a password.

The first part of the technical session was an overview of “Tiger,”
Java 1.5 and J2EE 1.5 developments and plans, presented by Graham
Hamilton. Here are my slightly edited notes.

  • Trashes on COM being complex, requiring IDE that generates lots
    of spaghetti code. This is the first of many mentions of Microsoft
    (though, he only ever says “VisualBasic”) developer mentions.
  • Meta Data. Tools understanding JavaBeans and other
    non -compiler enforced coding conventions. This is, basically, like xdoclet, except done by
    the compiler, and done inline instead of in JavaDocs.

    So, for example, if you wanted to use a tagging interface (like
    Seralizable), instead of having your class implement an empty
    interface, you’d do something like:

    public @fred int x;
    

    He called these “annotations” and described what they do as
    decorating the code. If anyone is allowed to interpret these
    “annotations,” a whole new type of coding and tools could spring
    up.

    Later on, we find out that this Meta Data stuff is going to be
    used to do many J2EE deployment descriptors inline, instead of
    requiring them to be maintained in a separate XML file.

  • Generics. Instead of having to worry about casting from
    collections, 1.5 will have something like
    HashMap, which means “the key is
    String, and other is Mamels.” Generics get a huge round of
    applause.

  • Better Iterating. Instead of having to use those damn
    Iterator and, in older code, Enumeration,
    1.5 finally picks up on one of the best control structures from the
    scripting world:

    for ( String object : collectionInstance) { ... }
    

    That is, the block of code iterates over all the members in
    collectionInstance, and sets object to the
    current member. I forget if he said, but I think the generics and
    autoboxing (see below) will take care of casting.

  • Enums. There’ll be compiler support for doing enums, for example,

    public enum Coins { heads, tails }
    

    Would create an enum with two possible values. Nowadays, you have
    to use homegrown stuff, or something like (my favorite “hammer”),
    the Commans lang Enum.

  • Autoboxing. You have “big primitives” (aka wrappers) and “little
    primitives” from big primitives to little primatives, e.g.,
    Integer and int. As languages like Perl and
    Python demonstrate, having to "manually" convert between the two is
    just stupid. 1.5 fixes this. Thus, you could have:

    Integer bigInt = new Integer 5;
    int lilInt = 5;
    int value;
    
    value = bigInt;
    
    if (value == lilInt)
      System.out.println("Now it's a little easier to code.");
    
  • C-style sprintf. 1.5 will sprintf (or
    is it just “printf“? This is all built into
    java.text. There wasn’t comment on i18n, but I
    assume/hope you can pass in Locales.

  • Scripting. Hamilton says “scripting languages are our friends.”
    JSR-223. They’ll be using PHP as the reference implementation
    language, and setting it up in Tomcat.

That’s it for now. I’m going to an intro session of JSF at
2:15. Hopefully it won’t be too hookey, or focus on VisualBasic
comparisons.

Here’s a quote from the conference to end with:

“You don’t have to be sarcastic, just wear it. If you don’t like it, you
can leave.”
–conference center security guy telling a Chinese attendee that he
must wear his badge at all times.

In SF

I arrived in San Fransico earlier this evening. The Cifreo’s and I had dinner down the street at an Italian place. It’s chilly here, but in a comfortable way. First thing tomorrow is the keynotes, but from what I’ve heard, the keynotes aren’t very good. And, anyhow, I’ll probably have to spend the morning tracking down my registration packet since it never arrived back in Austin.

Tonight I’m just trying to sort through all the vittles of the conference. There’s no good fotes yet, but I’ll upload them as they come.

Update: here’s the list of all the sessions and BoFs that looked interesting to me. I seriously doubt I can take in all 52, esp. as there’s several conflicts, but I might as well try.

Missing Weapons Of Mass Destruction:

There are two main possibilities. One that something is seriously wrong within the Bush White House’s national security operations. That seems difficult to believe. The other is that the President has deliberately misled the nation, and the world.

You, my dear readers, know that I usually avoid political
mucking on this weblog…but this missing weapons of mass destruction stuff is too easy.

Along with being being a reasonable article, there’s a good collection of quotes from Bush on the topic.

Also,

British Prime Minister Tony Blair is also under serious attack in England, which he dragged into the war unwillingly, based on the missing WMDs. In Britain, the missing WMDs are being treated as scandalous; so far, the reaction in the U.S. has been milder.

New York Times columnist, Paul Krugman, has taken Bush sharply to task, asserting that it is “long past time for this administration to be held accountable.” “The public was told that Saddam posed an imminent threat,” Krugman argued. “If that claim was fraudulent,” he continued, “the selling of the war is arguably the worst scandal in American political history – worse than Watergate, worse than Iran-contra.” But most media outlets have reserved judgment as the search for WMDs in Iraq continues.

Note that the reference to reports about Wolfowitz saying the war was all about oil was later found to be untrue.

Great Pyrenees


'Bumble,' the Great Pyrenees

If all goes as planned, the Coté and Kim house should have a new member by tomorrow. We haven’t decided on a name, but our short list so far includes “Tiny,” “Oso,” “Mouse,” and something along the lines of “Montana” or “Dakota.”

“Bumble,” as he’s called now, is 4 months and 3 weeks old…and he already weighs 50 lbs! When he grows up, he’ll be huge and furry, but sweet and gentle like most all large flock dogs.

There’ll finally be someone in the house hairier than me,

The Pyr sheds. A lot. Those who cannot abide the thought of tufts of white hair floating through the house twice a year should consider another breed. On the other hand, those who fancy exotic knit accessories may find the Pyr right up their alley. The dog’s fine undercoat can be collected when shed and spun into yarn used to make sweaters, scarves, afghans, and other items.

Python and the Programmer

They say you can hold seven plus or minus two pieces of information in your mind. I can’t remember how to open files in Java. I’ve written chapters on it. I’ve done it a bunch of times, but it’s too many steps. And when I actually analyze it, I realize these are just silly design decisions that they made. Even if they insisted on using the Decorator pattern in java.io, they should have had a convenience constructor for opening files simply. Because we open files all the time, but nobody can remember how. It is too much information to hold in your mind.

Yuh!

Silver Smallpants

12.1" PowerBook G4

The G4 arrived safe and sound.
I got Firebird up and running, it comes native with emacs and Java. An OS that ships with emacs has my heart from the get-go.
Now I just need to dump Eclipse, Tomcat, JBoss, python, and
a few other dork tools on it and I’m ready for the year 3000.

It’s going to take me awhile to get
used to the Mac interface, esp. the track pad. And this font anti-aliasing is killing me.

If anyone has “tips,” shoot ’em my way. So far, I haven’t figured out how to:

  • Delete things with one click
  • Cycle through all my open applications (Alt-Tab in Windows)
  • Find a list of all applications I can run.
  • Turn off all this damn anti-aliasing.
  • Have it make toast and eggs for me.

What Exactly Are Obidos?

All of the servers at Amazon are given names of cities along the Amazon river. Obidos is a port city on the Amazon river in Brazil, and the name of the [Amazon.com] machine that runs the book database. Simple as that.

Fixing Venture Capital:

The fundamental reason is that VCs do not have goals that are aligned with the goals of the company founders. This creates a built-in source of stress in the relationship. Specifically, founders would prefer reasonable success with high probability, while VCs are looking for fantastic hit-it-out-of-the-ballpark success with low probability. A VC fund will invest in a lot of startups. They expect about seven of them to fail, two of them to trudge along, and one of them to be The Next Netscape (“TNN”). It’s OK if seven fail, because the terms of the deal will be structured so that TNN makes them enough money to make up for all the losers.

. . .

VCs try to speed things up by spending more money. They spend it on PR, and then you get problem 3 (“PR grows faster than code”). They spend it on employees, and then you get problem 4 (“too many cooks”) and problem 2 (“high burn rate”). They hire HR people, marketing people, business development people. They spend money on advertising. And the problem is, they spend all this money before anyone has had a chance to learn what the best way to spend money is. So the business development guy wanders around aimlessly and accomplishes zilch. You advertise in magazines that VCs read, not magazines that your customers read. And so on.

From the "I pay $130 a month for what?!" Dept.

kimskotak: Hey – I want to tell you how the end of that movie went – it was so fucking cheesy. So it turns out that her boyfriend was the one who had raped her and when he was raping her he told her that he wanted to “ravish her”. So when she started suspecting him as the rapist, she was trying to con him into giving himslef away. So she got him t o have sex with her and said “ravish me” to him to see how he would react. Anyway, turns out that he was the rapist. The police eventually caught him in the act and when he was in jail, Paula Abdul went to visit him to find out why he had raped her and the other women. So she’s like “why?” and he was like”because you like it.” and she said “No!” and he was like, “Come on, say it….say it…..ravish me.” and the very last line before the movie ended
kimskotak: was when she bent over his shoulder and whispered in his ear…”tell it to the guys in jail.”
kimskotak: and that was the end…..

Mouse Gestures, Mozilla Firebird:

Mouse movements in combination with a click-hold and optionally a modifier that execute some browser functions. You press mouse button, draw a gesture, and release mouse button (you can choose which button to use in advanced preferences). This gesture is recognized and appropriate action is triggered.

I haven’t played with these yet, but they look like graffiti for your mouse. Looking through the supported
gestures page
, it seems like what you do is move your mouse in a specific pattern to activate some function in the browser.

For example, moving the mouse in an S shape causes the browser to open the View Source window.

On this general note, I’ve been using Mozilla Firebird for a few weeks now (after reading Ben Goodger’s “Why You Should Switch to Mozilla Firebird browser”), and it’s super-dope. Even that
curmudgeon Joel likes it
.

I’ve been using IE for a long time because Netscape/Mozilla just seemed like, to put it crudely,
a collective open source dump with terrible usability and, well,
just too much damn stuff. But this Firebird is the bomb: I rarely have to fight it to get what I want. The only problems
I’ve had so far are file associations, but if you don’t mind poking
through an RDF file, it’s no big deal.

Anyhow, all ya’ll should download it and set it as your default browser: it’s the shit.

Update:

matthewhray: You using some of the sweet plugins? Mouse gestures are dope.
bushwald: I just saw the post as a good excuse to call Joel a “curmudgeon.” Can’t pass moments like that up.
matthewhray: trudat
bushwald: I haven’t setup any plugs, I was just reading about that one.
bushwald: I’m still waiting for the “Butt Doctor” plug in: whatever it finds, it keeps.