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.

I've heard before that it's meant to be re-TRIE-val and therefore is pronounced "tree"

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

Slightly off topic, but I find the author's attempt to use an iterative method (TDD) to derive a recursive algorithm (quicksort) somewhat comical

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!

This comment is meant as a joke

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

I actually from a less technical person's perspective, "cute" error messages humanize errors, showing them that there was indeed someone who made that page they are currently on and not just some soulless computer and thus making solving the problem much more approachable!

Example 1: Chrome's dino page is actually great! Grandma doesn't fear it or call me out of panic the moment she sees it. Imagine if she got something like the default Apache 500 error webpage.

Example 2: the new BSOD. I saw on some other thread that some people hate it, but I think it's clear and directs the inexperienced user to what they could at least try to do

Here I was thinking that the very same group of people that think sl is a funny command line program wouldn't appreciate humanized error messages...

What in your opinion doesn't work with UG testing?

I disagree in general with your second point. Yeah, sure, this could make sense in some situations, but many tools and products exist for the sole reason that they offer a superior workflow and smoother experience than their existing counterparts.

Wasn't there that classic HN post about users not needing Dropbox because any Linux user could do the same with rsync?

I ended up in this current position because I was first interested in their field of work (geospatial work), and secondly skilled in programming. Even if I weren't a programmer I would probably work for them in some other capacity.

I don't feel qualified giving advice but personally I think I would look beyond what is commonly considered "tech". As another poster mentioned, everyone uses tech. When a company's work is sufficiently complex or special, chances are they may not rely on external vendors 100%.

Really out of my depth here but maybe some types of firms where I think there could be some interesting stuff internally:

- engineering - analytics - games - graphics/animations

Counter-anecdote: I'm working at a non-tech company (we build the in-house technical software that everyone else in the company uses) and the experience has been great. We deliver real and immediate value, our clients are our colleagues and there's a great emphasis on UX, user testing and what not as a result.

Yes, there are loads of other problems, especially on the technical side, because tech isn't the company's strong point (our processes, especially revolving around the DB and deployment, are quite a mess) but the right things are in place that make me enjoy my job.

As the other guy mentioned this has nothing to do with GoG. A good data language or library should provide the user (and plotting libraries) copyless, cheap and immutable slices of the data being handled. Javascript just doesn't really have one. It shouldn't be the concern of the plotting library however.

You can do anything with the DOM in javascript - you could create an anchor node then download the file automatically via a.click()

I don't think it's fair to label the failure of checked exceptions as "beginners didn't understand". It's the fact that returning null was deemed an acceptable return value on some types of failure throughout the standard library, rendering the whole idea basically moot since it didn't actually give you much guarantees.

And later on, checked exceptions were incompatible with new stuff like lambdas and streams

Yeah. IMO reducing everything to cost-benefit analysis feels like one of those "Silicon Valley" endeavours the feature article talks about - sounds attractive, but ultimately we ought to grow out of the good/bad one-dimensional thinking

Client side training with the usual python stack sounds like a configuration nightmare. Would it try to use the users GPU if it exists? Would it fallback to CPU? Does your user need a specific GPU card to play?