Author: Mike

Launching a Claude Code Project: Design First, Then Build
I used Claude’s desktop interface for iterative design, then handed off to Claude Code for implementation.

After deciding to revive my Hazelcast Microservices Framework (MSF) project, and to do so using Claude AI to do much of the heavy lifting, it came down to figuring out how to actually do this. I had no playbook for it. Nobody does, really — we’re all making this up as we go.

I wanted to be transparent about my use of Claude, and at the same time I think the development process is interesting enough to be worthy of discussion. (Heck, maybe it’s more interesting than the framework blog posts I set out to write.) So I expect to end up with a dual series of blog posts: the framework posts — started by Claude, co-edited together, and given a final polish by me — interleaved with my observations on how the collaboration effort worked.

This first “behind the scenes” post covers the design phase: going from a vague idea to a set of design documents and an implementation plan, all before writing a single line of code.

Starting the Conversation

Here was my original prompt to Claude:

I want to use Claude Code to help me finish a demonstration project I started some time ago to show how to implement microservices using Hazelcast. (The main value of Hazelcast is to create materialized views of domain objects to maintain in-memory current state.) If it’s more effective, we can restart with a blank sheet rather than modify the existing project.

I’d really like to iterate over the design several times before any coding starts — is that best done in Claude Code, or using this desktop interface? Ideally, creating various specifications or design documents before any coding starts would be perfect, if Claude can use these various documents as a guide to the coding process.

How do we start?

Claude immediately suggested splitting the work across two interfaces: use the desktop/web interface for design discussions and document creation, then move to Claude Code for implementation. Made sense to me — the conversational interface is better for back-and-forth design iteration, while Claude Code excels at multi-file code generation with direct access to the project directory.

This turned out to be excellent advice. The design phase involved a lot of “what about this?” and “actually, let’s reorganize that” — the kind of exploratory conversation that works much better in a chat interface than in a code-focused tool. I tried doing some design work in Claude Code early on and it was noticeably worse — like trying to brainstorm on a whiteboard that keeps trying to compile your diagrams.

The Design Phase: A Roadmap in Nine Documents

What followed was an extended design conversation that produced nine documents over the course of a single session. I’m not going to walk through every one in detail — you can follow the links if you’re curious — but a few of them are worth talking about because of what they reveal about the collaboration process.

Getting Started: Template and Domain

Claude’s first move was to produce a comprehensive design document template covering everything from executive summary to demonstration scenarios. We never actually completed it — the conversation quickly moved in a more specific direction — but it served its purpose as a structural starting point. The architectural equivalent of a napkin sketch: useful for getting the conversation going, not meant to survive contact with reality.

Before we could fill in any template, though, we needed to pick a domain for the demonstration. Claude laid out a comparison between eCommerce and Financial Services, and we settled on a hybrid approach: start with eCommerce (universally understood, clear event flows, and I had existing code to reference) but design the framework to be domain-agnostic so other domains could be plugged in later. We also simplified from four services down to three: Account, Inventory, and Order. (A fourth service, Payment, showed up later when we built out the saga patterns. Scope creep, but the useful kind.)

That decision led to the eCommerce design document — a detailed Phase 1 design covering all three services, their APIs, events, and materialized views. Three view patterns came out of it: denormalized views (joining customer, product, and order data), aggregation views (pre-computing order statistics), and real-time status views (current inventory levels). If you’ve read the previous posts in this series, you’ll recognize these as exactly the kind of thing that makes Event Sourcing + CQRS worth the effort.

Where I Pushed Back

The conversation then turned to longer-term goals. I had ideas for observability dashboards, microbenchmarking, pluggable implementations, saga patterns, and more — far beyond what could fit in a Phase 1. Claude organized all of this into a phased requirements document spanning five phases.

We iterated over this several times, adding and reorganizing. The most significant change I made was moving Event Sourcing from Phase 2 to Phase 1. Claude had initially positioned it as an advanced feature, but I saw it as the fundamental organizing principle of the entire framework — events are the source of truth, not database rows. Once I explained my existing Hazelcast Jet pipeline architecture (where handleEvent() writes to a PendingEvents map, which triggers a Jet pipeline that persists to the EventStore, updates materialized views, and publishes to the event bus), Claude immediately agreed and restructured the phases accordingly.

This was one of the more interesting moments in the collaboration. Claude had made a reasonable default assumption about complexity ordering, but I had domain-specific knowledge about how the architecture should actually work. The back-and-forth was natural — I explained my reasoning, Claude incorporated it, and the result was better for it. If I’d just accepted the initial phasing without pushing back, the entire project would have been organized around a less coherent architecture. And honestly, I almost did just accept it. It looked reasonable. Sometimes the most important contribution you make is going “wait, actually…” when the first answer seems fine.

Other additions during this iteration:
- Vector Store integration (Phase 3, optional) for product similarity search
- An MCP Server (Phase 3) to let AI assistants query and operate the system
- Open source mandate — everything in Phases 1-2 must run on Hazelcast Community Edition
- Blog post series structure — features developed in blog-post-sized chunks
Architecture, Code Review, and the Rewrite Decision

The next few documents came quickly. The Event Sourcing discussion led to a dedicated architecture document detailing the Jet pipeline design — based heavily on my existing implementation, but now formally documented with all six pipeline stages, the EventStore design, and how event replay would work.

Then I uploaded several key source files from the original project for Claude to review: the EventSourcingController, DomainObject, SourcedEvent (later renamed to DomainEvent), EventStore, and EventSourcingPipeline. Claude produced a thorough code review comparing the existing code against the design documents. The verdict was encouraging — the core implementation was solid and matched the Phase 1 design almost perfectly. Claude recommended incremental enhancement: add correlation IDs, framework abstractions, observability, and tests on top of what was already there.

I went the other way. After thinking about the package naming, dependency versions, and scope of changes needed, I decided on a clean reimplementation using the existing code as a blueprint. This let us start with the right project structure, package names (com.theyawns.framework.*), and dependency versions (Spring Boot 3.2.x, Hazelcast 5.6.0) from the beginning rather than refactoring them in later. Sometimes — as I’d noted in the previous post — the right move is to stop patching the old cabinets and start fresh.

I won’t pretend this was a purely rational decision. Part of it was just wanting that clean-slate feeling — new project, new structure, no legacy cruft staring at me from the imports. Developers love a greenfield. We can’t help it.

The Implementation Plan

Once the architecture was validated and we’d agreed on the approach, Claude created a detailed Phase 1 implementation plan — a three-week, day-by-day schedule with code templates, success criteria, and task checklists:
- Week 1: Framework core — Maven multi-module setup, core abstractions, event sourcing controller, Jet pipeline
- Week 2: Three eCommerce services — Account, Inventory, Order with REST APIs and materialized views
- Week 3: Integration, Docker Compose, documentation, demo scenarios
We made a few tweaks (updating Hazelcast from 5.4.0 to 5.6.0, for instance), and then it was time to move to code.

The Handoff to Claude Code

Claude provided specific instructions for transitioning to Claude Code, including a context block to paste when starting the session:
```
I'm building a Hazelcast-based event sourcing microservices framework.

Project location: hazelcast-microservices-framework/
Current state: Design documents complete, ready for implementation

Key decisions:
- Clean reimplementation (no existing code to port)
- Spring Boot 3.2.x + Hazelcast 5.6.0 Community Edition
- Package: com.theyawns.framework.*
- Three services: Account, Inventory, Order (eCommerce domain)
- Event sourcing with Hazelcast Jet pipeline
- REST APIs only

Implementation plan: docs/implementation/phase1-implementation-plan.md

Starting with Day 1: Maven project setup + core abstractions

Please read the implementation plan and let's begin.
```
The whole point of the “design first” approach: you’re not asking the AI to guess at your architecture. You’re handing it a blueprint. The more detailed the blueprint, the less time you spend arguing about load-bearing walls later.

Documents 7-9: Claude Code Configuration

Before making the jump, I asked Claude about setup suggestions for Claude Code. This produced three more documents:

CLAUDE.md (originally called .clinerules — I’m still not sure where that name came from) is the main configuration file that Claude Code reads automatically. It defines code standards, patterns, pitfalls to avoid, and documentation requirements. This file evolved a lot over the course of the project; looking at the commit history gives a good sense of how the “rules” grew and adapted as we ran into new situations. (More on that in a future post — it turned out to be one of the more interesting aspects of the whole process.)

claude-code-agents.md defined eight specialized agent personas — Framework Developer, Service Developer, Test Writer, Documentation Writer, Pipeline Specialist, and others — each with specific rules, code patterns, and checklists. The idea was to switch between personas depending on the task at hand (e.g., “Switch to Test Writer agent. Write comprehensive tests for EventSourcingController.”). Whether this actually helped or was just a placebo is something I’m still not sure about, honestly.

A docs organization guide rounded out the set, providing a recommended directory structure for keeping all the documentation organized as the project grew.

What Came Next

The resulting project grew well beyond the original three-week Phase 1 plan. At 150 commits, it now includes four microservices (Payment was added for saga demonstrations), an API Gateway, an MCP server for AI integration, choreographed and orchestrated saga patterns, PostgreSQL persistence, Grafana dashboards, and more. The three-week plan took considerably longer than three weeks. So it goes.

But all of that implementation work — and the interesting stories about how human-AI collaboration played out during coding — is material for future posts.

What I’d Do Differently (And What I’d Do Again)

If you’re thinking about using AI for a non-trivial coding project, here’s what I took away from the design phase.

Use the right tool for each phase. The conversational interface is great for the messy, exploratory work of figuring out what you’re actually building. Claude Code is great for building it.

Iterate on design before you write code. We went through multiple rounds of revision on the requirements and architecture documents. Each round caught issues or surfaced priorities (like Event Sourcing belonging in Phase 1) that would have been much more expensive to discover during implementation. Measure twice, cut once. The carpenter’s rule exists for a reason.

Bring your domain knowledge — and don’t be shy about pushing back. Claude made strong default recommendations, but the most valuable moments came when I disagreed based on my understanding of Hazelcast and the architecture I wanted. The AI is a powerful collaborator, but it doesn’t know what you know. If something feels wrong, say so. That’s where the real value of the collaboration happens.

And document everything. I mean it. The design documents weren’t just planning artifacts — they became living reference material that Claude Code used throughout implementation. The CLAUDE.md file in particular became a continuously evolving guide that shaped code quality across the entire project. Every hour spent on documentation saved multiples in “no, that’s not what I meant” corrections later. I’ve never been great about documentation discipline, so having an AI that actually reads and follows the docs was a surprisingly effective motivator to keep them current.

The Hazelcast Microservices Framework is open source under the Apache 2.0 license. You can find it at github.com/myawnhc/hazelcast-microservices-framework.

Next up: what happened when we actually started coding. Spoiler: the plan did not survive intact.
March 6, 2026
The Hazelcast Microservices Framework

How a side project connecting Event Sourcing to Hazelcast sat unfinished for years — and why I decided to bring it back with an AI collaborator.

In my previous post, I shared some of my thinking about Event-Driven Microservices — the coupling problems, the mental shift toward thinking in events, and the patterns (Event Sourcing, CQRS, materialized views) that make it all work. That post was conceptual. This one is personal.

I’ve been playing around with design concepts in this area for some time. While I was an employee of Hazelcast, I frequently worked with customers and prospects to show how Hazelcast Jet — an event stream processing engine built into the Hazelcast platform — could be used to build event processing solutions that would scale while continuing to provide low latency. These conversations were always framed around stream processing, though. Even when the intended use case was around microservices, we didn’t explicitly get into the Event Sourcing pattern. As someone coming from a background that was database-centric, the concept of events as the source of truth was a bit much for me.

The Light Bulb Moment

It was a light bulb moment when I realized that Hazelcast Jet could fit naturally into an Event Sourcing architecture — and that Hazelcast IMDG (the in-memory data grid, or caching layer) could concurrently maintain materialized views representing the current state of domain objects.

Think about it: Event Sourcing needs an event log and a processing pipeline. Hazelcast Jet is a processing pipeline. CQRS needs a fast read-side store that’s kept in sync with the event stream. Hazelcast IMDG is a fast read-side store. Event Sourcing + CQRS maps beautifully onto Jet + IMDG (even though that acronym is officially retired — it’s all just “Hazelcast” now).

And from there, I really wanted to demonstrate this. The original Microservices Framework project began.

Version 1: The Proof of Concept

The first version was focused on proving the core idea worked. Could I wire up a Hazelcast Jet pipeline to process domain events, persist them to an event store, and update materialized views — all in a way that was generic enough to work across different services?

The answer was yes. The central pattern that emerged was straightforward: a service’s handleEvent() method writes incoming events to a PendingEvents map, which triggers a Jet pipeline that persists events to the EventStore, updates materialized views, and publishes to an event bus for other services to consume. It worked, and it was fast.

Now, the central components of the architecture — the domain object, event class, controller, and pipeline — have survived relatively intact through multiple iterations of the implementation. The bones were good. But a lot of the specific implementation choices I made around those bones haven’t aged all that well.

You know how it goes with side projects. Technical debt accumulates quietly, one “I’ll fix this later” at a time, until you’re looking at a codebase where you know you’d make different choices if you were starting over — but the sunk cost of time already invested keeps you from actually doing it. It’s the software equivalent of a kitchen renovation where you keep patching the old cabinets because ripping them out feels like too big a project for a weekend.

That version of the framework is still hanging around on GitHub, although I decided not to link to it here as I may take it down at any time. (Upcoming posts will link to the improved version, so embedding links to the original will inevitably lead to someone grabbing the wrong one.)

I got it to a working state, but there was a long list of things I wanted to add. Saga patterns for coordinating multi-service transactions. Observability dashboards. Comprehensive tests. Documentation that went beyond “read the code.” Each of these was a meaningful chunk of work, and progress slowed to a crawl.

The Stall

Let’s be honest about what happened: the project stalled. Not dramatically — it wasn’t ever really abandoned. It just… stopped moving. Every few months I’d open the codebase, when I had some extra time, and make a few minor, inconsequential changes while thinking of the more ambitious refactorings or added features that I’d get to when time permitted.

If you’ve ever maintained a passion project alongside a day job, you know this feeling. The ideas don’t go away — they sit in the back of your mind, periodically surfacing with a pang of “I should really get back to that.” But the activation energy to restart is high, especially when the next step isn’t a fun new feature but the grind of scaffolding, configuration, and test coverage. So you close the laptop and tell yourself next month will be different. (It won’t be.)

Enter AI-Assisted Development

In early 2025, I started using Claude for various coding tasks and was genuinely surprised by the results. This wasn’t autocomplete on steroids — I could describe an architectural pattern and get back code that understood the why, not just the what. I could say “this needs to work like an event journal with replay capability” and get something that actually accounted for ordering guarantees and idempotency.

That’s when the thought crystallized: what if I could use this to break through the stall?

Here’s the thing — the stuff that had been blocking me wasn’t the hard design work. I knew what the architecture should look like. The bottleneck was the sheer volume of implementation grind: scaffolding new services, writing comprehensive tests, wiring up Docker configurations, producing documentation. Exactly the kind of work where you need focused hours, and a side project never has enough of those.

Now, I want to be clear about what I mean here, because “AI wrote my code” carries a lot of baggage. This wasn’t about handing off the project and checking back in when it was done. It was about having a collaborator who could take high-level design direction and turn it into working code at a pace that made the project viable again. I’d provide the domain expertise, the architectural decisions, and the quality bar. The AI would provide the throughput.

Making the Decision

I decided to move forward with a clean reimplementation rather than trying to evolve the existing codebase. The core patterns from the original work — the Jet pipeline architecture, the event store design, the materialized view update strategy — were proven and would carry forward. But the project structure, package naming, dependency versions, and framework abstractions would start fresh. Sometimes the best way to fix a kitchen is to actually rip out the cabinets.

The plan was to use Claude’s desktop interface for iterative design discussions (requirements, architecture, implementation planning) and then hand off to Claude Code for the actual coding. Design first, then build — with comprehensive documentation at every step so the AI would have rich context to work from.

What happened next — the design phase, the handoff to Claude Code, and the surprises along the way — is the subject of the next post.

February 26, 2026
Why Event-Driven Microservices?
You’ve heard the pitch for microservices. Small, independent services. Teams that can ship without waiting on six other teams to finish their sprint. No more three-month release cycles because somebody touched a shared library. It sounds great — and honestly, the core idea is great. But here’s the thing: a lot of teams adopt microservices and end up with something worse than the monolith they started with.

I’ve spent the most recent part of my career working with distributed systems, and I’ve seen some of the ways monolith-to-microservice transitions can go awry. A team takes their monolith, draws some boxes around the major modules, splits them into separate services, deploys them independently, and declares victory. Six months later they’re debugging cascading failures at 2 AM and wondering why everything is harder than it used to be.

What went wrong? They broke the monolith apart without actually decoupling it. And a distributed monolith — where you have all the operational complexity of microservices with none of the benefits — is arguably the worst of both worlds.

The Coupling Problem

Let’s be specific about what tight coupling looks like in a microservices architecture, because it’s not always obvious.

Synchronous request-response everywhere. Service A calls Service B, which calls Service C, which calls Service D. If any one of those services is slow or down, the whole chain stalls. You haven’t built a resilient distributed system — you’ve built a monolith with network hops. And network hops are the worst kind of function calls, because now you get to deal with latency, partial failure, and timeout tuning on top of everything else.

Shared databases. Multiple services reading from and writing to the same tables. This is the one that sneaks up on people, because the database feels like shared infrastructure rather than a coupling point. But the moment you need to change a schema, you’re coordinating across every service that touches those tables. You’re right back to “deploy everything together or deploy nothing” — which is exactly what microservices were supposed to fix.

Data format dependencies. Service A produces a message with a certain structure. Services B, C, and D all parse that structure. Now Service A needs to add a field or change a type. Congratulations, you need buy-in from three other teams before you can ship. That’s not independent deployment — that’s a distributed approval process.

Temporal coupling. Services that have to be running simultaneously to function. If the downstream service isn’t up right now, the upstream service can’t do its job. Your services aren’t really independent if they can only work when everyone else is awake. (Kind of like a group project where one person has to be physically present for anyone else to make progress. We’ve all been in that group project.)

If any of this sounds familiar, you’re not alone. And the good news is that these problems are well-understood, and there are well-established patterns for solving them.

Thinking in Events

Here’s the mental shift that makes the difference: stop thinking about services calling each other, and start thinking about services reacting to things that happen.

This is event-driven architecture, and at its core it’s about making your software reflect how the real world actually works. The real world doesn’t operate on synchronous request-response. Things happen — a customer places an order, a sensor reads a temperature, a payment clears — and other parts of the system respond to those events on their own terms, at their own pace.

When you build systems this way, something interesting happens to those coupling problems:

Synchronous chains disappear. Service A publishes an event. It doesn’t know or care who’s listening. Services B, C, and D each pick up the event and do their thing independently. If Service C is having a bad day, Services A, B, and D don’t notice — they keep right on working.

Data ownership becomes clear. Each service owns its data, publishes events about what changed, and subscribes to the events it cares about from others. No shared databases, no schema coordination nightmares.

Temporal coupling goes away. If a service is down when an event is published, that event waits in the stream until the service recovers and processes it. The system degrades gracefully instead of falling over.

Now, this isn’t magic — you’ve traded one set of challenges for a different set. Event-driven systems have their own complexities: eventual consistency, event ordering, debugging asynchronous flows. We’ll get into all of that. But at least these are the right problems to have — problems that come from genuinely decoupled services rather than from a distributed monolith pretending to be something it’s not.

Patterns That Make It Work

If you start exploring event-driven microservices, you’ll quickly run into a set of well-known patterns that have emerged to address the practical challenges. Chris Richardson’s microservices.io is an excellent catalog of these — I’d recommend bookmarking it.

Two patterns in particular are going to be central to what we explore in this blog, and I’ll admit it took me a while to appreciate how well they fit together:

Event Sourcing — instead of storing the current state of your data and updating it in place, you store the sequence of events that led to the current state. Every state change is captured as an immutable event in an append-only log. This gives you a complete, auditable history of everything that happened in your system — not just “the account balance is $500” but “here’s every deposit, withdrawal, and transfer that got it there.”

If you come from a database background (guilty), this feels deeply wrong at first. You mean I don’t just UPDATE the row? I keep every change? Forever? But once you get past the initial discomfort, the power of it becomes obvious. You can reconstruct any past state. You can answer questions you didn’t think to ask when the data was created. You have a complete audit trail for free.

The catch is also obvious — if you need the current state, do you really have to replay every event from the beginning of time? For a system that’s been running for years, that’s not just slow, it’s unworkable.

CQRS (Command Query Responsibility Segregation) — and this is where it gets interesting. You separate the write path (commands that produce events) from the read path (queries that serve up current state). The write side stores events. The read side maintains materialized views — pre-computed projections of whatever the read side needs, kept up to date by consuming the event stream.

See what happens when you put these two together? Event Sourcing gives you the complete, immutable history. CQRS and materialized views give you fast reads without replaying the entire event log every time someone wants to check a balance. Each pattern solves the other’s biggest problem. It’s one of those combinations where the whole is genuinely greater than the sum of the parts — and as we’ll see in later posts, it maps onto certain technology stacks almost embarrassingly well.

What’s Ahead

This blog is going to be a hands-on exploration of these ideas — patterns first, then concrete implementations. I’m genuinely excited about this, because I think there’s a gap between the theoretical literature on event-driven architecture (which is excellent) and the practical “here’s how you actually build one” content (which is thinner than you’d expect). In the posts to come, we’ll dig into:
- Resilience through decoupling — how event-driven systems degrade gracefully instead of cascading failures
- Auditability and replay — the power of an event log as a source of truth, not just for debugging but for compliance, analytics, and the ability to answer questions you didn’t think to ask yet
- Independent scalability — scaling the services under load without scaling everything, because your order processing pipeline doesn’t need to drag your user profile service along for the ride
- Evolvability — adding new consumers of existing events without touching the producers, so your analytics team can tap into a data stream without filing a ticket with the team that owns it
We’ll look at the patterns in general terms — what problem each one solves, what trade-offs it introduces, how to think about whether it’s the right fit — and then we’ll get into specific, working implementations that you can pull apart, run, and adapt to your own projects.

If you’re a developer who’s building or maintaining a microservices architecture and found it harder than expected — or if you’re designing a new system and want to avoid the common pitfalls — this series is for you. The patterns are universal; the implementations will be specific. Let’s see where it takes us.
February 23, 2026
A fresh start

I’ve repurposed my previous personal, travel-oriented blog to be more developer focused, giving me a place to share technical content now that I’m semi-retired. I still have an interest in programming and technology in general, so I’ll be reporting on topics I find interesting as I pursue projects that excite me. Watch this space for upcoming updates on my first such project.

February 22, 2026
D23Expo 2015: Walt Disney Animation

On Friday afternoon (Aug 14), Walt Disney Animation and Pixar presented their upcoming slate of animated features.

The presentation was kicked off by Alan Horn, Chairman of Walt Disney Studios.   He showed a history reel of Disney/Pixar animation highlights, and explained how proud he was to be connected to the heritage and legacy of Disney animation — to have a connection to the people who invented the art form of feature animation.

He further explained that when Ed Catmull and John Lasseter took over (as part of the acquisition of Pixar), the development model changed from an executive-driven process to a filmmaker-driven process.

He then introduced John Lasseter (head of Pixar and Disney Animation) to take us through the films.

I’ll cover Walt Disney Animation in this post, and Pixar in the post that follows.

ZOOTOPIA

John explained that he’d always been a fan of animation featuring anthropomorphic animals — animals that wear clothes, use machinery, drive cars (he cited Mr. Toad as an example here).   Zootopia is a film in that mode.

Director Byron Howard (Tangled, Bolt), Director Rich Moore (Wreck-it Ralph) and Producer Clark Spencer came out to present a film clip.   In the clip, Nick Wilde, a fox (voiced by Jason Bateman) is trying to con an ice cream shop owner out of a free ice cream for his son ( left the wallet at home … it’s the kid’s birthday … the poor kid is sick .. etc. ).   Watching this is bunny Judy Hops (voice by Ginnifer Goodwin), who will later pair up with Wilde to solve a missing persons case.

The area they inhabit is very richly designed, with different environs for the various types of animals — tunda, burrows, dunes, rainforest.

Ginnifer Goodwin came out to give some background on her character — she plays a cop, and in this world cops are always the bigger, tougher animals. So as a bunny, she’s assigned to be a meter maid rather than getting the good assignments.   So the missing persons case she is working (it wasn’t explained how that will come about) is going to be her big break.     In another hilarious scene — where Nick and Judy are trying to get information from a DMV employee played, appropriately enough, by a sloth — it’s unclear whether Nick is really trying to help or hinder the investigation.

We had a very brief video from Shakira, who played just a few seconds of her song Try Everything from the movie. She is also playing the character of a gazelle.

Zootopia will be released March 4th 2016.

GIGANTIC

Lasseter to returned to the stage to explain how, whenever Disney does a fairy tale story, it tends to become the definitive version of that tale.   Many of the Disney stories had been told and re-told in many different forms before Disney’s version.

So, Lasseter announced that Disney is now setting out to tell the definitive version of the Jack and the Beanstalk story.   The movie will be titled Gigantic, with a release date of 2018.   Nathan Greno (Tangled) will direct, and Dorothy McKim will produce.

The film is set in Spain during the Age of Exploration. We heard that when Jack goes up the beanstalk, he encounters not just a single giant, but a whole community of giants. In particular it appears he becomes the plaything of one young girl (Inma – not sure about the spelling).

Bobby Lopez and Kristina Anderson-Lopez (Frozen) will create the songs for the movie.   They came out on stage and Kristina sang “Little Man” from the film while storyboards for that sequence were shown.

No casting was announced.   The movie is scheduled for a 2018 release.

MOANA

John Musker and Ron Clements (The Great Mouse Detective, The Little Mermaid, Aladdin, Hercules, Treasure Planet, The Princess and the Frog) directing, Osnat Shurer producing.

Moana directors John Musker and Ron Clements. Image (c) D23.com.

This tale is set in the South Pacific.   The islanders in this region, historically, have been some of the greatest navigators in the world.   Yet, for some unknown reason, about 2000 years ago they stopped exploring and basically stayed at home for a thousand years.   Then, about 1000 years ago, they resumed their seafaring ways.   This story sets out to tell us why.

Teenager Moana longs to explore the ocean, but her father doesn’t want her (or anyone) to venture past the reef-protected immediate vicinity of their island.    She is encouraged and motivated by her grandmother.   She is also inspired along the way by a demi-god, Maui, played by Dwayne Johnson.

At this point Dwayne came out and told us more about his character.   A clip was played where he tries to impress Moana. The character Maui is covered with tattoos, which will animate to tell about his deeds.   He carries a giant fishhook with which he can pull islands up from the ocean floor.

Dwayne Johnson. Image (c) D23.com.

We saw a clip where Moana, as a young girl (about 2), meets the ocean for the first time. This is a beautifully animated sequence in which the ocean has real personality — it teases Moana by withdrawing to reveal shells, and as she moves forward to collect the shells, the ocean forms a wall around her, creating a virtual aquarium where she can see the sea life around her.   A wave then gently carries her back to the beach.

A Polynesian musical number was then performed by a large group of singers and dancers; I’m not sure if this was actual music from the movie or just to show the general tone, but it was beautiful and should be amazing when paired with animation like the preview we were shown.

Release date: 11/23/16

Those are the upcoming films from Walt Disney Studios feature animation … Pixar will be covered in the next post, and the live-action releases (Disney, Marvel, and Lucasfilm) in the posts that follow.

August 24, 2015
Expedition Everest Challenge, Part 3: The Hunt

After completing the 5K, the ‘Challenge’ part of the Expedition Everest Challenge is to complete a scavenger hunt.   (I’m not sure why this is called a scavenger hunt, as there isn’t really any “find something” aspect to this at all — unless you didn’t pay attention on the race to where the clue stations were located).

As soon as I crossed the finish for the 5K, I headed to the first clue station to get my first question.   This was by far the most challenging clue of the night:

Clue 1:

Only time will tell if you make it to the summit of Mt. Everest.   If climbing for 24 hours straight, how many times will at least 3 digits in the row be the same on your analog watch?   This is not boot camp so don’t use military time.

Thinking I was clever and had seen through the misdirection, I immediately went to the volunteers handing out Clue 2 and said you would never get 3 of the same digits in a row on an analog watch.   But this wasn’t the answer they were looking for; the clue writer was the clueless one here on the difference between analog and digital watches.

I struggled with this one more than I should have, probably because I was overly concerned with my time to finish the challenge (not sure why at this point, as I certainly wasn’t going to be winning anything!)    I quickly came up with 1:11, 2:22, 3:33, 4:44, 5:55, 11:11, and 12:22, knew to double that for a 24-hour period, and wrote down the answer 14.   Nope, try again.   At this point I saw that others had written down ’34’ and were being given the second clue, so I decided not to spend any more time on this one, wrote down 34, got the second clue, and didn’t worry more about it until the next day.

(As an aside, the next day I realized 11:11 was just one part of the whole series of 11:10 through 11:19 that all have 3 1’s in a row; but that only got me up to 32.   The last piece to click into place was getting 10:00 with 3 0’s in a row, so adding 10:00 am and 10:00 pm gave me the final two to get to 34.)

Clue 2 was a bit easier, but still required a little time to work through.   There was a wheel with letters around it (think the Wheel of Fortune wheel with letters rather than dollar amounts), and you had to figure out the word spelled a series of spins of the wheel.   They gave the starting letter as ‘C’ and then several directions such as Left 2, Right 2, Left 3 — but the first ‘spin’ wasn’t given as a number, but a hint:

Start with C and turn from there the number of years Expedition Everest has been run‘.

Fortunately, they’d given us the answer to this while we were in the corrals waiting to start the run — they asked more than once for a show of hands, how many had run the event all 7 years it had been run?    So I wasn’t sure if they were looking for 7 (previous runs) or 8 (total including tonight’s run).    I tried 7 first and got C, A, R, A, B, I, N, E, R — yep, that looks good, off to get clue 3!

(The clue stations were all marked with large lit balloons like the ones that marked the corrals at the start of the race, and they were all stationed along the race course — so essentially the challenge gave us a second lap of the in-park portion of the course we’d run earlier in the night. I think I recall the total mileage for the 5K + challenge as coming in at almost exactly 5 miles).

Clue 3 was simply to put into order the groups of letters ERS, INE, NTA, MOU — given the theme of the night I had MOUNTAINEERS as quickly as I could write it down, and was off for Clue 4.

Clue 4 gave the hint:

L + live + A + Sh + N

I was sure this needed to be sounded out to get the answer but I had to look at it several times before getting ‘elevation’.   But I definitely liked the trend of 3 and 4 being easier than 1 and 2 — only one more clue to go!

Clue 5 was not difficult, but it was time consuming.   There was a 13 x 13 grid of letters forming a word search. The clue:

We have finally found the Yeti and you will too, but where?

Solve the word search and you will know where he is hiding. Use this cipher and the previous four answers to help you in this quest.

Clue #1 x 3, Clue #2 x 4, Clue #3 x 2, Clue #4 x 3.

The leftover letters will tell you where the yeti is and what you need to do at the finish line.

So — Clue #1, the answer was 34, and I quickly saw that ‘THIRTYFOUR’ did appear in the word search grid. So I needed to find it twice more, for a total of 3 times, and circle those letters.   Then I circled CARABINER four times, MOUNTAINEERS twice, and ELEVATION 3 times.   The remaining, uncircled letters told me what I needed to do next:

Go Find the hidden Yeti on a clue card and hold it up at the finish

Going back through the clue cards, each had a different bit of artwork on the front.   It took me a bit before I made out the Yeti face diagonally across the second clue card.   I reordered the cards to put #2 on top and then started for the finish line — the final clue station wasn’t all that close so there was still some distance to cover.   As I approached the finish I saw the volunteers checking runners as they came through, if you weren’t holding up Card #2 they’d tell you nope and divert you to the side. I passed straight through, picked up my medal, and then stopped for pictures.

Can you spot the Yeti?

How about now?

Heading for the finish with “Card 2” ready to show

There was an after-party going on inside the park with several rides open, but having already done an AK day and ridden everything we were interested in, we decided to blow off the after-party and head for the room, to try to get some rest for a full day at Epcot the following day.    There were some nice photo ops in the park that might have been worth stopping in for, but I’m much more a morning person than a late nighter so I think for me, calling it a night at this point was the right call.

Done here.

Overall, this was a really fun event, and the only 5K that is treated as an ‘event’ by runDisney — all the other 5Ks are kind of third-tier add-ons to the marathon and half-marathon races.   I think something like this is really a nice change of pace, and while I know this is the last EEC, I hope it’s not the last time there’s an event of this type.

May 22, 2015
Expedition Everest Challenge, Part 2: The Run

The run portion of the Expedition Everest Challenge is a 5K. Our course started out by running around the circumference of the Animal Kingdom parking lot.   This portion of the run made up approximately a mile of the 5K course.   Just before we reached the park entrance, we came to the first of 3 obstacles along the course — the hay bales.   These were pretty low — probably a foot high and a foot long.   It would certainly be possible to just step over them, but I got into the spirit of the challenge and tried to take them at speed.

The first obstacle – Hay Bales

Soon after that I was at the 1 mile marker.   I was running with the new Apple Watch, and had decided to try to workout app on the watch rather than running with the Garmin that I usually use.   I was a little concerned that we hit the 1 mile marker while the watch showed me still well short of a mile (I think about .8).   After the race, I learned from other runners that it wasn’t my watch — the course was not officially certified and was in fact quite a bit short (somewhere in the 2.7 – 2.8 mile range).   That’s a surprisingly large miss even for a non-certified course.

Our course through the park was essentially a clockwise lap around the park — through the Oasis, left in front of the Tree of Life into Africa / Harambe, then cutting across to Asia and the Expedition Everest area.   Our path then took us into backstage areas.   There was a long out-and-back stretch along a roadway, and here we came to the second obstacle, which was to crawl under netting.   Fortunately this was on clean dry grass so it wasn’t too tough, although it was surprisingly exhausting and I really felt glad to get back to my feet at the far end.

Coming out of the second obstacle

At this point, continuing on the roadway away from the Animal Kingdom, I was overtaken by a couple of riders on bicycles.   Other runners were alerting everyone to move right so the riders could get by.   Someone said ‘Fire Department’; I’m not sure if that was correct but they were certainly EMTs from somewhere, as within a minute of them passing me I came upon the scene where they were performing CPR on a runner.   I heard conflicting stories about the outcome, so I’m not sure if he was OK or not.   I certainly hope that it turned out OK.

After we finished the out-and-back leg of the course on the roadway, we turned left and merged with runners who were finishing up the ‘scavenger hunt’ portion of the challenge which comes after the 5K.   At this point there were signs and recorded audio telling runners to merge to the right, and scavengers to merge to the left.   After this, it was a turn into the finish chute for the run.    But unlike other races, when you finish the run, you’re far from done (and there is no medal awaiting you for “just” finishing the 5K).   There was a stop for water bottles, and then race volunteers handing out sharpies with small LED flashlights attached.   Then you picked up your first clue for the scavenger hunt.

The details of the scavenger hunt will be in the third and final Expedition Everest Challenge recap post.

May 20, 2015
Expedition Everest Challenge, Part 1: Before the Race

I recently returned from my latest WDW trip and wanted to write up some memories of the trip while it was still fresh in my mind.

The main purpose of this trip was to run in the Expedition Everest Challenge (EEC).   I’ve always thought this looked like an interesting race but the timing has never worked out for me to run it.   When it was announced that 2015 would be final year for the EEC, I committed right away to attend.   Several of my friends were also planning to be there the same week — one for the EEC, another for her birthday — so I knew it would be a fun week to be there.   And the Epcot Flower and Garden Festival happening at the same time was another plus, although as it turned out we only spent one day at Epcot and didn’t see as much of that as we might have liked.

Registration and “Expo”

I knew from talking to friends who had run the EEC before that there wasn’t really a race expo — but I still wasn’t prepared for just how scaled down this event would be.   First of all, final race instructions didn’t even arrive until I was in Florida, so I wasn’t really even sure what was going to be happening when.   When I did receive the final race instructions email, I learned that the location for the registration was the Animal Kingdom parking lot.   When we arrived at the park, directions were non-existent — I never saw a single sign directing runners how to get to the registration location.    Since the registration didn’t open until noon our plan was to spend the morning in the Animal Kingdom then pick up my bib and other materials on the way out.   As we were trying to get into the park there was all “all stop” on the trams as a guest was walking down the tram-only roadway trying to find a way through the barriers and into the registration area.     Partly — OK, mostly — his fault, but again the complete lack of directions on how to get to the tents didn’t help.   (When we exited the park and were ready to head over to registration, we had to ask a cast member the best way to get there as I never saw a directional sign. It was definitely arranged in such a way that they clearly expected you to ride the tram to the front entrance and then walk back to the tents — but this was unclear from the parking lot and it looked like the trams would take you away from where you needed to be).

The registration area was just a big tent; you went into one side to turn in your waiver and get your race packet (bib, wristband for the after party) and then to the other side to get your race shirt and a plastic bag for the bag check.   It was by far the quickest registration I’ve ever been through for a runDisney event – I was probably out of there in under 10 minutes.    There was no official runDisney merchandise.   New Balance had a booth to sell this year’s monochrome shoes (so glad I got the 2014 version) and Fit2Run had a booth there as well.   (I think there was one other tent but can’t recall which company it was for).   That was the totality of the ‘expo’; I didn’t make any stops other than the registration tent and then we headed back to the car to spend the rest of the day in another park.

Pre-Race

On race night, I had dinner with friends at Jiko and then made the short drive over to the Animal Kingdom parking lot.    We arrived about 8:45 for a 10 p.m. start, and had a chance to do some visiting before time to head into the corrals.   I was in corral I (J was the last, so I’m definitely a back-of-the-pack run/walker).   The first corral started at 10, and I believe it was about 10:40 when our corral was scheduled to start.   Unlike other runDisney starts there were no fireworks as each corral started — I’m guessing that this is out of consideration for the animals rather than due to the relatively small scale of the race.   From the corral I watched the other groups start one by one. Because of the way the corrals were arranged we didn’t move from our assembly spot until we were the next corral to go.    Once we were up and in position, it was a pretty quick countdown to our start … and that’s where I’ll pick up the story in the next post.

Expedition Everest 2015 Starting Line

May 16, 2015
Dumbo Double Dare 2013: The Half-Marathon
Back-to-back runs is something new for me, so I wasn’t sure how Saturday’s 10K run was going to affect my run in the half on Sunday.    Even during training, there were no back-to-back runs.   I was following Jeff Galloway’s training plan for the Dumbo, and in that training plan he has you do long walks, rather than runs, on Saturday, and then the long runs on Sunday.    That seemed odd to me, but who am I to question the master?   So that was my training regimen, imperfectly followed to be sure, but long walks on Saturday and long runs on Sunday.

The good news is that I did not feel any ill effects from Saturday’s 10K. No soreness, aches and pains, or notable fatigue as I was getting ready on Sunday.    And I decided the motto for the day was “no excuses”.   Saturday was done, it was not going to affect my performance on Sunday.    The weather was again unseasonably warm, and while that would undoubtedly affect my speed, it was not going to keep me from finishing and having a great time.   I had three medals waiting for me at the finish line and I would run, walk, or crawl across that finish line to get them.

Pre-Race

The corral situation was less confusing today.   As soon as I turned the corner to head to my corral, I saw the “G” balloon clearly — and now that I know where G corral actually is, I’m pretty sure that the marker balloon had not been there on Saturday.    I knew I’d be slow today, and that starting in the last corral gave me no margin to fall behind pace, so I wanted to at least give myself the advantage of being in the front of the corral.    Mission accomplished — I was ready to enter the corral at 4:20 a.m. and was in the front row.   I sat on the pavement and passed the time texting and Facebooking, although I eventually realized I had better make sure I had enough battery power for the race and put the phone away.

We watched corrals A-F start; I think the intervals were 7 or 8 minutes apart.    As F was moving to the start, they began moving our barricade forward, and we edged our way closer to the start.   Once F had gone they moved us into place — so I had a front row view of Mickey, Minnie, and our race announcer as they counted us down to the race start.

First half of the race

And then we were off.    Being at the front of the corral certainly has its advantages — yesterday I had been so hemmed in that I felt like I couldn’t set my own pace at all.   Today with nothing but pavement in front of me, I was able to establish a good pace early, and the first couple of miles established a good faster-than-PR pace that I hoped would carry through.     Very early on I realized that there was some lingering effect from yesterday’s run — although I had felt nothing standing or walking, once I started to run I felt some twinges in the thighs indicating that I wasn’t 100% recovered from the 10K.   But this never became a factor, just something I was aware of without feeling it was affecting my run.

We did not run around by the convention center today, instead turning left on Katella, and then left on Harbor, to enter the park earlier than in the 10K.   Somewhere before mile 2, there was a big cheer coming from behind us, I turned in time to see the eventual race winner loping past us (Mile 2 and Mile 12 ran parallel for a while behind DCA).   Interestingly enough, I did not see the 2nd place or any other runners, so I have to assume the winner took it by a pretty good margin.

Our course through the parks was different than yesterday.   Instead of coming in through Cars Land, we ran behind Paradise Pier and California Screamin’, and entered the park at the western side of the Pier.   World of Color was again on for us as we ran along the northern side of the lagoon and headed into Cars Land.    From there we ran in front of the Tower of Terror and then headed toward the front of the park, essentially the reverse of yesterday’s course.    As we passed Soarin’ we turned right and exited the park, crossing the Esplanade and then entering Disneyland.

Backstage at DCA

Our course through Disneyland again took us down Main Street, but this time we went left rather than right at the hub and entered Frontierland.     We were able to run the Big Thunder Trail — this has been closed the entire month I’ve been here due to Big Thunder Mountain construction, I wonder if it will be closed again after the race.   We came out into Fantasyland, ran through the castle (yay!), and then turned into Tomorrowland.    We wound our way past it’s a small world and through Mickey’s Toontown, this time exiting Toontown through the same backstage entrance that we came into Toontown through in the 10K.    Our backstage run here was more curtailed than yesterday, heading straight out onto Disneyland Drive and then making a right towards Ball Road.    (I was a little unclear on the exact geography here … it seemed like we were running through the same area the corrals had been.   But that can’t be because the early wave runners would have been through here before the late corrals had emptied.   But I’m now curious — if I’d been at the back of the corral rather than the front, and looked behind me, would I have been able to spot the first wave of runners coming out of the park?

The Mile 4 marker was just as we came out of the park.   Now we had a long stretch of road running ahead.    At most of the mile markers, a couple of sweepers on bikes would tell us how we were doing vs. the required pace — 8 minutes ahead, 8 1/2 minutes ahead, 9 minutes ahead.    I’ve never heard these announcements before, but then I’ve never started in the last corral so I guess I’d never cut it as close.    The good news is the numbers were going up, I was building a little buffer ahead of the sweepers at each mile.

Miles 6 and 7 were all just road running.   Water stops were more frequent than the 10K (the 10K had been criticized for not having enough).    I was getting water at each stop, but had not adjusted sufficiently for the heat and humidity — I didn’t realize it at the time but I was not hydrating enough, and that was going to bite me very shortly.

Second half of the race

Between Mile 7 and 8 we went by a series of classic cars that lined both sides of the route.   I was amazed at how many there were — I figured there would be 20 or so cars, but then you’d turn the corner, and there was another row,   We entered the parking lot of the Honda Center, and there were still more.   There had to be at least a couple of hundred cars on display.   I was really starting to feel the heat at this point; I stopped trying to follow my pre-programmed run/walk ratio and decided instead to just run enough to keep my pace ahead of the required 16 min/mile pace.

At mile 9 we came to Anaheim Stadium.    We got a lot of encouragement here … cheerleaders, marching bands, scout troops — a lot of organizations had turned out to cheer.   (And actually there had been a lot of this along the route prior to this — but this was the main concentration).

It was nice to have the cheerleaders rooting us on, although a lot of them were encouraging us to fight, which seemed a bit strange for a friendly run.    Must be an L.A thing, maybe our race jerseys looked like gang colors.

About this point, the heat caught up with me.    I walked my way through the stadium, not running at all between miles 9 and 10.    I assured myself I just needed to cool off a bit, get some fluids into me, and then I could pick up the pace for the last three miles.   But the reality was I was done running, for all practical purposes — I’d do a few short 15-20 second runs maybe once a mile or so, and across the finish line, but I just didn’t have anything left in the tank.

Mostly it was the heat that had gotten to me, but I won’t deny that I hadn’t been as consistent with my training as I should have been, and always trained in the coolest part of the day in a more temperate climate — so I just had nothing to prepare me for the heat wave that manages to follow me to every runDisney event.    Also, it’s hard to find that motivation to run when everyone around you is walking … we were definitely the back of the pack at this point, and I think everyone within sight of me was content to just walk it in from this point in the race.    (Also, those helpful sweepers who had been calling out our pace at each mile marker did not appear again after mile 8 … I suspect that due to the heat they may have relaxed the pace requirement.)

Somewhere along mile 11 I realized I wasn’t even walking a straight line, so at the next water stop I took a little extra time to get more fluids in me, and had them refill the water bottles I was carrying (one was empty, and the other was as warm as bath water).

The finish was uneventful … I remembering walking by the spot at Mile 12 where we had spotted the leader run by 3+ hours ago, and walking around the Paradise Pier hotel and crossing through Downtown Disney, where we were being cheered on by a lot of the early finishers.    Then we rounded a curve and I could see the finish line.    I didn’t think I could run it from there, so I waited until I’d closed about half the distance to the finish line before I broke into a jog.    I made my way to the left side were Goofy and Mickey were awaiting, and got high fives from both just before I crossed the timing mat.

Post-Race

After the finish, I turned into the post-race area and had the big “D” Disneyland medal hung around my neck.   Then I made my way over to the Dumbo Double Dare tent, where I exchanged my wristband for a Dumbo medal.   And then to the Coast-to-Coast tent, where I again exchanged a wristband for a medal. (Dumbo is for doing both the 10K and the half this weekend, Coast-to-Coast is for doing a half-marathon or greater at Disneyland and Walt Disney World in the same calendar year)

Disneyland Half medal

Dumbo Double Dare medal

Coast-to-Coast medal

Water and Powerade were next — not just cups, as along the race, but full, cold bottles.   I took two Powerades and drained them right on the spot, then a water bottle to carry with me.   Photographers were moving through the crowd taking pictures, I had two or three taken around here so I bypassed the photo lines were you got your picture in front the official backdrop.     I grabbed a food box at the runner refreshment tent and sat down on the pavement to rest a bit — the walk back to the buses was a half mile or more and I needed a minute before I headed out.

I think I sat for 5 to 10 minutes.   I posted something to Facebook saying I’d finished, and then stood up (an amazing accomplishment) to head through Downtown Disney and to the shuttle bus area.     About midway through DTD, I felt I needed to sit down for a minute.   I had gotten a little light-headed.    I still had my water bottle with me, so I sat for probably 15 minutes sipping water.    I spotted a drink cart nearby, and decided another Powerade was in order.    I stood up again, found that the lightheadedness had passed, and walked to the drink cart, and then continued on to the buses.

I took a few hours of rest in my hotel room, and then put on my Half Marathon shirt, hung my medals around my neck, and headed back to Disneyland to get some pictures with my friends the princesses.

Next up: Wine & Dine half marathon in early November.   Between now and then, I’ll be doing my training runs in Atlanta, where the humidity will be more comparable to Florida.    And I’m hoping to get cool weather for that one … my WDW and DL halves have set the bar pretty low for a PR, so there’s no reason not to clear it easily in my next run.

Related articles
- Disneyland Half Marathon Weekend Course Maps and Corral Placement (runningatdisney.com)
September 2, 2013
Dumbo Double Dare 2013: The 10K
This morning I was up before 4 a.m. to get ready for the first leg of the Dumbo Double Dare, the inaugural Disneyland 10K.    I tend to be a morning person anyway so this didn’t throw me off much — I think I prefer this to night races, at least that’s been my experience so far.

I’ve been watching the weather forecast for a while, and I have to say, if accuracy in forecasting matters I’m not sure how any of these meteorologists stay employed.   Every day for at least a week, the temperature has been significantly above forecast — 99 on a day where 90 was the forecast high, for example.

The forecast for this morning was about 73 degrees, and one of the first things i did when I got up was check the temperature.   81.   Well, it’s not going to be a PR day, that’s for sure; and visions of the Tower of Terror race came back to me.    (Actually, this is my third runDisney race — Tower of Terror 2012, WDW Half 2013, and now Disneyland Half 2013, and all 3 have been “unseasonably warm”.    I hope things balance out and give me 40 degree temps for the Wine & Dine half in November, that would be spectacular.

The bus service was a pleasant surprise — I’d asked drivers a few times over the past few days where the bus stops were going to be, and they were not really sure, which made me a bit nervous.   But when I got downstairs, there was a prominent runDisney sign in the lobby indicating our pick-up was in front of the Embassy Suites (right next door).   So I walked over and joined about 8 people already waiting; we had a full busload of 25+ by the time the bus pulled up 10 to 15 minutes later.

Our dropoff was about half a mile from the starting corrals — a nice stretch and warm up pre-race, but I suspected it would seem far longer after.   (Actually, not too bad today, but the real test comes tomorrow).

The Disneyland 5K ran before our 10K started, so they sent the 5K runners ahead to the corrals while the 10K runners were held in a pre-race staging area, with entertainment, water, backdrops to have photos taken, and tents sent up by various charities and race sponsors.   I stayed near the water tables to get extra fluids in me, the high temp and high humidity combination made me want to make sure I was hydrated, even though that probably meant I’d be making a pit stop along the way.

Pre/Post-race assembly area

Pre-race entertainment

Follow Mickey to the starting corrals

The 5Kers took off – I heard they were a bit late starting but I hadn’t memorized the schedule so I didn’t notice the discrepancy.   We then made our way over to the corrals.   I was in corral G and honestly — I never saw it.   I saw balloons for D, E, and F   (A, B, and C were off in a different direction) and started making my way to the back of F where G was supposed to be.   I never saw it, but eventually started seeing G bibs mixed in with the Fs so I just merged my way into the crowd.    By this time the early corrals had already begun running so we started surging forward to get to the start.

I started my Garmin at 6:37 a.m. so that’s when my section of the mob was crossing the start.   Sunrise has been just a few minutes earlier, the temp had dropped a few degrees (79 now) but was still uncomfortable.

Our first two miles was on surface street. We started on Disneyland Drive next to the Disneyland Hotel, and proceeded south.   We crossed Katella and turned left to run in front of the convention center, where the D23 Expo banners were still hanging.

I had a run-walk strategy of run 20 seconds, walk 40, which was slower (more walking) than the ratio I’ve used in past races.   But I thought it would give me a better chance of finishing strong.   As it turned out, the race was just too congested for any sort of strategy other than run when there’s pavement in front of you, walk when there are people in front of you.   I tried to avoid doing too much running side-to-side, but occasionally when there was obviously clear space ahead I’d occasionally make a detour to the side to get around a slower group.

We continued down Convention Way to Harbor, and made the left to take us toward the parks.    We entered Disney’s California Adventure through Cars Land.    Mater and Lightning McQueen were out for photos.    Disney employees waved us ahead with checkered flags — I appreciated the well-themed encouragement.    Mater’s Junkyard Jamboree was whirling to add a little fun and background music to the run.   For some reason I missed getting pictures of any of this, but here are a few backstage shots as we headed into DCA.

Coming into DCA

The back side of rock

From there we continued onto Paradise Pier, and made a big loop of the lagoon.   The World of Color show was going … obviously it loses a lot during the daylight, but I loved running to the music and enjoyed glancing over at the fountains.   I saw the first race photographer of the morning along here but I’m not sure if he got me.   Mickey’s Fun Wheel was also going — in both parks, a few rides were operating (riderless) just to add a little kinetic energy to those of us who were losing ours.

A loop around the west side of the park brought us to Mile 3, just in front of Soaring Over California.    We continued across in front of Carthay Circle and headed down toward Tower of Terror, where we exited the park.

Here we descended and ran through a tunnel I didn’t know existed — I’m not sure exactly where it’s located but it seems it must be running under the shuttle bus drop-off area at the East end of the Esplanade.   Coming back up, we were in backstage areas surrounding Disneyland — I saw Cast Scheduling and Cast Costuming buildings, along with others that weren’t as prominently labeled.    We went from backstage to the Esplanade, through an open gate, and then under the train tracks onto Main Street USA.

Head toward the light

Cast Costuming, Cast Scheduling buildings

This is starting to look familiar

Running down Main Street was obviously a highlight so I stopped for a few pictures, then made the turn into Tomorrowland and continued around to it’s a small world.   From here we went backstage again, and passed a succession of interesting areas — vehicle maintenance, parade floats, seeing the backside of various areas such as ToonTown, etc.    At this point I checked my timing and realized I had enough of a buffer that I didn’t need to fear the sweepers … so I started taking more pictures, talking to those around me more, and just enjoying the morning walk.    I’d still take off at a jog when there was clear space in front of me, but that wasn’t happening all that often.

Main Street USA

Train Roundhouse and Monorail Barn — all 4 trains were visible but this photo really only captured one.

A nice display put on by costuming shop

Loved seeing vehicles awaiting maintenance.

Doom buggies

Bobsled

More bobsleds

Parade floats

Makeshift petting zoo

Custodial employees lined the backstage route to cheer us on. Now I want to go back and pick up that water cup I dropped.

Behind Mickey’s Toontown

Mickey’s Toontown backdrop

We came back onstage into Mickey’s Toontown and made our way through Fantasyland. Dumbo was running, appropriately. Of course, getting a picture running through the castle is one of the great shots everyone hopes to get, but I think after some couple decided to quite literally jump in front of me and mug for the race photographer’s camera I probably missed that opportunity.

We headed through Frontierland and then were backstage again .. I remember seeing what I assume is an employee commissary and Imagineering, as well as the back side of Indiana Jones.   We then came out into Downtown Disney for our final mile (or so).    A lot of the early finishers had made their way back here to cheer on those of us bringing up the rear, and with that motivation I did a bit more running along this last mile than I’d done for miles 4 and 5.    When I turned the corner past the ESPN Zone, I could see the finish line, and kept my slow jog going until I crossed the timing mat.

From the finish, we were herded through the finisher chutes where we picked up first our medals, then Dumbo wristbands for those racing again tomorrow, then water.   Race photographers were there to take pictures with the medals, the lines were a bit long but I felt it was worth the wait.   Then we picked up our runner refreshment boxes and were turned loose into the wild to reunite with family and friends.    I’m solo on this trip and while I know several other people who were running today, I hadn’t made any plans to meet up with them. So I decided that heading back to the hotel for a shower and some rest was the way to go … and then see what I felt like after that.

A few hours of rest and I made my way back to Disneyland, wearing my 10K race shirt and finisher’s medal.   I hadn’t checked out the photo ops available in Fantasy Faire before, so I thought this would be the perfect time.    I got pictures with Cinderella, Snow White, and Aurora, took in a few rides, and then decided to head back to the hotel again rather than spending more time on my feet.

10K Finisher’s Medal

10K Finisher’s Medal and ribbon

I’m very happy with today’s result — and more than a little worried about tomorrow’s.   It’s supposed to be cooler, but I have zero faith in the forecasters on that.   We are scheduled for an earlier start and that will also help with the heat and humidity.    I think I will again start by trying to do 20:40 intervals, although in the early going it’s quite likely there won’t be space enough to stick to any predetermined pattern.

Should be an interesting, and challenging, morning.   Looking forward to it!

Related articles
- Disneyland Half Marathon and 10k Courses Are Here! (lifelaugheatrun.wordpress.com)
- DDD Race Goals (prairieprincessrunners.wordpress.com)
August 31, 2013