HackerTrans
TopNewTrendsCommentsPastAskShowJobs

cuffe

no profile record

Submissions

Microsoft CMO leaving after 32 years

blogs.microsoft.com
2 points·by cuffe·3년 전·0 comments

[untitled]

1 points·by cuffe·3년 전·0 comments

[untitled]

1 points·by cuffe·3년 전·0 comments

JLL unveils first GPT model for commercial real estate

us.jll.com
1 points·by cuffe·3년 전·0 comments

[untitled]

1 points·by cuffe·3년 전·0 comments

comments

cuffe
·2년 전·discuss
You can self-host here: https://retool.com/self-hosted. Most people deploy it as a docker container on an EC2 instance but there’s various options
cuffe
·2년 전·discuss
Retool Forms is completely free. No arbitrary limits on the number of users, forms or submissions. I'll make this clearer on the landing page.

For building Retool Apps/Workflows, our pricing is here: https://retool.com/pricing
cuffe
·2년 전·discuss
Sorry just updated!
cuffe
·2년 전·discuss
Agree, the table is the component we’ve spent the most time building: https://retool.com/components/table-new
cuffe
·2년 전·discuss
Here are the docs: https://docs.retool.com/apps/forms. Just added a link to them from the landing page. Agree we should also add a quick demo to the landing page
cuffe
·2년 전·discuss
Hi all, engineer who worked on forms @ Retool here. Excited to get HN’s feedback on a new product I’ve been working on: Retool Forms. There are a ton of form builders out there (e.g. Typeform, Google Forms, Airtable Forms, etc.) and honestly we weren’t really looking to build another one. But as a developer, I wanted my data in my database, not in another SaaS app (which probably has a shoddy API, like every example I listed above). Surprisingly, the only way to build a form on top of my database was by a) building my own backend (probably via node), and b) building my own frontend (probably via React, and then maybe via formik). There was no “one click” form-on-top-of-my-database tool available.

So we decided to build a form builder. It allows you to:

1. Send data directly to your database (Postgres in our case), your data warehouse, or wherever else you want it

2. Write JS almost anywhere on the front-end, including libraries like moment and lodash, for custom validations, conditional logic, and data parsing

3. Run any arbitrary code in form submission (or validation), via our Workflows product

4. Store it in our database (where we give you a connection string), or your own database

5. Self-host it in your own VPC

And it’s free with no arbitrary limits on the number of users, forms or submissions.

I’m hoping to ship a bunch more features like integration to any REST API, more styling options, etc. If you have any feedback please let me know!
cuffe
·3년 전·discuss
we'd love to make the migration as easy as possible and would definitely be open to building an import tool. In the meantime if you're migrating feel free to email me at jamie at retool.com and I'd be happy to help import
cuffe
·3년 전·discuss
Thanks for the feedback. We're currently working on customization with the url parser and trimming headers/etc makes a lot of sense. If you're able to share more about your use case (jamie AT retool DOT com), happy to get it tuned on your dataset
cuffe
·3년 전·discuss
Thanks! Yes agree this is very important. We do show references from Retool Vectors out of the box, so you can see what embeddings were used to generate a response. If it'd be helpful I can walk you through a few internal Q&A bot examples which display references - jamie AT retool DOT com
cuffe
·3년 전·discuss
Today we use a cosine similarity search but we're planning to integrate with more vector databases and allow you to customize the search logic soon. Is there a particular query method you're looking for?
cuffe
·3년 전·discuss
I checked in with an engineer who’s focussing on app performance. You're right that this screen should not be 6MB. One part of the bloat is due to our webpack configuration. In lighthouse, you can see that >50% of the app.js file is unused for login. Most of this is actually used for the app after login.

We’re working on getting this down significantly but, that being said, the login page isn’t our highest priority. It’s the first thing customers see, but >99% of the time, they’ll already be logged in and navigate straight to the apps page, or a specific Retool app. For these pages, we’ve:

1. re-written our core runtime to avoid excessive message passing with iframes (up to 75% faster page load for slowest apps)

2. parallelized resource fetching with JS execution

3. cached app graph information in IndexedDB

4. tweaked webpack chunking strategy to avoid very small JS/CSS chunks

5. optimized resource fetching to avoid over fetching

Hope that’s helpful context. Definitely let me know if you have thoughts/other ideas
cuffe
·3년 전·discuss
Yes working on adding llama2 and AWS bedrock support right now for open source models. But we also want to let users bring their own models - is there a specific model you're looking for?

Who knows longer-term I'd love to help users fine-tune their own models on llama2/gpt-3.5!
cuffe
·3년 전·discuss
Excited to already see some great open source projects in this space (Langchain, Llamaindex, Axilla, etc) many of which we're exploring using for this project.

Just to be clear Retool Vectors is completely free (we're even taking on the LLM costs). We put the embeddings in a free postgres DB (and soon other open source vector DB providers) and give you the connection string so you can take it anywhere
cuffe
·3년 전·discuss
We changed our pricing earlier this year to be a lot more affordable for use cases with high end user counts (https://retool.com/blog/pricing-v2/). Let me know if that works better for you?

If you’re looking for external apps, check out portals (https://retool.com/products/portals) that has custom volume discounts for many, many users
cuffe
·3년 전·discuss
That's a fair concern and something we're working on improving every day! It's fairly common when you consider Retool in the context of other development platforms. VSCode is a 200MB download and is considered small in the desktop space. Even gdocs is ~30MB.

For context, these resources are cached on your machine. So you should find that the actual data transferred significantly decreases after the first visit.
cuffe
·3년 전·discuss
Agree we're working on building this exact flow into the product now. But in the meantime I have a Workflow (our version of a webhook/cron job) that does this internally that I can send it to you if you want. Just ping me at jamie AT Retool DOT com
cuffe
·3년 전·discuss
Awesome - would love to see how we can integrate here. Will reach out
cuffe
·3년 전·discuss
Absolutely, happy to help! jamie at retool DOT com
cuffe
·3년 전·discuss
Thanks! Yes so under the hood it's all in a postgres DB with a pgvector column + some metadata. If you go to retool database, you can grab the connection string and use the embeddings with your own apps. I'd like to open this up to bring your own database and integrate with other common vector DBs (Chroma, Pinecone, Mongo vector, etc) next
cuffe
·3년 전·discuss
TBH, I was pretty surprised too. It made me pretty skeptical of off-the-shelf AI apps in general. I now think that most actually effective AI apps will need to be developed in-house, and that “bolting on” AI to existing apps (e.g. Intercom, Salesforce, etc.) won’t work. I think there are a few reasons:

1. A lot of the useful data for answering questions is in our public docs and community forum answers, which Intercom doesn’t have access to. (And we wouldn’t feel comfortable giving them access to our internal Slack anyhow.) For example, we’ve debugged complicated OAuth issues in Slack, and there is a lot of “context” there that is helpful for answering future OAuth questions (but isn’t available to Intercom).

2. Intercom doesn’t allow you to customize prompts or customize context easily. In our case, for a highly technical product, “prompt engineering” allowed us to radically improve answer quality. We could also use chain-of-thought prompting, which Intercom didn’t support. Together these two improvements probably doubled the answer success rate.

3. We needed to integrate with our data warehouse for in-product context. For example, if a customer has an error with a particular product/feature, knowing what plan they’re on, which features they’re using, which feature flags are enabled, etc. is quite helpful.