jamis

Thanks for stating it more clearly than I did! You've nailed it. It's always bothered me when people dismiss their ability to learn a thing, because they think some part will be difficult. They really have no idea. Yes, the task as a whole will have difficult parts, but we as individual human beings are far more capable than we give ourselves credit for.

Agree about debugging. To my thinking, though, there are two types of "programming": professional (for day jobs, where debugging, testing, and maintainability matter), and recreational (where the point is to just explore new things and try crazy stuff that no one in their right mind would ever "really" do). This "def" stuff falls into the latter category.

Honestly, I wish there were more people doing posts about recreational programming topics. WhyTheLuckyStiff was one of the last great recreational Rubyists. I miss that kind of no-holds-barred exploration.

Thanks! I'm not the first to talk about using IRB for interactive fiction, but I think I might be the first to do so using nested defs. :) IRB-based Zork would be awesome! I hope someone does that.

The article links to my github repository for a wordsearch utility I wrote (here: https://github.com/jamis/wordsearch) and it includes a description of a technique for embedding a message in the unused letters of a wordsearch puzzle.

Backtracking works well to try and fit words in tightly, but (especially in cases where the words just BARELY fit) it can take a long time to generate the puzzles. I'm sure that judicious use of heuristics could prune unprofitable branches more quickly and speed things up, but I've not explored those optimizations at all.

Good point. I was relying mostly on the words being sufficiently complex that the odds of them appearing by chance would be small, but enforcing that assumption would be a good exercise.

Absolutely. Which is all the more reason why holding those ideas close is silly. Get some practice making those ideas real, and learn how to execute on something well.

I love the idea of constrained mazes like this. Another related idea is that of "plank puzzles" (http://www.clickmazes.com/planks/ixplanks.htm), which constrain available moves based on which planks you currently have access to.

The slides presentation was built on top of deck.js (http://imakewebthings.github.com/deck.js/).

Our problem here is the overloaded nature of the word "play". I do not disagree that children learn through play. But I'm using the word differently in my presentation: I'm using it to refer to activities that you (as an adult) pursue casually, as a way to relax or enjoy yourself. If you play the guitar very well, for instance, you might take an hour in the evening to just "play", singing along, etc. This serves many purposes, and is definitely valuable, well-spent time, but it does not serve to improve your guitar playing. To accomplish that, you'd need to spend some time working on guitar techniques that you are less accomplished at.

You can see my problem, hopefully. Ambiguity in language has been the downfall of more than one well-intentioned presenter!

I definitely was not recommending constant practice--I agree that doing so will hurt you more than it helps you! I was recommending consistently regular practice.

My intent was definitely not to portray learning as painful. Learning is a joyful thing. But it's not something you can acquire by passively staring at the world. You need to exert yourself if you want to do more than gain a passing acquaintance with things.

For me, it is interesting because fairly simple means can produce complex (and to me, beautiful) results. It's intrigues me to explore this and see what can be done with it.

It is also particularly interesting to me as a way to explore the features and syntax of a programming language. Maze algorithms are handy (and entertaining), but any algorithm would do. The idea is to implement the algorithm in the language of your choice (preferably one you are are not experienced in) and see how the language lends itself to the implementation.

Naturally, not everyone will share either of these interests with me. But I'm okay with that. :)

Nearly all of the algorithms I described extend well into multiple dimensions. I'm not sure how Eller's would work in 3D, but there is probably a way. And the Binary Tree and Sidewinder algorithms seem like they ought to be possible to adapt to 3D, but I don't immediately see how. The others, though, are all trivially expandable to n-dimensions (just add "up", "down" and any other directions you like to the list of possible moves).

You're absolutely right. Both this one and Aldous-Broder both have a worst-case where the algorithm never terminates. As for whether the algorithm is "unacceptable", that depends on the application. For games? Yeah, this is probably far from your best option for generating mazes. But for cases where you absolutely must have a uniform spanning tree, your options are limited. Wilson's is much better than Aldous-Broder, but still not perfect. Robin Houston has described a variant that combines both Aldous-Broder and Wilson (doing AB until about 30% of the field is filled, and then switching to Wilson's) which empirically improves the odds quite a bit, but as long as you're doing a blind random walk, you're pretty much never guaranteed to finish.

I don't believe Test::Unit does this intentionally; it's just a side-effect of the implementation (load all tests into an array, and iterate over the array).

Aside from me simply wanting to be able to quickly run my tests locally, you mean? :) Mostly it's just an issue of configuring that so it works for all the programmers. Each would need their own remote, and each would need to be hooked into CI. Definitely possible, it just hasn't been a priority.

We do have a CI server, and as you said it works well for catching failing tests. However, it requires that you commit and push your changes in order to test them, which means you are effectively publishing untested changes to your entire team. The same for any kind of distributed testing, unless you are using a shared volume to host your sandbox.

I'm running a Mac Pro with 8 cores, so there is a fair bit of parallelization I can do locally too. Unfortunately, the tests all depend on the database, and while I can certainly use tools like deep-test to spin up separate DB's for each worker, I've found that doing so adds a full 60 seconds to the test run. I fear that until we eliminate the database from (most of) our tests, super-fast runs will continue to elude us.

CI and distributed tests are good things, no question, but I'm still looking for ways to make it possible to run my tests locally in TDD-fashion. I'm far from out of ideas, it's just a matter of making time to experiment.

http://www.astrolog.org/labyrnth/algrithm.htm#perfect says that both the Aldous-Broder and Wilson's algorithms will generate "all possible Mazes of a given size with equal probability". But neither meets your criteria of "efficient", since neither is even guaranteed to finish. I'm curious, too, whether there is an efficient algorithm with the same property (generate any valid maze with equal probability).

Good point. I've removed the bit about O(log n), since aside from being misleading, it really wasn't even relevant to the point of the article.

Yeah, the recursive backtracker is my favorite. Nicer results, and its very flexible. The other algorithms that I'm going to review are interesting for various reasons, and you can learn a lot about the structure and "essence" of graphs by implementing them, but they aren't as generally useful for maze generation as the recursive backtracker.

You're right, of course, about the documentation being awful. I was actually working on fixing that at the end, but every time I'd spend a few evenings writing docs (which was a few more evenings where I didn't get to do what I wanted to do), people would ask questions on the list not covered by what I'd just documented...and I'd get discouraged all over again. Docs help, for sure, and I painted myself into a corner where there was too much to document in the amount of time I could afford to spend on it. My fault.

I actually used a website for handling feature requests and patches (lighthouseapp.com), and it worked great. But even the best tested patch for a known bug still needs review. It needs to be applied and tested locally. It needs an update to the ChangeLog. And eventually it needs to be bundled and released, each new release requiring (at minimum) some release notes and a blog post announcing it.

It was a bunch of little things that got more and more annoying. I would have loved to distribute the load across more devs, but aside from a few who would review patches on specific topics (Scott Chacon, for instance, helped with git issues), it was all me, all the time.

There was definitely an element of that, too. Most of the patches were reasonable changes: bug fixes, or minor feature additions that improved the usability for some large segment of the user base. There were a few that snuck in that I later regretted, but I got better at saying "no" as time went on.

However, ultimately, if every project said "no" to every feature the developer did not personally need, there really wouldn't be very many widely-adopted projects. They key is balancing patches that you don't personally need against your vision for the product: and I did have a vision for Capistrano. It just wasn't really clearly defined, especially early on, which is why I regret some of those patches.

It was definitely a learning experience all around.

If you're this traumatized by my decision, then honestly, I blame you (and people like you) for my burn out. Where were your contributions to the library, your documentation patches, your discussions of better ways to implement things? Have you been in the IRC channel, daily, helping people troubleshoot problems? Have you posted frequently on the mailing list in response to questions? If you're so dependent on Capistrano, where have you been? If your silence was because it all "just worked", then why are you so disgusted now? It all still "just works".

As for the "Hey, anyone interested" blog post: I've tried that before, on other projects. People don't respond to those. No one volunteers to be hit on the head with hammer repeatedly for no other compensation than a few slaps on the back. You have to really, really, REALLY want to do it, and a blog post is a bad way to ask for passion. Passion is discovered when you realize you need something, and it's not there (or not ENOUGH there). By dropping out, I've created an environment where people have to really examine their use of Capistrano and decide how passionate they are about it. Passionate enough to pick up where I left off? We'll see.

My decision was the right one. I stand by it. There has already been a post on the mailing list by a couple of programmers who have the credentials and the passion, and are willing to carry the torch. Maybe they would have responded to a blog post. Maybe not. But they've responded now, and now the community can either support them, or look elsewhere. My official sanction has nothing to do with it.

I am sorry you (and a handful of others) are frustrated. I wish it hadn't come to this. But honestly, it's not my problem anymore. (And my! How wonderful to be able to say that!)

I don't believe that's effective, especially for projects like Net::SSH and Capistrano where the hacker-to-user ratio is so low. If someone wants to step forward and maintain Capistrano, they'll do so, and the community will organize around them because they'll show they have the passion to do it. If no one steps forward, then an appointment would have failed anyway, because obviously no one has the necessary passion to maintain it, and it might be better for it to die and make way for other alternatives. Either way, appointing a successor would be futile.

Even if no one steps forward, would that be so bad? Capistrano works perfectly well for the vast majority of folks. It's not like I'm leaving behind a legacy of mostly-broken software. :)

Why is it "grossly irresponsible" of me to take this action? Are lives going to be lost or injured as a result? Will the economy suffer? Will my leaving this project result in a health epidemic?

I've never made any promises about the project. I never claimed that I would be around for ever. I never said I would ignore questions, either -- just that I would ignore emails sent directly to me. But I'm going to remain on the mailing list, and will remain about as responsive there as I have (and I'm, by far, the most frequest poster there).

Actually, the two are orthogonal. You can monkey-patch an aggregation into a model as easily as you can monkey-patch anything else in.

Also, modules aren't monkey-patching. :)

  http://en.wikipedia.org/wiki/Monkey_patch

Lastly, the modules referred to in the article were added statically, not dynamically. We don't use a lot of dynamic module inclusion (though we do it some).

It is db-backed. It's just that the fields exist on the people table, instead of in their own table.