@p@NonPlayableClown@toiletpaper Pure sheer of habit. In fact I again wish ActivityStreams2 would be an actual format instead of a framework as then it would be a generic command for any post…
@p@NonPlayableClown@toiletpaper Also it's wrong, should be -H 'Accept: application/activity+json' This is why I write scripts for basically everything that more or less has long-options disease…
@lanodan@NonPlayableClown@toiletpaper I saw some really baffling shit about content types in the spec, silverpill pointed them out; apparently cwebber wants to try to assert namespaces in the 'Accept:' header.
@p@NonPlayableClown@toiletpaper The `application/ld+json; profile="https://www.w3.org/ns/activitystreams" ` thing? I feel like that's just typical W3C, it doesn't even makes sense.
But well I'm the kind of bastard who thinks it should just have been something like XML with stylesheets so it renders somewhat sanely in browsers, so URLs no matter what kind of headers you pass still uniquely identity a ressource.
Bring back XSLT? I had the ``joy`` of working with that for a year and change. Could be worse, but also could be better. After experiencing enough app architecture paradigms come and go it starts get tiresome. Given enough time, regardless of the problems each was supposed to solve, it'll just come full circle to being another dumpster fire no matter what.
@toiletpaper@p@NonPlayableClown Sure it's not great, and I'd rather have a much better designed domain-specific language for transforming data.
I don't particularly care about which format but more about how things architecturally work. One shouldn't have to murk around in http headers to request a ressource, that's what URLs are for, dammit. (Although JSON-LD crowd seems to loves to do all the mistakes that XML did and some more instead of learning from it)
> The `application/ld+json; profile="https://www.w3.org/ns/activitystreams" ` thing? > I feel like that's just typical W3C, it doesn't even makes sense.
Turns out every parameter but "q=" has been deprecated as of 9110, but who tries to namespace a content type?
> it should just have been something like XML with stylesheets so it renders somewhat sanely in browsers,
I think it should have just been HTML with proper microdata.
Yeah that works too, although I often wonder how parseable/reliable the thing is, I feel like rel attribute on link/a elements is the only one that truly works.
> Ah, Seamonkey treats it like any other Atom feed (rendered as browser chrome), Firefox won't touch it.
Heh, kudos to Seamonkey there.
For Firefox maybe you disabled XSLT support in Firefox or it wants something extra in Content-Security-Policy. Don't really want to launch Firefox to check though, bastard thing has too much ads/tracking/"default browser [now][later]"/… by default, I just don't want to touch it.
That's an endemic problem with sw dev. It's such a vast field of knowledge that inevitably people who think they're doing something revolutionary end up reinventing the wheel (often badly) for no good reason just because we don't know what we don't know. Googling doesn't always help. I've certainly done it, but thankfully not at scale.
On a slight tangent, personally I like YAML for data presentation. Not because it's bandwidth friendly (not withstanding gzip), but because it's human readable. It's also nice to have a message based format to send separate but related discrete chunks of info. But that's really up to the use-case. I'm sure lots of other people passionately hate YAML, including the folks who have to write the parsers for it. LOL On the plus side, JSON is valid YAML. Several months ago I wrote a Perl CGI website templating engine that represents HTML DOM as YAML data (just for shits and giggles), then abandoned it because it's probably a bad idea. But it's featureful and works fwiw. And the other day I learned about this bad-boy which even though I'll probably never learn/use it, kinda gives me a boner. https://github.com/yaml/yamlscript Can you imagine if someone implemented a fedi protocol using that paradigm? I have little doubt it'd end with a forest of torches and pitchforks marching in the street.
@toiletpaper@lanodan@NonPlayableClown Allegedly perfect, browser says it is rendering in standards-compliance mode, probably something I did but I don't wanna debug text formatting. I am gonna pipe the shit through "fmt -l72" and wrap it in a <pre> tag.
> That's an endemic problem with sw dev.
"Penny-wise but pound-foolish" except for overspecifying the pennies to
such an extent that nobody can get the pennies correct. Many such
cases.
> but because it's human readable.
This is the line everyone uses. This is not my experience.
If 95% of the YAML spec were removed, it would be human-readable. It
is, at least in theory, but in practice it has a lot of punctuation and
ambiguity when reading. I hate JavaScript and I remember when YAML was
what we used because the alternative to YAML was XML and I still prefer
JSON.
Human factors aside, I mean, generating it makes a feller think "If I
made a plain-text data format and I tried to make it Perl, how close
would I get to this?" I mean, off the top of my head:
---
asdf:
- "This is how people think YAML is going to be."
- "This much would be fine."
:jkl:
- "What the fuck was that extra colon?"
- "What does it mean if there's a colon at the *beginning*, too?"
- Under what circumstances are bare strings allowed again?
okay:
wait: "What can you use for keys in associative arrays?"
:wait: "Do these keys collide? It depends on if your language has interned symbols and whether or not it makes you deal with YAML as a massive parsetree."
fuckin:
-
- "What?"
- "What does that mean?"
- baffling: ["Okay, hold on.", "Lemme find the YAML spec.", "Does that even parse?"]
- "Yes, it all parses."
- "I checked! (I didn't read the spec, I just pasted it.)"
@p@NonPlayableClown@toiletpaper YAML to me has way too many ways to end up with either a straight up invalid file or bullshit data to be a good format for human generation. On this side of things, YAML is the JavaScript of data format.
And who the heck not only does versions on a data format but actually uses them, at least at some version they just allowed JSON in, so once in a while I feel like having a yaml2json program, sticking to JSON, and hope the program which dealt YAML on me won't need special YAML semantics.
> I feel like having a yaml2json program, sticking to JSON, and hope the program which dealt YAML on me won't need special YAML semantics.
I feel the same way about HTML vs XHTML. At least the latter encouraged consistent syntax and wouldn't render if the ML wasn't 100% correct. So developers were forced to do it right or not at all. Validators even complain now if you write HTML5 with XHTML syntax (eg. using <br/> vs <br>). If languages don't force developers to use best-practices, more often than not, they won't, and it becomes a shit show overnight.
My love for YAML really started with Perl's Test Anything Protocol. If other languages had have adopted that universally, it would have made test driven dev a lot less pain in the ass imo. To it's credit TAP uses only a very limited subset of the spec. I have to agree that realistically the full YAML spec is kind of an everything AND the kitchen sink sorta deal.
> Well the yaml part of tap could be replaced with JSON fine.
Off hand YAML provides distinct separate messages with "\n---\n", but JSON has no such syntax. So if you send multiple tests' output in a stream you'd have to send them as elements of an array. Which means blocking until all the tests and their respective output are sent, rather than being able to immediately parse discrete chunks each time you encounter the message delimiter. So I think you'd still have to use YAML anyway, and default to JSON syntax for the data parts if that's your preference. Personally that's why I like it, because it's more flexible than JSON in certain situations. YMMV.
Apart from TAP, another cool feature of YAML is anchors/references so you don't have to repeat the same data when it's included in multiple records. In some use-cases that has significant advantages. Kinda like programming in Bash vs Perl. Really depends on the situation which is best.
> Yeah that works too, although I often wonder how parseable/reliable the thing is, I feel like rel attribute on link/a elements is the only one that truly works.
It's reasonable enough, and schema.org was mostly reasonable to navigate last I checked. The problem is no one cares about microdata except search engines, me, some dude that works at Comcast, and IMDB. Everyone wants JSON.
> Heh, kudos to Seamonkey there.
All they had to do was just not remove it; I don't know why Firefox removed it. (Also "live bookmarks". Probably Google's hand up Mozilla's ass when Google decided they were done caring about RSS and started pushing all of those "RSS is dead!" memes on the world.)
> For Firefox maybe you disabled XSLT support in Firefox or it wants something extra in Content-Security-Policy.
Nah, around the time Live Bookmarks were removed, Firefox started popping up the "Save As..." dialog box whenever I hit a feed, and all the "browser.feeds.*" options disappeared from about:config.
@p@NonPlayableClown@toiletpaper Save as even… damn that's somewhat worse than when it would display XML at you where then it could add an infobar thing to ask if you want to open it in another program. But I guess raw XML would scare the normies.
@p@NonPlayableClown@toiletpaper Perl context also reminds me of post-modern architecture where you'd show the ducts. Show the damn ducts once in a while, have courage in your designs. Nobody really is scared of the boiler stuff in the basement because Freddy Krugger, because they've seen the thing before and were fine.
Can't: YAML allows in-document references to other sections of the same document. I am fairly certain that you can blow up most YAML parsers and if I were going to do that, I would start with that mechanic.
> So developers were forced to do it right or not at all.
Developers were forced to do it right or just write "Transitional" in the doctype. The reason XHTML failed was that, while the option to do the sloppy version existed, you could do the sloppy version. HTML5 was an unambiguous improvement. The web is a mess and this is something we will all have to live with forever.
> If other languages had have adopted that universally, it would have made test driven dev a lot less pain in the ass imo.
I have seen TDD chase its own tail until you have to fill out fifteen forms and photocopy your birth certificate just to do the equivalent of `assert(n > 0, "n should not ever be zero here.")` and I personally want to fight anyone that ever touched the rspec code. Wherever I possibly can, I just bounce it through the API: way easier to get full coverage, way easier to reproduce failures and stop regressions, way easier to see the point of a test case so nobody ends up maintaining a test for a function deep in the bowels that is actually dead code. If the API can't trigger the code then the code should probably be removed.
Most TDD exists so that individual cogs at the feature factory can be fired. You see it as a bureaucratic requirement and people churning out nonsense test cases that don't actually test anything, you very rarely see it used as a way to make sure that an API is designed sensibly.
@toiletpaper@p@NonPlayableClown Yeah for me tests are mostly for public interfaces, in fact one thing that I think should be done much more is checking that your API/code examples actually match.
And coverage… the percentage is useless as fuck and line coverage is just bonkers because lines aren't part of the structure of programs, but hey "line goes up" :stonks: Which branches / functions got covered on the other hand is interesting information to have.
I used to be really gungho about TDD, but in more recent years I don't bother with it until interfaces stabilise and then I just bolt on whatever's necessary to keep them that way after the fact. Otherwise, especially in early stages where refactoring is frequent, it's just a pointless make-work project. But as far as tests go, I grew up with Perl and Test::More, which compared to my experience since in other languages, is a breeze to deal with. In fact if there's nothing analogous in whatever language I'm learning du jour, porting Test::More semantics tends to be knee-jerk one of my first side-projects to help me up my skillset.
> Otherwise, especially in early stages where refactoring is frequent, it's just a pointless make-work project.
Yeah; you'd think it'd be more cost-effective to do things to reduce churn than to bail water but nobody wants to take that approach.
The thing I got the most mileage out of was making a spider that just followed all the links on the site. You know, just fuzz some forms, let the thing hammer a form, this helps if you've got the input types nailed down and the client-side validators in place. (Haskell had a facility called "qtest" that was like this but in the small.) So you do that, you can exercise the entire public interface, HTML or some JSON API or whatever you're doing. (Never hurts to do it anyway, as about a million script kiddies will do exactly that, and I'd consider it a failure if they found the 5xx errors or SQL injections or whatever before I did. Hell, maybe just fire off whatever crawler/fuzzer they're using, save yourself some effort.)
> In fact if there's nothing analogous in whatever language I'm learning du jour, porting Test::More semantics tends to be knee-jerk one of my first side-projects to help me up my skillset.
QuickCheck? At least Property Testing has me wanting to automatically send known crash/exploit-prone data exhaustively to function arguments. Stuff like empty string, control characters, "\0", 4096 bytes of '\0' followed by 'a', … to char *; INT_{MIN,MAX}, 0, -1, 1 to int; …
I'd expect it to take a ton of execution time so not at each push/commit/… like a testsuite but at least prior to making releases, but at least execution is bounded in time unlike fuzzers like AFL/libfuzz/…
@p@NonPlayableClown@toiletpaper Yeah pretty much the idea, but at least it's going to be done testing at some point so could set it up to shoot you the logs via email if it found anything.
> I'd expect it to take a ton of execution time so not at each push/commit/…
Well, that's kind of the point: you don't wait for it, you just let the machine spin on it and see if it notices anything. It's not guaranteed to catch everything or even anything but if you just let an automatic fuzzer run while you work, overnight, over the weekend, just leave it running, every bug it *does* find is one that a human didn't have to.
@p@NonPlayableClown@toiletpaper Meanwhile I guess infinite fuzzers like AFL/libfuzz/… would need to log their stuff to IRC or something like that which seems like a recipe for annoying noise.
@lanodan@NonPlayableClown@toiletpaper If metasploit can make it easy for a bunch of skids, I don't know why it sounds unworkable to engineers. Basically you just let it go and if you get a 500 or it gets a 403 by following a link, etc., then you have it alert you.
Or, you know, just deploy it. Weird shit with zero links to it gets picked up by fuzzers, let the script kiddies do the work for you. (As long as you can fix the bugs before they figure out what to do with them.)
@p@NonPlayableClown@toiletpaper Yeah, just tend to pick infinite fuzzers as a waste of ressources, they're effectively bruteforce, meanwhile so many security bugs are the same shit over and over just slightly different codebase/endpoint/implementation.
Yeah. Also I'm having a little brain fog atm, because my neighbour kept waking me up repeatedly and didn't get a decent sleep. So, not 100% on the ball rn.
@toiletpaper@NonPlayableClown@lanodan Well, I mean, there's also the array-valued and float-valued keys, but I think we were talking at cross-purposes, you were talking about utilities existing and I was insisting that there is no function f such that f(yaml) = json and f^-1(f(yaml))=yaml.
@toiletpaper@NonPlayableClown@lanodan The conversion to JSON does not preserve the references. JSON has other restrictions that YAML doesn't have: "[\"asdf\", \"jkl\"]: You cannot do this in JSON.\n3.14159265: Pretty sure this doesn't work, either.\n" parses just fine as YAML but you can't convert it to JSON.
True. I didn't think about circular references. I'm sure that'd work fine in YAML, but blow up rather badly in JSON in the case that the parser tries to expand references by value. This is a matter of being very careful about use-case when choosing one or the other for a given dataset/project.
> Yeah, just tend to pick infinite fuzzers as a waste of ressources,
Your time can be wasted; the computer's cannot.
> they're effectively bruteforce,
Obviously they're brute-force. That's the point: let the machine crank on the tedious stuff and tell it to tell you if it finds anything interesting. This doesn't stop you from doing anything else: whatever you were going to do, you can still do that while the computer grinds. I mean, the other one, having the tests just spider the site, that catches breakage. It sounds trivial but if you consider how many things a site models and in which states those things can be, it catches more stuff than you might expect. Like that bug in Pleroma a couple of years ago where a deactivated user could still get a password reset link.
@p@NonPlayableClown@toiletpaper That one Pleroma bug for example would need you to think about things like states of user-inputs at least a little bit but they're not unknown states, which is more what infinite fuzzers are for.
Like you could take the OpenAPI description and exhaust it all with basically some template engine kind of similar to like the C++ template stuff except it's a bunch of small payloads instead of a monstrous file.
@p@NonPlayableClown@toiletpaper Yeah a dumb QA team hitting things manually just can't, but one that knows how to program can hit those N*M known states.
Meanwhile an infinite fuzzer is going to have trouble getting things like credentials, like there's a handful of somewhat correct ones in at least 64-bit if not 128-bit namespace, so you'd need to at least loop your crawler program/function/… over a list of different kind of credentials.
> they're not unknown states, which is more what infinite fuzzers are for.
Separate thing: infinite fuzzers are for just throwing at something; spiders that go exercise all the features are also brute-force but they are for finding the bugs you bump into when you have a thing with N states, and it is related to another thing with M states. Even the most thorough QA team isn't going to exercise the entire site with N*M states for large values of N and M and that's just two objects.
The machine is simple and it does not get bored; there's no reason not to do this. At any rate, someone will if it's a public-facing web application: skiddies try to cram all kinds of shit into form fields.
@p@NonPlayableClown@toiletpaper Like to give a more concrete example, say you throw the few OpenAPI examples each endpoint has plus generate some data based on the properties you can toss at each endpoint, and you do this for a handful of valid user credentials, one invalid, one unauthenticated.
So endpoint*payloads*creds requests to do, say there's 500 endpoints, average of 500 payloads you can generate per endpoint (pretty generous when most take just few parameters), 20 credentials and request time averages to 1 second (that's quite where I prefer testing functions lol). That means it would take 20000000 seconds which is a bit less than 2 months.
That's a lot but it can just run in the background, plus with some parallelisation it could probably be divided pretty easily by like 10.