Labs

About labs

For the purposes of our grading scheme, labs count as assignments.... Think of labs as being like secondary school (high school) science or social science labs. Exploratory learning experiences. Try something out, answer some questions, learn from the experience.

What to do:

• You must follow the steps I give
• You must answer each question I ask

• You may also try other things
• You may also comment on other things you noticed
• You may ask me additional questions

These are labs, so you should (ideally) have at least one lab partner. Now, some folks are going to do their labs remotely, and may have a harder time finding a lab partner. Still, try your best to find someone to talk through the lab with. In the end, however, each person turns in their own lab report.

Information about how to submit lab reports coming tomorrow (Tuesday).

Lab 1: Exploring the terrain

I'm going to post this in stages as I am running a little late in getting this up, and want you to be able to get started as class starts.

1. Create and validate a simple XHTML web page, with some text, etc.
   • Store the web page on the disk somewhere. This means you'll use file:/// to access it from the browser (like last time)
2. Open the Selenium IDE and create some trivial tests for your web page, just to get an initial test page that you can edit by hand.
   • Look at the 'source' tab and study each test a bit to make sure you understand it.
   • Can you write any tests by hand yet?
3. Now, look at chapter 1 and 2 of the Javascript Phrasebook, and look for some simple behaviors ('common phrases') that you can figure out how to write tests for easily, on a behavioral level (in other words, check for the desired behavior, don't check to see that the code worked.)
   • One example is displaying the modification date, but there are many others in Chapter 2.
   • Do NOT add the code to your web page yet!
4. Add the test(s) to your test page.
   • You will have to do this by editing the source code, not through the recorder, because you have not added the functionality to the web page yet.
5. Run your test(s). What happens?
6. Now add the Javascript phrase to your web page and run the test again. What happens?
7. Open up Firebug (if you have not already done so), and look at the Code Coverage window. What do you see?
8. Explore the DOM and Scripting windows as well.
9. Do steps 4 through 7 for another behavior/common phrase. Iterate until you start to feel a little more confident about the process as well as what it is revealing to you about the underlying infrastructure. Don't forget about all those behaviors that you skipped over thinking 'no way!' - they can (and should) all be developed this way.

Questions (These are in addition to the questions embedded in the steps of the lab. Those questions you should answer as part of your "narrative" - the story of how you did your lab. These questions are more general, for reflection.):

• When you develop pages this way, the browser is 'serving' your web pages to you, right? So why is it a client, not a server?
• The browser is translating the web page, including the javascript (we use the term 'translator' to include all kinds of interpreters and compilers). Does that make the browser a translator? A virtual computer? What part does the DOM play?
• What are your first impressions of code coverage now that you've seen it used a little bit.?
• What do you think of this 'immersion' process as a way to learn web development? What would help?

Lab 2: Visualizing websites as abstract objects

You should be working towards completing the first pass through the abstract object for Wednesday, writing a rough draft of the parts of the lab report you have covered as you go.

Short-term learning objective: better understanding of XML and DTDs.

Long-term learning objective: start to internalize a vision of websites as abstract objects.

Goal of the lab is to write a DTD for the CSUEB undergrad CS major (with options, etc.) and XML for a page displaying one of the various options.

On Monday, we'll collaboratively work on turning what is currently written more as an assignment into an exploratory lab format. After Monday's class, I (Prof. Holz) will take the data I collect from class and expand this version into a more formal lab assignment. We'll spend some time on the lab in class on Wednesday as well, to see how things are going.

1. If you need to brush up on XML or DTD, go over the tutorials at W3C schools.
2. Before you start looking over the major, discuss with your partners whether you are more verbal, more visual or more kinesthetic (movement) in how you think and how you express yourself. It's important to sketch out your abstract object in the abstract, before worrying about implementation details. The modalities in which we express information on the web is extremely important: knowing what modality(s) you naturally tend to use to mediate your own cognition is an important part of being effective at that cognition.
   • look up modality and multi-modality as it relates to expressing information on the web. Record your research in the lab report as data (quotations) and interpretation (paraphrase and relate to the lab). Don't forget to cite your source(s).
3. Choose a tool(s) to build your object in the abstract. For visual thinkers, open a drawing program, verbal thinkers, open an outlining program.
4. Now go over the undergrad major, sketching out the options using the outlining and/or drawing program. Complete the whole abstract object before you spend much time dealing with implementation details.
   • obviously, you will need to play with the DTD semantics somewhat, as you need to learn the general shape of the abstract object. But resist spending too much time on syntactic details.
   • anytime you need to change your model - move things around, change the level of abstraction, etc., stop and make a note. What did you change? Why? Try to see if any kind of pattern as to the

• • you'll need to decide what to put into the model and what to leave out. What level of detail should be included? Keep track of each decision you make. Those are assumptions. They are important to make explicit (more about this to come).

1. Sketch out one of the options in XML to test out your DTD. Did your DTD work? Was the level of abstraction correct? Too specific or not specific enough?
2. Trade your initial design for the DTD and XML with another lab group. Make comments on their initial design. Include their comments verbatim (if you don't know what verbatim means, look it up...) in your report, then analyze those comments and respond. Remember that you don't have to agree with what they said, but you should understand them. Also, include your comments on their design in your report, but you'll be able to look in again later, so you don't need to panic and include those now.
3. Go back and revise your DTD in light of what you have learned.
4. Code one of the options for the major in XML.

Reflective questions:

• (to come - in lab 3, which follows on lab 2)

Lab 3: Websites as abstract objects, part 2

This lab follows on from lab 2. To write a report for a lab that builds on a previous lab, what you do is reference the previous lab report, just like you would reference any other published material. You need to give people enough information that they could find the exact report to which you are refering. I like to use the IEEE Computer Society Style Guide Reference format, because it is so comprehensive.

1. This lab started using materials from a class prep assignment, so if you have not done that class prep, you need to do that first: write some XPath and XSLT for the XML you wrote for lab 2. Although you should get it running, don't worry about polishing this XSLT, that will come later.
2. Your XSLT depends on your XML, which depends on your DTD. Look at the XSLT and ask yourself if there are changes you could make to the XML (or to the DTD) that would make the XSLT more efficient? more expressive?
3. Go back to your DTD and make some of the changes that resulted from step 1. Make the changes to both the abstract object (picture/outline) and the concrete realization. Discuss how your abstract object compares to the one from lab 2.
4. Now write the XML for the same option you did in lab 2, but for your revised DTD. Again, discuss how your XML compares to the XML from lab 2.
5. Finally, go back and redo the XSLT that you did back in step 0. This time, validate the XSLT thoroughly. Think this through - we discussed the validation process in class.

Reflective questions:

• What do the differences in the DTD and the XML between this lab and lab 2 tell you about yourself about a designer of abstract objects?
• Looking back over these two labs, what can you say about your role in a design group?
• How do you plan to approach designing an abstract object next time?

Lab 4: Understanding Events

My goal with this lab is to help you start to develop a true intuitive (gut feeling) understanding of event-driven programming in general, and Javascript events in particular. To achieve this goal, I'm going to change the format a bit.

While we've worked with events off and on throughout the course, this is the first time they will be our primary focus. So I'm going to ask you to do some reading, and do the lab along with the reading.

How can you work with lab partners, you ask? Think like a teenager! Use a cell phone, instant messaging,email, etc. Don't put off starting on the lab - start now, and when you get stuck, send email to your partners and do something else for a while...

1. First, retrieve your final versions of the DTD, XML and XSLT from lab 3. You'll use them in this lab (since you know them so well.)
2. Open up Firefox with Firebug and/or Selenium IDE in 'info' mode.
3. a. Start working your way through Chapter 17 (Events and Event Handling) of -People.SwethaJavaScript: The Definitive Guide, 5th Edition_ (in Safari Books). You may find that you want to go back and skim over Chapter 13 first. As you go, try to figure out how to build Javascript event handlers for each type of handler listed in Table 17-1. You may find the online Safari Book Dynamic HTML: The Definitive Guide: 3rd Edition a lot of help in doing this, especially the section on Scripting Events. Also, don't forget about Chapter 21 in Javascript: The Definitive Guide, which talks about Javascript and XML. Also Chapters 5 & 6 in the Phrasebook. Chapter 4, on CSS, may also help with designing some handlers.
   • for each event handler:
     • validate the handler (test it to make sure it works, and add the test to the lab)
     • give the modified XSLT, XML and/or DTD, as necessary
     • explain your modifications
     • was it easy to figure out? hard? why/why not?
     • what resources did you use to build your event handler (which reading, which tools, etc)?
     • In order to do this, you'll have to change your DTD, XML, and XSLT. Pay attention to the changes that you make, as you go.
4. b. Styles (CSS) go hand in hand with Javascript. This relationship is not obvious when you read 3rd party books on the languages, because, while a syntactic relationship does exist, the important relationship is semantic, or design. Let me explain that differently. Many aspects of a web page can be expressed in multiple ways; that is the nature of agile languages. All of those ways, however, are not equally 'good' in every situation. So, for example, you can set the color of text using a color attribute of the HTML tag (bypassing styles altogether) or through a class attribute (using a style sheet.) Almost always, the latter is the better choice, as it organizes text into classes, reflecting the design of your abstract object. Javascript operates by manipulating the elements of the web object, most often the styles of the web object. So, learning to be proficient in Javascript involves learning to 'think in styles.'
   • for each event handler:
     • build styles in a stylesheet for the event handler, if necessary
     • an example of how to call a separate stylesheet is in the topic example in the course materials entry
     • look at how those styles interact with the javascript
     • make notes about your observations. a good place to do this is as comments in the css file
5. Once you've got the handlers working with Firefox, try the same code with Internet Explorer. What happens?

Reflective questions:

• Now that you've worked with the events a bunch, would you change anything about the design of your DTD?
• Do you understand why it is important to have the option to have events bubble and not bubble? Can you give an example of a situation with the CS Major in which you would want to have an event bubble and one in which you would not?
• How do the styles and javascript interact? How do they relate to the template-matching aspect of XSL?

Lab 5: Working with CGI

My goal with this lab is to get you working with CGI the modern way. We're way beyond what a 3520 class normally achieves in terms of developing a real understanding of how the web works, so at this point the labs have become somewhat freeform. You are helping me structure labs for the future, but by writing about your process and what you are learning, you can continue to integrate your knowledge into the structure you have been developing all quarter.

In fact, that is the fundamental lesson of this quarter. If you use this approach to all of your exploration in computing, you will integrate and retain new knowledge far better than you have in the past. That's why open-source systems have such extensive documentation in all of the source code - because the authors learned this trick themselves, at least in an intuitive level, and write about what they are doing while they are doing it, to help sort it out. They put it in the source because it's part of the source, part of what they are creating, but that's a topic for another day.

(There are materials in Course Materials and on my webdev resources page on dealing with CGI and on the accounts on dayz that you will probably find useful...)

The goal of the lab is to add, either to your existing code (DTD, XML, XSL, ...), or in a XHTML page, a form that calls a CGI script. You may want to start with a CGI script that does not use the CGI module, but the final version of your lab must use the CGI module.

Things to write about in your lab report and as you go:

• converting to the CGI module - what makes sense/what doesn't/why is or isn't it difficult, etc.
• usermin - did it help?
• debugging - what worked, what didn't...

A really good organizing model for this report is to look back over all five labs. Compare and contrast your experiences. We've not only been through a lot of programming languages, but through a lot of programming language paradigms, many or all of which were new for almost all of you. How did it go? Did you find your approach changing? Were some easier or harder than others? What new strategies do you have for learning new programming languages?