DEV Community: Minh Trinh

How I Reverted My Addiction to YouTube

Minh Trinh — Thu, 11 Feb 2021 18:04:14 +0000

I was addicted to YouTube and social media, like, alarmingly addicted. Talk about wasting 3-4 hours a day just watching endless YouTube videos. I had no control over my life or my time. I knew I had to do something about it.

A few weeks ago, I picked up Digital Minimalism by Cal Newport. In the book, he suggested removing all optional technology in 30 days - including any online service, news or apps that do not prevent you from functioning on a day-to-day basis. This process is called "digital decluttering". It aims to give you time to reflect on what matters.

Following his guide, I decided to cut down YouTube for 30 days.

Leaving YouTube was difficult. It was my primary source of entertainment. It was where I've learned pretty much anything - from learning a new language, coding to unclogging the sink.

To my surprise, after a month and a series of steps that I took to discourage myself from using YouTube, I no longer have the urge to use it anymore. It's just not that interesting to go and browse videos and watch them. I managed to reduce my YouTube time to less than 15 minutes on average per day. That equals to one YouTube video.

With COVID and quarantine life, I might not be alone in this battle against the infinite loop of excessive streaming habit and inner scream for help. Here is the list of my strategies and I hope you might benefit from it!

1. Find alternative hobbies

This first step is the most important. It is crucial to find other hobbies to not relapse back to YouTube. There are a few criteria for a high-quality hobby:

Analog: I highly recommend you find a few hobbies that don't need technology to function. This will create distance between you and your phone, which means less opportunity to pick up the phone and watch a random video.
Fun: It should be fun for you. It should spark interest, curiosity, passion - whatever floats your boat. It should be rewarding. I've started to read much more books than I used to. I also enjoy walking outdoor more, especially during COVID when nothing is open.
Requires skills: Find something that requires skills that you hold valuable - something you need to work on to "level up". They can be physical or mental. For example, learning a new instrument requires both physical and intellectual capability. A few examples: learning to sew, playing a new sport, playing chess, running, writing.

When you have a hobby that you need to invest your time and energy in, you tend to stick to it more to reap the rewards. Also, if you want to reintroduce YouTube back, you now have a set of topics in mind that YouTube can help open horizon. YouTube will then become your tool and will serve you instead of manipulating your attention.

I picked up my long lost hobby - playing the piano! It's great for the brain and soothes my soul.

My recommendation is to find at least two fun and analog hobbies, and one of the two should require skills.

2. Remove YouTube from your phone

Once you've acquired a few new hobbies, remove YouTube from your phone. This step seems obvious, but I feel the need to include it here. I'm just a normal human with all of the desires and without any tremendous amount of willpower, so I have to create external barriers to not rely on my inner self-control.

Having YouTube available at your fingertips is dangerous. In a split second of boredom, our brain will activate a subconscious urge to order our hand to open the app. This also gives YouTube permission to send notifications by default. That would equal constant distraction and allow YouTube to sneak in and steal our time without us even realizing it. Of course, you can disable the notifications from the settings, but in my experience, not having YouTube at all on the phone allows me to forget about its existence altogether.

If you use an Android device, it's impossible to uninstall the app (uhh Google, please fix this 🤦‍♀️). The most you can do is disable YouTube, and in doing so, YouTube will no longer show up in your applications list. You'll probably receive a warning when trying to disable it, but don't worry, nothing will go out of order if you do so. Google will try its best to keep us hooked, and remember, it's always easy to enable it back on.

3. Opt out of activity tracking

In other words, make YouTube dumb. I stumbled upon this feature while tinkering with my privacy settings on Google, and it honestly changed the game!

By opting out of YouTube activity tracking, Google will stop saving your watch history & search history in the future. There's also an option to delete my past data so I went ahead and deleted all my history.

After this change, I noticed YouTube still proposes videos that would interest me, but the recommendation engine would show more videos that I've already watched. As a result, YouTube became a bit duller and less engaging than it used to be.

To do so, all you need to do is go to https://myactivity.google.com/ > YouTube History and toggle off the YouTube History option:

There's an extra step if you want to delete your data. Just go to the Manage activity tab and choose which date range you want to delete your data from.

With this simple switch off, it takes me less effort and willpower to get over YouTube.

4. Block YouTube from your browser

I use BlockSite, which essentially is just a tool that blocks your access to certain websites of your choice. When a site is blocked, you don't have instant access to it by default and have to type in your password to access the site. There are also options to add even more friction such as adding extra challenges to unblock the page. Remember, make it inconvenient.

This is what I see when I type youtube.com in my browser:

I intentionally set my password to something ridiculous and difficult to remember and, funnily enough, I forgot my password 😜. Thanks to my laziness, I didn't bother resetting the password and stopped visiting YouTube altogether.

5. Schedule your watch time

Another effective strategy is to plan your watch time. Ask yourself a few questions:

When am I going to watch YouTube?
For how long am I going to use it?
What am I going to watch?
Do I watch it alone or with somebody else?
Why do I want to watch YouTube?

For example, I set out my schedule as follows: watch YouTube for a maximum of 30 minutes a day, after dinner at around 9 PM. Watch 1 or 2 chess game analysis videos from @agadmator because I want to follow what's going on in the current chess tournament.

By setting myself up to a specific plan, I'm less likely to go down the YouTube rabbit hole. I don't feel guilty for watching YouTube anymore because it now has become a tool. I regain control of my time and only use YouTube to follow my fostered hobbies.

Next, keep this schedule in a spot that's easy to see so that you have a constant reminder of your intention. For example, write it on a piece of paper and stick it on the wall. Or put a sticky note on your laptop.

6. Track your progress, but don't beat yourself up

YouTube has a handy built-in digital wellbeing tool called "Time watched profile" for tracking daily YouTube watch time. It also keeps track of your historical data for the last seven days and the rolling average. A good start would be getting into the habit of checking your watch time daily and becoming more aware of your time spent on the app.

Additionally, I keep track of my screen time with the Digital Wellbeing app on Android (or Screen Time for iOS users). Every day, I note my screen time on an external app to have a concentrated data source and further recognize my patterns. I use Notion to track progress, but you can use pretty much anything - an Excel table or even a paper calendar works too!

I don't think it's necessary to set a specific goal, like "spending less than 1 hour on YouTube". The primary purpose of progress tracking is to help you shift your focus to mindfulness. Results will come when we are intentional in our actions.

I keep track of other wellbeing factors besides screen time, but you don't have to if that's too much for you. The general idea here is to be mindful of your actions.

Finally, have fun with it! Don't beat yourself up if you don't remember your progress for one day, or if you used YouTube 1 hour more than you should today. Just remind yourself to get back to it tomorrow. Every new day is a fresh start 🎉

Conclusion

These are the solutions that I've tried and have worked for me personally. Some of these ideas might work for you while some might not. I'd suggest trying them out one by one and give yourself some time to get familiar with this new "regime". It's going to be difficult for the first week or two. You'll likely feel a strong sense of boredom and an urge to open up YouTube or any other time-sucking apps like Reddit or Twitter. It's completely normal to feel that way. Just remind yourself that you have a handful of hobbies to cultivate that will give you much more joy and satisfaction than spending 2+ hours on YouTube.

I hope this article proves to be useful in any way to you. Let me know in the comments!

Good luck 🍀

Sources

Cover Photo by Szabo Viktor on Unsplash

GitLab CI: Creating your own pipeline template library 👷

Minh Trinh — Tue, 19 May 2020 13:00:42 +0000

As developers, we all know that it is a good idea to reuse code as much as possible. We all know the DRY mantra - Don't Repeat Yourself. Functions, classes or web components abstract away logic, parameterize data, allow code to be reusable, maintainable and extendable.

With GitLab CI/CD, pipelines are defined in YAML. It's a human-readable data- serialization language (Source), so its focus is clear and concise data delivery rather than efficiency optimization. It's often not obvious how we can go about reusing code in YAML.

Today, we're going to learn how to create CI template library - a library comprised of reusable job templates that can be shared, extended, and overridden by multiple projects 👌

But first, why should I create a CI template library?

If you're a developer working on a side project on GitLab, or if your team is relatively small and your projects are diverse in programming languages and build processes, then it's probably good enough to stick to a single .gitlab-ci.yml file.

On the other hand, as a company grows, it often has standardized testing, building, and deploying processes that are applied to most internal projects. A CI template library increases time efficiency in pipeline development and decreases update and maintenance effort across the ecosystem.

To build a template library, let's first dive into the basic component of it - the job template ⬇️

Job template

A job is a basic building block of a pipeline. It usually has a single purpose, executed in isolation and, most of the time, independent of other jobs.

For example, let's say we have an awesome Node.js app called awesome-node-app and we need a job to install dependencies before building it. The install job would look something like this:

# awesome-node-app/.gitlab-ci.yml

install:
  cache: 
    path:
      - node_modules/ # cache node_modules/ in subsequent pipeline
  script:
    # install dependencies in CI mode
    - npm ci

Now, a job template is essentially a job, but it has the following extra properties:

Generic: It is project-agnostic which means it does not contain any data that pertains to a specific project.
Importable: It is easily imported and used directly in a project.
Customizable: It can be extended or overridden.

If we examine the install job above once again, it seems like we could, and should, transform it into a template. We might want to reuse it in another JS application in the future!

It's already generic enough, but not quite importable or customizable. Let's change that.

Making a template

Create and include a template

To create a template, all we need to do is move the job to a new file, install.yml:

# awesome-node-app/install.yml

install:
  script:
    - npm ci

Then, we need to figure a way to "import" and use this job in .gitlab-ci.yml file. Luckily, GitLab has a pretty sweet keyword include that allows us to do exactly that!

💡 include allows us to include and use content declared in an external yml or yaml file - either locally or remotely.

We already created install.yml locally, so let's include it at the top of our .gitlab-ci.yml, like so:

# awesome-node-app/.gitlab-ci.yml

include:
  - local: 'install.yml' # path to `install.yml`

The pipeline now has the job named install that does the same thing:

Using local file here probably won't make sense since we might want to reuse the template in another project and we do not want to just copy and paste the job definition. Remember, keep it DRY.

So let's go ahead and make a new template library that only stores templates! We can then refer to this library whenever we need to install.

Create a new repository ci-templates that's within the same group as awesome-node-app. Then, add install.yml at the root of the project. By now, you would have this:

ci-templates/
  | install.yml

Then, commit and push to master. Cool! Now your library is up and accessible to other repositories.

Let's go back to awesome-node-app/.gitlab-ci.yml, and include install.yml again, this time using include:file directive:

# .gitlab-ci.yml

include:
 # group name is your username if the project is under personal account
  - project: '<my-group>/ci-templates'  
    ref: 'master'
    file: 'install.yml'

💡We can modify ref to point to any other branch, commit SHA, or version tag of the file in Git history as we'd like. It's good practice to keep track of version history for your template file.

Great! We just basically told GitLab to "include this file install.yml from ci-templates repo on master branch into the pipeline". We now have install job imported from ci-templates to our awesome-node-app 💪

We can run the pipeline as-is - install is activated automatically without any further configuration.

However, what if we do want to change or add configuration?

Customize a template

Scenario: Right now, install only looks for dependencies declared in the package.json file at the root of a project. What if we have another-awesome-node-app that is a monorepo, and we want to run install multiple times in various locations?

another-awesome-node-app/
  | project_one/
  |__ package.json
  | project_two/
  |__ package.json

We need to parameterize our install template to take in some sort of data that holds information about the location of the package.json file we're looking for.

The most powerful way to parameterize a template is by using environment variables.

Environment variables come in two flavours:

Predefined environment variables: Variables provided by GitLab out of the box and ready to use without any specification.

💡They are references to branch names, merge request IDs, jobs info, and much, much more.

Predefined environment variables are incredibly powerful. We can do things like conditionally skipping a job in a pipeline, allowing jobs to run on certain branches, leveraging custom variables, and so on.

This topic deserves a separate article of its own, so if you're interested in knowing more about their use cases and real-world implementation, let me know in the comments below 💚

Custom environment variables: Variables defined in .gitlab-ci.yml (you can also define them in GitLab UI and via the API).

⚠️ Make sure to avoid name collision with predefined variables when naming your variable.

Custom environment variables work in great harmony with job templates. The syntax is as follow:

template:
  variables:
    # declare a key/value pair
    MY_VARIABLE: 'hello'
    ... # declare as many variables as you want 
  script:
    # call its value, this outputs "hello" in the runner
    - echo $MY_VARIABLE

Notice that the variable is declared within the job scope. This means that the variable is only accessible within the job and inaccessible from pipeline level.

Going back to our example, let's create a new custom variable named INSTALL_DIRECTORY and call it in our install script:

# ci-templates/install.yml

install:
  variables:
    INSTALL_DIRECTORY: '.' # default to root directory
  cache:
    path:
      - $INSTALL_DIRECTORY/node_modules/
  script:
    # cd to the directory of package.json
    - cd $INSTALL_DIRECTORY
    # install dependencies in CI mode
    - npm ci

One more thing before we move on, let's make the job hidden by default by changing the job name from install to .install. I'll explain how this works in just a bit.

# ci-templates/install.yml

.install:
  ...

Cool! Now we're ready to use this template in another-awesome-node-app. Let's include the template again:

# another-awesome-node-app/.gitlab-ci.yml

include:
  - project: '<my-group>/ci-templates'
    ref: 'master'
    file: 'install.yml'

We've just included .install, but this time, it's hidden, which means it's disabled by default. If you try running this pipeline in GitLab, it will not run simply because the pipeline is empty - there is no job!

So how do we use our template then?

Turns out, we can create a new job that extends our template to inherit its configuration.

Let's create two jobs install_project_one and install_project_two that extend .install. After that, we also need to change the default value of INSTALL_DIRECTORY in each job to the expected path:

# another-awesome-node-app/.gitlab-ci.yml

include:
  ...

install_project_one:
  extends: .install
  variables:
    INSTALL_DIRECTORY: 'project_one/'

install_project_two:
  extends: .install
  variables:
    INSTALL_DIRECTORY: 'project_two/'

Awesome! Now both install_project_one and install_project_two inherit the script from .install, but they find the package.json file in two different locations just like we wanted!

⚠️ Had we not specified install a hidden job earlier, we would have had one extra install job declared in our pipeline that runs in the root directory - where there is no package.json. This will fail the pipeline.

📝 To prevent side effects from including external jobs, it's good practice to declare all template jobs hidden and extend them when needed.

Going beyond templates

Mixins

We can also keep any other reusable snippets of configuration in the template library. I'd like to call them mixins.

Some mixin examples:

Bash scripts
Pipeline configuration partials

Here's one good example of what I meant by pipeline configuration partial:

.auth_gitlab_registry:
  services:
    - docker:dind
  before_script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
  after_script:
    - docker logout $CI_REGISTRY

This mixin logs the user into GitLab Registry before_script and logs them out after_script. However, it does not have script declared, which means that it cannot be run as a job.

💡script is required for job definition.

To use the mixin, all we need to do is extend it the same way we do with regular templates and, most importantly, define what's in script in the new job:


include:
  ...

build:
  extends: .auth_gitlab_registry
  script:
    - docker build $MY_APP_IMAGE
    - docker push $MY_APP_IMAGE

Summary

Here's what we've learned today:

Properties of a job template: generic, importable and customizable
Include and extend a template
Use environment variables to parameterize templates
Hide a job to prevent side effects
Use mixins to further simplify the pipeline

I'm sure there are many other techniques in building a CI template not listed here. Please let me know in the comments what you think of my approach and any suggestions/recommendations for further optimization!

I hope you enjoyed this article 💚

Cover photo by Pankaj Patel on Unsplash