| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| reading:2023:w27 [2023/07/02 13:40] – pluralistic, enshittification pfm | reading:2023:w27 [2023/07/09 08:40] (current) – broszura: Czy praca naprawdę popłaca? pfm |
|---|
| ====== Week 2023-W27 in reading ====== | ====== Week 2023-W27 in reading ====== |
| |
| ===== Longitudinal Evaluation of Open-Source Software Maintainability ===== | ===== Reactive systems ===== |
| |
| Source: [[https://arxiv.org/abs/2003.00447|arXiv:2003.00447]]. | Sources: |
| |
| ==== Definitions ==== | - [[https://www.reactivemanifesto.org/|Reactive Manifesto]] |
| | - [[https://www.reactiveprinciples.org/|Reactive Principles]] |
| |
| > **Maintainability** is the "degree of effectiveness and efficiency with which a product or system can be modified to improve it, correct it or adapt it to changes in environment, and in requirements". | Key properties of a Reactive system: |
| |
| > **Maintenance hotspots**, (...) parts of the source code that are most difficult to maintain. | * responsive --- responds in a reasonable time if possible; |
| | * resilient --- stays responsive even when failures occur (e.g. fail gently, isolate failures so they don't propagate and cause the whole system to fail); |
| | * elastic --- stays responsive under varying load; |
| | * message-driven --- relies on asynchronous communication. |
| |
| ==== Quotes ==== | My key take-away here is that asynchronously processed messages update some model behind the scenes, so when the time comes to return some data to the user, it is ready. However, this probably involves eventual consistency and increased complexity. |
| |
| > You cannot control what you cannot measure. | See also: |
| > --- DeMarco, T. (1982). [[https://isbnsearch.org/isbn/9780131717114|Controlling Software Projects; Management, Measurement and Estimation]]. | |
| |
| ==== Notes ==== | * [[https://martinfowler.com/eaaDev/EventSourcing.html|Martin Fowler's "Event Sourcing"]] |
| | * [[https://learn.microsoft.com/en-us/azure/architecture/patterns/bulkhead|Bulkhead pattern]] |
| |
| Models: | ===== Evolving HTTP APIs ===== |
| |
| - **Maintainability Index** --- a value calculated based on Halstead volume, cyclomatic complexity, and number of source code statements (or lines of code). | Source: [[https://www.mnot.net/blog/2012/12/04/api-evolution|Evolving HTTP APIs]] |
| - **Technical Debt Ratio** --- amount of time required to fix all issues divided by the estimated time to create the software system. Calculated by SonarQube. | |
| - **ARiSA Model for Maintainability** --- developed according to [[wp>ISO/IEC 9126|ISO 9126]] standard. It takes into account complexity, structure and design metrics to calculate a value assessing maintainability. | |
| |
| The study compared models mentioned above by applying them to 3 FOSS applications (FreeMind, jEdit and TuxGuitar). | - Compatible versions shouldn't cause any adjustments (shouldn't change versions). |
| | - Avoid major / incompatible versions. |
| | - Be backward-compatible, but still limiting the impact. New version requires everyone to adapt, so keeping the same version with some adjustments might make more sense from effort perspective. |
| |
| Further reading about the Maintainability Index: | ===== Self-contained Systems ===== |
| |
| * According to [[https://sourcery.ai/blog/maintainability-index/|Maintainability Index - What is it and where does it fall short?]], MI relies too much on LOC (among other things). | Sources: |
| * [[https://avandeursen.com/2014/08/29/think-twice-before-using-the-maintainability-index/|Think Twice Before Using the "Maintainability Index"]] mentions research done by "SIG" (Software Improvement Group?) and links to further articles on the topic. | |
| |
| My take-away is that while these methods can be useful, they probably won't be for Scala code-bases since branching is often hidden behind higher-order functions. Also, Scala is such an advanced language, that sometimes its own rich feature set adds to the complexity and decreases maintainability. | - [[https://www.innoq.com/en/articles/2016/11/self-contained-systems-different-microservices/|Self-contained Systems: A Different Approach to Microservices]] |
| | - [[https://scs-architecture.org/|Self-Contained Systems]] |
| |
| ===== Pluralistic: Tiktok's enshittification (21 Jan 2023) ===== | This idea doesn't sound very innovative, while it does sound a bit strict. Experience tells me being strict is good in theory, while practice one has to be flexible/open and mix things to achieve goals. |
| |
| Source: [[https://pluralistic.net/2023/01/21/potemkin-ai/#hey-guys|Pluralistic: Tiktok's enshittification (21 Jan 2023)]] (a //long// read). | ===== Firefox 115.0 release notes ===== |
| |
| In this essay, Cory Doctorow describes a life-cycle of an internet platform (not necessarily social media). A platform: | According [[https://www.mozilla.org/en-US/firefox/115.0/releasenotes/|to release notes]]: |
| |
| - provides value to its users; | > Certain Firefox users may come across a message in the extensions panel indicating that their add-ons are not allowed on the site currently open. We have introduced a new back-end feature to only allow some extensions monitored by Mozilla to run on specific websites for various reasons, including security concerns. |
| - abuses users to benefit business customers; | |
| - abuses business customers to benefit itself. | |
| |
| But along the way, people start depending on the platform so much that they can't leave it even when it becomes barely usable, like when users don't see what they'd subscribed for on Twitter or Facebook, but they see a lot of rubbish they didn't ask for. | However, this isn't very transparent about those other reasons for blocking extensions. Could for example Google request Mozilla to disable ad-blockers on YouTube? |
| |
| Right now we see some platforms trying out the last step: | ===== Czy praca naprawdę popłaca? ===== |
| |
| * Reddit [[https://arstechnica.com/gadgets/2023/06/reddit-api-changes-are-imminent-heres-whats-happening-to-your-favorite-apps/|changes API pricing]], leading to some applications shutting down. | Źródło: |
| * Twitter [[https://www.nytimes.com/2023/07/01/business/twitter-rate-limit-elon-musk.html|limits numbers of tweets]] users can read daily, supposedly to make [[wp>Web scraping|web scraping]] harder. | * broszura otrzymana na [[kongresono:2023|Kongresono 2023]]; |
| | * online (ang.): [[http://spunk.org/library/writers/brown/sp001735.html|Does Work Really Work?]], |
| | * kopia dostępna w [[https://theanarchistlibrary.org/library/l-susan-brown-does-work-really-work|The Anarchist Library]], |
| | * tłumaczenie: [[https://nieporzadekdistro.wordpress.com/|nieporządek distro]] |
| |
| Decentralised alternative to corporate social-media called [[wp>Fediverse]] has already noticed a huge influx of new users over the recent months and I suspect it will continue. | W tym krótkim tekście [[wppl>L. Susan Brown]]: |
| | - wyjaśnia dlaczego relacja pracodawca--pracownik jest identyczna z relacją pan--niewolnik --- bo pracownik rezygnuje z części swojej wolności na czas wykonywania pracy najemnej; |
| | - podważa pojęcie "własności w osobie" --- pracownik jest niepodzielną istotą i nie może oddelegować pracy do swoich umiejętności wykorzystywanych przez pracodawcę, tylko całą swoją osobę angażuje w wykonywanie pracy (nie może np. skorzystać ze wszystkich innych swoich umiejętności i możliwości); |
| | - pokazuje że barter wcale nie jest rozwiązaniem i przytacza trudności z oceną wartości pracy; |
| | - zachęca do tzw. //pracy wolnej//, wykonywanej z poczucia potrzeby a nie dla zysku. |
| | |
| | Przykładem pracy wolnej jest np. moje zaangażowanie w FOSS. |
| |