Beeminder Forum

TaskRatchet Development Updates

:stuck_out_tongue_winking_eye: You caught me! lol

The nice thing about using a headless architecture is that the Android client won’t need to care at all about what the backend is written in. All it cares about is the REST API.

And I’ve never done any Android development, so that’ll be a learning process all it’s own. :wink:

This week I’ve started work on designing the API which will be used both by the official clients and end users. I’m very new to API design, so I’ve started going through a course on RESTful API design. (Thanks to @clarissalittler for reminding me to check if my local library provides its members access to Turns out they do!)

1 Like

I’ve dabbled in both Elixir and Erlang and have built some for-real systems with Akka (a Java-based actors framework, which has the same sort of concurrency model as Erlang/Elixir) at work.

I like Elixir a lot, although I tend to still favor Python and JavaScript for personal projects, out of pure get-it-done-fast familiarity.


I second Akka. It’s a Scala library and the people who made it really know what they are doing. Akka is also more or less the birthplace of reactive streams which even made it into JDK 9.

I am making Beegment with Akka, maybe check that out as an example :slight_smile:

1 Like

I’ve finished watching the course on RESTful API design and created a rough draft of a version 1 of the API, modeled very much after Beeminder’s API. Feedback appreciated. :slight_smile:

Get user

GET /users/{user_id}

Result: userId, email

Get tasks

GET /users/{user_id}/tasks

Result: [task, task, …]

task: taskId, description, due, stakes, status(active,complete,missed,archived)

Get task

GET /users/{user_id}/tasks/{task_id}

Result: taskId, description, due, stakes, status(active,complete,missed,archived)

Create task

POST /users/{user_id}/tasks

Parameters: description, due

Result: taskId, description, due, stakes, status(active,complete,missed,archived)

Modify task

PUT /users/{user_id}/tasks/{task_id}

Parameters: description, due, status


If constraints fail: false
If constraints pass: taskId, description, due, stakes, status(active,complete,missed,archived)


Active tasks: Status can be changed to “complete”
Missed tasks: Status can be changed to “active” or “archived”; if changing to “active”, description and due date can be changed

1 Like

And, more progress:

  • I created a GitHub repository for the web client. I’ll be building it out first, mocking out the API as I go. That way, if the API needs to change, I won’t have to rebuild anything.
  • I’ve made the first wireframe for the web app (this is not intended to be final in any way):


Suggestions, critiques, and pull requests welcome. :slight_smile:


So I’m confused - is this API supposed to be accessed through HTTP, with the GET and POST? That seems very strange to me - why would you route it through HTTP? I know Beeminder does it but I’m not aware of any other API that does and it strikes me as odd.

I’m new to API design. My understanding is that most RESTful APIs are based on HTTP. What is the alternative you see most APIs using?

1 Like

Well it’s a REST API. What APIs do you know of that claim to be RESTful yet do not sit on top of HTTP?

But to answer the “why http” in a bit of a tangent: Back in the days people started abusing HTTP for things other than HTML and website resources primarily for the simple reason that most firewalls allowed port 80 already whereas using a different port required your network operator to whitelist that port by hand.
It was pure convenience. Not exactly a technical necessity.
Soon™ many services would just simply use HTTP and port 80 (and SSL and 443 respectively) and firewalls “had” to advance to higher OSI levels for traffic that used to be discernible because of its port numbers now became a black box. So nowadays firewalls look into the actually HTTP packets and try to figure out what is going on, adding complexity and so on and so forth. All because port 80 was already allowed and custom ports weren’t.
And what do users use if in doubt? The service that “just works” out of the box.

  • I’ve switched from using Reactor to actually doing a proper compilation. This allows for committing the compiled app, which in turn makes the next two enhancements possible.
  • I’ve added a stylesheet. It’s currently not doing anything useful except proving that I’ve done it. It’s precompiled from less.
  • I’ve set up GitHub Pages on the repository, so you can launch the app (such as it is) without cloning the repository. Nice!
1 Like

I’ve been spending a lot of time listening to interviews with people who have turned their own side hustles into businesses. Also, I’ve been going through a course on on customer development. My new top priorities for the project are:

  1. Start having interviews with potential users (please reach out!)
  2. Start capturing leads on the landing page
  3. Start running a service with as little code as possible, mostly manually (yes, Shirk & Turk style), to start getting some data I can use to inform the development of the service
1 Like

So far I’ve had one conversation with @zzq. It was very insightful. I’d like to have a lot more interviews with potential users (hint, hint), or really anyone who uses Beeminder. I need to start reaching out to more people directly to schedule interviews instead of waiting for interviews to come to me. Probably should make a goal for that… :wink:

I’d also really like to switch as quickly as possible to getting feedback from real users instead of potential users, and that means MVP time. I’m thinking I could start out by sending a daily email to a group of alpha users asking them what’s on their plate for the day. They can respond back (or not) with a list of tasks and stakes for each. I’ll then enter those tasks into an AirTable base. I can generate views using the base to see what tasks are upcoming or overdue, and send email reminders to the appropriate users. If a user misses a deadline, I can manually create a charge in Stripe.

This is so ridiculously manual that I have a feeling I won’t be able to resist the urge to automate almost as soon as I start. But I think if I can resist that urge for just a little bit I stand to learn a lot by having such a high level of awareness into how the system is working for those daring enough to join the experiment.

Thankfully, once I do stop resisting, AirTable has a fantastic API, and I think Stripe has a good one too (haven’t used it), so getting the first level of automation up-and-running shouldn’t be that hard.

Beyond that, I’ll let user feedback direct the project.


And… there’s now a “Join” button on which takes you to a page where you can give me a dollar and (really, truly) join the alpha! :grin:


Joined! Very exciting!

1 Like

What happens now that I’ve joined? I haven’t heard anything

@zedmango I’ll be emailing you once I’m ready to start the alpha. I’m going on a trip in a couple of days, so it’ll need to be after the 20th. Starting out, this will be a very manual process for me, so I want to be able to give it the attention it needs.


I was also delighted to cough up a dollar to try this out!

(Now I’m fantasizing about some kind of scheme for dynamic pricing for beta apps where you actually see the whole queue of people and initially you pay the $1 to get in line but then … basically there’s a big auction and you make people bid for their spots in the beta. Oh, yeah, I have a domain name that could work for this and everything:


I joined as well! So exciting!

1 Like

First email of the alpha sent!

@zedmango, @dreev, @openmedi, did the email get past your spam filters? Also, maybe add to your contacts…


:partying_face: It did!

1 Like