3 ms·

Have you heard of knitr (https://yihui.org/knitr/ https://yihui.org/knitr/)? It's the gold standard as far as I'm concerned for dynamic report generation that n

Have you heard of knitr (https://yihui.org/knitr/ https://yihui.org/knitr/)? It's the gold standard as far as I'm concerned for dynamic report generation that needs to run code. Since it supports running arbitrary shell commands, it can already be used to query remote databases as long as you have a CLI to query them with. Combined with RMarkdown (https://rmarkdown.rstudio.com/ https://rmarkdown.rstudio.com/), which augments Markdown with support for LaTeX typesetting, it's the ultimate toolset for doing this kind of thing. You can read a blog post here on how to use knitr within RMarkdown: https://kbroman.org/knitr_knutshell/pages/Rmarkdown.html https://kbroman.org/knitr_knutshell/pages/Rmarkdown.html I'm not trying to be a downer, but it seems like your product is just duplicating the functionality of these existing products but does less since it only supports SQL and Markdown. I guess you autogenerate charts, but it says you're targeting a technical audience that is presumably comfortable calling functions in Python and R for graphical data visualization. This is nitpicky, and I'm sure you have some command line option to choose another port (though your "get started" doesn't show how), but mdbook also uses 3000. I'm sure they probably weren't the first to default to that, either. I hope this doesn't come across as downplaying your product. It looks nice. I just don't see what you offer here that can't already be done with existing data ecosystem tools. I was using RMarkdown with knitr to generate all of my papers when I was an ML grad student years ago. It felt back then like I was the only person at Georgia Tech who realized these tools existed, and now it still feels that way.

edusoftwerks 5y ago
The problem with these tools is they only work sometimes, and when they do, its because you spent a whole day configuring your environment.
amcaskill 5y ago
Absolutely no need to apologize, thanks for taking the time to check out our project. I have written a lot of R Markdown over the years, and I agree wholeheartedly with most of what you're saying. The R ecosystem is phenomenal. Anyone who is excited about our project, might be 10x more excited about learning R and writing a report with R markdown. A big part of why we are building Evidence is that my co-founder Sean and I felt like we lost a lot on the presentation side when we graduated from notebooks to primarily working with data warehouses, dbt & BI tools. The thing is, we gained so much from that transition to 'the modern data stack' that we would never go back. So we're setting out to fix the presentation layer in a way that would have worked for us. Undoubtably, anything that you could accomplish in Evidence is going to be do-able within the R Markdown or jupyter ecosystems, so I won't try to claim any truly unique features. It's maybe more of a vibe: what's easy in Evidence vs. what's tricky in a notebook? If you're writing an ML paper, R markdown is definitely the move. If you're trying to build a common, internally consistent understanding across hundreds (thousands) of people about how your business is doing, and what they might do about it, Evidence is going to be a better fit. Here's a comment from awhile ago discussing the comparison with Jupyter: https://news.ycombinator.com/item?id=27363349 https://news.ycombinator.com/item?id=27363349 It only supports SQL and Markdown: That constraint is part of the point. In a large organization, a fair number of people are going to contribute to your reporting apparatus, and you want to keep it in a state where you can re-factor useful abstractions up into your data warehouse. This gets a lot harder if your reporting is a swirl of R scripts and python snippets and whatever else. Some order of magnitude more people know SQL and markdown than R or Python. Every business I have been involved in has someone there who is cranking out analysis and data pulls using SQL. Very rarely would that person be comfortable working in R markdown. You can't in-line an ML model into your reports: Again, we think this constraint is basically a good thing. If you have a model that is profitable to your business, it should be governed and executed in a purpose built environment and, where feasible, you should be storing the relevant outputs for posterity in your data warehouse. We will add instructions on setting the port! :)
lytefm 5y ago
I guess you could make the same argument pointing to Jupyter Notebook or D3.js - if you already know how to use a programming language like R, Python or JS and how to visualise data with it, you're probably not the target audience as end user. This looks more like it's made for an Analyst who mainly uses SQL or Excel. But if it makes me more productive that Jupyter Notebooks for simple reports, I'll give it a try.
Aeolun 5y ago
> I'm not trying to be a downer, but it seems like your product is just duplicating the functionality of these existing products but does less since it only supports SQL and Markdown. To me, this is a feature. Evidence sounds like it’s completely batteries included. Your example sounds like I have to learn a whole new toolchain.

edusoftwerks 5y ago

The problem with these tools is they only work sometimes, and when they do, its because you spent a whole day configuring your environment.

amcaskill 5y ago

Absolutely no need to apologize, thanks for taking the time to check out our project. I have written a lot of R Markdown over the years, and I agree wholeheartedly with most of what you're saying. The R ecosystem is phenomenal. Anyone who is excited about our project, might be 10x more excited about learning R and writing a report with R markdown. A big part of why we are building Evidence is that my co-founder Sean and I felt like we lost a lot on the presentation side when we graduated from notebooks to primarily working with data warehouses, dbt & BI tools. The thing is, we gained so much from that transition to 'the modern data stack' that we would never go back. So we're setting out to fix the presentation layer in a way that would have worked for us. Undoubtably, anything that you could accomplish in Evidence is going to be do-able within the R Markdown or jupyter ecosystems, so I won't try to claim any truly unique features. It's maybe more of a vibe: what's easy in Evidence vs. what's tricky in a notebook? If you're writing an ML paper, R markdown is definitely the move. If you're trying to build a common, internally consistent understanding across hundreds (thousands) of people about how your business is doing, and what they might do about it, Evidence is going to be a better fit. Here's a comment from awhile ago discussing the comparison with Jupyter: https://news.ycombinator.com/item?id=27363349 https://news.ycombinator.com/item?id=27363349 It only supports SQL and Markdown: That constraint is part of the point. In a large organization, a fair number of people are going to contribute to your reporting apparatus, and you want to keep it in a state where you can re-factor useful abstractions up into your data warehouse. This gets a lot harder if your reporting is a swirl of R scripts and python snippets and whatever else. Some order of magnitude more people know SQL and markdown than R or Python. Every business I have been involved in has someone there who is cranking out analysis and data pulls using SQL. Very rarely would that person be comfortable working in R markdown. You can't in-line an ML model into your reports: Again, we think this constraint is basically a good thing. If you have a model that is profitable to your business, it should be governed and executed in a purpose built environment and, where feasible, you should be storing the relevant outputs for posterity in your data warehouse. We will add instructions on setting the port! :)

lytefm 5y ago

I guess you could make the same argument pointing to Jupyter Notebook or D3.js - if you already know how to use a programming language like R, Python or JS and how to visualise data with it, you're probably not the target audience as end user. This looks more like it's made for an Analyst who mainly uses SQL or Excel. But if it makes me more productive that Jupyter Notebooks for simple reports, I'll give it a try.

Aeolun 5y ago

> I'm not trying to be a downer, but it seems like your product is just duplicating the functionality of these existing products but does less since it only supports SQL and Markdown. To me, this is a feature. Evidence sounds like it’s completely batteries included. Your example sounds like I have to learn a whole new toolchain.