Category: Practices

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.

Markus Gärtner interviewed Ron Jeffries, co-author of the Agile Manifesto and Coach of the first Extreme Programming team. Ron reflects back on the past 20-or-so-years of Agile Software Development and dares to look ahead on things to come.

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.

Another quick look for something needing improvement.

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

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.

Imagine a world, a game, a server, a client. Imagine all of us creating a programming world in which people can learn from experience and from seeing what we have done.

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)

A cartoon from Mastodon inspires some thoughts.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Joy projects. Impact. Transclusion?

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

Zoom report. Simplest thing that could possibly work.

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

A "database" to work with.

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

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

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

Thinking about software, economics, and the things I care about.

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

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

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

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.

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".

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

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

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.

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

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

First, some thoughts on TDD.

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.

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

Perhaps the biggest mistake in XP and Agile ...

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

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

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.

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?.

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

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.

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

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

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?

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.

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?

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.

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 ...)

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.

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!

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.

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?

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.

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

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

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

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]

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.

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.

Responses from Scrum officials to my recent Scrum articles here and on more private slacks have not been favorable. I think I'll sum up and move on for now.

I've chosen a large windmill at which one might tilt. Could we, of good heart and great skill and courage, fix Scrum? If so, should we?

The End Scrum Now site, a bit of a rant, raises important issues. Let's explore some of them.

Herewith, some remarks pro-Scrum, and a reminder that Scrum is not as good for developers as it might be. Even some advice to developers.

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.

A week ago, I posted a Scrum-related survey. Today, the results of that survey, and my comments.

Scrum asks for an Increment every Sprint. Of all the Scrum rules, this one is most important for developer success and survival.

A few(?) more thoughts on the battle between Scrum and Software Development. A review of some past thoughts, and some of today's.

The Scrum Alliance mission? Let's talk about that. Fail better.

As often happens, this article didn't go where I expected. I hope you like where it went.

What are you doing, Ron, how do you do it, and most of all, WHY?

I was going to move back into the dungeon today, but realized I wanted to talk about what I learned doing the ominoes exercise. Here goes ...

It is of course necessary to display yesterday's polyominoes, for our viewing pleasure.

The Zoom Ensemble folks have been playing with polyominoes. I can't resist embarrassing myself by trying them.

Alistair found some ancient estimate for a KWIC program and challenged folks to implement it. I'm picking up the challenge.

Every time these organizations stamp out a new ScrumMaster, there are programmers somewhere whose lives will be made worse.

Some thoughts on the world as I see it today, in 2021, from my privileged vantage point as an old white guy in the USA.

Today, some code review. No big plans. We'll see what we see. I expect to mention Beck's Four Rules.

We'll look at using invader count as a flag to start a new rack. I don't promise to change it.

I don't feel very bright this morning. Let's see if I can prove it.

I have an idea and I can't wait to try it out. Niagara Falls.

Today's plan: Code review, and targets of opportunity. Short morning, just one new class.

Displaying two player score. Beyond that, we'll see.

Attract mode needs to be turned back on. Maybe we should show both players' scores. What about those buttons?

Let's do more on the two-player game mode. We're probably getting to the hard part.

It's time to start on the two-player option. I have ideas but not precisely a plan.

A lesson from history, a surprise refactoring, and, apparently, a sermon.

Not really, but the saucer is looking to score.

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

The Agile Manifesto says that working software is the primary measure of progress. What does that mean?

Users observe the need for more racks of invaders. That's going to get ... interesting. Also Game Over if they reach bottom.

I've convinced myself that a global would be a better way to handle constants than the singleton. Kill your darlings.

Users have detected a problem. Users, do you hear me? Users!

Improving zombie behavior. Sound adjustments. Maybe more. Maybe less.

Let's take a look at a simple attract mode. Zombies!

More with Singletons. And distractions. And no singletons.

Improving our Singleton and using the idea elsewhere.

There's no reason to think that I'm smarter today than I was yesterday, but I am a bit more experienced.

Touch to Start has me thinking that attract mode might be within reach. Things go Very Wrong.

Saucer Scoring, then whatever makes sense to me at the time.

Another day of improv. Let's see what looks worth doing. (Wow, a factory object!)

What shall we do today? I honestly don't know.

Remarks on a Twitter comment from Jez Higgins.

Another defect. I'm starting to feel ... afraid. That's not a good sign.

This isn't Houston, but we definitely have a problem. And it's not a new one. And I'm tired of it.

Things we might do. And I'm thinking about conditionals. The next trick may surprise you.

I have an idea. Let's find out if it's a good idea.

Maybe some tuning. Do we need more start-up settings? Should the test results disappear? What about a FireControl object?

The world is burning, and I'm really just trying to ignore reality, but in addition, I've made a mistake. Another mistake, that is.

If nothing else, you have to admire me for getting over 100 articles out of ancient video games. Let's do another today.

A couple of interesting articles crossed my virtual desk yesterday. Links and some reflection within.

Better scaling, then more with the saucer, I guess. Plus whatever opportunities we spot.

More with the saucer, that's my plan.

I know the voices in my head aren't real, but they're sure ticked off at me for the past few days of messing up.

Well this goes entirely not as planned. Double Arrgh.

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

No, not space pirates all of a sudden. I released a fatal defect yesterday. What's up with that?

A couple of small changes to CodeaUnit and my CUBase template. Then let's see what we can improve about Space Invaders. (Saturday: Arrgh, a defect!)

More to do with bombs, especially targeted ones. We need some refactoring as well. The results may surprise me.

I think today we'll work on the bomb timing, and targeting the rolling bomb. Often, what I think will happen is what actually happens.

Let's continue the bomb dropping logic. Our current design can't do what's required.

Speed indicator; Bomb dropping order; Free player, maybe.

Some recovery from repo problems, some work with the clock, whatever else seems right.

The web site with sounds came back, so I'm scarfing them down and starting to install them. Should be mostly straightforward, he said. Except when my repo locked up.

If you're like me, you're wondering what space invaders eat. The answer will surprise you.

Let's damage shields from below, and try to continue small steps toward 'better', whatever we mean by that.

Let's make missiles explode, and continue improving this design.

I want to figure out why this program makes me feel bad. Then do something about it.

Some improvements. But first, a word about less technical matters, the book `x + y`, by Dr Eugenia Cheng.

A bit of planning, a bit of action.

Let's get a start on scoring. This should be easy enough. But--when is too much way too much?

I woke up this morning certain that some of my bitmap calculations were STILL off. Something has to be done.

A bit more exploding. I'm going to continue to let things get messy.

Let's do some damage

It's my ball and if I want to play with it you're not the boss of me.

One of these two things is not like the other ...

If the world isn't flat, how come these invaders keep falling off the edge?

Today we'll try to fix the collision logic to accommodate our origin changes, and to make the invaders explode.

I've moved the good iPad into the TV room and while waiting for our Sunday festivities to start, I'll set up the project's bitmap assets.

Having decided to move to CORNER mode from CENTER, we've got some work to do. I'm hoping this one isn't interesting.

Is it worse luck when Friday the 13th comes a day early? Or a near miss? Time to dig further into bombs failing to miss shields. (Added Friday: It was worse luck.)

I had no plan. Now I have a plan. Check code clarity, then work on shields. Things go ... oddly

Maybe make the invader bombs do some damage? Or what?

My plan for the day is to retrain myself by reading this code that I've not touched for two whole days, and then to see about moving things forward. My guess: invader missiles.

I think today I'll work on making the invaders march back and forth. Right now they just march forth and forth and forth ...

A friendly demo of shield damage techniques leads to an examination of an interesting coding approach. I need to figure out what I think about it.

It's 6 bloody AM and I'm programming. What's up with that?

Let's see about extending our square invaders game-like thing to be a bit more like a game.

Twelve articles and no product. What's up with that?

In the real game, the invaders' missiles eat away at the shields. How can we duplicate this effect?

An experiment and some planning. Then even some doing.

Learnings from the ancient scrolls. What shall we do about them?

This one is mostly for the record, if it goes as planned. I'm just going to import some more bitmaps. I recommend against reading this.

Let's see what happens if we try to refactor our little spike into something reasonable.

A bit of an idea about marching, and thoughts about spikes.

I need an idea. Representation is important.

I'm wondering how to move these invaders. Let's do an experiment.

Dave1707 from the Codea forum shows a much better approach to converting the bitmaps.

Importing Invaders. How hard could this be?

I'm having so much fun with Asteroids that I thought I'd look at the old Space Invaders game. I'm sure I'll learn something.

Let's clean up that level handling a bit.

Unfortunately, we need to take things to whole new levels. This'll be fun. (Later: not as interesting as some, but it has its moments.)

Let's get some more modernization up in this baby. I'm sure it's the only reason we aren't selling millions.

Let's see about reducing a Singleton or two, and maybe some more modern graphics.

Our marketing people have a challenging request: modernize the look of this game.

It could happen: I've figured out a good way to handle these callbacks.

We'll continue our code review, with particular attention to our tweens, especially that tricky one.

I feel like reviewing some code. What I learn? Kill your darlings.

We're nearly done here!

Some tweaks to hyperspace seem in order, but I feel that this thing is nearly done.

Enhance Hyperspace?

Perfect saucer shots and a start on hyperspace.

Let's put in some options.

Let's clean up the Aimer and look around. I think we need options.

I really want to crack missile targeting. I've made some observations.

Two things go right. One thing goes horribly wrong

Free ships. Beyond that, maybe some reorganization? No, more like confusion.

Let's finish up the small saucer, and how about testing it this time?

Ships Remaining Indicators. After that, who knows?

After some discussion of things we might do, we decide to do GAME OVER. The results will surprise you.

Run tests automatically, dribs, drabs, and oddities. Pretty calm.

Today I plan to give the saucer the ability to aim its shots. I anticipate zero trouble.

A bit of planning and a bit of doing.

Not really an answer, but just a bit of fun.

Some sound, and saucer needs to stop helping so much.

Let's do collisions. And try to TDD them.

We move saucer and ship in the direction of our new scheme, and get rid of the cloning of the collection. Also took a nice walk.

We made a number of useful changes last time. Let's harvest some value.

I'm sure my double dispatch approach will work fine. But the pattern seems simpler than that ...

Some thinking and working on collisions. Is Ron converting to London School???

I've determined that it's time to collapse some 'technical debt', in small, incremental steps.

We need to improve collision detection. I think we have to do it in one go.

I think this afternoon I'll just push a little further on the saucer. Maybe make it dangerous.

I've decoded how to draw the saucers. Let's see about making them fly. That will require some research.

Some rationale, an experiment, some learning, some protection.

We start asteroids on the edge, which gives us an edge on refactoring.

A new approach to steering. And an apology.

I found some better recordings of the Asteroids sounds. And it's time to trigger new waves.

Stereo, because I can.

Based on the 'learning' from #25, let's just make bigger buttons.

Today I decided to experiment with improved controls. The experiments, um, succeeded oddly.

New ship, new sounds, learn new tricks, amaze your friends, confuse your enemies. Apply now! UPDATED!

I think today we'll do waves of asteroids. And some tests.

I've made yet another mistake. Will the embarrassment never end?

I reckon it's time to kill the ship when it's hit by an asteroid. I have a clever way to do it and a direct way. Which is best?

I'm feeling like coding a bit this evening. So stand back.

Thinking about tests and refactoring. The boss wants a feature.

I think it's time to move more toward objects. Part of our mission is to decide what we like. And: 'No large refactorings!'

I thought I knew what we had to do today but I was a bit mistaken. We need more, and better thinking ... and code.

Just arriving 'at work' this morning, I'm thinking we'll make the Ship move. We need a safe place to land first. EDIT: Arrgh, a defect!

A report on last night, and a 'major' refactoring. P.S. There is no such thing as a major refactoring.

A quick report on a short project last night, then let's try to get something nearly playable.

I looked up tween and my tween example and it seems like just the thing. Let's find out.

First, I'm really feeling the need to improve this code. But maybe it's too soon to do good work? Plus explosions.

Displaying different shaped asteroids is nice, but we have an issue of size we might work on for a bit. And let's split them!

Having converted the 6502 asteroid shapes to Codea style, let's plug them in. This design is starting to bug me, and we'll think about that too.

Dave1707 offers a much better idea for the conversion of Asteroids graphics into Codea. Let's explore it.

I found the definitions of the asteroid shapes in DVG language. Let's draw them in Codea.

I spent last night decoding some graphics chip code on computerarchaeolgy.com, and I managed to draw an Asteroid in the classic style. Today, a look at what I found out. Updated: New Resource.

I've decided how buttons should work. It only remains to make it so.

To move forward with this project, the ship needs to be able to move forward. And turn. And fire ...

OK, Asteroids doesn't have a horizon, but today we'll start on the ship. Shouldn't be too hard: it's a triangle.

I needed to test some floats the other day. Let's improve CodeaUnit to help with that.

Today we'll clean up the code a bit. It really needs it.

Today I decided to draw two square asteroids at random angles. All's well that ends well, but I did get confused.

For something to do, and because it might be helpful to new Codea users, I'm going to implement an homage to the old Asteroids game.

The Gilded Rose 'kata' exists in many languages, but I've not seen Codea Lua. Maybe I should fix that bug. This is pretty boring. Skim, don't read. Needed for the record.

Some final thoughts on the Gilded Rose exercise. Well, final for now ...

To round out a dozen, we simplify things a lot. Too much? What do you think?

Experiment with lambda.

Today I think I'll double-check that double-decrement issue. Then I want to see if we can combine those two parallel if nests.

Some really nice progress today ... and one open question.

Dave Nicolette mentioned on Twitter that he was wondering whether a Mob Programming Gilded Rose kata, using Arlo Belshee's 'Read by Refactoring' would make a good video. That gave me an idea.

We're on a path more like re-implementing the program than refactoring it. That's a concern. Can we do better?

Today I plan to move the Conjured item code to the new scheme, and see what that tells me. Something will probably go wrong.

It's noon on Tuesday. I've whiled away the morning. Let's try to make a bit more progress on this code.

Monday, Monday ...

Are we doing it right? Are we in trouble already?

It's April 17th. It's snowing. We're on lockdown. Let's look at Gilded Rose and see what we might do that would be interesting.

Chet, Amitai Schleier, and I played with the Gilded Rose exercise the other day. I think I'll write about it a bit, starting from scratch. [edited]

Wow. Shapr 3D is neat! I wish I could use it. It's so cool I might warp my process just to fit it into my plans.

This may be the most powerful most frustrating 3D application ever created.

To create reasonable creatures or vehicles, I'd need a decent 3D object creation tool. Ideally, since this is an iPad project, an iPad app.

I am supposedly on a course to make the Orc stay within bounds of our little world. Today might be the day ...

It's probably time to work on behavior, so I want to take a bit of time to look forward at what we might do, might not do, and probably won't do.

It's Sunday. My long-suffering wife is prepping for the upcoming election. On my own, I decided to spike motion for my game creature.

I've decided a bit about the 'game' I'm writing in Codea. This should keep me off the streets for a while.

I've been reading examples and searching the web about terrain generation and I'm ready to start sharing. Brace yourself, this gets pretty random.

I feel I've got my feet firmly on the grass, dirt, and bedrock, and I can see what I'm doing. Time to become confused again.

I think I nearly have a solid place to stand: a tiny application that I understand pretty well. Today we'll clean it up and see what's next.

There's trouble, my friends, right here in river city. Is this little project serving my needs? Am I about to break through to the other side ... or to break through the ice and freeze?

We're at a fairly clean point right now. There are a couple of small topics in the code to consider, but we need to figure out a plan for what's next.

Owing to driver error, I lost all my code versions for the Orc program. We'll speak of recovery and then move on.

In response to some question on the codea.io forum, Dave1707 showed me a neat trick with text. It taught me something, and raised some questions.

Despite its great value in the hands of experienced TDDers, the uptake is slow and the practice is often hard to sustain. What's up with that?

The bird experiment worked pretty well. Now it's time to clean it up and consolidate what we've discovered.

I've made a couple of objects move, in two different ways. I figure that topic is spiked. What should I look at next? This session is gonna be rambling, I'll wager.

Today I'll build a different kind of creature, who moves differently from the Orc. The idea is to build up an understanding of where the design needs improvement in terms of flexibility or clarity.

Today I'll review the code, and think about whether to build in some object thinking. I want to ... but should I?

Last time I managed to make a fairly simple Codea Craft program draw an Orc standing on (or near) the floor. Today I plan to make him move a bit, and then to see what I've learned.

Yesterday I managed to move an Orc, by hacking a sample program. Today, let's try to do a clean version to consolidate our learning and ask ourselves some questions. Maybe even begin to answer some ...

I begin trying to make sense of Codea's ambitious and powerful Craft components.

>Alex Bunardzic has been part of a rambling Twitter thread about TDD and people who object to it. One of his concerns is that TDD proponents agree that TDD isn't always appropriate but don't say when. Let's explore that.

I tweeted this on the 18th, in response to something left frustratingly vague by one of my dear colleagues, which caused me to think more deeply about what they said.

Some folks who don't know TDD, and some folks who should know better, have been describing TDD in ways that don't match what I experience. Herewith, some thoughts.

In a Twitter conversation a week or so ago, I was asked to do a TDD video, to show how I do it. A video isn't within scope just now, but here's an article with real TDDed code in it.

A Medium article with an interesting mix of observation and questionable opinion inspires me to write what I hope will be the same. 😈

Despite my concerns about experienced coaches advocating against practices that are often quite useful, there are a few things where I'd at least advise great caution.

Some thoughts from Twitter on 'technical debt', what it is, what it isn't, and why we avoid it.

Why do we do that? One word: Productivity

A number of blogs, tweets and emails have crossed my 'desk' lately, gently or strongly advocating against some generally well-thought-of practices. I'm troubled by that.

This article expresses, in written form, the talk that Chet Hendrickson and I gave at the deliver:Agile conference.

A private note from GeePaw Hill, and a tweet from Brian Marick inspire me to mumble a bit about mindfulness and collaboration.

When I was blurting about the Increment as the most important thing, just the other day, GeePaw Hill mused about collaboration as the most important thing. Today, I'll muse on that and his notion of makers-making-made.

If you are not producing working, running, tested usable software in every single Sprint or iteration, you are not [yet] 'doing' Agile, you are not [yet] 'doing' Scrum.

A question on AgileMentoring.com triggered this little article. Perhaps repetition is the mother of something ...

Kate chats with people at the KALE Society meetup. They discuss some small issues and then one big one. Test Doubles come up. Darts are thrown.

A bit of a screed about naming, triggered by a super idea from Dan Terhorst-North.

We're here to discuss whether Agile ideas fit in with fixed-scope efforts. We'll look at Agile values, principles, frameworks, and practices. The answer is that Agile works just fine.

A couple of people asked me to list all the technical skills required in order to do Agile Software Development. I can't do that, but I can do this.

YAGNI can be a legitimate way to go fast at minimal cost. Skimping on the practices that support YAGNI? That's a mistake. Technical Debt? Not the same thing.

Some words and pictures about the various notions of 'technical debt', or, as I like to call it, wishful thinking.

A recent idea from an Organization That Should Know Better suggested that use of a standard story card format was a good idea. I tweeted 'wrong'. However, Chet and I talked about the subject a bit this morning.

Probably not a good thing to say. Possibly a good thing to think about.

A lovely post by GeePawHill led to a Twitter conversation about up front design, inspiring this article.

First some refactoring - then some behavior.

I decide to follow Braitenberg's approach a bit more closely, driving the wheels at different speeds rather than rotating the vehicle.

Let's Turn - making our little guy turn. And see the comments on Gross Hackery at the end of the article.

I'm playing in Codea with 'Braitenberg Vehicles', just for fun. I'll be sharing what I do with you all.

Agile transformations have little, if anything, to do with Agile Software Development. Let me hook up some connections for you. Bit of a rant here ...

Another tweet-storm, this one about slicing from top to bottom of the software. Slicing provides value, and information, sooner.

I was asked on Twitter what I meant when I said 'Simple, not easy. There's a difference.' I have no idea what I meant then, but here's what I think just now.

A chapter from 'Software Development, How I'd do it'.

The above was the title of my talk with Chet Hendrickson at deliver:Agile. I'll update this with a link to the talk when it is published. Meanwhile, here are some thoughts.

Where do we place the responsibility–surely not blame–when things don't go well on a Scrum team? Who's responsible for taking action? (A bit of something I wrote on Twitter, lightly edited.)

I'm not finished ripping Scrum a new one, but I don't want to come off all negative. So let's talk a bit about what I'd like to see done.

We've spoken often before about the backlog. Let's get down and dirty today. Delenda est backlogus or something like that.

If your factory pollutes the river, you're supposed to clean it up. If you plant kudzu to combat erosion, you are responsible for its destruction of everything in its path. If you swallow a spider to catch the fly, and die when you swallow the horse, of course -- it's on you.

The Sprint causes serious problems in many Scrum installations. What are some ways to mitigate those problems?

Let's consider the Scrum Sprint. What's the strongest case we can make against it? It harms people, how's that for a case?

In the spirit of inquiry, fairness, and a generally bad attitude because it's raining, let's consider how strong a case we can make against Scrum. It might be fun.

These articles about hills to die on are in response to a continuing trope on Twitter and elsewhere, to the effect that X is bad, or Y is better than X, and therefore don't do X do Y. These are amusing, provocative, and rather frequently ... mistaken.

When are Sprints a good idea, when not so good? What are their values, and their costs?

Bashing of Scrum (and other methods) is a common form of Internet Entertainment, and not without reason. Some of the concerns are more accurate than others. Choose carefully which hill you want to die on. In this series we'll explore some hills.

We keep re-reading about the FTP object, and re-learning how it works. Then a week later, we've forgotten.

Last time we zeroed in on the FTP capability of our new cut at my 'iPad' project. Today, I'm hoping we'll TDD an FTP object.

Against all my best judgment, we decide to 'start over' on this tiny product.

We've not done work on this for ages. Tozier and I try to figure out what's up.

Just a bit of reflection after two weeks off. Next week, I hope we'll actually do something. Today I remember the Boy Scout Refactoring Rule.

It has been a week since Tozier and I last worked, and I spent most of the time under repair. I'm thinking we'll work on the date-sensitive stuff. I'm mostly wrong.

Chet has me nearly convinced to move my site base to Dropbox. Today we'll talk further about that and about moving the product forward.

I decide to spike a bit on folder and file manipulation.

When this article appears, it will have been processed by our new (MVP) iPad Transfer Mechanism. 'Thank you for pressing the self-destruct button.'

Tozier and I learned something about habitable code yesterday. Topics may include bits of Confirmation Bias and fragments of Coding Morality.

You'll meet them where they are. You'll work with them where they are. And when you leave, they'll still BE where they are.

I thought today we'd work on the triggering mechanism for the iPad build. Instead something important happened! (Clickbait)

I'm wondering, today, whether the Increment could be the driver for all 'Agile' software development.

If I were a REAL product owner, I'd be pressuring the hell out of my team right now. So I will. How did that work out, Ron?

We'll try to focus on building features today, but there are lurking issues in those magical incantations we do about Dir and FTP classes.

Today, let's talk about cadence. Iterations, Sprints, to have them or not, that is the question.

Thoughts about Technical Debt

Time to do some work after the heavy refactorings involving quantum mechanics. Let's see if we remember how.

I was asked a question about one of today's modern approaches to Agile software development. Here are some general thoughts.

In this short session, we inch forward and wind up in a better place. Not THAT better place. I just mean the code is better.

What's next for the iPad project? Refactoring, it turns out.

We knew last Thursday that we had an issue with folders and folder names. A week later, we dig back in.

An innocent email question leads me off into wildness and chaos. What's new with you?

We really hope to get from end to end today. You won't believe what happens next. Unless you're paying attention.

Tozier and I shoot again for end to end on the iPad project. What happens next? As I write these words, I don't know either.

We're clearly closer than we were, and it feels very close. But not as close as we thought.

Bill and I decided to do a bit more on the iPad publication project. You won't believe what happened next. Unless you expect trouble.

What if I were to create a new software development framework? I'd never do that, but if I did, what might I do? Let's find out. Let's talk today about Whole Team.

Terms seem important to me today. (Revised 2017-07-05: Techniques)

Some Notes on the theme "If I were going to create a new framework, what would it be?".

Today Tozier and I will do a Quick Design Session and start TDDing something that will, I hope, turn into the actual app.

In which we suddenly realize something about Tozier.

Tozier and I start with some Ruby code for FTP or something.

Tozier and I try some things.

I'm told the iPad is the new Mac, or something. Anyway, it'd be nice to be able to write articles on the iPad and get them on my web site without lugging around my Macbook.

I've been trying to learn a 3D drawing program. Yesterday I noticed that I was working but not learning.

Some interesting tweets make me wonder: if I were creating a method today, what would it be?

Over the past few days, an ancient twitter thread accidentally revived, talking about how you don't need quality code when you're just validating assumptions. What do the ants have to say about that?

I was asked a question via email and liked my answer enough to write it up. I hope you like it too.

A Twitter thread gets me thinking about Mock objects and whether they're more than just a matter of personal taste.

Let's try this again. The previous article was not clear to all readers. I suppose this is often the case with my work but in this case I thought I'd try again.

At the time of the Agile Manifesto, we all did the best we knew. Here's something I wish we had done. (Revised)

The Backlog is an essential artifact in Scrum. It may also be the root of serious dysfunction.

Generalizing from a few results isn't proof. In this article I'm going to prove that by generalizing from a few results. Wait, what?

If we can't build software well, all our Agile is for nothing.

Content from XProgramming has been moved to this site. Some brief retrospective thoughts.

Robin Dymond asked me to write about making stories small. Well, there's this.

My friends and colleagues in the #NoEstimates circles have some good ideas, as I've commented elsewhere. I'm left, though, with a couple of concerns.

The Agile Manifesto says "Deliver working software frequently". Learn to do that. The rest will follow.

At the Agile Developer Skills course at the Raikes School, I commented that we don't usually test accessors. But we test everything. Is this a contradiction?

Jon Bettinger has found a failing test! Excellent!

My critiXXXXX advisors expected a more function-oriented solution. Here's something a bit better, perhaps ...

Philip Schwarz provided a nice-looking implementation. Let's look at it and try to build on his ideas.

I've been working with Scala a bit, just to learn what it is. I've found it interesting, if frustrating. Here is a bowling experiment.

Uncle Bob Martin comments on "Developer Certification WTF?" in a recent blog entry. Let's talk a bit about developer quality, and some things that are being done about it.

Choose your tools wisely, that they allow for the development of your skill.

Jim Shore has written a short item with the above title. Let's think about it a bit.

There are essential practices in Scrum and Agile. Not because we say so. It's the nature of the beast.

They're not XP's rules, they're the team's rules.

The C3 project team has voluntarily adopted a large number of practices. Every team member follows these practices closely. We have found that designing, coding, and testing in a consistent way means that the team becomes quite well integrated and that team members know just what they can expect from each other. Software quality is kept more uniform, and at a high level.

A few times during the project, a team took on a task and did not complete it within the iteration. They wanted to complete the task and kept it for the next iteration. This generally turned out to be a mistake.

There is some written documentation for the software, more commonly interpreting requirements than documenting design. Sometimes we document an approach to some particularly difficult area. We "never" document code.

We do use class comments to describe what a class is for, and sometimes how it works. We probably don’t do this often enough, and we probably don’t keep them as up to date as we should.

In general, we do not comment our methods. Beck teaches that a comment is used to indicate that a method is not yet finished. That’s how we use them.

Simplicity + Communication + Testing = Aggressiveness

We use CRC card design almost exclusively. Developers, managers, and users are all comfortable with the cards, since they are non-threatening. Moving the cards around makes it easy to describe how classes work, and it is easy to throw a couple of cards away and create new ones if the design isn’t working out.

Here are a few of the key code formatting patterns we use. The names and some of the examples are from Kent’s book.

Never underestimate the power of inspecting and changing things with Inspectors. Perhaps your GemStone database is messed up: a bunch of People have excess Parts in certain Bins.

We call the combination of frequent release with tests at 100%: continuous integration, relentless testing. The result is rapid progress and a system that always works better than it did the day before.

We all code to the exact same standards. We name our classes and methods the same way, we format code the same way.