In this episode we take a look at taking on complex tasks in a field where you're not very experienced, something all programmers must do at one point or another in their career.
Segment 1 - The Newcomer Effect
- This segment is going to focus on our experience configuring a vuejs service worker - I went in with no previous hand-on experience, a complete newcomer to service workers and an amateur at vuejs. Therefore this process is no doubt clunky, but as you’ll hear that’s exactly the point
- I want to be clear before I dive in here that we’re using the following particular scenario because it was recent, we are not pointing the finger at any of the plugins, apps, or resources that we mention below. The issues we’re discussing are industry-wide, and not on a specific service, platform, or individual.
- Recently we went to work with service workers on a Vue.js app (No BS News for Reddit)
- As apart of the coding challenge we had already had a basic service worker setup that allowed the local assets to load when the app was offline
- This functionality was made using a pwa plugin for vuejs
- We left this plugin mostly, if not completely, in its default configuration
- This default configuration registers a service worker and then generates a service worker file which caches those offline assets
- Mike got the project to this point during the coding challenge and then I took over
- This is where things all fell apart for me:
- I had done a couple of days on reading basic service worker configurations and functionality and then finally decided to dive into our project
- First thing I did was look around the file structure and I find a file named registerServiceWorker.js
- This file contained an import line regarding register-service-worker (which fueled my initial Google searches) as well as the registration and basic responses that you’d expect such as successfully registered, detecting offline, etc.
- Searching register-service-worker led me to the page that I linked above, which had some very brief documentation and a code example that looked like our registerServiceWorker.js file (so far so good)
- From there I ran some tests in Chrome, checking for service worker install, checking offline mode, etc to get my bearings
- At that point I wanted to start adding some code of my own to the service worker, from my readings I knew that the service worker was definitely a separate file and from the registerServiceWorker.js file I could see that it was referring to a file called service-worker.js
- Searching the directory for said file revealed that it didn’t exist
- I then went and checked in the browser again, taking a look at the sources tab to find out what file was running the service worker, it showed that it was definitely service-worker.js - which indicated that the file was being created dynamically as apart of the build process
- This led us down a rabbit hole of finding how to inject my service worker code into this autogenerated file
- Overall, we eventually did find a solution for the code injection, however, it was not in the original register-service-worker documentation, nor was it discussed a lot on stack overflow
- We did find one Stack Overflow thread that did help, which led us to a useful blog and a couple of interesting links - I also found a separate page on npmjs.com somewhere along the lines which contained the missing code we were looking for
- Basically we needed to add some injection configuration into the vue.config.js file and then from there make our service worker script
- Now I know that’s long winded, but it points out some very important problems/concerns:
- The newcomer effect is alive and well, I wrote an article on Medium about what I call the newcomer effect a long time ago, it basically means that any documents/signs/directions that are available for any given experience rarely take into account the needs of those that are complete beginners - increasing the entry “budget” for newbies
- I’m not sure how documentation writers do it - maybe it’s because they’ve been working on their projects for so long - that they completely miss major steps in their documentation. It’s got to be mentioned that we desperately need better documentation for beginners and furthermore, more linking between potentially helpful guides
- In this particular case, maybe it’s because many folks won’t write their own service worker, but rather just want the default to cache the local assets and that’s it, but shouldn’t it at least be mentioned that if you want to write your own service worker - please see x
- Toxicity and useless comments are alive and well - on various forum posts, comments, and of course Stack Overflow posts there are typically an abundance of comments that dismiss questions due to “user not being experienced enough” or similar reasons. Or questions that are marked as duplicates, when really the question was indeed unique enough to be answered
- I want to be reiterate here, that I’m simply mentioning some of the roadblocks that we face when we’re newbies on a given topic, I’m sure a bunch of these affect other people as well. I’m not pointing the finger at this particular PWA plugin, Stack Overflow, npmjs.com, or any other website. I’m simply using this particular recent scenario to point out common problems that could be ironed out for those of us that are inexperienced. These problems can be found across any programming language, and even outside of the programming world in some cases.
- In conclusion, once we got the service worker file running, we were off the races. We ended up being able to cache all our Google Fonts thanks to a helpful guide and are well on our way to getting more offline functionality added in the app. Once we had everything put together, the PWA plugin works great. But I stand by my position that finding instructions on how to setup something in Vue (or any other framework, library, or whatever you're using) shouldn't be the challenging part. The challenging part here should be that we need to get offline functionality working via our service worker itself, not figuring out how a service worker is setup in this particular configuration
Segment 2 - Strategies
- Complicated issues and topics arise all the time during the the development of a project
- They can range from concepts you haven't heard of like Binary Tree Searches or design patterns, advanced algorithms or even just complicated libraries/frameworks
- Sometimes when taking on a task it might seem that there's just to many unknowns for you and you’re delving into a sea of advanced topics
- I’m going to go through a couple ways I go about learning and implementing advanced topics.
- I start by breaking them down into as many smaller topics as I can
- For instance if the topic would be VueJs id break it down into
- Setup dev environment
- Create first hello world app
- Test reactivity
- Figure out navigation
- Figure out state sharing
- Learn about components
- Etc
- By breaking apart a complicated topic into smaller manageable topics it takes away the initial feeling of being lost and allows you to focus on one small easy to digest topic at a time
- If the topic is something that's hard to breakdown, or you don’t even know where to start breaking it down, it’s a good idea to take a look at the documentation and see what they start with. Usually the documentation starts with the simpler topics and moves on to the advanced ones. Of course if it has poor documentation that's a whole other problem that as Matt previously stated.
- Once the topic has been broken down to learn more about each section I would actually start coding almost right away. So as you’re learning about how to get a dev environment setup, actually set it up.
- The more I’m actually applying what I’m learning the faster I’ll pick up the concepts and find their downfalls and issues
- Speaking of issues advanced topics can also just be hard to debug issues. We’ve had an episode about troubleshooting so I won’t go to far into it but essentially your first key goal is to be able to easily reproduce the issue, after that using the chrome dev tools as your guide, you can put breakpoints everywhere you need to read the state of all the variables as you progress. This method usually
- Diagnoses my issues quickly
- And gives me a clearer path for a simple solution
- If you run into a roadblock and don’t see a solution at all, step away from that issue for some time. Even just getting up going to do a small chore might jog your brain into thinking about it from a different angle
- Sometimes you’ll run into issues figuring out seemingly simple features and you might have to use these strategies for them too
- Here's something that recently happened to me where I had to use all these strategies to get past a seemingly simple feature addition
- Get the best library to work in a basic way to my liking
- If it works figure out why it isn’t working in my particular scenario
- Reproduce the issue
- Troubleshoot the library code to figure out what is stopping it from working
- Fix the issue
- Had to add a comparison slider to a vuejs application
- A few libraries to choose from so thought it should be easy
- Tried all of them and they all had varying issues
- Issue arose here, had to figure a) should I use one of these libraries or build my own
- Broke down the problem
- During the process of fixing it, I had to step away a couple times and each time I found different ways
Web News - Thin Client Computing
- With the announcement of Google’s new streaming game service Stadia it seems like a good time to have a quick look at the current state and the potential future of thin client computing
- When referring to thin clients I mean a small, low power computer that essentially is used to remote connect to a offsite powerful one that provides greater performance then you can get with lightweight portable computers
- In reference to Google’s new game streaming service a person can play AAA games using any device that is connected to the internet and runs chrome.
- There's obvious advantages to this
- Using cheap hardware to still perform complex tasks
- Being able to access the same environment from any device without any sort of backups or syncing required
- Some not so obvious advantages actually can come for developers
- If large thin client powerhouses like google become really popular, a developer is now coding for a single set of hardware, as the actual thin client that the user has doesn’t matter
- Imagine gaming developers not having to worry what video card their audience will have because everyone will just be using thin clients to connect to a large datacenter with the same hardware in each machine
- The limitations are also pretty big right now. Network connection being the main one. The latency of your actions appearing on screen can be very distracting. If you click your mouse and only a second later something happens it makes working with the system very unpleasant.
- But with the knowledge that networks are constantly improving, latency is also getting better and maybe there are ways to make it almost unnoticeable, can you see a future where thin computing explodes?
Links
- Plugin Links
- Stack Overflow Thread
- Guide we used
- The Newcomer Effect: A UX consideration (Medium article)
You can find us on...
Facebook | Twitter | Instagram
RSS | Patreon | Spotify
Medium | YouTube | GitHub
Reddit
