Category: python

Before working out that validation idea, let's commit the good bits. Surprise Idea: The search for joy for everyone must never be abandoned.

Again with the weird hours! Elaborating an idea from a more civilized hour yesterday. Tout le monde déteste l’IA.

Weird hours again, but very interesting spike. Have a look! Tout le monde déteste l’IA.

Regrettably awake at 0445, I look for something to code. Tout le monde déteste l’IA.

I entertain myself by seeing how to improve the `bee` ContentFactory method. Tout le monde déteste l’IA.

As I dozed off, I had an Idea. We'll think about that and then find something to do. LLM note. Important(?) closing. Tout le monde déteste l’IA.

In a few more steps, let's provide some class methods, and the one-time-thru version of Sayer. Added P.S. Tout le monde déteste l’IA.

I was fiddling with the Denizen. I have a small need and a small idea. Small steps to nice outcome. Tout le monde déteste l’IA.

A small idea about the Denizen state machine. Tout le monde déteste l’IA.

I feel some tiny objects coming on. I plan to let them come. Tiny objects FTW.

Even working incrementally, I think it's too soon to be generalizing the Bee Denizen. Discuss, decide, do.

Working on Denizens seems interesting enough to keep me going. Let's see what we might do. Some discussion of how we generalize here chez Ron.

I'm tired of this program, or at least the work we've been doing. What might be more interesting? Definitely contains bees. Possibly important summary.

We need to get the boundary behavior right. This may mean I have to understand my code. Long, but rather nice.

A surprise requirement challenges me. They want the minimap changed substantially! Tout le monde déteste l’IA.

Shall we add more capability, or consolidate? I think we'll add. Callooh! Callay!! Tout le monde déteste l’IA.

Today, we'll decide if this is a Spike to be tossed, or a good enough base from which to proceed. Tout le monde déteste l’IA.

This morning I'll try to spike in a Section for the Scroller. I'll waste 90 minutes. This afternoon, I'll win! Tout le monde déteste l’IA.

Found an Arcade example that seems like just the thing. Tout le monde déteste l’IA.

Another cut at the mini-map. Tout le monde déteste l’IA. ... and yet ...

Let's try a spike for a mini-map. Not at all sure how to do it. Tout le monde déteste l’IA.

I do the wrong thing, then do the right thing. I tick myself off. I take a break. Tout le monde déteste l’IA.

The DungeonViewMaker seems to me not to be quite the thing. Let's do better. Tout le monde déteste l’IA.

I'd like to make the KeyPress code simpler. Here's something that works. Do we like it? Yes, but we don't love it. Tout le monde déteste l’IA.

Stepping is working. Let's make it more nearly right. I think an object is called for. Tout le monde déteste l’IA.

This morning, we'll try to put stepping into the dungeon creation. Tout le monde déteste l’IA.

Let's take some steps toward stepping visually through dungeon creation.

I had in mind to do some pleasant Making App additions to the program. I'm afraid that the code may not agree. Result: whining is never really wasted.

Having made my point about refactoring, I think we need a longer view ... and a longer view. Just some planning and a couple of pictures.

A tiny article about one tiny change. Some thoughts on whether it matters. Tout le monde déteste l’IA.

If we were to combine our formerly three now two sprite lists into one, would we lose some duplicated code?

The split between making the view and running it is working. Now we get to make it a bit more right. Result: quite pleased so far.

I'm just gonna go for it. If it works, I'll claim it, if not, there's always reset. It works! Wow!

This exercise has me hooked. I'm still engaged with getting DungeonView pared down until it looks ... much better. I'd say perfect, but there is no perfect: only better.

We'll remain on the quest to simplify DungeonView a bit longer. I did some things last night, and we'll do more this morning.

Let's move on_key_press out of DungeonView. Down to 146 lines, from 226 just a few commits ago.

If there was a feature I wanted, I'd do that. There isn't, so we'll look for some more small but significant improvements. Fiddling while Rome burns? Why not?

Looks like there are a couple of methods where our new Cameras object could help out.

... a simplification. At least one more instance variable should disappear. I wonder, though ...

I was watching Antiques Roadshow, as one does, when it came to me that a tiny object might be just the thing for DungeonView. Let's find out.

I've decided to commit this and refactor. Can always reset if I have to. General rule: try always to move forward.

OK, let's do the thing we love: find something to improve, and improve it. Shall we start where we left off? Result: Not as joyful as some days.

About programming. A few thoughts on what I do, and why I enjoy it so much.

Writing a note to ask for ideas, I got an idea. Let's see what happens with it. Result: I think it turns out nicely.

Received wisdom and personal experience tell me to cover built-in collections. Here's why.

Resource designation is awkward, and I think we're loading them multiple times. Let's see what we can do about this. Arcade helps out!

I have one. Very small but I think it'll make things just a bit nicer. We'll see.

I have an on-line meeting that I can pay only small attention to. Herewith, a report on whatever tiny changes I find.

Let's see if I can tire myself out with code. I enjoy crafting code and ain't no oligarch-feeding resource-consuming job-stealing computer program gonna take that away from me.

Let's see about removing those skulls from the path. Currently we just remove the sprites. This is more tricky than it might be.

We're on the hook for extending illumination, and we need some way to remove the Necrotic Path of Skulls.

Let's get back to work on displaying the path to things. We need a different Flooder setting for sure.

I have a bit of time where I can't concentrate deeply but can probably do some easy things. A new class reduces DungeonLayout.

We need to deal with the illumination issue in our breadcrumbs feature. Should be easy. Need to quell a rumor first.

OK, let's learn how to do the thing we already did. I plan to go in Very Small Steps. The morning's spike pays off, it seems to me.

I've thought of what may be a fun idea for the game. Let's talk about it, maybe do some of it. Spike written, thought about, tossed.

I need a little something to do. Here's something that could be done. Better code, not as easy to understand as it might be.

We'll glance at Flooder, to see if it needs any improvement (it surely well), then improve it. (Brief oblique cut at LLMs, oligarchs, etc.)

We need to improve Flooder, to allow constraining it to follow legitimate pathways. I am expecting it to be straightforward.

An upcoming feature demands a capability we don't have. Let's improve the Making App a bit. A good first step.

Knowing the fix, let's install it properly. Then maybe an idea.

Let's fix the defect. Bear bite costs me two hours.

No, a DEFECT, and a serious one. All hands on deck! Red Alert! OWOOGAH OWOOGAH!

With a reasonable design, reasonable changes are generally reasonably easy. So keep the design reasonable.

... if we can gin up something that's kind of fun. I have a simple idea that seems promising. Turns out to be Very Pleasing!

I see one more thing that needs doing. And then I propose that we have a little fun. What am I saying, programming IS fun for me. CW: Brief LLM excursion.

Let's figure out the new interaction feature, test, and do it. Success but with a reset and a general feeling of clumsiness.

We improve some code, reduce overall size and breadth of interfaces, make things better. CW: Brief LLM-"AI" remarks.

The recent refactoring around Layout and Cell gave me a very appealing idea. Let's discuss and quite likely try it."What kind of person wears Louboutins into a dungeon anyway?"

This afternoon I want to explore some alternative notions around the Cell topics raised this morning. Very promising results!

Speed report, and I noticed what looks like Feature Envy. Let's see where it leads. One serious mistake, quickly corrected. Very nice result. Some speculation.

We have a tricky problem ahead of us, but first: the tests are too slow. Nice result, very pleased.

Rested, I feel ready to do the passage-generating code. I'll TDD what I can. Maybe random seed will help.

I have a somewhat complex idea about passages, but a simpler scheme might work. Let's find out. Anticlimax: I stop just before the thrilling conclusion.

Some thoughts on how I work. It takes me a while to get there. If I got there. There must be an idea in here somewhere.

Some ideas about doors, and with luck, a bit more code.

With Content in good enough shape, I think doors can be next on the agenda. (I delete 235 lines from this article.)

A quick report on removing the old content objects in favor of the new. It goes quite well.

I think that the animated spikes are the last challenge for the new content scheme. Are we up to it? Let's find out.

I was going to say 'work', but this isn't work, it's fun. I continue to be pleased.

Not even that devious: this seems like a decent idea for the simplified Content. Decent progress.

I think we can do without the `info` object entirely. Let's find out. Bear takes a nibble but I think we're OK.

The new scheme for Content seems to be working out well. Remaining are two concerns ...

I think he's got it! We'll find out. Also: design documentation. Results: very favorable.

I think the new Content scheme isn't good enough. Planning to reset. Might save the tests.

This morning we made something work. Will it support everything we now need? Why didn't I ask that first?

With respect to Leonard Cohen, I want it simpler, not darker. Let's see what we can figure out. I am pleased.

I feel that I'm in a bit of a hole and still digging. Let's see how we might turn this around. We find ways to keep our oppressors off our backs.

I've made a notable change to PubSub, with more to come. Keyword arguments. Small apology for poor testing. We'll do better.

The new conditional-entry logic is clearly a hack. Let's provide a little improvement. Some thrashing. Method object. Satisfactory but not amazing.

While I'm in another world, let me muse about Content.

A few improvements, a bit of design thinking, and a plan takes shape. A good morning.

Let's give the spikes the ability to respond differently to control state, rather than the current fixed arrangement. Artisanal hand-crafted code, of course.

Still working on Lever-Spike connection. I was right not to panic yesterday, the snag wasn't a snag.

The spikes go up and down in the view. They need to react to a lever, and should also Deal Damage to Dot. We hit a snag, but do not panic.

Not the experimental kind, the stabby kind. Though there will surely be experimentation involved.

Let's add a Lever to our content objects. Herein, I make a prediction. Will I be correct? This one is darling, and I'm not going to kill it.

With the new event modifier, I think we can completely eliminate the button_pressed event.

I have in mind a caller-id feature for PubSub. Good time to do this, when users are few. Bears arrive unexpectedly.

I found a 1x1 transparent PNG. Let's use it for AppearingContent. A sweet little improvement.

I see opportunities for consolidation. Can we take advantage of them? Let's see. We change something unexpected. Is it too clever? Nahhh!

I think I'll try making the Button show up and down states. Sounds easy enough to spike something.

During a boring on-line meeting, I went ahead and put in the visibility logic. Let's see how things look now.

Dungeon content has aspects of model and aspects of view. Let's wrap it in a ContentView and then evolve to something more cohesive. Sort of Part I.

A few little changes to content this morning trigger some further improvement this afternoon. It's better than it was, and more capable too.

There's something not quite right about the design. Can we suss it out, or should we make it a bit worse? Lots of musing, very little code.

Sprites, yesterday and today. Refactoring the Content design, because Sprites.

PubSub could hold onto objects that should be dead. Two attempts and much fumbling later, I've learned a bit but have no solution that I like.

Amid horrendous technical difficulties, I propose to build a Strategy-based content item. In an astounding plot twist, we drop the Strategy idea!

Having chosen Strategy over Mixin, we'll get down to doing it for real.

I made some changes to the scaling of images. I'll report on that, but what I really want to do is to eliminate some duplication. I surprise myself.

The 'art' that I have for the game comes at various scales. We need some way to accommodate that. Outcome: OK, but there's a tiny telltale scent of corruption. Squidgy.

A couple of little changes from yesterday. Mostly just speculation, vague design thinking. I create an abstract class and draw an up-button.

Yesterday's idea for selecting random tiles seems tasty. Let's try it. Is it a kind of Composite Pattern? Answer: a firm 'kind of'.

I made one new texture last night, on my iPad. So I think I'll point the game to the recently-purchased set.

There is Massive Duplication in my texture-finding code. I plan to remove that. It goes rather nicely.

Today I propose to change the Border code to return a 'meaningful' string rather than those 0-15 integers. I figure I can handle something that tricky, probably.

We've agreed that our current borders scheme works, but isn't quite what we need. Let's see how to make some progress in how we make this dungeon. This pass, we prepare the soil.

Having 'done' borders, I'm learning what I want. 'Making App' vs 'Shipping App'. A bit of philosophy, a bit about why I write these words.

I have a bit of time this afternoon. Let's see what we might do about borders that would be better.

I found some of my favorite tiles and did an experiment yesterday. We have some interesting work ahead. We spike a border!

I have no idea what we might do this morning. I'm sure I'll have at least one notion quite soon. Things get a bit weird.

Let's deal with some of the PubSub issues and needs.

Things happen. People have to know about them. What shall we do about this?

A small improvement; a confession. I wind up thinking in public about how I live. CW: LLM-AI, Jesuitical

Based on a thing I did yesterday, I have an idea that I think will be quite nice. BorderedText, good yesterday and gratuitously better today.

I'm not sure what I'll do this morning. Look for something that interests me, I guess. We follow our nose. Refactoring for fun and profit.

We'll glance at the scrolling code, see what we can improve, and use it on our existing treasures.

Let's experiment with scrolling text. A bit of thrashing but a fairly decent object emerges.

We have a thin treasure/inventory capability wired in. Let's review our notes and pick something to add. We add visible treasures and console announcements with just a little code.

We have some content that is fixed throughout game play, and some that varies. We're getting close to needing to handle that. Perilously close.

I have a bit of time at the keyboard. Let's improve the dungeon contents code a bit.

Let's take a look at what might be good next steps toward a game. I'd like to get to some code today. A second personality emerges from my mind, the PDP.

This morning I'm going to put a Camera2D into my dungeon and see if I can figure out how to zoom and pan and such. I am hopeful but also expect confusion.

Let's see what we can figure out about the Arcade camera. I think we'll look at an example, and maybe bash it a bit to see what it does.

I think Arcade is in place. Do we like it? Is the code where we want it? What are our longer-term ideas?

I've added in Dot and it's clear we have work to do. Result: 1000X faster.

I think we'll take a cut at converting from pygame to Arcade today. I have a tentative idea, and I'm prepared to fail spectacularly.

Let's explore the Arcade platform, which we plan to use in our dungeon program. Here's how I like to learn a new system: by example.

That `make_lines` method is horrid. Let's continue cleaning things up a bit, starting there.

Are we close enough to having the right Border classes to try to draw them? Let's take a look at how we might do that.

We want to change border calculations to create a permanent structure. We proceed with a few very tiny objects. I think it goes quite well, though the article gets rather long.

I think about my code while writing it, and at other times. Here's what I think today.

Let's look around, see what we might do that might improve things.

Cleaning up Cell fixed a big design issue. Now we are left with a smaller one. We'll see what we can do about that.

We're engaged in a long series of small steps, moving capability from the Cell up to the classes that hold onto Cells. The good news: small steps can be done over a long period of time. Bad: it is often not very interesting. Did not use the word "gallimaufry". Could have.

We couldn't get in the straightforward way. Is there a more sneaky way to do this? Tiny steps, many commits, very tedious. One semi-interesting refactoring.

Cells know what room they are in. What will it take to undo this? The bear gets really close to taking a bite today.

Should we start to address the Horrendous Mess™, or do something else? Something else: work toward removing room knowledge from Cell.

A short session Friday, another Saturday, and we have Cell disconnected from it container. A triumph of small steps!

I just want to do a little more this afternoon. Can we move `at_offset` yet? Yes. Just one more use of `current` remains.

We are making a Horrendous Mess™, and we're glad of it.

Just for fun, let's see about moving `find_path` into DungeonLayout.

We'll begin the morning adjusting more tests to use the new Layout idea. This iterative incremental stuff? It really works! The Niagara Falls Method.

I've had an obvious but seemingly decent idea. Let's try it. Here's my cunning plan ...

What happens when right in the middle of things, what seems like a much better idea appears? Includes: musing on the balance between code quality and shipping.

None of my notes on cards appeal. Let's look at the code and see what it suggests. Sort of an odd result.

I'm not up for a lot today. Let's review those methods that can optionally return `None` and see what we can learn, maybe what we can do. Results: acceptable if not entirely satisfactory.

I was thinking this morning, while trying not to get up yet, about the programmer, the programmer's code, and their care. As to my recent defect, I really don't see what to do better. Yet.

I've been chasing a serious intermittent defect for five or six hours. This is almost unheard of, due largely to the way I work. But I finally figured it out. Brief comments on LLM-"AI"

Five or six hours of slogging here. Maybe scan, maybe just read 'Found It!'.

Today I think we'll see about using Flood directly, perhaps removing the convenience method on Cell, but adding some to Flood.

An exchange with Bill triggers some ideas for the flood. It's 0330 hours. Let's see what we can do.

The `flood` method is my current darling. Should we kill it? Is it just too cool to live? Let's examine it.

Today we start by actually finding furthest points. We need also to remove the path map code. The morning goes well: geek joy FTW!

I think the new generator is working well. Let's see if we can improve the way it's written. A very nice refactoring sequence, if I do say so myself. Thanks to Bill for the nudge.

Let's see what's up with that new generator. I think it's about 0.75 done.

A nudge from a friend impels what seems like a much better idea. But appearances deceive: it's more tricky than I thought. We build an interesting new capability.

We have a test that seems to compute what we want. Let's try to see where it should go, and put it there.

I've had what seems like a good idea. Let's find out.

We're working on finding a cell that is maximally distant from a given cell. What are our next steps?

Sometimes we focus on the application, sometimes on the making of the application. We begin with making.

I think ensure_connected can fail. Let's prove it, then fix it.

Having completed the basics of the contents vs layout design, it's time to look around and see what needs improvement.

The FGNO OGs gave me some good ideas about my design: thanks, OGs. This morning I'll start following some of those ideas. I use test doubles!

Today, we'll start populating our dungeon. We'll start with an intrepid adventurer named Dot.

This morning, I think we'll look at some code. As a start, I have a question about Room. Brief LLM-AI digression.

I did a little off-article cleaning of Cell. We'll look at that. And I have an idea which may be good, or then again, not. Weirdly, things go better than expected.

Yesterday's closing idea looks good to me. Let me know what you think, if you care to. We find that we're not quite finished. A serious lesson is relearned. LLM-AI diversion at end.

With our new path deviation operation working, it's time to look at the code and see if it's asking for anything. We end with a seriously questionable choice.

We need the validity check in PathHelper. And I see how to generalize it. Which should be first? Updated: found a test.

Let's see if we can make PathHelper less bad, perhaps even make it better.

We still get straight paths sometimes. I have an idea ...

We can make most of our paths wander, except for the straight left-right or up-down ones. I've had an idea. Is it a good one? I decide to use a prior idea, in an interesting spike.

When last we met, we had just discovered a nice way to make a wiggly path. Since then, I've improved the code a bit. We'll look at that and then see what we see.

Our minimal paths are too straight for most purposes. Is there a nice way to make them adjustably not so good? Is 'adjustably` a word? It is now. A nice discovery arises.

Yesterday at session end, I tried to hack in a minimal-path idea. Failed. Today let's try to fail better.

It is certainly no surprise that the day after something first works, there is plenty of room for improvement. We'll be looking for some of those things this morning. We learn from a small step.

Let's finish up the path between suites and see what it looks like. I suspect we'll want to try to tune it.

Nothing deep here, I mean a path in the dungeon, not a way of life.

We are working toward making dungeon description easier. I think of it as creating a little language. Today, adding randomness, if my luck holds. It holds, and we belay the whole plan.

Well, dungeon CREATION. We'll start with a little refactoring. I remember why I recommend testing bug fixes.

Making a dungeon seems generally to require looping and even conditionals. Do we want special support for those?

Suppose we wanted to create many different kinds of maps. How might we make it easier?

We sometimes get rooms within rooms by accident. Let's see if we can do it on purpose.

FGNO had some ideas. I'm not ready to work on holes. What about paths? A weird solution emerges.

The new jaggy room shapes sometimes include holes. Makes me think about secret rooms. And, not unrelatedly, about paths. Just thinking, and an interesting experiment.

Now that we can have as many room shapes as we can imagine, let's imagine some. The results may surprise you. They surprised me, in a good way.

I veer into philosophy and LLM/AI, based on thinking about many small changes, and how they add to understanding.

I had a few moments and decided to do a round room. At which point I realized that something can be improved.

A common but rookie mistake needs fixing. Using the same RoomMaker to make multiple rooms engenders chaos. Today, as often happens, I don't do what I thought I might.

I have a bit of time and a bit of energy. Let's scavenge Room to make a RoomFactory.

Yesterday's work has been taken as an experiment in having different room shapes, via different room builders. today, Let's get started on the real thing. I have some ideas. That's never a good sign.

FGNO Wants Better Shapes. We do an inadvertent spike. Along the way we discover an issue in generate, and learn the difference between a square and a circle. A superior day!

Recording some small changes.

With a little help from my friends, I set out to smooth some rough edges. Lots of small things. Nothing to see here, aside from one excellent name change. A metaphor issue discussed at the end.

The PathFinder code now uses Cell.generate, but there are signs that make us wonder.

PathFinder uses `generate`. But there's work to be done. And let's talk about generalizing `generate`.

Now let's see if PathFinder can benefit from the new `generate` method on Cell. Saturday: absolute debacle. Sunday: perfect.

Let's look into a suggestion from @blackoverflow. Turns out to be a good idea needing a little improvement. (Minor edit, courtesy @blackoverflow.)

Our cell generator looks pretty good. Let's test it on a copy of our suite test, then see how to put it in play.

I think a generator might be an interesting way to do this flooding thing. Let's see if we can gin one up. And we can!!

Let's see if we can make our SuiteFinder object more expressive. Arguably, it needs it. Arguably, we'll go too far. Too far? We went hog-wild!

What we need here, I reckon, is Method Object. Let's try it. Oddly enough, that's actually what happens. There might be something better still ...

We continue the prior article's session in a new article but same session, refactoring another bit of code that could use a little improvement.

This code isn't very good. I'll tell you why, and we'll try to do something about it.

We'll start with a review of existing code, possibly clean up the border logic a bit. But we'll at least start thinking about "continents" and paths between them.

I think I'm ready to draw smarter borders. I have chunks of a plan. Green shoes.

Thinking about how we could detect rooms that are adjacent. Warning: contains Philosophy of Programming as this old guy does it.

My design fantasies and experiments need to stop. Let's do the periphery feature. I have an idea. Results are satisfactory.

Let's look around, get aligned, decide what to do, then do it. Well, we do a little, but not much. Have I learned anything? PSA: Eat the rich!

Let's try a different approach this afternoon. I have a good feeling about this one. Things go fairly well, but not fantastically well.

Yesterday's experiment successfully showed me that I had a terrible idea. Today ... a similar success!

I think I'll experiment with a kind of cell that has x and y but really only as data for display, using just neighbors to show relationships. This may get weird. Experiment succeeds: Not a good idea.

It feels as if my objects aren't helping enough. It's important to recognize that feeling and see what can be done about it. Think, speculate, sleep on it, try something.

Starting the game seems too slow. How much? Why? Measure. Measure better. Think. Realize something. Plus: help from a new friend.

OK, we made the change easier. Now can we do the change? Yes! Slow is smooth: smooth is fast.

Let's see if we can do this with good testing and really small steps. It could happen.

Some small refactoring steps, very small. One rollback, no idea what happened.

I want to complete the path finding, and I think some of these objects would appreciate being better designed. Includes: a Great Lie wasn't ... this time.

I feel sure that I know just what to do next with paths, but I'm not sure how to test it in a reasonable fashion. Results: Happy!

For a program with no point, there sure are a lot of interesting things we might do. I'll try to make these articles more useful.

While I like the new bordered look, I still don't like the rooms all packed together. I have an easy idea that comes with a puzzle.

Drawing a room looks good. Let's generate a whole space of them and see how the map looks. An interesting drawing, and a small curious effect.

Drawing a room looks good. Let's generate a whole space of them and see how the map looks. We'll want some design improvement along the way.

We're drawing a grid. Let's try drawing a room.

I want to be able to see what the rooms look like, so I guess it's time to bring in PyGame and get something displaying on the screen. I plan to cheat. Good result!

I guess I'll set up an approval test with a random seed. Then see if we can create a better test.

Still nerd-sniped by dungeon allocation, I begin to get a sense of an approach. Let's see what happens. Python fits my hand. What's your preference?

GeePaw Hill is undertaking a dungeon sort of thing, in Kotlin, using a very interesting room allocation scheme. So I was thinking, what if ...

I stole borrowed adapted reused code for FGNO. Let's review it. CW: Live, dead, LLMs are not your friend.

Further fun with Celtic Knots. Still no code. Is this the dreaded BUFD??

I'm sort of burned out on linkages. A confluence of coincidental occurrences has me entertaining myself with Celtic Knots. Is there programming to be found here?

The ArcRod from yesterday defines the center and one end of a longer rod in 'real life'. I propose what would be called a hack if we did something like it in code. I stumble, but recover. Small steps FTW.

Past time to get back to the linkage. I'm glad I'm not on a deadline—other than the big one—and I don't know when that is. Anyway, let's add a link or two. Result: WOOT!

Studying the Walschaerts linkage, I think I see a path that my scheme can support. So let's see if we can inch into it.

Upcoming Components challenge us. XP has design thinking. Names are dropped. Brief descent to politics. Cute Video.

Bell Crank is kind of an inflection point. Let's see what we should do next.

Time for a new component, the bell crank. Not your regular crank, no, but a bell crank.

Maybe tables would be a useful way to express a linkage.

I've come up with a better way. At least I think it is. Herewith, a report. Green shoes.

We need an easier way to define a Linkage.

Give me an "AI" that cleans the bathroom and leave me to my art.

Log for the Record. Crash and burn. Read only if you want to see me confused.

There are two possible solutions for the ArcRod's position. We need to specify which one we want. Result promising but I'm sent back to the drawing board.

Tests notwithstanding, there's both satisfaction and discovery in animating the linkage. So let's do. (It works!!)

As much as I'd like to futz with the drawing code, I think it's time to continue work on the ArcRod. I'm goin' in!

Why, only yesterday, I thought I had made a mistake. Turns out I was wrong, I hadn't made a mistake after all!

Starting late today, might end early. Let's see if there are right-sized things to do. Good thinking, but the work does not go as I anticipated.

Today we do a very nice step by step refactoring to a Method Object. Quite pleasing, really. Yummy.

Long ago, Kent Beck described 'simple code' with four rules. One of them was about expressing ideas in code.

I'm making a small improvement to the ArcRod. I have a good reason for doing it, if I'm not mistaken. Then some renames, possibly improving things.

The upcoming component needs DESIGN. I hate when that happens. Let's talk about this. Something special happens!

I thought I might have done something, well, pretty silly. That particular concern turns out not to be the case.

Offline, I improved the Linkage collection rather nicely. Now we need a bit more improvement. Seems to be a pattern.

Am I losing my edge, if I ever had an edge? I realized something interesting about the evolving design. I decide my edge is no more dull than usual.

During my morning prep for being found alive again, I recognized an issue with my lovely new scheme. How troubling is it?

We need lots of small steps to unwind the previous design while moving toward the scheme of doing everything without reference to parent. It goes ... OK.

Moving toward everything running on `start` / `finish`, I think we need a place to stand. And not on a wheel. HOWEVER: Plan Dashed Immediately.

We reviewed the linkage program a bit at FGNO on Tuesday night. Some thoughts arose. My big lesson: Shut up and listen.

One nice thing about gentle refactoring is that often we get ideas for how to make things better. Today ...

One nice thing about gentle refactoring is that often we get ideas for how to make things better. Today ...

Let's carry on with changing the API of these classes. Where were we?

Let's see what else we can improve in our four existing components. I can name some things that I'd like to improve.

With four components in place, let's look at the code and see how it can be improved.

Let's do a simple piston this morning. I am hopeful that it'll be easy.

I'm very confident that our connecting rod is working properly. The code could use a little improvement.

Presumably, I "just" have to plug this function into a class and I should be good to go. We'll see. (Hmm, seems to have gone smoothly. What am I missing?)

One might think that what just happened was bad. In fact, I was recently reminded that it was quite normal.

In which, your intrepid author parameterizes a test. P.S. But not enough! But a quick patch saves me.

Time to start on the rotation part of this idea.

Let's keep inching forward, supported by careful tests. I want to get this thing right.

This is why I drew the pictures, but I am still Very Disappointed to find defects in my ConRod. Further disappointment follows.

I'm psyched to add another linkage component, but there are some issues in the code that could use improvement. What should we do?

So Canvas thinks scaling means actually changing where my objects are and how large they are. That seems like a problem. What if I were to scale down and back up?

Nerd-Sniped. Just for fun: locomotives?

Notes on setting up a new project in PyCharm. I forget between projects.

A small aspect of the game "nonograms" captures my attention. Darn it, I was trying to contaminate others, not myself! Also Anti-nerd-sniped.

Despite success coming up to speed on sockets, I'm not having fun. What to do? Resist fascism!

I think the bowling nerd sniping virus has worn off, so I suppose I have to look at the Robot World socket stuff again. Here's how I learn code I'm not familiar with. Resist fascism!

Let's take a quick look at our bowling scoring state machine. Just because. We find some nice improvements in this 'done' program. Also: Resist fascism, and take care of one another!

Duplication removal FTW. Also: Resist fascism, and take care of one another!

We're going to do the marks yet again! Why do I do this? And: a digression on "AI", and a very nice refactoring sequence. Also: Resist fascism, and take care of one another!

I think today we can do some work on the 'marks'. Also: Resist fascism, and take care of one another!

The One Machine to Rule Them All is going well. Today let's test total score and the small box values, if we get that far. Also: Resist fascism, and take care of one another!

... to rule them all. I thought this was too hard Now I think it's just right. Which is it? [Man bites bear!] Also: Resist fascism, and take care of one another!

I've been thinking about the second roll and I think I have a plan. Also: Resist fascism, and take care of one another!

FGNO discussion and yesterday's interruption cause me to start over. It's going well. Also: Resist fascism, and take care of one another!

Yes, actually. I've thought of a way to solve bowling scoring that is unlike any way I've done it before. Gotta try it. Sudden stop, see next article. Also: Resist fascism, and take care of one another.

I don't like the match-case code for the small boxes, although it works. The code that I had before was more likeable but incorrect in some details. What shall I do? I like today's result! Also: Resist fascism, and take care of one another.

Match-case for 10th frame seems too tricky. A state machine idea is gumption-trapped by a dash where there should be an underbar. Also: Resist fascism, and take care of one another.

I do not like the code that fills the small boxes. I have the time, and I'm going to keep trying. We get some good results. Not done yet. Also: Resist fascism, and take care of one another.

Scoring details aren't quite right. Long, tedious, more correct results, but I don't like the code much. Bear got a taste of me. Also: Resist fascism, and take care of one another.

I have a few moments at the code face, and see a couple of possible improvements. Also: Resist fascism, and take care of one another.

Musing on the process of making messy code habitable. Yes, refactoring has risks. So has messy code. Also: Resist fascism, and take care of one another.

Last night was FGNO. We spoke at length about this simple exercise. Herewith, some observations. Chet's blackmail plan thwarted. Also: Resist fascism, and take care of one another.

I can squeeze in one more session before tonight's demo. Can I add in two features and improve the code? Also: Resist fascism, and take care of one another.

Tonight is demo night. I need to be ready. We learn why we should never hurry: The Demo Is A Lie! Also: Resist fascism, and take care of one another.

An imaginary chat with my imaginary customer tells us what our next few steps need to do. Also: Resist fascism, and take care of one another.

Our weekly meeting last week spawned a new twist on an old problem: bowling. Also: Love one another.

Let's look at what we have, see how it can be improved, and decide what's next. Some nice refactoring. Also: Love one another.

Let's use the message length to decide when to respond. I think we can make this happen. Also: Love one another.

I'm glad I decided to take a break, because I have some smaller steps in mind today that I didn't have yesterday. Also: Love one another.

I've decided to start from a simple server from Real Python, and to evolve to something that makes sense to me. I have high hopes for this approach. Also: Love one another.

I'm inching toward a World server that I can drive from Python, Forth, or any language. Why is this taking so long? Also: Love one another.

An interesting video led me to try the speaker's idea for Game of Life. That led me to a very strange thought. And I'm not even stoned. Also: Love one another.

I added quite a few words, and found some issues. But we also need some big features. How shall we proceed? Also: Love one another.

We have a little game loop running, and it gets keyboard lines and echos them. Should we integrate something into the loop? If so, what? Also: Love one another.

Our little typing spike leads me to some design thinking. Spikes often unblock the thought paths, and that happens today. Also a few lines of code and a much improved 'UI'. #StopTheCoup!

OK, I'll do the PyGame text pane. It seems to be the simplest thing that could possibly work Unfortunately, it's more than one small step. #StopTheCoup!

I know what I would like to accomplish next. If there's a way to do it, I can't find it. I need help, or a change in direction, or both. #StopTheCoup!

I feel that I've shown that I can program A Forth, but I don't really know how to program IN Forth. Time to begin to learn. #StopTheCoup!

#StopTheCoup! We need a FileProvider to feed us tokens from files. And we need file names, I suppose ...

#StopTheCoup! Let's go after those skipped tests. I think they just need recasting. All goes pretty well!

#StopTheCoup! We're working toward an INCLUDE word to read Forth from a file, where we'd save the definitions for whatever app we're writing. I think we need an inversion of control.

#StopTheCoup! Some thoughts on using compiled words for things like looping. Our next priority is loading definitions from files. How might we do that?

#ElonaldDelendaEst! Let's review the conditionals and looping. Let's think about what seems to happen when we do as we do. Let's think about more Forth and less Python.

#ElonaldDelendaEst! One pair of looping words is now using our new CompileInfo compile stack protocol. There is one more looping construct that needs attention. We create and remove duplication, making the program simpler.

#ElonaldDelendaEst! Applying 0BR, BR, and the new CompileInfo protocol in conditionals has resulted in simpler and more consistent code. Let's take a look at loops. BEGIN-UNTIL goes nicely. Just one small misstep.

#ElonaldDelendaEst! How do we add simplicity? By removing duplication and redundancy, and occasionally by generalizing specifics. Sometimes it takes a few tries.

#ElonaldDelendaEst! Now that CASE is stable, let's use what we learned elsewhere. I think we'll simplify things a bit.

#ElonaldDelendaEst! I test some CASE results. Looks good!

#ElonaldDelendaEst! Continuing the implementation of CASE-ENDCASE. I think we need to do the case-sys, collect the branch points, and fill them in. I believe we have nearly-right mechanisms in OF-ENDOF, and we'll use those and make them more right.

Our CASE-ENDCASE only needs its branches hooked up to work, I believe. I'd like to find a simple test for the actual branching words.

A few words with GeePaw lead me to envision an even simpler Collator. Let's see. (Very smooth refactoring to a different, possibly better version.)

It turns out that a bit more study would have shown me that I already did a trivial Sys object and put it in play. Let's normalize that and then move a bit forward. A small surprise, and a bit of improvement.

If I recall correctly, it's time to start patching branch locations in CASE. Let's see how we might do that. We get a really nice start, despite nearly a week of forgetting everything we knew.

It is a fundamental premise of my work that we can (nearly?) always refactor from a design that no longer serves to one that is better. Can I refactor from my previous OK Collator design to yesterday's most excellent one? Let's find out.

Third time's a charm, they say. New idea feels very good. Woot! It is!

Just a few small refinements, because I was sitting here anyway.

The new Collator seems very nice by my standards. Let's make it even better. 🎉 🎊 🍾 🥂

Yesterday's "diversion" wasn't a debacle, quite. The code solution is OK, but the development process not so much. Let's try again. Outcome: Redeemed! This is up to my standards!

Continuing Diversion. It's working. I am not proud of what it is nor of what I've done. We can improve what it is.

Continuing Diversion. It's just too long!

GeePaw Hill has proposed a little problem, and he'd like to see how some of us solve it. Here we go! Outcome: I get a nice solution, much as I imagined, but my process was quite poor. Weird.

I'm going to try some further work on CASE, keeping it simple. Just pushing it forward a bit, if I can. I think we get a nice increment. Odd approach to testing.

Today I plan to actually begin the coding of the CASE-Of-ENDOF-ENDCASE phrases. And I have a glimmer of a better way to do it. Will the glimmer become light ... or darkness? Wisely, for once, I stop while I'm ahead.

Let's start thinking about CASE-ENDCASE. Thinking seems important right about now.

Reader Laurent points out a problem. I was going to fix it today, by accident. Let's do it on purpose. And maybe we can get down to cases.

I'm not sure what to do next. I'll reflect on some ideas exchanged with GeePaw Hill and then pick something, probably something easy.

I'll begin the morning with a bit of 'design thinking' about how we might interface our Forth to a bunch of robots. During that we find and fix a bug! Er, defect.

I have a little time. Let's see what we can do. Many tiny changes produce improved code. Who knew? (We did!)

It is literally oh-dark-thirty, and I am awake. Time to work on Forth. Is there a larger lesson? Yes, I think so. Things go well!

FGNO observations suggest a radical change to my 'Forth' spec, which should improve the supporting design. We FAFO a bit. Looks good. No great strides.

I have at least two more things to do before this thing is even good for its initial purpose. And I have what I think might be an interesting idea. Kind of a ragged morning.

I think yesterday's experiment with a pure interpreter has told us enough to decide not to do it. We'll discuss that, what it implies about experiments, and then look at next steps. Result: We have REPL!

I did an evil thing last night. It is tempting me toward a hard right turn. Must think about this. After too long, I realize that I was distracted by the shiny thing and didn't see its fangs.

Yesterday's pleasant discovery suggests that reducing our two word classes to one should be easy. Then, if it works as I expect, we'll talk about woulda coulda shoulda.

I'm interested in reducing my two classes, Primary and SecondaryWord to a single object that will feel more like a classical Forth word. This will require some thinking and doubtless some experimentation. Result: I am pleasantly gobsmacked!

At this writing I lack a feeling of direction. I'll muse briefly on the causes of that feeling, then try to find something interesting to do. We explore, change a few things, get a few ideas, then wander off. Pride in our work.

I've been busy programming in another universe, and fretting on this one's decline. It's time to get back into this Forth diversion from the Robot World, itself a diversion from something or other. Brief reflection on the olden days.

Well, our creation of Heap yesterday went smoothly, but it was all we did. Let's review the Forth code a bit more and see what it might be wishing for.

Now that CREATE-DOES> works, and I am reasonably confident that I have it right, let's review the code and check out the concerns left open last time. A perfect morning. (Added: P.S.

This time it's going to work, I'm sure of it. I promise not to change the title, or the blurb up to the next period if it doesn't. (Results: As predicted! Out of the park! Yay, team!)

I come before you today armed with information, if not knowledge. We'll try some small steps toward what I think I somewhat understand.

I fully expect to fail this morning: I don't see how to do what I need to do. I'll try to fail in a way that sets me up for a win sometime soon. Result: Bah!

I just deleted this morning's entire article. On purpose. Here's why.

I think we'll do variables and constants today. I also feel a pivot coming on. Unless I'm just hungry.

Interesting though compiled immediate words might be, I decide that variables are more important. I experiment with a somewhat smart heap and then, suddenly, realize how much we can do with a very rudimentary heap. I think we're onto something good!

If we're to be able to define compiler words with colon definitions, we'll need better access to the word under construction. I see options, vaguely. And I need information. Design musing here, little more. TL;DR may apply. We have an amazing interlude. We end with a Dangerously Clever Idea.

After this morning's somewhat lackluster performance, I do a bit of off-line refactoring and now I think we'll do a Lexicon. Can't hurt, might help.

There's refactoring to be done, including, possibly, some Big Changes. What shall we do? How shall we proceed? (Results: Two small steps; much confusion.)

My "friends" have well and truly nerd-sniped me. We're going to digress to look at Forth's tiny primitives that can be used to build words like IF-ELSE-THEN and such. Spoiler: A lot of thinking, and then a tiny but significant SUCCESS!

I've come up with an interesting possibility for reducing method clutter. Let's see what we think. (We think we like it!)

And so, Forth. Here chez Ron, it's another morning with Python and Forth. Some new year wishes within. Read on. (Spoiler: As often happens, things do not unfold as I anticipated. No worries.)

Unless I am mistaken, which is often the case, this morning's refactoring is going to be fine, F-I-N-E FINE. And I do not mean the meme, I mean really fine.

I think our little Forth is working as so far intended. Let's improve the code. Some thought on the original Forth(s).

I think I see, vaguely, what needs to be done to get our Forth to accept any Forth string and execute it. I am hopeful, if not entirely confident. Spoiler: It works!!!

We need to change our little Forth so that it can 'compile' and execute any Forth code, not just compile definitions. I'm expecting trouble and will regroup in that case. Results: I do a little refactoring and decide to regroup.

I think I'll invent the famous Forth return stack and use it to create a new looping kind of thing. Curiously that's almost exactly what actually happens. I even do R> and >R, and then don't use them.

Some Forth planning, and then, I write a POWER word that is hard to understand, and that could have been a trivial primary. Plus Forth comments, because POWER really needs them.

Today is my birthday. To celebrate, I think we'll implement DO-UNTIL.

Today, before the celebration begins, we'll do ELSE. Then we refactor the code. It takes me three tries to get code that I like. Long article, mostly just pasted and re-pasted code with small changes. Unwrap when ready, if you celebrate in a truly odd fashion by reading this.

With any luck, we'll do THEN today, which will make IF-THEN work. But first, some feedback led me to a very interesting site.

OK, after those nice improvements, let's get started on IF-THEN. Really. We complete *IF with a few lines of code.

Today I believe we'll actually get IF-THEN working. But first, I want to mention an odd thinking mistake that I made. (Result: Good changes, no work on IF. Yet.)

I haven't forgotten about IF. It's just that tests would be a lot easier if I had literal numbers. This goes really well.

The main story is still IF. Ron has what may be a good idea. We'll divert for literals. Lots of thinking written down here. A bit of code; a bit of success.

Ready for the next step in implementing IF-THEN. Is this a debacle, or a successful spike? Very long. Somewhat confused.

Our next story is IF-THEN. How might we do this pair of Words? Triple, if you count ELSE.

I've made some improvements. And I have a concern. Longish article, probably a quick read.

I read about how IF works according to Loeliger. Weird. How should we do it?

We need many things in our little Forth thing. Let's try to get clear on what we're doing here, and what we're not. Bad forth code slows me down. But we're doing OK.

Our first experiments went well. Let's start an implementation that's more like the kind of code we like to write. [Result: I am delighted!] (Also lambdas!)

A bit of reading and thinking is beginning to give me a sense of direction. Let's talk about it, and maybe implement a little something. This is how I work: read, think, code, rinse, repeat.

With a little help from my friends, I begin to reach some clarity on what this idea is and is not, and on why Forth has a 'compiler'. HYPOTENUSE! Gesundheit!

Still very early days for the Forth idea. I'll report on what I've been reading, muse a bit, perhaps try some code, if I can think of anything I want to learn. Progress!

I'm going to take a hard right turn and see about giving the game a 'scripting language'. I am proposing a Forth dialect. This could get weird. (Oops, it's Forth not FORTH. Sorry, Chuck.)

It would be nice if we didn't have to duplicate message strings in the code and tests. We're not going to internationalize, but something better than copying the strings would be good.

There is something I truly dislike about the current request protocol. Speaking of messages, should they be better organized? (Yes)

Let's review our new action handling and see what needs improvement. We rename around a dozen or fewer things. Was it worth it? Toot me up and tell me.

Why do I do this? Joy, pure and simple. The sheer pleasure of doing something well, or at least better. Long article, but should be mostly scannable. We begin and end wishing you joy.

Let's try that possibly better idea. I think we can do it step by step, in a strangler kind of style. I think it's going to work out!

After yesterday's debacle minor hiccup, let's continue to do a bit of error handling. We do some good stuff and perhaps have a better idea.

I was just going to make a small change, and tests are failing. How did this happen?

How much does the way I work apply to Real Work? What is the future of the Bots World? And let's improve the messages a bit.

I'm still slightly troubled by the `messages` and `used_ids` attributes of World. Is Method Object our solution? Or is this already a Method Object? Hey! This stuff actually works!

I think I see a better way to express the World's handling of actions. Let's find out if I'm right.

We'll start with some more error handling. Where we'll go, no one knows.

"I am the cat who codes by himself, and all mornings are alike to me." Mostly, anyway. Well, similar.

We'll take a look at some small changes to improve the World class. If only we could refactor the Real World so easily. Maybe we can?

We'll continue on our quest to do better Python. Today, we will try a match/case using a dictionary. It might make for better parsing of the tiny language that Bots and World share.

I've had an uneasy feeling about the project. A kind reader suggested a book. The book suggests what my concern should be. In a long article I express concerns ... and alleviate them a bit!

Bot's behavior is pretty cohesive now. But its member variables vary variously. Should we improve that? Once again we almost work on that ... and then something else comes up.

Bot is not as cohesive as it could be. I plan to change it. To make the change easy, a lot of small steps remove about 40 percent of the class. Nice, but it did make the article kind of long.

We set out to do a little code review, maybe some light refactoring. We get a surprise, thinking something is broken. It isn't. We learn descriptors a bit better. We discover questionable code, no surprise there. We improve. We see more for next time. Standard day in every way.

Having abandoned the decorator thread for now, I propose to test-drive a forwarding mechanism based on descriptors. It goes quite nicely.

I found a very strong series of articles about Decorators. They make a good case that I'm doing them wrong. What do we think about that? We change direction.

The next step with Python decorators is a class-based decorator. As usual I'll take a quick look at things on the Web and then go my own way. Results are 'interesting': I need more reading, and what I've learned is captured in a test.

I'd like to learn a bit more about creating class decorators, using decorator classes. We'll write some more tests, and perhaps find some additional useful references. Fun! Learned something!

The votes are still out regarding whether my `__getattr__` forwarding is too clever or not. This morning, I'll at least do a little learning about class decorators in Python. Language Preferences. Fun. Trouble. Learning styles.

Something about the Bot class bugs me. Python must have a good way to do this. (We find a way. Is it good?)

Today we'll address the need to provide details for Bots to be created. We'll use a callback: it seems sensible to me.

What shall we do today, Brain? Same as every day, Pinkie. Try to improve the world.

We'll look at the list of things to work on, but yesterday's experience has sort of set me back on my heels.

The top of our list needs attention. A small concern leads to much better code. Ron talks himself out of something. Comments are clues.

We'll check our list again, to see what might be fun to do. I did get a glimmer of an idea that I'd like to explore.

We'll review our list and pick some steps toward our overall goals. We might even remind ourselves what those goals are. Or we might trust that we'll find our way.

We'll pick a next chunk of our new message format and put in in place. Will we get clear to the end? Probably not yet. Also: Pyto on the iPad.

Before taking our new message format forward, let's think about how we almost missed the improvement. "It's dangerous to go alone. Take this."

A wild idea has appeared! This one's so nice I rolled out of bed early to work on it.

Our message format between Bot and World is a naked JSON structure. That makes sense for messaging, but I don't like it for processing. I have an idea that I think will help.

The present state of the code leads me to think about its evolution, and in particular, whether evolving it as I did led to substantial 'wastage' in code or tests. The answer may not surprise you!

To entertain myself, I coded a new RequestBuilder object, much like the InputBuilder, but building a dictionary-list composite like the requests expect. Results were good. Herewith, my report, not contemporaneous.

Setting out to review the code, I discover my old InputBuilder experiment. I go one way then, the other, then back. An actual revert of a commit. No new code, but some useful thinking.

How can I possibly think and write about programming today? How can I possibly allow myself to think about anything else? More toward client-server.

The reason for setting myself this public 2X20 challenge isn't so that I can be embarrassed in front of everyone. It's because I need more practice on small steps. The downside of thinking one is particularly smart. Results: Good, but by the skin of my teeth.

I've challenged myself to work in small steps, supported by tests, integrating new code as soon as I can manage it. I think I see a path. Spoiler: Works very nicely! Lesson: Need less tension, not more!

Some thoughts on choosing small steps. I think it's always possible. Is it always the right way to go? I issue a challenge to myself.

Not a high school, no, just getting ready for client/server in our World. Much design thinking, just a bit of code, a small step in what seems like a decent direction.

I've learned a bit about C/S. Should we apply it to our Robot World? It's about Joy, dammit!

OK, I promised to test reading, and I'm gonna do it. I sort of have a plan.

I am questioning whether I need all this rigmarole, and whether I owe you some further testing of this "legacy" overly complicated Message Class. Just thinking today, code browsing, no changes.

Working to get this tutorial under test, we do a simple refactoring, so that we can test something in isolation. Trivial in this case, but a useful technique worth remembering and practicing. A wild rabbit appears!

A first quick start at some tests may help me get off the dime here. Can I trick myself?

I've reviewed the full app server example from RealPython. Rather than just run it here and work through the details of its operation, I want to get it under test. This promises to be ... interesting.

A brief report on study and what I learned, then a look at the server side. Where is the bright side? I'd like to look at that sometimes.

Today I plan to try to run and understand the second example in the RealPython tutorial. See how an old man learns about unfamiliar code.

It's time to bite the bullet, lightly, and do some real client-server experimentation. I started last night, on my iPad. Aside from that and a bit of reading, I am entirely ignorant about sockets. Let's fix that a bit.

I believe that the client-side code includes a Block class. I further believe that we have no use for it. Even further, I suspect there are tests that use it, which should not. Let's sort this out. Simple changes, nothing to see here. Refactoring works.

It almost seems like I can't work on the code unless I'm typing an article. I guess I just don't want you to miss anything interesting that might happen. No promises, mind you.

I said I'd spare you the tedium of improving the tests, but you deserve to see what kind of improvements I'm making. I do not know what sins make you deserving of that, but you can examine your own consciences.

The Knowledge class and its usage have something to teach us, I think. There are issues here that aren't uncommon. Perhaps some changes will spark ideas. Theme: battling entropy, battling chaos.

We'll take a look at the NewKnowledge prototype, but I think I'm going to go with it. No one here to talk me out of it, and I think the result will be much less cluttered. TL;DR: Not worth it. Fun, though.

I have an idea for that Knowledge class. Let's see if it Just Might Work.`

Let's take a look at the code today, looking for things that do 'spark joy' and things that don't. Intuition. Pattern recognition. Joy.

We should try to get our new WorldInput stuff into play pretty soon. But let's look around and see what comes to mind.

Let's see what additional tests and capability we need in our new little batch mode objects. What were yesterday's notions?

In client-server mode, I believe that the program will want to accept a batch of commands from a client, process them all, and return a batch result. We'll discuss briefly why, and then see about doing that.

Still on the quest of separating server things from client things, in small steps. I think we're down to just one issue, the item a Bot might be holding. We discuss refactoring vs rewriting.

OK, I forgot that World references Block class. That's why we read the code before estimating, if we must estimate. Let's break that connection. Result: small progress, but Bear Bites Man.

The demo went well. Someone spotted a dangling thread of connection between server and client. Let's fix that.

It's Tuesday, so tonight is Friday Geeks Night Out. I want to demo something new. Can I get it ready this morning? Surprisingly, yes I can!

The WorldEntity only supports Bots so far. It needs to support Blocks, and whatever other items our world might one day contain. We need a type designation. We run into just a bit of trouble. Long article, nothing to see here.

We consider things to do, pick what seems most urgent, deal with it. We have a decent discussion of estimation, planning, how to know if you're slowing down, and what to do if you are.

I'm really sure we'll get the WorldEntity at least built and tested, and very likely put into play. Or my name's not Bonzo Calrissian. A long road but a simple one. One skipped test and had to update the demo.

Armed with a bit less ignorance we'll try to create and use a new world-side entity. I have ... ideas. Result: This is why story estimation is so fraught.

No, not the fish. An idea about flavors of Blocks. Exploration, Spike, Rollback. Just fine.

We've had good luck with `take` and `drop`. Let's see if Map would like to help World with the `step` method. Some nice improvements ... and a GitGlitch.

In writing, folx refer to Plotters, who plan out the story in advance, and Pantsers, who "fly by the seat of their pants". Which am I? Which are you?

We are told that Colin Chapman used to say "Simplify, then add lightness". Can we do that today?

We have one known thing to work on. Some things to put on the list. And let's see what the code wants.

With World using a separate Bot instance, separate from the ones we use on our nascent client side, we can start making some simplifications. Let's look around. Results mostly good but not all good. Rat hole.

Woot! I believe we have a complete disconnection between the client bot and the world. The world is running its own bot and I'm sure we have no cross-talk. I provide some general observations about this long refactoring, and its general implications.

I do manage to make an important change this morning, but I had hoped for much more. Progress is really quite good but I had fireworks in mind, not just sparklers.

Let's move further toward separating the World side from the Bot side. There are options and issues.

GeePaw and I addressed a serious design error. I think we wound up in a decent place. Today will tell.

Experience, thinking, and a few words with GeePaw suggest some moves. I try some things, roll back, but think we're on a decent path.

Based on a few days' experimentation, lots of thinking, and some messages with GeePaw, I have a tentative plan for moving closer to client-server style. Things go nicely!

We try a mad idea. We discover things. We despair. We assess where we are. We get another idea that's not so good. We roll back. We refactor just the least bit. We do a tiny JSON test. The idea becomes useful. We criticize the code. We devise a plan. Wow.

Continuing changes toward client-server. We'll discuss my lack of a real plan. We'll discuss why what I want to begin on today is particularly irritating. Much thinking, little code. As it should be.

This morning, without any direct Python network communications experience, I plan to start pushing the bot world code toward client-server. Along the way, I'm going to think about what GeePaw Hill means by a Making App. We do make a small but nice bit of progress.

Last night, we shared some observations about the code. We shared some observations about how we pair. We even did a bit of nice work.

We have adjusted `can_drop` to check scent. Let's do `can_take`. Should be much the same. I'll force myself to test this one-line change.

I have a bit of time, and I'm going back in.

My demon-dispelling thoughts this morning turned up what I think is a very nice-smelling idea. I must try it.

I do like the result of my changes to the state machine. I didn't always feel good getting from there to here. Let's see what I might possibly have done better. My conclusion surprises me.

We begin to look back at the evolution of the Bots' state machine. In this article we'll quickly review the three ways we have represented the Bot state. In the next, we'll look at the process of getting from there to here.

This morning, tests for the final state class, Walking, then create the class and plug it in. Then, time permitting, I think we can simplify things a bit. And wow, can we! Early bird, meet worm. Used "rip-roarin'" in a sentence.

I plan to start with some direct tests for the state classes. I think that will be interesting. And I'm expecting to use a Test Double, which is quite rare hereabouts. Plus: Amazing Grace.

This morning, I plan to start moving more directly toward one class per state. I'll be borrowing an idea from GeePaw Hill. Any mistakes in what follows are his and his alone.

I'm going to continue with Knowledge and see about pushing it into the Machine. Should be pretty easy. (Spoiler: NEVER SAY THAT!)

Our little Bot just shouldn't be this complicated. It's not getting better. Time to regroup and change course.

Explaining the situation to you helps. Then I pick a good first step. The rest is history: Long article, small steps, excellent outcome. Good job, rubber duckie!

I promised to improve the state machine tests. I guess I'd better do that. There's probably some good news in there. I learn to listen to myself.

Alone again, naturally, as the song says. I propose to convert to a more robust form of state machine this morning. Results cheer me up a bit, sorely needed.

I propose to make some changes that I think make sense and that my cohort will not disagree with much, if at all, despite not sharing my concern. As GeePaw put it last night, f[ool] around and find out.

I want to try an idea that I have about the client-server aspect of our little program. ... wanders off mumbling ...

We have been ignoring the requirement that this must be a multi-client one-server program. We have done nothing about that, on purpose. I think we need a bit more thinking, if not doing, on the subject.

Bryan comes up with a perfect term for what we're trying to do. We simplify one bit, improve another, must about others.

I think I'm on my own this morning. Maybe I should just open my Zoom to the public. Anyway, today let's just scan the code and see what we can see and why we see it. Maybe even do something about it.

The famous GeePaw Hill plans to join me this morning, at some point. Until that joyous time, I'll think about things we might do. We do two good things and are faced with an unknown. Note: one more thing added.

I'm planning to pair with GeePaw this morning. I have some improvements in mind, and will start on those before pairing time. We gather stones together. Well past time, you ask me.

This morning, up at 0650 for some reason, I think I'll push a bit on the "vision" idea. GeePaw arrives and helps out.

I think I'm on my own today. Feeling kind of lonely. I'll see what I can figure out.

Woke up at 3 AM with an idea. Going to work on it. I have opened my zoom in case anyone else on the team wakes up. Pairing, as always, is tricky but rewarding.

I've opened my pairing zoom at 0640, hoping Bryan was planning to be up. Perhaps he'll turn up. Meanwhile I'll try to spike something useful.

It's 0645 on Sunday. Bryan shows up as I'm summarizing status, and we get a really nice effect with some truly simple code.

We simplify two classes by adding just a bit of capability to another. Still wondering how to write articles after the fact.

Some pairing has been taking place, without contemporaneous writing. I will explain what we have. No, it is too much. I will sum up. Includes remarks on working without a net specification.

An attempt at refining the concept of this multifarious idea we're hatching.

A tiny experiment in Python on my iPad has inspired me to try a spike this morning.

We've agreed not to cater to client-server at all, to the degree we can manage it. As a first start, we've removed the World-Client variant classes and will simply be working with Biots sending messages to the World, and the World sending messages back. We'll see how that goes. I have one concern. Well, one that I care to mention.

We made some progress yesterday, and I'll report on that. Before today's meeting, I am a bit confused about what we should do next. I get a truly scary idea.

Secretly, Bryan and I are starting work on 'Biot World', a start at the joint project our Slack has been talking about.

Another quick look for something needing improvement.

Let's see what else might use a little improvement.

Still looking at that 20 line class. Yes, I think it needs improvement. Am I serious? I think I am.

I think we're nearly done with Sudoku at least for now. Let's look at the code and see what we can say about it. We find an issue in the first 20 lines. Wow.

After a review of notes, we move component looping from one class to another, in seven very smooth moves. I forgot to commit two of them, but it was still quite smooth.

Let's review our notes and see what to do next. Is there a way to wrap this up semi-neatly? Quasi-neatly? Not yet, but progress is good.

I believe that our naked and hidden pairs code was reporting that it had changed things when it had not. That would be bad. Let's see about doing it better.

Before we plug in the new Techniques, let's work on the 'Making App' with a very small Logger. Very mediocre results this morning. Meh.

Let's review our list and see what needs work. I want to try super tiny steps today, just as a matter of practice. (cf. Charles Beaudelaire)

We seem to have working code for hidden pairs. It is not yet a suitable object: more of a working prototype. Let's step back half a step and assess where we are and what to do next. We narrowly avoid a bear bite.

I think we're ready to try to find a real hidden pairs situation and adjust the notes accordingly. I am sure we're going to find an interfacing issue that will be a bit interesting. Includes notes on 'think-squared'.

Soon, dear, soon. We have the ability to set up a test. Let's see whether that sketched Hidden Pairs idea will work. I think there is at least one more stop before we're there, though.

Now that we have our foot in the door with `find_candidates_pairs` tacking a condition function, what would we have to say to define hidden pairs? Spoiler: We improve our ability to test.

As I think about additional Techniques, I believe I need more help from my objects. I have an idea to try out. Well, part of an idea.

Well, the new 'lonely' technique needs better testing and maybe a better name. I really want to do an unneeded optimization. There is grunt work to do. PyCharm earns a biscuit.

If, in the candidates for a given component, a value appears in only one candidate list, then that value must be assigned to the corresponding cell.

I wonder whether it would be that difficult to have constant Component instances rather than creating them dynamically? Kent Beck haunts me.

Yesterday's work useless. Last three days generally ragged. Today, I'll try to be more focused and go for speed. See Kerth's Prime Directive.

Based on input from my betters, I work on a faster way to deal with Candidates. GeePaw puts a word to it. Probably the wrong word. I go off on a tangent and discover profiling. An odd morning, with some interesting discoveries and one nice tiny object.

Having come up with the word 'evolving', I am ready to tilt once more at the windmill. Will I succeed this time? Spoiler: Yeah but U G L Y!

Tomas has been nerd-sniped and is solving Sudoku with Haskell. I nerd-snipe myself, thinking about Haskell, immutability, and updating. Some learning, almost no progress.

The Naked Pairs (NAIAIS) technique seems to work. What should we do next? I feel that we should step away from the brute force solver.

Ron, you keep changing the design all the time! Why don't you just nail down the design once and for all, and move on?

Did you ever look at your code? I mean REALLY look at it? This is going to be good! And it is!

I thought that I had made a misteak, but now I think I was wrong. I refactor to very small methods. Too far? Not for me, what about you?

Well, naked pairs, still, but I've used up that title. Brother Bill raises a question. I think we're OK. Let's try to implement the idea, whatever it is. Result: it goes very nicely.

Still not as interesting as it sounds, but this morning I plan to hunt down some naked pairs. I foresee some issues. And what about that pending issue from yesterday? Results: a bit long, but some shape emerges.

I've found some Python code for Sudoku techniques. I do not like it. But it'll be useful, I reckon, even though we aren't likely to copy it.

Reflection on how things are going makes me think we need to change direction a bit. Can we manage it without rewriting a lot of code? Can we keep all or most of our existing test working? Let's find out.

We already know of one more 'smart' technique that we might apply, but it seems a bit tricky. And how can we provide a 'menu' of techniques to be applied? Is this Big Design Up Front?

Let's fix that reminder test and set up to allow us to select techniques. A bit of progress, and raggedness tells me I need a break. It's artificial, it's intelligent, and it's not AI.

Let's try to put some intelligence up in this thing. Not artificial, mind you, though it will involve code. Spoiler: Works well and we learn a bit.

Tomas provides a clue. Whatever might we do with it? Ideas, experiments, and a decision not to go ahead with the ideas ... yet.

This thing just keeps on giving. I want to check something out. Result surprises me and I'll need to do some more thinking. Got good ideas? Let me know!

Is this a game of Sudoku, or a game of Columbo? I keep finding things to do! Fewer classes, a bit more clear ... but a few more lines of code.

It has been a while since I looked at the Sudoku code. I don't have anything in mind for it, but let's see what we can find just by looking.

I've thought of an object that we probably need. Let's find out. Result: A very pleasant refactoring sequence leading to a design that I prefer. Click to find out why.

What does all this have to do with real programming? We'll begin with last night's FGNO and go wild from there. We mention Iceland, and the age of the universe. Onions. Easter eggs.

I've come up with something that I think will be much nicer for computing the base positions from which to fetch our rows, columns, and sub-grids. A little refactoring does improve things, I think.

Let's review the code and the "project", to see what, if anything, we can conclude.

My theory is that once the sub-grid calculation is added to the Puzzle, we should be able to solve a 9x9. Let's find out.

The trivial test for my initial solver sketch passed. Will it hold up? Let's find out.

If the code agrees with me, I think I'd like to sketch a tiny solver this morning. Let's see if that's feasible. (Spoiler: It is.)

Let's see about getting the column, row and sub-grid for a given array index.

We spoke of Sudoku at FGNO, and my 'failure' with it, and with me, apparently, the failure of TDD, Extreme Programming and all of Computer Science.

I know it's a sin, but I've been trying a chatbot in conjunction with programming. Here's a brief report.

During our FGNO Zoom session, Ken brought up an interesting little problem. Let's play with it a bit. Gets a bit long, but it's really pretty light work. Fun effort, meant as such.

I'm not sure I'm done with this XST experiment, but I've come to some conclusions that I want to set down. Having done that, maybe I'll know what to do next.

Changing the rules a bit, yesterday, limits the richest player to around twice the starting amount. But are there still permanent winners and losers?

Bruce Onder appears with an interesting idea. It does make a difference.

Here's what my little simulation makes me think. Reflect upon the ideas of Richard Skelton and Robert Fitzooth. And maybe upon mine as well.

Let's clean up this code just a bit and then draw some conclusions about programming a thing like this. Clickbait: The technical conclusions are not what I thought they would be.

We recover quickly from a mistake last night, and get a nice histogram. I'm surely reading too much into this little simulation. Or am I?

Let's tune this thing up a bit. And let's try to avoid momentum calculations. P.S. The rich get richer.

I've been pecking away at the little simulation. Here's a report on status. We get some early results: the rich get richer.

"The rich get richer." I propose to pivot to implement a simple but interesting simulation. A good start after the usual trouble creating a new PyCharm project.

Mistakes? Technical Debt? Better ideas? All the above?

OK with that out of my system, what shall we code today? It goes so nicely, until oops.

I'm not out of ideas, but I am out of directions, and my momentum is low. What shall I do?

The swirl that is my life leads me to think about duplicates and such. Very speculative musings, no conclusion. Sort of Captain's Log Stardate 77691.1.

The statistics code is much better now. But a little widget might be just the thing. Turns into a medium-sized widget, but I think it's an improvement.

The statistics code runs, but is written in 1960's style—yes, I DO know what 1960's code looks like—and needs improvement. An interesting series of events with a fine result.

Commonly, when we group data by some criteria, we desire summary information about the groups: counts, totals, averages, and so on. We take a couple of nice steps before my brain is fried.

Yesterday's experiment with `group_by` seemed very successful. What does it tell us about what we're doing and what we should be doing? Bit of a retrospective.

Let's try an experiment, along the lines of my sketch at the end of this morning's article. It goes very well. Very well indeed!

I'm here for another step on the way to the grouping operator. I have at least one new realization going in. More than one coming out. Some code progress as well.

Time to push a bit further on the grouping operations. I don't get far before realizing that I need to break away and try again later. Not great, but good.

A bit of research into the past of Extended Set Theory suggests an interesting possibility for the future, and provides the joy of working something out on my own. Includes some possibly amusing history about how primitive man created such documents.

I'm continuing directly on from the preceding article, to create my XGroup implementation. It may turn out that a break was needed. We'll see.

This morning I'm working toward a join operator, by way of a grouping operator. I have vague ideas, and need some help from my code.

Fancy as my new streaming select is, I think it's, well, not quite the thing. Easily replaced, but do I need to pivot? I surprise myself.

OK, new rule, we're going to read XFlatFile sets into memory. Should we refactor to this new result, or TDD a new class? Let's refactor. Works quite well!

It's 0415 and I am thinking about buffering. I create an XSet with a billion records in it. Python does not sneeze.

The thing about learning is that when we have sucked most of the learning juice out of some fruitful idea, there is often work to be done to get the thing finished. We have at least two of those hanging fruits right now. One of them has an interesting effect!

The Powers That Be have invited me to discuss the risks around this Python XST effort, on the assumption that it is anything other than play.

There's no doubt that we can create sets or set operations that stream their results, avoiding creating large temporary sets in memory. There are issues to think about. First experiment works!

In which, your intrepid author considers times now and times then, assessing whether and how to adjust what we do with XST given the new reality.

A check of our list of ideas leads to discoveries, to key decisions, and to reflection on the realities of software development. Quite a span, as perhaps it always should be. Interesting article reference included.

Ran across this. Rather nice. Then I took one more step. Off a cliff. Fortunately, I didn't look down.

We've been working on calculated fields. Let's see about getting them built into sets. Yucch! I touched a debugger.

Our work on calculations raises some longer-term concerns about large dataset and statistics. Are we in big trouble?

Let's fetch values from XST records for our Expressions. I expect this to go smoothly. It does. We discuss small steps. No, smaller than that.

I have a bit of time, with distractions. Let's see about error conditions in our expressions.

We need to work on assignments and field values. I was thinking values, and then we do assignments instead. That's where the path looked best.

We'll take some steps along the expression path. I'm slightly questioning part of what we have. The path is zig-zag but leads to a good place.

Spikes for the expression parsing have taught us enough. Let's see how we can best move from the spike code into decent production objects. There's one somewhat large issue: symbols. No, two: data types.

Back to the interpreter. Shall we try the lambda thing again, or something else? Lambda seems fraught. Partial function FTW.

We can parse a simple expression. Let's sketch the expression interpreter. Bear gives us a nip, but we have progress.

I think I'll break down and do expressions. I'm thinking a simple Dijkstra-style parser will do the job for us. Let's see if we can find a simple way to develop one.

Suppose we want a set where one element is the sum of two others. What about calculating a scope? I am interrupted and then spot a squirrel.

Somewhat enlightened about how early XSP systems worked, there are a few ways we might go. I need too reflect on possibilities and pick a direction.

Study of some ancient scrolls leaves me thoughtful, and a bit disappointed.

You probably do not want to read this. I'm writing down my thoughts, in the vain hope of figuring out what they are and what they should be. Dave Childs was kind enough to send me some links to articles and other materials about XST. I include them at the end of this article, for reasons. The materials gave me some things to think about.

I was whining earlier about the difficulty of writing tests that assert about elements inside a result set. A thought has come to me.

I want to work on some indexing operations. Along the way I rediscover XFlatFile's existing scope set feature. Just what we need. Or is it? Includes a judicious rollback.

Laurent challenged me to find a better, more elegant formulation for getting the correct re_scoping set from a provided renaming set. I thought I had it. Then I thought I hadn't. Then I thought I had.

We have a long-form cardinality method. Let's use the len function and require it as part of the implementations.

Let's look around and see what we might do. I'll even make a list. Jira is an abomination upon the land.

I have received a bug report! This is great news! Someone is paying attention!

Putting a specialized rename into our flat set showed us that the symbol table there is quite ad hoc. Let's make it more like a set. (Turns out: no.)

Since the Flat sets know their field names once and for all, we could use a better rename that doesn't copy the data. Simple enough, rather nice.

If there was a kind of set that was expressed as a function, we could possibly pipeline operations, reducing memory impact. Is that possible, and is it a good idea? So far, maybe not.

What if a function IS a set instead of returning a set? This might be significant.

We try and succeed in implementing an XFlatFile that refers only to a subset of the file. This is a big deal!

I'm working on the idea of an XFlatFile that only reads a defined subset of the file. Am I working without a net? Not really.

Plus wasn't the right operator for union. Let's update that and then a few other operators.

I had thought that I'd work on the flat data. My thoughts led me astray, to a glimmering of a possibly good idea. So I'll just code something cute to finish the morning's work.

Thinking about rename in the Flat implementation leads to discovery of an interesting defect, and some thinking about use of the powerful generality of set theory.

In an astounding flurry, we are going to build a rename operation.

Childs has defined two "re-scope" operations. Let's see if we can implement one of them, and if we're glad we did.

We'll start with a simple removal of the requirement for implementations to implement `__contains__`. After that, we'll see. (And that's not what happens.)

In your absence, I made a simple but significant change. I had an interesting idea. And an important observation. And more.

We make some progress on our flat files, but progress is slow and there are a lot of words here. Best skim or skip?

Let's see about getting set creation sorted. We need to be better able to create sets with any possible base implementation. Deep confusion ensues.

To process flat files, we want to avoid leaving a file open, and we don't want to open it a zillion times. Do we have to invent buffering? Perhaps not.

Our experimental tests one flat records look good. Let me report on my off-line work, and then let's see what's next.

Let's get started on a flat-file-focused form of set. We make a bit of progress.

I want to begin by thinking about storage: how do we best produce specific memory / file formats? The article turns out to be pure speculation, but perhaps useful speculation.

Having prepared better than we did yesterday morning, let's proceed with wrapping our `frozenset` with a class of our own.

Let's have another try at wrapping our `frozenset` in an object that will work for us. Things go much better ... so far.

I make some useful initial observations, and then, well, I crash and burn. And mix a metaphor.

I think that this morning, I'll take a small step toward having more than one implementation of a set's data.

If I'm going to get serious about this Extended Set Theory thing, a tiny bit of design thinking seems to be in order.

It is 0253 hours. I have a report and another report.

Lets do `project`, as in projection, as preparation for trying a generator approach to set expressions. This part should be easy.

There's a thing I want to do with this XSet stuff, and I don't quite know how to do it. I need to better understand iterators and generators.

In which, we report on a nifty little thing, and then, well, I don't know yet what I'll do. Some concluding remarks on what it is that I do here.

In which, I show you what I'm dealing with, and mention an insight.

In which, I realize that I have made a mistake.

Let's see how we can select records from an XSet, using the `restrict` operator.

I propose to push a bit further on the use of Python frozenset to do a little Extended Set Theory. I mention symmetric difference!

Some random reading, and the messing about that I've done in the FAFO series, leads me to want to explore Extended Set Theory in Python. I do not expect it to be useful but it might be interesting.

A little planning on what I might like to do. No code, just thoughts. Wow, "slug" has a lot of meanings.

Joy projects. Impact. Transclusion?

Thinking about simplicity, generality, abstraction, and the FAFO data. A tiny but possibly important insight.

Zoom report. Simplest thing that could possibly work.

Too far is far enough. Not quite too far isn't.

A "database" to work with.

A Pythonista experiment makes me think. Time permitting, I'll build some files.

Having given Hill some bizarre advice last week, I propose to "Fool" Around and Find Out some things about the idea.

Wherein we consider some advice given to GeePaw Hill at a recent FGNO session.

In the unlikely event that I hit the saucer, it is supposed to display the "mystery score" that applies. I think we can do that.

We continue working on the game's beat sound. I am faced with a dilemma.

The game lacks the terrifying beat sound that characterizes the arcade game. Let's put it in. Begin with a mostly unrelated question.

Despite a lot of musing about the Situation, I've not made enough progress to spike anything. What shall we do instead? A tiny improvement?

Now for something completely different!

I only just realized the name of that bear. But mostly, musing about the Situation idea.

Let's see about this explosion mixin. Now that we've sat on it for a few days, so the glitter has worn off, do we still love it?

I think there's maybe one more explosion up in this program. Let's see if we should add it to our mixin.

There's at least one more place where the ExplosionMixin could be used. Should we use it? Let's find out.

Are mixins a moral issue, or simply a useful tool?

Just one tiny improvement.

The morning goes in a completely different direction than I expected. A good direction, though.

Continued: One of Kent Beck's perceptive Rules of Simple Design is the one about expressing all design ideas. Some code up in this thing bothers me.

One of Kent Beck's perceptive Rules of Simple Design is the one about expressing all design ideas. Some code up in this thing bothers me.

This morning I thought we'd start partitioning the 3 Player classes. The situation suggests otherwise. Some simple refactoring. It's all good.

Dude, did you ever look at your hand? No, I mean really look at it?

Let's look today at three classes that are similar but different. Make similar code more similar. Soft, gentle, geek joy.

Today we're going to resolve the issues with invaders getting low enough to end the game.

A report on a PyCharm Live Template for starting TDD. Some experimentation. No yippee.

I look back at what one might have learned along the way here. Joy: highly recommended. Find yours.

When the invaders fire on the robot, it does not explode. When it gets a new batch of invaders, they don't fire on it. This cannot endure. Results: good. Code: OK.

Can we figure out a decent way to improve the attract mode? Should we make the robot player a better player? Perhaps not.

There are issues. A long, slightly fruitful refactoring. A much more deadly attract mode that plays better than I do.

Trying to keep the Driver-Player simple. How well can I manage that?

Sometimes I get ideas that are really tasty but impractical. Let's try something practical.

I have an idea for a step toward attract mode. I plan to try part of it.

Let's at least deal with the invaders falling off the bottom. Maybe a first step toward a better attract mode. Pretty ragged.

Today, just a simple Game Over screen, so that we can at least see our final score.

I plan to implement a Game Over screen soon. The first one will just display GAME OVER. But could we build a somewhat smart attract mode? One that learned to play the game? Let's think.

How many ways can we think of to do a thing? How can we decide among them? CW: Ignorant Savages.

We'll make sure that our tests check the production generator function, but mainly I want to talk about small steps and TDD.

Bill Wake suggested a generator function for my invader starting heights. I think this will be a keeper.

Will a tiny object help clarity in the InvaderFleet setup? Let's find out.

Today I propose to make the invaders advance down the screen. I have the details. I am not entirely happy with the result, but it is solid.

... the thing I call TDD might not quite be TDD. Also some speculation, and some other speculation. Pure musing no code.

I think today we'll deal with the possibility of running out of invaders. Today we bite the bear. Take that, bear!

Let's find something to improve the program, but small enough to be suitable for an early Sunday morning. I think we did something right!

The Invaders game, while playable, isn't quite as done as it might be. It's well past time to be adding some capability. We briefly discuss the point of software development.

I think that I don't quite like how the Invaders deal with the edge of known space. Let's explore. Result: I am pleasantly surprised.

I put in a new method yesterday. I'm not sure if it was a good idea, potentially good idea, or sheer waste. I love changing code.

I have in mind a few small things that would like to have attention. Are they worth it? I think so.

We can remove some duplication with inheritance. One pythonic way is with a mixin. Let's look into that.

With the new ability for Sprites to detect collisions, let's start converting classes. We should be able to do them one at a time.

With a couple of classes using the Sprite, it seems like time to see if we can put enough useful behavior on it to make it more desirable to move to it.

Either I was less intelligent than usual, or there is something tricky going on here. I'll proceed with due caution.

I will share with you an intuition, a guess, about where this Sprite thing is going. Then I'll plug away.

Today I plan to improve the Sprite object to handle animation. I am optimistic about this.

Today I'll try to gin up a little object containing the mask, the rectangle, and the position, to see if it makes things better. I am hopeful.

Design Thinking: There's this notion of "encapsulation" that I've heard about. And "cohesion"?

What general notions might we draw from the past few days' work? What do you see that I do not?

We'll review the saucer code and improve it.

Saucer is still too complicated. I had an idea yesterday at close of session: a helper class!

Drilling down was useful, I think, but let's take a look around for new code signs. We wind up working on names. Again.

I think I see something that would improve the InvaderGroup logic. Let's find out.

Let's have a look at the new code for invaders and edges, see what it's telling us, and do something about those hundred-plus calls. Bear bites man. Man survives.

I promised to throw this spike away and do it over. Can we talk about this? Includes words like 'folderol' and 'bugaboo'.

Let's try a spike that may lead to an improved version of our invader fleet logic. I promise to throw it away.

A very strange session. Two hours of reading and thinking, one very simple change adding an enum, no major improvement. Wasted? Or valuable? I'm not sure yet.

I propose to identify and discuss the things I see in code, what they make me think, and perhaps a bit about what I might do about them. This does not go as I expected.

I've run into a small issue with the Sounds object. I think I have a solid idea for it.

Working on sound, we encounter an interesting refactoring, done in a very zen-like fashion. Small steps, add duplication until it resolves. This was really quite nice.

I have a somewhat more expressive way to, well, express what we did yesterday. Do we prefer it? Let's find out. Short, and sweet.

I propose to remove some if statements today. Why might we do that? Do we like the result? Readers may disagree. I might even disagree with myself.

I'm pleased that Invaders has been implemented without framework changes. And I see what I think is a desirable change. I learn otherwise.

I want to talk today about Programming by Intention, a notion I learned from Kent Beck and Ward Cunningham.

Seeking something to do, I'm back on my Invaders [DELETED] again. I do tidying. It comes down to joy.

GeePaw Hill and I both noticed something odd about the Wordle words. Is it an inherent property of the game, chance, or intelligent design? Spoiler: It's neither!

Herein, some comments on what I've learned playing with Wordle.

I've thought of a streamlined way to get the expected information values from the file data, and want to try another shot at parallelism.

I can't explain why, but I've decided it will be interesting to try the information theory ideas I've found on line.

Convinced that I can't make generating the SolutionDictionary fast enough, I'll explore pickling it.

I think yesterday we were limited by pickling. Who knew? First try: Debacle. Second try: Can't work, don't even try.

Today I want to try something new: concurrency. Includes: Thrilling Video.

I'm struggling to keep the shape of the solutions dictionary in my mind. Therefore I need something simpler.

Let's save some test time by saving some data. And let's look at the data to see what we can learn naively. Spoiler: I quickly ditch the caching idea.

I'm having trouble coming up with a real plan here. And I think I've squeezed everything I can out of `score`. I borrow an idea from GeePaw Hill.

I suspect there's a mistake in my scoring. We do some timing. We struggle for an idea. We resort to some bit twiddling. Do not read, that's my suggestion.

Trying to do 300 billion operations makes me think I should take a new angle. I need a better idea, or a computer that is 1000 times as fast as this one. A better idea may be possible ...

A bit of study tells me that my scoring algorithm is wrong, although there seems to be some debate about it. Then I have to figure out what to do next. I burn an hour of CPU time.

Our Tuesday evening Friday Geeks Night Out Zoom Ensemble is getting sucked into Ken Pugh's work with Wordle. I have caught the virus and am going to start a new Python project.

I have yet another idea for how to get rid of the conditionals in the saucer code. This one might actually be pretty decent.

I have an idea for how to get rid of the conditionals in the saucer code. It is a nasty idea. I must try it.

Time to look at the Saucer and see if it needs some improvement. I feel sure that it does. A very nice refactoring sequence appears.

It's Sunday morning and I have a little time to play. Let's see what's left for the Saucer.

Let's see what's left for the saucer and what we can do. It's late Saturday morning: maybe we won't do much.

We'll continue with the Saucer. We'll look at what's left and pick something. Includes thrilling video.

Yesterday I was running faster than my feet. Let's see how the Saucer code looks and how to improve its tests and the code itself.

Let's see about doing the saucer. How hard could it be? Well, not hard, but ragged and chaotic. I moved away from my A game for some unknown reason.

I think about screen layout. I look at the list of things to do. It's the Jira Trap!! It all seems so reasonable ... until it isn't.

My keyboard tray Jira is getting too messy. I'll clean it up and go to a much more high-tech solution. Also: a tiny tweak to screen layout. Also: robots

There's some duplication between the BottomLine and Shield. Enough to fix? Let's have a look. Outcome: This goes ever so nicely! Sweet!

I found a way to damage a Surface, given a Mask. I don't exactly like it, but it works. Now what?

Yeah, let's do the bottom line. Might be just the right size for the afternoon.

I think there are very few things left to do with Invaders. One of them is scoring.

More waffles, about the tensions between design alternatives for the Flyers. What if we were to open the doors as widely as possible? I think this is my last waffle on this topic. I like the outcome. Today.

I gave abstract method a chance, for almost 24 hours. I hated changing all my classes to implement all those pass methods. Let's try a different dispatch. Waffles?

Now that we have this metaclass, and now that we have this decorator, what shall we do? The answer may surprise you.

Let me explain. No, it is too much. Let me sum up.

We continue learning decorators using tests. Our simple decorator doesn't handle parameters in the wrapped function. Lets figure out how to do that.

Never heard of him. Let's learn about decorators, using tests.

The Python "decorator" is less bizarre than metaclasses and might be just the thing for our needs. Let's try one.

There are surely ways to provide my `ignore` feature without using metaclasses. I can think of one. Maybe it will help me think of another.

Having found a way that I think will work, I'll try again today to install the 'ignore' capability. Hamsters. And success!

Today, I plan to install the new metaclass with the `ignore` feature. Result: Bears discovered deep in the bag of tricks. They bite. Later: I know what caused it.

Today, in the spirit of meta, I work on a metaclass for ignoring methods. I start on Wednesday and finish on Thursday. It's scary weird.

What shall we do today, Brain? The same thing we do every day, Ron. Find something interesting to do. Things get very meta ...

The Invaders team has encountered a troubling issue, and have been making some troubling decisions. We need to explore this and deal with it at its root. Spoiler: It's not the programmers. People over process.

Let's do ReservePlayer. It has essentially no behavior. We'll TDD it anyway, and will be glad we did.

Thinking about how we'll replace a destroyed player has led me to a strange idea. Perhaps too strange, yet fascinating.

The words "time capsule" popped into my head last night. Have I told you my favorite thing about this program's design?

Bill Wake's comment suggests more use of the new Masker. Looks useful.

In which, a small object helps improve our code.

Part two, following P-247. Another idea. And we still have more opportunities to improve! Wait, SQUIRREL! Two of them!

In my quest to spend way too much time on ImageMasher, I have another idea. I should also mention why this exercise is a good one: changing code is our job.

Let's take a look at the ImageMasher. We'll see how far toward perfection (or lily-gilding) we can push it. We go a long way—and at the end I think I see still more that we can do.

It's oh-dark-thirty but I think I've got the answer.

An early idea got me up, to get it down, as it were. Too interesting for me to go back to sleep. Yes, I am strange.