KnobbleMcKnees

Hard agree. They also glossed over JS using a single threaded model precisely to avoid the huge mental overhead of dealing with multi-threaded models (I'm saying this is why it happened and this is the problem they aimed to solve, not advocating either way).

The other thing they've missed in why people moved to react in droves is so simple it's possible we've just forgotten it because it's become such a de-facto approach: co-location of declaration, behaviour and styling.

React took us out of the "X belongs with all the X things" mental model and allowed us to create isolated "X does this and looks like this" things that require far less mental overhead to drop into while making changes to a potential foreign codebase.

This is _exactly why_ Facebook preferred React to the status quo. Engineers changing one thing in one place with predictable effects is wonderful for teams operating at wide/deep scales.

Again, I'm not advocating for any of this, I just don't think skipping over history or twisting it into an unrecognisable ball gives any forward momentum to conversations about the evolution of UI/UX.

>Not happy about this post. Instead of asking to stop, they should do just what they suggest, without further ado - distribute the income to the ecosystem devs the way they see fit. Make it transparent, make application to these funds possible, make feature bounties, write it besides the donation button.

Additional admin that will lead to more costs in a self-fulfilling cycle. This is a bad idea. People who are donating are already doing so with intent. Trying to gues where their money would be best placed is playing unnecessary financial games. They're a software developer, not a pension fund manager.

>Once someone stops donating, it is unlikely they will put up the effort of continually researching on which client/dev to support. This would be much better handled by Jellyfin maintainers.

They're already using the client just as they're using Jellyfin, how is this any more effort than what they've put into donating to Jellyfin directly?

The qualities of sets that arrays don't have (and vice versa) are irrelevant to the point of neither being implicitly representable in XML.

You're either providing complex objects as properties or you're providing a list of complex objects. Worse, you can have a combination of both. Without a schema it is not possible to infer whether either or both is happening.

Yeah this was what I was going for, same point stands

No you've misunderstood my point. This doesn't work for cases where one child is in fact a property that is a complex object.

XML claims to solve the problem of attributes vs children but then falls short at the first hurdle by not discerning between a single complex object as an attribute and an array of complex objects as children.

JSON and YAML do not have this problem as they are explicit in their representation.

YAML example:

    parent:
        child: name

vs

    parent:
      - child: name

Try converting each of these to JSON. The former will give you an object property called child, the latter will give you an array property called child with one element

This is a bad take. Let me sum up.

>>“I need to configure this server and the server needs to know if this value is true or false.” >No, that’s bad. Don’t do that. That’s not a good use for XML.

First, the primary case that people use YAML for is not appropriate for XML? I don't agree with this but, taking it on face value, it creates a YAML strawman to attack.

Second, the rest of the argument boils down to "I don't like how floats are parsed in my language of choice". Guess what? You're storing your version strings in the wrong data type. Stop storing semver and it's variants in floating point types, that's not what they're for.

Finally, this is ultimately a "considered harmful" article, which is always a red flag.

That arrays point is such a weakness in XML that I rarely see addressed. Arrays and lists are such a common data structure in almost every programming language of the past 40 years that not having first class syntax for representing them is absurd and a huge weakness that makes XML a non-starter for me.

I agree with this, and also in a complimentary way, but it all seems very non-idiomatic for Go. But I am not a Go expert by any means.

Which, they didn't. Per the aforementioned hardware safety features.

Extremely broad and reliable rule of thumb: hardware safety features > software safety features

I couldn't have guessed that Sheerness had a natural scorpion population and yet somehow it isn't surprising either.

You reminded me of this [0] fantastic review of Sheerness in Kent. Blackpool is mentioned several times in comparison.

[0] https://www.reddit.com/r/unitedkingdom/comments/u2vu5x/i_thi...

There are lots of hardware features that enable cutoff (such as thermal runaway detection) but that's irrelevant to situations in which the environment has not been prepared for printing.

For example, your workshop may be well ventilated during the day and completely closed up at night. All the safety features in the world don't add up to a 100% safe usage experience for any piece of hardware. You don't want your printer doing this for the same reason you don't leave your table saw running when locking up for the night. Technically safe, but unadvisable.

Oh, so, without experience. Understood.

It also works where you don't have ssh to tunnel files, which is true for many servers in many professional environments.

Is that not coming from experience of working at a software company? As I believe you said elsewhere

The common use I'm referring to is similar to the OP, which is using it as a framework for assessing risk. In particular, aligning a team on the "known unknowns" is critical to building the confidence and alignment needed as a group to be able to deal with unquantifiable/inestimable risk.

> The more attention we give AI, the more it will be profitable for sites to use it to gain advertising revenue, and the more money will be given to it's development.

Pretty obvious slippery slope fallacy.

No he didn't, it was needlessly confusing and the fact that it introduced uninformed and unresolved intrigue for him and his wife goes entirely against the point he was trying to make. The reason being that: context is everything. When we structure a project status report this way, context is high and the audience desires new information over and above further context unless the balance changes.

Starting with "I'm okay" was the right thing to do in context: an unexpected call from a child at an ominous time of day is the context, and knowledge of their safety is therefore paramount. But following it with a riddle about bulls is useless nonsense in the same context.

Putting that aside, I didnt really appreciate this either:

>Though a bit angry

Angry at your son for being in a car accident? Was this before or after finding out the reason for the accident? Where is this context and why isn't it provided in the same structure you just outlined several paragraphs earlier?

I agree and this is a practical method that I've seen work well in several companies I've worked for. However I think there's a bigger problem that contributes to the loss of "spark" that the author strangely didn't address at all.

The fruits of labor grow ever higher. By which I mean: In the early days of a startup the problem space is ripe and plentiful, the impact you can have is outsized, and the pool of people with which to share it is the smallest it will ever be.

As a company grows, all three of these factors are subject to strain. The problem space becomes sparser, outsized impacts are recognised further up the ever-growing hierarchy, and the pool of people with which you're sharing your impact becomes larger and recognition becomes shorter lived and more diffuse.

I work for a company that's fully distributed, and do ~2k miles a year, almost exclusively to visit family.

Your halfway-house "build your life around your career" mentality appealed to me in my early 20s when I was on starter salaries and was unmarried and childless. That is no longer the case and you couldn't - as I've had the pleasure of telling several interviewers - pay me to return to it.

I'm actually British but I was appealing to the er, status quo in this case!

>256YB drives

Ah yes, Yagnibytes.

That was Donald Rumsfeld!? I always assumed this came from some techie or agile guru given how much it's used as a concept in project planning.

Whenever I'm sat in a four mile tailback at 6pm, I often look at everyone in the cars around me and, if they make eye contact, I give them a little nod and a smile, as though to say, "We chose this. This was a great choice".

I believe the part about hard coding production data was referring to recreation of the bug, not implementing the solution which the author describes subsequently as "a couple of array functions".

There's a fair bit of hand waving going on with technical details throughout but I don't think it's badly intended, more aimed at keeping the focus on the organisational issues described.

Again you are free to read it how you wish, biases and all.

I called his writing shitty. I like George and have used a lot the tools he's written over the years. I've made similar tools myself. Are you so offended that I have a single critical opinion of him? Because that's a reflection of you, not I.

The implication was that his technical knowledge is very good and his writing is not, but you missed that while you were getting angry.

I'm more confused because I thought the first rule of Elm was that you'll never meet anyone that uses it

I don't wish him any ill and hope the same... But it's been over a decade since I started following him and if there is a trajectory to maturity and quality in his writing, I haven't been able to track it.

And that's putting aside his recent Twitter drama ...