diff options
Diffstat (limited to 'blog')
| -rw-r--r-- | blog/content/notes/index.gmi | 1 | ||||
| -rw-r--r-- | blog/content/notes/interesting-articles.gmi | 16 | ||||
| -rw-r--r-- | blog/content/notes/tech/internet-basics.gmi | 26 | ||||
| -rw-r--r-- | blog/content/notes/tech/misc-python-stuff.gmi | 3 | ||||
| -rw-r--r-- | blog/content/notes/tech/on-testing.gmi | 23 |
5 files changed, 55 insertions, 14 deletions
diff --git a/blog/content/notes/index.gmi b/blog/content/notes/index.gmi index b4ad7d0c..c47a8c03 100644 --- a/blog/content/notes/index.gmi +++ b/blog/content/notes/index.gmi @@ -40,6 +40,7 @@ Notes about some books and long articles I like: => tech/motivating-example-for-logical-replication-for-dynamic-ui Motivating example for logical replication for dynamic UI => tech/about-web-development About web development => tech/on-software-development On software development +=> tech/on-testing On testing => tech/internet-basics Internet basics => tech/splicing-mkvs Splicing MKVs => tech/what-i-would-like-to-see-in-a-forge What I would like to see in a forge diff --git a/blog/content/notes/interesting-articles.gmi b/blog/content/notes/interesting-articles.gmi index 78ba6995..7966f6dd 100644 --- a/blog/content/notes/interesting-articles.gmi +++ b/blog/content/notes/interesting-articles.gmi @@ -10,6 +10,9 @@ Simplicity is sacrifice. See also: => https://www.geoffreylitt.com/2025/03/03/the-nightmare-bicycle.html Avoid the nightmare bicycle Good designs expose systematic structure; they lean on their users’ ability to understand this structure and apply it to new situations. +=> https://earthly.dev/blog/thought-leaders/ Don't Feed the Thought Leaders +Contingent advice (that depends on the situation) is in general better than generic advice. In my experience, one of the most difficult parts is knowning when you have to deviate from common practices. + ## Programming => https://mikehadlow.blogspot.com/2012/05/configuration-complexity-clock.html The Configuration Complexity Clock @@ -41,16 +44,7 @@ The history about Hungarian notations => https://www.hillelwayne.com/post/we-are-not-special/ We are not special Second of a series of three articles comparing software engineering with traditional engineering. Mostly dispels some myth and lack of knowledge about traditional engineering. -### Testing - -=> https://testing.googleblog.com/2014/05/testing-on-toilet-risk-driven-testing.html Testing on the Toilet: Risk-Driven Testing -"Your tests are a means. The bang is what counts. It’s your job to maximize it." - -=> https://testing.googleblog.com/2024/10/smurf-beyond-test-pyramid.html SMURF: Beyond the Test Pyramid -Test categories and the pyramid are excessively limited models. - -=> https://abseil.io/resources/swe-book/html/ch11.html#the_beyonceacutesemicolon_rule The Beyoncé Rule -"If you liked it, then you shoulda put a test on it." +=> tech/on-testing See also my own "on testing" for further notes about testing, including risk-driven testing, the Beyoncé rule, SMURF, test doubles (dummies, fakes, stubs, spies, and mocks), and classic/mockist testing (also Chicago/Detroit/London). ### Python @@ -175,8 +169,6 @@ A type of human behavior reactivity in which individuals modify an aspect of the => https://en.wikipedia.org/wiki/Novelty_effect Novelty effect An effect of introducing new elements on some activity or behavior. -=> https://softwareengineering.stackexchange.com/questions/123627/what-are-the-london-and-chicago-schools-of-tdd What are the London and Chicago schools of TDD? - => https://en.wikipedia.org/wiki/Sturgeon%27s_law Sturgeon's law An adage stating "ninety percent of everything is crap". diff --git a/blog/content/notes/tech/internet-basics.gmi b/blog/content/notes/tech/internet-basics.gmi index f83082c7..651f480b 100644 --- a/blog/content/notes/tech/internet-basics.gmi +++ b/blog/content/notes/tech/internet-basics.gmi @@ -17,3 +17,29 @@ The ISP must control use of the email addresses with the domain to prevent spam. Delivery targets decouple the email domain from the email service that stores the email. Users can choose to store email in whatever service they prefer, including an ISP service or other services. Email services must support transferring stored email. + +## Everyone must have a feed reader. All website updates should work with feed readers + +Getting updates from websites is tedious. + +Many use social networks to centralize updates. However, social networks are mostly controlled by entities not aligned with you. Also, social networks are rarely used to centralize updates, so they tend to be suboptimal for this purpose. + +RSS, ATOM and others are standards for sites to provide feeds of updates. There are plenty of feed readers. + +When you use multiple devices to follow updates, having device synchronization of subscribed feeds and read items is nearly a necessity. + +## Everyone must have sufficient data storage with sufficient resilience and control + +Keeping data with sufficient resiliency is complex, because making proper backups is difficult and tedious. + +Many storage providers do not give you enough control over your data if you want to move to a different provider. You should always keep a full copy of your data that you can access without the Internet. (You can achieve this by using systems that keep your data synchronized to at least a device you control, or by keeping your own backups.) + +(A way to provide this would be for NAS devices to support easy interoperable mutual encrypted backups, so that you can easily back up your data to someone you know in a way that they cannot read your data unless you want them to.) + +## Everyone must have a good password manager or trustable federated identities + +For good security, online accounts should have strong, unique passwords or no password at all. + +Strong unique passwords are still the best option, despite passkeys and federated identities, because they are lowest-common denominator and simple. + +Federated identities are useful, as long as the entity providing them is of enough trust for you. The providing entity can fail, deny you access, or die at any time, taking your federated identity with you. diff --git a/blog/content/notes/tech/misc-python-stuff.gmi b/blog/content/notes/tech/misc-python-stuff.gmi index f7cc33e7..1dc94a18 100644 --- a/blog/content/notes/tech/misc-python-stuff.gmi +++ b/blog/content/notes/tech/misc-python-stuff.gmi @@ -2,10 +2,9 @@ ## Tools -* Use uv for your software. It's modern and good. +* Use hatch for your software. * pipx is packaged by many distros and useful for installing Python software. Provide instructions for installing your software using pipx. * Use pytest for testing. It's PEP-8 compliant unlike unittest in the standard library. doctest is good too. -* Use ruff for validation. ## Python versions diff --git a/blog/content/notes/tech/on-testing.gmi b/blog/content/notes/tech/on-testing.gmi new file mode 100644 index 00000000..5bcccaa2 --- /dev/null +++ b/blog/content/notes/tech/on-testing.gmi @@ -0,0 +1,23 @@ +# On testing + +This document is mostly a collection of links with some annotations. + +=> https://testing.googleblog.com/2014/05/testing-on-toilet-risk-driven-testing.html Your tests are a means. The bang is what counts. It’s your job to maximize it. + +=> https://abseil.io/resources/swe-book/html/ch11.html#the_beyonceacutesemicolon_rule The Beyoncé Rule says that you should test automatically anything you don't want to break. The Beyoncé rule also implies that you can break things that are not tested. + +=> https://testing.googleblog.com/2024/10/smurf-beyond-test-pyramid.html Test categories and the pyramid are excessively limited models; SMURF evaluates tests along the tradeoffs of speed, maintainability, utilization (resource usage), reliability, and fidelity. Instead of spending effort thinking about test types, try to write tests that cover what you do not want to break (as per the Beyoncé rule above) while balancing the SMURF tradeoffs. + +Test doubles are components that replace parts of a system in a test. The following documents explain different kinds of useful test doubles: + +=> https://testing.googleblog.com/2013/07/testing-on-toilet-know-your-test-doubles.html Know Your Test Doubles + +=> https://martinfowler.com/articles/mocksArentStubs.html Mocks Aren't Stubs + +"Mocks Aren't Stubs" also discusses the classic and mockist test styles (the classic style is also known as Detroit or Chicago style or school, while the mockist style is known as London style or school). Classic testing validates state, using doubles only when necessary (probably because of SMURF tradeoffs); mockist testing verifies interactions by using mocks. + +(My personal opinion is similar to Martin Fowler's in "Mocks Aren't Stubs", you should use classic testing and structure your programs to simplify classic testing, unless for specific scenarios where mocks are better, such as the example posed by Martin: + +> A great example of this is a cache. The whole point of a cache is that you can't tell from its state whether the cache hit or missed - this is a case where behavior verification would be the wise choice for even a hard core classical TDDer. I'm sure there are other exceptions in both directions. + +You should also reduce the use of doubles as much as possible within the SMURF tradeoffs, probably also influencing the structure of your programs.) |