.::output >> /dev/null::.

Jay Fields Thoughts: Are Screencasts the Future?:

He [Geoffrey Grosenbach] sent back a few more reasons why he believes in screencasts as good teaching tools.

• Efficiency of time: It takes dozens of hours to read a 300 page book straight through. But a screencast can pack the most relevant information into an hour.
• Passive/Active: You can sit back and pick up whatever elements are interesting to you. Some people say the most valuable part is learning auxiliary shell shortcuts or workflow tips.
• Graphical/Textual: I don't know any tech publisher who pays an artist to draw helpful diagrams. Screencasts are inherently graphical and it makes sense to include a few diagrams that explain the topic better than paragraphs of text would.

I have been experimenting with doing screencasts for the class that I am a teaching assistant for. As far as I know, no other classes have been using this approach. I suspect that the HCI classes might use them but I have yet to verify that.

Like the quote above, I believe that certain things are easier explained and demonstrated through screencasts. For instance, I started the first screencast for the class to illustrate how to handle resolving conflicts during a wiki edit. For people who have never used a wiki before, handling conflicts during an edit can be a confusing task. Especially if they have no idea what to do and why a conflict would occur. And so, they tend to ignore the conflict warning and erased a previous person's edit.

After some students inadvertently destroy previous edits on the wiki, my initial thought was to write a short article on how to prevent this from happening in the future. It would have to contain numerous screenshots to actually show what was going on at each step. And then I realize how long it was going to be. Moreover, it would be hard to actually describe the conflict. Instead I opted for a screencast approach.

I opened two browser windows side-by-side and edited the same page on the wiki. I then had one browser commit earlier than the other to simulate a conflict. From there I just recorded what I needed to do to resolve the conflict. The video took about 3-5 minutes and I was able to show the real scenario and what actually happens. I did not use audio in this screencast but opted to use the "show text" feature of Quicksilver to type out important messages as the video progressed. I think it worked well.

I am also a fan of using pattern languages to describe best practices. So over this week (hopefully) I will have a set of screencast patterns done. I have already drafted the patterns map out and how each pattern related to another. I will admit that I am not expert in making screencasts but I have seen enough of them that I can tell which are good and which are confusing. I think my screencasts still fall into the category of the latter and would need some work on :)

This is actually something that I spent two days on trying to get to work properly. There were a couple of variables that made this harder than necessary: the documentation on getting the latest version of Photran to compile was a bit out-dated (we need the latest version of the CDT from HEAD for the tests to run) and the fact that we are switching to Eclipse 3.3 which might not work well with all the plug-ins out there.

The plan was to run some metrics and code coverage measurements on the Photran code base. Using the data that we gathered we could evaluate sections of code that needed refactoring and/or testing. We could only use free tools since we wanted the students to be able to run them on their own computers. Naturally, if we did not have this major restriction we would have chosen some better commercial tools.

The State of Flow Metrics was the first one I tried but it does not do a good job. The UI and visual feedback were so bad that I did not even know if it was working. So, I ran the tool on a smaller project; it completed the analysis. However the information it provides is not presented intuitively. Instead it adds a little icon on the left margin of the editor that does nothing more than indicate that it had analyzed that method. Then the data is presented in the Problems view along with all the other errors and warnings. For small projects, this is fine but for larger ones with 100s (or 1000s like the CDT) of warnings, you cannot even determine which are warnings from the metrics tool (vs warnings from the Java compiler). So this is pretty much useless for large projects or workspaces with 1000s of warnings. It has an export feature that is supposed to export the data to HTML and CSV forms but it refuses to complete for me.

The second metrics plug-in I tested was much better. It had failed to work the first time I used it because it was not able to access the data that it had collected from the analysis. However, after upgrading to the latest version of Eclipse 3.3 (Version: 3.3.1 Build id: M20070921-1145) this problem vanished.

Metrics view using the Metrics Eclipse plug-in

So, now we needed a code coverage tool or more specifically one that could analyze the tests that have been written for Photran. This is slightly more tricky. We need code coverage tools that can measure coverage on JUnit plug-in tests (vs the normal JUnit tests). JUnit plug-in tests must launch an instance of Eclipse to successfully execute to completion. So a majority of the test coverage tools mentioned here cannot do a decent job.

For instance, in Photran, if you just ran the normal JUnit tests there are only 125 such tests vs 1566 if you run the JUnit plug-in tests. So the coverage is going to be low for the former execution.

There was only one free tool that I could find that offered support for measuring JUnit plug-in tests: EclEmma. The first time I installed EclEmma it corrupted my entire workspace and I had to restore everything from the repository. I installed EclEmma again today on the latest version of Eclipse 3.3 and I think I know the proper way to invoke it so that it will not corrupt the workspace: always create two different run configurations and never mix them. So, when running the Photran, you should always create 2 configurations — one that EclEmma will run and one that normal Eclipse will execute without coverage. And the workspace should also always be cleaned after running EclEmma.

EclEmma code coverage in action.

I believe that the Eclipse update fixed something to make EclEmma work properly on Mac OS X. Yesterday, there was no clean separation of an EclEmma run-time from a normal run-time. In fact, both of them were always merged in the same dialog. This could be why the workspace was being corrupted since EclEmma's instrumentation was replacing the normal ones.

Bottom line, if you want to a good metrics and code coverage tool, go with the Metrics and EclEmma plug-ins. Of course, if you can afford it, go for a commercial tool like Clover.

After reading the Tipping Point by Malcolm Gladwell, I have been slowly following a trail of books that were part of the "Customers Who Bought This Item Also Bought..." list from Amazon. And I can say that this approach seems to work quite well. All the books that I have picked up so far have been really enjoyable.

This method of choosing new books to read also has it drawbacks -- mainly that I am only reading the same sort of things over and over. However, while browsing for the book at the local Borders (I am a member so I get 20% discount coupons each week to buy some new book) I also see some other books that are interesting and would be buy them once I run out of recommendations to read. One that has caught my fancy is Zen and the Art of Motorcycle Maintenance.

I have almost completed Freakonomics and while it is an interesting read (full of unexpected outcomes) it does not warrant any real blogging on my part. In fact, I find those stories to be more entertaining -- think of coffee table conversations material with someone whom you have just met -- but not really useful in any other sense. I have some reservations toward the anecdotes in the book since there isn't enough proof to convince me of their credibility. Again, like I said, it's a book worth reading just to stump your friends on some aspect of life in the US.

But Crimes of Logic by Jamie Whyte is something different. And did I mention that this book is thin, being around 130 pages, so you don't have to make a great commitment to read it. Probably all you need is about 4 hours before bed time. And since the chapters are short and non-continuous, you could easily read one or two during the times you are free and the book will still feel coherent.

Compared to Blnk, The Tipping Point and Freakonomics, there are no out-of-the-box anecdotes that would stump most people. In fact, Whyte uses only simple examples that everyone has probably heard about through the media. And using this simple examples, he points out logical fallacies about them! And he writes with such clarity that it is impossible to miss the punch-line at the end of each chapter. And when you get it, you would be thinking to yourself: how did I fall for that in the first place?!

I was surprised too that I had fallen for some of the logical fallacies while reading the newspaper or listening to the news. In fact this was really surprising. When I read academic papers, I tend to be more critical in my reading and can detect if certain sections are there just to finagle the reader into believing the paper. On the other hand when I read a non-technical article such as an article in a magazine or the newspaper, sometimes it feels that I just turn off part of my brain that does logical thinking. Yes, this is a very illogical thing to do since fallacies present themselves in all forms of writing and they especially abound in journalism.

So why does my logical side of my brain turn itself off? Probably because I don't really care about the news that much so I cannot be bothered to analyze it. Or more likely that I had somehow succumb to the journalistic writing style that favors gossip and shenanigans such that those elements seem more interesting than the gist itself. Whatever the reason, Whyte has certainly produced a nice little catalogue of common fallacies that people commit and how to detect them.

Now all he needs to do is convince the people who commit such fallacies to read them.