Hey folks, I have been hanging around Future-of-Code-like communities for a few years, trying to figure out what I want my focus to be. I’ve finally figured it out, and I made a demo video to share with y’all about what I’m working on. It’s a web and mobile app for tracking your personal information, including allowing end users to configure buttons and actions to customize their workflow. It’s not groundbreaking research, but it does enable end users to create interactive software anywhere they are. I’ve been able to replace at least four apps I previously used with “boards” I’ve configured in this app. I plan to open-source it and set up a free open-registration server soon. Here’s the demo if anyone would like to take a look!

Nice. And the red Smalltalk-80 book is prominently in the background 🙂.

Had to leave those Easter eggs in for those in the know 😃

I really like the problem you're tackling, I've been aiming in a similar direction, though in a radically different and differently radical way. I have a couple of questions that'll likely answer themselves once your app is published: • What sort of stack are you using? I'm guessing some sort of Javascript. What sort of upgrade burden do you anticipate for someone self-hosting? • What do you use for data storage? That's often a significant maintenance burden, in my experience. • Will the mobile apps work with arbitrary servers, or will anyone self-hosting need to put their own copies of the app through App Store review?

love the malleability 🙂

@Kartik Agaram Great questions. The architecture of the app is thick clients talking to a RESTful HTTP backend with JSON. I’m using this both for ease of initial development and ease of future development: if the frontend or backend become restrictive, there is the option for me or others to write new or additional frontends/backends in different technologies. The backend is currently a “normal” Ruby on Rails API backed by Postgres. To support self-hosting, I will want to set it up to be easy to spin up new instances on Docker or Heroku (which is where I currently host it). Hosting the app isn’t for non-programmers/non-IT people, due to the limitations of the underlying technologies. But this question has gotten me thinking of the tradeoffs of other backend technologies: Golang would allow shipping a single binary, but does not allow folks to easily verify the code included in that binary. The frontend is built on React Native, using the

react-native-web

package to also target web with the same frontend codebase. I want to set up the mobile clients to be configurable to access any backend, so that you don’t have to publish your own mobile app, but you have the option to if you make feature changes to it. There’s some developer burden keeping it up-to-date (it’s a heavy stack). For someone hosting, the frontend web updates would hopefully be as simple as keeping Node up-to-date and running an

npm install

. TBD how much interest the project gets; if/when some folks start self-hosting I know I’ll need to put more attention to ensuring they have a good experience. Any followup thoughts or questions you have based on that would be welcome! Thanks.

This looks great. It’s similar in spirit and form to something I’ve been working on though my project isn’t focused on todos/tasks. Is there an easy way to export and import JS? Is there a site we can try it on?

Site is not live yet but hopefully within a month or two. My focus now is to fix some bugs and incompleteness in the current feature set, so hopefully not too long. Could you explain more about what you mean by "export and import JS"? I don't quite follow.

I meant exporting the user todo/tasks to JSON.

Gotcha! The backend API operates via JSON so you can access the data that way. And I plan to focus on making it easy to get data in and out

Cool. FWIW, I feel you’re on the right path with this.

Thank you! I'd definitely be interested in hearing about what you're working on if you feel like sharing at some point (or have posted it before)

Thanks Josh. I hope to share something later this year.

I finally got around to watch that demo. Very nice! This would solve a lot of the open issues with my various workflows, simply by providing a configurable bridge between mobile devices (where I enter and retrieve information) and desktops/servers (where I process information). Looking forward to playing with it!

great! you’ll definitely hear about it here when it’s open; Future of Code is one of a couple of communities i’ll soft-launch it to before promoting it elsehwere

One more question: do your mobile apps store data locally, or are they just an interface to the server? For me, it is important to be able to work offline, in particular when travelling in areas with bad cell coverage.

@Konrad Hinsen The current architecture is that the data is stored only on the server. I would love to have offline support, and now that you bring it up I’ll put it on the roadmap to consider it. I’ve tried various offline approaches in the past, and there are definitely tradeoffs. One benefit of the server-based approach is that it is easy for folks to implement alternate frontends or backends in different technologies—it’s just RESTful HTTP with JSON. A more offline-and-sync approach might make that harder, and/or introduce a dependency on a specific vendor or library.

A persistent and clearly signposted caching layer can be both simple and optional, and would set you apart from most apps. I've lost the email I was drafting on the Fastmail app just because I lost signal for a while and it decided randomly to reload itself. I wish their data model included a notion of unsynced drafts that persist until explicitly deleted. Doesn't even have to try to transparently sync; that's where all the complexity of offline comes from.

I do understand the difficulties that come with syncing, but I don't really need that complexity for personal use. I don't use several devices in parallel just for the fun of creating race conditions. @Kartik Agaram suggestion of caching sounds like just the right level. The point is not being penalized by temporary signal loss.

I think the key is finding an approach that helps with your use case without introducing issues for other use cases. For example, I do use several devices in parallel (laptop and phone), so would need to ensure an approach that doesn’t make data loss likely in that case

Yeah, that was on my mind in my suggestion. Imagine a data model where you operate in regular connected state most of the time so the server holds the ground truth, but if it tries to send data to the server and fails it immediately throws it into a local store. You can delete things from the local store, and you can try repopulating from the local store for submission, but importantly these are all manual operations. Even submitting successfully doesn't automatically delete. Key is to be able to switch back and forth between the state on the server and your draft. That way you can gain confidence in the server side state before deleting.

You can delete things from the local store, and you can try repopulating from the local store for submission, but importantly these are all manual operations

Right, that’s exactly the kind of complexity I was thinking of above. We may get to that point, but that is not the focus of this project at this time.

By complexity here you mean interface complexity? Because the implementation seems simple.

This isn’t a topic I’m looking to dig into right now.

What's nice about a caching approach is that it's per-device. Disable it for a device and it's gone. But I'll stop commenting on this topic, because I am absolutely not an expert on data synchronization issues! Actually, my personal preference is apps using local file storage, with SyncThing handling synchronization. No server required at all. But mobile apps using local file storage are rather exceptional.