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.
Top comments (0)