| about | help | home | prefs | create account |
This page explains the two types of custom content you can create on CodingBat -- (1) custom pages and (2) custom problems in Java or Python. If you've created some materials you'd like to share more widely, email nick.parlante@cs.stanford.edu with "codingbat" in the subject to see about linking your materials off the CodingBat pages. To create pages and problems, start at the authoring page.
It's easy to create a page that links to select problems. A Teacher might do this to make a page linking to problems in a specific order for a class, mixing in suggestions or instructions. Every CodingBat user has their own "home page" (initially blank) at the url http://codingbat.com/home/email -- the easiest way to your home page is using the link at the the bottom of the authoring page.
When a user is looking at their own home page, there's an Edit button where they can edit the text that makes the page. To avoid security problems, the text is not full HTML, but it supports simple markup. In the text, a problem id like "p187868" is automatically made into a link to the problem. In this case, p187868 is a reference to the Warmup-1 sleepIn(), and p187868 is just the last word in the url. You can link to any problem in this way. Actually, you paste the whole http://codingbat.com/prob/p187868 into the text, but the last p187868 is the only needed part. Going to a problem from this page, the prev/next/chance links on the problem navigate correctly through the problems in the order given on the page.
Other markup in the text: blank lines make separate paragraphs, <pre> makes example code paragraphs, and <b> makes bolding. Write text like "a < b" directly without special html markup.
The lower part of the home page lists all the custom pages and problems created by the user. Problems appear in this list if they are not already listed in the text at the top of the page. To create a new custom page, use the New Page button, entering a title to identify the page using only lowercase letters, digits, dashes, and underbars, such as "basic-strings" or "section8" or "midterm-practice". The url for the new page is /home/email/title. Over time you may build up a few pages, so choose a title which will make sense over time (heh, especially since at present there is not way to rename or delete page!).
Each custom page has "description" sentence which summarizes the page's contents, like "String practice problems that stress substring()." If present, the description is used a the top of the page after the link on the list of pages. Add the tag "hidehome:true" to inhibit the link to a page on the home page (this same tag is used for problems below).
This section explains how to author new code problems. Start at the Authoring page which shows problems you are working on and allows you to create new ones. The following instructions are for a Java problem, and see the Python section below for the tiny changes to needed to author a python problem.
The New Problem button creates a new blank problem (don't worry, you can experiment with a problem without saving it). A problem is defined by components: doc, hint, tests, code, and tags, each of which are explained below. The suggestions below reflect what I have learned from writing many CodingBat problems, getting emails from confused students, etc.
Doc -- Describe in words what the inputs are and what the output must be. For a student, the challenge of a problem should be in working out its code, not from deciphering an ambiguous or incomplete doc. The doc should strive to be a clear and straightforward presentation of what the code must accomplish for all cases, pushing all the difficulty to the coding side.
The pattern for a doc is to mention the inputs, often with the word "given", and what the result must be for the inputs. There are systemwide axioms which you do not need to repeat: inputs are never null, but strings, arrays may be empty unless the specified otherwise. Sometimes the doc will include a little "so with this input the result is that" example sentence, if the computation is hard to describe only with words. The doc should use english words which are closest to their code analogs -- use "length" to refer to string length, since length() is the string method (other good words: "string", "char" and "return"). Avoid needlessly complex English words since English is not the first language for many users.
If some code concept like substring() or % is useful for the problem, the doc may include a "Note: ..." section which briefly describes the construct to save the student the discontinuity of looking it up. Such "Note:" sections are more common for basic/introductory problems, since for later problems it seems safe to assume the students have seen all the constructs. If the parameters are symmetric in the computation, it's simplest to give them short, standard names like a b c. If the parameters have distinct roles in the computation, you can give them short but real parameter names such as "out" and "word" in the makeOutWord() example below. Long variable names do not work well in the small in-browser code editor. A few examples:
Create a problem with an interesting algorithmic or logical core for the student to wrestle with. Implicit in this is a CodingBat idea: don't add complexity by making a problem which is realistic or has a motivating back-story. Practice problems do not need to be realistic. Instead, you want the description to be short and clear, and you want to have lots of problems so the student can work lots of repetitions (like exercise at a gym), building skill and confidence. Note how rather pointless the first 2 examples above are, yet they are fine for practice. Save the rich, realistic problem back-stories for full homework projects that really do something (i.e. nifty.stanford.edu). That said, some problems have longer, fun back stories, such a the dateFashion() example above.
For the dateFashion() example above, there is an order of if-tests that works the best in the solution, and I regard figuring out that order as part of the logical core of the problem. Therefore, the doc mentions the input cases deliberately not in the best order for the code. Most likely, the students will write some incorrect code, look at the outputs, and make a few attempts to get the correct solution. In this case, thinking about if-statements is the core of the problem, and I'm happy for the students to be put in that situation.
CodingBat problems most often have 1-3 arguments. With too many arguments, the table of given/result test cases is unwieldy. It also saves time that the methods often use the same parameter names:
With the standard parameter names such as above, nothing special is done to mark the parameter names in the doc. If the parameters are regular words, they can be marked with quotes if necessary, e.g. "you" and "date" in the dateFashion() example above (it's often clear enough without any quotes).
Many of the early CodingBat problems I wrote returned booleans, since booleans are a common early source of confusion for students that I figured could use practice. However, in practice, boolean results don't give the student much debugging feedback when working on their solution -- each row is just right or wrong with no additional data. Therefore, returning a String or int or array may work better, providing more useful results for the student to look at while their code is not yet correct (heh, students spend a lot more time looking at not-working cases than working ones!).
CodingBat makes practice material available for free to a worldwide audience which includes elementary school students. It is important that your materials avoid any non child-appropriate content or language. The problems can be silly or whimsical (e.g. answerCell()), but you must avoid any sort of inappropriate or offensive content, keeping in mind our worldwide audience with who knows what religious traditions. Inappropriate content may result in deleted content, accounts banned, etc.
The hint can provide a little help for the student. The hint is optional and can be left blank. For the original CodingBat problems, the first few problems in each section tend to have hints to help students get started in that section. A problem with a hint available will show with a little "H" when listed for the student. The hint text can include <pre> sections to write lines of hint code. A problem with a hint enables "showpost", described in the tags section below.
List the test cases, one per line. Each test lists the input values first followed by the result value at the end of the line, all separated by commas. The first 3 cases are shown to students just below the doc problem statement. The values are generally written like Java literals, e.g. a string, int, and boolean: "string", 34, false. Arrays are written as values within curly braces {1, 2, 3}. Empty arrays are a special case, since the literal must indicate the array type -- {int} for an empty int array and {string} for an empty String array. The first few tests should be nice obvious cases. Then have edge cases like the empty string, followed by a variety of more complex cases pushing on the logic of the problem. Typically a problem should have at least 10 tests and more than 20 for a complex problem. Having lots of tests is good, making it more likely you will help the student find all the cases in their code. It's impossible to predict the amazing range of coding errors students will make, but having a large variety of tests is one thing you can do to help them out.
The last few tests are "other tests" and are not shown to students -- this proved to be necessary as some students tried to solving the problem just with a huge if/else sequence just checking for each test input. These last tests should not explore new logic cases (since the students can't debug with them). Instead the last cases should generally be copies of earlier basic cases with the values changed slightly .. so they are not predictable, but should pass if the earlier tests passed. Individual cases should not be too long ... ultimately each needs to fit in a single row in the output table. You can write comments in the tests section with "//", and you can record notes to yourself that way at the top of the tests section for a problem. Philosophy aside: note that the tests don't actually prove that the solution code is correct. In the end, it's just a bunch of tests.
The code section should show your solution code for the problem. The method name and arguments are derived from here. Once students start using a problem, you should not change the method name or arguments as that will break all the student code for the problem. You can add a few tests or refine the wording over time, but you should not change the problem spec. The solution code is used to check the tests, and it can be shown to the students with the showsolution/showpost tags below. Indent the code with 2 spaces, since tabs don't really work in the browser.
The "tags" for a problem are free-form meta data about the problem, and we expect to add more over time. The basic format of the tags is "key1:value1 key2:value2 ..." where the key and the values may not contain whitespace. All problems should have section: and difficulty: tags, and all the rest are optional
To write a python problem, just add the tag "lang:python". The code should begin "def foo(a, b):" and Codingbat will pick up the function name from there. The input and test cases are written exactly the same as for Java problems, basically looking like Java literals: 6, true/false, "a string", {1, 2, 3}. The cases are not written as python literals. Someday I should support writing cases in each language's native syntax. Python code should just use the regular builtins, no imports.
Use the Preview button to see what your problem will look like for students. The Run button runs the problem code and shows the test results. It also does some publishing checks on the problem: has doc, has tests, difficulty number, section. The publication checks are just suggestions for now, and we have not figured out how to work those in for real publication. The Save button saves the current problem state (even if the problem is broken). The Preview, Run, and Save buttons all work as best they can, even if the problem is in a half-broken state. The Preview and Run buttons do not save anything, so remember to hit Save if you want to keep changes.