@neauoire what's the differentiating factor between your projects under research/tools and visual/utilities?
@neauoire Haha, no problem. All your recent Plan9 posting and stuff like this has led me down some deep rabbit holes, but I'm loving it :) I'm excited to do more with this tomorrow. Learning so much!
@neauoire So I'm supposed to be deciding on what classes to register for by tomorrow. Instead, I am playing with this. Then, as I was about to pause, I find that you've made another commit. Please stop terrorizing me with this fun ;(
@nathand Have you tried TinyTinyRSS? I'm curious about alternatives like miniflux
@chaitanya The downloaded canvas seems to have some problem on my mac
@Digital_Edge Definitely learn more about email! Once you see the magic of simple, plain text email you'll never go back :) When we're talking about html email with this sort of thing though, it just doesn't make much sense. Patches to projects are based on source code which is plain text. Converting that to HTML and back again is a minefield of potential problems. Some interesting sites:
@consoleaccess It's iMmErSiVe
@celia Tried ten times with cache disabled, averaged out to 2.12 seconds ¯\_(ツ)_/¯
@csrsuoeb New printer? What did you get?
@celia Oops, but this is on macOS, not a linux distribution
@celia Weird. Loading splitwise for me in Firefox (79) on my laptop takes 1.49 seconds
@esparta At first I was scared about the redesign, but it seems they've kept the most important things. A good admin interface, openness and transparency about pros/cons, etc.
I was already on the mini plan, so the pricing change won't impact me for 9 months or so. Do you think you'll go with the mini plan or micro plan?
I guess, I'm just trying to figure out how I could have multiple of these bot handling programs communicate with one backend for it.
Ideally, this would all be using a Go embedded database instead of some external db like MongoDB.
3. The Clients (e.g. IRC bot, Discord bot, Telegram bot): facilitates the communication between the Engine and end users.
The main problem: I can easily create a program that does all this for just one of those end points (e.g. one for Discord). I can create multiple versions for each of them. But then, to run them, each would have to query the original API by themselves. I'd rather have one central Engine be able to communicate with multiple Client bots.
1. API: a Golang library for the specific API I am tracking. I've actually done this already.
2. Engine: uses my API library to get data, store it in a database. Also accept queries from the Clients below to return data (e.g. is ___ online right now?) then send back what the Client should send to its service (e.g. Discord or IRC). Also, it needs to keep track of status changes (e.g. ___ has just gone offline, tell the IRC Client to send a message saying that).
3. The Clients: ...
If anyone has any advice for me, I would greatly appreciate it. I'm trying to write a program in Go, with a goal to keep it modular.
It's basic goal is to do two things:
1. Gather data from a public API and cache it in a database, occasionally refreshing this data.
2. Communicate with certain chat services as a bot, accepting queries for data and, for some of the info, sending notifications via those bots when there is a status change.
My idea was to split it into three portions.
@eletrotupi Updated & compiled castor yesterday. Yep. It's the one sure fire way of making my computers fans run at full blast
@celia Plus, of course, you get unlimited custom domains with them. And their send limits are pretty reasonable for any normal use.
@celia I do love Migadu :). Their support is awesome. You are always talking to one of the actual developers or system admins. And, I love how open they are about the benefits and drawbacks of their services.
An enthusiast of sorts.
Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.