Planet CDOT (Telescope)

Wednesday, May 12, 2021

Raymond Rambo

The Spring Workload and Auditing My Progress

Where Ya Been

I planned to write a blog post at the end of February talking about how much I got done in the month - reading that post I laid out some pretty hefty goals for a single month. Especially while I was still working.

However, at the time I was working maybe 16 hours a week? At the very least it was an amount that made me feel as if I could have multiple days off a week to work on projects.

That didn't exactly go as planned. As one might be able to tell.

The main purpose of this blog is to audit the amount of work I got done over the last 3 and a half months and plot a course for the next couple. It's not meant to be a big long document where I kick myself for not working hard enough because frankly, that's unhealthy. Plus I have good reasons for not getting any work done!

These last few months have been... well not stressful, but busy. Work picked up in a way that I did not expect as inventory and the spring seasonal came in full force over March and April. I was working between 30 and 40 hours a week at that time and I don't blame myself for not having worked on projects. Likewise, for the last half of April I tested positive for covid-19 which is not an illness that is easy to work on the computer with, I'll tell you.

So fine, I don't think kicking myself for not getting that lengthy list of projects done is helpful so I won't do it. However, like I said previously, I would like to take a look at that list and plan how I will get it finished soon and move on to the many other ideas in my head.

Goals 2

1. Implement my second feature into RayAi

This was not done for a reason I'll reveal in a bit, but as well, I didn't work on it because I haven't felt terribly inspired to work on it. I think at least 1 more feature is something I want to get done pronto but after that I think I'll put this one on the back burner for some new projects I have in mind. It's already on the back burner for...

2. Move my personal website to a better url

This one was simple in hindsight but annoying the way I did it. So I was recommended to a friend to use a VPS provided by a cheap and efficient provider. I thought this was a great idea at first, but I quickly realized setting it up was much more annoying than a slightly more expensive provider that made things easier. I fooled around with the VPS for a while and after deciding that I didn't want to be a server administrator and instead wanted to be a developer, I switched to a much simpler provider that allowed me to deploy my static site at overnight.

So that's a win!

3. Start on a React project

This one actually got done too! A family member has a small business and I offered to build them an e-commerce website from the ground up. I've run into a snag or two from learning more about React and I'm at the point in my development where I'm realizing I need to integrate the e-commerce elements from the start. But hopefully, I can finish this project up, since it feels like it's moving quickly, and move onto another React project.

So what's next?

Well, I don't think I'll be making a big showing of it in this blog post, but I have a few goals that I would like to accomplish before I write another.

The first is to finish up this e-commerce platform and put it under my belt. Having a project like this I feel will look really good and give a huge sense of satisfaction. Plus I can commission friends who have small businesses to build them something similar once I know how to do everything. :)

The second is to finally get to work on that Discord bot again. I like developing this bot for Discord but it takes a lot of time and I don't usually have the patience for it. It's nice the see the fruits of your labour though. I have ideas.

Finally, I would like to get started on a NEW new project, probably in React, and as well as the Discord bot, I have some ideas.

So these goals are in chronological order and if I get through the e-commerce platform and the Discord bot but don't start a new project, I'll be ok. But I absolutely would like to see these to fruition quickly.

Until next time!

by Raymond Rambo at Wed May 12 2021 22:18:42 GMT+0000 (Coordinated Universal Time)

Tuesday, May 11, 2021

Ray Gervais

Re: My Most Notable Failures

Remember when response videos where a thing? Here’s mine: So this week, Mr James Inkster(grommers) himself graced us with the first look into his thoughts for the past year in the form of a blog post titled, My Most Notable Failures. It was a damn good read; full of honesty and admittance not to actually making mistakes, but realizing that there’s still so much more learning to do. That’s how I interpreted many of the points he had raised, even going so far to say that by Breaking Linux by following random instructions online, he was truly becoming a real software developer by learning both how to break and fix your development environment.

by Ray Gervais at Tue May 11 2021 00:00:00 GMT+0000 (Coordinated Universal Time)

Tuesday, May 4, 2021

James Inkster

My Most Notable Failures

I’ve been on a journey from working more as a business analyst to a software developer. I’ve always believed in following your dream. To many people give up, and begin to settle. Partially because it’s the path of least resistance. It’s easy to not put yourself in a situation where you are uncomfortable or challenged to grow.

Open Source software has been a great way for me to dive into those, work on giant projects and give confidence to my abilities. I like being tested, I like people having high expectations of me, and nothing is more rewarding then failing for me.

Wait what?

Reconciling failure and what it means, is something school doesn’t teach. And I get why, the idea of “accepting” failure is bad. It shouldn’t be normalized, you shouldn’t want to fail. Once someone knows you will accept there failure, you may be quick to jump back to failure as a way to get out of a situation.

I always feel this is an internal “bias” people create. A way to justify one’s actions and what I mean is, be aware of this, fight these internal thougths. These are a simple bias in your own notion.

Now, what does this have to do with Open source? Well, when I first started doing Open source, I had failed on one of my code merges, the code I wrote was crap, and I couldn’t figure out how to write it, it was a simple CLI project, and I remember this quite clearly, because I accept that I failed, but I do not accept failing again on the same situation.

This allowed me to continue to break down barriers, work on larger projects, and even realize I have to spend more time analyzing and understanding the project I am working on. All these things, I do much more efficently now. This is probably one of the more daunting facts that a lot of people don’t get acclimatized too

Now, when I took DPS911, I had gotten used to working in a more complicated system, not as complicated as the current section has made it with microservices, which I am hoping to jump back into this summer.

The cool thing with DPS911 is that it really sets you up to be a software developer in the workplace. The only difference being expectations are higher, given that instead of you paying to be there, you are being paid to be there. So there was that, however I ran into the same situation when I first started it was simple as “Adding your own API route and front end code so you get a feel for how to navigate things.”

My second failure was at Co-op. Normally this is an easy task for me, but this took way longer then expected, partially because I found I had a gluten allergy (pesky gluten) which surprisingly can really affect concentration (yep, this is a thing?). And it was very hard for me to focus at first on top of working at home, it was a rough start for me. I got it done eventually, but needed help, there was a lot of moving parts, and being physically unable to concentrate is a tough challenge.

Over the course of the next 8 months, I spent a lot of time learning from extremely talented individuals, some who I questioned if they were robots because of the way they looked at problems, but overall amazing individuals who definitely pushed me to be a better developer. I got to use a wide variety of tools and software and I can honestly say I felt comfortable taking on every challenge. I knew to ask a bunch of questions even getting as far as being known as “the guy who asked more questions then every other previous co-op combined”, as I don’t believe in leaving any stone unturned. They quickly picked up on my ability like most people to go down rabbit holes, and as I gain more and more experience I don’t find the need too like before.

There was a number of identical procedures

  • Stand-ups (weekly for telescope, daily for work)
  • Going over current issues (stories at my workplace)
  • Telescope had : CI/DEV/PROD, work was CI/QA/PROD
  • work had a QA (sadly there is no budget for this on telescope)
  • discussion about the direction
  • presentations (my work actually started this after I had brought up, i had no idea what other people were working on, and the business teams said the same thing)

This was an amazing experience and big shout out to the individiuals there who pushed me, and made me a better developer, and made me think of different solutions to problems.

My third failure has actually been switching to Linux. Look, anyone whose been in the dev game a while knows Mac or Linux is the better development tool, they’re just so much more responsive, less bloat ware, and a lot of cool tools.

Whats my failure?

I’ve had to reinstall the OS because I’ve deleted or changed files that shouldn’t be changed….TWICE so far. It’s a learning process, and it really sucks messaging @Ray Gervais with “I need your help with linux again.”

And hes been fantastic with helping, and guess what people? I met him through Open Source and I consider him a pretty close friend now.

My next mission is to make a game, I’ve never done this before, so I’m sure there will be smaller and smaller failures, but it will be a fun journey, hoping there is no failure, but not shying away from it if it does happen.

And open-source has prepared me for this, and my next failure that I can’t wait to learn from, and if it never comes, hey, that means I’m perfect right?

by James Inkster at Tue May 04 2021 16:53:43 GMT+0000 (Coordinated Universal Time)

Friday, April 30, 2021

Abdulbasid Guled

How the covid-19 pandemic will define what is otherwise, a really bad moment

My grades are out. They're really good. Considering I took way too many classes than I really needed to, I'm happy with my results overall. So what's with the title?

Well, this summer is supposed to be an internship moment for myself and many others in my position. We should be gaining valuable experience in the industry. This is mostly to learn and to grow, even if it's a requirement for us to graduate. For many like me, however, graduation may not ever happen.

The covid-19 has hit every person in the world hard, especially the young folks. Businesses especially are having to make very tough decisions. I don't envy the business owners that have had to cut costs by laying off employees, but they should at least be aware of the consequences that will have. In my attempts to search for a co-op opportunity, I have applied to over 50+ jobs, both on my job board that my school has, and on other external sites such as linkedin, indeed,, and etc. I have only received 2 interviews. The first 1 rejected me after about 2 weeks. The second one is a pending rejection at this point, because internships start on May 3rd, and I don't anticipate an offer on the weekend. For students like us, it's very depressing. I know so many individuals that are uniquely qualified, and yet, aren't ever given a chance to shine. I don't want to be doing a minimum wage job for the rest of my life. That's why I came back to school in the first place. The reality is that this pandemic may not even end, anytime soon.

Although vaccines are starting to ramp up, the damage that has been done to the economy will be ever-lasting. I'm now left to ponder what to do next. I'm almost finished school at this point, but the amount of companies that have not said a word to me is astonishing. Consider this:

I don't want to show my resume, but I highlighted my skills in web-development as well as what I've done in the past 2+ years. Yet, that still is not enough.

Or even this:

This is a junior data scientist co-op job, and needs 1 co-op under their belt. I look at jobs like this and just get demoralized.

At this point, I don't even know what to do. I'll more than likely have to exercise the exempt option to have this co-op not count towards graduation, but that just means that those that were quite literally lucky enough to get a co-op will be more valuable due to their experience as opposed to someone in my shoes.

More scary, however, is that I still am required to have at least 1 co-op under my belt. How is this even possible when most companies aren't willing to take a chance at people like us? All this does is push my graduation date further, and I'm not getting younger. I want experience, a chance to grow. Telescope was exactly that chance. Now, I want to know if anyone else out there in the world would be willing to do the same

by Abdulbasid Guled at Fri Apr 30 2021 23:25:57 GMT+0000 (Coordinated Universal Time)

Monday, April 26, 2021

Pedro Fonseca

Welcome to Telescope 2.0

Telescope 2.0

Telescope 2.0 release.

Telescope 1.5
Telescope 2.0

What Telescope 2.0 mean?

This means that we have taken a project and improved it until a point that wasn’t a question of when or what, but the project needed a new major version because the minor ones weren’t enough to reflect the project and our work.

All the journey until we reach this point was intense and challenging.

The team

Lead by David Humphrey, the team working on Telescope 2.0 was a mix of former students, current students from Seneca, and one developer from the open-source community.

In the beginning, as expected from a recently formed team, we had to figure out as we work on the tasks the best way of working together. I believe this could’ve been a little stressful for some of us because some of us were still trying to find where to work and how to do it. And I believe at that point; this could create a feeling of being floating in the space.

The work

Our first task was to port the old Telescope from Gatsby.js (Javascript) to Next.js (Typescript), and the second one was to create Microservices to Telescope.

I decided to re-design the Telescope front-end and create a new logo for us. The old design wasn’t good enough to fit all the potential features that will probably land in Telescope's future. I already had worked on the Telescope front-end, so I knew the code and the design very well — and where to improve it. I might not be the perfect fit for designing Telescope since I’m not a designer, but I did my best.

One of the good parts of the designing process was receiving good feedback from the current team about the design and where to improve it.

So after David Humphrey approved my idea, the team had two tasks: Microservices and Front-end.

Some of us worked on both tasks. I only worked on the front-end.

UI and UX

To design the front-end, I had to study a little bit of UI/UX in the go, which caused some changes in the first sketches, but assuming that we were all living through a process where we need to deliver tasks while we were thinking about what we were doing, I would say that it was expected.

By learning a little bit of UI and UX, I could improve Telescope and understand how important a good UI is for a project. Because if you can deliver a good UX, the users will want to stay on your website, and the developers will feel more confident to work on the front-end code.


It was a big challenge delivering a new version every 15 days that should look good and work. That’s is where I think we touch the question where we need to look to Telescope as a product. Even if the users don’t use the entire product, they need to see the entire product to use it. So I’ve learned a lot regarding this matter.


First, I need to thanks David Humphrey for making all of this possible, for teaching us the way you do and for being on our side even when we make mistakes. Thank you so much.

The Telescope project is way more mature now, and so we are too.

It’s not about how many lines you wrote or how many commits you have done. Everyone here has a different life and a different work and study load. What matters is simple: did you tried your best? If you gave 100% that you could give to the project, I really need to thank you.

We made it as a team, and I wish we could celebrate it live, in person.

We have been learning, improving our skills while working on it, and we didn’t stop even now that we already made the release. We need a break to catch our breath and then start again.

I wish you all the best.

See you soon.


by Pedro Fonseca at Mon Apr 26 2021 12:06:18 GMT+0000 (Coordinated Universal Time)

Sunday, April 25, 2021

Royce Ayroso-Ong

My Open-Source Journey

Telescope 2.0 marks the end or the beginning?

Photo by Dino Reichmuth on Unsplash

In the least cheesiest way possible, I am so grateful I took this course — it really opened my eyes as to how large projects are developed and maintained.

Telescope 2.0 has finally released, and to everyone who threw me a bone, reviewed my PRs, and helped me out when I desperately needed it, I just want to say thank you.

Taking a Look Back at Where I Started

If you told me to write a simple front-end React website 4 months ago, I would’ve hesitated to deliver. I’ve taken 3 web courses and all the different lessons are still floating around in my head with no solid place to live yet; CSS properties, the numerous packages, the different JS frameworks and syntaxes to remember — all somewhere in there looking for a place to settle down. Needless to say, web development was never my strong suit and I wasn’t too keen on diving into all the nuances that go into a full-stack website. So when I first started this course — DPS911 — I was really debating on whether or not I should stick with it. But you know what? I’m glad I did, because through my small contributions to Telescope I’ve gained confidence in my abilities to create a high-quality front-end website, made in whatever JS framework you throw at me. To go from avoiding web development to embracing it (possibly even favouring it?) is something that can only be done through such a wonderful course. By giving us students a real-world taste as to how things are done in the actual field, we can start learning how to deal with and handle the challenges that may find us when they find us.

Necessary things like growing thick skin when your code is picked apart and reviewed, owning up to your mistakes and responsibilities, taking initiative and leading team meetings, figuring out and researching solutions to unknown problems, and confidently asking for help when you need it — all of these I learned working as part of Telescope’s dev team.

Final Thoughts and Future Plans

I would be lying if I said I wasn’t bummed to say goodbye to everyone in our last Telescope meeting since everybody I worked with was always eager to help me with my issues. I have one more pro-option and I’ve heard that there may be a DevOps-inspired course coming my way, and if it does I think I am ready to dive into unknown waters, maybe even see a few familiar faces once again.

by Royce Ayroso-Ong at Sun Apr 25 2021 00:58:43 GMT+0000 (Coordinated Universal Time)

Saturday, April 24, 2021

Yuan-Hsi Lee

My last telescope post as a student (hopefully)

This week, I still work with user accessibility. The footer has 2 corners that didn't meet the AA/AAA level of WCAG, contributor card, search result message, and slack icon. I want to talk about the slack icon one.

The slack icon we had was a svg file included in the project. We implemented it as a like this,

<span"logo" height="20" width="20" />

What I needed to do is to change the color filling of this icon. This can be done by changing the fill value of svg element. The solution I wanted to try is to make this svg file as a react component so that I can configure the fill value. However, I wasn't able to import the svg file in typescript. I ended up using the easier way which is using react-icon and find the similar slack icon so that the filling color can be configured. I'd love to try more with the making svg a react component next time with SVGR.

It's been 4 months working with telescope team, and I'm very grateful with the chance of working with a group of amazing people.

Thanks to Dave for the astonishing lectures and leading, I'm so lucky to have your courses and to learn from you in my last year of college. Working in web development is totally unexpected to me, but you're one of the people who make me enjoy this field more than yesterday.

Thanks to Anton who helped me with git and your blog posts are always informative! Thanks to Chris, Royce, Abdul, Ilya, Tony, Huy, and Mo. It's a bit of overwhelming to work with a team that all people are more experienced and smarter than me, but it is lucky that I get to learn from you.

Thanks to Pedro, you're the first person who talked to me in the team and have always been supportive and kind to me!

I'm not good at saying good-bye, so I'm no gonna. But I want to tell everyone in the project that I truly appreciate everything you've done. It was amazing working with you all, wish you all the best :) ū-iân tsài siong-huē! (Meaning: We'll meet up again when the timing is right.) (This is Taiwanese, my mother language)

by Yuan-Hsi Lee at Sat Apr 24 2021 04:46:32 GMT+0000 (Coordinated Universal Time)

Abdulbasid Guled

A perspective overview on my open-source journey. DPS911 Blog #14: Telescope 2.0 release

Where do I even begin?

Well, this has been a crazy ride the last 8 months. Today, we successfully shipped Telescope 2.0. It's rather bittersweet. Nothing too exciting really happened, and I think I liked it better that way than how many of our releases went, with many PRs going up last second. Looking back, it's been an up and down ride with many positives outweighing the negatives.

First of all, I need to thank the people I worked with during this whole saga. I'll list them in no apparent order:

  • Mo. I wouldn't be taking this course, or the predecessor, DPS909, if not for him. I didn't even know about our professor, David, at the time, but the way he was talking about him and just seeing how enthusiastic he was a year ago in our 3rd semester made me really curious. It would just be alot of positive stories and that made me really excited. Thanks so much, man! You've made working on backend/microservice related issues and Satellite a blast to work with.
  • Chris. You had some of the most quirkiest blogs I've ever read. Your user service was also one of the more annoying things I've had the unwanted pleasure of reviewing. I don't regret one bit of it. You've been a joy to be around, and my only regret is that our open source journey was not in-person. That said, that didn't stop you from helping me out time and time again. I appreciate that, and best of luck now that you're done CPA!
  • Anton and Ilya. You both have pretty much been my senpai this semester, since you both are a year ahead of me in the same program. I've always enjoyed asking you about how the program was for you, and that has smoothly transitioned into our work on both Telescope, and the Linux system development pro option we all ended up taking together. While you both may be graduating soon, I hope that what we've done together this semester will always stay with you both. I know I will for sure.
  • Yuan and Royce. Thank you for allowing me to not focus so hard on accessibility with the front-end. I always loved reviewing your PRs, even if I was never originally pinged to do so. I know my search context helped you in particular, Royce, so I appreciate the shout-out! I know who to call if I ever need help with accessibility and color related issues in the future.
  • Tony. Your work in the PWA PR and Feed-Discovery service was awe-inspiring. Even more important, your work in figuring out what components needed to be ported over with your list at the beginning of the semester was vital to us being able to switch to NextJS as quickly as we did. I only wished you weren't in your co-op so you could've been more active in our triage meetings. Stay strong, friend! You got a bright future ahead.
  • Pedro, Duc, and Minh. Thank you all for allowing me to stay away from the 2.0 design! CSS has always been my weakest area and the work you all have put into it has been magnificent. Reviewing the SignUp PR was just about the most I've done for you all, but that was always good enough for me! You all gotta show me Adobe Illustrator though, that software is a thing of beauty.
  • Josue. You caught alot of mistakes that I've made in many of my PRs. Most of all, that extra nudge you gave was the kind of support I really needed when going into more of the DevOps side of things. It's been a pleasure both learning and seeing you work your magic. Hopefully, we can continue working together in CDOT, assuming you convince Chris Tyler to give me an offer. :D
  • David. Your wisdom is something I will never, truly, forget. I can't begin to imagine how hard it must been when you're a professor and you're expected to know the answers to stuff you barely know of, and yet, you always seem to find a way to make things work. Whether intentional or not, you've been great technical and emotional support at times when I've needed them most. It's been an honour being your student the last 8 months, and it's an experience I will keep with me well until my career in the not so distant future.

There have been many others that have come and gone in my open source journey. Many of my colleagues that took DPS909 in the Fall did not take DPS911 this semester. Royce and Mo were the only ones I were familiar with heading in. That didn't stop me from being me, very hyper and active in both slack and github.

With that emotional piece outta the way, I'll discuss about what I did this week.

I landed 3 PRs this week. All 3 can be found below:

Not much work this week, but each of these PRs held some sort of importance to me, since 2 of them were updates/audits and the first one was a critical bug fix for our front-end.

In terms of what I reviewed this week, Chris's PR that I mentioned last week to fix the user e2e tests was one. Royce had a PR that I reviewed this week, you can find it here. Other than that, not much reviews from me. I did do an extensive review of Minh's Search related PRs to address advanced search features, but those did not land in time for 2.0. I blame my lack of reviews this week on final exam week, but w/e. What's done is done!

Open-Source has really been a fun adventure for me to really dig into. When I first enrolled in the Fall, I wasn't really sure about it, only that it allowed me to practice with other languages I never got to use since my program always loved C++. It's really been more than just languages, but the tools and skills you learn and use. It's stuff that sticks with you forever. For example, CI/CD pipelines were one area that I really fell in love with and was always fascinated with. Unit testing was a pain that I had to learn eventually, and it gave me alot of trouble. It's a skill that is invaluable though. With the recent Rogers shutdown due to a software update, it seems very clear that both tests and CI/CD are very important and should be a stable in software development.

It wasn't without it's bumps, however. My ending with hacktoberfest was very lackluster, and my release 0.3 was about as terrible as can be. With all this in mind, I managed to bounce back each time. Even as recently as the regression I introduced to the search feature, I found the bug fix and made a PR that fixed it in no time. It won't always be this quick, but I believe it's important for people to make mistakes, even big ones sometimes, because we never grow from them. This is an industry that evolves rapidly, and no one is ever perfect. Each time I was down, I got back up, and it showed in my work this semester.

When I started DPS911, I wanted to make it very clear that I would be willing to work on all aspects of telescope. I went hard with the typescript port, and even updated our front-end docs to make them more universal than they were before. I signed up early for the microservices, because I knew that having the skillset with the technology stack used would be vital to growing in this industry. It wasn't easy, but nothing is when trying out something new. When my posts service finally launched in staging and production, it was an amazing feat to see. Full-stack was always an area I enjoyed, because I wasn't ever restricted with where I worked. Being flexible is also important in this industry since you can move from one team to another and not lose track of standards used. This showed in the work I've done; I've worked on the front-end, back-end, DevOps related stuff, and Satellite. I'm proud of all the work I've done in each area, big or small, and I hope everyone else is too!

Most important of all, the connections I've made here and in the broader community is something I'll never forget. It's really made me interested in starting a project and making it open-sourced. If I don't get a co-op this summer, we are allowed to exempt 1 from our graduation requirements. I think I'll use that time to dig in and start something like this. It would certainly be interesting to see how far it goes.

It's funny when you think about it. My first contributions to Telescope was an update to our environment documentation, and my PR to audit the backend and microservices is also the final PR before Telescope 2.0. To see the growth I've made in front of me is really inspiring.

With all this in mind, I wanna thank you, the reader, for keeping up with my weekly posts. I know I lack any sort of images at times, but I believe that words are the best way for me to convey how I'm feeling at a specific point in time. Where do I go from here? Well, I'm still trying to get a co-op, but this summer will be my first free summer in 3 years. I started BSD in Winter 2019 so that meant that I had to go to school in the summer while those that started in the Fall 2018 semester got a summer off. It's certainly a time to reflect, but a time to relax and enjoy myself for sure. I got lots of stuff I wanna do this summer.

That just about concludes my journey in Seneca's open-source professional options courses. It's not the end of my open-source journey. I wanna continue contributing to Telescope in any way if possible and I'll make my intentions clear. With my lighter course load in my final year of school, helping Telescope go beyond where it's at will be something I look forward to doing, hopefully if given the opportunity. Spreading what I learned with those that take over Telescope after our group will be something alright.

Thank you to probably the most resilient group we've had, doing this course in the middle of a global pandemic. It was never going to be easy, but it was well worth it. Until next time, stay safe everyone!

by Abdulbasid Guled at Sat Apr 24 2021 02:01:54 GMT+0000 (Coordinated Universal Time)

Anton Biriukov

Telescope 2.0

It has not been easy, but we did it — Telescope 2.0 is up and running! In this article I want to discuss the struggles that I went through in the last few weeks prior to the release and, of course, congratulate everyone on the team on successful delivery of the new major version.

Photo by Maria Lupan on Unsplash

Snapshot Testing

Snapshots serve as an effective way of determining any changes to the rendered version of components in the system. There is a number of testing libraries available out there which provide snapshot testing functionality. In our case, I have tried to set everything up with React Test Renderer — an official testing library shipped by the React team. And it seemed to be working just fine, until it didn’t…It has come to my surprise that rendering snapshot tests which would take the styling of the react elements into account would be that complicated, and all thanks to Material UI. I have tried numerous ways to find a workaround it and even ended up switching the library, yet it didn’t help (yet). In the end, I have been able to implement a couple of snapshot tests with React Testing Library, which seemed to offer a more extensive functionality along with an active community of contributors. There is obviously a big room for improvements, but I think it is a good start. In the end of the day, we have already caught one change that Yuan was working in — the logo optimization, which is what the purpose of having these snapshot tests is. The more we build on it and the better coverage we achieve, the easier it would become for us to catch any unexpected changes in the UI.

PWA, Microservices, Accessibility and More

It has been very pleasing to finally be able to download Telescope on my iPhone, with proper logo and mobile-friendly UI. Even though Apple is tight on providing more extensive support for PWAs, it is definitely a very useful technology and I hope Telescope will move into this direction more in the future. Credits to Tony for numerous testing sessions and improvements on the PWA support for Telescope and to Pedro for following best UX practices. Even though I have not been heavily involved into the microservices work, it has been impressive to see the entire transition happening in a matter of couple of months. With the transition to the new UI we have also managed to make a good progress on the accessibility standards of the application.

Great job, team!

by Anton Biriukov at Sat Apr 24 2021 01:36:03 GMT+0000 (Coordinated Universal Time)

Chris Pinkney

Curiosity, one of the most genuine of emotions

​ Today marks the final day of my OSD700 experience. I can't believe it's already over, it feels like just yesterday when I was mashing my refresh button to ensure that I was one of the lucky few to get accepted into OSD600. Most of my friends weren't as lucky. Some may say it's through the power of fate, though personally I say it's through the power of fibre optic internet.

Chris, shortly after getting into OSD600

One of the things I've found myself ruminating on lately is just how much I've learned these past 8 months. Several questions have come up from friends asking me for advice, most of the time I the answer, or can at least yield some sort of guiding intuition. This intuition was solely gained from my time spent in these courses. I've found similar behaviour in some stackoverflow/reddit questions.

I've made friends too. I've had great experiences working with everyone in the project: from spending late nights working with Josue, to laughing at nonsense with Anton, Abdul, or Ilya, or talking about the benefits of coconut water with Tony, everyone has been a real joy to work with and get to know. I'm really going to miss everyone. My biggest regret is simply that this course couldn't have happened in person, I want my Telescope 2.0 pizza party damn it. Guess I'll just order a party size pizza anyway and send the bill to Dave.

Chris, shortly after finishing OSD700 (kidding of course)

Moreover, today also marks my final day as a Seneca student! My time at Seneca hasn't always been as wonderful as these two courses have been, in fact it's been mostly the opposite. I never considered dropping out or changing programs though, just that perseverance can often be a challenging endeavour in and of its own right. Although, OSD really turned things around for me. I always looked towards the lectures and to the weekly labs and assignments with an excited fervour. These courses ended up being so important to me whereas I would nearly say your time in CPA/CPD is wasted by not having the privilege of taking these courses.

But enough fluff from me. Let's discuss what went on this week with me.

The Maintainer

​ Sunday! I finally re-approved Tony's PWA PR after we got the final go-ahead approval from Dave. Interestingly, Tony reached out to the PWA's library creator to talk about how updates work when we deploy new code. The creator responded saying the PWA is updated! Because of this the PWA was given the go ahead.

I manually tested an update to a dependency with Doc Josue. We found both instances where the library was used and forced them to perform, like lions, tigers, and bears at a circus. Oh my. Always get excellent guidance from our resident Doc.

I also reviewed Abdul's PR which adds a health check to the posts service. Short, simple, to the point. My favourite type of PR to review.

​ Monday, bloody Monday. Off to a poor start apparently! I raised an issue but Josue told me that Abdul had beaten me to it. A funny coincidence, as Abdul had pointed out an issue with the users microservice, and was kind enough to throw a ticket up about it.

I also raised another issue to change the Users Microservice port to something that is unrestricted.

​ T-T-Tuesday. Approved a PR from Yuan which changed something that was bothering me since I created the about page using MDX. I also had the privilege of leading the final triage meeting, which was kind of sad for me. I always enjoyed leading the discussion, even if people were half asleep. I also "helped" by adding screenshot confirmations a few times in both Slack and GitHub to demo the Users Microservice being used live for the first time!

​ Thursday. Start off by approving Yuan's new slack icon fix. She brought in react-icons, a library I've used several times before and really enjoy. I also approved a neat addition to satellite which adds the ability to cleanly shutdown a satellite-based service. I also approved another one of Yuan's PRs which updates our dark mode palette. It removes a lot of magic strings we relied on in a few places and properly adds them to the MUI theme file.

​ Friday! A very sad day as it's our last release day, and the last day of class. I started it off by approving Anton's attempt to speed up CI which unfortunately doesn't seem to make a huge difference, though a lot of larger companies employ such techniques regardless. I then went onto approve Dave's PR which removes tests running prior to shipping a release. He also had an excellent write up to fully explain the process of this.

I then had a short meeting with Abdul to audit the use of createError in the Users Microservice. We came to the conclusion that it was fine as it was. I later approved his PR. Looks like Abdul has the honour of shipping the last piece of code to Telescope before 2.0 landed. Kudos!

​ And that was it. I had figured that this last Friday would have been more chaotic, instead it was more neutral. I won't complain about getting some more time to work on my blog post though!

The Microservice

​ Josue and I started the week off by working on converting the unit tests for the Users Microservice to proper e2e tests. We both got stuck about half way through when several responses seemingly stopped cooperating and refused to properly return what we were requesting. I started working on it the next day and found where the stumbling occurred, we either weren't parsing the JSON via await response.json() or weren't converting the response text via await response.text(). Silly little mistakes that we got eventually. With those out of the way we continued on our way and eventually had a lot of great tests written. Josue helped me out a lot with some really neat promise tricks, an area where I still struggle a lot. On another note, I ended up ripping out a lot of the code that checked for hardcoded error messages. More sage wisdom provided to me, as error messages generated by our dependencies may randomly change, leading to failing tests. I also got a little lesson from Sage Dave on the proper use the fat-arrow in JS, or rather how to clearly return a promise. I have a bad habit of saving the response to a variable, only to later return it without performing any logic. An unnecessary task which I changed in the final PR. We finally landed our updated tests on Tuesday.

​ From here we transitioned to attempting to implement a health check API for Firestore, both the production version and the emulated version. Both of us spent about an hour trying to research potential solutions to this, but at the current time it doesn't seem like this is possible. I even asked a (my first, actually) question on stackoverflow regarding this and was met with neutral responses. I updated the ticket regarding this issue and we moved onto something else.

​ Finally, we followed this up by trying to work on how a user becomes an admin in the users microservice:

  • We tried to post & put a user with a Telescope user token (via Postman) and were denied.
  • We tried to post & put a user with a Telescope admin token and were granted access.

Given the following, we both came to the conclusion that this work was already done for us. During our final meeting, both of us spoke to Dave about how exactly we're going to limit a user becoming an admin. We received some advice on how to proceed further, which was essentially 'lock down everything', something that I look forward to implementing with Josue. We'll give it another shot ASAP.

​ In the mean time, we decided to work on replacing the feed parser, which is currently being deprecated but used in a few places in our backend. We started out by curling the feed parser wiki, editing it to only have 3 blog urls (one atom, one rss, and one xml), and running our own web server via npx http-server, so instead of having our backend parse several hundred blog feeds, we'll only parse 3 of the possible known types of blog feeds. A really amazing idea from Doc. We continued on by doing some research into promise-based feed parsing libraries, which was eventually concluded with Doc suggesting that we replace feedparser-promised with rss-parser. From here it's just a matter of manipulating the shape of the data that we feed the new library we're transition too. We called it quits from here, but we'll continue working on it ASAP. Although that about does it with my microservice contributions for the week, I'll try my best to not to make this the last time I work on the microservice.

​ I'm exceedingly thankful to be working with Josue. He has both taught me a lot, and shown me proper ways of doing all sorts of things with both programming and soft skills. He is an exceedingly talented programmer worth his weight in gold, and more. Both he and Dave are two people that I can only aspire to emulate, surely either of them have forgotten more than I know. I truly wish Josue only the best in his future endeavours and hope that we keep in touch.

The Finale

​ I'm not sure what else needs to be said, I'm only sure that there's things left unsaid (if that makes sense.) The feelings and experiences from OSD cannot be expressed in a single post. I think my experiences as a digital carpenter in this course can be expressed in the following: I learned how to navigate and contribute to a medium-sized project in 4-8 months, and you can too!

Some big moments for me are as follows:

What's next? Well, I'm not sure. I still haven't decided if I'm going to McMaster University to upgrade to a Bachelor's Degree, or if I'll simply seek a job. I do know one thing, I really need a better chair.

So it goes. See you later everyone, and thanks for all the fish.

by Chris Pinkney at Sat Apr 24 2021 00:56:08 GMT+0000 (Coordinated Universal Time)

Friday, April 23, 2021

Tony Vu

Taking new initiative in Open Source Development

Since OSD600, I have been thinking to transfer my Open Source knowledge to my fellow vietnamese developers at Seneca. There are a couple reasons why I think it could be a good idea. First, Not many people get the chance to take both OSD courses like I did because OSD600 is only offered in the Fall and you need it to enroll in OSD700. I also did not notice that many vietnamese developers in the class. I feel many of them missing out on two of the best (if not the best) courses at Seneca. Personally, I believe OSD600 has helped me get my coop this term by sharpening my technical skills and boosting my confidence. Hence, my first reason is to provide initial guidance to open source knowledge and practices to vietnamese developers at Seneca, so they have a better chance to get a job after graduation. My second reason is to help build a tech community for developers at Seneca through communicating and building things together. My personal experiences working on Open Source projects have been very positive. I realized the only way to be innovative and progressive is to be open and respectful. In OSD700, we have a small team with people who are from different backgrounds and have different thinking process, but we worked together very well to successfully deliver the next pack of Telescope’s features. Since we started, we have made a new contemporary UI with Material UI, made the app into microservices, and made it into a PWA. All of these topics are trending and knowing them while you are still in school would prove critical later on.

To start the initiative, I have already got a few of my friends on board who are willing to work on this project with me. The idea is to imitate the process that we have been doing in OSD classes. I would steal some of professor Dave’s approaches to help the participants begin their contributions asap. So what’s the project will be about? Honestly speaking, I am not too sure now and I think this would require more discussion among the team. However, the initial idea is to build a platform for developers at Seneca to share and learn from each other. I will be open to ideas and will try to sketch it out with the team so we will have a plan to follow.

Ideas would not realize if you did not act on them. And I believe the right time to do it is now.

Thank you for reading.

Tony Vu

by Tony Vu at Fri Apr 23 2021 17:54:36 GMT+0000 (Coordinated Universal Time)

Hi Dependabot! I am Tonybot…

As I am still waiting for reviews on my PWA’s PR, I decided to take on an issue in an area that I have never touched. After looking at the list of current issues, I assigned myself to an issue helping to add more packages files to Dependabot config. I have seen Anton and Yuan actively working on this matter for a few weeks and been curious to know what it is. From my rough understand, Dependabot is a github bot that helps to identify outdated packages and update them to the latest version. It seems like a cool thing to have.

I looked at the requirement and reached out to Anton for clarification. I learned that you need to follow a template that has already been developed. The template is in yml format and look similar to the following:

This determines configs for Dependabot to know what to do. For example, in the above example, we would want Dependabot to check the package.json in /src/api/parser (aka parser service) every Tuesday at 5pm EST. It would be limited to 1 PR and the commit prefix will have the 'chore: pattern. The PR created by Dependabot would be reviewed by telescope maintainers, so the contributors cannot review it. I have no problem understanding the syntax as I have been familiar myself with Docker and yml is the main language of Docker files. I also did the same thing for the docker dependencies. Initially I did not understand how we check the dependencies in a docker image, and professor Dave has explained to me that it might be able to find out some update in dependencies that somehow the image did not update. The code is exactly the same except the first line. Instead of npm , it is docker

It was a small PR but I learned more about how Dependabot works. It is convenient that Github invented this so the repo can stay updated to the latest updates.

Thank you for reading.

Tony Vu.

by Tony Vu at Fri Apr 23 2021 14:15:57 GMT+0000 (Coordinated Universal Time)

David Humphrey

Telescope 2.0

In a few hours I'll be meeting with the team to ship another major release (2.0) of the Telescope project.  It's been a lot of work, full of late night debugging sessions over Slack and Teams, major successes as we've landed big features, and plenty of disappointments as we've experimented and refactored code.

Before we do this final release, I wanted to take a few minutes to look back over a year of development, and specifically at what we accomplished in Telescope during 2021.

I wrote in January about our plans to create a 2.0 release.  At the time I highlighted some of the areas I thought needed focus.  Today it's interesting to consider how we did on each of the various goals I had:

Goal Grade Notes
Migrate User data and Feed storage out of Redis and into a better database A- We have all the right pieces in place, largely thanks to the tireless work of @chrispinkney and @manekenpix, but there's still a bit more to do for it to be usable in production. I'm hopeful that a future dot release will sovle these.
Fix our Redis data corruption when we lose power on production D We researched, but never implemented a solution
Migrate away from the Wiki Feed List as the source of truth, and use the Feeds from the database C We have the beginnings of a parser microservice that works with the Users service, but it has no tests, and isn't production ready yet.
Modify our Authentication/Authorization system to allow token based authentication A We've shipped this now, and authentication/authorization works on staging, production, locally and in Vercel. We have a bit more work to do before it can be an A+, but it's basically done.
Figure out how to integrate user GitHub activity and contributions (PRs) B- We have the foundations for this to be an amazing part of Telescope 3.0, but the scope of it was too big for 2.0
Prototype having Twitch Streams, YouTube Live, and other "Telescope Podcast" experiences. I think this idea is great, but I'm still waiting to see if the students agree. Not everyone is comfortable to stream their work. Maybe we'll do it, maybe not. N/A We never looked into this. I don't think the group shared my interest in this feature, so I didn't push it. Maybe in 3.0?
Make the app installable as a Progressive Web App (PWA) on mobile A+ This was finally accomplished late in the 2.0 cycle thanks to the tireless work of @tonyvugithub
Improve the Admin dashboard(s) experience N/A We never started on this, and it's something we'll have to consider in 3.0
Better Admin tools for content (user, feed, post) management N/A Same issue.
Analytics D We did a bit of reserach and discussion on this, but never really got started on a solution. I think having the GitHub data will help make this a more compelling feature in 3.0
Build out our error/log reporting that we started with Kibana B+ We ended-up coming at this problem from a different direction, using Portainer. I think solving this in a later release, in combination with an enhanced Elasticsearch and Kibana analytics feature would be great
Improve UX for adding new feeds (e.g., automatic RSS feed discovery from blog URL) A+ We made a ton of progress here thanks in large part to the efforts of a small team of front-end wizards: @PedroFonsecaDEV, @DukeManh, and @Meneguini with back-end support from @tonyvugithub for feed discovery.
Improve accessibility A We spent quite a bit of time improving this, led mainly by @yuanLeeMidori
Improve developer experience A+ There was a tremendous amount of work done on DX, much of it thanks to @birtony, @HyperTHD, and @chrispinkney.
More and better automated tests A+ Our tests have never been better.
Improve docs B+ We didn't put as much effort into this as we could have collectively, but the work that was done was usually thanks to @yuanLeeMidori
Refactor and Simplify backend code. Split code into separate pieces and properly Dockerize: REST API, deployment server, feed processer, frontend A- We spent so much time on this, refactoring the backend monolith into nearly a dozen microservices. The work is nearly complete, but there is more we need to do. This wouldn't have happened without days of work by @HyperTHD, @chrispinkney, @tonyvugithub, @manekenpix, @raygervais, @c3h0, and @izhuravlev.
Continue building on the improvements we've started with Search (e.g., autocomplete for author names) B- Search is one of the areas that is so exciting about Telescope. Not only can we see what happened in the past few days, but also we can go back and search for things in the past. We spent quite a bit of time on search related UI updates, but there's still a lot left to do. Much of the improvements we do have are the work of @rjayroso, @izhuravlev and @huynguyez.
Swag? We have talked about having shirts, mugs, and stickers in the past, but it hasn't happened yet. Maybe for the 2.0? C We've had a hard time executing on this for two years. I think a lot of people want to see it happen, but it's very different work from developing the project. @izhuravlev has shouldered the bulk of this work.

Those were my goals in January, but lots of things changed.  Software development requires you to adjust schedules and feature lists to accommodate the realities of implementation.  As a result, our 2.0 is full of many things I didn't anticipate, which is great: it means we found ways to incorporate the interests of the team as a whole.

I spent some time today reading through the PRs we merged in 2021, and took notes on the major areas of interest and emphasis I saw.  Here's some of what I saw:

  • Snapshot, end-to-end, and unit testing
  • Continuous Integration (CI) and Continuous Deployment (CD)
  • SEO
  • Firebase
  • SAML based Authentication, JWT Authorization, and user Sign-up Flows
  • Security
  • UI Design
  • Logo, CSS, and Theming
  • Improved Accessibility and User Experience
  • Microservices
  • Elasticsearch
  • Redis
  • Full port of front-end from GatsbyJS to next.js
  • TypeScript rewrite
  • Dependency Updates and Maintenance, both manual and automated (Dependabot)
  • Paying off Technical Debt
  • Progressive Web App (PWA) and Mobile UI Support
  • Docker
  • Automation and Tooling fixes, updates, and improvements
  • React
  • nginx, Traefik, and routing, caching, certificate management
  • Documentation
  • Improved Developer Experience, including fixes for cross-platform differences
  • Bug fixes

I also dug into our community and project stats a bit:

  • 167 contributors, including students in the course, other current Seneca students not taking the course, and also some talented alumni and external contributors.  80 developers have added new code in the past year.  Our top contributors list has been updated with both new and familiar faces: @manekenpix, @c3ho, @PedroFonsecaDEV, @cindyledev, @HyperTHD, @birtony, and @tonyvugithub (not to mention Dependabot).
  • This community has done a lot of work together.  Since the start of this year: 225 Issues were created and 301 closed by over 400 Pull Requests.
  • During Telescope's history, 97K lines of code were added and 66K lines removed across 1K files, with 50% of that work happening in the last year.
  • As we ship 2.0, there are 20K lines of code, with the majority in JavaScript (67%) and TypeScript (25%).

In addition to these code and community metrics, Josue and I also looked at the state of the data in Telescope, and it's impressive to consider as well:

  • Over 700 people have written open source blogs that we've indexed.  The number is probably closer to 1,000 if we include blogs that no longer work (e.g., have been removed after a decade).
  • We currently have more than 6,000 individual posts indexed.  I don't have the total word count, but I'd love to know what it is.  It's crazy how much we've written about our experiences being involved in open source.  It's also incredible to consider that RSS feeds usually don't include everything by an author (only the most recent work) so the total number of posts we've had is larger still.
  • Our oldest indexed post is from October 2006 by Ben Hearsum.  Fifteen years!  I had a great conversation with Ben on Twitter this week about his post, and was struck by how valuable the open source student experience really is: Ben turned his open source course work and passion into a successful 14 year career as a Release Engineer with the Mozilla Corporation.  I updated Firefox to version 88.0 today using code that he wrote. I couldn't be more proud of him and his work, and I'm still just as excited about helping our students achieve these outcomes using open source contribution.
  • Our youngest post, at the time of writing, is by Tony Vu, and shows a lot of the same spirit Ben had 15 years ago: "As I am still waiting for reviews on my PWA’s PR, I decided to take on  an issue in an area that I have never touched. After looking at the list  of current issues, I assigned myself to an issue helping to add more packages files to Dependabot config." Working on open source at Seneca means looking around for ways to contribute, jumping into new areas of code, working in community, and writing about our successes and failures.

Telescope 2.0 moves us even closer to having the platform I've always wanted: one that can help gather and reflect the collective efforts of the Seneca community as it works on open source.  We still have more to do, and I'm already thinking about the areas I want to work on in the spring and fall.  Until then, I'm looking forward to reading the blog posts of my current team as they wind down after their final release.  Congratulations to the team on what you've accomplished.

Let me end with a note of public thanks to Josue (@manekenpix) for his tremendous efforts supporting the team and Telescope this term.  Josue reviewed most of the PRs I made, for which I'm extremely grateful, spent hundreds of hours mentoring the current students debug and write fixes, attended meetings, and was always on-call to support our deployments.  There would be no Telescope 2.0 without Josue, and I'm extremely grateful for his generosity and commitment.

by David Humphrey at Fri Apr 23 2021 16:24:52 GMT+0000 (Coordinated Universal Time)

Thursday, April 22, 2021

Calvin Ho


 Recently I've been working with a fork of the Open edx platform ( My coworker and I were tasked with changing the built in player which accepts a mp4 link (youtube or s3), into one that allows users to upload a file to the platform that to be indexed into the user's s3 bucket and then update the player with the uploaded video. Sounds fun right? I assure you, it is not.

I have no idea how big the code base is. It is massive and contrary to the implementation docs, the development documentation are hugely outdated. After struggling with the code, my coworker and I were able to complete the clients request and implemented the customized workflow. 

Then came the next request, analytics: Which users of the platform completed which modules? How long did a user spend watching a video? How many users enrolled in a specific course this week? We proposed two solutions, one was a hugely outdated, but easy to implement analytics providing a high-level overview of users of the platform. Unfortunately the library wasn't updated to support the newest release of Open edX platform we were using (Koa.2) and worst of all, it didn't provide the granularity the client was asking for. 

Great. Second solution: Use Open edX's own data analytics solution, this alternative is infamous for clogging up the Open edX's forum with requests to help debug the installation/implementation of it (including yours truly) and forcing many people to instead use the first solution. Just check out how amazing this document is teaching you to implement this, enjoy the diagram. 

I finally found some extremely old documentation written by the chief architect of edX. Check out the documentation for it. This was created in 2015 and has been barely updated since, one of the steps even tells you to use a Hadoop 2.3 when the repo has already migrated to use Hadoop 2.7. Out of all the instructions, I can personally tell you I had an issue with literally every step that required me to hack at it, there is no FAQ and the slack channel + forums are so quiet, you'd be ecstatic to even get a response. If it is one thing OSD has taught me, it was to research and adapt and maybe there might be a light at the end of it all. Here's a list of topics I had to research about to almost finally get this working:

  • Hadoop
  • Hive
  • Ansible
  • Django
  • Tutor Open edX
  • Virtual env
  • AWS
  • MySQL
  • Oauth2
  • Luigi
All this because, documentation is not up to date. People who work on Telescope, be thankful the slack channel is extremely active and the documentation is up to date.

by Calvin Ho at Thu Apr 22 2021 01:45:48 GMT+0000 (Coordinated Universal Time)

Tuesday, April 20, 2021

Tony Vu

Telescope 2021 — A PWA

Telescope 2021 — A PWA

“it’s not real until it hits Telescope as a blog post about what happened” — professor Dave

Those were words from my respectful professor, the one and only Dave, who I admire a lot. He reminded me of why we start the practice of writing blogs. It is not only a way to record what happened, but also a way to evaluate on your mistakes and the thought process that you went through to make them. These help you to become a better developer.

Today, my PWA’s PR finally got merged. A few of us were quite excited about it including myself. As I mentioned in my previous blog post, I have reached out to the creator of next-pwa to learn if the service worker would update the cache when there was a newer version in prod. And he confirmed “YES”. This is the last piece of wonderings we have to ensure that when we merge it, it won’t create more bugs.

After a few reviews from Dave to help me refine my code better and remove any extra code, I merged the PR with a big relief. I was worried that it would not be able to be merged before v2.0. If you used Telescope’s dev link right now you can install it to your Android phones and PC using Chrome or “Add to Home Screen” on iOS. An app icon will appear on your home screen and you can access Telescope like how you would through the browser, but it feels like a native app. My PR might have added only 70ish line of codes but to come to this point, it required a lot of efforts from many people to have a good code structure and a friendly mobile design. I want to shout out to Telescope team for making the website well responsive on mobile so its PWA feels seamless. Without these efforts, this PR would not happen.

So why I believe PWA will eventually play a big part in the future of applications. First, PWAs are powerful, effective, fast and app-like. Second, it worked offline. Third, PWAs can help companies save resource by developing native apps for different platforms. Coming from a business background, I understand that for corporations, it is always about the bottom line. It is same as why full-stack developers are more demanded or why cross-platform techs like React Native and Flutter have been on the rise. Many websites you are using are PWAs including Twitter, Youtube and of course our beloved Telescope. With the new initiative letting you install a PWA on PC, My gut feeling is that there will be more to come.

My PWA’s exploration has not ended, I still have a few things to do and one of them is to register cache of the blog posts. However, that would be a topic for a future blog post. Now I’m going to use my installed PWA to check if this blog got updated to Telescope.

Thank you for reading.

Tony Vu.

by Tony Vu at Tue Apr 20 2021 00:00:23 GMT+0000 (Coordinated Universal Time)

Monday, April 19, 2021

Mohammed Ahmed

Looking back at my work

Working with Telescope and Satellite was probably one of the many opportunities that I’ve enjoyed. I started off as a newbie when it came to stuff like CORS, microservices, and npm entirely. I never knew how deep web development was until I started DPS911, and I’m incredibly grateful with the experiences that I’ve went through.

To be completely honest though, I don’t think I was the best. I haven’t pushed a bunch of PRs, I kept being slow with fixing the issues that I was assigned to, I spent too much time reading than coding, and in my opinion, I was quite disappointing. There’s no excuse. I’ve just been really bad.

Even after the course, I want to continue contributing to Telescope and Satellite, I really do. I loved learning new things, I loved debugging bugs, I learnt so much about how web backends work, and how they handle errors. I loved every part of Telescope. Everyone was super kind and awesome, and we all collectively contributed to something that will benefit other Seneca students in the future, and I genuinely want to continue with that.

I’ve learnt so much about Open Source that I want to bring my own project onto CDOT sometime, the community here is possibly one of the best qualities that we have, but not many people know about it, and it’s a shame. Our Open Source community brings you up, both as a person, and also as a developer; you start to get confidence in your code, and your contributions. The culture here is amazing; you don’t know something? Don’t worry, we’ll help you out and teach you how x, y, and z works. Need help debugging? Don’t worry! We’ll hop on and learn what’s going on. People are willing to jump in and help when necessary, not cause of ego, but for the good of the project and our community, and that’s amazing.

For any person who’s contemplating taking the Open Source courses (both 909 and 911), please, go for it. This is a course that is the needle in the hay-stack, and I don’t regret it one bit. It’s a shame that Seneca doesn’t advertise CDOT a lot more, because I’d argue that it’s the best part of Seneca in general.

I don’t want to end off at a bad note. I want to continue to work on Telescope, along with my own projects. I want to contribute not for the clout, but to genuinely help people fix any issues that they encounter. I want to contribute to create a tool that users will use. I want to be in Open Source.

But I have to be honest. I was very disappointing.

by Mohammed Ahmed at Mon Apr 19 2021 17:10:50 GMT+0000 (Coordinated Universal Time)

Abdulbasid Guled

DPS911 Blog #13: One more step until the finish line

And another late post. In my defense, I was still recovering from my covid-19 vaccine this weekend and work/ramadan got me really occupied.

Not much longer left to go for me. This upcoming week will be my final week in Seneca's open source courses. It was a crazy ride, from good, to bad, then to really, really good. It's been a hell of a journey. I'll reflect on this more in the final write up, so stay tuned for that.

This week, I worked on porting our ElasticSearch client to Satellite. That one was more of a pain in the ass than I thought it would be, mainly because it wasn't starting. Also, intellisense wasn't as strong as it was with Redis, so I had to turn to documentation alot, both for regular and the mock versions of ELS.
You can find my PR for that, here.

I also worked on updating our posts service to use Redis from Satellite, and audit the posts service to use the createError() function which once again, also came from Satellite. You can find that PR here.

I have alot more long-term issues still assigned to me, that I would love to continue working on if given the chance. I really loved working on Telescope throughout the past 4 months, and getting a chance to continue working on this would be great for myself. Most likely though, I'll end up dropping them.

There's an interesting post to update the hero banner to use quotes from former open source students about their journey in open-source. It's this issue here. I kinda wanna take this on, because I think it'll be a fun way to end my journey. Also, I wanna add a quote of my own here so yeah, we'll see where that goes.

Otherwise, the rest of my work will come in the form of audits, both in the microservices, and the backend. The parser service is not ready to be served yet, so the backend code will more than likely have to stay for the time being. I got some audits I wanna do there. Good for me, since this week is final exam week. No big issues for me.

As for what I reviewed this past week, I got some worth mentioning:

My professor, David, once again ended up bearing the bulk of PRs that I reviewed this week. Maybe I'm trying too hard for those brownie points and marks. :D

Next time, self-reflection. I did open-source for 8 months now. My final blog post of the semester will probably be one of my longest ones yet. The past, the present, and the future all in one. Be prepared for a long read. In the meantime, this video is basically how I'm feeling right now approaching this final week.

PS: I got my covid-19 moderna vaccine on Thursday, so I now got a bit of protection against this deadly virus. I really want this lockdown to go away so that I can enjoy life again. I've been cooped up in this home for way too long.

PS PS: My professor's good friend, Chris Tyler, recently put up a job posting for CDOT researchers. Being in my 6th semester of BSD, and needing a coop job for the summer, I applied straight up. David, I know you're going to be reading this. Please give me a great reference, this CDOT job would be an absolute dream for me to continue doing open-source work and gain even more valuable work experience in software development.

by Abdulbasid Guled at Mon Apr 19 2021 02:15:18 GMT+0000 (Coordinated Universal Time)

Sunday, April 18, 2021

Yuan-Hsi Lee

Keep working on accessibility

Keep working with user accessibility this week. A simple change on our search help, the old font color is hard to read with the background color. I also make the title of the search help bolder and have some padding to make it more like a title.

Meanwhile, Royce is working with improve search help logic. The search help was only appeared before the user search anything. However, when the user can't find any result after the searching, it is possible that she could use some search help to get the wanted searching result. I believe this change of search help makes more sense and can be more helpful for the user.

When I was testing this PR, I found another issue related to user accessibility. (I thought I've been checking all corners already) There is a line of message telling the user "No results found" or "No more posts". This line of message in the search page has black color in both light and dark mode. Therefore, this line can't be seen in dark mode.

The issues that I've been working but not able to finish is to improve contrast ratio of slack icon. This slack icon is a svg file that we include in our repo. The color is white, and I'm not able to convert or fill in a darker color into it. This is my first time working with svg, the team gave me some suggestions in the weekly meeting, I will try to find out a fine solution to it!

by Yuan-Hsi Lee at Sun Apr 18 2021 19:00:46 GMT+0000 (Coordinated Universal Time)

Saturday, April 17, 2021

Royce Ayroso-Ong

Returning to Where It All Began

Status report: working again on the Search page

Photo by Sylwia Bartyzel on Unsplash

Before I begin, I’d like to make a shout-out to Abdul (@HyperTHD) for working on this PR right here. By creating a SearchContext, passing props and hooks across SearchPage’s many components have never been so easy.

I actually held off on doing this PR because I was unsure of how to go about it. The way I did the initial SearchHelp logic was that if the user clicked the search button it will trigger the onSubmit() hook, which is where I also called my function to hide the SearchHelp component. Thus, every time the user searched for something it would hide the SearchHelp. This worked sort of well, but what happens if the user searches for something and no results pop up? Maybe they mishandled their search and they don’t know where they went wrong. Or perhaps after a long session of searching, the user may have forgotten the nuances of the search syntax and needs a reminder. Both of these scenarios show that the SearchHelp component needs to be visible when an invalid or empty search is called. The main problem was that the hook that I created to handle the visibility of the SearchHelp was in the SearchProvider component but the logic for handling invalid searches was found in the SearchResults component. I was unfamiliar with React hooks to begin with, and now I needed to somehow pass the state and the hook for the SearchHelp through layers of component parameters. This is where Abdul’s SearchContext comes in handy — instead of passing multiple pieces of data as props through a variety of different components, you can simply import the pieces of data via the SearchContext right in the file where it needs to be used. Thanks to him I was able to focus more on how the logic would behave rather than fighting the layers of component structure and dependencies.

Other than that, I’ve almost got this PR ready to merge, just a couple more adjustments to satisfy the design community within Telescope and I’ll be set. Getting these two pull requests merged will be my plan for the weekend, as well as getting more issues completed for accessibility-related stuff. Since we are nearing the release of Telescope 2.0, I need to get on the accessibility issues right away to be able to merge anything by the release date.

by Royce Ayroso-Ong at Sat Apr 17 2021 01:01:36 GMT+0000 (Coordinated Universal Time)

Chris Pinkney

Dawn of the Final Week (Again)

The Maintainer

​ Like most weeks we started with panic, but this time with a little extra gusto as it's finals week.

I started off the week by "reviewing" one of Dave's PRs. I say "reviewing" as the tests for the PR are currently not yet passing, as such I was left to only review the code posted and not test the PR locally. As always, the code seemed fine. I was really excited to see this PR as the users microservice is finally starting to seriously come together.

I also approved a quick-fix PR from Pedro for a clean $20, as it was discovered that our landing page didn't properly display viewport heights. My favourite kind of PRs are always the ones that are <= 10 SLOC.

Also approved a really interesting Docker related PR from Doc Josue! I had never thought about how containers and volumes dispose of unused elements until now. I guess I just magically assumed they would disappear when the container closes.

Reviewed some changes to the frontend made by Royce, I liked where it was heading, just not how the names were duplicated. We discussed it during our Friday meeting as well, and everyone seemed to share a general consensus about the duplicated names but also agreed that the line was an excellent touch.

I approved Tony's PWA PR again since we have a bunch of testing now. I think it's adequate, however, Dave has expressed reluctance to add it as we're currently unsure how the PWA will behave when we deploy an update to prod. Tony has since reached out to the maintainer of next-pwa for answer. As a result, I have removed my approval and apologized to Tony. Hopefully we'll get a reply soon and can get some answers so we can move forward with this. Still one of my favourite PRs.

I added my thoughts to a comment that Tony left on an issue suggesting a share icon feature addition to Telescope. Tony expressed hesitation about working on this feature, but I think working in open source forces collaboration, expression, critique, and commentary, and shared my opinion as such. I'm curious to see what we can do with this. A share button would be cool, especially if it copied the link URL to the clipboard, then a user can just ctrl-v to share it to someone. Might be a nice feature for new comers to the project to tackle!

I also reviewed Royce's new SearchHelp PR which changes how the helpful search instructions are displayed on our search page. I pointed out a bug (that may or may not be related to his PR). Lots of great frontend fixes lately from Royce!

Finally, in other humorous news, I left a really dumb review on something that is either not finished, failing CI, or both. Heh. I'll have to take another look at it when it's ready. GitHub is great but either I'm not great, or the UI is occasionally un-intuitive.

The Microservice

​ I started working on converting the unit tests inside the Users Microservice to proper e2e type tests tests two days ago but ran into a few snags. For the life of both Josue and I just could not get the microservice to respond properly:

// takes a user object, performs GET using the user's email
const getUser = async (user) => {
  const response = await fetch(`${USERS_URL}/${hash(}`, {
    headers: {
      Authorization: `bearer ${createServiceToken()}`,
      'Content-Type': 'application/json',

  return response;
const response = await getUser(allUsers[0]); <-- array of user objects

response.body simply refused to co-operate with us, and returned a bunch of crap that we didn't want. Give us the user, curse you! Curse you and all the halflings!

The solution ended up being const user = await response.json() which allowed us to parse the JSON returned and make assertions based on the user returned via the GETs body. I'm currently sitting at 6 tests rewritten out of the... who knows, 15 or so that I have to do? I'm hoping to have the rest of them done by Sunday.

With only 1 week left I made it a point to issue a call for a potential roadmap for the Users Microservice. We still have a lot of work to do, but fortunately there's a bunch of us working on this stuff and a few items won't take too long.

After these e2e tests go in to replace the current unit tests I'll be shifting gears to work on how users are declared administrators, followed up by some research, and concluded with adding some quotes. Then finishing up what isn't done by end of week!

In other more personal news:

  • My first final went okay I think... hopefully.
  • Think I might buy a cherry tree for my backyard garden this year. I have no idea how trees work or how to care for them so hopefully I learn a lot...
    • A society grows great when aged people plant trees in whose shade they know they shall never sit. 🌲
  • Continuing with my Rust fascination from the previous blog post, I stumbled upon a Rust cargo library which adds support for various microcontrollers. I have a Circuit Playground Express sitting in my basement. I bought it last year with the hopes of designing an automated garden watering system. Maybe I'll try it in Rust sometime!
  • I've always wanted to get involved in something impactful. I remember a website that I bookmarked for this just occasion! Maybe it will help you, dear reader, too.

by Chris Pinkney at Sat Apr 17 2021 01:00:48 GMT+0000 (Coordinated Universal Time)

Tuesday, April 13, 2021

Tony Vu

Second attempt in PWA — Success (Well kind of)

Second attempt in PWA — Success (Well kind of)

This is the second part of my previous blog on my journey to explore PWA. As some of you might have read the first episode, you have known that my first attempt to implement PWA to Telescope nothing more than a failure in my opinion. If you have not read the first part, you can read about it here.

After getting myself together, I was determined to find out a working solution to my PWA issue. I decided to dig deeper into the web and tried out every single solutions I could have found or thought of with the hope that one of them will work or at least function. From my memory, I kept pushing new commit every 10 minutes for 3 hours straight. The list of force-push commits kept getting longer and longer but none of them has worked yet. Here is how many times I attempted to solve it.

It’s long, isn’t it? I was very confident that I set up everything correctly. However, it only worked locally and still not work in production for some unknown reason. I did not really know how to debug the service worker as professor Dave has said once that it is really difficult to debug service worker. It seemed like the workbox file and service worker file were not working. I decided to go to next-pwa github to ask the creators/maintainers about my issue, then I noticed someone filed an issue that is very similar to my problem. There were quite a few people commented in the issue saying they have same error by different causes. One of the posts came from someone who has some information about why workbox(a dependency of next-pwa ) did not work probably.

A few days later the creator released a new version integrating the new workbox version.

I updated to v5.1.3, but still PWA could not be installed on prod. And I found out that some file in the public folder cannot be cached. I decided to make a comment asking about it.

The creator answered quickly after and suggested a solution to it.

Now everything just clicked to me why it was working on prod before but not now. This google file was added after I started working on this and hence affecting the result. I added what he suggested to my code and it worked like a champ. Maybe I should have figured it out earlier rather than spending too much time grinding…

It was frustrating experience but I felt I learned a lot about PWA out of it. I also learned that Apple is still behind in the PWA movement but they have been making efforts to integrate PWA into Safari, so I will be keeping track of updates because I believe PWA will be a common thing of the future web.

Thank you for reading.

Tony Vu.

by Tony Vu at Tue Apr 13 2021 15:44:40 GMT+0000 (Coordinated Universal Time)

Monday, April 12, 2021

Yuan-Hsi Lee

First Attempt at Intersection Observer

Thanks to Pedro, I learned a cool API this week and applied it in our favorite project telescope.

I was assigned an issue to accomplish the new banner design, which is to make the navbar appear only when the user scroll to the timeline. In other word, the navbar should not be showed in the banner, but, it should be showed when the first post is at the top of the screen.

To accomplish this feature, I need to track the element in the current screen. The API that Pedro introduced to me is Intersection Observer. The basic idea of this API is to observe the element in the viewport. The function isIntersecting() tells you if the element that you're observing is still in the viewport. It doesn't have to 100% in the screen or 100% out of the screen, the observed percentage can be configured as well.

Therefore, since our goal is to show the navbar when the user scrolls to the timeline, and the first post is at the top of the screen. In other word, the navbar should be showed when the banner is totally gone. We put the observer to our banner.

In this PR, I move into

, so that I can separate it from the . Moreover, to add props for and in order to share the result of intersection observer. After moving the position of navbar, I also need to add navbar to about page and search page, because all pages used to share the navbar when it was in the banner header. The other changes that needed to make is the CSS styling of navbar in about page. In about page, uses a certain color from our palettes. Once we move navbar to about page, the navbar will be applied with these color because navbar icons all have in their links. By adding another styling setting to , the color can be overridden. I'm still thinking if there is a better way to do so, since the original styling for navbar should not be overridden, and the solution should not be overridden to correct.

It was an amazing experience to work with something new. Thanks to Pedro and Dave's help and suggestion in this PR! The initial thought was actually using React context. However, it is too complicated to use, and since we only need to share the state with one component, we can do it without using context. But, I'm definitely gonna check out more practices of React context.

by Yuan-Hsi Lee at Mon Apr 12 2021 01:15:16 GMT+0000 (Coordinated Universal Time)

Saturday, April 10, 2021

David Humphrey

Shipping Telescope 1.9.5

Yesterday the team shipped Telescope 1.9.5, and brought us one step closer to our 2.0 goals.  I spent a lot of time mentoring, debugging, reviewing, and also writing code in this release, and wanted to write about a few aspects of what we did and how it went.

First, I was struck by the breadth and depth of things that we had to work on during this cycle.  I was talking with a friend at Apple recently, who was reflecting on how complex modern software stacks have become.  I've been programming for over 30 years, and he even longer, and neither of us has ever reached the promised future where a NEW! language, framework, tool, or approach suddenly tames the inherint complexities of distributed systems, conflicting platform decisions, or competing user expections.  Reading through this release's code changes, I wrote a list of some of the things I saw us doing:

  • Writing Dockerfiles
  • Dealing with differences between docker Environment Variables vs. Build Args
  • Babel configuration wrangling
  • Elasticsearch
  • Redis
  • Browser origin issues
  • Nginx proxies and caches
  • OpenID
  • Firebase and Firestore mocking in CI and development
  • Traefik service routing
  • Combining SAML Authentication with JWT Authorization
  • Using Portainer to administer containers
  • Writing good technical documentation
  • Dealing with different ways of running the same code: locally, CI, via Docker, production
  • Dealing with failed Unit tests due to timeouts in CI
  • Understanding mock network requests in tests
  • Dependency Updates, some with breaking APIs
  • Configuring tests to be re-run on file changes (watch)
  • Dealing with authenticated requests between microservices
  • Writing e2e tests using Playwright
  • Hashing functions
  • Different strategies for paging results in REST APIs
  • Role-based Authorization
  • HTML sanitization
  • REST API param validation
  • TypeScript
  • Vercel Environment Variables
  • Material UI
  • Implementing multi-step forms in React
  • User Sign-up Flows
  • Accessibility
  • Intersection Observer API
  • React Refs, Context, custom Hooks
  • Scroll Snap API
  • Polyfills
  • Updating and Removing legacy code
  • Mocking database tests
  • HTTP headers

This list is incomplete, but helps give a sense of why Telescope is so interesting to work on, and how valuable it is for the students, who are getting experience in dozens of different technologies, techniques, and software practices.  The funny thing is, If I presented a new course that covers all of these topics, I'd be shot down in a second.  I have some colleagues who are convinced that the best way to learn is by working with toys and sheilding students from the realities of modern software; I disagree, and have always favoured doing real things as the best way to learn how to prepare for a life of software development, which stops being neat and tiddy the minute you start doing anything other than closely scripted tutorials.  We don't help our students by sheilding them from all the complexities of what they must eventually face.

I had a former student email me recently, who was struggling to reconcile how she felt about programming with what it actually was now that she was doing it fulltime.  A lot of what she said sounded familiar to me, and also very normal.  Rather than perceiving her discomfort as a problem, I recognized it for what it really is: the impossible demands that our software requires of us vs. how well equipped we are to meet them.  Programming isn't something you learn in 24 hours, one semester, or during a degree.  This is a long, winding road, and accepting that it's hard for all of us is an important part of not giving up.  Not giving up is 90% of what you need to be a good programmer.

So how do I get students to work on code like this?  First, I don't expect perfect results.  We work in smalls steps, issue by issue, pull request by pull request.  We get it wrong and correct our mistakes.  We struggle through trying different approaches until we land on one that feels right.  We help one another.

This past week I saw a lot of students working together on Slack and Teams to write fixes and do joint reviews.  The move to virtual learning has opened the door to much greater collaboration between students: anyone can share their screen with anyone else in the project at any time, and it's easy to "let me show you what I'm struggling with here."  I'm also fascinated at how students will join in on calls even if they weren't invited, knowing that their presence there will be welcomed rather than met with questioning looks.  This openness to collaboration, and to each other, is exactly what I've sought to build for many years.

On Thursday I spent most of the day stuck on writing one tricky end-to-end test for our authentication flow.  No matter what I did, one of our microservices kept returning a 200 vs. 201, even though the code never returns a 200!  I tried everything I knew how to do, writing, rewriting, and testing from different angles.  Nothing worked.  Eventually I reached out to Chris and Josue, who were just coming online to try and write some tests together.  Sharing my screen and talking to them for 5 minutes completely unblocked me, and was worth more than the 5 hours I'd already spent: our tests were silently automocking fetch(), and every request resulted in a 200.

I've also seen the quality of reviews continue to increase, week after week.  We've been at this for months, and in much the same way that a runner can slowly add more volume every week, or a lifter increase their benchpress in tiny increments, the ability of the group to review each others code and spot issues has gotten better and better with practice.  In the beginning, I had to review everything, and I still do one of the reviews of most PRs.  But more and more in this release I saw PRs land that I hadn't read, but turned out to be well reviwed by two or more other students.  It's been great for me to have my own code reviewed too, since I need help as well, and I've been able to fix many things through the students catching my mistakes as I worked.

Despite all the positives I've seen with collaboration and review, I also struggle to overcome some behaviours.  For example: merging code without reviews; hesitancy to review things that weren't specifically assigned to you; assigning everyone to review a PR, ostensibly meaning that no one is assigned.  Review is hard to teach, and easier to learn through experience.  Reviewing code is how I write most of my code: suggesting fixes or simplifications.  I also learn all kinds of things I don't know.  The students assume that they can send me anything to review, and I'll already know how it works, or at least understand the tech they are using.  Often I don't and I have to go read documentation, or write sample code, before I can provide useful feedback.  As a result, review is as much a documentation and educational process within a project/community as it is a chance to improve how things work.  If you don't request reviews before merging, or you don't get involved in giving them for other people's code, you miss the chance to build a subset of the project that understands how something works.  If you want to be the only person who can ever maintain or fix bugs in a piece of code, go ahead and do it all alone, because that's how you'll stay.

Another struggle I have is trying to figure out how to get people to push their code for review well before the day we ship.  I've yet to see a PR that gets reviewed and lands in a single iteration without changes (my own included).  I know I'm not capable of writing perfect code, but some of the students are still learning this the hard way.  It takes several days for a fix to get reviewed, tested, rebased, and landed.  However, yesterday a bunch of people showed up with unreviewed code changes that they expected to be able to ship the same day.  On the one hand, this is easily solved by being a ruthles product manager, and simply refusing to include things in the current release.  If we were in industry, this type of  bevaviour would result in people losing their jobs, as the rest of the team lost confidence in their colleague's ability to estimate and ship on time.  But this isn't industry, and these aren't employees, so I do my best to help people finish work on time.  Doing so means that mistakes get made, and yesterday's release wouldn't autodeploy to staging or production because of some missed environment variables for one of the containers.  People dropping unfinished code on the floor and walking away, expecting someone else to clean it up, isn't a great strategy for success.

Yet all of this, the victories and defeat, the frustrations and successes, all of it is what it's like to embrace the grind of software development.  If you're not up for it, or don't enjoy it, it's probably good to understand that now.  Most of what we do isn't hard, it's just tedious work that needs to be done, and there's no end of it.  What looks like magic from the outside turns out to be nothing more than a lot of long hours doing unglamorous work.  A release is a chance to let go, to finally exhale after holding our breath and concentrating for as long as we could.  It's nice to take a moment to breath and relax a bit before we do it all again, hopefully a little stronger this time.

by David Humphrey at Sat Apr 10 2021 16:03:43 GMT+0000 (Coordinated Universal Time)

Royce Ayroso-Ong

Let’s Get the Train Going

Talking to the right people, juggling branches, and reviewing issues

Hey all! This past week I got a couple of my PRs merged (see here and here) and now it’s full steam ahead with accessibility. Below is essentially the code in my latest PR that solves one of the most troubling thorns in my side. With my element decorator PR merged, I can finally single out BlogSpot posts and style them accordingly — and with just 4 lines of CSS code, the sizing issue saga can finally come to an end.

 * Custom styling for different blogging platforms.
 * Known hosts so far are: [,,], otherwise the class is "is-generic".
 * To add to this list see the Post.tsx file, under the `extractBlogClassName()` function.
 */ img {
  display: block;
  width: auto;

So what have I been doing this week? I’ve continued my accessibility conversation and I’ve taken this issue off of Yuan’s hands. I’ve been trying my best to review some PRs — but I’ve been wondering what the best course of action when it comes to PRs that I am not selected to review. I assume that they are looking for people who are familiar with the issue, and in that case, I don’t want to assign myself and start giving my critique. On the other hand, I know that some of these PRs are in desperate need of review since some of the people selected are too busy with their own stuff. I think how I will approach the following week is just to take my time to give a review whether I am on the list or not and if it was not warranted then it is what it is, they can just dismiss it right.

Lastly, once I get the code for the issue above running, then I will start to take Yuan’s advice and “…start checking all pages and components, see if the font size and colour pass WCAG 2.0.” (guideline here). Like I said in the last week’s post, I want Telescope to be able to be enjoyed by everyone.

by Royce Ayroso-Ong at Sat Apr 10 2021 03:22:48 GMT+0000 (Coordinated Universal Time)

Abdulbasid Guled

DPS911 Blog #12: The beginning of the end

Only 2 blog posts until I can stop writing these things...thank god.
Well, maybe I'll drop the odd post here and there!

After last week's bout, things sorta resolved themselves just nicely. With less school work to do this week, this was the week I've been waiting for to really just relax and take some time to look after myself, which included going for some walks. The weather was amazing this week, you can hardly blame me for that.

In terms of reviews, I got back to doing them, and I did alot. David ended up bearing the bulk of PRs I reviewed this week since the main story was getting a fully functional user service. That, and some other fixes related to our staging and production servers. Talking about all of them would mean I'd be writing this blog post forever, so here's a list of all the PRs he made that I reviewed:

These weren't the only PRs I reviewed of course. Today, I was with David helping Ilya get his search service ready to be merged in. This was a service we've been waiting for quite some time, as I had a PR that was blocked (This PR was here, however, like with the jest timeout PR I had, rebasing master onto here ended up closing the PR altogether. Good riddence I say, that was the last of my PRs with messed up timeframe of commits and the temporary fix was merged in by Josue not too long ago. I'll file a new PR to get this sorted out next week). Calvin's parser service also landed today, which means that all of the microservices we've been developing since 1.8 have now finally all landed.

I also did a number of reviews for some front-end related PRs. Namely, two from Yuan, which were the following:

She also that this PR that I reviewed as well to update our environment-setup docs to reference that they now use microservices. A good change, and one that will probably be changed again once the backend code is fully removed.

The more complicated PR was this one by Minh. He's updating the SearchBar design, and this means he needs to tweak with the new Search Context values that I provided in the new SearchProvider. The updates have been very slow, but since he's using logic that I made, I was able to provide my most extensive review ever on a PR. I think I've requested more changes in this PR alone, than I have in any PR I've wrote or reviewed this entire semester. His PR has been sitting for almost a month now and we can't have PRs sit in hell for that long of a time, so we're splitting parts of his code into another issue so we can land his PR in time for 2.0.

As for work that I did, well, I had a couple of PRs that got in successfully. My SearchContext bug was resolved, and it finally got merged in. You can find that PR here.

I also updated the jest e2e timeout settings so that our github actions don't timeout on the end-2-end tests and randomly fail CI for whatever reason. You can find that PR here

My big PR for this week, however, came in today after starting on it yesterday. Mo had two tasks on Satellite, of which, he was focused on the caching, while the other, the porting of redis, was sitting for a long time. I asked him if he was going to continue on with that, to which he mentioned that he didn't have the time. Knowing that my service, and Calvin's parser service needed redis in satellite, I finally decided to fork Satellite over and complete the port with his permission. I got a PR up with most of the code working, but the tests hanging up. While working with Ilya with his search service, I got some time with David to help debug this, and it essentially came down to how I was turning on and turning off redis.

The afterEach made alot of sense. Using redis.disconnect() would not work here, because the test would run again and fail due to a connection being terminated. So I had to use redis.quit(). The real issue was in my beforeEach. Starting the redis server here was tough. So on David's advice, I made the following changes in the redis.js file:

The try/catch was removed, the password code was removed, and I passed an options object to the function that returns a new redis constructor, using the REDIS_URL and the options object. In the test case, I called the createClientFunction in my beforeEach, and then, I used the done function that jest provides. It's an awesome function that helps with ensuring that asynchronous connections are properly handled with. I never wrote database tests before, so this is something I was amazed with. The redis test itself was very basic, just a simple redis ping command that returns "PONG". Applying the changes, and bam! The test closed up perfectly with no problems. A push and merge later, and I was good to go. I did rob Chris the chance to review it since I merged it without any reviews, which again, I need to stop doing. I have this feeling where if something's watching me code and it works fine, then I can just merge it in no questions asked. This is what let me to my problems last week, and luckily, that didn't occur this time. Satellite was updated and redis is now available publicly for all services that need it.

I wrapped up this week by reviewing and approving a PR by Josue to add the search service's correct values to our staging and production environment values. You can find this here.

The two main issues I want to tackle for next week are the health check for the post service ( and the search service being used in the front-end ( These issues should be simple enough to get in so I'll try and see if I can start them early on Sunday since I'll be busy with work this weekend. With our second-last update in, alot of PRs will be rushed in the next 2 weeks. 2 more weeks to go before my journey in open-source is on a pause. Until next week, see you guys next time!

A small PS: I got Ramadan next week starting on Monday most likely, which means I'm gonna be fasting for the next month starting next week. Happy Ramadan to all observing! This government shutdown and pandemic cannot come soon enough.

by Abdulbasid Guled at Sat Apr 10 2021 02:33:14 GMT+0000 (Coordinated Universal Time)

Chris Pinkney

Human Murmuration

Credulous at best, your desire to believe in
Angels in the hearts of men

​ The week started off not with a bang but with a whimper, as I opened an issue that Davedalf the White noticed during our weekly triage meeting. I've been trying to reproduce the bug, but like Pedro I just couldn't no matter how hard I tried. Software development can be strange like this sometime, but unfortunately if this can't be reproduceable fixing the invisible will post quite the challenge. (Edit: As of this Friday, during our weekly deployment meeting we're currently under the impression that this is no longer an issue.)

This was followed up by a quick microservice meeting to discuss the latest status and the massive changes required to fully land the Users Microservice. I'll talk more about that later but the clock is ticking, t-minus 2 weeks and counting from today's date.

Josue and I had a quick meeting with Pedro to discuss some typing issues related to his latest PR which updated the Dynamic Image component we use on Telescope's home page. The meeting was concluded by the suggestion to implement MUI Types. I kind of wish I had learned more about typescript and NextJS but I think I'm okay focusing mostly on the backend for now.

After the meeting, Josue and I reviewed a PR from Davedalf, following some excellent advice to not test this locally (as it's not really something that's testable locally), but instead read the code and the tests. It's hard to understate the significance of brief (yet detailed) code explanations.

I also reviewed Yuan's latest PR which adds a really that hides the navbar on the initial render of our website, but shows it as the user scrolls down. I pointed out an issue that (presumably) caused this PR to clash with another newly landed PR from Duke which adds (awesome) scroll snapping. Unfortunately I don't know enough to help beyond pointing out flaws. Living the dream.

On a similar note, I also left my thoughts (such as they are) on Huy's PR which touches up the author section of Telescope. I also reviewed another of Dave's PRs, yet again joined by Doc Josue, which is helpful given that I can barely read a lot of the code he's pushing out lately. Having someone to dumb things down for you is also helpful.

I also had a brief meeting with Dave regarding some issues he was running into when attempting to POST users to the Users microservice in some tests. Yet again Doc Josue was able to save the day, and a fix PR arrived shortly after. It turned out our backend was mocking our node-fetch requests, resulting in data not being sent to the microservice.

I finished off the night by leaving some thoughts about a weird code escaping bug, which was conveniently being caught by another blog post by yours truly. I've worked on our backend's sanitizer previously so fortunately I have a small bit of "insight" into what may or may not be causing the problem.

​ Friday, the week is over but we still have to deploy and land all our PRs before hand. Here's a flurry of PR's that I approved:

  • A PR which (finally) allows user authentication on our Vercel deployments. Something I've been waiting for for a while now.

  • and also ... a followup PR to fix something that I noticed just broke with the Vercel fix!

  • I also left some notes on Illya's search microservice.

  • Finally, I also approved a last minute fix from Doc Josue which fixed our latest prod deployment.

Users Microservice

​ We finally landed a fix for our paginated GET route (something I tried my best to review) which, admittedly, had me nervous for a few days. The problem we had previously was that the paginated GET route that I created only worked for users who had IDs starting from 0. Since we hash our user IDs, this obviously is not a solution. The solution is actually really clever: it relies on keeping track and embedding where we left off in the response's header so the subsequent request has all the information where to continue from in the response header:

const query = await db


let query = db.orderBy(documentId()).limit(perPage);

// If we were given a user ID to start after, use that document path to add .startAfter()
if (startAfter) {
    query = query.startAfter(startAfter);

const snapshot = await query.get();
const users = =>;

// Add paging link header if necessary, so caller can request next page
addNextLinkHeader(res, users, perPage);
module.exports.addNextLinkHeader = function (res, users, perPage) {
    // If there aren't any results, there's no "next" page to get
    if (!users.length) {

    // Similarly, if the number of users is less than the perPage size,
    // don't bother adding a next link, since there aren't going to be more.
    if (users.length < perPage) {

    // Get the id of the last user in this page of results
    const lastUser = users[users.length - 1];
    const lastId =;

    // Construct the body of the header, giving the URI to use for the next page:
    // '; rel="next"'
    const link = new LinkHeader();
    link.refs.push({ uri: `${USERS_URL}?start_after=${lastId}&per_page=${perPage}`, rel: 'next' });

    res.set('Link', link.toString());

Clever fixes like these are amazing.

Aside from going over this PR a few times, Josue and I wrote a tool to help export users from the Planet CDOT Feed List (a list of Telescope users and their blog information.) It... actually didn't turn out bad at all! The code is easy to read, maintainable, and best of all, short. It went through a few rounds of reviews (a new personal best for me.)

I also started initial discussions and research into proper e2e testing for the Users microservice, and implementing our own Redis cache. More on that to come by next Friday.

Overall a good week which I spent a lot of time reviewing, commenting on stuff, and having meetings.

In other more personal news:

  • Been playing a bit of Assassin's Creed Valhalla, it's a solid 6/10 which (in the few hours I've played) has been otherwise enjoyable.
  • Been thinking about getting into Rust a lot lately. All this JavaScript lately has been making me itch to get back into a "lower level" language.
    • I really wish I had pushed myself more in OSD600 to try something new. I don't regret my time using Python at all (as it was also new to me), but I guess the grass is, in fact, always brighter on the other side. Or maybe it's always rustier? Who knows.
  • Still enjoying The Way of Kings a lot. Finally on part 3 after starting this book nearly 4 months ago. Highly recommend the graphic audio version if anyone else is an audio book fan (they also have a preview on their website which is awesome)
  • Wish me luck with my finals start next week.

by Chris Pinkney at Sat Apr 10 2021 01:41:38 GMT+0000 (Coordinated Universal Time)

Tuesday, April 6, 2021

Tony Vu

First attempt at PWA — Failure

First attempt at PWA — A Failure

I started my exploration in PWA having some prior knowledge about PWA with NextJS. It is always good to know where you want to start in everything. From my past exposure, I learned about next-pwa , an out of the box package to make a Next project become a PWA. It is advertised as “Zero Config PWA Plugin for Next.js” and that was what I wanted to reduce development time. I wish everything was as smooth as I always expected (but rarely happened) as the advertisement. Yes, it has minimal config if you don’t need to make it work with other plugins. I did not know about that until my first attempt failed badly because of my lack of understanding how to combine configs in next.config.js . Below was how I thought I did it right…

The issue with this is that you can only use module.exports once. However, I was not careful enough to check all pages before submit my commit and since it showed the install option on mobile browser, I thought the commit was good to go until Chris pointed out that the About page did not load. That was when I learned that you should not have two module.exports .

I did a bit of research on the internet and found next-compose , a package to compose plugins together. I was thinking “Great! Problem solved!”. I followed the instruction in the README, and came up with something quite organized.

But then the About page still did not load. It was quite frustrating up to a point that I had to take a break from it and informed the team that we might need to take a different approach.

When I felt more composured, I decided to take another look at the PR and tried to figure out what I did wrongly. It turned out that withMDX plugin is structured a little bit differently and the way I set it up with next-compose was not incorrected. Also, Chris mentioned that someone during the triage meeting suggested to use another better established package called next-compose-plugins to solve the issue I had. Combining all information I have from the internet and what required for next-compose-plugins to work, I ended up adding a custom babel config file and a custom webpack config file as well as installing a few dependencies. Everything seemed to be in order, just that I still did not work…My very first attempt with next-compose-plugins can be found here. At this point, I felt that I needed to figure this out because it bothered me so much that I could not allow myself to give up on it. And the series of trials and failures began…

This blog ended here to express my frustration in the first attempt with PWA. In the next blog, I will explain how I successfully implemented a solution that worked.

Thank you for reading.

Tony Vu.

by Tony Vu at Tue Apr 06 2021 23:10:45 GMT+0000 (Coordinated Universal Time)

Yuan-Hsi Lee

Prepare for telescope 2.0

This week, I've been working mostly with UI changes, including user accessibility and investigating an issue in landing page for UI 2.0.

User accessibility

Use accessibility is one thing that I want to focus on telescope 2.0 release. There are many rules to follow to improve our user accessibility, and I started with the obvious one, which is checking the color contrast and size of all our pages and components. I've found the links color in dark mode, contribution card in dark mode, search help, slack icon can be improved. Also, since I'm working with mostly color styling, I also start to update the colors in our dark and light mode palette for better management.

Royce will be working with me on user accessibility, looking forward to working with him!

Landing page for UI 2.0

In Pedro's UI 2.0 project, he also plans to modify our banner. I'm assigned the part of moving nav bar from banner to timeline. The goal is to remove the nav bar from the banner, but show the nav bar when the user scrolls to timeline (posts). I've considered different solutions so far,

  1. Move nav bar to timeline (posts) component
    Currently, nav bar is above

    so that we can always see it in the top-right corner of the page.

  2. Only display nav bar when the timeline component touches the top of the screen
    This one is challenging for me. I haven't worked with element positions with screen before, not sure how much time do I need to investigate it.

  3. Make the nav bar component invisible in banner
    If we don't want it to be showed on the banner area, why don't we make it invisible in that area? For example, make the navbar element "under" the banner element?

Developer experience

As mentioned in previous post(s), I've been updating documents to follow the changes in telescope (mostly microservice). I closed my old PR for adding a new, temporary document for microservice transition. Instead, I go back to existing documents, and update them. Start with, I believe there are lots of documents can be updated.

by Yuan-Hsi Lee at Tue Apr 06 2021 04:10:59 GMT+0000 (Coordinated Universal Time)

Monday, April 5, 2021

David Humphrey


I collaborate on content with a lot of different people.  As a software developer, almost all of my work is done in git and GitHub.  As a professor working at a large institution, most of it is done in Microsoft Office, email, or increasingly, in Teams.  Lately I've been thinking about how these various tools come to shape our sense of what content is, and define our relationship to it, and eventually, to one another.

When we use the word "content," we do so in a number of competing grammatical ways:

  1. She was content with the outcome.  Content is a state of satisfaction, of being at peace, a happiness and willingness to accept something for what it is.  Tied up in this is also a sense of acceptance, and perhaps an understanding that a deeper longing will not be met.  Content is adequate.
  2. He poured out the bottle's contents. Content is what is found within, it is everything included, the full amount of something, what is available.  To think of content as being too little or too much misses what it actually is.  Content is what is there, not what you do or think of it.

The book's table of contents tells me what is to be found within its pages, but my goals as a reader will ultimately define how contented I am with the its coverage of some topic.

As a collaborator using git, I am never done creating content.  I write in any number of styles, languages, and software applications, and in every case I am freed from the burden of perfection.  I am able to be human, always aware of my existence within in time, that this will not be my last chance to improve things.  While my many failings are always with me, accruing within .git/, they are both on display for all who would judge me, but also hidden in the constant flow of error and eradication of mistakes by new commits.

When I'm in git, content is what is found within: this repository, this release, this branch, this commit, this moment.  To experience content this way is to examine the sea, and look upon a wave, knowing that another follows.

As a collaborator using office software, I am terrified of my mistakes.  I read, re-read, and read again, hoping to uncover the typo, incorrect figure, or failed copy/paste that will undo my assignment, exam, grant application, or email.  I am forever cursed to be human, always aware that my imperfections cannot be separated from my good intentions.  My results are judged on the basis of the final document I must eventually submit.  Whether it is satisfactory or not remains to be seen, for it must be judged, accept or rejected, and not by me.

When I'm in office, content is how what I've made is received: the satisfaction of the reader, and their acceptance of what I've produced, the liklihood of my work being enough.  To experience content this way is to come face-to-face with something washed-up on the shore.

Moving between these two worlds is jarring.  I am the same person in both, but how my errors are viewed is very different.  In one, it is an expected part of the process of  improvement; in the other, it is a stumbling block, a cause for concern, and a failure.  

It won't surprise you to hear that my heart belongs to git.  I am now so used to embracing my mistakes, iterating and improving my work, and adopting a continuous-quality process, that to have to switch to the more common office-style undoes me.  It's a fascinating experience to witness my colleagues different approaches to me and my work, depending on which style they prefer.

I only know how to correct, not write correctly, and git, for all its flaws, fits me nicely, for all of mine.

by David Humphrey at Mon Apr 05 2021 18:47:26 GMT+0000 (Coordinated Universal Time)

Sunday, April 4, 2021

Abdulbasid Guled

DPS911 Blog #11: The importance of patience

First of all, thank you David for being there for me this week. I definitely needed that boost of confidence. Go read his stuff here. You won't regret it.

This week, I took a break from the microservice hell I was in and wrote a PR to create a Search Context for our search related props. You can find that PR here. I ended up coding the initial context in about 20 minutes which wasn't so bad. The real problem came with reviews...

So, I only got like about 2 reviews only for this PR. I wasn't expecting such a low turn-out, especially considering this was for a piece of the front-end which most of our group was working on. Probably because I did alot of testing, and I hated having to rebase my PRs so frequently, I merged the PR in myself. Suffice to say, while the github actions tests were all green, I re-introduced a bug that we had fixed months ago, which was the search bar making a request on every letter typed. You can imagine my surprised when I was working on some other work for other classes and got a message that it was broken.

I got cocky and impatient and it ending up biting me pretty good. I quickly went about searching for a fix, and it took an hour of looking at the code, but it was simple. I just needed to also include the textParam that we had as a context value so the search results component used that value instead of the actual text when making the network request. We have a useEffect that gets ran in the context everytime the text changes, so that's what was causing the bug. I went to file the PR and...

My remote master was ahead of all my other branches, and thus, it was bringing in merge commits and other commits from other students as well. Great, so now I have to fix my git history once and for all. This was occurring for a few days and it affects all my current PRs up including the PR to introduce the search service to the front-end (Once the search service is merged in), and the PR to increase the jest e2e timeout seconds so our github actions doesn't lag and cause a random failure for no reason. You can find both PRs here and here. In any case, it was a pretty demoralizing week, and as a result, I didn't really do much in the way of reviews.

One thing that the Covid-19 pandemic has done is ruin any sort of live discussions. I try and be active in slack by talking as much as possible on current work I'm doing, but it's been clear that the majority of the other students aren't as active. School and life in the home certainly play a factor, but when only a few people are talking at any given point, it really ends up begging the question, "Why am I on Slack at all?". If I just need to shut-up and do my work, what's the point of even being there? I guess it doesn't help that I'm one of the few people working on microservices, so any PR I put up is going to get very few reviews. Chris is also feeling the same way with his User service since we don't learn Firestore/Firebase in Seneca. I've tried to help alleviate that by learning as much of Firebase as I can on my free time in order to be able to provide some sort of help whenever possible, but I can certainly do more.

I hate rebasing so often, because it means that any PR I have up is either not getting reviewed enough, or it's blocked by another piece of work not in the repo yet and I have to wait. I was talking about my SearchContext PR during this week's triage to make it as simple as possible for others to review and yet, I find the lack of reviews very discouraging to be blunt. I think we have a great group of developers this year working on Telescope. We've done alot of work since January, and I wanna ask in this post that everyone step up and at least try to review PRs that they don't feel comfortable reviewing. Our microservices are just as essential as the 2.0 UI updates. Even if it's easier to review front-end code since it's mostly UI based, and even if CSS is one of my weakest points in web development, I STILL make the effort to try and review UI PRs, because at the end of the day, I still learn something valuable that can help make me better with CSS. Especially now with the github cli available, making it very easy to go into another person's PR and actively test it locally, we have the potential to do much better, and I know we can.

There's only 3 weeks left until 2.0 launches and I'm starting to realize that many of the things I wanted to work on will probably not happen. If it's possible for me to continue working on Telescope past DPS911, I'll take that opportunity. With this in mind, I've decided to drop work on the redis data loss feature. I left a comment discussing what a solution can be for any future developers working on this feature here. If I can continue working on this after this month, it'd be great. I feel like this solution would be most ideal at solving this redis data corruption issue. I'll be updating the posts service's health check path to also check Redis to make sure that works once Redis is ported over to Satellite, and then, there's the JWT related stuff I wanted to look over as well. I think I messed up by taking on way too many issues and so I plan on dropping a number of them in the coming days, not because I can't do them, but because there's not much time and it'd be unrealistic for me to look at every one of these issues considering the time.

With this in mind, that about raps up this post. Made on Saturday instead of Friday due to the Good Friday long weekend. We'll be back on track next week. Until then, stay tuned!

by Abdulbasid Guled at Sun Apr 04 2021 02:59:28 GMT+0000 (Coordinated Universal Time)

Saturday, April 3, 2021

Chris Pinkney

This Horrifying Force (The Desire To Merge)

​ The weekend crept around like a bad habit. I spent it working at my job and making progress on my two PRs which couldn't be landed in our Friday release due to an acute programming deficiency time and review constraints. Both PRs went through a rampant series of reviews before they could be landed, which I am consistently and eternally grateful towards. Telescope would look like a dog's breakfast were I put in charge of approving or disapproving code integrations. Plus it's always good to have someone better than you review your code:

​ But we'll get into the users micro-service stuff shortly. Switching gears to some Telescope maintainer work, I approved a PR which adds Portainer, a container management GUI (which I had explored a few days prior with Josue) which makes the Telescope admin's lives much easier. I used to host a lot of game servers when I was younger (still do) so I love to play around with software like this.

I also approved a small PR which fixes a typo we had in our CSS, and another fixing the way we display hyphens in Telescope users names. The latter PR had some pretty interesting discussion based around how to approach this issue, how should we display long names which contain hyphens? Should we break the name onto a newline, or split the name at the hyphen? Eventually we decided to simply split onto a newline after encountering a hyphen.

I suggested the use of Formik for our new user sign-up page PR. The sign-up page will eventually be sending post requests to the Users microservice to allow Seneca Students to create accounts and add their blog feeds/GitHub info to their profiles. Naturally it's imperative that we employ double-validation (a word which I totally didn't create just now), meaning we should be validating information that users can input in both the frontend and the backend.

I also lead our weekly triage meeting, with my co-pilot Royce. I think it went really well. I certainly didn't feel as nervous as I did the first time leading.

Users Microservice

​ One change of note to one of my PRs mentioned above, was an idea suggested by Head Wizard Davealdore to validate the query parameters used in the users micro-service even further. We currently have code in the Users microservice which parses each parameter passed in when executing a GET request to /?per_page=xxx&page=yyy to retrieve Telescope users. These values for the parameters (xxx and yyy above) can be between >= 1 and <= 100 for per_page, and >= 1 forpage:

const parsePerPage = req.query.per_page < 1 ? 100 : Math.min(parseInt(req.query.per_page, 10), 100);
const perPage = !parsePerPage || parsePerPage < 1 ? 100 : parsePerPage;

const parsePage = parseInt(, 10);
const page = !parsePage || parsePage < 1 ? 1 : parsePage;

However, it was suggested to instead delegate some heavy lifting to Celebrate, a library we use in the backend as middleware to our routes, such that we don't have to entirely rely on weird hacky code like the above snippet. It looks something like this:

-    [Segments.QUERY]: {
-      per_page: Joi.number(),
-      page: Joi.number(),
+    [Segments.QUERY]: {
+      per_page: Joi.number().integer().min(1).max(100),
+      page: Joi.number().integer().min(1),

Not only does Celebrate now ensure that the parameters can ONLY be numbers (specifically integers), it ensures that they must be integers with a range between 1 and 100 for per_page and >= 1 for page. With this change also comes a much needed pruning of the spaghetti logic above, as since we're validating both page and per_page, we have no need to parse or specify the values, and the code can simply be changed to the follow:

-   const parsePerPage = req.query.per_page < 1 ? 100 : Math.min(parseInt(req.query.per_page, 10), 100);
-   const perPage = !parsePerPage || parsePerPage < 1 ? 100 : parsePerPage;
-   const parsePage = parseInt(, 10);
-   const page = !parsePage || parsePage < 1 ? 1 : parsePage;
+   const { per_page: perPage, page } = req.query;

Awesome. I feel that every time I work with Celebrate I always come out feeling quite pleased with this library and with myself. When a JS library ups your self esteem you've probably been inside the house for too long. Sigh.

​ I also wanted to spend some time later in the week converting the unit tests in the Users microservice to e2e tests with Doc Josue, however a big PR from Head Wizard Davealdore was put up for review which changed a lot of the background and common files in the users microservice. Because of these changes I had to alter the order of my operations since a lot of files that I'd be touching are going to get changed after said PR lands. Thus I instead spent the night working towards finally landing my paginated PR instead, followed by a review to Davealdore's above mentioned PR. Also I think a certain head wizard needs a break... or a beer, or both, preferably both:

​ I also reviewed a PR about Jest, which added a watch mode to the e2e test runner. Constantly re-running tests was slowly driving me (further) into madness. I actually never thought that this had to be added, and instead figured it was just part of Jest and that I was, instead, being too lazy to google to run it.

This weekend I hope to finally get around to converting the users tests to proper e2e tests, submit more reviews to Dave's large PR, and ideally start working on adding our data to Redis as a cache between Firebase and Telescope. Happy Easter.

by Chris Pinkney at Sat Apr 03 2021 17:53:40 GMT+0000 (Coordinated Universal Time)

Royce Ayroso-Ong

Adhering to Accessibility Standards

Status report: cleaning up PRs and setting new goals

Photo by Robert Ruggiero on Unsplash

This week I spent most of my time preparing a pitch for Seneca’s “Pitch Nite”, where our team — among other teams who took part in similar challenge sets in Seneca’s 2021 Hackathon— would meet Sightline Innovation. To see everybody’s different pitches, designs, and demos for their proposed solutions was wonderful. Though with “Pitch Nite” long done, it was time to get back to work.

Tonight I’ve made the suggested changes to my last week’s PR regarding decorating each post with a class that matches the blog host platform. I’ve changed how the function is used and where it is called and I’m planning on dedicating the weekend to make sure that this lands before Monday since I also plan to create a second PR to fix the Blogspot issue right away.

As for my plans to improve Telescope’s accessibility, I’ve contacted Yuan (she’s sort of currently leading the charge) as to where I should begin— I don’t want to set out to fix something she’s already got under control. Moreover, I’ve been using Anton’s initial issue as a good place to start, reading the set industry accessibility standards and making note of what to look out for. For example, there is an entire list dedicated to making sure your website is readable (see here)— I will spend some time going through the list as I examine Telescope inside and out. As for now, I may try and take over this issue (#2001: Improve the visual break between posts in the timeline) to help Yuan with all the front-end improvements.

by Royce Ayroso-Ong at Sat Apr 03 2021 01:26:57 GMT+0000 (Coordinated Universal Time)

Thursday, April 1, 2021

Anton Biriukov

Weekly Telescope Podcast

Incremental improvements to the about page, first admin buttons, accessibility improvements, introducing Portainer, Google Search Console verification and getting started on the Jest Snapshot testing for our front-end are among my list of highlights for the past week.

Last week we’ve made a steady progress towards our UI 2.0 milestone. It has been very nice to see About page getting more and more polished by the efforts of Chris. It was a tough one, but we finally have a properly styled and responsive About page!

Yuan has done a very good job with improving the accessibility of links in the dark theme in her pull request. We have finally seen the introduction of Portainer (kudos to Josue) and got started on adding UI elements for admin functionality. From my side, it has been interesting to work on configuring Jest and creating the first snapshot test for Telescope’s front-end. The setup process gets really confusing due to a lack of standardization and poor documentation, but Dave was able to give me hand with it. He says it takes “decades of being stuck” to figure such things out…Anyhow, here is the code for the snapshot of the Logo component:

// Jest Snapshot v1,                                               exports[`renders correctly 1`] = `                       &lt;img                         alt="Telescope Logo"                         height={50}                         src="/logo.svg"                         width={50}                       /&gt;                       `;

Adding more snapshot tests is fairly easy and we should put our effort into increasing the coverage in order to avoid burnout and gain more confidence with using automated tools, such as Dependabot.

Another insightful thing that I have been exploring is the Google Search Console. Good news is Telescope is on Google and required pages have been crawled:

We can also see some statistics on how many times Telescope was mentioned on other URLs and what were the top linking sites:

Surprisingly or not, most of our search appearances came from the US:

However, there are also bad news…our old website seems to still be more popular then the new Telescope:

There is definitely a lot of insightful information available for us to analyze on Google Search Console and I think that we should not hesitate to explore our options there!


To summarize, here is the PRs that I worked on last week:

And the following is a list of PRs that I have reviewed:

by Anton Biriukov at Thu Apr 01 2021 22:32:09 GMT+0000 (Coordinated Universal Time)

Monday, March 29, 2021

Tony Vu

Dark Theme as an essential factor to developer’s success

This week, I was tasked to bring back the dark theme to Telescope. We had the dark theme before and all the functionalities to persist it as a user’s choice but since the UI was incomplete at that time and there were too many pieces required attentions, we decided to put a hold on shipping the dark theme.

It was a simple task, I just need to uncomment my previous code and ensure the ToggleThemeButton is styled the same as other navigation tabs with a tooltip on hover. Also, thanks to changing in the theme object, professor Dave recommended to change the background color to pure white as he believes grey is so old school and did not reflect our modernized design. What can I say? Your wish is my command! Now we have a very contrast themes with white for light theme and black for dark theme. I feel these are the most obvious choices when it comes to different theme modes.

One thing I noticed is that the dark theme did bring joys to at least a few of our contributors for example Anton and Josue. Some of them even mentioned that they will never go back to light theme again. From a UX perspective, one might feel having the option to choose the color theme that they preferred would give them more motivation to use the site. It is interesting to know that a minor thing like a dark theme could affect the success of an application.

Besides helping with the dark theme, I was also reading up about PWA on the internet to find what to do to make Telescope a PWA. And this would be my focus for the next blog post.

Thanks for reading!

Tony Vu.

by Tony Vu at Mon Mar 29 2021 19:55:13 GMT+0000 (Coordinated Universal Time)

Sunday, March 28, 2021

Royce Ayroso-Ong

Spending the Weekend Thinking

My possible dive into web accessibility and rethinking solutions

In response to last week, my pull request for centring table contents got merged but my pull request for adding a non-breaking hyphen needs revision. My slapped-on solution (born from trial and error) needs a bit more baking in the oven. While working on that PR I was solely focused on just implementing a way to replace the normal hyphen with a non-breaking one as the PR title suggests. However, this direction essentially ignored any other way to solve the original issue — that my last name was being cut down the middle.

Instead of using JavaScript to handle this, it was brought up that this could also potentially be done with CSS (linked resources here). This way, not only does this solution help avoid having my last name cut off, but also gives us room for longer author names.

After a bit of research, I found an eerily similar issue here, they were having the same dilemma of trying to figure out how to not break at the hyphen. After trying their proposed solutions I can’t get similar results to our solution with JavaScript. That being said, I think I can improve the Javascript solution by first using Unicode instead of the string literal for the non-breaking hyphen, this will allow future maintainers to quickly understand what the code is doing (before it just looked like a redundant line of code to replace all hyphens with a hyphen). Furthermore, part of the problem that contributed to my name being cut off was because the container for the author's names was simply too small given the amount of extra space on the screen. So, what I did was added a breakpoint that gave larger screens more width for the author name. Hopefully, this solution combines the best of both ideas to accommodate long names that may or may not include hyphens in it (like mine).

Decorating Each Post With a Class That Matches the Blog Host Platform

I’ve been working on this issue for the better half of last week, and the main problem I encountered earlier was that I couldn’t fully extract the blogging platform name:

// Old solution
const blogClassName = new URL(post.url).hostname.replace('.', '-');
// What we want: medium-com | What we got:

It’s been a long time since I did regex back in my first year Unix course — so I brushed up and did some research. One of the solutions that I found was from this StackOverflow post which gave exactly the intended result:

function domain_from_url(url) {
    var result
    var match
    if (match = url.match(/^(?:https?:\/\/)?(?:[^@\n]+@)?(?:www\.)?([^:\/\n\?\=]+)/im)) {
        result = match[1]
        if (match = result.match(/^[^\.]+\.(.+\..+)$/)) {
            result = match[1]
    return result

However, you can’t just copy and paste a solution from the web and use it in a commercial product. I studied what the code did, and made almost a dozen modifications which came out like so:

const parseHostName = (hostname: string) => {
  var matches = hostname.match(new RegExp(/^[^\.]+\.(.+\..+)$/));
  var result = matches ? matches[1] : hostname;
  result = ' ' + result.replace('.', '-');
  return result;
const hostName = post ? new URL(post.url).hostname : '';
const blogClassName = parseHostName(hostName);

This produces the same result, yet they are completely different in structure. The way I did this was I combined the old solution which gave a URL that needed to be further parsed and simply made a function to do exactly that and extract the blogging platform name. What we are left with is a solution that decorates each post with the blogging platform name like so:

This will allow Telescope front-end devs to specifically style posts from certain blogging platforms (I’m looking at you BlogSpot).

Future Plans

Telescope 2.0 is coming up fast and I want to do more to contribute and so far I’ve been thinking that I want to join the fight to make Telescope more accessible. This came about when helping my grandparents (who I live with) surf the web since they struggle with certain apps/websites — I realized that things obvious to me (I grew up with the internet by my side) are not so obvious to them. Sometimes designers go for what looks modern/minimal/aesthetic but miss the mark on intuitive design and usability by assuming all users are more or less tech-savvy.

by Royce Ayroso-Ong at Sun Mar 28 2021 18:45:07 GMT+0000 (Coordinated Universal Time)

Yuan-Hsi Lee

User Accessibility and Developer Experience

Telescope 1.9 release is shipped! Hooray!

In this week, I gain some new experience in user experience and developer experience. I'll explain them in this post.


As discussed in the last post, Pedro and I want to handle the title issue. The old title has big font size which causes the title wrapped easily, and will need to expand the title to 2 lines, which is what we want to avoid.

In this PR, I shrunk the title size to make titles showed in one line (in most cases), and with smaller space used.



This PR also solved the letter-spacing issue on mobile



The other 2 PRs I want to mention is to improve user accessibility. We have an amazing dark mode to switch, but some font/element colors does not meet WCAG AAA rating, or even AA level.

Our old color choosing for links in dark mode looks like this,

The gray one is visited link and the light blue one is unvisited link. The gray one is hard to read, but when I check the contrast ratio, the blue one also has AA rating instead of AAA.

There are many colors I can choose to meet the required contrast ratio. However, I want it to be more consistent with light mode (the default mode). In light mode, unvisited link has blue color, and visited link has the color like dark red-violet.

Therefore, I stick with blue for unvisited link in dark mode (but make it brighter to meet AAA rating) and change gray to a pale pink with a hint of purple.

The other PR is to change the search bar color in dark mode. There is no config for dark mode hovered search bar. Therefore, the color is using the same one with light mode. I changed the color based on the same design pattern with light mode (same color with background but use border to tell apart).

These couple of weeks gave me lots of chance to work with user accessibility and I enjoy it. I took over another user accessibility issue and will be discussing with other developers to file more specific improvement issues.


When I was shipping this PR to bring back our admin button in UI2.0, I found that the old method to run login server does not work. The reason is that we're in the transition to change to microservice. There are easier ways to start the needed services separately.

After talked to professor Dave, he suggested me to write a new document to help other developers handling these environment setups. (Since this is the second time I asked him about it)

In this PR, I gather different scenarios and explain how to do env setup and explain why we do that. It is challenging for me since I need to read other people's code and to understand. This PR is still in progress, I hope I can get more people to review it and get it merged!

by Yuan-Hsi Lee at Sun Mar 28 2021 03:36:24 GMT+0000 (Coordinated Universal Time)

Ray Gervais

Getting Started with Neovim’s LSP

Or how to alienate yourself in the world of VS Code In my previous exploits around the terminal-based workflow -which, you can read about more here, I had setup a workflow with tmux, alacritty, and vim to great success for my average day tasks. Over the past while, I’ve wondered how I could further improve the setup and remove the context-switch which often occurred when working with other tooling such as VS Code.

by Ray Gervais at Sun Mar 28 2021 00:00:00 GMT+0000 (Coordinated Universal Time)

Saturday, March 27, 2021

Chris Pinkney

Hey Sailor

I started off the week approving a simple but much needed PR from Yuan which shunk the title font size and added a link to the author's blog (my favourite part.) I then went onto approve YET ANOTHER pr from Miss Lee (who has been making some nice additions to our front end apparently) which re-adds our much needed admin buttons to our front end.

Next I set my sights on the ever polite Metropass (if that is his real name). I reviewed Mo's really cool PR and left my thoughts for him to digest. I had suggested that in addition to hardcoding how long we specify our Cache ages (i.e. how long the browser should cache a piece of data vs requesting a new piece of data all over again) the developer could alternatively pass a specific value to specify how long they want to cache their stuff (the ever technical word.)

​ The PR also reminded me of how switch cases finally got added to Python, I remember Googling how to do them in Python during OSD600 while working on link checker program, and since Python (at the time) didn't have them, I had to instead use if/else etc. This is kind of an ugly change if you ask me but not an entirely unwanted one.

I also threw some thoughts about a PR here, and finally I also reviewed Tony's PWA PR.

​ I remember talking to Tony near the beginning of the semester and us both agreeing to work on the PWA together (though we have since diverged paths massively since I'm currently obsessed with microservices) so I'm glad to actually see it being worked on. I have to say I'm really amazed at how simple it seemed to set this up. For some reason I was picturing doing something like React Native to get this work. Nope, simply import a library and Bob's you're uncle. Amazing. I even tested it on my phone and it worked beautifully. I was in shock, truly.

​ Finally, I gave my comrade Ilya a brief lesson on microservices (and satellite) since he's taking over managing a microservice. I'm really excited to see where it'll head to because I can finally talk and review microservices after my experience working on one for the last few weeks. Speaking of microservice...

Feeling undeservedly accomplished for now, I went back to touching (finishing?) up the Users Microservice. I had at least two goals that I wanted to accomplish this week: properly paginate the GET route, and fully set up the users microservice for prod. First thing was first so let's dive in:

I started off by working on paginating (a fancy word for saying "give me only a slice of the cake instead of the whole cake") the GET route for the microservice. After working on the issue for a while I stumbled upon a major issue: How can I request only n number of records and know where to start at when I don't have a point of reference? I can't just pump gas into my car and know when to stop, I need some sort of point of reference. Similarly I can't just request 20 records from the DB without saying where to start and stop from. How would the query know which 20 I'm requesting? The first 20? The second? The third? Etc. Can't I to request 1 page of 20 records, another page of the following 20, and a third page of another 20 records?

​ Generally in these situations there's something called an offset. I can request 20 records on the 5th page and simply offset which records I want by 20 * 5, thus ensuring that I get records 100-120. But not in Firestore! Another gotcya that's slowly pushing my away from the database that I once loved. The problem with this situation is that the offset method in Firestore requests ALL records in the DB as opposed to the few that I request. This is a problem when dealing with massive databases. If I have a database with 100,000 records, and I request 20, why should I pay for the bandwidth of requesting 100,000? (Probably so Google can charge you for it, but that's neither here nor there.)

​ I contacted Sage Dave and asked for some advice which left both of us in a stump. The solution I came up with is simply start from user 0 and work my way up from that when requesting n users. If a user has an id of 0, I can request 10 users on page 1 and 10 users on page 2, and since I know my starting point of reference I'll easily be able to request the first 20 users.

​ I finished my PR and threw it up for review. As with most of my code I'm getting good reviews with a lot of language-based semantic nitpicks. JS is not my forte. I mean, I have no forte, but if I did JS would not be it. I'm really starting to enjoy it though.

Next up is making sure that the Users Microservice is ready to be deployed on production. Since our code lives inside of Docker (with traffic managed by Traefik) I have to ensure that my microservice can both receive and send signals to the other microservices as required. The complicated part of this PR is differentiating between what environment the code is currently running in, and how to respond accordingly as a result.

​ When the microservice is running in dev mode, we have ensure that we're using the Firebase emulator and not the actual Firebase db (as to not incur usage charges when we're simply fixing code or adding features). How do you tell which code to run when though? This is a minor problem I struggled with a lot in this PR (I think mostly it's because my knowledge of Docker, Traefik, dev vs prod, is flaky at best). But my main challenge I faced with this PR was getting the emulator to work inside of Docker's dev environment (there's a lot of minute details and things to keep in mind with this issue, so I'll try to keep this brief.)

​ There's currently two dev versions to this microservice, a Docker version and a local version. Think of them as one in the same entity, just with a different coat of pain. The local version works flawlessly, so why doesn't the Docker version? I simply am not able to communicate with my microservice via Docker. WHY? It's maddening! I felt my sanity slip away while working on it. I explored every Google hit I could think of before relenting and asking for help from Doc Josue. After about 2 hours of us trying to figure this out, we came across the extremely obvious (in hindsight) solution.

​ You need a few things to ensure that the Firebase emulator functions properly:

  1. You have to make sure that you specify a port and address in the firebase.json file.

  2. You have to make sure that the projectIds match for both the emulator and the firebase config file.

  3. You have to make sure that the FIRESTORE_EMULATOR_HOST environment variable is PROPERLY pointing to the emulated Firebase instance in question.

​ If you haven't guessed it, I was declaring the Docker address incorrectly: FIRESTORE_EMULATOR_HOST=localhost:8088 vs FIRESTORE_EMULATOR_HOST=firebase:8088. And it makes perfect sense too when you think about it. localhost does not exist to other Docker containers, thus saying "I want you (localhost:6666) to connect to Firebase at localhost:8088" is not applicable. localhost:8088 does not exist from one container to the next. Stupid. Very stupid of me. All we had to do was specify the Docker container's network address (via firebase:8088) and we were back in business. We also briefly tested deploying the microservice to prod using a real Firestore instance and I'm happy to report that everything works as expected!

Both PRs ended up taking much longer and being way more involved that I had thought either of them would be. I really happy that I stuck with it and managed to work through several blockers I had. I genuinely could not have done it without Doc Josue and Sage Dave as both issues required more pairs of eyes to finally figure out. Kudos to both of them. 🍻🍻🍻

In more personal news:

  • Currently listening to local Windsor band Woods of Ypres

  • I'm very excited that it's getting warming and I can finally start my garden up again. If anyone wants to request a specific fruit or veggie to grow now is the time, simply bring a 6 pack to share when you come to pick up the harvest. That or review my PRs. Preferably the former.
  • I finally got around to watching some of Dirty Money's season 2. It's just as good as season 1 so far.

by Chris Pinkney at Sat Mar 27 2021 02:43:01 GMT+0000 (Coordinated Universal Time)

Abdulbasid Guled

DPS911 Blog #10: The importance of proper code review

I know I'm supposed to work on the microservices, but these frontend code reviews are killing me... >.>

So Version 1.9.1 of Telescope is now released. 1.9 had a hiccup so we had to make a hotfix release. As long as the work is done, that's what matters.

I spent most of the week reviewing front-end code. There was alot of PRs in for 2.0 design fixes so I needed to look at those. Front-end code has always been something I enjoyed looking at and working with, and although I don't get much of a chance since many in our group prefer working on the front-end, reviewing them is always a breath of fresh air for myself. I might even pick up a smaller front-end issue in next week's meeting.

Anyway, here's a general list of PRs that I reviewed this week:

Probably my biggest list of reviewed PRs yet. As many of my issues require me to look into parts of Telescope I haven't looked at before, I used this time to look into PRs that others made so that we can get them in. Sometimes, I mess up and others have to correct me, but that's why we always have 2 reviewers required to approve in order to merge (Looking at you, 2022).

In terms of work I did, I made a PR to switched the SearchResults component to use the microservice urls instead of the old telescope backend url. This was all fine and dandy until....

So uhh, the SearchResults component makes a query to elastic-search. This will return the query and other parameters that the component needs in order to display it's results. I made the mistake of using the posts microservice url, which doesn't have a route that returns though queries. As a result, nothing shows up. We have another PR that adds the search microservice up, but the owner, Ray, has been slow with updating it so I was tasked with continuing his work, which is now my priority. Once that's merged in, we can add it to production, and switched the frontend to using that url instead of the posts service url. You can find the PR here.

I think the main thing this week is realizing how much more work I'll need to do in order to get better with performing code reviews. Looking at this PR for example, I blocked the PR from progress because there wasn't enough adequate testing of the PR to prove that it can work in all situations. Another block from David was more because the way it was being done was not the best solution in general. A different reason for this but one that probably rings more true than my reasoning because of the evidence to back up his point. This piece in particular made me think alot,

"However, this breaks how hyphenation works on the web. Hyphens are supposed to provide wrap opportunities to the browser, and removing that seems wrong.

I would expand the width of this container. We have more room on the page, why limit it to such a narrow region?"

Is the code working good enough? Or should we really question the way the code is written? There are good solutions and there are bad solutions. Both will work for software, but one is easier to maintain and makes more sense for developers while another solution does neither. It's not something I consider enough when reviewing front-end PRs and so it's something I need to really work on more.

In any case, that about sums up this blog post. Only 2 more releases left until the 2.0 release. Big stuff are going to be coming. We got 4 weeks left to get all this stuff in on time. Let's get to work! Until next time, stay tuned!

by Abdulbasid Guled at Sat Mar 27 2021 02:41:48 GMT+0000 (Coordinated Universal Time)

Friday, March 26, 2021

Nesa Bertanico

My Lovely Experience with Seneca’s Digital Health Hackathon

This year, Seneca launched their yearly Hackathon and here are the 8 different challenge sets on which everyone can join and pick:

Royce and I teamed up to create Team AREN and we picked the challenge set: Patient Data Consent System.

A situation & role-based data access system that makes it easy for medical professionals to gain access to patient data but also preserves confidentiality and privacy of patients. Patients can give consent to share only what they want to share and medical staff can only gain access to what they need and what was released by the patient. In the event of an emergency, all critical data for treatment must be released to medical staff. Relevant technology that could be used to secure the system and protect data should be considered (e.g., blockchain). Mentorship will be provided by sponsors to aid in solution creation.

Seneca: Digital Health Hackathon

First Day

I learned a very valuable lesson this day, before starting any project a good programmer should identify who are the stakeholders and what do they value the most. It is very important to begin any project with system analysis and a diagram to capture requirements and business analysis to understand what the business needs. Remember that at the end of the day, you are trying to ‘sell’ a program.

As my team failed to identify our stakeholders and their requirements, we did not impress our judges on the first meeting with our first design.

Luckily for us, we are a team of fast learners and we cope super quick. Our good judges explained to us what the application’s functionalities are and right after the meeting we have a new solid idea.

Second Meeting

We presented our solid idea and the judges liked it! They pointed out our mistakes and which area of the application can improved upon. Royce and I had so much ideas for the application so we had to brainstorm each idea before adding and implementing them into our application. I will confidently say that communication is truly the key. First, we had a good and fruitful discussion with our stakeholders laid out the foundation and the blueprint of the application. Second, a 1-on-1 brainstorming with the team formed a solid idea and implementation. Overall, we are able to design a logical and functioning application.

Final Countdown

Is it really the final countdown or should I say final 30 hours of staying awake to work on this project. Deprived of sleep, team AREN powered through the creation of this amazing application: (Click here to watch our 5 min video presentation)

After the submission of the final project, we slept for 4 hours to get up for the winner announcement.

After nail biting moment, the host was calling out for the challenge set winner for patient data consent system and they called out Team AREN! I was literally screaming my lungs out.

I was so happy because this was the very first ever Hackathon that I compete in, and we got so lucky.


After screaming, I went to eat breakfast at 3pm to take the most peaceful and satisfying nap I have ever had.

I got the amazing hackathon Tshirt and this amazing badge:

I will definitely join any upcoming hackathon! I am just so excited to work with other people, learn and experience how to understand my stakeholders (I strongly believe that this is a important for software developers because we will be maintaining, modifying, or creating different applications throughout our work life.), learn about new technologies, and how to have fun as a Software Developer.

by Nesa Bertanico at Fri Mar 26 2021 05:56:33 GMT+0000 (Coordinated Universal Time)

Sunday, March 21, 2021

Yuan-Hsi Lee

What are users thinking

This week, Pedro discussed his thoughts with me about the title design in telescope. He wants to make the title section smaller.

This is how telescope handling the post title,

The title stick to the top when you scroll up, so that you can always see the title while you keep scrolling down and reading the post.
If the title length is too long, we wrapped it with ...; and it can be expanded after user click the title.

However, once the title is expanded, the title section is twice big. It'll occupy too much space of the screen.

It's smart to find out this issue. I have little knowledge of user experience, so I never figure this out. This is a great chance for me to dig into this field.

The solution Pedro came up is to dynamically adjust font size. In the other word, when the title overflowed, the font-size will be adjusted to be smaller and able to fit the div element.

We've tried different approaches to make it work, but none of them came with an expected result. Therefore, we were thinking removing the sticky title feature. As Dave suggested, when we're making changes on the UI design, we should always consider user's "habit". For example, in other similar kinds of websites, how do they design this feature? Users usually get used to one kind of design in a specific type of website. There, browsing other blog-post websites about how they handle a long title is a good way to start.

In medium and, there is no sticky title design. The title goes to the second or the third line if it's too long. However, it's not the same as our telescope. We have only one timeline, gathering all the posts (the whole post, without "read more" feature) from different authors.

In the meeting, some team members said that they don't really need the title once they start to read one post; but some do. The team came up with a solution which is to make the font-size of title smaller so that in most cases, the title will remain one line. Our title font-size is about 3 times bigger than the content font-size. To compare with some similar websites, they're doing much smaller size for their title.

Better? Can you still tell this is a title of the post?

Biweekly release makes us keep shipping changes. Sometimes, there is no perfect solution for one issue. But, shipping changes in each release makes our project better and better, even if it's just a small change in every release.

by Yuan-Hsi Lee at Sun Mar 21 2021 00:26:46 GMT+0000 (Coordinated Universal Time)

Saturday, March 20, 2021

Anton Biriukov

Search Engine Optimization with Next.js

In this article, I will cover four steps that will help improve your website SEO.

Photo by Marten Newhall on Unsplash

When it comes to building any modern website, you will most definitely have to work on the Search Engine Optimization for it, because you want other people to be able to find your website and utilize it. Let’s take a closer look at what it is and how to make it work.

Search Engine Optimization is a term used to describe the process of making your website better for search engines. In order for them to be able to provide better and faster search results, they use crawlers — automated software which:

  • searches (‘crawls’) the internet constantly for new or updated web pages
  • indexes those websites — saves their content and location

There is a number of search engines available, with the most popular being Google, Bing, and Yandex. In this article, we will mostly focus on Google, which contributes to over 90% of all search requests on the web. Considering this number, just making sure your website is properly indexed by Google would already be a big win and should definitely be the first thing on the to-do list.

Verify Your Website (Domain)

Google provides a dedicated console to manage and review the SEO performance of your website. It is quite a powerful tool, which allows you to collect analytics and find ways to improve your SEO. The first step to start using this console is to verify your website in it:

It is fairly simple to use and provides all necessary instructions. Once verified, you will be able to access a variety of tools.

Enable Crawlers

Firstly, it is important to make sure that search engines’ crawlers are able to access your website. One of the most widely used ways to do so is with the robots.txt. Through this file, owners of a website can specify which crawlers are permitted to look for and index which pages. You can get more information about it on the official website or in this guide by Google. Ultimately, it takes the following form:

# Specify allowed crawlers (e.g Googlebot, Slurp, Yandex)
User-agent: *
# Specify which pages the above-mentioned engine should crawl
Allow: /
# Specify which pages the above-mentioned engine should not crawl
Disallow: /search
# Specify how often should crawlers perform searches for new/updated # pages on your domain (in seconds)
Crawl-delay: 1

This file should sit in the root directory of your website. In Next.js, the ./public folder It is important to note that although most crawlers will follow the instruction given in this file, it does not prevent them from crawling the pages if they would want to. If you wish to keep certain pages private, you should consider password-protecting them.

In fact, most popular websites will have the robots.txt file. For example, you can take a look at, or

Create Sitemap

A sitemap is a file that essentially contains a list of all of the pages on your website. Google provides a comprehensive overview of it in their guide. In order to generate a sitemap for our Next.js website, we need to consider what types of routes we have (static, dynamic). We also need to decide how often do we want to update it or which events should trigger the update. Once generated in .xml format, we need to compress it and store it in the root directory of the website (./public folder for Next.js apps).

Hyouk has a great guide on how to implement sitemap generation for Next.js website. In case you use GitHub to store your project, he also covers how to set up GitHub Actions to trigger new sitemap generation on each deployment to master the branch.

Essentially, you can configure CI/CD in a way that works best for you. For instance, you could also update the sitemap on every new release. Lastly, you Hyouk also provides an easy way to poke Google to tell it to re-index your website again:

$ curl

Lastly, it is also a good practice to add a link to the sitemap file in the robots.txt file:

# Sitemap Link

Generate Meta Tags

Meta tags are used to specify information about the authors of the website, site name, description, page title, keywords and more. Some of them should be assigned on a page-to-page basis, while some should be assigned globally. In Next.js, such attributes should be specified in ./pages/_document.tsx file. Below is an example of global attributes and a link to the corresponding file for the Telescope project.

&lt;meta name="description" content="Description of your website" /&gt;                                 &lt;meta name="author" content="Author's name" /&gt;                                 &lt;meta name="keywords" content="List, of, keywords" /&gt;                                 &lt;meta name="application-name" content="Application name" /&gt;

The canonical link allows you to specify the canonical URL for each page on your website and should be used on a page-to-page basis. For example, you may have development, testing and production environments deployed to,, and correspondingly. In this case, you want to tell crawlers that all identical routes under these domains should be treated as duplicate with the production one being canonical. In Next.js this link should be placed in the <head> tag of each page, which ./pages/index.tsx file would be best for:

  <link rel="canonical" href="" />

Social meta tags provide you with a great way to enrich links to your website posted on social media websites or forwarded in private messages. There is a number of markup tag systems used, with the most common ones being Facebook’s Open Graph and Twitter. Essentially this protocols allow you to specify information such as web page title, description, image, etc. to enrich the link to your website with. See this file from Telescope project for reference. In short, you can add the following to the <head> in your ./pages/index.tsx:

<meta property="og:url" content={currentUrl} />                             <meta property="og:title" content={pageTitle} />                             <meta name="twitter:title" content={pageTitle} />

Some of them should be assigned on a page-to-page basis (like above ones), while some should be assigned globally. For instance, on Telescope we use the following tags in ./pages/_document.tsx:

{/* Facebook's Open Graph */}
<meta property="og:type" content="website" />                                 <meta property="og:site_name" content={title} />                                 <meta property="og:description" content={description} />                                 <meta property="og:image" content={image} />                                 <meta property="og:image:alt" content={imageAlt} />                                 <meta property="og:locale" content="en_CA" />
{/* Twitter */}
<meta name="twitter:card" content="summary_large_image" />                                 <meta name="twitter:description" content={description} />                                 <meta name="twitter:image" content={image} />                                 <meta name="twitter:image:alt" content={imageAlt} />

Once specified and deployed, you can verify these tags using Facebook Sharing Debugger and Twitter Card Validator:

Facebook Sharing Debugger
Twitter Card Validator

If your website also has accounts on Facebook or Twitter, you can also link those by using twitter:site and fb:app_id. See and for official details.

by Anton Biriukov at Sat Mar 20 2021 04:17:47 GMT+0000 (Coordinated Universal Time)

Nesa Bertanico

CoroVi App

Created a cross-platform Covid19 mobile application written in Xamarin.Forms with SQLite database.

App idea and functionality

This app tracks the number of cases, recovered, and deaths from Corona.Lmao.Ninja API from a Global perspective or from a certain country.

These are the 3 major pages of the application:

  • HomePage – this is where data from the API will be displayed. The user will be able to check the death, recovery, and cases from a Global perspective or from a certain country.
    • Users can enter any country name they want to see to display their total cases, today cases, total recovered, today recovered, total deaths, and today deaths.
    • There is a list view that contains all countries listed with their cases, recovered, and deaths.
  • SelfAssesmentPage – this is where the SQLite will be used. The users will be asked to do a self assessment if they have COVID or not. The questions I used are from Ontario Self-Assessment
    • Users can start assessment where they will be asked if they are experiencing any of these:
      • Fever and/or chills
      • Cough or barking cough (croup)
      • Shortness of breath
      • Sore throat
      • Difficulty swallowing
      • Runny or stuffy/congested nose
      • Decrease or loss of taste or smell
      • Pink eye
      • Headache
      • Digestive issues like nausea/vomiting, diarrhea, stomach pain
      • Muscle aches
      • Extreme tiredness
    • All of the results will then be saved into the SQLite DB with the time taken.
  • AccountPage – this is where the users are able to see their status, if they have COVID or not from the saved SQLite DB
    • The users can do following manipulations of the SQLite data:
      • View more details
      • Update the existing assessment data
      • Remove the assessment data

Web Services Used

I used the API from:

  • Corona.lmao ALL : I used this API website to extract values to track the total cases, recovered, and deaths and display them on the application. 
  • Corona.lmao COUNTRIES + “any country name”: I used this API to extract values to track the total cases, recovered, and deaths of a SPECIFIC country name and display them on the application. I also used this to gather all the data from ALL countries to be displayed in a list view.

To be able to extract the data I have this Class to hold the data:

public class CountriesClass    {
        public string country { get; set; }
        public int cases { get; set; }
        public int todayCases { get; set; }
        public int deaths { get; set; }
        public int todayDeaths { get; set; }
        public int recovered { get; set; }
        public int todayRecovered { get; set; }

        public CountriesClass() { }    }

And then I have this function that takes in the link and parse it into a string and then to be returned as a list all through the help of sonConvert.DeserializeObject from NewtonSoft.

private string url_allCountry = ““;

public async Task<List<CountriesClass>> GetCountriesCovid()        {
            try {
                HttpResponseMessage res = await client.GetAsync(url_allCountry);
                if (res.StatusCode == HttpStatusCode.NotFound || res.StatusCode == HttpStatusCode.ServiceUnavailable)
                    return new List<CountriesClass>();
                try {
                    var response = await client.GetStringAsync(url_allCountry);
                    return JsonConvert.DeserializeObject<List<CountriesClass>>(response);
                } catch (Exception e){
                    return null;
            catch (Exception e)
               return null;

Then later in my HomePage.xaml.cs I bind my data from the url above:

            allCountries.ItemsSource = null;
            var list = await summaryNetworkingManager.GetCountriesCovid();
            summary_list = new ObservableCollection<CountriesClass>(list);
            allCountries.ItemsSource = summary_list;

Then I display the Binded summary_list in from my HomePage.xaml

<ListView x:Name=”allCountries” HasUnevenRows=”True”>
                                    <StackLayout Orientation=”Vertical” Padding=”2″>
                                        <StackLayout HorizontalOptions=”CenterAndExpand”>
                                            <Label Text=”{Binding country}” TextColor=”#0A345E” FontAttributes=”Bold” FontSize=”Medium”/>
                                    <StackLayout VerticalOptions=”Start” Orientation=”Horizontal”>
                                        <yummy:PancakeView BackgroundColor=”#68CAD7″ CornerRadius=”15,5,15,40″ Margin=”15,0,0,5″ HorizontalOptions=”FillAndExpand”>
                                            <StackLayout Margin=”25,5,0,5″>
                                                <Label Text=”{Binding cases, StringFormat='{0:n0}’}” FontSize=”Small” FontAttributes=”Bold” TextColor=”White”/>
                                                <Label Text=”Total Cases” FontSize=”Micro” TextColor=”White” Margin=”-1,-7,-1,-1″/>
                                        <yummy:PancakeView BackgroundColor=”#AABBF3″ CornerRadius=”40,5,5,40″ Margin=”0,0,0,5″ HorizontalOptions=”FillAndExpand”>
                                            <StackLayout Margin=”25,5,0,5″>
                                                <Label Text=”{Binding recovered, StringFormat='{0:n0}’}” FontSize=”Small” FontAttributes=”Bold” TextColor=”White”/>
                                                <Label Text=”Total Recovered” FontSize=”Micro” TextColor=”White” Margin=”-1,-7,-1,-1″/>
                                        <yummy:PancakeView BackgroundColor=”#FB9C80″ CornerRadius=”40,15,5,15″ Margin=”0,0,15,5″ HorizontalOptions=”FillAndExpand”>
                                            <StackLayout Margin=”25,5,0,5″>
                                                <Label Text=”{Binding deaths, StringFormat='{0:n0}’}” FontSize=”Small” FontAttributes=”Bold” TextColor=”White”/>
                                                <Label Text=”Total Deaths” FontSize=”Micro” TextColor=”White” Margin=”-1,-7,-1,-1″/>

SQLite DB Data

CoroVi app stores data into the SQLite DB when a user submits an assessment form.

My SQLite holds 12 Booleans for each question to be stored, 12 strings that hold results of each question and a Datetime to store the time of the assessment taken. 

Here’s an example of my Assessment Class

 public class Assessment 
        public event PropertyChangedEventHandler PropertyChanged;

        [PrimaryKey, AutoIncrement]
        public int Id { get; set; }
        public DateTime dateTaken { set; get; } 

        public bool bq1 { set; get; }

        public string sb1 {
            get {
                if (bq1) return “You have fever and/or chills”;
                else return “You have NO fever and/or chills”;
            set { }

This is how we insert a new item in the db:

public async void startSelfAssessment(object sender, EventArgs e) {

            Assessment newAssessment = await AssessmentManager.InputBox(this.Navigation, null);
            if (newAssessment != null)

This is how we Update existing item in the db

public async void updateDB(object sender, EventArgs e)
            var toUpdate = ((sender as Button).CommandParameter as Assessment);
            var updatedTask = await AssessmentManager.InputBox(this.Navigation, toUpdate);
            if (updatedTask != null)

This is how we remove existing item in the db

public void deleteFromDB(object sender, EventArgs e)
            var toDelete = ((sender as Button).CommandParameter as Assessment);

This is how we display all the items from the db

protected async override void OnAppearing()
            SelfcarePage.allAssesments = await SelfcarePage.dbModel2.CreateTable();
            allAssesmentTable.ItemsSource = SelfcarePage.allAssesments;


I learned how to implement a TabbedPage, use different kinds of UI components, parse JSON from a web service, deserialize JSON using NewtonSoft, and store data locally through SQLite DB.

At the start of the pandemic my dad told me to make a mobile app to track COVID updates with a simple self-assessment questionnaire, and I made it happen! I installed this application in his phone so he can use it. He is very proud of me and that made my heart skip a beat.

I am so happy with the end result of this project, aside from learning Xamarin.Forms I also made my dad proud.

Click here for the GitHub link!


This is my first time touching Xamarin.Forms and C#. I must say that I am a bit sad that Microsoft announced Xamarin.Forms will be deprecated in November of 2021 because they are releasing a new .Net based product called MAUI(Multiform App User Interface). Maybe I should be excited for MAUI instead?

We are all truly blessed to have the chance to enjoy all these amazing cross-platform frameworks, each framework is only getting better and better each day!

by Nesa Bertanico at Sat Mar 20 2021 04:06:48 GMT+0000 (Coordinated Universal Time)

Royce Ayroso-Ong

Iterative Progress

Status report: it’s best to break up a problem into smaller pieces

Photo by Sigmund on Unsplash

Phew! Dumping all my time into that issue to handle inline images really took a toll since nothing I did could produce the intended results without unintended consequences. Yet oddly, I feel a sense of resolve to keep going and be active more than ever to get it reviewed and merged. I felt bad earlier this week because I couldn’t handle my simple front-end issues — but through the iterative struggle, I’ve talked with more people this week than in all my previous weeks working on Telescope combined. I guess I just had to admit that I *didn’t* have a solid grasp on the bugs that were plaguing me and that it’s best to reach out (and in some cases bug people — get it?) for help than it is to make them wait on a PR that will never get resolved. Moreover, the beautiful thing about iterative progress is that it’s iterative (and still progress). No duh right? Though. it’s something that has escaped my mind while working on my UI issues as I wanted to get the perfect solution for all to see, not realizing that I could break down the problem into easier-to-tackle smaller pieces.

Things to do for the weekend and next week: get #1791 and #1807 merged since they’re ready to ship, issue #1983 (since it’s something that I’ve been messing around with), figure out what is expected from this issue #1809 since it already looks good to me, and lastly — put the nail in the coffin to the BlogSpot bug by implementing #1975. Oh and I think I needed to file an issue and PR for the SearchResults still using the old posts URL. That’s it, see you guys next week.

by Royce Ayroso-Ong at Sat Mar 20 2021 03:42:27 GMT+0000 (Coordinated Universal Time)

Abdulbasid Guled

DPS911 Blog #9: Services, Services, Services

Cause my blog titles are very long apparently and they're causing a bug. Well, hopefully, this is short enough for you!

So after the debacle that was the Post microservice, I've finally been freed to work on some other stuff. So what was the first thing I did? I went right back to the posts microservice of course.

You can find that PR here. This PR addressed moving the posts microservice over to the frontend. This required me to make the posts url an argument in the Telescope Dockerfile so that it can be passed. This is because Telescope uses different urls for the services depending on whether the frontend is being built in development, staging, or production mode. Fun Fact: My boi Royce's PR was failing to load any posts in his PR's deployment because I forgot to change the SearchResults.tsx page to use the new posts service. A funny catch from today's meeting that I found.

From there, it was simply a matter of putting the posts service url inside the next.config.js file, exporting it inside the config.ts file, then using that in place of the TelescopeURL wherever it was used. An unfortunate side-effect of this was that I had to reintroduce feeds back into the posts microservice because they were needed in some of the posts related components. I'm sure they can be removed at some point, but it's a matter of when and how.

I also worked on modifying our base jest.setup.js to import the development env files. You can find that PR here. This involved removing the jest.setup.js files from any microservice folder since those were only there to pull the env file and I did so in the base jest.setup.js file. I kept the one inside the posts service to import the MOCK_REDIS value, but I might take that out because it gets added in the jest scripts. I'll need to work on that a little.

I worked on some other PRs this week as well. Here's a list of the following PRs that I reviewed:

I also did research on possible ways to incorporate private and public keys into our jwt authentication. These would be used to sign payloads, making them more secure as opposed to using a secret from the env. This would also be something that the staging and production endpoints can take advantage of. I'm currently working on this with Yuan and Ilya, and hope to have a PR for this soon. This would also be incorporated into Satellite, making it even easier. I'll have more to report on this next week, hopefully.

Next time, ver 1.9 releases. I was assigned to continue work on the search microservice that Ray started due to him being stuck up on his work. Juggling that with jwt auth related stuff will be tough, but definitely doable. Until then, stay tuned!

by Abdulbasid Guled at Sat Mar 20 2021 03:12:07 GMT+0000 (Coordinated Universal Time)

Mohammed Ahmed

Satellite and Redis….

My feeling when testing Redis

Oh man, we’re back.

At the start of the week, I was informed of a microservice module called “Satellite”. Now, Satellite is the place where we keep any commonly used microservice. I really wanted to learn more about microservices and I thought this is the place.

During this week, I’ve worked on at least 3 modules for Satellite: createError, Redis, and Hash.

hash, and createError were pretty simple for the most part

but redis…. oh my….

Now, porting the code wasn’t the hard part. The hard part was to get the test to work properly. All I really had to do was to send a PING request, so that the service could return the string “PONG”. Well, first I realized that I needed to run Docker. Okay, understandable. but then after, I need to create a promise function that will handle the PING command. “So, what’s the problem?” you might ask. Well… there’s just one tiny problem. Jest does not quit, because the service is still running. Even when I killed Docker, it would still hang.

Now, in terms of figuring out what to do, I need to think of a couple of things: Where should the test go, Telescope or Satellite? If so, do I need to have a kill command within the test? How long should the promise wait before it receives “PONG”? These are all questions that I need to figure out, otherwise, Redis will not be properly ported.

I think that’s okay though, it’s how you learn after all, with many, many retries (and rebases).

So, what will be my next step? To be completely honest, I need to play around with Redis a lot more. I need to understand how it works in order to make the tests. I won’t give up.

by Mohammed Ahmed at Sat Mar 20 2021 02:36:45 GMT+0000 (Coordinated Universal Time)

Chris Pinkney


​ The week started off with me leading our weekly triage meeting, with Mo taking notes. There's not too much to talk about, as only a few students were wounded in the telescope attack. I decided to spend a good chunk of meeting time focusing on older issues, as seeing 100+ issues, some of them from 2019, makes my neat-freak skin crawl. I imagine that this is a project most medium sized projects deal with. I also imagine that larger scale projects simply don't. All in all I enjoyed leading the meeting but was surprisingly nervous throughout most of it.

I also lightly reviewed one of Sir Dave's PR as I happened to be playing musical chairs recently with various PORT values for the plethora of services we're all working on.

​ On Wednesday I continued to work on the excellent abundance of requested changes to my Users microservice by Mo, Abdul, Doc Josue, and Sir Dave. My all-time favourite requested change would have to be this one. Previously I had two functions which would create different users that I could save to my database (to test routes that return all users, for example) but this change lets me instantiate as many users as I'd like with one function, and simply pass in different information when required. Awesome. I had really wanted to do something like this but couldn't figure out how to syntactically get it down.

I also started working on a fix to the pathetically un-styled About page. I'm still not crazy about working on front-end stuff, but I'd still really like to get better at it, plus, in the immortal words of Doc Josue:

but you know, it's good to know a bit of everything

Although clearly he's never tried to ask three+ designers to all agree on a design of something, as I had several changes, both on the GitHub page and privately on slack, requested of me at the same time. Lots of fun! I did learn a lot about CSS in the process, and what I already knew was a big refresher for me as I'm not the greatest in styling stuff. I do however always enjoy doing CSS stuff... for about the first 30 minutes, then I just wish I had gone into medicine instead. Big thanks to Ilya who spent some time with me teaching me a lot about various CSS properties and breakpoints, and helping me get the PR to where it is today. Hopefully it'll land soon.

​ Thors-day! I finally finished my micro-service approved and landed! Many hours of hard work finally over, with more hours to come. I also got to use the shiny force button too!

I genuinely couldn't have done it without all the guidance and help given to me by my professor and peers. The one thing I love about open source work is the communication ability coupled with suggested changes. Learning from those better than you is incalculably valuable. I'm really glad that I stuck with it and got it done, although It didn't get completed in as timely of a manner as I'd have wanted.

Oh, and naturally my power went out half way-through my final rebase, which resulted in:

PS C:\Users\Chris\Documents\Code\Repos\telescope> git status
fatal: not a git repository (or any of the parent directories): .git

Lovely. I had to reclone my fork and continue on my way. Not the end of the world but definitely annoying.

So what's next? I'm not sure! Figuring out what to do is always part of the fun. I'd like to get this wired up to prod next, then do a test-run to see if everything works as expected. Then move onto addressing several security concerns. Finally, I'd like to start working on actually implementing the users micro-service!

​ Friday. I started out by reviewing a minor Husky fix by Josue. How strange that dependabot upgrading our web hook program actually caused it to stop working. I mean that genuinely not as a snarky comment. It seemed like functionality completely broke in between versions and none of us noticed it for a few weeks. Strange. Thankfully Doc patched us up and we're good to go.

I also very quickly approved this PR (generously explained to us during on Friday meeting call) which adds an authorized middleware to Satellite which ensures that users must be authorized to execute specific routes. I look forward to implementing this, as security is something I was concerned with.

Speaking of our Friday meeting, Royce spent some time working on a fix for inline img tags in Telescope which he was kind enough to explain to us. I didn't think a simple task like this would be so involved but given how different blog providers handle images differently than another, it makes sense that Telescope can't accommodate every blog provided equally. Royce proposed working on a fix to detect Blogspot (our current problem child blog platform) and handle those images differently from the rest. I'm curious to see how this will handle random RSS feeds (i.e. those not on medium/blogpost/dev/etc.) and if it'll be a problem.

Finally I also released a minor fix to my users micro-service's Dockerfile for prod. This is what I get for copying and pasting without looking through it. However the fix also fixes my OCD as I had just noticed that a few files were not in the same structure as the rest of the micro-services. Phew. Now I can finally sleep well at night.

An overall busy but quiet week for me. I'm really glad that I was able to get the microservice merged and I'm really excited to move further forward with it.

by Chris Pinkney at Sat Mar 20 2021 00:02:49 GMT+0000 (Coordinated Universal Time)

Monday, March 15, 2021

Pedro Fonseca

Telescope 1.8

Telescope 1.8

Telescope 1.8 is a significant mark for everyone active and working on the project; the microservices and the new UI are now on our production server. Which means the new Telescope is flying. And I’m so proud of every active member that contributed to the project since we started porting to NextJS.

The new UI is not 100% implemented, but it is working well.

Learning while reviewing

I was reviewing a PR from Duke when I faced a JS shorthand pattern in his code that I had never seen before. I spoke with Josue, and he already knew the shorthand and pointed me to the docs. It is incredible how JS syntax is like a river that flows. I love it.

The process of reviewing a PR and learning while doing it is good; I used what I learned with Duke in my PR for Posts, Timeline and Post.

Posts component tree.

I spent more time than I expected coding the new Posts, Timeline and Post components. I had three different versions of it — the first version wasn’t so effective because to make the tablet and mobile sizes, the code was becoming so long. The second approach had a very different start point from the first; but I didn’t go so far with it because at a certain point, with my previous experience with the components’ code, I realized the second approach future would end up in the same place as the first one(very different start points ending in the same place).

There was a structural problem on the first two approaches because for Desktop, some parts of the code needed to be inside a container and these same parts should be outside of a container for mobile devices. I tried to solve everything using CSS in the first two approaches to avoid code duplication, but it was getting highly hardcoded. Wednesday night, two days before the release, I still couldn’t break the hardcoded part into a dynamic code.

Thursday, one day before the release, I started to discuss the code and the ideas behind it with Meneguini, and our communication presented me with what I was missing. I had to accept that I would have to solve the problem using more than CSS.

So I used React powers to refactor the Post component and accomplish what we needed.

1.8 Final thoughts

What we achieved in 1.8 is a result of our communication and effort.

Tony did a good job working on our theme and font issue, delivering what was needed very fast.

Yuan Lee worked on the avatar issue, which is extremely important to our UI. She was incredibly generous with me and the project, waiting for me to finish my PR and avoiding a good amount of conflicts in a possible rebase. So we could coordinate which PR would get merged first.

Yuan Lee also worked with Anton on dependabot, and now she is investigating a solution for our post title.

Duke did an excellent work fixing and improving various issues on Telescope’s frontend:

As always, Josue did an excellent work not only for our UI. Everyone that knows him also knows that he is the kind of player who plays in all positions. Sometimes I attempt to argue with him how JS is more beautiful than TS, but until now, I didn’t make any progress on that.

Josue's main positions.

Meneguini help was essential in discussing the post-component puzzle with me, even without being a Telescope member.

We still have a good amount of PRs to fire, a bunch of issues to file, and this is the evidence that we are heading in the right direction.

Thank you so much.

by Pedro Fonseca at Mon Mar 15 2021 10:01:22 GMT+0000 (Coordinated Universal Time)

Sunday, March 14, 2021

Anton Biriukov

Weekly Telescope Podcast

In this blog post, I will provide you with some updates on what happened in Telescope in the last couple of weeks.

Photo by Werner Sevenster on Unsplash

Throughout the last 14 days or so we have continued the work on the microservices and UI 2.0, which was quite exciting to see. Besides, I have finally managed to find a good-looking and properly working changelog generator for our releases. Tested in our latest 1.8 release, it categorizes merged pull requests based on the labels specified in the configuration file. The produced result looks quite appealing:

Release 1.8 Changelog

Another thing that I was able to configure and land a PR for extending Dependabot coverage on almost every other package file in the project. It is extremely convenient and allows us to check for outdated dependencies in any package file from one spot — Since we now have 9 files monitored, we applied a scarce update schedule to prevent having 9 PRs open all at once. I have been constantly keeping an eye on Dependabot behaviour and am relieved to say it seems to be doing its work well. One observation I can’t emphasize more is the frequency of dependency updates in our root package.json file. We are getting 6–10 updates for the file each week and so far I had to manually re-trigger checks for this package file to keep up with the pace. I really think we should make these checks daily specifically for this file. Taking into account that our team has been extremely efficient with reviewing dependency update PRs, such a shift should not bring much trouble. On the positive side, if we manage (which we constantly have in the last few weeks) to review at least one dependency update PR each day, Dependabot will likely open another one on the following morning. If not, it will just stay blocked and won’t trigger any CI runs. Apart from that, I have noticed that it is extremely convenient to use the Dependency graph page on GitHub to double check that all of your dependencies of up-to-date prior to the release. Instead of using npm outdated and creating PRs yourself, all you need to do here is just to click on the button. Works very well while the rest of the team debugs Chris’s docker creations!

Besides dependencies, I have also had a chance to update our release workflow once again to incorporate the new end-to-end tests. In the process, we have also identified and fixed a bug with some missing dependencies when our CI runs on forked repositories. Using playwright-github-action really made it easy to make sure all required dependencies are installed on the cloud server running our tests.

Lastly, I have also started looking into our SEO situation. I have conducted a few test searches on Google (e.g. try searching for ‘seneca open source’ or even ‘seneca telescope’) and found out that it is currently quite hard to find Telescope without directly searching for it. I am looking forward to improving our meta tags to try to bring Telescope above in the search results.


To summarize, here is the PRs that I worked on last week:

And the following is a list of PRs that I have reviewed:

by Anton Biriukov at Sun Mar 14 2021 23:40:42 GMT+0000 (Coordinated Universal Time)

Tony Vu

Mock it until it is real enough…

I finally got the approval from Telescope’s reviewers to start writing unit tests on my service. And it was not as straightforward as I would have thought…

My first struggle came from planning for my tests. I did not know how to start as my service includes a chain of middlewares as well as external HTTP requests. I literally spent three hours researching on the internet about testing with HTTP requests and middleware testing. Finally I decided that I should test whether my middlewares work correctly and whether the final json response body gave me what I expected.

During the process, I gotta learn more about supertest and nock . supertest is the HTTP client for testing environment and nock is a tool to mock HTTP request and response. I have also learned how to make the two tools work together. The hardest part of this testing is to convince yourself that I am on the right track because sometimes I felt like I was just doing random things without any concrete reasons. I felt proud of myself to be able to write these tests because they were quite hard to get for me.

Here are the results of many hours trying…

The joy when I run jest --coverage and it showed 100% is too much…

Isn’t this beautiful?

Thank you for reading.


by Tony Vu at Sun Mar 14 2021 14:38:28 GMT+0000 (Coordinated Universal Time)