wheeeeee

.gitignore

@@ -1,3 +1,4 @@
 **/*.sw*
+**/mnt.d
 **/*.wav
 **/*.mp3

larynx.d/batch_play_wav.sh

@@ -0,0 +1,6 @@
+#! /bin/bash
+
+for f in ./script.d/*.wav; do
+   read -p "enter to play <$f>"
+   afplay "$f"
+done

larynx.d/batch_txt_to_wav.sh

@@ -0,0 +1,10 @@
+#! /bin/bash
+
+for f in ./script.d/*.txt; do
+   echo $f...
+   curl \
+      -sS \
+      -X GET \
+      "http://localhost:15002/api/tts?voice=${1:-"en-us/glados-glow_tts"}&text=$(urlencode $(cat $f))" \
+   > ${f%.*}.wav
+done

larynx.d/run.sh

@@ -0,0 +1,26 @@
+#! /bin/bash
+
+cleanup() {
+   kill -9 $(jobs -p) &> /dev/null
+   docker rm -f larynx
+}
+trap cleanup EXIT
+
+d="$(dirname "$(realpath "$BASH_SOURCE")")"
+
+docker run \
+   --rm -d \
+   --name larynx \
+   -e HOME=/mnt \
+   -v "$d/mnt.d:/mnt" \
+   -w "/mnt" \
+   --user "$(id -u):$(id -g)" \
+   -p 15002:5002 \
+   rhasspy/larynx:latest
+
+docker logs -f larynx &
+until curl -m 2 localhost:15002 &> /dev/null; do
+   sleep 1
+done
+open http://localhost:15002
+wait

larynx.d/script.d/01.txt

@@ -0,0 +1 @@
+Welcome, to the 2023, Q 1, D P hack uh thon project, for, rough edges.

larynx.d/script.d/02.txt

@@ -0,0 +1,5 @@
+Today, we are going to talk about, Fieldset, Indexes.
+
+Or rather, we are going to talk about, Dayta Platform, Connections!
+
+You can think of, "Dayta Platform Connections," as a sort of, index, to, fieldsets.

larynx.d/script.d/03.txt

@@ -0,0 +1,3 @@
+First, let us tell the story of, Fieldset Indexes.
+
+Once upon a time, the Platform is powered by assets, such as brands, fieldsets, and sources, and their mapping.

larynx.d/script.d/04.txt

@@ -0,0 +1 @@
+Each of these, relate, to one another. They are very, relational.

larynx.d/script.d/05.txt

@@ -0,0 +1,3 @@
+Except, they, aren't.
+
+Each, remembers, its own relationships.

larynx.d/script.d/06.txt

@@ -0,0 +1 @@
+Except when one forgets, or doesn't hear about changes, or nobody told it to begin with.

larynx.d/script.d/07.txt

@@ -0,0 +1 @@
+As professional engineers, naturally we defend against such events.

larynx.d/script.d/08.txt

@@ -0,0 +1,5 @@
+Today, these events cause us, our customers, and one another, recurring pain.
+
+Partial updates require intervention.
+
+Compiling a group of related entities, requires many operations.

larynx.d/script.d/09.txt

@@ -0,0 +1,7 @@
+What dew these assets look like together?
+
+How could they look in practice?
+
+Relational tables? Transactionally updated? Engineered ah tom ih city?
+
+Or, we could make them look like, themselves.

larynx.d/script.d/10.txt

@@ -0,0 +1,5 @@
+Graph, Daytabayses, let dayta be dayta.
+
+Define how dayta looks, and how it looks to each other.
+
+Such a natural representation lets, us, optimize.

larynx.d/script.d/11.txt

@@ -0,0 +1,5 @@
+One graph daytabayse is, Neo-four-jay.
+
+While not the most powerful, Neo-four-jay is a friendly introduction to the graph daytabayse world.
+
+and friendly, makes for running, hack-uh-thon projects.

larynx.d/script.d/12.txt

@@ -0,0 +1,5 @@
+Neo-four-jay has two primary operators.
+
+The first, Create, transactionally writes assets and relates them.
+
+Relations can be named and directional.

larynx.d/script.d/13.txt

@@ -0,0 +1 @@
+The second, Match, searches for assets, relationships, and cascades. Match even supports reverse lookup.

larynx.d/script.d/14.txt

@@ -0,0 +1,7 @@
+Neo-four-jay is suited to hack-uh-thons, and hack-uh-thons ahrr suited to scoping.
+
+We present, a prototype. Translating fieldset indexes, to dayta platform connections, in a graph daytabayse.
+
+We explore the power, of representing dayta natively, and protecting its accuracy.o
+
+We dew not, prove Neo-four-jay is the best graph daytabayse, nor show its viability for Qualtrics production werk, nor solve functional challenges, like global replication.

larynx.d/script.d/15.txt

@@ -0,0 +1,8 @@
+We, did, find, that neo-four-jay can serve Fieldset, Index reed operations, as fast as the current solution.
+
+
+This test was against a pre set list of assets. Any cash optimized daytabayse would greatly benefit.
+
+We show, the average response time, over 300 requests, of each endpoint.
+
+Notice, this compares co locating Neo-four-jay and Fieldset Definition service, to GOBS, with a network hop.

larynx.d/script.d/16.txt

@@ -0,0 +1,5 @@
+We adjust our measures to account for the network.
+
+With this after thought fairness, GOBS retains its leed.
+
+So, no, Neo-four-jay does not match GOBS for index reads.

larynx.d/script.d/17.txt

@@ -0,0 +1 @@
+At least, not, single, index reads.

larynx.d/script.d/18.txt

@@ -0,0 +1,10 @@
+Single, index reads, are a product of Fieldset Indexes today.
+
+Neither Dayta Platform reads, nor writes, look at single relations.
+
+At worst, Fieldset Definition Service will make, 19, index requests, with a range of potential problems, in a single operation.
+
+Even pear-alell-ized, this amounts to about 90 milliseconds per operation with GOBS.
+
+
+Compare to Neo-four-jay, and its native transactions, which can do the same in, 13, milliseconds.

larynx.d/script.d/19.txt

@@ -0,0 +1,5 @@
+Not only can a Graph Daytabayse pow ur better access patterns, but it can also pow ur, happier engineers.
+
+Compare a support engineer, checking indexes for a Fieldset and its Survey,  between today, and with a graph daytabayse.
+
+This technically won't happen. No one checks for broken indexes, when they, can't, break.

larynx.d/script.d/20.txt

@@ -0,0 +1,3 @@
+No-free-lunch is inescapable. What would it take, to move Fieldset Indexes, to Dayta Platform Connections?
+
+Some amount of hardware, certainly, perhaps a lot. We also need to determine how to oud hardware.

larynx.d/script.d/21.txt

@@ -0,0 +1,3 @@
+If we do, choose, to go forward, then the plan is as follows.
+
+First, we'll present our project to the platform. Assuming that goes well, we'll secure liquid funds. Those go into an offshore, untracked, account under a fake name.

larynx.d/script.d/22.txt

@@ -0,0 +1,7 @@
+Sorry, wrong crowd. What I meant to say, was...
+
+We'll first solve global replication, whether we build or destroy it.
+
+With whatever chosen graph daytabase technology, perhaps AY W Ess's, we'll migrate single index operations to it.
+
+Finally, we can migrate the platform to transactional Fieldset Definition Service endpoints.

larynx.d/script.d/23.txt

@@ -0,0 +1 @@
+With that, Dayta Platform Connections will be laive, ready to serve all Fieldset Indexing needs.

larynx.d/script.d/24.txt

@@ -0,0 +1 @@
+Thank you for your time and attention. We hope you have also learned a thing or two about graph daytabayses.