Lab46 Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
<WRAP centeralign round box>
<WRAP><color red><fs 200%>Corning Community College</fs></color></WRAP>
<WRAP><fs 150%>CSCS1730 UNIX/Linux Fundamentals</fs></WRAP>
</WRAP>

======Project: GRADE FIGURE-OUTERER (gfo0)======

=====Objective=====
Scripting is a great way to automate otherwise manual and time consuming tasks. The objective for this project is to give you another opportunity to play with your ever-expanding UNIX and command-line skills, and assist you with developing an even finer relationship between process and data: by having you calculate your grade in the class based on your evaluation data.

=====Background=====
Throughout the semester your participation, weekly journal entries, and projects have been gradually tallying up and made available to you via the super-nifty **status** tool. When you run it by itself, you will get some minimal usage information (something resembling as follows):

<cli>
lab46:~$ status
Must specify course (or help). One of:
    status unix
    status help
</cli>

In order to pull up your information, you merely need to invoke the command with the pertinent class:

<cli>
lab46:~$ status CLASS
</cli>

And you will be greeted with the summary data related to your standing in the class (you can also append the **detail** option to get even more of an information line-by-line breakdown):

<cli>
lab46:~$ status CLASS detail
</cli>

But, throughout all this, some very obvious data points are lacking: your actual, calculated results. All I am giving you is the raw data, and while I have scripts that can quickly give //me// an overview of your progress, I've left that same role up to you to fill.

And since you're all unprocrastinating, highly motivated and impassioned learners, I figured I'd give you a project that you've probably finished weeks ago in your individual quests for perfection: to write a script that will collect, process, and output that very information (you're welcome).

=====Grading Policy=====
You'll recall from the syllabus that the grading policy for the class is divided into three areas:

  * participation, which is worth a total of 13% of overall grade.
    * some have gone above and beyond with respect to participation, and have earned bonus points in this area.
    * for the current semester, participation bonus points can raise your maximum participation score to a value of **13**/13. Anything in excess of this is capped at 13.
  * journal (your personal reflections / informational composition of your experience in the course, which some have already been reaping great value from), worth a total of 13% of the overall grade.
    * in certain scenarios, you can earn bonus points by going above and beyond in your journal entries. Look for the "extra" attribute. This value gets added onto the journal total.
    * for the current semester, journal bonus points can raise your maximum journal score to a value of **13**/13. Anything in excess of this is capped at 13.
  * projects (the assigned activities you've been enjoying each week), which rounds out the remaining 52% of your final grade.
    * the majority of reported bonus points are earned in relation to the projects, and are therefore applied exclusively to the projects component of your grade.
  * Added up, these three components come out to a value of 78. So at this point in the course, you will be calculating your grade out of that value (78)
  * Once there, you can determine the letter grade.

Letter grades are on the following scale (taken from the syllabus):

  * A  (100.00+)
  * A- (94.00-99.99)
  * B+ (88.00-93.99)
  * B  (82.00-87.99)
  * B- (76.00-81.99)
  * C+ (70.00-75.99)
  * C  (64.00-69.99)
  * D  (58.00-63.99)
  * F  ( 0.00-57.99)

Each component needs to be calculated separately to gain the total number of points, and then those points summed together to get your final result.

Of course, we're not done yet, so new data is being added all the time (with each passing week, journal entry, and evaluated project), which means whatever value you may come up with today would potentially be obsolete come tomorrow.

The algorithms and the process for determining your grade based on the available data, however, remain the same.

Which is why this makes for such a great scripting project.

=====Task=====
As previously mentioned, throughout the semester you've been able to see the processed results of your various efforts in the class (projects, journal, participation). That information was made available to you via the handy **status** tool (expanded some more with the **detail** argument given).

====Participation====
Participation is evaluated on a weekly basis, based on the participation claims you've registered via the **wcp** tool.

Data will appear as follows:

<code>
PARTICIPATION
    4:wcp1:final tally of results (4/4)
    8:wcp2:final tally of results (8/8)
    12:wcp3:final tally of results (12/12)
</code>

====Journal====
The journal data is recorded, currently, in three categories per week, eligible to earn up to 8 points per weekly entry:

  * <nowiki>*:weekX:entry made before deadline [2/2]</nowiki>
    * was your entry in place by the time I ran my journal processing script?
  * <nowiki>*:weekX:filler text removed from entry [2/2]</nowiki>
    * there's some default text in each new entry that you remove for credit
  * <nowiki>*:weekX:met minimal word count (262/256) [4/4]</nowiki>
    * each entry must be at least 256 words to be counted for full credit

Data can look something like this:

<code>
    ...
    6:week2:final tally of results (6/8)
      *:week2:entry made before deadline [2/2]
      *:week2:filler text removed from entry [2/2]
      *:week2:met minimal word count (181/256) [2/4]
    ...
    4:week5:final tally of results (4/8)
      *:week5:entry made before deadline [2/2]
      *:week5:filler text removed from entry [1/2]
      *:week5:met minimal word count (80/256) [1/4]
    ...
</code>

====Projects====
That data, specifically for **projects**, is of the format (sample follows):

<code>
4:uxi0:final tally of results (4/5)
*:uxi0:cloned lab46 mercurial repository [1/1]
*:uxi0:subscribed lab46 address to class mailing list [1/1]
*:uxi0:subscribed to class mailing list [0/1]
*:uxi0:customized opus intro [1/1]
*:uxi0:customized opus title [1/1]
16:pbx0:final tally of results (16/16)
*:pbx0:lab46 submission successful [8/8]
*:pbx0:email submission successful [8/8]
16:pbx1:final tally of results (16/16)
*:pbx1:content correct [8/8]
*:pbx1:lab46 submission successful [8/8]
3:bonus:final tally of results (3/0)
*:bonus:uxi0 early submission bonus (2 days) [2/0]
*:bonus:pbx1 early submission bonus (1 day) [1/0]
</code>

You should see 2 types of lines. The first is the "final tally" line:

<code>
YOUR_SCORE:PROJECT_NAME:final tally of results (YOUR_SCORE/TOTAL_POSSIBLE_SCORE)
</code>

The data lines all start with an '<nowiki>*</nowiki>', and merely provide a deeper level of detail (how we arrived at that grand total for the project). It is of the format:

<code>
*:PROJECT_NAME:description [YOUR_POINT/TOTAL_POINT]
</code>

Each line item's point value (against its total) is presented at the very end of the line in square brackets (as shown).

Finally, to handle bonus points, notice what happens: the "total" values are all out of 0... so it ONLY counts for you, should we get any bonus points, and doesn't count against you should you not gain any.

Each project is clumped together, its "final tally" line leading the stanza, with the follow-up line items beneath it (note: **NOT** an average, but a //tally//).

Should there be any points deducted for lateness, they should be on the second line of the stanza (immediately following the "final tally" line). And would have the following format:

<code>
*:cus0:LATE penalty (1 day) [-26]
</code>

===Questions/Sub-Tasks===
On the command-line, how would you:

  * Capture JUST the **PROJECTS** category as produced by the **status** tool?
  * Determine the total number of projects evaluated?
  * Figure out which project(s) was/were worth the most points?
  * Figure out which project(s) was/were worth the least amount of points?
  * Figure out the total number of project points available?
  * Determine the total number of points you received on projects?

====The script====
Your ultimate task for this project is to write a script that scrapes the data generated by the **status** tool and computes your overall grade in the class.

I'd like your script to conform to a particular output format, described below.

===Output Specification===
Here is an example of the sort of information I'd like to see your script output:

<cli>
lab46:~/src/unix/gfo0$ ./gfo0.sh
==================================================================================
UNIX      uxi0 pbx0 cus0 pbx1 arc0 wpa0 udr0 sfp0 bns prjct+ptcpn+jrnal= result
==================================================================================
username: 100  86   91   79   99   0    0    83   3   41/52+11/13+12/13= 82/100 B
==================================================================================
lab46:~/src/unix/gfo0$ 
</cli>

NOTE that in the above, "username" should actually display YOUR USERNAME.

And note that the actual scores are left justified underneath the column heading listing the project name.

=====Useful tools=====
By no means an exhaustive nor implied list, you may want to ensure familiarity with the following tools/concepts when performing this project:

  * cat(1)
  * bc(1)
  * printf(1)
  * echo(1)
  * grep(1)
  * head(1)
  * tail(1)
  * sed(1)
  * cut(1)
  * tr(1)
  * wc(1)
  * I/O redirection (found in bash(1))
  * variables/variable expansion (found in bash(1))
  * command expansion (found in bash(1))
  * selection structures and evaluation facilities
    * if statements (found in bash(1))
    * <nowiki>[</nowiki>(1)
  * loops (found in bash(1))
  * arrays (found in bash(1))

Often times related and potentially useful commands you may want to know about can be found in the "SEE ALSO" section near the bottom of many manual pages.

====bash debugging====
If you add a **-x** argument to bash (in the shabang, or on the command-line if running your script that way), it will be immensely more verbose, reporting more precisely on its actions. This can prove most useful when trying to figure out various problems, be it syntax errors in your script or spurious logic errors.
=====Submission=====
Successful completion will result in the following criteria being met:

  * When all is said and done, you will submit your script, which:
    * runs the **status** tool and creates a snapshot of its output. Have your script process this snapshot vs. running **status** 20 million times during the run of your script (the data may change over time, but it isn't going to change that fast- cache the output to improve performance).
      * if an existing file is given on the command-line ($1), use that as your cached status file in your processing.
    * should be an organized presentation of the requested information as specified above.
      * spacing is important. I want to see column justification just like in my examples above.
    * is functional, displaying no errors of any kind.
    * utilizes shell logic predominantly
      * for those who can, do **not** write a C program that does it all; that doesn't mean you cannot write small programs to assist with pieces of the process though
      * use the various pattern matchers, filters, and text manipulation tools we've been playing with all semester (as well as new ones you find as you look for ways of performing this task).
    * is WELL and CONSISTENTLY COMMENTED.
      * and I don't just want to see "this is an if statement"-style comments. I want to see explanations of why you are doing things, especially the central processes.
    * is CONSISTENTLY INDENTED according to logic level (don't have everything riding the left margin, indent code inside if statments, loops, functions, etc.)
      * see how this bulleted list is consistent and indented?
    * no line exceeds 80 characters in width (inclusive of terminating newline).
    * all custom variable names must be at least 4 symbols in length
    * top-level score/total values are verified by evaluating line item values
    * makes use of selection constructs (if statements, case statements, conditional chaining)
    * makes use of looping constructs (the for and while loops we've been playing with)
    * makes use of arrays in a central and important way
    * the script should entirely automate the process; all you should have to do is run the script, and it will do all the work to output the necessary information.

=====Spirit of project=====
The spirit of the project embodies many aspects we've been focusing on throughout the semester:

  * recognizing patterns to employ effective solutions in problem solving
  * utilizing concepts and tools covered
  * demonstrating comprehension of concepts, tools, and problems
  * employing concepts in knowledgeable and thoughtful manner
  * following instructions
  * implementing to specifications
  * utilizing creativity
  * being able to control solution via consistent, clear, and organized presentation

Basically: I want your solution to be the result of an honest, genuine brainstorming process where you have (on your own) figured out a path to solving the problem, you have dabbled and experimented and figured things out, and you can command the concepts and tools with a fluency enabling you to pull off such a feat. Your solution should demonstrate the real learning that took place and experience gained.

Cutting corners, avoiding work, skimping on functionality, cheating through getting others to do work for you or finding pre-packaged "answers" on the internet violates the spirit of the project, for they betray your ability to pull off the task on your own.

=====Identifying shortcomings=====
I would also like it if you provided an inventory of what functionality is lacking or out of spec when you submit the project. The better you can describe your deviations from stated requirements, the more forgiving I may be during evaluation (versus trying to hide the shortcomings and hoping I do not discover them).

The more fluent you are in describing your shortcomings on accomplishing the project (ie "I didn't know how to do this" is far from fluent), the better I will be able to gauge your understanding on a particular aspect.

This can be in the form of comments in your script, or even a separate file submitted at time of submission (if a file, be sure to make mention of it in your script so I can be sure to look for it).

=====Submit=====
Please submit as follows:

<cli>
lab46:~/src/unix/gfo0$ submit unix gfo0 gfo0.sh
Submitting unix project "gfo0":
    -> gfo0.sh(OK)

SUCCESSFULLY SUBMITTED
lab46:~/src/unix/gfo0$ 
</cli>

I'll be looking for the following:

<code>
78:gfo0:final tally of results (78/78)
*:gfo0:gfo0.sh only uses cached status tool output when run [4/4]
*:gfo0:gfo0.sh effectively utilizes variables in operations [4/4]
*:gfo0:gfo0.sh effectively utilizes command expansions [4/4]
*:gfo0:gfo0.sh effectively utilizes regular expressions [4/4]
*:gfo0:gfo0.sh effectively utilizes selection statements [4/4]
*:gfo0:gfo0.sh effectively utilizes looping structures [4/4]
*:gfo0:gfo0.sh effectively utilizes functions in script [4/4]
*:gfo0:gfo0.sh effectively utilizes arrays in script [4/4]
*:gfo0:gfo0.sh is a proper bash script with shabang and exit [4/4]
*:gfo0:gfo0.sh accurately displays values in consistent alignment [4/4]
*:gfo0:gfo0.sh accurately displays values in pertinent categories [4/4]
*:gfo0:gfo0.sh accurately displays values based on current data [4/4]
*:gfo0:gfo0.sh use a status output cache file on given argument [4/4]
*:gfo0:gfo0.sh verifies score and total against detail line items [4/4]
*:gfo0:gfo0.sh no line exceeds 80 characters in total length [4/4]
*:gfo0:gfo0.sh all custom variable name lengths at least 4 symbols [4/4]
*:gfo0:gfo0.sh properly manages input violations [4/4]
*:gfo0:gfo0.sh operates according to specifications [5/5]
*:gfo0:gfo0.sh logic is organized and easy to read [5/5]
</code>

Additionally:
  * Solutions not abiding by spirit of project will be subject to a 25% overall deduction
  * Solutions not utilizing descriptive why and how comments will be subject to a 25% overall deduction
    * comments should be consistent in appearance (adopt a style; one that promotes readability)
  * Solutions not utilizing indentation to promote scope and clarity will be subject to a 25% overall deduction
    * indentation should be no fewer than 3 spaces (or 3-space tabs); I prefer 4.
Lab46 Wiki

User Tools

Site Tools

Page Tools
