Tuesday, October 26, 2010

Future of Education Task Force

As you may have read in the Muncie Star Press, I am on the Future of Education task force here at Ball State University. Contrary to the headline, competition from online institutions is not the primary motivation for the task force. Rather, our mission—as articulated by the task force co-chair— is:
Students coming to Ball State now and in the future are more technologically inclined, how do we tap into their expectations and mindsets to create a more relevant and better learning community?
I suggested that this be edited into a more relevant form, to wit:

How do we create a learning community?
Be that as it may, we had a major meeting yesterday, running from 9am until 3pm. The meeting was expertly facilitated by task force member and Entrepreneurship Center director Michael Goldsby. I would like to share here some of the highlights from this meeting.

We began with a SWOT analysis. Michael referred to all of the strengths, weaknesses, opportunities, and threats explicitly as "facts," and he used continuous numbering over the facts. This strikes me as significant, since I would have naively numbered strengths differently from the weaknesses, but using continuous numbering—and even continuous pagination—emphasized the fact that the ideas are more important than their categories. Several times, a task force member would say a single word or phrase that is known on campus, such as "The Working Well Program." Michael challenged with the simple question, "Why?" That is, he raised the level of discourse by forcing us out of academically-comfortable buzzwords towards meaningful facts. (For example, "The Working Well Program promotes physical and mental health among faculty and staff," a strength of the institution.)

A critical part of effective SWOT, as with brainstorming in general, is supporting divergent thinking by postponing criticism. This can be challenging for any group, and we were no exception. At several points, we devolved into discussion over points rather than supporting the creative brainstorming process. The facilitator was not always able to pull us back out. I have to admit, there was one point where I challenged a fellow task force member on a cited weakness, and it was completely unproductive to the process. I guess it's OK, though, since I did it because of my circumstances and everyone else did it because of who they are.

One of the task force members is Michael O'Hara, whose opinions on higher education I greatly respect even though we don't completely agree. He has a propensity for expressing complex ideas using just the right words, perhaps an artifact of his being both an academic and an actor. During the SWOT analysis, he championed the perspective of higher education as a humanistic endeavor rather than a utilitarian one. This point—the conflict of utilitarianism and humanism in higher education—is a critical aspect of the current debates, and I hope to return to it in later writings.

Another theme of the SWOT was the "placeness" of Ball State University. It is important for us to leverage our brick-and-mortar nature, given that much of our competition is from purely digital institutions. Martha Hunt pointed out that sustainability plays well into this discussion, that having a physical place allows for serious and grounded academic discourse on respect for physical space. As a Computer Scientist, I tend to abstract space and work with intangibles, and so it was good to have a Landscape Architect to bring us down to a discussion of what space really means.

The most challenging and intellectual elements were contributed by Matthew Wilson, whose scholarship as a humanities-minded geographer is directly tied to both virtual and physical space. In my opinion, the most meaningful challenge of the whole SWOT analysis was Matt's call for post-disciplinary thinking. Like the utilitarian vs. humanistic dichotomy, the call for post-disciplinarity cuts to the heart of much of higher education's problems. When a fellow task force member asked for my thoughts on post-disciplinarity, I pointed out that we are in disciplines, but problems, by and large, are not.

After the divergent SWOT analysis, which generated 200 facts in about three hours, we moved to a convergent mode in which each task force member had to select at most five of the greatest importance. The highest vote-getters moved to the next round, which consisted of an articulation of challenge statements of the form,  "How might Ball State University...?" Similar to the divergent-then-convergent SWOT, we started with some 25 challenge statements, each selected three, and the highest vote-getters moved forward. The final step involved the creation of a "map" of challenge statements, connected to their antecendents. As one who is well-versed in graph theory, visual rhetoric, and graph drawing, I saw this last step as particularly subject to manipulation and misintepretation, since we assumed a planarity in the articulation of a wicked problem.

I have many notes on the SWOT analysis in my blue notebook, which could be attributed to the fact that it was in the morning and was done with free coffee on hand. Upon reflection, though, I did find the SWOT the most interesting step, and the rest logically followed. I am not completely convinced that I would not have come up with the same output without investing a full collaborative day into it, but that's not really the point: the point is that now the task force has a shared experience that forms a collectively-owned starting point for the prototyping process.

Speaking of which, prototyping is next. Task force members are being put into teams to iterate through prototypes on the Future of Education. I am eager to see who the task force chairs assemble into groups, though in any case, I plan on using some of my software development tools to assist, definitely user stories and possible risk matrices. Assuming time allows, I will share my prototypes here, for my continued exercise in reflective practice and to invite commentary from the community.

Tuesday, October 12, 2010

Screencasting in Mandriva

I spent too much time today making a short screencast in order to demonstrate a specific property of Eclipse and Java. I could not find any clear recommendations on what software to use on Mandriva, my preferred Linux distribution, at least not beyond what was given on Wikipedia's page comparing screencast software.

I ended up using recordMyDesktop with the qt frontend, both of which were in the standard Mandriva repositories. You can select an area of the screen to record via the main window, but there is also a tray icon. Initiating a recording from the tray icon seems to always grab the whole screen, regardless of what is selected.
Additionally, the selection only seems to work if you choose the box and then hit record on the main window. Stopping that recording and then clicking record a second time results in having a full-desktop recording, which is not what I wanted. These complications caused me to have to throw away three reasonable takes, because it was easier to recreate them then to figure out how to crop a whole video. (Although if someone knows how to do that on Mandriva, let me know.)

With an acceptable take--although I forgot one important point, but am not willing to try yet again--I uploaded the file to YouTube. RecordMyDeskop produces Ogg Theora video output with Ogg Vorbis audio, which I think is great as a supporter of open formats. YouTube happily accepted the upload, recognizing it as Theory+Vorbis, and did its magical processing. The end result, unfortunately, had completely garbled video, just some colored flecks on the screen, while the audio worked fine.

A little scouring of the Web, and I discovered a Devede, a Linux application for mastering DVDs that can also be used to convert to AVI video format. After installing the requisite codecs, I was able to convert the ogv into avi, and I uploaded that to YouTube. Somehow it got confused and thought I cancelled the upload, so I had to do this twice, but the final one stuck.

This worked for me, but if anyone knows of a simpler and more streamlined process, I'm open to ideas.

Angry Unicorns

As I sit in office hours with no students around, I will share with you, dear reader, a tale of higher education, motivation, and an angry unicorn.

My students in CS222 are working in pairs on a two-week project, a little RSS analyzer. This was the halfway point, and we used our meeting today for each team to give a status report. After giving my introduction, I sat down so that student teams could, at their pace and discretion, come up and give their status reports. The first team came up rather quickly and did a fine job. After they collected their peer evaluation forms and sat down, there was a delay while the rest of the students considered whether or not to go next. I started a doodle, which turned out into a nearly-complete rendition of Strong Bad:
As the second group of presenters finally came to the front, I informed the class that I was one leg away from completing a sketch of Strong Bad, and that I didn't know what would happen if I had completed Strong Bad, but I'm sure it wouldn't be good.

We spent the next 50 minutes or so hearing status reports, at which time there was another lull, although by my estimation, about 20% of the class had not yet presented. So I started sketching again...
Once complete, I informed the class that I had completed my angry unicorn, and so I assumed that no one else wanted credit for presenting today. This was the first time I made any statement about the presentations being "worth credit," although the students knew that I was jotting down evaluations using the same rubric as their peers, and that I would email these later.

Immediately upon mentioning credit, there was hubbub and three more groups got up to give status reports. One of the groups had very little done, but they gave a great honest report. Another "group" was missing half, but the sole attendee gave a great synopsis of the team's status.

Most likely, it was mention of credit that made these last few get up and present, but I like to think it was the threat of angry unicorns.

Friday, October 8, 2010

All my thoughts, or, three-in-one

This morning, I attended a meeting where one of the agenda items was for each attendee to take five minutes to share:
  • The present state of higher education
  • The various responses to this state
  • How these responses point to a new vision for higher education
  • Readings to support this
Turns out, we didn't do this part of the agenda.

I'd hate for my hastily scribbled notes from before 8AM this morning to be wasted, so for you, dear reader: all of my ideas.


Java Workshop

About three weeks ago, I floated the idea of a Java Workshop to my CS222 class, and enough liked the idea for me to pursue it. Last Tuesday, I gave a two-hour evening workshop on the fundamentals of Java. Here is a synopsis of the major points we covered. The point of this post is primarily to refresh the ideas among those who attended, but others may still be interested to see what I consider as the Java fundamentals. It may be worth noting that this was explicitly about the language and environment of Java, not best practices or even software development.


  • "Java" refers to a language, an API, and a VM. It's good to be aware of this overloading of the word so that you can see how the whole system fits together, especially with the proliferation of languages that run on the JVM.
  • Java has primitive types and reference types. Primitive types are just boxes that hold values, but reference types are for objects, the fundamental building blocks of OO systems.
  • All of the primitive types have similarly-named reference types. For example, there's int and there's Integer. The difference between these reveals an important insight into object-oriented software design. Whereas an int variable is just a box that holds a value, an Integer instance is a representation of the idea of a number. Consider the following code.
    int x = 5;
    Integer y = 5;
    
    Here, x is just a box that holds an integer, and so we can say x=7, and that means we're putting a different value in the box. On the other hand, y is five. We cannot say y.setValue(7) any more than we can assert that 5=7 in mathematics.
  • It's good to recognize that y=5 is not free: it's using autoboxing to convert an int primitive into an instance of Integer. While it's true that premature optimization is the root of all evil, you shouldn't write code that creates unnecessary objects either.
  • It is critical that a Java developer builds a functionally-correct mental model of
    classes, objects, static, methods, and fields. A blog post is not the right way to help you, dear reader, to identify the problems in your own mental model. The good news is that my services are for hire. ;)
  • There are four access control modifiers that you should know so that you can read code: public, private, protected, and package-protected (which has no keyword). However, you should really only ever use public and private, so you just saved half your allocated brainspace on this topic.
  • To understand classes, abstract classes, and interfaces, I used an example like the following.
    public interface InningListener() {
      public void strikeOut();
      public void walk();
      public void balk();
      public void beaned();
      public void hit();
    }
    
    public abstract class AbstractInningListener implements InningListener {
      public void strikeOut() {}
      public void walk() {}
      public void balk() {}
      public void beaned() {}
      public void hit() {}
    }
    
    public class Inning {
      private final List<InningListener> listeners = new ArrayList<InningListener>();
      private int strikes = 0;
      public void addInningListener(InningListener listener) {
        listeners.add(listener);
      }
      public void strike() {
        strikes++;
        if (strikes==3) {
          fireStrikeOutEvent();
          strikes=0;
        }
      }
      private void fireStrikeOutEvent() {
        for (InningListener listener : listeners) {
          listener.strikeOut();
        }
      }
    }
    
    public class Demo {
      public static void main(String[] args) {
        Inning inning = new Inning();
        inning.addInningListener(new AbstractInningListener() {
          public void strikeOut(){
            System.out.println("Strike out!");
          }
        });
        for (int i=0; i<3; i++)
          inning.strike();
      }
    }
    
    A few highlights of this example:
    • This is an example of the Observer design pattern.
    • The abstract class provides default empty implementations of the methods in the interface so that implementors—like the one in Demo—can provide implementations of only those methods that they care about. This keeps the code from getting cluttered up with no-op implementations.
    • This pattern can be found throughout java.awt.event. I tend to do something a little more idiosyncratic involving inner interfaces and inner classes, but that's for another day.

  • If you're doing I/O, it's good to know that the InputStream/OutputStream family of classes is for byte-level I/O, Reader/Writer family is for character-encoded content, and the nio libraries are for blazing fast access to hardware buffers, and so can be ignored until you need it. To me, the critical classes to know are BufferedReader and PrintWriter. BufferedReader has the amazingly-useful readLine method, allowing line-by-line access to a stream, and a PrintWriter behaves exactly like System.out.



  • The classloader trick will load a resource from the classpath whether you are running in Eclipse, from a command-line, from an executable jar, in a servlet, or on Java WebStart:
    Thread.currentThread().getContextClassLoader().getResourceAsStream("whatever.png");
    



  • Here's a slapdash tour of the collections API:
    • List<T> defines a sequence. There are two useful implementations,
      LinkedList<T> and ArrayList<T>, which come with the usual caveats implied by their names.
    • Set<T> defines a set, in the discrete mathematics sense.
      The two common implementations are TreeSet<T> and HashSet<T>, but you should use the latter because you're always providing a useful hashCode method in all of your Java classes—or else you're doing it wrong.
    • Map<K,V> defines a dictionary, an associative array, a lookup table—choose your favorite mental model. Again, we have TreeMap<K,V> and HashMap<K,V>, and you should use the latter and override hashCode in all of your classes.
    • Finally, use guava.



I think that's everything we covered, except for some of the more specific questions. I hope this post is helpful to someone looking for a birds-eye view of Java. As I mentioned at the workshop, when I started using Java in 1998, there was not much to learn and there was basically one place to go to get started. Now, I imagine that novices can be easily overwhelmed by the immensity of just the standard libraries. By the way, the good news here is that the best place to go for an introduction to Java—as long as you aleady know something about programming— is still The Java Tutorials.

At what point intervention?

I find myself very nervous about this afternoon's 3:15 Studio meeting. I have a feeling that some key PBIs are going to be missing, but there's a sense in which that is fixed through Scrum by carrying them over with high priority to the next Sprint. My deeper concern is that the developers are losing steam, in large part because they have been myopically looking at the PBIs rather than keeping one eye on future needs. Alistair Cockburn put it best when he described software development as a cooperative game with two goals: first, meeting the needs of the current iteration; second, setting up for the next one. In looking over students' shoulders, eavesdropping in discussions, and directly working with them, I see the students expending all their effort on the first goal and almost none on the second goal.

There are various things I can do to help as a Product Owner who is also the lead software architect. I could invest time in developing a robust technical design document that describes the pieces of the architecture that are not yet in place. I could run through the product backlog and come up with reasonable estimations for every PBI so that I can make a product burndown chart to show studio velocity.

The key dilemma I keep coming back to, however, is this: at what point to I just sit down and write some code? The game is already based on an entity architecture kernel that I provided, and I am one of the principle stakeholders in the success of the project. I see some of the students seriously struggling with code that, to me, is at most a two-hour job. There is value in having students struggle through these problems so that they can develop problem-solving skills and learn to deal with frustration. On the other hand, one of the best ways to learn is by working with someone more talented. At what point is it better for me to just show them how to write it rather than trying to coax it out of them? For that matter, how do I know when it is better for the project for me to add modules or refactor modules students have already created? These questions make me nervous, and I think it's because there's no "undo" button for teaching.

In my mind, I keep coming back to the Confluence project, where I worked right alongside Carrie and Josh to build that system, and it was good: the system worked and they learned. For that project, I had release time to develop it, and both students received independent study credits, and I don't have any doubt that we did the right thing. 3:15 Studio is formed out of a "regular" class, with an order of magnitude more students. Does that mean it is any different?

Wednesday, October 6, 2010

Civilization, War, and Learning

Those of you who follow my Facebook posts have probably figured out by now that I broke down and bought Civilization V. It's the latest by Sid Meier, whose Pirates! is one of the best games I have ever played, but that's a post for another time. For those who are not familiar with the Civilization series, they are turn-based strategy games that follow the development of civilization from ancient times up to the modern age. Although they are a hallmark of PC turn-based strategy gaming---and I love turn-based strategy games---I have never played any games in the series until now.

Last night, I finished my first game of Civ V. I used the default settings, which were for beginning players, and I happened to be playing as the British Empire. My civilization developed much faster than the opposition, probably more because of the low difficulty setting than any clever strategy of mine. There are multiple ways to win the game peacefully: scientific leadership, diplomacy, and cultural development. Because my civilization was advancing so much more rapidly than my opponents, I took the classic gamer's optimization approach: military victory. After all, why wait for my inevitable cultural victory when I can just send my superior army to crush the opposition and annex their land to mine, thereby winning the game?

As my army crushed the opposition, the in-game music turned from pleasantly ignorable and ambient into rather dark and sad compositions. Every time I declared war and sent my troops over their borders, the music set the mood not of a glorious conquest, but of grief and despair. As my navy bombarded coastal cities, they caught fire, and I could hear the screams of civilians. As I destroyed the last city of the Indian empire, Gandhi appeared on the screen and congratulated me on destroying a kind and peaceful people. As I defeated my last opponent, I received the end-game screen, an image of WWI-era soldiers marching over a barren land, and again the music set a somber tone.

Here is a great example of the power of learning in games, following the themes in Koster's Theory of Fun. The game is clearly designed to be fun, and there is a sense in which my military victory was enjoyable, but even more than that, it made me think. The formal elements of the game (the rules) combined elegantly with the dramatic elements (the music and story) to produce a unique experience. Most games I play follow a single hero who single-handedly destroys the vanilla-evil opposition, and there was much rejoicing. In Civ, I actually felt guilty for destroying these other civilizations just so that I could "win."

I hope to be able to draw on this in my current efforts with the Morgan's Raid game (as well as the potential Underground Railroad project), where there is a similar lesson we wish to subtly teach: although the player takes the role of John Hunt Morgan, he is neither inherently a hero nor a villain, but the Civil War was undeniably an ugly and painful thing. We have an interesting design constraint in the game as well. Since it is designed for 4th grade students to play in schools, it's likely that it will be played without music, in crowded labs or during free time. It was the somber music of Civ that moved me the most; I can only wonder what would have happened if I had been playing without my speakers on, since I can never go back to my first experience.