"You don't need" Project
https://github.com/you-dont-need/You-Dont-Need

Handful of repositories dedicated to show how much you can do without the tools you rely on, for example:

- You-Dont-Need-JavaScript
- You-Dont-Need-GUI
- You-Dont-Need-Momentjs

Aspect oriented programming
A paradigm to manage cross-cutting concerns. Cross-cutting concerns are aspects of your application that cannot be isolated easily and effect multiple modules/services. For example logging/validation/caching/... . Managing them in a way that separates concerns from your domain logic is crucial. You might have already used this paradigm while working with your framework pipe lines or using nestjs interceptors
#paradigm

Today I doubted the usefulness of REST APIs, but restored my faith again.
If you are unfamiliar with REST:
https://restapitutorial.com/introduction/whatisrest

In general RESTful APIs have many advantages that are just plain useful for most applications. Statelessness, being cacheable and layared are some of their features. But It doesn't really makes you to take the REST paths, since one might say it's more convenient to have routes like

POST /submit-business
POST /deactivate-business

that contain domain related verbs and explain what back-end is going to do, rather than

POST /business
PUT /business/:id

and they wouldn't be wrong. Not only we can have the advantages mentioned earlier, but we could have slight performance gains as well! For example PUT /business/:id would possibly have to check for multiple properties to validate them and then convert it to another object that will be again checked by a query-builder for all of those optional properties and so on until the request life-cycle ends.
But with POST /deactivate-business we are talking about a single property, not a resource, so those problems are non-existent.
One might say HTTP verbs are confusing when we are not using REST, but that cannot be true since REST does not even care about the protocol. In fact it only says to decide upon a general rule and follow it, so I might as well use POST for updates while not violating REST.

What does REST offer that makes it special?
I also happened to read about Liskov-substitution-principle in the Clean Architecture book today, it made me see two of the advantages of having a Resource Based approach on my APIs like REST.

1. A shared logic could exist in the client that does not care about what resource you are referring to, and performs an action (such as delete). This is a pure example of LSP since we made our resources to follow a common interface.

2. Client and server are actually more separated than other approaches. For example if we decide to change the verb submit to create in our domain since we don't want to supervise the submission anymore, we wouldn't need to change anything in the routes if we were using REST in the first place.

#REST #HTTP #API

Since we mentioned Liskov substitution principle, this is Barbara Liskov, who introduced it and was awarded with Turing Award for her contributions.

A nice video to learn about this principle:
https://www.youtube.com/watch?v=gnKx1RW_2Rk

Nixcon 2024 tickets. Need more event organizers like this
#nix

Picture from the Clean architecture book

REP, CCP, CRP,... what?
Just mentioned three main component cohesion principles and they are pretty easy to understand.

Reuse/Release equivalence principle (REP)
Components that are meant to be reused, must be put through a release cycle for two main reasons:
1- Ensuring the compatibility of the components with each other via a versioning convention (e.g semantic versioning)
2- Users will know when the new versions are set for release and will adapt accordingly.

Common Closure Principle (CCP)
SRP but for components; that's it. Classes/methods that change for the same reason at the same time, must be put into the same component

Common Reuse Principle (CRP)
This principle, as opposed to other ones, talks about splitting components more than gathering them into one. it states "Users of a component must not be forced to depend on things they don't need". Yes, very similar to ISP.

At the end you might realize that these components are rather in tension with each other, The above picture illustrates this tension and states what is the cost of abandoning each principle in favor of the other one.

#principles #components #clean_architecture

A #typenoscript trick that was useful to me today:

type NullableKeys<T> = {
  [K in keyof T]: undefined extends T[K] ? K : never;
}[keyof T];

export type MakeOptionalPropertiesNullable<T> = {
  [K in Exclude<keyof T, NullableKeys<T>>]: T[K];
} & {
  [K in NullableKeys<T>]: T[K] | null;
};

MakeOptionalPropertiesNullable will make optional fields of T accept null as well as their type. e.g:

interface User {
   name: string;
   lastName?: string;
}

Will be transformed into:

interface NewUser {
   name: string;
   lastName?: string | null;
}

How is this useful?
Working with different controllers, validators or even ORMs might produce situations like this. For example in Prisma schemas any optional value is simply nullable so for an easier type mapping you might want to introduce a persistence model from your read model via this type mapper.
Or you want to accept both null and undefined from your users but don't want to clutter your domain types with it

How is this even working?
We are taking advantage of typenoscript mappers/transformers. NullableKeys<T> first creates a type that assigns never to any property of T that is not optional (deciding with undefined extends T[K]) and at the end it will get the keys of the transformed object (which will skip any field that has the type never). So we end up with a type like below:

"field1" | "field2" | "field3" | ...

What now? now we pass our type to MakeOptionalPropertiesNullable<T> which at first, goes through any key of T that is not included in NullableKeys<T>. Meaning any key that isn't optional. We don't want to touch those so we simply assign their respective types via T[K]. Now it's time for optional keys to join the party. They will be assigned their own types along side a | null to make them nullable. A simple & will seal the deal at the end.

One more thing to add to error correction codes:
They are used for storage as well. After all, storing data is like sending a message from past to future, and if the data can get damaged, we can assume it's on a "noisy communication line". For example, your CDs actually lose bits when you scratch them and error correction codes such as Reed-Solomon might come to rescue.

So how about you CDeez list of error correction codes from wikipedia:
https://en.wikipedia.org/wiki/Error_correction_code#List_of_error-correcting_codes

Pipelining (Instruction-Level Parallelism)
https://en.algorithmica.org/hpc/pipelining/

In order for a CPU to execute any instruction, it needs to follow a few steps:
Fetch machine code from memory
Decode the code and recognize instructions
Execute the instructions where some may do memory operations
Write the results to memory

Notice after an instruction is fetched, CPU can start to process the next one without waiting for it to complete. Modern CPUs take advantage of this and perform a "free" (since we are not using an extra core) parallelism. This is called Pipelining

#cpu #pipelining #parallesim

A simple vim trick that can come in handy. If you need to access output of one/multiple command(s), you can use :redir, Simply use it like below:

:redir >> output.txt

And execute your desired commands. After you are done, you can use

:redir END

to write the outputs to output.txt.

Example:

:redir >> output.txt
:echo "hello there"
:redir END

#vim

Regarding to pipe-lining, they don't always result in optimization. There are times when you might run into obstacles called Pipeline Hazards.
There are three types of pipeline hazards:

Structural Hazard: When two or more instructions need the same unit of CPU
Data Hazard: An instruction needs to wait for a previous operation to be completed
Control Hazard: CPU can’t tell which instructions it needs to execute next

The third one probably got your attention. How could CPU not know which instruction to execute next? Imagine a simple If statement. When CPU reaches this type of branching, It cannot choose future instructions with 100% certainty. That's why there a set of tricks to remove branches from your program as much as possible called Branchless-Programming.

It's worth noting that compilers do a set of optimizations in regard of removing branches as well. So knowing how your compiler acts is essential to how you optimize your code.

#CPU #Pipelining #Branchless_Programming.

Some of you vim users might miss how useful quick-fix list can be. An example can be mixing it with !make. Make command, when used after !compiler <name>, tries to compile your project then writes the resulting errors into a quick-fix list. It also supports a lot of compilers by default (like tsc).
This can be achieved like below:

!compiler tsc
!make
!copen

So if you are about to change a piece of code that probably triggers a lot of errors in your project, this is the way to get it on a quick-fix or location list. For more information on quick fix list:

!help quickfix

#vim

I wrote a simple C implementation of LZW compression scheme.
https://github.com/Keivan-sf/lzw/

LZW is a fast compression scheme which is behind .Z files; for example:

filename.tar.Z

These files were usually compressed and uncompressed via linux compress program

#compression #lzw

Purplesyringa (github) decided to compress her blog posts via webp and decode them in the browser using native APIs and it actually works!

https://purplesyringa.moe/blog/webp-the-webpage-compression-format/

This is very interesting since the image decompression utilities are already present in the browser so there is no overhead/extra code for decoding the compressed html page.

#compression

My average youtube feed

Sudo program is still receiving updates. Latest version just dropped last week
https://github.com/sudo-project/sudo

Todd Miller, who has been maintaining sudo for the past 30+ years

SQLite is not a toy database

https://antonz.org/sqlite-is-not-a-toy-database

Personally, I find sqlite to be very convenient. Being simple and serverless, supported by your favorite ORM and easy to setup just contributes to this quality.

#sql #sqlite