Let’s Build a Web App! Week 18 out of 30

Rona Chong
7 min readDec 4, 2017

--

*when you write your blog post in Sublime because you have no wifi LOL*This week: is week 18 of my 30 week journey, and I'm trundling away on
the modules of my site!
If:
you are appalled that last week you checked for my weekly post and found NOTHING, let me appease you by explaining that between a move and Thanksgiving (which was really just more time to move) I decided that last week was a no-go for any meaningful dev work. Sorry.
Else if:
you are unaware of what I'm talking about but find your interest dashingly piqued, say no more, and check out these other posts in this series to satisfy your curiosity.
Else:
read on as usual.
I'm blaming this nerdery on the side effects of writing in a text editor for programming.-----
Previous posts:
-----What did I aim to get done this week?
My "MVP" demo to the watchful Guillaume proved to be a chance to regroup myself and I got the advice to focus on one module at a time, one week at a time. This sounded right to me. I also felt it right to reduce my sense of the core functionality to the reader module and the database module, so those two modules would have the most priority. Having done a preliminary forum implementation/hack last week (Week 16), I decided to work on the reader module this week. My goal was to get the basic functionality done (you select from a directory of available series, you chose a chapter, you scroll down, you read.)
What did I get done this week?
The main bits toward my goal:
* setting up my CDN and underlying object store for serving image assets (a Cloudfront distribution backed by an S3 bucket, thank you AWS free tier cont.d)
* adding a small piece of config to my frontend to register my CDN endpoint
* for the reader: writing and manually testing my first hyperlink to an image hosted by my CDN, which doubled as writing and manually testing my first LazyLoad component
Some other bits which were less anticipated, or less relevant:
A bit of research, a bit of thinking and planning, and refactoring my site module React components to share a base "higher order" component which specified the styles for the containing div.
Consulting my mentors on one or two items -- also, merging a bunch of pull requests I'd made into master.
What didn't I get done this week?
I didn't create the metadata models for the series, chapter, and page entities in my backend, and the respective GraphQL fields to query for those entities. Likewise, I didn't get to add example metadata and corresponding assets to the database and CDN.
On the frontend side, I didn't write the queries through my Apollo client for series, chapter, and page metadata, and the subsequent asset retrievals from my CDN for each view component. I also still need to compose these components themselves.
What went well:
Although perms for my S3 bucket and CDN were a slight stumbling block (and represent a future Psyduck topic for me), getting my CDN set up and successfully grabbing from it in the most basic sense proved to be a trivial matter--that's when I think to myself, I chose the right solution for the problem at the moment. Three cheers for solutions that make things trivial!
Same applies to the LazyLoad component (I went with react-lazyload for my module). At least so far. I've also heard that writing the logic for lazy loading itself should probably be trivial in itself, but another small victory is knowing when something ostensibly trivial for others would not be so trivial for me at this point. It'd be the type of thing I could do in a day or two, as opposed to 10 or 15 minutes when I use an npm package.The good-naturedness of my mentor Johann for putting up with idiosyncratic preferences. I started a whole slack community to have communications about my questions and pull requests so I wouldn't have to belabor emails any more.
What was difficult:
Balancing normal life with being executive, when you're not strictly bound to a 9-to-5--During a brief conversation with the also-vigilant Julien, I remarked that "I do have structure! It just falls apart on me." This was another spotty week, to be honest. I lost one day to the vestiges of my move, which weighed down my errand list. I lost another day to mental preoccupation with external events, despite putting a decent amount of effort into setting up a productive work day. Friday, I arrived at 9 am "to treat school like work", but after my first 3 hours of work, got drawn into clearing the air about serious topics with a friend till evening. Saturday, relaxation items and errands expanded till I only started on project stuff at 10 pm. All the things I decided to do, instead of working on my project, are things you have to do sometimes, but overall, the frequency with which I prioritize other items over my project either has to decrease to no longer dominate my schedule, or I have to increase my efficiency when I do work.
Balancing upfront planning with figuring things out as you go--I still think I set aside the right amount of time to make plans and research things when I started out with this second project (one month), but every time I reach a point I haven't planned things out in detail, I see myself sinking a good day or two into researching figuring out how to do things before I execute. When you're only working 3 days out of the week (see, difficulty #1 above), that's a lot of time not spent executing."Am I working on an 'MVP'? Or am I working on Site Version 1.0?" The time I spend researching into things also reflects my tendency to choose what I think of as more 'complete' solutions for how to do things, as opposed to the most basic, most 'incomplete' solutions for how to do things. Did I need to set up a CDN? (Even though the task itself was trivial) or could I just have served things with nginx? The difference: an extra half day of research on new topics. Talking with my sister, she pointed out the same tendency applied to my approach to project execution as a whole, where my goals tend toward complete albeit 'basic' functionality, instead of what's really the "minimum viable" functionality to be a product--MVP.I take a lot of time to think things through, probably because I love thinking things through, but I worry I might need to deprioritize that too. Figuring out how to do the reader triggered a cascade of questions that I documented and could include here, except I don't have wifi at this point of drafting, and I spent something like 2.5 hours formalizing just one of them to ask a mentor of sorts.
What I would do differently next time:
* Continue to wake up early every day to come in to school at 9, and see how that works out for me.
* Continue to skip the functionality that's part of a complete, albeit basic, execution of my vision for Moshimoji if it goes past the bare minimum offerings for a reader-database duo.
* Discuss with an advisor at the beginning of the project, what a 'trival' execution of the project would look like, in terms of technology choices, and what a more 'complete' execution would look like, and decide on what solutions to pick at first and what solutions to implement later according to desired timeframes for output.
* Cut out some of the padding I've given myself in my daily schedule to attend to non-project things, at least for a week.
One cool thing I learned about:
* There are more specialized software solutions for serving image assets than web servers like nginx--'image servers'--which can do tasks like resizing content on demand per the specs of the viewport from which the GET request was made.

Misc links for your browsing pleasure:

--

--