Category: Uncategorized

I’ve gotten to a decent beta at this point, and I’m eating my own dogfood: my urologist put me on bladder training with a two-hour interval, so the app is set up with that as the default interval.

I’ve been testing it as I go along and added a few things that I needed:

1. Custom alert sound. I get enough alerts that I need it to sound different than the others. I’ve got a nice water-drip noise, distinctive but not obtrusive, that fires when the interval is up.
2. The process is not loads of fun, so I’ve added a little whimsy to the alert messages.
3. I’ve got a live activity so I don’t have to unlock the phone to reset the interval when I go.
4. Added quiet hours so it doesn’t ping me every two hours when I’m trying to sleep.
5. Explanatory “why the hell are we doing this anyway” text. Okay, I don’t need that, but it’s useful for someone to refresh their memory, or to get an explanation of why we’re doing it if their urologist has said, “make sure you pee every two hours.”

Running with this version a while to see what else it needs. Will look into art and design after it’s functional.

So one of the things that can happen after prostate cancer radiation treatment (and I note that I don’t think I’ve written a post about that — I suppose I was a bit distracted at the time) is that you can develop what’s called a stricture, ot narrowing, of the urethra from scar tissue forming.

This can cause you to not completely empty your bladder when urinating, and that can cause your kidneys to back up and get stressed.

You do not want to stress your kidneys.

My urologist tells me, “Okay, we need to make sure you’re getting your bladder emptied as much as possible. I want you to go pee every two hours, whether you feel like you need to or not.” Which doesn’t seem like such a big deal, except that I am, as I have noted, somewhat ADHD, and if hyperfocus kicks in, I am very likely to get caught up in something for hours at a time, only dimly realizing that I’m tired/hungry/thirsty/need to pee.

I could manually set myself alarms every two hours but that would be a pain to set up, and a pain to disable if I needed to. So I’m writing myself an app to do it.

It pings me every two hours to remind me it’s time to go; if I do so early, it resets the next interval to two hours from that point. If I don’t respond, it keeps bugging me until I do.

That’s the basic idea; I’m fairly sure I’ll want to add on to it (the process of writing this post reminds me that I really do want to be able to put it in vibrate-only mode when I’m, say, at a concert), but I’m going to get the basic version done and live with it for a while.

No idea if this is common experience, but if it is, I’ll definitely put it out on the App Store.

I wrote about whether the cloud is a long-term safe option for your data a while back, and this article has brought me back around to thinking through that again.

I think it’s important to realize that many of us (certainly I have) become heavily dependent on cloud services for extremely important things. Not “break the bank, on the streets” important but “huge sections of my memories not safe” important.

I am not dissing cloud services just because they are cloud services. I am looking at them again in a more jaundiced light because they are not services in the sense of “there is something wrong, and I can talk to someone and sort this”.

All cloud services hang a sword of Damocles over your head.

If you somehow trigger their automated systems, they will deny you in a flash, and the chances that you will ever be able to resolve the problem are near zero, unless you are a major source of income for them (and we’re talking millions of dollars of income, not something a typical person-in-the-street can generate) or have friends in high places: either someone inside the walls who “knows a guy” or a large and public means of embarrassing them for doing something blatantly stupid via automation.

For instance, there have been large numbers of automated account closings on Facebook of late. People have had their accounts closed in the process of opening them. Yes, this is completely nuts. No, Facebook is not doing anything. Why bother? They have plenty of users now. Who cares if a few hundred or a few thousand people lose access? (Hint: it’s the people who’ve had those accounts and trusted Facebook with their data.)

There’s the guy who uploaded pictures of his kid’s rash for his doctor to check on Google — and lost his account.

There have been a number of folks who lost access to their Apple IDs, resulting in major financial losses, and because they created the IDs long before two-factor and have forgotten their questions and answers…are just screwed.

Shymala and I have had a lot of frustration with Google and Squarespace dropping the ball on her Google Workspace connected to a .studio domain. The workspace is still currently AWOL. And Squarespace is getting 5 Benjamins a year, so it’s not like this is a free account and they don’t have to care at all.

What all these have in common is trusting an external entity to have their bests interests in mind.

Unfortunately, even if you’re paying for it (see Squarespace), you cannot trust that a cloud provider will not arbitrarily decide that you have violated some rule – which they will not often reveal to you, because security – and you’re just done, with no options.

So in this post, I’m going to try to look at what cloud providers I’m using and what I could do to mitigate risks with that provider.

Google

The biggest risk here is email. I have several different accounts, some quite old with a lot of archived email, and a few that are simply convenience accounts that I use to sign into things.

I also have a Google workspace for mail at the pemungkah.com domain, with a couple accounts set up there.

Risks:

• Losing access to my primary GMail would break logins for a lot of things. I have used “Sign in with GMail” a lot. I would also lose a lot of archived mail.
  • A search in 1Password tells me I have 439 accounts associated with my primary GMail. 60-ish are “signs in with GMail” for that account.
• Losing access for my secondary would inconvenience me more than anything else, mostly because I wouldn’t be able to receive password resets or change-of-email confirmations. Some would be harder than others to recover.
  • 29 accounts associated with my music GMail.
• Losing access to the Google Workspace would be a relatively minor issue; I haven’t used it for a lot. I’d have to set up new logins for some of my streaming accounts.

Probably the best thing would be to move my mail to a custom domain. I have several that would do as a base domain, and I could just set up mailboxes for the alternate accounts. A self-hosted mail service would be better; there seem to be some reasonable alternatives but they’d need to be evaluated. Using ProtonMail or Tuta with my own domain is a middle ground.

Apple IDs

Losing my Apple ID would be costly monetarily and emotionally.

• Only 4 non-Apple accounts depend on my Apple ID, and I could live if I lost access to all of them.
• All of my photos are in iCloud. If I lost access to my Apple ID, i could concievably permanently lose access to those. I have backed them up to Google Photos (yeah, not great either).
• I’d lose access to my Apple Developer account.
• My Find My would be broken, leading me to have to scramble to rehome all my devices. Stolen Device Protection would make that much harder to do, but I sure don’t want to turn that off.
• I use Find My Boxes to track where stuff is in storage. If iCloud locks me out, I can’t access that data anymore. (I have written an unloader script that converts that data to HTML, so I’m less screwed than I might be there.)

Microsoft ID

I use this for very little. If it went away I could set up another one.

GitHub

A pain in the ass, but recoverable. I could create repositories somewhere else.

Dropbox

I need to more deeply investigate this. We use Dropbox a lot for archiving stuff, and sharing data for Shymala’s writing and art. If we lost access, there’d definitely be some problems — some of the original art has been sold, and it’d be impossible to get prints of it anymore.

Plans

I need to move my primary email away from GMail alone. If it’s coming to a custom domain, I can just move the mail somewhere else. Proton or Tuta seem best; self-hosting is probably even better but incurs a lot more work for me to do, plus the hosting costs, or doing it locally. (See below for thoughts on that.)

Once I have the new mail, I need to change everything that uses GMail login first, then work through the 400 other accounts in batches. Some are simply “fuck you” accounts for the idiots who use my mail, and I can simply forget they’re there and remove them. The rest I’ll move to the new custom domain.

I can’t completely get rid of my Apple ID without losing iCloud and Apple Developer access, so I’ll set up a new Apple ID for the custom domain, and then migrate to it. The purchases on the old account will have to stay there, so I’ll set up a new Family account with the new email as the primary and add the old Apple ID as a secondary. I will add the new account to my Apple Developer origanizatin, and move all the responsibilities over to the new account, then start purchasing the Apple Developer access from the new account.

For GitHub, I’ll want to fork everything to the new account and close the old one. (GitHub may have a “move account”; if so I’ll use it). I will want to self-host a Git repository that I can push to as well.

Self-hosting

It’s possible to host most of this stuff on a server either at a colocation site or on a box literally in the house with Tailscale. Cohosted costs extra money, but has the advantage that I could put it at (say) Hetzner and outside the US, given the current political climate. In-house is max control and possibly a lesser ongoing investment but I’d incur a dependency on Tailscale. Going to have to work out the numbers and decide about this.

Summary

My heavy dependence on one GMail address and Google in general is not great. I should move the pemungkah.com domain to somewhere else (handwave) and use a custom email instead of GMail, and change everything over to that from the GMail address at a minimum.

Dropbox is going to be an issue, and I still need to make sure I have a way to really for-sure back that up.

Everything else depends on the GMail move, so I will be concentrating on that over the next few months.

That email address is now officially defunct.

I checked; I created it back when I bought my iPhone 5.

Years ago, it got leaked, and it has since been used for everything from someone in Canada’s VISA card to a bank account in Vietnam to some bozo’s Marriott account. (Hey David: thppppppppbt.)

It got so bad that when Apple opened up creating Apple IDs with your own email, I did that, and essentially abandoned the me.com address.

I used it for just political mail for a while, but I’ve gotten disillusioned that letting every random person running for office send me begging letters does any good, let alone giving them money. (They’re never “I did this because that’s what you sent me to Congress to do”, but “MY OPPONENT HAS MONEY! WE’RE CRYING! SEND ME MORE!” — and most of the time it’s futile anyway.) Mostly it was spam, people using it as a test email (especially screw you people: use MailHog or something. How are you going to know if the mail you’re sending looks right it it just goes somewhere you cant even read?)

I closed it today. Only had a couple things still left from the downloads I used it for, and I can reinstall them from my primary if I want them.

A grand experiment, but I’m not sad to never have to deal with it again.

I’ve been running OCLP (the Open Core Legacy Patcher) on my 2012 MacBook Pro; recently I ran softwareupdate from the command line and accidentally upgraded to Sonoma from Ventura. The experience was definitely mixed.

It handled it mostly okay for day-to-day work. Xcode 15.4 ran fine. Where I hit a problem, though, was when I tried running Azuracast under Docker. The machine ran insanely hot, so hot that it started throwing screen glitches. Rather than burn out my GPU, I elected to downgrade to Ventura. Here’s how that went. (Spoiler: a lot of toil.)

Getting Ventura back

The first step was to get Ventura back on the machine, This wasn’t particularly hard; I just needed to follow the standard OCLP procedure, but install to a new partition on my internal SSD. This cut the amount of space down by about another 200GB, but went well. I was able to install and have Ventura in good shape in a couple hours.

Retrieving the data from Sonoma

Here’s where we started having problems.

I had hoped that I’d be able to use Migration Assistant to bring the data back from Sonoma to Ventura, but no dice. Migration Assistant looked at the Sonoma disk, said, “nuh-uh, I ain’t downgrading” and refused to even consider mounting the disk. This meant I’d have to port everything back from that disk to the new one manually.

My first try was to rsync it over. This failed because now I didn’t have enough space to have two copies of the data. I deleted the data from the Ventura install and tried again. This time I created a service account with admin privileges, and copied ~/Library over from Sonoma. This didn’t seem to work either; most particularly iCloud login was broken.

Fixing the broken copy

After thinking about it a while, I decided that the problem was probably permissions. From the service account, I wiped the Ventura copy of my account again, and copied in two steps. First, I copied ~/Library over, then chown‘ed it to my user on the Ventura disk. I logged in as myself, set up iCloud, and all was good. Now came the question of moving the data without filling the disk.

I was able to use rsync (from the service account again), but this time I added --remove-source-files and --ignore-existing to the command. This copied only files I didn’t already have on Ventura from Sonoma, deleting them as they transferred. After this finished, I logged in to my Ventura account, iCloud was okay, and all my files were back.

I then rebooted into the installer again, removed the Sonoma partitions, and was ready to go.

I’m now currently running Azuracast under Docker, and having it ingest the RadioSpiral tracks from my iTunes library. It’s running warm, but not hot, and no more screen glitching. I’ll probably leave it on Ventura unless someone else running the same machine gets good performance from Sequoia.

And I can always run Linux if all else fails.

Visit the nodes of a binary tree in level order: all nodes at the root level, left-to-right, all nodes at level 1, left-to-right, etc.

I did try to solve this with slices and boy did I have trouble. I eventually stopped trying to use them and went to a list-oriented solution with a double closure.

/**
 * Definition for a binary tree node.
 * type TreeNode struct {
 *     Val int
 *     Left *TreeNode
 *     Right *TreeNode
 * }
 */

type MyList struct {
    head *MyNode
    tail *MyNode
}

type MyNode struct {
    Val int
    Next *MyNode
}

func levelOrder(root *TreeNode) [][]int {
    // Ideally, I want to end up with an array
    // of arrays of nodes, added in left-to-right order.
    getStash, helper := createClosures()
    helper(root, 0)
    stash := getStash()

    out := [][]int{}
    for i := 0; i < len(stash); i++ {
        out = append(out, []int{})
        thisList := stash[i]
        for scan := thisList.head; scan != nil; scan = scan.Next {
            out[i] = append(out[i], scan.Val)
        }
    }
    return out
}

func createClosures() (func() []MyList, func(*TreeNode, int)) {
    stash := []MyList{}

    var helper func(*TreeNode, int)
    helper = func(root *TreeNode, level int) {
            if root == nil {
                // Nothing to do at this level
                return
            }
            // Current node gets stashed at the end of the list for this level.
            // (*output)[level] is the slice to append to.
            // Add new node to list at this level
            if len(stash) <= level {
                stash = append(stash, MyList{})
            }
            
            n := &MyNode{Val: root.Val}
            if stash[level].head == nil {
                stash[level].head = n
                stash[level].tail = n
            } else {
                stash[level].tail.Next = n
                stash[level].tail = n
            }
 
            // add the left and right subtrees at the next level down
            helper(root.Left, level + 1)
            helper(root.Right, level + 1)
        }
    return func() []MyList { return stash }, helper
}

This solves the problem, but it’s poor on memory (8th percentile) and runtime (26%). On the other hand, the list manipulation worked correctly the first time. Let’s try to speed it up. First let’s try to remove the lists.

/**
 * Definition for a binary tree node.
 * type TreeNode struct {
 *     Val int
 *     Left *TreeNode
 *     Right *TreeNode
 * }
 */

func levelOrder(root *TreeNode) [][]int {
    // Ideally, I want to end up with an array
    // of arrays of nodes, added in left-to-right order.
    getStash, helper := createClosures()
    helper(root, 0)
    return getStash()
}

func createClosures() (func() [][]int, func(*TreeNode, int)) {
    // This will be our output structure. As we go down the
    // levels, we add more []int slices to hold the next level
    // of nodes. Because we work left to right, we always add
    // new nodes at a level to the correct slice, and they always
    // are added to the right end of the slice, giving us the
    // output data structure we want.
    stash := [][]int{}

    // We have to declare a named variable to be closed over for
    // a Go anonymous function to be able to call itself.
    var helper func(*TreeNode, int)

    // The real meat of the process.
    helper = func(root *TreeNode, level int) {
            if root == nil {
                // Nothing to do at this level
                return
            }
            // Current node gets stashed at the end of the slice
            //  for this level.
            // stash[level] is the slice to append to.
            if len(stash) <= level {
                // We have never accessed this level. Add a slice
                // so appends will work. You CANNOT just assign to
                // stash[level], because it doesn't exist yet and
                // you'll get an out of bounds error.
                stash = append(stash, []int{})
            }
            // Add this node's value to the end of the list at this
            // level.
            stash[level] = append(stash[level], root.Val)

            // add the left and right subtrees at the next level down.
            // Because we're tracking the level, we always append to the
            // right slice in the stash, which lives outside the recursion.
            helper(root.Left, level + 1)
            helper(root.Right, level + 1)
        }
    // The two functions the main function needs to call. Stash will be
    // exactly the needed data structure when helper finishes.
    return func() [][]int { return stash }, helper
}

That’s a significant improvement; 71st percentile runtime, 24th percentile memory. The problem I had the first time around was not properly managing the slices. To add an element to a slice after the current end, you must use append(), and I needed to do this for each level as I got there. The code to build the output structure from the lists was the learning experience I needed to get that part right in the rewrite.

Still definitely more comfortable manipulating data structures. Let’s try removing the closure and see how that goes; we’ll just let scoping make the stash visible to the helper.

/**
 * Definition for a binary tree node.
 * type TreeNode struct {
 *     Val int
 *     Left *TreeNode
 *     Right *TreeNode
 * }
 */

func levelOrder(root *TreeNode) [][]int {
    // Ideally, I want to end up with an array
    // of arrays of nodes, added in left-to-right order.
    stash := [][]int{}

var helper func(*TreeNode, int)
    helper = func(root *TreeNode, level int) {
            if root == nil {
                // Nothing to do at this level
                return
            }
            // Current node gets stashed at the end of the list for this level.
            // stash[level] is the slice to append to.
            // Add new node to list at this level
            if len(stash) <= level {
                stash = append(stash, []int{})
            }
            stash[level] = append(stash[level], root.Val)

            // add the left and right subtrees at the next level down
            helper(root.Left, level + 1)
            helper(root.Right, level + 1)
        }

    helper(root, 0)
    return stash
}

Interestingly, this is actually worse according to leetcode; 68th percentile now (3ms instead of 1ms). Honestly I think we’re in the noise at this point. No change in the memory usage.

I think if I’d gotten this in an interview I’d call the second or third solution good, and the first marginal. The rewrite time from the list version to the working slice version was only a couple minutes, and I never felt like I didn’t grasp the necessities of the problem.