
# Falling in Love with Code: The Journey from Struggle to Passion

Here we go again, over half a year since the last post.. Whoops. Well I've been
on parental leave so the blog has taken a bit of a backseat but it's time to
get back on track with some new content.

Let me guess, you read the title and thought "Oh great, another one of those
posts that tells me to just work harder and everything will be fine". Well,
you're wrong. This post is about how to improve and love what you do, not just
how to improve. There's a big difference. So lets get started.

It's no secret that I love code. I love writing it, reading about it, talking
about it you name it. But that wasn't always the case. I remember around 15
years ago, before I even knew what a for loop was, when I got the brilliant
idea that I wanted to create my own video game so I sat down and tried to learn
Java.. and it lasted a couple of weeks before I uninstalled everything and gave
up. I just didn't enjoy it. And there is a reason for that.. I was
uncomfortable with struggling and all I did was follow tutorial after tutorial.

My mindset had always been that everybody has a passion, you just got to find
it, so I tried a bunch of things and like clockwork I gave up a couple of weeks
later. That is until a year or two later that I took an intro to programming
course, we were all beginners there so the few weeks I had spent learning Java,
gave me a huge head start, I already knew what variables, loops, classes etc
were so I was acing exercises and projects everybody else was struggling with.

**And wouldn't you believe it, suddenly I was loving programming.**
![Duane doing a cool dance](https://i.giphy.com/media/v1.Y2lkPTc5MGI3NjExMDZhZG82aTB3ZHYxMW04enU2dnRhZ3djMm82aTNkMHQ0bnpndjg5ZSZlcD12MV9pbnRlcm5hbF9naWZfYnlfaWQmY3Q9Zw/5FKNjm8Ru327u/giphy.gif)

Turns out humans love doing things they think they are good at. Passion is not
something that randomly happens, it's something that is built by overcoming the
initial struggles and becoming really good at something. I can highly recommend
the book **So Good They Can't Ignore You** by Cal Newport if you wanna dive a
bit deeper into how skills lead to passion, it's a great read.

So how do you fall in love with code? Well, you gotta get good at it. And how
would you do that? Well here are some of my tips that I've learned over the
years.

## Avoid tutorial hell and build stuff

I know, I know, tutorials are great. They are a great way to get started and
learn the basics but they are also a great way to get stuck in a loop of
never-ending tutorials. So what is the best way to get out of tutorial hell?
Code code code. You gotta build stuff. It doesn't matter if it's a todo app, or
the next big social media platform, just build something. Learn by doing, by
just coding until you get stuck, then google the problem and fix it and repeat.
You will learn so much more by building stuff than by following tutorials and
try to be consistent, code every day, try to make atleast one commit to your
github every day even if it's just a small change (Easier said than done, I
know).

Eventually you will get into a habit and every time you turn on your computer
you will feel like coding. A great way to code on days you don't feel like
coding is to turn off your phone, turn off anything that you at that moment can
find more interesting than coding and just be bored until coding is the most
interesting thing you can do.

Don't forget about your mental health though, if life is crushing you, it's
okay to just take a break and play some video games or watch a movie. Small
steps.

## Get comfortable being uncomfortable

This is a big one. You gotta get comfortable with being uncomfortable. What
does that mean? It means that you gotta get comfortable with not knowing the
answer to a problem, with not knowing how to solve a bug, with not knowing how
to implement a feature. You gotta get comfortable with struggling and the only
way to do that is to struggle. You gotta get stuck, you gotta google the
problem, you gotta learn that even the unknown is solvable, and the more you do
it, the more comfortable you will get with it, and the more comfortable you get
with it, the more you will enjoy it. It's a beautiful cycle.

Eventually you will get so comfortable with being uncomfortable that you will
be confident in your ability to solve any problem that comes your way. Need to
build a complicated app in a language you never heard of? No problem because
you know that you can learn it and build it. You know that you can solve any problem that
comes your way and that is a beautiful feeling that will make you love what you
do and boost your confidence tenfold. Remeber that you can't master coding, you
can just become a better student.

## Don't over think it

Something I remember struggling with earlier in my career was the constant
stress that whatever I was building wasn't 100% following standards and best
practices.

_"Oh I wonder if my file structure is corretly set up, I should spend X
amount of hours researching how other people do."_

_"Oh no maybe there is a better way to write this function, I should spend X
amout of hours refactoring it."_

Coding is improved by writing line upon line of code not reading about concepts
and wondering what every one else will think about your code.

_"Is my file structure or my functions optimal?"_ - Propably not, but as long
as it's not causing you any problems it's fine. But what happens when you keep
coding and notice that they are causing you problems? Well congratulations, you
just leveled up and realized a better way of writing code. Bad coding practices
are realized the more code you write, not the more you read about them. Now I'm
not saying you should't read anything, reading is also a great source of
knowledge, but it's not close to writing code. For example you propably
sholdn't write the same function 10 times in 10 different places but if you do,
as soon you have to make a change in that function and realize you will have to
change 10 different places you will (hopefully) come to the conclusion that you
should have written it in a better way so you refactor and learn from it.

![Goku leveling up](https://c.tenor.com/0pmPIX08hQUAAAAd/tenor.gif)

## Conclusion

I hope these tips will help you to find passion in coding and I can guarantee
you that if you follow these tips you will become a better coder and you will
learn to love what you do which will make you 10x better. It might take a
couple of weeks, months or even years but if you keep at it you will get there.
Remember that it's a marathon not a sprint and that you can't master coding,
you can just become a better student.

Have a great rest of your day!


Everybody wants to love what they do right? If you are going to be doing this for the next 30 years, you want to learn to love what you do, but how do you learn to love coding?

Falling in Love with Code: The Journey from Struggle to Passion


# Javascript Level Up - Part 1 - The Prototype Chain

Remember when I said that I would update this blog once every 2 weeks?  
I hope not because as you may notice the last post was almost a year ago. __Whoops.__


Well worry not because I will be closing this year with a bang. A series of posts about knowledge
all Javascript devs should have but that I unfortunately see lacking all too often. Hopefully this will make
up for my lack of posts, nobody warned me how little free time you have when you have an infant (actually, 
pretty much everybody warned me about this but I thought they were exaggerating.. Turns out they weren't).

Enough yammering, let's get started!


## The Prototype Chain
Lets take a look at some code.
```js 
const hero = {
  name: 'Guts',
  weapon: 'Greatsword',
  swing: function() { console.log(`${this.name} swings a ${this.weapon}`) }
}

hero.swing()
```

Pretty straight forward, we create an object that has 2 properties: name and weapon. It also has 
a method called swing that logs the fact that they swing their weapon to the console.  
And when we then call the method we get our little message printed to the console (try pasting the code into
the browsers console if you want to test without whipping out your code editor).

"_Guts swings a Greatsword_"
![Guts swinging his greatsword](https://media.giphy.com/media/K0JrA2VbkFy2A/giphy.gif)

Working as expected right? Nothing strange at all about that I would say. Now what happens if we try to call 
__hero.roar()__ on our hero object? We get an error that .roar() is not a function. Still I would say that 
it is exactly as we expected since we never created it.

Now how about we call __hero.toString()__? Hmm strange, that returns an object, even though we never
created a toString method for our object. And that is due to...

### Prototypal inheritance
A prototype in Javascript in like a blueprint that your object will inherit from. Let's keep on 
with our hero example and let's create an object that inherits from our Hero object.

```js 
const villain =  Object.create(hero)
```

Now if we type __villain__ in our browser console we see that it is an empty object. What happens if we
try to call __.swing()__ on our villain object? 

It logs: "_Guts swings a Greatsword_"

But how does that work when our villain object was just an empty object? It's because we are inhereting from
our prototype the hero object. Try typing __villain.\_\_proto\_\___ into the browsers console. It returns
the hero object with name, weapon and the swing method.

But our villain is not guts, let's change that.
```js 
villain.name = 'Griffith'
villain.weapon = 'Saber'
```

and we run __villain.swing()__ and..

"_Griffith swings a Saber_"

![Griffith swinging his saber](https://media.tenor.com/G5AuRJr7LwYAAAAd/griffth-berserk-griffith.gif)


Now if we enter our villain object into the console we get \{name: "Griffith", weapon: "Saber"\} and we know
that we get the Swing method from the hero object we inhereted from. But let try typing __villain.\_\_proto\_\___
again.

It's still our hero object, the name is still Guts and the weapon is still Greatsword but we
logged that Griffith was swinging his saber which brings us to..

## Climbing the prototype chain
The way Javascript works is that when you call a function or try to get a property from an object it will
start climbing the prototype chain. In the case of __villain.name__ it will enter our villain object, find name
and use that. Which is why swing() uses the name from villain once we added it instead of the name from
hero that was in the prototype which it inherits from.

Now when we call __.swing()__ on our villain object it will check villain, find nothing there then climb
the prototype chain to hero where it fill find the method swing() and use that.

Great, glad we solved where those two come from, but we still haven't answered one question. Where did
__.toString()__ come from and why does that work on our hero and our villain object?

See every object in Javascript has a standard object prototype which contains things like __.toString()__ 
, __.hasOwnProperty()__ etc so everytime you create an object using squigly brackets you automatically get these 
methods. In our case it will:
1. Enter into villain, find nothing and climb up the prototype chain to hero.
1. Enter into hero, find nothing and climb up the prototype chain to Object.
1. Enter into Object, find __.toString()__ and call it.

But what happens if we try to get a property that does not exist, like __.helloWorld__?
Once again we will climb the chain, untill we get to the top. If nothing was found, it means that
the property has not been defined and we get the source of nightmares for many Javascript devs __Undefined__.



Hope you liked this post and that you learned something!
If you have any questions or opinions you can contact me through LinkedIn or Email (both available in the footer)
Stay tuned for Part 2 of the Javascript Level Up series! (It will not take another year I promise)


 


Welcome to this new series where we will take a little more intermediate dive into Javascript and how things actually work. Part 1 - The Prototype Chain!

Javascript Level Up Part 1 - The Prototype Chain


# Javascript: Compiled, Transpiled or Interpreted?

Yes, finally you will get an answer to the question that has been robbing you of sleep all those countless nights but before we can
understand what just-in-time compilation is, let's get some basics down mon petit cherie.

## Compiled vs Transpiled vs Interpreted

Now be wary that there is an ever going battle between people online of what the actual difference is between these three but this the most common
(_and right, fight me_) opinion.

### **Compiled**

Your code is translated into a language of a lower abstraction.

![Michael from the office saying what](https://media1.giphy.com/media/ghuvaCOI6GOoTX0RmH/giphy.gif?cid=ecf05e473f0onmzy8z2trx6mnxf7k9uefo19ys9d3ko06m9g&rid=giphy.gif&ct=g)

I'll try that again, a language that is readable for us humans is not readable for computers and vice versa. So a high level language such as
Javascript or Python is easy to read by us humans but gibberish for a computer, while something as elegant as binary code is Shakespearian for a computer
while for us stupid humans is just a bunch of zeros and ones.

A little example can be seen like this where abstraction levels go lower step for step:

1. Javascript/Python - Easy to read, easy to write. A lot of complicated stuff happens behind the scenes and you don't have to worry about it.
2. C/C++ - Things are a bit harder to read and write. You have to manage memory clean up and handle memory pointers. Not too bad but not as human friendly as the last abstraction level.
3. Assembly - If you see someone proficient in assembly then you have witnessed divinity, bask in their radiance. Things barely make sense to normal humans here.
4. Binary code - If you see someone proficient in binary code then you have witnessed a real life Terminator and you should propably run for you life. Everything is just zeros and ones, following a base 2 numeral system.

So what a compiled language means is basically taking a language of higher abstraction (human friendly) and turning it into something of a lower abstraction
(computer friendly). This is very much an oversimplification and compilers do a lot of other cool super complicated stuff too like optimizing the code but you
do not have to worry about that for now.

It's also worth noting that a compiled language is fully translated to a lower abstraction level before you can run it. This is worth keeping
a note of for when we talk about interpreted languages later.

### Transpiled

Your code is translated into a language of the same abstraction level.

Hopefully you understand somewhat what that means based on the previous information but let me give you some examples.

Take Typescript and Javascript for example. When you "compile" Typescript it is translated into Javascript. Typescript and Javascript are
on a similar abstraction level for us humans, both are easy to read and understand. So when a language is translated from one language to another language on the same level we call this transpiled.

Another example is using something like Babel that takes modern Javascript and translates it to older Javascript so that older browsers also can
understand it. Both modern and old Javascript is of the same abstraction level, so instead of saying it was compiled to a older version, we say it was
transpiled instead.

### Interpreted

An interpreted language is a lot like a compiled language. The language is translated from a high abstraction language into a lower abstraction language,
but remember what I told you to take a note of?
The main difference is that where in a compiled language the whole code is being translated before it is ran, an interpreted language allows you to have
an interpreter that step for step translates the language into a language your specific OS understands while it is running.

The bonus is that you do not have to compile the language every time you want to run it and if an interpreter exists for the target machine then
the language can also be translated so that it can understand it. But as you might have suspected translating a language step by step as you are
running it is not very efficient, which means performance takes a hit.

## Javascript - Just in time compiled

So back to the star of the show. What is Javascript, is it compiled or interpreted? - **Yes**.

![Jared from Silicon Valley asking which one](https://media0.giphy.com/media/w6AMhQzMaMb84/giphy.gif?cid=ecf05e47iuv8d6nqsw69lgtmuhons13ifylhwodisglpium7&rid=giphy.gif&ct=g)

Javascript is just-in-time compiled, but what the hell does that even mean. See in the early days of Javascript when
the internet was still young and sites couldn't do much it was an interpreted language since performance wasn't much of an issue.
But as the web evolved and the Javascript written became more and more complex browsers implemented more modern engines which used a mix of interpretation and compilation called just-in-time compiled.

How a just-in-time compiler works is that it runs through the code the same way an interpreter would but it also utilizes a profiler that constantly
monitors the code that is being run.
If it notices the same code being run many times the profiler will class that part of the code as "warm" and send it to be compiled and saved so that
for future uses the compiled code can be used instead which will perform much better.

Now as code keeps getting warmer and warmer eventually it will be what the profiler calls "hot" which results in the compiler trying to make
the code even more efficient by further optimizing it and instead using the new optimized version of the code for even better performance.

Now you are probably wondering, why not just compile and optimize the whole code? See every time code is compiled and optimized the code execution has
to slow down which is why only warm and hot code is compiled. Compiling and optimizing a line of code that is run once is a waste since
the interpreter will read the code, compile it, optimize it and save it for later all which take time but no time is being saved since it will never
use this optimized code again.

Optimizing a line of code that is run 10 000 times takes a little initial hick up but more than makes up for it later due to the performance increase
for that part of the code.

So that's it in simple terms how just-in-time compilation works in Javascript, I hope you learned something new and remember that the browser engines
are complicated monsters and have many optimization techniques that were not included in this article. Thank you for reading!


How many sleepless night haven't you spent wondering how a browser can understand the Javascript you write or what just-in-time compilation is? Countless I bet, but wonder no more because I have spent my precious free time reading about it just so I could share it with you.

Javascript: Compiled, Transpiled or Interpreted?


# Choosing a test framework: Cypress vs Playwright

## Introduction

Wether you are starting a new project or just realized that Selenium is a dumpster fire and want to upgrade to save your sanity this guide is here to help you choose which framework to go with.

_- But what about Test Cafe, Robot Framework etc?_

Good question little Johnny, let's be honest those tools do their job and if you enjoy them more power to you but the tools we are about to compare do everything those tools do but better.

I have professional experience with both tools in big and small projects, modern and legacy web apps and I am neither sponsored of affiliated with either tool, but hey Microsoft/Cypress Team if you wanna splash some money my way my contact info is in the footer 😉.

## Features and limitations

Let's just dive into the most important part when it comes to choosing a test framework by seeing what each framework can and can't do.

### Programming language

Based on what programming language you wanna use this one will be very decisive since Cypress can only be used with Javascript/Typescript while Playwright supports Javascript/Typescript, Java, C#, Python. So if Javascript is not your thing then congratulations you need go no further, Playwright is the tool for you. If you on the other side "enjoy" Javascript/Typescript we will need to go a little deeper to see what more sets these two frameworks apart.

### Features

- Component Testing - Playwright ✅ | Cypress ✅
- Integration/API testing - Playwright ✅ | Cypress ✅
- E2E testing - Playwright ✅ | Cypress ✅
- Mocking network requests - Playwright ✅ | Cypress ✅
- Typescript support - Playwright ✅ | Cypress ✅
- Great documentation - Playwright ✅ | Cypress ✅

#### So far so good, now let's see where these frameworks differ

- Multiple tabs/windows or pop up support - Playwright ✅ | Cypress ❌
- iFrame support - Playwright ✅ | Cypress 🟡
- Visual test runner - Playwright 🟡 | Cypress ✅
- Running test in parallel - Playwright ✅ | Cypress 💰
- Ease of use for non-coders - Playwright 🟡 | Cypress ✅
- Webkit support - Playwright ✅ | Cypress 🟡
- Speed according to tests by [checklyHQ](https://blog.checklyhq.com/cypress-vs-selenium-vs-playwright-vs-puppeteer-speed-comparison/) - Playwright ✅ | Cypress 🟡

#### Other differences that are more based on taste:

#### Syntax:

- Playwright - Classic JS syntax with async await
- Cypress - Promise like syntax with .then() and command chaining

#### Way of controlling the browser:

- Playwright - Chrome Dev Tools protocol
- Cypress - Electron app which embeds a browser.

#### Tool Support

- Playwright - Open source project ran by Microsoft. The team who built Chrome Dev tools protocol and Puppeteer working on it.
- Cypress - Open source project ran by Cypress.io with a paid version that has additional features.

---

Maybe this is all you need to make your decision but let's dive deeper into some the differences.

### Multiple tabs/windows or pop up support

This is a very decisive, does the app under test need to open new tabs, windows or pop ups? If yes the Cypress is out of the picture since
this is not supported and according to the cypress team [will never have multitab support](https://docs.cypress.io/guides/references/trade-offs#Multiple-tabs).
Playwright on the other hand handles pop ups, multiple pages or multiples tabs without any issues.

Yes there are suggested work around for Cypress but they are not very good, according to me this is a deal breaker if this is needed for your app.

### iFrame support

Cypress claims to have iFrame support that works well but let me tell you a little story:

In a project I worked for (it used a low code platform...) for some reason all the content was loaded through iFrames where on every page change a new iFrame
was loaded with the new content. Don't ask me why... Anyways I tried to automate this at first using Cypress iFrame support and it didn't work very well.
The tests were flaky at best.

I later rewrote the tests using Playwright and it was like night and day. The tests just worked and there were no issues.
If you need to test iFrames, use Playwright. You can try Cypress but it will definitely work better with Playwright.

### Visual test runner

Do you know why a lot of people love Cypress? It's this right here. The test runner, where you can see step for step what your code is doing,
see the results, grab elements with their element picker and time travel (step back and see what happened). It's a thing of beauty.

Yes in playwright you can use the debugger to see the code step by step and you can use their locator creator to find/create locators but it is very bare boned in comparison.

### Running tests in parallel

In Playwright this is free right out of the box and it even supports running tests in the same file in parallel. It's great.

In Cypress this feature is only available if you get the paid version (500 test results free). Never used the paid version since I see no reason ever
to pay for tools that have alternatives that are available for free.

Running tests in parallel is a great time saver so if you have a lot of tests consider this. (The cypress team probably deservers your money, they do a great job but why pay for something you can get for free.)

### Ease of use for non-coders

Now this one is very subjective. I have been coding for many years and would not consider myself as someone who's opinion we should listen to for this.
So instead this comes from things I have heard from colleagues with less programming knowledge and read about online on QA forums.

While the cypress syntax and way of working might seem a bit strange at first it seems to do very well with people with less coding experience,
the code is easy to read (although it can get very hard to read when the nesting goes overboard). Not having to worry about asynchronicity and just
chaining commands together is very easy to understand. That combined with the visual parts of Cypress such as the Test runner makes it great for people
just getting into test automation.

Playwright is more simple. Sure it's easy to set up but after that it's pretty much just basic javascript syntax. It's not hard in any way, you just need
some basic programming knowledge but it's just not as easy as Cypress is. Sure if you want to implement good design patterns such Page Object Model you will
eventually have to get more technical in both Playwright and Cypress but for people just getting started, Cypress takes the cake.

### Webkit support

Playwright has webkit support. Great!
Cypress did not for a long time but now it's finally implemented as a experimental feature. Soon to be great!

Other than that both have Chrome/Edge/Firefox support. If webkit is super crucial for your project then for now you should probably choose Playwright,
but soon this will hopefully be a tie between the two of them.

### Speed according to cheecklyHQ article

Speed is probably not something you should consider when you make your choice and these kinds of tests should always be taken with a grain of salt.
Since Cypress needs to load an electron app to start running the tests the start up will always be slower that playwright that just launches
the browser and controls it like a puppet.
This was just included in case you wanted to see some comparisons.

---

Thats all for this time but there will probably be more articles about these two frameworks coming soon. I hope this was enough for you to make
an educated decision for which testing tool you want to use for your next project and please do not go with one of those super expensive testing tools marketing teams
sell to clueless project leads. Send them this article instead because these tools are great.

If you wanna know more about how Playwright controls the browser through the Chrome Dev Tools Protocol then do not worry,
it's on my todo list to write an article about it so keep your eyes open.

Thank you for reading!


Are you wondering what test framework to use for you next project? Well look no further because here is a comparison of the two greatest test frameworks available at the moment.

Choosing a test framework: Cypress vs Playwright


# How it's made: My Tech Blog

First things first, welcome! Let's go through how this site was made and a little Q&A about why I did things the way I did.
So let's get straight into it, I built this site using:

- **Framework:** React/NextJS
- **Programming language:** Typescript
- **Posts**: MDX
- **Hosting**: Vercel

If you wanna see how the code looks like then you can check it out on [Github](https://github.com/JannisK89/Tech-Blog 'Link to Jannis Github')

It's a NextJS statically generated site where the articles are written using MDX, a way to write markdown combined with React code meaning I can just create a new markdown file,
write an article and push it for it to be visible for the world. For CSS I used Tailwind simply because it's the only way to make CSS tolerable.

## What will I be posting about?

Oh a little bit of everything. This here will pretty much be a place where I write and explains things that I learn since I find that one of the better ways
of really getting things to stick in my head is to explains them to other people.

Recently I have been diving deeper into how things actually work behind the scenes in Javascript/React/Next so there might pop up a couple of posts about that but I
will also be posting about building CI/CD pipelines, choosing Test Automation frameworks and other DevOps stuff as well.
I'm also looking to dive into Rust so some Rust content might start popping up soon.

Currently I am aiming at a post per week but there might be more some weeks and much less sometimes when life gets in the way.

## Are you the greatest developer ever? Why would anyone listen to you?

**Yes, the literal God of programming.**

Jokes aside, like I said in the previous question I mostly write these articles to spare my wife and friends from listening to me babel on about it. And who knows, maybe
you will learn something new if you stick around.

## Why NextJS & React?

Mostly because I enjoy using those technologies. I thought about giving Svelte a try but I have some other ideas where I'll use Svelte instead.
Also the way NextJS handles routing and static site generation felt like a great tool for making this kind of site.

## Why Typescript?

One might think that Typescript is overkill for something as simple as a blog but I am one of those few people that enjoy type systems even though the Typescript typing
system is not one of my favorites. So unless I'm using JS to solve leet code problems or something similar I'll probably go for TS instead.

<img src="https://pbs.twimg.com/media/EzRewP5VUAowWoN?format=png&name=900x900" alt="typescript meme" width="300" />

## Why are you not hosting you articles in a CMS or Database?

I simply saw no reason to over engineer what is very simple to make. Maybe in the future if my post count gets so high that maintaining mdx files is impossible I might
integrate with a DB or CMS but for now I see no real need for it.

## Why Vercel?

Because NextJS and it's free.

---

That's all for this post and don't worry, future posts will be of higher quality than this (propably not but I will try).


Welcome! What could possibly be a better first post than me explaining how I made the very page you are on and explaining what I am planning to post about.