Monthly Archives: May 2008

Food, Fun, and Networking: Seattle Girl Geek Dinners

3 Replies

I first heard about Girl Geek Dinners a while ago, and thought it sounded like a great idea. I sent an email to the original organizers, and soon heard back. They had also just heard from Liz Morgan, another woman in the Seattle area, and suggested we join forces to organize a local group.

And so we’re inviting all local technical women to join us for the First Seattle Girl Geek Dinner, to be held June 24th at the Microsoft Campus in Redmond. There will be food and beverages, and hopefully a lot of fun!

Please check out our site, let us know if you’d like to come by signing up, and help us spread the word!

How do I find an XmlDocument Element?

Leave a reply

We’re using XMLBeans as part of a project. I had a document called EventConfig that had many EventDetails. I needed to find one EventDetails element based on its child element, EventName.

Being new to XMLBeans, and in bug fixing mode, I checked the XmlObject API, and saw only that selectPath(String) took a String. I couldn’t find an example of what syntax to use to do this kind of a search.

The answer is XPath 2.0 (which is noted in the Javadoc for the method, but I didn’t understand what it meant at the time).

As usual, I found the W3C documentation to be a bit overwhelming. But I did find this XPath Tutorial which gave the correct syntax for XPath Predicates, which enable us to select specific nodes. Predicates are embedded in square brackets. So for my case, I could find my EventDetails based on the EventName.

public EventDetails findDetails(String eventName) {
    EventDetails eventDetails = null;
    String queryExpression = 
        String.format(
        "declare namespace po = 'http://www.stevideter.com/project/eventconfig';$this/po:EventInfo/EventDetails[EventName='%s']",eventName);
    EventDetails[] eventDetailsArray = (EventDetails[]) EventConfig.selectPath(queryExpression);
    if (eventDetailsArray != null && eventDetailsArray.length > 0) { 
        eventDetails = eventDetailsArray[0];
    }
    return eventDetails;
}

Why is Microsoft Excel so popular?

Leave a reply

Today we had a brainstorming meeting with the business analyst for one of our major clients. We pitched a wireframe for a workflow addition to the application.

The analyst was excited. This fell in line with a meeting she’d had earlier. The main decision there was to replace a large portion of the UI with Microsoft Excel templates. Users don’t like the UI and want to just use the Excel spreadsheets they already have for passing data back and forth.

One of my co-workers sighed, “Users just like Excel. It’s got to be the most successful product ever.”

I’ve seen this repeatedly. I’m tasked to build a web-based UI to automate
business processes. Once it goes live, I find out users don’t want to use the UI — and always seem to wish they could just use Excel instead. And businesses seem unwilling to force users to use the custom application that seemed so important six months to a year before.

There’s certainly a requirements gathering and design problem that’s usually fundamental to causing this problem. There’s frequently also a training problem once the application is launched.

But why is it always Excel that people want to hang on to? Why is it so useful that it seems to drive a huge portion of business processes in companies large and small?

I think a large part of its appeal is the low barrier to entry – it’s pretty easy to create a simple spreadsheet. It’s easy to learn the basics of how to add fields and other simple functions. And it’s easier to format than Word. All this despite a fairly unintuitive UI.

What can we learn from the high use of Excel? What can we apply from those lessons to our own applications?

Understanding the protected access modifier and inheritance in Java

4 Replies

The Java Tutorial gives the standard definition of the protected access modifier:

The protected modifier specifies that the member can only be accessed within its own package (as with package-private) and, in addition, by a subclass of its class in another package.

But what does this mean in practice? I see a lot of confusion that can be best cleared up by showing some code. Below are five classes. The first three are in one package, the second two in another: 

package com.stevideter.java;
 
public class X {
    protected void doSomething() {
        System.out.println("did something");
    }
}
package com.stevideter.java;
 
public class Y extends X {
 
    protected void doSomethingElse() {
        // inherited from X
        super.doSomething();
        X x = new X();
        // visible b/c of same package
        x.doSomething();
    }
}
package com.stevideter.java;
 
public class AccessTest {
    public static void main(String[] args) {
        X x = new X();
        // visible - same package
        x.doSomething();
        Y y = new Y();
        // visible - inherited in same package
        y.doSomething();
    }
 
}
package com.stevideter.java.examples;
 
import com.stevideter.java.X;
import com.stevideter.java.Y;
 
class Z extends X {
    protected void myDoSomething() {
        // can call as part of implementation
        super.doSomething();
        X x = new X();
        x.doSomething(); // compile time error; declared in different package
    }
}
 
public class ExternalAccessTest {
 
    public static void main(String[] args) {
        X x = new X();
        x.doSomething(); // compile-time error, not visible
        Y y = new Y();
        y.doSomething(); // compile-time error, not visible
        Z z = new Z();
        z.doSomething(); // compile-time error, not visible
        z.myDoSomething();
    }
 
}

Here we see that while we operate in the same package, we can always access class X’s protected method doSomething(). Subclass Y can access it via inheritance, and AccessTest can see doSomething() for X, because it’s in the same package, and Y because Y inherited it from X and is in the same package.

In the second package, we see that access to X’s protected method is far more restricted. Subclass Z can use doSomething() as part of its own implementation. But it cannot access it via an instance of X.

ExternalAccessTest, on the other hand, simply cannot see doSomething(). This is true for X, because X and ExternalAccessTest are in different packages. But perhaps it’s surprising that it cannot see it in Z, which is in the same package as ExternalAccessTest. The reason is that although Z inherits doSomething from its parent class X, because doSomething() is in fact declared in a different package, that method is not visible in the new package.

It’s this final case that seems to cause the most confusion. Z does inherit the protected method doSomething(). But that inheritance is restricted by that protected access modifier. The inheritance doesn’t “override” the original declaration.