Category: tdd

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.