Forem: Tobias Timm

Writing as a developer is like going on a journey

Tobias Timm — Wed, 18 Aug 2021 09:56:09 +0000

Do you often feel the urge to write an excellent blog article, or do you not care about it at all? Your choice doesn't matter here, and it is neither good nor bad.

As a developer, you need to handle a lot of reading, writing technical documentation, and explain to non-technical people how you would approach specific technical solutions. Maybe you can already read it between the line; the keyword I'm looking for is communication.

Communication is critical in the developer's life. So how can you relate this to writing a blog article?
Writing itself can be a joyful experience, where you can express your emotions and creativity in a completely new way. With writing, you can reflect on yourself and experience situations from the perspective of a different person.

Do you want an example?

Think of the last README file you have written. Have you adequately tested it and tried it out, like a person grabbing your GitHub repository? If not, do it!

Sooner or later, you will experience that maybe some critical pieces of information would be helpful or even required to know for your repository, and you forgot to mention them within your README.

Another example? Here we go.

A new junior developer joins your team, and you need to explain how insert your fancy framework here works. To make it easier to memorize it, you should also write it down.

Have you ever tried to explain your beloved framework to starters or non-technical people in an easy way or even write it down for them?

Okay, so writing is an essential skill to learn as a developer, but how can I overcome myself by doing it more often?

If you ask most developers why they don't write more often, the most common answers are:

"I have no time for that."
"I don't like it."
"I don't even know what I should write about."

I have no time for that

I can emphasize myself with that statement. Most of my days are fully packed with work stuff, and if I can finally spare some hours/minutes, they are most often blocked by other topics that I wanted to explore.
Unfortunately, there is no easy answer to loose this situation.
At least I can share some tips/tasks for better handling.

Reprioritize your calendar and check if it is vital that you attend every meeting
Create a blocker for ~30 minutes dedicated to writing
Ask your colleagues for help; for example; they could participate in a meeting instead, take over a particular task, ... .

I don't like it

Writing like every other activity isn't for everyone, which is completely fine, but can you say that you tried it out long enough?
To get a grasp on your emotions and motivation towards writing, set yourself a challenge. Make a week dedicated to writing.

The goal should be a small article about a topic you like. Every day try to write at least for thirty minutes; it doesn't matter if you write some words or can even phrase sentences within the 30 minutes.
You have a ready-to-publish blog article at the end of the week, and you should post it!

It isn't good, or do you think it isn't perfect?
Try not to be too hard on yourself. Small steps are the key to success, and feedback is more than welcome. If you don't want to publish your article, give it to a friend or colleague and talk about it.

So how do you feel after the completion of this task? Happy, excited, stressed, bored? Sort your emotions and try to retake this exercise after 3-4 weeks. If your emotions and feelings haven't changed, you either found a new hobby, or writing isn't your correct fit; it should be something you enjoy, not something you feel like you need to do.

I don't even know what I should write about

There are several creative methods for brainstorming topics you can write about, but for starters, take your current technology stack and start with the simple things.

How to set up a server with technology xyz
Creating a blog with abc
...

This is covered all over the internet

Maybe it is, but does it cover your perspective? I bet not. There is at least one or two things that you would do differently than the other blog post.
It is crucial and significant to share that with the whole world!

Another great way to explore topics is to ask your colleagues or friends. Maybe there are some particular questions nobody has answered before.

tl;dr

I have mentioned several times how vital writing is for me as a developer, and like every other activity, it can be a challenging journey. If you don't like it, try not to force writing on you, it should be something you enjoy doing.
If you like it or haven't tried it out, try it! Don't be picky or too hard on yourself with your first result. Mistakes are allowed, and there is no perfect article/documentation.
To make it easier to start or to get into writing:

Set yourself a goal to write something in a certain amount of time. For example, write a small article by the end of the week.
Pick a topic covered by your daily work. Which framework are you using in your current tech stack? Try to explain how it works under the hood or set up a project with it.
Reserve ~30 minutes a day in writing something. It can be a sentence or even some words.
Present your work by publishing it or sharing it with your family, friend, or colleague by the end of the week. Ask them for some feedback!
Did you feel stressed, happy, excited while doing this? Reflect on your emotions
Redo this exercise in 3-4 weeks and compare the results.

Try to get as much enjoyment out of it as possible and make mistakes. There is no perfect article, and there will never be one.
In mastering writing, you can reflect your technical perspective from different angles, improving your communication skill on several levels.

Share your story

Do you have some tips on motivating yourself for writing, or what difficulties do you occur on your journey? Share your thoughts in the comments!

The New Way of the Developer?

Tobias Timm — Wed, 25 Nov 2020 15:34:19 +0000

Back in the days, most developers have had an engineering background or studied computer science; nowadays, the software developer's role becomes more popular.
New ways to become a developer are approaching on a weekly/monthly basis.

You can attend Bootcamps, be self-taught, do an apprenticeship, study computer science or a combination of several fields, and many more.
The possibilities are endless.

My questions are now:

Are there any significant differences between these developer paths?
Is their mindset on the same page?
Do you need a computer science degree to become the "better" developer?
Is a JavaScript developer coming from a Bootcamp worse than a Java Developer shifting towards JavaScript?

I'm interested in everybody's opinion; please feel free to share your thoughts!

A Journey through your Code

Tobias Timm — Tue, 17 Nov 2020 14:11:26 +0000

Do you know the struggle of onboarding new devs to your codebase? Can you recall again what the most critical files were and the reason for feature x y z?

Documentation is challenging, and also most of the developers don't like writing it. Especially when you onboard new fellows, you will feel the pain of lacking documentation.

Do not worry anymore! CodeTour to the rescue! 👩‍🚒

VS Code extension that allows you to record and playback guided tours of codebases directly within
the editor

Basically, with this extension, you can explain your code intents, mark important places, and create
FAQs within vscode that every one of your team can use as a source of information.

The only downside, it is limited to Visual Studio Code at the moment.

Get started with CodeTour

To get started, open vscode, select extensions and search for CodeTour. You can also install it via the marketplace page.

After installation, open the command palette and search for Record Tour.

The next step is giving the recording a name.

You can associate a CodeTour to a specific commit, tag, or branch. To keep it simple, we will go with None.

You can see in the bottom left corner of your screen a CodeTour section now.

Recording our first Tour

To add your first step, navigate to any code-file you want to explain and press the + within the editor's left gutter.

Within the discussion panel, you can explain your intent or add some useful information and hints for your team's other developers.

The editor supports markdown, which is excellent!

Press the Add Step to Tour button to continue.

That's it! You have successfully created the first step to your new Tour.

To expand your first CodeTour, you could add several more steps, navigate between more files, and mark the important stuff.

You could even export the tour file and commit them alongside your codebase.

CodeTour vs. Comments

I like the idea of having tours within my source code to onboard people or explain a bit more in-depth about what I was thinking.

I don't think that they are a proper replacement for code comments or refactoring the code with clear intentions.

Also, this extension is exclusively available for vscode yet. This makes it pretty unusable for everyone working outside of Visual Studio Code.

CodeTours, Documentation, Comments, and the right intentions visualized by your code should all live happily in peace together within your codebase.

Conclusion

If you want to bring your onboarding or feature explaining to the next level, CodeTour is an excellent supporter for that job 😉.

JS/TS development with Sublime Text in 2020

Tobias Timm — Tue, 10 Nov 2020 15:48:56 +0000

For many developers, Visual Studio Code is the standard editor of choice.
Microsoft created something beautiful and fantastic 🦄 ❤️.

If you can remember the days before Code, you should have heard of an editor called Sublime Text.

Sublime Text is there for a reason.
Until now, it is the most performant editor I have ever used. For me, it is on the same level as a good vim config.

Developed by Sublime HQ Pty Ltd, most web developers have used the editor for a long time.

The only downside, you need a license for $80.

So why should you even care about another editor?

To answer that, you should ask yourself:

Am I satisfied with the performance of my editor?
What features am I using daily?
Do I need an editor or an IDE?
...
Am I just curious to try out another editor?

If you can answer most of these questions in favor of Visual Studio Code, you can stop reading 🤓.

Otherwise, I will demonstrate how you can work with Sublime Text 3 for TypeScript/JavaScript development and get most of the Code benefits combined with great performance.

Install

You can install Sublime Text on any operating system easily via their download area

Or if you are on macOS via brew

brew cask install sublime-text

After installing and entering your license key, you are ready to install Package Control.

Package Control

Package Control is the built-in package manager of Sublime. You can install snippets, themes, color-schemes, syntaxes, and extensions through it.
It is not included by default, so you need to activate it explicitly.

You can do this in two ways.

Menu

Open the Tools menu
Select Install Package Control

Command Palette

Open the command palette Win/Linux: ctrl+shift+p, Mac: cmd+shift+p
Type Install Package Control and press enter

Afterward, we are ready to go 🚀!

Language Server Protocol (LSP)

Introduced by Microsoft with Visual Studio Code, the official definition of LSP is:

The Language Server Protocol (LSP) defines the protocol used between an editor or IDE and a language server that provides language features like auto-complete, go to definition, find all references, etc.

We can install a client for the LSP within Sublime itself to use this awesome feature.

Open your command palette type Package Control: Install Package and press enter
Type LSP and select the first upcoming result

The LSP is installed now successfully!

To have everything in place for JS/TS web development we also need to install these extensions

LSP-css
LSP-html
LSP-json
LSP-typescript
TypeScript Syntax
JSCustom (only if you plan to use react)

Your Sublime Text is capable of using the awesome auto-complete of the LSP now 🎉.

Problems with the `PATH`

I'm using volta to manage my node versions and the problem that the LSP wasn't picking up my $PATH correctly.

To fix this problem, I could start Sublime Text through the terminal, but someone on GitHub gave me a hint to add.

path+=('/Users/USERNAME/.volta/bin')

to ~/.zprofile / ~/.profile. After a system reboot, the LSP worked perfectly fine when opening a .ts file. You can validate that via the Status Bar

Settings

I've learned the keyboard shortcuts from Visual Studio Code and are also used to the look and feel. In Sublime, you can achieve nearly everything.

To do so, we need to enable some stuff through the configuration.

You can open the settings via the menu or keyboard.
Win/Linux: ctrl+,, Mac: cmd+,

On the left side, you will see the default settings of Sublime, and on the right side, you can override these.

I will share my current configuration with you; most of these settings are self-explaining.


{
  "color_scheme":"Packages/Color Scheme - Default/Mariana.sublime-color-scheme",
  "theme":"Adaptive.sublime-theme",
  "auto_indent":true,
  "auto_match_enabled":true,
  "binary_file_patterns":[
    ".DS_Store",
    "node_modules/",
    "tmp/",
    "*.png",
    "*.psd",
    "*.ai",
    "*.min.js",
    "tmp/",
    "_tmp/"
  ],
  "bold_folder_labels":true,
  "caret_extra_bottom":2,
  "caret_extra_top":2,
  "caret_extra_width":1,
  "caret_style":"phase",
  "extend_env":{
    "PATH":"/usr/local/bin"
  },
  "fade_fold_buttons":false,
  "file_exclude_patterns":[
    ".DS_Store"
  ],
  "folder_exclude_patterns":[
    "build",
    "dist",
    ".git",
    ".awestruct",
    ".sass-cache",
    "_developer-materials",
    "_downloads",
    "_tmp",
    "_specs",
    "_site",
    "_products",
    "_projects"
  ],
  "font_face":"Operator Mono Lig",
  "font_options":"dlig",
  "font_size":14,
  "format_on_save":true,
  "highlight_line":true,
  "highlight_modified_tabs":true,
  "indent_guide_options":[
    "draw_normal",
    "draw_active"
  ],
  "match_brackets":true,
  "match_brackets_angle":true,
  "match_brackets_braces":true,
  "match_brackets_content":true,
  "match_brackets_square":true,
  "open_files_in_new_window":false,
  "origami_auto_zoom_on_focus":false,
  "rulers":[
    80,
    100,
    120
  ],
  "save_on_focus_lost":true,
  "scroll_past_end":true,
  "wide_caret":false,
  "word_wrap":false,
  "translate_tabs_to_spaces":true,
  "tab_size":2,
  "trim_trailing_white_space_on_save":false,
  "use_simple_full_screen":false,
  "show_rel_path":true,
  "only_show_lsp_completions":true,
  "show_encoding":true,
  "show_line_endings":true,
  "find_selected_text":true
}

With these settings, Sublime Text should look a lot more Code-like.

Keymap

The next thing to configure is the keyboard shortcuts.
You can open the keymap preferences via Command Palette or Menu.

Like before, I will share with you my current adaptions. If you are fine with the default Sublime keymap, you don't need this. My keymap will make Sublime feel more like a Visual Studio Code.

[
  { "keys": ["tab"], "command": "expand_abbreviation_by_tab", "context":
    [
      { "operand": "source.js", "operator": "equal", "match_all": true, "key": "selector" },
      { "match_all": true, "key": "selection_empty" },
      { "operator": "equal", "operand": false, "match_all": true, "key": "has_next_field" },
      { "operand": false, "operator": "equal", "match_all": true, "key": "auto_complete_visible" },
      { "match_all": true, "key": "is_abbreviation" }
    ]
  },
  { "keys": ["super+b"], "command": "toggle_side_bar"},  
  { "keys": ["ctrl+shift+k"]},
  { "keys": ["super+shift+k"], "command": "run_macro_file", "args": {"file": "res://Packages/Default/Delete Line.sublime-macro"} },  
  { "keys": ["ctrl+r"], "command": "prompt_select_workspace" },
  { "keys": ["super+ctrl+p"]},
  { "keys": ["ctrl+shift+up"]},
  { "keys": ["ctrl+shift+down"]},
  { "keys": ["super+alt+up"], "command": "select_lines", "args": {"forward": false} },
  { "keys": ["super+alt+down"], "command": "select_lines", "args": {"forward": true} },
  { "keys": ["ctrl+super+up"] },
  { "keys": ["ctrl+super+down"]},
  { "keys": ["alt+up"], "command": "swap_line_up" },
  { "keys": ["alt+down"], "command": "swap_line_down" },
  { "keys": ["ctrl+0"]},
  { "keys": ["super+shift+e"], "command": "focus_side_bar" },
  { "keys": ["shift+f10"], "command": "contextmenu" },
  { "keys": ["super+ctrl+a"], "command": "alignment" },
  { "keys": ["super+shift+ctrl+d"], "command": "dash_doc"},
  { "keys": ["super+."], "command": "lsp_code_actions"},
  { "keys": ["f2"], "command": "lsp_symbol_rename" },
  { "keys": ["f12"], "command": "lsp_symbol_definition" },
  { "keys": ["super+option+r"], "command": "lsp_document_symbols" },
  { "keys": ["super+option+h"], "command": "lsp_hover"},
  { "keys": ["super+ctrl+l"], "command": "split_selection_into_lines" },
  { "keys": ["super+shift+l"], "command": "find_all_under" },
  { "keys": ["super+shift+r"], "command": "reveal_in_side_bar" },
]

Git

Visual Studio Code has a great interface for all interactions with git. Sublime has some custom packages for that, but the best way to integrate a similar experience is in installing Sublime Merge. It integrates seamlessly into Sublime Text, and for now, you can use it for an unlimited time for free (only if you can live without a dark theme 🙈).

Extensions to mention

We are nearly finished with setting up Sublime Text. I've some extra extensions to make the editor more awesome.

A File Icon
BracketHighlighter
DashDoc (only useful if you are using Dash)
Emmet
GitGutter
Gutter Color
HTML5
JSPrettier
MarkdownPreview
SCSS
SideBarEnhancements
SublimeLinter
SublimeLinter-eslint
SublimeLinter-stylelint

Themes

There are many awesome themes for Sublime like ayu, One Dark, Monokai, Spacegray, but unfortunately, you will not get all of the Visual Studio Code themes.

This was a huge bummer for me because I like my personal created Code themes, so I've created a package that can convert any Code theme for Sublime.

https://github.com/tobiastimm/code-theme-converter

Conclusion

With the LSP's introduction and adaption, you can enhance a lot of other editors with the underlying power of Visual Studio Code. Like with the Sublime-LSP, there is a similar approach for vim/NeoVim. I really love Sublime, and despite the lack of some features, I love the overall performance. It has everything I need for my daily development.

Like with everything, pick the editor that best suits your needs!

I hope this article gives you some new insights on how to setup Sublime in 2020.

Convert any Visual Studio Code Theme to Sublime Text 3 or IntelliJ IDEA

Tobias Timm — Sat, 11 Apr 2020 10:45:07 +0000

Today I wanted to share my work in progress open-source project code-theme-converter.

Working with Visual Studio Code is a daily routine. Still, there are moments where I prefer to use other editors like Sublime Text 3 or WebStorm.

Opening these editors without using my themes was a huge bummer for me.
To solve this problem, I've created this package to "easily" convert themes to Sublime Text 3 or IDEA IDE's.

Currently supported is only converting a theme to a Sublime color scheme, with more to come soon.

Onboard your codebase with CodeTour

Tobias Timm — Tue, 31 Mar 2020 15:29:12 +0000

While browsing through my GitHub feed yesterday, I discovered a kind of new Visual Studio Code extension called CodeTour.

Curious what this extension is about, I looked at their corresponding marketplace page.

VS Code extension that allows you to record and playback guided tours of codebases, directly within the editor

So basically, with this extension, you can explain your code intents, mark essential places, and create FAQs within vscode that every one of your team can use as a source of information.

The biggest downside, it is limited to Visual Studio Code at the moment.

Get started with CodeTour

To get started, open vscode, select extensions and search for CodeTour. You can also install it via the marketplace page.

After installation, open the command palette and search for Record Tour.

The next step is giving the recording a name.

You can associate a CodeTour to a specific commit, tag, or branch. To keep it simple, we will go with None.

You can see in the bottom left corner of your screen a CodeTour section now.

Recording our first Tour

To add your first step, navigate to any code-file you want to explain and press the + within the left gutter of the editor.

Within the discussion panel, you can explain your intent or add some useful information and hints for the other developers of your team.

The editor supports markdown, which is excellent!

Press the Add Step to Tour button to continue.

That's it! You have successfully created the first step to your new Tour.

To expand your first CodeTour, you could add several more steps, navigate between more files, and mark the important stuff.

You could even export the tour file and commit them alongside your codebase.

CodeTour vs. Comments

I like the idea of having tours within my source code to onboard people or explain a bit more in-depth about what I was thinking.

But, I don't think that they are a proper replacement for code comments or refactoring the code with clear intentions.

Also, the fact that this extension is only available for vscode yet makes it pretty useless for everyone working outside of Visual Studio Code.

CodeTours, Documentation, Comments, and the right intentions visualized by your code should all life happily in peace together within your codebase.

Conclusion

If you want to bring your onboarding or feature explaining to the next level, CodeTour is an excellent supporter for that job 😉.

Property-based testing with React and fast-check

Tobias Timm — Wed, 25 Mar 2020 18:12:14 +0000

Property-based testing is quite a popular testing method in the functional world. Mainly introduced by QuickCheck in Haskell, it targets all the scope covered by example-based testing: from unit tests to integration tests.

If you have never heard anything about property-based testing or QuickCheck, don't worry, I've got you covered 😉.

Like the name is intending, this testing philosophy is all about properties.

It checks that a system under test abides by a property. Property can be seen as a trait you expect to see in your output, given the inputs. It does not have to be the expected result itself, and most of the time, it will not be.
fast-check documentation

Our example application

To demonstrate what the benefits are and why you should also consider this testing method, let's assume that we have the following react application written in TypeScript.

In this example, we will use fast-check, a framework for this testing method.

Our application is a pixel to rem converter. The purpose is to enter a pixel value, which is converted to the corresponding rem value, assuming that the base font size is 16px.

RemConverter.tsx

import React, { FC, useState, FormEvent } from 'react'

interface Props {}

const RemConverter: FC<Props> = () => {
  const [baseFontSize] = useState(16)
  const [px, setPx] = useState(baseFontSize)
  const [rem, setRem] = useState(px2Rem(px, baseFontSize))

  const convert = (e: FormEvent) => {
    e.preventDefault()
    setRem(px2Rem(px, baseFontSize))
  }

  return (
    <div>
      <form onSubmit={convert}>
        <h6>Base font-size: {baseFontSize}</h6>

        <div>
          <label>PX</label>
          <input
            data-testId="px"
            value={px}
            onChange={e => setPx(parseInt(e.target.value, 10))}
          />
        </div>

        <div>
          <label>REM</label>
          <input data-testId="rem" value={rem} disabled />
        </div>

        <button type="submit">Convert</button>
      </form>
    </div>
  )
}

export function px2Rem(px: number, baseFontSize: number) {
  return px / baseFontSize
}

export default RemConverter

Our <RemConverter /> is a functional component that expects an input for the pixel value and outputs the corresponding rem in another input. Nothing to fancy yet.

Getting into testing

To begin our testing adventure, we will write a regular integration test with @testing-library/react.

So what do we want to test here?

Scenario: We want to enter a pixel value of 32 and press on the Convert button. The correct rem value of 2 is displayed.

RemConverter.test.tsx

import React from 'react'
import { cleanup, render, fireEvent } from '@testing-library/react'
import RemConverter from '../RemConverter'

afterEach(cleanup)

describe('<RemConverter />', () => {
  it('renders', () => {
    expect(render(<RemConverter />)).toBeDefined()
  })

  it('should convert px to the right rem value', async () => {
    const { getByTestId, getByText } = render(<RemConverter />)
    fireEvent.change(getByTestId('px'), {
      target: { value: '32' },
    })
    fireEvent.click(getByText('Convert'))
    expect((getByTestId('rem') as HTMLInputElement).value).toBe('2')
  })

})

Above is an easy and simple test to validate our scenario and prove that it is working.

Now you should start thinking 🤔

Did I cover all the possible values?
What happens if I press the button multiple times?
...

If you go the TDD way, you should have thought about things like that beforehand, but I don't want to get into that direction with the article.

We could start creating a list of possible values with it.each, but this is where property-based testing can help us.

QuickCheck in Haskell, for example, creates n-amount of property-values to prove that your function is working.

fast-check, like said before, is a library for that written in TypeScript.

So let's rewrite our test with fast-check.

Testing with `fast-check`

To start writing tests with fast-check and jest, all you need to do is import it.

import fc from 'fast-check'

Afterward, we can use specific features to generate arguments.

Our test would look like this:

import React from 'react'
import { cleanup, render, fireEvent } from '@testing-library/react'
import fc from 'fast-check'
import RemConverter from '../RemConverter'

afterEach(cleanup)

describe('<RemConverter />', () => {
  it('renders', () => {
    expect(render(<RemConverter />)).toBeDefined()
  })

  it('should convert px to the right value with fc', async () => {
    const { getByTestId, getByText } = render(<RemConverter />)
    fc.assert(
      fc.property(fc.nat(), fc.constant(16), (px, baseFontSize) => {
        fireEvent.change(getByTestId('px'), {
          target: { value: `${px}` },
        })
        fireEvent.click(getByText('Convert'))
        expect((getByTestId('rem') as HTMLInputElement).value).toBe(
          `${px / baseFontSize}`,
        )
      }),
    )
  })
})

Quite different, doesn't it?

The most important part is

 fc.assert(
      fc.property(fc.nat(), fc.constant(16), (px, baseFontSize) => {
        fireEvent.change(getByTestId('px'), {
          target: { value: `${px}` },
        })
        fireEvent.click(getByText('Convert'))
        expect((getByTestId('rem') as HTMLInputElement).value).toBe(
          `${px / baseFontSize}`,
        )
      }),
    )

We will go through it step by step.

First of all, we tell fast-check with fc.assert to run something with automated inputs.

fc.property defines that property. The first argument is fc.nat() that represents a natural number. The second argument is our base font size served with the constant 16.

Last but not least, the callback function is containing the automatically created inputs.

Within this callback function, we include our previous test using the given parameters.

That's it 🎉.

If we run our test with jest now, fast-check generates number inputs for us.

How can I reproduce my test, if something goes wrong?
Whenever fast-check detects a problem, it will print an error message containing the settings required to replay the very same test.

Property failed after 1 tests
{ seed: -862097471, path: "0:0", endOnFailure: true }
Counterexample: [0,16]
Shrunk 1 time(s)
Got error: Error: Found multiple elements by: [data-testid="px"]

Adding the seed and path parameter will replay the test, starting with the latest failing case.

   fc.assert(
      fc.property(fc.nat(), fc.constant(16), (px, baseFontSize) => {
        fireEvent.change(getByTestId("px"), {
          target: { value: `${px}` }
        });
        fireEvent.click(getByText("Convert"));
        expect((getByTestId("rem") as HTMLInputElement).value).toBe(
          `${px / baseFontSize}`
        );
      }),
      {
        // seed and path taken from the error message
        seed: -862097471,
        path: "0:0"
      }
    );
  });

Conclusion

This is only a simple example of what you can do with the power of property-based testing and fast-check.

You can generate objects, strings, numbers, complex data structures, and much more awesome stuff.

I would recommend everybody to look into fast-check because it can automate and enhance many of your tests with generated arguments.

For further reading and many more examples, please visit the fast-check website.

The example application can be found on CodeSandbox and GitHub

Web development with Windows 10

Tobias Timm — Sat, 21 Mar 2020 16:23:59 +0000

I'm writing this post because every time I switched on my windows machine and felt the urge to code, something was missing.

I'm used to macOS and Linux systems like Arch, Ubuntu, so things like a proper terminal, a package manager, bash, zsh, brew, docker, ... are the universal tools I need.

On Windows, I needed to deal with PowerShell, strange syntax compared to POSIX, no good package managers, weird git installations, and many more.

Web development felt like a huge bummer.

Maybe you are thinking now: "So why are you on Windows anyway if you don't like it?".

It is easy to answer that question. I'm also a gamer 🎮 , and despite all the improvements, Windows is still the king for gaming.

So I'm used to switching between environments, but there are moments when you don't want to change because you are just too lazy 😴.

WSL to the rescue ⛑

When you have never heard of WSL, don't worry. WSL or Windows Subsystem for Linux is a compatibility layer for running Linux binaries natively on Windows 10.

So, in short, you have a lightweight Ubuntu within your Windows system that can talk and interact with each other.

If you are developing with Visual Studio Code, for example, we will make use of that functionality to be in a Linux world with all the benefits and still have Windows as our primary operating system. More about that later.

Sounds cool.

Enable WSL

To get started with WSL, you need to enable it first.

Open a PowerShell terminal in administrator mode and type.

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

Afterward, restart your computer if prompted.

For reference, you can visit the official windows docs

Choose a Linux Distribution

Next, we choose a Linux distribution for WSL.

Just open the Microsoft Store and search for Ubuntu.

On the distro page, select Get and wait till you can Launch it.

Important: You must launch the distro once before you can get started with WSL.

A terminal should pop up, where you create your first Linux user account.

If you elevate a process using sudo, you will need to enter your password, so make sure you choose a password you can easily remember!

Now we are ready to go! 🎉

Enhance WSL with the new Windows Terminal

The built-in terminal of Windows isn't wrong, but if you are used to iTerm, hyper, or any other terminal emulator, it isn't that good.

To get the new terminal by Microsoft, search for Windows Terminal in the Microsoft Store

After launching, you should see something like

If you still encounter Powershell as your default terminal, go to the settings of the terminal (arrow down icon in the header) and search for

      {
        "guid": "{2c4de342-38b7-51cf-b940-2309a097f518}",
        "hidden": false,
        "name": "Ubuntu",
        "source": "Windows.Terminal.Wsl"
      },

Copy that guid and paste it into the defaultProfile setting.

Install `zsh`

This is pretty straight forward. First of all, update your packages with

sudo apt-get update

After that, you can install zsh with

sudo apt-get install zsh

After installing, execute zsh in your terminal and create your preferred settings.

To set zsh as your default shell, just type

chsh -s $(which zsh)

The next time you open a new terminal or tab within your WSL, zsh should be started automatically.

I will not detail this post about how I configured my shell because this is very opinionated and depends on your current needs.

Configure `git`

You usually don't need to configure much in git except your username and email, but I want to use Windows's built-in credential helper.

Make sure that git is installed in your Ubuntu environment.

sudo apt-get install git

Also, install git for Windows (you need it for the credential helper)

If both are installed successfully, go into your shell and type

git config --global credential.helper "/mnt/c/Program\ Files/Git/mingw64/libexec/git-core/git-credential-manager.exe"

If you have installed git for Windows in another directory, you need to change that path

When you clone a repository, which needs HTTP authentication, the Windows Credential Helper should pop-up.

Enable `gpg`

Because I'm a fan of gpg signed commits, we should enable that.

You can install gpg in Ubuntu via

sudo apt-get install gpg

The next step is creating a key; I will forward it to the excellent GitHub documentation about gpg.

If everything is set up, you only need to add a small change within your .zshrc profile because otherwise, you cannot enter the password if you sign something.

export GPG_TTY=$(tty)

To test that gpg is working correctly.

echo "test" | gpg --clearsign

should output something like

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

test
-----BEGIN PGP SIGNATURE-----
....
----------END PGP SIGNATURE-----

The last step is to configure git to use gpg. For that, we need our public key first

gpg --list-keys

This command should print

pub   rsa3072 2020-02-29 [SC] [expires: 2022-02-28]
      YOUR_PUBLIC_KEY
uid           [ultimate] YOUR NAME
sub   rsa3072 2020-02-29 [E] [expires: 2022-02-28]

Copy your public key identifier and type

git config --global user.signingkey YOUR_PUBLIC_KEY

git is signing your commits now via gpg!

Install Visual Studio Code

I use Visual Studio Code as an editor, and luckily with the Remote Extension Pack, it is a real pleasure to work with Windows + WSL.

After installing code and the extension pack, go into your terminal and open a folder via

code .

Visual Studio Code should pop-up and prepare the connection to WSL.

If no errors are popping up, you are good to go.

Code will use WSL everywhere, and you can enjoy your Windows + Linux development experience.

For troubleshooting, I recommend the "Getting Started Guide" of the official WSL extension

Conclusion

I hope this guide helps you set up a serene and productive environment for development on Windows 10.

If you need help or miss something important in this guide, let me know via the comments.

Happy developing! 😊👩‍💻

Forem: Tobias Timm

Writing as a developer is like going on a journey

I have no time for that

I don't like it

I don't even know what I should write about

tl;dr

Share your story

The New Way of the Developer?

A Journey through your Code

Get started with CodeTour

Recording our first Tour

CodeTour vs. Comments

Conclusion

JS/TS development with Sublime Text in 2020

Install

Package Control

Language Server Protocol (LSP)

Problems with the PATH

Settings

Keymap

Git

Extensions to mention

Themes

Conclusion

Convert any Visual Studio Code Theme to Sublime Text 3 or IntelliJ IDEA

Onboard your codebase with CodeTour

Get started with CodeTour

Recording our first Tour

CodeTour vs. Comments

Conclusion

Property-based testing with React and fast-check

Our example application

Getting into testing

Testing with fast-check

Conclusion

Web development with Windows 10

WSL to the rescue ⛑

Enable WSL

Choose a Linux Distribution

Enhance WSL with the new Windows Terminal

Install zsh

Configure git

Enable gpg

Install Visual Studio Code

Conclusion

Problems with the `PATH`

Testing with `fast-check`

Install `zsh`

Configure `git`

Enable `gpg`