396 karma · joined June 20, 2019
Writing to Stripe is not supported, but you will likely want to use the Stripe API directly in order to handle errors.
The events endpoint works slightly differently from webhooks: https://table.dog/blog/principles/events-are-better/
I wrote about this here:
I sometimes use a text editor just because the indenting works well.
This allows me to break down the tasks into sub tasks. Would be useful to sum the time for each branch.
What tech stack did you use front/back end?
You get lots of benefits, but then you cannot use any C system calls which most code relies on (networking, disk, GUI) etc.
It looks like runtimes are going to create message passing interfaces to access these C system calls.
Wouldn't it be easier just to create better sandboxes for the old code rather than create a WASM runtime with new message passing interfaces to all the old C system functions?
I have similar apps, and the Adsense rejection is quite vague.
I find that modelling SQL tables first removes the “where in the JSON-like tree should this live” question - often a single object type lives in many places in the tree.
Breaking data into atomic units and then building up any JSON-like structures you require with queries is very flexible, and solves persistence first.
ORMs seem to solve persistence second after modelling your data as JSON-like in-language objects.
Persistence needs to be solved as disk is cheaper than RAM and your program cannot live forever with data in RAM.
I said I would feel more energised keeping the money in my pocket.
I agree with OP that if you are on a powerful machine with fast internet it would be better just to load a massive HTML document of list items.
E.g. A business process involving PDF's could auto annotate some information for a human processor to whizz through.
When I last checked, Supabase is a group of processes that you manage yourself.
This means that:
- A. If something goes wrong or you need to customise something, it would be quite complex to fix as you have all these different processes and code bases to understand. The sum of depended-on lines of code for all the open source code bases in Supabase would be massive.
- B. You are tightly locked in. Once you code against the Supabase API's you will not be able to move your app off of it. Other API's lock you in too, but because Supabase does so many things you would need to replace a lot of functionality all at once to move away.
I think that the text/notation based representation of programs (or state machines) is the most effective way.
The reason is that it leverages the human ability to use language. I think our intuition for language and thought is much better than our intuition for 2d/3d spaces.
A picture is worth a thousand words, but if you need exact precision, as programs need, no amount of non-text-pictures would give you that flexibility to describe exactly what you want without losing details.
There is a steep learning curve to languages, but once you have learnt the language, these concepts get attached and integrated to your thoughts. This allows you to design increasingly higher levels of abstraction, until you are working with concepts in your current domain.
- 1. Push the sacrum-point as far back as possible for the entire movement, keeping your back straight. I have found this reduces the number of things I am focusing on and seems to be comfortable.
- 2. Focus on explosive-like movement from the bottom. I find exerting my effort at the bottom of the squat to the first 20% of the lift creates momentum, and avoids slow and unnatural pauses which seems to cause me injuries.
Strange that he says this, because the original "Good Parts" principle is that you can use the "good" subset of the language.
No matter how many new features they add, that same "good" subset is still there ready to use due to backward compatibility.
Your initial ideas need constant iteration as you interact with reality to see what works.
A team that will leave in a few months for the next thing have no incentive for iteration or great execution - both which are needed to interact with reality to find something that works.
Over time competition between the 3 major clouds combined with hardware getting cheaper will mean there is not going to be a massive jump in prices, if any at all.
It is not impossible to design relatively cloud-portable server software.
Also I think FedEx, and companies in general, would prefer to increase revenue rather than reduce costs (by running their own data center) in order to increase their net profit.
- Excel (I see this as just an advanced calculator. Basic pivot tables and charts).
- SQLite (I start with this and then move to a SQL server if it cannot keep up with write throughput. I use it to “reduce distributed state” so that I can understand everything with just a function stack trace. I often find data modelled in 2nd or 3rd normal form tables beats “how should I nest this data” in a general language as you can use SQL to produce many tabular views from the same scalar values).
- Javascript (Since I read “The good parts” I find JSON and modern JS as a scripting language much more productive than anything else for small or disposable projects. Closures, event loop and async/await built in by default, global distribution in browsers, JIT produces machine code that gets you closer to a compiled language performance than any other dynamic language).
- Typed languages (I used to dislike types because I felt they got in the way and what’s the point? Now I see them as a tool to get extremely fast iteration loops as your editor will tell you if all the things snap together magnetically in less than one second. Great for breaking things apart and reconnecting them. I work on many code bases, and all that implicit type data in your head disappears when you leave a dynamic code base for a few weeks. Also having a spec for messages your server sends and receives allows you to auto generate docs).
- Sublime (so snappy to start I use it as a general scratch pad).
- Regular expressions (sometimes there is no substitute. I like that there is a little string matching machine and notation that is the same in every language, and that you can rapidly iterate outside of the code base in a web editor then paste it into the program).
- Preview (extremely fast to open and zoom into vector based graphics like PDFs).
- PDF’s (in a world where every app that reads and writes doc-like-data wants to lock you in, being able to export to PDF will at least allow you to read your content without the app far into the future. Spotlight on macOS will index the text allowing for search).
- Pen and paper (just being able to see your thoughts and then refining them or finding new branches of thought is a huge improvement over trying to keep everything in your mind. The computer is often too distracting for this).
I would assume SQLite has some optimisations for native tables (rather than reading the data from another virtual table backed file)?
One reason it is slower is that it is is difficult to create a map like diagram where you zoom in to get greater detail.
I know JS very well, but it takes me 20x longer than web stuff to workout how to do something as it’s just pure trial and error.
Each script run is slow as it must actually do the actions in the GUI.
JS is more useful than AppleScript in my opinion as it supports JSON data and functions.
> It's always the same thing, figure out what the UI needs then build an endpoint for it. Most API code involves struggling with an ORM to query a database and mangle the data into a shape that the UI expects to see.
Most business API's have business specific per user read/write access roles.
I am starting to think that a better solution to GraphQL and other DSL's is to:
- A. Make the iteration speed of adding a new plain HTTP endpoint very fast.
- B. Use a typed language, and some kind of macro to extract the types into an Open API spec.
This way everything is just a regular function in your general language:
- http_handler(request) -> response
- user_has_access(user, resource) -> bool)
etc.
Regular functions have no external dependencies, are easy to understand, edit and stand the test of time better than DSL's.
If GQL does what you need out of the box, it seems a win. But I would assume some endpoints need to fall back on the above approach anyway giving you a mixture of GQL-generated and hand-written handlers.
Loved this game as a teenager.
When riding a normal bike, I feel safer knowing I can quickly abandon the bike and dive to the side if needed.
E.g if I had some tables with string UUID foreign keys, would it suggest them?