Remember One Another

Today, over a delicious Mexican lunch, Mr. Chandler and I met with Mr. R, a graphic designer and a believer. Mr. R has been gracious enough to assist us by designing a logo for ROA. At this first meeting, he showed us variations on a number of concepts.

While I manned the laptop on which we viewed the images, Mr R and Mr. Chandler discussed the ups and downs of well-known symbols and various shapes and abstracts. After discussing both the look and the message we desired in the logo, they finally narrowing the field to a few of the designs, which Mr. R plans to refine for us.

We spent most of our office time today refactoring our properties files. Before today, the ROA project used separate test and server (“web”) versions of application.properties, each containing a simple list of properties to be accessed by applicationContext. These properties defined our databases for the project. Separate test properties were used so we would not interfere with our server DB, and could use, for instance, a DB set to re-create itself every test, instead of updating.

Because we edit the project on a local computer, but deploy it to a webserver, we had pulled the webapplication.properties out of versioning and Eclipse, and created two different versions, on similar filepaths, one on the webserver, one on my local machine.

Today, to get these configuration files back into source control, and to simplify our code, we made two major changes.

First, we reinstated a generic applicationContext file, which extends truncated webapp… and testapp… files. These latter files now contain very little other than pointers to their respective properties files, as well as the generic context file.

Second, we created a new project under subversion called ’siteconfig’, and committed the test and webapplication.properties files for both the local machine and the webserver. We are now free to add more machines as we wish, and can edit only the appropriate files, but still maintain them in source control.

Difficult aspects of these two changes included getting the new Subversion project created properly, and making sure that the project knew on which box — local or web — it was running.

The Subversion software can be rather picky at times. There are some processes that can only be accomplished by a particular sequence of user actions and others that do not appear to be allowed at all (we are still learning!). This strictness is part of why the software is useful — it defines a certain way of handling files so that multiple users are prevented from accidentally overwriting or duplicating each others’ work. A bit of trial-and-error soon solved our naming and file placement problems, and we were able to commit our files to version control.

The problem of letting the project know which location it was running in was a bit more difficult, and, while Mr. Chandler did all the work on this one, it is, for lack of better subject matter, today’s Note for Dense Summer Interns:

In applicationContext, we parameterized the path to the new siteconfig files, calling ‘${tm.site}’ rather than hard coding the path and forcing ourselves to use two more applicationContext files. Now all we had to do was to configure the project to recognize the variable, and, more importantly, its value…

After much terminal and vi work, Mr. Chandler discovered that the correct place for a variable on our webserver was in the Java options for the ‘/etc/profile.d/java.sh’ directory. In order for the ROA project to pick up the values, we could either log back into the webserver, or start up another terminal window to trigger it.

For our local machine, Mr. Chandler put the variables into /etc/profile.

For running tests on Eclipse on the local box, Mr. Chandler used the following process. In Eclipse, he selected ‘window’, ‘preferences’, ‘installed JREs’, and ‘edit’, and added the new ‘tm.site’ variable to the default VM arguments.

Coding Axiom of the Day: The best way to fix a coding problem is often to delete things. Mr. Chandler and I have found this to be true in numerous situations, from last week’s headsmack to a problem with today’s new Subversion project, the latter of which was solved by deleting everything out of the filepath for the new project, allowing Subversion to recreate it.