expo/expoweb
1
0
Fork 0
mirror of https://expo.survex.com/repositories/expoweb/.git/ synced 2024-11-22 07:11:55 +00:00
Code Issues Packages Projects Releases Wiki Activity

Kill it with Fire

Browse Source
This commit is contained in:
Philip Sargent 2021-12-05 23:57:56 +00:00
parent a2c2427114
commit 71f3e762eb
6 changed files with 80 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

BIN
handbook/i/dumpsterfire.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 115 KiB

BIN
handbook/i/killitwithfire.jpg Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 31 KiB

13
handbook/troggle/trogdjango.html
View File

@ -41,18 +41,21 @@ note that the suffix on a name '<var>'_set</var> actually denotes a function cal
<p>Every extra plugin increases the "vulnerability surface" of troggle with respect to django upgrade problems so we now only install a new plugin if it is really, really necessary and we have removed as many as we could. For example, when django-staticfiles broke during one upgrade we discovered that we could use our own troggle.expopages as a workaround, so we are not planning on reinstalling staticfiles if we don't have to.
<h4>Why we still use django</h4>
<h4 id="4layer">Why we still use django</h4>
<p>Well we <a href="trog2030.html">might not use django indefinitely</a>, but unlike many frameworks the necessary functions are separately replaceable. So this gives us an evolution path. We can incrementally reduce the amount of django we use, replacing it with our own simpler python that does only what we need.
<p>The separate functions within the framework form a "stack". These functions exist in all web application frameworks but in Django they are <a href="https://docs.djangoproject.com/en/dev/misc/design-philosophies/">loosely coupled</a>.
<p>The stack is:
<ol>
<li>SQL database: <a href="https://docs.djangoproject.com/en/dev/topics/db/">mapping</a> to/from python objects and indexing/access routines for all the entries (sqlite, MySQL, MariaDB, postgres all work)
<li>request/response (<a href="https://docs.djangoproject.com/en/dev/ref/request-response/">http GET/POST</a>) including <a href="https://docs.djangoproject.com/en/dev/topics/auth/default/#auth-web-requests">access control</a> and <a href="https://www.moesif.com/blog/engineering/middleware/What-Is-HTTP-Middleware/">security middleware</a>,
<li><a href="https://docs.djangoproject.com/en/dev/topics/http/urls/">URL mapping/dispatch</a> which matches a requested URL with a chunk of python code, and vice versa (declarative and bidrectional),
<li>SQL database: <a href="https://docs.djangoproject.com/en/dev/topics/db/">mapping</a> to/from python objects and indexing/access routines for all the entries (sqlite, MySQL, MariaDB, postgres all work). This is where the multi-user synchronisation happens too.
<li>request/response (<a href="https://docs.djangoproject.com/en/dev/ref/request-response/">http GET/POST</a>) including <a href="https://docs.djangoproject.com/en/dev/topics/auth/default/#auth-web-requests">access control</a> and <a href="https://www.moesif.com/blog/engineering/middleware/What-Is-HTTP-Middleware/">security middleware</a>. We could never keep up with web security if we didn't use a well-supported system for this.
<li><a href="https://docs.djangoproject.com/en/dev/topics/http/urls/">URL mapping/dispatch</a> which matches a requested URL with a chunk of python code, and vice versa (declarative and bidrectional). "Cool URIs don't change."
<li><a href="https://docs.djangoproject.com/en/dev/topics/templates/">templates</a> which format the results of data queries into HTML pages or JSON data exports
</ol>
<p>See the <a href="https://docs.djangoproject.com/en/dev/misc/design-philosophies/">django design philosophy</a> on 'loose coupling and tight cohesion'. Note that having a URL dispatcher that supports <a href="https://docs.djangoproject.com/en/dev/topics/http/urls/#s-reverse-resolution-of-urls">reverse resolution</a> is important: it is a key reason why we need a framework and not just a mess of javascript. We have nearly 100 URL patterns.
<p>See the <a href="https://docs.djangoproject.com/en/dev/misc/design-philosophies/">django design philosophy</a> on 'loose coupling and tight cohesion'. Note that having a URL dispatcher that supports
<a href="https://docs.djangoproject.com/en/dev/topics/http/urls/#s-reverse-resolution-of-urls">reverse resolution</a>
is important: it is a key reason why we need a framework and not just a mess of javascript. We have nearly 100 URL patterns.
We should try to reduce the number of distinct URLs perhaps, but they help document the structure too.
<hr />

1
handbook/troggle/trogindex.html
View File

@ -24,6 +24,7 @@
<li><a href="trogsimpler.html">Troggle - a kinder simpler troggle?</a> - Radost's proposals (critiqued)<br>
<li><a href="trogspeculate.html">Troggle Architecture Speculations</a> - as in April 2020<br>
<li><a href="trog2030.html">Troggle in 2025-2030</a> - architectural evolution proposal<br>
<li><a href="trogkill.html">Troggle - Kill it with Fire</a> - rewrite considerations<br>
</ul>
<a href="troglaptop.html">Troggle laptop configuration</a> - how to set up a software development machine<br>
<ul>

61
handbook/troggle/trogkill.html Normal file
View File

@ -0,0 +1,61 @@
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Handbook Troggle Kill it with Fire</title>
<link rel="stylesheet" type="text/css" href="../../css/main2.css" />
</head>
<body><style>body { background: #fff url(/images/style/bg-system.png) repeat-x 0 0 }</style>
<h2 id="tophead">CUCC Expedition Handbook</h2>
<h1>Troggle - Kill it with Fire</h1>
<p>This is a book: <em>Kill It With Fire: Managing Aging Computer Systems (And Future Proof Modern Ones)</em>
<p>Read the brief reviews:
<a href="https://www.amazon.co.uk/Kill-Fire-Manage-Computer-Systems/dp/1718501188">
<img border="1" class="onright" width="150px" src='../i/killitwithfire.jpg' alt='book cover image'/></a>
<ul>
<li>on <a href="https://nostarch.com/kill-it-fire">No Starch Press</a>
<li>on <a href="https://www.amazon.co.uk/Kill-Fire-Manage-Computer-Systems/dp/1718501188">Amazon.co.uk</a>
<li>on <a href="https://www.goodreads.com/book/show/54716655-kill-it-with-fire">Goodreads</a>
</ul>
<p>About a third of the book is about management and doing repair/rewrite inside large organisations, but
nearly half of it is directly relevant to us:
<ul style="list-style-type:square; line-height:115%; padding-left: 20px;">
<li>Consider <em>iteration in place</em> as the default approach.
<li>Beware of <em>artificial consistency</em> as proposed to "improve" technical value.
<li>Don't assume that what you can't see is simple to replace: there may be years of effort hiding considerable complexity which appears simple on the surface.
<li>Previous modernization efforts may have left behind serious scar tissue which you need to consider.
<li>Many people try to fix things which are not, in fact, broken. Don't optimise beyond diminishing returns.
<li>Modernization needs momentum to finish the job: don't take on risks without also producing compelling value.
<li>Decisions made to <em>avoid rewriting the new code later</em> are usually bad decisions.
<li>The only thing worse than attempting to fix the wrong thing is leaving the fix attempt unfinished.
<li>Site reliability expressed as uptime percentages is rarely the real issue.
<li>Speed of recovery after failure is always more important than you think.
<li>A perfect record of no failures can always be broken, but resilience is an accomplishment that lasts.
<li>Know when to run a systemic Code Yellow hackathon and when not to.
<li>Always discover why previous modernisations failed <em>first</em>.
<li>Spend a lot of time <em>problem setting</em> before you start to think about <em>problem solving</em>.
<li>Working through a major modernisation is all about managing <em>scope</em>.
<li>Code is much easier to write than it is to read. Modernisaton means a lot of <em>code reading</em>.
<li>Human beings are absolutely terrible at estimating probabilities and risk. We always under-estimate the amount of work in a rewrite and over-estimate the likelihood of success.
<li>Success does not come all at once. What are the <em>progressive success criteria</em> during the reengineering?
<li>Use <em>Diagnosis, Policy, Actions</em> where there is little consensus about what success looks like.
<li>Use <em>bullet journalling</em> to maintain your own morale during a re-engineering project.
<li>When a failure is <em>user input</em>, fail gracefully with helpful message.
<li>When a failure is due to <em>a programming or specification bug</em>, fail hard and fast.
<li>Build simple, <em>performant</em> systems before you start on the bells and whistles.
<li>Prioritise simple code running fast early, so that you can iterate fast.
<li>An existing system is <em>not</em> a reliable specification for the proposed new system. Important behaviour will be implicit, not documented.
</ul>
<p>The book was published in March 2021.
<br>
<hr />
Return to: <a href="trogintro.html">Troggle intro</a><br />
Return to: <a href="trognotes.html">Troggle Programming Guide</a><br />
<hr />
</body>
</html>

10
handbook/troggle/trognotes.html
View File

@ -49,6 +49,16 @@ live and in-use: all the foreign keys and relationship cardinalities.
<p>And, you may be surprised to discover, we have given a lot of thought into how to make it easier for you
to <a href="../computing/contribute.html#programming">get involved in the programming</a> while not screwing up this multi-decade software project.
<h3>Kill it with Fire</h3>
<a href="trogkill.html">
<img border="1" class="onright" width="150px" src='../i/dumpsterfire.jpg' alt='dumpster fire'/></a>
<p>Everyone at some point feels like giving up and wonders if we should just rewrite it all from scratch using 'modern' techniques.
Several of us have given this a lot of thought, see <a href="trogsimpler.html">'A kinder, simpler troggle'</a>,
the <a href="trog2030.html">2030 plan</a>, <a href="trogspeculate.html">architecture constraints</a> and most importantly, <a href="trogdjango.html#4layer">the 4-layer stack</a> <em>any</em> future technology with some public URLs would need to emulate.
<p>We have also been learning from the global software community when you really do need to 'Kill it with Fire': what are
the characteristics of code and of organisations that mean that it is a good idea to give up, and if so how to
manage the rewrite. The answers are "almost never" and "don't": as explained in <a href="trogkill.html">this summary of the book 'Kill it with Fire'</a>.
<h3>Perhaps an external add-on?</h3>
<p>Perhaps you can program something external to troggle, in JavaScript say, using troggle data?
<ul>