han4wluc / han4wluc.com Goto Github PK

there are only few primitives to implement animations.

animation can be implemented by changing properties over time.

• value
• duration

missing og tags:

<meta property="og:locale" content="your value" />
<meta property="og:image" content="your value" />
<meta property="og:logo" content="your value" />

Why I like and recommend this book:

• Every software engineer develops experience of what good software should look like. However if you asked me to explain what good software should look like, I would have a hard time explaining it. What this book does is exactly that, it breaks down what makes good software into small pieces and discusses each point individually so that the reader can learn it.
• By the time the reader finishes this book, the reader will have developed a detector for things to watch out in codebase and techniques to design good software.

Recommend who should read this book:

• Any Software engineers both in their early career or experienced who care about software quality

Philosophy of Software Design is a great book about how to write good software

Having been writing code for 10 years, I agree with all points made in this book.
My experiences has given me an intuition on what good code should be like, and how to design a system.
However it is not a systematic approach and follows mostly my intuition and gut feel.
The does an extremely good job to break down aspects of good code design and make each concept accessible for the reader to analyze.

I will follow most suggestions in this book, and recommend it to people working with me.

In this post I will go through the book's content and give my personal experiences and opinions on it.

Every software developer has been though this experience:

We hack something together and make it work.
It does the job and is amazing.
We keep adding more features and more code, we are able to meet all the new requirments at a fast speed
At some point, we experience that bugs start popping out, adding functionalities and making changes take longer time.
We spend more time debugging.
At some point we conclude that there is a better way to structure the code.
We come to the decision, should we stop development to re-write part or all of the codebase?
This experience happens again and again in nearly all software developmetn projects.

There are some key points on this experience.

• The project becomes more complex as you add more code
• You find that there is a better way to do something

We experienced this many times, and from each experience we become a bit better software engineers.
But, have we gone back to analyze, why did the software become complex, what could we do to manage the complexity and design better systems?

This book analyzes exactly what is complexity, and what things makes software more complex, and what to watch out for. It also shares serveral techniniques to use to manage this complexity and have easier to work with code.

I was implressed on how the author was able to break down those abstract details into small, understandable and tackable concepts.

I have been through organizations with different levels of code quality.
Some organizations disregarded code quality and only cared about shipping out features.
Some organizatios had well established code guidelines and review processes and made sure every change was adhering to the quality standads.
It is really really hard to maintain high quality code, especially when there are many inexperienced programmers and little leadership on code quality.

Leadership, the top leaders in engineers should be first examples of pushing for code quality. If the leaders don't care or don't know how to distinguish good code design, why should I care?
Junior programmers are ones that focus more on writing working code rather than high quality code. One main reason is that they are not able to distinguish good vs bad code. If left untouched, they will write a lof of code their way. The leaders has to be able to tell the junior developer if a piece of code is good or bad.

My conclusion is that:

• Tactical programming will take you far, but just as far.
• There will be a point with tactical programming will meet a bottleneck. This is not necessarly bad as most projects will never reach the bottleneck.
• However for long term success and scalability, you will need to reach that level of code quality.
• I'm betting that high quality code is more productive and enjoyable than writing non high quality code

What chapter is about:

Definition of Complexity:
"Complexity is anything related to the structure of a software system that makes it hard to understand and modify the system"

An important and pratical attribute of complexity is that
"Complexity is more apparent to readers than writers."

The 3 symptoms of complexity:

• "Change amplification": "a seemingly simple change requires code modifications in many different places"
• "Cognitive load": "how much a developer needs to know in order to complete a task"
• "Unknown unknowns": "it is 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"

The 2 causes of complexity:

• "Dependency": "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". Dependencies lead to change amplification and a high cognitive load.

• "Obscurity": occurs when importation information is not obvious. Obscurity creates unknown unknowns, and also contributes to cognitive load.

My opinions:

Chapter 2 is one of my favourites. It breaks down what is exactly complexity and where it comes from.
I knew that dealing with software main problem is complexity. However I would have a hard time to answer what is complexity.
The author decomopresses Complexity into 3 symptoms and 2 causes:

We want to minimize complexity in our systems. By having clear definitin, symptoms and cuses of complexity we can be much more cautious and aware how our code impacts complexity.
This helps us build a red flag detector, code smell detector, an inner radar to detect complexity when we see it.

Chapter 3

What chapter is about

Tactical programming is about creating working code as quickly as possible to get the job done.
Strategical programmming thinks more about the overall design of the system.
Strategical programming might take longer in the short term, but it saves more time in the long term.

My opinions

basically is making a point that you should aim for long term, rather than short term. Working code is not what we aim fore, instead we want to aim for a good designed system, it pays in the long run.
Quoting Margin Flower: "High quality code is cheaper to write"

This is not about technical complexity per set. but to encourage the reader to adapt a strategic instead of tactical.

Subsequent Chapters go on describing techniques that tend to produce lower complexity code.

Deep Modules

What chapter is about

It is very important to distinguish interface from implementation.
When working on a task that involves different modules, is impossible to understand the implementation of all modules. That would be too big of a cognitive loaad.
Instead, what we can do is to be able to understand the interface of the relevant modules would be enough.

Do not attach implementation with interface. When implementation changes, the interface should not change.

Information Hiding
The interface should hide information that the user does not need to know.

Althought this is obvious in theory, it is harder to apply in practice when you are actually designing a module. It takes some attempts to come up with the right interface.

General Purpose Modules are better
This was a very interesting finding. I have experienced, but did not pay that much attention to it.
But this is also a good news.

My opinions:
...

Different Layer different abstraction

Pull complexity downward

Better together or apart

Define errors out of existence

Design it twice

Writing comments

Choosing names

Write the commenta first

Modifying exisring code

Cobsistency

Data binding and View rendering

uhtml was the best library for frontend development I ever encountered.
uhtml replaces for me all FE frameworks such as react, vue, svelte.

below I will share my journey on how I ended up with uhtml.

First of all, lets talk aboit why do we use or need a FE framework in the first place.

Lets start with the most basic FE

this is all good. html and css enables us to create any static non interacrive UI, and we dont need any js framework.

when we start to want add new interactive, now we need to add javascript. example we want to increase a counter on button click:

this works very well. but what is ugly is that you need to update the value and update directly manually.

what we would actually want to write is like this:

so that the html is automatically updated. and we dont need to write extra js to manually uodate the html.

but this does not work with pure html and js. we would need to turn everything into js

now it works. and well we implemented a very simplistic version of uhtml.

there are many things that uhtml does such as performance optimizations, habdling functions/event listeners, all kinds of edge cases and more.

so now. we have resolved the data binding.

Components

what else we use FE frameworks for?
one is for components

web components have made a lot of progress in the last years, and are able to satisfy most features provided by the other FE frameworks.

you can create web components with libraries such as lit or stencil. or just use raw web component API.

full example.of using web components

Routing

another feature that FE frameworks provide is the routing. however, you can implement the basic features within 20 lones of code:

react router for reference is xxx kb

State Management

state management is a big topic for me in FE. I have been dealing with state management and thinking about an ideal solution for a long time. It turns out I finally found the solution.

the best solution for a problem is to remove the problem alltogether in the first place.

i ended up with a solution to state management without using any state management framework.

a normal Javascript class, like how mobx uses it, is already a great interface for a state store. is just plain js class.
the mobx magic is that it automatically tracks changes. is no trivial problem. mobx is xxxx kb in size.
how do I solve it? simply by calling render manually.
it works extremely well.
I get a granular control on when things get re rendered. and dont get surprises. is very flexible.

dev experience

npm run dev will open a webpage with livereload or even hot module reload.

simpler alternatives are

serve
or eleventy

selling service vs selling product