Congrats on the launch, really great stuff. As a software developer who has been studying (very slowly) a law degree, I can really see how products like that improve existing processes can really fill a need. I've also seen some former colleagues gain a lot of traction in a very similar legal process improvement space.
For a completely unrelated use case, I've started using it as my docx viewer on Linux, and so far it's been great (and solves one of my pain points moving from MacOS).
Love this, and I'm in the same boat. Is your configuration of kanata public at all?
I know it's mostly muscle memory, but macOS shortcuts just seem sane and consistent and that has been one of the biggest frustrations when trying to switch. I found toshy[0] which does something similar - did you try that? The goal is purely macOS key remappings in Linux, so a much smaller scope than kanata.
I didn't try toshy, I had a bad experience when I tried kinto.sh a couple of years back, and I had a pretty clear idea of how I could get what I wanted out of a fully featured keyboard remapping tool under Linux. I initially started with Kmonad, but once I found Kanata, and realized that it had a TCP interface for programmatically changing layers, I quickly switched.
I have a Kinesis 360 keyboard, and my config[0] probably won't work for other keyboards, but it can give you a starting point for your own config.
This x100. I have regularly tried to set up a Linux environment, thinking that there really isn't that much of a barrier to being productive on Linux, but with the lack of polished commercial apps and the hardware quirks I always seem to spend more time finding workarounds than actually working.
I have found more recently that I can get something reasonable (for me) set up, although I'm confident I'll always need a Mac nearby to do some things on.
I didn't really run into this as an issue at all. Then again, "commercial apps" sounds largely like a relic of the 90's. It has Slack and Teams and Spotify and can run most games thanks to Valve.
Biggest thing I ran into was that MS Word is too buggy to 100% reliably read anything created in alternate programs. I know it's Word and not LibreOffice or anything because it happens between different versions of Word too.
I'm trying to manage working on both Linux and MacOS, and this has been the number one frustration. Fortunately, toshy.app (as well as into) exists and does a pretty great job at mapping shortcuts to match MacOS.
Fantastic work, and really appreciate the write up. It's quite timely for me - I'm from a tech background and have just started studying Australian law, and was thinking about doing exactly this - so you are years ahead of me :).
> For someone interested in using the data (and help out with bugs/issues), where would you suggest starting?
I think the best place to start is by downloading the Corpus (visit https://huggingface.co/datasets/umarbutler/open-australian-l... , and then click "Files and versions" and then "corpus.jsonl"). You can then use my Python library orjsonl to parse the dataset (you'd run, `corpus = orjsonl.load('corpus.jsonl')`). At that point, there's any number of applications you could use the dataset for. You could pretrain a model like BERT, ELECTRA, etc... and share it on HuggingFace. You could connect the dataset to GPT and do RAG over it. Etc...
Do you have happen to have any documentation about your benchmarking? I'm also considering these options at the moment (currently using pg+timescaledb) and interested in what you found.
I just created large tables, and tried to join, group by, sort them in pg, clickhouse, duckdb, looked what failed or being slow, and tried to resolve it.
I am happy to answer specific questions, but I didn't use timescaledb.
Another option is https://kinto.sh . It worked perfectly for me out of the box on Pop OS, and with a few tweaks to shortcuts I’m pretty happy with the experience to the point where I can fairly seamlessly switch between computers and not be driven crazy by the shortcuts.
I don't think Jacascript/HTML is the hurdle - for me it's all of the tooling around the ecosystem that makes me want to avoid it. That said, these types of tools have been a good entry point into front-end work, and I'm now at a point where building directly in JS makes more sense.
One thing that is a huge win for the work I am doing - using Dash, I'm able to prototype an informal API and build the visualisations in a single step, which is great when it's unclear what is going to be useful. Long-term it definitely makes maintenance harder, and I think that's where there is a gap in the ecosystem - ideally I want to eject the front-end and convert the API to something more formal to hand off to a real front-end developer.
Thanks for this. I'm interested in how you compare yourselves to dash in particular - having a quick look at the network calls, the way you interact with the back-end looks fairly similar. I've written some relatively complex apps in Dash and have been hitting some limitations there, so I'm keen to see how Pynecone might help get past some of these.
For a completely unrelated use case, I've started using it as my docx viewer on Linux, and so far it's been great (and solves one of my pain points moving from MacOS).