1- First, try to understand it,
2- Then try to learn how explain your understanding to people.
Most of us focus on the first one. Even those who appear like good explainers, they don't practice explanation capability as a habit and a planned task, they are so because of their job nature (teaching, coaching ...) or they do it unconsciously as a technical way for better understanding, they don't really care about others.
This is the case in software engineering terminology. Typically, computer scientists produce new (rigorous and abstract) terms and definitions, then software stakeholders make efforts to understand them.
Cross cutting:
- Common use is in cinematography, where main action (main scene) is combined simultaneously with other secondary actions (add effects, suspense and reality to the scene).
The metaphor is: during the main scene, the camera is cutted away to display many other secondary actions.
- In a software, we distinguish between core features and cross cutting features (aspercts). The same program may execute a business logic of a core feature, and in the same time it perform a technical aspect (authentication, logging, metrics).
- Laws of science:
>> Empirical laws (deal with observables) VS Theoretical laws (unobservable)
>> Deterministic laws (gives exact value) VS Statistical laws (gives a rage of possible values).
- Greedy algorithm: provide a local optimum solution (don't look "a head") (e.g. short path)
- Regex:
- Greedy quantifier: .*x (consume all, then backtrace looking for "x")
- Reluctant (lazy) quantifier: .*?x (go step by step looking for first "x")
- Arrays / Linked list:
When dealing with insert/delete at the beginning, prefer linked list.
When dealing with insert/delete at the end (or just data access), prefer random access structures (array, dynamic array)
No comments:
Post a Comment