2
points
superzamp
Joined 693 karma
co-founder @ formance.com
meet.hn/city/fr-Paris
- Isn't the screen size difference basically enough between these two? I can't see why the 16" would need more performance, some ppl just want / can carry large computers with them while some other prefer to have something as small as possible.
- I think it's even realistic to say that dotfiles are vulnerable to being used as a fingerprint mechanism by nefarious packages. One could easily create an inventory of github profiles <> dotfiles; then read local dotfiles when their package gets installed on a developer laptop.
- Well, France just took a stance and officially qualified this as terrorism [1] for the first time.
[1] https://www.diplomatie.gouv.fr/fr/dossiers-pays/israel-terri...
- If you want to treat yourself with an accounting game night, there's this one built by @patio11: https://keshikomisimulator.com/
- PS: it's not highly visible in the link but this post is 6 months old [1]. Wondering where they are now, given that they seemed to have less than that in runway.
[1] https://community.preciousplastic.com/questions/questions-on...
- I would imagine that getting the user out of the in-app purchase payment screen and attempt to redirect them at the website for payment, have them figure out how to enter credit card details etc would result in a drastically decreased conversion rate though.
- superzamp ycombinator.com
- Attempts at doing this are effectively already existing, the IEX [1] exchange being an example, albeit on a less ambitious scale than your idea:
> It's a simple technology: 38 miles of coiled cable that incoming orders and messages must traverse before arriving at the exchange’s matching engine. This physical distance results in a 350-microsecond delay, giving the exchange time to take in market data from other venues—which is not delayed—and update prices before executing trades
- Oh I definitely agree with that. I’m just wondering here if having something mechanical, predictable, deterministic (instead of whatever the hell that is that we have right now) wouldn’t be an interesting way to align incentives.
- If that's the goal, one might wonder why are tariffs implemented in such a static way. Why not having your own tariffs importing from XYZ be updated on a monthly basis based on what XYZ imported from you last month.
- | Formance | formance.com | OSS Financial Infrastructure | NYC, Paris |
Currently hiring for Product Engineers [1], with a background in fintech/payments to work on our ledgering, reconciliation, and accounting systems. We have a highly modular product architecture, so this is a very good opportunity for a technical person who want to drive and own a scope of our platform moving forward.
We don't really care about your tech-stack background in the sense that adapting to ours is the easy part if you have enough experience already. Everything is open-sourced at github.com/formancehq if you want to check it out.
Location: Paris, FR or Europe (Remote) Compensation: Above €75K with equity, exact offer based on experience.
---
[1] https://posthog.com/blog/what-is-a-product-engineer
Send us a note at jobs@formance.com (mention HackerNews in the subject)
- The graph seems to be alright, there are indeed red and (some) green pixels, looks like an issue with your extension unfortunately.
- > Anastasios Angelopoulos, with beard, and Wei-Lin Chiang
What is going on here, are we suppose to specify people's position in a photo according to facial features now?!
- 2 points
- (Disclaimer: I’m the author, nice to see your take here and pleasantly surprised to see my post here as well!)
You can surely use accounts with fine grained attributes (e.g. to describe the soon to be received but not yet available money or customer 1234, naming it users:1234:pending). You can even add more data to this account on a metadata level (e.g. finer grained accounting classification).
The problem with an account-only approach is that a monetary value represented in it is only temporarily represented here, and if there’s a specific set of attribute relative to that value, you’ll be somewhat forced to overly complicate your structure of accounts to persist theses values throughout the ledger.
Banks are not fintech and hence face different issues so let’s take an example anchored in that context. Imagine you’re holding $100 for user 1234, spread across two FBO accounts at two different banks. You might be interested in persisting the nature and location of these funds throughout the ledger. So instead of having an account structure such as users:1234:main:jpmc, users:1234:main:fargo and so on, you could simplify your ledger structure by having a single users:1234:main holding something like:
So that no matter the complexity of your ledger transactions, you’ll always be able to « reveal » the identity of these funds which would otherwise be lost in a ledgering model optimized for classical accounting.[USD/2 100 (bank: jpmc)] [USD/2 100 (bank: fargo)]But that’s just an example, the idea is to explore the concept of semi-fungibility and how it can improve some of the challenges fintech face (in their journey of being not bank).
- > Does recording it twice
Double entry is (confusingly) not about recording it twice, it's about using a transaction model where the state of N accounts has to be changed in compensating directions within a transaction for it to be valid, N being >= 2.
So depending on how your transaction schema is defined, a double-entry transaction can be written without ever even repeating the amount, e.g.
Making it effectively impossible to represent invalid state change. Things get trickier when N > 2 as classical double-entry tend to _not_ directly relate tuples of accounts directly to one-another and instead relying on a aggregated balancing of the changes to the N accounts at the transaction level, though YMMV between different ledgering systems.{"debit": "cash:main", "credit": "giftcards:1234", "amount": 100} - Precisely. Designing a transactional system can be solved. Designed a transactional system that properly entangles the bits with the assets they represent is the hard part.
I've written a bit about it on my own co's product blog in an attempt to demystify some core concepts [1], [2], [3].
Still on ledgering and expanding into less mathematical and more applied concepts, I can also recommend a book called "The Accounting Game: basic accounting fresh from the lemonade stand" [4].
[1]: https://www.formance.com/blog/engineering/how-not-to-build-a... [2]: https://www.formance.com/blog/engineering/debits-and-credits... [3]: https://www.formance.com/blog/engineering/ledgering-all-the-... [4]: https://books.google.com/books/about/The_Accounting_Game.htm...