Category: tdd

We have a thin treasure/inventory capability wired in. Let's review our notes and pick something to add. We add visible treasures and console announcements with just a little code.

We have some content that is fixed throughout game play, and some that varies. We're getting close to needing to handle that. Perilously close.

I have a bit of time at the keyboard. Let's improve the dungeon contents code a bit.

Let's take a look at what might be good next steps toward a game. I'd like to get to some code today. A second personality emerges from my mind, the PDP.

This morning I'm going to put a Camera2D into my dungeon and see if I can figure out how to zoom and pan and such. I am hopeful but also expect confusion.

Let's see what we can figure out about the Arcade camera. I think we'll look at an example, and maybe bash it a bit to see what it does.

I think Arcade is in place. Do we like it? Is the code where we want it? What are our longer-term ideas?

I've added in Dot and it's clear we have work to do. Result: 1000X faster.

I think we'll take a cut at converting from pygame to Arcade today. I have a tentative idea, and I'm prepared to fail spectacularly.

Let's explore the Arcade platform, which we plan to use in our dungeon program. Here's how I like to learn a new system: by example.

That `make_lines` method is horrid. Let's continue cleaning things up a bit, starting there.

Are we close enough to having the right Border classes to try to draw them? Let's take a look at how we might do that.

We want to change border calculations to create a permanent structure. We proceed with a few very tiny objects. I think it goes quite well, though the article gets rather long.

I think about my code while writing it, and at other times. Here's what I think today.

Let's look around, see what we might do that might improve things.

Cleaning up Cell fixed a big design issue. Now we are left with a smaller one. We'll see what we can do about that.

We're engaged in a long series of small steps, moving capability from the Cell up to the classes that hold onto Cells. The good news: small steps can be done over a long period of time. Bad: it is often not very interesting. Did not use the word "gallimaufry". Could have.

We couldn't get in the straightforward way. Is there a more sneaky way to do this? Tiny steps, many commits, very tedious. One semi-interesting refactoring.

Cells know what room they are in. What will it take to undo this? The bear gets really close to taking a bite today.

Should we start to address the Horrendous Mess™, or do something else? Something else: work toward removing room knowledge from Cell.

A short session Friday, another Saturday, and we have Cell disconnected from it container. A triumph of small steps!

I just want to do a little more this afternoon. Can we move `at_offset` yet? Yes. Just one more use of `current` remains.

We are making a Horrendous Mess™, and we're glad of it.

Just for fun, let's see about moving `find_path` into DungeonLayout.

We'll begin the morning adjusting more tests to use the new Layout idea. This iterative incremental stuff? It really works! The Niagara Falls Method.

I've had an obvious but seemingly decent idea. Let's try it. Here's my cunning plan ...

What happens when right in the middle of things, what seems like a much better idea appears? Includes: musing on the balance between code quality and shipping.

None of my notes on cards appeal. Let's look at the code and see what it suggests. Sort of an odd result.

I'm not up for a lot today. Let's review those methods that can optionally return `None` and see what we can learn, maybe what we can do. Results: acceptable if not entirely satisfactory.

I was thinking this morning, while trying not to get up yet, about the programmer, the programmer's code, and their care. As to my recent defect, I really don't see what to do better. Yet.

I've been chasing a serious intermittent defect for five or six hours. This is almost unheard of, due largely to the way I work. But I finally figured it out. Brief comments on LLM-"AI"

Five or six hours of slogging here. Maybe scan, maybe just read 'Found It!'.

Today I think we'll see about using Flood directly, perhaps removing the convenience method on Cell, but adding some to Flood.

An exchange with Bill triggers some ideas for the flood. It's 0330 hours. Let's see what we can do.

The `flood` method is my current darling. Should we kill it? Is it just too cool to live? Let's examine it.

Today we start by actually finding furthest points. We need also to remove the path map code. The morning goes well: geek joy FTW!

I think the new generator is working well. Let's see if we can improve the way it's written. A very nice refactoring sequence, if I do say so myself. Thanks to Bill for the nudge.

Let's see what's up with that new generator. I think it's about 0.75 done.

A nudge from a friend impels what seems like a much better idea. But appearances deceive: it's more tricky than I thought. We build an interesting new capability.

We have a test that seems to compute what we want. Let's try to see where it should go, and put it there.

I've had what seems like a good idea. Let's find out.

We're working on finding a cell that is maximally distant from a given cell. What are our next steps?

Sometimes we focus on the application, sometimes on the making of the application. We begin with making.

I think ensure_connected can fail. Let's prove it, then fix it.

Having completed the basics of the contents vs layout design, it's time to look around and see what needs improvement.

The FGNO OGs gave me some good ideas about my design: thanks, OGs. This morning I'll start following some of those ideas. I use test doubles!

Today, we'll start populating our dungeon. We'll start with an intrepid adventurer named Dot.

This morning, I think we'll look at some code. As a start, I have a question about Room. Brief LLM-AI digression.

I did a little off-article cleaning of Cell. We'll look at that. And I have an idea which may be good, or then again, not. Weirdly, things go better than expected.

Yesterday's closing idea looks good to me. Let me know what you think, if you care to. We find that we're not quite finished. A serious lesson is relearned. LLM-AI diversion at end.

With our new path deviation operation working, it's time to look at the code and see if it's asking for anything. We end with a seriously questionable choice.

We need the validity check in PathHelper. And I see how to generalize it. Which should be first? Updated: found a test.

Let's see if we can make PathHelper less bad, perhaps even make it better.

We still get straight paths sometimes. I have an idea ...

We can make most of our paths wander, except for the straight left-right or up-down ones. I've had an idea. Is it a good one? I decide to use a prior idea, in an interesting spike.

When last we met, we had just discovered a nice way to make a wiggly path. Since then, I've improved the code a bit. We'll look at that and then see what we see.

Our minimal paths are too straight for most purposes. Is there a nice way to make them adjustably not so good? Is 'adjustably` a word? It is now. A nice discovery arises.

Yesterday at session end, I tried to hack in a minimal-path idea. Failed. Today let's try to fail better.

It is certainly no surprise that the day after something first works, there is plenty of room for improvement. We'll be looking for some of those things this morning. We learn from a small step.

Let's finish up the path between suites and see what it looks like. I suspect we'll want to try to tune it.

Nothing deep here, I mean a path in the dungeon, not a way of life.

We are working toward making dungeon description easier. I think of it as creating a little language. Today, adding randomness, if my luck holds. It holds, and we belay the whole plan.

Well, dungeon CREATION. We'll start with a little refactoring. I remember why I recommend testing bug fixes.

Making a dungeon seems generally to require looping and even conditionals. Do we want special support for those?

Suppose we wanted to create many different kinds of maps. How might we make it easier?

We sometimes get rooms within rooms by accident. Let's see if we can do it on purpose.

FGNO had some ideas. I'm not ready to work on holes. What about paths? A weird solution emerges.

The new jaggy room shapes sometimes include holes. Makes me think about secret rooms. And, not unrelatedly, about paths. Just thinking, and an interesting experiment.

Now that we can have as many room shapes as we can imagine, let's imagine some. The results may surprise you. They surprised me, in a good way.

I veer into philosophy and LLM/AI, based on thinking about many small changes, and how they add to understanding.

I had a few moments and decided to do a round room. At which point I realized that something can be improved.

A common but rookie mistake needs fixing. Using the same RoomMaker to make multiple rooms engenders chaos. Today, as often happens, I don't do what I thought I might.

I have a bit of time and a bit of energy. Let's scavenge Room to make a RoomFactory.

Yesterday's work has been taken as an experiment in having different room shapes, via different room builders. today, Let's get started on the real thing. I have some ideas. That's never a good sign.

FGNO Wants Better Shapes. We do an inadvertent spike. Along the way we discover an issue in generate, and learn the difference between a square and a circle. A superior day!

Recording some small changes.

With a little help from my friends, I set out to smooth some rough edges. Lots of small things. Nothing to see here, aside from one excellent name change. A metaphor issue discussed at the end.

The PathFinder code now uses Cell.generate, but there are signs that make us wonder.

PathFinder uses `generate`. But there's work to be done. And let's talk about generalizing `generate`.

Now let's see if PathFinder can benefit from the new `generate` method on Cell. Saturday: absolute debacle. Sunday: perfect.

Let's look into a suggestion from @blackoverflow. Turns out to be a good idea needing a little improvement. (Minor edit, courtesy @blackoverflow.)

Our cell generator looks pretty good. Let's test it on a copy of our suite test, then see how to put it in play.

I think a generator might be an interesting way to do this flooding thing. Let's see if we can gin one up. And we can!!

Let's see if we can make our SuiteFinder object more expressive. Arguably, it needs it. Arguably, we'll go too far. Too far? We went hog-wild!

What we need here, I reckon, is Method Object. Let's try it. Oddly enough, that's actually what happens. There might be something better still ...

We continue the prior article's session in a new article but same session, refactoring another bit of code that could use a little improvement.

This code isn't very good. I'll tell you why, and we'll try to do something about it.

We'll start with a review of existing code, possibly clean up the border logic a bit. But we'll at least start thinking about "continents" and paths between them.

I think I'm ready to draw smarter borders. I have chunks of a plan. Green shoes.

Thinking about how we could detect rooms that are adjacent. Warning: contains Philosophy of Programming as this old guy does it.

My design fantasies and experiments need to stop. Let's do the periphery feature. I have an idea. Results are satisfactory.

Let's look around, get aligned, decide what to do, then do it. Well, we do a little, but not much. Have I learned anything? PSA: Eat the rich!

Let's try a different approach this afternoon. I have a good feeling about this one. Things go fairly well, but not fantastically well.

Yesterday's experiment successfully showed me that I had a terrible idea. Today ... a similar success!

I think I'll experiment with a kind of cell that has x and y but really only as data for display, using just neighbors to show relationships. This may get weird. Experiment succeeds: Not a good idea.

It feels as if my objects aren't helping enough. It's important to recognize that feeling and see what can be done about it. Think, speculate, sleep on it, try something.

Starting the game seems too slow. How much? Why? Measure. Measure better. Think. Realize something. Plus: help from a new friend.

OK, we made the change easier. Now can we do the change? Yes! Slow is smooth: smooth is fast.

Let's see if we can do this with good testing and really small steps. It could happen.

Some small refactoring steps, very small. One rollback, no idea what happened.

I want to complete the path finding, and I think some of these objects would appreciate being better designed. Includes: a Great Lie wasn't ... this time.

I feel sure that I know just what to do next with paths, but I'm not sure how to test it in a reasonable fashion. Results: Happy!

For a program with no point, there sure are a lot of interesting things we might do. I'll try to make these articles more useful.

While I like the new bordered look, I still don't like the rooms all packed together. I have an easy idea that comes with a puzzle.

Drawing a room looks good. Let's generate a whole space of them and see how the map looks. An interesting drawing, and a small curious effect.

Drawing a room looks good. Let's generate a whole space of them and see how the map looks. We'll want some design improvement along the way.

We're drawing a grid. Let's try drawing a room.

I want to be able to see what the rooms look like, so I guess it's time to bring in PyGame and get something displaying on the screen. I plan to cheat. Good result!

I guess I'll set up an approval test with a random seed. Then see if we can create a better test.

Still nerd-sniped by dungeon allocation, I begin to get a sense of an approach. Let's see what happens. Python fits my hand. What's your preference?

GeePaw Hill is undertaking a dungeon sort of thing, in Kotlin, using a very interesting room allocation scheme. So I was thinking, what if ...

Kind of at loose ends this morning. Let's look at the Game of Life code and see if anything comes to mind. Just some small changes, other than reorganizing the files.

... not necessarily most beautiful, but there seems always to be something to talk about even in simple programs like the Game of Life. Today we remove the façade.

Of the two approaches I've tried, I have a preference. Let's discuss that and align the code with my wishes. Takes two tries. So it goes.

Let's review yesterday's conversion of the Game of Life from an object-oriented design to simple functions. I have at least one idea already.

The Game of Life code is quite simple. What if we didn't use classes, just vanilla functions?

The ArcRod from yesterday defines the center and one end of a longer rod in 'real life'. I propose what would be called a hack if we did something like it in code. I stumble, but recover. Small steps FTW.

Past time to get back to the linkage. I'm glad I'm not on a deadline—other than the big one—and I don't know when that is. Anyway, let's add a link or two. Result: WOOT!

Studying the Walschaerts linkage, I think I see a path that my scheme can support. So let's see if we can inch into it.

Upcoming Components challenge us. XP has design thinking. Names are dropped. Brief descent to politics. Cute Video.

Bell Crank is kind of an inflection point. Let's see what we should do next.

Time for a new component, the bell crank. Not your regular crank, no, but a bell crank.

Maybe tables would be a useful way to express a linkage.

I've come up with a better way. At least I think it is. Herewith, a report. Green shoes.

We need an easier way to define a Linkage.

Give me an "AI" that cleans the bathroom and leave me to my art.

Log for the Record. Crash and burn. Read only if you want to see me confused.

There are two possible solutions for the ArcRod's position. We need to specify which one we want. Result promising but I'm sent back to the drawing board.

Tests notwithstanding, there's both satisfaction and discovery in animating the linkage. So let's do. (It works!!)

As much as I'd like to futz with the drawing code, I think it's time to continue work on the ArcRod. I'm goin' in!

Why, only yesterday, I thought I had made a mistake. Turns out I was wrong, I hadn't made a mistake after all!

Starting late today, might end early. Let's see if there are right-sized things to do. Good thinking, but the work does not go as I anticipated.

Today we do a very nice step by step refactoring to a Method Object. Quite pleasing, really. Yummy.

Long ago, Kent Beck described 'simple code' with four rules. One of them was about expressing ideas in code.

I'm making a small improvement to the ArcRod. I have a good reason for doing it, if I'm not mistaken. Then some renames, possibly improving things.

The upcoming component needs DESIGN. I hate when that happens. Let's talk about this. Something special happens!

I thought I might have done something, well, pretty silly. That particular concern turns out not to be the case.

Offline, I improved the Linkage collection rather nicely. Now we need a bit more improvement. Seems to be a pattern.

Am I losing my edge, if I ever had an edge? I realized something interesting about the evolving design. I decide my edge is no more dull than usual.

During my morning prep for being found alive again, I recognized an issue with my lovely new scheme. How troubling is it?

We need lots of small steps to unwind the previous design while moving toward the scheme of doing everything without reference to parent. It goes ... OK.

Moving toward everything running on `start` / `finish`, I think we need a place to stand. And not on a wheel. HOWEVER: Plan Dashed Immediately.

We reviewed the linkage program a bit at FGNO on Tuesday night. Some thoughts arose. My big lesson: Shut up and listen.

One nice thing about gentle refactoring is that often we get ideas for how to make things better. Today ...

One nice thing about gentle refactoring is that often we get ideas for how to make things better. Today ...

Let's carry on with changing the API of these classes. Where were we?

Let's see what else we can improve in our four existing components. I can name some things that I'd like to improve.

With four components in place, let's look at the code and see how it can be improved.

Let's do a simple piston this morning. I am hopeful that it'll be easy.

I'm very confident that our connecting rod is working properly. The code could use a little improvement.

Presumably, I "just" have to plug this function into a class and I should be good to go. We'll see. (Hmm, seems to have gone smoothly. What am I missing?)

One might think that what just happened was bad. In fact, I was recently reminded that it was quite normal.

In which, your intrepid author parameterizes a test. P.S. But not enough! But a quick patch saves me.

Time to start on the rotation part of this idea.

Let's keep inching forward, supported by careful tests. I want to get this thing right.

This is why I drew the pictures, but I am still Very Disappointed to find defects in my ConRod. Further disappointment follows.

I'm psyched to add another linkage component, but there are some issues in the code that could use improvement. What should we do?

Could an LLM-human relationship be like pair programming? And if it were .. ?

I have some strong objections to the so-called 'AI' LLM systems that are all the latest thing. But with some regrets, I have tried whatever is built in to Google search.

I've been reading and thinking about objects not based in classes, in Lua/Luau. Let's explore and consider.

Minimal syntax and access to meta-programming yields a close-to-the-metal language that we can shape to our liking.

I figure I'd better do at least a rudimentary frame display, to show more clearly what is happening and that it is as we wish.

We need to make the little marks that show up on the scoresheet, at which point I think our point will be made. Result: Point made!

The PinCount object isn't all that pleasing. Let's find a better way to deal with an unknown future.

The current frame works perfectly, except that it needs to know the future. That should be easy to fix: just know the future.

The knock on our bowling TDD demo is that the assumptions make it too easy. Therefore ... let's make those assumptions come true.

A casual remark at FGNO a few weeks ago turns my attention, once again, to bowling. Are you even serious?

A small aspect of the game "nonograms" captures my attention. Darn it, I was trying to contaminate others, not myself! Also Anti-nerd-sniped.

I see yesterday's mistake. We complete the spike. Result: Works as expected. Not worth using.

In this session, I make some progress and then get stuck. Maybe worths kimming this, but no even good insights follow.

Today I'll try to make my new "holes" scheme work. Wish me luck.

I'm imagining a new way of scoring bowling. Recording the idea with intent to try it if it seems tasty upon reflection. Take this, "AI"!

Last night at FGNO we were reviewing a bowling exercise we had all tried. Today, I want to try something ... in Lua.

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

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

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

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

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

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

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

Continuing Diversion. It's just too long!

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

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

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

First, some thoughts on TDD.

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

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

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

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

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

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

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

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

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

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.

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?

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.

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

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.

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.

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

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

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.

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

Some odds and ends, a nice feature, and a bit of trouble. And the most distracting thing ever!

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

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

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

Maybe some wind for my sails. A need for better notes. An idea from Bryan's experiment with Unity. A thought about apps without programming. Everything is hopeless. Not necessarily in that order.

Doors, or I'll know the reason why! Just in: Ron bites bear!

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

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

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

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

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

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

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

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.

I really want to make some progress on the creatures that hang around the WayDown. But first, I am going to write a Coda on CodeaUnit and my simple toolset.

Let's try a more conventional approach to our deferred collection. First, some words on why it's a good idea.

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?

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

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

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

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

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.

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

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]

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?

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

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

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.

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.

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.

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.

Responding to a mistaken TDD flowchart.

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.

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.

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.

A foray into Google App Engine turns into a Tibetan adventure with Bos grunniens. No real lesson is learned.

I found this picture of a roulette wheel. I wonder how hard it would be to make my little game use it.

Let's finish wiring up our second pass at Jim Jeffries' roulette example, and see what we can see.

I felt I owed it to myself to do Jim Jeffries' roulette exercise, this time with more tests. You won't believe what happened next. (Sorry, I have a click-bait virus.)

Jim Jeffries (no relation) proposed a TDD exercise / challenge. I took it on. The results may surprise you. (Sorry.)

Going too far is quite difficult to do.

It's common to tweet things objecting to high automated test coverage as if it's irrelevant, incompetent, or stupid. I suggest otherwise with a thought experiment.

In which we discuss the technical debt metaphor, bright code, and the inevitable decline of civilization.

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

Kate Oneal chats about testing with the Ann Arbor KALe Society.

Jonathan Rasmusson wrote an interesting article. I agree. It's not about unit tests. It's about skill and understanding.

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

As Tozier and I work on Scraper, I find the pairing to be quite difficult, though not unrewarding.

It's good to have people watching over me. Already got some feedback on this morning's article.

True to my word, for once, I'm learning RSpec. Follow along and laugh at my ignorance.

Channeling ELO. Also a Codea Diamond that you might find interesting.

A number of people have tried the Diamond Problem now. Let's look at their work and see what we learn.

The trouble with thinking is, you keep getting new ideas. I wanted to try this one. Turned out quite oddly.

Alistair Cockburn published an article about thinking in solving a problem with TDD. I'm all for thinking. Let's see how I do it. UPDATED.