DEV Community: Ricardo Delgado

Easily Handle Component Versioning with Vue3

Ricardo Delgado — Thu, 29 Apr 2021 15:09:18 +0000

VueJs is known for its simplicity and low learning curve, helping launch apps from beginners to senior devs alike.

But anyone who's spent time building up a codebase in Vue has learned with growth comes pain. Because of that it's important to address those scalable issues early on before an organization is stuck in a quagmire of tech debt and spaghetti code that can take days, weeks, and even months to correct.

Versioning components is one of those issues that can rub against a developers ego, but to care for "6 months in the future you", versioning components is an incredibly important time and energy saving strategy.

Tools like bit.dev handle this issue very well, but I'm preferential to duck tape and toothpick homegrown solutions that work just as well as a service that can cost upwards of $200 per month.

Why Do I Need To Version Components

If you're asking this question then you haven't had to deal with a design team that gets a new lead.

If you're asking this question then you haven't found a new library that more efficiently handles an issue that had been buggy since it's inception.

If you're asking this question then you haven't attended a Vue Conference and walked away thinking "duh, why haven't I always done it that way?"

In other words, your code will change, and in Vue if it's a component that's implemented in a hundred different files, then you will be kicking yourself as you ctrl+shift+F your way through your codebase.

Standard Component Usage

For this example, we'll take a simple Vue Button Component:

<template>
  <button
     :class="['button', { block, color }]"
     @click="$emit('click')">
     <slot />
  </button>
</template>

<script>
import { defineComponent } from '@vue/composition-api'

export default defineComponent({
  name: 'Button',
  props: {
    block: Boolean,
    color: {
      type: String,
      default: 'primary'
  },

  setup(props) {
    const colors = {
      primary: 'green',
      error: 'red',
      secondary: 'purple'
    }

    return {
      color: `style-${colors[props.color] || 'green'}`
    }
  }
})

Where things get tricky is if you decide to take a new approach to how you want colors to set. Rather than using a named color table it'll instead act as a pass through style.

<template>
  <button
     :class="['button', { block }]"
     :style="buttonStyle"
     @click="$emit('click')">
     <slot />
  </button>
</template>

<script>
  [...]
  props: {
    color: {
      type: String,
      default: 'gray'
  },

  setup(props) {
    return {
      buttonStyle: computed(() => { color: props.color })
    }
  }
}

This will, of course, break any instance in which you had used the Button component.

Handling Component Versions

Approaching this problem, the most straightforward solution is to create a stopgap between the code of the component, and how the component is called.

In this mindset then, we'll create a shell component that'll wrap around versioned components.

Most likely you're used to organizing your components as such:

src/
   components/
      VButton.vue

Which is probably useful in almost every scenario, but if you've happened to come across Vue - The Road to Enterprise by Thomas Findlay (which I highly recommend if you're beginning to architect large scale Vue apps), then you'll know that organizing Vue components is vital for a digestible code base.

Borrowing a few concepts from Thomas, this is a good organizational strategy to handle component versioning:

src/
   components/
      global/
         VButton/
            index.vue   <-- shell
            VButton-v1.vue   <-- versioned

This will help keep your components nice and tidy, and with folders collapsed, the various component folders will provide easy reference for the grouping of shell and versioned components inside.

Writing a Shell Component

For the sake of this Button component, and most likely all simple components, there's going to be 4 main things we have to handle when building a shell:

Passing props
Passing attrs
Carrying emits
Passing slots

But first is how to handle the loading of the versioned component file:

<template>
  <component :is="buttonComponent">
    Button
  </component>
</template>

<script>
import { defineAsyncComponent, defineComponent } from '@nuxtjs/composition-api'

export default defineComponent({
  name: 'VButton',
  props: {
    version: {
      type: String,
      default: 'v1'
    },
  },

  setup(props) {
    const versionComponent = (version) => defineAsyncComponent(() => {
      return import(`./VButton-${version}.vue`)
    })

    return {
      buttonComponent: ref(versionComponent(props.version)),
    }
  }
})
</script>

Thanks to old tried and true <component> paired with Vue3's defineAsyncComponent this was actually a fairly easy lift.

Next is handling props, attrs, and emits:

<template>
  <component
    v-bind="{ ...$attrs, ...$props }"
    :is="nButtonComponent"
    @click="$emit('click')">
    Button
  </component>
</template>

Using built-in elements $attrs and $props, attrs and props are very easily passed to a child component to be digested.

And lastly, slots:

<template>
  <component
    v-bind="{ ...$attrs, ...$props }"
    :is="nButtonComponent"
    @click="$emit('click')">
    <slot
      v-for="(_, name) in $slots"
      :name="name"
      :slot="name" />
  </component>
</template>

The one flaw with using $slots is that they're not dynamic, but this mostly gets the job done. Since each shell is specific to each component then it would be easy to more explicitly define slots if need be.

And that's it. It's easy as importing your component just as you might normally:

import VButton from '@/components/global/VButton

But then when you use the component, passing a version prop notifies the shell which versioned component to use, and that should help curtail many breakages and allow adoption of the change to be handled over time:

<Button
  color="purple"
  version="v1"
  @click="handleClick">
  Click Me!
</Button>

Note: This is an MVP for this concept. Someone can rightly criticize this approach for some of the following reasons:

It's not globally useable
It could be much strong written in pure Vue3 render functions (this example comes from a Nuxt 2.15 app using the nuxtjs/composition-api plugin, which is missing some features from Vue3, including resolveComponent which would most likely be able to solve this issue)
This wouldn't be useful for more complex components

While these are true, I still think this is a very useful strategy especially if you are the type of dev who builds their own UI from scratch.

Update

After a bit of messing out on codesandbox, I put together a working example that also uses the render function as the shell component:

Note: In this Vue3 example slots can just be directly passed as the third parameter, but in Nuxt (and possibly Vue2 with the composition-api plugin) it needs to be: map(slots, slot => slot) using lodash.

Update 2

After working with the concept for a bit I hit a particular tricky spot - emits.

The issue with emits is that, to my knowledge, there isn't a way to handle a passthrough of them as directly as you are able to with props or attributes.

This makes the shell component a bit less "user friendly" because each shell becomes more customized, and forces there to be two components that need to have emits maintained.

This is not optimal.

Then I remembered an article I read about an anti-pattern in Vue, but a common one in React, passing functions as props (I wish I could find the article to link to it).

Rather then:

@click="$emit('myFunction', value)

It becomes:

@click="myFunction(value)"

// in <script>
props: {
  myFunction: Function
}

I will say that this strategy is helpful on high-level components, but very low level components, like a button or input wrapper, would probably still be best served using emits in two places so that their events are easily consumed.

Using Nuxt's New @nuxt/content Module To Launch My New Portfolio

Ricardo Delgado — Wed, 02 Sep 2020 22:29:37 +0000

It was about time I spruced up the old portfolio website, and the timing was perfect as it lined up with Nuxt introducing a new content generation module - @nuxt/content module.

Adding Content To A Nuxt Project

The setup for the @nuxt/content is the same as any other new nuxt project. I prefer using:

yarn create nuxt-app <project-name>

Then you can add the module:

yarn add @nuxt/content

And in your nuxt.config.js file add:

{
  modules: [
    '@nuxt/content'
  ]
}

Additionally, you'll want to make sure your Nuxt app is set to universal to have access to asyncData, and I'm using static page generation.

And that's it for the heavy lifting. This level of simplicity makes it quick and easy to get to the fun part and create your site.

In your nuxt project, you'll now have a new folder called content, and within that folder you'll be storing all your posts. I'm going with markdown but there's any number of different file types that Nuxt content can parse including yaml, yml, csv, json, json5, xml.

Each file has a front matter area, which is similar to dev.to's input area:

--------
title: Title
description: Add a description
--------

Along with built-in properties dir, path, slug, extension (ex: .md), createdAt, updatedAt, you can also add custom ones, such as tags, which can be used to query content.

File Structure

Next you'll want to create your file structure to handle loading your pages correctly.

First thing, in the content folder I'm adding a sub-folder for just articles, just in case in the future I want to have another content type available for use.

- content
  + articles
    - new-articles.md

Then in the pages directory I'm going to add:

- pages
  + articles
    - _slug.vue
    - index.vue

Notice that I'm going to leverage Nuxt's built in routing to create a page that accepts the slug as the path name, which is the article's file name. This will help long term with SEO, so make sure you're naming your files with that in mind.

Retrieving Content

This is where things get really fun.

The power of the Content module is that it adds $content to the context.

$content is the built-in plugin that allows you to reach files within the content folder.

Basic usage:

async asyncData({ $content }) {
  const docs = await $content('articles').fetch()

  return {
    docs
  }
}

By default, $content receives two-ish parameters, the first is the path within the content folder, the second are options. The reason I say two-ish parameters is because as you add parameters to the beginning of the call to create a specific file path.

Also, note the use of asyncData in this example and within the docs. Something to keep in mind is that asyncData is only accessible to files within the pages folder, otherwise if you wanted to use it in another area, such as in a component, you'd have to use the beforeMount lifecycle hook using this.$content.

Displaying Content

Another handy bit of functionality that comes with the module is the <nuxt-content> component.

Basically, it accepts the returned content from asyncData and displays it without any handling.

From the above example, since we returned an array of articles, then your template would look something like:

<nuxt-content
  v-for="doc in docs"
  :document="doc"/>

And that's it! Everything translated properly from your content files beautifully on the page.

Leveraging Content

While a lot of cases will be handled with the basic usage of $content here's just a couple of examples on some more things you can do with the content module.

Accessing a specific article

Since the content path spreads, you can use $content coupled with another context element $params to retrieve specific articles.

async asyncData({ $content, params }) {
  const doc = await $content('articles', (params.slug || 'index')).fetch()

  return {
    doc
  }
}

This allows for an incredibly clean and SEO friendly way to share posts and articles.

Creating an articles index page

Some of the other functionalities of $content are focused around querying your content files.

Some examples are only, sortBy, and limit, but you can find the complete method listings here: https://content.nuxtjs.org/fetching

To create an articles index page, we're going to aim for a few specific criteria:

Limited to 5 posts
Shows only the header, the date, and the description
Sort by most recent

To accomplish this we can do something like this:

async asyncData({ $content }) {
  const articles = await $content('articles')
    .only(['createdAt', 'title', 'description'])
    .sortBy('createdAt', 'desc')
    .limit(5)
    .fetch()

  return {
    articles
  }
}

Then in your template, you can specifically handle the various items:

<div v-for="article in articles">
  <h2>{{ article.title }}</h2>

  <p>{{ article.description }}</p>

  <small>{{ article.createdAt }}</small>
</div>

Simple as that.

While using the content module can create simple websites incredibly easily, I can envision some enterprise uses as well.

Looking forward to diving even deeper into @nuxt/content.

This article is cross posted from https://ricdelgado.com/articles/nuxt-content-new-site

Mocking Nuxt Global Plugins to Test a Vuex Store File

Ricardo Delgado — Wed, 06 May 2020 20:47:31 +0000

This is one of those edge cases that drives a developer up the wall, and once it's finally solved you run to The Practical Dev to hopefully spare someone else the pain you went through.

I've written previously about Vue Testing: VueJS Testing: What Not How, and since then have become the "go-to" for my company's Vue testing issues.

But this one was quite a head scratcher.

The Problem

Vue's testing is pretty straight forward thanks to vue-test-utils. Testing components is really easy, as long as pieces are properly broken down to units (see my post).

With vue-test-utils you can mount components locally within the test file, test against the local mount, and ta-da tests.

Via the mount, and Jest's functionality, things like plugins and mocks can be handled either locally within the file or globally within config or mock files.

This problem, though, has to deal with Vuex Store files which are not mounted. This is because state, actions, mutations, and getters are tested directly and not within the Vue ecosystem (which behave differently than if tested directly).

Sample Vuex Store file:

export const actions = {
    testAction({ commit }, data) {
        commit('TEST_MUTATION', data)
    }
}

export const mutations = {
    TEST_MUTATIONS(state, data) {
        state.data = data
    }
}

Sample Vuex Store test file:

import { cloneDeep } from 'lodash-es'
import * as testStore from '@/store/testFile'

describe('@/store/testFile', () => {
    let actions,
        mutations

    const cloneStore = cloneDeep(testStore)

    beforeEach(() => {
        actions = cloneStore.actions
        mutations = cloneStore.mutations
    )}

    it('test action calls test mutation', () => {
        const commit = jest.fn()
        actions.testActions({ commit })

        expect(commit)
            .toHaveBeenCalledWith(
                'TEST_MUTATION',
                expect.anything()
            )
    })

Approaches

This issue circled around a global plugin called $plugin, which is a plugin that was created to handle api requests globally.

This means that within the store file there is no imported module, and therefore rules out solutions such as jest.mock() or adding a file to the __mocks__ directory.

This also ruled out adding to VueTestUtils.config, since again there is no Vue instance to test against.

Every time the test was run it returned $plugin as being undefined.

Solution

The solution to this problem is actually pretty easy, and I'm a little surprised it took so long to figure out.

Here's an example of what an action like this may look like:

export const actions = {
  async testAction({ commit }) {
    let data

    try {
      data = await this.$plugin.list(`endpoint`)
    } catch (e) {
      console.log(e)
    }

    commit('SET_DATA', data)
  }
}

When imported into a test file, it acts as a pure function, without having anything to do with Vuex functionality.

That means that this refers to the actions variable, and not a Vue instance!

Once that was cleared up, I added this to the beforeEach loop in the test file:

actions.$plugin = {
  list: () => {
    return [{}]
  }
}

And that's all. No more failing tests, and no more undefined plugins.

Appreciating The Iteration

Ricardo Delgado — Mon, 27 Jan 2020 12:56:53 +0000

Software Engineering is a modern day dilemma akin to Don Quixote charging at windmills in attempts to slay dragons.

It's miraculous to watch people in a team spend hours upon hours discussing solutions for problems that are as easy to reach as sending the Space Shuttle to Proxima Centauri.

It's the moment when the title Engineer is most obvious, mentally walking down branches, attempting to avoid future pitfalls for solutions that haven't even been implemented.

Internally, the Engineering mind is quite fun and exciting, yet a boiling cauldron of contradictory realities of insecurity and deep set assuredness.

One of the hardest issues that I've faced in my short time as a professional Front-end Developer is accepting that my job is one that can't give me a sense of daily accomplishment in return for a full day of writing code.

All arrows are pointing to completion, finishing the task, launching a product, meeting timelines, and not disappointing users and bosses alike.

I'm grateful for the company I work for, because they're acutely aware of Developer burnout and push hard for us not to cross 40 hours of work per week.

Nonetheless, the opposing force of "finishing a product" pushes back hard, and I cannot deny that as a deadline begins to approach, the pressure mounts no matter how hard you may be told not to let it.

These are how the seeds of stress are planted. It's how coding standards and a programmer's well-being are put aside for the sake of meeting an artificial line drawn in the sand. All to be able to click a checkbox to move a project from version 1 to version 1.1?

These things don't do much to motivate.

To me there's nothing better than the act of creation and making it work. The dopamine hit of seeing a problem and solving it, which may or may not align with administrative goals in project estimation.

How then can an engineer maintain a sense of completion in workflows that are never complete?

This is so hard to mentally understand as the most obvious signs are pointing towards finality and accomplishment. As we lust over that moment we can put down our tools, kick our heels up, and say to ourselves, "ah ha, this is just how I wanted it."

That dream is impossible, and chasing these ghosts of our imagination can drive someone mad.

Leaving these aside, what measure can be used to feel our way through a workday? If far off goals leave you feeling empty and unaccomplished, how can someone maintain a perspective to avoid falling for the pitfall of "completion"?

Take yourself back to your first code camps. Or the first coding lessons you took. Or the first time you wrote actual code.

Think back to the first time you figured out how to use a loop, manipulate data, move an UI element with the click of a button? Whatever those early senses of achievement may have been.

Knowledge is a powerful drug, as well as a destroyer of the simplicity.

But that doesn't mean that the simple excitement of basic accomplishment is gone, it just means that you stopped paying attention to it in lieu of something you believe to be more compelling.

Allowing the mind to keep searching for more and more complex problems to solve may be the foundation of your pay rate, but unfortunately leaves the beauty of the mundane by the wayside, a tragedy to chasing achievement.

If feeling lost and bored while developing, and stressed at far off goals, allow for a challenge to bring things back to basics.

Bring your attention back to the moment by moment pleasure that you feel by solving problems, breaking down a puzzle, and connecting with fellow like-minded people who are driving towards accomplishing something together.

Leave behind the wide-viewed problems, and find your way back to the smallest of accomplishments.

Then iterate it. Again and again and again.

Placing emotional payoffs in small, everyday accomplishments will quickly make far off, nearly unachievable focuses seem silly.

By the time a goal, artificial or not, is reached, you've had hundreds upon hundreds of little victories. You won't be worried about putting things down to take a break after "accomplishing something so huge," you'll be excited about tomorrow's fun and excitement for a whole new set of accomplishments to achieve.

Ultimately, you and your mental well-being are more important than any product that could be made - sacrificing that for any reason will do nothing more than keep any long-term goal from being accomplished anyway.

And why sacrifice both to accomplish neither?

Rebuilding A BBS Relic

Ricardo Delgado — Sun, 19 Jan 2020 14:42:05 +0000

I'm reaching that point in my life where I get to shake my fist at the clouds, and yell at these young whippersnappers about how much better online gaming used to be in a time before the internet.

What's this oxymoronic sentence I wrote, you may be asking? Online gaming before the internet?

That's right kids, there indeed was a moment in computer history pulling together the two separate moments of playing chess against a 16-bit Intel 8086 Processor and neverending worlds of Orc battles.

You may or may not be familiar with this sound:

But this was the sound of pure online communities. It wasn't to connect with people from around the world, but rather other nerds in your neighborhood.

It's hard to imagine, but Bulletin Board Systems (BBS) formed in a time before being a nerd was cool. When being too smart or being different meant that you'd actually be a societal outcast.

BBS were one of the rare places where refuge could be found amount like-minded weirdos, and of course one of the first aspects to grow out of the new communities was robust gaming community.

Captured in AMC's now defunct tech-drama "Halt and Catch Fire", the rise of BBS, preceding the browser wars of the early-to-mid-90s, was something that could be compared to the childhood of the internet: naive and innocent.

It's still my favorite time of my personal history dealing with computers.

And since I'm hitting my nostalgic years, I thought it was about time to revisit one of my favorite BBS games - Barren Realms Elite.

Barren Realms Elite was a turn based strategy game, where you would make various decisions around war, banking, land use, etc., to defeat other people in the game.

While that was fun in and of itself, what I miss the most is playing a game where you only get one turn per day.

Rebuilding Barren Realms Elite

The original BRE, which was based on an earlier version called Solar Realms Elite, and developed by Amit Patel can be found here: http://www-cs-students.stanford.edu/~amitp/Articles/SRE-Documentation.html

There's also some online BBS modulators where you can plan the original version as well: https://archive.org/details/msdos_Barren_Realms_Elite_1999

What was done is amazing, and it'll be the foundation for my new project:

LORD DYSTOPIA

To keep things simple, I'll be developing the game in NuxtJS (VueJS), with a Firebase backend. Before there is any comments "why build it with that" - it's what I know best and can develop in the fastest.

Lord Dystopia will share many of the same features such as warring, trading, covert operations, and land usage.

Games will be up to 25 players, and will have a length of 1 month, with point totals being determined by troop totals, food, land, money, and some other factors with the winner having the highest point totals at the end of that month.

Most importantly, though, is that each player will only have one opportunity per day to take up to 5 turns.

Thankfully there won't be much, if any, need for visual aspects and I can focus on game play and functionality.

I want to state upfront that this is a fun project that I'm choosing to work on for nothing more than a love of programming and missing a game I used to love playing.

If you're interested in signing up to be a BETA tester, please send an email to: lorddystopiaonline@gmail.com

Thanks! Look forward to seeing you on the battlefield.

Cultivating A Positive Attitude To Be A Better Dev

Ricardo Delgado — Fri, 08 Nov 2019 14:00:40 +0000

The interconnectedness of building products demands that even the most technical roles requires you to be a pleasant coworker for the sake of your team.

While in theory that seems like great advice, the details are easily lost, especially to people who tend to be naturally introverted and don't have naturally strong skills in social dynamics.

I'm writing this post on DEV in the lens of making your workplace an easier situation to exist in, but this mentality easily extends beyond that. Whether it's family, friends, neighbors, new situations, or anything where it's required for you to get along with others, a positive attitude will benefit you in unimaginable ways.

People Like Happy People

There's going to be a strange underlying sentiment behind this post - "should I act this way to make other people like me, or should I do it to feel better in my life?"

This is a very valid question, and truthfully there's no set answer.

Personally, I'm a bit rebellious, grew up listening to punk rock, and generally don't mind pissing people off. One time in college someone told me they'd never seen me smile, and truthfully I think I would've been able to live my entire life rarely leaving my apartment unless it was necessary.

But, that attitude didn't do anything in terms of progressing my life, and especially made it difficult for me to deal with other people.

School, work, friendships, family... most of these situations were a living hell for me.

If there were other people involved, there would always be some kind of drama or conflict.

For me learning how to cultivate a positive attitude not only made my normal interactions better, and helped get me my current position as a software engineer despite not having professional experience (and I've been informed my attitude is a reason why), but it's made my daily life feel so much better.

There's no Sophie's Choice. Whatever your motivations may be, cultivating a positive attitude will improve your life in a multitude of ways, including workplace success.

Worrying Too Much About Others

When I made my first leaps into changing my life outlook, I realized that I was constantly looking at the things other people did and judged it.

"Why did that guy make that wrong turn? What an idiot!"

"Why would someone leave this here? That's so inconsiderate!"

"Who would say something like that? They must be a selfish jerk!"

"My boss said something rude! He's totally incompetent!"

And are any of these statements wrong? Probably not.

The problem is the sphere of your attention and focus, and how it undermines your ability to be in control of your circumstances.

Accept this upfront - there is no perfect world in which you can currently live in.

The fact is that no matter how much you complain, get upset, honk your horn, or yell at your tv, you will never be able to change the way other people behave.

This doesn't mean that you should become a mat that people can walk over and abuse. But allow your focus to peel off from them and return to you.

Ultimately, I think there's two subconscious self-destructive mechanisms at work:

You're disappointed in the world you see around you. It hurts deeply when they don't ascend to your expectations of excellence, and
You aren't deserving of your own attention, and it going to others is a way that you punish yourself by not allowing yourself to feel good about you and your life.

This is normal. Most people live inside of this world. Don't beat yourself up about it.

But, I will turn it around and say, how many times have you messed something up in your life? Be it minor, like making a wrong turn, or not carefully watching what you say.

Let's say it happens 3 times a week.

Now think about how many people you cross paths with on a daily basis. And it may be possible you may have witnessed one person, out of the thousands you may come by, do one of their 3 screwups.

Assuming The Best In People

A lot of the issues that arise around dealing with people is the assumption that you know their intentions.

Unfortunately, the human mind hasn't evolved the ability to mind reading yet, and if anything recent studies show that people are terrible at understanding each other's intentions.

Often times when dealing with other's, especially in the work environment, there's an unfortunately thick layer of suspicion and defensiveness.

There's a strong desire, for example, to always interpret your boss's directions as a criticism of your work.

Leading to: "why would they say that? Why would they do those things? Don't they know I'm working hard?"

When, in reality, your boss may actually have something in mind that you don't know or aren't privy to. Or, even better, they're truly trying to help you become a better worker.

Of course, on the other hand, you may have a sociopath as an employer. I've had a few myself. Every critique was actually a power move on their part, trying to demean me for their own ego inflation.

The problem is that even in those worst of circumstances, people have nowhere near the amount of introspection to realize that they're doing unfair actions towards a subordinate. To them its justified management.

The question again boils down to measure of control.

Even at the two ends of the spectrum, assuming people's best intentions solves both scenarios.

As an employee, if you take direction and assume that it comes from the best place, you will be thankful and appreciative that your boss is concerned about you doing the best work you can.

Even if their intentions are not fully wholesome, you at least will placate their issues and most likely will leave you alone because you're not giving them the pushback they're looking for.

Of course, if you do have a sociopathic boss, please go looking for a new job - it'll especially be much easier to find one with a new positive attitude!

Practical Steps

Positive Affirmations

Positive affirmations are more commonly known as "fake it till you make it," and are one of the most powerful ways of improving your mentality.

First, take a sheet of paper, fold it in half, and write down 5 to 10 negative self-thoughts or beliefs you hold on the left side.

On the right side write the positive take on the negative side, being careful not to state it negatively.

For example:

Negative: I am not a hard worker
Positive: I enjoy taking my time with work, and don't put unrealistic demands on myself

A less effective positive spin would be something like: I am a hard worker.

The key is not to lie to yourself, but to instead change your thoughts from negative to positive. While what you're focusing on specifically is important in a certain way, it's more a matter of redirecting the internal process and voice inside your head.

After you've created a list of 5 to 10 affirmations, tear them away from the other side of the paper, and now you have a list of things to repeat yourself daily.

Maybe post them on your bathroom mirror, and repeat them to yourself. Or maybe on your fridge. Basically anywhere you'll remember to repeat them to yourself regularly.

It's also important that when you feel the negative thought arise, you gently guide them to the positive affirmation.

It's vital not to see negative arising thoughts as bad or wrong, but rather a built in neurological connection between two points in your brain that you're trying to redirect somewhere else.

Doing this regularly will create a more harmonious internal experience, which will then reflect to the world around you.

Daily Meditation

I wrote last time about how to get started meditating, so I won't get too much into the mechanics.

I wanted to focus on one main key that's a byproduct of meditating - becoming less reactive.

Meditation, in part, is the act of constantly watching your thoughts from a distance. Reinforcing this feeling over and over again, eventually you learn how to keep a healthy distance from them, and don't react quite as quickly as you normally would.

In a work setting this can be the difference between a healthy meeting, or an ugly one that turns personal.

Being able to maintain distance from an arising thought like, "why would they say that?" in the middle of a high pressure situation that can happen in certain meetings, can save a lot of potential headaches.

You'll find yourself acting more like a mediator between yourself and the external world, rather than a combatant.

These are only a few small things that can help relieve a great deal of pressure that comes with the odd dynamics we find ourselves in because of work.

Becoming more light-hearted, more present, less argumentative, more helpful, patient, and understanding can be hugely important in progressing in your career.

But beyond that, it can also help greatly in your personal life. And that kind of benefit is worth investing time in.

Some other great resources:

Incorporating Meditation Into Your Programming Routine

Ricardo Delgado — Mon, 28 Oct 2019 15:05:15 +0000

It's easy to get lost in the specificity of a career in computer science.

What's the right framework? Which language is the best? Mac vs Windows vs Linux? Tabs vs spaces?!

Unfortunately, the surrounding foundation can sometimes be left untended. How good of a programmer can you really be if you're fraught with anxiety and depression? Or in a less dramatic way, unable to clear mental clutter while making decisions?

This is not a cure all

Often in the meditation and spiritual communities, meditation is sold as a cure for all mental and physical issues.

It's too easy to go to a "guru" and ask for help in a situation, and the response be "meditate more."

Rather than that, I'd instead try to propose seeing meditation as a structure in which one can build stronger mental tools. While there are numerous personal benefits to it, for the sake of posting this on DEV, I'd rather focus on how meditation can improve your skills as an engineer.

Mental Clarity

Without a doubt, a good meditation practice can clear out a great deal of the mental chatter that torments the inside of many people's minds.

This includes negative self-talk, constant self-doubt, a layer of suspicious interpretation while communicating, and that general stream of internal voice that never seems to quiet when you want to focus on work.

One of the most important lessons when learning meditation is that you are not your thoughts, a concept made most famous by self-help author Eckhart Tolle.

As an industry founded on thinking this may be a hard pill to swallow, but to maybe loosen your assuredness, watch this video by Neuroscientist and meditation teacher Gary Weber about thoughts:

In essence, quieting your thoughts and relaxing the feeling of ownership over problem solving (and seemingly "higher cognitive functions"), allows for smoother thinking.

Stress and Personal Relief

While I don't want to focus on the de-stressing aspects of meditation too much, I will at least ask you if taking a small amount of time out of your day is worth providing a reduction in your stress?

What if 10 minutes of meditation reduced your stress by 5%? Would that be worth it?

What about 20 minutes, reducing 20%?

It's just something to keep in mind. Again, this is not a cure-all, but it does help to focus on the fact that a small investment of time can have a noticeable, and not insignificant, return.

A Very Beginner's Guide To Meditation

It is more than possible to fully immerse yourself in all the various types of meditation practices, find yourself on a week long retreat, and be on the path to full blown enlightenment.

These things are possible, and there are many people pursuing it and experiencing it everyday.

But that does not need to be the goal of your practice. Technically anyone's practice can be whatever they'd like it to be - as long as it's wholesome.

In this article I'll focus on a very basic concentration practice that only needs to last 10 to 15 minutes, and will have a good effect at relaxing the mind.

While it's not required, I will add that personally I have experienced the benefits of moving beyond the beginner level of meditation. Some teachers, like Robert Thurman, would argue that solely doing concentration practice without diving into the deeper practices only achieves temporary gains, as opposed to the massive and life altering changes that happen with a more serious meditation practice.

But for now, we'll happily take the temporary gains for the sake of career betterment.

Getting Started - What To Focus On

Let me say this upfront, and I want you to hear this in your head as you get started - you will never ever stop your thoughts as a beginning meditator.

This is by far the loudest feedback I hear from people when they tell me that they've tried meditation but didn't continue their practice.

"I stopped because I couldn't get my thoughts to stop."

Let me reassure you, if you were a meditator for 10 years, and you managed to silence your thoughts, it would be seriously impressive.

This is perhaps born from a Westerner's interpretation of what a process is about - focusing too much on the finish line while losing the joy of the action itself.

Yes, you will have thoughts. Yes, they will drag you away from the nowness you're trying to achieve. Yes, it will be distracting and you can feel frustrated if you focus too much on "I didn't win this meditation round."

There's two things to be aware of:

This is a practice. That means that how you go about it is how you will do it. If you make your practice relaxing and enjoyable, you are practicing relaxation and enjoyment. If your practice is frustrating and unpleasant, you are practicing frustration and unpleasantness. These things will carry into your life because you are practicing them.
Even though "you are not your thoughts", you are also your thoughts.* And any frustration you push towards your thoughts, you're also pushing on yourself. This will have the opposite effect of relieving stress that you're trying to achieve. In the "you are not your thoughts" domain, try to give yourself direction, but don't be cruel, mean, or lacking sympathy to thoughts - as they are yourself in a way. Practice loving yourself and your mind and you will be more loving towards yourself and your mind.

** Note: If there's anything about spiritual and meditative practices you'll have to be comfortable with its contradictions. I apologize ahead of time to all the hyper-analytical thinkers.*

Sitting Form

Let me be upfront - this kind of stuff doesn't matter much. Before listing out the traditional sitting positions, know that what's important is that you're comfortable enough to sit in one of these positions for long periods of time.

Other than that, if you're sitting, it's about good posture. A long back, shoulders high, and stable posture are perfect. If you're laying down, maintain a position where you won't fall asleep (unless you're trying to fall asleep!).

Full Lotus

Each foot rests atop the thigh of the opposing leg. This is a very traditional position, but can be very tough on the knees and legs for people who haven't been practicing in this position from a young age.

Half Lotus

This is my preferred sitting position. One foot sits atop the other's thigh. Easier on the knees.

Seated

The typical way Westerners sit. Totally ok for meditation, make sure to maintain good posture and relaxed arms.

Chair Sitting

If you are older or have physical limitations, sitting in a chair for your meditation is great. This is also good to remember for anyone who wants to meditate during their commute to work or at a park.

Laying Down

While not ideal, learning how to meditate while laying down can help many people overcome insomnia.

What should I do with my hands?

You may notice some interesting hand positions in meditation statues, often referred to as mudras.

While they have pretty interesting interpretations, one of the easiest is to lay your hands comfortably in your lap. Really it's about making sure your shoulders are relaxed.

The Practice

While I'm going to focus on concentration practice, there are an endless number of meditation practices out there. My personal favorites tend to be noting practice and self-inquiry. I'll put a list of resources at the end of the post.

But concentration is a great place to start. It has the most immediate "feeling better" results, especially if you take the time to really enjoy your time taking a break from the a noisy world.

Again, and to repeat this over and over and over again, you will not be able to quiet your thoughts. You will get distracted by work dramas, or life issues, or anything else that pops up into your psyche.

But stop seeing these as distractions. Rather, this is about the continual act of observing your thoughts and realizing that they're "over there" and you're "over here."

To take it one step back for a second: A thing observed can never be its observer.

If you are observing your thoughts, you are therefore not them. While meditating remember this dynamic when you get lost in thought, acknowledge your thoughts, and then gently guide yourself to your concentration. This is a great moment to practice patience and be understanding to yourself.

Between that dance, which happens over and over again, set yourself a goal of focusing on the breath exiting your nose.

Try to sense it flowing in and out of your nostrils. See if you can even concentrate strong enough to feel it flowing across your nose hairs.

Next focus on the cyclical rhythm of your breath. Feel it flow out of your nose, then back in. See if you can concentrate on the exact moment when you shift from breathing out to breathing in.

See if you can notice when your breath begins and ends. See if you can sense when it feels like it's "the middle" of your breath.

You can even use a naming convention to it. Something like, "in" and "out" or "start", "middle", and "end".

See if after awhile you can shift from speaking these things in your head, to wordlessly recognizing the same breathing cycle.

If you feel like it's beginning to be hard to focus on your breath, you can try focusing on something else - like your hands resting, your chest breathing, your diaphragm rising and falling, etc.

It's ok to not do this perfectly, and do it in your own way. The most important aspect is attempting to maintain focused on your object of focus, and eventually widening to what's around you.

But first and foremost, just enjoy your sit. Allow thoughts to rise, allow yourself to try (and fail) to concentrate. Be patient with the process, and allow all the hidden benefits discover themselves.

Resources

I would recommend Mastering The Core Teachings of The Buddha or The Mind Illuminated for anyone wanting to have an indepth explanation for how to mediate.

A Visual Strategy To Handle On-Going Tasks

Ricardo Delgado — Mon, 21 Oct 2019 11:43:38 +0000

Is there anything harder than getting your workflow in order? Between bullet journals, Trello, Monday.com, Git, or whatever else it may take to get things in order, it's obvious that keeping things tidy is quite a challenge - I'm especially looking at you solo entrepreneurs and freelancers.

While it feels like technology should be the best way to solve this problem, like with many things, it doesn't quite get the job done.

How many tasks are left open because you didn't want to add that last note to close out a task? How many journals have the first few pages filled out, only to get frustrated with the monthly task of re-writing and re-organizing what you've accomplished (which seems like way too many)? Who hasn't gotten annoyed at the tedium of rewriting the same task every month?

For something like this I like to go old school. And I thought I'd share an organizational strategy I find very helpful to get long-term tasks accomplished (or keep long on my radar).

Keep It Visual

Like holding a book, looking at a globe, or admiring the paint strokes on a Van Gogh painting - sometimes it's better to see something in front of you to really "feel" what's going on.

For my Visual Organizer I use cut up index cards pinned into a corkboard. You could just as easily use Post-it Notes and tape, even though I prefer pins because they don't lose their stickiness.

Cut your paper into two different sizes. The larger papers are going to be for the day headings, and the smaller ones will be your tasks.

The board is set up so there are series of multiple tasks on the left, while the days of a work week (for me it's Monday to Sunday) are set to the right.

While other organizers focus on accomplished tasks, I'm focusing on establishing a work schedule in which I can track the attention I give to a certain task.

In my experience it's far too easy to get lost doing a specific job, while others fall to the side as I go down the proverbial "get it done" rabbit hole.

Instead, I want to focus on carving out time in my schedule to work on specific tasks while visually seeing what else I have to do.

The idea is to break down my task slips by the amount of days per week I'm willing to focus on a particular job.

Big jobs may need attention for every day of the week, therefore requiring 7 slips. While smaller jobs may only need two or three days per week (2 or 3 slips).

The amount of time you want to spend on each is entirely up to you, and determined by how many tasks you are trying to accomplish. A good possible strategy is writing a specific amount of time you're willing to give that task on each slip, and setting a timer as you work on it.

The key is not focusing on completing a job, but rather, giving consistent attention to a multitude of tasks, inching each closer to the finish line without any stragglers.

As each job is given attention for the day, then you move the task under the day in which you worked on the task.

As you fill out your week, you can visually see what hasn't been given attention, and what is.

Then, at the end of the week, you move your pins back to the beginning and start over again.

A good example would be:

5 slips dedicated to a solo business project
3 slips dedicated to a course you want to take online
2 slips dedicated to learning a new language
2 slips dedicated to a small portfolio project

This is a strategy to complete tasks that can last several days, weeks, or even years. This is about properly parsing your attention, so that nothing can fall through the cracks.

VueJS Testing: What Not How

Ricardo Delgado — Mon, 14 Oct 2019 20:30:33 +0000

I've been focused so much on testing within VueJS lately that I really wanted to get some thoughts about it down in a post.

This especially occurred to me yesterday as I was writing a new component, and approached it purely from a Test Driven Design (TDD) direction.

When I first heard of TDD it seemed totally unappealing. I couldn't mentally integrate writing tests before code.

Before getting started, let me clarify that this is not a tutorial on tests or testing in VueJS. I'm assuming that you may have taken a stab at testing and became frustrated or didn't see the use in it (a position I was in for quite a long time myself).

Even though this post isn't about how you go about writing tests, Vue has tremendous documentation on it.

Here's my personal favorite resources on writing tests in VueJS:

Vue Test Utils
Vue Testing Handbook by lmiller1990
Edd Yerburgh's Testing Vue.JS Applications

To start with, my non-test driven way of coding would usually entail writing lots of lines of code, and when I thought of another feautre I wanted then I'd write the appropriately needed functionality.

For example, if I was writing a page for a calendar, I would start first with the main Vue file:

<template>
  <div>

  </div>
</template>

Then wholesale write some code to accomplish what I wanted:

<template>
  <div>
    <div>{{ title }}</div>
    <div>{{ currentDate }}</div>
    <div>{{ dayOfWeek }}</div>
  <div>
</template>

<script>

export default {
  name: 'Test',
  data: () => ({
    title: 'The title'
  }),
  computed: {
    currentDate () {
      return new Date()
    },
    dayOfWeek () {
      return this.currentDate.getDay()
    }
  }
}

</script>

Alright, great, a nice and easy to understand a Vue component file... but actually, I just realized I want this calendar to show multiple days of the week.

And what about date formats?

And what about in various languages?

And...
And...
And...

Anyone who's built an application should know this feeling. And while this example is very straight forward, what happens when it's not?

Something that is incredibly appealing about Test Driven Design is that it slows down the process.

Sitting down and slamming your keyboard over and over again, may get digital letters, numbers, and symbols to pop up on your monitor, but is it necessarily effective in the long run?

Of course, if you have a pretty small, simple project, then by all means feel free to skip TDD, but keep in mind the point of TDD is to break your code down into small manageable parts.

Which leads to the first major mental hurdle about testing I'd like to make:

Break Your Code Down Into Easy To Manage Pieces

It's so hard not to indulge the awesomeness of programming and write super complex functions to handle whatever your component may need.

Without a doubt coding is fun, interesting, and compelling all at the same time. Its power will course through electronic veins and arteries like lightning combusting a tree in the middle of a lonely forest.

But it wasn't until I came across this slightly unrelated example in VueJS's official style guide for simple computed properties that gave me a programmatic epiphany:

Bad

computed: {
  price: function () {
    var basePrice = this.manufactureCost / (1 - this.profitMargin)
    return (
      basePrice -
      basePrice * (this.discountPercent || 0)
    )
  }
}

Good

computed: {
  basePrice: function () {
    return this.manufactureCost / (1 - this.profitMargin)
  },
  discount: function () {
    return this.basePrice * (this.discountPercent || 0)
  },
  finalPrice: function () {
    return this.basePrice - this.discount
  }
}

I've seen that bad example in my code a million times, and without getting too lost in the details, the point is to focus on the concept of breaking things down to make them easier to digest.

While this is a good rule for almost every aspect of writing code, it also makes a lot of sense in testing, and I would argue is a good place to start to write "testable code."

For example, imagine a method that you want to test that looks like this:

testCode (value) {
  const variable = value * 2
  const variable2 = this.computedValue * 3   
  const variable3 = this.transformValue(value)
  const variable 4 = async function() {
    await return axios(...)

...

You get the point.

I used to think that there was a flaw with testing while attempting to tackle a complex function that I'd written.

As I attempted to write my way out of a maze of nested functions and asynchronous behaviors that functioned the way I wanted, I'd find that it wasn't easy to write tests at all for it.

Looking at the above testCode method, there's at least four different aspects that need to be mocked to get a single test to work.

Unfortunately, you'll find yourself wondering why even write the test at all, since it feels as if the entire function requires every aspect to be mocked anyway.

Writing Testable Code, A Subset of Test Driven Design

The more that I work with tests the more I'm willing to believe that tests don't hold much value unless your code was written with Test Driven Design.

On the one hand, it is entirely possible to revisit your code, and try to think your way through what tests need to be written by analyzing what's there.

Take the following example:

<template>
  <div :class="{ myClass: isTrue }">
    {{ companyName }}
    <div :style="{ hidden: showDiv }">
      {{ warning }}
    </div>
    <button @click="isTrue = !isTrue">
      Click me!
    </button>
  </div>
</template>

<style>

export default {
  props: ['companyName'],
  name: 'Test',
  data: () => ({
    isTrue: true
  })
  computed: {
    showDiv () {
      return this.isTrue
    },
    warning () {
      return `${this.companyName} is a warning.`
    }
  }
}

</style>

Coming upon a very short snippet of code like this definitely makes it easy to breakdown code to write tests.

You may even just build your tests by analyzing the component from top to bottom.

When isTrue is true does it render myClass in the main div's classes.
Does the companyName prop render correctly?
Does the rendered style show properly from the showDiv computed property?
Does the warning computed property return the companyName prop properly in the string that's defined?

Etc.

The problem with building a component's tests after the code has been written is that it doesn't tell the story of the component.

While the tests above may address the technical specifications of the code, it doesn't address the intentions of the component.

Instead, let's look at how Test Driven Design writes the component, and pay attention to how it helps drive the mental clarity of what is being written, not just how it's being written.

1. Make sure the component renders correctly, and this is known as a sanity test and should be the first test in every test file.

Test:

import TestComponent from 'src/components/TestComponent.vue'
const wrapper = shallowMount(TestComponent)

it('sanity test', () => {
  expect(wrapper.isVueInstance())
    .toBe(true)
})

Corresponding code: Creating a file in the components folder named TestComponent.vue.

2. Insure you're receiving the correct props.

This gets tested before rendering because logically, you would need to receive the prop before it can be used (meaning you wouldn't be able to test anything dependent on it).

Test:

it('receives companyName prop', () => {
  wrapper.setProps({ companyName: 'test' })
  expect(wrapper.props().companyName)
    .toEqual('test')
})

Corresponding Code:

<template>
  <div>
  </div>
</template>

<script>
  props: ['companyName']
</script>

3. Set proper checks for companyName prop, not allowing for non-alphanumeric characters to be used in name.

Test:

it('companyName prop checks for validity', () => {
  const value = wrapper.vm.$options.props.companyName
  expect(value.required)
    .toBeTruthy()
  expect(value.type)
    .toBe(String)
  expect(value.validator && value.validator('test name'))
    .toBeTruthy()
  expect(value.validator && value.validator('test ^'))
    .toBeFalsy()
})

Corresponding Code:

<script>
  props: {
    type: String,
    required: true,
    validator: v => v.match(/[^a-zA-Z0-9 ]/g) > 0
  }
</script>

Note: Notice how each test only creates the very smallest amount of code needed to satisfy it. While there may be a concern of tedium, the long term clarity of development will be evident.

4. The companyName prop renders

Test:

it('companyName prop renders validly', () => {
  wrapper.setProps({ companyName: 'test name' })
  expect(wrapper.find('div').text())
    .toContain('test name')
})

Corresponding Code:

<template>
  <div>
    {{ companyName }}
  </div>
</template>

As you can see over just four tests, there's a much clearer direction to what is being built by starting with tests first.

The next tests would progress in an order similar to this:

warning computed property is returning the correct string
when clicking the button does it change the data value
does the hidden class render when the button is clicked
etc.

Each test dictating what the following test would be, like a digital karmic flow.

Building the component from bottom up allows for a much more succinct connection between all the aspects of the component. Your code will follow a logical progression of steps, rather than a "build as needed" style of development.

The simplicity will allow for longer-term understanding of what's being built, plus all the positive benefits of having 100% coverage on your code (since each line only exists because there is a test for it).

What I Learned My First Week at My First Dev Job

Ricardo Delgado — Mon, 07 Oct 2019 10:22:05 +0000

One day I'm filling out job applications, doing Leetcode until my head is doing somersaults, and then the next day I'm in.

To think that just about a year ago I wrote about my fears of even attempting to look for a developer job, and now I'm looking back at my first week as a professional software engineer.

It's still hard to believe, even though the reality of my day-to-day is so familiar and tangible.

This post is for anyone still on the outside looking in. I'm one of the most guilty of imposter syndrome, and worry everyday if I'm capable of doing this job.

Thankfully, my first week flew by and a lot of my initial concerns are dissipating. Most surprising was what actually seemed to be important to the position - which had much less to do about code than I previously thought.

Even though I only have one week under my belt, here's some things that I'm wishing I'd spent more time focusing on in preparation for the position.

Communication is Key

I'd seen terms like "Agile" or "Scrum" thrown around Twitter or Reddit programming circles, but I never quite paid attention because I didn't make the connection on their importance to a person's ability to code in a team.

Without a doubt, Scrum has been the biggest focus of my first week.

And if you really think about it, it makes so much sense and flies in the face of the independent and isolated nature of the process of learning how to code.

From Wikipedia entry on Scrum (software development):

"Scrum is an agile process framework for managing complex knowledge work, with an initial emphasis on software development, although it has been used in other fields and is slowly starting to be explored for other complex work, research and advanced technologies. It is designed for teams of ten or fewer members, who break their work into goals that can be completed within timeboxed iterations, called sprints, no longer than one month and most commonly two weeks, then track progress and re-plan in 15-minute time-boxed stand-up meetings, called daily scrums."

To properly think of Scrum, I put it in terms of a modern military.

In the past, an Army would be made up of large battalions of specific units - infantry are foot solders, cavalry are mounted units, etc.

But the modern military has gotten more complex and sophisticated, relying more on speed and agility rather than blunt force and numbers.

Instead of large battalions of specifically skilled units, there's been a movement towards "commando groups." These groups are a mix of all different skilled units - it may include a few small infantry Platoons, supported by a couple of mounted units, a few air support units, etc.

By, taking a giant army, and parsing it down to smaller versions of itself, it creates a powerful unit that can more rapidly deal with issues in the field.

Scrum uses a similar mentality for software development. Instead of front-end engineers working independently from back-end engineer, Scrum Teams are a mix of five or so people with complimentary skills trying to solve specific tasks in two to four week cycles called Sprints.

It's like parsing down a large corporation into a bunch of startups.

There's a lot of structure in the system, which includes daily meetings, meetings every other week or a month, one-on-one meetings, etc, and a focus on good documentation of work done and work to be done.

Basically, my biggest misunderstanding of the job was just how much I'd be working with other programmers, business people, an administrators who don't necessarily know what I'm doing.

It became clear right away that the fundamental aspect to my job is knowing how to collaborate, not just write good code.

I realized that I'd made a mistake of not taking opportunities to do Hackathons, and instead focused on the specifics of the language I would be working with.

In hindsight I see that going to meetups could've prepared me better for the position.

Github, Jira, and Coding Standards

These could also fall under the umbrella of collaboration, but I set it off to its own space because this is more about collaborating via your code, rather than the management of collaboration.

I am truly intimidated by Github. While Github Desktop has made it much simpler to manage local and remote repositories, it's still not the easiest thing to wrap my head around.

This will definitely come as things go, but in the meantime here's an awesome site to help you learn about Git Branching, and other features of Git: https://learngitbranching.js.org/

Jira is a service that keeps track of tasks that are determined in Scrum meetings. Truthfully I haven't had to work with it yet, but knowing that it will be vital I wish I would've invested more energy into learning it ahead of time.

Think Trello, but that can easily be tied into code.

And with there being such an obvious emphasize on readability, knowing how to maintain documentation and adhere to coding standards is vital.

Here's a few resources that I've been using daily - I work in VueJS so these are mostly specific to that framework, but there should be equivalent ones for whatever framework or language you work with:

The A11Y Project Checklist (Accessibility)
VueJS Style Guide

Also, in my project we're using Storybooks, which is a tool for developing UI components in isolation. I had never worked with it before the project, but I could see it being a great item to add to your resume:

StorybookJS

Testing and Thoughtful Development

The days of my independent Mad Max-like programming is over.

Another perk of being isolated is the ability to write whatever you want, however you want.

Being part of a team changes all of that, and one of the many decisions you'll have to keep in mind with your code is if it'll be digestible by other people.

As I start diving into the codebase it dawns on me more and more that there is going to be a lot of eyes looking at what I've written. And whatever that is it needs to be understood easily and quickly.

While everyone agrees testing is important, and especially vital in Scrum development, it's such an easy thing to toss aside because it can become a perceived sticky spot.

While I'm okay with testing, it's an area that I wish I had spent even more time focused on. Being expertly fluent in writing tests will make writing code an absolute breeze. Plus it will make it much easier for others to work with what you've done.

Not to dive too deeply into it, but from what I've seen, when Test Driven Design is coupled with Component Driven Design, it makes writing tests a whole lot easier.

Some VueJS testing resources:

Vue Test Utils Documentation
VueJS Testing Handbook
Jest Docs

Also check out my previous post about an awesome book on testing by VueJS Core team member and author of Vue Test Utils Edd Yerburgh: Treasure Map to Vue Testing Gold

Can't wait to see what week 2 brings!

Treasure Map to Vue.js Testing Gold

Ricardo Delgado — Fri, 04 Oct 2019 09:58:47 +0000

The idea of testing is so fulfilling. Planning your way through your code, creating reliable trail markers that will keep your code bug free, it's every compulsively organized coder's dream.

BUT in reality, testing can be closer to wandering around the woods, hoping to stumble into a solution that makes sense to creating better and hopefully faster code.

Personally, I struggle with testing. I'm a natural planner and organizer, and I can see that testing should be such an effective way to get ahead of my future self and let him know that hour twelve of a programming day may not be the most effective time to be pushing out lines of code.

As a Vue developer there has been times where I'm left confounded by testing within the intricacies of Vue's framework. While Vue is notoriously well known for it's well written documentation, I was often left scratching my head and moved on from writing tests out of frustration.

When it was announced last year by Manning Publications that they were publishing a book on Vue testing by Edd Yerburgh, core Vue team member and the author of Vue Test Utils, I immediately purchased the "Manning Early Release Program" (MEAP) version.

Being able to get the perspective of a core Vue member on their product is really helpful, and I'd recommend seeking out the opinions of an original author as one of the best ways to learn about a topic.

While some people may be able to learn strictly through documentation, I feel I may reflect a potential case for some incoming issues in the developer community.

Being a person who has a non-technical background but self-taught my way into being a professional developer, I usually can't wrap my head around technical documentation that easily.

Usually, along with whatever technical documentation I may be going over, I'll have a few tutorials open alongside, flipping back and forth trying to decode the words that at times feel like they were written in Ancient Sumerian.

To me this is the biggest strength of Yerburgh's book. It is extremely well written, and very easy to read and understand.

It's so simple, in fact, that even though it's recommended to code along with the book's examples, I nonetheless find myself reading the book and absorbing the information without necessarily needing to sit in front of a computer at the same time.

The book catches most of the important topics, such as Vuex, Server Side Rendering (SSR), child and parent components, unit tests, end to end tests, etc.

Of course, like with all guides of a particular tool, you'll still find all sorts of things to drive you crazy during implementation, but a quick flip back into Yerbugh's book, or Vue Test Util's documentation usually provides a good roadmap out of whatever issue you may find yourself in.

Links:

Purchase Testing Vue.js Applications from Manning Publications
VueJS Testing Documentation
Edd Yerburgh's Github
Edd Yerburgh's Twitter

All The Ways That I Failed At "Sum 3"

Ricardo Delgado — Sat, 07 Sep 2019 19:00:47 +0000

I have a problem in my life and it's name is Leetcode.

While trying to think of topics to write about on DEV, I kept reading all these posts from talented developers who write so authoritatively about coding and I couldn't help be think, "I definitely cannot do that."

It seems like most coders' solutions and strategies to coding problems come so clearly. In the meantime, I approach solving problems like a monkey slapping at buttons until a banana pops up in my console so I can scream in delight.

But most importantly is to just enjoy the process. Coding is so much fun, so I thought I'd share my coding failures (and sometimes successes).

Sum 3

Sum 3 is a mean-spirited twist on another Leetcode problem called Sum 2. Where in Sum 2 you loop through an array adding two elements until they equal to a target number, Sum 3 uses three.

Oh, and with the caveat that of only using each element once per 3 array pairing.

var sum3 = (array, target) => {
  // magic
}

var nums = [-1, 0, 1, 2, -1, -4]

sum3(nums, 0) // [ [-1, 0, 1], [-1, -1, 2] ]

Attempt 1: Hitting It With A Hammer

My first, and totally useless attempt at a problem like this, is to shove it into a meat grinder, turn the crank, and hope sausage comes out at the end.

In this case, its about running as many for loops as humanly possible praying that there's some kind of solution in it, and then maniacally laughing as my browser catches fire and melts my hard drive into a puddle of plasticy goo.

Attempt 1:

var nums = [-1, 0, 1, 2, -1, -4]

var threeSum = (nums, target = 0) => {
    var solution = []

    for(let a = 0; a < nums.length; a++) {
        for(let b = 0; b < nums.length; b++) {
            for(let c = 0; c < nums.length; c++) {
                let sum = nums[a] + nums[b] + nums[c]
                if (sum === target) solution.push([nums[a], nums[b], nums[c]])
            }
        }
    }
    return solution
}

Alright, straight to the point. No muss. No fuss.

Let's check the output.

[
  [-1,-1,2],[-1,0,1],[-1,1,0],[-1,2,-1],[-1,2,-1],
  [-1,-1,2],[0,-1,1],[0,0,0],[0,1,-1],[0,1,-1],
  [0,-1,1],[1,-1,0],[1,0,-1],[1,0,-1],[1,-1,0],
  [2,-1,-1],[2,-1,-1],[2,2,-4],[2,-1,-1],[2,-1,-1],
  [2,-4,2],[-1,-1,2],[-1,0,1],[-1,1,0],[-1,2,-1],
  [-1,2,-1],[-1,-1,2],[-4,2,2]
]

Oh boy. Yeah, this isn't good.

What went wrong? Right off the back, I can see two major problems:

We use the same element in the array over and over again.
There's duplicates all over the place.

Alright, we're going to implement something like this to address issue 1:

if (a !== b && b !== c && a !== c) {
  let sum = nums[a] + nums[b] + nums[c]
  if (sum === target) solution.push([nums[a], nums[b], nums[c]])   
}

I'm going to wrap the core of the algorithm in a conditional where if any of the variables are in the same position in the array, then the sum array won't push into the solution array.

[
  [-1,0,1],[-1,1,0],[-1,2,-1],[-1,-1,2],[0,-1,1],
  [0,1,-1],[0,1,-1],[0,-1,1],[1,-1,0],[1,0,-1],
  [1,0,-1],[1,-1,0],[2,-1,-1],[2,-1,-1],[-1,-1,2],
  [-1,0,1],[-1,1,0],[-1,2,-1]
]

The duplication issue is a bit trickier.

To stick with the theme of this attempt, let's lob a grenade and see how the pieces fall in the exact right place we need them to.

First, let's sort the sum array, so that we can make sure it's in the same order no matter where it's found in the the nums array.

if (a !== b && b !== c && a !== c) {
  let sum = nums[a] + nums[b] + nums[c]
  let sumArray = [nums[a], nums[b], nums[c]].sort((a, b) => a - b)
  if (sum === target) solution.push(sumArray)   
}

Ok great. And what does that give us?

[
  [-1,0,1],[-1,0,1],[-1,-1,2],[-1,-1,2],[-1,0,1],
  [-1,0,1],[-1,0,1],[-1,0,1],[-1,0,1],[-1,0,1],
  [-1,0,1],[-1,0,1],[-1,-1,2],[-1,-1,2],[-1,-1,2],
  [-1,0,1],[-1,0,1],[-1,-1,2]
]

Unfortunately JavaScript doesn't allow arrays to be directly compared, so something like this [] === [] won't work.

That means writing a helper function to check if the new array is in the solution array.

var isInSolution = (newArray, solutionArray) => {
    let dup = false
    let [a, b, c] = newArray

    solutionArray.forEach(array => {
        let [d, e, f] = array
        if (a === d && b === e && c === f) dup = true
    })

    return dup
}

And then we have to adjust the core to something like this:

if (a !== b && b !== c && a !== c) {
  let sum = nums[a] + nums[b] + nums[c]
  let sumArray = [nums[a], nums[b], nums[c]].sort((a, b) => a - b)
  if (sum === target && !isInSolution(sumArray, solution))
    solution.push(sumArray)
}

Let's fired up this bad boy.

[
  [-1,0,1],[-1,-1,2]
]

Boom! Now that's how you get some Leetcoding done.

Here's the complete code for Attempt 1:

var threeSum = (nums, target = 0) => {
    var solution = []

    for(let a = 0; a < nums.length; a++) {
        for(let b = 0; b < nums.length; b++) {
            for(let c = 0; c < nums.length; c++) {
                if (a !== b && b !== c && a !== c) {
                    let sum = nums[a] + nums[b] + nums[c]
                    let sumArray = [nums[a], nums[b], nums[c]].sort((a, b) => a - b)
                    if (sum === target && !isInSolution(sumArray, solution))
                        solution.push(sumArray)   
                }
            }
        }
    }
    return solution
}

var isInSolution = (newArray, solutionArray) => {
    let dup = false
    let [a, b, c] = newArray

    solutionArray.forEach(array => {
        let [d, e, f] = array
        if (a === d && b === e && c === f) dup = true
    })

    return dup
}

Look at all that beautiful code. There's functions calling functions, there's a couple of instances of one liner sort functions, arrow functions, logic tests... now that's some verbose coding there!

It's the equivalent of driving a Ford F-150 with mudding tires, chrome rims, flames painted across the sides, a big American flag, and Garth Brooks blasting on the radio just to go pick up a half gallon of milk from the Seven Eleven around the corner.

This is gonna be amazing.

TIME LIMIT EXCEEDED

Well... I guess throwing three loops together isn't going to efficiently get the job done.

Attempt 2: If I Only Had A Brain

Since hammers won't work, it's time to use a little finesse and actually think about what this problem is asking.

The core question boils down to this: a + b + c = 0.

And if you really think about it, we only need to know two of the numbers, and make sure the third one exists.

Let's try this whole thing from a different angle:

var threeSum = (nums) => {
    var solution = []

    for(let i = 0; i < nums.length; i++) {
        var newArray = [...nums]
        var firstNum = newArray.splice(i, 1)[0]

        for(let j = 0; j < newArray.length; j++) {
            var secondNum = newArray[j]
            let diff = (firstNum + secondNum) * -1
            if (newArray.indexOf(diff) > -1 && newArray.indexOf(diff) !== j)
                solution.push([firstNum, secondNum, diff])
        }
    }

    return solution
}

The most biggest difference in this attempt is this:

let diff = (firstNum + secondNum) * -1

This should speed things up by letting us cut out one of the for loops in the previous attempt (spoiler alert: it doesn't).

When we run our first test run, we get this result:

[
  [-1,0,1],[-1,1,0],[-1,2,-1],[-1,-1,2],[0,-1,1],
  [0,1,-1],[0,-1,1],[1,-1,0],[1,0,-1],[1,-1,0],
  [2,-1,-1],[-1,-1,2],[-1,0,1],[-1,1,0],[-1,2,-1]
]

This is all starting to look a bit too familiar.

So we go through the same steps as before, checking for duplication, yadda yadda yadda.

TIME LIMIT EXCEEDED

Well, if there's anything I've learned so far, if you need a very slow algorithm written, then I am your man (DM if interested).

Attempt 3: Being Clever

I can't decide if these questions are specifically made so that you have to think your way out of a proverbial Labyrinth of excessive thinking, or if I loved knocking over my Lego towers with my He-Man action figures too much as a kid.

There was definitely something to the a + b + c = 0 way of thinking. There's also something to the idea of avoiding walking through loops too much.

While thinking things over, something popped into my head; the old tried and true merge sort algorithm. The key to merge sort is to keep cutting the data down into more and more manageable pieces, until it's as easy as comparing two values.

So let's try this...

Like the line of thinking to add a + b + c = 0, if an array is ordered, then the two extremes should be able to set the parameters of what could possibly equal to 0.

Take our sample array: [-1, 0, 1, 2, -1, -4]

When organized it becomes: [2, 1, 0, -1, -1, -4] which means that the sum of the two most extreme numbers are: 2 + (-4) = -2.

Walking closer to the center will bring the number closer to zero.

Since the extremes currently add to -2 then moving the last element closer to the center will increase the total, and vice-versa if the sum is positive.

The biggest benefit of this is that we've cut two loops in half.

So let's get started.

var threeSum = nums => {
    const solutionArray = []

    nums = nums.sort((a, b) => b - a)

First things first, we're going to sort the nums array in a descending order (highest to lowest).

Next, we're going to add a couple of fail safes - you know, just in case Leetcode tries and trick us like the sneaky jerks they can be.

var threeSum = nums => {
    const solutionArray = []

    nums = nums.sort((a, b) => b - a)

    if (nums.length < 3) {
        return solutionArray
    }

    if (nums.length < 4) {
        if(nums[0] + nums[1] + nums[2] === 0) return [nums]
        return []
    }

Then we get to the meat of the algorithm.

First we want to iterate through the array.

    nums.forEach((num, i) => {
        let j = i + 1
        let k = nums.length - 1

The magic here is in the two variables we assign:

j, which will be the beginning of our first half-loop
k, which is the end of our second half-loops

"J" is the next element in the array after the the current forEach element, and that "k" is the last element in the array.

We're going to be walking the two ends of our array together, and seeing how many add to our target number of 0, until j and k meet (aka j < k).

while (j < k) {
  let sum = num + nums[j] + nums[k]
  if (sum === 0) {
    solutionArray.push([num, nums[j], nums[k]].sort((a, b) => a - b))
  }

  sum > 0 ? j++ : k--
}

As i iterates through, then the amount of elements j and k have to travel gets shorter on each iteration.

It's simplicity is annoying. And certainly nothing that I would've ever realized on first seeing the problem.

This is the complete code, including a few more adjustments to cover a few other special cases:

var threeSum = nums => {
    const solutionArray = []

    nums = nums.sort((a, b) => b - a)

    if (nums.length < 3) {
        return solutionArray
    }

    if (nums.length < 4) {
        if(nums[0] + nums[1] + nums[2] === 0) return [nums]
        return []
    }

    nums.forEach((num, i) => {
        let j = i + 1
        let k = nums.length - 1

        if (i !== j && num !== nums[i - 1]) {
            while (j < k) {
                let sum = num + nums[j] + nums[k]
                if (sum === 0) {
                    solutionArray.push([num, nums[j], nums[k]].sort((a, b) => a - b))
                    // this step is to skip duplicate numbers in the array
                    while(nums[j] === nums[j + 1]) j++
                    while(nums[k] === nums[k - 1]) k--
                }

                sum > 0 ? j++ : k--
            }
        }
    })
    return solutionArray
}

Click submit and SUCCESS

This is definitely not something that I would have just been able to figure out. But probing the problem from different directions led to certain insights that gave way to a solution.

And if anything, that's what I'd like to get across. I don't know how other programmers do it, but I'm certain wrong way more than I am right.

But it's perfectly ok, because there is always insight from each failure, and you never know what'll lead to a break through to solve the problem.

Onto the next challenge, and onto the next failure!