I let this week get away from me due to all the chaos that comes from midterms. Ah well, so much for inbox 0.

Without further ado (i.e. excuses,) let’s begin with what went down this week on the admin side of Telescope.

​ On Wednesday it was discovered that our new Telescope builds were failing to deploy to our staging server despite our CI being all green across the board:

Copying API_URL=https://dev.telescope.cdot.systems to NEXT_PUBLIC_API_URL
Using NEXT_PUBLIC_API_URL=https://dev.telescope.cdot.systems
info  - Creating an optimized production build...

Failed to compile.

./src/components/Posts/Post.tsx:101:54
Type error: Argument of type '{ month: string; day: string; year: string; }' is not assignable to parameter of type 'DateTimeFormatOptions'.
  Types of property 'year' are incompatible.
    Type 'string' is not assignable to type '"numeric" | "2-digit" | undefined'.
   99 |   const date = new Date(dateString);
  100 |   const options = { month: 'long', day: 'numeric', year: 'numeric' };
> 101 |   const formatted = new Intl.DateTimeFormat('en-CA', options).format(date);
      |                                                      ^
  102 |   return `Last Updated ${formatted}`;
  103 | };
  104 |

The failing file was Post.tsx, which strangely enough, was not touched for about 10 days. The builds were building just fine otherwise, it wasn’t until we tried to build Telescope using Docker that we discovered the failure.

The fix was even stranger (old vs fix):

  const date = new Date(dateString);
  const options = { month: 'long', day: 'numeric', year: 'numeric' };
  const formatted = new Intl.DateTimeFormat('en-CA', options).format(date);

vs.

  const date: Date = new Date(dateString);
  const formatted = new Intl.DateTimeFormat('en-CA', {
    month: 'long',
    day: 'numeric',
    year: 'numeric',
  }).format(date);

I laughed about it with Josue before approving the fix 🤷 The lesson: have your CI deploy using the same tech as your prod server. Our CI does not build, run , and test using Docker and that’s where the disconnect came from. One failed using Docker, and one did not.

Thanks Doc Josue!

​ I also minorly reviewed Tony’s microservice. I didn’t end up testing it locally, it’s on my list of things to do tomorrow after work. It’s great to see another microservice popping up that I can look at and borrow (steal) ideas from. Currently looking forward to more of this, plus Abdul’s and Professor Dave’s stuff.

User Microservice Update

Several updates happened this week to my microservice:

  • I finally got Firebase to work offline.
    • It took a lot of trial and error, and blog posts mostly. I’m still not that great at reading technical instruction documentation.
  • This means I can implement testing!
    • Since the db can now be manipulated offline, I can add and delete data to ensure that when we use the actual production version of the db, all our code that we’ve developed will work as intended.
    • This also means that I can now start writing unit tests to ensure a solid relationship between Express and Firestore.
    • The whole experience of this two pronged attack (offline mode + testing) has been really enlightening, it really displayed how quickly a prototype can be created, demoed, and implemented using some basic tooling. It doesn’t matter if your db is on or offline, if you can test it then the code you created is guaranteed to work on a production version (sans outside interference from other tools like nginx, firewalls, etc.)
    • I added several basic unit-tests using Supertest (after failing an initial attempt using Got)

I also got some really great feedback and direction from a little demo I presented to Professor X. Let’s take a look (and laugh) at this week’s goals from last week’s blog post:

  1. Get testing working with the emulator and Jest Done!
  2. Implement Satellite
  3. Create some basic README.md files
  4. Export my private key to .env (was having trouble with this last week) Not possible in this form
  5. Figure out how to utilize my User class/schema Will likely be deleted
  6. Create an update route
  7. Create a delete route
  8. Add date/time users were created (mostly for funsies)
  9. Add date/time users were updated (again, for funsies)

Here is the updated todo list that I want to get done between now and our next big release (1.8 - March 12th 2021):

  1. Finish up making some more tests, specifically ones that test Celebrate’s validation rules
  2. Migrate to https://www.npmjs.com/package/@firebase/rules-unit-testing because @firebase/testing is deprecated
  3. Create a basic README.md file
  4. Implement a list of current deficiencies and issues to discuss when the draft PR goes up
  5. Implement Satellite
  6. Dockerize the microservice
  7. Add Firestore private key placeholders to env.production and env.staging
  8. Tidy up the package.json run commands using npm-run-all
  9. Create an update (put) route
  10. Create a delete route
  11. Add date/time users were created (mostly for funsies)
  12. Add date/time users were updated (again, for funsies)
  13. Migrate unnecessary package.json dependencies to dev-dependencies
  14. Finally, create a draft PR!

I think that about does it for me this week. Hoping to get some more done next blog post to show off.

Other news:

  • I got an Aeropress on sale this week and some ground coffee at a local coffee shop, I’ll never go back to my Kureig.
  • I think midterm week went okay for me. 🤞
  • I’m participating in Seneca’s hackathon next week! It’s my first and I’m hoping it’ll be a lot of fun.