
I’ve been reading tech Medium for a few years now. There is this clickbait phenomena where authors tend to write something along the lines of:

- “some slightly old technology is going to die, here’s what to use instead”
- “stop using that new technology, here’s why”
- “this technology vs that technology, why this is always better than that technology”.

you get the idea.

Freedom of speech is a beautiful thing that allows such content on the platform and thank God I am NOT a moderator nor in charge of stopping these kinds of content.

### Doing anything for the clout

One possible motivation would be to generate outrage from folks like myself. If you’re reading this article they already have achieved their goal of chasing clout. Any publicity is good publicity. They are satisfied with their comment section fighting them why they’re wrong or why they are right.

### Jumping on the hype train

When carbon came out a few months ago, I’ve seen countless articles suggesting “why you should re-write your entire C++ project using carbon”!

Why? just because there’s this new trendy thing should we throw all the things we are using (and that in most cases are making money from in our companies we work in) away?

That notion by itself is at best laughable.

### Negligence towards Tradeoff

There are countless comparison SEO hells in the tech articles. As a software engineer one of the most useful skills you acquire is to detect trade-offs and choose between technologies and tools available to reduce your cost and maximize your performance.

These kind of articles completely forget that fact and try to tell you why something is always better than that technology and why you should never even consider using that technology.

Don’t even get me started on the “that technology is dead …” articles.

### My two cents to these writers

Spend time on your articles. You’re readers are humans, not some crawler robot trying to index your content based on key word frequency or content score. Have some respect for our time and well being.

Closing this article with a quote from beloved Scott Hanselman:

There are a finite number of keystrokes left in your hands before you die. stop wasting your keystrokes.

Thank you.

stop wasting your keystrokes, my honest rant without a clickbait


## Laying down the knowledge foundation

Understanding your knowledge involves breaking it down into four parts:

### 1. Things you know that you know (Known knowns)

You've got a solid grasp on certain aspects in your field. These are the things you've done before, have a track record of success, and can easily replicate. Your confidence in these areas is based on proven experiences and successful projects, making them feel almost second nature.

### 2. Things you don't know that you know (Unknown knowns)

Intuition plays a role here. It's the ability to leverage your past experiences and knowledge to navigate unfamiliar territories. For instance, if you're familiar with queue data structures, trying to understand something like RabbitMQ becomes less daunting because you can draw on your existing knowledge.

### 3. Things you know that you don't know deep enough (Known unknowns)

These are the areas where you've heard about certain concepts but haven't invested enough time to gain a deeper understanding. To tackle these:

#### Use Eisenhower Matrix for Efficient Improvements

Prioritize your knowledge gaps based on urgency and importance. Concentrate on high-importance concepts within your expertise, going deep to enhance your skills efficiently.


#### Going deep

Opt for deep work over shallow work. Proficiency isn't accidental. it comes from intentional, deliberate and focused practice. Delve into your known unknowns with deliberate efforts to deepen your understanding.

### 4. don't know that we know (Unknown unknowns)

There's a vast realm of things you're not even aware of not knowing. Exposure is the key to reducing these unknown unknowns. Immerse yourself in tech books, explore new concepts, and keep up with emerging technologies. The more you expose yourself, the more you uncover what you don't know and need to know.

## The competence-confidence loop

Engaging in tasks that initially seem intimidating is crucial. Success or failure, each experience contributes to personal growth. Recognize that failures are stepping stones to success. Through this continuous cycle, not only do you become more competent, but you also boost your confidence as a software engineer. Remember, the key is to keep growing and evolving.

Competence creates confidence and confidence helps you become more competent. This is a positive feedback loop you can leverage to go to the next level in your career, as a software engineer.

Developing self-confidence as a software engineer


> “I cannot remember the books I've read any more than the meals I have eaten; even so, they have made me.” -Ralph Waldo Emerson

When I read books, especially those on technology and psychology subjects (I'm not much into fiction), I often find myself wondering, "Why am I reading this if I'll forget most of it later?". This thought can be discouraging because our human brains tend to evaluate my daily activities based on the rewards I expect from getting them done.

Reading books and maintaining that student mentality can feel like a challenging long-term investment in today's world.

### setting the right expectations: your brain is not a hard drive


From an evolutionary perspective, our brain's primary role is to support our survival instinct by vividly recalling our negative experiences to prevent their repetition in the future, for example thousands of years ago, if you were walking around in the forest and ate a funny looking fruit that was venomous you would be remembering every detail about it for the rest of your life, not to eat it ever again because of the horrible experience it was. This is why we often remember bad memories more vividly than good ones.

Reducing this powerful biological computer to a mere hard drive is a disservice to the nature. It's not realistic to expect to remember every word we read. Reflecting on myself and my own experiences throughout my life, I blame modern school habits for forming such unrealistic expectations.

### it's important to build critical thinking

One of the most useful skills you can develop is the ability to distinguish between bad books and good books. To achieve this you have to read a lot of books without thinking about their ratings and coming up with your own conclusions. Critical thinking helps you take everything with a grain of salt, meaning just because it's written in a book doesn't mean it's true (unless a respected proof is provided)

My two cents for recognizing good books are the following points:

1. Are knowledge gateways to many other references. You will know what other concepts to pursue after you're finished reading it
2. Not only do they teach you what you know you don't know, but also they help you resolve your unknown unknowns (find out what you don't know that you don't know)
3. Good books have a great distribution of shallow and deep concepts throughout so it's more interesting and easier to keep on going

### Connecting the dots and emotional charge

It's essential to make an emotional connection with what you're reading. When you're emotionally engaged with a subject, you're more likely to remember and understand it. This can involve finding personal relevance in the material, such as relating it to your own experiences or passions.

For example couple of years ago, I started specializing in the software industry. I started reading "The pragmatic programmer" which was one of the top recommended books for developers to read. I could read it without problems but I wouldn't say I necessarily understood what the concepts meant, because I did not have the industry knowhow to really appreciate what was written.

Effective reading goes beyond passive absorption of information. It's crucial to actively engage with the text. This means connecting new knowledge to what you already know. Try to relate the information to your existing understanding or experiences. Don't be afraid to ask questions while you read and jot them down. Later, revisit these questions to gain a deeper understanding or seek answers. This active involvement helps create a web of interconnected knowledge.

### Use it before you lose it

The ultimate goal of reading should be practical application. It's crucial to find ways to apply the knowledge you've gained. This could involve using the information in your work, applying it to problem-solving, or sharing your insights with others. When you actively use what you've read, you not only solidify your understanding but also make the knowledge a valuable part of your life.

### It's okay to revisit your previous books

Re-reading is a valuable strategy to reinforce your understanding and retention of important concepts. On the first read, you might grasp the surface-level knowledge. Revisiting the same material allows you to dig deeper and uncover nuances or details you might have missed initially. It's like peeling back layers of understanding with each re-read. It's especially helpful for complex or dense texts.

> "No man ever steps in the same river twice, for it's not the same river and he's not the same man" -Heraclitus


overcoming the fear of forgetting what you read


As of 2023, with the emergence of generative AI and tools like chatGPT, the integration of AI into developers' workflows has become quite common. AI now comprehends our code, offers suggestions, generates different kinds of tests, and provides explanations that would otherwise require manual searching on Google or Stack Overflow.

Back in 2021, I had the opportunity to try out the beta version of Copilot, and I must say, it was truly astonishing (still is!). It significantly slashed the time I spent writing repetitive code, although there were instances when it ended up being a bit obtrusive. At that time, I began learning Go, but I had to disable the GitHub Copilot extension. This was because I was trying to grasp the language's syntax, but the extension was consistently auto-completing my code, creating a bit of a hindrance.

Apart from that observation, I stumbled upon an interesting idea, which called "collateral knowledge" or "chain of learning." This simply implies that while attempting to grasp new concepts, numerous questions might crop up that encourage you to delve deeper and acquire additional knowledge. This chain of curiosity and learning contributes to personal growth and a better comprehension of the world around you. Particularly in the realm of programming, it can transform you into a more adept software engineer, moving beyond the role of mere developer.

Using AI for learning is akin to consuming fast food – it's quick and easy, but lacks substantial nourishment. While it's true that you can generate a plethora of data by employing multiple prompts to learn various things, this doesn't quite compare to the experience of having over 30 tabs open, toggling between them, and grappling with the material until you truly understand it. In my view, the more effort you invest in understanding concepts, the longer that understanding will endure, and the more effectively you'll be able to apply it across diverse scenarios.

Use AI for text-formatting, composing emails and other shallow tasks, but not for learning. learn it yourself.

why i won't deliberately use AI for programming


As software engineers, a significant part of our work involves creating data pipelines where several steps involve initializing and converting values based on different data sources. However, handling exceptions and potential errors at each step can quickly make the code hard to follow and nested. In this article, we explore how the Maybe monad can help simplify data pipelines and improve code readability.

### The problem

Let's consider the following scenario in a microblogging application: we want to determine the number of likes the first comment of a post has. The code might look like this:

```js
const postId = 34;
const postObject = repository.findOneById(34);
const postComments = postObject.comments;
const firstComment = postComments.first();
const numberOfLikes = firstComment.likes;
```

In this seemingly simple example, several things can go wrong, such as database connection issues, not finding the specific post, absence of any posts, or no comments or likes on the post. To ensure robustness, we need to handle exceptions and errors at each step.

### The Imperative Approach

To handle errors and exceptions, we often resort to nested if statements and try-catch blocks. However, this approach quickly becomes complex and hard to manage. Here's an example of the imperative approach to handle errors in the code:

```js
const postId = 34;
try {
    const postObject = repository.findOneById(34);
    if (postObject != null) {
        const postComments = postObject.comments;
        if (postComments.length > 0) {
            const firstComment = postComments.first();
            const numberOfLikes = firstComment.likes;
            if (numberOfLikes != null) return numberOfLikes;
            else 0;
        }
    }
} catch (e) {
    throw e;
}
```

As we can see, the code becomes convoluted and harder to follow as we add more steps that depend on previous ones. This mixing of implementation details with data operations leads to decreased code readability and maintainability.

### The Maybe Monad

To simplify the handling of complex data pipelines, we can utilize the Maybe monad. A monad is a design pattern that abstracts the pipeline implementation by wrapping a value with a specific type. In this case, we'll create a class called "Maybe" that encapsulates the value and provides a bind method for chaining operations.

Here's the definition of the Maybe class and its bind method:

```js
class Maybe {
    value;
    constructor(value) {
        this.value = value;
    }
    bind = function (func) {
        const newValue = func(this.value);
        // here we can decide to do anything with our data
        // we can implement all sorts of gaurds, exceptions handlers here
        return Maybe(newValue);
    };
}
```

### Refactoring with the Maybe Monad

Using the Maybe monad, we can rewrite the previous code in a more concise and readable manner:

```js
const postId = 34;
const numberOfLikes = Maybe(postId)
    .bind(repository.findOneById)
    .bind((post) => post.comments)
    .bind((comments) => comments.first())
    .bind((comment) => comment.likes);
```

By leveraging the bind method of the Maybe monad, we can chain the data operations while encapsulating error handling and exception management within the Maybe class itself. This abstraction allows us to focus on the core logic of the data pipeline, improving code readability and maintainability.

Monads, such as the Maybe monad, provide a design pattern that simplifies the handling of data pipelines by abstracting the implementation details and encapsulating values within a specific type. By separating the core logic from error.


understanding declarative javascript using monads


Software development field is moving too fast. It’s so hard to keep up 100% with latest trends and new technologies. In my opinion it is one the cons of becoming a software engineer. You have to be willing to study lots of new technologies on a daily basis to be able to stay fresh and relevant.

Some of the technology trends are fad and short-lived. They are not going to be something that’s used by a lot of companies in the future but some of them are here to stay.

There’s a common term in JavaScript ecosystem called “JavaScript fatigue” describing newcomer’s Exhaustion of the current state of the endless number of JavaScript frameworks and libraries which seemingly do the same thing with different names.

In this article I intend to shine light on some of the ideas surrounding this issue we are facing and share my opinions on it.

Put emphasis on the timeless concepts
Try mastering protocols, Their history and the philosophy behind them. protocols are the underlying principles underneath all of the libraries and tools we are using on a daily basis.

For example, HTTP, TCP, gRPC or Web Sockets are always maintain their definition in terms of technical specs and functionality. What you expect from a HTTP 1.1 request is as solid as bedrock and has never changed since 1997.


HTTP 1.1 RFC, Try reading RFCs as a hobby for in your spare time, You’ll thank me later :D
Emphasis on learning timeless concepts and building blocks frees you from paying too much attention to the libraries that implement them and even better, Mastering fundamentals lets you learn new tools and libraries very rapidly.

The best camera is the one you already own, stay focused
Cloudflare just announced using new reverse proxy instead of nginx and made a call for open sourcing it. what happens to nginx now? Nothing. Many organizations will keep using it because it is good enough for their needs and not all of us should keep up with the latest shiny thing or make new frameworks for ourselves.

There are many instances when people make new tech to solve their problems. It is important to pay attention to FOMO (fear of missing out). Just because someone is using something fresher doesn’t mean you should switch too.

You can always port your existing knowledge to new technology
Imagine using redis or memcached in your projects, you are already familiar with key-value pair in-memory databases. One day there’s a new modern replacement for them called dragonfly.

you already have a good understanding how that new thing works because you are proficient in the less modern tech. You can quickly pick that up if needed and port your legacy knowledge to the new tech so you don’t need to fear missing out.

Underrated skill of our generation, learning what to learn
Working in the software industry, you’ll quickly notice you can’t learn everything. It is much about what you ignore than what you pay attention to. As said in the previous section, timeless concepts let you make better decisions in what to learn next and what areas need more of your limited attention.

You have to learn the ability to quickly understand what to ignore and what to pay attention to.


Many dots may come up but you don’t have to connect them!
Deprecated or old doesn’t always mean useless
There are many web applications built on top of jQuery, working really well serving their customers. Rewriting such applications is just too much work and my not deliver any new value to the business. If new tech doesn’t bring any new business value to your customers you may want to reconsider using it in the first place.

If you enjoy this much chaos, more power to you!
Ending this short article with the notion that, there are many people who deeply appreciate how fast things are moving and also are into the chaos surrounding the whole ecosystem. I’m not by no means against this preference and want to mention it is just not my cup of tea. If you like this much chaos, more power to you! stay open-minded but also intentional at the same time.

maintaining my sanity in a world full of new shiny technologies

Recently I finished reading a great book called “A Philosophy of Software Design” written by John Ousterhout. In this article, I am going to distill everything I’ve learned throughout my journey and try to apply them to Vue.js ecosystem.

### Complexity
In the first and second sections, the book teaches us to fight complexity in our systems, we must take two important actions:

Eliminate complexity by writing shorter and more obvious code
Encapsulate complexity in components (or modules) so that other developers working on the project are not exposed to it all at once
These points may seem obvious or trivial at first, but personally I've seen engineers with all levels of expertise make the same mistakes over and over again (including myself!).

So to tackle this problem we should first learn the definition, symptoms and the possible causes of complexity.

### Definition
“Complexity is anything related to the structure of a software system that makes it harder to understand or modify.”

### Symptoms
Complexity in software systems has 3 major symptoms:

#### Change amplification
“Change amplification means a seemingly simple change requires code modifications in many different places.”

Meaning there are a lot of couplings in our system which breeds complexity.

#### Cognitive load
“Cognitive load is measured by how much a developer needs to know in order to complete a task.”

#### Unknown unknowns
“it’s not obvious which pieces of code must be modified to complete a task, or what information a developer must have to carry out the task successfully.”

Causes
Now, what can actually cause those symptoms in our software systems? two major factors are to consider:

Dependency
A dependency exists when a given piece of code cannot be understood and modified in isolation. The code relates in some way to other code, and the other code must be considered and/or modified if the given code is changed.

Obscurity
Obscurity occurs when important information is not obvious.

In JavaScript/TypeScript projects, non-existing JSDoc or using the “any” type all over the place are two examples of obscurity.

Have you ever been in a situation when you were forced to read the low level implementation of a component just to know what props to pass to it or how something is handled inside? you’ve just experienced obscurity.

Working Code is !enough
There are 10 types of developers in this world. The ones who can read binary and the ones who can’t. Just kidding 😄.

There are two types of developers, Tactical and strategic.

Tactical
Tactical programmers’ focus is to get something working as fast as possible, such as a new feature or a bug fix. The product managers and executives love them but this is exactly how systems eventually become complicated.

Tactical developers’ mindset is the main cultural factor that brings about “Technical debt” in most cases.

Strategic
Strategic programmers realize that working code is not enough.

Most of the code in any system is written by extending the existing codebase, so your most important job as a developer is to facilitate those future extensions.

Strategic programmers do proactive or reactive investments. such as:

Find a simple design for each new component
Try a couple of alternative designs and pick the cleanest one
Try to imagine a few ways in which the system might need to be changed in the future and make sure that will be easy with your design
Write a good documentation
When you discover a design problem, don’t just ignore it or patch around it
We should strive to be a little more strategic and a little less tactical in our careers.

Module depth
Each module or component has two parts: an interface and an implementation.

The best modules are the ones whose interfaces are much simpler than their implementations.


This is exactly where “breaking code to smaller parts” can actually make our architecture worse, because the benefits provided by shallow modules are negated by the cost of learning and using their interfaces.

Interfaces should be designed to make usage of the common case as simple as possible (KISS).

Hiding information, or leaking it!
Each component should encapsulate a few pieces of knowledge, which represent design decisions. The knowledge is embedded in the component’s implementation but does not appear on its interface, so it is not visible to other modules.

Information leakage occurs when a design decision is reflected in multiple components. This creates a dependency between the components. Also, if a piece of information is reflected in the interface for a component, then by definition it has been leaked.


JSON interface does not tell us how it does parsing or stringifying. It hides that knowledge and just does it for us.

Different Layer, Different Abstraction
If a system consists of adjacent layers with similar abstractions, this suggests a problem with the class decomposition.

Pass-through variables
Imagine you have a long chain of methods and a variable is passing down through it. This variable creates complexity because it forces all the links in that chain to be aware of its existence, even if one of them doesn’t use it.

Even worse, let’s say you want to modify the implementation or type of that variable, You need to change all those methods which that variable is passed to (change amplification) or if a new variable comes into play you have to make sure the path that variable traverses is correct and expected.

An example of pass-through variables in Vue.js is props usage.


A quick example of prop drilling in a hypothetical to-do list application
In the example above, we are passing a dynamic URL that we need to post a payload to whenever we check something in our to-do list. Let’s suppose we only have access to that URL in the root index.vue file so we can’t just hardcode that in the TaskItem.vue file so we are forced to pass it down the component tree like that.

Now imagine if requirements change, in that case we need to change 3 places to accomplish one thing!

Pass-through functions
Methods that do little except invoke other methods, whose signatures are similar or identical, are shallower as they increase the interface complexity of the class, but they don’t increase the total functionality of the system. They indicate that there is confusion over the division of responsibility between classes/components.

Interface of a class should normally be different from its implementation: the representations used internally should be different from the abstractions that appear in the interface.

Better Together Or Better Apart
One of the most fundamental questions in software design: given two pieces of functionality, should they be implemented together in the same place, or should their implementations be separated?

Subdividing components can result in:

The more the number of components is, the harder it is to keep track of them all (more hassle because of more moving pieces)
Additional code to manage the components
Separation makes it harder to see the components at the same time, or even be aware of their existence (increasing unknown unknowns).
Code duplication
A few indications that two pieces of code are related are:

They share information
They are used together (only compelling if bidirectional)
They overlap conceptually
It’s hard to understand one of the pieces of code without looking at the other.
We should:

Bring together if information is shared.
Bring together if it will simplify the interface.
Bring together to eliminate duplication.
Separate general-purpose and special-purpose code. Failing to do so is usually a red flag.
In Vue 3, there’s this concept of composition API that we can use to easily use other Vue primitives that we already know and love such as computed properties, refs and reactives, watchers and lifecycle hooks in one place and use it everywhere we like.


useTodos.ts composable gathering all logic in one place
What we did here is that we gathered the logic and state spreading through 3 different components in one single file. we can import this file and use what it returns like any other module and even if requirements change in the future, we only need to change one file!

Pull Complexity Downwards

It’s more important for a module to have a simple interface than a simple implementation (as also said above).

We should try to do complicated tasks in the inner layers and do more general things in the outer layers. This reduces cognitive load for others because we are creating modules with more functionality and simpler interfaces which is the textbook definition of “deeper modules”.

Define Errors Out Of Existence
The exceptions thrown by a class are part of its interface. Classes with lots of exceptions have complex interfaces, and they are shallower than classes with fewer exceptions.

Exception handling is one of the worse sources of complexity in software systems.

Exception handling code is inherently more difficult to write than normal-case code. Furthermore, it creates opportunities for more exceptions.
It’s difficult to ensure that exception handling code really works. Some exceptions can’t easily be generated in a test environment.
Code that hasn’t been executed doesn’t work.

The best way to eliminate exception handling complexity is to define your APIs so that there are no exceptions to handle.

Exception masking
Reduce the number of places where exceptions must be handled.

Exception aggregation
Handle many exceptions with a single piece of code. Exception aggregation works best if an exception propagates several levels up the stack before it is handled. This allows more exceptions from more methods to be handled in the same place.

This is the opposite of exception masking, masking usually works best if an exception is handled in a low-level method. For masking, the low-level method is typically a library method used by many other methods, so allowing the exception to propagate would increase the number of places where it is handled.

Masking and aggregation are similar in that both approaches position an exception handler where it can catch the most exceptions, eliminating many handlers that would otherwise need to be created.

Just crash when it makes sense to do so. By the same token, it also makes sense to define other special cases out of existence.

Design it Twice
Designing software is hard, so it’s unlikely that your first thoughts about how to structure a module or system will produce the best design. You’ll end up with a much better result if you consider multiple options for each major design decision.

Writing better comments
There are a lot of excuses for not commenting in any code base such as:

Good code is self-documenting.
I don’t have time to write comments.
Comments get out of date and become misleading.
The comments I have seen are all worthless. Why bother?
All of these excuses are debunked in the book.

Good documentation helps with two of three ways in which complexity manifests itself in software systems: cognitive load and unknown unknowns.

Comments should decrease obscurity
Consider the following points:

Decide on conventions for commenting.
Don’t repeat the code. Comments at the same level of details as the code is not useful and a red flag. Ask yourself a question “could someone who has never seen the code write the comment just by looking at the code next to the comment?”. If the answer is yes, the comment is not useful.
Comments augment the code by providing information at a different level of detail, low-level comments add precision, high-level comments offer intuition.
If interface comments must also describe the implementation, then the class/method is shallow.
Delayed comments are bad comments, write the comments first.
Comments are a design tool. Comments serve as a canary in the coal mine of complexity. If a method or variable requires a long comment, it is a red flag that you don’t have a good abstraction.
Early comments are fun comments, Early comments are not really too expensive.
Choosing Names
Good names are a form of documentation/abstraction. Good names have two properties, precision and consistency.

Consistency
Always use the common name for the given purpose. Never use the common name for anything other than the given purpose. Make sure that the purpose is narrow enough that all variables with the name have the same behavior.

The greater the distance between a name’s declaration and its uses, the longer the name should be.

Precision
Vague names are a red flag. It’s fine to use generic names like i and j in a loop. But if the loop gets so long that you can't see it all at once, then a more descriptive name is in order. Also avoid names that are too specific. - If you find it difficult to come up with a name for a particular variable that is precise, intuitive, and not too long, it suggests that the variable may not have a clear definition or purpose.

Consistency
Consistency creates cognitive leverage, once you have learned how something is done in one place, you can use that knowledge to immediately understand other places that use the same approach. Examples include names, coding style, interfaces, design pattern, and invariants.

Document the most important overall conventions. Enforce conventions with automated tools (like ESLint) to check for violations.

Don’t change existing conventions. Having a “better idea” is not a sufficient excuse to introduce inconsistencies. The value of consistency over inconsistency is almost always greater than the value of one approach over another.

Like the saying goes:

When in Rome, do as the Romans do.

Code Should Be Obvious
Software should be designed for ease of reading, not ease of writing.

Things that make code more obvious:

Choosing good names (as mentioned above)
Consistency (as mentioned above)
General-purpose techniques such as white space or comments.
Things that make code less obvious:

Event-driven programming
Generic containers
Different types for declaration and allocation
Code that violates reader expectations
One of the bad practices in Vue is handling business logic and state mutation in watchers. Watchers or watchEffect should be implemented in a “fire and forget” manner. Also using provide and inject can potentially be not obvious. use these tools wisely.

We’ve covered key concepts discussed in the book. now as a bonus let’s see how SOLID principles relate to our readings above!

SOLID Vue
1. S for “Single-responsibility principle”
The idea behind the SRP is that every class, component, module or function in a program should only have one responsibility. As a commonly used definition we can say: “every component should have only one reason to change”.

Your components need to do one thing and if you want multiple thing happens you should compose them so that a reader understands “oh this a component that gathers 3 other components that only do one thing, so it should only be able to do 3 things!”

Be cautious if you have a component that imperatively does a lot of different things at once.

A great example of SRP is tailwind CSS, A utility-first CSS framework packed with classes like flex, pt-4, text-center and rotate-90 that can be composed to build any design, directly in your markup.

Great thing about tailwind that everyone loves is that it is consistent and composable so you can throw as many classes to a div as you’d like and be sure that the end result will be a combination of the classes and non of these classes are implicitly overriding each other’s styles.

2. O for “Open–closed principle”
The open-closed principle states that software entities should be open for extension, but closed for modification.

Slots are great examples of how we can Facilitate extensions in Vue. Slots will help us extend our components with any template we want and in the same time keeping our state inside!


In computer programming, as soon as you introduce a “state” you are responsible for its existence and side effects. Always ask yourself “what changes my states?”. Always have a “state machine” in your mind that handles every expected behavior or unexpected errors. This is how we can make sure we are closed for modification.

3. L for “Liskov substitution principle”
Personally I don’t think we get to see a lot of LSP in the Vue ecosystem because I assume there aren’t a lot of companies or teams that are using class components, but anyways, here’s the description!

The “Liskov substitution principle” simply implies that when an instance of a class/component is passed or extended to another class/component, the inheriting class should have a use case for all the properties and behavior of the inherited class.

4. I for “Interface segregation principle”
The interface segregation principle states that the interface of a program should be split in a way that the user/client would only have access to the necessary methods related to their needs.

This is kind of related to the first principle (SRP) and this is closely related to deep modules concept discussed at in first sections of this article. It is important when designing prop interfaces and how components interact with each other.

5. D for “Dependency inversion”
High-level modules should not import anything from low-level modules. Both should depend on abstractions.

Let me show you an example in Vue: loose coupling between backend APIs and component props.


Never let your backend API properties define your components’ props, instead conclude an interface that satisfies both APIs, UI and application requirements simultaneously, then use a map function to transform the API data so that in complies to the interface.

This way if API or requirements change, you only alter the mapping implementation and all the component tree will be untouched!

This method of thinking is inconvenient and takes more time to develop at first but this is an investment for future changes.

At last we should consider not obsessing about all the rules said above. There are technical debts to overcome deadlines etc. but we should strive for fundamentals and learning them because we will subconsciously be better programmers in the end.

philosophy of software design in vue.js applications



  
### My story

I always wanted to have a personal blog, [but never actually put the time in to get it done](/blog/developers-productivty-and-procrastination). 
Creating meaningful blog posts is not an easy task, might as well have systems and tools in place helping us do it faster and easier.

I tried many different ways and flavors of blogging. Wordpress was heavyweight and clunky, Medium or other micro-blogging services did not just feel _right_ to me. Naturally as a web developer, I wanted to have something of my own and make it from scratch.

### Github pages
I made a repository on Github to host all of the code needed for the blog. Then used the Github pages free service to serve the HTML files available on the repo. 

As a cherry on top, you can use Cloudflare's free services to point the `YOUR_USR.github.io/YOUR_REPO` to your custom domain `YOUR_DOMAIN.co.uk` for example.

That's exactly what I did to `Mahdikarimi.com` and pointed it to `mhdi-kr.github.io/personal-blog` using Cloudflare and my domain provider settings.

### Next.js, Filesystems and Markdown parsers

This website was built upon the Next.js React framework. I've developed React components layout and stylings. The actual content of the blog posts are written in Markdown format in a specific directory inside the repo. 

Next.js allows you to acess filesystems in serverside configuration using the `fs` object available in Node js.
The `getStaticProps` function is called by Next.js when the page is first loaded. It is then used to fetch the markdown content using Nodejs filesystem.

After fetching the actual content as strings we need to parse it using a Markdown parser and pass it onto the components as state props for react to do its magic. 

### Sky is the limit!

You can do all sorts of cool things with Markdown files! You can hide any metadata inside it files called _Frontmatter_. Your markdown parser will provide it to you and you can use it to embed dates, tags or arbitrary static state in your blog posts! 

Using that state in React, you can conditionally hide/show your posts, render tags or dates, etc! Sky's the limit.
  
### Generating static HTML, CSS and JS files

By using the `next export` command in the terminal, we can render all the HTML, CSS and JS files we need for the website to be up and running without a runtime in the `/out` directory. This is great because this is all we need for Github pages!

  
### Publishing changes without hassle
Let's publish the generated files to Github Pages. I use the `gh-pages` CLI utility,[ available on NPM](https://www.npmjs.com/package/gh-pages), to publish the static files to a specific branch.

  

Github automatically detects push-events to this branch and then deploys my newly created HTML and assets files to the web!


  

### All in one go!

  

You can aggergate all the steps I talked about in one single command, or even register it as a NPM command to run every time you want to publish your blog.

  

```Bash

$ yarn build && yarn export && touch out/.nojekyll && gh-pages -t -d out

```

### Handling comments

Any form of content creation requires a feedback loop to bring value to its users as well as authors.

The problem with Github pages for handling comments is that everything is static. You don't have access to a database on it to be able to do CRUD operations. 

Of course there are workarounds for those kinds of tasks but I wanted something elegant and fast. This is where utterances comes into play. 

With utterances Github app you can have fully functional comment section in your posts! It uses Github issues under the hood and I could easily integrated this with React.

Make sure you [checkout their documentation for more details!](https://utteranc.es/)

maintaining my statically generated tech blog

> I always wanted to learn/do that but never actually found time for it -me sometimes

Procrastination means putting things off till the last minute. The deadline of a task, project or duty comes around sooner or later. Then after being high on adrenaline and pulling a couple of all-nighters, we manage to survive and deliver what we easily could have done without that much stress.

## The cause

By personal experience, I think procrastination has 3 major causes.

1. ### 1. Your value system

    > “He who has a why to live for can bear almost any how.” - Friedrich Nietzsche

    Why are you doing this task? What will you achieve? What is your goal? money? social validation? whatever the reason might be, you have to go through this personal conversation with yourself.

    Our brains are wired for survival and passing genes to the next generation. That is the ultimate goal of any living being. Our natural instinct could not care less about getting straight A's in final exams or learning that hot new technology, unless you couple it with some value deep within your psyche.

    Try to understand your why, then and only then, you will be able to bear its how.

2. ### 2. Fear

    We are scared of the unknown and ambiguity, just like how children fear darkness. 

    When we don't know completely what we are dealing with as a challenge, a classic trick our brain does is to try to avoid it by sticking to short term pleasure, but here's when you have to intentionally interfere with this natural response.

    After gaining momentum, that fear will be gone and you will have no problems doing that work again.
  

3. ### 3. Distraction

    We live in a society prone to distraction. We're constantly called on social apps, emails and other matters thanks to the internet.

    We cannot get rid of distraction entirely, but the thing we most certainly can do is _reducing the possibility of being distracted_ when we are actively working.

    There are many systems, apps and tools you can facilitate to reduce the amount of distraction you receive per day.

## The cure

I wrote about the potential reasons why you might be procrastinating. Now let's see how we might be able to get decrease it.

- ### Remove the delay for execution

    The more time you take to prepare, the less likely you are to finish the task at hand.

    There's a famous quote by Warren Buffet saying "An idiot with a plan can beat a genius without a plan", personally as a professional "over-thinker". this is not a case for me.

    I've seen times and times again that when I get to work without that much planning I am quicker gain feedback and to change course and keep moving step by step. Hip-firing my way through success if you will.

- ### Gain momentum

    Newton's first law states that if a body is at rest or moving at a constant speed in a straight line, it will remain at rest or keep moving in a straight line at constant speed unless it is acted upon by a force.

    I've experienced the same concept can be applied to human actions. If you're not doing anything and are lazy to start things, chances are you are going to be that way unless you gain momentum towards what you want to do.

    Same principle applies to people that are motivated and high performer. They are more likely to keep doing what they are already doing.

- ### Try SMART goals

    While planning ahead of time, try to set specific, measurable, attainable, realistic and time.-bound goals.
    SMART goals have the attributes that will help you have less friction towards starting, doing and finishing your tasks.

- ### Pomodoro technique

    Simply put, you set an alarm for 10-15 minutes, you get to work and discard any distractions or any multitasking. 15 minutes of laser focusing on one task. After that you take a 5-10 minute break. Repeat this process multiple time and you will get so much out of your day!

    Pomodoro technique is effective because you limit all of your friction. It is only 10 minutes! it is going to be fun! But there's a compound effect to it. which will pay off soon.


Developer's Procrastination

### What we already know about developing applications

we start with names, key-value pairs, ifs and elses, iteration and procedures.
on top of all this we have atomic data types in every single programming languages such as strings, numbers and booleans.
we can go even higher than that to reach arrays, hashes and namespaces.
object oriented programming brings other abstractions such as classes, objects with methods and inheritance.
A mixture of all these entities make up our _programs_

### A reason to refactor

functional programming is refactoring what you already know about wiritng applications
At the start applications are written neatly but as the time goes on and we keep adding features and dependancies to our apps, it becomes a mess

### Mathematicions have the same problems as we do

In my opinion, computer science is a subset of mathematics. They faced the very problems we have with writing our applications and came up with _principia mathematica_ to try to explain maths in atomic levels of abstraction

In mathematics, a function is a relation between two sets, a mapping from one to another.

what we do is not the same as functions, we return numbers, or void or IO or database or HTTP request

what if applied some rules to our programming to make it look like maths?

-   Look at inoput and parameteres, generate output
-   no side effects

in hope of making programs easier to understand and easier to maintain
fx wont affect x

make datastructures immutable
dont change things
how can we be productive? make a copy of any ds you want to mutate.
there's a problem. a lot of copies. what if you have a milion element array?

### lets start with a clean sheet of paper

### side effects

customers and business care about the side effecst! actyally desired effects!
how to change outside world with functional limitations?
there should a some kind of a queue that has messy appearance that our functions inqueue stuff in it and some parts of our code grabas stuff from it and executes it

### Functional refactoring in action

Here's what we want to achieve. we first need to read the text content of a `.svg` file, then we need to pipe the content through a package called `svgo`. It optimizes SVG string and removes unneeded content without affecting the actual vectors. Then we need to make a `.vue` single file component and write the content we have in it.

```javascript
// optimizer.js
const fs = require("fs");
const { optimize } = require("svgo");

const optimizer = (arg) => ({
    import: () => optimizer(readFiles(arg)),
    optimize: () => optimizer(optimizeItems(arg)),
    export: () => writeComponents(arg),
});

const readFiles = (paths) =>
    paths.map((filePath) => ({
        path: filePath,
        content: fs.readFileSync(filePath, "utf8"),
    }));

const optimizeItems = (contents) => contents.map(optimize);

const writeComponents = (items) => {
    items.forEach((item) =>
        fs.writeFileSync(component.path, component.content)
    );
}

optimizer(["foo.svg", "bar.svg"]).import().optimize().export();
```

notice we are only declaring seperated functions with predictible actions without any mutiation to any variable
three main functions to do certain tasks. then aggregate these functions in `optimizer` factory function to be able to do dot chaining with the results

you can write individual tests for each function and increse the coverage


[unfinished] Refactoring to Functional paradigm


Hello friends, Today I’m going to show you how you can make a VS Code extension using WebView panels and Vue 3.

Our First “Hello World” Extension
Let’s start with a simple extension that shows a message toast in the bottom right, shall we?

According to the VS Code official instructions, we first need to install the following two packages.

$ npm install -g yo generator-code
After installing these packages, We need to run this command to scaffold our basic extension.

yo code
After completing required steps in the CLI, we have a base extension that we can tinker with.

In the extension.ts file generated we can see two callback functions: activate() and deactivate() .These functions are called in our extension’s lifecycle when starting and stopping.

To test and run our extension go ahead and press F5 on the keyboard. This will open up a new VS Code instance called the “Development host” that has our extension loaded up locally.

in the extension.ts file we can see a key with which our extension is registered in the Command palette. That key also has to be registered in the package.json file in our extension root directory with a title.

In the extension host, open up Command palette and type in the registered title to activate our extension.

> Hello world
press enter and now we should be able to see that information message we’re looking for!

now if we want to make any changes we just have to go back to our source code, apply our wanted changes and press f5 again to re-run the extension host!

now let’s do more interesting stuff by creating a WebView!

Extension WebView
VS Code is an Electron based application so it is technically like a browser that can render HTML or CSS and has the ability to run your own JavaScript!

to programmatically render all of your web files we need to do the following:

We add a function that returns a panel, for that panel we can set a html property which will be eventually rendered as a WebView in VS Code!


now by pressing f5 again we should call our new command in the Command palette using:

> Show Panel
and yeah this work! our html is now loaded and rendered like a browser INSIDE VS Code.

ok then now that we are able to import 3rd party CSS and JavaScript, all there’s to do is to have a Vuejs project built and them imported over the VS Code context.

If that sounds like a lot of work it actually is! I already have built a template for you guys to use.

Head over to my GitHub using the link below and clone the template, I will continue to explain how it works.

https://github.com/Mhdi-kr/vscode-webvue

Enter VS Code WebVue
We have two packages, our extension package and our Vue package.

In the vue package we have simple counter app we can open it up in the browser like all the other vue apps by running it in the development server

After making changes to in the vue package, Nodemon scans for file changes and build our vue app to files with specific names, then those files are imported using VS Code file resolution API and injected into our HTML template string.

The Nodemon also opens up an instance of VSCODE so we don't need to refresh manually. it also watches the extension’s source code as well restarting it if any changes are made, so this incredibly increases the ease of our DX.

Now lets run to see our vue extension in action!

yarn watch
An instance of development host opens up containing our web files and registered command!

> Hello world
Here you can see your vue project already built and injected using VSCode WebView API. you can utilize the full functionality of Vue js such as its amazing reactivity and its available plugins out of the box!


when you start developing on the /packages/client/ vue application directory, your changes will be watched using Nodemon, then rebuilt and be opened inside VS Code extension host ready to be used with VS Code Command palette!

Inside the vue application code, the vscode object is globally injected and can be used to send messages to the VS Code runtime and perform tasks such as read/writing files, etc.

making a vscode extension using vue ecosystem


This repo is my honest endeavour to build a skill tree for frontend development. I'm trying to come up with a skill tree that is as broad as possible, but still as specific as possible.

Road maps are great for describing the order of steps taken in a project or a tutorial, but real life does not work like that in my opinion, for example in the infamous web development road map repo there's git and source control step in the very beginning of the road map.

my real life did not start with git! I started web development messing around with pure HTML. not even a single line of js code was written! I did not consider myself proficient in git until my second or third job! so I think those do not represent my real life.

In my opinion real life is much more like a tree, where you can go from a root node to any leaf node if you wanted! you can choose to learn a little bit HTML and css and decide to go and learn more about js without anyone forcing you to learn git (or any arbitrary technology) first.

This is less overwhelming, and I think that's the value I want to bring to people with this repo.

tired of learning about react hooks or redux? why don't you hop onto CSS and animations to spice things up?

[unfinished] Frontend Development Skilltree

[unfinished] Webassembly, whats whys and hows


When I joined the Alibaba Travels company, I was tasked to maintain and migrate the hotel CRS (Central Reservation System) panel. It was developed using Vue.js 2.6, webpack, bootstrap-vue UI component library. There used to be a lot of technical debts and anti-patterns such as prop-drilling and excess use of mixins, etc. We were in dire need of a big change.

There were a lot of ups and downs, but after 3 to 4 months I was able to replace Vue 2 with Vue 3, Webpack with Vite, configured cypress and testing environments, resolved breaking changes and last but not least, migrate ALL of the used SFC (single file components) to use a totally different UI component library with different props, design and behavior!

All of the said changes were committed to the same git repository but in a different branch! Just like natural selection, I knew we could not afford to redo things from scratch. This is how we get to my first point here.

### Prefer changing existing code to redoing everything from scratch

There were a lot of pieces of code that I could reuse in the migration without any problems such as the custom date and currency plugins and utils, backend API integration sdks, reusable general components that existed in the codebase, etc.

I tried to do as little change as possible in terms of removing whole code sections or components and rewriting them, but I have to admit, sometimes you just cannot do it.

I tried to rewrite one of our views about supplier CRUD actions from scratch, my estimated time for the task was one week. It took two to finish while fixing a lot of unpredicted bugs in the meantime. I learned something important, when migrating code especially if the requirements are the same as before and there’s nothing to drastically change, improve upon code that already exists. the heavy lifting is already done. you can deliver faster with higher quality that isn’t rushed.

### Premature optimization is the root of all evil

Always implement things when you need them and never when you foresee that you might need them.

Premature optimization means postponing delivery in favor of making the perfect architecture which to some extent, is a fairy tale.

Passionate developers tend to over-engineer their design and architecture. We crave optimizations in our designs and developments. These actions seem so exciting to us and we spend so much time on them that we forget about the product itself. Our number one goal should be to deliver value to the business.

Over-engineering could be a great way to learn new things. However, the question is whether production code is the right place for experimenting or not.

I learned that perfect code is not written overnight. it’s not a linear path to perfection. The nature of software development is of an onion. You have layers upon layers of iteration over the same thing to make it better every day. Like a painter that brushes over the same canvas over and over again that it becomes Starry night.

### Beware of abstractions

> “Duplicate code is cheaper than the wrong abstraction”

Abstractions are great because right ones simplify things in the long run, But if you try to abstract everything, you’re gonna lose your flexibility in adding features.

Make sure you have developer’s experience (DX) in mind whenever you want to add some sort of abstraction or automation to your codebase.


### Know your environment's limitations

As a general rule of thumb, it is great practice to know the pitfalls and problems you’re likely to have using your language or framework of choice.

For vue.js or any other framework/library that uses declarative programming and has tight coupling with states, it is so important to be able to keep track of state and side effects.

Declarative programming without a good side-effect management is just imperative programming with more steps.

### Embrace humility

At the time of migration, I did not know the answer to a lot of my questions. I learned to constantly ask other teams about solutions and suggestions, alongside my own research.

Don’t be afraid to ask questions, You can’t know it all. You have to decide how much of a generalist you want to be, and how much of a specialist you want to be.

### Gain domain knowledge as soon as possible

Without domain knowledge, you will not be using 100% of your technical skills. No matter how good you are in your tech stack, you need domain knowledge to use it.

Domain knowledge lets you foresee problems that haven’t occurred yet and avoid them beforehand, whether it is the implementation of complex UIs or the architecture design of a MongoDB schema.

Take time to know the business, ask questions, set meetings. remember you’re only here to support your business.

### Get in touch with users, directly or indirectly

It always feels good when your direct users thank you for your app’s features, and it is eye-opening to see how exactly they interact with it and what they expect from it.

The best-case scenario is where a developer can afford regular meetings with users and stakeholders and collect a list of to-dos that will be added in near future.

Connecting with users can create a positive feedback loop that will benefit both you and them.

### Automate what you can especially mundane and repetitive tasks

There are a number of repeatable tasks we do every that can be automated and drastically speed up our process.

One example of automation in my workload was an optimization pipeline for our SVG components. I developed a little script that I run to generate Optimized SFC Vue components from SVG files to lazy load them where I need them. here's the node program for it:

```javascript
// optimizer.js
const fs = require("fs");
const { optimize } = require("svgo");

const optimizer = (arg) => ({
    import: () => optimizer(readFiles(arg)),
    optimize: () => optimizer(optimizeItems(arg)),
    export: () => writeComponents(arg),
});

const readFiles = (paths) =>
    paths.map((filePath) => ({
        path: filePath,
        content: fs.readFileSync(filePath, "utf8"),
    }));

const optimizeItems = (contents) => contents.map(optimize);

const writeComponents = (items) => {
    items.forEach((item) =>
        fs.writeFileSync(component.path, component.content)
    );
}

optimizer(["foo.svg", "bar.svg"]).import().optimize().export();
```

Get to know the automation tricks your IDE of choice will provide you. This will drastically increase your workflows speed as the time moves on.
Learn to use regex, it can help you find patterns in your codebase saving you hours of manual searching in large code bases. If you use vim, create macros for your most frequent actions.

### Start small and be consistent

Working on large software applications is daunting. Chopping up big tasks into smaller, doable sub-tasks and focus on them one at a time until there’s no subtask is left. This method was famously used by Napoleon called "divide and conquer" and it just works.

you can eat an elephant one peace at a time, lay the bricks until the wall is done. fast iteration, fast correction, fast delivery will get you through hell.

### Beware of burnout

I am passionate about my profession. I don’t feel time passing by when I’m working, but, everyone has a limited amount of energy and mental capacity each and every day and this is just a fact.

Just take breaks to sharpen your axe. Make sure you have enough physical resources, food and sleep to keep you going.

Take a great care of yourself and health, because it is priceless.

### Take responsibility and bury your burden

Get to work. stop blaming legacy code, previous developers, or decisions made before you. It is all gone and past. You’re the player now, you’re the one everyone will blame or praise afterwards. The choice is only yours.

pieces of advice for my junior developer self

making the worlds dumbest two axis robotic arm


### Random access memory types

#### SRAM

Static Random Access Memory

#### EEPROM

Electrically Erasable Programmable Read-only Memory

#### Flash memory

### Possible optimizations

#### Software

use `PROGMEM`
what it does is

```cpp
const dataType variableName[] PROGMEM = {}; // use this form
```

#### Serverside

Do the heavy lifiting on the server. provide lightweight interface for arduino to work with.

### Problems ahead

#### Memory fragmentations
