Bumps [typescript](https://github.com/Microsoft/TypeScript) from 3.4.4 to 3.4.5.
<details>
<summary>Commits</summary>

- See full diff in [compare view](https://github.com/Microsoft/TypeScript/commits)
</details>
<br />

[![Dependabot compatibility score](https://api.dependabot.com/badges/compatibility_score?dependency-name=typescript&package-manager=npm_and_yarn&previous-version=3.4.4&new-version=3.4.5)](https://dependabot.com/compatibility-score.html?dependency-name=typescript&package-manager=npm_and_yarn&previous-version=3.4.4&new-version=3.4.5)

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.

[//]: # (dependabot-automerge-start)
If all status checks pass Dependabot will automatically merge this pull request.

[//]: # (dependabot-automerge-end)

---

<details>
<summary>Dependabot commands and options</summary>
<br />

You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot ignore this [patch|minor|major] version` will close this PR and stop Dependabot creating any more for this minor/major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
- `@dependabot use these labels` will set the current labels as the default for future PRs for this repo and language
- `@dependabot use these reviewers` will set the current reviewers as the default for future PRs for this repo and language
- `@dependabot use these assignees` will set the current assignees as the default for future PRs for this repo and language
- `@dependabot use this milestone` will set the current milestone as the default for future PRs for this repo and language
- `@dependabot badge me` will comment on this PR with code to add a "Dependabot enabled" badge to your readme

Additionally, you can set the following in your Dependabot [dashboard](https://app.dependabot.com):
- Update frequency (including time of day and day of week)
- Automerge options (never/patch/minor, and dev/runtime dependencies)
- Pull request limits (per update run and/or open at any time)
- Out-of-range updates (receive only lockfile updates, if desired)
- Security updates (receive only security updates, if desired)

Finally, you can contact us by mentioning @dependabot.

</details>

dependencies

chore(deps-dev): bump typescript from 3.4.4 to 3.4.5

Bumps [@types/next](https://github.com/DefinitelyTyped/DefinitelyTyped/tree/HEAD/types/next) from 8.0.1 to 8.0.4.
<details>
<summary>Commits</summary>

- See full diff in [compare view](https://github.com/DefinitelyTyped/DefinitelyTyped/commits/HEAD/types/next)
</details>
<br />

[![Dependabot compatibility score](https://api.dependabot.com/badges/compatibility_score?dependency-name=@types/next&package-manager=npm_and_yarn&previous-version=8.0.1&new-version=8.0.4)](https://dependabot.com/compatibility-score.html?dependency-name=@types/next&package-manager=npm_and_yarn&previous-version=8.0.1&new-version=8.0.4)

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`.

[//]: # (dependabot-automerge-start)
If all status checks pass Dependabot will automatically merge this pull request.

[//]: # (dependabot-automerge-end)

---

<details>
<summary>Dependabot commands and options</summary>
<br />

You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot ignore this [patch|minor|major] version` will close this PR and stop Dependabot creating any more for this minor/major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
- `@dependabot use these labels` will set the current labels as the default for future PRs for this repo and language
- `@dependabot use these reviewers` will set the current reviewers as the default for future PRs for this repo and language
- `@dependabot use these assignees` will set the current assignees as the default for future PRs for this repo and language
- `@dependabot use this milestone` will set the current milestone as the default for future PRs for this repo and language
- `@dependabot badge me` will comment on this PR with code to add a "Dependabot enabled" badge to your readme

Additionally, you can set the following in your Dependabot [dashboard](https://app.dependabot.com):
- Update frequency (including time of day and day of week)
- Automerge options (never/patch/minor, and dev/runtime dependencies)
- Pull request limits (per update run and/or open at any time)
- Out-of-range updates (receive only lockfile updates, if desired)
- Security updates (receive only security updates, if desired)

Finally, you can contact us by mentioning @dependabot.

</details>

chore(deps-dev): bump @types/next from 8.0.1 to 8.0.4

Unlike other methods that force fit change from the get-go, Kanban is about evolution, not revolution. It hinges on the fundamental truth that you can’t get where you want to go without first knowing where you are.
Kanban is similar to Scrum, in that it helps teams release software early and often. However, Kanban gives more flexibility in terms of planning and execution. Instead of working in time-based sprints, work is continuously delivered in Kanban, and your team pulls single pieces of work from the backlog, and then moves them to done.

### Concepts

#### Visualize the workflow
In short, you should be able to, at any time, look at your overall workflow, be able to determine quickly what you should work on next, have visual cues for priority and time to complete, and that system should be easy to add, remove, and re-organize. The main form of visualization is the Kanban board.

#### Limit the work-in-progress
In Kanban systems the work-in-progress (WIP) at each state in the workflow is limited and new work is "pulled" into when there is available capacity within the local WIP limit.

#### Manage the flow
The flow of work items through each state in the workflow should be monitored and reported - often referred to as Measuring Flow. By flow we mean movement. We are interested in the speed of movement and the smoothness of that movement. Ideally we want fast smooth flow. Fast smooth flow means our system is both creating value quickly, which is minimizing risk and avoiding (opportunity) cost of delay, and is also doing so in a predictable fashion.

#### Make the work explicit
Until the mechanism of software development or IT operations process is made explicit it is often hard or impossible to hold a discussion about improving it. Without an explicit understanding of how things work and how work is actually done, any discussion of problems tends to be emotional, anecdotal and subjective. With an explicit understanding it is possible to move to a more rational, empirical, objective discussion of issues. This is more likely to facilitate consensus around improvement suggestions.

#### Implement feedback loops
An evolutionary process cannot work without feedback loops. The purpose of feedback loops is to be able to compare expected outcomes with actual outcomes and make adjustments. Specifically, we want to make process and policy adjustments as a result of the feedback and understanding the current outcomes in comparison with our expectations or desires.

#### Improve and evolve
It is the WIP limit that ultimately stimulates conversations about process problems. Things which impede flow, or introduce perturbations that mean flow is inconsistent or ragged, often result in a challenge to the WIP limit. The team has the option to break the limit, ignore the problem and carry on, or to face up to the issue, discuss it and suggest a change.

When teams have a shared understanding of theories about work, workflow, process, and risk, they are more likely to be able to build a shared comprehension of a problem and suggest improvement actions which can be agreed by consensus


### Metrics

#### Lead time
Lead time is the time taken from when an issue is logged until work is completed on that issue.

#### Cycle time
Cycle time is the time spent working on an issue — typically, the time taken from when work begins on an issue to when work is completed, but also includes any other time spent working on the issue. For example, if an issue is reopened, worked on, and completed again, then the time for this extra work is added to the cycle time.

#### Throughput
In Kanban throughput is mainly used for tracking team's performance. Logically, the objective is to continuously improve it. Throughput is the number of work items that the team is capable to deliver in a given time period, e.g. week, month, provided that they keep a bearable work load.

agile

javascript

kanban

Kanban cheat sheet

Scrum is a management framework for incremental product development using one or more cross-functional, self-organizing teams of about seven people each.
It provides a structure of roles, meetings, rules, and artifacts. Teams are responsible for creating and adapting their processes within this framework.
Scrum uses fixed-length iterations, called Sprints, which are typically 1-2 weeks long (never more than 30 days).
Scrum teams attempt to build a potentially shippable (properly tested) product increment every iteration.

### Concepts

### Roles
There are three core roles in the scrum framework. These core roles are those committed to the project in the scrum process; they are the ones producing the product (objective of the project). They represent the scrum team. Although other roles may be encountered in real projects, scrum does not define any team roles other than those described below.

#### Product owner
The product owner represents the stakeholders and is the voice of the customer, who is accountable for ensuring that the team delivers value to the business. The product owner writes (or has the team write) customer-centric items (typically user stories), ranks and prioritizes them, and adds them to the product backlog. Scrum teams should have one product owner, this role should not be combined with that of the scrum master. The product owner should be on the business side of the project, and should never interfere or interact with team members on the technical aspects of the development task.

#### Scrum master
Scrum is facilitated by a scrum master, who is accountable for removing impediments to the ability of the team to deliver the product goals and deliverables. The scrum master is not a traditional team lead or project manager, but acts as a buffer between the team and any distracting influences. The scrum master ensures that the scrum process is used as intended. The scrum master helps ensure the team follows the agreed scrum processes, often facilitates key sessions, and encourages the team to improve. The role has also been referred to as a team facilitator or servant-leader to reinforce these dual perspectives.

#### Development team
The development team is responsible for delivering potentially shippable increments (PSIs) of product at the end of each sprint (the sprint goal). A team is made up of 3–9 individuals who do the actual work (analyse, design, develop, test, technical communication, document, etc.). Development teams are cross-functional, with all of the skills as a team necessary to create a product increment. The development team in scrum is self-organizing, even though there may be some level of interface with project management offices (PMOs).

### Workflow
A sprint (or iteration) is the basic unit of development in scrum. The sprint is a timeboxed effort; that is, it is restricted to a specific duration. The duration is fixed in advance for each sprint and is normally between one week and one month, with two weeks being the most common.
Each sprint starts with a sprint planning event that aims to define a sprint backlog, identify the work for the sprint, and make an estimated commitment for the sprint goal. Each sprint ends with a sprint review and sprint retrospective, that reviews progress to show to stakeholders and identify lessons and improvements for the next sprints.
Scrum emphasizes working product at the end of the sprint that is really done. In the case of software, this likely includes that the software has been integrated, fully tested, end-user documented, and is potentially shippable.

#### Sprint Planning
During the sprint planning meeting, the product owner describes the highest priority features to the team. The team asks enough questions that they can turn a high-level user story of the product backlog into the more detailed tasks of the sprint backlog.

The product owner doesn't have to describe every item being tracked on the product backlog. A good guideline is for the product owner to come to the sprint planning meeting prepared to talk about two sprint's worth of product backlog items. To make an example really simple, suppose a team always finishes five product backlog items. Their product owner should enter the meeting prepared to talk about the top 10 priorities.

##### Whats the outcome of the Sprint Planning?
There are two defined artifacts that result from a sprint planning meeting:

###### The sprint goal
The sprint goal can be used for quick reporting to those outside the sprint. There are always stakeholders who want to know what the team is working on, but who do not need to hear about each product backlog item (user story) in detail.

###### The sprint backlog
The sprint backlog is the other output of sprint planning. A sprint backlog is a list of the product backlog items the team commits to delivering plus the list of tasks necessary to delivering those product backlog items. Each task on the sprint backlog is also usually estimated.

##### Who attends to the Sprint Planning?
- Product owner
- Scrum master
- Development team

#### Daily scrum
The Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours. This is done by inspecting the work since the last Daily Scrum and forecasting the work that could be done before the next one. The Daily Scrum is held at the same time and place each day to reduce complexity. During the meeting, the Development Team members explain:

- What did I do yesterday that helped the Development Team meet the Sprint Goal?
- What will I do today to help the Development Team meet the Sprint Goal?
- Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

##### What's the outcome of the Daily Scrum?

- An updated scrum board to improve visibility of the progress.
- A list of blockers or impediments that need to be deal with by the Scrum Master.

##### Who attends to the Daily Scrum?
- Scrum master
- Development team

#### Sprint review
A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. This is an informal meeting, not a status meeting, and the presentation of the product increment is intended to elicit feedback and foster collaboration.

##### What's the outcome of the Sprint Review?
- A progress status report
- An update from the product vision and feedback given by the Product Owner and stakeholders

##### Who attends to the Sprint Review?
- All the Scrum Team including the Product Owner
- Stakeholders may attend as well

#### Sprint Retrospective
The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint. The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning.

This is a three-hour time-boxed meeting for one-month sprints. For shorter sprints, the event is usually shorter. The Scrum Master ensures that the event takes place and that attendants understand its purpose. The Scrum Master teaches all to keep it within the time-box. The Scrum Master participates as a peer team member in the meeting from the accountability over the
Scrum process.

##### What's the outcome of the Sprint Retrospective?
- A detailed plan to continuosly improve the work process
- A status report of completed action items in the continous improvement plan since last restrospective

##### Who attends to the Sprint Review?
- The Scrum Master
- The Development Team

### Metrics

#### Sprint burndown

Scrum teams organize development into time-boxed sprints. At the outset of the sprint, the team forecasts how much work they can complete during a sprint. A sprint burndown report then tracks the completion of work throughout the sprint. The x-axis represents time, and the y-axis refers to the amount of work left to complete, measured in either story points or hours. The goal is to have all the forecasted work completed by the end of the sprint.

A team that consistently meets its forecast is a compelling advertisement for agile in their organization. But don't let that tempt you to fudge the numbers by declairing an item complete before it really is. It may look good in the short term, but in the long run only hampers learning and improvement.

![Burndown chart](https://raw.githubusercontent.com/ricardocasares/grow/methodologies/assets/methodologies/burndown_chart.png "Burndown chart")

##### Anti-patterns to watch for

- The team finishes early sprint after sprint because they aren't committing to enough work. 
- The team misses their forecast sprint after sprint becase they're committing to too much work. 
- The burndown line makes steep drops rather than a more gradual burndown because the work hasn't been broken down into granular pieces.
- The product owner adds or changes the scope mid-sprint.

#### Velocity

Velocity is the average amount of work a scrum team completes during a sprint, measured in either story points or hours, and is very useful for forecasting. The product owner can use velocity to predict how quickly a team can work through the backlog, because the report tracks the forecasted and completed work over several iterations–the more iterations, the more accurate the forecast.

Let's say the product owner wants to complete 500 story points in the backlog. We know that the development team generally completes 50 story points per iteration. The product owner can reasonably assume the team will need 10 iterations (give or take) to complete the required work.

It's important to monitor how velocity evolves over time. New teams can expect to see an increase in velocity as the team optimizes relationships and the work process. Existing teams can track their velocity to ensure consistent performance over time, and can confirm that a particular process change made improvements or not. A decrease in average velocity is usually a sign that some part of the team's development process has become inefficient and should be brought up at the next retrospective.

![Velocity report](https://raw.githubusercontent.com/ricardocasares/grow/methodologies/assets/methodologies/velocity_report.png "Velocity report")

##### Anti-patterns to watch for

When velocity is erratic over a long period of time, always revisit the team's estimation practices. During the team's retrospective, ask the following questions:

- Are there unforeseen development challenges we didn't account for when estimating this work? How can we better break down work to uncover some of these challenges?
- Is there outside business pressure pushing the team beyond its limits? Is adherance to development best practices suffering as a result?
- As a team, are we overzealous in forecasting for the sprint? 


### Summary
Scrum’s roles, artifacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.

Scrum does a strong emphasis on cross-functional teams, time-boxed and to-the-point meetings. Team motivation, trust and transparency are key aspects of it.

#### Sources
- [Rational unified process](https://es.wikipedia.org/wiki/Proceso_Unificado_de_Rational)
- [Scrum reference cards](http://scrumreferencecard.com/scrum-reference-card/)
- [The Scrum guide](http://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-us.pdf)
- [Scrum (Software development)](https://en.wikipedia.org/wiki/Scrum_(software_development))
- [Scrum Practitioners Open Questions](https://www.scrum.org/Forums/aft/1292/afpg/2)

scrum

Scrum cheat sheet

I gave a talk last Wednesday in Kraków regarding voice user interfaces with Alexa & Node.js, feel free to check out the [slides](https://slides.com/ricardocasares/voice-user-interfaces-with-amazon-alexa) and [repo](https://github.com/ricardocasares/rolling-with-alexa) for the demo.

alexa

node.js

skill

Voice User Interfaces

Two days have passed since I started building this website on `Next.js` and I'm very surprised about what I have been able to achieve in so little time:

- Server Side Rendering
- Code splitting
- Isolated styles components, as well as just one place to manage global styling
- Theming
- Test driven development with `Jest`
- Incredibly fast and responsive development workflow

We will discuss some of this points in the post and I will discuss others in future posts, but let me first explain you a bit better about how is this site built.

In this [git repository](https://github.com/ricardocasares/analogical) I keep the code for the whole app, and using GitHub as my database, I'm using issues to store the blog posts, which are then retrieved and rendered as HTML. I enjoy writing posts in Markdown, and I'm getting a comments system for free, but I haven't yet implemented this.

So, getting started, `Next.js` is built upon a very simple premise that you might find familiar if you used to build websites in the 90's, and resumes basically to this:

> Your file system is your routing system

Taking this into account, my project structure looks like this:

```
.
├── components
├── config.js
├── lib
├── node_modules
├── package.json
├── pages
├── providers
├── routes.js
├── server.js
├── static
└── yarn.lock
```

But pay especial attention to the `pages` folder, this is actually the only thing `Next.js` enforces to start a new project, you need this folder. Mine looks like the following:

```
.
├──  pages
│   ├── changelog.js
│   ├── index.js
│   ├── photos.js
│   ├── post.js
│   └── work.js
```

This leads to the first point in the top list on this post, server side rendering. Every file inside the `pages` folder is mapped to an `URL` in your app. The only requirement in this file is to export a `React` component. It might be a class extending `React`'s `Component` or as well a stateless component.

Let's check the code inside `index.js`

```jsx
// external
import React from "react";

// internal
import Page from "../components/Page";
import Title from "../components/Title";
import Subtitle from "../components/Subtitle";
import Chart from "../components/Chart";
import { dark } from "../lib/themes";
import { ThemeProvider } from "../providers/Theme";

const Index = () => (
  <ThemeProvider theme={dark}>
    <Page title="analogic.al">
      <section className="intro">
        <Title>Hello!</Title>
        {/*  Omitting the rest of code here for brevity */}
      </section>

      <section className="grid charts">
        <Chart
          title={"Methodologies"}
          data={[
            { label: "Kanban", value: 50 },
            { label: "Scrum", value: 30 },
            { label: "Waterfall", value: 20 }
          ]}
        />
        {/*  Omitting the rest of code here for brevity */}
      </section>
    </Page>
  </ThemeProvider>
);

export default Index;
```

Do not care much about the inner components, but just pay attention to the default export `Index`, which is just a stateless component.

Go ahead and try for yourself!

```shell
npm init
npm install react react-dom next
```

Create a `pages` folder, with an `index.js` file that exports some `React` component:

```jsx
export default () => <h1>Hello world</h1>
```

That's it, run `$(npm bin)/next` from your console, go to your browser, hit `http://localhost:3000/` and you will see a server side rendered home page.

Neat!

### Code splitting

But wait, this leads to the second topic in the list: code splitting. For those who might not know, code splitting is a technique to reduce the amount of code that needs to be delivered to the client in order to render the resource they have requested for.

Simply put, your app might have a blog, a login page and maybe and admin dashboard to manage the posts. We can suppose that users hitting the `/blog` endpoint of your app, are interested primarily in reading your articles, so there is no need for you to deliver code that belongs to the admin dashboard or login page, that's why we split the bundles into chunks containing all necessary code to render just one resource, like the blog, for example.

All of this comes out of the box with `Next.js` by the simple fact that you are organizing your app into pages. So every page already has everything it needs to render itself. When navigating to another page, new chunks belonging to the requested resource will be downloaded on the fly in order to render.

But now, let's imagine that you hit `/login` page, you are probably planning to login and manage your blog posts or comments. `Next.js` is smart enough to let you make predictions about the next resources your users will ask for, so in this case you are able to download them in advance using a nice little feature of the `next/Link` component.

By adding the property `prefetch` to `Link`, `Next.js` will prefetch this page chunk in advance, so in our previous scenario, by the time you finish writing your username and password on the login form and hit the login button, the code needed to render the admin dashboard has probably already been downloaded, providing a seamless experience.

So go ahead and modify your `index.js` file to look like this:

```jsx
import Link from "next/Link";

export default () => <div>
    <h1>Hello world</h1>
    <Link href="/about" prefetch><a>About</a></Link>
</div>;
```

And create the new `about.js` page:

```jsx
import Link from "next/Link";

export default () => <div>
    <h1>About</h1>
    <Link href="/"><a>Back to home</a></Link>
</div>;
```

The `prefetch` function only works in production mode, so this time, run a build using `$(npm bin)/next build` and then `$(npm bin)/next start`, go to your home page, and check the Network tab inside Chrome developer tools when you refresh the index page. Luckily you will see the about page chunk being downloaded before hand.

Now, sitting on the about page, hit refresh, and notice that since we didn't add `prefetch` to the `Link`, the home page chunk will not be downloaded in this case.

That's enough for this post already, but I plan to keep writing about my adventures with `Next.js`, I hope this encourages you a little bit to start experimenting yourself.

Happy hacking!

next.js

server side rendering

Learning Next.js

When a function calls itself until it doesn't. Seriously.

Use it when it feels natural. When you face a problem where it fits nicely, you will most likely recognize the scenario: it will seem like you cannot even come up with an iterative solution. Also, clarity is an important aspect of programming. Other people should be able to read and understand the code you produce.

``` javascript
let countDown = (from) => {
  if (!from) return;
  console.log(from);
  countDown(from - 1);  
}
```


Recursion baby

Our goal is to identify when the constructor was called without the new operator and then invoke the constructor properly. Observe the following code.

``` javascript
function CarPart(name) {
  if(this instanceof CarPart) {
    this.name = name;
  } else {
    return new CarPart(name);
  }
}
```

In this code, we evaluate if the this object is a CarPart and proceed as normal. If the this object is not a CarPart (ie, it's a window object), call the constructor again, this time with the new operator.

Now our constructor works properly with or without the new operator.


Scope safe constructors

Constructor Stealing is to call the Shape constructor from within the Rectangle constructor.

``` javascript
function Shape() {
    this.colors = ['red', 'blue', 'green'];
}

function Rectangle() {
    Shape.call(this);
}
```

The `apply()` and `call()` methods can be used to execute a constructor on the newly created object.


The changelog

Notes and thoughts on software development.