DEV Community: Jaime González García

Practice Happiness

Jaime González García — Fri, 18 Dec 2020 13:31:01 +0000

This article was originally published at Barbarian Meets Coding

I've been diving a lot into the science of happiness and contentment for the past months as I prepare for our second child. These are some things I've found useful.

1. Meditation

I've been practicing meditation for about 5 years. I don't have a consistent practice, it comes and goes. Even so, meditation has helped me be more patient with my son Teo, my wife Malin and with all the struggles of parenting. Meditation has improved how I treat myself and other humans, cultivating empathy, reflection and improving my self-awareness.

A great boon of meditation is that it creates space between action and reaction, between something happening around me, or to me and me reacting to it. That space is great to make better decisions on how to react to things and to learn to know myself.

Meditation creates space between action and reaction.

As my son throws a tantrum for the 4th time this morning, I can see my anger and irritation rise within me and choose to be patient, because I know that patience and being calm are far better tools to take care of a 3 year old than anger and shouting. Without meditation, I'm far more likely to have my anger bubble out making everything worse.

Likewise meditation makes me aware of feelings and thoughts as I experience the world. As I feel anger, irritation or discomfort about a person or situation at work, I can take a mental note, understand the source of those thoughts and feelings, and prevent them from taking the better of me. Sometimes, I'll find that the mere act of taking a mental note of a feeling "I'm angry" has the power to dispel that very feeling (which is nuts, but it works).

Headspace is a great place to start meditating. It's beautiful and extremely beginner friendly.

Mindfulness, a practical guide to finding peace in a frantric world was the book that got me into meditation in 2015. That's a nice way to get into meditation if you enjoy reading books.

2. Exercise

Super basic, but there's no bad mood that going for a walk can't fix.

Low on morale => exercise
Low on energy => exercise

Can't find energy to exercise? Start with 5 minutes. Anyone can do 5 minutes of anything.

Can't do 5 minutes? Do 1 minute.

is go exercise too vague of an advice? Do this:

If you aren't much for sports or exercise, start by taking brisk walks. Any length works. You'll find yourself taking longer walks than you expected because they're enjoyable. You can be present and enjoy nature, or talk to a friend, or listen to an audiobook, podcast or music.
The next step is doing HIIT or High Intensity Interval Training. This is good for you heart, your metabolism and your brain. Anything that rises your heartbeat is good for you. Don't know where to start? Try Freeletics. They have lots of free workouts that you can do without any equipment. If you haven't done much exercise before, take it easy at first.
Then combine it with strength training by lifting weights and incrementally increasing the weight over time as you get more fit. Strength training increases your strength, develops muscles, increases bone density, flexibility and combats aging. Bigger, leaner, stronger is a great book to get started with strength training.

Adults who engage in leisure time aerobic and muscle strengthening activities show greatly reduced risk of all cause and cause specific mortality.

Recommended physical activity and all cause and cause specific mortality in US adults: prospective cohort study

At the end of the day, if you can find a form of exercise that you enjoy, rises your heartbeat and you can do consistently you're doing great.

3. Journaling

Journaling, the habit of writing down your daily experiences and thoughts, helps me develop more self-awareness, and creates a space and time for me to talk to myself. It's a very peaceful and enjoyable activity.

Journaling is something that had been repeatedly recommended to me but I never got around to doing. Oddly enough, the breakthrough for me was reading Jordan Mechner's own journal on The Making of Prince of Persia. By reading his words, his thoughts about graduating from university and coming of age, his hopes for the future, his struggles when choosing between a career in game development and film making, his writing about trivial daily things... it finally clicked. And so I started journaling and it's been a wonderful experience. You should try it too. And if you're lacking inspiration. Try reading The Making of Prince of Persia.

Tip: Get a real good notebook and a real good pen. It gives you that additional visceral joy in the mere act of putting pen to paper. Baronfig are the ones I use, and they are awesome.

4. Gratitude

I combine gratitude with my journaling. It helps me focus in the things that I appreciate in life and to cultivate appreciation.

No matter how shitty my day has been, there is at least one thing I'm sure to be grateful about. (plot twist: There's more than one. The more you cultivate appreciation the easier it is to find the good in life.)

If you don't know where to start, just write down one thing you are grateful for every night before going to bed. If you already have a habit of journaling, or taking notes while planning your day, a great way to start a habit of gratitude is to take that time to write what you are grateful for. (This technique is known as habit stacking and is a great way to take advantage of existing habits to develop new ones).

The little book of Gratitude is a short and super cute book that you can use to cultivate more gratitude.

5. Investing in your strengths

This was something I learned in The Science of Well-being. A course about increasing your happiness that Laurie (from The Happiness Lab) does at Yale. The tl;dr is that you are happier if you spend time doing things that you enjoy doing, that play to your character strengths 😅 (doh)

In the hecticness of life it is easy to come out of contact with this basic principle. We very easily fall into the daily grind, and start focusing more in what it is expected of us and what others need from us that we get out of touch with our own needs.

Do you know what makes you happy? Can you carve some time for it in your day to day?

If you aren't fully aware of your character strengths or you have never stopped to think about it, there's a free survey that is a great way to get some ideas.

These are mine:

I've learned that if I spend some of my day doing any of those things I feel happier and more content. Even doing one thing, for as short as 30 minutes counts. For example, I'm super curious and love learning new stuff. If I block 30 minutes or less to learn something new, I feel a profound sense of contentment that accompanies me for the rest of the day.

6. Sleep

Sleep should probably be at the top of this list. It is the one thing whose lack of makes the most difference in your energy and mood levels. Yet it is so easy to trade hours of sleep for anything else. You may trade hours for getting ahead in your career, or to play video games and watch series. There's also something called revenge bedtime procrastination, a phenomenon in which people who don’t feel in control over their daytime life refuse to go to sleep so that they can regain a sense of freedom and control during late night hours. This is me as a parent. Night time is pretty much the only time of the day where I feel I can get some me-time. And I bet that there are a lot of people out there in the same situation as me.

The problem is that continuously trading sleep at night for doing other things is an evil circle where you progressively become more tired, more irritable, until you get to a point where you are so exhausted that you can't enjoy life. You aren't even present. You are a husk. And that's no way to live. Therefore get some sleep.

It is very easy to go around tired or even exhausted and not realize you aren't sleeping enough. Devices like smart watches or a fitbit are great tools to help you realize how little you sleep and/or exercise. They put a number on it, they bring it to your attention and they nudge you ever so slightly towards doing something about it.

A great book to learn more about the importance of sleep is Why we Sleep: Unlocking the Power of sleep and dreams.

Where can I Learn More?

So that's it! Hope you can use any of these tricks to have a more fulfilling and content life!

Here's a couple of places that you can use to continue your journey:

The Happiness Lab. A really great podcast about the science of happiness that you can start listening to in your next brisk walk. Do it. Right now! :)
The Science of Well-being is a free course that teaches you a lots of the theory behind the science of well-being (how bad we are at predicting the things that will make us happy, what things do really make us happy, etc...) and a bunch of practices like the ones detailed above to help you live a happier life.

Have a wonderful day!

This article started as a twitter thread, if you find it useful and want more, find me on twitter.

Learn Vim. A new extension to help you learn Vim in VSCode

Jaime González García — Sat, 05 Sep 2020 13:45:51 +0000

As I was writing JavaScriptmancy, Boost Your Coding Fu with VSCode and Vim and Wizards Use Vim I've always envisioned a more interactive way to teach through practice, play and games. Life happens and I sort of got as far as writing but never much further. I left those cool ideas of interactive learning, roguelikes, RPG-esque JavaScript, Vim platformers archived somewhere at the bottom of bottomless TODO lists, half-remembered thoughts and someday/maybes...

But yesterday as I was preparing breakfast I wondered... Hmm could I write a VSCode extension to help people learn Vim in VSCode? Could I do it in just one day? And it turns out I can... Sort of

Behold!

Learn Vim, a VSCode extension that helps you learn Vim right within VSCode, keeps your progress and provides room for thoughtful reading and deliberate practice (and soon games?).

Open Visual Studio, install Learn Vim like any other extension and then:

Open the command palette
Type Learn Vim
Victory

Hope you find it useful! And don't hesitate to give me a shout, ask me a question or let me know what you think. Have fun! And may the Elder Gods of Vim always be with you.

TypeScript Types Deep Dive - The Talk

Jaime González García — Sun, 07 Jun 2020 15:38:32 +0000

Learn more about the wondrous and mysterious world of the TypeScript type system, this time condensed into an exciting, fun and insightful talk by yours truly. Enjoy!

5 Minutes Vim: Copying, Cutting, Pasting, Registers, and How to Tame Them

Jaime González García — Sat, 01 Feb 2020 22:02:54 +0000

This article was originally posted in barbarianmeetscoding.com. Sorry for the long 5 minutes-ish. 😊

In this 5 minutes of Vim goodness we'll learn how to effectively copy, cut and paste things in Vim by taking advantage of Vim registers and a cool plugin. Here we go!

Copy and paste. Doesn't sound like much excitement, does it? You are probably accustomed to use your mouse to perform some text selection, copy or cut it and then paste it somewhere else. And that is it. Not so much to be excited about.

Vim spices up copying, cutting and pasting in a couple of ways:

It gives you new shiny operators and commands you can use in combination with all the motions you've learn thus far
It provides a handful of registers where you can save stuff for later pasting which can enable interesting workflows

The two main commands for copying and pasting are y and p. Why y and not c for **copy, you may wonder? Well, if you are familiar with Vim you may know that c is already taken, it is the change command. And thus, the vi engineers had to come up with a suitable way to describe copying and settled on the colourful name of yank (because engineers are far more playful than one would think at first sight). So in Vim you don't copy stuff, you yank it (great naming... So visceral). p stands for put and therefore in Vim you yank some text from somwhere and put it some place else. If you're accustomed to think of p in terms of pasting then feel free to use whichever mnemonic makes you happy.

From now on, instead of copy I'll say yank so you get accustomed to it and can easily connect it in your brain and muscle memory to the letter y. Yank! Yank! Yank!

y is an operator. You can combine it with any of the motions and text-objects we've learned to yank stuff to your heart's content:

yl yanks a letter,
yaw yanks a word,
yas yanks a sentence
yi( yanks everything within ( and so on...

If you double y as in yy you get a linewise operator like dd and cc and yank a whole line. The Y command also yanks a complete line.

In order to paste things you use the p command and its variants:

p pastes something after the cursor
P pastes something before the cursor
gp same as p but puts the cursor after the pasted selection
gP same as P and puts the cursor after the pasted selection

Pasting in Vim is kind of special and the behavior of p and P depend on whether you've yanked characters or lines. If you've yanked characters then pasting will put those characters after or before the cursor (no surprises there). If you've yanked lines, however, pasting will put those lines after or before the line where the cursor is resting on. This behavior may sound weird at first but it makes a lot of sense in practice.

Imagine that you are contemplating this powerful extract from an ancient text:

Hither came Conan, the Cimmerian, black-haired, sullen-eyed, sword in hand, a thief, a reaver, a slayer, with gigantic melancholies and gigantic mirth, to tread the jeweled thrones of the Earth under his sandaled feet.

And you want to add more intensity to this passage you may decide to yank the the particle and sprinkle it here and there:

v
Hither came Conan, the Cimmerian, black-haired, sullen-eyed, ...

Start by jumping to the the particle with f,w:

       v                  v
f,w    Hither came Conan, the Cimmerian, black-haired, ...

Then yank the word with yaw, jump to the next location were to put the with ;w and paste with P:

                         v                 v
;w    Hither came Conan, the Cimmerian, the black-haired, ...

The jump to the next location again with ;w and type . to repeat the last change:

Hither came Conan, the Cimmerian, the black-haired, the sullen-eyed, ...

Want to duplicate a line instead? It is as easy as typing yyp. Imagine that you have an array literal in JavaScript and it's filled with magical items of wonder:

const chest = [
  {name: 'sword', weight: 2.1, state: 'well kept'},
  {name: 'rusty dagger', weight: 0.4, state: 'worn out'},
];

And now you want to add some more items to this chest. You can use any of the existing items as a template and type yyp to duplicate it:

const chest = [
  {name: 'sword', weight: 2.1, state: 'well kept'},
  {name: 'rusty dagger', weight: 0.4, state: 'worn out'},
  {name: 'rusty dagger', weight: 0.4, state: 'worn out'},
];

Then type ci' to change its name to something else:

const chest = [
  {name: 'sword', weight: 2.1, state: 'well kept'},
  {name: 'rusty dagger', weight: 0.4, state: 'worn out'},
  {name: 'scepter of fire', weight: 0.4, state: 'worn out'},
];

Want to n-plicate a line? (Yes, I'm pretty sure that's a real word) It is as simple as typing yy{count}p. Yes! Counts also work with yank and pasting because they're just commands! Let's retry the example above but this time type yy5p:

const chest = [
  {name: 'sword', weight: 2.1, state: 'well kept'},
  {name: 'rusty dagger', weight: 0.4, state: 'worn out'},
  {name: 'rusty dagger', weight: 0.4, state: 'worn out'},
  {name: 'rusty dagger', weight: 0.4, state: 'worn out'},
  {name: 'rusty dagger', weight: 0.4, state: 'worn out'},
  {name: 'rusty dagger', weight: 0.4, state: 'worn out'},
  {name: 'rusty dagger', weight: 0.4, state: 'worn out'},
];

Wow! Impressive, isn't it?

Ok. So if y, the yank command, copies stuff... How do you cut things in Vim? Aha! Here comes a surprise!

Cutting Stuff In Vim

You may be familiar with the d (delete) and c (change) commands in Vim? As their name indicates they let you delete and change text in Vim. A lesser know fact is that, in addition to deleting and changing text, they also cut it.

Imagine that in addition to the chest we had earlier we now have a brave adventurer ready to explore the world and confront its perils. Sadly, our adventurer has little and lacks many of the tools of the adventuring trade she'll need to survive:

const chest = [
  {name: 'sword', weight: 2.1, state: 'well kept'},
  {name: 'rusty dagger', weight: 0.4, state: 'worn out'},
  {name: 'rusty dagger', weight: 0.4, state: 'worn out'},
];

const sonja = {
  name: 'Sonja',
  inventory: [
  ],
};

Let's give her some help and move the well kept sword from the chest into her inventory:

v
const chest = [
  {name: 'sword', weight: 2.1, state: 'well kept'},
  {name: 'rusty dagger', weight: 0.4, state: 'worn out'},
  {name: 'rusty dagger', weight: 0.4, state: 'worn out'},
];

We type 2jdd to jump two lines down and delete (and cut) our sword:

const chest = [
  v
  {name: 'rusty dagger', weight: 0.4, state: 'worn out'},
  {name: 'rusty dagger', weight: 0.4, state: 'worn out'},
];

Then /in<ENTER> to move our cursor on to of the in in inventory:

const sonja = {
  name: 'Sonja',
  v
  inventory: [
  ],
};

And now we type p and we're ready for adventure:

const sonja = {
  name: 'Sonja',
  inventory: [
  v
  {name: 'sword', weight: 2.1, state: 'well kept'},
  ],
};

Now you can save the file and if you have an autoformatter setup it'll fix your indentation or you can type == to manually format that line.

What more can you do with cutting and pasting in Vim? Have you ever made a typo and need to swap two characters? Type dlp (or xp). Want to swap couple of lines? Type ddp. Want to swap a couple of paragraphs? Type dapp.

Excellent! So now you've boosted your knowledge with yanking, cutting and pasting in Vim. But there's yet one crucial element left that we haven't even touched on yet: The mighty registers.

A wonderful way to illustrate the impact of registers is swapping two values within Vim. I do some variant of this task incredibly often.

Imagine that you have a couple of CSS variables that represent a couple of colors in a color theme of a beautiful website you've just designed:

:root {
  --red: #0F0;
  --green: #F00;
}

You quickly notice the colors are wrong. You've mixed them. The red is the green and the green is the red. Oh no! What to do!?

So you try swapping them using what we've just learned. You type /#<Enter> and put the cursor on top of the hexadecimal value:

  --red: #0F0;
         ^

You cut it with daW:

  --red:
       ^

Type n to move to the next hex value, delete it with daW and try to paste the red with p, but...

:root {
  --red:
  --green: #F00;
}

What!? That is so not what I expected to happen. What did I do wrong?

You may have noticed the issue with this swap as you were following the example but if you haven't I will tell you: The problem is that delete also cuts. When we deleted the hexadecimal value for the green color in the last step we literally overwrote the red hexadecimal value. That's why when we typed p at the end the pasted characters where #F00 and not #0F0 as we initially expected.

But what did we overwrite exactly? Most systems have the concept of a clipboard, which is a place where you put the stuff that you copy and cut. Well Vim doesn't have a clipboard, Vim has registers.

Vim Registers

Vim registers are the equivalent of a clipboard, but since you have lots of them, they're that much powerful.

When we use commands like y, d, c and p we're interacting with Vim's unnamed register. You aren't limited to that one though, you have 26 named registers, one for each letter of the alphabet, that you are free to use as you see fit.

The way that you explicitly access a given register is by prefixing a command with "[a-z]. So:

"ayy yanks a line into the a register
"add cuts a line into the a register
"ap pastes from the a register

Using the same pattern we can access the mysterious unnamed register which does have a name after all. Its name is " and you could replace y for ""y if you had a fancy for writing more than you need to. But we won't do that.

Using the lowercase name of a named register overwrites its contents, whereas if we use the capitalized version of that name we will append whatever we yank or cut into the register (this can be really useful when we want to collect text into a register for later pasting).

Using named registers offers one way to solve the problem that ailed us earlier when we were swapping colors. Instead of using the unnamed register alone we could've used it in combination with the a register:

/#<Enter> to move the cursor to the first hex value
daW to cut the green color value in the unnamed register
n to move to the second hex value
"adaW to cut it into the a named register
p pastes the first hex value in the write place
k to go up
"ap which now pastes from the a register and we're done

Excellent! If you ever lose track about which register you have put stuff in, you can rely on the :registers (or :reg) command. :registers will print the value of all registers into a buffer. If you're only interested in the contents of a particular register you can also specify it as an argument. For instance, typing :reg a after the previous example would result in the following:

--- Registers ---
"a    #F00;

Another useful way to interact with named registers is by taking advantage of the fact that capitalized named registers append to the register instead of replacing its contents. For instance, we could build an outline of a markdown document by continously appending headers to the a register:

/^#.*<ENTER> to jump to the next header
"ayy to copy the header into the a register
n to jump to the next header
"Ayy to append the header to the contents of the a register
then n and "Ayy until you've gathered all the headers you want
"ap to paste the outline of the mardown document

In addition to the named and unnamed registers there are more registers that will be useful from time to time: The yank register (0), the delete registers (1-9) and the black hole register (_).

The yank register 0 holds the last bit of text you yanked. That is, it only stores text you have yanked with the y command and lives completely unperturbed by whatever happens with cutting operations like d or c. This can be really useful if you want to rename a variable or other pieces of text. Using the yank register offers yet another alternative way to swap values.

The delete registers 1-9 are nine registers that contain the last 9 pieces of text you cut or deleted. They work as a queue where every time you cut something it gets stuck in the queue at position 1, whatever was in 1 is pushed to 2 and so on. The delete register can be really useful when you happen to delete something in the past and you want to bring it back (in fact, it just saved me from losing a beautifully written parapraph). Just like the named and yank registers, you can take advantage of delete registers as an alternative way to swap values.

The black hole register has a fitting name because it truly allows you to delete text into oblivion. A nice way to avoid overwriting the unnamed register is to prefix the delete operator with the black hole register: For instance, type "_daw to blast a word into oblivion for ever and ever.

For a list of all registers available in Vim and how you can use them take a look at :h registers.

Copy and Pasting In and Outside Of Vim

Everything we've discussed thus far only applies to the world of Vim. All the commands and registers that we've seen allow you to yank, cut and paste text only within the confines of Vim. What happens when you want to copy to or paste from outside of Vim? For instance, when you find a wonderful piece of code on StackOverflow and want to try it in a program?

There's two registers that work as an interface between Vim and the outside world: The + and the * registers.

You can use the + register to interact with the system clipboard in Windows, Mac and Linux
You can use the * register to interact with the primary clipboard in Linux, and also the system clipboard in Windows and Mac (since these two only have the single clipboard)

One thing that I find super convenient and that I'd advise you to do is to have your system clipboard use the unnamed register. That way you can seamlessly copy and paste between Vim and the rest of your computer, taking advantage of the fastest commands d, c, y and p, and avoiding the need to specify the + and * registers.

If you are using Neovim you can enable this behavior in your vimrc like so:

set clipboard+=unnamedplus " use system clipboard

Likewise in traditional Vim:

set clipboard=unnamed " use system clipboard

Take a look at :h clipboard for more information.

Pasting in Insert mode

All of this article has focused on how you can copy and paste things from within Normal mode. Sometimes however, it can be helpful to paste things within Insert mode. Earlier you learned how you can paste using the p command but that won't do in Insert mode (it would just insert the letter p). What to do? Well, in some instances (f.i. gvim and mvim) you may be able to use your system copy/paste key bindings, but you can always rely on <C-R>{register} to paste text from any given register:

<C-R>a pastes the contents of the a register
<C-R>" pastes the contents of the unnamed register
<C-R>0 pastes the contents of the yank register.

And yes, you've guessed it right, the R stands for Register. Use that as a mnemnonic and you'll never forget how to paste things in Insert mode.

A Really Cool Plugin To Simplify Working With Registers in Vim

Before we part here is a really cool plugin that helps you work with register in Vim: vim-peekaboo. This plugin extends " and @ in normal mode and <CTRL-R> in insert mode so you can see the contents of the registers as you are about to perform a copying, cutting or pasting operation:

Cool right?

And that's all for today! Take care and have a wonderful day!

Learn Svelte: Connecting the Pomodoro Timer and Tasks with Props and Stores

Jaime González García — Tue, 28 Jan 2020 22:15:57 +0000

This article was originally published on Barbarian Meets Coding. You can often find me there and on Twitter.

Svelte is a modern web framework that takes a novel approach to building web applications by moving the bulk of its work from runtime to compile-time. Being a compiler-first framework allows Svelte to do some very interesting stuff that is unavailable to other frameworks like disappearing from your application at runtime, or allowing for a component centered development with HTML, JavaScript and CSS coexisting within the same Svelte file in a very web standards friendly fashion.

In this series we'll follow along as I use Svelte for the first time to build an app. I'll use my go-to project¹ to learn new frameworks: A Pomodoro Technique app, which is a little bit more involved than a TODO list in that it has at least a couple of components (a timer and a list of tasks) that need to interact with each other.

In this part 5 of the series we finally put everything together and integrate the pomodoro with our collection of tasks. Yihoo! Let's get started!

Haven't read the other articles in this series? Then you may want to take a look at this list of resources for getting started with Svelte, and the first, second and third parts of building the Pomodoro Technique app.

Pomodoro Meets Tasks

So we have our pomodoro timer on one side, we have our list of tasks on the other. They are both living their lives independently as completely self-contained components. One can count down pomodoros, the other can manage a collection of tasks. Our next step to be able to support the Pomodoro technique is to get them to talk to each other so that a user can:

Select the tasks to focus on
Start a pomodoro and focus fiercely on that task for 25 minutes
Complete a pomodoro and take a rest
Or cancel a pomodoro and type down the reason Why

But How can they talk to each other? Either by sharing some state that can be passed between components through props, or by using a Svelte store.

Let's implement both solutions and discuss the pros and cons of each of them.

Sharing State Through Props

What are Svelte props?

props (short for properties) are the mechanism that Svelte uses to send data into a component. In essence, props define the interface of a component. How it interacts with the outside world.
.

So far in the series we've barely touched on props because both the Pomodoro Timer and the list of tasks have been self contained up to this point. Now however we need for both components to communicate. Specifically:

We need the TaskList component to be able to communicate with the outside world that a task has been selected
We need to tell the PomodoroTimer which task has been selected

Selecting a Task

So we start by updating our TaskList component so that a user can select a task. We define a selectedTask variable that will save that information:

<script>
  let activeTask;
  // more code...
</script>

And we update the template to select a task using a new button:

{#if tasks.length === 0}
  <p>You haven't added any tasks yet. You can do it! Add new tasks and start kicking some butt!</p>
{:else}
  <ul>
    {#each tasks as task}
      <li>
        <!-- NEW STUFF -->
        <button on:click={() => selectTask(task)}>&gt;</button>
        <!--- END NEW STUFF -->
        <input class="description" type="text" bind:value={task.description} bind:this={lastInput}>
        <input class="pomodoros" type="number" bind:value={task.expectedPomodoros}>
        <button on:click={() => removeTask(task)}>X</button>
      </li>
    {/each}
  </ul>
{/if}
<button class="primary" on:click={addTask}>Add a new task</button>
{#if tasks.length != 0}
  <p>
    Today you'll complete {allExpectedPomodoros} pomodoros.
  </p>
{/if}

Now whenever the user clicks on the > button we will call the selectTask function that sets the activeTask to the selected task:

function selectTask(task) {
  activeTask = task;
}

And whenever a user removes a task we will check whether it is the activeTask and in that case we will clean it up:

function removeTask(task){
  tasks = tasks.remove(task);
  if (activeTask === task) {
    selectTask(undefined);
  }
}

Excellent! Now we need a way to tell the user that a given task is selected. We can do that by highlighting the active task using CSS. One way to achieve this is to set the class attribute of the li element to .active like so:

{#each tasks as task}
  <li class={activeTask === task ? 'active': ''}>
     <!-- task --->
  </li>
{/each}

But Svelte has a shorthand syntax that makes it more convenient to add or remove classes based on your component's state:

{#each tasks as task}
  <li class:active={activeTask === task}>
     <!-- task --->
  </li>
{/each}

Now we need to add some styles linked to that .active class inside the component:

  .active input,
  .active button {
    border-color: var(--accent);
    background-color: var(--accent);
    color: white;
    transition: background-color .2s, color .2s, border-color .2s;
  }

And finally we have a way to select a task to work on within the TaskList.svelte component:

Notifying The Outside World A Task Was Selected

Excellent! The next step is to let the world outside of this component known that a task has been selected. Svelte lets us do that through event dispatching. Inside our component we can define our own domain specific events and dispatch them to our heart's content.

A suitable event for our use case could be called selectedTask:

import { createEventDispatcher } from 'svelte';
const dispatch = createEventDispatcher();

function selectTask(task) {
  activeTask = task;
  // dispatch(eventName, eventData);
  dispatch('taskSelected', {
    task: activeTask,
  });
}

So now, whenever the user selects a task, we'll call the selectTask function that will:

Update the active task
Notify the outside world that a task has been selected by dispatching a taskSelected event with the currently active task

In our app component we can subscribe to that new event just like we would subscribe to any other standard DOM event:

<main>
  <h1>{title}</h1>
  <PomodoroTimer />
  <TaskList on:taskSelected={updateActiveTask}/>
</main>

The App.svelte component will now store its own version of the activeTask:

<script>
  let title = "il Pomodoro";
  import TaskList from './TaskList.svelte';
  import PomodoroTimer from './PomodoroTimer.svelte';

  let activeTask;
  function updateActiveTask(event){
    activeTask = event.detail.task;
  }
</script>

That we can then send to our friend the Pomodoro Timer:

<main>
  <h1>{title}</h1>
  <PomodoroTimer {activeTask} />
  <TaskList on:taskSelected={updateActiveTask}/>
</main>

Pomodoro Timer Meets Active Task

But in order to do so we to define a new prop inside our PomodoroTimer component:

<script>
export let activeTask;
</script>

Since it doesn't make sense for a user to be able to interact with the pomodoro timer unless there's a task that is active, we can start by disabling the pomdoro timer in such a case:

<section>
  <time>
    {formatTime(pomodoroTime)}
  </time>
  <footer>
    <button 
      class="primary" on:click={startPomodoro} 
      disabled={currentState !== State.idle || !activeTask}>start</button>
    <button on:click={cancelPomodoro} 
      disabled={currentState !== State.inProgress || !activeTask}>cancel</button>
  </footer>
</section>

Cool!

Finally, we can increment the pomodoros spent in a task when we complete a pomodoro. We update the completePomodoro function in PomodoroTimer.svelte to include that functionality:

function completePomodoro(){
  // We add one more pomodoro to the active task
  activeTask.actualPomodoros++; 
  completedPomodoros++;
  if (completedPomodoros === 4) {
    rest(LONG_BREAK_S);
    completedPomodoros = 0;
  } else {
    rest(SHORT_BREAK_S);
  }
}

But what happens if a user removes a task while the a pomodoro is running? A great user experience would prevent the user from being able to do that, either by disabling the remove button when a pomodoro is active or by showing a prompt to the user. For now however, we're just gonna leave that as a bonus exercise or future improvement.

We're not displaying the pomodoros we've spent on a task quite yet, so let's not forget to do that. Back in the TaskList.svelte component we update our component markup to show that information:

  <ul>
    {#each tasks as task}
      <li class:active={activeTask === task}>
        <button on:click={() => selectTask(task)}>&gt;</button>
        <input class="description" type="text" bind:value={task.description} bind:this={lastInput}>
        <input class="pomodoros" type="number" bind:value={task.expectedPomodoros}>
        <!-- NEW input -->
        <input class="pomodoros small" bind:value={task.actualPomodoros} disabled >
        <!-- END NEW -->
        <button on:click={() => removeTask(task)}>X</button>
      </li>
    {/each}
  </ul>

And our styles:

.pomodoros.small { 
  max-width: 40px;
  text-align: center;
}
.active input[disabled] {
  opacity: 0.6;
}

And Tada! We finally have a working Pomodoro Technique app:

An Alternative Approach With Slightly Less Coupling

While I was implementing the tasks and timer integration above I was somewhat unhappy with the idea that both the TaskList component and PomodoroTimer were modifying the same object activeTask. The more places within an application that have access and can modify the same data, the harder it becomes to reason about the state of the application and how it changes over time. This, in turn, means that a bug related to that piece of data could be introduced in many different places within an application. And it also was somewhat boilerplatey to have to pull the activeTask upwards to the parent App component to them pipe it down again to PomodoroTimer.

Here goes an alternative approach that sacrifies the independence of PomodoroTimer from TaskList but reduces the amount of code needed and reduces the coupling of data:

Include PomodoroTimer component inside the TaskList component
We have all the data we need so we can enable/disable the PomodoroTimer as needed
Instead of passing the activeTask into the PomodoroTimer, the timer communicates when a task has been complete through an event and the TaskList updates the activeTask.

<PomodoroTimer disable={activeTask} on:completedPomodoro={() => activeTask.actualPomodoros++}/>
<ul>
  <!-- list of tasks remains unchanged -->
</ul>

Sharing State Using a Store

Another way in which we can share state in Svelte are stores. Where sharing state through props is extremely coupled to the DOM tree and the structure of your application, sharing state through stores is completely DOM independent. Using Svelte stores you can share data between any component of your application, no matter where they are, with just a single import (that of the store).

What is a Store?

A store is an object that helps you share data between the components of a Svelte application. Stores are independent from the DOM tree and the structure of your application, so they are really useful when you need to share state between components that are far away from each other, or that should be decoupled. Stores are also reactive: whenever their value changes they notify their consumers of this change so that they can react to it. A component becomes a consumer of a store by subscribing to it via the subscribe method or $ (you'll see some examples below).

For more information about stores take a look at Svelte's Store documentation

The Active Task Store

Let's create a new store that will allow us to share the active task between the TaskList and the PomodoroTimer components. The TaskList component still has the complete list of tasks and will keep the responsibility of selecting the active task based on user input. This means that we can reuse much of the previous example. What's different? For one there won't be a taskSelected event and even more interestingly the activeTask will be a Svelte store.

Let' start by creating the store in its own file tasksStore.js:

import { writable } from 'svelte/store';

export const activeTask = writable();
// The initial value of this store is undefined.
// You can provide an initial value by passing it as an argument
// to the writable function. For example:
// 
// const count = writable(0);

The activeTask is a writable store which in layman terms means that it is a store that components can use to write information that can then be shared between components. Aside from being a way to share information, stores are also reactive which means that they notify components when data has changed. Let's see how we can take advantage of these capabilities to communicate the TaskList and PomodoroTimer components.

Writable Stores

Writable stores are stores that components can write to. In addition to subscribe they have the set and update methods that allow components to set a value in the store, or update the current value by applying a function.

The next step is to have TaskList import the activeTask store replacing the former let activeTask variable within the component.

// import activeTask store
import {activeTask} from './tasksStore.js';

// remove old variable
// let activeTask

Since activeTask is now a store we can't just set its value as we did before. So instead of:

  function selectTask(task) {
    activeTask = task;
  }

We need to use the set method of the store:

  function selectTask(task) {
    activeTask.set(task);
  }

Likewise activeTask no longer refers to the activeTask itself but to the store that stores its value. In order to retrieve the current value of a task you use the get method. So intead of:

function removeTask(task){
  if (activeTask === task){
    selectTask(undefined);
  }
  tasks = tasks.remove(task);
}

We write:

// import get from svelte/store
import { get } from 'svelte/store';

// use it to retrieve the current value
// of the activeTask store and therefore
// the current task that is active
function removeTask(task){
  if (get(activeTask) === task){
    selectTask(undefined);
  }
  tasks = tasks.remove(task);
}

Using set and get can be quite wordy, so Svelte comes with an alternative syntax that lets you directly change and retrieve the value of a store by prepending it with a $ sign when you're inside a component.

Using that convenient syntax we can update the previous example with this one:

// use it to retrieve the current value
// of the activeTask store and therefore
// the current task that is active.
function removeTask(task){
  if ($activeTask === task){
    selectTask(undefined);
  }
  tasks = tasks.remove(task);
}

// Use it to update the value of the activeTask.
function selectTask(task) {
  $activeTask = task;
}

Which looks very similar to the original implementation. Isn't that cool? We're using as store to manage our state but it pretty much looks just like setting and reading a normal JavaScript variable.

get and set or $store? Which one to use?

If you're inside a component then there's no reason to use get and set. Prefer using the shorter and less boilerplatey $store syntax.

Outside of a component, when retrieving or updating the value of a store you'll need to use the get and set methods. Why? Because the $store syntax automatically subscribes and unsubscribes from a store by taking advantage of a component lifecycle events. You mount a component, you subscribe, you destroy a component, you unsubscribe. In the context of a vanilla JavaScript module however there's no concept of a lifecycle. Therefore the compiler wouldn't be able to know when it'd be a suitable time to unsubscribe from a store leading to memory leaks.

Whe can also use $activeTask within our component's template to check whether a given li belongs to the active task and highlight it:

<ul>
  {#each tasks as task}
    <!-- update $activeTask here -->
    <li class:active={$activeTask === task}>
    <!-- END update -->
      <button on:click={() => selectTask(task)}>&gt;</button>
      <input class="description" type="text" bind:value={task.description} bind:this={lastInput}>
      <input class="pomodoros" type="number" bind:value={task.expectedPomodoros}>
      <input class="pomodoros small" bind:value={task.actualPomodoros} disabled >
      <button on:click={() => removeTask(task)}>X</button>
    </li>
  {/each}
</ul>

So now we can set the value of the activeTask whenever a user selects it within the TaskList component. The next step is to remove all references of activeTask from App.svelte and update our PomodoroTimer component to make use of the new store.

We update the completePomodoro method using the same $activeTask syntax we learned earlier:

import { activeTask } from './tasksStore.js';

function completePomodoro(){
  // Get the current active task and add a pomodoro
  $activeTask.actualPomodoros++; 
  completedPomodoros++;
  if (completedPomodoros === 4) {
    rest(LONG_BREAK_S);
    completedPomodoros = 0;
  } else {
    rest(SHORT_BREAK_S);
  }
}

And the template to enable and disable the timer whenever a task is active or not:

<section>
  <time>
    {formatTime(pomodoroTime)}
  </time>
  <footer>
    <button class="primary" 
      on:click={startPomodoro} 
      disabled={currentState !== State.idle || !$activeTask}>start</button>
    <button 
      on:click={cancelPomodoro} 
      disabled={currentState !== State.inProgress || !$activeTask}>cancel</button>
  </footer>
</section>

If you take a look at the page right now (remember you can run the local dev environment with npm run dev) you'll be happy to see that everything is still working. Wihoo!

What Type Of Stores Are Available in Svelte?

In addition to writable stores Svelte has readable and derived stores. Readable stores are stores whose value can't be updated by a component. Derived stores are stores whose value is derived from other stores. Whenever these stores change, the value in the derived store is updated.

If you want to learn more about Svelte stores take a look at the Svelte documentation.

Props vs Stores

Now that we've completed two different versions of our Pomodoro Technique app using both props and stores let's take a moment to reflect and compare both approaches:

Props

Svelte components define their interface with the outside world using props. Using props allows parent components to communicate with children and vice versa. You can send data downwards from parent to child using props and upwards from children to parents using events.

Props Pros

Sending data back and forth props is quite simple.
Understanding the contract used to interact with a component is quite straightforward as it is defined by its props.
Following the flow of data using props is as easy as seeing how data flows inside the component via props and comes out of the component via events.

Props Cons

This type of state management creates a coupling between components and makes your application a little bit rigid: If a new requirement forces you to move a component to a different location in the page you may need to update the way you provide information to that component.

When to Use Props

Because of all of the above it seems like props are a good solution for low level components that are completely isolated (a date picker, a type ahead, etc), or components that are near each other (in the DOM) and part of a closely related unit.

Stores

Svelte stores are an extremely convenient way to share data between components in a loosely coupled way. Since you only need to import them to start accessing and changing data, they can be used to communicate any component anywhere within your application DOM tree.

Store Pros

They are more flexible than props and allow you to communicate components that are far away in your application DOM tree. They don't force you to pass the information one step at a time through the DOM tree, one import and you can access and change your data.
They establish a loose coupling between components. Using a store to communicate between components leads to flexible web applications where a requirement to change the layout of your application requires no changes in your data handling logic. That is, if you have two components that communicate using a store and all of the sudden you get the requirement to move one of them far across the page, there's no problem, you can just move it away and there's no additional code changes required. Compare that to a solution where both components communicate through props and you would be forced to change your state management strategy.

Store Cons

The data interactions between components aren't as straightforward as when using props. Since the interactions no longer happen between components, but between a component and a store, it may be harder to reason about how actions on a component affect other components.

When to Use Stores

Use stores when you need to communicate between components that are far away in your application DOM tree
Use stores when you want to keep your options open and your components loosely coupled (e.g. if you expect that you may need to)

Are There Any Other Way to Share State in Svelte?

In addition to props and stores, Svelte offers a middle ground solution: The Context API. The Context API allows you to communicate between components without passing lots of props or events deep inside the DOM tree. It consists on just two methods setContext(key, value) and getContext(key). A parent component can use the setContext(key, value) method to save some data, that can then be retrieved by any child of that component using getContext(key).

You can find an example of how to use The Context API within Svelte Tutorials.

Looking for the source code for the pomodoro app?

Look no more! You can find it on GitHub ready to be cloned and enjoyed, or on the Svelte REPL where you can tinker with it right away.

More Reflections About Svelte

Working with Svelte continues to be very pleasant. In addition to my previous reflections (1, 2, 3) I've found that:

It is very easy to communicate components using props and events. The syntax is very straightfoward, lightweight and easy to remember.
I really like that Svelte comes with a state management solution built-in and how easy it is to use stores change data or read it in a reactive fashion.

Concluding

In this article we finally connected everything together and have a working pomodoro timer. Yihoo! We learned how you can use props and events to communicate between components that are near each other in the DOM tree, and how you can use stores to share data between components in a more loosely coupled fashion.

In upcoming parts of the series will dive into testing, async, animations and more. See you! Have a wonderful day!

Check this super old pomodoro technique app I wrote using Knockout.js back in the day I started doing web development. ↩

Peak: Secrets From the New Science Of Expertise Or How To Get Better At Anything

Jaime González García — Thu, 16 Jan 2020 22:09:44 +0000

This is an adapted twitter thread that I thought useful enough to improve slightly and crosspost to Dev.to. Hope you find it helpful! 😁👍

// Detect dark theme var iframe = document.getElementById('tweet-1217720266157121536-310'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1217720266157121536&theme=dark" }

We recently started a book club at our office centered around two pillars: Diversity, Equity and Inclusion, and Personal Development and Wellness. We pick a book on each topic every quarter, read it and then discuss it. The books for this quarter are:

Of the two, I started reading Peak because they have it only for a limited amount of time in Storytel my audiobook service of choice. 🇸🇪

The book is extremely interesting and has filled me with optimism and motivation to put in more work and effort to kick ass at the different endeavors that matter to me: coding, parenting, being a great husband, a good person, exercising... 😁

Here are some notes on how you can be more awesome at doing the stuff you care about.

Consistent Practice Beats Natural Talent

You can improve at something through consistent practice. The brain is very malleable and will adapt to the activities you spend your time doing. So as you practice something, you'll start becoming more proficient at it. Consistent practice and effort beat natural talent.

But not all kinds of practices are equally effective.

Just spending hours practicing by doing something will only get you so far. To become a true master of a skill you need purposeful or even better deliberate practice.

Purposeful Practice: How to get Super Good at Something on Your Own

“So here we have purposeful practice in a nutshell: Get outside your comfort zone but do it in a focused way, with clear goals, a plan for reaching those goals, and a way to monitor your progress. Oh, and figure out a way to maintain your motivation.”

Getting outside of your comfort zone is a key ingredient if you want to get really good at something. So push yourself a little bit harder every time.

The reason that most people don’t possess these extraordinary physical capabilities isn’t because they don’t have the capacity for them, but rather because they’re satisfied to live in the comfortable rut of homeostasis and never do the work that is required to get out of it. They live in the world of “good enough.” The same thing is true for all the mental activities we engage in

The other key ingredient to mastery is feedback: having a way to asses whether you're getting better or not. This helps you validate your learning and keeps you motivated.

Deliberate Practice: Achieving True Mastery Guided By Experts

Deliberate practice is a step over purposeful practice and requires:

A well developed and rigorous field (like music, chess, ballet, etc...)
A teacher that can guide and tailor your practice.

“… we are drawing a clear distinction between purposeful practice— in which a person tries very hard to push himself or herself to improve— and practice that is both purposeful and informed. In particular, deliberate practice is informed and guided by the best performers’ accomplishments and by an understanding of what these expert performers do to excel. Deliberate practice is purposeful practice that knows where it is going and how to get there.” (emphasis mine)

The main purpose of deliberate practice is to develop effective mental representations that make you more effective at learning and performing a skill. A person that can memorize 300 digits doesn't use raw memorization to do it, instead she builds mental representations to encode those digits in a way that bypasses the limitations of short-term memory. Expert teachers can really aid you in your practice because they already know the most useful mental representations in their field.

Knowing is never as good as doing. Most traditional education and learning systems focus a lot on learning knowledge and very little on putting it to practice. Deliberate practice focuses on doing. That's the most effective way to master a skill. The next time you find yourself learning something by reading a book, or watching videos consider investing your time in doing instead (e.g. building an app instead of watching someone else build an app).

An interesting fact is that deliberate practice isn't fun. Surveyed master violinists all agreed that practicing scales and other exercises that really contributed to the improvement of their skills weren't fun at all. But they practiced on because it was what was needed to become a truly awesome violinist.

Where Can I Find More?

If you find this topic interesting, here are a couple of articles that will help you get started with deliberate practice:

Or you can read the book.

Now go become a master! 💪😀💪

🔥🧙‍♂️🔥

P.S. Fun fact: You may have heard that you need to put in 10000 hours to truly master a skill. This statement is popularly known as the 10000 rule and it was popularized by Malcom Gladwell in his book Outliers. Well Malcolm took that tidbit from the same research done in this book and the authors make an attempt to correct him in this essay: Malcolm Gladwell got us wrong: Our research was key to the 10,000-hour rule, but here's what got oversimplified

Learn Svelte: Creating a Pomodoro Timer

Jaime González García — Mon, 13 Jan 2020 23:33:49 +0000

This article was originally published on Barbarian Meets Coding.

Svelte is a modern web framework that takes a novel approach to building web applications by moving the bulk of its work from runtime to compile-time. Being a compiler-first framework allows Svelte to do some very interesting stuff that is unavailable to other frameworks like disappearing from your application at runtime, or allowing for a component centered development with HTML, JavaScript and CSS coexisting within the same Svelte file in a very web standards friendly fashion.

In this series we'll follow along as I use Svelte for the first time to build an app. I'll use my go-to project[^1] to learn new frameworks: A Pomodoro Technique app, which is a little bit more involved than a TODO list in that it has at least a couple of components (a timer and a list of tasks) that need to interact with each other.

In this part four of the series we continue coding along as we create a pomodoro timer that will allow us to work on a given task with our complete focus and full attention. Let's get started!

Haven't read the other articles in this series? Then you may want to take a look at this list of resources for getting started with Svelte, and the first and second parts of building the Pomodoro Technique app.

Working on a Task with Your Full Attention

In the last part of this series we learned how when using the Pomodoro Technique you'll typically start your day sitting down, deciding what you'll achieve during the day and breaking it in as many pomodoros as you think it'll take. A pomodoro is a special unit of time used in The Pomodoro Technique which represents 25 minutes of uninterrupted work focusing on a single task.

The next step in The Pomodoro Technique consists in:

Picking the most important task,
Starting the pomodoro timer, and...
Start kicking ass by focusing single-mindedly on that task for the next 25 minutes.

After the 25 minutes have passed, you'll rest for 5 minutes, and then start a new pomodoro. After 4 pomodoros have been completed you'll rest for 20 minutes. It is important that both when the pomodoro starts and when it finishes, we get a auditory cue which will act as trigger to first get us into focus, and then to get us into a resting mindset.

So if we were to attemp to build a pomodoro timer to support this workflow, it would need to fullfill the following set of requirements:

It should have three states: An active state where we are working on a task and a state where we're resting and an idle state where we're not doing anything at all.
In the active state it should count from 25 minutes downwards
- When a pomodoro starts we should hear a cue
- When a pomodoro ends we should hear another cue
- We should be able to cancel or stop a pomodoro any time
In the resting state the timer should count from 5 or 20 minutes downwards
- It should count from 20 minutes downwards when 4 pomodoros have been completed
- It should count from 5 minutes downwards any other time
In the idle state nothing happens

Once a pomodoro has been completed whe should increase the number of pomodoros invested in the task in progress, and whenever a pomodoro is cancelled we need to type down the reason why (how were we interrupted? Why couldn't we keep our focus?). In this part of the series we'll just focus on building the timer itself, and in future articles we'll continue improving the timer and finally putting everything together. Let's get to it!

The Pomodoro Timer

Since a pomodoro timer seems like a completely separate responsibility from anything else in our app up to this point it deserves its own component. So I'll start by creating a new component called PomodoroTimer.svelte:

<p>
  Hi, I'm a pomodoro timer. Yo!
</p>

And adding it to our App.svelte component:

<script>
    let title = "il Pomodoro";
  import TaskList from './TaskList.svelte';
  import PomodoroTimer from './PomodoroTimer.svelte';
</script>

<main>
  <h1>{title}</h1>
  <PomodoroTimer />
  <TaskList />
</main>

I remember the rookie mistake I made in earlier parts of the series and I import the component before I use it in my template. Now my dev environment should display the new component...

Although it doesn't...

Weird...

Recheck, look at typos, refresh, rerun dev server. After some troubleshooting I realize that I need to do a hard refresh in my browser, it seems like it is caching localhost:5000. So hard refresh it is and now I see the new component. Sweet!

Starting a Pomodoro

Let's begin by implementing a way to start working on our first pomodoro. We're going to need:

A button to kick off the pomodoro
A way to represent the time left in a pomodoro

The button is quite simple. We update our svelte component template to include a new button that when clicked will start a new pomodoro:

<section>
  <p>
    Hi, I'm a pomodoro timer. Yo!
  </p>
  <button on:click={startPomodoro}>start</button>
</section>

Since we don't have a pomodoro timer just yet, we'll start by creating an empty startPomodoro function for the time being:

<script>
  function startPomodoro(){}
</script>

Now we need a way to represent the pomodoro timer. The initial state of the timer will be the length of a pomodoro (25 minutes). And since we'll often interact with the timer by decreasing a second at a time, we'll represent the length of a pomodoro in seconds (instead of minutes):

<script>
  // length of a pomodoro in seconds
  const POMODORO_S = 25 * 60;

  // time left in the current pomodoro
  let pomodoroTime = POMODORO_S;

  function startPomodoro(){}
</script>

Since I don't like having magic numbers in my code I'll extract the time conversion between minutes and seconds inside a function:

<script>
  const minutesToSeconds = (minutes) => minutes * 60;

  // length of a pomodoro in seconds
  const POMODORO_S = minutesToSeconds(25);

  // time left in the current pomodoro
  let pomodoroTime = POMODORO_S;

  function startPomodoro(){}
</script>

Now we need to represent that time in the template in the format MM:SS. We can use a function to transform the pomodoroTime into the desired format:

  function formatTime(timeInSeconds) { 
    const minutes = secondsToMinutes(timeInSeconds);
    const remainingSeconds = timeInSeconds % 60;
    return `${padWithZeroes(minutes)}:${padWithZeroes(remainingSeconds)}`;
  }

Which uses a couple of helpers:

  const secondsToMinutes = (seconds) => Math.floor(seconds / 60);
  const padWithZeroes = (number) => number.toString().padStart(2, '0');

Having defined formatTime we can use it in our template to transform the value of pomodoroTime:

<section>
  <p>
    {formatTime(pomodoroTime)}
  </p>
  <footer>
    <button on:click={startPomodoro}>start</button>
  </footer>
</section>

The complete component now looks like this:

<script>
  const minutesToSeconds = (minutes) => minutes * 60;
  const secondsToMinutes = (seconds) => Math.floor(seconds / 60);
  const padWithZeroes = (number) => number.toString().padStart(2, '0');

  // length of a pomodoro in seconds
  const POMODORO_S = minutesToSeconds(25);

  // time left in the current pomodoro
  let pomodoroTime = POMODORO_S;

  function formatTime(timeInSeconds) { 
    const minutes = secondsToMinutes(timeInSeconds);
    const remainingSeconds = timeInSeconds % 60;
    return `${padWithZeroes(minutes)}:${padWithZeroes(remainingSeconds)}`;
  }

  function startPomodoro(){}
</script>

<section>
  <p>
    {formatTime(pomodoroTime)}
  </p>
  <footer>
    <button on:click={startPomodoro}>start</button>
  </footer>
</section>

And looks like this:

But if we click on the button start nothing happens. We still need to implement the startPomodro function. Now that we have an initial implementation for the timer we can fill in its implementation:

function startPomodoro() { 
  setInterval(() => {
    pomodoroTime -= 1;
  },1000);
}

And TaDa! we have a working timer:

Completing a Pomodoro and Taking a Break

Now there's two options, we can either focus on working on the task at hand and complete a pomodoro (Yihoo! Great job!) or we can cancel the pomodoro because we've been interrupted by something or someone.

When we complete a pomodoro, two things should happen:

The pomodoro count of the current task should increase by one
The timer goes into a resting state and starts counting down

Since we aren't going to integrate the timer with the rest of the app yet, let's focus on item number #2 by creating a new function completePomodoro. Whenever the pomodoroTime count down arrives to 0 we complete the pomodoro calling this new function:

function startPomodoro() { 
  setInterval(() => {
    if (pomodoroTime === 0) {
      completePomodoro();
    }
    pomodoroTime -= 1;
  },1000);
}

Whenever we complete a pomodoro we're going to slide into a resting state counting down from 20 minutes or 5 minutes depending on whether we have completed 4 pomodoros up to this point. So:

We define a couple of constants to store the lenghts of the breaks LONG_BREAK_S and SHORT_BREAK_S
We define a completedPomodoros variable we'll use to keep track of how many pomodoros we have completed up to this point. This variable will determine whether we take the short or long break.
We implement the completePomodoro to complete a pomodoro and jump into the resting state:

  const LONG_BREAK_S = minutesToSeconds(20);
  const SHORT_BREAK_S = minutesToSeconds(5);
  let completedPomodoros = 0;

  function completePomodoro(){
    completedPomodoros++;
    if (completedPomodoros === 4) {
      rest(LONG_BREAK_S);
      completedPomodoros = 0;
    } else {
      rest(SHORT_BREAK_S);
    }
  }

We still have an interval running our counting down function so we need to make sure to stop that interval before we proceed. We update the startPomodoro function to store a reference to the interval:

let interval;
function startPomodoro() { 
  interval = setInterval(() => {
    if (pomodoroTime === 0) {
      completePomodoro();
    }
    pomodoroTime -= 1;
  },1000);
}

And clear it whenever we complete a pomodoro:

function completePomodoro(){
  clearInterval(interval):
  completedPomodoros++;
  // TODO: update the current task with a completed pomodoro
  if (completedPomodoros === 4) {
    rest(LONG_BREAK_S);
    completedPomodoros = 0;
  } else {
    rest(SHORT_BREAK_S);
  }
}

The rest function sets the timer into the resting state:

function rest(time){
  pomodoroTime = time;
  interval = setInterval(() => {
    if (pomodoroTime === 0) {
      idle();
    }
    pomodoroTime -= 1;
  },1000);
}

It's very similar to an in-progress pomodoro but it sets the pomodoro into an idle state when the count down finishes. The idle state can be modelled with this other function:

  function idle(){
    clearInterval(interval);
    pomodoroTime = POMODORO_S;
  }

The whole component looks like this right now:

<script>
  const minutesToSeconds = (minutes) => minutes * 60;
  const secondsToMinutes = (seconds) => Math.floor(seconds / 60);
  const padWithZeroes = (number) => number.toString().padStart(2, '0');

  const POMODORO_S = minutesToSeconds(25);
  const LONG_BREAK_S = minutesToSeconds(20);
  const SHORT_BREAK_S = minutesToSeconds(5);

  let pomodoroTime = POMODORO_S;
  let completedPomodoros = 0;
  let interval;

  function formatTime(timeInSeconds) { 
    const minutes = secondsToMinutes(timeInSeconds);
    const remainingSeconds = timeInSeconds % 60;
    return `${padWithZeroes(minutes)}:${padWithZeroes(remainingSeconds)}`;
  }

  function startPomodoro() { 
    interval = setInterval(() => {
      if (pomodoroTime === 0) {
        completePomodoro();
      }
      pomodoroTime -= 1;
    },1000);
  }

  function completePomodoro(){
    clearInterval(interval);
    completedPomodoros++;
    // TODO: update the current task with a completed pomodoro
    if (completedPomodoros === 4) {
      rest(LONG_BREAK_S);
      completedPomodoros = 0;
    } else {
      rest(SHORT_BREAK_S);
    }
  }

  function rest(time){
    pomodoroTime = time;
    interval = setInterval(() => {
      if (pomodoroTime === 0) {
        idle();
      }
      pomodoroTime -= 1;
    },1000);
  }

  function idle(){
    clearInterval(interval);
    pomodoroTime = POMODORO_S;
  }
</script>

<section>
  <p>
    {formatTime(pomodoroTime)}
  </p>
  <footer>
    <button on:click={startPomodoro}>start</button>
  </footer>
</section>

Now, when things go wrong and we get distracted we must cancel the pomodoro, write down the cause of our distraction (so we can reflect and learn from it) and start over. Let's update our timer to support this use case.

Cancelling a Pomodoro

In order to be able to cancel a pomodoro we'll add a new button to our template:

<section>
  <p>
    {formatTime(pomodoroTime)}
  </p>
  <footer>
    <button on:click={startPomodoro}>start</button>
    <!-- New button HERE -->
    <button on:click={cancelPomodoro}>cancel</button>
    <!-- END new stuff-->
  </footer>
</section>

Whenever the user clicks on this button we'll cancel the current pomodoro using the cancelPomodoro function:

function cancelPomodoro(){
  // TODO: Add some logic to prompt the user to write down
  // the cause of the interruption.
  idle();
}

And now we can start and cancel pomodoros:

Improving The User Experience Slightly

With our current implementation a user can start a pomodoro when a pomodoro has already started, and likewise cancel a pomodoro which hasn't started yet which makes no sense. Instead the user should get some visual cues as to what actions make sense under the different conditions. So we're going to improve the user experience of our timer by:

Enabling the start pomodoro button only when we're in an idle state
Enabling the cancel pomodoro button only when we're in a pomodoro-in-progress state

In order to do that we need to keep track of the state of the timer so we start by modeling the different states available with an object:

const State = {idle: 'idle', inProgress: 'in progress', resting: 'resting'};

And we'll store the current state of the pomodoro timer in a currentState variable:

let currentState = State.idle;

We then update the different lifecycle methods to update this state as needed:

function startPomodoro() { 
  currentState = State.inProgress;
  interval = setInterval(() => {
    if (pomodoroTime === 0) {
      completePomodoro();
    }
    pomodoroTime -= 1;
  },1000);
}

function rest(time){
  currentState = State.resting;
  pomodoroTime = time;
  interval = setInterval(() => {
    if (pomodoroTime === 0) {
      idle();
    }
    pomodoroTime -= 1;
  },1000);
}

function idle(){
  currentState = State.idle;
  clearInterval(interval);
  pomodoroTime = POMODORO_S;
}

And now we update our templates to take advantage of this new knowledge to enable/disable the buttons that control the timer:

<section>
  <p>
    {formatTime(pomodoroTime)}
  </p>
  <footer>
    <button on:click={startPomodoro} disabled={currentState !== State.idle}>start</button>
    <button on:click={cancelPomodoro} disabled={currentState !== State.inProgress}>cancel</button>
  </footer>
</section>

Awesome!

The full component at this point looks like this:

<script>
  const minutesToSeconds = (minutes) => minutes * 60;
  const secondsToMinutes = (seconds) => Math.floor(seconds / 60);
  const padWithZeroes = (number) => number.toString().padStart(2, '0');
  const State = {idle: 'idle', inProgress: 'in progress', resting: 'resting'};

  const POMODORO_S = minutesToSeconds(25);
  const LONG_BREAK_S = minutesToSeconds(20);
  const SHORT_BREAK_S = minutesToSeconds(5);

  let currentState = State.idle;
  let pomodoroTime = POMODORO_S;
  let completedPomodoros = 0;
  let interval;

  function formatTime(timeInSeconds) { 
    const minutes = secondsToMinutes(timeInSeconds);
    const remainingSeconds = timeInSeconds % 60;
    return `${padWithZeroes(minutes)}:${padWithZeroes(remainingSeconds)}`;
  }

  function startPomodoro() { 
    currentState = State.inProgress;
    interval = setInterval(() => {
      if (pomodoroTime === 0) {
        completePomodoro();
      }
      pomodoroTime -= 1;
    },1000);
  }

  function completePomodoro(){
    clearInterval(interval);
    completedPomodoros++;
    if (completedPomodoros === 4) {
      rest(LONG_BREAK_S);
      completedPomodoros = 0;
    } else {
      rest(SHORT_BREAK_S);
    }
  }

  function rest(time){
    currentState = State.resting;
    pomodoroTime = time;
    interval = setInterval(() => {
      if (pomodoroTime === 0) {
        idle();
      }
      pomodoroTime -= 1;
    },1000);
  }

  function cancelPomodoro() {
    // TODO: Add some logic to prompt the user to write down
    // the cause of the interruption.
    idle();
  }

  function idle(){
    currentState = State.idle;
    clearInterval(interval);
    pomodoroTime = POMODORO_S;
  }
</script>

<section>
  <p>
    {formatTime(pomodoroTime)}
  </p>
  <footer>
    <button on:click={startPomodoro} disabled={currentState !== State.idle}>start</button>
    <button on:click={cancelPomodoro} disabled={currentState !== State.inProgress}>cancel</button>
    <!--button on:click={completePomodoro}>complete</button-->

  </footer>
</section>

Adding Some Styling

Now let's apply some styling to our timer. The timer consists on some text with the timer itself and a couple of buttons. The styles of the timer feel like something that should belong to this component and this component only, but the styles of the buttons sound like something that should be consistent across the whole application.

Styling the timer text is quite straighforward. We just update the styles within PomodoroTimer.svelte. While I'm doing this, I remember HTML has a time element that is a more semantic way to represent time in a web application and I switch my puny p element for time:

<style>
  time {
    display: block;
    font-size: 5em;
    font-weight: 300;
    margin-bottom: 0.2em;
  }
</style>

<section>
  <time>
    {formatTime(pomodoroTime)}
  </time>
  <footer>
    <button on:click={startPomodoro} disabled={currentState !== State.idle}>start</button>
    <button on:click={cancelPomodoro} disabled={currentState !== State.inProgress}>cancel</button>
    <!--button on:click={completePomodoro}>complete</button-->

  </footer>
</section>

And now, for the buttons, how does one do application-wide styles in Svelte? There's different options but for this particular use case we can take advantage of the global.css file that is already available in our starter project. In fact, it already has some styles for buttons:

button {
  color: #333;
  background-color: #f4f4f4;
  outline: none;
}

button:disabled {
  color: #999;
}

button:not(:disabled):active {
  background-color: #ddd;
}

button:focus {
  border-color: #666;
}

Let's tweak this a little. We're going to have a primary and secondary action buttons, where the primary action is going to be the start pomodoro, and the rest will be treated as secondary action (we really want to get our pomodoros started). The primary action will use a set of accent colors while the secondary action will use a set of base colors which we'll define as a color scheme using CSS variables:

:root{
 --black: #333;
 --base: white;
 --base-light: #f4f4f4;
 --base-dark: #ddd;

 --white: white;
 --accent: orangered;
 --accent-light: #ff4500d6;
 --accent-dark: #e83f00;
}

Now we redefine the styles for the secondary action button which we'll just act as the default look and feel of a button:

button {
  background-color: var(--base);
  border-color: var(--black);
  color: var(--black);
  font-size: 1.5em;
  font-weight: inherit;
  outline: none;
  text-transform: uppercase;
  transition: background-color .2s, color .2s, border-color .2s, opacity .2s;
}

button:disabled {
  opacity: 0.5;
}

button:focus,
button:not(:disabled):hover {
  background-color: var(--base-light);
}

button:not(:disabled):active {
  background-color: var(--base-dark);
}

And we define new styles for the primary action button which will build on top of the styles above:

button.primary {
  background-color: var(--accent);
  border-color: var(--accent);
  color: var(--white);
}

button.primary:not(:disabled):hover {
  background-color: var(--accent-light);
  border-color: var(--accent-light);
}

button.primary:not(:disabled):active {
  background-color: var(--accent-dark);
  border-color: var(--accent-dark);
}

Now to make the inputs fit it with the buttons we'll tweak their font-size:

input, button, select, textarea {
  font-family: inherit;
  font-size: 1.5em;
  font-weight: inherit;
  padding: 0.4em;
  margin: 0 0 0.5em 0;
  box-sizing: border-box;
  border: 1px solid #ccc;
  border-radius: 2px;
}

We also update the font-weight of our app to be lighter and more minismalistic because why not:

body {
  color: var(--black);
  margin: 0;
  padding: 8px;
  box-sizing: border-box;
  font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Oxygen-Sans, Ubuntu, Cantarell, "Helvetica Neue", sans-serif;
  font-weight: 300;
}

We make the add task button in the TaskList.svelte component also be a primary button:

<button class="primary" on:click={addTask}>Add a new task</button>

And why not? Let's make the title a little bit bigger (I'm getting carried away here). Inside App.svelte:

  h1 {
    color: var(--accent);
    text-transform: uppercase;
    font-size: 6em;
    margin: 0;
    font-weight: 100;
  }

And that's it! We may need to revisit the styles to make sure the contrast is enough to support great accessibility but this is a start:

Sweet! And that's all for today. In the next part in the series we'll continue with:

Refactoring our timer with the help of automated tests (because I'm not super happy with the current implementation).
Adding auditory feedback when the pomodoro starts and ends.
Integrating the timer with the tasks so we have a full pomodoro technique flow.

Looking for the source code for the pomodoro app?

Look no more! You can find it on GitHub ready to be cloned and enjoyed, or on the Svelte REPL where you can tinker with it right away.

More Reflections

Working with Svelte continues to be very pleasant. In addition to my previous reflections (1, 2), I've found that:

Formatting functions are very straightforward. When I needed to format the time in a specific format in my template, I just went with my gut, wrapped the formatting within a vanilla JavaScript function, used it on the template formatTime(pomodoroTime)} and it worked.
Assigning and binding properties to a DOM element is also straightforward. Once more, I just went with my gut, typed disabled={currentState !== State.idle} and it worked as I expected it to. Principle of least surprise! Yey!
Having the styles within a component feels very natural and useful: There's no need to switch context as the styles are in close proximity to where they're used. If you ever need to update the styles of a component you know where to go, and likewise if you remove a component its styles disappear with it (You don't need to search around your application in a deadly csshunt).

5 Minutes Vim: Learn to Use Vim's Help

Jaime González García — Thu, 02 Jan 2020 21:08:43 +0000

This article was originally posted in barbarianmeetscoding.com. 😊

In this 5 minutes of Vim goodness we'll learn about one of the most amazing yet often underused features in Vim and how you can use it to become more effective with Vim. Vim's Help! Here we go!

Vim's help is truly amazing and unique. If whenever you use Vim you run into a problem, or wonder how to do something, or how something works, try typing :h {keyword} and Vim will do its best to fulfill your wishes and find the help you need. The {keyword} itself can be a command, a key combination or just something that you want to learn more about:

Want to know how the :global command works? Then try :h :global.
Want to know what the daw key combo does? Test :h daw.
Want to know about motions in Vim? Then try :h motions.
Want to know what the wildmenu option does in the vimrc? Type :h 'wildmenu'.
Want to learn how to quit Vim? Yes. You guessed it. Go :h quit
Want to learn what CTRL-W does in insert mode? Try :h i_CTRL-W

Can't exactly find what you want?

Sometimes Vim will have more than one match for the keyword you are searching for. In those cases, Vim will send you to the help page that contains the first match but this might not always be the one you want.

If you can't seem to find exactly what you are looking for, try the following:

Type :h {keyword} as usual but don't press ENTER at the end. Instead type CTRL-D or TAB. That will show you all the occurrences of the keyword within Vim's help and may just reveal what you're truly looking for.

Become More Effective Using Vim's Help

Type :h or :help and you'll be taken to the help's index which starts with information about how to use the help itself:

How shall I help you, oh master?

This initial help document contains a quickstart guide with a couple of nice tricks that will allow you navigate Vim's help faster:

Type <C-]> to follow a link (you can differentiate links from regular text because links are highlighted)
Use <C-O> to go back to where you were before
Use /{pattern} to search within a document (that's how you normally search for things in Vim by the way).
The help appears in a normal split window so when you're done with it you can just close it with the :quit command just like any other window
Skim :h help-summary and :h helphelp at least once to get a feel for all the things that you can search for in Vim and how to do it.

Remember! You don't need to know these key combinations by heart. Just remember :help. Type :help and you'll be brought to the help about how to use Vim's help where you'll find them again. Help. Help.

Read the Help like a Book

Vim's help is great for precision lightning attacks of curiosity and/or need, like the ones above, but it is also great to peruse and read like a book.

When you type help, right below the quickstart introductory guide, you have the Vim user and reference manuals. The user manual is essentially a book on how to use Vim, from novice to expert with topics ranging from how to move around in Vim to how to create your own syntax highlighters. The reference manual is an in-depth reference of everything Vim. Both of them are really great.

Get Help with Vim Plugins

One thing that is really cool is that Vim's third party plugins also appear in the help. Just installed a popular plugin and don't quite know how it works? Try :h {nameOfPlugin}. If you are unsure about the name of the plugin's docs, then take a look at the bottom of the :help page where you'll find the third party plugins listed:

The type of information that is really useful to look out for is:

What does it do?
How do you set it up? Does it work out of the box or does it require some additional setup?
What are the commands and mappings that it adds to your Vim setup? How can you customize them?

A small warning here: With Vim plugins you will often find that the help you can find inside Vim is far superior to whatever you can find outside (like searching the web). So it is very important to get into the habit of using help, even for plugins, specially for plugins.

Can't Find The Documentation of a Plugin?

You can load the docs from a plugin using the :helptags ALL command. But you don't really want to do that manually. Instead, use a plugin manager to load all the docs of your plugins automagically. We will look at how you can do that later in the book.

Awesome! That's it! Hope you found this article useful. Take care!

5 Minutes Vim: CtrlP considered harmful

Jaime González García — Wed, 01 Jan 2020 12:07:26 +0000

This article was originally posted in barbarianmeetscoding.com. 😊

In this 5 minutes of Vim goodness we'll break the shackles of convention and become slightly more productive when using Vim. Here we go!

Of all the activities you'll perform when coding with Vim (or any other editor), one of the most common ones is the simple act of moving between files. Since this is such a common thing we do in our daily coding using a plugin that allows us to move between files seamlessly is a must-have for all Vim users.

These plugins fall in the category of fuzzy search file finders and they let you go from a workflow that in Vim can resemble:

The slow typing of a file path using the :edit command
The slow navigating of the file tree of your project in netrw (:h netrw).

and in other editors a manual search for a file with the mouse, to something that is so straightforward and instantenous as thinking of the name of a file, typing it and jumping right into it.

In VSCode it's called quick open and can be reached with CTRL-P or CMD-P. In other editors it's called Go To File or something similar. In Vim there's a slew of plugins that provide a similar (and often more powerful) functionality: fzf.vim, ctrlP and denite are some of the ones which come to my mind as I type these words.

I personally use fzf and I use it all the time. The first mapping that I added to my vim fzf configuration was this:

nnoremap <C-p> :<C-u>FZF<CR>

I probably found it somewhere in the docs and it has served me really well over the years. I just type CTRL-P, the name of my destination appears in my head, my fingers materialize it into text, and BOOM! I'm in that file.

All seems fine but when you stop to thing about it... Why use CTRL-P at all for such a common coding task? It forces me to move both of my pinky fingers away from the home row. That doesn't feel really great, does it? The answer is probably tradition and inertia. I can't quite remember which was the first editor to provide this sort of functionality (textmate?), but we've just continued the tradition and used this key binding when there are far better choices.

So instead, in order to perform this super frequent task, we can use the premium space in our keyboard, the home row. And we can rely on the <leader> key so that jumping into fuzzy search is super smooth:

nnoremap <leader>s :<C-u>FZF<CR>

In my vim config <leader>s is <space>s. Both of these keys are under my hand in resting position so jumping into fuzzy search mode is completely friction free.

But this is just an example. The really important thing is the principle behind it:

Question everything: When using plugins or copying mappings from other plugin configurations or vimrcs from other users question the mappings and commands, think about how often you use them, and adapt them before you incorporate them in your own config.
Put frequent tasks in the home row: Take advantage of the <leader> key in combination with the home row keys for frequent coding tasks

Happy fuzzy finding!

Goodbye 2019! Hello 2020 Holy Shit!

Jaime González García — Wed, 01 Jan 2020 01:22:07 +0000

This article was originally posted in barbarianmeetscoding.com. 😊

I cannot believe another year has passed! And I really can't believe that 2020 is upon us. The 2020 of flying cars, hoverboards and deep space exploration. But indeed it has, and that means that it is time for the traditional reflective year summary, a wrap-up blog, retrospective of sorts, on what I've achieved the past year, my biggest fails, what I've learned and what I am planning to do in 2020.

One of the best things about writing this article is that I will go back and read the ones I wrote the previous years. Which is really, really cool. It's like having a conversation with past Jaime. And it's also really surprising to see how many things happen and can be achieved within the space of a year. Just for these reasons, I encourage you to follow the same practice, even if you don't publish it and it is for your eyes only. It's a really enjoyable habit.

So! Let's get to it then: In 2019...

In 2019...

2019 was a very interesting and quite atypical year¹ in many different ways both in my personal life and at work. If I had to summarize it in a single sentence it would be: super cozy family year, lots of fun at work, sick and exhausted most of the time yet I got lots of stuff done.

I started the year on parental leave up until the end of March beginning of April when Teo started going to kindergarten and I went back to work. It was sad and a relief at the same time. I really enjoyed spending so much quality time with my son, but having him start kindergarten was a great experience for the both of us. He got to develop a lot in a very short amount of time, he had a lot of fun meeting new friends and being in a new and very engaging environment, and I got more time for myself and to go back to coding full time which is something I really enjoy doing.

I rejoined the Hangouts Meet team at Google after ~10 months of parental leave with lots of energy and enthusiasm, and it's been a blast to go back to doing software development full time. It took me a while to regain my confidence as a software engineer, but every day, week and month that passed increased my confidence and contributions to the team. By the end of the year, I feel like I became a very strong contributor, leading a lot of initiatives and having a strong impact in what we have delivered. I even started a front-end guild to create a local community around front-end software development in our office in Stockholm, because I love hanging out, sharing ideas about code and encouraging people to learn from each other.

I am so very grateful to all the people (my wife Malin and my colleagues at Google) that supported me in me coming back to Software Development. I'm so much more happy and at peace working on something I really enjoy doing and having all the bits within my life align so much better. Thank you!. (If you're curious about this I wrote about it in this article).

It was a surprisingly tough year as a parent, even though it wasn't as utterly exhausting as the first year it was difficult in a different way. I think the trickiest part has been to balance work and life as a parent and having those two responsibilities weighting on me throughout the day. That plus being sick really, really often with Teo bringing ultrapowerful germs from kindergarten into the holy sanctuary of our home (It is crazy, I've never been so sick, so often in my life, and I used to be one of those persons who never got sick). In an ideal world I would have plenty of energy for both but I haven't yet cracked that problem and I'd often pass out on the couch now and then after work and after spending some time with Teo. Malin has far more energy than I do, and is a constant inspiration on what it means to be an awesome parent. Malin is awesome.

As tough as it is, it is also wonderful to spend time with my Malin and Teo, and following along as Teo grows into an awesome person. The development he's experienced throughout this year has been amazing to behold and ~2 years is my favorite age of his thus far. It has also been really cool to be support him along the way, teach him new things and give him lots of love.

Work, parenting and exhaustion leave few time and energy to do anything else but I somehow managed to work on some side projects and community contributions. I think that the secret here is that even when the conditions and the environment for doing stuff are quite adverse, a little bit of consistent work over time produces great results.

Writing

I started writing Wizards Use Vim, a new and wonderful book on Vim that I couldn't finish in 2019. I've been using Vim since 2013, and after a ton of in-depth experimentation with it in 2018 I embarqued on a quest to make Vim more approachable to everyone with my my book Wizards Use Vim. I wrote ~200 pages mostly at the beginning of the year, and then I did something strange, I jumped to working on a different book: Boost Your Coding Fu with VSCode and Vim.
I wrote and published Boost Your Coding Fu. The original idea was that Boost Your Coding Fu was going to be a very short book, very drafty, like one of those 30 pages books some people give away to get readers subscribed to their blog. But once I started writing it I couldn't help myself, so I wrote it and started improving it, iterating, reviewing, perfecting it some more, and it ended up been a solid and short (140p) book which I completed in July.
I built a website for Boost Your Coding Fu, with an online reading experience open for anybody to read, learn and enjoy. I also recorded lots of videos with step by step VSCodeVim tutorials.
The JavaScriptmancy Books were in the top 100 JavaScript books of all time.

Blogging

I redesigned Barbarian Meets Coding and added a crazy fantasy conan-inspired pixel art animation to its front page:

I wrote 40 articles in my blog this year of diverse lengths and topics. This is crazy because I think this is the most articles I've written ever in this blog during a year.
- There were technical posts on Vim, TypeScript, Svelte but also soft posts on motivation, focus and career.
I redesigned and relaunched my newsletter with more personal articles, wrote 8 newsletters and when life got pretty tough I kind of paused it.
In addition to my blog, I put a lot of my content on dev.to, an amazing, warm and super welcoming community for software developers. At the end of the year I reached 15K subscribers² which is pretty amazing.

My favorite articles this year were:

YouTube

I created more YouTube content this year that any other year up until now with 18 videos. Creating videos is a ton of fun but it has proved really challenging. Mainly because I've found very hard to find a suitable time to record videos given that I have a toddler around with massive powers of mayhem and destruction, and a light sleep.
My channel grew to 278 subscribers. Wiho!
I also tweaked the design of my channel.

Podcasting

I created an experimental podcast where I narrate the Boost Your Coding Fu With VSCode and Vim book with a strong yet soothing voice. I completed 7 chapters.
I also created a website for the podcast and made it available on iTunes and Google Podcast. I wrote an article on my wiki on how to do that if you want to do the same.
I was interviewed by the Frontmatter podcast about my life, my career at Google, and my experiences as an author.

Speaking and Dev Relations

My speaking contributions in 2019 were very small. This hasn't changed so much since I became a dad. This year I spoke on two events:
- I was at the Google Developer Group Stockholm speaking about how you can be more productive with VSCode and Vim.
- I helped Hon kodar organize an Angular workshop for women who code or want to learn to code. I delivered two talks and helped throughout the workshops.

In the olden days I didn't have a problem participating or organizing events after work hours, but today with the life of a parent it becomes harder and harder to justify. I just enjoy spending time with my family too much, and supporting my wife in taking care of Teo who can be quite a handful. I think that's a very strong reason why I haven't been doing more of these in-person speaking thingies, it is far easier and more convenient for me to just write or record something when Teo is sleeping.

Reading

In 2019 I read 48 books. I also started and didn't finish dozens more. I wrote an article about my favorite books in 2019, so if you're looking for new books to read you may want to take a look at that.
In addition to the above, I also "read 23 books" on blinkist. If you haven't heard about blinkist it's a service where they summarize the most important ideas in very diverse and popular books. I'm not sure if I quite like it yet, sometimes it can feel very superficial, but one thing that I like about it is that it exposes me to lots of ideas that I wouldn't peruse normally because I'd never prioritize that time investment.

My Biggest Fails of 2019

Even though it has been a great year overall, this year I felt very often that I was in survival mode, being sick and/or exhausted for long periods of the year. I felt very often that, just as I was about to come back to a good spot of working out, having energy, doing things, something would happen that would knock me back down.
I left lots of things half-started and unfinished: The Wizards Use Vim book jumps right into my mind but also the JavaScript-mancy series have been lacking a lot of attention.
I tend to spread myself too thin over too many activities and projects.
Exercising and working out hasn't been great this year. I've had some good runs throughout the year but combining work, family and working out hasn't really worked out. I so need to get better at this.
I still downprioritize sleep when I shouldn't. This is a constant struggle as a parent when stealing time from sleep hours is the only way you can find some time to invest in yourself.
We used to travel a lot, but we haven't done much of that this year. That's something that I definitely want to go back next year, because it is very enjoyable and I think it's great for Teo to get exposed to different cultures.

In 2020 I want to...

In 2020 I want to kick ass even more! But we'll talk about that tomorrow. Now it's time to cook a great New Year's Eve dinner. Happy 2019! And an even happier 2020!

The life of a first-time parent is likely very atypical year after year as your child develops and you get confronted with new challenges and life routines. ↩
Subscribers are often referred to as followers. But I am not Jesus Christ so I prefer to call them subscribers. e.g. people that are interested in the content that I write and find that content helpful and useful enough to subscribe for more. ↩

The Wizard Logs - Part III - The Adventures, Glory and Misfortunes of Writing Wizards Use Vim

Jaime González García — Mon, 30 Dec 2019 14:33:03 +0000

This article was originally written in barbarianmeetscoding.com. Cover image credit from media in diablo 3

It has been a looooong time since the last time I wrote a wizard log, yet I haven't been idle. Not quite. But some context may be needed.

Last year I embarqued on a quest of sorts: I wanted to make Vim more approachable to everyone. So I started writing Wizards Use Vim, an introductory book to Vim that teaches you all you need to know to be an effective Vim user in a fun and light manner.

But after a couple of months of intense writing I had another idea. If I really wanted to make Vim approachable to developers, I better find developers where they are. And so I built a bridge towards Vim in the form of a new book: Boost Your Coding Fu With VSCode and Vim.

I started writing Wizards Use Vim to take a break from the JavaScriptmancy Series. Then I started writing a book on VSCodeVim to take a break from Wizards Use Vim. Procrastinator level epic.

Jaime. Procrastinator Level Epic.

The original idea was that Boost Your Coding Fu was going to be a very short book, very drafty, like one of those 30 pages books some people give away to get readers subscribed to their blog. But once I started writing it I couldn't help myself, so I wrote it and started improving it, iterating, reviewing, perfecting it some more, and it ended up been a very solid book which I completed in July together with:

A page to act as a hub for the book
An online version of the book open for anybody to read, learn and enjoy
A cheatsheet with all the stuff covered within the book
Lots of videos with step by step VSCodeVim tutorials
An experimental podcast where I narrate the book

And had great reviews from readers:

I simply don't know how to express my fascination about the vscodevim book.

The only thing that I can say right now is thank you and congratulations.

I was searching for some vim information and then I found your book, explaining exactly what I needed (cause I'm using vscode lol).

I brought it for the lowest prize cause I'm not in my better days. Now I finished reading, I wish I could give 3 times more.

Hey, I just finished reading your book about VSCode and Vim. I read it in 2 days, was a pleasure to read it and also very valuable, I like your way of teaching, definitely works for me.

Only one chapter in, but I'm already a big fan of @vintharas 's vim vscode book.

So... Yep. This whole thing kind of derailed a little. What started as the idea for a super short book to help vscode users get a feel for Vim and how it can make you a more productive developer, ended up becoming a shitload of work and content.

And therefore, with all this time invested in Boost Your Coding Fu plus the super tough life as a parent of a wonderful toddler, Wizards Use Vim has been pretty much frozen. Up until now that is! :D For I shall come back to it and finish the shit out of it. This is the current status of the book with 250-ish pages:

Intro. Draft complete
Part I. Vim Apprentice. Draft complete
Part II. Vim Master. About 30% draft completed
Part III. Vim Grandmaster. Only an outline

My next goal for the upcoming three months is to:

Create a draft for the complete book
First Review, editing and add exercises
Second Review, editing and add illustrations
Complete final cover
Publish
Complete full print cover
Publish in print

And that will be my sole focus come 2020. So hold tight because there's some amazing Vim content coming your way and lots of updates as I progress through these goals.

Learn Svelte: Adding, Editing and Estimating Tasks In The Pomodoro Technique App

Jaime González García — Sun, 29 Dec 2019 17:34:41 +0000

This article was originally published on Barbarian Meets Coding.

In this part 3 of the series we continue our project by making it possible to create a list of tasks and estimate the number of pomodoros it will take to perform them. Let's get started!

Haven't read the other articles in this series? Then you may want to take a look at this list of resources for getting started with Svelte or the first part of building the Pomodoro Technique app

Starting a Daily Pomodoro Routine

When you follow the Pomodoro Technique, the first thing that you'll do everyday before you start working is to sit down and follow these steps:

Decide what tasks you want to achieve today,
Estimate how many pomodoros it will take to fulfill them and, then
Prioritize them taking into account how many pomodoros you can realistically achieve

Let's improve our skeletal Pomodoro app to support this initial flow by providing a way to create and estimate Tasks.

Defining a Way to Model a Task

The first thing that we need to do is to devise a way to model a task. In our current version of the app, a task is just a string that represents a description of whatever we need to get done:

<script>
  const tasks = [
    "plan some fun trip with Teo",
    "buy some flowers to my wife",
    "write an article about Svelte"
  ];
</script>

<style>
  ul {
    list-style: none;
  }
</style>

<ul>
  {#each tasks as task}
    <li>{task}</li>
  {/each}
</ul>

But we need our tasks to be slightly more involved with information such as the number of pomodoros we expect the task will take, the status of the task (is it completed or not?) and the actual number of pomodoros the task took.

So we'll model the task using a class Task within a new file Task.js with some initial fields to cover our initial use case:

export class Task {
  constructor(description="", expectedPomodoros=1) {
    this.description = description;
    this.expectedPomodoros = expectedPomodoros;
    this.actualPomodoros = 0;
  }
}

We can now replace the strings from our original example with instances of this class:

<script>
    import { afterUpdate } from 'svelte';
  import {Task} from './Task.js';

  let tasks = [
    new Task("plan some fun trip with Teo"),
    new Task("buy some flowers to my wife"),
    new Task("write an article about Svelte"),
  ];
</script>

The UI remains the same for now. We've just changed the underlying way in which we represent a task. Now, let's make it possible to add new tasks.

Creating new Tasks

Our goal for this tutorial will be to get to a working implementation of a Pomodoro technique app as soon as possible, so we'll focus on getting there fast with little regard for an amazing user experience or great design. We will center our development in getting the basic core functionality in place and later we will polish and refine.

In order to have a quick implementation of an editable list of tasks where one can add and remove tasks to their heart's content we're going to follow this approach. We'll:

Make all tasks editable by using inputs for each task
Add a button to add new tasks
Add a button to remove tasks beside each one of the tasks

Making Tasks Editable

In order to make our tasks editable we are going to update our TaskList.svelte component. Instead of plain list elements:

<ul>
  {#each tasks as task}
    <li>{task}</li>
  {/each}
</ul>

We'll use inputs:

<ul>
  {#each tasks as task}
    <li>
      <input type="text" value={task.description}>
      <input type="number" value={task.expectedPomodoros}>
    </li>
  {/each}
</ul>

The example above seems like it's working but it really isn't. The value={task.description} only works one way, from the data into the template. But if a user tries to edit a task, the new description or pomodoros won't be reflected in the data. The way to establish a two-way data binding between data and template is by using the bind:value directive:

<ul>
  {#each tasks as task}
    <li>
      <input type="text" bind:value={task.description}>
      <input type="number" bind:value={task.expectedPomodoros}>
    </li>
  {/each}
</ul>

And now we can edit task descriptions and the number of pomodoros we expect each task will take. Whenever we update the underlying data, it will be reflected in the inputs, and likewise, whenever we update the inputs, the changes we do will be reflected in the data.

Let's adjust the styles a little bit so that the input fields suit their content better:

<style>
  ul {
    list-style: none;
  }
  .description {
    min-width: 400px;
  }
  .pomodoros { 
    max-width: 100px;
  }
</style>

<ul>
  {#each tasks as task}
    <li>
      <input class="description" type="text" bind:value={task.description}>
      <input class="pomodoros" type="number" bind:value={task.expectedPomodoros}>
    </li>
  {/each}
</ul>

Svelte styles are scoped to the component itself so I could've styled the input elements directly (with nth-child selectors for instance), but I like to use semantic named classes for two reasons:

They are easier to read and make sense of
If I happen to change the order of the inputs at some point in the future I won't break the styles of my app

Now it looks better! Nice!

Adding New Tasks

The next thing we want to do is to be able to add new tasks. So we add a button that will perform that function:

<ul>
  {#each tasks as task}
    <li>
      <input class="description" type="text" bind:value={task.description} >
      <input class="pomodoros" type="number" bind:value={task.expectedPomodoros}>
    </li>
  {/each}
  <button>Add a new task</button>
</ul>

Whenever we click on this button we will add a task to the list of tasks that we want to complete today. In order to do that, we handle the click event using the on:{event} directive so that every time a user clicks on that button a new task is created and added to our list:

<button on:click={addTask}>Add a new task</button>

The addTask function belongs to the behavior-y portion of our Svelte component inside the script tag:

<script>
    import { afterUpdate } from 'svelte';
  import {Task} from './Task.js';

  let tasks = [
    new Task("plan some fun trip with Teo"),
    new Task("buy some flowers to my wife"),
    new Task("write an article about Svelte"),
  ];

  function addTask(){
    tasks.push(new Task());
  }
</script>

And now when I click on the button to add a new task... nothing happens. Hmm...

After some tinkering and troubleshooting I realized that the way Svelte knows whether something changes is through a new assignment. So we need to update our code above to the following:

function addTask(){
  tasks = tasks.concat(new Task());
}

I also learnt some interesting things:

Svelte has nice support for sourcemaps so I can look at Svelte code in Chrome Dev Tools. However, I cannot set a break point or use logpoints inside the addTask method.
With the aid of console.log inside addTask and the {@debug tasks} on the Svelte template I could see how the list kept growing but the template was never updated. After fixing the issue, as the list kept growing the {@debug tasks} was executed and logged the updated list of tasks.

<script>
  import {Task} from './Task.js';

  let tasks = [
    new Task("plan some fun trip with Teo"),
    new Task("buy some flowers to my wife"),
    new Task("write an article about Svelte"),
  ];

  function addTask(){
    tasks.push(new Task());
    console.log(tasks); // => this grows everytime
  }
</script>

<!-- this was only executed the first time -->
{@debug tasks}
<ul>
  {#each tasks as task}
    <li>
      <input class="description" type="text" bind:value={task.description} >
      <input class="pomodoros" type="number" bind:value={task.expectedPomodoros}>
    </li>
  {/each}
  <button on:click={addTask}>Add a new task</button>
</ul>

It is very easy to inspect the generated code both within the Svelte Playground or when developing Svelte locally. The output JavaScript produced for pushing a task in the existing array is:

function addTask() {
  tasks.push(new Task());
}

Whereas if we update the value of the tasks variable the following code is generated:

function addTask() {
  $$invalidate(1, tasks = tasks.concat(new Task()));
}

That $$invalidate function must be the one that warns Svelte that data has changed and that the template (the part that depends on tasks) needs to be re-rendered.

Anyhow! Now we can add new tasks:

Removing Existing Tasks

We can add tasks, so we should also be able to remove tasks whenever we change our priorities. In order to do that, we add a new button for each task:

<ul>
  {#each tasks as task}
    <li>
      <input class="description" type="text" bind:value={task.description}>
      <input class="pomodoros" type="number" bind:value={task.expectedPomodoros}>
      <!-- NEW STUFF -->
      <button on:click={() => removeTask(task)}>X</button>
      <!-- END NEW STUFF -->
    </li>
  {/each}
  <button on:click={addTask}>Add a new task</button>
</ul>

And create a new removeTask method to perform the actual removing:

function removeTask(task){
  const index = tasks.indexOf(task);
  tasks = [...tasks.slice(0, index), ...tasks.slice(index+1)];
}

JavaScript should really have an array.prototype.remove method... FizzBuzz it, let's do it (one should never, ever do this at home or work. Only on hobby projects with zero stakes).

I add a new ArrayExtensions.js file with this beautiful thing:

/**
 * Returns a new array without the item passed as an argument
 */
Array.prototype.remove = function (item) {
    const index = this.indexOf(item);
    return [...this.slice(0, index), ...this.slice(index+1)];
}

And update our TaskList.svelte component:

<script>
    import { afterUpdate } from 'svelte';
  import {Task} from './Task.js';
  import './ArrayExtensions.js';

  let tasks = [
    new Task("plan some fun trip with Teo"),
    new Task("buy some flowers to my wife"),
    new Task("write an article about Svelte"),
  ];

  function addTask(){
    tasks = tasks.concat(new Task());
  }
  function removeTask(task){
    // It looks way nicer, doesn't it?
    tasks = tasks.remove(task);
  }
</script>

And now tasks can be removed:

A Slightly Better User Experience Using Svelte Lifecycle Hooks

Wouldn't it be nice if the newly created task description would come into focus when a new task is created? That way the keyboard friendly user of our app could press Enter on the Add new task button, type away the task and estimation, press Enter again on the button, and so forth. Maximum productivity.

In order to be able to add this type of functionality we need to know when a new input is added to the DOM, and have that new input get the focus. After taking a quick look at the Svelte docs I found that you can hook into the lifecycle of a component to solve this sort of things. The afterUpdate lifecycle hook is the one that's executed after the DOM has been updated with new data, so that sounds like a good candidate:

<script>
    import { afterUpdate } from 'svelte';
  import {Task} from './Task.js';
  import './ArrayExtensions.js';

  // Rest of the code has been collapsed for simplicity's sake

  afterUpdate(() => {
    console.log('Hello! I was updated!'):
  });
</script>

If we take a look at our app right now we'll see how every time the component is rendered we get that message printed in the console. Now we need to get a reference to that input element that gets created. Svelte has a special directive that may help with that bind:this.

You can use it like this:

<script>
    import { afterUpdate } from 'svelte';
  import {Task} from './Task.js';
  import './ArrayExtensions.js';
  let lastInput;

  // rest of the code collapsed for simplicity's sake
</script>

<style>
/** styles collapsed **/
</style>


<ul>
  {#each tasks as task}
    <li>
      <input class="description" type="text" bind:value={task.description} 
       bind:this={lastInput}>  <!-- THIS IS NEW! -->
      <input class="pomodoros" type="number" bind:value={task.expectedPomodoros}>
      <button on:click={() => removeTask(task)}>X</button>
    </li>
  {/each}
  <button on:click={addTask}>Add a new task</button>
</ul>

And now that we have a reference to that input we can use it to make it come into focus when we create a new task:

<script>
    import { afterUpdate } from 'svelte';
  import {Task} from './Task.js';
  import './ArrayExtensions.js';
  let taskAddedPendingFocus = false;
  let lastInput;

  let tasks = [
    new Task("plan some fun trip with Teo"),
    new Task("buy some flowers to my wife"),
    new Task("write an article about Svelte"),
  ];

  function addTask(){
    tasks = tasks.concat(new Task());
    taskAddedPendingFocus = true;
  }
  function removeTask(task){
    tasks = tasks.remove(task);
  }
  function focusNewTask(){
    if (taskAddedPendingFocus && lastInput) {
      lastInput.focus();
      taskAddedPendingFocus = false;
    }
  }

  afterUpdate(focusNewTask);
</script>

This solution seems quite brittle for several reasons, like the fact that I have an nagging feeling that I can only get away with it because the newly created input is the last input in the DOM. But it will work for now. Sometimes the right solution is the working solution. We shall pay our accrued technical debt soon enough.

For the time being, enjoy with a nice focus behavior:

Setting a Goal of Pomodoros for the Day and Keeping it

The final thing that we want to add to support the pomodoro startup flow is to have a way for the user to understand how many pomodoros they're comitting themselves to complete. A quick way to do that is to just sum all the estimated pomodoros for all tasks and show them to the user.

This is a perfect feature because it's simple and it lets us experiment with the reactivity system in Svelte.

In Svelte, you can create properties that are computed from other existing properties. In this case, we need a new property that is the sum all of current pomodoros for all tasks. Such a property could look like this:

<script>
    import { afterUpdate } from 'svelte';
  import {Task} from './Task.js';
  import './ArrayExtensions.js';
  let taskAddedPendingFocus = false;
  let lastInput;
  let tasks = [
    new Task("plan some fun trip with Teo"),
    new Task("buy some flowers to my wife"),
    new Task("write an article about Svelte"),
  ];
  $: allExpectedPomodoros = tasks.reduce((acc , t) => acc + t.expectedPomodoros, 0);

  /** rest of the code omitted for the sake of clarity. **/
</script>

The $: syntax tells Svelte that the allExpectedPomodoros property is a reactive value, and that it needs to be updated any time tasks is updated (The funny thing is that this is actual valid syntax in JavaScript which I've never used in my life).

Now we can add it to our markup:

<ul>
  {#each tasks as task}
    <li>
      <input class="description" type="text" bind:value={task.description} bind:this={lastInput}>
      <input class="pomodoros" type="number" bind:value={task.expectedPomodoros}>
      <button on:click={() => removeTask(task)}>X</button>
    </li>
  {/each}
  <button on:click={addTask}>Add a new task</button>
</ul>
<!-- New stuff here -->
<p>
  Today you'll complete {allExpectedPomodoros} pomodoros.
</p>

And we are done!

And What happens When There's no Tasks?

Ok, just one more thing. There's one last detail that'd be nice to have work out. What happens when there are no tasks?

Right now we just show an empty void of nothingness but it'd be nice to show some encouraging message to our users to have them start the day with strength. Let's do that!

We can take advantage of Svelte's {#if} and {:else} blocks to show a message when there are no tasks yet. For example:

{#if tasks.length === 0}
  <p>You haven't added any tasks yet. You can do it! Add new tasks and start kicking some butt!</p>
{:else}
  <ul>
    {#each tasks as task}
      <li>
        <input class="description" type="text" bind:value={task.description} bind:this={lastInput}>
        <input class="pomodoros" type="number" bind:value={task.expectedPomodoros}>
        <button on:click={() => removeTask(task)}>X</button>
      </li>
    {/each}
  </ul>
{/if}

<button on:click={addTask}>Add a new task</button>

{#if tasks.length != 0}
  <p>
    Today you'll complete {allExpectedPomodoros} pomodoros.
  </p>
{/if}

Looking for the source code for the pomodoro app?

Look no more! You can find it on GitHub ready to be cloned and enjoyed, or on the Svelte REPL where you can tinker with it right away.

Some More Reflections So Far

In general, working with Svelte has been quite pleasant. Here are some more thoughts to add to the ones from the last article:

In general things still work mostly as I expect them to work and it is easy to troubleshoot and recover from errors. I was surprised that array.push didn't trigger a component render but after diving into the issue I understand that it is much easier for the compiler to understand that changes happen on assignments. And it does make a lot of sense, it easier to think of having to update the values of things instead of learning a new API (like setState for instance).
It was a pity that I couldn't put breakpoints or logpoints in the svelte code in Chrome Dev Tools. I really expected that to work but perhaps it requires some additional setup that I am unaware of. It does feel like something that should be supported in a dev environment out of the box.
It is really cool that the Svelte tutorials and the playground provide access to the code generated by the Svelte compiler. It was fun to take a peek into the generated code and realize that the array.push wasn't generating an invalidating call. (This also shows that Svelte does have a runtime, albeit small, even though people often market it as completely disappearing once your app has been generated).
The syntax for handling events, binding elements to data, the if and else blocks, it was non standard but quite reminiscent at times, and in general easy to learn. (Although that may be because of the experience I have with many other frameworks that implement similar capabilities with slightly different syntax)
The $: reactive values are really easy to implement and render in your component.

And we have come to an end for today. Hope you enjoyed this article! Take care!