July 15: Project Work II (Marine Day, lectures take
place)
July 22: Project Work III
July 29: 14:50-15:50: Term final exam
Exam coverage: All handouts, all explanations during lecture, all exercises
(except advanced exercises), all Moodle questions
Team Composition
First row: Remedials: Complete uncompleted exercises
Rows 2-12: Project teams (pairs)
Matched according to preferences submitted last Friday
Special cases:
A prefers to work with B, B with A, C with A ⇒ A, B form a team, C
separate team
A prefers to work with B, B with A and C, C with A and B ⇒ A, B
form a team, C separate team
No preference: Pairs formed according to assumed strength
Odd number: One team with only one member, according to
preference
How to Create an Application
Start with overall idea, with a user perspective (what should the users
be able to do)
Decide what data is needed (models, attributes/columns, model
relationships (1-n, n-n,...)
Decide what URIs are needed (routing, controllers/actions,
scaffolding)
Work on functionality (models, controllers)
Work on presentation (layouts, views, stylesheets)
Keep a checklist with items left to do (e.g. remove delete links from
users/index.html.erb; this list may become quite long at some point)
Work in a way that preferences visible functionality early
How to Work Together
Find the way that works best for your team
Efficient time use:
Chatting for an hour is a big waste of time
Brainstorming and design for an hour can be very productive
Efficient and precise communication
(misunderstandings can be very expensive)
Pair programming for central or difficult parts
Separate work for easier code, report writing
Try to split work so that both participants can use their knowledge
across the board
(important for final exam, too)
Be careful about dependencies (migrations, gems/bundle,...)
Pair Programming
Two people programming together
Sharing one computer, one keyboard, one mouse
Roles:
Driver: Uses keyboard, writes code
Navigator: Checks code, advises driver, thinks about next steps
Take regular turns
Migration Dependencies
Migrations are executed in order of their creation time
(part of filename)
Creating migrations separately requires great care
Bad example:
A creates a migration MA on PC-A
B creates a migration MB on PC-B and executes it
Code from PC-A is merged to PC-B
rails db:migrate is executed (but does nothing)
Migration MA is never executed
Checkpoints for Application
Use Rails conventions wherever possible
Use validations, tests
Use layout(s) and stylesheet(s)
Use decent code layout (indents, spaces)
Assistant Professor/TA Responsibilities
Assistant Professors and TAs will have closely assigned
responsibilities
Some will mainly answer basic technical questions
Some will mainly answer advanced questions
Questions may be redirected
Use Moodle Q&A for questions, too
Additional Rules and Advice
Talking within a team is allowed (but watch voice volume)
Talking and other kinds of collaboration between teams is not allowed
Make backups, do not lose your data
If you know how to use a version control system, use it
(e.g. git, svn; but do not make your code publicly viewable)
Otherwise, make regular backups into folders labeled by date/time, on
separate devices
(e.g. two separate PCs or a separate USB memory stick)
Always make a backup before merging work
Label your backups by date/time
The rails console command (irb with direct access to Rails
application) can be helpful
Today's Deliverables
Submission: Between 18:20 and 18:25, into box at back of room
