We're a group of makers shipping together. We help each other stay accountable and reach our goals.
Apply for access
Marc Köhlbrugge
PRO
@marc
Yes, 100% planning to!
I actually have an unfinished pull request for a year ago for this and I think I tried once before as well. But there's some technical difficulty to mixing different record types and sorting them all by date, while still using the cache.
Recently I came up with a simpler way of doing it. Will give that a try soon, because I agree the posts have a lot of potential but are difficult to discover right now.
Questions, roasts, intros, and milestones already share the same back-end by the way. I did the work for that a while ago. They are all "posts" with a single column specifying their type. So once I make the change to the feed, all of them will be automatically part of it 👍
Longer term, maybe even todos will become a "post", making the code even simpler. They already share a lot of the same functionality like @mentions or being able to receive likes and replies etc.
Plus, I see people writing longer todos these days. Myself included. But we don't support line breaks yet. Don't see a good why we shouldn't allow that.
So "todo" could simply a special type of post.
Either way, that's something more long term. For now, adding posts to the feed seems like a good first step.
I think that a todo as a post makes sense. It's quite common for task managers to have a title for the task and a description, then you decide if you use only the title or both.
I like the idea of simplifying data models and not repeating functionality when possible. So, no reason a TODO couldn't be a post. I figure it's a bit of text, media, hashtags, at-tags, comment tree like everything else
The only difference I can see is that posts can have a topic like "Finance"
To avoid joins/for perf reasons, maybe just use a discriminator column and have a generic posts table with "type" being the discriminator (values "post" "todo" where "post" rows have the topic ID/name filled in and whatever else makes them unique; all other columns could be shared)
I don't know if you're familiar with micro.blog but it's an excellent direction for WIP to expand on the blogging area. Launching a personal blog is cool, but you know that you starting with zero traffic. Knowing that your content will be seen by an active community of like-minded people makes a big difference! If WIP had a similar setup, I would start drafting my first post on how WIP has impacted my life in the next five minutes. I truly believe that not only would this approach convert users into paying customers, but it would also significantly boost platform exposure. Not to mention SEO. If you need any support with UI/UX or growth hacking, I'm eager to help!
Imagine: marc.wip.co, szymon.wip.co, lis.wip.co, paul.wip.co... for me it's a solid idea! 😊
Sorry yeah like @ben said I don't really maintain the Windows version as it's difficult for me to test. Getting Electron builds to work is tricky by itself, let alone if you don't have a machine to test one.
It's open source though, so if you want to have a look at it yourself you can do so here: github.com/marckohlbrugge/wip…
I also welcome any PRs that help fix the issue.
I plan on revisiting the menubar app in the future after I release the new API.
Oh, that's surprising. I wonder why?
The (new) founder, John, said that the user base isn’t as active as on Slack (though I doubt it is that much higher), and he is rebuilding the project. As far as I understood, the community can make their own bots, but no official ones in Telegram.
I mean it’s his own project, all and all, so I hope someone will make a TG bot at some point.
Again, gladly, WIP has an official bot hehe!
100% using managed databases. Don't trust myself to run those myself haha. At least with the web server, I know I can just nuke it and reset it with a few commands without any data loss.
And yes, Kamal lets you configure resources limits using Docker's config. I think it's called cap ? I haven't looked into it yet, but it seems like a good idea. So maybe set each container to use a maximum of 80% CPU usage, just so it never takes down the full machine? (assuming the other containers don't use up the remaining 20% at the same time)
I have never used cap but I have used resources with limits + reservations via compose which should just be passing those through as cli options: docs.docker.com/compose/compo… - I would ChatGPT this to see what args are 🤣
80% of 90% should be good enough to keep control of the box. I'm lazy and I have two or three dozen containers running without issues on a 4 GB droplet. Worse case, you can narrow it down to the service.
Longer term, maybe even todos will become a "post", making the code even simpler. They already share a lot of the same functionality like @mentions or being able to receive likes and replies etc.
Plus, I see people writing longer todos these days. Myself included. But we don't support line breaks yet. Don't see a good why we shouldn't allow that.
So "todo" could simply a special type of post.
Either way, that's something more long term. For now, adding posts to the feed seems like a good first step.
I think that a todo as a post makes sense. It's quite common for task managers to have a title for the task and a description, then you decide if you use only the title or both.
I like the idea of simplifying data models and not repeating functionality when possible. So, no reason a TODO couldn't be a post. I figure it's a bit of text, media, hashtags, at-tags, comment tree like everything else
The only difference I can see is that posts can have a topic like "Finance"
To avoid joins/for perf reasons, maybe just use a discriminator column and have a generic posts table with "type" being the discriminator (values "post" "todo" where "post" rows have the topic ID/name filled in and whatever else makes them unique; all other columns could be shared)