|
Jabor posted:30 seconds is too long imo, our incremental builds take about that long and it's long enough to break your flow. A webpack-dev-server-based incremental build will give you that. You hit save and the page immediately refreshes with the changes. I agree that 30 seconds is far too long to maintain workflow. When folks were throwing around figures of fifteen minutes I assumed we were talking about full-scale CI builds or something.
|
#
?
Oct 25, 2018 19:27
|
|
|
|
| # ? Nov 14, 2025 15:17 |
|
|
NihilCredo posted:case 2 means being able to say 'hey, we have objective evidence that the problem isn't on our side and it wasn't a case of miscommunication, it's *your* software that is not respecting the specs' which saves a crazy amount of time and therefore money The problem is that just because a problem is objectively caused by someone else, doesn't mean that you're not the one who has to "fix" it.
|
|
#
?
Oct 25, 2018 19:36
|
|
|
Doom Mathematic posted:A webpack-dev-server-based incremental build will give you that. You hit save and the page immediately refreshes with the changes. I agree that 30 seconds is far too long to maintain workflow. When folks were throwing around figures of fifteen minutes I assumed we were talking about full-scale CI builds or something. Yeh I'm talking 30 seconds for a full CI build. Local incremental build is milliseconds
|
|
#
?
Oct 25, 2018 19:43
|
|
|
prisoner of waffles posted:attributes are guaranteed to have 0 or 1 cardinality and their order is insignificant tho right but thats how it should be. having an xml tree with multiple elements with the same name is loving stupid in all cases where you arent representing an array. and if youre representing an array, those elements should be isolated in a child element that denotes it's an array. json does it better
|
|
#
?
Oct 25, 2018 20:17
|
|
|
Doom Mathematic posted:The problem is that just because a problem is objectively caused by someone else, doesn't mean that you're not the one who has to "fix" it. No, but it often means you can bill the time spent fixing it.
|
|
#
?
Oct 25, 2018 20:37
|
|
|
no matter what you slap on top of json, you're going to have problems with things like this: code:
|
|
#
?
Oct 26, 2018 21:08
|
|
|
How many message containers do not have problems with integer overflow? If anything JS reads that as a floating point as so is perversely a little better.
|
|
#
?
Oct 26, 2018 22:48
|
|
|
Lol that was fast: https://sqlite.org/codeofconduct.html?latest
|
|
#
?
Oct 26, 2018 23:31
|
|
|
CRIP EATIN BREAD posted:no matter what you slap on top of json, you're going to have problems with things like this: hey so if you're referring to the problem where a precise floating point number such as 4611686018427387904 will get serialised as '4611686018427388000', losing precision, I wrote a module which doesn't do that. if it's not useful or you were talking about something else then that's okay I just thought I'd throw that out there
|
|
#
?
Oct 27, 2018 00:30
|
|
|
qntm posted:hey so if you're referring to the problem where a precise floating point number such as 4611686018427387904 will get serialised as '4611686018427388000', losing precision, I wrote a module which doesn't do that. if it's not useful or you were talking about something else then that's okay I just thought I'd throw that out there the fact that you have to work around that means the standard is completely broken and useless. there's no reason why in a serialized format, THAT IS ALREADY A PLAIN STRING should have to quote an integer to get around the fact that everything is a loving floating point number.
|
|
#
?
Oct 27, 2018 00:33
|
|
|
MrMoo posted:How many message containers do not have problems with integer overflow? If anything JS reads that as a floating point as so is perversely a little better. well, lets see, xml doesnt. also jesus christ interpreting a number value and losing precision is better than breaking? i guess if you aren't transferring anything useful and your a mouth breathing moron that would be ok. json is broken trash for idiots.
|
|
#
?
Oct 27, 2018 00:36
|
|
|
is there a standard for XML serialisation?
|
|
#
?
Oct 27, 2018 00:53
|
|
|
yes
|
|
#
?
Oct 27, 2018 01:00
|
|
|
it’s called JSONx
|
|
#
?
Oct 27, 2018 01:02
|
|
|
mystes posted:Lol that was fast: lol
|
|
#
?
Oct 27, 2018 01:03
|
|
|
old code of conduct was better
|
|
#
?
Oct 27, 2018 01:04
|
|
|
json: works almost all of the time for web apis and is nice to read xml: it's lovely, but will do more than json
|
|
#
?
Oct 27, 2018 01:05
|
|
|
im glad templedb has settled on a reasonable coc
|
|
#
?
Oct 27, 2018 11:18
|
|
|
akadajet posted:xml: it's lovely, but will do more than json also it has a schema language that can be used to enforce syntactic correctness of esoteric things JSON didn’t feel the need to standardize like timestamps
|
|
#
?
Oct 27, 2018 14:54
|
|
|
ComradeCosmobot posted:also it has a schema language that can be used to enforce syntactic correctness of esoteric things JSON didn’t feel the need to standardize like timestamps tbh idk if i want my serialization format to be so opinionated as to stipulate a timestamp format so i just do what everyone else does and pray that dates are iso-8601 or seconds since the epoch and if not 
|
|
#
?
Oct 27, 2018 15:26
|
|
|
God forbid that your serialization format stipulate (or even just allow you to stipulate) how things are serialized.
|
|
#
?
Oct 27, 2018 15:28
|
|
|
if you want a more expressive type system for your serialization format, just use protobufs. of course, it's not as portable, but that's the price you pay for complexity. in both xml and json you soon land in having to serialize almost everything as a string anyway.
|
|
#
?
Oct 27, 2018 15:37
|
|
|
if the date format you're using in json can't be found on this page then welp
|
|
#
?
Oct 27, 2018 15:46
|
|
|
brap posted:if the date format you're using in json can't be found on this page then welp 2018. gada 27. oktobris
|
|
#
?
Oct 27, 2018 16:06
|
|
|
TheFluff posted:if you want a more expressive type system for your serialization format, just use protobufs. of course, it's not as portable, but that's the price you pay for complexity. in both xml and json you soon land in having to serialize almost everything as a string anyway. how aren't protobufs portable
|
|
#
?
Oct 27, 2018 16:48
|
|
|
Sapozhnik posted:how aren't protobufs portable Well, if you're not using one of the dozens or so languages that have protobuf libraries then it isn't very portable, is it?
|
|
#
?
Oct 27, 2018 17:12
|
|
|
Finster Dexter posted:Well, if you're not using one of the dozens or so languages that have protobuf libraries then it isn't very portable, is it? probably faster to implement it on your platform than chase infinite serialization bugs
|
|
#
?
Oct 27, 2018 18:05
|
|
|
jit bull transpile posted:probably faster to implement it on your platform than chase infinite serialization bugs yeah, that's fair
|
|
#
?
Oct 27, 2018 18:24
|
|
|
what language _doesn't_ have a protobuf binding in tyool 2018?
|
|
#
?
Oct 27, 2018 18:49
|
|
|
qntm posted:hey so if you're referring to the problem where a precise floating point number such as 4611686018427387904 will get serialised as '4611686018427388000', losing precision, I wrote a module which doesn't do that. if it's not useful or you were talking about something else then that's okay I just thought I'd throw that out there
|
|
#
?
Oct 27, 2018 19:10
|
|
|
TwoDice posted:what language _doesn't_ have a protobuf binding in tyool 2018?
|
|
#
?
Oct 27, 2018 19:17
|
|
|
Peeny Cheez posted:Srsly. Perl has at least one protobuf implementation. it would be really weird if it hadn't to be honest, that's a totally perl thing to have an implementation of everything
|
|
#
?
Oct 27, 2018 19:35
|
|
|
Perl probably just has an implementation of some other programming language which has an implementation of protobufs.
|
|
#
?
Oct 27, 2018 19:49
|
|
|
toiletbrush posted:I don't know if it's still the case, but the commonly suggested JSON library for .NET used to spot 'date like' strings in JSON requests and reformat them into it's own format, even if the field being deserialised is a string, making validation that a date was provided in a certain format a massive pain in the rear end/impossible. The author still insists this is the correct behaviour. god drat what the gently caress
|
|
#
?
Oct 27, 2018 20:34
|
|
|
AggressivelyStupid posted:god drat what the gently caress
|
|
#
?
Oct 27, 2018 20:43
|
|
|
lol gently caress newtonsoft.json, it was one of my constant headaches from my C# days
|
|
#
?
Oct 27, 2018 20:59
|
|
|
my favourite issue came from not even using newtonsoft.json but a lovely object database that apparently used it internally, because if you tried to retrieve a serialized Dictionary<string, object>, any nested objects would be returned as Newtonsoft.JObjects instead of dictionaries.
|
|
#
?
Oct 27, 2018 21:05
|
|
|
even if I had no context of this discussion, seeing Newtonsoft.Json I could tell immediately it was a library targeted at a microsoft language
|
|
#
?
Oct 27, 2018 21:21
|
|
|
the date sniffing in newtonsoft json only happens if you are using dynamic typing and have date sniffing on. you should not be using dynamic typing so it will never be an issue.
|
|
#
?
Oct 27, 2018 21:41
|
|
|
|
| # ? Nov 14, 2025 15:17 |
|
|
microsoft needs to do a hostile takeover of newtonsoft.json, fix the bullshit and release it as System.Json in netstandard2.1 or whatever the gently caress so that library authors never have to (??) deal with a dependency conflict related to it ever, ever, ever again java has a similar problem where the popular json library (jackson) ships mutually incompatible breaking changes in minor releases and every library takes a dependency on it so inevitably as a consumer you have to do trial and error to pin the jackson version to something mutually compatible yourself in your project.
|
|
#
?
Oct 27, 2018 21:48
|
|