UK Company named "><SCRIPT SRC=HTTPS://MJT.XSS.HT> LTD" forced to change it

Re:UK Company named "><SCRIPT SRC=HTTPS://MJT.XSS.HT> LTD" f... by crdrost on Friday October 25, 2024 @08:15PM (#41951374)

That advice is 90% because developers are lazy. Like we'll write

    const csv = rows.map(cols => cols.join(','))
                    .join('\n')

because we are too lazy to write the more correct,

    const esc = cell => `"${String(cell).replace(/"/g, '""')}"`
    const csv = rows.map(cols => cols.map(esc).join(','))
                    .join('\n')

(And perhaps something slightly more efficient but slower that only quotes each cell when it needs to be escaped.)

I caught myself doing it the other day, Go has a JSON library and here I was too lazy to define a struct,

    w.WriteHeader(500)
    fmt.Fprintf(w, `{"error": %q}`, err.Error())

Is %q a JSON-compatible format? I have no idea without reading some source code! Almost certainly it won't \u-encode weird characters. That might be OK, I think the only stuff you really have to escape in JSON strings is newlines, backslashes, and double quotes? And %q probably handles those. Maybe it breaks on ASCII control characters...

But yeah, we are meant to always use a library because we have deadlines and we are willing to compromise a whole lot of quality to deliver on them.

[ Parent | on HN ]

Re:UK Company named "><SCRIPT SRC=HTTPS://MJT.XSS.HT> LTD" f... by wruza on Friday October 25, 2024 @09:06PM (#41951647)

Both cases are the result of library/runtime/env designer not thinking about the crowd. If csv.esc(s) and json(x) were available right away, without imports even, you wouldn’t have to decide whether it’s fine. Fmt should just have %j.

Specifically json and unjson I make globally available in all my projects. If I used csv more often than once in a decade, I’d have csvesc(s) too.

Sometimes you read some stdlib reference and wonder what they were thinking with things like System.out.println and without one-line one-arg readtext(), tojson(), fetch() and so on. It’s like a kitchen with all appliances still in boxes and all utensils in a tight vacuum cover. Everything is there, but preparation friction makes it absolutely unusable.

[ Parent | on HN ]

Re:UK Company named "><SCRIPT SRC=HTTPS://MJT.XSS.HT> LTD" f... by lyu07282 on Saturday October 26, 2024 @07:45AM (#41954160)

I don't think the problem we are talking about is lazy programmers or the availability of libraries.

People think hard things should be easy and with less "friction". If I want to output a string why should I have to know what the difference between stdout and stderr is? If I write CSV to a file why do I need to know the difference between CRLF and LF, and UTF-8 and UTF-16 or what a BOM is? At the end of all of this you end up with a company named 'W""oopWoop;' crashing the banking industry.

So no, you should know all of that, and more or get the fuck out of my industry.

[ Parent | on HN ]

Re:UK Company named "><SCRIPT SRC=HTTPS://MJT.XSS.HT> LTD" f... by wruza on Saturday October 26, 2024 @09:00AM (#41954479)

For me it is. I feel the friction and how it disrupts the parallel flow of multiple lines of thought on the code, cause you have to stop and implement a stupid method. Also have seen this many times in less experienced or less patient programmers, who inlined lots of code that should have been a library and cut corners in there due to time, mental and other pressures. Providing them a set of tools they could paste (poor platform) into a globally loaded module improved their jobs a lot.

I think the high horse here is a bad point cause it simply claims it must be hard for no good reason. It’s not even complexity-wise hard, you just have to (metaphotically) unpack your instruments every time you use them. That’s bs at all experience levels and it must be obvious to anyone who works in a shop. Ime, the problem isn’t knowledge, but inconvenience.

[ Parent | on HN ]