Assignment 5 – October 1, 2006
Due: During your discussion section
Language: Any programming language of your choice (but please ask before are using an esoteric one like Haskell or Erlang for instance ). If you want to rewrite your parser, you do not need to use a statically typed object-oriented language anymore.
Libraries: You can libraries for this assignment (yes even an XML library). But it is your responsibility to check with your TA whether you have fulfilled all the requirements. Your TA might have different requirements in addition to / in lieu of the ones listed here.
Objectives:
Sub-objectives:
TWO programmers working side-by-side, collaborating on the same design, algorithm, code or test. One programmer, the driver, has control of the keyboard/mouse and actively implements the program. The other programmer, the observer, continuously observes the work of the driver to identify tactical (syntactic, spelling, etc.) defects and also thinks strategically about the direction of the work. On demand, the two programmers can brainstorm any challenging problem. Because the two programmers periodically switch roles, they work together as equals to develop software.
—Laurie Williams
North Carolina State University Computer Science
Basically that is what pair programming is all about. Pair programming is usually emphasized as one of the best practices for eXtreme Programming (XP). XP is an agile form of developing software that might sound preposterous the first time you hear about it. Usually when we talk about software development, we envision things going mostly in one direction. This also applies to when you are doing your projects. You read the specifications and requirements, sit down and code, test your program and submit it. It appears that software is a linear process (or as software engineers like to call it: waterfall model of creating software). XP believes in doing things in little cycles: choose a few requirements (not all of them at one time), code a bit and test. Repeat until the software is completed (or when the deadline is here).
You can find out more about pair programming from p. 483 of the textbook. You can also come to office hours for a quick demo on how to pair program.
For this assignment, we will determine the pairs (might be groups of 3 depending on your section size) on Monday and Tuesday during discussion section. You must work with someone in your section. The TAs will determine the pairs.
Here are some tips to make pair programming successful:
Since you will be pair-programming, you should do your work in only one repository. Pick one partner’s repository and do you work from there. There is no code reading for this week.
The instructions that follow might be a little confusing, so please read them carefully and ask questions when in doubt.
Your portfolio generator currently generates HTML that is hard-coded for a specific set of known tags with known relations. This makes your code is rigid and hard to change. Imagine if you needed to include more information in your generated portfolio. How many places would you need to change in your code? 2? 3? If it is more than one, then you are probably a victim of shotgun surgery. This time, you are going to extend the functionality of this application by moving much of the data and the definition of the description of the data to be outside of your source code.
Here’s what you need to do.
Read a file of your own design (the format file) that represents the relationship between legal tags. The format of this file is determined by you.
The listing below is just one way of describing the metadata. If loosely follows the YAML way. You do not need to do it this way, If you want to do it in a XML-ish manner, you can.
Example of the format that describes the metadata that we have been using:
portfolio: project
project: title, date, author, summary, files, versionhistory
files: doc, code
doc: f
code: f
versionhistory: versioninfo
Listing 1: One way of describing the metadata that we have been using
How to interpret this data. This means that the portfolio tag can only contain the project tag as a direct child. The project tag can contain title, date, author, summary, files and versionhistory tags. So this example of a format file tells us the tags that we can expect.
If you know what a DTD for an XML file is, this is exactly the concept that we want to except that you do not need to use a DTD file. Creating an format file that specifies the list of tags and their hierarchy allows for new tags to be created and will allow that little code needs to be changed to handle those new tags.
Now, with the description of the metadata from above, your program should be able to generate an error when it encounters a tag that is nested improperly. For instance, having a project within a files tag.
Since the above describes basically the same metadata format that we have been using you need to add (at least) two more nested categories to it. It is up to you and your partner to decide what other information would be useful to have.
You might also want to consider adding the “multiplicity” of each tag. For instance, maybe the title tag should only occur at most once. So if you see it twice you should throw a warning and take the most recently encountered one.
You can still make the assumption that valid text can only occur in the leaf nodes.
Come up with a way to generate your new metadata file automatically. This is similar to what you did in assignment 4. This is where you should be going: “Wait a minute…. how can I possibly generate the metadata file easily if my metadata description can change?”. Yes that is exactly true. So now you have a conflicting interest. Even if you have a flexible parser, your metadata generator is going to be very specific.
Well, there is nothing much that can be done. It just shows that some change are harder to accommodate than other changes. Your metadata generator is going to be tied down to your what information you need to extract if you use method one from the week before. If you use the GUI method, then your GUI has to change too. Although, if you are really ambitious, you and your partner can try playing around with Jelly Swing, XAML and GladeXML. Jelly Swing (project does not appear to be active) allows you define your user interface for Java Swing using a XMl file. XAML does the same but for .NET. GladeXML uses the GTK libraries. If you used a web interface, then it is probably even simpler! Just generate a new form layout from the metadata description language.
So for step 2, you can make your metadata generator specific to the new metadata format you defined in step 1 (remember to take into account the two new tags that you defined). Or you can make it a dynamic user interface that can change to accommodate new metadata formats.
Parse the metadata file and validate it against the metadata description file. If you wrongly nested tags, you should throw an error. Again you should have an internal representation after parsing.
With this internal representation, generate the HTML. This time around you must make use of CSS to make the presentation better. I do not want to see the HTML styles hardcoded into your program. So instead of doing a transformation for <title>My Title</title> to <h2>My Title</h2> your program should now output <div class="title">My Title</div>. If you do not know CSS that well, go use a CSS editor or use a template from somewhere. So, if you need to change the style for your title, you can just go ahead and modify your CSS file so that it has some lines that go:
.title {
font-size: large;
font-style: oblique;
font-weight: 300;
font-variant: small-caps;
text-transform: none;
letter-spacing: 1px;
color: #0070d1;
}
UPDATE: Using the method above will take care of the styling for a lot of tags generically: just place each tag into its own div. However, it does not take care of the fact that for links, you cannot just place the link in a div and expect it to link! You need to use the <a href="some_url"> </a> tag .I am interested in how you solve the problem of designating one tag as the link tag while trying to keep it flexible. If you have already done it in some way, then just show that method during discussion section.
This step might seem kind of pointless to some of you. However, I can assure you that aesthetics is one of the most important thing in a web page. You should do your best to make it look good. Even most projects on SourceForge.net have a decent looking home page.
Again, using a CSS file for styling makes it really dynamic and easy to change your HTML layout without touching your program’s. source code.
And that is the assignment for this week. Next week you will be working in the same pairs. We will be dealing with databases and web scripting languages. We will provide you with PHP and MySQL access (hopefully. TSG has been rather tardy in replying). Some of you will want to use something else. You can use any other web database or web scripting language but you have to provide the facilities by yourself. You are NOT allowed to use a web framework like Django or Ruby on Rails or Hibernate or Struts or…. More information on the next project will be provided soon.
Grading:
Notes
Each person in the pair will get the same points for the technical and style aspects. Your participation points might be different. Also be aware that just because you are able to explain the program better than your partner does not mean that you get higher points. All it shows is that you did not collaborate properly as a pair while coding.
Does your HTML output look nice? You get a 1 if you only have plain HTML. You get a 5 if it looks good enough. There are no in-between points.
Does your program feel like an application? I want to see a program that is easy to use. It should be easy and flexible enough that other people can use it. That means that you do not hardcode the input file or output file name. And your program provides feedback when something goes wrong instead of just silently crashing.