This documentation assumes you've booted in to the arch ISO using a USB drive or some other method. Connect to Wi-Fi (if needed) # Verify no internet access ping -c 2 google.com # Connect to wifi using iwctl iwctl device list station wlan0 scan

Current perceived strategy for growth Every hour worked must be billable unless absolutely necessaryMore billable hours means more revenue Unbillable hours means less revenue This is how APAX defines "efficiency" Increase APAX margins by hiring cheaper, less-experienced engineers Our only way to grow this approach is do more of it More projects

Project Setup NextJS / turbo repo 8 hrs Layout / tailwind foundation 12 hrs CircleCI deploying to Vercel 6 hrs Postgres locally w/ lando 2 hrs Postgres in the cloud 4 hrsVercel DB? Planetscale? AWS? Data Layer Foundation

Easily protect your AWS CDK-defined infrastructure with AWS WAFv2 AWS WAF resource type reference WAF with CDK examples

Completed Discovery The site currently uses an unmaintained module called Panelizer for managing layouts. They are upfront in their documentation that it simply exists as a migration path to the new core drupal module called Layout Builder. It states that the migration is in alpha and could result in loss of data. With this in mind, it's recommended to take the result of the discovery phase and start with a fresh Drupal 10 install and write data migrations to the new site. This allows to have a clean slate in terms of data structure and technology choices with regard to the site layout. Scope Planning / Design Phase Iterating on restructuring of drupal constructs (Content Types, Paragraphs, Taxonomies, etc)

This compares profiling of the same code base running Drupal 9.4.9 and 9.5.0. Profiling was done locally using xhprof. All Drupal caches were cleared when switching drupal core versions. The totals are averages from 3 runs of each test case. The call stack is ordered by descending wall time and taken from just one run that I thought described the average order. The biggest thing that stands out to me is the time spent running Container::getServiceIdMappings and Container::generateServiceIdHash. Also, the number of calls to DefaultPluginManager::cacheSet went up on the cold start. Cold Start - Home Page Drupal 9.4.9

Dump DB # Eliminate compression and use all cores (8 in this example) pg_dump -h 127.0.0.1 -U postgres -Z0 -j 8 -Fd amlegal -f dumpdir # Compress directory in parallel using pigz tar -cf - dumpdir | pigz > dumpdir.tar.gz Restore DB pigz -dc dumpdir.tar.gz | tar -C dumpdir --strip-components 1 -xf -