Category: python

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.

I didn't see it on my drawing, I didn't see it in my code, but then I saw it in the code in my mind. The lessons today, oddly, are about dozing, and estimation.

I believe I'm close to understanding masks well enough to build a little object. Another test or two and then I hope to try something. Chaos may or may not ensue.

Before I try to improve the way the Shield adjusts its image and mask, I feel that I need a better understanding of how things work. We'll use tests to learn and record.

Some reflection, and an exchange with Rickard, makes me think that my lovely little Tasks object isn't as great as I initially thought it was. Let's think, code, think, and learn.

Let's do some tasks, now that we have the Tasks object. We'll see how we like it.

Not my ideas, mind you. Two good ideas from Tomas set me on a course for last evening and this morning. Are there rats in here?

Let's see if we can add lightness to our reminder facility.

My timing defects have caused some thinking, some of it mine. There might be a better way. (This is long, because there's a lot of design thinking. Then some rather interesting doing.)

There's a second "timing" defect in Invaders. This one is harder to forgive. Mea culpa. Plus: At least one other defect. And I allowed myself some fun writing this one, too. Same as it ever was.

Let's clean up the shields code and improve the damage. I've found a missing piece, the explosion part. A rather nice refactoring sequence ensues.

Let's clean up the shields code and improve the damage. I've found a missing piece, the explosion part.

It's 3 AM. The power's out, the phones are down. Of course I'm going to program a bit.

I have the facts. Let's draw four shields. Then shoot them a bit.

The Invaders game has shields, four of them. They take damage from invader shots, but are not destroyed in one go. This will be interesting. What do we need and what are some small steps?

Let's start transitioning away from inherited `interact` methods, making them abstract as originally intended. I'll try to devise a sensible way of proceeding,

Let's explore last night's matrix idea. There's got to be a pony lesson in here somewhere.

Last night, some topics came up that I'd like to consider a bit this very early morning.

If I'm right, which assumes facts not in evidence, this next step is going to be surprisingly easy. This often happens. There may be a reason.

I had an interesting realization about the shot patterns. And we have a hanging commit, some broken tests, and more to do before we are done.Things go well. Thoughts on small steps.

Let's find another small step toward invader shots. Maybe even more than one. Very long, I'm not sure why. And no commit at the end. Afternoon distractions. Not delight, just distractions.

Invader shots emanate from invader columns, according to a pattern. How are we going to do that?

Everyone needs them. Let's make that happen. Then, let's explode some invaders.

I think first I'll have the invader and player shots destroy each other if they collide. I had hoped for more. This caused enough trouble. Mostly resolved, I think.

I think today I get to start on the invader shots. How much of the original game's pattern must I follow? Probably it's too soon to ask. Squiggles!

There's reason to believe that there's an object in here. Let's bring it out. I feel I picked a poor path. How could I know?

At least two collision issues face me. One is how to stop the shot after it hits an invader. Another is that I see an object trying to be born.

Let's see about how to detect collision between the invaders and the player shots. I think we want to do actual bit overlap.

In response to a question from Bruce, I find myself looking askance at one of my darlings. Should I kill it?

We have a start at player shots. Let's get one on the screen .. and then off the screen.

I think I'd like to try the player shot. Names are becoming an issue. For once I do the right thing.

It's time to make the game look a bit more like a game. I'd like to think briefly about what to do and how to do it.

Having used the BitmapMaker in the game code, I envision a better way of using it.

I think the bitmaps are ready to be moved into the Asteroids-Invaders repo. I hope to actually use a couple of them in this session. Success! And an amusing mistake.

I've been pecking away at making the bitmaps for Space Invaders. Let's take a look at where we are. Gross ad-hocery and a lot of pasted data and bitmaps. Not very interesting, even for me.

There may be room for more refactoring in the fleet/group area. What even are those two objects? New CSS, consider clearing browser caches.

Let's continue to look at InvaderFleet and see whether some handy little objects might help us out.

It seems to me that InvaderFleet may be asking for some refactoring. Let's start with some thoughts on TDD, and a look at the tests and code.

I would really like to move this game along a bit. But there's a matter of scale that needs attention: the reversal points. And that fills the morning.

Let's continue with moving the invaders. We have some issues to deal with, and for at least one, I have no solution in mind. Lots of thinking tells me there's something funky in here.

I believe that I've made a mistake. This will not be my first, nor, I fondly hope, my last. CW: Contains brief Jira abuse.

It's time for a README file. Well past time, to be clear. And I have an ulterior motive, which will become apparent in due time.

Part of a short series on design, static vs dynamic languages, god objects, and our ability to understand the code.

Let's take the next steps to, um taking the next steps.

Bruce gave me a very nice idea: Bumpers! I think I'll try it.

I've decided to extend the Asteroids program to include Space Invaders in addition to Asteroids. I expect this to be—well—not easy but not too difficult.

We've managed to import some bitmaps and display them. It's time to start sketching and executing a plan. Then I ask myself a hard question, leading to a complete change of direction!

We do a quick bitmap experiment, and then create some alien surfaces from the original Space Invaders arcade source code.

Further setup for the record. PyCharm pleases me.

Today I plan to set up a new Python project. This one will be a Space Invaders replica. I'll say a bit about the idea, but this is mostly just a record of how setup went.

Somehow I am enjoying working on, refining, polishing this Asteroids game. I don't want to stop. I have at least two silly features in mind. And, are there still lilies to gild? We discuss inheritance. Basically done?

Is this program as perfect as I can make it? Is there anything left to do? When your best idea is spinning asteroids ...

Tomas Aschan inspires me to try an object. I don't think I'm going to do exactly as he said, but when this works, he deserves much of the credit. If, perchance, it doesn't work, it'll be Chet's fault. But it will work.

What if we made all three `draw` commands look alike?

On our quest to improve SurfaceMaker right out of existence, let's try a LinePainter object to replace it. Except that I change my mind almost immediately. Notes within on hints that I wasn't working ideally.

Now that we've improved SurfaceMaker, can we improve it all the way to nothing? Let's find out.

I've implemented the SurfaceManager to allow callers to specify extra room for fat lines. That was not a good idea.

We've improved the SurfaceManager a lot. We'll do a quick review of that, and then see what we've missed. Why? It's good for us and for our organization. Late note: Ron was too clever.

At the time I worked out how to draw the game objects, I was new to Pygame and all its works and all its pomps. We deserve better. Refactoring FTW!!

The screen objects are too big for the amount of screen space we have. We need a global change of some kind! (Turns out to be disappointingly easy.)

We'll start with some philosophizing, and then we'll do a review of the saucer's missile-firing logic. Fun is actually the point.

I have no particular goal in mind this morning — yet. We'll look at our recent work and then beyond it. My initial concern: Aliasing.

I'm going to take another try at improving the ShotOptimizer code. Not because we really need to, but because we want to learn how to make code better. That's my story and I'm sticking to it.

I see the issue and fix it. An aliasing issue. I haven't had one of those for a very long time. Still no committed code change but some good ideas. Next time?

It's 0430 hours, commonly called oh dark thirty. I have a desperate need to clear my mind and get back to sleep. I try some things and settle on none. I learn some things but no net code change.

This morning PyCharm and my code rubbed my nose in the notion that a "static method" signal may mean that the method in question really belongs on some other class. Let's explore that idea.

Today I think it might be fun to extract a SafetyChecker class from ShipMaker by refactoring. First I get a better idea, and then the code tells me what it really wants. Fascinating!

Just for fun, I add a cheat code. Might not be my last one.

It's funny how thinking about one thing can give you an idea about another thing. Just a little fun today.

OK, let's see if this baby will fit where we intended it to fit.

Because I injected a defect into my two-player game, and because it could be better anyway, let's make it better.

After all that happiness, I realized that free ships go to the wrong player in the two-player mode. Bummer. In fact: Dammit!

Let's review how we added a two-player mode to the game. Let's look at how it was done. Frankly, I am pleased. EXCEPT: A Defect!!

If things go roughly as I expect, we'll have the two-player game today. Sometimes things do go as I expect. It could happen. It DOES happen!

Yesterday, an idea. Today, an experiment. Your intrepid author is optimistic. Things go very nicely.

Let's think about a two player alternating game and how we might do it. A bit of design thinking seems to pay off.

I think the coin test is better than it was, but it isn't what it could be. Let's do better, just for the practice. I surprise myself with a challenge.

I thought this morning that I had broken the game. Why am I even doing this seemingly useless changing? How do you get to Carnegie Hall?

I'll just have a look in and see what might need a little tidying, then, shall I?

Zoom report. I notice a thing. What is to be done about it? Something nice. Repeating the Faulkner quote from yesterday.

Sensible thoughts lead me to wild speculation about the future of this tiny program. Who knew? Then, I create something nice: a Transponder!

Let's continue the scoring improvements, with a little help from our friends.

Working with Saucer has me thinking that scoring is unnecessarily complicated. Let's look into that. Isn't it amazing how much a tiny program like this one can be improved? And I didn't even try to do a poor job.

Saturday: Remove unneeded abstract method. Discuss design. Sunday: a nice refactoring series.

As small as this program is, it shows us examples of issues that arise in larger applications, and suggests similar changes to those we'd make in the wild.

I really don't like the fact that I am either too dull or too lazy to derive the quadratic targeting calculation. Either it goes, or I do, and I get to choose.

I'm just going to look at random bits of code and see what they suggest to me. Watch me if you care to.

Bill Wake gives me some thoughts about a static method. We'll look at that, and see what else may need a bit of improvement.

Last night, I showed my friends two largish methods. Soon, everything was different.

This morning, I woke up thinking something was broken. Fortunately, I was mistaken. Let's fix it anyway. Also, thanks to a reader!

This afternoon, I notice something that could be better. Let's see if we can find a bit of improvement.

The final of four articles covering a single refactoring session. It has gone ever so nicely.

We continue a long refactoring session. It goes so smoothly that it all happens in one stress-free morning.

I begin a long refactoring session. I'll split the article another time or two. I am a merciful person at heart.

Again today, I plan to make the necessary adjustment to missile velocity to improve targeting. Again today, I have an idea. (First of a few articles all reflecting one morning session.)

I've left in two tests that aren't testing anything, and I still want to improve targeting. Let's see what we can manage. (Answer: Not much. Final thought on story estimation.)

This morning I discover that the code doesn't do what I thought it did, nor what I now want it to do. Inching toward better.

The new targeting code seems to work, though I could not derive it. I want to refactor so that it makes more sense, and I have an idea for a bit more testing.

I get some good advice from a reader (!) and ten (unrelated) consider a demonic idea. I lift a solution from the Internet. Some nice little refactoring. A few tests. Saucer is deadly. Could be more deadly.

The small saucer should always target the ship, while the large one targets randomly. Let's see how we might manage this. The Gunner does know the saucer ...

I think today I'll put in the small saucer, because the game is already too hard for me.

Let's begin by getting rid of the Explosion Flyer, at least the Flyer part of it.

We think about our design, do a feature, recognize a potential concern. Not what I planned, but that always happens.

Must think about, maybe spike about, an idea from GeePaw Hill. How pure do I want to be, on what dimensions? In the end, "No!" and I'll tell you why.

Observations from Rickard. And let's remove some Flyer subclasses. I still think I've gone too far.

SaucerMissile must go: it is not bearing enough weight for the trouble it causes.

A Mastodon exchange with Rickard makes me wonder whether this program violates Kent Beck's "Rules of Simple Design". I need to think about this.

I think I've gone too far ... I discuss, speculate, wonder, and do not as yet know what to do. Ideas welcome, as always.

At least I'm trying ...

Yesterday's experience causes me to question a central design notion.

Last night, Hill observed something notable. We worked on it then, and I'll do more now.

Looking at Game, and it seems we can improve quite a bit. Great outcome, nearly perfect!

Let's go after Fleets and Fleet. There's too much there for what we need. And, perhaps, too little. Discovery: I like it!

What shall we do now? Think about splitting Gunner? Discover something different in there? Create a debug keystroke? Why not all the above?

I am slightly irritated by the fact that my lovely Gunner object would really benefit from an additional change.

OK, lily-gilding aside, what are we really doing to do with `nearest`?

I'm going to do the tiny object for the `nearest` code. I just want to see how it looks. Talk about gilding the lily.

I had an idea last night as I was dozing off. If I can remember it, I'd like to try it out. This turns into a long series of revisions of about ten lines of code. Fun for a Saturday.

As a lark, I plugged in the Gunner. Doesn't seem to work. Let's see what's up.

I've received a PR or two from Jani, and then on to more work on Gunner,

I am trying to do little things in a house full of banging. I found something possibly worth thinking about. And maybe I go off the rails. I'm not sure.

A toot from Jani led me to see the defect allowing ships to shoot themselves down. The question is what to do about it.

We are getting a new roof today. Might be hard to concentrate. Fortunately, I try never to need deep concentration anyway. Shall we work on Saucer today? We shall. (TDD really works nicely here.)

A couple of small changes, then we'll see what's next.

I did a bit last night. Let's see if we can finish the HG this morning. I bet we can, but then, I read ahead in this article.

Let me do a little background TDD here, see what I come up with.

I need all the help I can get playing this game and I'm thinking I'd do better if I could shoot down the Saucer's missiles. Also, some thinking, and hyperspace recharge cycle.

We want the game to start in "Attract Mode". Should be trivial. Shall we do a Seed? No, something more fun. Also: I make a mistake. Not the first time, just the most recent.

Jira is the name of the area on my keyboard tray where the yellow sticky notes live. It's getting messy. Let's see if there's anything on there we can scratch off, or if all else fails, actually do.

The Game knows the objects that need to be loaded into the mix to start the Game. Let's fix that up.

A Timer-related idea. I have a little time, let's try something. It goes very nicely, I think.

No, I mean REALLY look at it. Did you think I was finished with Thumper?

Did you ever look at your code, man? Like, really look at it?

I think we should break out the thumper logic into a Flyer and simplify Fleets accordingly.

This morning I have concerns about the order of events, and what they are. Let's see if we need more clarity there. It goes well. Important footnotes.

This morning I thought I'd clean up Fleets a bit. Is now the time for that?

As usual, what happens today isn't what I planned. I recognize a design issue, implement a very interesting test, then generalize what happened to consideration of real teams. Watch how my thoughts evolve.

We need a GameOver object and a Quarter object. Let's try one or both of those.

I think there's just one more smart Fleet to remove and then we can greatly simplify Fleets and its interface. I wonder what other specific Asteroids notions may be lurking in the upper levels.

I think I'll move to replace another Fleet subclass. People I trust are tired of Asteroids. I briefly address that concern.

While I believe that my preparation work the last few days has been valuable, it doesn't feel much to me like real progress. Today I want a better feeling. And I get it!

Some thoughts on tests and code, inspired by shipping a defect and by ideas from Rickard. And then some changes. I have a nice one in mind.

I think I can do better than I've done with the Fleets object. Let's think about it.

Let's start with a question from Rickard, and then have a look at the Fleets / Fleet setup, to find one or more small steps toward our desired design. ALSO: Big mistake! Released broken game!

Let's see if we can reduce accesses to the specialized lists in Fleets. As so often happens, the next step isn't in the direction I expect. That's OK.

I think I'll start by counting missiles in the Ship and probably Saucer. Then we'll see what's next. The thing is to keep stepping toward the larger goal. Some interesting [mis-]steps.

What additional special objects do we need, and how might they work?

Let's put the full interaction protocol in place, so that more of our special Flyers can operate.

While sitting in a mostly boring on-line session, I'll do some small safe changes.

I am going to do a thing, and then another thing. Don't tell Hill about the other thing.

I am oddly without a plan this morning, even my tentative sort of plan. Be prepared to read my sort of thinking. I hit a few bumps but not major ones.

We make more small changes in the direction of independent objects interacting to make the game emerge. Let's experiment with full interaction.

I'll do a small change, then see what comes to mind. As long as we keep moving in roughly the right direction, we're good. Thoughts on small steps.

As I move toward the decentralized model, I need some thinking about next steps. But first, an interesting test.

The double dispatch is doing its job. Let's see about cleaning up the references to fleets and whatever else comes to mind.

-ralization. Just a picture of the relationships of some of the objects to start. Then a question: a world record? Guinness, where are you? And then: progress!

Some detailed thinking on how to refactor to a decentralized model. With any luck, some starting code. But I do feel the need of the thinking part.

I really liked the "decentralized" version of Asteroids that I did in Kotlin. Thinking about doing it again, in Python. Refactor to a new design? Why not?

I've been perusing the ancient scrolls, i.e. the Github repo of the original asteroids code. Some notes on what I think I understand so far, then some code. Repeat. Success!

Let's put in some more sounds. I anticipate little trouble. Even here, we learn some interesting lessons.

TIL that I had my speakers swapped left for right. And how to do stereo in pygame.

As one would hope, sound generation in pygame is pretty simple. I managed to work out the basics all by myself. Well, myself and the entire Internet.

Let's see if we can make hyperspace more dangerous.

I need another distraction. What's in "Jira"?

I need a distraction. Let's look for one.

We'll continue plugging in the MovableLocation, but I think it may need a better name.

I want to while away a little time. What can we find that's right-sized?

What if there was some sort of Position object?

We want to get rid of the GFragment class. To do that, we have to get a little head.

While I am OK with the subclass design, I think we can do better. Also "Replace polymorphism with data."

Just the before and after versions of the refactored Fragment classes. Lurvely.

I want to take a look at the explosion, especially the draw method and see how we can clean it up. Many many tiny steps FTW!

Today I plan to add gold to the gilded lily, in the form of still more enhancements to the Ship's explosion. Unjustified, but I plan to be amused by the result. And I am.

We have some rudimentary fragments. Let's make some better ones. I spend ages tweaking numbers.

I almost always have fun here, actually, but today let's explode the ship. That should be a good exercise for the Fleet-based design.

I have some loose end notes in my keyboard tray Jira. Let's have a look at some of them.

I learned something new, and apply it. Also I have an idea of my own. Will wonders never cease!?!?

Thinking about some design issues, some good, some maybe not so good. Seven footnotes, none useful.

We do a bit of review of the code today, and we find some nice improvements.

We'll finish up our refactoring of the checking methods down into Fleets and lower. Quite a few odds and ends, none of them difficult. A noticeable improvement to Game.

It's afternoon and I have some distractions. I'd be wise not to try anything, but maybe I can find some tiny safe steps.

We must be pretty close to done in our quest to move responsibilities down to Fleets, Fleet, and flyers. Also some generic Python thoughts.

Let's move some more Game responsibilities closer to where they belong. (It goes better this time!)

I was off my game yesterday, and want to do better today. I can't be smarter, but I can go slower. I think that, plus experience, will serve. (I still manage to get in trouble.)

Let's push more behavior down into the objects. There's plenty of room at the bottom. (I nearly interfere with the canine, but finally make a little progress. Don't read this article.)

Some of what I did last time needs improvement. This is no surprise, but, really, I coulda shoulda woulda done better. I forgive me.

Are there still easy ways to make use of our Fleets and Fleet classes? The remaining cases may be a bit more difficult. "Repeat, not quite the same way."

There isn't enough simplicity in here yet. Let's add some more.

Colin Chapman's motto at Lotus might apply here. Let's see if we can simplify this code. That will help us add lightness, I think.

I am concerned about an aspect of the design which is inviting mistakes. How might we address it? I surprise myself with a much simpler change than I had expected to make today.

In for a penny and all that, I do the Ship's spawning Timer, somewhat the same but slightly different. I mention a Fundamental Learning.

Now that I have my nifty timer object, I want to use it. Is there a rationale for this? I'll find one.

A test suggests that calling a method from the Timer works just fine. I confess that I find it a bit hard to grok at first.

Features are important, but I learn more from code review, so let's see what we can see. Timer object: Ron does not kill his darling.

There are things not to like. There always are. Let's find some and improve them.

After Hill's good advice yesterday, the Zoom group last night came up with something even better.

I don't know why I needed a hint for this test, but I'm glad to have had it.

The Saucer missile should usually be random, but sometimes aimed. Let's see about aiming. (It goes very smoothly, but I'm a bit light on tests.)

In the unlikely event that I shoot down the saucer, I'm supposed to get points. Let's make that happen.

The saucer's missiles just emanate from center screen. Time to fix that. I'm not sure how to test it. Oh, wait, I have an idea.

I kind of spiked something. I apologize.

Looks like it's time to deal with missiles and the saucer. It fires, and the ship can shoot it. Which should I do first?

My browser was open to the `random` page, and for a moment, my mind was open too.

The Saucer is a saucy little minx. Let's add some more sauce.

Continuing the saucer implementation in a second contemporaneous article, just to spare your eyes.

I remark on some things I learned from Rickard, and then get started on Saucer. I'm so successful that I had to split the article into two to spare the reader.

Let's see about pulling collision logic off into its own class. Should be easy, he said...

I may have casually been referring to the yellow sticky notes in my keyboard tray Jira as "stories". That's not consistent with my classic advice about stories. And my first-ever pull request!

Today I'll keep moving things into the Game object. Probably boring. One Learning: the current_instance trick was useful. Mentioned at the top for your convenience.

I'll just peck away at moving top-level fuctions into my game class. Tedious unless I get a clever idea. Very boring, do not read.

I think it's time to start moving the main loop code to an object. Very rambling and ambling flow this morning. Lots of thinking, small steps. One roll-back.

OK, let's do collisions differently and see what we think.

I'll pick something off the yellow sticky-notes Jira on my keyboard tray.

Let's see about displaying the available ship count, little ships in a row.

I've done what I intended with the billiards diversion. Let's see what we need here in Asteroidsville. Just small stuff. PyCharm impresses me greatly today.

Rightly called on my B.S., I strive to improve by running some timing tests on this tiny patch of code.

I'll point you to a fairly famous anti-clean-code video screed, comment on that, and explore the efficiency, or lack of it, in our little billiards program. I notice something surprising. And something important.

Rotation of vectors isn't second nature to most folks. Let's describe how my little Python billiard ball reflection program works.

Today let's review the code and improve it a bit. I think PyCharm can help with that. Same refactoring, four times!

We should probably keep score. Shouldn't be terribly difficult. Just some text ... how hard could it be?

For the next day or two, I'm going to do a little exercise on the game of billiards. Very simplified, of course.

Let's add the help messages to the GAME OVER screen, and, time permitting, work on quarter insertion. I expect the first bit to be mostly tedious.

Let's clean up startup and maybe we can come up with a finite supply of ships and maybe even GAME OVER.

I think it's time for asteroid waves. Let's review stories. We create some questionable code and question it. It confesses and tries to reform. What do you think?

Let's do safe entry. Should I put this thing up on GitHub? No one has asked for that.

We'll review and refine the list of things to do and pick something. Doubtless fun of some kind will ensue. Loving PyCharm's auto-run of the tests!

Just some random cleanup, unless I get an easy idea.

Today's story is to make the missiles damage asteroids. But I have a larger question. P.S. I am the Cat ...

Let's see if we can make this thing fire a missile.

Our fun with delegation, plus an early call to breakfast meant that yesterday I didn't get to collisions. Let's work on that today. [Ron makes a rookie mistake.]

It's time for more features and less playing with drawing. This leads me to think about common behavior in motion and collisions. Ron learns something about inheritance and delegation!

Let's do to the ship what we did to the asteroids. And some thoughts about the future.

My search for why the window is double-sized caused me to observe that I can't scale my objects to arbitrary sizes. I think part of the issue is coupling, so that's interesting.

I noticed a graphical anomaly and think I can fix it. And another that confuses me.

One more tweak on the SurfaceMaker, then lets see about using it to make more asteroids.

I'm still pecking away at improving the surface creation. I'm wondering if my caching object, tiny as it is, is more than I need. We'll see. I think I should take advantage of the limitations of the current situation.

I have an idea, or some fraction of an idea. Let's see what we can make of it. (As often happens, I don't go where I thought I would.)

Some advice for a better way sends me scurrying to read about list comprehensions.

We don't even have 200 lines of code yet. How can refactoring make any sense already?

I'm at a low energy point but maybe I can get an asteroid up.

My plan is to wrap the flight path, which I realized last night is 100x easier than I've been doing it. But I was reading about the Rect object ...

Let's just inch forward by making the Ship turn ... and inch forward. I think we basically know how to do this. (I do quite a bit of refactoring, an odd thing to do in a spike.)

I've learned two ways to make the ship transparent. One of them is a good way.

OK, let's fare off on our own here and see about drawing a ship. As I am new to Python, this will entail learning how to create a list or array or one of those things.

I've decided to work with Python a bit. I think I'll enjoy it as much as Kotlin, and I'll certainly enjoy being further away from Gradle.