TaskRatchet Development Updates

Update:

API:

  • Made some modifications to allow Google Cloud Scheduler to ping it multiple times a day to send out morning emails. This is what allowed me to reopen the alpha. (:tada:)
  • Started work on integrating with Stripe so that authorizing and capturing charges can be automatic.

CLI:

  • Decided to build it in Python. (Sorry @phi!)
  • Added a generic command that allows me to test API endpoints more easily.

Yesterday my wife suggested that delete always be available, and it just immediately charge you the amount you pledged. So, in essence, you decided it would cost you this much not to do the task, and you can decide to pay that at any time to make the task go away. Basically an uncle button, in Beeminder parlance… Does that approach make sense to you?

2 Likes

Hmm. Deletion-wise, what about a case where a task becomes pointless? E.g. you pledge to do something for work by x date, but someone else ends up completing it or the task is no longer necessary? Do you just count it as complete then, even if you didn’t complete it? :thinking:

3 Likes

That’s a good question. It seems like that’s the perrenial issue with task lists. I don’t know if I have a full answer to that, though I think it’s partially to be careful regarding what tasks you create.

I’m definitely open to any insights you all may have on this question.

2 Likes

I like it, but I’d say to make sure the interface is clear that “delete” means “pay.”

I still think you should be able to delete without charge in the first 10% of the time, for typos and situations where you realize right after you make a goal that you won’t be able to do it.

I think of it like a to-do list - when it no longer needs to be done, you cross it off.

2 Likes

Relevant:

@mary and I had an out-loud discussion of that as well and came to a conclusion that we failed to write down and now can’t remember!

3 Likes

Interesting discussion! The key difference is that one is a personal to-do list, so the emphasis is on what you still need to do, and the other is a promise to someone else, so the emphasis is on your reliability as a promiser.

3 Likes

Update

Setting up automatic Stripe charges has proved to be more involved than expected. The way I have payment methods stored now, Stripe won’t allow me to create new charges via the API. In order to store the payment methods the way Stripe wants them, I need to set up a page for users to use to re-add their payment details.

In order to do that, I may as well build this page in a way that I don’t have to rebuild it once I start on the web app. So that basically means starting on the web app now, which I’ve done here. I’ve switched away from Elm to Angular, as this will allow me to be productive immediately.

:wave: I think you may be having problems getting my emails; I’ve sent you several without acknowledgement? (Please don’t charge me, I’ve completed all the tasks so far!)

2 Likes

@shanaqui Oh, my! Yup! I see the emails. My apologies for not staying on top of that. Expect responses today. :smiley:

Whew. :smiley: Just thought it’d be best to check in about that, since I had two tasks showing as overdue.

1 Like

@shanaqui Yes, totally my fault. I’ve created a Beeminder goal to help prevent this from happening in the future:

Do note, though, that weekends will continue to be challenging for me as long as I’m running the service more-or-less manually.

3 Likes

something something Pavlovian response something something

1 Like

Oh totally, just wasn’t sure how soon you’d be charging the ones which had become overdue. (Is there a plan for that?)

1 Like

lol Accurate. :stuck_out_tongue_winking_eye:

Right, charging tasks is all manual right now. I’m working on changing that, but getting to that point requires quite a few other things to be in place, too.

Once it’s working, the way it will work is that a charge will be authorized soon after the task becomes overdue, and then >= 24 hours later, the charge will be captured.

Update

API

  • Still working towards automatic charges.
  • Made API infer user id when possible (Thanks @zzq for pointing this out!)
  • Updated auth strategy to be less broken and more normal (Thank you, @zzq!)

CLI

  • Add get method support
  • Add --staging flag
  • Improve arg parsing
  • Improve usage docs

Web

  • Build some basic web components just to get a feel for things
  • Add Storybook for isolated component development && testing
2 Likes

Update

I’ve really bogged down with getting automatic charges working. To save cards to Stripe in a way that allows me to create new charges later, I have to use a somewhat complicated flow, which in turn requires building out the web app to include a functional card saving interface. This also requires authenticating the user to ensure we’re saving the card to the correct user account in the database.

I started trying to make this happen using Angular, but I’m questioning whether that was the right decision. I’m considering trying this in Vue or React to see if it’s more approachable for me. React would also be nice on a personal level since I have some contracts coming up where I’m expected to build things in React, so building the web app in React would mean I’ll likely be more productive on all these projects.

1 Like

Update

  • Switched to React for the web app.
  • Gave the landing page a small face lift, plus legal stuff due to services requiring I have them.
1 Like

Update

I’m taking a few days off from TaskRatchet, but I’ve been reaching out to some people for advice on session management and authentication, including the great @zzq.

Update

I’m taking a break from TaskRatchet development for a while to get some health issues under control. So I won’t be working on the project or posting updates here from 9-23-19 to 10-14-19.

Also, I won’t be actively managing the alpha October 4-14, so feel free to continue emailing me new tasks and completions during that time, but I won’t be updating your data or creating charges until after I get back.

1 Like