I think that your consideration is a good one, but I think it comes down to numbers. Will a no-additional-cost-per-ride pass increase the "unnecessary" load on the system so much that they need to start using additional transit vehicles, thus increasing emissions? What percentage of trips are "unnecessary"? Will the growth of the system for "necessary" trips be able to handle the "unnecessary" load anyway?
Aside: for "unnecessary" trips, I'm setting aside the possibility of other options, such as "I already own a car and will now use that instead of paying 1 EUR".
I think they meant (and I am interested in hearing about) appealing a "block" decision that was made by your automation.
If I'm a real human and trying to post a "good" post, but the model classifies it as bad and automatically blocks it, how do I appeal that decision? Can I? Or is my post totally blocked with no recourse?
When a post gets published, it will be send to machine learning image via REST.
If bad, the post will be kept as Draft.
A new record gets created in another database table to keep track them, the accuracy rate was recorded as well.
This was made to make sure no irreversible action was done on the good content.
Blogs with more than 1 year of history would not go through moderation but no action was being taken, just recording the accuracy for future reference.
Later, someone from our team (me usually) would check them by eye and pull trigger on them, they would go into make the training better.
If something would pass the moderation but it was indeed spam, would go into another iteration.
We had to do this for over a month, through the time, the success was around 99%, no blogs would be wiped by machine classification from our database unless confirmed by someone.
That time the whole model was trained for that specific content. Later it get into other type of spams. Which we trained different models.
Overall, the the machine actions were logged, content/users/blogs would get labeled and bad marks on them.
They would be displayed in a report page, until someone make the final decision, through the whole time, the user would be shadow banned (shadow banning didn't help though) and their content would not be published.
Thanks for the detailed response! And nice to hear how much you've managed to keep humans involved in the process. I used to work on a content review automation system for a big company, so it's always fun to hear about how others handle similar cases.
And there's a lot of overlap between how that system acted and what you're describing. It makes we wonder if there's space for a company that offers this sort of model training + content tagging + review tooling capability as a service, or if there's too many variation on what "good" and "bad" input is to make it generalizable.
First names: "We draw racially distinctive first names from two sources. First, we use the
same set of names in Bertrand and Mullainathan (2004), which are in turn drawn from
Massachusetts birth records covering 1974 to 1979. Second, we supplement with names
drawn from administrative records on speeding infractions and arrests provided by the
North Carolina Administrative Office of the Courts and covering 2006 to 2018. We pick
the most common names among drivers born between 1974 and 1979 with race- and
gender-specific shares of at least 90%"
Last names: "Last names are drawn from 2010 Decennial Census data. We use the names with
highest race-specific shares that occur at least 10,000 times, picking 26 total for each
race group"
Apple purchased Siri from a startup of the same name. The startup founder chose the name because he liked it, having first heard of it because it was the name of a former coworker.
So, while perhaps less usual, it was chosen with the knowledge that it was very definitely a name used by people.
May I ask why you think that? (Sincere question, not meant to be snarky). Even assuming electric car assembly is simpler than an ICE powered car, there are still a lot of large, heavy, and expensive components. And that's setting aside all the regulations around it being a "street legal" vehicle, which can place odd constraints and vary from location to location.
I could see there being ways to build your own, just as you could build your own house or laptop if you acquire the right parts. What makes you think that people will broadly want and use kits? (or am I misinterpreting what you're saying?)
The overall mechanics of an electric car is (or can be made, if it's not a conversion) so much simpler; the battery is, in fact, modular, each piece weighing about the same as or less than a regular car battery. I can easily imagine a market for consumer EVs assembled not by huge plants but rather by small local shops as well as enthusiasts. The age of the large brands dominating is coming to an end...
"Sample: 52% of the company's IMs were being sent between 6pm and midnight."
Sounded unbelievable to me! As it turns out, it's not true.
The author links to another of his articles that links to the Harvard Business Review paywalled article, but Microsoft has directly published the actual statistic behind this claim.
"Workplace Analytics data showed the share of IMs sent between 6 PM and midnight has increased by 52 percent on average."
I've been helping teach high school CS classes for years, and even just being able to use some free accounts with students to share code and workspaces has been flawlessly simple. I've always (even pre-pandemic) been a remote instructor, and Repl.it has been one of my best tool experiences. Thanks for the great work!
What considerations do you put into how to handle versioning? I'm thinking mostly of the "decider" logic.
For example, in SWF + Flow land, I maintain different versions just by keeping the old implementation and using version numbers. For Temporal, your team's recommended way is to have a single decider get the execution's version, and write conditionals into the business logic for both cases (https://docs.temporal.io/docs/java-versioning). Is the change in approach intentional, or just a matter of what's been built so far?
The change in approach is intentional. It is still possible to use the old method, but for the majority of cases, it is just too heavyweight. There are two main problems with versioning entire workflows:
1. Need to keep the workers with old code around. It might be solved for some languages like Java by dynamic code loading, but it is still pretty complex. For long-running workflows dozens of changes can happen during their lifetime, requiring dozens of versions to be present at runtime.
2. When a bug is fixed the old versions do not get the fix as they are inherently immutable. Thus a workflow that runs for a month and has started yesterday is still going to experience a bug that was fixed today.
The approach that Temporal promotes is to version each piece of code independently when needed. This way, there is only one version of the entire code in production to maintain, and bug fixes can be deployed any time and apply to all the open workflows that didn't reach the code that was fixed.
Like most thing, its an "it depends" situation. The tech exists, but isn't in wide usage. There's a higher upfront infra cost to pay back, and while short distance reroutes can be accommodated, you do set the general routing in stone. This works fine for larger, denser areas with routes that are more or less fixed.
King County metro (includes Seattle) is one of the agencies that's made major investments in trolley buses.
Battery only bus tech is also growing. I don't think it's viable for large scale usage yet, but KC Metro has been working on and piloting it seriously for a few years. It's possible that by the time more places would look into trolley buses during fleet replacement, battery ones will be ready.
Trolley buses are necessary on many Seattle routes because of all the hills, you just can’t beat torque on a good electric (same is true for many other hilly cities like SF, Vancouver, and Lausanne).
Metro and sound transit has also invested in a lot of hybrids. The most recent fleet is pretty interesting (they also have a few battery-only electrics, but these seem more like testing).
The buses in Lausanne when I lived there were on overhead electric when in the city center and switched back to diesel when they came off the wires. The same was true in a number of other Swiss cities. So I would hardly call it "not in wide use." Just not in the USA.
Ah, I think we're both right here, just on slightly different things. You're correct, trolley with diesel backup isn't new and is in fairly wide usage around the world. To the original comment:
"retaining the ability to drive disconnected from the wires and constantly charge when in an area with the wires"
Seemed to refer to trolley buses with rechargeable battery backups, which are much less common. Admittedly, I don't have non-US stats, just that there are only a handful of cities in the US that use them.
Which routes in Lausanne had that? I never noticed any dual use buses when I lived there. It isn’t surprising, Seattle used to have dual engine buses in the 80s/90s that were diesel until they went into the downtown bus tunnel. They got rid of that when they brought the train in, and I guess the buses were cleaner by then as well.
I lived there up to about eight years ago, and I recall most of the routes running through the center city were dual. I couldn't name route numbers at this remove, though.
Aside: for "unnecessary" trips, I'm setting aside the possibility of other options, such as "I already own a car and will now use that instead of paying 1 EUR".