Previous Lecture

lect03

Next Lecture

lect03, Mon 04/06

Monday Section: Initial README, Team Agreements

Teams are Assigned

You should have been:

• invited to a team channel on the Slack
• added to one of the teams on the ucsb-cs48-s20 Github org.
• given admin access to a project repo for your team
• given read-only access to a FEEDBACK repo for your team

You’ll also be put into a Breakout Room with your team during section today.

The Slack: _articles vs. _help channels

On the Slack, there are several pairs channels that have the endings _articles and _help, for example:

• #git_articles, #git_help
• #nextjs_articles, #nextjs_help
• #spring_articles, #spring_help
• etc.

In each case:

• If you want to share a useful article, tip, blog post, video, etc. about the topic, post in the _articles channel for the topic.
• If you need help with the topic, i.e. you want to ask a question, post in the _help channel for the topic. You are also encouraged to provide help in the _help channel if you think you know the answer to someone’s question.

The #nextjs_* channels are for everything JavaScript related

Note that the #nextjs_articles and #nextjs_help channels will also be used for all technologies that relate to the next.js stack, including:

• JavaScript
• node
• express
• React
• Cypress testing
• etc.

The #spring_* channels are for everything Java related

Similarly that the #spring_articles, #spring_help channels will also be used for:

• Java
• Thymeleaf
• Maven
• JUnit
• etc.

If you aren’t sure, you can always use #general

If you aren’t sure where to post or ask something, you can always use the #general channel.

A few more special purpose channels:

• Always monitor the channel for your team
• Always monitor the channel for your discussion section or lecture section during lecture or section

Absences

If you need to miss class for an unavoidable reason, please notify:

• FIRST, your team, on your team channel
• SECOND, DM the instructor.

Please send these notifications:

• in advance where possible.
• as soon as possible after the fact, when advance notification isn’t possible.

This is a matter of showing respect for your team.

Then, as soon as possible after the class, check with your team to see what you missed. It should be a team responsibility to help one another with unavoidable absences.

Unavoidable reasons might include:

• Being too ill to participate in class
• Family emergency
• Internet outage
• An online job interview that could not be scheduled at another time.

Of course, unavoidable absences should be rare if you are going to remain in good standing with your fellow team members, folks that are depending on you to do your part for the team.

Breakout work today

Today, during your breakout sessions, you should accomplish the following tasks:

1. Add an initial README.md (details below)
2. Start a discussion of your team agreements / team norms and record whatever agreements you are able to reach in team/AGREEMENTS.md (details below)

Initial README.md

One member of the group should go to the page for the repo, e.g.

• https://github.com/ucsb-cs48-s20/project-s3-t2-meal-plan

On the page for your team, you should see a screen like this one:

Click on the work README in the sentence We recommend every repository include a README, LICENSE, and .gitignore.

In your README.md, put the following:

• The name of your project
• A one sentence description of your project
• A list of the full names and github ids of the members of your project team

team/AGREEMENTS.md

Under a directory called team, create a file called AGREEMENTS.md.

In this file, you’ll first put the names of the members of your team.

Then, you’ll enter a list of agreements. These are things that you all agree are good practices for creating a harmonious productive team.

As a suggestion, the first few team agreements, might be these:

1. When one of us is absent for an unavoidable reason, we will let the other team members know on the team slack channel, in advance when possible, as soon as possible afterwards when not.
2. We will each try to keep such absences to a minimum.
3. Those of us that are present will do our best to share with the absent team member(s) what they missed and help them get back up to speed.
4. We will all do our best to contribute to the teams success.

You then might add a few more.

Consult this article for ideas:

• https://ucsb-cs48.github.io/topics/teamwork/

If you run out of time

If you run out of time, the agreement discussion can be continued outside of class over the slack, and during the next lecture.

If you finish early

If you finish all of the above, you can start on a discussion of the following things. These are discussions that will carry over into Tuesday and Thursday lectures, but you can start them now if you’ve finished the items above.

Add to your README.md:

• Which tech stack your group plans to use
• Some initial planning about what what you want your app to do for the user.

Which tech stack

We’ve provided a lot of information for you already, and when we formed groups, we took tech stack preferences into account. So in most groups, there is likely to be a quick consensus on which tech stack to use. But you should still discuss the pros/cons of each, and share your preferences with one another.

If you have questions, or need guidance, ask the course staff (Prof. Conrad, Scott, Andrew L, Bryan T, Cole B., Kristin H, and Victor S.).

Planning your app

For the second item, focus on writing a single paragraph in which you go into a bit more detail about what you plan for your project.

• This is NOT intended to be a full specification of what you are going to build. It is just an opportunity to briefly add a bit more detail that wouldn’t fit into the one-sentence description.
• Later this week, we’ll be going through some “user-story mapping” exercises to do a more detailed design, so don’t get bogged down trying to make this paragraph comprehensive or perfect. It’s just a first step.

Some things to consider:

How many different kinds of users are there, and what are their roles?

Examples:

• A ride share app mvp has two kinds of users: those looking for rides, and those offering rides.
  • A third kind of user role you might need is site admins, users that can have the power to delete anyone’s posting.
• A game app might have only one kind of user: game player
• A Recipe sharer app might have two kinds:
  • Users that look up recipes, but can’t add new data to the system
  • Admins that can upload new data to the system
  • Later, you might also allow user contributed content; in that case, you might want admins to have the ability to delete inappropriate content.

Think about the fact that your app will be available on the public internet. If your app allows user contributed content of any kind, there is the potential for inappropriate content (spam, or worse) to be added. One option is restrict your user base to folks with an @ucsb.edu login; we can provide example code for both Spring Boot and next.js that you can build on to add this feature to your app.

What will each different kind of user be able to do in your app?

• What are their goals in using their app?
• How does your app allow them to accomplish their goal?

Future steps: .gitignore and LICENSE.md

Two future steps will be to also add .gitignore and a LICENSE.md

The .gitignore will depend on your tech stack choice.

• Create a file called .gitignore in the root of your repo
• For Spring Boot project, we recommend the contents from this article: https://ucsb-cs48.github.io/javatopics/gitignore_maven/
• For next.js, a good start is the .gitignore for Node, found here: https://github.com/github/gitignore/blob/master/Node.gitignore

For the LICENSE.md:

• Consult https://choosealicense.com/.
• The MIT license is a reasonable choice if you don’t want to spend too much time troubling over this.
• Create a file called LICENSE.md in the root of your repo, and copy the license terms into that file.