Forem: Tomek Skupiński

How Plugin Creep is Killing Your Editor's Performance

Tomek Skupiński — Mon, 15 Apr 2024 12:04:58 +0000

If you'll enjoy reading this post and would like to stay in touch, please subscribe to my newsletter.

Hope you enjoy the read, let me know what you think about it in the comment below or get in touch on Twitter,

Tom

Optimal configuration for a coding editor is a tricky thing. On the one hand, you want your main working tool to stay lean and fast; on the other hand, there are many cool things out there you might want to try. Have too little, and you are missing out on an opportunity to enhance your workflow. Add too much, and you end up with slow startup times, lower performance, and random things ruining your focus. All of which leads to miserable development experience. When you reach this point, you know that Plugin Creep already set in.

What is Plugin Creep?

Plugin Creep occurs when you keep adding new plugins/extensions to your editor. It’s a gradual process that turns your editor into a resource-hungry, hard-to-work-with, and difficult-to-maintain mess. Plugin Creep can affect any software. When writing this post, I noticed the term used in one of the WordPress communities. WordPress is known for the millions of plugins you can use to handle anything you need. It’s also known for getting extremely slow—surprisingly fast. The regression is proportional to the number of plugins you install.

Why does it happen?

Here are the most common reasons why Plugin Creep happens:

Resource Consumption: Each plugin, regardless of size, requires some amount of memory and processing power to function. As the number of plugins increases, this cumulative demand strains your system.
Code Overhead: Plugins are essentially extra code that your editor needs to load and execute. This introduces overhead, especially with poorly optimized plugins, leading to slower startup times and potential lag during editing.
Compatibility Conflicts: Plugins aren't always designed to work perfectly together. They might interfere with each other's code or compete for the same resources, leading to unexpected errors, crashes, or strange behavior within your editor.
Dependency Issues: Some plugins rely on specific versions of other libraries or software components. Over time, as plugins and dependencies update, maintaining a compatible and functional setup becomes a complex juggling act.

As you can see, Plugin Creep is mainly a problem of accumulation. A single plugin will have negligible impact, but the combined effect of multiple plugins adds up. Each plugin brings its own resource demands and potential conflicts.

Why Plugin Creep is Dangerous

Plugin Creep can quickly snowball into a serious issue. If you keep it unchecked, it can seriously hinder your productivity. Here’s how:

Performance Degradation: Each plugin adds to the overall resource consumption of your editor. Over time, this can lead to slow startup times, lag during editing, and even crashes, especially on machines with limited resources.
Stability Issues: Compatibility problems between plugins can lead to unexpected crashes, errors, or strange behavior in your editor. Debugging these issues can be time-consuming and derail your daily work.
Feature Fatigue: With a plethora of features at your fingertips, it's easy to fall into the trap of "feature fatigue." You might spend more time configuring than actually coding.
Maintenance Burden: Keeping plugins updated becomes a chore. New features might break compatibility with your current setup, and conflicts arise as plugins evolve independently.

You need your editor to be fast and sharp. Somebody might say that you won’t even notice a few milliseconds of difference in startup time, but it adds up. The slower your editor is, the easier it gets to get out of flow and lose your focus.

What can you do to avoid it

Here is a set of things you can do to avoid Plugin Creep.

Use built-in tools

Most modern editors come packed with powerful features under the hood. Before reaching for a plugin, you should at least try working with built-ins. Invest time into learning built-in features, reading documentation, and learning keybindings. The best way to avoid Plugin Creep is to eliminate the need to install new plugins.

You might be using the wrong editor

Sometimes it might be better to look for another editor. If you notice that your tool of choice wasn’t made with your workflow in mind, maybe there is something out there that will suit you better. A lot of problems people encounter when over-configuring software come from the fact that they try to make it what they would like it to be, and it might have never been designed to support their way of working in the first place.

Take your time to find tools that suit you and easily integrate into your workflow. Don’t use something only because everybody is doing it. Find your own way. You will be using those things daily - invest time into building your toolbox.

Audit things you install

Before hitting install, take a closer look at the plugin.

Review the opened issues. Are those being addressed? You don’t want to step on an issue that won’t ever be solved. It doesn’t mean that the plugin needs to be actively developed. Some of the best plugins I used had no new commits in the last 4–5 years. They just do the job, and there is no need to change them. You can rely on their stability.

What’s the development and user experience philosophy behind it? If you build the core of your workflow around a plugin that changes often, your workflow will be subject to frequent changes as well.

See what the community thinks about it. If there are no opinions about it, there is a high chance you are a beta tester, and as any pioneer, you will pay the price for it.

Focus on the problem

Before rushing to install plugins, step back and truly analyze the problem you're facing. Is there a gap in your editor's native functionality? Maybe you are missing something in your workflow. What if you wrote a simple function to do the job?

Clearly defining the core problem will help you determine if a plugin is truly the right answer, and it can guide you toward selecting the best solution rather than just piling on more features.

Don’t fix what’s not broken

If you have a mature workflow and tinkering around with your editor config isn’t your thing, it’s completely fine to just leave it alone. Don’t fix what is not broken. Even after I moved from Vim to Neovim, I used my old Vimscript-based config for years before rewriting it to Lua. It did the job fine and worked well.

Load plugins when they are needed

Many editors offer the ability to selectively load plugins. I don’t load most of my Neovim plugins on startup and only load them when I first use them. You can also load plugins per file type, or on certain events. This significantly reduces background overhead and can make a huge difference in your editor’s performance.

Prune your config

Your editor is a piece of software, and you should treat it as any other tool in your stack. When you notice it’s slowing down, don’t ignore it. Spend some time to see why and whether you can eliminate the problem. The sooner you do this, the better. Sometimes it will be as simple as updating plugins or removing the ones you no longer use.

If you let it accumulate, it will become this terrifying piece of mud you don’t really want to touch, and in extreme situations, you might need to declare editor config bankruptcy and start over.

Learn to debug your editor

Most modern editors offer amazing tools to debug their behavior and performance. It’s worth looking into it and learning how to debug yours. It’s equivalent to being able to do some small repairs around your car. You might not need it if you are a casual driver, but every professional truck driver will tell you it’s essential for their profession.

Final word

I’ve spent countless hours changing my Neovim config. When I first started to work in Vim, I learned the hard way that overloading it with plugins is a bad idea. Not only does it become slow, but you also end up not using most of it because your brain can only process a limited amount of new things at any time. I hope this article will help you avoid my mistakes.

How Loosing First Programming Job Helped My Career

Tomek Skupiński — Mon, 20 Nov 2023 17:00:32 +0000

Currently, I'm reading "Same as Ever" by Morgan Housel. In one chapter, he writes about how adversity often spurs human growth. This chapter took me back six years, to the time when, after quitting the consulting career path and learning for some time, I got my first coding job and lost it soon after.

I'll spare you the details, but the gist is this: after a challenging six months, my journey with the company (let's call it Company A) came to an end, and I was let go. Company A was looking for junior with some more applicable skills, and I was missing those skills. It was a simple mismatch of expectations, but for me, it felt like a small end of the world.

I was lucky enough that the other company (Company B) I previously interviewed for was still interested and wanted to hire me. Before I joined Company A, I took part in demo day at Company B where I worked on simple tasks with more senior developers. I made a good impression, they offered me a job, but I liked the Company A more and decided to go this way. After Company A let me go, Company B was happy to take me in.

I joined Company B with a completely different mindset to the one I had when joining Company A. My imposter syndrome hit the roof, I questioned my choice to change profession. I exaggerated all my mistakes and lost most confidence in my skills and choices. I was under a serious amount of stress and I could feel it.

At the same time, this challenging period, while tough, was incredibly motivating. Determined not to repeat past mistakes, I dedicated countless hours to learning and becoming self-reliant. I was fortunate to have a CTO who had a great process for training junior developers, and helpful people in my team who patiently tolerated my countless questions. Looking back, I couldn't have asked for a better environment to kick-start my programming career.

Even after gaining independence and confidence in my work, the motivation from those early struggles stuck with me. To this day, I strive to bring value quickly to new teams and make myself useful as soon as possible. I still learn after hours, and try to be better at my profession.

Reflecting on it, my experience at Company A was a wake-up call, a mix of fear and realization. I knew I never want to go through something similar again. I'm aware I don't always control everything, but I'm dedicated to do everything I can to make things work, within healthy boundaries.

This part of my programming journey, though difficult, has been valuable. I'm happy it played this way, it shaped me as a professional, and helped build good habits. It also made me more cautious when interviewing.

If you are going through something similar remember, however tough and groundbreaking it seems, it's up to you what you will do with it. With a bit of luck and a lot of grid, you can come out stronger on the other side.

Choosing tech stack for side project

Tomek Skupiński — Mon, 13 Nov 2023 16:05:05 +0000

I agonized over the tech stack I should use to build the project. To streamline the process and avoid falling into procrastination, I time-boxed the entire exercise. When I reached ~80% of allocated time, I knew I needed to make a decision soon. Prior to that, I tried to answer different questions:

What should backend be written in? I recently picked up Rust, and it would be great to battle test it.
Should this be API + client or monolith? I was tempted by Next.js as I wanted to try it for some time, and it offers a bit more sensible development experience than pure React.
Where should I host it? I thought about using AWS as it would be a nice learning opportunity.

At some point, I realized that I couldn't answer these questions without understanding why I wanted to build this project. I knew that my project's features can be implemented with any tech I choose. Now I needed to set my own priorities, and realize what's in this project for me. The main thing here was understanding that I really care about getting this project to production. In the past, when I built something, it was because I wanted to learn or try new tech. This time, I cared about putting it out into the world.

Phrasing this as my highest priority simplified a lot of things. Now, having multiple options on the table I could simply ask myself "Which one will allow me to ship faster and not hate myself in the future if I need to extend it?". I still going to learn a lot from building it, but at least 80% of stack is familiar, which with limited resources I have gives me a good starting point to get where I wanna be with this.

As for decision itself I decided to go with Ruby on Rails. Why?

Ruby <3
it's framework I know best
it offers great development experience
it's made with bootstrapped projects in mind, perfect for solo/small team development
with web views I can use it to develop mobile apps and I might need it for my product
monolith just makes sense for solo development, I don't wanna jump between repos
it's a good opportunity to dive deeper into Hotwire (a modern HTML-over-the-wire solution)

Of course Rails comes with some downsides but if I experience major ones it will mean that my project is at a stage where it is successful enough, and those are good problems to have. First I need to get there and Rails is the fastest way for me.

As for other tools, I'm gonna stick to Heroku for hosting to limit time I need to allocate into infrastructure management. Might move it to AWS at some point, but for now, my aim is to keep things simple and concentrate on development.

Let me know what is your decision process in similar situations.

Destructuring in JavaScript. What is it? How does it work? Why should you use it?

Tomek Skupiński — Tue, 10 May 2022 05:42:32 +0000

What is destructuring?

Destructuring in JavaScript is a powerful feature that lets you extract values from data structures like arrays and objects. It can be used to make your code more readable and concise.

In this blog post, we'll take a look at what destructuring is, how it works, and some of the benefits of using it.

How does destructuring work?

Destructuring is simple though it might seem magical and confusing at first glance. It works by taking an array or object and creating variables from its properties.

Destructuring arrays

For example, let's say you have an array of numbers called myNumbers:

const myNumbers = [1, 2, 3, 4, 5];

You can use destructuring to create variables from the elements of the array.

const [first, second, third, fourth, fifth] = myNumbers;

console.log(first); // 1
console.log(second); // 2
console.log(third); // 3
console.log(fourth); // 4
console.log(fifth); // 5

As you can see, destructuring lets you extract data from arrays and assign it to variables.

Destructuring objects

You can also use destructuring to extract data from objects.

For example, let's say you have a person object with properties name, age, and country:

const person = {
  name: ' John Doe ',
  age: 30,
  country: ' United States '
};

You can use destructuring to create variables from the object's properties.

const { name, age, country } = person;

console.log(name); // John Doe
console.log(age); // 30
console.log(country); // United States

As presented above we can use destructuring to extract object properties and assign them to the variables.

Destructuring nested data structures

Destructuring can also be used to extract data from nested data structures.

Let's say you have an array of objects with properties name, age, and country.

const people = [
  {
    name: ' John Doe ',
    age: 30,
    country: ' United States '
  },
  {
    name: ' Jane Doe ',
    age: 20,
    country: ' Canada '
  }
];

You can use destructuring to create variables from the nested object's properties.

const [{ name: name1, age: age1, country: country1 }, { name: name2, age: age2, country: country2 }] = people;

console.log(name1); // John Doe
console.log(age1); // 30
console.log(country1); // United States

console.log(name2); // Jane Doe
console.log(age2); // 20
console.log(country2); // Canada

This helps us simplify more complex data structure and extract values form each element of array.

Destructuring function arguments

Destructuring can also be used to extract data from function arguments.

Given that we have a function that takes an object with properties name, age, and country:

function sayHello({ name, age, country }) {
  console.log(`Hello, my name is ${name}. I'm ${age} years old and I'm from ${country}.`);
}

You can use destructuring to extract the data from the object and pass it as an argument to the function.

sayHello({
  name: ' John Doe ',
  age: 30,
  country: ' United States '
});

// Hello, my name is John Doe. I'm 30 years old and I'm from United States.

As you can see, destructuring makes it easy to extract data from data structures and pass it to functions as arguments.

Benefits of Using Destructuring

Destructuring can be used to make your code more readable and concise. To show it we will compare code that uses destructuring with one that doesn't for the examples we wrote above.

Array comparison

Let's take our myNumbers array and try to sum up all the integers inside it.

Without destructuring, you would have to write the following code:

const myNumbers = [1, 2, 3, 4, 5];

let sum = 0;

for (const num of myNumbers) {
  sum += num;
}

console.log(sum); // 15

With destructuring, you can write the following code:

const myNumbers = [1, 2, 3, 4, 5];

const [first, second, third, fourth, fifth] = myNumbers;

const sum = first + second + third + fourth + fifth;

console.log(sum); // 15

As you can see, destructuring can make your code more concise.

Let's take a look at object examples and how restructuring can help us make code more readable.

Object comparison

We will use our person object from the previous example.

Without destructuring, you would have to write the following code:

const person = {
  name: ' John Doe ',
  age: 30,
  country: ' United States '
};

console.log(person.name); // John Doe
console.log(person.age); // 30
console.log(person.country); // United States

With destructuring, you can write the following code:

const person = {
  name: ' John Doe ',
  age: 30,
  country: ' United States '
};

const { name, age, country } = person;

console.log(name); // John Doe
console.log(age); // 30
console.log(country); // United States

Using destructuring makes our code more readable.

Extracting function arguments comparison

Last but not least let's see how using destructuring to extract function arguments can help us make it easier to understand and work with:

We will use the sayHello function we are already familiar with from the example above.

Without destructuring, you would have to write the following code:

function sayHello(person) {
  console.log(`Hello, my name is ${person.name}. I'm ${person.age} years old and I'm from ${person.country}.`);
}

sayHello({
  name: ' John Doe ',
  age: 30,
  country: ' United States '
});

With destructuring, you can write the following code:

function sayHello({ name, age, country }) {
  console.log(`Hello, my name is ${name}. I'm ${age} years old and I'm from ${country}.`);
}

sayHello({
  name: ' John Doe ',
  age: 30,
  country: ' United States '
});

Our destructured example is both more concise and readable.

Conclusion

Destructuring is a powerful feature that can be used to make your code more readable and concise. It is a convenient way to extract data from data structures without having to write a lot of code.

If you're not already using destructuring in your JavaScript code, I encourage you to give it a try - it is worth adding to your toolbox.

Main features of JavaScript programming language

Tomek Skupiński — Sat, 30 Apr 2022 05:56:29 +0000

JavaScript is a high-level interpreted programming language. It is a language that is also characterized as dynamic, weakly typed, prototype-based, and multi-paradigm.

History

JavaScript was originally developed by Brendan Eich in 1995 while he was working for Netscape. It was originally called LiveScript but was renamed to JavaScript in order to capitalize on the popularity of Java. The language was standardized in the ECMAScript language specification in 1997.

Usage

JavaScript is used in conjunction with HTML and CSS to create web pages and web applications. It can be used to add interactive features to web pages, such as games, form validation, and animated graphics.

JavaScript is also used for server-side programming with technologies such as Node.js. This enables JavaScript to be used for developing web applications and server-side applications.

Features

Some of the features that make JavaScript unique are:

dynamic typing
prototype-based inheritance
first-class functions

Dynamic Typing

In JavaScript, variables are not statically typed. This means that you don't have to specify the data type of a variable when you declare it. The data type of a variable is determined automatically based on the value that is assigned to it.

For example, the following code declares a variable without specifying a data type:

let foo;

The data type of the foo variable is automatically set to undefined. However, if we assign a value to the foo variable, the data type will be automatically set to the type of the value:

let foo = 42; // foo is now a Number

let foo = 'bar'; // foo is now a String

let foo = true; // foo is now a Boolean

This dynamic typing is one of the reasons why JavaScript is a very flexible language. It allows you to write code without having to specify the data types of variables upfront.

Prototype-based Inheritance

In JavaScript, inheritance is implemented using prototypes. A prototype is an object that defines the properties and methods for a class of objects.

When you create a new object, you can specify its prototype. The new object will then inherit all the properties and methods from the prototype.

For example, let's say we have a Person prototype with a name property and a sayHello() method:

function Person(name) {
  this.name = name;
}

Person.prototype.sayHello = function() {
  console.log('Hello, my name is ' + this.name);
};

We can then create a new Person object and call the sayHello() method:

let john = new Person('John');

john.sayHello(); // Hello, my name is John

As you can see, the john object inherits the name property and the sayHello() method from the Person prototype.

First-class Functions

In JavaScript, functions are first-class citizens. This means that they can be treated like any other value in the language.

For example, you can assign a function to a variable:

let foo = function() {
  // do something
};

You can also pass a function as an argument to another function:

let bar = function(foo) {
  // do something with foo
};

bar(foo);

And you can return a function from another function:

let baz = function() {
  return function() {
    // do something
  };
};

let qux = baz();

qux(); // this will execute the function that is returned from baz()

Because functions are first-class citizens in JavaScript, they can be used in a wide variety of ways.

Summing up

These are just some of the different JavaScript language features and characteristics. JavaScript is a powerful and popular language that is used in many different ways. Explore the different features of JavaScript to see how you can use it in your own programs.

What is recursion in programming and when to use it?

Tomek Skupiński — Tue, 26 Apr 2022 14:28:58 +0000

What is recursion in programming?

In computing, recursion is a method where the solution to a problem is found by breaking it down into smaller subproblems. This process is then repeated until the original problem is solved. The classic example of recursion is the Towers of Hanoi problem.

To better understand recursion, let’s look at an example. Let’s say you want to calculate the factorial of a number. The factorial of a number is the product of all the positive integers less than or equal to that number. For example, the factorial of 5 is 5! = 5 4 3 2 1 = 120.

You could calculate the factorial of a number using a loop like this:

def factorial(n):
    result = 1
    for i in range(1, n+1):
        result *= i
    return result

However, this iterative solution is not very efficient. A more efficient solution is to use recursion.

 def factorial(n):
     if n == 1:
         return 1
     else:
         return n * factorial(n-1)

This recursive solution is more elegant and efficient. When you call the factorial function with some value of n, it will:

Check if n is equal to 1. If it is, it will return 1. If n is not equal to 1, it will return n * factorial(n-1).

As you can see, this recursive solution breaks the problem down into smaller subproblems. It will keep breaking the problem down into smaller subproblems until it reaches a point where the subproblem is trivial to solve. Then, it will start solving the subproblems from the bottom up.

The factorial function is a simple example of recursion, but there are many other examples of recursion in computer programming. Other common examples include the Fibonacci sequence and quicksort.

When should you use recursion?

Recursion can be a very powerful tool, but it is important to know when to use it and when not to use it. Recursion is best used when the problem can be broken down into smaller subproblems that are similar to the original problem.

For example, the problem of sorting a list of numbers can be broken down into smaller subproblems: sorting a smaller list of numbers, sorting a list of numbers with the first element removed, etc. This is why the quicksort algorithm is recursive.

On the other hand, recursion is not always the best solution. If the problem cannot be broken down into smaller subproblems, or if the subproblems are not similar to the original problem, then recursion is probably not the best solution.

For example, the Towers of Hanoi problem can be solved recursively, but it would be much more difficult to solve iteratively.

When in doubt, it is usually best to try an iterative solution first. If an iterative solution is not possible or is too difficult, then you can try a recursive solution.

Pros and cons of recursion

Like any tool, recursion has its own set of pros and cons.

Some of the pros of recursion include:

Simplicity: Recursive solutions can often be simpler and easier to understand than iterative solutions.

Generality: Recursion can be used to solve problems that cannot be solved using iterative methods.

Flexibility: Some problems are easier to solve using recursion than iteration.

Some of the cons of recursion include:

Overhead: Each time a recursive function is called, there is some overhead involved. This can make recursive solutions slower than iterative solutions.

Memory usage: Recursive solutions often use more memory than iterative solutions because each time a recursive function is called, another stack frame is added to the call stack.

Debugging: Debugging recursive solutions can be difficult because it can be hard to trace the execution of the program.

When to avoid recursion

There are some situations where you should avoid using recursion.

Some situations where recursion might not be the best solution include:

Problems that can be solved using simple iteration
Problems that require only a small amount of data
Problems that are not well suited to being broken down into smaller subproblems

Summing up

Recursive solutions are not always the best solution, but they can be a powerful tool in your toolbox. If you are unsure whether or not to use recursion, try an iterative solution first. If an iterative solution is not possible or is too complex, then you can try a recursive solution.