An Update

I write as I listen to “Our Plague Year“, I sit on the bed I’ve sat on for a week straight.

I left Toronto a week ago, and I don’t think I’ve fully processed the time passing. I still feel like it has only been a week since everything changed so abruptly. You can see this failure by the two week gap between my pull requests. Working on school work has become a bit of a chore, there was some burnout already building up prior to everything happening.

With my routine gone, it is easy to lose track of time.

At least Telescope is something I find worthwhile. It is significantly easier to work on it than all the other assignments. It was jarring nonetheless, to see that two week gap.

So here is what I worked on prior to and after this new world.

Release 0.8 was more of a bug fix release. Making sure things were looking better and getting Telescope to a state where things don’t break too much. It was also one where we tried to do some soul searching for Telescope. One of those goals was more successful than the other.

  • Issue:#853 |PR: #854

    Telescope has a drawer that works now.
    I’m glad that we decided to use material-ui, as I’ve probably mentioned before, it does make creating a working interface much easier.
Initial work for drawer

The documentation for material-ui was a great asset. It made adding a drawer a very painless process, and there wasn’t many lines of code that needed to be added to achieve this. Customizing the drawer was the most difficult part, while I got the drawer to an acceptable level, there are still some tweaks I want to work on but will need more research to be able to achieve it.

The documentation I read can be found here, under the Temporary drawer section, and the code to bit of code to achieve the functionality can be read below.

// This code goes outside of the return() along with the other const variables  
const [state, setState] = React.useState({
    right: false,

  const toggleDrawer = (side, open) => event => {
    if (event.type === 'keydown' && (event.key === 'Tab' || event.key === 'Shift')) {

    setState({ ...state, [side]: open });

  const sideList = side => (
      onClick={toggleDrawer(side, false)}
      onKeyDown={toggleDrawer(side, false)}
        <ListItem className={classes.item}>
          <Link to="/search" className={classes.links}>
        <Divider className={classes.line} />

// This bit of code goes inside the return()
  classes={{ paper: classes.paper }}
  nClose={toggleDrawer('right', false)}
  • Issue:#827 |PR: #851

    This pull requests makes sure Telescope has a <title> so the tab can provide more information that simply “;

    In order to achieve this, I followed GatsbyJS’s documentation about SEO components. While I could have done other things, I felt that at least setting groundwork for SEO information can improve Telescope so it is easier to navigate, faster, and more user-friendly.

    This pull request required some fixes so that we re-used already existing code and so that my debugging console.logs() were removed.

    The documentation I followed can be found here, and the blog starter I used to help me with the layout was the gatsby-starter-default, more specifically the SEO component.

    The code for Telescope was as follows:
import React from 'react';
import PropTypes from 'prop-types';
import Helmet from 'react-helmet';
import useSiteMetadata from '../hooks/use-site-metadata';

function SEO({ description, lang, meta, title }) {
  const siteMetadata = useSiteMetadata();
  const metaDescription = description || siteMetadata.description;

  return (
      titleTemplate={`%s | ${siteMetadata.title}`}
          name: `description`,
          content: metaDescription,
          property: `og:title`,
          content: title,
          property: `og:description`,
          content: metaDescription,

SEO.defaultProps = {
  lang: `en`,
  meta: [],
  description: ``,

SEO.propTypes = {
  description: PropTypes.string,
  lang: PropTypes.string,
  meta: PropTypes.arrayOf(PropTypes.object),
  title: PropTypes.string.isRequired,

export default SEO;

I had to add the SEO component to each page we had, and we will have to add the component to every page we make so the Tab can be more informative. But it is a simple <Seo title=”Title” /> so that our tabs are better.

New and Improved!
  • Issue:#771 |PR: #776

    This is where I removed the famous pants that gave the name to our release. Lots of useless files were removed and as a result the code was cleaned up a bit. No tutorials or documentation to follow this time. Just figuring put what was being used and what was not.
  • Issue:#769 |PR: #777

    This fix revolved how the then-new header looked once logged in. The original fix did not take into consideration login state, so nothing was styled.

The fix was mostly CSS and material-ui themes. Currently, I can’t access the logged in site, but my fixes were approved, so I will assume it looks wonderful.

File an issue if it doesn’t.

  • Issue:#804 | PR: #852

    So this is where we find that Telescope soul searching wasn’t as successful. I have not really found how or what should go on the about page, much less how it should be organized. Part of this is a result from some issues that occurred while trying to film a promo for Telescope. Day 1 of filming turned into the the only day of filming. While I try to salvage any footage, I decided to add the page meanwhile. I do not want a repeat of the search bar.

    Components ready to be used but nowhere to put them.

    Now…to make those components…

    I hope that I will be able to get a sort of routine during these uncertain times. I hope I will finish all that I need to, both for telescope and for my other school work. But most of all, I hope I get cake somehow.


Along with with writing and the arts, I have always enjoyed languages. I like the patterns, the similarities, the differences, and the coincidences. During the past summer, I realized it was the first time in two years that I didn’t have anything to do. Four whole months where I could actually work on my hobbies without thinking about deadlines or grades. The perfect time, or so I thought, to give learning a language a shot.

Things got out of hand. Quickly.

To make a long story short, I added way too many languages to my Duolingo app. Among the many, I had Japanese and Russian. They were the only languages I chose that had an alphabet different from the Latin Alphabet, but was my experience with both quite the opposite!

The Japanese module started with you learning hiragana, one of the building blocks of the Japanese writing system. You would learn a character set, words you could make with that set, and then when it came to test your knowledge, you could click on the nice tiles and be done.

Image result for duolingo japanese
Duolingo Japanese Modules

Russian wasn’t like that.

When I decided to do Russian, it threw me right in, with no explanation of the Cyrillic alphabet. There are 33 letters in it, and not many of them sound the way you would expect.

Image result for cyrillic
See the P? It’s not our type of P

I did my best, but it is not easy to write something when you don’t know what each letter sounds like. Unlike the Japanese module, I actually had to type and spell. Which meant I had to get a Russian keyboard for my phone.

Eventually, I realized I could only get so far. Sure, I could wing certain words, auto-correct saved me a couple of times, but there was a lot of fundamental knowledge that I was missing. The more words I learned, the harder it was to remember them all. The more I tried to move forward, I would be stopped because I could not spell.

It was the realization that made me give up on Duolingo. That, and the fact it made the process into one about gaining points. Learning and understanding become secondary when there’s a number you need to gain.

You might be reading this, wondering what it has to do with my progress with Telescope, and well…

Much like I lack the Russian fundamentals, I lack the fundamentals of a big part of web development. I’m currently at a place where I am stuck, hacking away hoping something sticks. Up until recently, I dealt with problems everyone else had dealt with because they had been problems in our assignments. Now, working with Telescope, and all the stuff it interacts with, you can’t really go to stack overflow and find an answer.

It feels difficult asking for help, since I feel that I should know a lot of what I don’t. It doesn’t help that the more the project grows, the more daunting it becomes to learn. I didn’t exactly set myself up for success either, since I signed myself up to work on a complicated, for me, area in my capstone project for my first milestone. Too much research to do, too little time.

My first issue and pull request for 0.6 were very easy; adding a react version to the eslintrc file.

PR: Added react version to eslintrc file | Issue: React Version Warning

What I did:

  1. Added settings to the eslintrc file that specify the React version to
  2. Prevents the warning about React version not being specified

The code:

settings: {
    react: {
      version: require('./package.json').dependencies.react,

Where I got the fix:

Warning: React version not specified in eslint-plugin-react settings

My second pull request wasn’t.

Issues: Add static route to serve new GatsbyJS frontend | Add building frontend for staging and production deployment

Pull Request: Point / to the gatsby public folder

At first my issue was that my machine could not run docker. Well, it can, it just takes a toll. I can only have VSCode and one firefox tab open at the same time. Usually, when I’m coding, there are at least 7 tabs. It didn’t help that my capstone also had a milestone going on at the same time, and that I was working on the frontend. I couldn’t do all of them at the same time, and I tend to push projects to the side when I don’t feel confident.

Eventually I realized I could work on what I was doing without Docker – my capstone milestone was passed, Telescope’s design was frozen – so no more excuses. I read a lot, but it was more to rule out stuff than anything else. At the end, I ended up adding this code to the Gatsby side of things.

What this code does, its to create a proxy on localhost:3000, where our server is, and process requests.

My problem arose from the fact that I could only successful point the server to the public folder, which only appears once you build gatsby, which was not what we wanted. We wanted to be able to see the changes made to the frontend in development mode immediately. No matter how much I researched, I couldn’t find anything. I also didn’t know if I should change any of the routes or if I needed to make my own. This was probably my first time looking at Telescope’s server, and I’m still not quite sure at what a lot of it does.

Eventually, we decided to just point to the public folder and have docker build Gatsby automatically. I also added that code, with a lot of help from David and Josue, which you can see below.

This was my first time dealing with Docker, which was interesting.

Going forward, I want to do more work implementing the frontend. I feel that I will be able to work on more issues that way. I also have a better understanding and a better base, which will free up my time to review more pull requests. I feel like I need to do more reviews, and I’m often too busy working on my own issues to do reviews.

Despite the difficulty, I’m glad I decided to continue working on Telescope. The benefit of deadlines and grades, is that you need to do work. And in order to get things to work, sometimes you need to learn. At I’m still trying with web dev, even if the same can’t be said about Russian.

Speaking of Russians, turns out that while we were working hard for release 0.6, Telescope suffered an attack from a Russian and Ukrainian IP. Can’t say I expected that.

Aside: Black Hole of Time

When I started working with Telescope, I didn’t want to.

I’ve never been the best coder, nor I felt comfortable with open source. So when it came time to start setting up Telescope, I had no clue about what should be done and I didn’t want to go into any of the discussions. There were about 60 people all desperate to file bugs, and way fewer who knew what they wanted to do and had very strong opinions about it. I might or might not have also redirected all the emails from GitHub into their own folder in my email. To be honest, I can’t say coding is my passion. I think its neat when things work, but I don’t “eat Java for breakfast.”

There had been a discussion about the what technologies we should use early on. I didn’t care for it. Not until I found Gatsby – and at this point I’m starting to feel like an ad. I like working on the front-end and designing interfaces, it is combination of the accomplishment I feel when I code something successfully and doing graphic design. I wanted to work with the fronted of Telescope, it would be something that I knew and could lead on.

And so we’re here.

For release 0.6, I finally started designing.

I did some research about modern design, determined to bring Telescope away from the 90’s vibe. With Adobe XD, I soon spend way too much time on it.

For the first iteration, I made a hero banner, main page, and a menu drawer.



After the initial design, the discussion moved away from the main telescope repo to a team discussion that can be found here.

Some of the feedback was:

  • Smaller paragraph width
  • Smaller navbar size
  • Having author and date visible
  • 21px for main text
  • darker colours

From that feedback I made some improved designs:


One of the problems I ran into, was that the blog section was too small. There was too much white space surrounding the blog, and adding another blog besides it would not bring an optimal reading experience. So I decided to add a participant section – mostly as a place holder – to balance the content.

Afterwards, I took an on-demand edit approach to the feedback I received.


Eventually, I decided when the design should be frozen. I also realized that an on-demand approach is not particularly good way to deal with feedback. Specially since I wasn’t letting people know my design decision. Going forward, I would like to implement a better system about feedback on designs, as well, as one about posting the designs.

I found that the current way is not great for following conversations, and it doesn’t allow people who aren’t on-line at the moment to give any feedback.

Overall, I’m happy with what I made and I’m looking forward to doing more designs.

2020/01 Collection: Working on Telescope


“Something just flashes into your mind, so exciting, and you must out with it. If you stop to think it over, you spoil it all.”

L.M. Montgomery

I spent my three weeks off deliberating whether to take the class following DPS909. On the one hand, I enjoyed the experience it gave me…on the other, there weren’t a lot of projects I was interested in working on. While localization helped me last semester, it took a while to get pull requests accepted and there weren’t that many projects that I could find that still required Spanish translations.

Additionally, there isn’t really a way to improve the quality of my requests, other than through volume…and I have my limit when it comes to editing.

So I was at a cross roads. I already had the six courses required for my sixth semester. I already took a professional option course. I didn’t need to take another open source class, I could just move on and do open source on the side.

And then I showed up to the first class.

Half an hour in, I was registering myself in the course. What can I say other than humphd made a very convincing introduction to the course?

My goal for the semester would be to work on the front end of Telescope and use my creative skills so that the UI looks as best as it can.

Fast in every way that matters

“‘How did he happen to do that?’ I asked after a minute.
‘He just saw the opportunity.'”

F. Scott Fitzgerald

When I decided I wanted to work with the front end, I knew I wanted to use GatsbyJS. I had only done translation for it, but I wanted to use it and Telescope was the right opportunity for it.

GatsbyJS is a React-based framework that generates static sites. It utilizes popular web technologies such as Webpack, GraphQL, ES6+ JAvaScript, and CSS. This allows Gatsby to not have too much of a learning curve as it is made with technology that programmers are familiar with.

Gatsby also has a big community and plugins that allow us to use already made solutions rather than create our own for scratch.

Furthermore, as an increasingly popular framework I thought it would be good to implement it and use it. It felt like valuable experience and worthwhile for the project.

How I Learned to Stop Worrying and Created a Gatsby Site

“To learn something new, you need to try new things and not be afraid to be wrong.”

Roy T. Bennett

For the second week, I decided to learn the basics about making a Gatsby site in order to convince the rest of the team that Gatsby would be a good fit. The process what’s pretty easy, and while css is never entirely painless, I felt pretty good after making some quick sites. I go in to more detail in my blog post about creating Gatsby sites, which can be read by following the link in the title.

An Unexpected Journey

“The great enemy of communication, we find, is the illusion of it.”

William H. Whyte

The day was Wednesday and I was ready to add Gatsby to Telescope. A simple “Hello World” starter from the Gatsby docs would be more than enough to get the team started with the front-end. I figured a bunch of issues could be filled out after the blank slate was merged and I could get the ball rolling.

Having gone through all the issues during a triage meeting, I saw that there were a few contributors eager to help with the font-end and the UI. Issues #511, #512, and #513 made me optimistic about being able to have a good interface by the time release 0.5 came about. After all, the strength of open source was the numbers. The many can do more than the one.

It…didn’t quite worked out that way.

When I looked at the Telescope repo that Wednesday morning, I noticed someone else beat me to it. A pull request that read “Initial frontend work for GatsbyJS app.”

It was then when I first realized I needed to communicate more about what I was doing. I had realized some time before Wednesday that I needed to keep up with the conversations going on Telescope – as I had missed important discussions about how we wanted Telescope to look.

But just reading and giving your opinion is not enough. Communicating what you are doing and what you are going to do are also important.

This was only the beginning.

The initial template from the pull request looked like so:

While not the “Hello World” starter I had in mind, It looked like a good base to start with. Besides, I never told anyone how I planned to start the front-end. As far as I’m aware, there are no telepaths working on Telescope.

However, there were some changes requested and it did not pass the tests. This meant we could not merge the pr, which was disappointing as I wanted to work on the front-end ASAP. There was a week left for release 0.5 after all.

I regularly checked the pr hoping to see some changes, ready to review and merge, but nothing really happened until two days later.

It was Friday.

Seeing another comment made me happy. The too red x beside the title of the pr? Not so much.

While the pr had been updated, there was no response to any of the changes requested in regard to the failed tests. This was yet another failure in communication, but also one due to our lack of knowledge about ESlint. I’ll return to this point later, though.

The updates have been changes to UI, so now the interface looks like this:


The weekend passed without any comment. And I admit, it is frustrating to look back and see how much time had passed, and how little I asked for updates on the UI. Because, not only was this putting us behind for release 0.5, what was I going to do for my release 0.5?

I couldn’t work on code that had yet to be merged. At least, when it came to the UI.

It wasn’t until Monday that I talked about the status of the pr and laid out a plan of action. It needed to be a priority – at 5 days, it was the oldest pr of the semester and it was halting the development of the front-end. Additionally, going forward, small issues would be issued to better utilize our contributors, and we’d use Adobe XD for prototyping and getting feedback on the designs.

When I checked the pull request later on Monday, more changes had been requested and the status remained red. Luckily, the changes were more nits that could be worked on later on.

On the Tuesday, @humphd filed an issue to “Add static route to serve new GatsbyJS front-end.” I signed on, and started working on it that afternoon. I was not sure what I needed to do, and the lack of a Gatsby site meant that I couldn’t quite test out what I was learning.

So I decided to make a test site to work on my issue, I had waited long enough. It was then when I finally realized why the other pr kept failing.


Telescope is the only project I’ve worked on that uses ESlint. All my test sites have been made without it, and I had never looked into what ESlint did or how it worked. What I’m saying is that it had never been and issue.

Until now.

So I filled and issue. I waited about 10 minutes, and then assigned the issue to myself. Might as well do something outside of my comfort zone, right?

You can read more about how I dealt with that in this link, and you can see my pull request in this link.

So after all that time, ESlint tests failed the pr because we hadn’t added a React plugin.

Finally, today, Friday January 24th, the pr was merged. Telescope has a new front-end!

2020/01/25 02:03:14 EST

The past three weeks flew by.

A blink, an another day passes by. It certainly doesn’t help having a computer that loves taking its time to run anything. Neither does scrolling through reddit, if I’m honest.

My contributions weren’t quite what I expected. Though I admit, I still learned quite a bit, though not all was technical knowledge. If anything, I now know how much time can be wasted through a lack of communication, or by not being on the same page.

We all have different priorities and different projects we want to work on, so not only is it necessary to speak up, it is necessary to make sure you are understood.

Also. Following up on people is better than just silently anguishing.

On the bright side, I feel fairly comfortable working with Gatsby and I’m not afraid of touching the ESlint file anymore.

However, there is a lot for me to work on for the next release.

It’s fine :’)

How I Learned to Stop Worrying and Created a Gatsby Site

When I first thought about using Gatsby, I did what I always do when doing something new: I overthought it.

I spent too much time reading about what Gatsby was and what Gatsby could do, and where you could use Gatsby…instead of making a site. Sometimes, the best way to learn something, is to do it. Theory can only get you so far, and you can only show off so much with theory.

For about a month I did nothing, and then when I volunteered myself to work on the front end of Telescope, I had no experience. I had to fix that quickly, so I could convince everyone else working on telescope that we should use Gatsby.

How to start a Gatsby Site

The first step in creating a Gatsby site, is to install the Gatsby CLI. According to the Gatsby docs site, the CLI is “the main entry point for getting up and running … a Gatsby application.” It allows you to run all the commands you need.

To install it globally you need to run:

 npm install -g gatsby-cli

if you want to see the commands you can use, you can either check the Gatsby docs site, or using the CLI run:

gatsby --help.

Installing it in my computer didn’t take long, unlike the other process, so that was nice.

After installing the CLI, you have some options. If you use:

 gatsby new name-of-project

then the site generated is the default Gatsby theme. It looks like this:

You can find the repo for the default site at gatsbyjs / gatsby-starter-default

Gatsby also offers other official starters, which you can use by using the new command and the url of the git repo. For example:

gatsby new your-site

The starter site templates offered by Gatsby are:



Perfect for a blank slate

gatsby-starter-blog-theme and gatsby-starter-theme-workspace are also available themes, but they do not have a demo available.

You can use other templates that are not starters or you can make your own, to install them it follows the same principle as above. Using the new command and the URL of the repo.

For my practice side, I decided to use the default starter because my React knowledge was rusty. It took a good day, but I got the hang of it and was able to rearrange a site the way I wanted.

While most of the process was similar to building a React app, I found the way to generate a dynamic navigation bar interesting.

In order to do that, you need to go into the gatsby-config.js file, and add menuLinks to the site metadata.

module.exports = {
  siteMetadata: {
    title: 'Gatsby Default Starter',
+    menuLinks:[
+      {
+         name:'home',
+         link:'/'
+      },
+      {
+         name:'page2',
+         link:'/page-2'
+      }
+    ]
  plugins: []

By creating the navigation link this way, you can use GraphiQL to make requests, like so:

The query will return JSON objects with the links (

File Structure

But I’m getting ahead of myself, after you run gatsby new, you should be aware of the project structure structure.

A possible file structure, (

While you can find a more thorough lists of files that are generated for a Gatsby site in the docs, I will focus on the ones I spent most of my time on.

/public – Is a folder generated when the command gatsby build is ran, inside it you will find the files you need to host your site.

/src – Is where you will write the code for your front end. It’s where you will find folders for your pager or your components, among other things you will see on your site.

/src/pages – Components in this folder are pages with automatically created paths based on the page name. For example, a file named lab.js will be found in the path “/labs”. If you want something like “labs/lab-1”, then you would create a folder in /src/pages named lab, and inside it you would create a file named “lab-1.js”

gatsby-config – Meta information about the site can be found here. This where we put the menuLinks for a dynamic navbar, for example. This file also can include information about the plugins used, or where you would specify a path-prefix. For more information, the Gatsby docs are a great source of information.

Seeing What You Have Made

If you want to see how the site looks while you are making it, you need to run gatsby develop. On my machine, the first time run develop when I open my project, it takes a really long time (about 5 minutes or so) . While the waiting time does go down the subsequent times, it still is a bit of a wait.

The upside is, you don’t need to run gatby develop every time you update anything on your site. After saving the changes, the process is reloaded and you can see the changes in localhost:8000.

Once you have completed your site, you can run gatsby build to generate the public folder files that you need to make your website go live. If you want to run the website based on the public folder files, you need to use gatsby serve.


After my first attempt at blog with Gatsby, I also made a portfolio site for another class, which also took me about a day.

My experience had been fairly positive and painless, which made me I feel like Gatsby would be great to use with Telescope, as it is fast to create a static site, and there is a lot of templates that can be used. This allows telescope to look good, without having to spent too much time on insignificant details.

“As for me, I am tormented with an everlasting itch for things remote”

Now that I have no deadlines looming over my conscience, I can look back at my work over the past four months and reflect without the pressure to look for the next big bug.

My first experience with open source, was filing issues on my classmates’ text-note editors. It had been simple code, and it had been code that I had also written. On the blog post, I mentioned how through coding my own text-editor, I had found a bug. One that I was able to see replicated in several repos.

I had been optimistic in that blog. I mentioned a new-found confidence, that while real…it was one that would not last.

The problem was, that I would not have the same experience ever again in the next four months. There would not be a bug that I already found through my own work. That is not to say that it is not possible, but given the few side projects I work on and the scope of the repos I wanted to work with…

That was impossible.

I didn’t want to work in some programming student’s practice website. I wanted to work on a popular framework, on something with a growing community, something I could see myself continue and better my coding with.

It was with that mindset that I rapidly made my experience hell. Because while working on big projects is not a flaw…wanting to find the issue while working on a big project and no experience is.

I admit I fixated too much on finding the issue. I wasted hours looking for something big, rather than doing anything. I clicked page after page, rejected issue after issue, ignored repo after repo, because I wanted to find something that was just right. Even after finding time and time again, that it was impossible.

Doing several small fixes is miles better than not doing a single big one.

And sure. Good first issues don’t really help you grow, but they do expose you to a greater pool of skills. If I had realized that sooner, I might have had an easier time working on a repo I liked. It is easier to find something to work on when you are not stuck looking at only three projects.

Sadly, it is not something that I truly realized until I was desperately looking for something to work on for my last and final issue.

Repository: ruby/www.ruby-lang.orgIssues: 2244 | 2248 | 2249Pull Requests: 2299 | 2300 | 2301

This repo is the Jekyll source for the Ruby language. While it is a language that I have never used, it is one I have heard about.

I did another round of translations and I have to admit, a benefit of doing these, is that it exposes me to a lot of frameworks and languages I would not have otherwise worked with because I don’t know enough about them to code with them.

This time around, I did some updating of the documentation rather than full on translating. It still made me realize I prefer translating to English, though the reasons are very shallow.

Tildes. And 100% solely because English doesn’t have them.

I spend a lot of time copying and pasting from google translate because apparently everything has a tilde and it is faster to use translate than to have use the keyboard shortcuts.

…Also because I always miss one, and I’m so tired of making edits.

for example, the shortest translation required me to change five words (four because tildes) and I still managed to miss two. Moments like these remind me why I never went into professional translating. I don’t nearly care enough about grammar.

Which kind of connects why this section is about Ruby, and not a continuation of Gatsby. I do like working on Gatsby…It is just that my grasp of the formal you is not very strong and I’m still working on editing that page. Gatsby-es only allows you a page at a time, so that’s that.

Despite my weak passion for accurate spelling, I am glad these repos have people that do care, because they allow a greater pool of programmers to read, work, and contribute to these projects.


Repository TelescopeIssues 482|354|316Pull Requests 484|481|320|

Working with SAML was interesting.

With my first pull-request, I hadn’t really needed to work with anything other than the HTML. It had been very easy to ignore everything that was being added to the project. After linking the login with the main page…I could not anymore.

In order to be able to do what we wanted with the SAML, we needed to run docker and understand what it was doing. The gist of it, is that Docker runs like virtual server that allows of us to programs like Redis and express at the same time. Docker would also take care of SAML and how it would connect once we coded in the express routes.

In order for SAML to be implemented, a greater level of communication and collaboration was needed. We were not experts on docker nor had we payed attention to it while it was set up. After being point to the right person, the whole process went more smoothly.

I had initially filed an issue to use my mock login page, but after learning about what Docker did and more about SAML, we learned that we couldn’t use my page. The user should be redirected directly to the page in charge of the authorization. So while the routes were being set up to support that, I made sure I understood what was going on so I could make some documentation so other people would be able to use what we were making.

Overall, the course was a positive experience. I learned a lot of practical skills, and while I can’t say I always did the best coding, working on open source was incredibly valuable and I would love to continue in the future.

The Final Countdown

As the semester winds to a close, it means Telescope should achieve some sort of workable iteration. While it seems daunting, the fact is, 60 coders coding away should be able to make something that works.

I have to decided to focus my energy on authentication, and while some of my classmates are figuring out the bigger picture with SAML, I am doing the smaller steps to get login working. It is easy to get carried away with a big project and spend too much time planning instead of getting something done.

For example, this week I connected the login page with the main page. It is not a big fix, but it is necessary to be able to test login and make sure it works with what we have made so far. After getting the fix merged, I decided to get a rudimentary express login started. I filed the issue and I have been reading about how to code it with what we currently have.

What my fix would do, is that it would allow people to login, be redirected to a confirmation page, and then back to the main page. This will allow for the SAML project to move further along.

My steps after getting the login merged will be determined as I discuss the SAML process with the others working on it. While that happens, I decided to take a further look into GatsbyJS, as it would be a good idea to integrate it with Telescope. As Telescope is a static page with a collection of blogs, it could really benefit from the React based framework. However, I would first need to convince the rest of the team that it is a worthwhile effort.

Speaking of Gatsby, my contribution with the Spanish localization has been going so-so. My first pull-request has yet to be merged and I’ve had trouble setting aside some time to fix the problems. With the semester almost over, assignments for other classes have begun to pile more than usual.

It does not help that editing has never been very appealing, much less when you have to keep formal and informal you’s in mind. I initially thought the only thing I needed to change was the pronoun.

The naivety…

So this week I will continue to fix the errors of my past. Hopefully I will finally get my pull request merged so I can work on more pages. I am hoping to get a shirt out of it by the end of the semester.

It will look really nice besides my hacktober one.