Lukas1994

42 ms·

31.
Down Rounds 101(causal.app)
3 points by Lukas1994 4y ago|0 comments
32.
The Minimum Viable Data Room(causal.app)
2 points by Lukas1994 4y ago|0 comments
33.
Improving React Interaction Times by 4x(causal.app)
2 points by Lukas1994 4y ago|0 comments
34.
Improving React Interaction Times by 4x(causal.app)
2 points by Lukas1994 4y ago|0 comments
35.
by Lukas1994 4y ago
Good stuff! What's the size difference between the composite index vs the two separate indices?
36.
by Lukas1994 4y ago
It's more of a short term solution. We're working closely with the AG Grid team to get these changes merged :)
37.
by Lukas1994 4y ago
We're measuring Google's new INP metric + we log long event handlers and long task. It's really noisy though and hard to see regressions in the aggregate metrics. We'll probably share another post about this stuff soon.
38.
by Lukas1994 4y ago
Also, shout out to 3perf.com - Ivan has been extremely helpful with getting this over the line :)
39.
by Lukas1994 4y ago
If possible definitely use Vercel :)
40.
We improved React loading times with Next.js(causal.app)
68 points by Lukas1994 4y ago|50 comments
41.
by Lukas1994 4y ago
https://causal.app/blog/scaling
42.
by Lukas1994 4y ago
This is the talk version of the blog post discussed here: https://news.ycombinator.com/item?id=32000400
43.
Causal's 1000x Spreadsheet; Performance beyond profiling(youtube.com)
7 points by Lukas1994 4y ago|2 comments
44.
by Lukas1994 4y ago
I can highly recommend checking out http://aosabook.org/en/index.html
45.
by Lukas1994 4y ago
Definitely agree — that’s why we have an Excel export. Importing is much harder so we haven’t worked much on that.
46.
by Lukas1994 4y ago
Sounds sick! Would love to play it once it's ready :D
47.
by Lukas1994 4y ago
We store the model representation (formulas, data) in Postgres. We just keep it in memory for computing updates faster.
48.
by Lukas1994 4y ago
We'll probably offer an on-premise solution soon but most companies are quite open to using SaaS these days (banks and financial institutions might be an exception).
49.
by Lukas1994 4y ago
E-commerce companies have 1000s of products, modelled over 100s of weeks, broken down by 10s of locations, ... SaaS companies running cohort models over multiple products, geographies, ... You pretty quickly end up with very large numbers.
50.
by Lukas1994 4y ago
Nice! Any open source code I can check out?
51.
by Lukas1994 4y ago
This post is pretty good: https://lord.io/spreadsheets/
52.
by Lukas1994 4y ago
Nots sure what you mean but you can just signup here and use it for free: https://my.causal.app/register
53.
by Lukas1994 4y ago
Correct
54.
by Lukas1994 4y ago
That's exactly what we're doing :) The issue is that most of the time people look at aggregates and to compute those you have to compute all the leaf cells.
55.
by Lukas1994 4y ago
Right now we keep our paid customer models' in memory. Models in free accounts are just evaluated every time (these models are usually much smaller). For now we want to avoid the complexity of distributed systems and just run this on v
56.
by Lukas1994 4y ago
We're mainly working with high growth startups but people seem to be quite open to try out new tools. There will always be spreadsheets but once your company reaches a certain size they move their financial budgeting to Anaplan/Ad
57.
by Lukas1994 4y ago
If you're interested in multi-dimensional calculation engines I can also highly recommend this documentary: https://tm1.film/ Companies like Amazon are still using TM1 for their forecasting. We're trying to build
58.
Scaling our spreadsheet engine from thousands to billions of cells(causal.app)
323 points by Lukas1994 4y ago|109 comments
59.
by Lukas1994 4y ago
Sorry but I can't update it.
60.
by Lukas1994 4y ago
All these Gitlab pages are really impressive. I found https://docs.gitlab.com/ee/development/fe_guide/graphql.html pretty useful!

More ›