There is a point at which a useful blog needs a better front door than its most recent post.
An article can explain an idea, take a position, and work through an example. A few weeks later, however, the reader who wants to use that idea may need something different: a current reference, the right download, a guide to contributing, or a clear place to begin. Those resources should not require remembering which Tuesday an article appeared.
I have been adding that kind of structure to EduDataSci. The new pages bring together a Microsoft Fabric architecture reference, practical projects and downloads, and a set of GitHub guides that start with the questions people actually ask. They are intended to make the site more useful after the reading is finished.
There is also a new Sunday contributor. His priorities are companionship, duck sticks, and exposing what he considers a deeply neglected squirrel problem. Blaise has acquired a section of his own, and he is taking the responsibility seriously.
A reference home for Fabric architecture
The new Fabric Architectural Patterns and Best Practices page brings the architectural arguments developed across the site into one dated reference. Rather than another tour of product names, it starts with decisions: how data arrives, who owns it, what consumers may rely on, how it is secured, and what keeps it operating reliably.
The page covers landing zones, Landing Lakehouses, ingest–transform–surface boundaries, managed ingestion, Materialized Lake Views, semantic serving, Business Events, capacity operations, delivery practices, and agent-ready meaning. It includes diagrams, examples drawn from financial services, and links both to the underlying EduDataSci articles and to current Microsoft documentation.
The practical distinction is between knowing that a capability exists and knowing when to use it. A team may already know what a shortcut does. The architectural question is whether it should reference a producer’s approved product, an uncurated source landing, or a stable test surface—and whose identity should govern that access.
Similarly, the choice between Lakehouse and Warehouse should not become a contest over which icon looks more modern. The useful question is which team owns the publication contract and which engine supports that team’s responsibilities. The reference makes recommendations while explaining the conditions under which another choice is more sensible.
This edition is reviewed against information available on October 19, 2026. Its date matters. The page distinguishes a generally available core capability from a preview extension and links readers to the documentation that should be checked before implementation. It is a reference with an explicit review point, not a claim that a static page can replace current product documentation.
Pages for the next visit, not just today’s reading
A dated article and a reference page do different work. The article preserves the argument made at a particular moment. The reference provides a place to bring related decisions together and make the current recommendation easier to find.
That is why the architecture material is a page rather than another entry pushed down the chronological feed. A reader planning a new lending product can return to the same starting point. A colleague can send the reference to a project team without assembling half a dozen links. Someone revisiting an older article can follow through to a broader view of the patterns.
The same distinction applies to the site’s existing What Is a Data Product? reference. A concept that appears throughout the writing deserves a direct route of its own. The goal is not to turn every article into a manual. It is to give recurring ideas a useful home alongside the articles that explore them.
A clearer starting point for GitHub
The new GitHub: Download and Contribute hub addresses a gap that is easy to miss when GitHub is already part of your working day. Sharing a repository link is not the same as helping somebody use what is in it.
Some readers want the finished download. Others want to inspect the source, report an issue, or make a small improvement. Those are different tasks, and they should not all begin with the assumption that the reader is already comfortable with branches and pull requests.
The GitHub Desktop guide provides a visual route into contribution. The editor connection guide covers the starting points for Visual Studio Code, Cursor, Bob, and Kiro. Together, they help connect the repository to the place where a reader intends to work.
There are also dedicated pages for Codex, Claude Code, GitHub Copilot, and Gemini CLI, plus a broader introduction to cloud coding agents.
These pages are not an invitation to surrender review because a tool can propose a change. They are ways into a shared working process. Understand the task, work within an appropriate scope, inspect what changed, test it, and leave a contribution somebody else can evaluate. The interface may change; responsibility for the result does not.
Projects and Downloads: a place for the usable materials
The Projects and Downloads page gives the site’s practical work a common entry point. It introduces the projects, explains who they are for, and directs readers toward the relevant guides and downloads.
That distinction is important to me. An article can show why a pattern is valuable. A repository can expose its implementation. A project page should connect those two things without requiring the reader to reconstruct the whole story.
The initial projects address rather different audiences: teachers trying to recover preparation time, and developers moving an application toward a repeatable Azure deployment. What they share is an attempt to make a useful method reusable. The pages explain the intended starting point and keep the responsibilities that remain with the user visible.
They also make contribution easier to understand. A useful contribution might be a clearer explanation, a better worked example, or a reproducible report of something that failed. It does not have to begin with a large software change.
Teacher Workbench brings the work back to education
Teacher Workbench: Giving Teachers Back Time introduces a collection of reusable AI skills for lesson preparation, differentiation, assessment, intervention, and related classroom work. A coordinating skill helps select the relevant specialists, while the teacher supplies the learning goal and classroom context.
For me, this is a return to my roots in education and an opportunity to give something back. The point is not to replace the teacher’s understanding of students. It is to reduce the amount of repetitive explanation and preparation required to get a useful first version of a resource.
A familiar lesson is a good starting point. A teacher might ask for a worked example, supported practice, and a short check for understanding, then inspect the results against the actual objective. Beginning with known material makes the output easier to judge. It also makes it easier to see when the tool has misunderstood something that matters.
The project page leads to the teacher guide, worked workflows, editable materials, and platform download instructions. Its references begin with California K–12; teachers elsewhere can supply their own standards and curriculum. Approved school environments, deidentified information, and professional review remain part of the working approach.
I am also grateful to CITE’s CTO Mentor Cohort 15 for helping test the work. Shared materials become more useful when people bring real problems and practical feedback to them. That is the kind of participation the project is meant to support.
Lovable Deployment gives a prototype an operating path
Lovable Deployment: From Prototype to Azure addresses a different handoff: the point at which an interesting application becomes something people may depend on.
The project provides a starter overlay for an existing Lovable application connected to GitHub. Its materials bring together Azure infrastructure definitions, GitHub Actions workflow templates, runtime components, and adoption and operations guidance. The documented release approach uses staging, approval, production promotion, and a separate rollback workflow.
The value is not simply that an application can be hosted somewhere else. It is that the team has a defined place to address identity, configuration, change review, deployment, and recovery. Those responsibilities should not arrive as a surprise after the first successful demonstration.
For example, an internal operations team may have a useful prototype for reviewing exceptions. Before it becomes part of the daily process, somebody must own access, releases, failures, and support. The starter provides a way into that conversation without pretending to settle every application-specific decision.
It is not a blanket migration of an application’s database or existing backend. The project page makes those boundaries explicit and points readers to the adoption and verification guidance. That is the distinction I want these project pages to preserve: a reusable starting point is valuable precisely because people can see what it supplies and what they still need to decide.
And now, a word about the squirrels
The site’s newest section is The Anti-Squirrel Resistance, written from Blaise’s perspective. His first letter, Dear World: You Are Not Taking the Squirrels Seriously, introduces both the correspondent and the problem as he understands it.
Blaise is a white golden retriever with strong opinions about being included. He believes walks are important, duck sticks are welcome, and a suspicious amount of human activity occurs without adequate canine participation. He is particularly unconvinced by any explanation for why I would go somewhere involving a ball and leave him at home.
His letters appear on Sundays. They are a separate, deliberately lighter part of the site: observations about the world from a dog who is quite certain the humans are overlooking important evidence. Readers looking for Fabric architecture will still have Fabric architecture. Readers who need a break from deployment responsibilities can spend a few minutes with somebody whose main concern is whether the squirrel got away again.
I do not need to turn every part of life into a technology analogy. Blaise is here because he is part of mine, because his view of ordinary events is entertaining, and because a serious professional life can leave room for a very unserious dispute with a tree-dwelling neighbor.
Find something useful, then put it to work
The common purpose behind the new pages is straightforward: make it easier to move from an idea to a useful next action. Read the architecture reference before choosing a pattern. Use the GitHub hub to find the right way to download or contribute. Visit Projects and Downloads when the question becomes what materials are available to try.
A page is successful when it saves a reader from reconstructing context, hunting for the right file, or guessing which step comes next. The articles can continue exploring ideas in depth while the reference and project pages provide a more dependable route back into them.
Start with whichever resource matches the work in front of you. Bring a real question, test the recommendation against your situation, and share a specific improvement when something could be clearer. That is how a collection of posts becomes more useful than its publication history.
And on Sunday, Blaise would appreciate it if you took the squirrels seriously.
