Home - Matt Whipple

Josephus Recurrence

Repetoire Method

Queue

Transactions on Data Science

C++ Crash Course

Cracking the Coding Interview

TODO Net: SSH

Linksys WRT1900AC

Swing For the Fences or Bunt

Chromebook

ChromeOS

• Quirks
  
  • Storage Space
    

Disk Space

Potential Personal Tipping Point

Evaluation Without Prompting

(setq org-confirm-babel-evaluate nil)

Exercism

HackerRank

Using MFA and Role Assumption from Command Line Bash

• Why Separate Tools May Make Things Worse
  

  An fundamental concern when using some of these tools to manage authentication is that there is no straightforward means to populate the environment variables to support that approach. When invoking a command from a shell on a POSIX-y OS that command will normally be run in a forked process; that forked process can read exported environment variables from the shell but can't modify or otherwise muck around with those variables. The allowance of such access could present some fairly obvious dangers both intentional or accidental, and while some creative solutions such as using `exec` to load code into the current process may be possible, they are best avoided for that reason. The safe and common solution for this type of problem would be some mechanism of IPC where the invoking shell is able to retrieve the appropriate values and update the environment accordingly. Obviously additional tools could provide these values back to the shell, but at that point their value over using the AWS CLI effectively vanishes.

• Cutting Out the Middle Man
  

  The AWS CLI can provide the values required for the environment so rather than introducing an intermediary the simplest approach is to simply load those values into the current environment as retrieved from the CLI. There's often a tendency to gravitate towards output formats such as JSON which can quickly introduce additional complexities around handling such values in bash, but the AWS also supports simple text output which is fits neatly within bash's wheelhouse. Simple, space delimited text can be easily parsed with bash so the retrieval of these values from a call to the AWS CLI can be as simple as:

  read AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN << $(aws sts..)
  

  This approach works as long as the command produces the expected fields in the expected format, the above will parse the output produced if the AWS call is provided the arguments:

  --query 'Credentials.[AccessKeyId,SecretAccessKey,SessionToken]' --output text
  

  • Basic MFA Usage
    

    This can be wrapped up in a function which adds those arguments and loads the returned values into the exported environment.

    aws::load_credentials_from() {
        # Clear any existing token which could mess with request.
        unset AWS_SESSION_TOKEN
        local aws_exec_result=$($@ --query 'Credentials.[AccessKeyId,SecretAccessKey,SessionToken]' --output text) ||
            echo "Failure acquiring STS ticket!"
        read AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN <<< ${aws_exec_result}
        export AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN
    }
    

    This can then be used with any appropriate call to sts to load the environment with the results of the call such as:

    aws::load_credentials_from aws sts get-session-token ${other_args}
    

    A function which issues the call to sts directly may be simpler. The design above accomodates both of the use cases documented here but most enviornments are likely to only require one use case and corresponding sts call.

    Given an MFA serial and a profile name the above could be used to authenticate with an MFA token retrieved from a prompt with a call such as:

    read -s -p "Enter MFA code for ${AWS_MFA_SERIAL}:" token
    aws::load_credentials_from aws sts get-session-token --serial-number "${AWS_MFA_SERIAL}" --token-code "${token}" --profile="${AWS_PROFILE}"
    

    Typically the MFA serial will be configured for a profile, so assuming a standard profile the serial could be looked up from that file and a function exposed to use that MFA.

    declare AWS_CONFIG_FILE="${AWS_CONFIG_FILE:-${HOME}/.aws/config}"
    declare AWS_PROFILE='default'
    
    aws::lookup_mfa_serial() {
        AWS_MFA_SERIAL=$(awk -s "BEGIN { thisP=0; } /\[.*]/ {thisP=(\$0==\"[${AWS_PROFILE}]\")} /mfa_serial/ { if (thisP) { print \$3 } }" "${AWS_CONFIG_FILE}") 
    }
    aws_load_mfa_session_token() {
        [[ -n "${AWS_MFA_SERIAL}" ]] || aws::lookup_mfa_serial
        read -s -p "Enter MFA code for ${AWS_MFA_SERIAL}:" token
        aws::load_credentials_from aws sts get-session-token --serial-number "${AWS_MFA_SERIAL}" --token-code "${token}" --profile="${AWS_PROFILE}"
        # Echo newline for subsequent prompt.
        echo
    }
    

    Sourcing that function into the current shell provides MFA authentication into the current shell by simply calling the function `aws<sub>loadmfasessiontoken</sub>`.

  • Role Assumption
    

    The above works for simple MFA authentication with a particular profile, in more complex environments however you may need to assume different roles. Each such role can be represented as a separate profile within your AWS configuration (I prefer a `role@account` naming scheme). The configuration files need to match a particular format which I need to dig out information about but am unfortunately? in the camp of having simpler needs right now so I can't experiment. In short however a profile can be dynamically selected by parsing the config file with a function such as:

    aws::select_profile() {
      PS3='Select an AWS Profile #: '
      select AWS_PROFILE in $(awk -s '/\[profile/ {print substr($2, 0, length($2)-1)}' "${AWS_CONFIG_FILE}"); do
        echo ${AWS_CONFIG_FILE}
        AWS_ROLE_ARN=$(awk -s "BEGIN { thisP=0; } /\[profile/ {thisP=(\"$AWS_PROFILE\"==substr(\$2, 0, length(\$2)-1)) } /role_arn/ { if (thisP) print \$3 }" "${AWS_CONFIG_FILE}")
        break
      done
    }
    

    Authenticating with the selected profile can then use the previously defined `aws::load<sub>credentialsfrom</sub>` function:

    aws::assume_profile() {
      aws::load_credentials_from aws sts assume-role --profile "${1}" --role-arn "${2}" --role-session-name "${1}-session"
      echo
    }
    

    Those two functions can be stitched together using:

    aws_assume() {
      select_aws_profile
      aws_assume_profile ${AWS_PROFILE} ${AWS_ROLE_ARN}
    }
    

    The final product upon sourcing the above is that `aws<sub>assume</sub>` is available as a function which will prompt you for a role to assume and load the appropriate authenticated values for that profile into the current environment.

    Implementing auto-completion for the profiles could be a nice alternative, but as already mentioned I'm not currently using this and the `select` based option was normally sufficient.

    The full latest version of these snippets that I load into my bash shell is available at https://gitlab.com/mwhipple/mw-config/-/blob/master/bash.d/aws.sh

AWS Database Migration Service (DMS)

For Tinkering

Grievances and Resolutions

• Emacs is Too Slow/Initial Adoption
  

  My initial exposure to emacs was in the late 1990s when it would for one reason or another accidentally open on Linux machines I would use. At that time it would generally elicit a groan as I waited for it to finish loading and then either stumbled through using it or closing it and switching to vim. PCs at that point were not slow through a long lens, but slow enough that emacs (at least without some optimizations) was sluggish enough to put me off. It also felt a bit too alien which may have been aggravated by cosmetic similarities to simpler editors such as Notepad acommpanied by the significant behavioral differences; but that's just speculation about thoughts I may have had ~20 years ago.

  Several years after that I was in search of a new editor (which has been a periodic quest of mine). At that time I had started down the path of using Eclipse but was looking for something smaller and more flexible and figured that PCs had sped up enough by then that the previously perceived cost of emacs would be gone (there's obvious cost in Eclipse also but that is a more obvious price for what it is). I started actively learning emacs and was quickly drawn into the discoverable self-documentation that it provides and the REPL-y model of being able to dynamically execute code within and against the editor environment.

• Too Basic
  

  Emacs quickly became my primary go to editor and I started down the road of trying to use emacs for everything. Shortly thereafter I had jobs which involved a fair amount of Java coding and so I ended up using Eclipse and IntelliJ IDEA to match the tools familiar with the rest of the team while I got my bearing in unfamiliar terrtitory. Emacs gradually faded into the background while I used shinier alternatives for most of my work and only used emacs for simpler purposes. At this point I fell into the common trap of overreliance on my editor. At the time I somewhat attributed this to a faction of the Java culture which leaned heavily on tooling, but now I'd argue that it is an instance of a nuanced continuing tension which falls out of having more powerful tooling but it certainly does not have clear boundaries.

  Emacs is certainly capable of providing similar functionality but my attempts left me stumbling over package selection and lower level details which were all bundled up neatly in the newer IDE alternatives.

  This pattern was broken as I was preparing to change jobs and practicing for coding exercises. Much of the convenience that IDEs provide can be used to produce some parts of code far more easily, but also with less understanding. Switching back to emacs broke that spell over me and forced me to think far more intentionally about the code I was writing and the value the tool was providing for me, so I switched back to emacs.

• Avoiding the IDE Project Model
  

  An immediate practical advantage of a simpler editor is that IDEs track their own model of the projects on which you're working. This can often lead to obvious issues such as development processes being defined in terms of specific editors or even specific versions of those editors and as a result not being directly portable to any system not using that editor (including systems such as CI). A less obvious issue is that this also normally introduces a large amount of information and configuration about your project which is cached or indexed internally to the IDE. This alternative projection of your project data invites new issues when this IDE managed state falls out of step with other definitions or when drift is introduced as that internal state evolves.

  This often manifests as the IDE misbehaving until such state is flushed. Ideally the IDE will coordinate such state though a manual refresh is often a backup option; I've had to occasionally wipe out a project entirely, however. While this is normally not a major issue to correct once recognized, that recognition can waste a fair amount of time. Normally the need for such refreshing is also tied to other changes and therefore isolating the problem down to the IDE rather than those changes may not be straightforward. A variation which is particlarly likely to invite confusion is where the poor behavior of the IDE is that it continues to behave properly when the canonical project has been broken in some way.

  These pitfalls are likely to be addressed through improvements to the IDEs and through new habits/knowledge but they impose additional overhead which doesn't produce value at runtime and the reconiliation of reproducibility between two models is non-trivial.

  Most often much of the additional power of IDEs aims to allow developers to work with larger projects without getting lost amidst the project size: or from another angle they allow projects to sprawl out and then superimpose organization on to that sprawl. The alternative is to structure projects such that they can be navigated and exercised without looking for a tool which may be sweeping mess under the rug. While larger projects may benefit from some such features within or without an IDE, more intentional use of organization and standard build tooling confers a more inherent coherence to the project itself. A large swatch of software currently being developed should also be of a small enough size (potentially something like one bounded context) that if the code is not grokkable without the support of tooling it's likely just a result of sloppiness.

• Emacs is Too Big
  

  An underinformed concern that I acquired at one point was that emacs itself has grown to be too large. This was primarily based on times when it was built from source and the enormity of the repository which noticeable during cloning and as consumed by the resulting copy. This size spawned a fear that core emacs has become bloated through some combination of legacy cruft and inherting functionality which should likely not be part of the core. Generally speaking emacs offers value as a more minimalist alternative to larger IDEs and that value would be inversely proportional to the size of emacs itself.

  This concern was trivially addressed when I stopped to pay closer attention to the repository itself. While the repository itself is large, the size of the active state is a small fraction of the overall size. This is almost certainly due to the extended period under which emacs had been under active development and therefore the reasonably full record of the changes over that time would grow to be significant even if the product of those changes had much more tightly bound growth.

  While repository may be notably large, the size of the current project is well within reason and not large enough to lend ample support to fears imputed by the size of the repository as a whole.

• Elisp is Too Integral
  

  An ideological concern with Emacs is how fundamental the role of elisp plays within the system. This is particularly evidenced when looking at the source code where references to `lisp.h` are ubiquituous throughout the code base, presenting a clear picture that that file and therefore elisp is one of the foundational building blocks upon which everything is built rather than being a relatively abstracted extension mechanism.

  The most obvious concern with this is that it means that replacing elisp with another language or engine (such as Guile) would be difficult at best. This could be advantageous in that other languages may have larger communities and have better support for some areas in which elisp has come up short.

  From a design perspective this speaks to emacs being a lisp interpretter within which editor behavior is built; so while emacs is described as an extensible editor it could be viewed as more of an extension environment in which an editor exists. In limited past experience platforms with this motivation often end up far more difficult to work with. While extensible systems may offer well defined extension points into which additional behavior may be added and make use of an array of well-defined supporting constructs, systems which have an ostensible purpose but provide a generalized platform to enable that purpose can end up introducing a lot of noise. Such platforms often provide a combination of building blocks and contracts that must be satisfied but push enough responsibility on to the developer to bridge that gap that any introduced limitations and non-portable knowledge outweigh the supposed benefits. The issue likely comes down to trying to provide a unified solution for both the general purpose and the system specific aspects of any extension behavior; the general purpose behavior is likely most easily delivered using the more powerful and likely more familiar tools provided by operating systems and language ecosystems rather than operating within the confines of any specialized tools provided by a particular environment so the primary role should then shift to one of integrating that behavior with the target system which reduces the role of the target system to one of providing a well defined means of integrating that behavior, which in turn leads to the alternative perspective of focusing on an extensible system rather than providing a more general purpose platform (as with most things there is plenty of middle ground also).

  The above concerns are primarily based around the perception that elisp exists as an extension mechanism. In a far more practical light the implementation language for Emacs and elisp is C and exposing C for wide extension has several pitfalls. Safe and consistent extension of a notably sized codebase in C is likely to involve a fair amount of established conventions around code organization and memory management. After creating such additional scaffolding the extension code will interact with the system in specific ways and start to look like a more specific dialect of C, and at a certain point this may be accompanied by the realization that the introduction of such a more specialized form of code is akin to introducing a new language but with somewhat implicit idioms. Therefore layering in some form of language above C makes sense and elisp is a nice simple starting point, and is a natural fit to provide the more dynamic interpretation which allows the more exploratory coding favored by GNU projects.

  Elisp being an entry point doesn't necessarily address why there wouldn't be others. While the benefits that integral language idioms can provide over code conventions is fairly straightforward, the memory management concerns are far more subtle. The management of the lifecycle of objects across multiple languages is not straightforward and reconciling how different languages approach that issue would require significant care. On top of that presenting anything resembling a unified runtime across different language styles is likely to acquire costs hand over fist. Many of these types of concerns are evident when reading some of the Guile documentation (and the general recommendation to work towards pushing as much as possible into Guile so that the work of coordinating lifecycles across boundaries is minimized).

  On top of everything else there's also the general takeaway that this is a somewhat imagined problem. Elisp works and it's simple (and simple enough to be reimplemented elsewhere as needed). Making a practical argument against a language choice in a working system needs a fair amount of support to offset the costs of enhancing that existing language as necessary, and without that support is more likely to largely come down to personal preference. Further this also aligns with the earlier general purpose platform vs. extensible system concept where new behavior should be able to use whatever tools are desired and just be implemented outside of emacs which is simply integrated into the system at the appropriate point using elisp as glue code and otherwise following the general software tools philosophy.

• There's Too Much Legacy Cruft
  
• Standard Elisp is Too Primitive
  

  After using emacs for a while and starting to try to pay closer attention to available packages, a major gripe is that elisp feels too low level. Some of the major strengths of lisps are that they allow evolving the language used to be closer to the problem space; the fundamental property that written code is a lisp structure itself confers the relatively rare property that such alignment is easily attainable in structure in addition to verbiage. Emacs lisp, however, does not provide a notable amount of such high level constructs. This fits in with snide Emacs quips such as it being a promising OS that is only missing a good editor.

  Although Emacs is ostensibly an editor, most of the language constructs provided remain seemingly too generalized and primitive rather than supporting what would be expected to be typical editor use cases. A particular case that stands out in my mind when dealing with this several years ago was working on wiring up a hook for comint mode. I believe the specifics were that I was running a `compile` with an external process that triggered a rebuild on code changes (typical watch behavior such as done by watchman) and was configured to clear the screen upon each such refresh. The control sequence used to clear the terminal was not working as desired in comint-mode so I wanted to write a handler that would clear the screen when that sequence was sent. While the code was not overly difficult it was far more tedious than expected. The general use case seemed like a typical one: something along the lines of listen to a buffer change and react based on the modified content. The actual fix involved a fair amount of smaller building blocks which involved concerns such as actually retrieving the content out of the buffer, searching through that content, and paying appropriate attention to concerns such as the buffer continuing to mutate after the event and doing any necessary resolutions to produce the desired outcome. While this is does not qualift as particularly low level it certainly felt like a representative enough use case for an editor that several of the steps involved may have been provided by more packaged functionality.

  This is also evident in cases such as typical emacs configuration. It seems reasonable to expect that such configuration could be highly declarative given the previously described ability of lisps to easily enable what amount to domain specific languages combined with the evident domain of the editor (and the configuration thereof). In spite of this, emacs configuration (and general functionality) remains primarily imperative. While a more imperative orientation is more natural for defining the general purpose logic that delivers the underlying functionality provided in elisp packages, it often leaves concerns such as configuration a less readable assemblage of disconnected actions rather than a more descriptive definition of how those actions fit together into an interrlated final composition.

  This is ultimately fairly nit-picky and could easily be addressed through creating or adopting libraries that provide higher level constructs. In the past I started down the path of creating such a library for my configuration and I'm currently planning on working towards the same while trying to build as much as possible on community supported offerings.

• Wider Elisp is Too Disorganized
  
• Emacs does too much
  

Why GitLab

GitLab vs. GitHub

Motivation

• Alternatives
  
  • Microsoft
    

    For tool compatibility, any preferred OS would be POSIX compliant. Last time I used a Microsoft OS (~10 years ago) it didn't fit naturally into that category; I think they may be more in line currently the fear would be that it still represents too significant of an ecosystem split to warrant crossing (maybe next time I get a device).

  • Apple
    

    Apple OSes are a compelling alternative, particularly given that OS X allows for convenient development against both OS X and Linux whereas the converse case of developing for OS X on Linux is non-trivial. I often use Macs for work computers and am also likely to recommend Apple devices generally to others, however I prefer Linux due to it supporting a higher level of tinkering and a wider range of devices. As previously mentioned Linux is also far more likely to be aligned with deployment environments (Apple seems to have little penetration in the server space), and in particular the differences between OS X and Linux can often be subtle enough to not be immediately obvious but cause subsequent consternation.

  • Others
    

    There are a variety of other POSIXy operating systems available, some of which promise some conceptual advantages over Linux; Linux largely adopts models which are similar to older versions of UNIX which have proven to be remarkably robust but have been incrementally augmented in other OSes). Linux has a far larger community and knowledge base from which to draw and therefore promises more pragmatic economy.

Restoring Data Onto a Different Replica Set

• TODO Add sources
  

  In an ideal MongoDB deployment you have fully operationalized and independent environments with things like proper disaster recovery in place for each enviornment. In reality however the production environment may be the only one that's actually important and ay pre-production environments may ultimately just act as a disposable proxy for production. In any relatively small engineering team such an environment may not justify significant investment and may suffer some minor neglect as a result. In such a scenario if that more disposable environment does end up being disposed of, a recovery plan may involve loading a sanitized copy of production data into that pre-production environment.

  The MongoDB documentation provides ample information on restoring backups from data files, and messing with some of the internal databases should allow you to get all of your replica sets and any relevant configuration servers for sharding mapped out properly. This can be a hassle if you're not using some kind of management interface that eases the pain, but at the end everything should be pointing to the right place.

  BUT…those instructions are suitably focused on restoring a backup to a cluster which matches that from which the backup was taken and there can be some additional wrinkles if you're doing something like restoring a backup from one environment into another.

  A particular issue I've run into is around the target environment being on a much lower "term" than the source environment. Unfortunately `term` is a generic enough…umm…term that it's likely to not be a useful hint by itself without a fair amount of background context and so its significance in associated errors may be glossed over. I no longer have the specifics for when I encountered this error and will need to dig in a bit to collect more concrete information. At the time I ran into the issue I ended up having to poke through the MongoDB source code for the significance of the term "term" to click (which was also referenced in a relevant StackOverflow post). This could affect data nodes or also config nodes as newer versions of Mongo use replica sets on both.

  The "term" here is a reference to an election term which is part of with the Raft-based consensus that MongoDB replica sets use to coordinate understanding of which node is the primary/master node that should be accepting and replicating writes to the data: thereby being responsible for consistency and durability. The term number is used to make sure that all of the nodes in the replica set are up to date as operations are replicated to them, and so if a term number in the oplog (such as retrieved from a backup) is higher than that of the cluster then the cluster ends up in a state where it considers itself out of date and therefore unable to safely handle writes. There are likely more rigourous and correct explanations of this around.

  Messing with this number is not something which is readily exposed, and while there is likely a better way to handle this issue a quick solution is to just force the cluster ahead as many terms as are needed. Note in particular that this solution may be suitable for a relatively disposable cluster but elections impose a short period of unavailability and therefore triggering a flurry of elections will cause a proportional amount of downtime which would be unacceptable for any service that should have relatively high availability.

  An election can be instigated by having the primary stepDown, and therefore terms can be incremented by repeatedly issuing a stepDown. As this is a relatively hacky solution in any case the simplest solution would be to issue a stepDown request to all of the nodes on the cluster in a loop until the required term is reached. Such a solution could be done in bash with something along the lines of:

  while true; do for h in ${mongo_hosts}; do mongo –host ${h} ${mongo_authoptions} –eval rs.stepDown() done sleep 10 done

  That command may certainly need some tuning as I'm not able to easily verify anything about it, and it also may need adjustment based on how connections to Mongo can be established. Harmless errors/noise will be returned for the secondaries. The outer loop could also be modified to break at the desired term number but that's out of scope for this quickly thrown together memory; similarly retrieval of the active term may need an additional line in there. Some variation of the above with some trivial monitoring should do the trick, and a key safety factor is that so long as the cluster has a term at least as high as the terms in the operations things should work so if the term is advanced too far it shouldn't cause issues.

Issue Running Tests for AWS Provider

• Preparing an Escape Hatch
  

  The first step in attempting to work through this issue was to make sure an escape hatch was available: leaving a terminal window running with `top` allowed for getting in to kill the process even after the system becomes painfully slow (since a sigterm can be sent with a manageably low number of key presses).

This Site

• Publishing
  

  This was relatively straightforward by borrowing from the provided example⁹, modified a bit to match my tastes.

  • Use of Project .el File
    

    My initial hope was to adopt a simpler approach than the example configuration as the first iteration. This site started as a single org file to export to HTML, so the hope would be that that could be done through invoking an existing function through emacs batch mode¹⁰. This didn't pan out however: basic export functionality seems focused on buffer contents and the combination of loading the file into the buffer and exporting it seemed to stretch the limits of what should be done in the shell rather than in an elisp file. More appropriate functions exist as part of the more powerful publishing functionality, though that functionality involves a combination of defining projects and tracking some of their related state. This therefore once again tips the scales back toward using a separate elisp file (and is the approach used in the example project). I had also hoped to use directory local variables to help with project definition, but as those files seem to be oriented towards mode specific editor configurations rather than more general or structural configuration it didn't seem to offer an idiomatic (even if feasible) possibility. Ultimately the solution therefore uses an elisp file within the source directory of the site which defines the project and provides functions to help with publishing.

    A big part of the original motivation was that additional logic should not be required solely for the sake of the publishing pipeline, and that remains a goal. More elaborate configuration is expected as the project evolves and therefore project specific elisp was to be expected. The logic in this file should therefore remain the authority on the project configuration regardless of whether it is accessed through a batch build process or a more typical emacs (etc.) session. Ideally that file can remain entirely unaware of the batch invocation, and the publishing pipeline therefore involves nothing more than calling an appropriate standard function.

  • Integration with Make
    

    With the very simple initial alternative of easily calling a readily available emacs function off the table, pursuit of abject triviality is abandoned. As in virtually every other project I work on I therefore introduce `make` to capture the resulting recipe. On a basic level this is a trivial indirection where the emacs batch command is captured in make rather than in the GitLab CI configuration file, there are however two further adjustments.

    The first of these tweaks is bridging the now more segmented build configuration. If the build is managed entirely within emacs then emacs has access to all of the relevant parameters: however if make is performing more general build definition then it should also provide parameters such as where artifacts should be built. The resulting call to emacs is therefore enhanced to issue a call which passes relevant arguments through to be used in the ultimate project configuration.

    Another slightly more interesting issue is that make introduces a new dependency which therefore must be present in the container within which GitLab calls emacs. For the smallest code footprint the desire would be to use an already published image which contains both (an up-to-date) emacs and make. After a bit of local experimentation the `dev` tagged `silex/emacs` images fit the bill. That particular image seems to be of a fairly large size but considering how it is being used that's not expected to be of practical consequence. Normally I'd also be likely to wire up a make target which recreates the containerized behavior (a host target which calls `docker run` to invoke another container target) but at the moment this doesn't feel interesting enough to warrant the effort given the relative ubquitious availability of make and emacs.

Family Media Site

• UI
  
  • Standard Functionality
    

    My main thought around Web development (which will be covered elsewhere later) is that the base level functionality provided by modern browsers is more than sufficient for most uses, as long as the developer is able to design systems decently well. In most healthy ecosystems weight usually builds on one side of a boundary which allows a commensurate reduction in weight on the other side: either a foundational system grows richer and the solutions built on top of that foundation grow smaller or an underlying kernel grows smaller and more focused and more specialized work is offloaded to those solutions which are built on top of it. Currently Web development seems to be growing on both sides at once where the languages and runtimes continue to grow more powerful but the systems built tend to remain at increasingly levels of abstraction above that foundation. While this is likely beneficial for some of the more immersive uses of the Web it feels very heavy handed for basic sites and SPAs. My intent would therefore be to just use functionality readily available in a browser: however that does require the aforemented design and dot connection in a space which I honestly don't have much interest in, which is a largely a reason the UI was left alone for a while.

  • React
    

    The UI is ultimately going to be built using React. The main reason for this is that it is widely popular and I'm currently using it at work. More thoughts around React will likely be captured separately. The starting point will be the typescript template provided by Create React App¹², and the UI will be developed using functional components and hooks with minimal additional dependencies.