rdubz

78.0.1 doesn't look yanked to me https://pypi.org/project/setuptools/78.0.1/

afaict they just released 78.0.2 with a revert of the offending bits

The graphs a couple folds down seem to justify the "alarmist" tone.

I learned about parquet2json from HN recently, and would use it for this:

```bash

parquet2json cat <file or url> | grep ...

```

https://github.com/jupiter/parquet2json

interesting, I've had a much easier time pairing (and felt benefits like you describe) over Zoom. Pairing by actually having 2 people at a desk never felt very comfortable, but screen-sharing with each person on their own monitor etc. works great, IME. I'm curious what you've tried / why it hasn't worked...

I had saved the chart here, Google reverse image search led me to this article https://streets.mn/2014/05/22/chart-of-the-day-travel-effici... which says it's from Scientific American.

There were a few other hits as well. This one mentions the Steve Jobs quote and corroborates "Scientific American, 1973" https://www.smestrategy.net/blog/using-the-6-thinking-for-st...

This is a pure panic run on the bank though, irrational and counter-productive. The bank was not insolvent and could have been fine if everyone didn't withdraw all at once.

This is incorrect. SVB converted deposits to risky paper that lost value. They were insolvent.

The fact that the risky paper would return its promised 1%/yr, if everyone just waited 10 years, is a canard. SVB's depositors could get 4% elsewhere, today. Asking them to sit tight at 1% is the same haircut as liquidating that paper at a loss today (which is what happened).

Is this accounting for inflation?

4% inflation per year (the most common estimate I see in the US) means 3x over 30 years doesn't even break even (1.04**30 ≈ 3.24).

I often wonder how much people obsessed with home prices rising (in the US at least) take this into account. How much housing mania is fueled by people getting excited about gains that aren't as real as they think?

"Each year, 1.35 million people are killed on roadways around the world."

https://www.cdc.gov/injury/features/global-road-safety/index...

Seems to me that traffic deaths are "caused by" humans... not totally surprised they have decided those don't count, but I feel that that's wrong.

Back of envelope:

The 10MB estimated size came from [100 bytes per row] * [100k rows].

50 of the bytes per row were "description", which should compress well (2-3x, I'd guess).

40 bytes per row were the IPFS ID/hash, IIUC. I assumed this is like a Git hash, 40 hex chars, which is really just 20 bytes of entropy.

He also estimated 14 bytes for the size (stored as a string representation of a decimal integer, up to 1e15 - 1, or 1PB?). That's about 50 bits or 6-7 bytes, as a binary integer. Sizes wouldn't be uniformly distributed though so it would compress to even fewer bytes.

So if SQLite was smart (or one gzips the whole db file, like you did), it makes sense that a factor of 2 or so is reclaimable.

if you are "cutting and pasting from the notebook into a .py file" you should look at `jupyter nbconvert` on the CLI.

I think there's ways to feed it a template that basically metaprograms what you want the output .py file to look like (e.g. render markdown cells as comments, vs. just removing them), but I've never quite figured that out.

Summary:

1. healthy decentralized services often have <1% of users who do "want to run a server," and the whole thing works as a result 2. immutability / inability to change quickly is good for protocols 3. crypto community does need to decide whether it cares about money or decentralization

Took a while getting to the good part of 1. Should have skipped "'no one wants to run a server' is factually incorrect!"

I loved the Moxie piece but it was strange bc Moxie is a legendary cryptopunk who presumably believes decentralization is good (though hard to attain/maintain)... right? Moxie made excellent points but left me wondering what he actually thinks, or thinks should happen.

I also liked the pushback here about email being an example of failed decentralization, because Gmail is big or something? Email seems like the last major decentralized communication protocol still standing, despite incredible centralization/"balkanization" of the messaging space.

semi-OT but Twitter seems to have recently started putting "mobile.twitter.com" in my URL bar (on mobile), as well as adding a UUID in a "t" query param when you use their "copy link" flow, which is all annoying cruft to have to delete when sharing links.

They used to just put "?s=19" through "?s=22" or so, which enumerated clients (desktop, mobile, Android, etc), which was better than the junk most other services stuff in (like utm_source and friends...)

(post author here )

"Better bike infrastructure" and "a bit of pedal assist" are both good things that we need more of.

Even in the best possible future, I believe cycling in US cities will involve some amount of mixing with cars for the rest of my natural life (unfortunately!), so I'm not sure "completely bogus if…" is fair.

And anyway, a little extra speed is still useful because it's transportation.

Here's a fun thought experiment: define "places I can go" as "the locus of points within 1hr bike ride of a train station." If e-bikes let me go 50% faster (say, avg 15mph instead of 10mph), that multiplies the accessible area around each train station by 2.25x! I can go more than twice as many places now!

Maybe I need to caveat it more, but I'm really focused on the range from, say, ≈5mph (uphill on a "leg-bike", or starting from a stop at a light or stop sign) to ≈25mph (roughly my top speed on a leg-bike or e-bike).

In that range, and in mixed traffic (which is unfortunately most urban riding in the US), a 5mph difference can be a step change in terms of whether drivers even feel the need to pass me at all. 15mph is only 50% faster than 10mph, but can totally flip the "who's passing who" dynamic from "cars passing me frequently+aggressively" to "cars hesitate, back off, and then I get ahead / pass the next cars in line at the next light."

Here's an account where I've been posting videos that illustrate this a little more viscerally: https://twitter.com/CarsDontFitJC/status/1457490588320817153

Used e-bikes are also available, and cheaper.

I'm comparing new cars to new e-bikes and, sure, in both cases you can get something "pretty good" for ≈half the average new {e-bike,car} price. Some people will get something "very good" for 2x the average!

From what I can tell the research supporting the $40k average (or, alternatively, $800/mo) seems reasonable:

https://www.cnet.com/roadshow/news/average-new-car-price-202... https://www.motor1.com/news/370609/average-american-monthly-...

Definitely something I want to hash out and cite more though.

Thank you, fixed! https://github.com/neighbor-ryan/ebike-gitbook/commit/8e5885...

Haha, good catch, fixed! https://github.com/neighbor-ryan/ebike-gitbook/commit/dad5ac...

Did that via Gitbook WYSIWYG editor, not sure what all those other changes are about, hopefully didn't break anything

Hi, I'm the site creator, just saw this posted! Happy to field questions.

The site is due for an update, I've been compiling a lot more resources and bolstering some of the arguments with more data, but lately I've been spending a lot of time on these cyclist PoV videos https://twitter.com/CarsDontFitJC

To briefly touch on a few common q's I see cropping up here: - Yes, cycling infrastructure is really bad everywhere in the US (some places worse than others). That's orthogonal to most of the things that are great about e-bikes though. Better infra, and more e-bikes, are both part of fixing the US's horribly broken urban transportation landscapes. - "Rain and snow": it's just not that hard to make biking reasonable in all but the most inclement weather, and anyway, solving {traffic, parking, traffic violence, air pollution, noise pollution, emissions} on the other ≈95% of the days would be extremely good for everyone (including drivers). Making everyone wear a "$40k internal combustion parka" everywhere is not a good solution either!

I really appreciate the thoughtful feedback and discussion I have some related projects with cool software angles I am hoping to post here as well, soon™

Attempting to expand on context that I think the parent left implicit:

- Women are underrepresented — in STEM fields at large and in the cryptocurrency space in particular — relative to a fairer world with less sexism, outmoded notions of gender roles, etc.

- This underrepresentation self-perpetuates partly because well-meaning men in these fields don't realize it's happening: it always feels better to believe a happier story about the world being more fair, and such men have less data about what keeps women out than they would have in a fairer world where women were more present to tell their stories.

- Erring on the side of feminine or gender-neutral pronouns — against this backdrop of under-representation — is a lightweight way to signal basic awareness of these issues and avoid the appearance of reinforcing them or believing they should be reinforced. As such, it informs my general model about the writer's thoughtfulness/sensitivity, which has some bearing on how compelling I find their argument to be.

It also bears noting that while I can mostly shrug and move on if a writer is implying apathy (or worse) about this issue, it is a more acute and even threatening signal for some women whose careers/lives have been damaged by these playing fields' having never​ been level, and it is morally fraught to participate in and benefit from discussions/community/resources that are effectively/unfairly off-limits to under-represented groups.

tl;dr:

- default-masculine-pronouns are not neutral,

- we've all been tacitly made to think that they are,

- some work to counter that makes sense, and

- it's good to push conversations/awareness about them because the default perpetuates them.

Humans kill a million people each year with cars.

Driving should be illegal.

rebase : centralized repo :: merge : decentralized repo

rebase : linked-list :: merge : DAG

If the work/repo is truly distributed and there isn't a single permanently-authoritative repo, a "clean, linear" history is nonsensical to even try to reason about.

In all cases it is a crutch: useful (and nice, and sufficient!) in simple settings, but restricting/misleading in more complex ones (to the point of causing many developers to not see the negative space).

You can get very far thinking of a project as a linked list, but there is a lot to be gained from being able to work effectively with DAGs when a more complex model would better fit the reality being modeled.

It's harder to grok the DAG world because the tooling is less mature, the abstractions are more complex (and powerful!), and almost all the time and money up to now has explored the hub-and-spoke model.

In many areas of technology, however, better tooling and socialization around moving from linked-lists (and even trees) to DAGs is going to unlock more advanced capabilities.

Final point: rebasing is just glorified cherry-picking. Cherry-picking definitely also has a role in a merge-focused/less-centralized world, but merges add something totally new on top of cherry-picking, which rebase does not.

A problem with rebase workflows that I don't see addressed (here or in the replies) is: if I have, say, 20 local commits and am rebasing them on top of some upstream, I have to fix conflicts up to 20 times; in general I will have to stop to fix conflicts at least as many times as I would have to while merging (namely 0 or 1 times).

Moreover, resolution work during a rebase creates​ a fake history that does not reflect how the work was actually done, which is antithetical to the spirit of version control, in a sense.

A result of this is the loss of any ability to distinguish between bugs introduced in the original code (pre-rebase) vs. bugs introduced while resolving conflicts (which are arguably more likely in the rebase case since the total amount of conflict-resolving can be greater).

It comes down to Resolution Work is Real Work: your code is different before and after resolution (possibly in ways you didn't intend!), and rebasing to keep the illusion of a total ordering of commits is a bit of an outdated/misuse of abstractions we now have available that can understand projects' evolution in a more sophisticated way.

I was a dedicated rebaser for many years but have since decided that merging is superior, though we're still at the early stages of having sufficient tooling and awareness to properly leverage the more powerful "merge" abstraction, imho.

Looks cool!

Mobile experience seems poor:

- Weird margins taking up lots of the screen

- Back button seems to be disabled (I pressed it about 200x trying to get back to HN and nothing happened)

- "view mode" would be nice: don't pop up keyboard for editing when I click on some part of a source file, but still support clicking symbols and offering options e.g. jump to definition.

post author here, this is good perspective, thanks.

* The "<++=" operators are much-maligned but I've seen them ~0 times in 6 months; I may have come in to SBT-land just as they were being finally phased out, I think I did see them in the beginning a bit.

* Agreed that the recursiveness of the build is presented somewhat confusingly and navel-gazingly!

* Speed-wise, I imagine you're talking about reloading projects, either in the SBT CLI or IntelliJ? That's pretty fair, I've had to adjust my IJ workflow a bit to not trigger full-project-refreshes as often (e.g. disabling auto-import). If you're talking about e.g. compilation or other tasks being slow, I'd be surprised and interested to hear more, though.

* re: SBT plugins being stuck on 2.10, I was also a bit daunted to read that early on, but at this point I've written several SBT plugins and it's basically never been an issue or introduced any friction; curious to hear if it's caused problems for you.

* Agreed that there is a steep learning curve and some payoff that reasonable people may value differently, and also to not write a build system :)

scala-maven-plugin allegedly supports this: http://davidb.github.io/scala-maven-plugin/example_cc.html

That said, I remember trying it and not sticking with it years ago, but I also don't use it in SBT. I remember if it was particularly broken in any way that caused me to abandon it in Maven.

There may be some subjectivity around what constitutes added/removed complexity.

The ability to factor out repeated logic and configuration in SBT, by dint of using Scala instead of XML, removes a lot of complexity. Of course, arbitrary Scala can get more complex than arbitrary XML.

As some points of reference, not saying these clearly argue for one side or the other:

Here is the Maven POM for ADAM's core module:

https://github.com/bigdatagenomics/adam/blob/adam-parent_2.1...

and its parent POM:

https://github.com/bigdatagenomics/adam/blob/adam-parent_2.1...

For comparison, build.sbt from my fork of ADAM:

https://github.com/hammerlab/adam/blob/e4bee3227b5979e65a73d...

And a plugin that it inherits that factors out a lot of functionality I reuse across projects:

https://github.com/hammerlab/sbt-parent/blob/1.7.5/src/main/...

Spark's POMs (e.g. https://github.com/apache/spark/blob/v2.1.0/pom.xml) vs. SBT project folder (https://github.com/apache/spark/tree/v2.1.0/project) are another point of comparison.

It's not hard for me to imagine how someone used to staring at one or the other of these kinds of configs, maybe for years, would feel that it made more sense than the other, but having spent some significant time with both, I think the points about having the option to express more sophisticated logic – that SBT provides – are pretty important, and the lessons extrapolate-able beyond building Scala projects :)

All very reasonable, thanks.

I've used Blaze at Google and then Pants at Foursquare, so I've seen this sort of thing done, but yea, Pants seemed like it was going to take a higher level of commitment to set up / maintain, due to smaller OSS ecosystem around it, so I had to short-circuit that thread.

Also, putting everything in a monorepo is not really an option in my current OSS-focused setup, and I've come to have grave doubts about its desirability overall, after years of believing that it was the ideal way, but that's another discussion :)

hiya jackson :)

yea… that's a longer discussion. I've been influenced on this by some coworkers (cf. http://www.hammerlab.org/2015/01/21/introducing-ketrew-0-0-0...) and conference talks (including one at NEScala 2wks ago, https://github.com/nescalas/proposals-2017/blob/master/long-... ); one way to think of it is that there are blurry lines between a DSL and any plain old API… they're kind of the same idea, though conventionally DSLs have tended to involve more punctuation marks, and I agree that that can be taken too far, and that SBT did in fact take it too far in the past!

On the other hand, XML with a given schema is a kind of DSL as well, and where it's possible to make e.g. Scala DSLs overly concise to the point of inscrutable trickiness, XML APIs are frequently considered to be inscrutably verbose, as we've all heard and experienced ad nauseum.

However, given Scala's powerful type-checker and flexible syntax, more sane middle grounds can be explored. Maybe a less controversial example in SBT is the "/" operator for constructing filesystem paths (https://github.com/sbt/sbt/blob/v0.13.13/util/io/src/main/sc...), which I incidentally just mimicked in a java-nio-Path-wrapper library this past weekend (https://github.com/hammerlab/path-utils/blob/1.0.2/src/test/...). The alternative here is Java's Path.resolve(), which is a bit clunky to say the least.

Also some of the JSON-DSLs we dealt with at 4sq come to mind as nice bits of ad-hoc syntax that still benefit from all of Scala's type-checking wondrousness :)

(edit: fixed broken link)

post author here, thanks, I think a couple things you said are spot on.

In a perfect world I would have discussed Gradle here as well, but I've never actually used it and so that fell out of scope (same with a more thorough treatment of Pantsbuild that I hoped to do).

Your articulation of Maven's issues also resonates :)

I do experience slow project reloads in IntelliJ (not as much on the SBT CLI), so that's fair. Not a dealbreaker given how much easier (read: more possible?) it is to express the logic I want to express in SBT, but reasonable people can disagree about those tradeoffs :)

(disclaimer: post author)

Any specific examples you have in mind?

As I mentioned in the post, the first… 5 Maven plugins I looked for all existed in about as good or better form in SBT-land.

Come to think of it, the dependency plugin in SBT, https://github.com/jrudolph/sbt-dependency-graph, seems to be missing some wildcard features that I used to like in maven-dependency-plugin. OTOH, it has some things that afaik don't exist in maven-dependency-plugin, like dot-graph output.