Moving the Curve

Michael Eaton asks: how did you get started in software development, and I’m answering.

How old were you when you started programming? I’m another late bloomer. I remember having access to an early edition Macintosh for a short period when I was 13 or so, but it didn’t take. I didn’t really start programming until after I made my first web pages (I don’t count HTML as programming, sorry) and wanted to add some functionality to them. That would have been when I was 24 or so.

How did you get started in programming? I like to tease my father that he could have saved a lot of money if he’d encouraged me when I first asked for a computer (shortly after the aforementioned school Macintosh). Instead I ended up getting a degree in International Politics and starting down the researcher path. Then one day I realized I was having more fun maintaining and modifying the FoxPro relational database that went along with the research than doing the research itself. I eventually decided to switch careers, first into web site design (it was all the rage in 1994!) and then into development.

What was your first language? The first language I had any proficiency in was Perl. I had the great luck to be friends with Nat Torkington and got him a short gig helping out at the Web 1.0 site I was writing HTML for. He inspired me to look into the language and discover what it could do.

What was the first real program you wrote? The first useful program I can remember was an overtime tracking system, written in Perl with an Informix backend. I still shudder at the memory of the sorts of loops I wrote.

What languages have you used since you started programming? Professionally, I’ve written code in Perl, Java, JavaScript, Visual Basic, PHP and C#. I went back to school to get a Computer Information Systems degree, and learned Pascal, C, and C++ in the process, although I don’t think I can claim to have ever used those specific languages outside class. I’ve played a bit with Ruby on Rails and I’m trying to carve out more personal time to learn Haskell this year.

What was your first professional programming gig? I lucked into a position as the developer for a tech support intranet at Adaptec, which became a proper programming position as I developed the skills.

If you knew then what you know now, would you have started programming? Yes, and earlier, and with more rigor.

If there is one thing you learned along the way that you would tell new developers, what would it be? Write more code. There’s no substitute for writing code and seeing what it does. Just like anything else, it’s practice that makes you better.

When I first started, I suffered from perfectionists disease, which often lead to the dreaded paralysis by analysis. I wanted to write the most elegant code possible. But I didn’t have the skill and experience yet to know how to write that code, and ironically held myself back a bit by not just writing code and seeing what worked and what doesn’t, and why.

These days, I write code at the drop of a hat. My folders are chock full of 5 and 10 line classes that do nothing but verify my understanding of basic concepts in the language. If I have a question, I write a program first to see if I can answer it. And then I truly understand how the language works. The result is I write better code.

What’s the most fun you’ve ever had … programming? Completely refactoring an existing program. We had a Perl program that let customers submit tech support tickets into our tracking system. It was a typical example of spaghetti code, most of which I’d inherited and then made worse through my youthful bumbling. I had enough downtime that I could slowly work through the program, end to end. It was a great feeling of satisfaction, evidence of how I was learning. It wasn’t the most sophisticated program I’ve written, but it’s one of the most successful. As far as I know, that program is still in production, 10 years later.

So, how did you get started in programming?

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!

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;
}

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?

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.

I’ve seen several programmers struggle with a similar question. They create a collection of some sort, and add items to it in a loop. When they finish the loop and try to use the collection (or list, or array, or set, or map) it looks like every single object in the collection is the same one — the last one added to the array. Usually they’ve written code that looks something like this C# example:

using System;
using System.Collections.Generic;
 
namespace Stevideter.ArrayTest
{
    public class Program
    {
        static void Main(string[] args)
        {
 
            List<Person> people = new List<Person>();
            Person person = new Person();
            for (int i = 0; i < 3; i++)
            {
                person.Name = String.Format("Person {0}", i);
                person.Age = i * i;
                people.Add(person);
            }
 
            foreach (Person person1 in people)
            {
                Console.Out.WriteLine(person1);
            }
        }
    }
 
    class Person
    {
        private String name;
        public String Name
        {
            get { return name; }
            set { name = value; }
        }
 
        private int age;
        public int Age
        {
            get { return age; }
            set { age = value; }
        }
 
        public override string ToString()
        {
            return String.Format("{0} is {1}",name,age);
        }
    }
}

What happened? Why is the output:

Person 2 is 4
Person 2 is 4
Person 2 is 4

The answer is in the mystery that is parameter passing by value.

In both Java and C#, parameters are passed by value. But what this means for objects is not what you may intuitively expect. When you pass an object reference to a parameter, the value that is passed is, in fact, a copy of the reference, not a copy of the object that is referenced. Both the original reference and the value copy point to the same object. That is why you can update the members of an object in a method that you pass it to - you have a copy of the address where that object lives on the heap.

In the code above, only one Person is created. Each trip through the loop, the members of
person are updated. When people.Add(person) is called, the reference to the object created by new Person() is copied and added to the List people.

When you change the object’s values the next time through, every reference to that object sees the changes, because they all still point to the same instance on the heap. This is why at the end, every item in the array has the most recent updates. The code, as usual, is doing exactly what you told it to do.

Instead, you need to create a new object for each object you want in the array, and add that new reference to the array. This time, let’s see it in Java:

package com.stevideter.java;
 
import java.util.ArrayList;
import java.util.List;
 
public class ArrayTest {
 
    public static void main(String[] args) {
 
        List<Person> people = new ArrayList<Person>();
        for (int i = 0; i < 3; i++) {
            Person person = new Person();
            person.setName(String.format("Person %d", i));
            person.setAge(i*i);
            people.add(person);
        }
 
        for (Person person : people) {
            System.out.println(person.toString());
        }
    }
}
 
class Person {
    private String name;
    private int age;
    public String getName() {
        return name;
    }
    public void setName(String name) {
        this.name = name;
    }
    public int getAge() {
        return age;
    }
    public void setAge(int age) {
        this.age = age;
    }
    @Override
    public String toString() {
        return String.format("%s is %d", name, age);
    }
}

This time we get the results we probably expected:

Person 0 is 0
Person 1 is 1
Person 2 is 4

At this point, you might be confused by the issue of scope, and feel you must declare and instantiate the object outside of the loop, afraid of losing the object when the loop ends.

What is actually lost when we leave the for loop is access to the reference person.
But the references to the heap location for the object created by each call to new Person() still exist. So the objects are still in the heap, and can still be used via the array/collection to which they were added.

I know I still get caught now and again by the implications of pass by value in Java and C#. When is the last time it surprised you?

This article on Making Small Commits lead me to think about when to commit and when to branch a code base.

Branching is the black art of version control, and anyone who has tried it at least once has probably had the nightmare that arises from having to merge code back in.

It’s an art worth learning, however. Sometimes you’re working on a feature, or a refactor, that’s significant enough that you can’t risk partial checkins.

Now, for context, I’m a big believer in frequent checkins. Beyond the advice in the linked article, I tend to check in almost any change. Add a method? Check it in. Add a single unit test? Check it in. Version Control is my brain and my undo. I’d rather revert a version or 10, but be confident, than realize I need to go back about halfway through my current rewrite.

Given I like, and in fact need, to check in often, I feel I probably need to use branching more often, as well. An recent example was work we started for a client. Right after integrating the first elements of the new features, the client changed the current request. Entirely. However we were stuck deep enough in a combination of new elements not yet finished and concurrent refactoring that it became easier to comment out large sections of code than refactor. If we’d just branched the new feature set, and continued maintenance on the trunk version, we would have saved ourselves frustration - and the risk that comes from half-finished features that probably won’t ever make it to the top of the backlog again!

What is your philosophy on branching your code base?

This post on the JavaRanch Big Moose Saloon led me to fire up Eclipse and write some test code. The question is basically how can you use the ability to map a parent bean as part of a bean definition in Spring.

Let’s look at three classes and see how they can be mapped using Spring.

public abstract class SuperBean {
	private int id;
	private String name;
 
	public int getId() {
		return id;
	}
 
	public void setId(int id) {
		this.id = id;
	}
 
	public String getName() {
		return name;
	}
 
	public void setName(String name) {
		this.name = name;
	}
 
}
 
public class SubBean extends SuperBean {
 
	private String newProperty;
 
	public String getNewProperty() {
		return newProperty;
	}
 
	public void setNewProperty(String newProperty) {
		this.newProperty = newProperty;
	}
 
}
 
public class DifferentBean {
	private int id;
	private String name;
	private String myProperty;
 
	public int getId() {
		return id;
	}
 
	public void setId(int id) {
		this.id = id;
	}
 
	public String getName() {
		return name;
	}
 
	public void setName(String name) {
		this.name = name;
	}
 
	public String getMyProperty() {
		return myProperty;
	}
 
	public void setMyProperty(String myProperty) {
		this.myProperty = myProperty;
	}
 
}

now let’s map them in Spring:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd">
 
    <bean id="superBean" abstract="true"
        class="com.stevideter.spring.SuperBean">
        <property name="id" value="1" />
        <property name="name" value="superBean" />
    </bean>
 
    <bean id="subBean" class="com.stevideter.spring.SubBean"
        parent="superBean">
        <property name="id" value="2" />
        <property name="newProperty" value="subBean" />
    </bean>
 
    <bean id="differentBean" class="com.stevideter.spring.DifferentBean"
        parent="superBean">
        <property name="id" value="3" />
        <property name="myProperty" value="differentBean" />
    </bean>
</beans>

And now let’s write a simple app to show what happens with these mappings:

import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;
 
public class TestClass {
 
    public static void main(String[] args) {
 
        ApplicationContext context = new ClassPathXmlApplicationContext(
                new String[] {"applicationContext.xml"});
 
        SubBean subBean = (SubBean)context.getBean("subBean");
        System.out.printf("ID: %d, Name: %s, Property: %s\n",
                                subBean.getId(), subBean.getName(), subBean.getNewProperty());
 
        DifferentBean differentBean = (DifferentBean)context.getBean("differentBean");
        System.out.printf("ID: %d, Name: %s, Property: %s\n",
                                differentBean.getId(), differentBean.getName(),
                                differentBean.getMyProperty());
    }
}

If we run this class, we get the following results:

ID: 2, Name: superBean, Property: subBean
ID: 3, Name: superBean, Property: differentBean

What we learn from this is that you can use the parent attribute to map to a parent bean definition that your bean class doesn’t inherit from. What’s necessary is that the classes are compatible, which means that the child class has all the properties that are defined in the parent class. In fact, the documentation notes you don’t have to declare a class on the parent definition at all.

I find it more useful to think of the parent definition as a template, to avoid the trap of thinking it is an object-oriented style of inheritance. Another way to think of it is as a parent interface for the child bean; you must implement these properties in order to use this definition.

I signed up for Twitter way back in the day when picking a short name (smd) was important because most people I knew were still using it for the intended SMS purpose. Like so many other new services, I more or less forgot about it, occasionally checking back when someone mentioned it.

In the past week, I caught Tweet fever (I blame avflox’s livejournal post) and have seriously been experimenting with Twitter again. Naturally the web interface wasn’t interactive enough for me, so I started experimenting with clients. Many people have been recommending twhirl so I gave it a try.¹

Overall, twhirl is quite nice, although I find myself constantly accidentally exiting by clicking the ‘x’ on my client. Since twhirl appears in my system tray, I expect closing the window to minimize it to the system tray, not completely exit the program.

That aside, my biggest annoyance was that when I clicked a URL in a tweet, it was opening up in IE instead of Firefox, my default browser. I found reference on the twhirl site to how to fix this issue in Vista, but no posts or comments about this being an issue in XP.

I had Firefox check, and it believed it was the default browser. IE knows it’s not the default browser. When I click URLs in Outlook, they open in Firefox.

I went to Control Panel > Add or Remove Programs > Set Program Access and Defaults > Custom and saw that while “Use my current Web Browser” was select as the default, Firefox didn’t appear on the list. Just IE and Safari. As an experiment, I chose Safari, went to twhirl, clicked a URL, and sure enough, it opened in Safari.

So I reinstalled Firefox, went back to the control panel, and saw that Firefox was now an option. I selected it, clicked ok, and clicked another URL in twhirl. Finally, success.
–
[1] must. resist. obvious. rhyme.

We had a very fruitful. frank conversation with the business analyst for the main project I’ve been working on for the last two years. We discovered a lot of the pain points for users and now know there’s concrete things we can do in the next sprint or two to really help them out.

But what really made me smile was her comment, while describing the current user workflow, that a feature I spent a lot of cycles on was really appreciated. “The users love that, it really saves them a lot of time.”

It was frustrating to implement, with lots of tiny gotchas, while not being terribly technically interesting. I must confess, I didn’t particularly enjoy coding it. So it was a great reminder that even the drudge work can make a difference.