This platform has a GitHub app that you can integrate into your public repositories (check the docs for repo owners). It uses stripe connect which is supported by 120 countries. Let me know if you have suggestions for improving it.
The way I understand it now, they attach an invite to an email that you don't even read, but it shows up on your calendar. Is it too much effort to open the attachment yourself? Normally it's advisable not to open attachments from sketchy senders.
About the same as four people in the average American car (25mpg at four people is 100mpg per seat). Compared to say, your average truck driver (like, 10? 15?), it's absolutely spectacular.
A good European train can technically do 400-500mpg per seat, so 4-5x, but load factors tend to be much lower, I believe around 80-85% for planes vs 40-50% for intercity trains.
Given that then, in the real world conventional trains are about 2-3x more efficient than planes. High speed trains lose a significant amount of that advantage - can't beat physics (air resistance).
At the end of the day, long distance travel is simply expensive however you cut the cookie. There's nothing particularly special about air travel.
I think this isn't specific to iCloud, just in general invites are automatically picked up from emails. Calendar invites have long been a source of spam, so I'm not surprised there's also a vulnerability.
I'd avoid having separate services share a DB. Besides the overhead, you get scary hidden dependencies that way. If this approach is considered not micro but rather an in-between, the article should mention it as an option.
It's all just human arrogance in a centralized neural network. We are, despite all our glorious technology, just space monkeys who recently discovered fire.
Again, you're stretching definitions into meaninglessness. The way you are using "sampling" and "distribution" here applies to any system processing any information. Yes, humans as well.
I can trivially define the entirety of all nerve impulses reaching and exiting your brain as a "distribution" in your usage of the term. And then all possible actions and experiences are just "sampling" that "distribution" as well. But that definition is meaningless.
I read a similar story on reddit yesterday [0]. It looks like these lawyers have taken a page off of patent trolls by engaging in similar extortion schemes, suing thousand of small business in hopes the businesses will settle to avoid costly legal battles. But these kind of predatory practices can just straight-up kill a new business who can't afford to them pay off.
They're not sampling from prior conversations. The model constructs abstracted representations of the domain-specific reasoning traces. Then it applies these reasoning traces in various combinations to solve unseen problems.
If you want to call that sampling, then you might as well call everything sampling.
It does not directly target an IR like Cranelift/LLIR or even bytecode since the goal was to make this work in an alternative way (I used to design PL type systems before so I can understand the rigor involved in building a complete language). Additionally, many _target-C/C++_ languages clutter the workspace with source & header files and other config metadata (albeit for plausible reasons). The main highlights are *deducible types* that match corresponding semantics in C++, *non-exhaustive pattern matching* and a *limited syntax grammar*. The _expression-based_ part is still incomplete but parseable.
There are many missing features (still v0.1 pre-release). So far, output source files are heavily underoptimized and error handling is basically messed up. My aim was to design a minimal PL that is similar to ML/Python and can target C++. It is also the first time I get to use a PEG parser implementation.
Sure, but I don't think civit.ai leans into the "novel/powerful/dangerous" element in its marketing. It just seems to showcase the convenience and sharing factor of its service.
It seems ridiculous but I think it may have some credence. Perhaps it is because of sci-fi associating "dystopian" with "futuristic" technology, or because there is additional advertisement provided by third parties fearmongering (which may be a reasonable response to new scary tech?)
I think the assumption here is that "microservices" means each team is dealing with lots of services. Sometimes it's like that. But if you go by the "one service <=> one database" rule of thumb, there will probably be 1-3 services per team. And when you want to use other teams' stuff, you'll be thankful it's across an RPC. First basic reason is if you don't agree with that other team on what language to write in.
It'd really help to see a concrete example of a modular monolith compared to the microservice equivalent.
There would be a mix of versions, managed via branches.
The part about debuggability sounded appealing at first, but if the multiple services you want to run are truly that hard to spin up locally, it won't be any easier as a monorepo. First thing you'll do is pass in 30 flags for the different databases to use. If these were RPCs, you could use some common prod or staging instance for things you don't want to bother running locally.
I worked in smaller companies and now I work at Google. I enjoyed working for smaller companies so much more. I would never make a change from a small company to Google for the same pay. I think you will be shocked by how political and non-meritocratic Google is. Living abroad is also far from being all roses.
For bar/restaurant owners and/or trade show organizers, here's a pretty cool project called High Score Host that just launched and has an attractive lifetime deal available right now as part of their public beta. Could be a game-changer for those of you who understand the value of building an email list.
Originally built for brick-and-mortar businesses like bars, cafes, and restaurants, it allows them to transform any screen into a live leaderboard, engaging customers and collecting their emails at the same time.
If any is interested in being part of the Beta Test, you can find it at the url above
1300 is a nice sample size if you're sampling randomly.
If 1/3 of people have a trait, you'll get a good sense it's common after asking 300 people, even if the total population is a million. Surveying more gives diminishing returns as the result quickly converges on the real proportion.
The real problem with all surveys is the sampling isn't truly random, which skews results.
