Category: All Articles

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.

I want to muse today about Small Steps and how they affect me. I owe GeePaw Hill a pat on his cute little head for helping me focus on them.

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.

I woke up this morning thinking about a very invidious, nay, odious, nay, heinous comparison.

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

My mistakes make me laugh. I greet them as old friends. How do yours make you feel?

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!

There are far more important things going on in the world than my Python programming.

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.

Why do we work as we do? How might we improve? We look back at our process and practices in the large. We accidentally invent "Agile".

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.

We can only improve total productivity by improving people and processes. Re: A post from Kent Beck and Gergely Orosz. [cw: "Intercourse"]

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.

This is kind of second-level speculation about what makes my program hard to understand and what might make it better.

Here I speculate and comment on why my decentralized asteroids game is difficult to understand.

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?

It's OK to care about programming. It's OK not to care much about what your company is trying to accomplish. No, really, I'm serious.

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.

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.

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

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'll record here short notes on things that I may choose to write more about in the future, on social topics. I plan to update it from time to time, and to change the date, sometimes.

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.

I do not love that phrase, but I do love programming.

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.

Does everything have to be easy? What about hard things?

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.

Some thoughts on the Alliance holding its conference in Florida, and on some surely well-intended remarks by their chairperson, on their blog.

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.

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

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

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.

Today I want to try to think about the decentralized version of this program, why I like it so much, despite that it is clearly harder to understand.

I typed in some code with one finger, iPad on my lap last night. Here's a report on how nicely it turned out.

Let's see if we can get this thing to cycle around on the screen. I think it's in hand now. (Didn't work, stopped in middle.)

I think that this morning I'll make the little circle drive around the big one. I could be wrong. (Added in Post: We get a test to run, but don't get to the drawing.)

Now for Something Completely Different: A Codea Lua experiment for Hill.

We have three versions for a reason: comparison of their designs. Let's do a bit of that today.

Let's give a splat to the Saucer and maybe to splits.

There's supposed to be a graphical effect when the ship explodes. Let's produce one.

Yesterday as I was summing up, I had an idea for a different way of handling the multiple shapes for asteroids. Let's try it.

It seems that it might be interesting to make the Asteroids spin. I don't think they spun in the original game, but hey this is the 21st century or something. But wait! You also get varied Asteroid shapes!

Today I am quite tired of Asteroids, and particularly tired of this version with its very weak structuring. The foregoing does not constitute a plan.

A bit of duplication starts me off this morning. A nice result, I think. YMMV.

We need to fix safeToEmerge and let's do zigzag. Features! Woot!

Let's get started on the saucer firing at the ship, which I think is the largest remaining "requirement". Added: My testing game is weak today.

I just noticed an opportunity for improvement. Will I stop at just one?

This code is hard to navigate. What can we do to make it easier? Nothing to see here except ... Squirrel!!

This morning we'll try to do the "safe emergence" feature for the Ship. I am filled with troubled antici ...

This morning I'll just continue applying the new Timer, plus whatever catches my eye. At least that's my plan here at the top of the article.

Let's start moving our new Timers into a separate table. That should be "easy".

OK, you talked me into it. Let's see about doing the System part of Entity - Component - System, just to see what it's like. Plastic Sliders??

Now that we've got the PluggableTimer working, let's make two that should be a bit more useful. Added in Post: You may touch the hem of my garment.

My "Jira" is some sticky notes on my keyboard tray. Maybe yours should be as well. Anyway there are some things we might do.

Let's think a bit about making a saucer timer and/or a ship timer, using our rudimentary component system. I think it'll be easy and perhaps educational.

Well, of course I've made a mistake, rather good at it in fact. But have I broken the saucer timing?

Let's see if we can shoot down the saucer. That shouldn't be too difficult, except that I can't remember what the score is supposed to be.

Let's compare the asteroid implementation in the flat version versus the centralized object-oriented version.

Let's just do some little things. Rotate the asteroids, maybe add in the other shapes. But no: A refactoring goes awry. Or agley, I don't know.

Last night we briefly discussed a comparison between my versions. Let's think about that. Alligator?

I think it's time to start on the saucer. What do you think?

There's duplication in the collision logic, and I manage to eliminate most of it with some very simple steps, almost all automated. Nice!

Let's do the drop in animation and the slowing down due to inexplicable friction in outer space's near complete vacuum. Ooo! A lesson unlearned! I wish I were more wise.

After yesterday's social concerns, I'd like to turn my attention back to happier matters, the kill-or-be-killed environment of the intrepid men and women who shoot down asteroids in the interest of humankind.

I feel the need to address intolerance, starting with two topics which I feel are related, "It's OK" and "Lives Matter".

We're keeping score in our head. Let's display it. I fully intend to steal the code for this from another version. We also handle ship-asteroid collisions and provide respawn.

I've forgotten that the ECS technique provides for a bit of polymorphism. We need some and will soon need more. Let's see if we can make that happen.

Today I plan to implement the ship's flare. My reasons are not all good ones.

It's past time for some cleaning, and if I'm on my game, some tests.

Rather than clean up the code more, I intend to bash in asteroid splitting. This is not wise but should be amusing.

ECS is supposed to be more performant because of memory locality. Does memory locality matter on my computer? Let's try a simple way to find out. Also: We kill some asteroids.

I have some thoughts on Entity Component Systems design for this program, and perhaps in general.

I'm not sure what to do this morning. Maybe an asteroid. There are other options. Also: Beck's Rules of Simple Code.

Some design thinking leads the cat's servant to think we can improve our nascent ECS component.

I may be moving toward Entity-Component-Systems design. Let's find out. Further Cat Scripture.

Kotlin's `object` could help me clean up the globals a bit. Shall we allow it? Also: more Cat Scripture.

I think I'll do a bit of cleaning this morning, then maybe other things. I've been given an idea.

I just punched in some code to aim the missiles. Let me share it with you.

Today we'll start bringing things a bit more into a sensible structure. Just a bit.

Perhaps we'll try to fire a missile today. Unless something else comes up.

It seems clear that this 'flat' no-objects version of the game wants to know certain key objects. Let's see how we might deal with that.

The new flat version can draw a ship and an asteroid, both poorly. It can move them along the screen. Let's see if we can 'refactor' toward an actual design for the game.

Let's add a simple object type to SpaceObject. That should let us do drawing in a more generic fashion. Update: Found a better way.

I think we'll do a bit on the ship. That will require me to think a bit about coding standards up in this um program. In Post: This is actually getting interesting!

I often predict in these lines what I'll do, and only rarely is that what actually happens. today I don't even know what I'll try next.

I'm going to try Asteroids in a third fashion, this time more procedurally. I just want to see what it would look like.

I'm working toward some small improvements to the delegation code. I'm not sure it's worth it. I think we'll have to try it to find out.

I think there's a simplification to be had, and none of you people suggested it to me. TAP TAP. Is this thing on?

Let's keep simplifying and see what we can find. Let's work to eliminate the Collidable collection.

'Your scientists were so preoccupied with whether they could, they didn't stop to think if they should.'

In our Zoom meeting last night, I got some possibly conflicting advice. I have an idea for how to resolve the conflict.

It is not given to us to be perfect, nor to do perfect work. But this program, surely it's close? Let's talk about the value of tiny improvements.

Now that the Collision Strategies area all broken out, let's have a look and see what we think about them. Am I reversing yesterday's work? Yes, some of it. That's OK. (Ninth decade? Really?)

After an idea that doesn't pan out, we complete the installation of CollisionStrategy objects. We begin assessing what we like — and what's troubling.

We'll try another one of our CollisionStrategy things. I was hoping for some reuse but am not clear yet how to get it, nor whether its really worth it. I think we'll complete all four Strategies and then look around.

Delegation using Kotlin's `by` seems not to be quite the thing, though I believe I could make it work. I think that late yesterday I invented the Strategy pattern. Let's find out.

As promised, we'll discuss `by` delegation, but I now think that it isn't going to be as useful as I had hoped. I could be wrong, and — oddly enough — hope that I am.

Let's simplify some tests. I think we can get `knownObjects` out of Game.

Let's see how we like the look of the new GameCycler, and review how it went. There are things to do. Could we get more objects to be immutable? That would be interesting.

Let's move some more code over into GameCycler. We complete the Strangler!

Let's look at cohesion, duplication, and other considerations. Maybe we can get a bit more gilding on this lily.

I've gone back and forth on how much type information to preserve. Let's try to compare the two.

With the simpler SpaceObjecgCollection in place, it's time for Transaction. Do we just check out the old version? No, we do not. But why not? Also: You are waffling, sir!

I think we're ready to try the new simpler collision scheme, which is really the old collision scheme from before we started this centralized version. We'll discuss further whether this is a step backward or forward.

I really thought I was finished improving the centralized version, but these small changes will, I think, make things much simpler overall.

There's a lot to like about the centralized version, but this morning I realized that it's far from ideal. Let's explore why and what to do.

Let's explore some possibilities for improvement. Maybe we can even reduce some duplication. That would be nice. Added in Post: Almost a complete waste of time! Dammit! My hopes are dashed!

Last night, I made a change that I now believe to be a mistake. In fact, I did it twice. Further: We begin to draw a conclusion.

With changes to Transaction, I think I can get rid of most of the type checking in the system. I could be right ...

I think that code in Missile is a bit too clever. I may have a better idea. Let's find out. Also: remarks on Jira.

Let's rename all the `interactWithThisAndThat` to `interact`. I think that will reduce unnecessary noise. We'll see.

The new Interaction object is in place. Now let's work to unwind the calls through Subscriptions, moving toward simplifying the hierarchy. Added in Post: Woot!

Let's do interactions in our new type-sensitive style. Let's do it with an object. Let's test-drive the object.

Let's try replacing interactions all at one go. It might not be too difficult. In Post: I do it, it works, I roll it back.

I think we just have one more `finalize` to remove. After that, well, I hope not the Deluge. Also: Do you have a lessón for your minkey?

I'll take another run at finalize. I expect to succeed this time. I could be wrong.

Today, probably, we'll push on with making things more cognizant of type. Probably in Transaction. But let's think first. (Added in Post: we don't do what I thought.)

I'm rather sure there is no active use of the `attackers` and `targets` collections. Let's remove them.

We're engaged in a somewhat extended diversion in our centralization effort, aimed at making better use of Kotlin's strict typing. Let me explain.

Last night, in a stroke of good fortune, I was schooled by GeePaw Hill. I may have learned an idea, and I may be able to learn to apply it. Also, ducks, and an oblique reference to a koala bear. Added in Post: Nice result so far.

Let's experiment today with the sketched collision logic that I threw in a number of days ago. Maybe it has been long enough to see its flaws. Hypotenuse!

This morning, we Big Plan a bit, then do small changes. We're refactoring toward a new design: we're not doing a big rewrite. It's going quite well.

I think we can simplify things a bit by adjusting the hierarchy of our space objects, now that a number of subclasses have been removed. Let's see if I'm right. It could happen.

I had an idea the other day, something I should probably have done a while back, so with a little time this afternoon, I'll try it now.

I plan to wrap up the centralized version of Ship creation this morning, with the concomitant removal of two classes from the mix and the system.

I have a cunning plan for doing the ship insertion in the centralized version. I predict that this is going to be nice.

I have a little time. Let's try another experiment.

It's time to address centralizing creation of the Ship, including hyperspace. This is one of the more complicated bits in the game. (Ron keeps a spike. Shall we withhold his treats?)

I have a test that sometimes fails. I have no notion of how that can be happening. Let's find out.

As we centralize more and more code, the Game class is getting messy. Should we start to improve it now, or let it get worse before it gets better? Some thoughts about thinking.

I have a little time. Let's see if we can take a few small steps toward wave-making. Should be possible, I had it working yesterday.

Today, I was hoping to finish up the new centralized wave-making. But first I need to bring my testing up a bit. Added in Post: Includes Ron's Jira.

Today, I think I'll start on moving the WaveMaker logic into the game. There are issues.

I'll begin this new year as I ended the old one, programming and writing about it. Today, I think we'll work on score.

Now on a somewhat better build, I'll begin by redoing yesterday's changes, and then continue with the centralizing work. Bison?

Continuing to work on creating a centralized version of Asteroids, for comparison with the current decentralized design. Amazing the things I don't know how to do.

I think I can start on a collision detection thing. Shall I test it, or spike it?

An insight and an idea show me a way to approach centralized control. I think it'll be quite nice.

Let's try another way of decelerating to see if we like it better.

While I muse about a different design, there are a few things that we need to do, and I need something to distract myself. Things go oddly but turn out OK. Details in Summary.

Not that this version is exactly done, but I was thinking: Would it be interesting to start over and do Asteroids in a different style?

Going to try for a light morning, as I have an appointment. Let's check the checklist and pick some small but beneficial changes

Yes, I know there's a closed-form solution for targeting. Let's see if there's something simpler. But first, a bit more safety.

The Saucer can fire targeted missiles. Let's explore what we might do about that.

'When things get too complicated, add simplicity.'' Let's try that.

An issue in the design troubles me. I'm not sure whether it really should trouble me, but I think something needs to be done. I really find this hard to think about. I'll discuss why at the end. And I'll tell you what you should do.

The Kotlin game appears to me to have a different scale factor between asteroids and ship. I don't see yet what's going on. I discover that I've done a very poor job. Don't read this, it embarrasses me.

Can you believe that I forgot the flare of the ship's exhaust when it accelerates? No wonder I can't win this game.

The original game spawns more and more asteroids. I'm terrible at the game but I guess we need the feature. Just a little afternoon playing around.

The game should display some info about the keys to operate it. Not that I don't know, or the other person, but there might be one more person ...

When it's GAME OVER and we want to go again ... where do we put the quarter? A HARD DECISION: which way would you go?

I'd like to clean up ship emergence. I believe it can be more clear and if it can be, it should be. BONUS: A movie of the most interesting bug so far.

I think I've thought of a defect. Let's find out.

Best laid plans scarcely get past the first paragraph.

This morning, out of the blue, I plan to assess a core aspect of my Asteroids design: the subscription model. The conclusion surprised me. (Yeah, click bait. Skip to the end if you're that way.)

the OneShot and DeferredAction are looking for places to be used. It's 'small boy with hammer' time!

In which, our intrepid hero has yet another idea. Will this one be better, or just another idea?

Got this thing, might as well use it. Let's eliminate WaveMaker.

Where do ideas come from? I don't know. Where do they go? Into the code, of course.

The game is supposed to give you a finite number of ships. And it's supposed to be possible to earn new ships at certain levels of point score. How could my 'independent' objects do that?

Finalize existed because an object could be destroyed by another object. The unwritten rule now is that objects do not destroy other objects. Can we get rid of finalize?

I improved the Splats a bit last night. I report on last night, think about design, improve Saucer some more, and feel rather ashamed of myself. But good, too.

Let's have the saucer fire randomly. Should be about what I need for an afternoon session.

Let's give the Saucer some more capability. And a question/request to readers.

Too much duplication in colliding. Let's sort it a bit.

As much fun as I'm having with the odd simplicity / complexity mix of this program, it's time for a feature. We'll do the Saucer ... or at least start on it.

Still thinking about the essence of this design and what it implies. This time for the game, not the world. I am fascinated and love what it is ... and isn't. In a real sense ... it isn't a game at all.

Events of the morning cause me to reflect on what the odd design of my Asteroids program might tell us about life in general. Turning social, a bit. Observing, not deciding.

I'm renaming Interactions to Subscriptions. IDEA helps. What else?

Now that all the SpaceObjects are broken out, we have duplication. Let's see how much and how we might improve things.

I think I'm ready to create a Ship class and remove SolidObject (or turn it into ship, whichever works. Let's do this!

I'd like to get my version of this thing closer to the state of Hill's, so that whatever changes he comes up with are easier to assess, and to learn from.

GeePaw Hill and I paired remotely for about three hours on the new 'Interactions' idea that I am borrowing from him. It went rather well, though differently than I had expected.

I feel that I understand something when I can do it, not when I can just use it. Let's try to learn Hill's latest idea.

I want to break all the Solid objects out into separate classes. Have not yet found a smooth way to do that.

An imaginary chat leads to a determination to push this design as far as it can go. Along the way I face an apparent fact.

In which our intrepid author expresses frustration and then gets down to making the program better.

Let's see if I can sort out the HyperspaceOperation a bit.

Fundamental theorem or not, implementation inheritance the tool of the devil or not, what we have is better than anything I can foresee. Full speed ahead! (Three false starts, then success.)

The Fundamental Theorem of Software Engineering is 'We can solve any problem by introducing an extra level of indirection'.

Hill has been learning the code with an eye to helping me understand why he is right and I am wrong. I fully support this and have some comments.

Having written up the theory of the game this morning, this afternoon I feel pretty certain that what's supposed to happen isn't really happening. We need to see what's to be done about it.

Implementation inheritance, or delegation? I've chosen the former in a fairly big way. Why? It seems that I'm evolving a sort of 'framework', and to make it do what I want, I think I need this inheritance. Some may disagree.

A change improves many objects. Summary follows.

Kent Beck has me thinking about cohesion and coupling. Let's look at the ShipMaker with that sensor turned on.

We replace ShipMonitor with ShipChecker and ShipMaker, about the same number of lines but far less intricate. A win.

Tidying. Why are we all setting asteroid velocity?

I'd like to push the new interaction scheme a bit further, returning something less basic than a Pair. A day to make the code a bit better.

Sometimes you just know you have a good idea. Sometimes you're even right. Is today one of those sometimes?

What if we run out of asteroids? What shall we do? Is a GameGod trying to be born? Sorry. Nope. Won't do that. Minor deities, that's one thing. One thing to rule them all? Nope.

I have dedicated the next portion of my life to implementing that cool hyperspace emergence rule. It means that I have to be able to count asteroids. So be it. But how? You'd think it'd be easy. It isn't.

Info from a viewer leads to a question. The answer leads me to a bigger question: Why didn't I think of that? THEN THIS ARTICLE GOES SIDEWAYS.

Let's do hyperspace ... and try to do it right.

My Zoom Buddies made an interesting observation. I choose to respond productively.

Things are a bit ragged here and there. Let's just trim them up a bit.

When things get bad in space, your ship has a hyperspace capability that will remove you from normal space and, after a delay, insert you back somewhere else. There is a chance that you'll not survive the attempt. Our mission today: implement this capability. There are issues.

Before a respawned ship appears, the game is supposed to check to be sure that it won't emerge colliding. How, in our distributed system, can we do that? At this writing, I do not know.

In Asteroids, after your ship dies, if you are allowed any more, a new one appears ... somewhere. Let's see how to make that happen.

No, not young people tweens. Tweens are little objects that do interpolation for us. I think we should have them. P.S. Dealt with that little lifetime issue.

It's 0500, way too early to be awake. I am awake. To keep the demons away, I think I'll see about narrowing the Flyer creation interface. As one does.

Hill tweeted something. Perhaps it had been mentioned at the Zoom Ensemble but if it was I missed it. It seems like a good idea. Spoiler: It was!

Options abound. further cleanup of Flyer seems prudent. But it might be fun to do the Splat. So many choices. Splat wins.

Looking at Flyer collisions, I wonder how it would look if it didn't look like it does. P.S. Two more little refactorings. Free of charge!

I think something needs to be done about the growing mess in the flyers. Let's take a look and see what we see. I'm trying to honor GeePaw's concerns ... and yet ... and yet, I go a different way than I anticipated, with better results.

It's about time ... to work on time. I think the code is telling me something, but I'm not sure just what it is. Shadows in the mist.

I have in mind some learning to do about Interfaces, and possibly abstract classes. I want to work on scoring, and I have in mind a way to do it with a flyer. Spoiler: He shoots! He scores!!

We have an interesting architecture going here, unlike any I've used in these games before. Let's see if it can go all the way.

What shall we do today, Brain? Let's see if we can get this baby under some semblance of control. Spoiler: It's ALIVE!!!

I believe I learned enough yesterday to make a good job of the ShipMonitor today. One question is whether to start over, or move forward. I make the right decision, of course.

I have what seemed, in the early morning hours, to be a good idea. Is it? Let's find out. ARRGH: What we may have found out it that it's too cute to live. HOWEVER: There may be a clean way out.

Let's get the display loop running on a Game instead of a couple of ships. Then I'll see if I can figure out the keyboard connection. Probably.

OK, I've seen it move. Should I plug in drawing for each element? Or test controls?

Creeping up on actually having to display some objects. Maybe I should just do it today?

We're like ten articles in on a video game with no video. This is rather interesting. I'll try to explain why.

I may not get much coding in today, but I have some ideas and will set them down in the few minutes before I have to head out.

The Zoom team 'might have done differently' but agree that current code isn't signalling very strongly how it wants to be. I guess today I have to add more of a mess.

This morning I'm wondering whether I made a mistake yesterday. Well, I must have made some mistake, but I have a particular possibility in mind.

It's lonely in outer space. We need some other stuff up here.

Space objects, as everyone knows, have a maximum speed limit. This morning, I plan to implement it.

Space objects, as everyone knows, have a maximum speed limit. This morning, I plan to implement it.

I seem to be zeroing in on an asteroids kind of game in this exercise. That's probably good, because I've done asteroids at least once before.

I managed to make a test work in the Ship project (its new name). Let's see what we can predict about a game design.

A growing list of questions, and hopefully answers, as I learn about Kotlin, IDEA, OPENRNDR, and all that jazz.

I want to play further with OPENRNDR. I've skimmed the docs. I'm impressed, and probably dangerous.

Yesterday, the OPENRNDR starting project ran on my machine. Today, before studying the system, let's take a look at the code and tweak it a bit.

This morning, I'm going to try to get OPENRNDR running with Kotlin on my machine. I've seen it done on a Mac and on a Windows machine. What could go wrong?

Let's see if we can figure out a clean way to accomplish yesterday's accomplishment.

I think I'll do a bit more on darkness. With some TDD, of course.

First, some thoughts on TDD.

Two stories loom before me: some kind of a magic bridge, and darkness. One of these is easy.

A periodic republishing of habits that I would like to have. New items at the top, but each issue includes all prior items.

I have in mind recreating, or ripping off, some special rooms from the old adventure. Ideally, I'll be able to build these with no new features. Whether we have all that we need, I'm not sure. We'll find out.

In honor of the occasion, I think I'll sum up my current thoughts, feelings, notions, regarding Kotlin, IntelliJ IDEA, and all that jazz. I admire good work. These are good.

Why am I putting so much wonderful capability into a game-making system that will never be used to make a game people will actually play? To tell the truth, I kinda lost track ...

Sometimes something really simple is not obvious. This may be a case for pair and mob and ensemble programming.

A periodic republishing of habits that I would like to have. New items at the top, but each issue includes all prior items.

Further thoughts on the past few days' transformation, followed by looking for similar opportunities.

Can we remove the duplication of the action methods from World and Room? Let's try.

More world-building.I'll try to devise some affordances.

A bit of world building. Will it point up any notable needs? Oh, yeah!

What shall we do today, Brain? Same as every day, Pinky, try to create a world.

It's 0420 and I have an idea. I figure never pass up an idea, so here I am at the keyboard.

I think the Covid jab hit me this time. Just a short article. Anyway, it's Saturday, what do you expect? (We do stumble on a nice result.)

Typing 'go blue' instead of something like 'go east' results in a runtime exception. I take exception to that. Let's fix it.

Converting the enums to Kotlin's preferred rules. Published for the record, whatever that means. Probably means, scan or don't read at all. Nothing to see here, move on ...

Just a bit more play with the Direction and Room enumerations and related code. Should I work out why 'e' doesn't work, or just make it impossible?

I don't know quite what we'll do this morning. Something fun. Let's start by talking about good times.

Often tiny changes can have very desirable effects. When that happens, it may be a sign that things are in decent shape.

Feeling rather done with Gilded Rose, I take another look at the text game building code. There are issues.

A periodic republishing of habits that I would like to have. New items at the top, but each issue includes all prior items.

It seems to your faithful author that we've done nearly all we can with the Gilded Rose. We'll take a final look. Or maybe not final. Who knows?

I want to try another approach to the product-type lookup. I have to try it to see if I like it.

We'd like a better way of getting from an items name to its type. We'd like it to be bullet-proof, but not difficult to manage.

A periodic republishing of habits that I would like to have. New items at the top, but each issue includes all prior items.

I was glancing at yesterday's article last night, and noticed some truly odd code that IDEA generated for me. We'll start there, and I have some improvements in mind.

I'm going to start keeping track of the 'resolutions' I make as I program. I'm sure some of these are generally applicable but I'm working in Kotlin as I start this list.

We are supposed to implement a new feature in the Gilded Rose program. Let's do that ... and let's take a look at where we are ... and where we might go. (Final: We go somewhere rather nice!)

The point of a kata is that we do it again and again, practicing to get better. This isn't really a kata, but it's somewhat like one. (Outcome: Two points to GeePaw.) (UPDATE: Not a bug! Woot!)

I do some microtests. Didn't even take an hour, including writing.

Let's see if we can wring a bit more out of refactoring the Gilded Rose. (Some wiggling back and forth to slightly better code.)

Continuing the long refactoring from the previous article.

One course seems obviously better. I shall choose the other.

Articles 76 and 77 are a long, tiny-step refactoring. Here, we'll preview where we started and where we wind up.

Yesterday the FGNO / Zoom Ensemble played with the Gilded Rose. This morning we'll look at it here.

Mostly I plan to solve the water problem this morning. But I'm wondering about concision. When is enough too much?

Two small changes for your amusement. UPDATE: No, three! Thanks Christian!

Wrapping collections keeps the tricky stuff inside and offers nice clean easy stuff on the outside. That's why we do it, right there.

This morning I plan to encapsulate my map of Item instances, and show why I think it's a good idea. In addition, I'll clarify what I mean by 'always' and 'never'.

Let's keep banging away at the new Item. We'll make them a bit smarter.

Yesterday's work on using the DSL turned up some issues. None of them surprise me—but that doesn't mean I know how to deal with them. Or ... do I? (And: I seem to be feeling whimsical.)

Let's do some world-building, with tests. OK, I admit it: no tests yet. Barely made it work.

Let's fix one of those 'lateinit' variables. They're definitely a code smell.

Some things seem to me to be happening at the wrong time. One issue is the GameResponse. Another is in building the world. What ever shall I do? (I 'discover' TODO.)

Some tidying, but I do need to find a smooth way to do it.

There's not really much left to do here, if my purpose is to build a DSL for Zork-like games. That's a big problem. Today: A nice refactoring in tiny steps.

A quick test of a simple idea seems good. I am pleased.

Let's make some progress toward Room actions. Some fairly nice refactoring and feature addition in here. Includes: praise for IDEA and Kotlin.

Let's see if we can untangle things a bit in and around Imperative, Phrase, and the like.

Back to the Phrase-matching find. I'll grow it incrementally this time ... and it works! Life is good.

OK, with that off my chest, we can do some code. Let's keep after Actions and the associated items. Things do not go as I expect.

Some Twitter chatter and a moment of not knowing what I wanted to code this morning has led me to think about what people should do.

I think this morning's thinking was good enough to deserve a chance. Could my thinking be wrong? It has happened before.

In which, our intrepid hero realizes that while thinking is good, clear thinking is better than muddy thinking.

A really nifty idea collapses. Yet, I ain't bovvered! Come read and find out why.

Let's do a bit more on the SmartMap, and then try to get it in play. (Spoiler: It works nicely! I am pleased.

I have what I think is a very nice idea. Let's talk about it and then start working toward it. Is this BUFD?

Now I'll try adding something to my actions collection, first in regular code, then tomorrow I'll try to add the capability to the DSL.

Let's look at the Actions in the new Imperative. Advice from my betters suggests I could do, well, better.

Report and confession on last night and some behind the scenes grunt work.

Let's make the Actions in the Lexicon do their job. There are some issues ... do we resolve them? We do and it's great! A big lesson is relearned.

This time around, I'll plug the Imperative into the game, or know the reason why I couldn't. I'm hoping for the former. (Spoiler: works!)

Let's find more small steps toward replacing the old Command idea with Imperative. I have in mind providing a Lexicon in the existing structure.

I want to move the testing bits for Imperative back down to the test branch, segment, section, whatever it's called. IDEA impresses me.

This morning, I want to try a different way of mating the new Imperative to the existing scheme. First, I'll have to figure out what that scheme is, and whether there's anything in it to like. I suspect there is.

Let's put this in context. No, I'm not explaining. We're going to put all this into Context. Includes Shiny Squirrel pattern.

Let's see about converting the `when` to a table. Sounds easy enough.

A bit more work with the new Imperative. In reviewing the code, I'm not sure what else it needs to do the job. After a bit of testing and enhancing the tables, I'll think about whether and how to use it.

This morning I plan to share some early thoughts and perhaps turn them into code. (To enjoy this article, please set your expectations to 'I wonder how Ron might go from a vague dreamy idea to something that might actually be useful'.)

I think I'll experiment a bit with a Command object and its context. I'm not sure where this will lead. Perhaps to the bit bucket.

Some interesting insights from last night's Zoom inspire me to morph my design. A lot of thinking, a little coding. A decent direction, I think.

A fix for the warnings, but do I like it?

Today's plan: plug in the new parser. We'll need to refine it just a bit, but I'd like to get it in play this morning. Best laid plans ...

Let's see about cleaning up that `expand` method.

It's 0525. I want to begin to try something before actually starting my day. This may go somewhere interesting, or crumble to sand in my hands. (Spoiler: I think it went rather well.)

Refactoring in the direction of what we think we might prefer. Beck said: Make the change easy, then make the easy change.

I get good advice from my betters. In the face of that, I forge ahead.

Let's do some very simple parsing.

A little refinement, and then let's press forward on Picov Andropov objects.

At a more civilized hour, I have an improvement in mind. And it's really time to start doing something about inventory. And, curiously enough, I am rather successful.

It's 0415 and I'm awake, with what seems to be a good idea. Is it a good idea to program at 0415? That remains to be seen.

Let's push the Spike in a little deeper. I've got some ideas for how it could be quite nice. Good ideas? We'll find out.

Yesterday, in an astounding flurry, I made a magic word open a lock. I also made a bit of a mess, which is partly good but probably mostly bad. Today, I set out to improve the code—and the feature. (As usual, that's not what happens.)

I want to set up a test world where you have to say a magic word to open a door, or something like that.

When we make two changes at once, there are four possible outcomes, and three of them are bad!

Still working toward the View displaying our new 'say' text. Might make it this morning.

I think the next thing I need is for a message to come out in response to a command. We need an extension to GameResponse. (For once, reverting would have been the wrong thing to do ... probably.)

I have some design thinking to report, but my hope for today is to have an operating grate somewhere in the world. I manage a good first small step.

I need smaller steps. The Game sends the command to the current rRoom. But the World knows the rooms, and neither the Game nor the Room do. Let's try passing the World to the Room.

In order to find out what our DSL should be like, I propose to code up a few scenarios 'by hand'. I make some progress but not as much as I'd hoped for. Lost thread. Reverted. Good man!

Now that the game can be played, more or less, it's time to think of some scenarios that we need our DSL to support.

Inching forward. Pretty sure I can make a TextField work. Final Result: The Game is Playable!

There must be text things in JavaFX/TornadoFX. Everyone has them. How hard can it be? Wow, I hate being ignorant. But I love learning!

How bad is it when you actually EXPECT your own article to be boring? I'll do my best to say something interesting. Includes a very long sentence and a small but important win.

Time for a little planning, and some worrying. How far can I go before making this thing somehow playable? How far should I go? Bonus: A devil duckling!

I wonder what we can do about output without actually having a way to play the game ...

I'm psyched after two consecutive sessions with some success and no big troubles. What could possibly go wrong?

How about a bit of code improvement? That might be fun.

Let's parse a bit more of the DSL (Dungeon Scripting Language?) and then see what happens. I have high hopes, tempered by decades of experience.

Let's try something specific with the DSL builder idea. I have in mind a text game like ADVENTure or ZORK.

In which your intrepid author suddenly realizes something, and decides to do something he rarely does.

I want to understand DSLs and builders. First, I have to figure out how to make a new project with tests in it. I anticipate an onset of grumpiness as I learn new things.

OK, I'm feeling like working on acceleration.

I have tidying to do, and some stories to implement. At this writing (0815), no actual plan.

So few lines, so many design questions. We'll work more on Ship motion. (I manage some whimsy. Must be getting more comfortable with IDEA/Kotlin.) P.S. Learned a thing.

OK, let's see if we can code up an operator in this baby. Overall Result: Much more comfort.

Let's plug away, learning IDEA, Kotlin, and whatever, while also seeing how much TDD we can do on an essentially graphics-oriented game.

First some grumbling, then an idea for something useful that I've not done before.

I'm inching forward in my learning of Kotlin and TornadoFX. Progress is happening, but so slowly that I can't write as I usually do.

We've all agreed to fork the repo. I'm on my own, more or less, and already confused even though I haven't even started.

After more than a little hassle, my colleagues and I have a Kotlin shell that we can pass around. Today, for fun, I'm going to try to write some tests and code.

Perhaps the biggest mistake in XP and Agile ...

There is a sticky note on my desk needing attention. Let's attend to it. I have a small concern. Also: smaller steps pay off.

Usage changes. Language is usage. Language changes, not necessarily for the better, in my opinion.

I wonder why I'm doing what I'm doing. Meanwhile, requirements changes to the robot's radar result in some design issues.

I've decided to deviate from the spec to make my work with this example more interesting (to me). I anticipate no real difficulty with this extensive set of changes.

Today I have to find a way to do it right ... and light. How little can I do while still improving the code?

I think we need to improve the map display a bit. We'll spike, and that's going to prove a point that I made yesterday, I hope. Or disprove, in which case we can laugh at me hahaha.

My Customer (me) wants the radar screen rotated to forward = up. The developers (me) are happy to oblige. P.S. Came back later for the thrilling conclusion.

Maybe we need a bit of console display. And I'm sure we'll find some code to improve. Foraging, basically.

Let's not allow movement into obstacles, and maybe penalize moving into pits.

I found a little something. And some other somethings.

I have an idea for something that might be better. But that's not my reason for being here. (And should all ojbects be written for their own convenience? Yes, and ...)

Let's slide in the remaining callbacks, and see what else we can see before brekkers.

My Inner Eddie says we may be in big trouble. Let's find out. ClickBait: Absurd claim at the end.

In which our intrepid author takes on important notions while scarcely mentioning the actual topic at all, hoping to enlighten himself while offending no one. Tall order.

Oddly, I take as today's writing prompt, a strange tweet from a person of curious name.

Let's see if we can get the new connection object to run as if it were on a thread, even though we don't have threads. That should be amusing.

More on TCP/IP. A realization that might have come sooner, but today's OK too.

I've been trying for days to get a decent TCP/IP socket connection working on the iPad, apparently for my sins. So far, I've failed miserably. Today, Saturday, another try.

More on server code. I have an idea. Should I try it? Answer: no.

I think we have only one hard problem remaining. Let's see what we can do about that. MORAL: Don't be like Ron's brother's brother.

Well, I don't know. A bit more on motion. Maybe a start on scan/look? Oh and a better look for the robot?

Let's turn around and go backward, and see whether we begin to see some improvements to how we do these things. RELEARNING: I need smaller steps.

More on Request-Response. Maybe some little objects?

Moving toward standard request-response. Seems about time. But Never would be better. ALSO: A very brief introduction to industry standards of completeness.

I've made a mistake. Or I'm about to make one. Or both. Certainly not neither.

Today we work further toward accommodating the 'spec'. I think we'll focus on the robot status. I think I may rediscover why something is a good idea.

We need to make the robot-world communication a bit more like the spec, and a bit more like client-server. Then we can make more progress. ERRATUM Near the end.

More on the JSON connection. I think I see something symmetric, if not actually easy.

The spec requires us to communicate using JSON. It's time to get started with that. As I type this I wonder something ...

TCP. I think I know what I did wrong yesterday. If I can make this work, it'll help me TDD the server's main loop. Bonus: Kitty!

Let's try more than one connection. Do I need coroutines? Let's try without. LEARNING: I seem not to be able to have multiple connections within this one program.

I'm spiking TCP. Not writing the article as I go. Instead, I'll record bits of progress and what I may have learned.

Something in last night's Friday Coding Zoom struck me. I need to think about this and try it.

OK, sockets. At least for a little while. And a conversation with myself. No, I'm OK, really. And thanks to Dave1707.

Let's start by talking about design. Software design. I definitely don't know anything about any other kinds. Interesting thoughts interwoven with vague mumblings.

Let's review some code.

Try again. Fail again. Fail better. Been down so long, it looks like up to me. Summary: Much better.

Let's see about helping the robot understand the new 'look' tables. I feel sure that I'm going to want an object up in this thing. The outcome may surprise you.

Today's demo day. We're good to go, but I think we can do better. Anyway, gotta do somethin'. Anti-Spoiler: I decide not to spoil the code for the sake of maybe a feature.

Rotation Matrices? Why not, might be better. Let's spike. Warning, this is gonna get a tiny bit mathematical.

Awakened by a strong rainstorm, I decided to get up and watch it. I'll code a bit while I do. I'll try to think before, during, and after coding.

So many good ideas. But we need to ship it. We'll talk about that—and get ready to do it! UPDATE: Walking skeleton works!

I think we're ready to draw something. How can we make the drawing more testable? I have a p-baked idea, for small p.

First we do a Lens. Then an amazingly smooth, very long, step by step refactoring. I'm proud of this one!

I have a bit more time and an urge to do some code improvement. Let's see what we can do to make all this a bit easier.

A bit of musing about the world, a bit of planning, a bit of coding. It's Sunday, so this will probably be short.

Working toward a 'walking skeleton'. I think I know what I'd like it to be.

What do skeletons have to do with robots? Could there be more than one skeleton?

Day 2. I did watch a couple of GeePaw's videos. Good news. Thinking ensues. Concerned about Knowledge.

Tuesday night's Friday Night Coding Zoom has hooked me. This is the beginning of the result of that hook.

Completing a refactoring makes a feature easier. Unless I'm wrong, but I'm not.

Apparently not Done-geon. Those missing tests for that trivial code bug me. There's something to learn in here. LATER: A very nice outcome!

Unable to do nothing, I made a 'simple' change to the Dungeon program. It works ... and I don't like it. Later: Sometimes doing the right thing doesn't work out.

Some thoughts after another pleasant conversation with Colin Hammond of ScopeMaster.

If in fact I'm done, for a while at least, with the dungeon program, what shall I do and write about. Your input welcome.

Countdown to ... what, exactly? Let's check the yellow sticky notes. Time for a break from Dungeon?

Let's clean up those free-hanging functions just for fun. It'll make things just a bit better.

I think that today I might get all the Decor specified for all the dungeon layers that are supported. That's an estimate, and I could be wrong. (Spoiler:not wrong, and some nifty refactoring.)

Let's work again, on controlling the dungeon layout. My objective this morning is to define at least one level's Decor. I'm extending the story based on feedback.

No promises, just a look at Tile and its friends.

This one's gonna be rambling. A design idea keeps coming back to me. I feel that the program would be much better, if ...

I was asked what I tell people to do that I don't do myself. The answer may surprise you.

Up-front Design? In Agile? Sure, let's do some. I call it 'thinking'.

More on improving control over Dungeon creation. And a RAT. And a bear bite, kind of.

OK, with discussion of ease out of the way, let's get some ease up in this Decor.

We should have it. What should we do when we haven't?.

I start out to think about that clever trick and my plans for Decor. Then I change direction based on what I've learned. This has important implications for estimation, COSMIC or otherwise.

Let's work on the Spike aimed at creating DungeonObjects. Uh oh: Something too clever has been done here!

Still working on better control over creation of Dungeon Objects. I think I'll do a Decor factory method this morning. I can't think how to test it. The Internet helps me.

Estimation and a tiny bit of code. ScopeMaster took up my challenge.

Let's start on the Dungeon Object allocation story. I think we'll start in the middle, or near the bottom. So far, no takers from the pro-estimation folx. UPDATE: Hammond has done CFP for the story! Details tomorrow.

I don't like estimates in this world. Perhaps you do. If so, and you're so inclined, pick up this challenge. I'll tell you everything I know to help you.

This morning, I plan to write about COSMIC Function Points, Agile Practices, Civility, and Kindness. I can't wait to find out what I have to say.

Some thoughts on something GeePaw said. And I think we'd better complete the fixing of the publish situation. What is `the best we know how`?

Friday the 13th. That bodes well, always my lucky day. Besides, it was yesterday where I interfered with the canine. (Oh No! He did it again!)

Time to pick something to do. This always surprises me. Late update: THIS IS NOT GOOD. WE HAVE A MAJOR SHIPPED DEFECT!

Today I'm going to try to learn something. I wonder if I'll learn what I set out to learn, or something else.

Loose ends. Finding little things to do. Generalizing from few cases and many years. Delenda Chicago est.

A bit of thinking and doing with the `publish` feature. Small changes, much thinking.

'Nothing at all', the game says. What's up with that? And various musings.

Colin Chapman of Lotus said that to add speed, you must 'add lightness'. Can we add some simplicity up in this dungeon?

Let's apply some of the ideas from D3 in the curreent Dungeon program. We'll see whether they're a step toward a better design.

I'm wondering whether I need the complex publishing approach that I'm using in the Queue. Only one way to find out: reasoning fails me. (As always, I wind up somewhere else.)

More work on the new event-driven scheme. I hope to get to an interesting problem today.

What have I learned in this Dungeon Crawl? What would I do differently? I've decided to find out.

Yesterday, testing something required my code to be a bit less smooth than I'd have liked. Today I have an idea that I think is going to be quite fine. It's not even too clever.

We need to talk. We need to code, as well. And we need to test. A nice result, a better commitment.

Let's check our stories along the way to better control over the trash, er, treasures in the Dungeon.

Let's do some messages.

What do we do when we find two classes that are rather similar? We make them more similar, of course! (That''s not what happens.)

More work on improving the ability to place Dungeon Objects. Today I want to look at Decor and Loot. What will really happen? I never know until I get into the code.

I saw an interesting contagion-related graph on Twitter and decided to do something like it.

Another run at the current Big Story. Need to find something that will lead me away from confusion rather than into it. Might have to think. Might even have to draw a picture.

More on providing control over placing things in the Dungeon. I'm thinking about changing my mind, but I might change my mind about that. (Spoiler:Bear bites man.)

We're still prepping for the story about better control over what goes into the Dungeon. Some things remain that I'd like to clear up. And a small story!

The FNCS has spoken regarding the defect. I do some smoothing. Multi-signature method? Possibly. I ain't bovvered.

I have shipped a defect, and a serious one. What happened? How could I have avoided it?

Planning Meeting. I'm not sure what to do today, but have some ideas.

Pushing the object further down. What does he mean by that?

Let's look at some of the 'story' cards I've saved up and see what we might work on.

Just a bit more tidying, as Kent Beck puts it. Soon, new features or something. But today is not that day.

The experiment i did yesterday deserves a bit of commentary. Something to think about.

My plan for the day is to find a place to try out my clever idea, so that we can look at it in place and decide whether to allow it. Will it stay in?

A bit of Internet dispute about cleverness. When is code too clever to live? I have an example in mind.

A couple of working diagrams. Here's why I think rough diagrams are quite often good enough.

Drug-free, our intrepid author looks upon his works. Does he despair? (Spoiler, No, Mikey likes it!)

Today: Recovering from a couple of days on Nyquil. Is my brain operating?? We'll see.

Gonna refactor you a little bit more ...

I think we'll look at some of the methods that analyze the dungeon as part of building. I'm hoping for a good idea to pop up. TL;DR: Ron is out of kilter, copes, then stops before doing damage..

Back to tiny steps, if I possibly can. And you know what? I bet I can.

My side quest to move dungeon building out of Dungeon class continues. What monster shall I slay today? Let's find out. (Stress level too high. A clue.)

Continuing separation of building from running. Today, narrowing the scope of Tile. An idea for a better way of doing it. A good idea? I'm not sure.

Last time I had part of an idea. Today I have a larger fraction of the idea. Let's see if we can get all the way.

What are you trying to prove, Ron?

Pecking away to reshape things more to our liking. Small steps in roughly the right direction, that's the ticket.

Are we missing some layers in the Dungeon? The classes, not the places.

Reducing the span of concern for Tiles. Seem like a good idea. Will it be too difficult? Let's find out. (Spoiler: Almost, but not too difficult.)

Some tiny improvements ... or are they?

There's probably a bit more to do on isolating dungeon building from dungeon running, but the low-hanging tasty fruit has mostly been harvested. As for larger design improvements, I am at a loss. That may be a good thing.

Here, some thoughts raised by yesterday's Agile Alliance Zoom thing.

You'd think that software developers would realize that they are prone to error. Yet we are often more opinionated than we probably should be. Here's my opinion on that.

Plotter or Pantser? Which am I? Which are you?

Let's look at what we've done and see what might be next on our quest to separate building from running the Dungeon.

Let's do some more opportunistic refactoring toward DungeonBuilder. And I have a few thoughts to think about the direction I've taken.

Here are just a few of the unsolicited favorable comments I've received about 'The Nature of Software Development'. Some drawings included.

More gentle refactoring in the general direction of DungeonBuilder. No Monty Python reference intended.

Still trying to drift in a good direction. So far we've just barely improved, if at all.

Trying again. Last time was a disaster. I'll sum up.

Oh Hell, let's just do something in roughly the right direction.

Time to set a tentative direction and move that way. I am daunted before even starting. No code today.

I found myself wondering what I'd do with this program if I started over. I shouldn't do that. But what I could do ...

Today I plan to just look for some small opportunities to improve the code. I will be particularly looking for ways to use my fp primitives, and to improve them to make them more useful.

I'm disappointed, at least so far, that my 'functional programming' capability seems not to be helpful in the Dung[eon] program. But maybe there's still hope.

In which: Our intrepid author attempts to find some use for the FP library he has been toiling on for over four hours.

Today, for your delectation, I offer: the Library Trap! (Update: I looked at XSet2.)

Let's see if we can find a decent way to provide filter, map, reduce functions in Codea Lua.

Kent Beck is writing about 'tidying'. It's a whole patch of delicious strawberries, and I highly recommend them.

Yesterday's search for strawberries in the XST patch discovered problems. I want to at least double check what we did. TL;DR: It all works. Odd morning.

We're taught to 'make it work; make it right; make it fast'. We're taught that if it's hard to test, it's not right. Let's explore. TL;DR: No strawberry here?

Further thoughts on the river, the hill, and the nature of reality. I don't know why I wrote this. It's just here in today's part of the big integer.

A river flows rapidly down a hill.

Can we make our programming life immediately easier with this one simple trick? The answer may surprise you.

Some day--and that day may never come--it may fall to you to write the most important program of your life. Here's one man's example of how to do that.

One 'reason' why folx don't want to learn technical practices seems to be that they expect no benefit. Sometimes that's more about futility than actual benefit.

Some developers show little or no interest in learning practices that could make their lives better. I'd like to understand that.

I don't know whether this is good or bad, but it's an interesting trick.

Wandering off. Spinning down. Fading out. My projects here have a habit of that. What does that say about me, about you, and about our work? And krill? Really?

In my thinking about Strawberries, I'm wondering what issues folks have with Scrum, good or bad. Please tell me. I'll mention some ways here.

There are signs and portents. What are they telling us? Is this death--or is it perhaps a rebirth?

I'm taking a couple of on-line comments as writing prompts today. Let's see what we get.

Today I learned a new term. Maybe better/worse than 'Dark Scrum'. (TL;DR: If it isn't joyful, we're doing it wrong.)

Agile Software Development is about people working together. For that to happen, it helps to be kind, respectful, and helpful. Let's talk about that.

I'm pressing forward with the Lispy thing, but I have some concerns. I find it difficult to think about but I think I have an angle. (Spoiler: It's a wrap!)

TDD is too big a lump to be a good strawberry. Today I'm playing with TDD to try to find a bite-sized goodie. I expect not to accomplish that.

Technical Practices, Craft, Excellence, Improvement, Ease, Joy. What ARE you talking about??

A Twitter exchange yesterday and today has given me today's topic. I love it when not having a plan comes together. (Hm. Societal impact is similar ...)

Let's consider the implications of small-step development on our three shadow views of the program. (Includes Sarlacc.)

Yes, short feedback cycles are good. But is the trick of the trade 'small', rather than 'short'? The answer will not surprise you.

Working software is at the core of success with agile methods. Let's remind ourselves about that.

GeePaw Hill is workin on an idea. I urged him to publish his thoughts because I knew it would help him to make things concrete. Also I wanted to comment here.

I wasn't really planning to write about Sudoku again, but here we are.

I know what you're thinking: 'Is this four rules or only one?' Well, to tell you the truth, in all this excitement, I kind of lost track myself. You've got to ask yourself one question: 'Can I use this?' Well, can you?

We're here to replace raspberry jam with strawberry jam. We need those delicious nodules of flavor and value.

It's not the method. It's not the framework. It's your unique assemblage of innumerable small things that work together toward success. And some larger things: the people.

It's Wednesday. At last night's Friday Zoom Ensemble, we talked about Jam. I am inspired to put down some thoughts. Bottom line: On-line strawberry, not raspberry. (Updated, more links.

Just a bit more playing with the Lispy Calculator to while away a few minutes in the afternoon.

Thoughts and observations. Stuff and nonsense.

I'm going to push forward with this LISP / Scheme dialect. I'll begin by explaining why, and why not.

It's still the weekend, so I'm going to follow Peter Norvig's Python LISP Implementation a while and see where it takes me.

It's my weekend and I'll try if I want to. You could try too if it happened to you. Spoiler: This takes a very weird turn. Final line: Your move, Bill!

I guess there's nothing for it but to figure out how to rewrite, i.e. refactor, a set operation based on the existence of helper structures. But how? I have ideas but are any of them any good?

Bill Wake is trying to get me to think in terms of trees. I don't want to, but he does have some good ideas. Thanks, Bill!

Today I plan to experiment with creating some form of expressions that might be optimized. I expect to stumble a lot. Come along, point, and laugh.

No, not smiles and frowns. Algebra. At this moment I don't think much code will be done today. Feel cute, might delete later.

It's 6 AM and I have an idea. This could be very good or very bad.

I don't love the interface for adding functions into an XSet. And I want to add them 'one level in'. Will hilarity ensue? Probably not, but something will happen.

Some HNY thoughts, and more on the function as an element idea. Joy, philosophy, code. What's not to like?

I was thinking before I got up about median and mode. Then I had a truly marvelous idea.

I want Lua tables to be more useful as XSets. There's a hard way. But the current design also offers an easy way. (The answer will surprise you. It surprised me.)

I'm on a path to make ordinary tables behave like XSets. But first, I have to figure out how this thing actually works! Much musing, then some code.

I have in mind small things for today, starting with an interesting and confusing mistake left over from yesterday.

No, I'm not hearing voices. But the code does tell us things, just like any working material. We need to learn to listen. Today, we listen and the result is good.

A look at the code. Maybe a bit more on stats. P.S. I learn something and ditch almost all the code I wrote this morning.

It's Christmas, I'm waiting for the household to wake up, and I enjoy what I'm doing. Perfect holiday so far!

I didn't do the best possible thing in this morning's XST article. Here's what I think about that.

Today I plan to get grouping and summing working. Who knows, it might happen. If not, there's always tomorrow or my birthday.

Let's think about what the current drafts of summing and grouping tell us about our system. Then code (anyway).

Today, rather than make any deep progress, I plan to work on something I consider interesting, sums, averages, and grouping. I promise to publish this even if it explodes. (It doesn't, quite.)

Transformations, optimizations, and the relationship between OO and XST. Got some thinking to do. You get to watch, if you're tough enough. At least a tiny bit of code.

Step by step, inch by inch, slowly we turn long searches into more direct accesses.

I don't want to get stuck in a never-ending series of new setops: there won't be much learning there. Where's the beef?

I'm sure a lot of you have been saying 'Yes, but what about tuples?', or 'Why XST anyway?'. Today, we address those fascinating concerns.

Let's work on those new operations a bit.

Short morning today. I have a tentative plan for indexes. I'll scribble some sets. Might code.

Last night's Zoom Ensemble netted me a few ideas. I'll start exploring those today. Hilarity or perhaps something good will ensue. I can't wait to find out.

Further reading leads me to think about design, and design motivation. Castles in the air. Or underground. Good stuff happens.

In conversation with Bill Wake and with the Internet, I have an idea for something to try. And I'm just about ready to assess where we are and where we should go.

I'm not sure whether this will be useful, but Bill Wake gets the credit if it is.

Bill Wake was trying to hammer an idea into my head. I must think about that. And I have a small idea of my own.

Time to work on the actual restrict operator for CSV, since the pattern-maker experiment was a success.

There's no way around it, I've got to work on the fast restrict today. Might not finish. We'll see.

Getting started with CSV data. And reporting a conversation.

Reflection leads me to focus a bit more on set operations, and less on internal methods. Does this call for a new layer? Also: real technical debt! Updated with idea from Carl Manaster!

I'm going to try to create pipelines using coroutines. I think they may make for a more expressive interface. I turn out to be partially right.

How do you design a thing like this, Brain? Same as everything else? Or not?

I was puzzling over an issue with 'union' and gained an insight that either I've never had, or that I had lost. Whee!

I found the easy way to build an iterator in Lua, so we'll do that and see whether it improves the code as much as I think it will.

I think I'm going to start on restrict today. There are some issues around atoms.

Last night I understood how to do something with XST that I've not in the past been able to do. So let's talk about why XST is interesting and what one might do with it.

I have a random idea about the data structure for sets, so thought I'd give it a try.

Save me, I'm thinking about Extended Set Theory again.

I have a mad scheme for making an object move using applyForce and momentum. (Arrgh, results suggest that we need to file a bug report.)

An experiment by Dave1707 inspires Ron to figure out what's really going on with applyForce. Will he succeed? The answer may not surprise you.

Ooo, an accidental play on words. We're going to change our cube's direction, but also the direction of these articles.

On this day of thanks, I'm moved to think about all the -isms that seem to plague us, and how to deal with them.

We've learned how to move things using code. It turns out that Codea can handle moving them for us, for fun and profit.

I think we need to learn about Craft physics so that we can tutorialize something about it. This turns out to be a bit of fun.

Here's how you really do that. An improved design for our entities.

A couple of new entities lead to a design concern.

In this tutorial, we'll make our cube move around the 3D volume a bit, then improve how it looks. And we'll improve how we look at it.

Converging on a plan, I decide to do a series of tutorials. Herein, an explanation of what I mean and intend, and the first one.

I'm setting out to learn, again, about Codea's 'Craft' capability, its 3D voxel-based facilities. Today, I'll talk about my reasons, ambitions, and look at some code.

Just because I think I should do SOMETHING, I think I'll improve how CodeaUnit displays results on the screen.

I'm going to try to build a 'fluid interface' feature for Codea's graphical style capability. Why? I don't know.

Let's improve CodeaUnit a bit. But first, what's the deal with iOS shortcuts? An odd report on an odd morning.

Driven by some Slack chatter, I've been thinking about feedback. How does that fit into life, and into this little program?

As requested.

Some refactoring, and some thoughts on a Twitter thread. And an odd surprise: the code says No.

Rules, rules. TDD rules, Beck Rules, OK. And a cat.

I'm just not up for going back into the Dung mines. Gonna put plain function detection into the stats instead. Also, random subtweeting. Also bear bites man.

At last, I get to apply Dave's scrolling thing. It's simple, and obvious, and I never thought of it. And a couple of stories of a great programmer.

This morning, I plan to add detailed method reporting to the full report. I am expecting no real trouble but have recognized a mismatch.

Let's get some output up in this baby. I plan to steal two good ideas while I do this.

I wonder what we could do about comments. They're tricky.

"If this is his idea of fun, he must be a laugh riot at parties." -- A Reader

Backward? Or forward? Which was it?

We continue working on our little 'Making App', because it's kind of fun. Today, I foresee a 'major refactoring'.

Let's do methods, and try to drive out some objects.

In the interest of variety, let's do some work for the makers here. Let's see how we can collect some interesting statistics from Codea programs.

One small improvement. Then I want to consider the bigger picture: if I were starting over, how would I do this program differently?

Late start today. Not sure what to do. Try the hex map again, I guess. Feeling meh. But it works!

Let's continue to prepare the Dungeon class to work on hexes as well as square tiles. I expect no real trouble. I look forward to learning why my expectations will not be met.

I have in mind a fun small win on the path to hexes: a multiple dispatch. If nothing else, you may be surprised at what I think is fun. (And I do get in the weeds a bit along the way.)

I said I wasn't going to write an article today. Was I wrong? I want to just look around. And some thoughts on self improvement.

I found the defect, and I think I can fix it. Let's find out. Then I rationalizeXXX explain something.

What's the deal with Jira? Is it a bad thing, or the worst thing?

I'm thinking of adding a shark to the game that you can only escape by jumping over it. Today, however, a bit more on Maps.

Already wrote one article today. Not sure about this one. Probably I'll find an acorn somewhere.

We were thinking about words for code. Let's consider these. New! Improved! Now with more words!

Well, I guess there's nothing for it but to forge ahead getting a hex map to draw. I rather regret committing to this idea.

Can I make a hex map in the game yet, or do I need more than a couple of changes? I don't know. Let's try to find out. Spoiler: Not great, not horrible.

Today, I'm going to try a fun exercise to demonstrate Codea's translate, scale, and rotate.

Today my cunning plan is to try to make the Map the primary container of Tiles, and the tiles collection secondary.

My commitment for the day is to be using the new Map objects for something in the actual game. I think I see at least a couple of ways to go. Spoiler: It's in!

Today I'm going to start plugging the new Map classes into the actual Dung program. I expect a little chaos. For large values of 'little'.

Let's keep on drilling. Real soon now, we'll have hexes in the game.

Another idea? A possibly better idea? We don't pay you to think, we pay you to do.

I promise, I'm nearly ready to plug in the new hex coordinates. There's just one more thing that I want to do ...

In Agile, there's no design. Everyone knows that. So why is there so much design in Agile, and how can they go so fast?

No, not really. Cartesian coordinates, perhaps. Yesterday I was optimistic at session end. How will I feel today? Let's find out.

Frequent readers know that I try to keep my code well-organized and well-designed. No one is perfect. Well, I'm not. Today we face mistakes.

Today I'll do the first experiment, or a few of them, putting hexagonal tiles into the Dung program. I expect this to get really messy, but with luck, we learn a lot.

Today I want to step back and write about screen transformations, translate and rotate. They are fairly natural to me, but some folks are not so familiar with these powerful tools.

In a fit of madness, I decided to try to convert the square-tiled Dung game to use hex tiles. Let's see how well my theory of programming holds up. Just inspection and planning today.

I have to face facts: I simply enjoy writing code and making it better.

Today we'll talk about why no one should do what I've been doing the past few days, and intend to do for a few more.

Bill Wake found an interesting site about hexes (not the magical kind) and now I'm not sure what I want to do.

Let's push this Hex spike a bit further, see what we can learn. Come on, it'll be fun. You can hold my beer. Well, chai.

An idea from the Zoom Ensemble last night has caught my attention. Let's explore it.

Notes on getting up and running on my new Mac. Probably not an interesting article, I'm writing it as a letter to the future me.

Two ways of doing a thing appeared on the Codea forum today. I'd like to see whether we can transform the one into the other in small steps.

Another in my continued attempts to come to terms with what Scrum is rather than what it could (and should?) be.

Satire? Idiocy? Monkeys? Why not all three?

Again today, I take my writing prompt from GeePaw. I have a good purpose in mind. (Added: Dammit. I didn't expect to end up here.)

Is it useless marketing BS? Certainly there are issues. [CW: language, systemic racism/sexism]

Events in a few worlds lead me to write a few words about how we treat each other.

When someone shows you who they are, believe them the first time. -- Maya Angelou

I've had a reply from the Chief Product Owner of the Scrum Alliance.

I think that today I'm going to write about joy. I have no idea where this goes. Walk with me ...

I mentioned that the dungeon program is boring me on Twitter and asked for ideas. Andreas asked about software design. Practice, folks, practice!

Are we ready to lock classes? Probably not yet.

I'm bored with this program. What shall we do about this?

Jeff Patton writes about the importance of outcomes. Yes, and ...

I've think I've figured out the disconnect between my view of the Scrum Developer priorities, and those of the Refactoring Team who created the new CSD track.