41–50 of 66 posts
- take a photo of a supermarket receipt and OCR all the items
- get that at least 95% correct
- output that in a document with correct horizontal grouping?
If not, can someone recommend me an Android app for this?
I just use GnuCash, a scanner, some good old Samba file-hosting on a local Debian server running 24/7, and WOL and VNC (or just SSH and SCP) if I need to access anything from not at home.
What "no code" is really about is "no figuring out the toolchain, deployment, integration with third parties, etc". For actually writing business logic, replacing code with drag and drop logic blocks is... not really helpful to anybody. But with all the crap that programmers actually spend our days dealing with removed from the picture, anybody can write their own business logic, even if they have to do it in gasp co…
> For actually writing business logic, replacing code with drag and drop logic blocks is... not really helpful to anybody It's not helpful for anybody to be able to write their own services, even if they cannot code? Everyone who can't code, would disagree with you. Sure, they can spend some free time to pickup programming, and maybe after a lot of reading and practicing, would be able to build the flow in a programm…
The second sentence ("First, you work all month, and then you give half of the money to those who didn't work.") is already so blatantly wrong and reactionary that I almost have to force myself to read on - after all, if the premise is already flawed what good can come of it?
Soooooo, the author moved away from waveapps because the system did no allow him to link multiple pictures to 1 receipt. So he started implementing his own no-code solution which... also doesn't allow him to link multiple pictures to 1 receipt...
Earlier quoted context omitted.
> For actually writing business logic, replacing code with drag and drop logic blocks is... not really helpful to anybody It's not helpful for anybody to be able to write their own services, even if they cannot code? Everyone who can't code, would disagree with you. Sure, they can spend some free time to pickup programming, and maybe after a lot of reading and practicing, would be able to build the flow in a programm…
Eventually, there's almost always a need for some edge case, some scenario not quite covered by the no-code framework, and you're back to writing code, even if it's sold as not actually coding.
> and you're back to writing code
My point was more geared towards the people who can't write code. So this is not really an alternative for them. So something imperfect that kind of does what you need, in most cases, is most of the times better than nothing.
I don't think anyone is selling "no code" as a solution that works for everything and any case. But it does work for a lot, so us "real" programmers can stop implementing the same boilerplate over and over, and people who can't program, can build automated workflows for themselves, which is nice.
It's not "no code" it's "code later". It doesn't prevent the effort of coding the solution, just moves it down the line and makes it harder. The good part is that (as the article) says, you only need to write the code when you know the code will be used. The bad part is that the no-code solution will break at some point. Usually because some part of the chain introduced a breaking change, or the process its modelling…
> It doesn't prevent the effort of coding the solution, just moves it down the line and makes it harder. What is harder about using a OCR app and calling the Airtable API to get the expenses compared to writing all the code to take photos, scan for text, and then upload to Airtable or even a SQL DB?
So, to take the example: you set up the expenses handling with no code, it's easy, all good. Then halfway through next year, the OCR app starts charging $1 per scan (as a hypothetical). Now you have to write some code. But your accountant is waiting for your receipts, so you have a deadline for the coding. And your code has to use the Airtable API, because that's where the rest of your process takes off. That API might be a lot harder to use than, say, SQLite, which would be your choice if you were coding the system from scratch.
So the code you have to write has constraints from the rest of the process that still works, and a deadline. So it's harder to write.
That's what I meant by "makes it harder".
The second sentence ("First, you work all month, and then you give half of the money to those who didn't work.") is already so blatantly wrong and reactionary that I almost have to force myself to read on - after all, if the premise is already flawed what good can come of it?
Yeah, I mean clearly half of the money is going to RENT. ;)
> First, you work all month, and then you give half of the money to those who didn't. It's called RENT.