DEV Community: Mike

SvelteKit & Prisma - A match made in digital heaven

Mike — Tue, 03 Aug 2021 04:05:42 +0000

Key Takeaways

Most production applications need to persist & retrieve data. Prisma is a pretty genius way to achieve that.
With SvelteKit, you get client & server-side data fetching - the best of both worlds.
This all even works if JavaScript is disabled in the browser.
Template GitHub repo: https://github.com/mikenikles/sveltekit-prisma

What are you going to learn?

We are going to start with a default SvelteKit application. Once initialized, we will learn how to install and configure Prisma before we will use the PrismaClient to perform create, read, update & delete (CRUD) actions against a local SQLite database.

Things you need to know

In order to get the most out of this post, I expect you are aware of the following technologies:

The foundation

Let's start with the basics: A SvelteKit demo app.

I recommend you first create a GitHub, GitLab or Bitbucket project and start a development environment with Gitpod. Alternatively, you can follow along on your local computer.

npm init svelte@next svelte-with-prisma

When prompted, select the following options:

"Which Svelte app template?" SvelteKit demo app
"Use TypeScript?" Yes
"Add ESLint for code linting?" No
"Add Prettier for code formatting?" Yes

When complete, please follow the "Next steps" listed in the terminal to install dependencies and start the SvelteKit demo app.

If you've followed along so far, you can copy & paste the following commands:

cd svelte-with-prisma
npm install
npm run dev -- --open

That's how quickly you get started with SvelteKit. In your browser, you notice the "TODOS" navigation item. If you play with this list, items are persisted on svelte.dev and deleted after a while.

Next, we are going to add Prisma to persist todo items in a local SQLite database.

Add Prisma

Prisma.io states "Prisma helps app developers build faster and make fewer errors with an open source ORM for PostgreSQL, MySQL and SQLite."

From my personal experience, this statement is certainly true. Let's go and experience it for yourself.

Install & initialize Prisma

First things first: npm i -D prisma because, well... without dependencies we won't get very far 😉.

Next, we are going to initialize Prisma. For that, we use npx to execute commands.

npx prisma init

⚠️ This currently overwrites an existing .gitignore file. Keep an eye on 8496.

This creates a prisma directory at the root of the project. In it, you find the schema.prisma file.

At this point, I recommend you install the prisma.prisma VS Code extension. It adds syntax highlighting, formatting, auto-completion, jump-to-definition and linting for .prisma files.

Define the `Todo` model

Open the prisma/schema.prisma file and add the following model definition to the end of the file:

model Todo {
  uid        String  @id @default(cuid())
  created_at DateTime
  text       String
  done       Boolean
}

Psst... How do we know what fields to define? Well, we take a peek at the Todo type definition in src/routes/todos/index.svelte 😉.

Configure a SQLite database

Open the .env file (that file was created by the npx prisma init command earlier). In it, set the DATABASE_URL to "file:./dev.db"

We also have to open the prisma/schema.prisma file to update the datasource.db.provider to sqlite.

Check the reference docs for more details on the above two values and what other databases are supported.

Create the database and tables

We're making great progress! Let's now use the Prisma CLI to create our SQLite database and create a schema based on the Todo model we defined earlier.

It's easy:

npx prisma db push

Give that five seconds ⏳.

I recommend you read through the console output, I find it highly interesting. For one, it gives us a good deal of detail about what's going on. However, it also contains the following output which is one of the reasons I'm mind-blown by Prisma:

✔ Generated Prisma Client (2.28.0) to ./node_modules/@prisma/client

So much goodness! Basically, they use the Todo model to auto-generate a bunch of TypeScript definitions and Javascript code which we are going to import in just a second. In other words, the "Prisma helps app developers build faster and make fewer errors" sentence on the Prisma website is not just some marketing speech, it is truly genius!

Ok, I'm done being a fanboy about it, let's move on and thanks for your patience there with me 😅.

One last thing, please add prisma/dev.db to your .gitignore file since we don't want to commit the dev database to version control.

Use the `PrismaClient` to interact with the database

The SvelteKit demo app nicely encapsulates all API features in the src/routes/todos/_api.ts file. To be more precise, the actual CRUD logic happens at https://api.svelte.dev/todos. We are going to modify the _api.ts file slightly to deal with CRUD right there and use the PrismaClient instead of delegating to a backend API.

Move the Todo type so we can reuse it

First and foremost, let's move the Todo Typescript type. By default, it's defined and used in the src/routes/todos/index.svelte file. However, with the changes we're going to make to the API, we are also going to need that type in the src/routes/todos/_api.ts file.

Cut the Todo type from src/routes/todos/index.svelte
Paste it below the import statements in src/routes/todos/_api.ts, and prefix it with export
Use the following import in the src/routes/todos/index.svelte file: import type { Todo } from "./_api";

Update the API to use Prisma

Open the src/routes/todos/_api.ts file and add the following import:

import { PrismaClient } from '@prisma/client';

Remember? That's the generated code I was so excited about earlier 😀.

Next, we need a new instance of the PrismaClient (add this below the import statements):

const prisma = new PrismaClient();

Moving right along, it's time to update the api method signature to tell Typescript that the data parameter is of type Todo.

export async function api(request: Request<Locals>, resource: string, data?: Todo) {

The following code:

const res = await fetch(`${base}/${resource}`, {
  method: request.method,
  headers: {
    'content-type': 'application/json'
  },
  body: data && JSON.stringify(data)
});

needs to be replaced with this:

let body = {};
let status = 500;
switch (request.method.toUpperCase()) {
  case "DELETE":
    await prisma.todo.delete({
      where: {
        uid: resource.split("/").pop()
      }
    });
    status = 200;
    break;
  case "GET":
    body = await prisma.todo.findMany();
    status = 200;
    break;
  case "PATCH":
    body = await prisma.todo.update({
      data: {
        done: data.done,
        text: data.text
      },
      where: {
        uid: resource.split("/").pop()
      }
    });
    status = 200;
    break;
  case "POST":
    body = await prisma.todo.create({
      data: {
        created_at: new Date(),
        done: false,
        text: data.text,
      }
    });
    status = 201;
    break;
}

We're getting there 💪. In the if statement right below the code we've just added, remove the res.ok && since we no longer have a res variable.

Lastly, change the return statement to the following:

return {
  status,
  body
};

Let's test

Start your SvelteKit demo app with npm run dev and navigate to http://localhost:3000 in your browser. If you use Gitpod, hold CTRL / CMD pressed and click on the http://localhost:3000 URL in the terminal, it'll open a new browser window with the SvelteKit demo app.

Click on the "TODOS" navigation link and add a few todos, rename some, mark others as done.

In a new terminal, open the Prisma Studio with npx prisma studio. The studio opens in a new browser tab. Click on the Todo model and validate that the data matches what you see in the SvelteKit demo app.

Congratulations 🎉!

Bonus - definitely read this

Disable JavaScript in your browser and test the todo list again. This is how the web is supposed to work - without JavaScript!

We used to develop websites like that, then we spent a decade thinking it's a great idea to move everything into JavaScript and thanks to Svelte & SvelteKit, we now once again develop web applications that work the way the web was intended to work.

JavaScript's purpose is to enhance the web experience, not break everything if JavaScript is disabled.

Conclusion

With a few modifications to a default SvelteKit demo app, we managed to configure Prisma to persist todo items. There is of course a lot more you can do with Prisma, and with SvelteKit for that matter. The source code at https://github.com/mikenikles/sveltekit-prisma should get you a long way towards your own web app.

If you found this interesting, you may also like (wow... is this an e-commerce website 😂?!) my current project called Webstone. Webstone is a full-stack web application boilerplate with a CLI to automate tedious tasks like adding new pages, updating the database (of course it uses Prisma 😉). It's in early development, but do hit that star button on GitHub which helps me get motivated to spend more time on the project 🙏.

👋

I said goodbye to local development and so can you

Mike — Wed, 30 Jun 2021 03:18:28 +0000

Key Takeaways

Individual developer efficiency is hard to measure, but directly impacts a company’s bottom line and team morale.
Remote work requires developers to onboard in isolation, a process that was already challenging when teams were co-located.
Onboarding instructions are often outdated, as are automated onboarding scripts because only new hires run them.
www.gitpod.io provides automated, one-off development environments you spin up in the cloud for each task. In seconds, repeatedly, and securely.

What it’s like today
- Open source project onboarding
Meet Alice and Bob
- Set up a new project
- Develop a new feature
- Switch context
- Set up a new computer
- Contribute to open source projects
What’s the catch?
Conclusion

What it’s like today

Whether you recently joined a new team or contributed to an open source project for the first time, I’m quite sure you spent anywhere from an hour to a few days onboarding. If you were lucky, other contributors provided detailed, up-to-date instructions you could follow. Possibly even commands you could copy & paste and watch your development environment set itself up one step at a time. If this is your experience, congratulations on finding such a great and diligent team - tell them what an awesome job they did 🤩!

More often than not though, this is not what an onboarding experience is like.

It is more likely that there are no automated scripts while instructions, if there are any, are slightly outdated or incomplete - leaving you struggling to figure things out on your own. The techlead to the rescue, who then asks you to update the documentation so the next team member who joins does not run into the same issues. Except, the project evolves, and instructions fall behind again. This is no fault of anyone in particular, but simply a fact of life because once a developer sets up their local development environment, there is no need to set it up again when the code changes. Every team member applies incremental changes to their development environment without starting from scratch, leave alone following the onboarding documentation.

This process is costly, both in terms of time and team morale. The larger your team, the more time is lost on setting up development environments and keeping them maintained. At the same time, I don’t know anyone who enjoys reading outdated documentation. Feeling helpless on the first day working on a new project is certainly not a great way to get started 😕.

Open source project onboarding

In addition, there is a cost that applies to open source projects that is almost impossible to measure: the % of people who would like to contribute to a project, but give up because getting started is too complex or interferes with their other projects in their local environment!

To illustrate this with an example, imagine you usually work with Java 8 and want to contribute to two open source projects. Project A requires Java 7, while project B only runs with Java 11. In order for you to contribute to these projects, you need to install a Java version manager and remember to switch Java version every time you change the project you work on.
The exact same applies to databases (no need to install MySQL, MongoDB, Postgres, etc. locally), operating system libraries, anything you currently install locally.

Let’s look at a day in the life of two developers and see how cloud-based development environments simplify workflows significantly.

Meet Alice and Bob

Bob is like most of us, he works on a desktop or laptop where he installs development tools, clones git repositories and installs dependencies for the projects he works on. He may or may not have had a great onboarding experience 😉. Once every so often, Bob is required to upgrade his tools and dependencies, a task he dreads because upgrading the version of an installed programming language may impact projects that are not compatible with that newer version. With every new version he installs, his cognitive load increases as he needs to remember to switch to the correct version based on the project he works on. Bob is very, very careful in the way he treats his computer because he really doesn’t want it to break… Just imagine setting everything up again from scratch 😱.

Alice is not like Bob, not anymore! Alice too lived a life like Bob where she carefully set up and maintained her local development environment over the lifetime of her laptop (we will talk about her experience when she gets a new laptop later). However, she has since realized there is a better way not only for herself, but for her entire team and anyone who contributes to their projects.

Alice no longer has any code on her computer, none whatsoever. She does that thanks to cloud-based, ephemeral development environments provided by www.gitpod.io.

Let’s dive in and learn more about Bob and Alice and how you can turn yourself from being a traditional Bob to being a modern, efficient version of Alice 🥰.

Set up a new project

Bob

Bob starts by cloning the source code, then ensures he has the correct runtime versions installed (e.g. Java, Node, .NET) and also makes sure the project supports his operating system.
Once that’s all good, he looks for onboarding instructions and works his way through that, potentially spending up to a few days on this task.

Alice

Alice creates a .gitpod.yml configuration file at the root of her project, then adds start tasks such as the following:

tasks:
  - init: npm install
    command: npm run dev

She also enables Gitpod Prebuilds - telling Gitpod to continuously create new development environments as soon as her project’s source code changes! This significantly reduces the startup time when she or anyone who works on her project needs a development environment.

Develop a new feature

Bob

Bob is very familiar with this workflow, it’s something he does many times a week, possibly even a few times per day.

He starts by making sure his new feature branch is based on the latest code. He does that by first pulling the latest default branch and then creating a feature branch.

Since one of his colleagues may have added a new dependency or changed a required runtime version, Bob needs to ensure he has the latest versions. You know, otherwise he starts the dev server only to be presented with an error message telling him a dependency is missing. You know what I’m talking about 😉.

Then, Bob is ready to shift into feature development mode. Well... after he started the database and dev servers.

Alice

She’s keen to get started right away. Once she looks at the issue on GitHub, GitLab or Bitbucket, she simply clicks the “Gitpod” button*. This opens a new workspace with a feature branch already created, all dependencies installed and the database and dev servers started!

* She gets that by installing the Gitpod browser extension. Alternatively, she could prefix the issue URL with gitpod.io/#<issue-url> to open a new development environment.

Switch context

Imagine this: You’re working on a feature when your team member contacts you, letting you know she needs your review for a production hotfix pull request. Here’s how Bob and Alice handle this situation:

Bob

Hm... 🤔 Bob is a bit hesitant. He has a bunch of code changes that are not ready to be committed, he also removed a dependency that is no longer needed thanks to his feature - yay! The timing to review a pull request is less than ideal.

He stashes his changes, pulls the PR branch and switches to it. Since he removed a dependency in his feature branch, he needs to install that again because the production hotfix PR still requires it.

Time to start the dev server and review the hotfix. Looks good, LGTM 👍.

To get back to his feature branch and continue development, he first switches back to his branch. Next, Bob needs his stashed files back, then drops that dependency his feature no longer requires and eventually starts the servers.

Alice

Alice’s workflow is no different than when she develops a new feature. She opens a new browser tab, navigates to the pull request and opens a new development environment based on that PR. Within seconds, the environment starts and the database and dev servers already run - ready for Alice’s review.

She can even leave review comments right within VS Code and have them synced with GitHub.

When she’s done with the review, Alice closes the browser tab. This brings her back to her previous development environment where she continues to work on her feature.

Set up a new computer

Bob

Oh boy... where to start?! Ah right, from scratch 😰!

Alice

Alice, well Alice is excited to get a new computer and is up and running as soon as she installs her favourite browser 🚀. Way to go, Alice!

Contribute to open source projects

Remember the example with the three open source projects earlier that use different versions of Java? In Alice’s case, she does not have Java installed locally at all. She starts any open source project in an ephemeral development environment and uses whatever version of Java is configured for that project. She can even contribute to two projects in parallel - if she really wanted to 😛.

What’s the catch?

Well, for the time being you need an internet connection to work like Alice. The good news, it doesn’t have to be high bandwidth since the data exchange between Gitpod and your browser is minimal. A decent latency is all you need for a smooth experience.

If you read this and think “Well, what about X?” please get in touch, I’d love to work with you and set up Gitpod for your project.

Conclusion

Alice & Bob, two not-so-fictional characters living their life as software developers. I used to be a Bob for close to two decades before I found www.gitpod.io which gives me everything Alice has! Want to get a sneak peek? Click the following button to start your first development environment in the cloud (it will open the source file of this blog post):

I’d love to hear your thoughts and feedback, please get in touch 🙏.

Why I Left Google and Joined Gitpod

Mike — Mon, 15 Mar 2021 12:01:59 +0000

tl;dr: After almost three years of working with global enterprises on their digital transformation at Google, I joined Gitpod (www.gitpod.io) to help build the Developer & Community Success team. Gitpod caught my attention in 2019. It is clear to me that ephemeral, cloud-based development environments are going to be the default way of working and I want to be part of the team that shapes the future for millions of developers around the world!

My time at Google

I joined Google Cloud in 2018 after many years of working in the startup world. The main goal for my time there was to learn more about sales since this was one area I hadn't had much experience.
The first day, the first week, who am I kidding... the first two years were overwhelming. I learned new things every single day, attended courses on personal growth, mentorship, DEI (diversity, equity & inclusion), team building, productivity, interviewing, you name it. It felt like a university where I also got paid to partner with global businesses and work on real world challenges, mainly focused on the travel & e-commerce industries. I led internal global communities, presented at conferences and participated in strategic meetings both internally and with customers to deliver cloud migration or application modernization projects.

After two years, I started to work with a very large customer and repetition kicked in, recurring meetings dominated my calendar and my daily tasks were no longer aligned with my personal goals in life. This led me to spend more and more of my spare time pursuing my dreams, taking away time I would have much rather spent with my family.

2020

Without commute and no business travel in 2020, I had a very productive year to focus on my personal interests:

Book #1: Cloud Native Web Development
Book #2: A Smart Guide for Your Career as a Software Engineer
SaaS #1: your-analytics.org
Gitpod article #1: Cloud Based Development - from Dream to Reality
Gitpod article #2: Why I use a cloud-based development environment and how you can too

Book #1, both articles, the SaaS product, and my personal website all relate to Gitpod (www.gitpod.io).

These projects motivated me and were without a doubt a lot of fun. Most importantly, they aligned with my personal goals. I knew I needed to align my day job with something I cared about and believed in. I knew my time at Google was coming to an end.

Who in their right mind would give up a job at a global, well-paid company that repeatedly ranks as the best employer?

Read on to learn why I am that person.

Gitpod - The way we are all going to develop software

It was in mid January when Gitpod reached out to me, based on my InfoQ article I linked to above and my personal advocacy for their product. It had been well over a year since I started to use Gitpod and talk about it publicly. After an initial conversation and some back and forth, we agreed there was a good fit and working together would benefit both Gitpod and myself.

Throughout my career, I developed software but also enjoyed mentoring, writing and sharing my work at meetups, conferences or in articles. At Gitpod, I get to focus on all that - a true win/win. On top of that, we have an opportunity to improve the developer experience for millions of developers around the world - many of them don't know yet how much more efficient they could be 🚀!

Why join Gitpod?

I remember my excitement when jQuery, Bootstrap and React were in their very early days. I had a gut feeling these frontend frameworks would take the world by storm - and they sure did.
About two years ago, I experienced the same with Svelte and Tailwind CSS. They are still in their early days, but make no mistake they only just got started.

When I learned about Gitpod in 2019, my gut feeling was back, even stronger than when I heard of the technologies mentioned above.

So let me leave this here for historians to find 😀:

Automated, ephemeral development environments in the cloud are the way we are all going to develop software in the not too distant future.

Google, Uber, and more recently Shopify all already work like that, when will you start?

So, what is Gitpod?

Please read my article Cloud Based Development - from Dream to Reality to understand why Gitpod exists and what challenges it solves.

In short:

Gitpod provides always ready-to-code development environments.

As a developer, think about all the time you spend setting up a new project or working your way through onboarding documentation. What about switching context when a team member asks you to review their code? Remember the last time you troubleshooted a colleague's issue that "worked on my machine"? How about a message from the team lead telling everyone to migrate to a newer version of Node.js or Java? Let's not even talk about downloading and installing dependencies or database seed scripts that no longer work because the schema changed.

Gitpod eliminates all that.

With Gitpod, you work in an ephemeral development environment for each feature, bug fix or code review. Even better, it all happens in a browser and requires minimal compute power on your laptop. Any and all changes to the development environment setup are reviewed, tested and versioned like all your other code.

Hey, don't take my word for it. Do me favour please 🙏🏻

Open your browser and navigate to your GitHub, GitLab or Bitbucket project.
Prefix the URL with gitpod.io/# end hit Enter.

That's it. That's all it takes to spin up a new environment.

Hold on though, it gets better! We haven't even talked about prebuilt workspaces, custom environment images, or self-hosting Gitpod.

Check out these short screencasts to learn more:

In conclusion

Sometimes in life you have to make decisions that seem contrary to what most people would do - I'm talking about leaving Google. This is one such moment in my life, not the first and likely not the last. It is the right decision at this point in time.

I talked to many people about this decision and once I presented Gitpod, the feedback was unanimous: "Wow, I can't believe how simple that is. Join them, this is exactly what you're good at!"

I have no doubt the future of how we develop software is going to be based in the cloud. The amount of time we waste globally across all local development environments is simply not sustainable going forward. Developer experience is going to become a competitive advantage not only for hiring the best talent, but also to compete by improving productivity and reducing time to market.

Please reach out to me via Twitter @mikenikles or find me in the Gitpod community at https://community.gitpod.io. I would love to dive deeper into Gitpod and work with you to enable the next generation of software development environment for your project & team.

👋

A Svelte component to format numbers

Mike — Sat, 09 Jan 2021 17:09:31 +0000

Photo by Nick Hiller on Unsplash

Let's develop a Svelte component that formats numbers in a human readable way.

Instead of 63476432, the component displays 64M. Here are a few more examples:

6	=>	6
63	=>	63
634	=>	634
6347	=>	6.3K
63476	=>	63K
634764	=>	635K
6347643	=>	6.3M
63476432	=>	63M

It supports different locales as well. Converting 63476432 looks as follows

ko-KR	=>	6348만
zh-TW	=>	6348萬
de-CH	=>	63 Mio.
ar-SA	=>	٦٣ مليون

How it's done

We leverage the Number.prototype.toLocaleString() method (docs). Thanks to that, the Svelte component becomes very basic:

<script>
  export let number;
  export let locale = "en";

  $: formattedNumber = number.toLocaleString(locale, {
    notation: "compact",
    compactDisplay: "short",
  });
</script>

<style>
  span {
    font-variant-numeric: tabular-nums;
  }
</style>

<span>{formattedNumber}</span>

It is important to make sure number is of type Number. If you pass a string, the toLocaleString method will not work as intended.

Typescript

I highly recommend you enable Typescript for your Svelte project (instructions) and refactor the FormattedNumber component as follows:

<script lang="ts">
  export let number: number;
  export let locale: string = "en";

  $: formattedNumber = number.toLocaleString(locale, {
    notation: "compact",
    compactDisplay: "short",
  });
</script>

<style>
  span {
    font-variant-numeric: tabular-nums;
  }
</style>

<span>{formattedNumber}</span>

Voilà, now the Typescript compiler makes sure you pass a Number.

2021 - My Objectives & Key Results

Mike — Sat, 02 Jan 2021 17:21:46 +0000

Photo by 🇻🇪 Jose G. Ortega Castro 🇲🇽 on Unsplash

tl;dr: My personal 2021 OKRs are publicly available.

I briefly touched on Objectives & Key Results (OKRs) in my 2020 - Year in Review blog post. Below, I will dive deeper into what I have planned for 2021.

What is OKR?

The Wikipedia article for OKR defines it as a goal-setting framework for defining and tracking objectives and their outcomes. It is often used in businesses to set goals (objectives) and measurable steps to achieve these goals (key results).
At the company level, an objective may be to have 500 new customers by the end of the year. Throughout the company departments, sub-objectives and key results are defined that all work towards that company objective. The marketing team may have a key result of "Hold two webinars per month to introduce new product features" whereas the development team may have a key result of "Achieve a Lighthouse score of 90 across all metrics."
A high Lighthouse score leads to a better user experience and hence, a higher conversion rate whereas the marketing team shares what's new with the world - both result in getting a step closer to 500 new customers.

Your objectives must be clearly defined and your 3 - 5 key results must be measurable as seen in the two examples above. To contrast, here are two bad key results:

Marketing team: "Introduce new features"
Development team: "Improve Lighthouse score" These are bad key results because you cannot measure their progress or success. "Introduce how many features? How often?" and "Improve the Lighthouse score by how much?"

If you can assign a progress percentage to your key results, you likely have a good key result.

Why create personal OKRs?

I used personal OKRs for the first time in 2020 and despite everything that happened in the world, I had one of the most productive and successful years in my life. Check my 2020 - Year in Review blog post for full details.

Without goals and concrete, small steps towards these goals, living life is like driving a ship in the ocean without navigational assistance. You move (read: you get older), but you don't really know which way you go or whether you actually make progress.

What to expect in 2021

Towards the end of each quarter, I will plan the key results for the upcoming quarter. Check back frequently at the link below to see what quarterly OKRs I define and whether I achieved the current quarter's OKRs. See me succeed or fail 😀.

Why share my OKRs publicly?

First of all, you can find my OKRs available here.

I see three benefits:

Encourage others
Personal accountability
See me fail in public - maybe

Encourage others

The main reason to share this publicly is to encourage you to think about OKRs for your life. I had great success at work for many years and exceeded my personal expectations of 2020 thanks to OKRs.

I allow comments on the pages so if you have questions, you can leave comments right on the Notion pages. I'll answer whatever comes up there.

I also allow duplication of these pages. Click the "Duplicate" button at the top right to create a copy in your own Notion account. All you need to do is update the databases to match your own objectives and key results. If you do that, please drop me a note on Twitter or in the comments below to let me know. I'd love to see how many people I encouraged 🙏.

Personal accountability

I am generally pretty good at following through with a plan I set in motion so this is not really a reason to publish publicly. However, for people who are good at procrastinating, sharing OKRs publicly is a great way to feel a bit of social pressure to make sure you work on your goals.

See me fail in public - maybe

I think where it gets interesting is if I don't achieve my objectives and run a retrospective to determine what went wrong. This is where sharing it all publicly will add a lot of value to people who follow me.
You know, it is like when someone writes code on stage in real-time and every single attendee pays close attention and waits for an error to show up on the screen 😂. By the way, based on personal experience, this is the best way to get everyone's undivided attention!

Always learn, always grow!

👋

A smart guide for your career as a software engineer - My new book

Mike — Thu, 31 Dec 2020 20:53:59 +0000

You can buy the book at https://gum.co/a-smart-guide-for-your-career-as-a-software-engineer.

Do you want to earn a six figure income, work from anywhere, live a lifestyle of your choosing and be a part of the people who develop the next generation software applications? Are you a software engineer already, but want to change jobs or advance in your current role to get promoted?

If that is you, congratulations! The bad news is that there are thousands of other people just like you with more starting that journey every day. Each one of them is a potential competitor when you look for your next job. They may even be your co-worker and friend who also want to get promoted!

A Smart Guide for Your Career as a Software Engineer is exactly the book you want to read. You learn what it takes to stand out among the crowd, how to impress the interviewers and most importantly, how to be an employee that gets promoted because you add value and come across as professional, well organized and energized.

Throughout my career, I have had many job interviews as a candidate, interviewed well over a hundred candidates and saw even more resumes. I was fortunate to meet incredible human beings who have become good friends, but I also participated in interviews where I didn't quite understand what was happening 😆.

❌ I've experienced things as bad as candidates yelling, walking out or telling us they were wasting their time talking to me and my team.

✅ On the other end of the spectrum, I've witnessed candidates who showed up well prepared, confident, and people who said "I don't know" a number of times and still got hired.

What to expect

The book is structured around the following topics:

Why become a software engineer?
How to become a software engineer?
Job search
Resume / Curriculum Vitae (CV)
Interviews
Offer negotiations
First day
First 100 days
Promotions
Teamwork
Leaving the company

Read it cover to cover or jump to the topic that most applies to your current situation. Armed with the knowledge, advice, tips & tricks and templates in this book, your chances of getting that next job or being promoted rather than your co-worker are significantly higher than without reading this book.

All throughout the book, you find ✅ and ❌ to visually highlight things I recommend you do versus things you better avoid. There are over 80 tips & tricks in the book!

About the author

I am Mike Nikles; I have led hundreds of job interviews and reviewed thousands of resumes over the last twenty years in my career as a software engineer. I also sat at the other side of the interview table plenty of times as my LinkedIn profile proofs.

I currently work at Google. Prior to that, I had my own business and worked at companies anywhere from two to hundreds of employees. I helped with critical first hires, tripled engineering teams and mentored others to become efficient hiring managers.

You can learn more about me on Twitter @mikenikles or on my personal website www.mikenikles.com.

Templates

Optionally, I provide templates in Google Doc / Sheet and Notion.so format for the following:

Job search tracking
1:1 meeting notes template
Personal development plan template
"People I Met" spreadsheet
Promotion tracking

In the book, I describe what each template does and how you can develop your own. The templates are available if you want to save time and use what I have been battle-testing personally.

Why write a book about career advice?

I dive into a bit more detail in the book itself, but I have always mentored others and started to notice patterns in what mentees asked me about. After I published my first book, Cloud Native Web Development in summer of 2020, I realized I can reach a lot more people through that medium compared to 1:1 mentoring (in hindsight, things always seem obvious haha).

There is an ever-growing number of people who look at starting their career as a software engineer. With GitHub, free online courses, YouTube, and many other available resources, you no longer need a university degree to be a software engineer. What you do need is passion and a desire to learn. It is a tough path, but well worth every step you take on it.

I wrote this book to help you fast-track your career and make sure you stand out among the many other candidates who apply for the same role. In a remote-first world, this becomes increasingly important!

Purchasing Power Parity

For my previous book, a number of people contacted me and said they would love to read it, but couldn't afford it. I provided these individuals with coupon codes based on what they said they could afford and without exception, they were thrilled and so was I 💪. I would absolutely love to provide my content for free and I will continue to do that with blog posts, helping out in online forums, answer questions in chat rooms and with videos starting in 2021, but writing a book takes effort and comes with a cost to myself which is why I charge a minimal price for it. For the next 30 days, the book is $20, which means you pay $1 for each year of experience I have, seems like a good deal to me 😉.

I'm excited to announce a purchasing power parity policy (wow… that's a lot of Ps 😛). I cannot automate it, but if you think the price is too expensive, please contact me and we can figure something out that works for you. The best place to reach me is with a direct message on Twitter @mikenikles. If you decide to do that, please message me with a price you can afford.

Help spread the word and earn 30%

The main goal of this book is to help as many people as possible with their career as a software engineer. I can only reach so many people through my network, so here is my offer to you: Help me spread the word and earn 30% of your sales!

How does it work? I need you to follow these steps:

Create a Gumroad.com account (so you can get paid)
Contact me via Twitter @mikenikles and let me know you are interested in helping me spread the word about the book
Provide me with your Gumroad email address and I will create a unique link for you to share with your network. Every time someone buys a book through your link, you earn 30% of the sale.

Wrapping up

Personally, 2020 was one of the best years of my career and I'm excited to wrap it up with the publication of this book. There is so much experience and knowledge I have acquired over the years, why keep it for myself? Onwards to 2021!

If you want to hear more from me, sign up for the newsletter below or follow me on Twitter @mikenikles.

Always learn, always grow!

👋

2020 - Year in Review

Mike — Thu, 24 Dec 2020 19:14:26 +0000

Photo by Kelly Sikkema on Unsplash

That's a wrap for 2020, the most unpredictable year in a long time. There has been, and continues to be, tragedy and suffering for many people globally. So much of that could likely be avoided with a bit of common sense and wearing a mask… 😷

Year in review

Work from home

Some time in early March, I started to work from home. To be completely honest, I was glad it (finally) happened. I worked remotely for a few years as a freelancer earlier in my life and remember that time as the most productive time ever.

For someone who works in the software industry, I have never liked open office spaces, not to mention the 9 to 5 work hours and the fact I needed to be present. These are leftovers from the industrial age. There is so much to be said about the inefficiency I have experienced in offices, let's just be glad we are past all that.

What I am most thankful for is that people who can work from home finally get a chance to spend more time with their families. Missing dinners, birthdays or the first step of your child because you are abroad or working late to make someone else's dream come true is ridiculous.

In my case, working from home resulted in a lot less wasted time:

No more commute (~1h 15m per day)
No more domestic & international travel (~4 to 6 days per month)

I had two options as to what I could do with that extra time. Play video games, watch Netflix, scroll through Facebook or be smart. I opted for being smart and using the time wisely, which I reflected in my OKRs.

Objectives & Key Results (OKRs)

In my first week at home earlier in 2020, I knew I had to get my WFH routine set up. The first step was to create objectives and key results for the rest of the year. I highly suggest you look into that as you wouldn't try to cross an ocean in a boat without GPS or a compass, so why live life without any clear direction?

My top objectives I set for the year were:

✅ Publish a technical book about modern web development (Cloud Native Web Development)
✅ Develop a SaaS product to experiment with new technologies (Your Analytics)

Svelte - a technology bet that paid out

Over two years ago, I learned about www.svelte.dev. I spent some time to understand how it worked and it was clear to me that Rich Harris was onto something. I dropped React and started to use Svelte (Why I moved from React to Svelte and why others will follow). I received quite a bit of push back from people when I started to recommend Svelte back then, just the same way I received push back when I recommended React before people talked about it.

Svelte's daily downloads increased by 10x this year, from ~2k to ~20k. Companies such as Disney and IKEA and many others now use Svelte and the trend is clear.

This was a bet I made two years ago and in 2020, it showed it was worth it. Expect to hear a lot more about Svelte in 2021.

Focus on more than one income source

"Don't put all your eggs in one basket" is a common saying to mitigate loss. We all follow that in one way or another. Whether it is eating healthy (you wouldn't just eat pasta every day) or investing in various industries to better weather market difficulties.

How many of us though rely on one single income source? "Study hard, get a good job" is what you likely heard from your parents. They told you that because it worked for them. However, with the availability of the internet and its global reach, I no longer believe a single income source to be a smart decision.

My OKRs in 2020 reflect that and with my first book, I created my first additional income source besides my full-time job. As you will see in my next blog post, my 2021 OKRs are very much focused on creating further income sources. Look at yourself, find what you enjoy and what you are passionate about, then start creating. Create more and consume less!

What worked

First and foremost, I published a book and made significant progress with my SaaS product, which is used by eight teams at the time of this writing. The best part: It's completely free until I get a chance to integrate with Stripe :-). If you have less than 10k pageviews per month, it will forever be free or you can self-host it for free too.

Secondly, for the time of 2020 when my wife and I lived in the UK, we had a great daily exercise routine. The lack of the daily commute and generally being more active needed to be compensated for. Make sure you move!

I also deleted my Facebook account and decided to focus my social media time on Twitter. More on that in my next blog post where I talk about 2021. Along the same lines, I trimmed my RSS feed, unsubscribed from all sorts of email lists, cut toxic people from my network and became a lot more protective of my time by learning to say "no".

What didn't work

After relocating back to Canada, our exercise routine went down the drain for a while, something that needs to be picked up again.

I stopped taking my half an hour nap at lunchtime. That was something I did for the first few months when I started to work from home and it was great. This is high on the list of things I want to revive. Even if you don't fall asleep as easily as I do, I suggest you try lying down for thirty minutes to rest.

I do not yet live at the place I want to live, but this is something I will continue to work towards in the coming year.

Takeaways for 2021

In my next blog post, I will go into a lot more details on what I have planned in 2021. I will also publicly share my OKRs and hope to inspire some of you.

Overall, for all that happened, 2020 was a pretty good year for me personally. The lifestyle I live now is a lot more aligned with my personal values. Not 100% yet and I will make further adjustments in 2021 to move closer to exactly how I want to live my life. More to come!

👋

Why I turned my homepage into a timeline

Mike — Sun, 06 Dec 2020 21:32:28 +0000

Photo by Félix Prado on Unsplash

What has happened so far?

On December 21, 2019 I migrated my blog from Medium to my own infrastructure (this blog post has more details). The main reason was to own my content rather than leaving it on servers owned by a company. It also gives me more flexibility should the need arise to provide my content in other formats, e.g. RSS feed.
In summer of 2020, I launched v2 of my website in preparation for the publication of my first book, Cloud Native Web Development. The main goal of v2 was to significantly simplify the architecture.

As of v2, the homepage displayed a list of blog post previews.

That was great up until just about now, read December 2020.

Why choose a timeline as my homepage?

The latest evolution of the homepage looks as follows:

A lightweight version of the timeline is used on mobile:

See this Twitter thread for progress updates and how the homepage came together.

The reason to show a timeline is twofold and inspired by Florin Pop's timeline on his website:

Simplicity
It's about more than blog posts

Simplicity

A bit over 1,000 visitors per month read a single blog post where I explain why I moved from React to Svelte, according to my public website analytics.
The second most visited page is the homepage with roughly 800 visitors per month. While the previous version was colorful and had nice images and blog post summaries, I received feedback from people saying they look at the titles and if anything sounds interesting, they click and read the blog post.

The new timeline view reflects that and only displays a blog post's title, with a call to action to read the post.

A nice side effect with the new view is a much more performant homepage given there is only a single image to load.

It's about more than blog posts

Throughout my career, I have mentored others, answered questions in online communities and worked on side projects.
With the timeline view, I have a place to showcase this work and help others find me online and see what I'm up to.

The filter & search features help narrow down what is displayed in the timeline. Starting in 2021, I am going to revive my YouTube channel, so expect there to be new entries on the timeline.

Technical implementation

The majority of the work happened in PR 252. There are about 10 lines of custom CSS code, the rest is styled with Tailwind CSS and of course still based on Svelte & Sapper.

You ask, I share my opinion - Free ebook

Mike — Mon, 17 Aug 2020 22:17:45 +0000

Cover photo by https://unsplash.com/@robschreckhise

Since I released my Cloud Native Web Development book, many readers messaged me saying they enjoy my personal view of various topics.

Would you read a free ebook written by me where I discuss my view of the tech world? You ask, I answer.

Any tech topic is fair game. Learn how to code, job hunting, hiring process, interviews, promotions, big vs small biz, testing, pair programming, job levels, spaces vs tabs. Whatever you can think of, I'm sure I have an opinion.

Who am I?
I have twenty years of web dev experience and am the author of Cloud Native Web Development (http://mikenikles.com/cloud-native-web-development). I was an individual contributor, software architect, co-founder, CTO and now work at Google Cloud helping enterprise customers modernize their applications.

How does it work?

Simple, ask your question in the comments.
I will collect all of them, together with the responses I get on Twitter. I will then answer each question and combine all answers in a free ebook.
You download the book and start reading and learning.

Ask me anything!

Svelte now supports TypeScript

Mike — Tue, 21 Jul 2020 17:08:51 +0000

That's it, Svelte now supports TypeScript :-)!

https://svelte.dev/blog/svelte-and-typescript

How I wrote 214 pages for a web development book with 19 pull requests in 3 months

Mike — Fri, 03 Jul 2020 20:11:11 +0000

Photo credit: Florian Klauer

About the book

The best place to learn about the book is on its landing page. It contains
details of the content, a list of each chapter, reviews and more.

In short: Cloud Native Web Development is a hands-on guidebook that walks readers through the entire end-to-end
process of developing, testing, deploying and monitoring a cloud-native web application.
Everything you need to know, packed into a single book.

Each hands-on chapter comes with a corresponding pull request on GitHub. All readers are part of a private GitHub
organization where they can collaborate together, ask questions and exchange their experiences.

Writing and self-publishing the book - my journey

2000 until early 2020

A book like Cloud Native Web Development cannot be written over night. It's twenty years of work experience,
numerous failures, a handful of successes and a personal desire to continously grow and expand my knowledge.

For the past few years, I repeatedly thought I would like to write a book about everything it takes to run a web application in production. There are tutorials, video courses and guides available online for any topic you can imagine. Need to compare React and Svelte? You'll find
plenty of tutorials. Want to learn SRE (site reliability engineering) best practices? Check here.

However, unless you know what to look for, you won't succeed because there are so many pieces to the puzzle, it's challenging to know where to start.

February 2020

With COVID-19 spreading across the globe and governments putting countries into lockdown, it became immediately
apparent that this is not like a previous pandemic. I had two options:

worry, feel anxious, be unsure what to do
look at it as an opportunity

I was privileged enough not to worry, not to feel anxious. So I went for the second option and decided to make
the best of the situation.

It was now or never to write a book. Luckily, my wife supported me all the way, otherwise this would have never
been possible. In fact, she encouraged me to spend as much of my spare time on the book because she knew how much it would mean to me to publish that book I had been talking about for years.

The outline of the book had been in my mind for a while already. The tech stack I wanted to use was pretty clear
to me as well. I wanted to use technologies that I believe in, technologies I use in my projects and technologies
I believe are about to become very popular.

Self-publish vs. using a publisher

This is a tricky one. Late in 2019, I was contacted by two publishers who asked me to develop a Svelte online course. When I learned that my take-home pay would be between 12% and 18%, I declined. Now, writing a book was never about earning a lot or quitting my day job. It was about sharing my knowledge and helping others learn from my experience. Having said that and knowing my personality, I knew I would make this as perfect as it gets and invest a lot of time. So why did I reject the publishers? Quite simple, while the financial reward is not the first priority, I believe my knowledge and two decades of experience is worth something worth paying for. It's still a lot cheaper than four years at university where you are taught things you likely won't need in real life.

In addition, a publisher provides you with technical reviews. Without sounding arrogant, my book is about my experience,
my view of what's best and my best practices. There are very few people who know my experience better than myself.
It turned out I had amazing technical reviwers among my co-workers and friends, and even a PhD student from Austria
who, by chance, found my website and contacted me. He became the first to fully review line by line and provided input as valuable as a tech reviewer at a publishing company could have done.

A publisher would have given me a wider reach, but on the other hand, my blog gets 80 to 100 unique visitors per day
from across the world, that's good enough for me to get started.

March, April and May 2020

From a "behind the scenes" point of view, these months were not exciting. Lots of writing, both the book and the corresponding source code.

I started with an empty Google Doc, wrote down the top-level chapters and started with the "About the author" chapter. It
was the only chapter I was pretty sure I knew what to write :-). It also helped to turn the white screen into something that looked like a tiny essay. Anything other than a blank page is better at that stage of the process!

Development of the source code

The idea was to give access to the source code to all readers. I wanted to make sure the commit history, the PRs and everything related to the code was perfect. So how did I manage 105 commits without any mistakes or commit messages
such as "Whoops... try again."?

I had two repositories! A "playground" where I experimented, made sure everything worked and tested things for individual chapters. In parallel to the experimentation, I wrote the book's hands-on part. When I was satisfied with the code, I switched to the "clean" repository, the one readers have access to now. I followed the instructions I wrote in the book. This made sure I was the first person to actually follow along my instructions in the book.
It also meant I wrote the entire book's source code twice - once with lots of experimentation and once in a clean way.
As I'm writing this, I was curious to see how many commits the "playground" repo has and to my surprise... it has 119!
That's only 14 more than the final repo... I could have sworn it would be a lot messier!

June 2020

The book's content was completely written some time in early June. At that point, I shared the book with a few more
technical reviewers. Prior to that, I had a few close friends and "Thomas, the Austrian" who provided feedback.
The tech reviews went very well and I felt comfortable publishing the book.

June 26, 2020

Two days before the self-imposed publication deadline, my wife suggested we develop a landing page for the book.
"Sure!" She also did some research on book covers and designed the one you see now. Based on that, we developed
the website in the same colors.

June 27, 2020

I adjusted headings, aligned them to new pages and updated the table of contents. My wife reviewed it and made
sure everything was properly aligned. My wife got up, looked at me and said, "We need to change the icons in the book." One day to go... I was surely nervous, but learned over the years that it's best to trust her. I'm glad I did as the icons now look a million times better than the black & white ones I used previously!

June 27 was a Saturday and we stayed up until 2:30am or so on Sunday morning. When we finally went to bed, we felt
we were ready.

June 28, 2020

A few last-minute updates to the table of contents due to changes to page numbers and I downloaded the PDF and
published it on Gumroad.

Lessons I learned up to this point

Pros

I think the best thing I did was starting with a very clear idea in my mind of what I want to write about. I knew
exactly who the target audience would be, I pretty much had all chapters in mind and also knew I wanted there to be
source code and a private community of everyone who buys the book.

Patience & dedication: From the very beginning, I set myself a strict deadline of June 28, 2020 (my birthday).
This project was a big time investment and I knew there is no excuse to delay anything if I wanted to hit that deadline.
The rule I set myself was very clear: Spend as much of my spare time on writing, every day. Looking back at my time
tracking, I wrote at least a little bit every single day.

Cons

Writing a 200+ book, with 19 pull requests is a lot of work and I spent a few hundred hours on it. If I write another book, I will give myself more time. It is more likely though that I would write a shorter book ;-).

Perfectionism is your biggest enemy to get stuff done. Sure, I'm very proud of the final outcome and how each chapter maps to a pull request and sometimes even individual sub-chapters that map to commit messages. My readers absolutely love and appreciate this, but it put a lot of pressure on me throughout the process.

The first week since publication

37 books sold with no advertising other than posting on my Twitter account (500 followers) and LinkedIn.
Given the incredible feedback I received from reviewers, I am confident I will reach a wider audience once the 37 readers wrap up the book and hopefully provide some feedback on Twitter to help promote the book.

Estimates from reviewers vary between 30 to 50 hours to finish the book, depending on their level of experience
in web development. I'm keen to keep an eye on what happens over the next few weeks and months.

Final thoughts

Writing Cloud Native Web Development was an incredibly fun project. I learned a lot about writing, publishing,
EPUB (it's basically HTML!), marketing, and what it means to be dilligent and stick to a strict schedule.

Would I do it again? Possibly, but not in 2020 :-).

Please head over to the book's page and get yourself a copy!

👋

A complete rebuild of www.mikenikles.com

Mike — Sat, 27 Jun 2020 08:16:36 +0000

Photo credit: Thought Catalog

It's been an interesting few evenings to rebuild www.mikenikles.com:

Let's first talk about v1.0

The previous version was a proof of concept. I wanted to run
Ghost.org on Cloud Run (https://cloud.run), with Sapper
as a static site generator for the frontend, so that the Ghost database did not have to be accessed at runtime.

The architecture looked like this:

What were the challenges?

Publication process

To publish a new blog post, I had to:

Start the Cloud SQL databaes used by Ghost.
- It's worth noting I have could left that turned on, but the point was not to have a database at runtime ;-)
Log in to the Ghost instance.
Write the post and upload assets.
- Asking for reviews was tricky. I would have to give reviewers access to Ghost and they would see the blog post displayed in Ghost, not the way it will look once deployed.
Publish the post.
Wait for the static website to be generated and deployed to Firebase Hosting.
Shut down the Cloud SQL instance.

As I mentioned well before I developed v1.0, this was over-engineered and overly complex.

Operating costs

The operating costs were about CAD $40 per month:

Throughout the first half of 2020, the blog had ~2,000 unique visitors per month with ~5,200 page views.
I wanted to find a more cost effective way to provide my content to others.

Google Analytics

I used Google Analytics and Firebase Performance tracking. While the insights are interesting, I rarely looked at more than number of visitors, the country they are from and which blog posts they read. The various scripts I needed to get this to work also came at a performance cost I want to avoid in v2.0.

The goals for v2.0

Before starting the project, I defined the following goals:

Open
Best practices
Automation
Low operating costs

Open

I want all aspects of my website to be open. The source code
including project management, pull requests, issues, etc.

Each blog post will be released as a pull request. Anyone can access drafts and provide feedback. This also gives me the flexibility to potentially allow for community contributions such as translations etc.

In addition, I will make the website's analytics available publicly as part of a project later in 2020. Stay tuned for that by following me on Twitter @mikenikles.

Best practices

As it has always been the case, my personal website is a place for me to experiment with new technologies.
If I get asked "How would you ...?" in relation to web development, I want my answer to be "Have a look at
www.mikenikles.com".

A perfect Lighthouse score, fully accessible, top SEO ratings, works without JavaScript, etc.

Automation

For anyone who's worked with me they know that automation is near and dear to me. "Don't document what you can automate!"
The focus is on using NPM scripts where necessary and connect it all via GitHub Actions.

Each PR provides a preview URL and once merged, a production deployment happens within seconds.

To create a new blog post and all necessary directories, I use npm run generate and answer a few questions.

Operating costs

As close to $0 as possible and no database since it's all static content - simple.

What's new in v2.0?

Architecture

It's a lot simpler:

Diagram source: https://excalidraw.com/#json=5406435517136896,jY4N1Wo4Vgqn45E9uxUqPA

All we've got is:

Gitpod.io for my cloud-based development environment.
- Get 30% off your Gitpod subscription with my coupon code mikenikles.
GitHub for the blog posts, source code and workflow automation.
Vercel for hosting.

The publication process now looks like this:

Write the blog post and add assets.
git push it to GitHub and open a pull request.
Share the draft URL with reviewers; iterate on the post.
Merge the PR.
- Deployment to production then happens automatically.

Interactive blog posts written in `mdsvex`

This is arguably a bit of a nice-to-have. It is so nice though that I have to point it out!

I write this blog post in mdsvex which is basically Markdown with Svelte mixed in wherever I want.

An example taken from https://svelte.dev/examples:

<Clock />

Note: The above clock only renders on my blog at https://www.mikenikles.com/blog/my-personal-website-v2-0.

In the blog post file, the following is what I write:

<script>
  import Clock from "./clock.svelte";
</script>

...
Another example, taken from https://svelte.dev/examples:

<Clock />

I'm looking forward to taking advantage of that as I get back into more frequent blogging.

Draft preview URLs

Have a look at the recently closed blog post pull requests, open one and find the preview URLs to see how the post looked when it was in draft.

With the blog post's content available in the pull request, reviewers can comment on individual lines and I can pick up the conversation right there in the correct context. No more back & forth via emails or copy & paste from shared Google Docs.

What's next?

Personal website & blog

I track the v2+ project on GitHub. The focus is going to be on small enhancements and experiments as I see fit.

Book: Cloud Native Web Development

On June 28, 2020, I (will release) released my book Cloud Native Web Development.
It's two decades of web development experience packed into 200+ pages and 19 pull requests. It's a hands-on guidebook from zero to production and anything in between!

Use coupon code DEV for a 25% discount!

👋

DEV Community: Mike

SvelteKit & Prisma - A match made in digital heaven

What are you going to learn?

Things you need to know

The foundation

Add Prisma

Install & initialize Prisma

Define the Todo model

Configure a SQLite database

Create the database and tables

Use the PrismaClient to interact with the database

Let's test

Conclusion

I said goodbye to local development and so can you

Table of contents

What it’s like today

Open source project onboarding

Meet Alice and Bob

Set up a new project

Develop a new feature

Switch context

Set up a new computer

Contribute to open source projects

What’s the catch?

Conclusion

Why I Left Google and Joined Gitpod

My time at Google

2020

Gitpod - The way we are all going to develop software

Why join Gitpod?

So, what is Gitpod?

In conclusion

A Svelte component to format numbers

How it's done

Typescript

2021 - My Objectives & Key Results

What is OKR?

Why create personal OKRs?

What to expect in 2021

Why share my OKRs publicly?

Encourage others

Personal accountability

See me fail in public - maybe

A smart guide for your career as a software engineer - My new book

What to expect

About the author

Templates

Why write a book about career advice?

Purchasing Power Parity

Help spread the word and earn 30%

Wrapping up

2020 - Year in Review

Year in review

Work from home

Objectives & Key Results (OKRs)

Svelte - a technology bet that paid out

Focus on more than one income source

What worked

What didn't work

Takeaways for 2021

Why I turned my homepage into a timeline

What has happened so far?

Why choose a timeline as my homepage?

Simplicity

It's about more than blog posts

Technical implementation

You ask, I share my opinion - Free ebook

Svelte now supports TypeScript

How I wrote 214 pages for a web development book with 19 pull requests in 3 months

About the book

Writing and self-publishing the book - my journey

2000 until early 2020

February 2020

March, April and May 2020

Lessons I learned up to this point

The first week since publication

Final thoughts

A complete rebuild of www.mikenikles.com

Let's first talk about v1.0

What were the challenges?

Define the `Todo` model

Use the `PrismaClient` to interact with the database

Interactive blog posts written in `mdsvex`