I've built a mobile airpollution sensor together with a few other parents and their kids at my 8-year old son's primary school in London. Air pollution is a big topic as the school is right next to a busy road, a lot of children are suffering from asthma and Islington has been pretty useless in collecting/publishing data. So we've started taking things in our own hands and built a handful of raspberry pi based monitors in class rooms, the playground and children take it with them on their school run. geo-tagged data is automatically uploaded to little influxdb/grafana based web service wheneve the pi has a wifi connection. Makes it an interesting project for kids to look and interpret charts and stuff as well. Currently we're measuring PM2.5/PM10, temp and humidity only, haven't had the time yet to look into NOx sensors yet...
True. But isn't it a bit too easy to just tell people to stop using Excel (which they won't do anyway) instead of giving them something to help them solve their problems _within_ the Excel/spreadsheet world?
great story. I used to train on a C152 and knew a few guys at the local aerodrome who had done ferry flights from the US to the UK. Which is something I (as a shitty weekend VFR pilot) have the uttermost respect for. But that story about getting it from Oskosh to Gaborone, wow.
Ok, here's he full story: We have a product (https://www.xltrail.com) that makes git diff and all that work with Excel workbooks. So you get a lot more out of it than dropbox/drive/sharepoint etc as you get to inspect content changes.
90% of our clients/prospects are in financial services (heavy workbooks with VBA, think applications, not spreadsheets) but today I spoke to a prospect from a different industry which made me think that there might be people outside banks, hedge funds going down the same path.
In general, yes. However, from my own experience, there is a (small and industry-specific) subset of "Excel developers", especially in investment banks, hedge funds etc that know both.
Commit your Excel workbook to a Git repository.
I know it's a binary file so you can't diff or merge out of the box, but at least you get the commit history.
Does that make more sense?
It's an interesting idea (though I'm not sure how much appetite there is out there).
We've built a version-control app on top of Git for workbook files (www.xltrail.com) so I know a thing or two about parsing the cell content of sheets.
There is no Python library that supports reading cell formula content across all workbook files (for instance, xlrd does not support formulae at all).
If you can go beyond Python, have a look at sheetjs.com (open-source JavaScript based) or Aspose (commercial .NET solution).
That aside, "client" integration of such a tool could be a major blocker from our own experience. E.g. if you could build it in such a way that it's "fire and forget" (like uploading it to SharePoint and integrate it there) it is a lot more likely to being used. Or integrate it via Git (drop me a message if you want to chat). Or add it as a feature to something like rubberduckvba.
Our server-side (commercial) product actually does handle spreadsheets as well as VBA code. If you want to see it in action, have a look at our demo repositories: https://demo.xltrail.com
It's the hosted version (free plan). But we also have customers who use the (free) self hosted version and we and them love it. Do you use GitLab yourself?
We (disclaimer: I'm the co-founder) have developed a Git-based add-on for Excel workbooks. Basically, it starts where Git left off in the Excel world. Here's a short blog post how it works out for one of our open source projects: https://www.xltrail.com/blog/xlwings-is-now-on-xltrail
The diff is actually not really straightforward - a sheet is two-dimensional and you have to work out column/row inserts/deletes (which themselves are intertwined) before you can even start looking at cell changes. So it's quite non-standard stuff.
That's a very good point - but for what we do (on-premise version control for Excel where each workbook version represents one object) we won't be getting even close to that number. But yes, agreed, it entirely depends on your use case.
After evaluating a couple of options mentioned in the other comments here, we recently replaced our in-house built s3 clone with minio for our on-prem version of our app. Very robust and stable.
https://github.com/bstiel/airpollutionpi