CornCobs

Yes, they deprecated the CRS field and the current state of geojson handling libraries is pretty messy as a result since geojson does not have versioning!

If you have old geojson in a different projection, will your library respect the crs field or will it simply misinterpret your data?

Wondering if anyone could shed light on the decision to remove it as a standard when projection seems to be a critical part of GIS.

Not everywhere that python is run has access to pip. Sshing into some locked down remote machine and needing to debug some script is a use case that comes to mind.

Isn’t the browser inspector more than sufficient? You get the interactive object inspector in the console, live expressions, log points etc.

For node you it’s possible to hook it up with the browser inspector as well

Something interesting I realized about their choice of name - S7.

1. It's a combination of S3 and S4 obviously.

2. It's also linked to another OOP system called R6. Interesting how it's a step forward one way (6->7) and a step 'backwards' in another way (S->R).

To me it shows the philosophy of not creating something entirely new but improving the existing systems quite nicely!

I actually think this "multi-tiered" system of OOP is quite cool, when compared to languages that stick OOP in your face upfront.

1. Basic users don't even know it's there, they're just calling regular functions.

2. S3 in base is super simple to understand and easy to extend the first time you need to implement your own summary.

3. Full blown OOP with slots and methods is available when you really need it (rare for a user and not library author imo, lists and S3 are sufficient for most things).

The big issue I see is the incompatibilities in the various systems making this "ramp up" not so smooth. But it looks like that's what S7 is trying to address so that's cool.

Yes, though the languages do not support it explicitly you can simulate lazy evaluation by wrapping all your arguments in closures. This way they won't be evaluated until called within the function body.

I too am a Tidyverse shill. Hadley Wickham truly did an amazing job designing the whole ecosystem and API. I personally haven't encountered another API that has given me the same feeling of mastery and empowerment - just the correct blend of expressiveness, cohesion and ease of use.

Of course this is partly attributed to R's great DSL capabilities and making documentation first class. But I've definitely seen terrible APIs in R too.

Wonder if anyone else has had a similar experience with another ecosystem? (Regarding API design)

I'm in a similar boat. I have to use a 3rd party component library written in web components for our react app (esri/calcite-components) and it's a huge pain because * You can't override styles except what is exposed through css variables * They often encapsulate some internal logic which I can't control from React (tbh this could happen with a React library too)

Seconding NewPipe. Though recently it's been unable to load comments and the error banner keeps popping up as a result (no comments may actually be a plus?)

I still use the regular Youtube app for shorts but NewPipe is definitely a better experience overall. My main gripes with the official Android Youtube client: - They made it so annoying to choose your video resolution (Seriously, who tested this and found it better than the old method?) - I can accept not being able to play in the background, but if you lock your screen while in fullscreen mode and then unlock it, there is a very noticeable lag before the app exits fullscreen mode, and in this period you cannot resume playback.

Inline styles don't work with a strict CSP. Have you ever had to work with such a restriction?

What syntax of nim's is the network: ... Used to declaratively construct the neural networks? Is it a macro? Looks really neat!

+1 for mobX. Dead straightforward, does one thing and does it well. Only worry is that it increasingly feels like an outsider in React. I'm working on an app that uses React, web components and mobX, and upgrading to React 18's concurrent rendering breaks stuff, and I'm not sure which of my relatively niche technologies (mobX or WC or maybe the interaction of the 2?) causes it.

Preact has been looking increasingly attractive as a library that does its own thing and nothing more. Anyone knows if preact signals are basically a drop in replacement for mobX?

> They will eventually discover that they’re wrong, and we will have yet further examples of evolution’s devious paths. In my terminology, their dogged search for skyhooks will uncover heretofore unimagined cranes. And precisely because their conclusions will be the opposite of what they hoped to discover, we will take them seriously.

An important part of being able to truly ask oneself if they are wrong is the humility to seriously consider an alternative. The author's treating of ID research as a foregone conclusion, even with his acknowledgment that we could be wrong in the next paragraph, seems rather ironic. Isn't it this kind of hubris that he is precisely calling out?

As a relative outsider to the observability space, I have always wondered this:

Is observability/telemetry only about engineering-related issues (performance, downtimes, bottlenecks etc.) or does it include the "phone-home" type of telemetry (user usage statistics, user journeys)? Looking through the websites of most of the observability SaaSes it seems to only talk about the first. Then how do people solve the second? Is it with manual logging to the server from the client?

> These InteractionHandlers are just objects satisfying a specific TypeScript interface. They’re not coupled to React or hooks or anything like that, which feels quite freeing, honestly. There’s no worrying about stale closures or dependencies or hooks rules - it really is just TypeScript.

> None of the interactions depend on a particular rendering system. We can actually use the DOM as a render target with all its pointer events disabled, and use this interaction system on top, which is quite neat!

In general, I think this is the most important takeaway here. Too often, we couple all our frontend logic to the rendering framework (especially state) when it has no business living in React and being tied to the component lifecycles.

I've had really good experience with MobX for React - separating out all our state into independent observable objects that React simply reacts to. This really cleans up a lot of logic and makes the presentation layer very clean.

In particular, a pattern that I believe in is simply exposing singleton, global stores for various parts of my application - effectively treating them as APIs that the rest of the app can subscribe to.