The MakerSquare Thesis Project is your final and largest project as a student. It'll probably be the largest code base you share with potential employers. The project will last four weeks and will be the last step before you focus on hiring and job search.
You'll begin by working with your team to define a solid infrastructure to support your project.
Use the lessons you learned during the greenfield-project and the legacy-project to help inform the decisions you make now.
-
Get into your assigned groups (end of this document)
-
Each member should spend five minutes (no talking) answering the following questions:
- What are my 2 greatest technical strengths?
- What are my 2 greatest technical challenges?
- What are my personal goals for this project?
-
Group Discussion
- Discuss your individual answers with your group. Get to know each other.
As a group, decide which team members will fulfill each of the three core scrum roles.
- Product Owner
- Scrum Master
- Development Team
- Fill out the Team section in the readme with this info.
Don't worry too much about choosing a name at this point. You'll likely refactor it several times anyway.
- The Scrum Master must Create a new GitHub Organization account for your team. This ensures that all members share equally in the glory of the project.
- Add all your team-mates as members to the new org.
- Create a repo within your new org for your project.
Create product vision by drafting a 'Project Summary'
- Copy
_PRESS-RELEASE.mdinto the root directory of your own project repo and complete the exercise described therein. Note that the actual instructions are hidden in a comment block. You'll need to view the raw file, not the rendered markdown version to see them. - Use github issues
In order to support your current team and future contributers to your project, you'll need to document your project as you build it. It should be the case that, without any intervention or additional explanation from you, the next team of collaborators (or yourself in six months) can dive in and figure out how to start hacking easily.
Document your project and codebase to the point that if you decide to push it to hacker-news, anyone with a solid understanding of JavaScript can (after reviewing your documentation and comments) start submitting pull requests. Plan on not having any face-to-face interaction with the next team of collaborators. The most effective and efficient way to accomplish this is to do it right from the very start. Don't wait till the last minute. That will never work.
- Heavily comment all aspects of your code.
Be sure keep your project backlog (using github issues) up to date. There should be clear documentation of tasks completed (github provides this functionality automatically) and next steps/features in your project backlog so that your collaborators can just dive right in.
You should use github issues to track both your project's backlog of tasks and fixes and to provide a way to track future goals. You can use labels to organize issues and milestones to group issues together and to visualize your progress.
You may want to take advantage of a tool like waffle.io to manage github issues with a more powerful interface and can provide a kanban-board-like place to manage your project and workflow.
- Document your team's git workflow by copying
_CONTRIBUTING.mdinto the root directory of your repo and editing it suite your needs. It follows a forking workflow.
The provided _CONTRIBUTING.md advocates for a git rebase based workflow
instead of a git merge based workflow. The advantage of a rebase based
workflow over merge is that a rebase, even one which fixes conflicts, does
not introduce a new commit into your history. If you use merge and there are
any conflicts, then you will get a new "merge commit" in your history. Over
time, you can accrue hundreds of merge commits which can make your history
significantly harder to read and introduce a much lower signal to noise ratio
in your history. rebase avoids these problems by changing existing commits
instead of creating a new one.
Because rebase changes commits, you will have to push with the -f or
--force flag to your branch after rebasing, as the history has changed in a
way that git cannot resolve. You should never rebase or push with force to
the master branch of your repository, as that will invalidate everyone elses
clones and checkouts of the repository.
Though it advocates for a slightly different version of the rebase workflow, the article, A romance of a single dimension: linear git history in practice does an excellent job of justifying the practice. I strongly recommend reading it, even if you choose a different option.
Remember, you're welcome to use which ever git workflow you want, _CONTRIBUTING.md is provided here as a suggestion (with the intention of you editing it). But whichever workflow you choose, you must document it well, you must be consistent, and you should always have someone other than the person who wrote the code review it before it's merged into the central repository.
- Document your team's style guide by copying
_STYLE-GUIDE.mdinto the root directory of your repo._STYLE-GUIDE.mdis provided as a template, you should edit it to reflect your agreed upon setup.- AirBnB's and The Google JS Style Guide are also excellent examples.
Your project readme is the very first thing that users will see when they view your github project. It's the portal that must link to the other content files in the root of your repo.
- Use
_README.mdas a template to create a thorough readme.- It must link to the documentation you've created (as described by the items above).
You must have a deployed website setup.
- Configure automatic deployment of your master branch using Heroku/AWS/etc.
Your team should communicate new ideas for features or report important bugs through github issues or whatever tool you use to manage github issues, that way everyone on your project can see what important things are happening and there is always a repository of further work to be done.
To introduce new code into your project, your team should always make pull requests - never make commits and push directly to master. After you make a pull request, at least one other member of your team should do a thorough code review of the changes and you should have a good back and forth where the code is refactored and improved before being merged in. This will guarantee a higher degree of code quality and will prevent careless errors from being merged into your application.
- Read this excellent (and brief) article about pull requests
With continuous integration, you will benefit even more from a pull request based workflow because you will always know that you are never merging breaking code into your master branch.
You may want to use a persistent chat service like hipchat, slack, or irc to communicate as a team so that you can have efficient asynchronous communication. This will make your team more accountable and efficient, so you don't have to stop everyone else's work to discuss small issues or request code review.
- Create a simple home page for your project.
- If you're not sure where to start, checkout using GitHub pages. It's free, robust, and can easily be personalized to your own domain.
- Make the landing page a salesman's dream (clear, flashy, cool design, etc)! Templates are your friends!
During your Thesis Project, you'll be using TDD.
Test driven development is not valuable because it catches errors, but because it changes the way you think about interfaces between modules. Writing tests before you write code influences how you think about the process. It provides a safety net for performing refactoring and it documents the expected behavior of the system.
Refer to the the solution branch of the testify for some solid examples
You must implement all of the following:
- Include testing when defining your project scope
- Continuous integration to run all tests on commit
- You can use any CI system you like, TravisCI (easy) or Circle-CI (med) or Jenkins (hard) are all options
- Make testing part of daily standups
- Discuss testing during mentor check-ins
You must implement 2-3 of the following:
- Unit testing on the client
- Unit testing on the server side
- Integration testing for your API and database
- End-to-end testing for your main workflows
- Code coverage reports for unit tests
- Visual testing for your app’s look and feel
An important part of your thesis project is its presentation. We'll hold several practice sessions in the lecture hall, culminating in the creation of a video that can be shared with prospective employes, on your online resume and/or your portfolio page. Theis practice will help prepare you to speak eloquently about your project in your interviews thereafter. Practice sessions will be held with your entire cohort present, providing a range of perspectives to help refine your delivery (keep an eye on your calendar for specific dates). Your group presentations must be (at most) 3min long.
In preparing for your presentations please make sure that you address the following specific issues/areas:
- Be sure to introduce your team at some point during the video; typically this occurs at the beginning or the end of the presentation.
- Explain the project to the audience at a high level before jumping into details. Think about framing your presentation as a story.
- Try to coordinate tightly between the person speaking, at any time, and the person driving tech. The person speaking and the person driving should not be the same person at any time.
- Do not require the audience to read too much text on the screen
- Do not have off-mic conversations with your team while you are presenting.
- Everything that you put into your presentation should make the case for why you or one of your teammates should be hired as a software engineer. If you have a lot of time left, there are a lot of things you could be saying about why you are awesome.
- Speaking of time management, your presentation must run precisely 3 minutes long.