2,928 karma · joined May 20, 2016
site: https://vinayak.io
github: https://github.com/vinayak-mehta
We found that installing MCPs was not the most straightforward experience, especially for someone who doesn't have Python and Node set up on their computer. So we built a desktop app that handles the complexity of installing the right tools in the environment to make MCP installation super easy.
The app itself is open-source and it runs only on your machine. Your data only goes to Anthropic when you ask Claude to do something with it. You can find the GitHub repo here: https://github.com/fleuristes/fleur. We also have an app registry where you can submit more MCPs: https://github.com/fleuristes/app-registry. We're making sure that every MCP we add works really well because we found a ton of them which had errors and didn't work. We're also trying to figure out a way to make the Google OAuth flow very smooth before we add the Gmail and Calendar MCPs.
Let us know what you think!
This could be done with SQL comments, but having it in a structured format makes it more reliable to parse and validate programmatically. I do see why YAML's quirks could become a problem in a tool that's meant to help you make sure your database is in order, we didn't run into issues like country codes or numbers being interpreted as sexagesimal (yet).
Perhaps a middle ground would be to keep the actual migrations in .sql files for readability, while using a separate metadata file (in JSON or TOML) for the orchestration details. What do you think?
Would love to chat more here or there if you're keen!
For materialized columns, it's a "easy" (not really because you still need to monitor the backfill) because we can run something like `ALTER TABLE events UPDATE materialized_column = materialized_column WHERE 1`. Depending on the materialization that can bring the load up on clickhouse because it still creates a lot of background mutations that we need to monitor, because they can fail due to all sorts of reasons (memory limit or disk space errors), in which case we need to jump in and fix things by hand.
For materialized tables, it's a bit harder because we need to write custom scripts to load data in day-wise (or month, depending on the data size) chunks like you mentioned, because an `INSERT INTO table SELECT * FROM another_table` will for sure run into memory limit errors depending on the data size.
I would love to think more about this to see if it's something that would make sense to handle within Houseplant.
Nice analysis from Debarghya Das on Twitter: https://x.com/deedydas/status/1866335915125465541
As pointed out in this thread, right now it only works with text-based PDFs. But there's a PR[1] which will add OCR support (using EasyOCR) for image-based PDFs in some time.
Remote: Yes (onsite also works)
Willing to relocate: Yes
Technologies: Python, Flask, Celery, Airflow, Docker, Kubernetes, Git, some experience with C, Rust, JavaScript, HTML, CSS, Spark
Résumé/CV: https://vinayak.io/files/vinayakmehta_resume.pdf
Email: vmehta94 at gmail dot com
> A common use of COM was scripting with Visual Basic in the 1990s ...
This sounds nifty!
I'll take a look!
As for practical work-related side benefits, I've neither had my open-source work weigh in on the hiring process (as everyone still asks algorithms/data structures questions) nor earned much money through it. But I love building open-source tools that would be useful for people, including me (I used `present` for a talk some days ago), so you could say it's just a hobby at this point.