I'm not the director. OR AM I? (I'm not.)
144 stories
·
5 followers

Defund the Police? We’ve Already Done It Successfully in America.

2 Comments and 12 Shares

The American system of law enforcement is so deeply embedded into our national psyche that if you find the idea of defunding or abolishing the police challenging, I don’t blame you. But imagine calling an ambulance because a loved one was having trouble breathing or was suffering a stroke and, instead of the expected trained paramedics, a man with a gun showed up. Not great, right? As Jamie Ford explains in this thread, that was not unusual in America until recently.

Until the 70s, ambulance services were generally run by local police and fire departments. There was no law requiring medical training beyond basic first-aid and in many cases the assignment of ambulance duty was used as a form of punishment.

As you can imagine, throwing people with medical emergencies into the back of a paddy wagon produced less than spectacular health outcomes. Now imagine how much worse it became when disgruntled white police officers were demoted to ambulance duty in black neighborhoods.

From Kevin Hazzard’s The First Responders:

Emergency care was mostly a transportation industry, focused on getting patients to hospitals, and it was dominated by two groups: funeral homes and police departments. Call the local authorities for help and you’d likely get morticians in a hearse or cops in a paddy wagon. If you received any treatment en route to the hospital — and most likely you did not — it wouldn’t be very good. At best, one of the people helping may have taken a first-aid course. At worst, you’d ride alone in the back, hoping, if you were conscious, that you’d survive.

Pittsburgh’s Freedom House Ambulance Service changed all that, ushering in a new era of much improved medical care for communities around the US.

Together the two men hashed out a plan: Hallen would raise the money, Safar would contribute his medical expertise, and together they would design advanced ambulances and teach paramedics to provide care on the scene of an accident or emergency. It would be a pioneering medical effort, and Hallen, who was white, suggested another first. The Falk Fund was committed to mitigating racism, and Hallen wanted to staff the service with young black men from the Hill. He hoped that empowering individuals long deemed unemployable would be a source of pride in the black community, a symbol of equality, and a signal that bigoted notions about the black people of Pittsburgh standing in their own way were nonsense.

To help with recruitment, Hallen and Safar partnered with an organization called Freedom House Enterprises, a nonprofit dedicated to establishing and supporting black-run businesses in the city. Freedom House handled staffing for the fledgling ambulance service and recruited the first class of paramedics, including Vietnam veterans and men with criminal records.

So this is a great instance in which armed and untrained police officers have been relieved of a particular responsibility and replaced with specially trained personnel, resulting in a greatly improved outcome for members of the community. If you want other examples, just think about how odd, unhelpful, and dangerous it would be for our communities if the police showed up — armed with a loaded weapon — to collect your garbage, to put out fires, to inspect restaurants, to fix potholes, or to deliver the mail. No, we have sanitation workers, firefighters, public health inspectors, municipal maintenance workers, and postal workers to do these jobs — and they’re all trained in the ins and outs of their particular disciplines.

With these examples in mind, instead of armed personnel handling a wide variety of situations for which they are often not trained, it becomes easier to imagine traffic patrols conducting transportation safety stops, social workers responding to domestic disputes, special crisis centers assisting rape victims, mental health counselors helping people behaving erratically in public, housing guides finding homeless folks a place to stay, student safety coaches helping struggling students navigate school, unarmed personnel responding to property crime, and drug addiction counselors helping drug users stay safe. These are all areas where American communities have applied policing by default, like a flimsy bandaid. It’s ineffective, expensive, and dangerous, and communities should think seriously about supporting and funding alternatives that will be more effective, cheaper, safer, and produce better outcomes for everyone.

Tags: cities   crime   Jamie Ford   medicine   policing
Read the whole story
kemayo
5 days ago
reply
St Louis, MO
popular
6 days ago
reply
Share this story
Delete
2 public comments
WorldMaker
1 day ago
reply
I was wondering why this history of ambulances is even less well known than the mafia tactics that lead to not-for-profit civic volunteer fire departments, and then the mention in the article that the innovating ambulance group was a black-owned business answered that. Wow, this should be more predominant in history books.
Louisville, Kentucky
cjheinz
8 days ago
reply
Yay!

Time travel in Avengers: Endgame

1 Share
Time » I'm using this essay to share some random thoughts about the entire Marvel Cinematic Universe to date. If you prefer, you can skip straight to the time travel discussion. * Probably the thing I appreciate the most in Iron Man is the very naturalistic, almost improvisational dialogue between Robert Downey Jr. and Gwyneth Paltrow (and sometimes Jeff Bridges). It's fast and entertaining and you can see that a lot of the time Paltrow isn't actually able to keep up with him, which is of course exactly what you want in those character interactions. Sadly it's not something I ever expect to see again in the MCU, the franchise is far too tightly controlled for that. I enjoy the lengthy scenes where Stark is slowly assembling the second Iron Man suit through trial and painful error. It's fun to watch him succeed, but RDJ also has good comic timing and it's humanising for him to screw up painfully a few times, earning the end result. And yes, the suit is sweet. At the time, the special ...
Read the whole story
kemayo
7 days ago
reply
St Louis, MO
Share this story
Delete

Second-guessing the modern web

2 Shares

The emerging norm for web development is to build a React single-page application, with server rendering. The two key elements of this architecture are something like:

  1. The main UI is built & updated in JavaScript using React or something similar.
  2. The backend is an API that that application makes requests against.

This idea has really swept the internet. It started with a few major popular websites and has crept into corners like marketing sites and blogs.

I’m increasingly skeptical of it.

There is a sweet spot of React: in moderately interactive interfaces. Complex forms that require immediate feedback, UIs that need to move around and react instantly. That’s where it excels. I helped build the editors in Mapbox Studio and Observable and for the most part, React was a great choice.

But there’s a lot on either side of that sweet spot.

The high performance parts aren’t React. Mapbox GL, for example, is vanilla JavaScript and probably should be forever. The level of abstraction that React works on is too high, and the cost of using React - in payload, parse time, and so on - is too much for any company to include it as part of an SDK. Same with the Observable runtime, the juicy center of that product: it’s very performance-intensive and would barely benefit from a port.

The less interactive parts don’t benefit much from React. Listing pages, static pages, blogs - these things are increasingly built in React, but the benefits they accrue are extremely narrow. A lot of the optimizations we’re deploying to speed up these things, things like bundle splitting, server-side rendering, and prerendering, are triangulating what we had before the rise of React.

And they’re kind of messy optimizations. Here are some examples.

Bundle splitting.

As your React application grows, the application bundle grows. Unlike with a traditional multi-page app, that growth affects every visitor: you download the whole app the first time that you visit it. At some point, this becomes a real problem. Someone who lands on the About page is also downloading 20 other pages in the same application bundle. Bundle splitting ‘solves’ this problem by creating many JavaScript bundles that can lazily load each other. So you load the About page and what your browser downloads is an ‘index’ bundle, and then that ‘index’ bundle loads the ‘about page’ bundle.

This sort of solves the problem, but it’s not great. Most bundle splitting techniques require you to load that ‘index bundle’, and then only once that JavaScript is loaded and executed does your browser know which ‘page bundle’ it needs. So you need two round-trips to start rendering.

And then there’s the question of updating code-split bundles. User sessions are surprisingly long: someone might have your website open in a tab for weeks at a time. I’ve seen it happen. So if they open the ‘about page’, keep the tab open for a week, and then request the ‘home page’, then the home page that they request is dictated by the index bundle that they downloaded last week. This is a deeply weird and under-discussed situation. There are essentially two solutions to it:

  1. You keep all generated JavaScript around, forever, and people will see the version of the site that was live at the time of their first page request.
  2. You create a system that alerts users when you’ve deployed a new version of the site, and prompt them to reload.

The first solution has a drawback that might not be immediately obvious. In those intervening weeks between loading the site and clicking a link, you might’ve deployed a new API version. So the user will be using an old version of your JavaScript frontend with a new version of your API backend, and they’ll trigger errors that none of your testing knows about, because you’ll usually be testing current versions of each.

And the second solution, while it works (and is what we implemented for Mapbox Studio), is a bizarre way for a web application to behave. Prompting users to ‘update’ is something from the bad old days of desktop software, not from the shiny new days of the web.

Sure: traditional non-SPA websites are not immune to this pitfall. Someone might load your website, have a form open for many weeks, and then submit it after their session expired or the API changed. But that’s a much more limited exposure to failure than in the SPA case.

Server-Side Rendering

Okay, so the theory here is that SPAs are initially a blank page, which is then filled out by React & JavaScript. That’s bad for performance: HTML pages don’t need to be blank initially. So, Server-Side Rendering runs your JavaScript frontend code on the backend, creating a filled-out HTML page. The user loads the page, which now has pre-rendered content, and then the JavaScript loads and makes the page interactive.

A great optimization, but again, caveats.

The first is that the page you initially render is dead: you’ve created the Time To Interactive metric. It’s your startup’s homepage, and it has a “Sign up” button, but until the JavaScript loads, that button doesn’t do anything. So you need to compensate. Either you omit some interactive elements on load, or you try really hard to make sure that the JavaScript loads faster than users will click, or you make some elements not require JavaScript to work - like making them normal links or forms. Or some combination of those.

And then there’s the authentication story. If you do SSR on any pages that are custom to the user, then you need to forward any cookies or authentication-relevant information to your API backend and make sure that you never cache the server-rendered result. Your formerly-lightweight application server is now doing quite a bit of labor, running React & making API requests in order to do this pre-rendering.

APIs

The dream of APIs is that you have generic, flexible endpoints upon which you can build any web application. That idea breaks down pretty fast.

Most interactive web applications start to triangulate on “one query per page.” API calls being generic or reusable never seems to persist as a value in infrastructure. This is because a large portion of web applications are, at their core, query & transformation interfaces on top of databases. The hardest performance problems they tend to have are query problems and transfer problems.

For example: a generically-designed REST API that tries not to mix ‘concerns’ will produce a frontend application that has to make lots of requests to display a page. And then a new-age GraphQL application will suffer under the N+1 query problem at the database level until an optimization arrives. And a traditional “make a query and put it on a page” application will just, well, try to write some good queries.

None of these solutions are silver bullets: I’ve worked with overly-strict REST APIs, optimization-hungry GraphQL APIs, and hand-crafted SQL APIs. But no option really lets a web app be careless about its data-fetching layer. Web applications can’t sit on top of independently-designed APIs: to have a chance at performance, the application and its datasource need to be designed as one.

Data fetching

Speaking of data fetching. It’s really important and really bizarre in React land. Years ago, I expected that some good patterns would emerge. Frankly, they didn’t.

There are decent patterns in the form of GraphQL, but for a React component that loads data with fetch from an API, the solutions have only gotten weirder. There’s great documentation for everything else, but old-fashioned data loading is relegated to one example of how to mock out ‘fetch’ for testing, and lots of Medium posts of varying quality.


Don’t read this as anti-React. I still think React is pretty great, and for a particular scope of use cases it’s the best tool you can find. And I explicitly want to say that – from what I’ve seen – most other Single-Page-Application tools share most of these problems. They’re issues with the pattern, not the specific frameworks used to implement it. React alternatives have some great ideas, and they might be better, but they are ultimately really similar.

But I’m at the point where I look at where the field is and what the alternative patterns are – taking a second look at unloved, unpopular, uncool things like Django, Rails, Laravel – and think what the heck is happening. We’re layering optimizations upon optimizations in order to get the SPA-like pattern to fit every use case, and I’m not sure that it is, well, worth it.

And it should be easy to do a good job.

Frameworks should lure people into the pit of success, where following the normal rules and using normal techniques is the winning approach.

I don’t think that React, in this context, really is that pit of success. A naïvely implemented React SPA isn’t stable, or efficient, and it doesn’t naturally scale to significant complexity

You can add optimizations on top of it that fix those problems, or you can use a framework like Next.js that will include those optimizations by default. That’ll help you get pretty far. But then you’ll be lured by all of the easy one-click ways to add bloat and complexity. You’ll be responsible for keeping some of these complex, finicky optimizations working properly.

And for what? Again - there is a swath of use cases which would be hard without React and which aren’t complicated enough to push beyond React’s limits. But there are also a lot of problems for which I can’t see any concrete benefit to using React. Those are things like blogs, shopping-cart-websites, mostly-CRUD-and-forms-websites. For these things, all of the fancy optimizations are trying to get you closer to the performance you would’ve gotten if you just hadn’t used so much technology.

I can, for example, guarantee that this blog is faster than any Gatsby blog (and much love to the Gatsby team) because there is nothing that a React static site can do that will make it faster than a non-React static site.


But the cultural tides are strong. Building a company on Django in 2020 seems like the equivalent of driving a PT Cruiser and blasting Faith Hill’s “Breathe” on a CD while your friends are listening to The Weeknd in their Teslas. Swimming against this current isn’t easy, and not in a trendy contrarian way.

I don’t think that everyone’s using the SPA pattern for no reason. For large corporations, it allows teams to work independently: the “frontend engineers” can “consume” “APIs” from teams that probably work in a different language and can only communicate through the hierarchy. For heavily interactive applications, it has real benefits in modularity, performance, and structure. And it’s beneficial for companies to shift computing requirements from their servers to their customers browsers: a real win for reducing their spend on infrastructure.

But I think there are a lot of problems that are better solved some other way. There’s no category winner like React as an alternative. Ironically, backends are churning through technology even faster than frontends, which have been loyal to one programming language for decades. There are some age-old technologies like Rails, Django, and Laravel, and there are a few halfhearted attempts to do templating and “serve web pages” from Go, Node, and other new languages. If you go this way, you’re beset by the cognitive dissonance of following in the footsteps of enormous projects - Wikipedia rendering web pages in PHP, Craigslist rendering webpages in Perl - but being far outside the norms of modern web development. If Wikipedia were started today, it’d be React. Maybe?

What if everyone’s wrong? We’ve been wrong before.

Read the whole story
kemayo
86 days ago
reply
St Louis, MO
samuel
87 days ago
reply
Cambridge, Massachusetts
Share this story
Delete

Some people are starting to act as if this whole thing is pretty much over. It h...

3 Shares

Some people are starting to act as if this whole thing is pretty much over. It has become more and more the norm to bend the rules, and there will be increased social pressure to go along.

I think this is important to note: you will feel bad, sometimes really bad, if you don’t go along.

But please remember that this is a sacrifice. Part of that sacrifice might be that you have to feel bad about not doing what your group is doing. But we have to do this to save lives.

Read the whole story
kemayo
103 days ago
reply
St Louis, MO
Share this story
Delete

The Obituaries of Republicans Who Opposed Nixon’s Impeachment

1 Share

Ryan Goodman, Just Security:

In that summer of 1974, seven Republicans joined the Democrats to vote for at least one article of impeachment, including Toni Railsback (Ill.), Hamilton Fish Jr. (N.Y.), Lawrence J. Hogan (Md.), M. Caldwell Butler (Va.), William S. Cohen (Maine), Harold V. Froehlich (Wis.), and Robert McClory (Ill.)

Ten Republicans voted against all three articles of impeachment: Edward Hutchinson (Mich.), David Dennis (Ind.), Delbert Latta (Ohio), Trent Lott (Miss.), Joseph Maraziti (N.J.), Wiley Mayne (Iowa), Carlos Moorhead (Calif.), Charles Sandman (N.J.), Henry Smith (N.Y.), and Charles Wiggins (Calif.).

Regardless of whether the congressmen voted for or against the articles of impeachment, their legacies were largely defined by this one moment. So much so that newspapers titled their obituaries with reference to this vote.

Regardless how Trump’s impeachment trial turns out, those Republicans who vote to acquit him — which may well be one and all of them — will forever be defined by that vote. To say that corruption is acceptable is itself a form of corruption.

My prediction: the most likely scenario is that the entire Republican Senate caucus votes unanimously to acquit. But the nature of Trump’s mob-style rule over the Republican Party is such that no dissent is allowed. None. If any Republicans stand up to Trump — even just a handful — the odds increase significantly that the whole dam will burst.

Read the whole story
kemayo
196 days ago
reply
St Louis, MO
Share this story
Delete

Hi, I was wondering if you know of amy games tonally similar to the WoD games, but with a less clunky rules and dice system? My players aren't huge fans of the dice pools and there is so much content that I have been struggling to digest any edition of the games to run it as well as I do 5e D&D, but 5e doesn't really suit the game I have planned. Thanks bunches for having such a great blog btw

1 Share

It really depends on what “tonally similar to the WoD” means to you – the game line is not particularly known for its tonal consistency! Hunter-style monster-of-the-week procedurals call for a very different approach from Promethean’s magical realist road-trip gothic, and neither is anything like the overwrought superheroes-with-fangs nonsense that old-school Vampire brings to the table.

So, let’s cover a few bases:

  • If you’re looking for something like the brooding political soap opera that many old-school World of Darkness games were advertised as (never mind whether the mechanics actually had anything interesting to say about that style of play!), and assuming you’ve no objections to new-school RPGs where the players and the GM share narrative authority, you might have a look at Urban Shadows.

  • If the “formerly human weirdos exploring surreal otherworlds” strand of the WoD is more your speed – or maybe if your players are just big fans of Pyre – you could check out Afterlife: Wandering Souls. It’s very artsy, so fair warning if talking about your feelings isn’t your group’s idea of a good time.

  • If you’re into the Dark Ages strand of the WoD, the self-described “Castlevaniapunk” milieu of Miserable Secrets may be up your alley; I won’t promise that you’ll find its playing-card-based mechanics less clunky than Storyteller-style dice pools, but at the very least it’ll be a different clunky. It’s also good for emulating Vampire Hunter D, if you’re into that sort of thing.

  • If your ideal WoD is captured by the franchise’s brief ventures into film noir territory, definitely check out City of Mist. It has shades of the old WoD’s superhero goofiness, too, wrapped up in a remarkably robust set of mechanics for running low-key investigative procedurals that just happen to sometimes involve fistfighting God.

  • If you’re after a system that’s specifically adaptable for running a game in the vein of Mage, the Fate Accelerated Edition version of the licensed Dresden Files RPG isn’t a bad place to start. (Note that there’s also a Fate Core version, which is less well suited for this purpose.) I’m admittedly not a big Jim Butcher fan, and the rulebook’s tone kind of annoys me, but you can just lift the rules easily enough.

  • Finally, if you just want to run a vampire coffee shop AU or something – which, let’s be honest, is what many WoD games end up turning into at the table – there’s Die For You.

Does any of that cover what you’re looking for, or did you have something more specific in mind?

Read the whole story
kemayo
196 days ago
reply
St Louis, MO
Share this story
Delete
Next Page of Stories