From 3fe84e39dd2ddbc3f9f75f02b9bc543c2012f4e2 Mon Sep 17 00:00:00 2001 From: Mitja Felicijan Date: Fri, 22 May 2020 12:48:29 +0200 Subject: Added comments --- ...-love-and-hate-relationship-with-nodejs copy.md | 41 ++++++++++++++++++++++ ...30-my-love-and-hate-relationship-with-nodejs.md | 41 ---------------------- content/2020-04-05-remote-work.md | 37 +++++++++++++++++++ static/style.css | 23 ++++++++++++ templates/post.twig | 14 ++++++++ 5 files changed, 115 insertions(+), 41 deletions(-) create mode 100644 content/2020-03-30-my-love-and-hate-relationship-with-nodejs copy.md delete mode 100644 content/2020-03-30-my-love-and-hate-relationship-with-nodejs.md create mode 100644 content/2020-04-05-remote-work.md diff --git a/content/2020-03-30-my-love-and-hate-relationship-with-nodejs copy.md b/content/2020-03-30-my-love-and-hate-relationship-with-nodejs copy.md new file mode 100644 index 0000000..a57e4a6 --- /dev/null +++ b/content/2020-03-30-my-love-and-hate-relationship-with-nodejs copy.md @@ -0,0 +1,41 @@ +~ title: My love and hate relationship with Node.js +~ description: How I found a way to love and hate Node.js with a passion +~ slug: /my-love-and-hate-relationship-with-nodejs.html +~ date: 2020-03-30 +~ template: post +~ hide: false + +Previous project I was working on was being coded in [Golang](https://golang.org/). Also was my first project using it. And damn, that was an awesome experience. The whole thing is just superb. From how errors are handled. The C-like way you handle compiling. The way the language is structured making it incredibly versatile and easy to learn. + +It may cause some pain for somebody that is not used of using interfaces to map JSON and doing the recompilation all the time. But we have tools like [entr](http://eradman.com/entrproject/) and [make](https://www.gnu.org/software/make/) to fix that. + +But we are not here to talk about my undying love for **Golang**. Only in some way we probably should. It is an excellent example of how modern language should be designed. And because I have used it extensively in the last couple of years this probably taints my views of other languages. And is doing me a great disservice. Nevertheless, here we are. + +About two years ago I started flirting with [Node.js](https://nodejs.org/en/) for a project I started working on. What I wanted was to have things written in a language that is widely used, and we could get additional developers for. As much as **Golang** is amazing it's really hard to get developers for it. Even now. And after playing around with it for a week I felt in love with the speed of iteration and massive package ecosystem. Do you want SSO? You got it! Do you want some esoteric library for something? There is a strong chance somebody wrote it. It is so extensive that you find yourself evaluating packages based on **GitHub stars** and number of contributors. You get swallowed by the vanity metrics and that potentially will become the downfall of Node.js. + +Because of the sheer amount of choice I often got anxiety when choosing libraries. Will I choose the correct one? Is this library something that will be supported for a foreseeable future or not? I am used of using libraries that are being in development for 10 years plus (Python, C) and that gave me some sort of comfort. And it is probably unfair to Node.js and community to expect same dedication. + +Moving forward ... Work started and things were great. **Speed of iteration was insane**. For some feature that I would need a day in Golang only took me hour or two. I became lazy! Using packages all over the place. Falling into the same trap as others. Packages on top of packages. And [npm](https://www.npmjs.com/) didn't help at all. The way that the package manager works is just horrendous. And not allowing to have node_modules outside the project is also the stupidest idea ever. + +So at that point I started feeling the technical debt that comes with Node.js and the whole ecosystem. What nobody tells you is that **structuring large Node.js apps** is more problematic than one would think. And going microservice for every single thing is also a bad idea. The amount of networking you introduce with that approach always ends up being a pain in the ass. And I don't even want to go into system administration here. The overhead is insane. Package-lock.json made many days feel like living hell for me. And I would eat the cost of all this if it meant for better development experience. Well, it didn't. + +The **lack of Typescript** support in the interpreter is still mind boggling to me. Why haven't they added native support yet for this is beyond me?! That would have solved so many problems. Lack of type safety became a problem somewhere in the middle of the project where the codebase was sufficiently large enough to present problems. We started adding arguments to functions and there was **no way to implicitly define argument types**. And because at that point there were a lot of functions, it became impossible to know what each one accepts, development became more and more trial and error based. + +I tried **implementing Typescript**, but that would present a large refactor that we were not willing to do at that point. The benefits were not enough. I also tried [Flow - static type checker](https://flow.org/) but implementation was also horrible. What Typescript and Flow forces you is to have src folder and then **transpile** your code into dist folder and run it with node. WTH is that all about. Why can't this be done in memory or some virtual file system? Why? I see no reason why this couldn't be done like this. But it is what it is. I abandoned all hope for static type checking. + +One of the problems that resulted from not having interfaces or types was inability to model out our data from **Elasticsearch**. I could have done a **pedestrian implementation** of it, but there must be a better way of doing this without resorting to some hack basically. Or maybe I haven't found a solution, which is also a possibility. I have looked, though. No juice! + +**Error handling?** Is that a joke? + +Thank god for **await/async**. Without it, I would have probably just abandoned the whole thing and went with something else like Python. That's all I am going to say about this :) + +I started asking myself a question if Node.js is actually ready to be used in a **large scale applications**? And this was a totally wrong question. What I should have been asking myself was, how to use Node.js in large scale application. And you don't get this in **marketing material** for Express or Koa etc. They never tell you this. Making Node.js scale on infrastructure or in codebase is really **more of an art than a science**. And just like with the whole JavaScript ecosystem: +- impossible to master, +- half of your time you work on your tooling, +- just accept transpilers that convert one code into another (holly smokes), +- error handling is a joke, +- standards? What standards? + +But on the other hand. As I did, you will also learn to love it. Learn to use it quickly and do impossible things in crazy limited time. + +I hate to admit it. But I love Node.js. Dammit, I love it :) diff --git a/content/2020-03-30-my-love-and-hate-relationship-with-nodejs.md b/content/2020-03-30-my-love-and-hate-relationship-with-nodejs.md deleted file mode 100644 index a57e4a6..0000000 --- a/content/2020-03-30-my-love-and-hate-relationship-with-nodejs.md +++ /dev/null @@ -1,41 +0,0 @@ -~ title: My love and hate relationship with Node.js -~ description: How I found a way to love and hate Node.js with a passion -~ slug: /my-love-and-hate-relationship-with-nodejs.html -~ date: 2020-03-30 -~ template: post -~ hide: false - -Previous project I was working on was being coded in [Golang](https://golang.org/). Also was my first project using it. And damn, that was an awesome experience. The whole thing is just superb. From how errors are handled. The C-like way you handle compiling. The way the language is structured making it incredibly versatile and easy to learn. - -It may cause some pain for somebody that is not used of using interfaces to map JSON and doing the recompilation all the time. But we have tools like [entr](http://eradman.com/entrproject/) and [make](https://www.gnu.org/software/make/) to fix that. - -But we are not here to talk about my undying love for **Golang**. Only in some way we probably should. It is an excellent example of how modern language should be designed. And because I have used it extensively in the last couple of years this probably taints my views of other languages. And is doing me a great disservice. Nevertheless, here we are. - -About two years ago I started flirting with [Node.js](https://nodejs.org/en/) for a project I started working on. What I wanted was to have things written in a language that is widely used, and we could get additional developers for. As much as **Golang** is amazing it's really hard to get developers for it. Even now. And after playing around with it for a week I felt in love with the speed of iteration and massive package ecosystem. Do you want SSO? You got it! Do you want some esoteric library for something? There is a strong chance somebody wrote it. It is so extensive that you find yourself evaluating packages based on **GitHub stars** and number of contributors. You get swallowed by the vanity metrics and that potentially will become the downfall of Node.js. - -Because of the sheer amount of choice I often got anxiety when choosing libraries. Will I choose the correct one? Is this library something that will be supported for a foreseeable future or not? I am used of using libraries that are being in development for 10 years plus (Python, C) and that gave me some sort of comfort. And it is probably unfair to Node.js and community to expect same dedication. - -Moving forward ... Work started and things were great. **Speed of iteration was insane**. For some feature that I would need a day in Golang only took me hour or two. I became lazy! Using packages all over the place. Falling into the same trap as others. Packages on top of packages. And [npm](https://www.npmjs.com/) didn't help at all. The way that the package manager works is just horrendous. And not allowing to have node_modules outside the project is also the stupidest idea ever. - -So at that point I started feeling the technical debt that comes with Node.js and the whole ecosystem. What nobody tells you is that **structuring large Node.js apps** is more problematic than one would think. And going microservice for every single thing is also a bad idea. The amount of networking you introduce with that approach always ends up being a pain in the ass. And I don't even want to go into system administration here. The overhead is insane. Package-lock.json made many days feel like living hell for me. And I would eat the cost of all this if it meant for better development experience. Well, it didn't. - -The **lack of Typescript** support in the interpreter is still mind boggling to me. Why haven't they added native support yet for this is beyond me?! That would have solved so many problems. Lack of type safety became a problem somewhere in the middle of the project where the codebase was sufficiently large enough to present problems. We started adding arguments to functions and there was **no way to implicitly define argument types**. And because at that point there were a lot of functions, it became impossible to know what each one accepts, development became more and more trial and error based. - -I tried **implementing Typescript**, but that would present a large refactor that we were not willing to do at that point. The benefits were not enough. I also tried [Flow - static type checker](https://flow.org/) but implementation was also horrible. What Typescript and Flow forces you is to have src folder and then **transpile** your code into dist folder and run it with node. WTH is that all about. Why can't this be done in memory or some virtual file system? Why? I see no reason why this couldn't be done like this. But it is what it is. I abandoned all hope for static type checking. - -One of the problems that resulted from not having interfaces or types was inability to model out our data from **Elasticsearch**. I could have done a **pedestrian implementation** of it, but there must be a better way of doing this without resorting to some hack basically. Or maybe I haven't found a solution, which is also a possibility. I have looked, though. No juice! - -**Error handling?** Is that a joke? - -Thank god for **await/async**. Without it, I would have probably just abandoned the whole thing and went with something else like Python. That's all I am going to say about this :) - -I started asking myself a question if Node.js is actually ready to be used in a **large scale applications**? And this was a totally wrong question. What I should have been asking myself was, how to use Node.js in large scale application. And you don't get this in **marketing material** for Express or Koa etc. They never tell you this. Making Node.js scale on infrastructure or in codebase is really **more of an art than a science**. And just like with the whole JavaScript ecosystem: -- impossible to master, -- half of your time you work on your tooling, -- just accept transpilers that convert one code into another (holly smokes), -- error handling is a joke, -- standards? What standards? - -But on the other hand. As I did, you will also learn to love it. Learn to use it quickly and do impossible things in crazy limited time. - -I hate to admit it. But I love Node.js. Dammit, I love it :) diff --git a/content/2020-04-05-remote-work.md b/content/2020-04-05-remote-work.md new file mode 100644 index 0000000..bf75da7 --- /dev/null +++ b/content/2020-04-05-remote-work.md @@ -0,0 +1,37 @@ +~ title: Remote work and how it affects the daily lives of people +~ description: How I found a way to love and hate Node.js with a passion +~ slug: /remote-work.html +~ date: 2020-04-05 +~ template: post +~ hide: true + +I have been working remotely for the past 5 years. I love it. Love the freedom and make your schedule thingy. + +## You work more not less + +I've heard from people things like: "Oh, you are so lucky, working from home, having all the free time you want". It was obvious they had no clue what means working remotely. They had this romantic idea of remote work. You can watch TV whenever you like, you can go outside for a picnic if you want and stuff like that. + +This may be true if you work a day or two in a week from home. But if you go completely remote all these changes completely. I take some time to acclimate but then you start feeling the consequences of going fully remote. And it's not all rainbows and unicorns. Rather the opposite. + +## Feeling lost + +At first, I remembered I felt lost. I was not used to this kind of environment. It felt disoriented and a part of you that is used to procrastinate turns on. You start thinking of a workday as a whole day. And soon this idea of "I can do this later" starts creeping in. Well, I have the whole day ahead of me. I can do this a bit later. + +## Hyper-performance + +As a direct result, you become more focused on your work since you don't have all the interruptions common in the workplace. And you can quickly get used to this hyper-performance. But this mode requires also a lot of peace and quiet. + +And here we come to the ugly parts of all this. **People rarely have the self-control** to not waste other people's time. It is paralyzing when people start calling you, sending you chat messages, etc. The thing is, that when I achieve this hyper-performance mode I am completely embroiled in the problem I am solving and this kind of interruptions mess with your head. I need an hour at least to get back in the zone. Sometimes not achieving the same focus the whole day. + +I know that life is not how you want it to be and takes its route but from what I've learned this kind of interruptions can be avoided in 90% of the case easily just by closing any chat programs and putting your phone in a drawer. + +## Suggestion to all the new remote workers + +- Stop wasting other people's time. You don't bother people at their desks in the office either. +- Do not replace daily chats in the hallways with instant messaging software. It will only interrupt people. Nothing good will come of it. +- Set your working hours and try to not allow it to bleed outside these boundaries and maintain your routine. +- Be prepared that hours will be longer regardless of your good intentions and your well thought of routine. +- Try to be hyper-focused and do only one thing at the time. Multitasking is the enemy of progress. +- Avoid long meetings and if possible eliminate them. Rather take time to write them out and allow others to respond in their own time. Meetings are usually a large waste of time and most of the people attending them are there just because the manager said so. +- The software will not solve your problems. And throwing money at problems neither. +- If you are in a managerial position don't supervise any single minute of workers. They are probably giving you more hours anyways. Track progress weekly not daily. You hired them and give them the benefit of the doubt that they will deliver what you agreed upon. diff --git a/static/style.css b/static/style.css index 223edef..2265ccd 100644 --- a/static/style.css +++ b/static/style.css @@ -155,6 +155,19 @@ p.modified { margin-top: 50px; } +.draft { + color: #ddd; + position: absolute; + top: 500px; + left: 400px; + font-size: 160px; + text-transform: uppercase; + font-weight: 800; + z-index: -1; + transform: rotate(-45deg); + display: block; +} + ::selection { background: #ff0; color: #000; @@ -165,6 +178,10 @@ p.modified { color: #000; } +#replybox { + margin-top: 70px; +} + @media only screen and (max-width:480px) { body { font-size: 18px; @@ -217,6 +234,12 @@ p.modified { code, pre { font-size: 14px; } + + .draft { + font-size: 90px; + top: 400px; + left: 50px; + } } @media (prefers-color-scheme: light) { diff --git a/templates/post.twig b/templates/post.twig index e7d01bd..553c76e 100644 --- a/templates/post.twig +++ b/templates/post.twig @@ -43,7 +43,21 @@ by {{ global.author }} + + {% if options.hide == 'true' %} +
Draft
+ {% endif %} + {{ content }} + +
+ + + -- cgit v1.2.3