Yesterday @philip and I met and discussed various startup issues I had on my mind. Incredibly valuable conversation! I came away with several new insights and a whole list of things I could do to make progress.
Also just created a new Beeminder goal–narthur/err–that’s a simple autodialed Toggl goal for spending time working on fixing existing code errors and making the code more robust against future errors. I think that’ll be the best way to start making steady progress on that front.
Recently I’ve been working on trying to improve @shanaqui’s workflow for handling support requests. Currently it requires them to switch back and forth between the Slack bot and the email client to copy over the user ID and task ID. I’m hoping to reduce the amount of friction here or perhaps eliminate it.
I’ve discovered a bank transaction for the TaskRatchet account from a payee I know but the transaction I don’t recognize. So plausibly it could be legitimate, but it’s also worrying. I’ve created a new Beeminder goal–tr-ynab–to help me start better staying on top of TaskRatchet’s money flow.
I deployed an update to the internal Slack bot so @shanaqui can now delete users. It deletes all their tasks, then their user, and finally deletes their associated customer from Stripe. It was pretty interesting learning how to create a confirmation popup so we don’t accidentally delete any users.
Also I’m considering switching to use a monorepo for TaskRatchet. Currently we’re using separate repos, specifically so that I can selectively make some of the repos public. However I’m not sure that’s valuable enough to outweigh the potential development simplification of combining everything into a single private repo.
I don’t have that much experience with monorepos. I’m already using pnpm to manage a monorepo for the TaskRatchet API since that repo contains both the old python and the new typescript versions. So I might use pnpm or maybe turborepo if I decide to go that direction.
I’ve tried Turborepo and found it a bit immature and hard to use. On the other hand, I have better experiences with Nx. (mostly backend stuff)
Using YNAB for TaskRatchet has been working well so far.
At @sheik’s recommendation I spent some time reading Nx’s website. Seems pretty cool. Definitely currently leaning towards using pnpm + nx for a monorepo.
The ADHD medication shortage has hit Michigan, so not sure if I’ll have that help for a while. So opportunities to experiment more with techniques for managing to work even with my ADHD untreated. However it’s hard for me to imagine that I’ll be able to avoid having my work bandwidth reduced if I’m unable to work out the issue with getting my medication.
At @philip’s prompting, I’ve scheduled my tr-finance goal for archive and added a new tr-finance-blocks goal to replace it. Basically this is a switch from tracking straight time to tracking half-hour blocks, with the hope that it’ll help me do more meaningful work when I have a beemergency, and also reduce the number of days I need to make progress on this goal.
Been doing some more thinking on how to structure TaskRatchet’s GitHub repositories, and this is what I’m thinking so far.
Basically I’m thinking to create two monorepos–a clients monorepo which will be public, and a private infrastructure monorepo.
I think this has two big benefits to creating a single monorepo:
In addition, I expect I’ll be leaving quite a few of my existing repos as-is, either because they are mostly abandoned or it’s otherwise unclear that there would be much benefit to moving them into a monorepo.
I’m thankful that I was able to receive my medication this month after all. Though I expect it will always be a concern. I’m working to do better at building exercise into my life to try to better diversify the tools I’m using to address my symptoms.
I’ve created the second infrastructure monorepo, this one private, and imported all the repos into it I specified above, archiving them after importing them.
I’ve converted a second of my startup-related goals to block-style–err to err-blocks. This goal is for spending time working on resolving production errors.
I posted this update on an old discussion about what programming language I should use for TaskRatchet’s backend:
In it I joked that in the future I may fail to resist the urge to port TaskRatchet to Haskell, though I think in reality, the benefits of being able to build both the frontend and backend in the same language (TypeScript) has enough benefits that I’d need some pretty strong arguments to switch to a different language.
I’m pretty sure there do exist Haskell frameworks that would let you write both the front + backends in Haskell (and e.g. compile the frontend to JS or WASM — GHC just added native WASM code generation recently) but I am not familiar with them. I’m not going to suggest that you ought to switch, but if you ever do I’m happy to give Haskell advice. =)
I’m pretty sure there do exist Haskell frameworks that would let you write both the front + backends in Haskell
Yep, see Reflex. This is the only one I’d feel comfortable using in production. Miso exists but has only had one commit in 2023.
compile the frontend to JS or WASM
WASM can’t be used for frontend AFAIK — it has no DOM access (in general, not merely in Haskell).
Given that the official JS backend a) has been merged into GHC but b) is still not feature-complete, right now might be the worst time to use GHC for frontend 
JavaScript backend merged into GHC | IOG Engineering
Is GHCJS dead?
Not yet! As it stands, the JavaScript backend doesn’t provide all the features provided by GHCJS. In particular it doesn’t support Template Haskell and we’ve removed the extended GHCJS FFI syntax to refine its design. See our roadmap below for more details.
Nevertheless GHCJS is unlikely to be updated to use a GHC version more recent than 8.10.x. So from our point of view it is in maintenance mode until the JavaScript backend totally subsumes its features. New maintainers who want to continue the development of GHCJS until its feature set has been fully subsumed by mainline GHC are of course welcome.
This said, the last time I used GHCJS was a couple years ago for a toy thing, so it’s not a particularly well-informed take.
Given that the time I have to work on my own projects continues to be constrained, I’ve decided to explicitly shift my focus back to TaskRatchet. With almost no marketing it continues to grow, so I think that’s a good signal that that’s the best place for me to put my energy.
I recently deployed a few fixes to the TaskRatchet API, which forced me to fix the deployment pipeline on the new infrastructure monorepo. It was quite a headache to get working since I had to change how I was authenticating with Google Cloud from GitHub Actions. But it’s all done now, so I think future API work should go quite a bit more smoothly.
Today I did some work on the autodialer and thereby more time on fixing deployment automation in the new clients monorepo. It does seem like Netlify has very good monorepo support. Each site can have a sub directory specified, and it will cancel deployment previews for sites that weren’t changed.
I’m planning to switch TaskRatchet over to monthly billing. This is for two reasons:
This change is not imminent–it’ll take some dev work to complete.
In addition to my ongoing conversations with @philip, I’ve started talking to Melissa of Datasmithing. I’m hopeful that she’ll be able to help me find ways to rearrange things to allow me to put more energy into TaskRatchet.
I’m currently considering shifting how I manage my time, basically blocking out periods of time to focus on specific projects. I’m still trying to work out how I’ll handle that in practice, what goals and automations I’d need, etc.
