My new MacBook Air is supposed to be delivered next Thursday. I’m planning to use it mostly as a desktop (so I have to migrate my existing Mac mini to it) but it will also travel with me (so I have to make sure everything that’s on my existing MacBook Air gets copied, too).

I’ve just started figuring out the least bad way to do the migration; it seems like the smart thing is to copy everything from the existing Air to the existing Mac mini and then build the new machine from the mini. But I have a couple of weeks to figure it out.

Or I did. Today, I got an email from Apple telling me to come in and pick up my machine! But I decided not to do it today because I was very busy getting the High Holy Day Honors ready to go, which required dusting off code I hadn’t seen for a year.

I couldn’t resist fixing one of the many infelicities in the code – for historical reasons, it uses an unholy mixture of files in Dropbox, Google sheets, and even local CSV and Excel spreadsheets. I changed the code so that the data from one of the local spreadsheets is now in a tab in my master Google spreadsheet, which will make it easier to find and update next year.

Tomorrow, we have a High Holy Days planning meeting; I should be ready to send out the Honors after that meeting (maybe even before).

And then I can go to the Apple Store and pick up the new Air and really get confused.

I had big plans for today – I was going to get caught up on Quicken, wine bookkeeping, refill the wine refrigerator, and work on the High Holidays honors for Shir Hadash.

I got caught up on Quicken and put the wines we bought yesterday into CellarTracker, but the rest of the plans will have to wait.

I wrote a program a while ago to help me pick which wines to move into the wine refrigerator (based on how far along in the drinking window a wine is and how many bottles I have of it), but I noticed that the list showed the same wine in several places. I’d reworked the program a few months ago to take the inventory information I get from CellarTracker and put it into a simple sqlite3 database to figure out which bottles to move. It seemed to work well, but today I realized that CellarTracker returns the information in order of acquisition, so that if I bought the same wine a few times, it wouldn’t be consolidated.

It should be easy to consolidate the data in the database – all it would need is a few GROUP BY clauses in my query. I looked at the statement I was using to query the database:

select
  type,
  ready,
  whereitis,
  b.label,
  beginconsume,
  endconsume
from
  (
    select
      min(n, n * (now - bc) / (ec - bc)) as ready,
      label,
      beginconsume,
      endconsume
    from
      (
        select
          count(*) as n,
          julianday(beginconsume || '-01-01') as bc,
          julianday(date(endconsume || '-12-31')) as ec,
          beginconsume,
          endconsume,
          julianday('now') as now,
          vintage || ' ' || wine as label,
          type
        from
          wines
        group by
          label
      )
    order by
      ready
  ) r
  inner join (
    select
      type,
      vintage || ' ' || wine as label,
      location,
      location || ' ' || bin as whereitis
    from
      wines
  ) b on b.label = r.label
where
  ready > 0
order by
  ready desc;

and I realized that it would be a whole lot easier to rewrite the logic in simple Python than it would be to figure out how to fix the query.

So I did.

Doing the work in Python may mean that the program runs slower than doing it in the database – on the other hand, I only run the program once a month or so, and it only takes a couple of seconds when I do run it. And next time, I might be able to figure out what I’m doing!