Category: refactoring

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Continuing Diversion. It's just too long!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

A followup to yesterday's article 'Why does this work?', with questions and answers and some references to folks from whom I have learned.

A reader wonders why I seem never to dig a hole I can't readily get out of. It is curious, isn't it? If this article raises questions for you, please ask them! (More in subsequent article.)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I want to discuss something that GeePaw and I were talking about: sloppy code. My sloppy code.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Another quick look for something needing improvement.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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?

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

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

Let's review some code.

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

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

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

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?

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.

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

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.

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

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.

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

On June 19th, I sent this email to the CPO of the Scrum Alliance. I have had no reply. In a second article today I will offer some related ideas.

Let's pretend we care about that inefficiency in drawingOrder. Also a momentary loss of momentum.

I don't usually predict an outcome but today I think something good is going to happen. Let's find out.

Today, more refactoring to remove connections between dungeon objects and their tiles. And, as always, some thinking.

Let's set some direction. I'm concerned that I'm off track on what is of value to work on. Possibly it's residual fear from decades ago.

I think we'll do a bit more on our 'Making App', the part of our code that helps us make the 'Shipping App', the product we ship. (We decide to bless this effort.)

One more challenge in the class/method finder, then maybe we'll think about what we actually need in our Making App.

I've had an idea about a change--perhaps an improvement--to the class/method reporter. As I write this, even I don't know what happens next.

More work on our nascent Making App. Dave1707 has some interesting tricks in his programs. And we have a fine small example of refactoring 'legacy' code.

Dave1707 from the Codea forum provided an interesting program. I would like to bring it under control.

A Slack conversation brought up the question of why I do ... the things that I do.

In which our intrepid author makes a grievous error: disagreeing with Kent Beck. Or does he?