salsakran

It's not hat "homebrew install gcc? pip install foo" is hard for us, it's that we didn't want to support 1000s of people trying to set it up on their machines.

Every possible source of error we eliminated meant we'd need to spend less time on twitter debugging installation problems. It's useful to remember that our target install base isn't python developers who might want to hack away on a python project, but rather analysts, end users, DBAs and all kinds of people who've never heard of homebrew and who might not even be comfortable with using a terminal in Mac OS X let alone compiling things.

Off the cuff, I'd estimate that between the team members at the time, we'd shipped perhaps 100k+ LOC of java into production systems at past jobs.

It didn't seem interesting to rehash why we didn't want Java's verbosity in a small team.

It sounds innocuous, but we were planning on supporting a lot more databases, and when you start needing to build drivers for MySQL, Postgres, SQL Server, Oracle, Redshift, etc etc anything that makes this step more brittle starts to add up.

There are a lot of things that are mostly painless if you're deploying and supporting a single instance that become nightmares at the scale hundreds or thousands of installations you don't control.

Hey -

Really appreciate you taking the time to try it out!

If you're still around, are you using the default schema ('public') for your tables? We've found a few bugs around non-default schema we're working on.

If you don't mind, cast a vote in https://github.com/metabase/metabase/issues/1294

We're going to be building out connectors by community demand. =)

Could you take a screenshot of what it looks like and leave a post on with it on http://discourse.metabase.com/

I'll try to reproduce it. What database are you using?

Really strange. Out of curiosity what version of OS X are you on? If you don't mind filing an issue at https://github.com/metabase/metabase/issues/new or http://discourse.metabase.com/ we would love to get to the bottom of what's going on.

it looks like the field isn't marked as an FK in our semantic model. Could you go the admin, and click on "Metadata" and check to see what "special type" that field is marked at? If it's not "Foreign Key" you can set it to that and see if you can filter by linked fields.

What type database are you pointing this to? Do you have FKs/constraints set?

Dumb question, but what dialect of SQL does the JDBC interface use?

Splunk is mainly about log analysis, though they have a new BI product. It's primarily about making sense of your logs. We primarily work with a database you already have (and eventually the data warehouse you'll spin up).

Palantir is a wide set of tools and really about much more powerful analysis than we're targeting.

Our whole bag is letting non-technical people in your company get answers to their common questions by themselves.

Thanks! We ship a sample database to play with in all the distributions.

Oh, that's an old version tag. Keep an eye out for a new version in a few hours, the app should offer you a chance to update.

Regarding FK's we let you filter or group by any attribute on either the table you're working with or any attribute on an FK in that table. Are you using the sample DB or your own?

Let us know what you think!

Yes, writing the app in Clojure has been very interesting. Some things were downright magical, while other aspects felt very rough coming from other languages and frameworks. Ironically the prototype was in django =)

There will be a blog post about it coming up!

Are you on virtualbox? Sounds like a port binding issue. If you open an issue at github.com/metabase/metabase or http://discourse.metabase.com/ we'll try to debug exactly what's happening.

So in practical terms, you'll eventually want to bring everything back in and create a analytics DB or data warehouse. Depending on what your schemas look like in each microservice, you might just be able to add each DB into Metabase and hit them up.

We don't do cross DB joins in the query builder. You can still use something like PG foreign data wrappers to create an uber-db with all the tables from each microservice.

Regardless of whether you use MB or another tool, there will be some legwork. Part of the tradeoffs involved in the great monolith vs microservices decision.

easter eggs to come =)

We occasionally see failures to deploy when things don't spin up fast enough. Does it blow up every time you click on the deploy button?

Thanks for the kind words!

Redshift, Druid and Presto are in planning, but in general, we're going to build drivers in the order of community demand. If you have a specific db, open an issue or chime in on one of the open driver issues letting us know it's important.

Yes, we're mainly focused on making it easy for non-technical people to pull data out. We have had embedded applications that hit a REST api to expose actions on the data that was embedded though.

We run it on linux in production and it's the primary platform we recommend for company wide deployments.

Power BI is pretty awesome, but pretty complicated when we tried it out. With enough attention it can do very cool things. Our primary audience is folks who don't need the level of customization, and have a lot of non-technical coworkers that want to ask their own questions.

Yup, TR has a bioinformatics DB they sell which I think is based on metabase.org. We're in a sufficiently different space that we're hoping it's not a conflict.

We don't explicitly support snowflake schemas but folks are definitely using MB with them them. We have a limited set of joins accessible through the query builder and snowflake schemas work really well.

re:dash is very cool, and we actually used an early version way back.

The primary difference is audience. Most of the impetus to build it came from the difficulties we had getting non-analysts to do their own data pulls and ad hoc queries. While some number of people were able to edit SQL others had written for them, it rapidly became unsustainable.

As a consequence of the audience, we have lots of ancillary features (like the ability to see detail records and walk across foreign key links, the data reference, etc) that fell out as we learned how people used the tool.

Thanks for the kind words!

Would love to hear what you think of the codebase.

Think they missed editing out the final "Text Magic now to get started:" at the bottom of the page.

https://cloud.google.com/prediction has been out for years.

They're already starting to lock down all the data that was originally Creative Commons. They've stopped allowing you to download snapshots as spreadsheets, and generally hobbled the API.

The easiest way to get them to use a CRM is to only pay commissions on deals marked as closed in the CRM. Run all meetings off the CRM, and if someone's lead status isn't updated make a point of asking why. Requires a bit of discipline, but if you make it the rules of "the game", sales people will play along.

Acquihires are bought not sold.

Your acquirer will have some sort of price formula they use for these things and will have a price in mind usually. It's also hard to pin down exact numbers as they vary wildly by who is doing the acquiring.

You should dig a little and see if they've acquired anyone of a similar size and peg to that.