DEV Community: AmasiaNalbandian

Breaking the habit

AmasiaNalbandian — Mon, 11 Apr 2022 04:18:16 +0000

This week I broke.

After spending numerous hours investigating and attempting to make the requests stop onTextChange, I decided to take a leap and start rewriting this to make it work. The main problem that I was facing was that author and posts both had their own component, but shared the same Input Component. There were many layers involved in the search to be quite honest, which was making the submit event more complicated than it needed to be.

When looking at the code, I realized everything needs to be in one place only - the Searchbar.tsx. So I started putting all the states for the inputs there. Then in this PR I had to integrate the props for the input. So I passed the text field to the SearchInput.tsx where it would determine whether it would be for author or post. This I thought was a bit of duplicate code. In fact, AuthorSearchInput.tsx and PostSearchInput.tsx are identical files. I removed it and made a reusable Input file instead. We would just pass down different props depending on the input field it was for.

I made sure the input box would only have to handle the input. We don't need to complicate the UI here. This means that the submitHandler is now in SearchBar.tsx. Do you see where I'm going with this? The last piece of the puzzle is the states which I also put into SearchBar.tsx. So what I then did is I passed those states down to the input component, as I had created props for them in the input. This means that ultimately, all control for the search queries is now in SearchBar.tsx only. This made things MUCH easier.

I cleaned the rest of the code up, and put up a pull request, describing the change to be required to complete the UI for the Search Bar. I was lucky the next day we had a triage and was able to explain what the PR was for to my peers and how it was just to make sure the search behaved the same way, nothing new or complicated. That earned me ✅✅ in 24 hours (personal record)!

Another reason that I got reviews might have also been that by breaking habit and moving code around, I also removed more code than I wrote.

Unblocking myself

Since the PR I needed was put in, I started to continue working where I left off. As I mentioned in my previous blog post, I had just created a new branch with all of my new UI changes. I rebased that branch, since it already had included the migration of the project. From there it was extremely simple - because I had already tried to implement various ways around the code before I changed it, I knew exactly how to plug everything in.

Ok now that everything looked great, I had to come back to my main problem. I avoided the big rebase in my first PR, however I needed to now get my code from the new branch in. What I did was I took my branch with the PR, let's call that PR-branch. I removed all the commits I had made on this PR. Then I rebased the branch. This rebase was obviously a lot easier since I had no commits. Next I made sure both branches were rebased to the current master branch. I then just merged my newbranch to my PR-branch. It was so easy and so smooth! When I had successfully done all of this, I felt that I had really mastered Git enough to be comfortable doing risky hacky things like this.

Now again, we sit and wait for some reviews - I am hoping for a clean PR, but we are human. I do want to push this in ASAP, and therefore will recall my previous tactic that if I get any feedback I need to address it right away so that my peers can review it again while their workspace is setup.

Sheriff 2.0 for release 2.9

AmasiaNalbandian — Sun, 10 Apr 2022 23:34:27 +0000

This week we've circled back to being Sheriff! I really enjoyed my first time being sheriff, however this time I am extremely anxious and nervous.

Why I am anxious?

Last week, as we entered our first week of the release, we had many issues to tackle (as all previous releases). However this is the first time I am seeing there remains 70 issues left open 4 days before the release. This has made me extremely nervous for myself but my peers also. Are we going to be able to deliver 70 issues? We should probably ask if we are going to be able to review 70 issues in 4 days instead... Probably unlikely?

By the time we got to Thursday when I was going to do the Triage, we had it down to about 40 issues without any PRs. This didn't help me at all because at this point we were one day away from the release, and I knew we would have to shift a lot of stuff over. I tried to keep the pressure on, and look past the fact it was one day, I've seen miracles before...

Sheriff Duties

The plan

Release 2.9 is going to be shipped by Jerry and I. I was really excited to see we would be able to work together again after he helped me learn some Rust last semester. For the triage, he would lead it and our goal provided to us was to "Ship new code, any bugs or documentation should be moved to alpha." We moved some issues in Triage to alpha, which was good to organize.

Reviews

Below is a list of PRs I reviewed this week:

My contribution

My work on the search bar was not done yet. Since my last post, after I made the updates, I had received more feedback about the search being triggered by every key change. I tried my best, and even tried to implement the useEffect to catch when it should be sending the request, however, because of the way the code was written, it became really difficult to successfully implement this. Half way through this week, we also decided not to wait to merge Move frontend from src/web to src/web/app which meant I would have to resolve a conflict. When I went to rebase after the merge I made a mistake and forgot to squash again. However for some reason I had many files to go through and I figured to just start a new branch to then merge.

I also started redoing the UI as was suggested by Dave. So the idea would be to have something that behaves as such:

For the UI here, I decided to make the input the same across all and pass it props instead. This would mean all the input boxes would be more uniform. As I discussed last week with my design, they look identical now.

Release 2.9

As we usually know, every release there is a problem. For this release, we had some mysteries to uncover. When Jerry and I went to create the release, I accidentally created a patch tag instead. I used pnpm version patch to release, forgetting that this was not a patch but a minor. After we reset head and removed the commit, then deleted the remote tag, I created the new version as a minor and pushed. This time we had the pleasure of pushing the local tag again. So we went back and removed that. When we went to view the build, we saw it had failed. There was an error about how the package-lock did not match the current pnpm-lock.yaml. This was a big problem. How did our CI not detect this? After a few hiccups, we put up a new package-lock and were able to successfully build the new release. So although there were some problems, nothing major - because after all this was a minor release. :P

Accepting Good Feedback

AmasiaNalbandian — Sun, 10 Apr 2022 20:54:50 +0000

This week I want to talk about all the feedback I received for my PR about the searchbar UI. I had some really good reviews, and we caught a few bugs that almost got by. Here are some of the feedback I got:

Responsiveness of the advanced search button and input:

Our color themes for dark and light mode:

My reaction:

Responsiveness:

I really don't want to say anything on this because how disappointing it is to me. I guess at the beginning I added the button and made sure the click event worked to open up the advanced tray items, and then I forgot about it (seems very me).

Color Themes:

The color themes were something I had never had to consider. Surprisingly, for all the work I had done to this day, I have not run into this code yet. I look forward to explaining how it works down below! :)

Addressing my issues:

Responsiveness:

This wasn't too difficult of a task for me. I am really lucky to be able to understand how the grid/flex system works now and was able to apply my knowledge on this here. Another thing I forgot had existed was the float property. I love this property for making elements sit where they need to sit without having to play with so much other props.

Color Themes:

We use MUI for the color themes. Having worked with themes previously on another project I got the jist of it. Basically we are creating our own themes for colors to use. So every time you want to use that blue color you find relaxing, you can put it under a name and use it, instead of you know... "what is the HEX code again???".

When I started, I put my own color name telescope-blue for the color of the telescope logo. From this I was getting many errors. I learned that I can't just name telescope-blue and that I would have to specify this name as a palette in the createPalette.ts. So if you want to go with this approach - by all means. Otherwise you can use the PaletteColorOptions provided by MUI.

I decided that the info color is usually blue, and that I could define the color of blue for this as our Telescope blue. I explored some good color contrasts for the hover states through trial and error, and came to consensus with the new theme.

One of the other problems I had was understanding how the MUI Textarea worked for adding custom CSS. To explain this I will first show the code I ended up putting in:

        <TextField
        variant="outlined"
        size="medium"
        fullWidth
        label={labelFor}
        onChange={(event) => setText(event.target.value)}
        value={text}
        InputProps={{
          classes: {
            root: classes.customInput,
            focused: classes.customInput,
            notchedOutline: classes.customInput,
          },
        }}
        InputLabelProps={{
          classes: {
            root: classes.customInputText,
            focused: classes.customInputText,
          },
        }}
      />

There's two props we see here InputProps and InputLabelProps. They are different.

So InputProps is the CSS props for the input itself. Whereas the InputLabelProps is the props for the label where it says "Look for an Author". After a lot of trial and error, I realized we can set different classes for focused, but adding classes.focused. Lastly, to change the color of the border we use notchedOutline.

One other issue I ran into here with this was that if you make the fontSize of the two InputProps and InputLabelPropsdifferent, you run into some overlapping with the label and the round border.

After pushing my changes...

After putting up my changes, I am really excited to get this PR in. Although for now it's only the author and post search, it still makes a difference and you can refine the search by BOTH and not just one anymore.

Preparing for Burn Out

AmasiaNalbandian — Sun, 10 Apr 2022 20:04:50 +0000

As we start to embark the end of our journey for Telescope 3.0, there are some things to begin thinking about to prevent burn-out as we get close to the finish line. In every team, to be successful there has to be a good balance between give-and-take. To provide some insight to this, we can look to these 5 questions provided by Dave:

1. Which part of Telescope 3.0 do I own?

Finding out the answer to this provides some insights to what kinds of issues/questions I should be participating in. I should be more present in discussions about these topics to not only help educate others who are new, but to keep myself updated on the new changes which might come.

From previous blogs, I've done a lot of work on the Search bar, and search service. I would say anything related to the search functionality I could definitely help out on. As we start exploring new issues such as autocomplete, I should keep myself updated on how the Search works and what code has changed.

2. Which existing Issues are part of this? Which new Issues do I need to file in order to properly describe the work? When will those issues be filed?

Although this is really 3 questions.... I will argue it is one. If you've ever come across S.M.A.R.T. goals you would notice the pattern immediately. We need to start addressing S.M.A.R.T. goals (our issues), in order to successfully pave the way.

It's funny timing, because in my last PR I talked about how I was already breaking up the search UI into smaller issues. I can imagine for my case, I might need to do some more issues as we come across them. However, I will summarize what I mentioned in my last post:

These are all the open issues we have right now to complete the advanced search bar. In addition, I know that Roxanne is exploring autocomplete for the search bar.

3. Who can I depend on for support in development, debugging, testing, and reviews? I can't do this alone.

This is always the hardest question. Personally, from experience, it is difficult to depend on others, but I've learned in this field - you NEED reviews. In addition, this question is extremely important. If we don't have a good idea of who we can turn to for support, we usually will get stuck and make no progress. Therefore it's important, to be successful, to prepare for everything.

In the upcoming weeks, I am hoping to depend on the sheriffs for reviews(debugging, testing etc). In addition, I know I might run into problems with React Syntax so I am really hoping that if I write on Slack someone will be able to help - as has been the case in the past. However, I will probably continue to add Roxanne and Jerry to the PRs as they seem to be engaged in this area as well, and it will help keep them up to date with the changes I am making.

4. What are the risks that I see, which could prevent me from getting this shipped?

This question prepares us for any "grey areas" that we might need to prepare for. For example, in the last PR I posted about the searchbar, I already have some concerns I am seeing that I can't seem to address easily. For example:

Updating the search after any character change in the input fields (very wasteful).
Implementing an onEnterKey press.

Additionally, we always have the usual suspects of development:

Waiting for PR reviews
A service breaks

So for now I have those four, but because the search is complex and touches most areas of the projects, I can imagine I might get blocked again by more.

5. How will I mitigate these risks?

In order to prepare better for our potential risky areas, it's important to have a game plan. We don't need to have a solution right away, but an idea of what you need to do in order to waste less time. A great example of this is when you go to a soccer game. You're going to bring a first-aid kit. You have no idea what might go wrong, but you have a strategy and some tools for when you do.

One of the more recent things I've noticed working in this project is the best way to work is to move your code quickly. You get feedback on your PR, address it right away - and put it up to get another review. It's easier for others to review 5 times in the same day, than 5 times in the same week. Therefore one of the ways to mitigate risking long PR review processes, is to keep updating your code after the feedback you receive.

As for the grey areas, for the first issue about the character change, if I can't figure something out, I will probably have to make another PR to clean up the code to make it work better (tie it up differently). For the latter, I imagine the React syntax is incorrect, and I need a peer to help me review this.

Conclusion

In summary, after writing this post I see a clearer image of what is to come in the upcoming weeks. I can feel more at ease, as long as I stick to the plan.

Keeping it short and simple

AmasiaNalbandian — Mon, 28 Mar 2022 20:16:56 +0000

Continuing my progress in the Telescope repository for Release 3.0 my Search bar PR from last week got some reviews. Unfortunately, I was not really given any "feedback", aside from being told the PR was too big, and to split it up.

Hearing this was extremely disappointing. A part of myself thought I was over splitting this issue any further - yet we've managed to come across this thrice. There's no way to separate the UI from the backend anymore - the backend is all ready. So what I've done to remove the old search bar UI more easily is I have put functionality for ONLY author and post search. In another PR I can add the rest of the fields (i.e. title, dates).

In my new PR, instead of tackling all four issues, I only decided to tackle one. Which is the UI for the search bar. In this PR, I will address new UI for the existing fields. In the second PR, I can address issue 2894, where we can search by new fields, date and title. Both of these PRs should build on the last issue, issue 2110, which is for the advanced search dialogue.

Unlike my PR for search, my previous PR for the translation services got a lot of feedback. I got a lot of feedback on my code, which was nice, but some of it was being nit-picky so I decided to put my foot down. There were a lot of complaints about the UI. I understood the issue, however, the PR was never meant to address the UI for this. I ended up creating a new issue for this. To be honest, I really do not like MUI and would prefer not to have to tackle this. We are using an older version of it, however, there is not much customization.

Remembering Hacktoberfest...

AmasiaNalbandian — Mon, 28 Feb 2022 06:01:16 +0000

A while back I wrote a blog post about the troubles contributors had when maintainers fell short of their responsibilities. Unfortunately, I've had the pleasure to witness déjà vu - yes, all the way back from October.

This week I was excited to look into using i18n for localization in the Telescope web app. I think this was a great idea, and even if we only translate the about page, we would be able to welcome and educate others from around the globe about what Telescope is.

As I began my search into next-i18next, I was so excited because the npm page for the package was very clear and instructive - everything I would have said was necessary in my maintainer guideline blog.

I went through the steps, and tried along the way to see if everything was working and able to run. I got a few different errors from silly mistakes:
Didn't understand how to get the translations from the common.json

My favourite: you need to implement the serverside rendering too!

I did all the steps listed and put up a PR. Although I was able to get the translation working, even through browser locale, the PR never succeeded in deployment or build.

I had a feeling this was going to happen. I wasn't able to build it locally either. I explored the error, and I came across an issue filed in October 2020 for next.js. I don't know what happened, and I don't know what to say... but when you see an issue with 114 thumbs up - A LOT of people have clearly ran into it.

The best part? The response provided received 100 thumbs down as there was clearly never going to be any support for next export in next.js

There were many attempts for a workaround provided by many different people, but none seemed to be stable as I approached all of them. Some seemed like it was promising, but really unnecessary workaround for something that should have been simple. Basically most of it was trying to get localization to not work statically - to avoid the next export all together.

So as you can tell, the PR was closed. What I ended up doing was instead used i18n - without next.js and instead with React. This allowed us to put in localized routing. This means that we can create a select list with the various language options and allow users to select from there.

I believe the idea works better because:
1) We are only translating some pages - why put a "language dropdown" for all the pages and then not have it translate?
2) It might be easier to maintain down the line... It was extremely easy to use i18n as opposed to next-i18n. The logic of it is very simple too, which allows us to select which keys to use when selecting an option from the select.
3) It works...

So - what did I learn?

First of all I learned that programmers are gritty - and not just me. You tell a programmer something doesn't work and if they can't fix it they'll find another way - we simply hate the word "quit", and the issue was a great example of this. There were SO. MANY. ALTERNATIVE. ATTEMPTS.

Next, what worst than poor maintenance? A lack of understanding for the requirements and limitations of your product. There were clearly many people running into this issue, and many left disappointed. At one point, someone said that they didn't support next export because none of their stakeholders required it...

The icing on the cake was that many people complained that the documentations stated that it is supported, and eventually they put in a note that explained hybrid apps do not support next export. The only solution from that issue was that they moved up the note so that it was ahead of all the instructions (basically don't waste your time setting it up, it doesn't work vs. I spent 3 hours trying to make it work and it still doesn't work).

Although I sound really disappointed, I really am not. I was able to get the translations working with i18-next and react-i18next, and have put forth a PR for the functionality.

Managing my 6 hour goal:

As for my goal of working 6 hours a week - I feel very productive and accomplished. I spent about 4 hours with the translations, and another 2 making more progress on the search bar - I even put up a [draft PR]](https://github.com/Seneca-CDOT/telescope/pull/3055) as I continue to work on it.

I would say this strategy is very helpful in feeling productive and continuing to work. I look forward to continuing this mindset as I make more contributions in the upcoming weeks!

Never Ending Errors

AmasiaNalbandian — Mon, 28 Feb 2022 05:17:05 +0000

You know how when you try to avoid a problem for a while, it turns into a bigger one? Well last week we barely made a scratch on the surface for the search bar:

This week I did a rebase for the branch. This rebase was for 10 separate commits. I am not a fan or rebasing and having conflicts. This means I am a new fan of continuously updating my branches with the latest code in master.

Although I was finally able to rebase the branch(also incorrectly), I was now presented with a new problem... or should I say error:

TypeError: Cannot set property statusCode of Error which has only a getter
    at createError (/app/node_modules/http-errors/index.js:101:33)
    at /app/src/routes/query.js:13:10
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
{
  error: ResponseError: index_not_found_exception
      at onBody (/app/node_modules/@elastic/elasticsearch/lib/Transport.js:337:23)
      at IncomingMessage.onEnd (/app/node_modules/@elastic/elasticsearch/lib/Transport.js:264:11)
      at IncomingMessage.emit (node:events:402:35)
      at endReadableNT (node:internal/streams/readable:1343:12)
      at processTicksAndRejections (node:internal/process/task_queues:83:21) {
    meta: {
      body: [Object],
      statusCode: 404,
      headers: [Object],
      meta: [Object]
    }
  }
} query error

The problem was foreshadowed in my blog last week:

I was unable to get the port for the queries working, so once I solve that, I will be able to get the inputs working.

I was able to come up with a work around. What has happened was ever since we finally had the tests created for ElasticSearch, we ripped out the functionality from Telescope, to use Satellite for ElasticSearch. This has caused some issues with the port it listens to. I believe the correct port to use now is localhost, but I am not too confident this will work on staging. I asked Dave if the error only shows up for him locally, and he confirmed, so it seems when we run our containers locally, we are trying to connect to 127.0.0.1 port 9200 for Elasticsearch, but this is not correct as we have migrated over to Satellite to provide us the Client.

The fix that seemed to work and avoid the error, seems to be able to query properly locally, however, I wasn't able to reproduce the error to write in the PR the proof of it working. I'll have to spend some time on this this week.

Elasticsearch progress

Added title in search UI
Added back the useEffect for the search so it is more interactive (populate search as you update fields)
Hooked up the API calls for Search from the front-end (we can search by titles! - more to come!)

Remaining work

Tie up all the search input fields
Remove code from the old search
Clean up the UI
Any other bugs that I am probably not expecting...

Debugging and Exploration

AmasiaNalbandian — Wed, 16 Feb 2022 01:57:35 +0000

This week again felt like I didn't do much.

I am so sick of writing this - so to resolve this whole ordeal, my goal by the end of this blog is to outline a better measurement of my contribution to Telescope.

Expo-CLI

In retrospect, this week I spent more than enough time trying to explore this issue that I created. I found it extremely difficult to get my virtual devices working on Android Studio. I was actually extremely confused because I have taken a course in Android Development, where we used Android Studio, and I was able to successfully run the apps I created in the virtual devices. However, I thought Expo was causing a problem between the sym link it creates to launch the app in the desired virtual device. After a lot of debugging, I noticed it had something to do with the adb.exe file in the Android directory on my PC.

I did some more exploration.

I did all the updates.

I uninstalled Android Studio twice.

I deleted the virtual devices on my PC.

No luck.

What I recalled was that for our Android Development class, there were environment variables that I needed to set. I re-read the documentation for expo-cli and Android Studios, and both discussed this for Linux and MacOS users, but not for Windows. I decided that I would explore this for Windows. I found documentation for this, and went into my environment variables. To my surprise, the key was missing. I had never erased it, but somehow must have been removed. I added the key back in, and went back to the Telescope Repo to try and launch it one more time. To my surprise, it worked! I was so relieved because I have wanted to get into some of the React Native work since we started it, but I could not launch the darn thing! I was starting to become frustrated because I was losing an opportunity to try something new, with something that was out of my hands. I wrote a PR to update our documentation for Windows users to note that they may need to set the environment variables with images, in hopes of having less frustrated contributors (something I mentioned in a blog long long long time ago).

After this I went to the issue to ship react native app to Android. I made an account, but I got side tracked. I was happy to read and understand how we will be shipping this though, and hope to potential create the automated releases from GitHub Actions as I read about.

Search Bar

This search bar... it's so close, but every time I finally get it launched and working... I get frustrated and tired.

This week I did a rebase for the branch. This rebase was for 10 separate commits. I am not a fan or rebasing and having conflicts. This means I am a new fan of continuously updating my branches with the latest code in master.

After my rebase, I was able to run it, and it seems I am very close. I was unable to get the port for the queries working, so once I solve that, I will be able to get the inputs working. I think I might need to make a new issue to create another input for the general search on the search page. This will search the term inside the input in all the text fields.

Expectations

So as I mentioned, it's becoming really difficult for me to stay motivated as each week I am feeling that I am not getting much done. I believe the most realistic expectation is to take an Agile approach. I'm going to take a guess how long each issue will take. From there I will dedicate about 6 hours a week for these issues. As we discussed in the beginning of the semester, the train will leave the station, and there will be another train. I think if I follow my guidelines for the time I dedicate, I will not leave each week feeling like I got nothing done - because even though I didn't make a 4 file change PR, I spent time working and solving issues.

This being said, I want to spend another 2 hours on Search bar and see where I land. I refuse to write another blog about this issue, unless its the final one.

Setbacks are expected

AmasiaNalbandian — Sat, 05 Feb 2022 05:01:15 +0000

In my last blog post, I discussed about how my plans for release 2.6 fell short as I tried to tackle the challenges presented as a "sheriff". Fortunately, I was able to start the week off fresh, and told myself it doesn't matter, we can remain productive. That is until we were slammed with a deadline for the PRs on Tuesday night instead of Thursday morning, when we normally plan the release to be made.

Although this came as bad news, we have to look at things differently, and more positively. What I decided to do was to pull up my plans for release 2.6. From there, I knew we had a deadline of 12 hours. Realistically, not very suitable....

Recovery

Fortunately enough I decided to just look past this, and do my best. I broke down the list of my plans:

1) Elasticsearch PR - This needs about 4-6 hours of work to put up at best.
2) Supabase - Duke pulled all of this off because he is superman.
3) The front-end issue in the dashboard, and it's sister issue that I took on as it was in the same area.

Looking at the list, my options were extremely limited. There was no way I'd pull off the ElasticSearch UI in time, and Supabase was finished. This wasn't so bad because realistically, I could tackle the dashboard issues. I began by doing the sister issue, which was an error about how it was trying to access an undefined variable. I knew the solution, but in my PR I wanted to educate others and myself of what it is. I googled the name for this, and it is called the optional chaining operator. I find this operator extremely useful and use it a lot at work. However, if you'd asked me what it was called last week - I had no idea. Now I do!

Next I began to play around with the CSS for the dashboard. I thought this one would be easy... Now that I think about this, how do I keep falling for the same front-end misconceptions time and time again? Am I seriously delusional? What I did not realize was that for some reason we had 3 or 4 (still not too sure) "layers" of terminals for the build dashboard.

.xterm-viewport,
.xterm-screen,
.xterm-link-layer,
.xterm-cursor-layer,
canvas {
  width: 100% !important;
  max-height: 100%;
}

Above, you can see that I had to set the width of all the layers to 100%. Additionally, I put everything in a flex-box. I can honestly reflect back from my WEB222 days and say I finally understand how flex-boxes work. Before I would be really confused, but this is because you usually have to have a parent and child div. I guess I always overlooked this. Once you set the parent div to display: flex and flex-direction you are pretty much set.

One thing I did notice was a comment about the hamburger icon that was on the right. I had no idea what that icon did... So I decided to click it! It pulled the dashboard menu from the left. This was so confusing. I click on the right, but then it shows on the left. So I fixed it to be on the left, so it was more intuitive.

After a lot of CSS fun, I was happy with my work and pushed it up. I made some funny typo that was caught by my peers (this is why we look at code too and not just results!), fixed - and shipped!

Surprise Breaks!

It's really not a release unless something breaks, huh?

This week none of the changes we put in broke anything. It was so good... Too good. So on Tuesday night, the deadline for the PRs for release 2.6 the programming Gods reminded us to be humble.

One of the packages broke our master branch! When I finally got around to the Slack discussion, we had narrowed it down to MDX. I was really shy to join in so late to the discussion, but it seemed that we had some movement going for a solution, then it stopped. I decided to jump in, at worst I'm going to be ignored. I spoke with Tue and Anatoliy who were trying to explore this. We got some hints that the release from MDX for 2.0.0 may be related, as that was when the PRs started to break. We got some push back that there was nothing we can do, however, this felt odd... There's always something to do. I went to the MDX GitHub page again to look at the issues (something I learned to do when Dave linked me an issue from Parcel Build that I was also complaining about). Surprisingly, Anatoliy had already submitted an issue! I was so proud of this, because it showed how dedicated he was to solving this issue, and some of us are afraid to get "open" in opensource - but not him!

Unfortunately, I didn't like the tone of the response we got from their team - probably because we just rained on their parade after their 2.0.0 release. However, it was helpful, they mentioned that we needed to migrate if we were going to use MDX after 2.0.0. Oddly enough I thought I would start a stream for open source programming this same evening. I decided we should do some investigation and it would be fun to do it live. Tue, Anatoliy, Thanh, Josue, and I got on a call on MS Teams to work together. To be quite honest, I'm still not sure how we figured this one out, I was sharing my screen and just doing what they were telling me so I wasn't able to keep up with their solutions( I was driving a car, and they were telling me where to go). However - we solved it, and that to me was really amazing teamwork. We quickly let the group know, and I am sure many of them battled out their PRs to merge in to avoid having to rebase - haha. I felt really happy about fixing this, because it was a big blocker for our release - we need to keep our CI clean!

Overall although I wasn't able to hit all my goals from my previous posts, I feel that I achieved more. The magnitude of the MDX issue probably gave more weight to my output of contribution, personally. I think we need to have a different perspective on our ideas for "how much work I did". I think estimation of weight and hours for the issue is more important than knocking off more issues.

Taking Lead in Telescope

AmasiaNalbandian — Thu, 03 Feb 2022 21:49:21 +0000

Last week, I got to do something extremely exciting! As I discussed my previous post, I would be the "sheriff", where I am responsible to guide and lead my peers so that we can pave the way to successfully deploy release 2.6 in Telescope .

Duke and I will be "sheriffs" the upcoming week, and I can image that will take a bit of a toll on the projects I push, as I try to support the team and get our goals accomplished. Oh! I should mention - I am so excited to be doing a release. This will be my first time on a more official repository (older me will remember this moment and probably laugh hahaha).

Well, to start off, I was not wrong about the responsibilities taking a toll on my goals for release 2.6! I did not complete as many issues as I wanted to for this week, and it left me falling behind for the release. So my first advice for the role is to take that into consideration.

The second thing I'd like to note is the last bit of my quote, where I will probably laugh. I can look back now and definitely laugh. Not only did I do my first release, I did my second and third. Being sheriff was overwhelming, I wanted to encourage all our contributors and push them in the right direction, ask if they required support when issues went stale, but also handle new high priority issues.

New Issues!

Before we even began the week, we had an issue to tackle! Node-fetch introduced a vulnerability, and unluckily we were using that version. Right away, Duke and I got tasked with handling this fix. I took lead and did the release in Satellite (more below), and then began tackling the issue with Node-Fetch. I thought it would be an easy npm i node-fetch vXXX. I was wrong - I forgot we use pnpm and the process is a little different. I tried to update but nothing was working. What was working was if I did pnpm audit --fix, then I would run pnpm i. However, this was creating an override object in package.json. This is not what I wanted... I read the document on pnpm audit and realized, this is better than what I wanted....

I pushed up my changes, and wrote a quick description of how this worked. I am sure this was new to many of us, as we are just currently working with pnpm in our codebase!

However, we were not done with pnpm... It striked again in Satellite!

We didn't realize our docker containers were still using npm and not pnpm. So when we upgraded Satellite to use pnpm, we added a hook to only allow pnpm. This caused our builds to fail in Telescope. I knew how fast the fix would be, however, I had no time to figure it out, so I created an issue, and assigned it back to the contributor who presented the line of code in the repository. This was not my attempt to point fingers, but the idea of "ownership". That part of the repository is now in their "ownership", and anyone who has questions or needs guidance should go to that individual.

Releases

When I started the release process, I was really lost. Previously, I made a release for my static-site-generator and wrote about it. I will note that my intention for that blog was to help others, and especially myself... This was around the time I began to notice that blogs can be used as notes. This was exactly what I did first thing - pull out my blog. Although I watched how to do a release on Telescope, Satellite was MUCH different. I ended up having to delete the tag I created twice... but nobody will know... unless they read my blog.

Progress on current Issues

As I mentioned, I haven't made much progress on the current issues. I guess I took a step back and decided to prioritize some things, such as the breaking changes in Telescope. I also did some reviews for PRs to get merged in:

Remove all Elastic APM code from Telescope

Add YouTube channel test case for feed discovery service

Modified regex to match user only

Lastly, I followed up and let the group who would install the UI library to let them know Expo PR was landed!

Final Thoughts

Overall, although it feels like I didn't contribute as much as I wanted to in terms of code, I look back and think of the amount of time I spent reviewing PRs, adding labels or updating our documents for the release. I did take a lot of time to read through blogs and look into the repository to understand each individuals interests. I was lucky enough to have Dave provide a skeleton template of areas, and from there I went ahead and filled in the open issues related, and individuals who had an interest in the area on the wiki page for release 2.6 planning. I took charge for the 2.6 planning, and when I was done, I felt as if we had a good amount of issues to tackle, and everyone was taken care of. I wanted to leave that meeting, and have everyone understand how crucial their role is in their contributions, and feel a part of the team. I look forward to seeing how well we push through the next week, as we work to complete the issues under the release. This will give us a better idea of how much we can take on and ship each release.

Pathway to Telescope 3.0

AmasiaNalbandian — Sat, 22 Jan 2022 04:59:56 +0000

Recent Contributions

In the last week, I was eager to get started on my work for release 2.5. What I was not aware about was that I would also be contributing to 2.5.1, the patch for the search bar which I broke in production. I was finally able to get my work in for the search bar back end.

As many of the students in my class are not too familiar, I tried to make the steps to test the PR very clear, and listed them to the best of my abilities. I was really excited to see that there were other students who got involved in the PR review for this.

Unfortunately, I completely forgot to test the search bar in the front end was still working... So you can imagine my surprise when a few hours after we released 2.5.0, I see someone write "the search bar is not working for me...".

What I did immediately was go to production and tested it! I saw the error in the console, by using the developer tools for Chrome. The error I saw was the validation response for the advanced route. I knew exactly where the code was broken, and so I started working on a fix right away(... when I got off work).

What I did in the original PR for the search bar was I used req.baseUrl to be able to see if it was a request coming from the /advanced route, or the / route. One was for the general search, and the other was for the advanced endpoint. Unfortunately, baseUrl was not able to determine this properly in the front end. The solution for this was to instead use req.route.path which was much successful in determining the route. The fix for this was posted the same day of the release, which I am happy about.

Planning ahead for Telescope 3.0

As we slowly knock down our 7 releases in the semester, I want to spend some time discussing specifically what I would like to get involved with. In my previous post, I was very general and for this one I have a few areas I am interested in.

1) Elasticsearch

Are we surprised? No. I really want to push forward the UI for advanced search. The last time I worked on it, I had just a few minor changes to make, and we were set. What I really want to try and do is make sure that the code is not hard-coded anymore. That is why I had such difficult time last semester trying to implement all of this.

2) JWT

I already picked up an issue to do regarding the JWT signing. We are looking to include this into the containers in staging and prod, which should be interesting because I wanted to learn more about the containers.

3) Supabase

Again, I've been assigned to an issue for investigating Supabass. This is the fresh new hot topic of the repository. I saw the issue go up last year, and I was interested as many people were saying how innovative it is. I have some catching up to do with regards to this area, however, I am going to be working with a few other students on this (another goal I had mentioned in my previous post!), who are more familiar with Firebase (our current implementation). Hopefully I will be able to keep up and can learn two things here: Firebase AND Supabass. It will be cool to see the difference between the two and gain insight on when to leverage one over the other.

4) The SSO?

I wanted to work on this last year - I read the post Dave shared about how the SSO worked. Did I understand all of it? No way. The reason I would like to get involved into this is because for my PRJ666 class, our project was supposed to use an SSO. Unfortunately, it's not so easy to gain permission from institutions for this, and therefore I feel I missed an opportunity for something that is very commonly used today. I've added a question mark because maybe this is not something I get to for Telescope 3.0, however, maybe we can try this in 4.0?

How do we get there?

So far I've listed about 4 areas that I am interested in working on for Telescope 3.0. What I want to do next is discuss what I will need to achieve this.

Realistic, I have struggled getting started in the past because some of the code is not clear how to run or access. Usually I run back to my developer tools and inspect elements, but with this project it's proven to be challenging. So what I've honestly been doing is using Git Blame to see who worked on this code, and messaging them. Everyone has a great attitude - and are more than happy to help. What I do next is I write it all down in my Telescope.md file. I want to keep a log of all of this, and then add these to the documentations where I notice it is missing. What we can also do is add this to Alex's idea of Breaking up issues into GitHub Projects. This will allow new contributors, or current contributors to be able to quickly access and run code in new areas they are trying to explore(the not so fun part).

Additionally, I am noticing the downfall to the releases are that it will be difficult getting more students involved in PR Reviews. I KNOW you might not know anything about the area of code. I sometimes look at some PRs and go WHAT? However, I think PR reviews are an easier way to learn about the code base and the different innovative solutions being placed in the code. For example, the fix for the min-height of the GitHub information. So my plan is to start reviewing other students' code, and when I put up a PR I will tag them to review. This will make some students feel more obligated to review, and we can get more traction going.

Next three weeks for release 2.6

Hopefully we will not have a 2.6.1 - this time I want my code to sit in there at least THREE days before we release. This is my MAIN goal.

As I'm assigned a few things, I want to catch up with Duke and Abdul regarding the Supabass, so I know when we want to work on it, and how we can get started. This one will be slow progress until we are done exploring, and start coding. I don't do this enough - and I'll be excited to research about code!

There's a pending front-end issue for the dashboard that I have started. I want to aim for this to be in by next Friday.

I also want to get back to my Elasticsearch UI. I feel that there might be a lot of feedback, and will require more time to implement. Therefore I want to target this a little earlier in Telescope 3.0. I will be doing this the following weeks. I will need lots of help to test everything for this, and will need to find a way to convince people since I can't pay them with grades.

Overall I am looking forward to 2.6 and want to focus on these two/three issues. Duke and I will be "sherriffs" the upcoming week, and I can image that will take a bit of a toll on the projects I push, as I try to support the team and get our goals accomplished. Oh! I should mention - I am so excited to be doing a release. This will be my first time on a more official repository (older me will remember this moment and probably laugh hahaha).

Continuing Open Source

AmasiaNalbandian — Sun, 16 Jan 2022 07:52:52 +0000

As I continue my journey through open source for another semester, there are more things that I want to explore and hence use this post to set goals for the semester.

First, I want to continue working on the Searchbar for Telescope. So far, I put up the backend of the API for Elasticsearch. My goal now is to create the UI for the search bar so that we can have more refined searches.

My main goal is to keep working away in React. This may not sound so exciting - however, I want to become more comfortable and proficient in React. Whether this means getting more front or back end code in - it is something I want to add to my resume and never hesitate to answer "How comfortable are you with React?" in an interview.

I am very comfortable with front end work and don't have much exposure to back end services and such. However, I am alright with taking up more front end work, as it will slowly introduce me to more areas of the repository. This is another goal - to become more familiar with the code in the repository for Telescope.

There's a lot to work on in the repository, and as a result there are many services and dependencies. Just as I got involved in Elasticsearch and nginx, I want to get involved with more! This was honestly one of the most scary things I did last semester. For nginx - I had no idea where to start. The change was literally 4 lines of code, but I learned so much. Elasticsearch was a bit more code, and again, I had absolutely no idea what I was doing, however after reading A LOT of the documentation, I went from playing with one file, to understanding there are more files involved.

I also want to have better time management. Yes I work better under pressure, but there's no reason to put the "pressure" on the deadlines. I should set my own deadlines before the due date and work towards that.

Lastly, as most of the students in this round have taken the previous course, I hope to work on an issue with another student(s). I want to be more involved and share ideas with others as we tackle issues.