Skip to content

New Teammate Onboarding

Jump to bottom
Alexi edited this page Apr 20, 2023 · 33 revisions

Project Neo

So, what exactly is going on here? What are our goals?

Project Proposals

Below is the (most recent) project proposal document, for easy reference.

Alexi's Component

CapstoneProposal_v2-1 CapstoneProposal_v2-2 CapstoneProposal_v2-3 CapstoneProposal_v2-4 CapstoneProposal_v2-5

Other Teammate's Components

tbd

Repository Structure

This project is composed of three separate repositories that work together. This implementation allows for code separation, even though they are all interrelated.

Repositories

  • Neo: Manages local device AWS connection listener; ideally runs on local IoT device (Pi, or laptop)
  • Neopolitan: Library for displaying text on an LED board. Also includes a graphical display for use on a laptop
  • Dibiasky: Frontend for interfacing with IoT devices

Making new Issues

Issues from multiple projects can be added to one project board, as is done here. The drawback is that issues can only be added to milestones from the same repo (same with tags I imagine). I haven't fully hashed out milestones yet but that will be a nice thing to have once I do.

When adding a new issue, make sure to add it to the correct repository. Unfortunately, if you add it to the wrong one you can't edit it to change it to a different repo, you have have to make an entirely new one.

Try to add at least a description, if not a full user story, to each new issue. I think most of mine have them by now, but I imagine some are still missing info. Feel free to hound me/comment on any that aren't understandable. I'm also a big fan of the checkboxes for required subtasks.

I'm trying to stray away from "overall project" issues as much as possible and instead make individual "duplicate" issues for things that have to happen across all three repos, but sometimes there are overall things. Put these in the neo repo.

Tags

I really liked having the week-x and priority-x tags to help me figure out when an issue was planned/done and see how important issues are when I decide on a new one to work on. As mentioned above though I think that means we need to add those tags to each repository which is a lot of duplicate work. I'd say tag as you like and I'll add more tags later if I feel like we need them.

Branches

It would be nice to structure branches with all necessary info, such as issue#-briefdescription-initials, but sometimes that's a lot of work. I'd say try to organize them somehow but don't worry too much about it.

Requirement Organization

Development Log and Time Tracking

The requirement for this project is 275 hours per person. A (rough) hourly breakdown is located in the Developer Log. This allows an easy way to view hours spent on the project, a helpful way to see where you last left off, and a way for teammates to quickly see others' work. I am tracking hour by hour because it's easiest for me, and you can see in the navigation how I summed my hours for given time periods, but feel free to do it however you want, if at all.

If I ever get really stuck on something, I'm also adding the fix I found here so I can reference it later.

Project Board Organization

Project board columns and their intended usage (totally up for debate):

  • Backlog: Created issues that are not planned for the near future.
  • ToDo: "Up next" issues. At present there is no real timeline for these, they're more just "this needs to happen next" or "I'll work on these when I finish something else". This could be changed to a weekly plan so we have a better idea of timeline, but personally I don't feel like it needs to be.
  • In Progress: Currently working on (in some capacity). Some of these I'm more passively working on, ie I'll start working on them then leave them here while I work on something else for a bit.
  • Review: Issues that are finished but haven't been added to the weekly report. This makes it easier for me to see exactly what issues I've worked on that week and in combination with my hour log is what I'll use for my weekly check-ins.
  • Done: It's finished, covered in my weekly check-in, and reviewed by all team members if necessary.
  • No Status: This is where all new issues/PRs get put by default. Ideally we never have things here and use it as a staging area for new issues only right after they are created. When there are 6 columns I have to scroll horizontally to see the whole board and I hate that. lol.

First Steps

First off, sorry this is a bit of a mess. I'm doing my best to get it all organized, but the complexity going from one dev to multiple is quite a bit because I have to actually explain everything instead of just knowing what I want.

1. AWS Collaboration

Collaboration in regards to AWS is going to be tricky. I think the safest and potentially easiest way to do things right now is separate AWS accounts utilizing the same code. This makes it so that we're each responsible for any incurred costs and then we can collaborate when we run into individual access issues. I think for now this will work just fine with using separate resources, but if/when it becomes a problem it'll be a fun exercise in learning more about AWS.

So in short: separate and unlinked AWS accounts, for now.

2. Github Collaboration

All three repos have some very basic CI set up (more would be better, there are issues for that iirc). Because it's only the two of us working on this, the way I'd like to structure it is no required reviews for PRs, but require status checks to pass. This way we can both get work in without having to wait and if things get messed up it's just a quick Zoom call/Slack message to get it fixed.

You've been added as a collaborator to all three projects, go ahead and see if you can make a PR into all of them, if you like.

Actual First Steps

Let's see if we can get you set up on par with what I have so far. I expect to miss a setup step somewhere that will make you environment different from mine, so this might take a little bit of patience.

1. Get Neopolitan Working

Probably the easiest one to start with because it has no AWS connection and not many dependencies. I think you said you were interested in the drawing library, if not you can skip this.

  1. Clone the Neopolitan repo
  2. Follow the steps in the readme to get dependencies installed
    • Please take note of anything that's missed in setup steps and either let me know or just make a PR to the readme so it's documented somewhere
  3. Run the program using the steps in the readme
  4. Run the program with arguments using the steps in the readme

I've tested it on a new environment and it worked fine for me, but I'm curious to know how this will break for you!

2. Get Dibiasky Working

I think this is where things will start to break. This is where AWS Amplify comes in for user auth. Here's how I'd go about it:

  1. Go through the AWS Amplify QuickStart Tutorial. Don't worry about using my code yet, let's just see if we can get this working.
  2. Continue with the PubSub tutorial. If you follow it exactly there are no issues, but once you start editing routes/client ids it gets weird.
  3. This is where it gets tricky...maybe best if we go through it together?? todo: more steps
  4. Clone Dibiasky repo and see if you can get it to work from there

3. Get Neo Working

This is where we will probably start running into issues. There is some funky AWS thing that I know I missed here, I'll do my best to find it beforehand but no promises. IIRC, the solution is in my dev log somewhere.

  1. AWS IoT Overview
  2. IoT Core Connection Tutorial (start here)
  3. Install neo repository
  4. Create a .env file in the root directory. This will hold your individual connection secrets.
  5. Using the keys from the tutorial, add these variables to .env:
    • ENDPOINT=your-aws-endpoint (looks like xxx.iot.us-west-2.amazonaws.com)
    • DEVICE_CERT_PEM="-----BEGIN CERTIFICATE-----xxx-----END CERTIFICATE-----" (copy the contents of Device.cert.pem)
    • DEVICE_PRIVATE_KEY="-----BEGIN RSA PRIVATE KEY-----xxx-----END RSA PRIVATE KEY-----" (copy the contents of Device.private.key)
    • ROOT_CA_CRT="-----BEGIN CERTIFICATE-----xxx-----END CERTIFICATE-----" (copy the contents of root-CA.crt)
  6. todo: add missing steps that I don't know I missed yet
  7. At the end of all this, you should be able to run the program and see published messages in the MQTT Test Client

4. Make some PRs

Could also be the first thing. Make sure you can download all 3 repos, make some changes, submit a PR, have it pass tests, and get it merged back in. I figured just a simple edit to the ReadMe, or even just add a random new line somewhere, or if you really want to go deep look at the code and add a bunch of // what does this do? comments.

Moving On: Suggested Roadmap

This is just my thoughts of where the best place to go next would be. Totally open to discussion and it might take a moment to get even this far. Not necessarily in order of precedence.

  1. Team meetings/time commitments already covered
    • It would be great for us to have a scheduled time to meet every week to stay on the same page with what all is going on, but honestly I'm pretty darn busy and I imagine you are too. My preference is for doing our best to meet synchronously as much as we can but for the most part communicate async, but I understand that can make things more difficult and requires really good communication. Just let me know what works best for you.
  2. Add user-specific page to Dibiasky
    • I think that for now so we don't overlap code too much it might be a good idea to make separate pages in the webpage. The "correct" way to do this might be to show different information based on the currently logged-in user, the simpler way would be to just have a tab to switch between them so we could both see each others information, the easiest way would be to just add all our stuff to the homepage and not mess with stuff (too much) that isn't ours. This really depends on how interested you are in React, if you want to work on this go right ahead, if not let's go with option 3 for now and I'll look into it eventually.
  3. Your own repo??
    • This all really depends on what you want to work on. I've barely scratched the surface of deeper AWS stuff so far, so if you wanted to get started working with Lambdas or your own DS queries you could totally start with this and we could tie them into what I have so far later. The benefit would be that we're working somewhat independently for a little bit so I have a chance to set things up better, but the drawback is it pushes back the timeline for you getting onboarded with what I have so far.
  4. "Does this code make sense?"
    • Read through the code in all 3 repos and make sure everything makes sense. Are there places where things could be done differently or need more comments? Are there some things that are just done in not the best way? I imagine this will happen anyway by nature of working on the project (and honestly I don't expect you to want to start here).
  5. Start picking issues
    • This is probably a better way to go about the above item. Take a look at the project board for some issue(s) that look interesting (or ask me for some good starters) and take a crack at them. This would give you (and me) a better feel for what you're interested in working on.
    • Good First Issues
  6. Do our goals/milestones make sense?
    • Similar to #4, but perhaps a bit easier. Take a look at my project proposal and all the milestones in the 3 repositories. Do you have a clear understanding of what my goals are for this project? Can I clarify anything (I can probably clarify a lot of things, I just don't know what)? What can we add to make this align with what you want to get out of it?

Bottom Line

If we could get it so that you can run Dibiasky and Neo such that you can trigger an echo to your local console from the webpage by the end of the week that would be pretty cool and I think that would put us on the right track for moving forward.

Clone this wiki locally