Putting the 'Micro' in Microbrain
Tags: opensource
Published: 2021-02-13 03:33:43

![Microbrain](https://dev-to-uploads.s3.amazonaws.com/i/fk3ygbsg4bgssf21ggoe.jpg)

<div align="center"><a href="https://memory-alpha.fandom.com/wiki/Microbrain_(insult)"> Microbrain </a></div>


...And we're back.

From outer space.

I just walked in to find you here with that sad look upon your face.

___

​	Monday-funday rolls around and I started the week off working on my [About page issue](https://github.com/Seneca-CDOT/telescope/issues/1651). I'm finding this issue to be unexpectedly challenging, mostly due to the fact that my NextJS knowledge is not great, plus I'm trying to figure out how to style an MDX page using a combination of [Pagebase](https://github.com/Seneca-CDOT/telescope/blob/master/src/frontend/gatsby/src/pages/PageBase.js) and [template](https://github.com/Seneca-CDOT/telescope/blob/master/src/frontend/gatsby/src/templates/template.js) at the same time, as our previous about page for Telescope was comprised of both pieces. In essence, my problem resolves around the fact that I can't just wrap plain markdown in an MUI theme. So right now I'm trying to import the about page content separately and style the entire `about.mdx` page. But this too is being problematic, yet also opportunistic. If I can solve this issue, I'll be able to simply import all of our other documents  in our `docs` folder and render them accordingly.

However during our last triage meeting on Tuesday Royce raised a question asking if we can re-implement Pagebase, so He, Anton, Ilya and myself are going to have a meeting to [discuss how to implement that](https://github.com/Seneca-CDOT/telescope/issues/1691). This might be a better alternative for me, and will probably be more elegant that the current spaghetti I'm cooking up. Mmmmm pasta.

​	Tuesday rolls around and and I'm still practicing away with my goal of GitHub inbox zero, all notifications clear and unfortunately all the fishy PRs have been hooked, lined, and sinker'd already. Hoping my pole snatches a few before the end of the week. In other news, [Pedro's](https://medium.com/@pedrofonsecadev) new design is [looking REALLY nice](https://github.com/Seneca-CDOT/telescope/issues/1676) and I'm really interested to see more.

We had a great triage meeting as usual, this week [I was the desinated taker of ~~lives~~ notes](https://github.com/Seneca-CDOT/telescope/wiki/Triage-Meeting-February-09th,-2021), and I think I organized them pretty well all things considered.

​	Wednesday, everyone's least favourite day. Today I started working on a small [meta tags issue](https://github.com/Seneca-CDOT/telescope/issues/1655) that I raised a few days ago. I found that we're using `<title>`, `<Head>`, `<meta>`, both, neither, or using our SEO component, incorrectly. So I'm hoping to fix these smaller issues with this PR. As `<meta>` tags also relate to [Accessibility](https://github.com/Seneca-CDOT/telescope/issues/1608), Anton's domain, I spoke to him about this as not to step on any toes, he gave me his blessing so I got to work. The way this week is looking I'll have the PR ready today or sometime later.

I'm also starting to review [an older PR by Mo](https://github.com/Seneca-CDOT/telescope/pull/1606), which adds a neat frontend variable, a topic which I somehow always struggled with during the few times that I've tried to implement it. I made a comment on and I'll get back to it ASAP.

​	Thursday. I reviewed [another PR](https://github.com/Seneca-CDOT/telescope/pull/1694) from Mo and had to do [some](https://stackoverflow.com/questions/66020820/npm-when-to-use-force-and-legacy-peer-deps/66035709) [light](https://github.com/npm/rfcs/issues/218) [research](https://docs.npmjs.com/cli/v7/commands/npm-install) on what exactly `legacy-peer-deps` does. I also finally made the time to start some light work with my User Microservice (see below.)

> Having a peer dependency means that your package needs a dependency that is the same exact dependency as the person installing your package. This is useful for packages like `react` that need to have a single copy of `react-dom` that is also used by the person installing it.

<div align="center"><a href="https://classic.yarnpkg.com/en/docs/dependency-types">Source</a></div>

​	Friday is here. I started off the morning by commenting on [a PR that adds documentation](https://github.com/Seneca-CDOT/telescope/pull/1695), and you know how much I love me sum documentation. Moving on, I spent some time trying to test [yet another one of Mo's PRs](https://github.com/Seneca-CDOT/telescope/pull/1696) but for some reason I'm getting super strange errors. I followed up with Mo and everything looks fine on his end so I can only assume that it's something on my end. I was hoping to have a review for this up by today but Jest is not co-operating with me and I don't even know where to begin with these errors.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/43iwy5dio2y4x61vi3i7.gif)

Our meeting was cool, I enjoy all of our meetings but the demos that some of us put on on Fridays always give me something to go *ohhhhhh*... *ahhhhhhhh*.... *ouuuuuuuu* at. We started off with Yuan and Anton demoing their respective works and investigations with Dependabot and Renovate. Both seem really cool. Dependabot is built into GitHub natively now, though Renovate seems more customizable (*and more advanced.*) I've always wanted to implement Dependabot to some repo, so maybe I'll do it for my capstone project. Looking forward to see more Dependabot in action. 

**Edit**: *I regret everything. Bot-sama plz.*

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/yxbv3dyctvj3hnnnx0tr.png)

Similarly, during the meeting I had a chance to demo my very (*minor*) work that I've done on the User Microservice the group, and got some really great feedback and direction which I'll discuss below.

I ended Friday with a little hangout session with Anton and Abdul where we spend an hour figuring out the best possible names for GitHub tags for Dependabot to use. It's **very** serious business.



___

#### User Microservice

*For those who didn't read last week's blog post:  I'm currently working with Anton on a way to [migrate a large list of data](https://github.com/Seneca-CDOT/telescope/issues/1642) (Telescope users names and blog URLs) to an external database. The database we agreed to work with is Google's Firebase.*

​	Woohoo! I'm giving this current PR its own section because it's a lot to talk about (and also because I'm really excited about finally contributing something on the larger side to Telescope.) I had a meeting with Anton on Monday before our Triage meeting, which was a lot of fun, he's a great guy to work with. We partially scoped out the issue but had several questions we needed to raise during our meeting such as:

- How does the current feed system work?
- How does Seneca's authentication work, and what does it return (and how can we leverage this data for our issue)?
- Since we're adding more data to the users (GitHub usernames *&* Avatar URLs) what should we do about our "legacy" users which won't have this information on file (until they sign into Telescope again?)
- Do we want a user to store multiple feed URLs?
- How should we parse users with multiple names?

Thankfully, all these questions (and more) got perfectly answered. We also got some feedback on what the user "schema" will look like ([*which you can see here*](https://github.com/Seneca-CDOT/telescope/issues/1642#issuecomment-776922598).) I'm still trying to find my mix between brevity and verbosity, currently leaning more towards the latter as my weird anxious mind (*imposter syndrome*) makes me want to explain everything humanly possible (*to the detriment of others, mind you*.)

I'm very excited to start working on this, hopefully, if time permitting, I'll be starting on this later this week.



##### Feedback and Direction:

As mentioned after Friday's show-and-tell, I got some good comments, concerns and directions to take this feature in:

- So Firebase requires a private API key in order to authenticate the developer's working on the DB. I'm currently storing this key in a `.json` file, which is pretty redundant given that we have a perfectly good `.env` file to utilize.
  - After the meeting I went to try and implement the in the main `.env` file but ran into a few blockers:
    - The JSON key is too large to fit inside of a single-lined string.
    - Furthermore, I couldn't even import any environment values as they were all being listed as `undefined`. I wanted to look into this further but used enough time as it is so I dropped this issue for now. I'll ask for help soon*ish*.
- ~~Add some CRUD code to **create** a user to the db (*with a randomly generated id*.)~~
- ~~Add some CRUD code to **read** a user from the db (*with a specific id*.)~~

- Figure out how to add unit tests, and work with the Firestore db offline (*probably the most challenging.*)
- Implement [middleware to handle data validation](https://www.npmjs.com/package/celebrate).



##### Things I'd like to do:

- Implement pino logging
  - We currently use [pino](https://getpino.io/#/) in a few places in the project, I'd like to use it here too.



I hope to have a draft PR up for all of the above by Friday the 19th. Maybe a better approach is to implement a basic skeleton and create various issues to see if anyone is interested in trying their hand at this.



___

Other News:

- Stanford made their iOS development course [public on youtube](https://www.youtube.com/playlist?list=PLpGHT1n4-mAtTj9oywMWoBx0dCGd51_yG) which is awesome. Maybe I'll take a look into that sometime.
- Attended a Seneca Honours Bachelor of Technology - Software Development Alumni where five graduates spoke about their history in the program and where they are now. Surprisingly two of the alumni gave shoutouts to David Humphrey and the OSD course! Again, extremely grateful that I'm here.