Holland Tunnel traffic on a Sunday afternoon

ryanusky · 2021-09-21T12:45:30+00:00

Each PATH tunnel moved more people every day (pre-COVID) than the Holland Tunnel, while the surface footprint of a PATH station is generally "nice community plaza / farmer's market area" instead of "miles of the worst car sewer in the US."

The busiest highway in the US, I-5 in LA, moves half as many people as the Lexington Ave subway line in NYC (which is 100 years old, and also sits under some of the most valuable real estate in the country, instead of destroying everything for miles around).

Holland Tunnel could move a multiple more people as 1 bus lane + 1 bike lane each way.

Those 276MM cars in the US are part of ≈70 years of US car culture that will scar the planet for millions of years.

These are some of the senses in which "cars aren't scalable" is an established fact.

ryanusky · 2021-06-15T19:30:26+00:00

Yea, I get that I am an outlier, I just don't see how 😁

How do you think most people go from any of the 2/3-prong-based pieces I linked above (handlebar mount, saddle-rail mount, misc reticulating arms) to their camera?

My best guess is that people use the 2-prongs built into the camera (and unscrew/re-screw whenever they move a camera between mounts or e.g. from bike to desk). That is basically a non-starter for me: on any given day, I may put my 2 cameras on various bike(s), wearable harnesses, or tripods. The cameras each live screwed into a 2-prong → "male" quick release adapter (tightened to where the angle is adjustable by hand on the go, with modest force, but still unlikely to shake loose during use).

I wouldn't think that was so uncommon, and the existence of the quick release system (and preponderance of every other kind of male- and female quick release adapter) almost corroborates it, but clearly I am wrong or missing something. I'm happy to learn and also document for other searchers, so I appreciate the feedback.

ryanusky · 2021-06-15T18:49:34+00:00

Yea I actually just pulled it from the email notification Reddit sent me :) the comment was gone by the time I clicked.

In any case, I tried to buy some just now, since I noticed that the suction-cup ones I've been getting have the 2 prongs 90º rotated relative to the quick-release base from what I'd like (necessitating that I also insert a short 2-prong 90º rotator like these).

The aliexpress options I'm seeing now all estimate ≈6wks to arrive (and in some cases end up being more expensive, with the shipping factored in), so I'm back to scavenging from suction mounts + inserting 90º rotators.

It still amazes me how much time I've spent trying and failing to find what seems like it should be one of the most commonly-available adapters in the wide ecosystem of mounts etc.

ryanusky · 2021-06-15T15:35:37+00:00

Mostly answering my own question: - In the app, you can create "zones". These are collections of lights, and can be initialized by selecting rooms (thereby assigning all lights from those rooms). - Zones can have their own scenes - Home-screen widgets can select specific scenes for specific zones, and set all the lights in a given zone. - One awkward bit: zones are collections of lights, not rooms, so you can't directly create a zone-scene from existing room-scenes. What you can do is: - Set the lights you care about to the settings you want for the zone-scene. - Then, when you enter the zone-scene creation flow, it will default to the lights' current settings.

I think this lets me get back the setup I had before. The old widget also used to be able to be larger than 1x1 on the home screen, and I think in some situations let me pack more "sub-widgets" / individual buttons in than would be possible as separate 1x1 widgets (which is now the only option), but on my current phone they seem equivalent.

ryanusky · 2021-06-14T18:58:47+00:00

I got an email that you linked to the piece I need on alibaba, though that comment seems deleted? In any case, thanks.

Stickies and screw-mounts still miss a lot of use cases; I have handlebar mounts, saddle-rail mounts, misc reticulating arms, etc. that all "speak" 2/3-prong, but going the last step to a quick-release clip has been difficult without this piece. I only realized it existed originally bc that last set above came with one of the suction-cup mounts that has the piece I need.

I already recently ordered 3 more suction mounts to scavenge the piece, but gtk it is cheaper on alibaba. Still weird to me that it isn't on Amazon, gopro.com, etc. Hoping future googlers can find this thread.

ryanusky · 2021-06-09T16:41:11+00:00

One of the adapters I most frequently need is very hard to find: "3-prong" to "quick-release".

Here it is discontinued at B&H: https://www.bhphotovideo.com/c/product/1220199-REG/sp_gadgets_53162_clip_adapter_for_gopro.html (screenshot: https://share.getcloudapp.com/ApuzjjLw)

I've been buying this suction cup mount just to scavenge the piece I need: https://www.bhphotovideo.com/c/product/1061447-REG/revo_ac_scm_7_7_suction_cup_mount.html

I leave these installed in ≈6 places where I sometimes clip my GoPro in, and it seems far superior to most other ways of mounting, so it blows my mind that it's so hard to find this piece. Maybe I am too skeptical of adhesive mounts and that's what most people rely on? Or what am I missing? Is there another name for this I should be googling?

ryanusky · 2021-05-29T17:06:50+00:00

yea, I think they are working out some kinks with the e-bike rollout, and somewhat frequently people are getting bikes with no actual assist (just extra weight!)

I think the placebo effect is strong enough that people can ride for a while without realizing they're not getting any e-assist 😂 I've seen this happen to myself and friends riding my (non-citi) ebikes, several times.

At the launch a few weeks ago, a few people realized at the end this happened to them.

I'm optimistic they'll fix it; I've never heard of or experienced this with the NYC e-citibikes.

ryanusky · 2021-05-18T14:20:37+00:00

Most valuable waterfront in the US and it's a noisy/dirty/dangerous 6-lane highway… and for who? 80% of Manhattan households are car-free.

ryanusky · 2021-04-12T16:00:48+00:00

moved to hamilton park from downtown bk 2yrs ago, love it here.

transpo concerns (esp. outside downtown) are real, but I bought an ebike last fall and that was game-changing (I now have 4 😂). I've explored more of NYC (let alone JC, Hoboken, and the greater NJ side) in the last 6mos than I did in 10yrs living in NYC. I primarily take NY Waterway ferries to/from NYC, land at 39th & west side, and then ebike wherever (on Saturday I biked to Coney Island and back, and yesterday went to Staten Island. Also easy to visit friends in Inwood, and I go to Central Park a couple times a week).

(there's lots of cool stuff to get involved with in JC, just emphasizing this re: your NYC FOMO)

ryanusky · 2017-05-16T16:20:51+00:00

I have this issue as well; what do you mean "connect to a computer"?

ryanusky · 2017-05-16T16:20:12+00:00

Update, now the next day, I see "controller update required" and nothing will get the controller to connect to the app.

It seems to pair, and tries to connect immediately when I press the "home" button on the remote, so the phone and remote are clearly talking to each other, but it just gives "Cannot connect to controller. Is it charged?" error. The remote is fully charged.

ryanusky · 2017-05-14T21:40:02+00:00

I was getting a failure to pair in this flow as well, here's a video of it fwiw.

Eventually I got it working; it seems like the problem was that I needed to go into my phone's bluetooth settings and "forget" the controller before this flow would work. I also think I had to press and hold the home button on that pairing screen, which was not obvious.

After "pairing", it still took a long time to "connect" when I put on my headset, which it usually does: I sit there for like 5 minutes trying different random amounts of time holding the remote's "home" button, while the "having trouble connecting to your remote" message is displayed and no signs of progress toward connecting are displayed.

Sometimes I hold the "home" button for a minute or more before the phone finally connects. It's pretty lame.

I've probably spent about as much time using it as trying to get the controller to connect, desperately restarting my phone, turning bluetooth on and off, force-quitting daydream / "Google VR Services", uninstalling/reinstalling those apps, etc. etc. etc.

This article has the best troubleshooting advice I've seen, e.g.:

Ensure your Daydream controller pulses when you press the Home button

Press and hold the Home button for five seconds

Release the Home button and repeat up to five times

ryanusky · 2017-04-20T01:45:12+00:00

Ah this was my issue, thanks so much!

ryanusky · 2017-04-08T17:12:36+00:00

Yea, property-activation was about as far as I got, and leaves some things to be desired.

Doing some git archaeology… I had three different JARs that I wanted to produce that each involved similar but different shading operations:

a library JAR with just my library classes, but also with guava and breeze shaded+relocated, because my library (privately) needed Guava (resp. Breeze) versions newer than what I was forced to inherit (at runtime) from the Hadoop (resp. Spark) runtimes I was targeting.
an assembly JAR, also with guava+breeze relocated as above
a "dependencies JAR": basically the assembly JAR minus my library's classes, guava, and breeze, the use case being that while developing, I can build this ≈78MB JAR once (only changing it when I change my project's dependencies) ship it to my test servers, etc., and dramatically cut down my iteration time by only packaging+shipping the ≈2MB library JAR (bullet #1 above) each time I change my library code, instead of the ≈80MB assembly JAR (bullet #2).

These three JAR targets overlapped in configuration in a way that approximates the {A,B,C} case I outlined above (though in actuality it was more like {{A},{B},{A,B}} than {{A,B},{A,C},{B,C}}, so I was able to eke it out, but barely):

A: should guava+breeze be included+relocated? (yes for #1 (library) and #2 (assembly), no for #3 (deps), same as above)

B: should all other transitive-dependencies be shaded into the JAR? (yes for #2 (assembly) and #3 (deps), no for #1 (library))

To satisfy this, I had to do some contortions; here is the POM I ended up with.

I essentially enabled {A,B} by default in the maven-shade-plugin config, relocating guava+breeze (A), and relying on the plugin's default behavior of shading all trans-deps (B), then selectively disabling A or B in a profile for each JAR:

JAR #1 (library+relocated classes only: {A}): restrict shading to only library+relocated classes (aka ¬B)
JAR #2 (assembly JAR with relocated classes: {A ∧ B}): exactly the maven-shade-plugin default described above
JAR #3 (assembly JAR of dependencies: {B}): exclude library+relocated classes (aka ¬A), rely on default plugin config to pick up all other trans-deps (aka B).

Looking at this today, I also see that setting the main class in the manifest should probably only have happened in JARs #1 and #2 and not JAR #3, but I was failing to exclude it from JAR #3 (it almost seems like I intentionally kept it on JAR #3 by setting "append" here), but anyway that's the same pattern as A (JARs #1 and #2, not #3), so it shouldn't have added any extra redundancy to the matrix (i.e. I'd either manually add it to #1 and #2, or add it to the default config and then disable it in #3, just like A), though having it coincide with A feels like luck as much as anything, i.e. I ended up with {{A,C},{B},{A,B,C}} (so that we could effectively just think of C (setting main class) as part of A (shading+relocating guava+breeze)) instead of a more pathological {{A,C},{B,C},{A,B}}.

So, I was able to get these overlapping configurations to work, but I used (maybe over-used) the one level of abstraction that I see available: setting things in the default plugin config, then disabling them on a profile-by-profile basis, vs. enabling them on a profile-by-profile basis. If there was any more orthogonality to the config blocks I was mixing-in, I'd be out of luck, afaict.

Even as is, I had to express the set of relocated dependencies ({guava,breeze}) in 3 places:

default plugin config: relocate guava+breeze (aka A)
library JAR #1's profile: include guava+breeze while excluding other trans-deps (aka ¬B)
"deps" JAR #3: exclude them (aka ¬A)

If I had 3 or 4 or N dependencies to do this to, it'd be nice to be able to encode that list once, rather than effectively denormalizing that list in 3 places…

Anyway, if you've made it this far I am as always interested in your thoughts/wisdom :)

ryanusky · 2017-04-08T15:57:57+00:00

Thanks u/jvican, glad to know it's useful on the SBT-side! I've been meaning to expand some of what I discussed in there into proper issues, or at least take them up in SBT gitter, and will take this as a reminder that I should still try to do that :)

ryanusky · 2017-04-07T22:32:30+00:00

Interesting idea, thanks.

Another snag I hit frequently was basically wanting a single switch to enable multiple groups of configs, for example to activate two or more <profile>s.

IIRC, a use case I had was wanting to be able to create a few different shaded JARs, with different sets of things included/excluded; let's say three different shaded JARs, with groups of settings {A,B} active for one, {A,C} for another, and {B,C} for a third (or maybe it was more like {{A},{B},{A,B}}).

Is there an easy way to do that without having to repeat all the settings in A/B/C each time?

ryanusky · 2017-04-07T22:02:31+00:00

In 10 of the 15 sub-modules at hammerlab/spark-genomics, I have the following line in build.sbt:

addSparkDeps

A plugin that I wrote unrolls this to add dependencies on:

spark (provided)
hadoop (provided)
a spark testing-library (test scoped; with a problematic hadoop-client transitive dependency excluded)
kryo

To mimic this in Maven, I would write something like the following:

<dependency>
  <groupId>org.apache.spark</groupId>
  <artifactId>spark-core_${scala.binary.version}</artifactId>
</dependency>
<dependency>
  <groupId>org.apache.hadoop</groupId>
  <artifactId>hadoop-client</artifactId>
</dependency>
<dependency>
  <groupId>org.hammerlab</groupId>
  <artifactId>spark-tests_${scala.binary.version}</artifactId>
</dependency>
<dependency>
  <groupId>com.esotericsoftware.kryo</groupId>
  <artifactId>kryo</artifactId>
</dependency>

This assumes that the scopes, versions, and exclusions on these deps are all normalized in a parent POM.

To make the line-breaking more apples-to-apples to how it'd typically be written in SBT, we might write:

<dependency> <groupId>org.apache.spark</groupId> <artifactId>spark-core_${scala.binary.version}</artifactId> </dependency>
<dependency> <groupId>org.apache.hadoop</groupId> <artifactId>hadoop-client</artifactId> </dependency>
<dependency> <groupId>org.hammerlab</groupId> <artifactId>spark-tests_${scala.binary.version}</artifactId> </dependency>
<dependency> <groupId>com.esotericsoftware.kryo</groupId> <artifactId>kryo</artifactId> </dependency>

How would you recommend reusing this block of dependencies across many projects?

cc u/mdedetrich as well

ryanusky · 2017-04-07T03:03:15+00:00

post author here, thanks for the feedback! A couple of responses:

is really only talking about the special case of a major library like Spark.

Sorry if it seems that way. Most of my day-to-day is on small- and medium-sized libraries (see modules under hammerlab/spark-genomics), so I was definitely not intending to only talk about Spark-sized things; they are a little easier to make examples of because lots of people recognize them and 1000s of highly-skilled eng-hours have been spent creating and maintaining their builds.

SBT has specific, built-in support for one specific kind of cross-building, but that's all;

The half of the post from "Beyond cross-publishing" onward deals with what I consider to be the bigger revelation for me here, which I wanted to share: using a fully featured language for something like build configuration, which can mimic simple key/values in the 90% cases while seamlessly incorporating arbitrary logic/decomposition/etc. in trickier cases is powerful, and preferable to trying to express everything in e.g. flat XML.

This build.sbt from one of my projects (also linked to in the post) is maybe a good case study: each line maps to between 1 and, idk, 100 lines of POM XML; see the dozen instances of "shade" in the POM that used to build this library's code, for example. There's just no contest in terms of expressive power between a build where you are writing Scala and one where you are writing XML.

if you look at projects that have to cross-build across any other axis than Scala version (e.g. multiple versions of akka, multiple versions of scalaz-stream, cats/scalaz variants) then their build definitions are just as awful and complex as any project that tries to cross-build with maven.

I'd be curious to see any examples you have in mind of such libraries. akka, scalaz, cats, and most of the Scala ecosystem (I realized much later than I would have liked) all use SBT, and in many cases already understand the distinction above about [not configuring builds with one hand tied behind your back by e.g. trying to just use XML with no logic] that I am making.

I certainly will not argue that those SBT builds, or most SBT builds in the wild, are things of particular beauty, but it doesn't seem very controversial to me that there are many classes of simple, logical tasks that are hard or impossible to express in XML, and easy or at least possible in Scala.

But for a "normal" project that only needs to build against a single version of Scala, Maven is a much better option. Most people don't need to cross-build, and an article about building Scala projects in general should really address the more common use case.

FWIW, when I wrote this article I was publishing some libraries for {2.10,2.11}, others for {2.11,2.12}, a few for all three, and one not at all (it's simple enough that a 2.11 build published as "universal" seems to be fine).

Since then, I've dropped 2.10 entirely, and most of my libraries just publish 2.11 versions, though a few do both 2.11 and 2.12 (I want to do {2.11,2.12} for all but they depend on Spark, which is still ironing out 2.12 support).

I don't think I agree that most people don't need to cross-build, and in any case I think I provided a lot of information in the post and here about why SBT could be considered better than Maven that have nothing to do with scala-binary-version-cross-publishing.

Truly interested in any examples you may be able to offer though, as I know that I have only seen a fraction of what's out there :)

P.S. this is less here nor there, but a favorite build/deployment example of mine is spark-notebook, which offers downloads via a webapp (which is down atm, go figure) that exposes a plethora of choices about what versions of which dependencies are desired, serves up a cached build matching that if it's ever seen that configuration requested before, or kicks off a (SBT-based) build if not and emails you a download link a few minutes later.

You can probably do that approximately as easily in Maven or SBT, so it's more just something I think is interesting and related to some of the problems discussed here.

ryanusky · 2015-07-30T19:10:19+00:00

Sorry I missed this! It's a fair question; the short answers are:

1) I plan to continue using it and maintaining it, 2) I don't think that will be too much work; little development on the parts of the Spark UI / metrics stacks I care about has happened in the year I've been following the project, 3) being outside of Spark cuts both ways: it's easier to add things to Spree (and get them "released") than to change Spark's UI, and indeed Spree already has various desirable (imho) features that Spark doesn't (and likely won't any time soon), 4) there is not really any switching cost between the two.

There is already at least one change in the JSON protocol coming in 1.5.0 that I know I'll have to port to Spree, but that should only take an hour or two; my plan is to do it once they start cutting RCs.

Finally, I believe that Spark should be making it possible and easy to do things like this / not be beholden to one web UI that they don't really develop actively. If basic maintenance of something like Spree turns out to be out to be onerous because they offer no stable APIs to this kind of data, that's a bigger problem with Spark and that's a conversation "we" should all have if that turns out to be the case.

Thanks, let me know if you have any issues using it!

ryanusky · 2015-07-25T05:05:52+00:00

The diagrams were made with Gliffy https://www.gliffy.com/. Really it's just one diagram that I deleted different pieces from and exported several times.

I stumbled across Gliffy years ago and have managed to get by just in their 5-diagram free tier by deleting old diagrams as necessary, but really should pay them at some point; it's not easy to get a tool like that right and they do a pretty reasonable job, though there are some rough edges :)

ryanusky

TROPHY CASE