Strip the readme down for later.

README.md

@@ -1,64 +1,14 @@
 # Go Web Starter Kit
 
-This is a learning projects for me to learn Go.  It's a simple website that serves past stream
+More instructions coming. This is a fairly complete web development starter kit in Go. It tries to
-information, a place to post links during stream, and the games I've made while live streaming.
+be as simple as possible without leaving out modern features like reactive UIs and database
+migrations.  A primary thing that's included is working authentication, since that's the main thing
+holding people back when they first start, and also the easiest to get wrong.
 
-## Getting godoc To Work
+In fact, if you look at how I do it in this first version it is _WRONG_ so do not use this in
+production yet until I can make it correct.  Just use it to learn for now.
 
-There's a built-in command `go doc` but there's also a more advanced tool by Google called `godoc`.
+## Getting Started
-I know, amazing naming. Anyway, to get it you do this:
 
-```shell
-go get --tool go.googlesource.com/tools/godoc@latest
-```
 
-You can then run it and start indexing everything you've installed and _also_ yourprojects packages,
+....
-plus get a nice web browser based search page to view the docs:
-
-```shell
-go tool godoc -http=localhost:6060 -index
-```
-
-> ___NOTE:___ Google doesn't know how the internet works so you have to use `localhost:PORT` and not `127.0.0.1:PORT` when you run this.
-
-After that it'll take some time to index everything but you can already start browsing the APIs you need, and your project's stuff is in the _Third Party_ section.
-
-## Dealing With Module Bullshit
-
-The way to think about Go's modules is that they don't have modules, they have "projects."  Every
-directory's .go files export all of their functions without any namespacing based on the file's
-name. So if you put `FooBar` into `tools.go` and `Dipshit` in `fuckyou.go` then your namespace for
-_all_ files has raw dogged `FooBar` and `Dipshit` without any reference to `tools` or `fuckyou`.
-
-That's because your root directory is a whole __project__, not a module.  To then create a namespace
-you have to make a directory, place the files in that directory, and add `package mymod` at the top
-of those files.  You then have to import this as if it's an __entire fucking project__ everywhere
-you want to use it:
-
-```go
-import 'mywholewebsite.com/rootproject/subproject'
-```
-
-In this case you have a directory `subproject` and in there are a bunch of .go files with `package subproject` at the top to indicate they are in that subproject.  Thinking about Go's modules as separate projects helps to sort out this `import` statement.
-
-1. mkdir tools
-2. Create files in tools/ with `package tools`
-3. `import "zedshaw.games/webapp/tools"` to get the subdirectory
-
-## Why Did Go Do This?
-
-That's because it comes from Google, and Google is famous for two things:
-
-1. Using a monorepo.
-2. Assuming everyone else uses a monorepo.
-
-Don't believe me? Go look at the official first document [covering modules](https://go.dev/doc/tutorial/create-module) and you'll see they create two _totally separate projects at the root which then link to each other_.  That's not how anyone else thinks when they make a single project to work on, but if you're suffering in monorepo hell you'll do it this way.
-
-I'll also posit that Google has some weird incentive that measures numbers of projects in the
-monorepo as some kind of metric for employee productivity, so everyone working there is motivated
-to get as many little projects into the monorepo as possible, thus a great way to get them to adopt
-Go is to make Go support pulling tons of random projects from the root of a monorepo.
-
-So that's why you have to put your whole entire domain name into the import, and why you have all
-the functions just raw dogged into your face when you make multiple files, and why subdirectories
-are treated like whole little projects.