Rolandt

Having spent most of yet another weekend messing around with various Jupyter related projects, not least OpenJALE (still a WIP), an extensions guide for my Open Jupyter Authoring and Learning Environment, frustration at one of the things I was linking to breaking in a MyBinder launch caused me to tweet in frustration.

This morning, seeing a collection of liked tweets noting how much I apparently hate the whole Jupyter project, I checked back to see what I said.

Stupidly, I then deleted the tweet.

Crap.

What the tweet said, and this isn’t true, was how much I hated Jupyter every time I encountered it, showing a screenshot of a failed MyBinder launch breaking on a JupyterLab dependency.

The break was in a launch of one of my own repos, I might add, where I had been trying to install a JupyterLab extension to provide a launcher shortcut to a jupyter-server-proxy wrapped application.

For those of you who don’t know, jupyter-server-proxy is a really, really useful package that lets you start up and access web applications running via a Jupyter notebook server. (See some examples here, from which the following list is taken.)

The jupyter-server-proxy idea is useful in several respects:

• a container running a Jupyter server and jupyter-server-proxy only needs to expose only a single http port (the one that the notebook / JupyterLab is accessed via). All other applications can be proxied along the same path using the same port;
• many simple web applications applications do not have any authentication; proxying an application behind a Jupyter server means you can make use of the notebook server authenticator to provide a challenge before providing access to the application;
• the jupyter-server-proxy will start an application when it is first requested, so applications do not need to be started when the environment is started; applciations are only started when requested. If a repeated request is made for an application that has already been started, the user will be taken directly to it.

The extension I was loading provided an icon in the JupyterLab launcher so the app could be accessed from that environment as well as from the classic notebook environment.

I don’t use JupyterLab very much, preferring the classic notebook UI for a lot of reasons that I properly need to document, but I was trying to play into that space for folk who do use it.

JupyterLab itself, the next generation Jupyter interface, is a brilliant technology demonstrator, helping push the development of Jupyter server protocols and demonstratring their use.

And I hate it as a UI. (Again, I need to properly document why.)

And I get really frustrated about how over the years it has, and perhaps continues, to break numerous unrelated demos.

Until eighteen months or so, when work work started to suck all my time, I’d been posting an occasional Tracking Jupyter newsletter (archive), spending a chunk of time trying to keep track of novelty and emerging use cases in the Jupyterverse. Jupyter projects are far wider than the classic notebook and JupyterLab UI, and when viewed as part of a system offer a powerful framework for makeing arbitrary computing environments at scale available to multiple users. In many respects, the UI elements are the least interesting part, even if, as in my org, “Jupyter” tends to equate with “notebook”.

As part of the tracking effort, I’d scour Github repos for things folk were working on, trying to launch each one (each one) using MyBinder. (Some newsletter editions referenced upwards of fifty examples. Fifty. Each one;-) Some worked, some didn’t. Some I filed issues against, some PRs, some I just cloned and tried to get working as a quick personal test. Items I shared in the newsletter I’d pretty much always tried out and spent a bit of time familiarising myself with. These were not unqualified link shares.

One of the blockers to getting things working in MyBinder was missing operating system or Python package dependencies. In many cases, if a Python package is in a repo on Github you can just paste the repo URL into MyBinder and the package will install correctly. In some cases, it doesn’t and the fix is adding one or two really simple text files (requirements.txt for Python packages, apt.txt for Linux packages) to the repo that install any essential requirements.

That’s an easy fix, and quick to do if you fork the repo, add the files, and launch MyBinder from your fork.

But perhaps the most frustrating blocker, and one I encountered on numerous occasions, and still do, was a MyBinder launch fail caused by a JupyerLab dependency mismatch.

Now I know, and appreciate, that JupyterLab is a very live project. And while I personally don’t get on with the UI (did I say that already?!) I do appreciate the effort that goes into it, at least in the sense that I see it as a demonstrator and driver of Jupyter server protocols and the core Jupyter (notebook) server itself, which can lead to many non-JupyterLab related developments.

(For example, the move to the new Jupyter server from the original notebook server is very powerful, not least in terms of making it easier to launch arbitrary application containers via JupyterHub or Binderhub that can use the new server to send the necessary lifesigns and heartbeats back to the hub to keep the container running.)

My attacks against JupyterLab are not intended as ad hominem attacks or as disparaging to the developers; the work they do is incredible. They are a statement of my preferences about a particular user interface in the context of the impact it may have on uptake of the wider Jupyter project.

If I had encountered JupyterLab, rather than then classic notebook, eight years ago, I would not have thought it useful for the sorts of open online education I’m engaged with.

If things had started with JupyterLab, and not classic notebook, I’m not convinced that there would be the millions of notebooks there are now on Github.

I am happy to believe that the JupyterLab UI has gone through peak complexity in terms of first contact and that when it replaces the classic notebook to become the default UI it will not be overly hostile to users. But I remain to be convinced that it will be as relatively straightfoward for non-developers with a smattering of basic HTML and Javascript skills to develop for as the classic notebook UI was, and is.

I am reminded of the earlier days of Amazon, Google, Twitter et al, when their APIs were easy to use, didn’t require keys and authentication etc. With a few Yahoo Pipes you could build all many of things armed with nothing other than a few simple URL patterns and a bit of creative thinking. Then the simple APIs got complex, required various sorts of auth, and the play for anyone other than seasoned developers with complex toolchains stopped.

So: failed builds. Over the years, many of the failed builds I have encountered, many of the failed demos from repos labeled with a MyBinder button, have resulted from mismatches, somewhere, in JupyterLab versions.

The complexity of JupyterLab (from my perspective, as a non-developer, and no familiarity with node or typescript) means I would struggle to know if, how or what dependencies to fix things, even I had the time to.

But more pressing is the effect of JupyterLab dependencies and package conflicts breaking things. (Pinning dependencies doesn’t necessarily help either. MyBinder puts in place recent packages in the core environment it builds, so users are dependent on it in particular ways. As far as simplicity of use goes (which I take as a key aspiration for MyBinder), pinned requirements is just way too complicated for most people anyway. But the bigger problem is, there are certain things (like the core Jupyter environment MyBinder provides) that you may not be able to pin against.)

Now I may be misreading the problem, but it’s based on seeing literally hundreds of error messages over the years that suggest JupyterLab package conflicts cause MyBinder build fails.

And this is a probem. Because if you are trying to lobby for uptake of Jupyter related technologies, and you give folk a link for something you tried yesterday that worked, and they try it today and it fails because of a next generation user interface package conflict that has nothing to do with the classic notebook demonstration I’m trying to share, then you may have lost your one chance (at least for the foreseeable future) to persuade that person to take that Jupyter step.

So, as ever, reflective writing has helped me refine my own position. There are three things that I have issues with relating JupyterLab:

• the complexity of the UI (but this seems to be being simplified as the UI matures away from peak developer scaffolding);
• the complexity of the development environment (I keep trying to make sense of JupyterLab extensions but have to keep on giving up; IANAWD);
• (the new realisation): the side effects in breaking unrelated demos launched via MyBinder.

(Another issue I have had over the years was the very long, slow build time that resulted from JupyterLab related installs in MyBinder builds. This has improved a lot over recent versions of JupyterLab (again, the scaffolding seems to be being taken down) but I think it has also caused a lot of harm in the meantime in terms of the way it has impacted trying to demonstrate Jupyter notebooks or their application that themselves have no direct JupyterLab requirement.)

Now, it might be that this is a side effect of how MyBinder works, (and I don’t mean to attack or disparage the efforts of the MyBinder team), and may not be a JupyterLab issue per se, but it does impact on the Jupyter user experience.

At the end of the day, at the end pretty much of every day for the last seven years, there’s rarely been a day where I haven’t spent some time, if not many hours, using Jupyter services.

So to be clear, I do not hate Jupyter (that was a typo). But I do have real issues with JupyterLab as the default UI which caters more to the development aesthetic than the narrative computational notebook reader, on the way it can impact negatively on my Jupyter user experience, and on the way I believe it makes it harder for folk to engage with at the level of contributing their own extensions.

PS as another reflection, I know that I do myself reputational harm, may cause reputational harm, and may offend individuals via my tweets and blog posts. First, the account is me, but it’s also an angry-frustrated-by-tech-but-hopeful-for-it persona. Second, I often admit ignorance, my opinions change and I do try to correct errors of fact. Third, attacks are never intended as ad hominem attacks, they are typically against process in context, how “the system” has led to, allowed, enabled or forced certain sorts of behaviour or action. (If I say “why would you do that?” the you is a generic “anyone” acting in that particular context.) And fourth, my own tweets and blog posts typically have little direct impact that I can see in terms of RTs, likes or comments. On the rare occasions they do, they often result in moments of reflection, as per this blog post…

Get the book.

Once when she was a girl, Chloé’s friend Denise urged her to pull her wavy hair back into as pony tail. Chloé thought this uncomfortable. Denise, more fashionable, argued that discomfort was that lot of women: “you look like a Jew.” I doubt poor Denise knew that Chloé was, in fact, a Jew. Chloé didn’t say anything.

This is a meditation on contemporary racism in France, mediated by the memories of the Occupation. Those memories are fascinating.

Here’s a fun interactive by Duc-Quang Nguyen. Upload an image and get back a transformed visual that uses dots, lines, or ascii. Use the menu options to easily change resolution, colors, and shapes.

It’s a combination of Georgios Karamanis’s code and Elana Levin Schtulberg’s experiment of the same ilk.

Tags: Duc-Quang Nguyen, pixels, R

This is a really bad article about a really interesting topic. The Ikhwân al-Safâ’ is a set of notes - an introductory encyclopedia, really - on science and medicine authored and distributed in the tenth century CE. "It consists of extremely heterogeneous materials, reworked to represent the whole educational training intended for an élite," writes Wolfgang Schwarz in his summary, and so you can see how this would be one of the earliest examples of distance education. I'm rather less than enthusiatic about the Stanford Encyclopedia article because it takes a long time to get around to even telling readers what the Ikhwân al-Safâ’ is and what it contains, first spending eleven long paragraphs discussing disputes about authorship and another section in deep discussion about its ideological commitments. I recommend starting in section 4 and then jumping to section 6 and only then (if you're truly interested) reading the author's vast redactive scholarship. Image: Orientalia.

Have you ever wondered why you have to consent to terms required by the websites of the world, rather than the other way around? Or why you have no record of what you have accepted or agreed to?

Blame the cookie.

Have you wondered why you have no more privacy on the Web than what other parties grant you (which is none at all), and that you can only opt in or out of choices that others provide—while the only controls you have over your privacy are to skulk around like a criminal (thank you, Edward Snowden and Russell Brand, for that analogy) or to stay offline completely?

Blame the cookie.

And have you paused to wonder why Europe’s GDPR regards you as a mere “data subject” while assuming that the only parties qualified to be “data controllers” and “data processors” are the sites and services of the world, leaving you with little more agency than those sites and services allow, or provide you?

Blame the cookie.

Or why California’s CCPA regards you as a mere “consumer” (not a producer, much less a complete human being), and only gives you the right to ask the sites and services of the world to give back data they have gathered about you, or not to “sell” that personal data, whatever the hell that means?

Blame the cookie.

There are more examples, but you get the point: this situation has become so established that it’s hard to imagine any other way for the Web to operate.

Now here’s another point: it didn’t have to be that way.

The World Wide Web that Tim Berners-Lee invented didn’t have cookies. It also didn’t have websites. It had pages one could publish or read, at any distance across the Internet.

This original Web was simple and peer-to-peer. It was meant to be personal as well, meaning an individual could publish with a server or read with a browser. One could also write pages easily with an HTML editor, which was also easy to invent and deploy.

It should help to recall that the Apache Web server, which has published most of the world’s Web pages across most the time the Web has been around, was meant originally to work as a personal server. That’s because the original design assumption was that anyone, from individuals to large enterprises, could have a server of their own, and publish whatever they wanted on it. The same went for people reading pages on the Web.

Back in the 90s my own website, searls.com, ran on a box under my desk. It could do that because, even though my connection was just dial-up speed, it was on full time over its own static IP address, which I easily rented from my ISP. In fact, that I had sixteen of those addresses, so I could operate another server in my office for storing and transferring articles and columns I wrote to Linux Journal. Every night a cron utility would push what I wrote to the magazine itself. Both servers ran Apache. And none of this was especially geeky. (I’m not a programmer and the only code I know is Morse.)

My point here is that the Web back then was still peer-to-peer and welcoming to individuals who wished to operate at full agency. It even stayed that way through the Age of Blogs in the early ’00s.

But gradually a poison disabled personal agency. That poison was the cookie.

Technically a cookie is a token—a string of text—left by one computer program with another, to help the two remember each other. These are used for many purposes in computing.

But computing for the Web got a special kind of cookie called the HTTP cookie. This, Wikipedia says (at that link)

…is a small piece of data stored on the user‘s computer by the web browser while browsing a website. Cookies were designed to be a reliable mechanism for websites to remember stateful information (such as items added in the shopping cart in an online store) or to record the user’s browsing activity (including clicking particular buttons, logging in, or recording which pages were visited in the past). They can also be used to remember pieces of information that the user previously entered into form fields, such as names, addresses, passwords, and payment card numbers.

It also says,

Cookies perform essential functions in the modern web. Perhaps most importantly, authentication cookies are the most common method used by web servers to know whether the user is logged in or not, and which account they are logged in with.

This, however, was not the original idea, which Lou Montulli came up with in 1994. Lou’s idea was just for a server to remember the last state of a browser’s interaction with it. But that one move—a server putting a cookie inside every visiting browser—crossed a privacy threshold: a personal boundary that should have been clear from the start but was not.

Once that boundary was crossed, and the number and variety of cookies increased, a snowball started rolling, and whatever chance we had to protect our privacy behind that boundary, was lost.

Today that snowball is so large that nearly all personal agency on the Web happens within the separate silos of every website, and compromised by whatever countless cookies and other tracking methods are used to keep track of, and to follow, the individual.

This is why most of the great stuff you can do on the Web is by grace of Google, Apple, Facebook, Amazon, Twitter, WordPress and countless others, including those third parties.

Bruce Schneier calls this a feudal system:

Some of us have pledged our allegiance to Google: We have Gmail accounts, we use Google Calendar and Google Docs, and we have Android phones. Others have pledged allegiance to Apple: We have Macintosh laptops, iPhones, and iPads; and we let iCloud automatically synchronize and back up everything. Still others of us let Microsoft do it all. Or we buy our music and e-books from Amazon, which keeps records of what we own and allows downloading to a Kindle, computer, or phone. Some of us have pretty much abandoned e-mail altogether … for Facebook.

These vendors are becoming our feudal lords, and we are becoming their vassals.

Bruce wrote that in 2012, about the time we invested hope in Do Not Track, which was designed as a polite request one could turn on in a browser, and servers could obey.

Alas, the tracking-based online advertising business and its dependents in publishing dismissed Do Not Track with contempt.

Starting in 2013, we serfs fought back, by the hundreds of millions, blocking ads and tracking: the biggest boycott in world history. This, however, did nothing to stop what Shoshana Zuboff calls Surveillance Capitalism and Brett Frischmann and Evan Selinger call Re-engineering Humanity.

Today our poisoned minds can hardly imagine having native capacities of our own that can operate at scale across all the world’s websites and services. To have that ability would also be at odds with the methods and imperatives of personally targeted advertising, which requires cookies and other tracking methods. One of those imperatives is making money: $Trillions of it.

The business itself (aka adtech) is extremely complex and deeply corrupt: filled with fraud, botnets and malware. Most of the money spent on adtech also goes to intermediaries and not to the media you (as they like to say) consume. It’s a freaking fecosystem, and every participant’s dependence on it is extreme.

Take, for example, Vizio TVs. As Samuel Axon puts it in Ars Technica, Vizio TV buyers are becoming the product Vizio sells, not just its customers Vizio’s ads, streaming, and data business grew 133 percent year over year.

Without cookies and the cookie-like trackers by which Vizio and its third parties can target customers directly, that business wouldn’t be there.

As a measure of how far this poisoning has gone, dig this: FouAnalytics‘ PageXray says the Ars Technica story above comes to your browser with all this spyware you don’t ask for or expect when you click on that link:

Adserver Requests: 786

Tracking Requests: 532

Other Requests: 112

I’m also betting that nobody reporting for a Condé Nast publication will touch that third rail, which I have been challenging journalists to do in 139 posts, essays, columns and articles, starting in 2008.

(Please prove me wrong, @SamuelAxon—or any reporter other than Farhad Manjoo, who so far is the only journalist from a major publication I know to have bitten the robotic hand that feeds them. I also note that the hand in his case is The New York Times‘, and that it has backed off a great deal in the amount of tracking it does. Hats off for that.)

At this stage of the Web’s moral devolution, it is nearly impossible to think outside the cookie-based fecosystem. If it was, we would get back the agency we lost, and the regulations we’re writing would respect and encourage that agency as well.

But that’s not happening, in spite of all the positive privacy moves Apple, Brave, Mozilla, Consumer Reports, the EFF and others are making.

My hat’s off to all of them, but let’s face it: the poisoning is too far advanced. After fighting it for more than 22 years (dating from publishing The Cluetrain Manifesto in 1999), I’m moving on.

To here.

My therapist and I were talking about relationships—romantic and otherwise—and she offhandedly mentioned that an important part of the bedrock of relationships is sharing common interests.

This came as something of a surprise to me, and that fact helped explain why I got flummoxed trying to describe the nature of what I quest to Bumble: it never occurred to me that it might be as simple as revealing what it is I like to do, what makes me happy.

(As a side note: if there were as many beach bonfires on PEI as women who list beach bonfires among their favourite things to do in their online dating profiles, there would be a lot more beach bonfires. I have never been to a beach bonfire.)

This revelation led my therapist to ask me to describe what I would do if presented with an unfettered day.

My answer: I would be in a European capital city; there would be a lot of eating; and wandering about so as to cultivate happenstance; the public library would be visited, perhaps an art gallery or a museum; multiple book, magazine and stationery shops; stops for coffee and reading the newspaper; an open-air cinema to close the day. No bonfires.

This, in turn, reminded me that public libraries exist, something I’d all but forgotten (contact tracing at the library entrance, understandable given COVID, rains on a fundamental conceit of public libraries: free and open anonymous access).

So I decided to unforget the public library, and ordered up a copy of Needing to Know for Sure: A CBT-Based Guide to Overcoming Compulsive Checking and Reassurance Seeking, a book possibly recommended to me by my other therapist (she recommended the authors; I guessed at the book).

I picked up the book this week, my first library loan in many many months. It turned out to be one of those books the details of which didn’t scratch my particular itches, but the broad strokes of which were very helpful. Witness these section titles:

• Living in a World of Maybe and Good Enough
• Living Well Although Bad Things Happen and We All Die
• Without Uncertainty, Creativity is Lost
• Excitement and Anxiety are Related
• Certainty is a Feeling, Not a Fact
• Learning Mindful Acceptance of Discomfort

Writing those out, I’m thinking maybe it was the book recommended to me after all. At the very least, “Learning Mindful Acceptance of Discomfort” is a notion that will feed me for some time.

I returned the book this afternoon and, the library die now being cast, I went hog wild and borrowed four more:

• “You’re in the Wrong Bathroom!”: And 20 Other Myths and Misconceptions About Transgender and Gender-Nonconforming People — to help me understand more about the context into which Olivia emerges.
• A Happy Life in an Open Relationship — I’ve never been able to grok open relationships, and don’t find myself drawn to the notion, so an opportunity to learn, unencumbered by an actual relationship as I am.
• The End of Normal: A Wife’s Anguish, A Widow’s New Life — an autobiographical book written by Bernie Madoff’s widowed daughter-in-law.
• Tools of Titans — although The 4 Hour Workweek was an important and helpful book, the expanded Tim Ferris cinematic universe that has followed has been of little interest; borrowing this hefty tome is my attempt to put that to a conclusive test.

In the meantime, what with all the bonfire-loving Island women seeking bonfire-loving soulmates, I’ve decided to try to get better at simply being single, and to that end, I’ve booked myself dinner and a room for one at the Inn at Bay Fortune for the end of the month. I’ve no idea how a romantic seaside dinner for one actually works. But I’ll find out.

I've been puzzling over this one for a couple of years now, and I finally figured out the solution.

The Vega-Lite charting library can generate bar charts using a JSON definition that looks like this:

{
  "$schema": "https://vega.github.io/schema/vega-lite/v5.json",
  "description": "A simple bar chart with embedded data.",
  "data": {
    "values": [
      {"bar_label": "startups", "bar_quantity": 157},
      {"bar_label": "webdevelopment", "bar_quantity": 166},
      {"bar_label": "quora", "bar_quantity": 1003},
      {"bar_label": "conferences", "bar_quantity": 152},
      {"bar_label": "datasette", "bar_quantity": 111}
    ]
  },
  "mark": "bar",
  "encoding": {
    "x": {
      "field": "bar_label",
      "title": "Label",
      "type": "nominal",
      "axis": {"labelAngle": 90}
    },
    "y": {"field": "bar_quantity", "title": "Quantity", "type": "quantitative"}
  }
}

There's just one catch: Vega-Lite defaults to sorting the bars alphabetically by their nominal label.

But sometimes you might want to control that sort order - to have the order that the bars are displayed in directly reflect the order of the data that you passed in.

To do this, pass "sort": null as an option to the x encoding:

Open this example in the Vega Editor

Vega-Lite Sorting documentation.

I characterized my most recent post (Putting Personal Knowledge Management in Context) as potentially a grumpy old man rant. The triggering event was a side-by-side software review, Obsidian vs. Roam: Which PKM App is Right For You? – The Sweet Setup. My instant reaction was “PKM isn’t about apps” and thinking that it was will get you in trouble. I thought it might be helpful to explore that reaction and see where it might lead.

The review itself is a very well done comparison between the two apps in question. But it is based on an implicit assumption that is also flawed. Because the assumption is implicit, people aren’t likely to catch it and wonder later why they become dissatisfied with whatever choice they make. There is a clue lurking in one of the opening paragraphs:

It’s impossible to say “just use this one” when it comes to picking the right connected note-taking app for you. On the surface they may seem similar, but there are several important differences that stem from fundamentally different approaches to how your notes are stored and managed.

The author is acknowledging that they cannot, in fact, answer the question they have set before us. They then proceed to explore the question anyway because it’s an easy question to ask and answer and because we are accustomed to expecting questions to have neat answers. Worse, we only ask questions that we expect have answers. 

I expect this bothers me, in part, because the underlying topic is knowledge management. The underlying motivation for knowledge management, whether in organizations or for individuals, is dealing with questions that don’t have obvious answers. Or questions that provoke deeper questions. 

Asking questions has always been a high-risk behavior. Where will we end up if we continue to explore the PKM space as a practice for asking questions that don’t yet have answers?

The post PKM Isn’t About Apps appeared first on McGee's Musings.

mkalus shared this story from Michael Kalus.ca.

"Official" tasting notes and background information.

The Beans

A sweet and sour smell comes off of them, while the beans themselves look like they're made of milk chocolate with a consistent colour and texture.

Brewing Method AeroPress

I am following James Hoffman's "The Ultimate AeroPress Technique". 11 grams of coffee and 200 grams of water. Steep 2 minutes, then swirl and let settle for 30 seconds before fully pressing it through.

On the first sip I get a strong hit of dark chocolate, followed by some sweetness, which is quite pleasant, though the bitterness does linger a bit at the end.

As the coffee cools the bitterness takes a bit of a backseat and the sweetness comes more forward. This is quite nice.

Rating: 4.5/5

Brewing Method French Press

The French Press brings out the dark chocolate much more so, with the bitterness being unsurprisingly stronger than in the AeroPress.

It is a much bolder coffee and I am almost curious to see how it would pair with some milk. I suspect it would add more sweetness. Pleasant and I quite like it.

Rating: 4.6/5

This isn’t a recommendation. It’s more of a habit that I’ve acquired recently. If this makes its way to Hacker News and people think how could he, my only response will be 🤷, why not.

I’ve been building a thing, in JavaScript, an application sort of like things I’ve built in the past. With the same basic goal of making something useful. How I get to that goal is flexible. But it ends up being a lot of using boring technology, trying not to overthink the easy parts, trying to properly-think the hard parts, and so on. So there’s not that much to write home about that would surprise your usual React/Next.js/JavaScript engineer person.

But one thing that I do think is sort of unusual is: I’m vendoring a lot of stuff.

Vendoring, in the programming sense, means “copying the source code of another project into your project.” It’s in contrast to the practice of using dependencies, which would be adding another project’s name to your package.json file and having npm or yarn download and link it up for you.

Back in 2016, I wrote an article about optimistic and pessimistic versioning, which mentioned vendoring as the ‘most pessimistic’ approach, and that’s roughly true. Vendoring means that you aren’t going to get automatic bugfixes, or new bugs, from dependencies. It means that you don’t have to trust dependency authors at all.

The downsides of vendoring - no automatic updates, a bigger source tree, more code to maintain, it seems weird and unconventional - are probably pretty clear to JavaScripters, and most members of most language families. Languages like C did vendoring by default, in that people would copy header-only libraries into their projects. Go, for a while, was a little like that - you’d copy files in, whether automatically or manually. But nowadays Go modules (to my untrained eye) look a lot like the norms of other languages.

So what are the reasons for doing this? Here’s what’s on my mind.

I read dependencies anyway

I read a lot of other people’s code. I highly recommend it. One of my golden rules is that you shouldn’t blackbox things you don’t need to. I like to “use dependencies for efficiency, not ignorance.”

When I’m vendoring code - copying it into the project and making it pass my basic eslint & testing standards, I’ll do light rewrites and refactors of new code, allowing me to get a deeper understanding of how they work and where their limits lie.

Obviously, other people’s code is their code. I didn’t do 100% of the thinking that led to it - I’m probably doing 5% of it. But absorbing that bit into my mind, instead of seeing only the external API surface, pays dividends.

And sometimes, sure - I’ll read through a dependency, start refactoring, and realize that it’s going to be simpler to write it myself, or I should find another option. It doesn’t matter if something is a dependency or my code: when you ship a product, it’s all your responsibility.

You don’t really use most of your dependencies

Vendoring makes it very obvious that many dependencies have lots of surface area - API calls and methods - that you don’t use. This hooks into the debate about tiny modules (less surface area! less waste! way harder to maintain!), or big ones, but for this article, the point is that you can pare down dependencies into their ideal form in your application.

Dead code elimination helps! But it can only do so much, and the dead code still exists in your project. Even the most advanced DCE isn’t going to pare down methods of a class that you’re using. Only some DCE systems can handle CommonJS, and most work on the level of individual variables, not parts of those variables.

To go a step further, you can trim the test suite down to the API surface you use, run coverage, and comment out or remove the parts that are dead.

Old projects stabilize

Old projects might not be stable. They might have bugs - they usually do. In every issue tracker, there’s at least one multi-year bug that is so wicked that it might never go away.

But old projects have stabilized. They don’t change that often, and when they do the changes are minor. So the value that you got out of that fast release cycle two years ago doesn’t apply. And worse - you have a lot of old patterns that the project probably can’t remove! Do you want IE10 workarounds in your project? If you’re using a lot of third-party dependencies, you’re probably inheriting polyfills for stuff like Array.includes.

In my brief rewrites, I can pluck out old-fashioned polyfills for isArray or code that checks that JSON.parse really exists in this environment. In 2021, it does.

It’s sort of good for open source

This is a mixed bag. My vendored copy might float far away from the original, and contributing back the changes in full isn’t going to be useful. A lot of the changes that I make are going to be somewhat cosmetic or things like adding TypeScript support for things that didn’t have it.

But on the other hand, porting a fix from my vendored copy to the original is going to be pretty quick, and having dependencies in the source tree itself is an ideal scenario for fixing bugs in vendored code quickly.

Dependencies that are GPL’ed (there aren’t many, but the license still lingers) will get released when the thing is released, because the law requires it - though those changes won’t be especially exciting. Things that are MIT/BSD/ISC licensed will mostly get upstream fixes, for the good of the community.

Not everything

I don’t vendor React or Webpack or other large, incredibly complex dependencies. They’re going to change quickly and there’s little I can really contribute to those projects. I’m happy to keep lodash as a dependency for a few extremely battle-tested utilities. But for small to medium-sized dependencies, vendoring makes a lot of sense.

Technology is seeing a little return to complexity. Dreamweaver gave way to hand-coding websites, which is now leading into Webflow, which is a lot like Dreamweaver. Evernote give way to minimal Markdown notes, which are now becoming Notion, Coda, or Craft. Visual Studio was “disrupted” by Sublime Text and TextMate, which are now getting replaced by Visual Studio Code. JIRA was replaced by GitHub issues, which is getting outmoded by Linear. The pendulum swings back and forth, which isn’t a bad thing. Some of the reasons for the last pivot - from complexity to simplicity - have been solved. Webflow fills a need, and produces better output than Dreamweaver did. Notion is more accessible to people who don’t know Markdown. VS Code is very helpful. Excessively helpful. It’s fine.

The same problems will crop up. In structured editors like Notion, the tendency to overstructure is common. Usually you’ll see a lot of structure - a table of nested pages with types, very particular formatting, a well-chosen icon. And then, after putting the structure in place, the content arrived and didn’t fit it. The columns aren’t filled in, or are filled with heterogenous information. The structure is encoded, but doesn’t reflect reality or doesn’t reflect how people actually thought about the information.

Webflow has buttons to add effects. It’s easy to add effects. Effects will be added, because there’s a button to add them. Everything for the next few years will slowly fade in as you scroll. I don’t know why. Stripe did it.

Fancy tools aren’t bad. Professional authors use Microsoft Word and they have the absolute courage, the phenomenal self-control, to never fiddle with fonts. I, however, don’t. Give me iA Writer to save me from myself.

And simple tools make you think a little more. The notetaking tool I use isn’t very good at recommending links, so I retype names and things, manually, every time that I refer to them. Would it be better if it did great autocomplete? Would it be even better if I didn’t even have to link things, and it automatically associated similar topics?

I don’t think so. As Drucker said and is written on the back of all my Field Notes notebooks, “I’m not writing it down to remember it later, I’m writing it down to remember it now.” The friction of having to write, to structure thoughts in plain text, to remember the name of the person I need to reference on this page: that is the point. Frictionless note-taking produces notes, but it doesn’t - for me - produce memory.

The same goes for a lot of things. I use neovim to edit code like a grandpa, and I don’t use a file tree. There’s no “directory listing” in my editor. I hit ctrl-p and fzf helps me find the file by name. This is obviously not the future of coding: shouldn’t I be navigating the source tree in 3D like in Jurassic Park? Sure, but the names of things, their functionality, and how it all fits together should be things that exist in one’s mind, not just in a computer.

Source

I'm not sure exactly what is meant by "join" here, other than that "Automattic has hired key members of the CC Search team and will sponsor their contributions." This is at first blush a good thing, as development had stalled, as evidenced by this frozen GitHub repository. But does "join" mean "acquired" here? Will the company (WordPress, or Automattic, or whoever is in charge) continue to support (or allow) the search API, or does it become an exclusive WordPress feature? And, for that matter, why can't Creative Commons support what seems to me to be one of its most important services?

There's a classic though illegitimate move in persuasive writing, and it is this: if you want to discredit an idea, associate it with an obviously bad idea. That's what's happening in this article. The obviously bad idea is 'Zoom in a room,' where students "sit in a classroom, masked and socially distanced, with Chromebooks... while the teacher instructs remotely from home." The idea being discredited by association is the four-day school week. There's nothing inherently bad in this idea, especially if it is joined with a four-day work week generally. And support for it isn't based on hygiene theatre or any such thing, it's based on the idea that maybe we don't want to spend most of our lives in an institution, either as students or workers. 

There are many moving parts in this post, which is great, though it makes teasing them apart a challenge. It begins with a reference to Greg Lukianoff's principles for “the empowering of the American mind” on the Foundation for Individual Rights in Education (FIRE) blog. Now there's a slant in this presentation, but bar some editing for perspective, the principles are reasonably sound. Jacobs suggests they apply in public school, which leaves open the question of parochial schooling, which is widespread in the U.S. and elsewhere. Wouldn't these principles apply?

But more: I think there's a distinction to be drawn between moral principles and social principles. The former guides a person's sense of right and wrong, and these should be freely chosen and expressed, and not imposed on a person. The latter, though, consists of principles necessary for free and peaceful coexistence, and apply to all regardless of their beliefs. Teaching social principles is not the same as teaching moral principles; teaching them is not 'indoctrination' or any such thing, and is in effect no different than teaching people the highway traffic act.

The Downtown BIA presents their State of Downtown report this year via video:

It’s been particularly rough for Downtown in almost all categories because of the combined effects of a loss in office workers, resident shoppers, restaurant and arts patrons, tourists and event-goers of all kinds.  And yet the representatives of those markets are pretty optimistic, and expect that post-pandemic downtown will be a lot like the pre-pandemic.  (Where changes occur will likely be invisible to most – for instance, inside those office buildings, on transit, and how we communicate.)

A special shout-out and thanks to CEO of the BIA, Charles Gauthier.  Charles is retiring this year, after an indispensable career not just in leading the organization but in his outreach, understanding and negotiation with so many different constituencies that make up the complex core we call Downtown Vancouver.  The City is a better place because of him.

“You either die a hero, or live long enough to see yourself become a venture capitalist.”
— Unofficial motto of Party Tent, the famous two-faced venture-backed startup that imploded one dark night when their lead designer got busted for not paying the font licensing fees for Gotham

Making the jump from software to investing

I started making the transition from software into angel investing a couple years ago. A few things immediately became apparent:

• I don’t know what I’m doing
• I wish I had paid more attention (and had more access) to financial discussions at previous startups I worked at
• And oh neat: this is pretty exciting

It’s been a couple years now, and I’ve learned a lot. And since I’ve recently seen so many developers start showing an interest in making a similar leap… I thought I’d share some thoughts on making that transition.

Don’t worry about a possible impending global financial crash or the fact that valuations are totally bonkers because of all the other new investors jumping into the mix: you’re an investor now, dammit, and metrics and forecasting don’t need to be your priority anymore. (Kidding. Probably.)

The cold start

I think it’s understandable that most people who have worked for startups in the past have no idea how the whole industry really works. They might be able to build an amazing, scalable backend perfectly written in eight different programming languages (except JavaScript), but when it comes to raising money, when it comes to stock treatment and valuation differences, when it comes to analyzing a new company — which might still be just a single person and a napkin sketch! — it’s just not their wheelhouse.

Part of that is a failure of previous work experiences: as an industry, we don’t do a really great job at teaching these things, or even worse, we hide them behind the “that is confidential information!” justification. At the first startup I worked at, our CEO walked us all through our books line-by-line and described how the business worked, saying “if a company hides this from you, treat it as a red flag”. I think about that a lot.

So the trick is to cram all that information you had missed out on and get yourself up to speed quickly. One straightforward way to start is to — unsurprisingly — read. There’s a lot of great information out there: I’m a fan of Holloway’s guide to angel investing, which is a deep-dive into angel investing in particular. But don’t forget that there are always two sides to every angel investment transaction: yours and the founder’s. So I also think it’s super helpful to read up on “how to raise” resources, too. Brad Feld and Jason Mendelson’s Venture Deals is kind of the gold standard. That’s actually what I first read before starting to raise money for During a few years back. There’s a ton of overlap between raising money and investing in companies, and if you’re looking to do one of them, I highly suggest doing the other, too. You learn so much about investing from trying to raise money. And you learn so much about raising money by investing.

Investing without money

One of the first things I hear from others who are interested in becoming an angel is “what’s the minimum check size to get started”? And, naturally, that’s an important question to ask, especially because people are all sorts of gradients between “I don’t have any extra money for this” and “I own Amazon”.

The minimum check size is zero.

The thing I hate most about investing is that the iteration cycle is so expensive. Both in terms of money — it’s your money, and you ostensibly don’t want to piss it away — and it’s especially expensive in terms of time. Think you found a breakout company? Cool, now just wait 5-10 years before you can get a full result. Makes you pine for software, where you can make a mistake, discover it when you deploy it three minutes later, push a fix, and redeploy, all within ten minutes. The investing iteration cycle sucks. And if you’re just getting started, it can be really expensive before you even start becoming competent.

Something I tried to leverage before taking investing seriously is to do it without money at first. There are a few ways to do that:

• Advising. I advised companies for years before investing in a single startup. I had similar goals going in: I had some domain knowledge that could be helpful for founders, and I wanted more chips on the table to increase chances of making money on startups. (Being involved in more companies leads to better returns than being involved in good companies alone.) Being a startup advisor is a good way to gain insight into the executive-level decisions you may not have had much exposure to in the past, and it also helps you expand your mindset into more companies than just the one you’re working full-time on. It also prepares you as a future angel investor to help figure out how to be an asset to a company when you’re not dealing with them on a daily basis. That’s one of the trickier things of being an angel, I think; you have to be clear where you can help at the drop of a hat, and be clear to the founder when you’re out of your depth. Being an advisor to a company comes with it a slew of other considerations; might have to write more about that in the future (let me know if you’re interested!)
• Syndicates. Angel syndicates have been around for decades, but recently they’ve become far easier to get into as a newbie. AngelList Syndicates is the most well-known these days, and it does make it easy to get started if you’re an accredited investor. One of the best things you can do is to join one (or preferably many) syndicates. You’ll get deals in your inbox every couple days and you can use that to use a critical eye and ask yourself, “well, would I actually invest in this, or not?” Most syndicates have a minimum investment amount — usually $1,000 or $5,000 — but the real minimum is zero: you can just decide not to invest in the deal. More deal flow (especially if you don’t have a ton of connections yet) means you can iterate far quicker on “is this startup a good investment”? It’s helpful for future founders, too, since the more pitches you see, the better off you’ll be in making your own pitch. Really can’t stress how helpful this was for me: I spent a few months basically just monitoring deals, making mental notes as to how I analyze a pitch, and then I slowly started making small investments here and there until I became more comfortable. Certain syndicates are even more helpful with this, too: I’m currently setting up a syndicate for former GitHub employees with an emphasis of being a gentle start to gain an understanding (and exposure) to the process. Take a look if a previous employer you worked at had an alumni investment group. Your university might have one as well.
• Crowdfunding. This is really enabled by very recent changes in US law allowing different treatment of crowdfunded investment rounds. Republic seems to be one of the early winners of this kind of approach: they host crowdfunded raises for vetted companies that you can invest in, some for as low as $100. But you can also browse through their existing public pitches and help your iteration cycle, too. (Take a look at Gumroad’s $5M raise, for example.) Again, the name of the game is getting your eyes on as many deals as possible so you can learn and evolve your own instinct for your own later investments.

Another option, if you’re feeling lonely, is to just add the phrase “angel investor” to your Twitter profile. You’ll start getting lots of randos sending you weird pitches. It’s… uh, not necessarily a recommended approach.

How can I be helpful?

One of the common jokes is that every investor will inevitably end an email with the phrase “How can I be helpful?” It comes from a good place, of course — sure, everyone wants to be helpful — but just expressing the desire to be helpful isn’t really… well, helpful.

Before really jumping into investing, it’s worthwhile to really ask yourself how you’re actually planning on being helpful. Otherwise… why are you even doing this? Just throw a bunch of call options on $GME or some shit instead. Part of the benefit of angel investing is using your background to hopefully improve your return on investment.

There are a lot of ways to be helpful, but I’ve found for early-stage startups that are three main areas where help is always sorely needed:

• Hiring. Hiring hiring hiring. Hiring is always the problem. Most startups you invest in probably have at least some network they can fish for leads, but the first 10-20 hires are critically important, and they can be tricky to find. This is where generalists get their time to shine, and attracting these types of people (or even just discovering them) can be difficult. Being able to mine your own network for possible hires, or simply being available to talk to the founder about candidates, is really helpful. One of the startups I’ve invested in does a good job of letting targeted hires talk directly to an existing investor, and that’s been really valuable to landing hires that otherwise might head elsewhere. You want to be that kind of person who can help out in this sapce.
• Customers. After hiring, I think helping with customers (depending on the business) is the second most important thing for an early startup. You’ll start getting your monthly investor updates from your portfolio company, and more often than not they’ll reach out for leads into companies of x size in y industry. It’s good to be able to make those introductions to potential customers. Revenue, as you might imagine, turns out to be a good thing.
• Domain knowledge. This one really depends on the circumstances, but sometimes there’s just a great fit between you and your portfolio company. Maybe you’ve worked on something similar in the past, or are a huge user of the product they’re building. Or, maybe the company is really struggling with marketing, and that’s something you love digging into. This area can change a lot as a company grows, so it’s worth thinking prior to putting in a check about what’s special about you now and what’s special about you a few years down the line, when things are different. And yes, I think you’re special; don’t be so hard on yourself.

You and them

There’s a lot more to dig into; if you’ve never done this before, virtually everything is a learning process. I’m still learning what feels like new things every day. But it’s really been fun, especially if you have some experience in the industry and you find yourself getting burned out on the software side of things. Just talking to other companies, seeing different approaches and mentalities of how they attack problems… it can be pretty eye-opening. And a lot of the time the advice you give as an investor or advisor doesn’t even have to be perfect advice. Sometimes it’s just helpful to say “whoa, don’t do that, because I did that early on at this other startup and it was a fucking terrible decision, and here’s why”.

The only other aspect that ties into all of this is to keep remembering what you’re doing here. For these companies you’re a source of capital. And that’s great- that’s how big things can come from humble starts. Hopefully you’re a source of reassurance, wisdom, and encouragement, too. But you’re not changing the world; the founders and their team are. You’re not some sort of ridiculous genius savant for picking winners; you might just be competent at wiring money back and forth. It’s worth pointing that out because the power dynamics here are totally fucked up. People come to you for money, and you get to make the ultimate decision: yes or no. Easy to get wrapped up in that… but try not to.

Try to help people, try to make good decisions, and hopefully things work out for everyone.

One of the issues of working in distance education is providing individual support to individual students. In a traditional computer teaching lab environment, students encoutering an issue might be able to ask for help from teaching assistants in the lab; in a physical university, students might be able to get help in a face to face supervisory setting. In distance education, we have spatial separation and potentially temporal separation, which means we need to be able to offer remote and asynchronous support in the general case, although remote, synchronous support may be possible at certain times.

Related to this, I just spotted preview of a Docker workflow thing, Docker dev environments, for sharing work in progress:

The key idea seems to be that you can be working inside a container on your machine, grab a snapshot of the whole thing, shove it on to dockerhub (we really need an internal image hub….) and let someone else download it and check it out. (I guess you could always do this in part but you maybe lost anything in mounted volumes ,which this presumably takes care of.)

This would let a student push a problem and let their tutor work inside that environment and then return the fixes. (Hmm… ideally, if I shared an image with you, ideally you’d fix that, update the same image, and I’d pull it back???? I maybe need to watch the video again and find some docs!)

One thing that might be an issue is permissions – limiting who can access the pushed image. But that would presumably be easier if we ran our own image hub/registry server? I note that Gitlab lets you host images as part of a project ( Gitlab container registry ) which maybe adds another reason as to why we should at least be exploring potential for an internal Gitlab server to support teaching and learning activities?

(By the by, I note that Docker and Microsoft are doing a lot of shared development, eg around using Docker in the VS Code context, hooks into Azure / ACI (Azure Container Instances) etc.)

In passing, here are various other strategies we might explore for providing “live”, or at least asynchronous, shared coding support.

One way is to gain access to a student’s machine to perform remote operations on it, but that’s risky for various reasons (we might break something, we might see something we shouldn’t etc etc); it also requires student and tutor to be available at the same time.

Another way is via a collaborative environment where live shared access is supported. For example, using VS Code Live Share or the new collaborative notebook model in JupyterLab (see also this discussion regarding the development of the user experience around that feature). Or the myriad various commercial notebook hosting platforms that offer their own collaborative workspaces. Again, note that these offer a synchronous experience.

A third approach is to support better sharing of notebooks so that a student can share a notebook with a tutor or support forum and get feedback / comment / support on it. Within a containerised environment, where we can be reasonably sure of the same environment being used by each party, the effective sharing of notebooks allows a student to share a notebook with a tutor, who might annotate it and return it. This supports an asynchronous exchange. There are various extensions around to support sharing in a simple JupyterHub environment (eg https://github.com/lydian/jupyterlab_hubshare or potentially https://github.com/yuvipanda/jupyterhub-shared-volumes ), or sharing could be achieved via a notebook previewing site, perhaps with access controls (for example, Open Design Studio has a crude notebook sharing facility is available to, but not really used, by our TM351 Data Management and Analysis students, and there are codebases out there for notebook sharing that could potentially by reused internally behind auth (eg https://github.com/notebook-sharing-space/ipynb.pub )).

A fourth approach is now the aforementioned Docker container dev sharing workflow.

The inexpensive and unassuming Escali Primo Digital Scale can transform the way you bake and make you a more efficient cook.

RSS is of course a staple in my toolbox. I use it every day, I've built applications around it, and it gives me this huge advantage in keeping up with developments and discussions in the field. This article is presented in the context of a Zapier marketing campaign for 'email subscriptions to RSS'. This is a service offered by other companies as well; I've been using it in Feedly for the last year. Tip of the day: "Some job search sites, like We Work Remotely, offer RSS feeds for each of their categories of jobs that you can subscribe to for updates." Again, note, this is a marketing post, and readers should be aware that the Zapier features touted can also be performed using other (free) applications.

A must-read article (from, not surprisingly, The New Yorker) recommended by Peter Ladner, and seconded by me.  It’s about more than e-scooters – namely the micromobility revolution, the relation of technology to human beings, and at the end, a rather dark scenario as we return, post-pandemically, to the streets:

Some tasty nuggets from the complete article here:

Transportation wonks hailed scooter-sharing as the best solution to their “last-mile problem,” when the trip between the train station and home is a little farther than walking distance—around a quarter of a mile, for most people. Futurists saw it as the first transportation mode to incorporate mobile-computing and global-positioning technology in its core design, and touted the e-scooter as a harbinger of the battery-powered, software-controlled car of the future. But to detractors e-scooters were a fad, and scooter-share programs were a tech hustle that exploited a limited public resource—city streets—to enrich private investors. …

In the late two-thousands, the first wave of e-bikes arrived in the city as food-delivery workers, virtually all immigrants, began using them. For a fifteen-hundred-dollar investment in an e-bike, a worker can increase his nightly earnings by two dollars an hour—which could amount to thousands more in yearly earnings. …

On March 20, 2020, Cuomo put the state into lockdown. Within weeks, the food-delivery workers whom the N.Y.P.D. had been harassing were being hailed as frontline heroes. During the terrifying early days, particularly, it seemed as though ambulances and delivery e-bikes were the only vehicles moving. …

In renting a scooter—or a bike—you provide the hire company with information about you, your route, your travel speed, your driving style, and your destination. Cities grant scooter concessions in part to have access to these data, which are aggregated and anonymized according to rules that underpin the Mobility Data Specification, an open-source digital tool. This information is far more granular than the data that can be gleaned about subway or bus ridership. …

A data-driven form of collective intelligence employed in scooter fleets, geofencing uses G.P.S. to create virtual boundaries around terrestrial places. The technology can keep scooters off sidewalks and away from restricted areas by automatically cutting the power to the motor when the scooter crosses the geofence. Geofencing also requires users to end rides in designated scooter-parking areas, reducing sidewalk clutter. You could still pick up a parked scooter, though, if it isn’t locked to anything, and throw it into the East River. …

(Horace) Dediu argues that, just as the heavy desktop computer has been superseded by lighter laptops, tablets, and smartphones, so the automobile will be “unbundled” into much lighter, cleaner, and less resource-dependent E.V.s that can be used for most of the trips people now make by car. (In the U.S., sixty per cent of all car trips are less than six miles.) Lithium-ion batteries, first introduced to consumers by Sony in high-end camcorders, today power an ever-expanding array of mobile devices—not just our phones and laptops but also vehicles like e-bikes, e-scooters, e-monowheels, e-skateboards, and other continually evolving forms of micromobility that no longer require the user’s energy to move them.

Dediu calls e-scooters “smartphones on wheels.” No other vehicle on the road has a higher proportion of brains to brawn. …

Superpedestrian’s operating system was performing more than a thousand autonomous maintenance checks a second—brake issues, battery-cell-temperature imbalances, severed internal wires, water penetration—so that an algorithm that has learned to detect signs of incipient scooter failure can take the vehicle out of service before a serious malfunction occurs that might land the machine in the shop and the rider in the hospital. (The system can also detect collisions and report unsafe driving to local control centers.) As a result of this regimen of automated self-care, Link scooters require maintenance once in every two hundred and fifty trips, versus the industry standard of once in every fifteen to forty trips….

Even cities with smoother infrastructure have reported an epidemic of certain types of injuries at the beginning of sharing programs. Wally Ghurabi, the medical director of the emergency center at UCLA Health Santa Monica Hospital, participated in a 2018 study, conducted by the university, of two hundred and forty-nine patients admitted to the E.R. after scooter accidents, of whom ten had worn helmets. A hundred of them had head injuries. …

Even before the pandemic, transport planners knew that many people who take up biking are shifting from public transit, or walking, and not from cars. The micromobility gains in Paris and London are mostly at the expense of their Métro and Underground systems …

As people go back to working in offices and shopping in stores, but potentially remain leery of trains, buses, and car pools, many will mode-shift to four wheels rather than two. Ridership on the subway is still at only thirty-five per cent of its pre-pandemic levels; bus ridership is about fifty per cent. Traffic, however, is already reaching pre-pandemic levels at the river crossings and on interborough expressways open to commercial traffic, even as it remains depressed in midtown. According to Sam Schwartz, a longtime New York transportation analyst, the city is facing a “scary” traffic scenario this fall, unless something is done to redirect the public’s atavistic retreat to private automobiles.

If seventy-five per cent of remote workers return to their Manhattan offices, he explained, but twenty per cent of them remain fearful of public transit and mode-shift to driving, the number of vehicles entering the central business district in Manhattan will increase by two hundred and nine thousand cars over the 2018 peak, when midtown traffic crept along at an average of five miles an hour. (Congestion pricing, the plan to toll drivers crossing the East River and entering Manhattan below Sixtieth Street, seems all but inevitable now.) Unless the M.T.A. receives additional funding, there will almost certainly be cuts to subway and bus service to make up for missing fares. Instead of the fifteen-minute city, we may be looking at a ninety-minute one.

There’s a premise out there (articulated pretty much at every rezoning hearing by Councillor Jean Swanson to justify a no vote) that newer, bigger apartments and condos constructed in a lower income neighbourhoods will have gentrification effects – in particular, an upward pressure on rents.  Seems reasonable to some, unverifiable to others – or at least no justification to argue against new development that will eventually become older and relatively more affordable.

Sooo … this research from the States will add fuel to the debate, which maintains new development can actually lower some rents.  Nor do an increase in amenities have a measurable effect.

From Planetizen: