Moving some scripts around and writing some new ones.

Author: deltaepsilon

README.md

@@ -1,5 +1,12 @@
 {
   "dependencies": {
-    "gitbook-plugin-ga": "^2.0.0"
+    "gitbook-cli": "^2.3.2"
+  },
+  "scripts": {
+    "start": "gitbook serve",
+    "install": "gitbook install",
+    "build": "gitbook build",
+    "build:debug": "gitbook build ./ --log=debug --debug",
+    "versions": "gitbook ls-remote"
   }
 }

package.json

@@ -0,0 +1,119 @@
+Hello YouTube!
+
+It's Chris Esplin again, haunting your suggested videos feed!
+
+This will be a short update on what I've been doing for the last year.
+
+In the Summer of 2017 I was approached by some great folks from Udemy.com.
+
+They were interested in publishing a Firebase course to their platform...
+
+...and thought that I might be interested in collaborating on a course with Juarez Filho.
+
+Juarez and I have been in the Google Developer Expert program for a few years...
+
+...and we both specialize in Firebase for web.
+
+We use the Firebase platform every day and know the space pretty well.
+
+So I said "yes", understanding that I was in for a lot of work.
+
+I use time-tracking software every day...
+
+...so I can confidently say that I've spent over 450 hours on this project over the last year.
+
+I had no idea what I was getting into.
+
+The problem is that I couldn't stomach the thought of knocking the course out quickly.
+
+I've been unhappy with my video production skills for a while now, and I wanted to solve that.
+
+So I bought a bunch of video equipment and software and started teaching myself.
+
+I worked on the project for three hours every morning before work and on Saturdays...
+
+...except for vacations and breaks for a bit of freelance work.
+
+Anyway, the reason we're here is because I've got over 40 videos and I'm anxious to ship them!
+
+We're talking about a full-blown, two-and-a-half hours video course on `udemy dot com`.
+
+I'm a web developer, so this is Firebase for web, not Android or iOS.
+
+That's not to say that the fundamentals won't apply if you're a native developer...
+
+...but I built the demo project in React and used the JavaScript SDK for everything.
+
+You can start learning with the free companion site, `full stack firebase dot com`.
+
+I've used `full stack firebase dot com` as a place to outline the material...
+
+...because you've got to write it all down before you can start shooting videos.
+
+So start at `full stack firebase dot com` and you'll find links to purchase the course on Udemy.
+
+You'll find a bunch of introductory modules about high-level Firebase concepts.
+
+We've covered serverless concepts and how to think about the Firebase ecosystem.
+
+And of course you'll find modules on each of the big Firebase platform features.
+
+These modules include the Firebase command-line interface, Authentication, Firestore...
+
+...the Realtime Database, Cloud Functions for Firebase, Firebase Storage...
+
+...Firebase Cloud Messaging, and Firebase Hosting.
+
+Each module starts with an introduction and a walkthrough to demonstrate the feature in action.
+
+Next we implement the feature in our demo app.
+
+The original plan was for Juarez to write a demo app in Angular and I'd do one in React.
+
+Juarez is behind schedule, so the Angular demos aren't ready;
+
+however, my React demo app is live at `react dot fullstackfirebase dot com`...
+
+...and you'll be able to deploy your own version of it when you take the Udemy course.
+
+Don't get hung up on the fact that it's in React, because you won't need to code any React.
+
+The Firebase SDK is all vanilla JavaScript, so my integrations are vanilla JS as well.
+
+I would have done the entire app in vanilla JavaScript...
+
+...but that would have added a few hundred more hours to the development process.
+
+So let's wrap this up.
+
+I am not giving up on YouTube. 
+
+I've just been wholly consumed by learning video production and making a Firebase course.
+
+`full stack firebase dot com` is still a work in progress, but it's free for everyone.
+
+The Udemy course isn't free, but it isn't expensive either.
+
+I'm confident that you won't find a more comprehensive course on Firebase for web.
+
+And now that I've spent a few hundred hours learning to produce videos and screencasts...
+
+...I'm anxious to dive back into YouTube.
+
+So smash that like button.
+
+Hit it three times if you can. 
+
+Just make sure that it's an odd number of times so that YouTube registers the "like" correctly.
+
+I'll hang out in the comments to respond to questions...
+
+...and as always, make sure to subscribe for the latest Firebase tips and tricks!
+
+
+
+
+
+
+
+

scripts/01.01 - full-stack-firebase.txt renamed to scripts/FullStackFirebase/01.01 - full-stack-firebase.txt

@@ -0,0 +1,121 @@
+Hello YouTube!
+
+If you've been keeping up on Firebase in the last year then you're likely using Firestore.
+
+Firestore is a bit of a successor to the original Firebase Realtime Database.
+
+After Google purchased Firebase in October of 2014...
+
+...Firebase had to move over to Google infrastructure.
+
+That's a ton of work, but once you're on Google infrastructure, you're on Google infrastructure!
+
+So you might as well design a new database from scratch that crushes everything that came before.
+
+And there's how we got Firestore.
+
+I've talked about Firestore in the past...
+
+...so review those videos or check out `full stack firebase dot com` for the Firestore introduction.
+
+I'd like to talk at a high level about Firestore sub-collections.
+
+First, we need to review the Firestore data model.
+
+Firestore is a document/collection database.
+
+Documents hold whatever JSON data you'd like, but they must live within a collection.
+
+A document can have any number of sub-collections with their own documents.
+
+And you can keep nesting your data within sub-collections to your heart's content.
+
+But that would be a horrible mistake.
+
+In fact, I haven't found a great use case for sub-collections yet.
+
+First off, you can easily save embedded JSON objects within your documents...
+
+...so it's not necessary to make a sub-collection to nest data within a document.
+
+And second, sub-collections are easily orphaned.
+
+What do I mean by orphaned???
+
+I mean that if you delete a document's data without deleting it's sub-collections...
+
+...you can no longer query the document...
+
+...so you might lose your reference to it, and lose track of its sub-collections.
+
+This deserves some extra explanation.
+
+If I have a collection called `foods`, I can query all of the documents in my `foods` collection.
+
+Imagine that I have a `food` document named `gelato`.
+
+My `gelato` document has attributes for `color`, `calories` and `deliciousnessRating`.
+
+I want to track the ingredients in my gelato, so I create an `ingredients` sub-collection.
+
+When I query my `foods` I get an object back named `gelato`...
+
+...with `color`, `calories` and `deliciousnessRating` attributes.
+
+But I don't get the `ingredients` sub-collection. 
+
+I only get the `ingredients` sub-collection if I make a separate query for it.
+
+And I have to just know that it's there.
+
+There's no hint that my `gelato` document has sub-collections.
+
+So I can lose track of my `ingredients` sub-collection by forgetting that it exists.
+
+Now imagine that I delete my gelato document for some reason.
+
+My `gelato` document is gone, but I've forgotten to delete my `ingredients` sub-collection.
+
+Because, get this... I have to manually delete a document's sub-collections.
+
+And to add insult to injury...
+
+...since I deleted the `gelato` document, it no longer shows up in my `foods` queries.
+
+So now I don't know that `gelato` ever existed, but the `ingredients` sub-collection is still there.
+
+You can see these orphaned sub-collections by clicking through the Firestore web console.
+
+But you have to click through every single document to find them...
+
+...because orphaned sub-collections don't show up when you query their parents.
+
+This is garbage.
+
+I'm confident that the Firebase team knows of this problem and has some plan to address it...
+
+...because Firestore is still in beta of course...
+
+...and I'm thankful to have Firestore even with it's wacky sub-collection system.
+
+Just don't get suckered by sub-collections.
+
+They have their uses for sure.
+
+I've used them to cascade security rules and it's been great...
+
+...but sub-collections are still iffy as a cornerstone of your data model.
+
+The good news is that you don't need sub-collections to build your app on Firestore.
+
+And they'll likely get more useful in time, so I'm hopeful.
+
+Let me know what you think about Firestore in the comments.
+
+I'll hang out and answer questions as always...
+
+...and don't forget to smash those "like" and "subscribe" buttons.
+
+If you're already subscribed, maybe unsubscribe and subscribe again...
+
+...just for the satisfaction of clicking that fantastic "subscribe" button one more time.

scripts/01.02 - why-firebase.txt renamed to scripts/FullStackFirebase/01.02 - why-firebase.txt

@@ -0,0 +1,122 @@
+I pay close attention to the Firebase ecosystem...
+
+...so my Google News feed often has Firebase- and Google-related articles in it.
+
+A few weeks ago I saw an article pass through my feed about Firebase apps leaking data.
+
+It was coverage of some security research by a company named Appthority.
+
+Appthority did an audit of thousands of Android and iOS apps and found some serious problems.
+
+These apps had all implemented Firebase, but failed to implement Firebase security rules.
+
+So these apps' Firebase databases are basically public for everyone to read.
+
+I thought, "wow, that's really horrible... I sure hope they get that fixed!"...
+
+...and I forgot about it.
+
+But in the last few days the coverage has gotten heavier...
+
+...and it's entered into clickbait territory.
+
+When the clickbait farms start to recycle content, the coverage goes from "ok" to "horrible".
+
+The details of the story suffer, because the clickbait farms are churning out articles...
+
+...without even a cursory understanding of what they're writing about.
+
+So I'd like to clear this situation up a bit.
+
+Just be to one-hundred percent up front, I am not speaking for anyone but myself.
+
+These are my opinions that I'm talking about because the clickbait is misleading.
+
+So what is actually happening with these data leaks?
+
+It's simple.
+
+Bad developers are lazy and believe in security-through-obscurity.
+
+Firebase has given them all of the tools that they need, but they haven't used them.
+
+And as a result, apps by lazy, incompetent developers are leaking data all over the web.
+
+This happens because Firebase is a back-end as a service.
+
+This necessitates that the Firebase database is publicly accessible.
+
+Anyone can make requests to your Firebase database, both the Realtime Database and Firestore.
+
+So Firebase has Security Rules that you write to lock down your databases.
+
+These rules are, admittedly, the weakest part of the Firebase platform.
+
+I am not implying that the security itself is weak, because it's bulletproof.
+
+But Security Rules are difficult for developers to understand...
+
+...because they solve a complex set of problems.
+
+I've noticed that Firebase's default security rules have become more strict over the years.
+
+You now have to manually override them to make your database public.
+
+You're supposed to replace the default rule with your app-specific rules to lock your data.
+
+It's a little like changing the admin password on your new router.
+
+People don't think anything will ever happen to them...
+
+...so the vast majority of routers still use their publicly-discoverable default passwords.
+
+Likewise, bad developers don't think anything will ever happen to them...
+
+...so they override Firebase's Security Rules and make their apps publicly accessible.
+
+A publicly-accessibly app is easier to develop on...
+
+...because you never run afoul of your own Security Rules.
+
+And that's fine if you're writing a little demo app or an internal prototype with dummy data.
+
+But it's become clear that there are a ton of bad developers out there...
+
+...and these devs shipped their apps without ever locking them back up.
+
+If you're interested in stealing, there are a ton of insecure apps out there.
+
+And some of them are poorly configured Firebase apps.
+
+If you've been a bad developer, please write some security rules.
+
+I'm happy to help you sort them out.
+
+In fact, I've written some tutorials over on `full stack firebase dot com` that will prove useful.
+
+And for everyone else...
+
+...thank you for taking basic security measures and locking down your Firebase apps.
+
+Data security is no joke.
+
+We have to take our responsibility as developers very seriously.
+
+I don't want to work in a highly-regulated industry...
+
+...and bad data security, even if it's inadvertent, will drag us all down.
+
+And if you somehow conned me into installing an insecure app on my phone...
+
+...shame.
+
+Shame.
+
+Shame.
+
+Shame.
+
+
+
+
+