That is for the "black cab" taxis, the ones you can hail by waving on the street.
For a private hire vehicle (the kind you telephone or use an app to book), the price is under £700 (under £500 if the driver speaks English).
That doesn't seem unreasonable. The GP comment was referring to the American system where the license are traded at very high costs (tens, hundreds of thousands of dollars).
Those are the prices for becoming a black cab driver (allowed to respond to street hails and use taxi ranks) - to drive for Uber only requires a "private hire driver" license.
The private hire license avoids the need for "the knowledge" and to have the traditional London black cab. There are still fees involved, of course - but becoming an Uber driver is much less demanding than becoming a black cab driver.
> Football hooliganism was well on the way to being solved by the early 90s
I'm not old enough to remember football hooliganism in the 80s and before, but abroad at least, it was very far from solved by the 90s - which is why passports are taken away.
> than all the security theatre prevented some atrocity
Without commenting on how effective any of this is, you won't hear about prevention because it isn't news.
It was probably an order or two of magnitude worse in the seventies and eighties, and somewhat tied in with deprivation and NF racism of those decades. Dutch and British supporters were notorious for it. My father and uncles wouldn't take me to matches as a young 'un. Had they been interested and old enough, I'd have pretty comfortable taking my kids in the nineties.
By the nineties there was just a dwindling hard core minority of hooligans, that were starting to become removed from the clubs. Same for the international element, it had become some thugs being thugs, and mostly separated from grounds, matches and the general support. They tagged along with the footie event, for a good punch up in a city bar or city square. From a point of view of "everyone well behaved" it remained a problem. From a point of view of hundreds or thousands of opposing supporters kicking off, it was mostly solved.
Prevention isn't news, but arresting someone preparing a bomb, or caught on a bus with a machete on their way to wherever is. Yet for all the additional surveillance...
> Bear in mind neither MPs or electorate got to choose him to lead the Tory party
It's worth pointing out that Tory MPs absolutely voted for him before Tory party members got the chance to, and that if MPs in general don't like him then they can vote to bring down the government whenever they like. Quite why non-Tory MPs should get to pick who leads the Tory party I have no idea.
They got to shortlist him, by eliminating candidates until just 2 remain. Then the choice is with the party membership. Which is not the same as voting for him.
That's for the shortlist. It's perfectly possible, albeit vanishingly unlikely that everyone preferred Hunt and the buffoon as second choice. Going on the party's difficulties the last three years it's perfectly likely he was second choice for a clear majority. The disjoint between MPs and membership seems to be becoming a chasm.
This was really odd for me to learn only a couple weeks ago. I had always assumed I was a Gen Yer and that Millenials were just getting out of college now.
You're correct. None of the parent's argument makes any sense in light of this error. I don't understand why the post is being upvoted--the data is outright wrong!
I sense that people may blindly upvote posts reporting figures, especially if they come with sources.
Generation X and Millennial isn't really a sharp transition. No generation is, but it is even more diffuse this time since there wasn't necessarily one or multiple "big events" at a fixed date. I don't know if parent's argument is correct, but what is being said is essentially early Millennial, ~1985 and late Millennial, ~1995. Huge difference in many e.g. housing markets. Once people born around the actual millennial gets old enough we might start talking about Generation Z instead.
Could be the case for many people. I think the commonality between generations might even be declining in favor of other divides. It is in some ways assumed that many people are starting at the bottom and mostly share paths based on development. But I am not sure that is the case anymore, if it ever really were.
I don't think it's fair to say that preserving page structure and formatting is never a good idea. For example, at least one good use for PDFs is sheet music/tabs. Formatting is obviously important here as it tends to lose meaning without it, but equally as important is the page structure and per-page nature of reading vs scrolling. As a (hobbyist) musician, when I'm playing an instrument, I don't have any free hands to scroll with, so it's important to me that I don't have to do it very often.
The problem with putting all async code directly into components is that often, async code is business logic or some other non-view-layer thing that doesn't really belong in a component.
The benefit of redux-thunk (and there are obviously other alternatives that provide the same value) is that it lets you write plain functions that have nothing to do with the store, and nothing to do with components. If you put all your business logic into these plain functions, then they're really easy to test, reason about, move, refactor, etc.
> What drives people to put all of that into their store?
It's worth pointing out that redux-thunk doesn't move async code into your store. The store (i.e. reducers) is still completely synchronous.
> async code is business logic or some other non-view-layer thing that doesn't really belong in a component.
In many React applications, components are separated into independent "controller"-layers and "view"-layers (containers and components are nomenclature I see occasionally, but the important takeaway is that both inherit from the React component class). Business logic has no place in your view components, of course, but is quite appropriate in your controller components. I don't think component implies view layer here. Even redux actions, when used, are appropriately called from the controller layer and not the view layer. Redux doesn't change anything about logical separation of concerns.
When the Flux pattern was originally introduced, it was driven home that it should not be used for everything. redux-thunk seems to encourage that you use it for everything. What do you use when global state is not necessary (or wanted)?
> Business logic has no place in your view components, of course, but is quite appropriate in your controller components.
Sure. Where you actually put stuff depends entirely on the complexity of what it is that you're building. If you have an async function that you need to use in several places then it makes sense to keep it separate. If you have several of these then maintaining a separate container component for each view component that needs access to these quickly becomes unmaintainable.
On the other hand, keeping them as separate functions and adding them in via redux `connect` syntax and `mapDispatchToProps` is simple and makes it clear what's going on. In this scenario, the `connect` higher-order-component acts like the container class, but it built up from separate parts depending on what you need.
> redux-thunk seems to encourage that you use it for everything
I don't think this is true. redux-thunk is a piece of middleware and that's pretty much it. It should be used however is most appropriate for your application and your particular use case. Keeping state inside components isn't always appropriate, but isn't always a bad thing either. If one is growing too complicated, then perhaps the other is more appropriate.
I agree that no two applications have the same needs, but async functions (and non-async, for that matter) are naturally separate and reusable, so I'm not sure I am entirely clear on what you are getting at here. What is the benefit of using connect to connect your function and simply calling that function from your controller? Code needed in multiple places should not require redux.
> Notice how a real person’s arm doesn’t reach the handle quite as easily as the stick figure in the diagram
Not that these doors aren't terrible design (they are), but notice how the stick figure is facing towards the handle when they open it, but the man in the image is facing away from the handle and reaching behind him to open it. If he turned around to face the other way before trying to open the door, he'd find it a lot easier.
Schools exist for the same reason that farms and factories exist: it's a lot more efficient having specialised workers (in this case teachers) who can do the job far more effectively (in this case teach 30 or so children) than having every person do it themselves (in this case every parent take a large portion of time out of their day to teach their own child individually).
The alternative to school was for girls to help out around the house until they were married off and for boys to either learn their father's trade and then do that for the rest of their lives or get apprenticed off to whoever could take them and then do _that_ for the rest of their lives.
School helps children create a life for themselves. If children don't learn anything there they'll find far fewer paths open to them later on.
So we're both agreed then that the goal isn't to "use less code"? I get your point though, so I'll rephrase:
> The goal should be to try harder to use less code
Why is this the goal? At best it's a performance optimisation that some (probably most) sites could use to speed up time to render. But at the same time, there are many other sites where this doesn't make sense or for which the purpose isn't the traditional document based web that is sped up by removing JS. Why should sites that actually benefit from something like WebAssembly be limited just because other sites will use it and (continue to) be slow bug ridden monsters?
[1] https://tfl.gov.uk/info-for/taxis-and-private-hire/licensing...