Laelith Wiki

User Tools

Site Tools

Trace: • 290.2.3.0 • the-dwarvery • the-penitents • 18.5.2.0 • 17.5.2.0 • the-blackened-houses • 4.0.1 • killhem-tree • the-dyers • 1.5.0.0
en:outskirts:mages-peaks:mages-principles

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
en:outskirts:mages-peaks:mages-principles [2023/11/12 21:30] – ↷ Page moved from en:laelith:high-terrace:mages-peaks:mages-principles to en:outskirts:mages-peaks:mages-principles YannZeRookieen:outskirts:mages-peaks:mages-principles [2024/10/28 08:00] (current) – external edit 127.0.0.1
Line 19: Line 19:
 ===== Principle #2: “Code to minimum, put it in the hands of users quickly, and be ready to throw away and rewrite everything” ===== ===== Principle #2: “Code to minimum, put it in the hands of users quickly, and be ready to throw away and rewrite everything” =====
  
-{{ en:laelith:high-terrace:mages-peaks:mages-principles:matt-palmer-ipum7ket2jo-unsplash.jpg?nolink&400|}}+{{ en:outskirts:mages-peaks:mages-principles:matt-palmer-ipum7ket2jo-unsplash.jpg?nolink&400|}}
  
 In opposition to the [[https://en.wikipedia.org/wiki/Principle_of_least_effort|Principle of Least Effort]], over-engineering is a common disease in software development. It can come from several factors: poor or incomplete specifications from stakeholders, personal desire to impress others or to indulge oneself, the will to do the Big Thing the right way from the get-go, etc. In opposition to the [[https://en.wikipedia.org/wiki/Principle_of_least_effort|Principle of Least Effort]], over-engineering is a common disease in software development. It can come from several factors: poor or incomplete specifications from stakeholders, personal desire to impress others or to indulge oneself, the will to do the Big Thing the right way from the get-go, etc.
Line 38: Line 38:
 ===== Principle #3B: “…but it may still be useful to craft your own scooter” ===== ===== Principle #3B: “…but it may still be useful to craft your own scooter” =====
  
-{{ en:laelith:high-terrace:mages-peaks:mages-principles:dmitry-vechorko-43npci0njly-unsplash.jpg?nolink&400|}}+{{ en:outskirts:mages-peaks:mages-principles:dmitry-vechorko-43npci0njly-unsplash.jpg?nolink&400|}}
 At the same time, ask yourself if you are not crushing a molehill with a bulldozer where a simple shovel would have made the job just nicely (Principle #1). Some libraries are so bloated, trying to solve everything by writing the Equation of the Universe, that they become huge. As a result, you overload your code. On top of this, the number of dependencies is so large that such libraries can become fragile or introduce incompatibilities. This can become a big problem. At the same time, ask yourself if you are not crushing a molehill with a bulldozer where a simple shovel would have made the job just nicely (Principle #1). Some libraries are so bloated, trying to solve everything by writing the Equation of the Universe, that they become huge. As a result, you overload your code. On top of this, the number of dependencies is so large that such libraries can become fragile or introduce incompatibilities. This can become a big problem.
  
Line 54: Line 54:
 You are also welcomed to check out the #help channel and help the poor Pilgrims who are lost. You are also welcomed to check out the #help channel and help the poor Pilgrims who are lost.
  
-{{ en:laelith:high-terrace:mages-peaks:mages-principles:sharon-mccutcheon-uxs73pngytc-unsplash.jpg?nolink&300|}}+{{ en:outskirts:mages-peaks:mages-principles:sharon-mccutcheon-uxs73pngytc-unsplash.jpg?nolink&300|}}
 ===== Principle #5: “GitHub and Pull Requests are our oyster” ===== ===== Principle #5: “GitHub and Pull Requests are our oyster” =====
  
Line 71: Line 71:
 This being said, there are some areas when it is more difficult or makes less sense to perform automated testing – or it becomes too much of a chore to maintain. An example is to perform automated tests on user interfaces. This is difficult. If you want to walk this path, check out advanced tools such as [[https://playwright.dev/|Playwright]] or similar. And always keep in mind Principle #1. This being said, there are some areas when it is more difficult or makes less sense to perform automated testing – or it becomes too much of a chore to maintain. An example is to perform automated tests on user interfaces. This is difficult. If you want to walk this path, check out advanced tools such as [[https://playwright.dev/|Playwright]] or similar. And always keep in mind Principle #1.
  
-{{ en:laelith:high-terrace:mages-peaks:mages-principles:dmitry-vechorko-q7qznp-vslm-unsplash.jpg?nolink&300|}}+{{ en:outskirts:mages-peaks:mages-principles:dmitry-vechorko-q7qznp-vslm-unsplash.jpg?nolink&300|}}
 ===== Principle #7: “Google Doc then Wiki” ===== ===== Principle #7: “Google Doc then Wiki” =====
  
Line 96: Line 96:
 This principle is a result of the previous one: the success or failure of UI and UX always lies in tiny details. But this is also true for code architecture, code writing styling, naming things properly, designing data models, writing relevant comments, performing good peer reviews, etc. Details are important, and yes, it can be tedious to polish these last 10% (which often take you much more than 10% of the project time). This principle is a result of the previous one: the success or failure of UI and UX always lies in tiny details. But this is also true for code architecture, code writing styling, naming things properly, designing data models, writing relevant comments, performing good peer reviews, etc. Details are important, and yes, it can be tedious to polish these last 10% (which often take you much more than 10% of the project time).
  
-{{ en:laelith:high-terrace:mages-peaks:mages-principles:sander-sammy-phoypwql--w-unsplash.jpg?nolink&300|}}+{{ en:outskirts:mages-peaks:mages-principles:sander-sammy-phoypwql--w-unsplash.jpg?nolink&300|}}
 ===== Principle #10: “We pay attention to security” ===== ===== Principle #10: “We pay attention to security” =====
  
Line 113: Line 113:
 Last but not least: we Mages have a very specific set of superpowers. Our duty and or reward is to use these to serve the Laelith community. This should be the North Star of everything that we do: does this new feature, technology, idea, trick, effort, etc. bring something useful and valuable to the Laelith community? Everything else, including our ego, is irrelevant. Last but not least: we Mages have a very specific set of superpowers. Our duty and or reward is to use these to serve the Laelith community. This should be the North Star of everything that we do: does this new feature, technology, idea, trick, effort, etc. bring something useful and valuable to the Laelith community? Everything else, including our ego, is irrelevant.
  
-{{ en:laelith:high-terrace:mages-peaks:mages-principles:amandine-bataille-31muw23ql74-unsplash.jpg?nolink&600 |}}+{{ en:outskirts:mages-peaks:mages-principles:amandine-bataille-31muw23ql74-unsplash.jpg?nolink&600 |}}
  
  
en/outskirts/mages-peaks/mages-principles.1699824629.txt.gz · Last modified: 2024/10/28 08:00 (external edit) · Currently locked by: ::1,216.73.216.252