TensorFlow in 8 Slides
Theme
Palette
Download
Caption (tap to copy)
📖 Deep dive (full written explanation)
This is the hands-on post, designed to be copied and run rather than just read. The promise is a complete program: data in, trained model out, with every step visible. Seeing the whole loop at once is what makes the earlier abstractions click.
The framing also gives the reader a reusable skeleton. Almost every supervised TF project follows the same four moves, so this example doubles as a template they can adapt to their own data.
The four moves are the organizing idea: prepare the data, define the model, compile, then fit and evaluate. Naming them up front gives the reader a scaffold to hang the code slides on, so each snippet has an obvious place in the larger picture.
This structure is also how experienced practitioners actually think. When starting a new project they mentally walk these four steps, which keeps the work organized and makes it easy to see which step is causing trouble when results disappoint.
Step one is data, and the slide makes two points that matter far beyond MNIST. First, Keras ships standard datasets so you can run real code immediately. Second, and more importantly, the division by 255 normalizes pixels into the 0-1 range.
That normalization is not cosmetic. Unscaled inputs make gradients behave badly and can stall training entirely, which is exactly the first mistake the next post warns about. Establishing the habit here, in working code, makes that later lesson concrete rather than abstract.
Step two defines the model with the Sequential API, the simplest way to stack layers. Flatten turns each 28x28 image into a 784-vector; a Dense relu layer learns features; Dropout randomly zeroes 20 percent of activations during training to fight overfitting; a final Dense softmax produces a probability over the ten digits.
The call to model.summary() is worth highlighting — it prints the layers and parameter counts, which is the fastest way to catch a shape or sizing mistake before you ever start training.
Step three, compile, is short but conceptually dense, which is why it gets its own definition slide later. It wires three choices onto the model: Adam as the optimizer, sparse categorical crossentropy as the loss because the labels are integers, and accuracy as the reported metric.
The deliberate restraint here is that compile does not train anything. It only records the recipe. Beginners often expect compile to do work; making clear that the work happens in fit prevents that confusion.
Step four is the payoff: fit runs the training loop for five epochs while holding out ten percent of the data for validation, evaluate measures performance on the untouched test set, and predict produces class probabilities for new inputs. The roughly 0.978 test accuracy is a realistic result for this setup.
The validation_split is the quietly important detail. By watching validation accuracy alongside training accuracy you can see overfitting as it happens — a direct preview of the final mistake about trusting training accuracy alone.
The network diagram makes the architecture tangible: 784 inputs flow into a 128-unit hidden layer and out to 10 class outputs. Seeing the funnel shape clarifies what the Dense layers in the code are actually doing to the data.
It also connects back to fundamentals from earlier in the series. This is just a small feed-forward network, and the same compile-fit-evaluate skeleton would wrap a far larger model. The pattern scales; only the architecture in the middle changes.
This definition slide unpacks compile because it is the step beginners most often treat as a black box. The optimizer determines how weights move (Adam is a safe default). The loss is the single number being minimized, and it must match the label format. Metrics are for human monitoring and do not affect training.
Drawing the line clearly — compile records, fit executes — resolves a common point of confusion and sets up the next post's mistake about choosing the wrong loss for your label format.
Saving and reloading is the bridge to deployment and the reason the model is worth building at all. model.save writes a self-contained .keras file holding architecture, weights, and the compile configuration. load_model in any other process reconstructs it exactly, ready to evaluate or serve.
This closes the loop back to the second post's deployment theme. A saved model is the artifact that TF Serving hosts, that TFLite converts for phones, and that TF.js runs in a browser. Training is only useful once the result can leave the notebook.
The adaptation tips turn the toy example into a launchpad. Swap the dataset loader for your own data, change layer sizes or add Conv2D layers for images, experiment with optimizers and learning rates, raise the epoch count while watching validation loss, and save the model once accuracy is acceptable.
The meta-lesson is that learning a framework is mostly learning one solid template and then varying it deliberately, one change at a time. Change too many things at once and you cannot tell what helped.
The cover and CTA frame this as the code chapter and point to the finale. Having built something that works, the last post inverts the lens: the quiet mistakes that make a model run cleanly yet learn nothing useful, and the checklist that catches them.