Readit News logoReadit News
doctor_eval commented on U.S. Department of Defense – Detecting Agile BS [pdf] (2018)   media.defense.gov/2018/Oc... · Posted by u/rareitem
doctor_eval · a year ago
While this document starts strong and has some good points, it strongly conflates “scrum” with “agile” and goes downhill pretty quickly.

> wrong answer: what’s a sprint cycle?

You don’t have to have sprints to be agile. What’s important are the four values.

The manifesto says, “Individuals and interactions over process and tools” but this document then goes on to talk a lot about specific processes and tools.

It’s a trap!

doctor_eval commented on "Security is our top priority" is meaningless   blog.waleson.com/2024/07/... · Posted by u/jtwaleson
WalterBright · a year ago
I bought a chainsaw recently for $10. I then bought about $100 of kevlar armor to wear while I use the saw.

No money => no safety

Take a look at history as far back as it will go. Safety expenses only happen when the money is there.

Next time you see someone using a chainsaw, take a look at their protective equipment. If they work for a company, they're likely wearing:

1. ear protection

2. face shield

3. helmet

4. kevlar gloves

5. kevlar chaps

6. kevlar boots

If they're some rando with a saw, odds are pretty good they have none of that on. They won't spend their own money on their own safety. It's only deemed essential if someone else is paying for it.

doctor_eval · a year ago
This is just rubbish. Safety arises from multiple dimensions - Kevlar-threaded armour is a single, last line of defence that helps only when everything else has failed.

Actual safety comes from training, practice and operations - such as understanding how the tool works, what unexpected dangers exist, what techniques to avoid, the state of the immediate environment, prioritising safety (eg by not creating time pressure) and the design of the tool itself (eg chain guards and anti whip mechanisms)

By the time your Kevlar armour comes into play you are well outside the safety zone and deep into the shit your pants zone.

doctor_eval commented on "Security is our top priority" is meaningless   blog.waleson.com/2024/07/... · Posted by u/jtwaleson
doctor_eval · a year ago
> The needs of security are opposed to the needs of a convenient user experience. Improving one typically hurts the other.

I must be Dr Contrary tonight but this strikes me as bullshit.

SSH is more convenient that telnet. Passkeys are more convenient than passwords. TouchID and FaceID are more convenient than passwords.

In general, security is an afterthought that is inconvenient to developers to add back. But in the digital world I haven’t seen many examples of security being less convenient than the alternative.

(I am writing this from an airport and definitely do not assert that this applies to the built environment.)

doctor_eval commented on "Security is our top priority" is meaningless   blog.waleson.com/2024/07/... · Posted by u/jtwaleson
WalterBright · a year ago
Safety is a luxury that profit enables.

Increased productivity => increased profits => more safety

Nothing comes for free.

doctor_eval · a year ago
Safety is not a “luxury enabled by profit”. It’s one of many necessary dimensions for efficiently creating value over time.

If you are a sole trader and you fall off a ladder and hurt yourself because you took some stupid shortcut, the cost is extremely high.

If you work for someone and they make you do something stupid that hurts you, the cost to them has traditionally been relatively low, so they are motivated to push you because that’s better for them. Fortunately, in most modern countries this is no longer the case.

Safety only becomes a “luxury” when capital becomes concentrated into the hands of people for whom other people are disposable.

doctor_eval commented on Eight Years of GraphQL   magiroux.com/eight-years-... · Posted by u/fagnerbrack
megadal · a year ago
> This is nonsense. GraphQL queries are simple HTTP requests, with no more complexity than REST. You POST a query string and some JSON

The complexity of GraphQL in fact begins there, and also sort of explains a lot of why GraphQL is all but simple: Why am I using a query language instead of just passing an AST via JSON, a data format every general purpose language supports very well these days?

The answer to the above question, and most of GraphQLs other complexities: Some arbitrary design decision.

Another example: GraphQL could've easily been expressed as a REST API, even an Open API. From what I have seen, with the help of VC backing and FAANG endorsement, GraphQL mostly rose to replace JSON:API, which accomplishes pretty much all of the same goals in just JSON (and is RESTful).

One big issue of GraphQL is also that API clients tend to suck. That's not a problem for OpenAPIs.

And again, why is this the case? Some arbitrary design decision.

I feel like in general, someone creating a new DSL where it's not needed (and is obviously designed to look cool rather than actually be expressive), is a good sign they're just writing the software to stroke their ego rather than reach a meaningful end.

That's why in all the promo material for GraphQL you only see the query language, and not all of the actual setup required to send a request or even what an actual GraphQL HTTP request looks like. GraphQL, the framework, is not actually as simple and elegant as GraphQL the query language attempts to portray it as.

It's almost like someone came up with a query language for fun then came up with all the details of how a web server would utilize it afterwards.

Even today, GraphQL markets itself only as a query language (A query language for your API). When, as you have already mentioned, it is more than that.

That's why most developers know vaguely what GraphQL is ("Oh, that one language") but not how it actually works in practice. And when they actually encounter it, it feels almost like a betrayal, because it's nowhere near as simple, sleek or elegant as all the marketing they saw suggested.

At least, this was my experience when having to deal with a third party GraphQL API (funny enough, they migrated from REST, see ShipHero).

doctor_eval · a year ago
These are just assertions with little to back them up. As TFA says, you can make all the same claims for REST. And GraphQL works the same as REST. But instead of a complex mishmash if positional and named parameters, it has a super simple query structure.

When you create a stack of REST APIs, you’re creating a DSL. But it’s a DSL with arbitrary and frequently undocumented relationships between objects, no type safety, and masses of hidden complexity.

GraphQL is simple. If you don’t think it’s simple, you don’t understand it.

> One big issue of GraphQL is also that API clients tend to suck. That's not a problem for OpenAPIs.

The clients are unnecessary. You can get ridiculously complex clients for REST, too. But you can also use GraphQL just using fetch().

The only material difference between the two from a client perspective is:

* REST gives you everything, even if you don’t want it

* GraphQL requires you to request what you want using a minimal query language.

GraphQL also lets you perform multiple queries in parallel, on the server, which REST can’t easily do.

REST is a PITA for any data model that’s more complex than CRUD.

doctor_eval commented on Eight Years of GraphQL   magiroux.com/eight-years-... · Posted by u/fagnerbrack
dudus · a year ago
I've veen reading about graphql forever and never understood it. Your comment finally made it click for me. Do you happen to have any more documentation around your method of working?
doctor_eval · a year ago
Unfortunately I’m on a bus to the airport for a couple of days so I’m a bit constrained.

If you know Postgres, I would recommend taking a look at Postgraphile. It’s awesome, and comes with an explorer web UI that really helps (GraphIQL with extras). Everything happens in real time. so if you update a view, the UI updates.

There are lots of GraphQL clients but many of them do all sorts of crap you don’t need. I just use graphql-request which is super simple. But of course you can just use fetch() too.

There are also lots of “standards” for GraphQL that make it seem more complex than it is. Ignore that stuff and just start playing with a good server like Postgraphile.

Good luck!

doctor_eval commented on Eight Years of GraphQL   magiroux.com/eight-years-... · Posted by u/fagnerbrack
georgyo · a year ago
Wait, people are using graphql for private, not exposed, backend apis?

Who would torture themselves like that?

Isn't the whole point that your frontend can make the exact queries it needs and load the exact data it needs?

Namely, last I checked, client libraries for working with graphql are only good with JS. I tried working with graphql a few years ago in python and the only two client libraries absolutely sucked. Server libraries were great, but python clients sucked, badly. I ended up writing bare requests with a hardcoded heredoc for the query and endless square brackets to get the fields for the little data I needed.

Maybe the situation improved dramatically in the last three years, but I can't imagine so dramatically.

I wouldn't pick graphql as a private backend API in a million years. Well, maybe if ever single service was written in nodejs with no possibility of using other languages.

doctor_eval · a year ago
This is nonsense. GraphQL queries are simple HTTP requests, with no more complexity than REST. You POST a query string and some JSON and it’s done. If your client makes it harder than that, don’t use it.

Here’s my workflow for creating an API with Postgraphile:

    create view graphql.object as select some,columns from table;
(That’s it)

It’s trivial to query it with curl, I’d give an example but I’m afk rn.

I’ve been using GraphQL for about the same amount of time as in the article and it solved a bunch of problems for me.

It’s so easy to use, and saves so much time - once you spend the time to understand it.

doctor_eval commented on iOS 18 could 'sherlock' $400M in app revenue   techcrunch.com/2024/07/16... · Posted by u/signa11
doctor_eval · a year ago
I’ve always felt that writing apps for Apple devices is more like creating phone accessories than building products.

Apple cares about selling iPhones and other devices. If your idea can help them sell more, and they can do it better, they will.

I think that’s perfectly natural and OK - and what’s more, I think it’s on the app developers to understand this and to plan for it.

You might get a few years head start on Apple, but you gotta be able to read the tea leaves.

doctor_eval commented on For advertising, Firefox now collects user data by default   heise.de/en/news/For-adve... · Posted by u/firebaze
jillesvangurp · a year ago
Which will lead to counter moves by alterative browsers and websites and Google risking the loss of browser market share. If you think this is unthinkable, just look back at Microsoft's dominance of the browser market twenty years ago. Exactly like Google is doing they were pushing through all sorts of user hostile stuff via internet explorer. Before Chrome came along, Firefox was one of the few holdouts against them. Internet explorer users were dealing with all sorts of crap. Popups, popunders, all sorts of viruses, cross site scripting attacks, etc. Mostly that was just a mix of poorly designed features but there was also MS trying to get into search and advertising and they were trying to abuse their defacto monopoly to do that.
doctor_eval · a year ago
I don’t disagree with you in principle, but this history is not quite right. IIRC the IE6 team was shut down. Basically only Mozilla and Apple were building browsers at scale until Chrome came along.

I might be misremembering?

doctor_eval commented on How do jewellers capture every last particle of gold dust? (2017)   ft.com/content/0512638c-b... · Posted by u/EndXA
candeira · a year ago
A friend of mine had an art studio at the Nicholas Building, and I got to speak with a jeweller who told me that he still did a lot of bespoke work in wedding rings, especially for tradies who would otherwise wear down store-bought rings because they were solid gold and therefore softer. I don't remember the details, but he specialised in harder alloys that are nevertheless mostly gold, and therefore "good as gold" for a wedding ring.

Would that be your partner?

doctor_eval · a year ago
Not my partner, but I bet they knew each other, it was a great little community and she was there for the better part of 20 years.

Great parties in the 00’s!

u/doctor_eval

KarmaCake day5374May 4, 2019
About
mark -at- commandquery.com

I’m building software to help small bus and coach companies.

View Original