expo/expoweb
1
0
Fork 0
mirror of https://expo.survex.com/repositories/expoweb/.git/ synced 2025-12-08 14:54:28 +00:00
Code Issues Packages Projects Releases Wiki Activity

the wrong things - online edit of handbook/troggle/trog2030.html

Browse Source
This commit is contained in:
Philip Sargent
2025-06-28 08:11:28 +01:00
committed by Expo on server
parent 88c6b59976
commit 286f21d5a9
1 changed files with 9 additions and 6 deletions
Download Patch File Download Diff File Expand all files Collapse all files

15
handbook/troggle/trog2030.html
View File

@@ -22,10 +22,7 @@
there is such a lot going on we would create a large volume of software even if we stick close to the metal.
[I could well be wrong. That is Option 1.]
<h3>[ Update March 2024 ]</h3>
"Legacy displacement" is now a fairly mature part of software engineering, though most computer science graduates won't have heard of it. There are standard ways of partially and incrementally retiring old systems and replacing them, while maintaining a live service to users throughout. See <a href="https://martinfowler.com/articles/patterns-legacy-displacement/">Legacy Displacement</a>.
<div class="onright">
<div class="onright">
<figure >
<a href="https://martinfowler.com/articles/patterns-legacy-displacement/#UnderstandingTheOutcomes">
<img width=350 src="legacy-replace.jpg"></a>
@@ -33,11 +30,17 @@ there is such a lot going on we would create a large volume of software even if
</figure>
</div>
<h3>[ Update March 2024 ]</h3>
"Legacy displacement" is now a fairly mature part of software engineering, though most computer science graduates won't have heard of it. There are standard ways of partially and incrementally retiring old systems and replacing them, while maintaining a live service to users throughout. See <a href="https://martinfowler.com/articles/patterns-legacy-displacement/">Legacy Displacement</a>.
</a>
<h3>Option 2</h2>
<h3>[ Update May 2025 ]</h3>
<p>What we have learned over the past 6 years, as we have tried to simplify troggle, is that the essential quality of django that we use the most is <em>indexing</em>: being able to find a cave, entrance, logbook entry, survex file etc. with a query.
<p>Also, we do not use the database because we have have a lot of data (it's tiny), but because it gives us multi-user serialization.
<p>So many of the previous efforts to "improve things" have been aimed at improving <em>the wrong things</em>.
<h2>Option 2</h2>
<p>
We keep the same architecture as now, and incrementally replace modules that use django/SQL with direct object storage of collections using pickle(), shelve() and json().
Concurrency is not a problem as all data is read-only (this is not <em>entirely</em> true - see below).