A Strike

This week, our faculty union went on strike to protect the quality of our institutions.  In particular, the Chancellor's office was attacking adjunct faculty (trying to put them at a lower pay scale and raise the percent of adjuncts we should hire) and tenure (they were trying to be able to retrench without regard to seniority and to move us between institutions without discussion with the receiving institution).

Engineers don't strike, so I really had no context for how to deal with this.  However, I agreed with the principles the union was fighting for and I trust my colleagues who lead the union.  We were on strike for three days and it was eye opening.

I learned that I have colleagues across this institution that I have never met and we agree on so many things.  I knew they were there, but they weren't really real to me before this.  I have a new interdisciplinary connection to this institution that I will work to remember.

I learned that our students are INCREDIBLE!  They backed us by bringing us food (a bbq with burgers and dogs for everyone and more donuts, cookies and coffee than we could consume).  They backed us by marching with us.  They backed us in they way they spoke to the media, the Chancellor, and the Governor.  They backed me personally with private messages of support, too.

I learned that, together, we can change the tone of this institution.  When Dr. Cedia was our president, he would talk about the "Ship Family" and everyone knew exactly what he meant.  We stood together against the pressures from the state and took care of each other when things were difficult.  Our students clearly understand "Ship Family" even though Dr. Cedia is gone and our current administration doesn't seem to really embrace that term.  Having been reminded, I don't believe our faculty will let go of that very soon.  The student are our allies and they took care of us as much as we try to take care of them.

I hope that the institution recovers quickly and that we can move forward with a renewed commitment to Ship Family.

Testing for Code Structure

Our students learn to use Test-Driven Development in CS1, so they are pretty good at writing tests by the time they are in our upper division courses.  This week, in my Large Scale Architecture class we hit on a different kind of testing that they hadn't seen before: testing the structure of the code.

We were studying the Lazy Load pattern and ran into this quote in the text: "The most intrusive elements of ghosts is that every accessor needs to be modified so that it will trigger a load if the object actually is a ghost." [Patterns of Enterprise Application Architecture by Martin Fowler]  That quote generated a great discussion when we asked these questions:

• What happens if you forget that in a getter?
• What happens if you forget that in a setter?
• How does inheritance affect that?

In the end, we decided that this represented a pretty big risk, so I asked the students if they could write a JUnit test that, given a class, could verify that all of the getters called the load function. (I left out testing setters because they have the additional challenge of passing the right type of object into them.)

After some discussion, the students wrote a "verifier" class that uses reflection to find all of the getters in a given class that extends a Ghost class, calls each one and makes sure that each one has the side effect of calling a load method.  This has two significant questions:

1. Should you test inherited getters?  The answer is yes, but then you also inherit the getClass() method, so you have to handle it separately
2. How do you check if the load method is called?  This one is a bit harder.  The solution they came up with was to make a mock class that extended the class under test overriding the load method.  The overriding method would either set a boolean or increment a counter when it was called.  The JUnit test could use the verifier to call all of the getters on the mock class and verify that the load method was called correctly.

I like this lesson because it shows the students that we can use JUnit tests to test the structure of the code in addition to testing its behavior.  That allows us to put in place safety nets that catch us when we forget things like "every accessor has to call the load method." 

What a useful class period that one was!

Getting Ready for the Next Phase

Getting Ready for the Next Phase

This is my twentieth year as a faculty member and my fifteenth year as a department chair.  This summer I emptied my office and redecorated because it is time for a new beginning.  I have always loved this job, but I don't want to let it become a mindless habit.  I enjoy thinking about how I approach my job, my students, my faculty, and my administration.

So, to help make sure that I don't lose that focus, the goal of this blog is to help me remember to pay attention to the details even though I have done them for so long.  Perhaps there is still a better way for me to present material, design assignments, grade exams, assess my classes, revise the curriculum, negotiate for budgets and staff, etc.