Living Museum of Learning
The Easiest Cell
Yesterday, Ivy learned P5JS 3D shapes.
She built a WEBGL scene containing a box, sphere, cylinder, cone, and torus. She learned how translate() moves objects through 3D space, how rotateX(), rotateY(), and rotate() change their orientation, and how orbitControl() lets her look around the scene.
It was a world where the computer already knew how to draw the shapes.
Then we switched to her iOS Rubik's Cube project.
Here, the computer did not know what a Rubik's Cube cell looked like. Ivy had to construct it herself with UIBezierPath, coordinates, lines, and geometry.
The front face was already being drawn with fillSquare(). The challenge now was to work on the top and right faces, where the cells are no longer ordinary squares on the screen.
Ivy immediately noticed the difference.
"There is more calculation on the top or right face, right?"
"It'll be much more complicated than the front face," she said.
Instead of asking Ivy to solve the entire top face, I asked:
"Which cell do you think is the easiest?"
She looked at the cube and picked one.
"This one."
"Then we can start from this one."
We commented out the drawCube() call so she could see only the new geometry.
For this first piece, I told her she could hardcode the coordinates. We did not need a beautiful general solution yet. We needed one successful cell.
She gave the function a good name: fillTop.
We improved it slightly to fillTopCell.
Then the geometry began.
A triangle appeared.
Oops.
She adjusted the points.
Now there was an open parallelogram.
Close it.
Fill it.
Stroke it.
Bring drawCube() back.
The yellow cell appeared on the cube.
Oops again.
Two vertices of the yellow cell were too high.
But something important had already happened: despite the wrong height, the four points still formed a parallelogram. Ivy had captured part of the underlying geometry even before every coordinate was correct.
By the end of the class, she had a working fillTopCell() function and a real yellow cell integrated into the Rubik's Cube.
The first cell was small, but it changed the nature of the problem.
Ivy was no longer simply learning commands such as box(), sphere(), or rotateY().
She was beginning to see that a visual object can be built from a mathematical structure.
A cell is a set of vertices.
Vertices determine edges.
Edges determine a polygon.
A polygon can be filled.
And a collection of such polygons can become a face, while several faces can become a cube.
Even the expression
30 * sqrt(3)
was no longer just something mysterious appearing in code. It represented geometry.
More importantly, Ivy experienced the process of discovering that geometry through programming.
A difficult problem does not always need to be solved from the top down.
Sometimes the best first question is:
Which part is easiest?
Once one piece works, it becomes a laboratory.
We can inspect it.
Measure it.
Compare it with neighboring pieces.
Find the pattern.
Then generalize.
That is why hardcoding the first cell was not a step backward. It was a deliberate first step.
First make one thing work.
Then understand why it works.
Then turn the special case into a general rule.
The same habit will help Ivy far beyond a Rubik's Cube.
There is another lesson hidden in yesterday's mistakes.
A triangle, an open parallelogram, a filled cell, and two misplaced vertices are not failures to hide.
They are evidence.
Each wrong picture tells us something about the geometry encoded in the coordinates.
Programming becomes much more powerful when mistakes are treated as information rather than as interruptions.
And perhaps the most interesting transition of all happened between the two projects.
In P5JS, Ivy learned to manipulate ready-made 3D objects.
In Swift, she began learning how to construct the geometry behind an object.
One is learning to use shapes.
The other is learning to think in shapes.