91–100 of 114 posts
Borland Delphi was the modern MS Access clone. Ever have seen how fast you can build an DB app with that? I'm sure the newest version of Delphi is still as good today as the 2001/2003 version at that time ;) On Mac it is Filemaker or not?
My job was to get them y2k compliant and then start modernizing them.
Here is how the modernizing went. I was told to upgrade them from Access 2.0 to Access 2000.
Everyday users sucked down data from Oracle to run queries and processes that I developed. Users had access to everything, so a user could modify one of my queries. When it broke, I had to remember what the original query was. I did this by always housing a copy of the Access database on my local machine.
Every Tuesday Payroll was run at 5pm. Guess what? Every Tuesday I was there until 11pm as something always went wrong in the process. There were these misc pieces of compiled code other developers had written that nobody know what it did or had source for. Example: one developer wrote a piece of code in QBasic, compiled it and made it part of the process to strip out white space from data that was read in via a text file. He lost the source. When there were problems with this step he denied it was his code. Every database used this piece of code and everything broke.
I digress. I loved Access for what I could do with it. It served a purpose. It wasn't the best but it is what I had to work with to put food on the table. Now-a-days, using tools like MySQL Workbench and TOAD give me some of the same sense of creating views and queries to re-use but obviously these are not replacements for everything Access allowed you to do.
I worked for a furniture company that used Access for everything and I mean everything. HR, Payroll, inventory, ordering, dispatching, security, etc. One amusing use was having to make an entry that you took a soda from the break room. Totally on the honor system. You filled out an Access Form that payroll then billed you for (provided they remembered to actually do it). My job was to get them y2k compliant and then…
Most of the common problems that people try to solve with their own custom solutions could be better solved by some off the shelf SASS solution.
HR, Payroll, inventory, ordering, dispatching, security,
All of those problems could be better solved with a cheap off the shelf "small business solution" that would probably cost less and be more maintainable in the long run
I've been developing professionally for over 20 years and if someone offered to pay me to write a custom solution for any of it, I would direct them toward off the shelf solutions. There is no way that I could develop something as well as a company that specializes in those areas.
One of the things several colleagues have said to me over the years is that Access tended to be a dangerous tool in a large organisation: like Excel but on crack. You end up with a large number of autonomous, undocumented systems built on an ad-hoc basis by personnel who were often not even in a technical role. Personally I think that sounds like a great way to leverage the domain expertise of lots of different emplo…
You also end up with a mess of VBScript code that isn't versioned. When something breaks and someone calls IT, it really helps if IT knows the system exists. In a large organization, supporting disjointed business processes (or worse, fragile amateurish integrations) costs more than the software. At scale, consistency matters more than performance variance in some areas. Access is also a nightmare from a security sta…
This is one reason why (I guess) largish companies even have or create apps to manage other apps - like an app to manage (as in know about, not really manage as in monitor) all the other apps in the company. Like a list of apps app. Initially I wondered whether it was overkill but later realized that at that scale, such automation can be useful. But I guess it can go to the other extreme too and become a time sink.
I'm working on such CRUD app builder, which might be interesting to you. It's self-hosted and because it's written in Golang the entire server is a single binary - users can simply download the binary, run it and that's it. The data is stored in PostgreSQL. The form builder generates JSON, which is stored in the database and the server builds the resulting app on the fly. I'm building the first demos as we speak. So…
Heads up: Youtube video on https://www.formbolt.com/demos/walkthrough/deployed/ is broken on Desktop Safari Version 10.1.2 (12603.3.8).
On creating an app (locally), app error-ed, but the app was visible after refreshing the page, (sorry I couldn't replicate again to get the exact wording).
Might want to add "chmod +x" to the README for non-technical users.
You might want to link to the apps over at localhost:3000 from the app blueprints table.
Loved the:
- single binary deployment - creation of db using the master pw - the fact that the data is stored locally and is kept in the db if I ever decide not to use the app
Cheers,
Marcus
Don't let the sales, marketing, and services part distract you.
In time SSD will kill SQL and CRUD so there is no need for another RDBMS.
Try goms ( https://github.com/artpar/goms ) These type of softwares are now increasingly known as BAAS - Backend as a service. You can also find other similar products on the github readme. This is still in development, and I am using this as backend for two of my other projects. The goals are similar to what you have written, plus more.
JOIN tables, sparse tables, deeply nested JOINs - all this is needed to code link-following in the relational model. So you need an ORM to handle the JOIN pain for you, but relational db query perf degrades as your joins get deeper, so the ORM needs to make hard choices around caching and database query round tips - but the ORM doesn't have enough information about the UI to make these choices - you end up needing to…
As an aside, do you think traditionally built apps should be moving away from SQL and towards immutable stores like Datomic?