Summary: Explains course activities, policies, and recommendations.
Note: Even if you've taken a course with me before, please read this syllabus
carefully. Because of the nature of this course, I've chosen some
activities and policies that are quite different from my usual approaches.
This class meets twice per week on Tuesday and Thursday from 2:15 to 4:05 p.m. Although this is nominally a lecture
class, I plan to lecture as little as possible.
A major requirement of this
course is to undertake a significant team software development project:
specifically, a Web application.
Before Fall Break, our focus will be on preparing for
I've set what I believe to be an ambitious schedule for plowing through
this material. However, the assignments will be relatively small scale
and focused on
developing skills rather than assessment. (Please don't feel lost--come
talk with me if you feel you need more feedback than you are getting.)
To learn Ruby on Rails, we will work through the Ruby on Rails 3 Tutorial. You will have time to work on the Tutorial together during class, but I expect you to read through the assigned chapters before class, and you may need to finish the exercises after class.
You'll form project teams. We will brainstorm project ideas in class, and I will assign teams based on your preferences. You will do some initial work to scope out the project and plan the first iteration.
After Fall Break, you will embark on your project.
There will be three iterations, each lasting roughly two weeks. (Unfortunately, the Thanksgiving break makes scheduling iterations a bit awkward.) You will begin each iteration with a team meeting, hopefully involving your project customer, to scope out work to be done in that iteration. If all goes well, you will end each iteration with deployed, working software. At the end of each iteration, you will give a brief, informal presentation and conduct a team reflection (or retrospective) on what went well and what can be improved in the next iteration.
We will spend some class time on further "Tech Topics" chosen by the class. I've already chosen two: XP principles (which we probably won't have time to read about before Fall Break) and usability. I may assign you reading to complete before class, but I won't require you to complete exercises after class, because your technical focus should be on your project.
Particular activities are discussed in more detail below.
Because of its scale and importance, the project gets its own section of the course Web site.
The Ruby on Rails 3 Tutorial is meant to be hands-on. To learn the concepts and skills, you are expected to follow along with the code presented in the text and to do the end-of-chapter exercises, as well as any additional exercises that I pose. In addition to the Rails Tutorial, we'll do hands-on work with database design and SQL.
As we work through these technical exercises
during the first half of the semester, you will have class time for
technical work: part of class on Tuesday and most or all of class on
Thursday. I will expect you to work in pairs; I will require the pairs
to mix up at least once and possibly several times. Any students who
have prior experience with Ruby, Rails, or databases will be expected to spend some time
mentoring their classmates, because that's the professional thing to do.
You will commit most of your technical work to GitHub,
a public revision control
repository. When you switch partners, you will also begin work on a new
repository building on another pair's code. In order for the class to stay together, I
expect you to
complete most exercises before our next class meeting, and I will check on an occasional basis. (If you've done
something you are especially proud of, let me know via email and I will
make a point of looking at it.)
Some exercises will require pencil-and-paper work (e.g., the database
design exercise). Other exercises will be more intensive (e.g., your
extension of the Tutorial
application) and you will have mroe time to complete them.
Although our "Tech Topics" after Fall Break may involve programming
exercises, you will not be assessed on these exercises and you need not
complete them after class. They are for your professional development
to learn skills for your project; make of them what you will.
To prepare for discussions of Extreme Programming and some other topics,
I will pose questions for you to reflect upon as you read,
and then respond to in writing. These questions will usually require a
prose response--a sentence or a paragraph--but sometimes snippets of
code. When assigned, reading responses will be due via email by 10 a.m.
on the day of class. This is intended to give me plenty of time to
adapt my lesson plan to the content of your responses.
You will discuss the readings; my role should be to facilitate your discussion. I
do not intend to lecture over the readings. But, I've learned (painfully) that it is all too easy to
unintentionally fall into lecture mode. If you catch me lecturing, please stop me!
You can expect to have a reading response due every Tuesday during
the first half of the semester, and occasionally on other days.
I struggled to figure out how to evaluate students' individual learning in a way that fits the learning goals for this course. Written exams are rare in the software development workplace (although sometimes used for certification).
To make individual assessment relevant to our goal of developing
professionalism, each student will be examined orally in a format
similar to the technical component of a job interview. Exam questions
may concern programming in Ruby, Ruby on Rails, database design, SQL,
Extreme Programming, development tools used in the class, and/or your
experiences with the project.
Individual examinations will be scheduled for Finals Week. We will
further discuss the format and scheduling of oral examinations at some
point during the final two weeks of class.
I expect you to follow the highest principles of academic honesty.
Among other things, this means that any work you turn in should be your
own or should have the work of others clearly documented.
In particular, I encourage you not to reinvent the wheel if your
encounters a technical problem that has already been solved, but rather
code that has been shared for the purpose of education
and reuse: from our textbook or other technical/tutorial books, from
Web-based tutorials, or from open-source projects (being aware of the
If you use code verbatim from source such as these, you should cite the
source of that code in a comment or README file and/or preserve any
copyright notices that are distributed with the code.
You should never
give away answers to exercises or
examinations. You may, however, work together in developing solutions
most exercises. You are strongly encouraged to use each other as
resources in your technical work; in the workplace, colleagues will
often be one of
your most important sources of advice and information.When
you explicitly work as part of a group or team, you need not identify
the work of each individual, unless I specify otherwise.
If you have a disability that requires accommodations, please let me know early in the semester so that we can work together to find accommodations that meet your learning needs. You will also need to provide documentation of your disability to the Academic Advising Office, located on the third floor of the Rosenfield Center (x3701). See the Student Affairs page on Academic Accomodation for more information.
In this course, I won't take attendance and there will not be an
explicit policy mapping attendance to grades. However, professionalism
demands that you attend class consistently and participate in both
discussions and technical work. Make sure your classmates know you by
the time we arrange project teams. Even if you already know the
you should support your classmates, who may later become your
teammates. Don't let your teammates or your pair programming
partners down. If
I don't see you for several classes in a row, we will need to talk
about whether it is appropriate for you to continue in the course.
That said, I do care about you, and if you miss class I would
appreciate a note to let me know what happened. Touch base with your
classmates, catch up on the work you missed, and come see me if you
have further questions. If I see that you have missed several classes,
I will be in touch with you.
Reading responses are due by 10 a.m. the day of class in order to
give me time to prepare a lesson plan that takes your responses into
account. Unless another due date is given, technical exercises should
be completed by the next class period after we work on them in class.
Because the first half of the semester will have a rapid pace and
the second half of the semester will focus on the team project, all
work is due when it is due. There is no policy for accepting late work.
If there are exceptional circumstances, talk to me.
Absolute deadline: All work must be turned in by Friday, December 21 at 5 p.m.
I am available to mentor and advise you on technical issues,
software development process, pair/team dynamics, and other matters
related to the course. We can meet one-on-one or in a group. When
necessary, we can discuss issues that concern your whole team during
class time. If team meetings aren't already on the agenda, please let
me know in advance via email that you want to make time for this.
See my contact information to learn how to make an appointment with me or when to drop in.
Because of the goal of professional development, I see my role in
this class as more of an adviser, mentor, and facilitator than as an
instructor. However, it is also part of my duty to give you feedback on
your progress and assign you a final grade for the course.
Exercises and reading responses will be graded on the following scale:
|PLUS (105%)||-||Exhibits exceptional insight and/or craftsmanship.|
|CHECK (90%)||-||Meets the requirements of the assignment.|
|MINUS (75%)||-||Does not meet the requirements of the assignment.|
|ZERO (0%)||-||Not turned in.|
We will develop rubrics for evaluating individual and group performance on the project as the project gets underway.
The following scheme will form a basis for final grades.
|Success of team project
|Individual contributions to project
I do not believe in grading on a curve; I would be thrilled to give you all As.
Janet Davis (firstname.lastname@example.org)Created August 25, 2012