3 ms·

A couple weeks ago I helped my nephew with a project he was working on using gspread. I haven't programmed in Python in years but was able to make it all go in

A couple weeks ago I helped my nephew with a project he was working on using gspread. I haven't programmed in Python in years but was able to make it all go in an hour or so of poking at the gspread docs. It's pretty neat. I've often thought spreadsheets should be more commonly used as the UI for software. Lots of business folks have a good grasp of spreadsheets, but not of programmer-y or database concepts. I dunno how I'd integrate spreadsheets into anything I'm working on, but if I were doing enterprisey stuff, I'd be trying to make it fit.

stephen-mw 9y ago
That’s funny you say that. One of my pet projects was using google sheets to control SSH access with non-techies. It worked surprisingly well. https://github.com/stephen-mw/gdoc_ssh_manager/blob/test/README.md https://github.com/stephen-mw/gdoc_ssh_manager/blob/test/REA...
rabidrat 9y ago
> I've often thought spreadsheets should be more commonly used as the UI for software. I've had this same thought! I've been working on [VisiData] (Python+spreadsheet+terminal) for the past year, and I think the interface is more than sufficient for all kinds of applications. Besides the main VisiData app, I've made a git interface (vgit), a game (vdgalcon, a remake of Galactic Conquest), a chat client, and I have designs for a unix shell and a python debugger, among other things. If you want to try to fit something you're working on into a terminal spreadsheet interface, we could put something together really quickly. With vdtui (the core interface layer), you just have to collect your row objects, specify the columns, write the commands, et voila! We should be able to get a workable prototype going in an hour or two at most.
tinix 9y ago
Funny, I do a lot of enterprise stuff, and our biggest pain is getting organizations/individuals/clients to not use spreadsheets. Like, we'll have clients wanting to export/import data via sheets, but it'll be complex multidimensional data that cannot be represented in a 2 dimensional data format like a spreadsheet. As soon as you start needing to do lookups, stuff is gonna get hairy. Or organizations that don't understand that data needs to be aligned properly, etc... Sure, you're a human, you can look at this, and understand it, but when you change where you put your labels constantly, it's a nightmare. Oh, just let some customer send their data over, and we can copy and paste it in.... HAHA right... good luck with that if you don't teach every single user who touches that data how to sanitize it. That's too much for a bunch of humans to deal with, generally, for anything remotely complex. It's too easy to make too many mistakes, whether it be typos, copy/pasting the wrong thing, referring to something by a slang or localized terms, that fails a lookup, so they create a new record, etc... Sure, I'm sure some nutter has implemented a fuzzy search algorithm in Excel, but I doubt it's truly production quality... Most people would just use Access or a real database at that point. So my solution is to build software to solve these problems. Spreadsheets are great, especially collaborative ones, for certain tasks. I've seen plenty of large companies running their whole business off a gigantic shared spreadsheet (on google drive) complete with colored spreadsheet dashboards up on TVs, and everything. (and yes, we built new pipeline software for them, using those formula, it was invaluable) Spreadsheets just don't scale though (depending how you use them), and for anything remotely complex, humans will make mistakes. At some point you might as well be doing some kind of light-weight bespoke software development, as you'll gain more flexibility and ease of use in the long run, and you'll probably save time/money/hassle with proper data warehousing, etc... I'm not saying I never use sheets, it's ideal, but you have to build in lots of validation logic, etc... I use gspread myself, personally, when doing very specific data tasks for clients, but I hate giving clients direct access to a sheet that interfaces with code, or I do give them access to a sheet, but not access to run the code against it. Too much room for pain and confusion. They will break it, and most customers are not the trial-and-error type, and not all tasks are even safe to attempt with brute force.

stephen-mw 9y ago

That’s funny you say that. One of my pet projects was using google sheets to control SSH access with non-techies. It worked surprisingly well. https://github.com/stephen-mw/gdoc_ssh_manager/blob/test/README.md https://github.com/stephen-mw/gdoc_ssh_manager/blob/test/REA...

rabidrat 9y ago

> I've often thought spreadsheets should be more commonly used as the UI for software. I've had this same thought! I've been working on [VisiData] (Python+spreadsheet+terminal) for the past year, and I think the interface is more than sufficient for all kinds of applications. Besides the main VisiData app, I've made a git interface (vgit), a game (vdgalcon, a remake of Galactic Conquest), a chat client, and I have designs for a unix shell and a python debugger, among other things. If you want to try to fit something you're working on into a terminal spreadsheet interface, we could put something together really quickly. With vdtui (the core interface layer), you just have to collect your row objects, specify the columns, write the commands, et voila! We should be able to get a workable prototype going in an hour or two at most.

tinix 9y ago

Funny, I do a lot of enterprise stuff, and our biggest pain is getting organizations/individuals/clients to not use spreadsheets. Like, we'll have clients wanting to export/import data via sheets, but it'll be complex multidimensional data that cannot be represented in a 2 dimensional data format like a spreadsheet. As soon as you start needing to do lookups, stuff is gonna get hairy. Or organizations that don't understand that data needs to be aligned properly, etc... Sure, you're a human, you can look at this, and understand it, but when you change where you put your labels constantly, it's a nightmare. Oh, just let some customer send their data over, and we can copy and paste it in.... HAHA right... good luck with that if you don't teach every single user who touches that data how to sanitize it. That's too much for a bunch of humans to deal with, generally, for anything remotely complex. It's too easy to make too many mistakes, whether it be typos, copy/pasting the wrong thing, referring to something by a slang or localized terms, that fails a lookup, so they create a new record, etc... Sure, I'm sure some nutter has implemented a fuzzy search algorithm in Excel, but I doubt it's truly production quality... Most people would just use Access or a real database at that point. So my solution is to build software to solve these problems. Spreadsheets are great, especially collaborative ones, for certain tasks. I've seen plenty of large companies running their whole business off a gigantic shared spreadsheet (on google drive) complete with colored spreadsheet dashboards up on TVs, and everything. (and yes, we built new pipeline software for them, using those formula, it was invaluable) Spreadsheets just don't scale though (depending how you use them), and for anything remotely complex, humans will make mistakes. At some point you might as well be doing some kind of light-weight bespoke software development, as you'll gain more flexibility and ease of use in the long run, and you'll probably save time/money/hassle with proper data warehousing, etc... I'm not saying I never use sheets, it's ideal, but you have to build in lots of validation logic, etc... I use gspread myself, personally, when doing very specific data tasks for clients, but I hate giving clients direct access to a sheet that interfaces with code, or I do give them access to a sheet, but not access to run the code against it. Too much room for pain and confusion. They will break it, and most customers are not the trial-and-error type, and not all tasks are even safe to attempt with brute force.