← Back to branch summary

~azzar1/unity/add-show-desktop-key

« back to all changes in this revision

Viewing changes to www/apps/tutorial/help.html

  • Committer: matt.giuca
  • Date: 2009-01-14 10:10:12 UTC
  • mto: This revision was merged to the branch mainline in revision 1090.
  • Revision ID: svn-v3-trunk0:2b9c9e99-6f39-0410-b283-7f802c844ae2:branches%2Fstorm:1132
The new ivle.database.User class is now used in Request and usrmgt, which
    means it is now almost universally used in favour of ivle.user.User (now
    deprecated).

Noticeable change: The minor bug where the change to a user object in the
    database is not reflected in the user's session (eg. changing nick doesn't
    update title until log out).

ivle.dispatch:
    Session now contains 'login' (username string) rather than 'user' (full
        ivle.user.User object). This is a unicode string now.

    req.user is now a ivle.database.User object rather than an ivle.user.User
        object. This makes for a whole lot of really subtle differences, but
        largely conforms to the same interface. Note that strings must now all
        be unicode.

    login: Removed use of ivle.db. Now uses User object.

    html: Now handles unicode login and config options.

ivle.db: Removed update_user. Now replaced with Storm model.

ivle.database: Renamed has_cap back to hasCap (saved for later). Fixed small
    unicode bug.

ivle.makeuser.make_svn_auth now takes a store object.

usrmgt-server: Use new User class.

userservice: Now uses User class internally.
    get_user action now returns ISO 8601 date format, rather than a
        time tuple. (Wasn't being used).
    get_user action no longer transmits local_password (small security risk;
        note that it wasn't possible to see this for any user other than
        yourself unless admin).

ivle.util - added function object_to_dict.

Show diffs side-by-side

added added

removed removed

Lines of Context:
www/apps/tutorial/help.html
1
 
<p>Tutorial</p>
2
 
<p>TODO: Write Tutorial help</p>
 
1
<p>A key part of the IVLE worksheets are the programming exercises. You will 
 
2
find several of them interspersed
 
3
amongst the text of a typical worksheet.</p>
 
4
<!-- The exercises come in three levels of difficulty: basic,  -->
 
5
<!-- intermediate and advanced.  -->
 
6
<p>To complete a worksheet you must solve all of exercises that it contains.</p>
 
7
<!-- The advanced exercises will require more time and thought, and you are encouraged to try them if you yearn for a challenge. -->
 
8
<p>Normally each exercise will require you to write a piece of code, and submit it for verification.
 
9
Your submitted code will be automatically tested by IVLE against a number of different inputs. You will
 
10
get feedback from IVLE about which test cases your solution passed, and which ones (if any) it failed. 
 
11
To complete the exercise you must pass all the test cases.</p>
 
12
 
 
13
<p>If you want to check how your code behaves before submitting it, click on the button
 
14
labelled <strong>Run</strong>, at the bottom right hand corner below the exercise box. 
 
15
The result of Run will be displayed in the console window.
 
16
When you believe your solution is ready
 
17
for submission, click on the button labelled <strong>Submit</strong>, next to the Run button.  
 
18
You can submit as many attempts as you like for a particular problem.</p>
 
19
<div class="note">
 
20
<p class="first admonition-title">Note</p>
 
21
<p class="last">The IVLE system keeps a record of each submission you make,
 
22
including which test cases were passed or failed.
 
23
This information is aggregated and made available to teaching
 
24
staff and curriculum developers so they can monitor student
 
25
progress and improve the quality of the worksheets.</p>
 
26
</div>
 
27
<p>The test cases can be <strong>very</strong> picky about small details, things that we humans tend to
 
28
overlook. Therefore you should pay close attention to the requirements of the exercise, and watch out for
 
29
things such as:</p>
 
30
 
 
31
<ul class="simple">
 
32
<li>Capitalisation of letters.</li>
 
33
<li>The format of the output. In particular the amount and location of whitespace (spaces, tabs, line breaks).</li>
 
34
<li>Punctuation.</li>
 
35
</ul>
 
36
<p>Normally there are several test cases for each exercise. The first tests are usually the simplest and the most lenient
 
37
in terms of correctness. Later tests become more challenging and stringent. When you fail a test case you will
 
38
see a short message about the kind of thing your program did not do properly. This should give you some idea about
 
39
what needs to be fixed in order to pass the test, although sometimes it might take a bit of thinking before
 
40
you can resolve the problem. Don't be afraid to ask for help.</p>
 
41