Wednesday, March 24, 2010

Project 6

Due Date: Sunday, 28 March (topic selection)

Sunday, 4 April (brief outline)

Wednesday, 21 April (presentation)

Group project


Description

In this project, you will have the opportunity briefly to investigate a topic of interest in the area of client-side web development.

Given the remaining time of the semester and the length of each presentation, you are not expected to conduct an exhaustive study of your topic. The purpose of this project is for you to find and present some starting points for using a particular technology or discuss the utility of some general approach. Please consult with me if you have any questions.

Deliverables

This project consists of the following deliverables:
  • Topic selection (two or three choices in order of preference) due Sunday, 28 March.
  • Brief outline of your presentation due Sunday, 4 April.
  • In-class "lightning talk" (very brief presentation)  of your findings (8 minutes, followed by up to 2 minutes of questions) held on Wednesday, 21 April.
  • Where appropriate, presentations should address "who/what/when/why/how" questions, discuss the significance and availability of the technology, and how it relates to competing technologies.
  • Accompanying materials, such as electronic copies of your visual presentation, code examples, etc.
Groups are required to involve all members in the presentation. For example, each group member could present a separate part of the findings.

Possible topics

Here are some possible topics:
You are encouraged to propose other topics, subject to instructor approval.

Submission

Each team is to make exactly one submission. Any written materials should be submitted either  to Blackboard or Google Docs.

Project 5

Due Date: Wednesday, 28 April, for the in-class demo

Sunday, 2 May, for the final graded submission

Group Project


Objectives

Familiarity with
  • client-side JavaScript
  • DOM event handling
  • Dojo toolkit
  • AJAX
  • mashups
  • public web APIs

Description

In this project, you will develop a browser-based mashup (from at least two sources) of your choice, pending on instructor approval. No later than Sunday, 4 April, should you have discussed your project choice with the instructor and finalized the project requirements. This project is a great opportunity for your group to get really creative and have lots of fun. (Hint: keep it simple! As many of the examples show, some useful mashups are extremely simple.)

General requirements

For full credit, your mashup should have the following characteristics:
  • data and/or functionality from two or more source APIs (a link to each source must be included in the footer of the application's pages)
  • clear, useful functionality on top of the source data/functionality
  • some form of persistent data (if required for the functionality provided)
Extra credit will be given for mashups with a focus on social justice. You may look for demographics and other suitable APIs here.

Examples

Sample project

The default project, in case you prefer not to come up with your own, is a continuation of the food and health themes from Project 3 assigned in an earlier version of this course. The requirements for this option, called the Recipe Sanity Check Mashup, are as follows.
  • The user enters the ingredients of a recipe into a table with a column for the ingredient name and another column for the quantity.
  • The user then presses the "check" button.
  • For each ingredient, the application then shows the following information:

    • energy in kcal for the given quantity
    • some pictures that pop up on demand
  • The application also calculates the total energy for the recipe.
Extra credit is given for the following additional functionality:
  • (Less hard) Links to health-related articles for each ingredient.
  • (Less hard) Storing data for ingredients not yet in the database.
  • (Harder) Storing, retrieving, and searching recipes.
Nonfunctional requirements:
  • XHTML 1.1 compliance.
  • Browser-based mashup in JavaScript with one or more suitable libraries such as Dojo, JQuery, etc.
  • Per-ingredient calory data comes from Google Base, where you can manually enter this information through your Google account. Recipes can be stored there as well.
  • Photos come from a source such as Flickr. You should narrow the search using suitable tags.
  • Health-related articles can come from the British NHS.

Alternative approaches

You are also welcome to build a hosted mashup using platforms such as Yahoo! Pipes or Ning. You will need a Yahoo! account to use Pipes, or a developer account on the other services, and you will learn on your own how to use them.

Submission

Please share your group's storage account with the instructor and send the instructor email as soon as your project is ready to be reviewed. The date your message is received counts as the submission date.

Project 4

Due Date: Sunday, 11 April

Group Project


Objectives

Familiarity with
  • client-side JavaScript
  • DOM event handling
  • separation of concerns between content, visual styles, and executable code
  • MVC architectural pattern
  • Dojo toolkit
  • Automated client-side testing

Description

In this project, you will
  • reimplement project 2 (without the reporting functionality) using the Dojo toolkit
  • add automated testing for the required functionality using the facilities Dojo provides

Functional requirements

These capabilities must be implemented, and there must be an integrated suite for automatically testing them:
  • Manage projects (categories) for which to track time.
    • create
    • modify
    • delete
  • Start/stop tracking time spent on a project.
    • If tracking for one project is in progress and the user starts tracking time on another one, the app should allow this only after confirmation.
  • Real-time dashboard displaying simultaneously
    • the total time worked today, this week, this month, and this year
    • the time worked today, this week, this month, and this year on the currently active project

Nonfunctional requirements

  • All code for dynamic client-side functionality must be provided in the form of external JavaScript source files using components from and the architecture provided by the Dojo toolkit; embedded JavaScript within XHTML documents is not permitted. Your code should include inline comments where appropriate.
  • All content must be valid XHTML 1.1 documents. You are advised to use a validating editor or the W3C Validation Service to ensure that your content is valid. For convenience, you may want to place a link on each document that runs the validation service on this document. Your document should state the correct document type at the top.
  • All rendering styles must be provided using a single shared valid CSS2 style sheet. There must not be any rendering styles in the documents themselves. You are advised to use a validating editor or the W3C CSS Validation Service to verify that your style sheet is valid.

Grading

Total: 10 points
  • 0.5 - valid XHTML 1.1 (browser shows standards compliance mode)
  • 0.5 - external CSS, no style attributes in content documents
  • 0.5 - correct use of divs and tables
  • 0.5 - consistent layout and navigation
  • 1 - correct use of Dojo's framework capabilities (OO, event support, etc.)
  • 1 - correct use of Dojo user interface widgets
  • 3 - required functionality
  • 3 - test suite

Collaboration

Consider obtaining a free hosted Subversion (SVN) repository, for example, here or here.

Submission

Please share your group's storage account with the instructor and send the instructor email as soon as your project is ready to be reviewed. The date your message is received counts as the submission date.

Project 3

Due Date: Sunday, 28 March

Objectives

  • Project team formation

Description

Your job is to form a project team of size three. The remaining projects for the semester will be group projects, so it is important to have the teams ready as soon as possible. Only in exceptional cases will teams of size other than three be permitted.

Each team member will receive the same grade for a group project. At the end of the semester, however, each student will have the opportunity to comment on the relative contributions within their team. If significant disparity of contribution to group projects is reported, adjustments to students' final course grades may be made.

Submission

To submit this project, please send me email (exactly one message per team) with the names and email addresses of the team members.

Monday, February 1, 2010

Project 2

Due Date: Sunday, 28 February

Individual Project

Objectives
Familiarity with
  • separation of concerns between content, visual styles, and executable code
  • XHTML
    • divs, tables and CSS layers (not to be confused with the deprecated, nonstandard layer element)
    • user interface elements and forms
  • CSS
  • JavaScript
    • DOM (document object model)
    • client-side scripting and DOM event handling
  • usability (also have a look here and here)

Description

In this project, you will develop a simple, non-persistent browser-based time tracker. Specifically, your application should provide the following functionality. (Details will be clarified in class and on the mailing list.)
  • Manage projects (categories) for which to track time.
  • Start/stop tracking time spent on a project.
    • If tracking for one project is in progress and the user starts tracking time on another one, the app should allow this only after confirmation.
  • Real-time dashboard displaying simultaneously
    • the total time worked today, this week, this month, and this year
    • the time worked today, this week, this month, and this year on the currently active project
  • Report generation.
    • Per project
      • Summary: time worked on this project today, this week, this month, this year, or since a custom date
      • Details: list of daily, weekly, monthly, yearly breakdown or breakdown since a custom date
    • Overall
      • for each project, daily, weekly, monthly, yearly breakdown or breakdown since a custom date
The visual design requirements for this application is as follows:
  • All pages must have the same, consistent layout.
  • All pages must have the same, consistent text styles, using some cool fonts and colors other than the default.
  • Use divs to divide each page into (common) navigation and (page-specific) content.
  • Use layers to place a cool logo somewhere (consistent) on each page.
  • Use forms wherever the user needs to be prompted to submit some information.
  • Reuse an existing date picker component to allow the user to enter dates.
This application does not (yet) support persistence: if you reload it in the browser, all internal data will be lost.

Your application must also satisfy the nonfunctional requirements stated below. It is recommended to use Eclipse to author the documents, style sheets, and code for this application; you can then browse the documents locally or remotely using different web browsers.

Nonfunctional Requirements

  • All content must be valid XHTML 1.1 documents. You are advised to use a validating editor or the W3C Validation Service to ensure that your content is valid. For convenience, you may want to place a link on each document that runs the validation service on this document. Your document should state the correct document type at the top.
  • All rendering styles must be provided using a single shared valid CSS2 style sheet. There must not be any rendering styles in the documents themselves. You are advised to use a validating editor or the W3C CSS Validation Service to verify that your style sheet is valid.
  • Your application must work on a cross-platform, standards-compliant browser such as Firefox or Chromium.

Grading

Total: 10 points
  • 0.5 - valid XHTML 1.1 (browser shows standards compliance mode)
  • 0.5 - external CSS, no style attributes in content documents
  • 0.5 - correct use of divs and tables
  • 0.5 - overall visual design
  • 0.5  - consistent layout and navigation
  • 0.5 - external JavaScript, no embedded code
  • 1 - reuse of existing date/time picker
  • 2 - time tracking
  • 1 - dashboard
  • 3 - report generation

Submission

Please send the instructor email as soon as your project is ready to be reviewed. The date your message is received counts as the submission date. Be sure to include your project URL in your email message.

Wednesday, January 27, 2010

Tentative course schedule for Spring 2010

This week-by-week course schedule is tentative. It is likely to evolve as we progress through the semester. In particular, we will probably move up the material on JavaScript and cover additional client-side technologies toward the end of the semester. We may also study some concurrency concepts.

Week 1
  • Introduction and overview
  • Motivation: rich internet applications (RIA), web 2.0
  • Projects
  • References
Week 2
  • Course software 
  • Overview of content markup languages: XML, XHTML, WML, VoiceXML
  • Overview of Dynamic HTML (DHTML) = XHTML + CSS + DOM + JavaScript
  • Main XHTML content elements
  • Separation of content from styles: CSS
Week 3
  • XHTML content and the Domain Object Model (DOM)
  • Prompting users for input: forms
Week 4
  • Client-side executable content: Java applets, Active X, JavaScript, Flash
  • Event model: DOM elements as event sources, JavaScript functions as event listeners
  • Dynamic HTML (DHTML) = XHTML + CSS + DOM + JavaScript
Week 5
  • ACM presentation
  • Event model (cont.)
  • Selenium IDE for automated in-browser system testing
Week 6
  • Event model: using links as event sources
  • DHTML summary
  • Content syndication
Week 7
  • AJAX overview
Week 8
  • ACM presentation
  • Test 2
Week 9
Week 10
  • Review of IE6 issues
  • Dojo model-view-controller architecture: tutorial
Week 11
  • Recap of Dojo MVC architecture
  • AJAX and the Dojo bind method (now in DojoAjax example)
  • Overview of remix/mashup architectures
  • JSON (JavaScript object notation)
Week 12
  • Test 3
  • Mashing up using JSON versus XML
Week 13
  • Test 3 discussion
  • Lightning talks on emerging client-side technologies
Week 14

Project 1

Due Date: Sunday, 31 January

Objectives

Familiarity with
  • Software installation process
  • Eclipse
  • Mercurial (hg)
  • Synchronization between workspace and public web folder using hg

Description

Your job is as follows:
  1. Install the software for this course, especially if you are doing your work outside the departmental labs. You are encouraged to discuss any issues you encounter on the mailing list.
  2. Familiarize yourself with Eclipse and the JavaScript project support.
  3. In Eclipse, create a new JavaScript project called, e.g., HelloJavaScript.
  4. Within this project, create at least one (X)HTML page; be sure to choose XHTML 1.0 Strict as document type.
  5. Add some content to your page(s). You may find this reference useful.
  6. Open the page(s) in the various ways available within Eclipse: HTML editor, text editor, web browser, web page editor.
  7. Right-click on the HelloJavaScript project node in the project explorer and share with Mercurial using Team > Share Project..., then choose Mercurial, then press finish.
  8. Log in to random.cs.luc.edu and navigate to your course folder created in project 0
  9. Create a subfolder with the same name as your project.
  10. Now cd into the subfolder and run hg init. Then run pwd and take note of the result. 
  11. Finally, set up an auto-update hook by creating the file (still in the subfolder) .hg/hgrc with content 
  12. [hooks]
    changegroup = hg update
  13. Back in Eclipse, right-click on the HelloJavaScript project node and Team > Push the project to URL ssh://random.cs.luc.edu//result/of/pwd/command/above. You should now see one or more files in that remote subfolder. (Every time you add new local resources, be sure to commit them locally before pushing them to the remote repository.)
  14. To verify that remote publishing was successful, also view your project through its public URI by appending HelloJavaScript to your course folder's URI.

References

Submission

To submit this project, please send me email with the URI of your project folder.

Thursday, January 21, 2010

Project 0

Due Date: Monday, 25 January

Objectives

Familiarity with
  • Course mailing list
  • Linux account
  • Existing Apache web server
  • Personal folder for public web pages

Description

Your job is as follows:
  1. Subscribe to the mailing list for this course. Be sure to review any prior messages on the list. Very importantly, if the name under which you have registered for this course is not apparent from your email address, be sure to include your real name in your subscription request.
  2. Make sure your Linux account works. Otherwise email the lab manager (with a copy to me).
  3. Log in to your Linux account and create a folder called public_html in your home folder. Make sure your home folder and the public_html folder are readable only by you but executable by anyone. Use the chmod command if necessary:

    chmod 711 ~
    chmod 711 ~/public_html
    
  4. Make up any secret string (consisting of any combination of at least seven letters, numbers, dashes, or underscores). This string will become a secret between you and myself and must not be shared with anyone else. As a subfolder of your public_html folder, create a folder whose name is equal to that secret string, and as a subfolder thereof, create a folder called 424. We will now refer to this folder as your course folder. (In case the secret string ever gets compromised, immediately make up a new one, rename the corresponding folder, and inform me.)
  5. Using a web browser, view your course folder at its public location (URI):

    http://webpages.cs.luc.edu/~yourid/yoursecret/424
    

Submission

To submit this project, please send me email with the URI of your course folder.