Headline: “Hospital ER reports 161 percent spike in visits involving electric scooters.”

Between June and September 2017, physicians at University of Utah Health’s emergency room treated eight patients injured by scooters, although each of those were probably people’s personal devices and not the electric fleet vehicles owned by companies such as Bird, Lime and Skip.

During the same period this year, that number had climbed to 21, according to Troy Madsen, a doctor who practices at the University of Utah Health’s Emergency Department.

So, an increase from 8 to 21.

“Most of the patients with these injuries specifically reported that they were riding an e-scooter or a rental scooter,” Madsen said, noting that they ranged in age from 20 to 50 years old and were often injured attempting to catch themselves in a fall. “Interestingly, more than 80 percent of the injuries this year happened between Aug. 15 and Sept. 15, which would correspond with the increasing popularity and availability of the e-scooters.”

The article notes that the increase in injuries is related to the increase in ridership but makes no mention of how much the ridership has increased. It also makes no attempt to quantify what the rate of injury is per rider or per ride.

In July it was estimated than as many as 1000 new scooters were dropped on SLC. We don’t know if there have been more since then, or what the use rate of the scooters is, but it’s safe to say that total scooter use is up by far more than 161% from what it was before these services were available.

In other words, the rate of injury is probably significantly down from what it was before scooter rental companies came in. This is the opposite impression from what the article presents by simply excluding any numbers about the increase in use or what at what estimated rate riders are being injured. It only uses the increase in ridership to connect the new injuries to the introduction of scooter share services.

It’s well documented that for bicycles and pedestrians that in urban areas there is “safety in numbers.” The default assumption here should be that the greater the number of people riding scooters the lower the injury and fatality rate. This is left out, and because scooters are “new” the article uses a benign and potentially positive statistic to increase potential riders fears.

How to terrify people about scooters. was originally published in Bad Data on Medium, where people are continuing the conversation by highlighting and responding to this story.

There’s quite a few tutorials out there for using Vue.js and Electron but they all seem to require a huge amount of effort and boiler generation to get started.

In vue-cli 3 the need for boiler generation has been greatly reduced and the entire developer workflow is much simpler. I sat down to greenfield what it would be like to integrate this simpler setup into Electron and was pleasantly surprised.

Let’s get started.

Now that we’ve got Electron and Vue.js setup, we’ll need a JavaScript file that initializes the Electron app.

As you can see, there’s a development mode that loads the page from the webpack development server and a production version that uses the static assets generated by webpack.

First, let’s get the dev server up and running by adding a script to package.json.

You can adjust the sleep command based on how long it typically takes to startup webpack in the vue-cli-service.

npm run dev

Your site will pop up now and you get all the development environment goodies that Vue.js and webpack have to offer.

For the “production” build we need a little more. By default webpack will use relative URLs for all the static assets. This is no good for Electron, which will need full file paths instead.

In the old vue-cli 2 days, boiler generators would spit out a bunch of config files be like “have fun maintaining these!” Today, with vue-cli 3, there’s a programmable way to mutate webpack config options using a vue.config.js file and it’s wonderful.

That’s about it. You can test this build out pretty easily by just running the vue-cli build and Electron.

npm run build
electron app.js

Now you’re ready to build the final Electron app in whatever builder you choose (there’s like half a dozen of them).

All this code is up on GitHub as well. If you have any suggestions or improvements got ahead and log issues or pull requests in that repo.

It’s best not to consider sweet potatoes as you would other potatoes.

When I’m looking at a Yukon, Gold, Red or Fingerling potato I think about all the different ways I can fry and crisp it, but none of that works too well with Sweet Potatoes.

I’ve tried all manor of sweet potato fries and hash browns but they always end up a little flat or lame. Look closely at the crispy sweet potato fries in your favorite restaurant, you’ll notice they are coated in a dry flour before being fried, a trick I’m not too eager to replicate in my own kitchen.

Sweet Potatoes land in farm boxes most of the year but rarely in the summer which is fine as their sweet and savory character pair poorly with the warm days of summer.

The best way to pull out the sweet caramel notes of the sweet potato is to roast them. Wash them first if they are quite dirty, as to not fill your home with smell of the dirt burning in the oven, but if they come relatively clean there’s no need to wash as the skin will be eventually be discarded.

As sweet potatoes roast moisture is released. To help this process along and allow the core to heat more evenly with the rest of the potato its best to pierce it all over prior to roasting. You can use a fork if it’s sharp and deep enough but these days I just use the end of a chefs knife to penetrate about a third of the way through. These cuts should be about an inch apart around the entire surface of the sweet potato.

When the roast is finished you’ll see a discharge that burns after leaking onto the surface of the roasting pan. If you cut off the tips of the sweet potato this discharge will come out the end, if you don’t you can’t predict where this will happen and the process could split the potato prematurely and make it roast unevenly.

Coating a sweet potato in fat before roasting aids in the carmelization of sugars that come to the surface. I use ghee as it won’t burn easily and the flavor won’t conflict with butter I add after the roast. Roasting in ghee fills your kitchen with a pleasant buttered caramel smoke.

There’s no exact roasting time and temperature for sweet potatoes as each one varies so widely in size and shape. Some are bulbous and round while others are long and skinny. Larger potatoes I roast at 350f for at least 80 minutes while longer ones I roast at 400f for an hour. The surface should be dark but not black, once the surface blackens the char extends well under the surface and only the core will be edible.

After removing them from the oven let them cool for a few minutes but not all the way. I usually wear a pair of gloves for the next part so that I can work with them while they are still too hot for my bare hands.

With a knife in one hand pull the skin from the soft flesh and place the flesh in a bowl and discard the skin. While still hot melt in a good grass-fed butter. I use Kerrygold butter and the bright yellow makes the final result intensely orange.

Now it’s time to add spices. Any number of pumpkin spices will do. These rich mashed sweet potatoes are great with cinnamon, all spice, nutmeg, even curry. But my personal favorite is cardamom. In fact, I stopped adding other spices and just grind up a few cardamom pods. There seems to be no amount of cardamom that is too much for them to handle. I add one or two when serving them as a large portion and 7 or 8 when I want to smear the sweet potato across a plate so that food can be dipped in it like you would a demi-glace.

Cardamom Sweet Potato Summary

• Wash if noticeably dirty.
• Pierce the skin all over.
• Cover in fat.
• Roast at 350f–400f for 60–120 minutes depending on size and shape.
• Cool for a few minutes.
• Pull flesh from skin.
• Mix & melt butter into the flesh until it’s a consistent paste.
• Crack a few cardamom pods, pull out the seed, grind in a mortar and pestle, and add it the puree.

* Wash if noticably dirty.
* Pierce the skin all over.
* Cover in fat.
* Roast at 350–400 for 60–120 minutes depending on size and shape.
* Cool for a few minutes.
* Pull flesh from skin.
* Mix & melt butter into the flesh until its a consistent paste.
* Crack a few cardamom pods, pull out the seed ,grind it in a mortar and pestle, and add it the puree.

The more I live with async/await the more I discover new patterns and leave behind many old ones.

One constraint of working with async/await is that we only have a single return value from async functions. In the old callback world, you could pass more than one success object to the callback.

In addition to multiple callback results, you also had the option of returning a stream from your function (while still accepting a callback) which allowed you to do hybrid APIs that accepted steam input/output in addition to function parameters and callbacks.

I used this heavily in request. The goal of request was always to reduce the amount of typing you had to do in order to use HTTP. But even as flexible as this API became, there was some common boilerplate you can find almost everywhere people use request.

request(url, {json: true}, (err, resp, body) => {
  if (err) return cb(err)
  if (resp.statusCode !== 200) return cb(new JSONError(body))
  // success!
  console.log(body)
})

In practice, I tend to write small functions on top of request to handle this boilerplate. But as I started taking async/await for granted these constraints began to weigh on me more and more. Eventually, I started thinking about an alternative approach.

Constraints instead of features.

request implements many, many, features which you enable with different input options. When enabled, some of these features also impose constraints (enabling JSON decoding means non-JSON responses will fail) but these features are so general purpose that the constraints can’t expand enough to what you normally want (enabling JSON decoding DOES NOT impose that the status code must be 200).

When I wrote request I had already spent a lot of time with HTTP. I had done a lot in Python and eventually worked on Node.js Core HTTP adding features that also impacted request. request has always been an HTTP client from the perspective of someone who knows HTTP. But after 8 years of using request I have a much better idea of what a better pattern is for everyday use.

One big shift in my thinking is that the client shouldn’t offer features, it should offer constraints. I want to tell the client what is acceptable and build a single narrow path to success the client can impose without any other code on my part.

This fits well with the constraints of async/await. The more we constrain the success path the easier it is to get to a single return value and the closer that return value is to what the user wants it to be.

Introducing bent

let request = bent()
let response = await request(url)

This looks like nothing, but it’s actually already quite constrained by bent’s defaults. The method is GET, the status code must be 200, the return value is the response object (which is also a stream). But let’s do a bit more.

let api = bent('https://api.site.com/v1', 'json')
let obj = await api('/entry/point.json')

This is something I’m surprised I’ve never seen in HTTP clients given how common it is for a client to only operate on a single API service in a given code file. With bent, we create an async function prepared just for this API service, which is a JSON service at a base URL. The return values are now decoded JSON, any other response will generate an error.

Maybe there’s already a fancy computer science term for “function that returns an async function” but that’s not the part of this pattern that interests me. I’m much more interested in moving towards APIs that ask for “what is allowed” rather than just “what do you want to add.”

let put = bent('PUT', 'https://api.site.com/v1', 201)
await put('/upload', Buffer.from('example'))

This function will also accept a stream.

await put('/upload', fs.createReadStream('./file.txt'))

Another interesting thing about async/await is that we get to normalize input values (Buffer, JSON, or Stream). With callbacks you had an incentive to use the pipe interface when working with streams because it could often get you out of also requiring a callback. With async/await there’s no such benefit. In fact, you want the return value to remain the same between different input types so stream just becomes another parameter.

P.S. Like all the modules I write now, there’s 100% code coverage and automated releases w/ semantic-release. While this module is new, it’s actually pretty solid and on good footing 😀

One thing you see often are rounded avatar buttons. These are easy to add to your own app when the service, like Twitter, present images people already expect to be rounded.

But other login services, like Facebook, may not be giving an image that easily round-able or centered around the user’s face. Enter: <compretend-img>, an HTML Element powered by machine learning.

Using facial detection, we can take almost any image a user gives us and create a perfect avatar.

I’ve put together a great Glitch tutorial, but I’ll also spell out the basics here.

1. <script> include the element.

Add this to the <head> section of your website.

<script src="https://cdn.jsdelivr.net/npm/compretend-img/dist/compretend-img.min.js"></script>

2. Add style for image.

Add the following CSS to the <head> section of your website for a 50px avatar.

compretend-img img {
  width: 50px;
  border-radius: 50px;
}

Note that there’s an image that loads within the <compretend-img> element.

3. Add a <compretend-img> element that crops faces.

Add the following HTML to your webpage.

<compretend-img crop="faces" width="100" margin="25" scaled="2" src="IMAGEURL">
</compretend-img>

Let’s talk about the properties we’re setting here.

• crop=”faces” Tells compretend to crop the image around facial detections
• width=”100" Tells compretend that the target width is 100 pixels.
• margin=”25" Tells compretend to add a 25 pixel margin around the detection cropping. This is so that when we round the image it doesn’t cut out the actual face.
• scaled=”2" Tells compretend to scale the image to 2x the target width. This is so that the image still looks good on high resolution devices like iPhones.

And that’s it!

You can check out the project on GitHub and sign up to learn about more stuff we’re doing at Compretend.

Big notable projects like Linux and Node.js have comforting long term support cycles that ensure Enterprises and other production users can continue to use a release for years without migrating to a new one.

The ecosystems built on top of these projects tend to try and follow a similar cycle. They keep old releases in their CI configuration and block PR’s from being merged if they don’t work on older release lines.

I’m just going to come out and say it, this is a destructive practice for smaller projects.

1. This isn’t how LTS is done in big projects.

You can send a pull request to Node.js today and get it merged without a single test on an old release line. In fact, it is only merged to the CURRENT release line and your review will likely only mention that release line.

The LTS Working Group periodically takes recent changes and prepares a backport to an old release line. Who is the LTS Working Group? Vendors.

More specifically, it’s a collection of contributors that care about Long Term Support. All of them happen to work at companies with a strategic interest in Enterprise Node.js users (Google, IBM, NodeSource, Nearform).

LTS didn’t exist in Node.js until the Foundation brought these vendors into the process. It wouldn’t still exist without their involvement, and we’re all better for it.

You, in your GitHub project, probably don’t have this kind of investment from vendors.

You, in your GitHub project, probably don’t have the time or resources to manage more than one release line of development.

And yet, you’re putting up more of a barrier to contributions than big projects with lots of contributors and investment. Stop.

2. You’ll never get LTS contributions unless you stop providing them for free.

Contributors to projects tend to be users of newer releases. This is partly because people that are willing to dig into the internals of a module they use are closer to the bleeding edge.

But another reason we don’t get as many users of older releases contributing is that we aren’t really asking them to. If they can’t use anything new, what is their incentive to contribute?

If you cut support for an older release people will show up to complain, but how many of them are willing to contribute? How many of them have ever even considered it necessary?

We’ve cultivated a class of passive open source consumers who are disconnected from the realities facing the projects they depend on. If we are open to contributions to continue to support them, then we should also require that they step up to do this work.

3. You’re burning out maintainers.

I’ve talked to a lot of open source developers about burnout. A common theme is that they feel like there are far too many expectations on too few people.

In particular, people feel an obligation to do work they don’t even personally care about or are connected to.

If people who care about long term support are part of your contributorship, you can empathize with their needs and work with them as a peer. But because so few of the users of old releases are involved in the development process, maintainers see them as freeloaders with unreasonable demands and expectations.

The fastest path to fix this is to simply stop supporting use cases for which nobody concerned with that case is willing to contribute. If you don’t want the burden of these expectations burning out contributors, just stop considering these requirements until people are willing to step in and do the work.

4. Enterprise does not deserve a free ride.

There’s a lot of money coming from Enterprise into open source. Many companies are willing and able to put resources in when necessary.

The reason they haven’t spent nearly as much time with smaller projects is because they just don’t need to, these projects are already bending over backwards to support them for free.

These companies have no problem pitching in when they have no other choice. If Enterprise companies depend on your software, there’s a vendor selling to them that will do whatever it takes to make them happy.

Saying you won’t do the work to support an old release isn’t saying “I don’t care about you being a user.” Instead, you’re saying that there are two ways they can be a user.

• Upgrade.
• Help me keep it running for people who won’t upgrade.

Nobody is entitled to use software they don’t pay for without any effort whatsoever on their part.