We have discussed the fundamentals of programming as consisting of data & actions (often on data) and organizing the actions via sequence, selection, repetition and modularization. This practice/learning activity will revisit those ideas in more detail focussing on modularization to organize the actions in a program (or set of scripts). The learning activity is described after the Process Reminders below.
Keep the "pair programming" process in mind as you work. One person types and the other person watches and corrects, questions, etc. After a bit (at most 30 minutes) you change roles.
This activity is for you to learn, so it is not graded. The learning will be inferred in the PARR (Programming Activity and Reflection Report) document you (eventually) submit and in one of the in-term exams. Remember to add to your notes for the PARR.
If you have questions about the assignment send me an e-mail or drop by my office. If you have a question while working on the assignment do the same. Keep in mind that when you encounter something you can't figure out you can/should think, explore, seek answers on google, etc. but, do not spend more than 15-30 minutes trying to overcome a particular error or problem.
The syllabus noted a couple ways you might earn extra credit. I am adding another.
One is to share some aspect(s) of programming or Snap! you think others might not have experienced. You should annotate your program using the program notes (File icon | Program notes) and/or comments blocks (see p.68 of the Snap! Reference Manual. The annotation should describe or explain the learning/insight(s) you want to share.
To receive extra credit for such an annotated program on this activity you will also need to submit a copy of your algorithms. Either create a PDF of a document or include the text in your submission message.
The alternative method to work for extra credit is that the partnership could suggest additions to our how to do it page. You might suggest a revision to clarify (or finish) something that is there already or an entirely new topic. Please indicate how/why you think the would be helpful. Be sure you fully and clearly describe what you are talking about.
The third method to receive a bit of extra credit is to submit the "Create your own problems ..." that you created and solved. Include all three problems and a pseudo-code algorithm of each solution.
Submitting something for either kind of extra credit is as simple as sending an e-mail message. The message should:
The goal here is to provide activities that help you understand and use modularization as a program tool. Modularization can help organize the execution of actions to accomplish particular goals by allowing you to think in terms of overall tasks and leaving the details for later development after you have "solved" the problem in terms of big ideas. We are at the point where programs/scripts are getting more complex. Modularization also allows us to use the same code to do similar (or identical) tasks without having to have multiple copies of the same code. For example you might draw the initials JPE twice to produce a look of narrow letters drawn inside fatter letters. Or you might draw them at different locations or with different sizes or colors. Another modularization task is to develop a rectangle drawing module that allows you to draw a house windows and doors and a sidewalk leading up to it.
When developing modules (new blocks) it is useful to consider:
How that task might be done. Try to think of several different ways to accomplish the same goal. (This will familiarize you with the task and prime your brain for making decisions about how parameters might be used to accomplish similar but slightly different tasks.
Think about different ways or situations the module could be used in a program. Identify any data values that might be used to allow the same code to work in each of the contexts. Consider whether/how that might necessitate a different approach to the task.
When using modules there are two actors involved—the module itself and the code/script that called or invoked the module. As the programmer/designer, you must decide which actor is responsible for which actions. The goal is that the module should do only those actions appropriate to the task and the calling code/script should do everything else.
As you start making the module do more (through the use of parameters) the calling code/script will communicate the expectations via the parameters and the module will include additional instructions that use the parameters to accomplish the purpose previously done by the caller/invoker.
I suggest you use a different sprite for each of the items. This should make working on a particular script less confusing.
The goal is to produce scripts that draw a set of initials or an organizations acronym, e.g., UNI. However, to provide some consistency and to provide some particular programming experience, everyone is to draw the letters MPI. Each initial/Letter should be drawn by its own module (block).
The initials should be of the same height.
Draw the letter(s) to a specified height. Each letter will need to set its width to be proportional to the height value. I suggest height to width ratios of 60% for most letters, 80% for W & M, and 25% for the I. Feel free to experiment or otherwise choose different ratios. Note that the width ratio value will belong to the letter, not the caller/invoker.
Draw the letter(s) at a specified location (x- & y-coordinates). I suggest you use the upper-left point of the letter as the location. (If you were drawing an O or Q you could think about the upper-left corner as indicating half the width from the center. The G would be more problematic.) This should build on (still include) the capability of specifying the height.
Draw the letter(s) with a specified line thickness and line color. This should build on (still include) the capabilities of specifying the height & location. Note that you can specify in the settings whether you want the ends of the line to be square or rounded (Flat line ends checked or not).
Include a single script that will call/test/exercise all four routines. The script should clear the screen at the start but not in between the calls, i.e., all four should appear on the screen at the same time. The routines should do only what is needed. However, as a safety mechanism, you might consider having them all assume the pen is up when they start and pick the pen up when they end.
The goal is to produce a block and a main/controlling script that will draw a scene. The primary user-defined block/module you are to use is a rectangle. The block/module should have parameters for length and width (a length shorter than the width will produce a rectangle on its end), and for location (x- and y-coordinates of some corner). Some examples of the possibe scenes include:
Perhaps with a house, a barn, a board fence with posts, etc.
Each house would likely include a door and windows (perhaps with panes) and perhaps a sidewalk leading up to the door. You might consider having some closer to the street and some further back.
This might be just one big building with a ground level entrance, multiple floors, and several windows per floor.
In all cases you might consider adding things such a door knobs, chimneys, vent pipes, etc. Trees and bushes could be added by doing a spirograph-like drawing.
You may wish to produce other modules/blocks for such things as slanted roofs (triangle of a given size & location), trees (1 or more spirals over a solid line for the trunk), etc.
There will need to be an overall controlling script that puts the pieces together.