Is It Safe?

For the last couple of days I have been contemplating buying another fire-proof security file. I currently have two Sentry KS-4100 files.

I keep a lot of records: Some are important, like identification documents for three countries, my last will and testament, lease agreements, insurance policies, deeds of ownership, computer backups, and, yes, even tax records. Others hopefully aren’t so important: Receipts for many of the items I have purchased. My credit card has a nice benefit that extends the manufacturer’s warranty by up to a year, and to claim that benefit, I need the receipt. Also, in case of a disaster that destroys my property, my renters insurance will want to examine the receipts so I can be reimbursed for the purchase or replacement costs, not just what the lost items were worth at the time.

Unfortunately, I’m running out of room for these receipts. While looking at buying another KS-4100, I more closely inspected its UL-72 certification. This particular Sentry file is manufactured to keep the interior at or below 350°F (177°C) for a fire that rages at 1550°F (855°C) for half an hour, which is apparently typical for an apartment fire.

As we all know, paper burns at 451°F (233°C) and it singes a bit sooner, at about 405°F (207°C), so keeping the interior of the file at or below 350°F keeps paper safe. Sentry also states that “CDs, DVDs, USB drives and memory sticks” are protected.

CDs and DVDs are mostly made of polycarbonate, with a melting point 513°F (267°C); jewel cases are mostly polystyrene that melts at 464°F (240°C), so CDs, DVDs and their cases are protected. I didn’t check the material of memory sticks and USB drives, although I’m a little worried about my portable hard drives now.

However, I also keep credit cards and ID cards in there, and they are usually made of polyvinyl chloride (PVC) (@I have since been corrected that credit cards are usually produced from polyvinyl chloride acetate, or PVCA, but I haven’t found the melting point of that yet.@), (@Apparently, the properties of PVCA can vary a lot, but one low figure that was provided to me was 257°F (125°C), which is still too low to be protected in the KS-4100 security file; PVCA cards would probably be safe in the expensive Sentry 6720 media file mentioned below.@), and I organize the receipts in nice colorful transparent polypropylene (PP) draw-string envelopes. PVC products, and therefore nearly all ID and credit cards, melt at a mere 176°F (80°F), and my PP envelopes melt at 338°F (170°F), just below the temperature the safe could reach while working as certified.

I’m really experiencing mixed up feelings right now, and I am considering switching to paper envelopes for organization, but the PP envelopes are so much more resilient and practical, and the temperature difference from 338°F to 350°F isn’t that great. That’s perhaps a risk I’m willing to take.

With IDs and credit cards, however, that’s a completely different matter. I’m fairly certain that in an apartment fire, the inside of the safe could easily reach 176°F and melt my passports, my international driver’s licenses and ID cards, and my credit cards (oh shucks, I’ll just get new ones, Washington Mutual willing, but that’s another rant for another hour).

I could get a data-storage security file like the Sentry 6720, which keeps the interior at or below 125°F (52°C). Apparently that’s good enough for floppy disks, and assumeably for hard drives as well, but unless I’m mistaken, it’s still too hot for credit and ID cards! And more importantly, it retails more than ten times the cost of the KS-4100.

How do protect your documents? Am I paranoid? Am I a “filing rat”, and you simply don’t have documents to protect? Please send me your ideas, if you like.

Share

A Summary of COMP 312

Here’s a short summary of this semester’s COMP 312 class: We had the manpower, but not much was done.

Consider the minor projects I had outlined before the class. These are the ones I implemented on my own:

  • 145545, “Find Again” for “Find All” (Feature 1504566)
  • 145868, Allow Auto-Completion with Fully Qualified Class Name
  • 144164, Add Java 6.0 to Options
  • 145518, Make “Run” Switch to Interactions Pane Again

This one was started by other developers, but I finished it:

  • 145554, Fix Javadoc with -private flag

This one was completed by another developer without my involvement:

  • 145546, Fix Line Number Not Available in JUnit

And these are the ones we did not finish:

  • 145550, Turn on “Hour Glass” When Indenting Code (Bug 687674)
  • 145557, Empty java files cause junit test error
  • 124006, Array Entries as Debugger Watches (Feature 1356085)
  • 144162, Default Imports for Interactions Pane

Considering that we had seven developers, with four of them in COMP 312, I had expected to implement every project on this list. Instead, we only finished 6 out of the 10 tasks, and I worked on 5 of them. Only one task was completed without my involvement, and one was partially implemented, but the changes did not cover all aspects of the problem. It is sad that only two minor projects were attacked at all by the COMP 312 developers, and only a single one was completed satisfactorily.

Of the major COMP 312 projects, I had hoped that each pair of developers in COMP 312 would finish two projects, perhaps a total of seven projects. In the end, we completed three projects and made good progress on four others, so it looks like we got close to achieving my goals. However, if you consider that I completed two projects on my own, worked on another one alone, and had to finish the only major project that was started by COMP 312 students, then this part of the summary is as bad as the first part.

These were the projects I worked on without anyone else:

  • 144166, External Tools Facility
  • 145866, Auto-Completion Based on Compiled Class Files
  • 145867, Allow Auto-Completion for Standard Java API Classes

This project was started by other developers, but I finished it:

  • 145543, Automatically Add New Files to Project (Feature 1444433)

Three other developers worked on these three projects and made good progress, but did not complete the task:

  • 70906, Indent Bugs & Parser Bugs, 2007-11-19
  • 145552, Problems With New Interpreter
  • Update the Eclipse Plugin

And these major projects were not approached:

  • 145869, Allow “Open Javadoc” for JUnit 3.8.2
  • 145556, Change Double-Click Selection and Next/Prev Word
  • 145559, Ensuring DrJava’s JUnit Works With Large Projects
  • 145558, Ensure that DrJava Works after Sleep/Hibernate
  • 145553, Pasting While Inside a Comment Should Auto-*
  • 145551, java.class.path does not reflect Extra Classpath (Bug 991311)
  • 145549, Make Non-Default Key Bindings Work in All Text Areas (Bug 676588)
  • 145548, Ensure Compatibility with Windows Vista
  • 145547, Ensure Compatibility with Mac OS 10.5 (Leopard)
  • 145544, Replace All Limited to Selection (Feature 1461858)
  • 145542, Automatic Trace (Feature 1369672)
  • 145541, Imports should persist over breakpoints (Feature 1418853)
  • 144165, “Auto-Import” Dialog for Definitions Pane
  • 124039, “Search All Files” Progress and Abort (Feature 1431014)

Unfortunately, I have no idea what has changed over the last few years and why the last two or three iterations of COMP 312 less successful.

Share

Connexions Version of “Programming for Change”

Dr. Nguyen had sent me an email with an example of how to include Java applets in a Connexions document. Today I finally updated the Connexions version of our “Programming for Change” nifty assignment that I had started to create last year. The Connexions version now also includes applets, and both the original HTML version and the Connexions version now use an actual image of the star-shaped graph of conversion functions instead of ugly ASCII art.

I had to experiment a little bit since neither the example nor Connexion’s reference described how applets packaged in jar files can be used. It turned out I needed to specify the class name as source of the media, not a file name as described on the reference page of the <media> tag, and then provide the jar file in a <param> tag.

Example applet for the constant solution.

Once those additions were made, I decided the Connexions Version of “Programming for Change” was ready to be published.

In general, Connexions has probably become better. I saw that it now includes a LaTeX importer, although I haven’t tried it. It’s still a slow, cumbersome system, though, that makes a writer jump through an exorbitant number of pointless hoops. I’m going to edit all the lectures for the COMP 202 course that I will teach next semester, and I will make their appearance more consistent, but I’m not sure I also want to port all of them to Connexions. I might end up being forced to do that, even though I don’t see the value of having a Connexions port at all: No one in his right mind would want to maintain the documents.

In other news, I fixed a bug in DrJava that would throw a NullPointerException when using “Step Into” in debug mode and corrected three typos in the QuickStart guide (two found by a user, a third found when I grepped for the misspelled word). I’m glad I didn’t make that mistake, although I’m the only one who has updated the DrJava documentation since it was created almost three years ago.

I also fixed a problem with loading projects and restoring the selection and active document. I don’t know how that got screwed up again, but I know that I fixed it once already, and after that it was working.

I completed the “project auto-refresh” task from COMP 312 that wasn’t finished; now there is a menu item to invoke the feature on demand, and the black list can be edited in the “Project Properties” dialog.

I changed the “Insert Variable” dialog so that it maintains the previously selected variable; I believe this makes the dialog less confusing. Finally, I’ve been in the process of adding a few actions to DrJava that can be invoked from the command line of an external process. The actions are implemented as side effects of the evaluation of the command line: A variable used to denote an action performs the action and then evaluates to the empty string, disappearing from the command line.

So far, the following properties are available:

  • ${action.save.all} — save all source files and the project file
  • ${action.compile.all} — compile all source files and included external files
  • ${action.clean} — clean the build directory
  • ${action.open.file;file="Foo.java";line="100"} — open a file and jump to a certain line, if a line number was specified
  • ${action.auto.refresh} — perform a project auto-refresh

For example, the command line

${action.clean}${action.compile.all}find ${project.build.dir}

cleans the build directory, then compiles all files, and finally runs find on the build directory, resulting in a listing of all class files.

Oh, and I graduated, but I still, still, still don’t have my diploma.

Share

Paper: Programming for Change

Programming for Change – Nifty Assignment

OOPSLA 2006 Educators Symposium

The development of any piece of software begins with a set of specifications describing in some detail the problems to be solved. Almost invariably, the specifications change during the development of the software. Trying to anticipate all possible changes and write a program that does everything is a futile undertaking. However, it is not unreasonable to expect that programs be written in such a way that an “epsilon” (read “small”) change in the specifications will only necessitate a “delta” (read “manageable”) change in code.

Programming for change is a continual process in which software is designed over many iterations to capture the problem’s essence and express. At the heart of this process is the effort to identify those elements that can vary (variants) and delineate them from those that do not – the invariants. A properly designed software system should strive to decouple the variants from the invariants in order to facilitate the re-use of the invariants and allow modifications to the variants with minimal perturbation to the existing code.

To illustrate the importance of programming for change to students, we guide them through the development of a program that converts temperature measurements. The assignment consists of a series of small exercises, each of which imposes a small change in the requirements and forces appropriate modifications of the code. To promote code re-use, we apply the Janus Principle and require that the programs must be written in a way that supports multiple distinct user interfaces. For certain specification changes, we ask students to identify the variants and the invariants and make appropriate modifications to the code. In several situations, we require the students to modify their code in more than one way and discuss the pros and cons.

Share

Workshop: Object-Oriented Design Festival

Object-Oriented Design Festival

SIGCSE 2006

Object-oriented (OO) programming begins with analysis and design that produce a model describing the objects in the problem domain,
their relationships, creation and interactions. The workshop covers fundamentals of OO analysis and design such as abstraction, separation of variants from invariants and decoupling of system components, via appropriate applications of composition, inheritance, polymorphism, and design patterns. The workshop will progress from a small design example illustrating the principles to a larger design problem to be solved by small teams of participants. Their solutions will be discussed in terms of design goals and compared against a solution provided by the presenters.

Share

Long Time No See

Ok, so I’ve definitely been having a bad conscience for not writing. It’s not like I haven’t done any work, but I have to admit that I haven’t worked on the concurrent unit testing project since my accident. The week before that I was just gearing up to work on it again, after the hurricane. After the accident, for about three weeks, pretty much all through October, my back was hurting when I was sitting. It still stings a little bit now every once in a while. I just found it hard to work on a project like this that required working in long stretches.

So instead, I added an interesting part to the Rice Marine Biology Simulation. The simulation was already able to protect against fish that use System.exit, call thread or system functions, and cause a heap or stack overflow. The only thing I couldn’t really do anything against was a fish that diverged without using up any resources.

Initially I had thought about putting each fish into its own thread, and then killing the thread after a certain amount of time had passed. The problem with this is the way thread killing is implemented in Java: If I tell a thread to die, it is forced to throw a ThreadDeath exception at the next opportunity. However, ThreadDeath implements Throwable and can thus be caught. Therefore, it is possible to write a fish that diverges, catches the code>ThreadDeath that is supposed to kill it, and continues to diverge. At that point, I gave up.

After having worked on my bytecode scanning and rewriting framework for the concurrent unit testing project so much, I realized there’s another perspective: I can scan the fish classes being loaded for catch statements that are so general they might catch a Throwable, Error, or ThreadDeath, and if the user attempts to load such a class, prevent it. That means the fish that does get loaded has no way to prevent ThreadDeath from unwinding the stack and eventually killing the fish.

This is what I implemented. The actualy scanner was really easy to write. Writing and integrating the class loader was a lot more difficult. In Java, if the same class files is loaded by two different class loaders, the classes in memory are treated as different. Unfortunately, Java doesn’t provide a way to find out if a class has already been loaded by another class loader. I would have liked to know if a class has already been loaded by the system class loader so it doesn’t have to be checked anymore, but that wasn’t possible. Now I scan every class except for a select class of trusted classes. The new system is pretty cool, I think.

I was told in C#, it’s possible to deactivate the ability to catch its equivalent of the ThreadDeath exception, so such a class loader and scanner wouldn’t be necessary in a C# implementation.

I’ve also written a few thousand words for our OOP book. There’s still lots of work to do, though. We’re working with my temperature conversion examples, but we realized the step from the third iteration (built-in functions with quadratic growth) to the fourth iteration (lambdas, linear growth) is too steep. So we’ll throw in a shape example to familiarize the reader with abstract classes and inheritance first. I’ve been working on that, but haven’t had the time. I would like to write more, but I need to focus on other things.

One last piece of good news: The OOP/OOD workshop that Dr. Nguyen, Dr. Wong, Eric Cheng, and I have submitted to SIGCSE 2006, this time to be held here in beautiful Houston, has been accepted. So eventually we’ll have to work on that, but we’ll try to create as much overlap with the book as possible.

I finished lots of grading yesterday and today. And now I really have to dive into CUnit again…

Share

Presentation: Design Patterns for Parsing

Design Patterns for Parsing

Where: SIGCSE 2005
When: February 27, 2005

We provide a systematic transformation of an LL(1) grammar to an object model that consists of

  • an object structure representing the non-terminal symbols and their corresponding grammar production rules,
  • a union of classes representing the terminal symbols (tokens).

We present a variant form of the visitor pattern and apply it to the above union of token classes to model a predictive recursive descent parser on the given grammar. Parsing a non-terminal is represented by a visitor to the tokens. For non-terminals that have more than one production rule, the corresponding visitors are chained together according to the chain of responsibility pattern in order to be processed correctly by a valid token. The abstract factory pattern, where each concrete factory corresponds to a non-terminal symbol, is used to manufacture appropriate parsing visitors.

Our object-oriented formulation for predictive recursive descent parsing eliminates the traditional construction of the predictive parsing table and yields a parser that is declarative and has minimal conditionals. It not only serves to teach standard techniques in parsing but also as a non-trivial exercise of object modeling for objects-first introductory courses.

Share