Have they included real profiles in the screenshots of the "Discover profiles" menu and the list of likes? If so that's pretty irresponsible even with the faces obscured.
I'm quite possibly missing something, but this is baffling to me (Text S1 from the paper) [1]:
> All the chopped carrots were carefully transferred to the glass wash tray. As shown in Figure 2,
> 500 mL of ultrapure water was used to wash the blade and the chopping board further to transfer all the particles in the same glass wash tray.
Who would expect contaminants left on the blade and the board to be counted alongside those in the chopped food itself? I suppose it's difficult to rigorously separate the chopped and the chopped-upon, but the distinction seems essential to support, or not, the hypothesis about human consumption.
Something which goes further than this, but works very well for my use case and would probably suit others in the WFH crowd: OpenMPTCProuter [1]
This handles failover between connections and also aggregates them using MultiPath TCP to maximize bandwidth & overall reliability at the expense of increased data usage and the cost of running a machine somewhere with a decent connection, even a cheap VPS.
I'm using it to aggregate ADSL, Starlink and 4G, resulting in a stable 250mbps/50mbps connection.
but then you face the same problem as when you have a VPN to a VPS, sites will see your IP address, see you are coming from a cloud service provider, and block you.
Forgot to say that it's open source (AGPL) on GitHub [1]. I find it handy just being able to run `git blame` on a doc, but I'm sure it could be made more useful. Contributions are welcome!
The only benefit of the hosted version is that the OAuth setup is already done. If you're ok registering an OAuth app with Google (instructions in README.md) then it's trivial to run yourself. Given that there's no fine-grained permissions on Drive - it has to ask for read only access to your entire Drive just to access one doc - I completely understand wanting to run it locally.
This is similar to the Structure dashboard in Repography [1] which is a web app I built, with the added advantage that it's kept up to date automatically so you can embed it in your README.md and not have to keep updating it yourself.
I was surprised by the observation that Python rounds towards even numbers, so round(0.5) = 0, but round(1.5) = 2.
This is indeed clearly documented [1], I guess I never looked closely enough. I found some discussion on the dev-python list [2] which shows at least I'm not the only one surprised by this!
That's good to know and kind of dangerous. I have seen banking regulators getting upset in the past because of roundings not following the usual convention ("banker's rounding"). You will have a hard time explaining it's an unexpected behaviour of some programming language rather than the management of the bank trying to be cute with the numbers.
Banker's rounding is "round to even", because it limits the amount of bias introduced by the rounding.
> But I know the regulator will expect round(0.5) = 1, not 0.
That's not necessarily the most helpful, as there's at least two tie-breakings which provide that, but differ in their treatment of negative numbers (round up or round to +∞, and round away from zero or round to ∞).
I have seen banking regulators getting upset because they (effectively) assumed infinite precision until the "final rounding" (their verbiage). This was at a major financial services provider with exactly zero numerical stability analysts.
Hey there - your points are accurate! Here are a few more:
- We are open source / MIT
- You can re-use Payload's auth layer in your own apps and with Contentful you can't
- Contentful has rigid RBAC, but Payload features function-based access control down to the field level
- Payload supports field conditional logic, meaning "check a checkbox, see more fields, uncheck it, extra fields disappear". This is huge. And is super hard to build right but it's very important for a good admin experience.
- Payload gives you a local Node API (note: not HTTP / REST / GraphQL.) Contentful does not. With Payload's local API, you can do lots of awesome things within hooks, access control, etc. - and even reuse it in your own endpoints. All of this is impossible with Contentful without going through their HTTP layer
- Payload lets you add your own admin UI views
- Payload has no usage limits
- Payload is code-first, Contentful is "point and click"
Phew. There's a lot more. This all is just top-of-mind word vomit.
Our enterprise offering can either be self-hosted or it can leverage Payload Cloud, once we have it built. Some enterprises opt to manage Payload on their own infrastructure, and just pay us for SLA and premium features like SSO, audit logs, etc. But we do have enterprises in line to use our managed infrastructure as well... so basically, the answer is "both".
most people wont read it, but the serious people will. and better to claim your narrative than leave it in the hands of users who know less than you about your own market.
Yep! As our cloud hosting is not yet launched, we don't have the pricing finalized for that but for our enterprise features and SLAs, it's all broken down based on what you need. For 20 seats, a few enterprise features and a lower-tier SLA, you'd pay a few thousand a month.
For hundreds of seats, with a more robust SLA, your costs would scale linearly, but it's entirely based on what you need.
I'm kind of curious what you mean by 'point and click' here? The contentful web interface is, of course, a web interface - but it's perfectly possible to interact with the API directly for people who want to do so.
As Graydon Hoare notes in the comments on GitHub this wasn't the first repo so the real history goes back even further. He's also shared a "prehistory" repo [1] which is interesting to browse. The first commit [2] in _that_ repo is from 2008 but Graydon mentions starting work back in 2006.
Anyway in a sense this repo represents Rust in the real world rather than in gestation, so seems apt to call it the birthday.
reply