⚠️ Job search, please boost!
@werefox You could have a look in our fediverse-job postings (Vacancies posted to the fediverse) over at search.flockingbird.social.
Search for terms like "engineer" "remote" etc. You can even use the tags to drill down.
And make sure to re-visit this every several days, we update the index a few times a day.
If you know someone who's interested, don't hesitate to put her/him in contact with me ^^
I can give more details on the lab and the team atmosphere.
🏗️ Help needed!
We need a "job or not" recognition-thing that takes a toot, and produces a flag (or score) whether it is a job-posting, a vacancy.
To improve the fediverse job search tool https://search.flockingbird.social/, which now includes false positives. We want to reduce those.
PM us, mail to hi-at-flockingbird.social or reply 👇 if you'd like to help!
@colinsmatt11 thanks for the shout out to Preact. Will def check it out.
And yeah, a poll can have only 4 options so I chose Most Obvious, Weird and Other.
@epic @doctormo Sorry for making it appear I find meilisearch badly documented. It's exceptionally well documented. Clear, to the point, with lots of detail if wanted. Meilisearch is a showcase of how well OpenSource can be done.
No, hunter2, the bot and job search is poorly documented. It's also OpenSource though I see now, we should clarify that on the readme.
@doctormo also, the live index runs at meili.flockingbird.social. You'll need auth tokens, if you want to play with it. You can find a (read-only, limited) set in the source of the webpage ...
@colinsmatt11 sorry for the confusion I caused. Thanks for your insight, though!
The "limits" I'm talking about are development limits. There's just so much functions, callbacks and <template> one can add to a single static file before it grows unmanageable. We've hit that point where we need some abstractions, build tooling etc. Those are the 'limits' I meant.
The search backend is barely under load, let alone a bottleneck. And can easily be scaled up.
@lxzio search.flockingbird.social is a single webpage that uses a search backend.
*If* we were to use server-side rendering, that rendering would be built into that backend. Currently it returns JSON, it could just as easy return HTML.
What the current HTML page needs to do, is very simple really: POST/GET request and then parse the response (search results) JSON and build the local state from that.
Maintaining the state and building HTML is what is stretching our current setup, mostly.
@lxzio Interesting! We don't need server-side rendering, though. Does it then still offer enough benefits?
@lxzio Is it possible to summarize the reasons for preferring Next.js in a toot? Is it the tooling, the architecture, typescript or something else?
@taylan Is it possible to summarize the reasons for preferring Vue.js in a toot? Is it tooling, a paradigm, the architecture, not-x or something else?
The bot that fills the search is written in Rust. Hence the option for "Yew". It would allow keeping most logic in a single language.
We already use Bulma, for CSS, but there's nothing keeping us there.
JS is an option, but TypeScript preferred, because... well, mostly because it's not JS.
Less tooling > more tooling. Simple > Complex. Because... well, less stuff to set-up, break, maintain and grok.
We've introduced a feature to our Job Search, that lets you refine jobs by tags.
Check it out at https://search.flockingbird.social
Hi! We are building a professional social network.
Where you manage your business network. Decentralised, and privacy friendly.
Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.