Open in app

Sign in

Write

Sign in

In which I scrap one pull request and work on another.

Hey strangers and friends!

Here’s my weekly breakdown for what’s gone down most recently in my web dev journey. It’s Week 14 out of 30 — getting super close to the halfway mark.

What’s that? You don’t know what I’m talking about and would like to? Well, for context, here are the previous posts for this blog series:

What did I set out to do?

I’m in a game of catch-up with my intentions to have a basic MVP of my project done, since I went on a detour of adding some ordering functionality to django-graphene last week. This week my goal was to wrap up the PR (pull request) for the functionality and then complete my first PR on my actual web project (mostly, cleaning up the code for what I had so far, to submit to a mentor or two).

This would let me get back on track for building out the rest of my MVP.

What did I end up getting done?

For the django-graphene PR:

  • Not exactly what I had in mind: in the process of looking at some existing django-graphene tests (in preparation for writing unit tests for the change I added), I realized that I could probably achieve the same functionality I was adding by creating a custom resolver for any GraphQL field being queried — so long as custom input arguments were also possible. It took a bit of trial and error to piece syntax together (the documentation wasn’t right there in the django-graphene docs) but in the end, I ended up with a custom resolver that did what I needed for my app.
    Once I knew this pattern was feasible I didn’t see the need for the change I had worked on adding to django-graphene, so I left that in a branch and went on my way.

For the first PR for moshimoji:

  • I worked on adding proptypes to the components I had written so far.
  • I reconstructed my master branch from an early commit, but without some files which I’ve since separated out into another repo. This was to have an early state to make my PR against.
  • I worked on, but didn’t finish, troubleshooting the auto-reload of user statuses once a new user status is submitted on the user dashboard view. This was a bit of functionality that’d been working previously but stopped after I implemented the ‘load more’ option (not sure why!).
    To fix it, I switched from calling the ‘refetch’ function to the more hands-on ‘update’ function (is exact in specifying how the Apollo cache should be updated following a mutation).
    I also implemented GraphQL query fragments to ensure that my queries involving user statuses had overlap in structure, and always queried for the ID and typename (presumably the prereqs for the cache to resolve new data as relating to the same node).
    I’ve taken some steps to enable heuristic fragment matching, but it seems like this enabling isn’t completely successful yet since I’m still getting some warning messages.
The persistent error messages about heuristic fragment matching that haven’t gone away!

What went well:

I feel that I’m continuously learning and gaining familiarity with the tools I’m using, so that’s nice. And when I tweet about what I’m working on, a lot of times the people behind that tool will get back to me! Thumbs up for an involved community.

As usual, I’m spending some time being conscientious about my time management. I tried out one new habit, which is to tally how much time I’ve spent on different categories of activities as the day goes on (one step beyond my original recording habit), and I definitely think it’s helped me aim at working a certain amount each day.

What was difficult:

I had a couple of conversations this week with friends since I feel like I tend to spend a lot of time resolving small details (this week’s example would be getting my heuristic fragment matching to work; the last two weeks would be achieving my ordering functionality for queries one way or another) instead of covering good ground with the actual building of the app. I think some of this comes out of the choices I’ve made with my technology, some of it comes from my unwillingness to make hacky solutions when a ‘proper’ solution exists; some of it comes out of my habitual choice to continue slowly breaking a problem down so long as I’m making headway, even if that means taking days to solve something instead of solving it in an hour with the help of someone experienced with the matter, and of course some of it comes out of my inexperience. Regardless of the reasons, it’s hard to question the way you work and change your approach. They say awareness if the first step to fixing a problem, but it’s the second step of pushing yourself to do things differently that I stall at.

I haven’t written about this directly before, but I have an anxiety issue which rears its head every once in a while and honestly probably takes one or two days of productivity away from me a week, on average. I’m aware of the issue and am working on it.

What I would do differently next time (next time typically meaning from now on :P):

  • Ask mentors about what choices I’m thinking would be appropriate from the beginning of a project, to get more context on the considerations to take into account
  • Be more willing to gloss over small details like using fragments (leaving implementation of that to the future if it proves difficult)
  • Be willing to have temporary workarounds that I can go back to removing once an MVP is done
  • If I’m spending time on a problem that my mentors are probably familiar with, pull them in after an hour.

One cool thing I learned about:

These are probably some basic details about node, but invoking node scripts in other node scripts w/ npm (package.json feels a lot like a C makefile), and the context-dependent behavior of npm when it comes to saving new dependencies to a package.

Misc links for your browsing pleasure:

GraphQL
Apollo
Project Management
Self Improvement
Web Development

--

--

Rona Chong

Written by Rona Chong

89 Followers

(✿◕‿◕)

Help

Status

About

Careers

Press

Blog

Privacy

Terms

Text to speech

Teams