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.
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.
+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.
Dad has a Mazda. Can vouch for this 100%. It's very clear to me when I drive it that their car interfaces are very deliberate and properly designed. That rolling knob thing which controls the screen is amazing and I wish it were standard
The next course of action would be to split your distance calculation into multiple steps - a few dimensions at a time.
Then we need to decide on an order to these comparisons - what about using entropy derived from the training data?
Then as a further improvement, what if the order need not be constant, depending on which group the data point is closer to? And what if not all dimensions need to be considered?
Before you know it, woah! You've reinvented trees!
Not exactly. These tree models are ensemble methods, meaning they comprise several trees. Each individual tree may be small, but it is difficult to pinpoint explanations when that tree is but one amongst a forest
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.