| <?xml version="1.0" encoding="UTF-8"?> | |
| <opml version="1.0"> | |
| <head> | |
| <title>Feeds of Lesley Lai from Inoreader [https://www.inoreader.com]</title> | |
| </head> | |
| <body> | |
| <outline text="Arts" title="Arts"> | |
| <outline text="Sarah's Scribbles" title="Sarah's Scribbles" type="rss" xmlUrl="https://sarahcandersen.com/rss" htmlUrl="http://sarahcandersen.com/"/> | |
| </outline> | |
| <outline text="Tech Blog" title="Tech Blog"> |
| # | |
| # SoC - Separation of Concerns | |
| # | |
| Definition: | |
| Order your thoughts by focusing on one aspect at a time, establish boundaries and organize the system into meanigful parts. - Edsger W. Dijkstra | |
| Explanation: | |
| Software development is a multidimensional discipline and it involves looking at different aspects simultaneously. | |
| The idea of separating the different aspects of a problem allows us to solve one problem at a time and eases the process of reasoning. Isolating aspects also lets work to be postponed to a later time and allows collaboration to happen. |
| # | |
| # IOSP - Integration Operation Segregation Principle | |
| # | |
| Code is separated into functions of logic (operation) and non-logic (integration) - Ralf Westphal | |
| IOSP calls for a clear separation: | |
| * Operation: a method contains logic, transformations, control structures or API invocations | |
| * Integration: a method only contains calls to other methods within its code base |
| # | |
| # SRP - Single Responsibility Principle | |
| # | |
| Each software module should have only one reason to change. | |
| Gather together those things that change for the same reason, and separate those things that change for different reasons. - Robert C. Martin | |
| Example: |
| # | |
| # POMO - Principal of Mutual Oblivion | |
| # | |
| Two modules at the same level of abstraction should not know each other. ("mutual oblivion" - not knowing each other) | |
| It is the independece of parts - no functional units knows another one. They are all completely independent of each other. - Ralf Westphal | |
| Example - muscle movement in human bodies: | |
| A nerve cell does not know anything about a muscle cell and a muscle cell does not know anything about a nerve cell. All they do is follow a simple contract: Acetylcholine (ACh) - one produces ACh as output, the other consumes ACh as input. |
| # | |
| # LOLA - Law of Leaky Abstraction | |
| # | |
| All abstractions are leaky. The outsider may need to know some insider information to use the abstraction. | |
| An abstraction should not hide that which it abstracts, but rather simplify access to the underlying complexity. - Joel Spolsky | |
| Example: | |
| * Automobiles have abstractions for drivers: There is a steering wheel, accelerator and brake. This abstraction hides a lot of detail about what's under the hood: engine, cams, timing belt, spark plugs, radiator, etc. |
| # | |
| # SLA - Single Level of Abstraction | |
| # | |
| Within a certain method we look to keep all the code at the same level of abstraction to help us read it more easily. - Robert C. Martin | |
| A helpful analogy is a newspaper article: | |
| 1) First comes is the most important thing – the heading. From this you should roughly know what the article is about. | |
| 2) The first sentence of the article describes it on a high level of abstraction. |
throwtheswitch libraries: Unity, Cmock, Ceedling, etc http://www.throwtheswitch.org/
UNITY, Unit Testing for C (especially Embedded Software) http://www.throwtheswitch.org/unity/
CMock, Automated Mock & Stub Generation For C http://www.throwtheswitch.org/cmock/
This gist lists various C++ 'quick benchmarks' that have been written on quick-bench.com to test/verify various hypotheses. Quick Bench makes use of Google Benchmark.
Reserve in a vector vs not reserve
Cost of data indirection (e.g. direct vs pointer vs pointer-to-pointer)
