Category: robot-world

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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