I used to do Sudoku all the time, but I lost interest around the time Lauren came into our lives. Coincidentally (?), I'm back into it again.

(Oh, what's Sudoku? It looks something like a crossword puzzle, but it's all numbers. 9x9 grid, divided into nine 3x3 sections. To finish the game, every row, column, and 3x3 section must have all of the digits 1-9. There's no math involved, other than being able to count to 9. There is some real logic involved, though.)

When at my computer I use Verek's Sudoku Companion. It's freeware, though it didn't used to be: I had to pay for my copy. (Verek is no longer in business, though, so I'm glad they're giving the app away.)

Sudoku Companion gives you all the options I think you might need in a computer-based version of the game, other than an "I give up just solve it for me" button. It offers six levels of difficulty: Easy, Medium, Hard, Fiendish, Insane and Sudoku of the Day. I'm not sure where the Sudoku of the Day comes from, but everybody running the app gets the same one on the same day, so it's a nifty way to have a little friendly competition. A timer at the bottom of the window tells you how long it's been since the game started, and the timer pauses if the game isn't frontmost (so if you take a break, the timer stops). You can also create your own sudokus, and save/share them. (It's very difficult to create a good one, though.)

I can usually complete an 'insane' sudoku in about thirty minutes. The dailies are usually forty minutes to an hour.

If you like sudoku and you're on a mac, go get a copy of Sudoku Companion (that's the direct download link). Do a couple warmup games, and then try Sudoko Companion Daily.png. It's the most difficult sudoku I've ever played, and took almost two hours to complete!

Retail software is a three legged stool.

• User Interface
• Engineering

Right?

Oh, what? There are only two legs there? Huh. What's missing?

Marketing is the third leg. Very rare is the product that can succeed without it, no matter how well crafted. (Yet so many try.)

More on this soon. Something very big is brewing.

My PMC fundraising efforts are winding down for the year. We've raised almost $18,000!

• $12,851.76 on my account
• $4,200 (approximately) on Dave Schlageter's account
• $650 on Chris Rawson's account

That all adds up to 17,751.76.

We've delivered 228 bundles so far, and still have another 28 somewhere in the pipeline (either waiting for payment or we're waiting for registration codes).

(I keep saying "we" because Corinne and Cindy are still helping me.)

We're going to keep accepting offers for a few more days.

On the technology side, I'll mention that this morning I totally rewrote the code which decides if a bundle will be accepted. In the process I made it fairer, and lowered the price points at which an offer will be accepted.

It's all based on percentages. First it divides your offer by the total retail value of your bundle to get the bundle's "offer percentage." So if you offer $50 for a bundle that's worth $100, the bundle's offer percentage is 50%. Then it figures out the minimum percentage we'll accept for that bundle, based on the following rules:

1. There's a minimum offer percentage, let's call it min_pct. Any offer below that is rejected.

2. There's a maximum offer percentage (max_pct). Anything at or above it is accepted.

3. Small bundles (where the retail is at or below a certain threshold, min_ttl) must be at or above max_pct.

4. Large offers (retail above a certain threshold, max_ttl) must be at or above min_pct.

5. For bundles whose retail value is between min_ttl and max_ttl, it figures out what percentage to accept. It's a sliding scale based on where the bundle's retail value falls in the range between min_ttl and max_ttl.

6. There's one last complication: if the bundle included any "rare" apps, then the required percentage is raised by a certain amount. An app is rare if there is only one left.

Follow all that? Hey, even if nobody else cares, at lest this will serve as a good refresher on the math in that code, the next time I need to update it.

Now go build yourself a bundle before we shut it down for the year! Most of the titles have not sold out.

I'm raising money for the PMC again this year (duh), and doing it the same way as last year (and the year before, and two years before that). What method is that? I ask lots of developers (companies and individuals) to donate copies of their Mac apps (and iPhone, this year), and then I sell them in bundles.

Some developers donate five copies, some one hundred. Some tell me I can have as many as I want.

I don't really sell them, either. I give them away as thank you gifts in exchange for making donations to the PMC via my fundraising account. The “buyer” builds their own bundle out of the big list of available software, then sends me an email to tell me about it, including how much they'd like to pay.

The project is a huge amount of work. Everybody gets a response, even those offers that are turned down for being too low. An accepted offer involves LOTS of email:

1. in: initial offer
2. out: your offer is accepted, please make donation
3. in: donation receipt as proof of payment
4. in: “What’s taking so long?”
5. out: acknowledgement of receipt, “please be patient”
6. out: one registration request for every app in the bundle, sent to the donors
7. in: one app registration per app in the bundle
8. out: “Thank you for your donation, you can download your software here…”

(That's just the simple ones. Some bundles have twice as many messages, due to questions or problems.)

Between sending out all those messages, there's a database that needs to be maintained to keep track of everything. Apps are reserved for a “buyer” so that we don't agree to a bundle and then run out before we can fulfill it. Registration codes have to be copied into the database when they come back from the developers/donors. The buyer’s contact info needs to be entered before we ask the app donors for registrations.

It's a lot of work. I used to do it all myself. I put the project off this year because I absolutely dreaded doing it all again.

To my rescue came Corinne Dillingham (my wife) and Cindy Compton: both have volunteered many hours on this project to help me deal with all this email, via a shared gMail account.

Corinne's helping me because she loves me and knows this is important to me. Cindy's helping because she's been bitten by cancer herself, and is still fighting it... she bought a bundle last year, and this year she's in the trenches with us.

Unfortunately the project has one major flaw: it's far too much work! I keep streamlining the process, but no matter how smooth I make it, it's all still being done manually. Three people can't possibly keep up with dozens or hundreds of people making offers all at once. We fall behind. We run out of apps but the bundle builder still lists them as available because we don't even know we're out yet, as they are "taken" by email which is still in the queue. So, we keep getting more offers for apps that have sold out.

Clearly, I'm doing it wrong.

The donors have been very generous in covering our oversells. (Thanks guys and gals!) Still...

This is the last year I'm doing it like this. Let me say that again: this is the last year I'm doing it all this way.

This is clearly a great way to raise money for the PMC. Last year I raised over $14,000, and most of the work was done in just a couple of weeks. This year looks pretty good too. It's just too much work!

That doesn't mean I'm quitting. It just means that I need to finish my "PMC app" (the database app we use behind the scenes) and make it a full web-app, like a storefront, and fully automate the process.

If I don't have it working (at least crudely) by the time PMC signup opens in January, then I'm not signing up.

There, I said it. It's scary, but true. I've just given myself a deadline.

I'll have more to say about this. I know how I want the app to behave, how it should work. I just need to make it happen, and still get paying work done in the process.

Wish me luck! I don't want to give up the PMC, but there's just no way I'm doing it like this again next year. I'm quite pleased with how this has grown and improved over the years, but it's time for it to move up to another level or be allowed to die.

In the meantime, though, go buy a Mac or iPhone software bundle! We'll continue accepting bundles for at least another week or two.

BBEdit 9.2 was released today.

(Sorry about having two BBEdit-related posts in a row like this. I have other things to talk about too, trust me. I'm just warming up again.)

I played a small part, again. Most of my time was spent on the brand-new Lasso module. There are 168 changes in the official change notes. (There were actually a lot more than 168 changes, trust me.) The excerpt listed below includes those I'm particularly happy about or with which I was personally involved.

The blue stuff, below, is what I worked on or was somehow directly involved with.

Additions

• ✫ BBEdit now has a “Sleep” command. ✫

• Lasso is now a fully supported language, with syntax coloring, functions listed in the function popup, and automatically generated fold points.

• There’s a new color setting in the Text Colors preference: “Numeric Constants”. This can also be adjusted on a per-language basis in the appropriate language’s settings (in the “Languages” preferences).

• Added a feature to the language module interface for giving the module control over resolution of include file references.

• The Menus preferences now has a group of commands so that you can assign keyboard equivalents to operations in FTP/SFTP browsers, if desired.

• There’s a new setting in the “Editing” tab for language-specific preferences (Preferences -> Languages): “Tab width”. Edit the value here to set a language-specific value for the default tab width. (I — and probably others — requested this.)

• ✫ BBEdit now implements the necessary hooks so that the following JavaScript functions now work when using “Preview in BBEdit”: window.alert, window.confirm, window.prompt, window.onbeforeunload ✫

• Disk browsers can now explore tarballs (.tar, .tar.gz, .tgz files). When an eligible file is in the listing, it will have a disclosure triangle next to it. Twist it open to reveal the files and directories within. As with other items displayed in disk browser listings, you can view files in the editor view, or double-click them to open in a separate window for editing.

Changes

• ✫ The internal mechanics and UI presentation for recent items have been overhauled. ✫

  I love this one, as the redesigned "Open Recent" menu item is much more usable.

Fixes

• Fixed a bug in the ActionScript function parser. No longer tripped up by a function return type of * (which is the explicit way of typing something as “untyped”).

• Fixed a bug which allowed ActionScript’s get to be recognized as a function-starter in JavaScript files (similar to the function keyword).

• Fixed possible cause of a crash related to populating the function popup in JavaScript files.

• Fixed missing fold widgets for fold ranges containing a single line break.

• Fixed crash when JavaScript functions with assigned names, such as foo.bar[bat] = function() {...}, were not in a recognized/expected form.

• Fixed bug in which using “Save As” did not change the document’s language if the default was something other than “(none)”. This change also addresses a bug in which the document’s language wasn’t recalculated if the file’s name changed on disk.

• A variety of changes have been made to reduce application startup time.

• Fixed a bug in the Ruby module which would cause a multi-line, general delimited input string (%+string+) to fold incorrectly (the closing fold point was one character too soon).

• Fixed a bug in the Ruby module where Begin/End blocks could cause fold points to be be placed at seemingly random places in the document.

• Fixed a bug in the Ruby module where complete for or while loops, written on a single line and within curly braces, could throw off the folding for the entire document.

• Fixed a bug in the TeX module in which a $math$ section within a {required param}, where the $math$ section contained a closing curly brace (e.g. caption{foo $i_{0}$ foo}), would confuse the parser. This tended to manifest as incorrect autofolds and improper indentation in the function popup.

• The Ruby module will no longer detect regular expressions as the first token immediately after a string or another regular expression. This resolves a syntax coloring bug found with the syntax used by the Merb framework (which uses an overloaded ”/” method.)

Now go buy a copy. Or two. Please. More sales at BB means more work for me. (Blah blah blah |BEdit Disclaimer|)