awful programming: feature flags and suffering

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > awful programming: feature flags and suffering

«‹›1114 »

NihilCredo: Jun 6, 2011; iram omni possibili modo preme:
plus una illa te diffamabit, quam multæ virtutes commendabunt

CRIP EATIN BREAD posted:

don't use jvm serialization

Can you expand? I've never done more than dabbling with JVM langs. Are you supposed to write manual serialization / deserialization functions as a matter of best practice?

# ? Feb 23, 2019 19:21

Adbot: ADBOT LOVES YOU

# ? Apr 19, 2024 23:47

gonadic io: Feb 16, 2011; >>=

NihilCredo posted:

Can you expand? I've never done more than dabbling with JVM langs. Are you supposed to write manual serialization / deserialization functions as a matter of best practice?

you're supposed to use an actual serialisation format. json, protobuf, loving xml, whatever it doesn't matter as long as you actually pick one based on your needs and the information you need to convey.

jvm serialisation is supposed to be one generic fits-all-needs but it actually fits none. you shouldn't be serialising arbitrary objects and you certainly shouldn't be deserialising them.

# ? Feb 23, 2019 19:27

DONT THREAD ON ME: Oct 1, 2002; by Nyc_Tattoo; Floss Finder

NihilCredo posted:

Can you expand? I've never done more than dabbling with JVM langs. Are you supposed to write manual serialization / deserialization functions as a matter of best practice?

No there are just very high quality open source serialization libraries and everyone uses those instead of the built in

# ? Feb 23, 2019 19:28

DONT THREAD ON ME: Oct 1, 2002; by Nyc_Tattoo; Floss Finder

I think I broke rust:

code:

#[test]
fn test_3() {
    assert_eq!(true, true);
}

when i run the test:

code:

error[E0308]: mismatched types
  --> src/testing/new_year_chaos.rs:52:5
   |
52 |     assert_eq!(true, true);
   |     ^^^^^^^^^^^^^^^^^^^^^^^
   |     |
   |     expected u32, found struct `std::vec::Vec`
   |     in this macro invocation
   |
   = note: expected type `u32`
              found type `std::vec::Vec<_>`
   = note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)

i'm trying to write some macros which i'm really really bad at and then this started happening. my macros aren't that crazy and i've removed them from scope. i did a cargo clean. no idea what's going on i feel like i'm missing something really simple

e: i figured it out. I was defining this macro and it was interfering with the one in std:

code:

#[macro_export]
macro_rules! line {
   ($($x:tt)*) => (vec![$(stringify!($x)),*]);
}

DONT THREAD ON ME fucked around with this message at 20:36 on Feb 23, 2019

# ? Feb 23, 2019 20:33

gonadic io: Feb 16, 2011; >>=

DONT THREAD ON ME posted:

I think I broke rust:

i tried it on the playground and couldn't recreate. i recommend making a new project that has just that test and see if it happens, maybe push to github, then clone and see if it happens.

# ? Feb 23, 2019 20:36

DONT THREAD ON ME: Oct 1, 2002; by Nyc_Tattoo; Floss Finder

gonadic io posted:

i tried it on the playground and couldn't recreate. i recommend making a new project that has just that test and see if it happens, maybe push to github, then clone and see if it happens.

See my edit!

# ? Feb 23, 2019 20:37

gonadic io: Feb 16, 2011; >>=

just saw your edit, that's pretty fucky with macros not using qualified paths and instead just looking for poo poo in scope

# ? Feb 23, 2019 20:38

DONT THREAD ON ME: Oct 1, 2002; by Nyc_Tattoo; Floss Finder

gonadic io posted:

just saw your edit, that's pretty fucky with macros not using qualified paths and instead just looking for poo poo in scope

yeah i'm a bit surprised. the error is happening because assert_eq! calls panic! which calls line!, and none of these are qualified. There must be a reason for that because it seems pretty obvious. I'll investigate and open a bug if one doesn't exist.

# ? Feb 23, 2019 20:40

dick traceroute: Feb 24, 2010; Open the pod bay doors, Hal.; Grimey Drawer

I wrote something like this on Friday

code:


Assert(true, false);

In a test

# ? Feb 23, 2019 20:52

crazysim: May 23, 2004; I AM SOOOOO GAY

dick traceroute posted:

I wrote something like this on Friday
code:
Assert(true, false);
In a test

Sometimes I do that to quickly and brainlessly see the stdout my test runner captures.

# ? Feb 23, 2019 21:45

NihilCredo: Jun 6, 2011; iram omni possibili modo preme:
plus una illa te diffamabit, quam multæ virtutes commendabunt

gonadic io posted:

you're supposed to use an actual serialisation format. json, protobuf, loving xml, whatever it doesn't matter as long as you actually pick one based on your needs and the information you need to convey.

jvm serialisation is supposed to be one generic fits-all-needs but it actually fits none. you shouldn't be serialising arbitrary objects and you certainly shouldn't be deserialising them.

I didn't even know jvm had its own serialisation format, I was talking exactly about converting an inline class to json / xml / whatever.

Is the runtime representation such that a serialization library can recognize an inline class and automatically convert it to and from either { "personAge": { "age": 15 }} or { "personAge": 15}? And if so, is there a recommended convention or did they leave it to the main library authors to decide?

# ? Feb 23, 2019 22:03

Arcsech: Aug 5, 2008

dick traceroute posted:

I wrote something like this on Friday
code:
Assert(true, false);
In a test

idk that�s not too uncommon

we have a �fail(String reason)� in our test base class that does basically this that�s mostly used in callbacks that shouldn�t be called, but is sometimes otherwise useful

# ? Feb 23, 2019 22:09

pseudorandom name: May 6, 2007

NihilCredo posted:

I didn't even know jvm had its own serialisation format, I was talking exactly about converting an inline class to json / xml / whatever.

Is the runtime representation such that a serialization library can recognize an inline class and automatically convert it to and from either { "personAge": { "age": 15 }} or { "personAge": 15}? And if so, is there a recommended convention or did they leave it to the main library authors to decide?

the runtime representation precisely stores the exact object graph and the reason you don't use Java's native serialization is that precisely representing the object graph is a arbitrary code execution vulnerability waiting to happen

# ? Feb 23, 2019 22:34

Arcsech: Aug 5, 2008

NihilCredo posted:

I didn't even know jvm had its own serialisation format, I was talking exactly about converting an inline class to json / xml / whatever.

Is the runtime representation such that a serialization library can recognize an inline class and automatically convert it to and from either { "personAge": { "age": 15 }} or { "personAge": 15}? And if so, is there a recommended convention or did they leave it to the main library authors to decide?

just use Jackson

e: or gson

e2: to answer your question, the answer is yes, there is a convention, it�s called �java beans� and it�s really over engineered like a lot of java poo poo, all you really need to know is your objects fields should be private and have getters and setters of the form �getField/setField� except for Booleans which should be �isField/setField�

e3: just to emphasize the point, do not use the built in Serializable interface, ever. it is a recipe for disaster in multiple ways. use a library and standard serialization format instead. but many of them want use to use the getter/setter stuff

Arcsech fucked around with this message at 23:25 on Feb 23, 2019

# ? Feb 23, 2019 23:18

CRIP EATIN BREAD: Jun 24, 2002; Hey stop worrying bout my acting bitch, and worry about your WACK ass music. In the mean time... Eat a hot bowl of Dicks! Ice T; Soiled Meat

Jackson is amazingly fast.

But yeah, I am usually very specific about my serialization. Always use a DTO, always make it immutable, and be explicit about the serialization via annotations.

The better route is to generate streaming serializers/deserializers from a schema like amazon does for the AWS SDK.

# ? Feb 23, 2019 23:27

Arcsech: Aug 5, 2008

I�m not gonna edit that post again but also keep in mind that java beans have nothing whatsoever to do with spring beans, because java has the reputation it does for a reason

# ? Feb 23, 2019 23:28

carry on then: Jul 10, 2010; by VideoGames
(and can't post for 10 years!)

spring weenies are some of the most annoying people at meetups and i say that working on a java ee appserver lol

# ? Feb 24, 2019 00:01

Doom Mathematic: Sep 2, 2008

NihilCredo posted:

Can you expand? I've never done more than dabbling with JVM langs. Are you supposed to write manual serialization / deserialization functions as a matter of best practice?

There are also vulnerabilities associated with this kind of thing, I think, because the Java serialization format tells the deserializer what class it represents an instance of, rather than you, the programmer, specifying this. So the deserializer just runs away and constructs an instance of whatever class it was told to construct. That can be any constructor of any class your JVM has available. That constructor can have any conceivable side-effect.

# ? Feb 24, 2019 00:02

DONT THREAD ON ME: Oct 1, 2002; by Nyc_Tattoo; Floss Finder

Java has ruined abstraction for an entire generation of programmers.

# ? Feb 24, 2019 00:35

Feisty-Cadaver: Jun 1, 2000; The worms crawl in,
The worms crawl out.

the built in serialization is also being straight up removed in a future jdk iirc

# ? Feb 24, 2019 00:35

Doom Mathematic: Sep 2, 2008

Feisty-Cadaver posted:

the built in serialization is also being straight up removed in a future jdk iirc

Good to know!

# ? Feb 24, 2019 00:53

eschaton: Mar 7, 2007; Don't you just hate when you wind up in a store with people who are in a socioeconomic class that is pretty obviously about two levels lower than your own?

Krankenstyle posted:

macos-only sounds somewhat macOS-only??

what I�m saying is that much of the project is intentionally not macOS-only, and what is macOS-only might not be that hard to swap for something else

eschaton fucked around with this message at 01:57 on Feb 24, 2019

# ? Feb 24, 2019 01:13

kitten emergency: Jan 13, 2008; get meow this wack-ass crystal prison

DONT THREAD ON ME posted:

Java has ruined abstraction for an entire generation of programmers.

composition rulz, inheritance droolz

# ? Feb 24, 2019 04:34

FlapYoJacks: Feb 12, 2009

uncurable mlady posted:

composition rulz, inheritance droolz

Inheritance is fine if you ever go more than one layer down.

# ? Feb 24, 2019 05:13

DONT THREAD ON ME: Oct 1, 2002; by Nyc_Tattoo; Floss Finder

ratbert90 posted:

Inheritance is fine if you never go more than one layer down.

# ? Feb 24, 2019 05:34

CPColin: Sep 9, 2003; Big ol' smile.

ratbert90 posted:

Inheritance is fine if you always go more than one layer down.

# ? Feb 24, 2019 06:00

pokeyman: Nov 26, 2006; That elephant ate my entire platoon.

ratbert90 posted:

Inheritance is fine? go, layer down!

# ? Feb 24, 2019 06:23

Soricidus: Oct 21, 2010; freedom-hating statist shill

Arcsech posted:

e2: to answer your question, the answer is yes, there is a convention, it�s called �java beans� and it�s really over engineered like a lot of java poo poo, all you really need to know is your objects fields should be private and have getters and setters of the form �getField/setField� except for Booleans which should be �isField/setField�

beans are terrible. hope you didn�t want to have immutable objects, or really to enforce any kind of invariant, because we�re gonna force you to add arbitrary mutation methods to everything!

at least jackson provides a way to use constructors instead of setters if you add enough annotations, so you don�t have to use beans. never use beans.

# ? Feb 24, 2019 09:40

Stringent: Dec 22, 2004; image text goes here

DONT THREAD ON ME posted:

No there are just very high quality open source serialization libraries and everyone uses those instead of the built in

Not in Swift! The Codable protocol is loving tits and the Swift team has every right to be exceptionally proud of it.

# ? Feb 24, 2019 10:30

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

on anroid your app usually ends up with 2+ entirely different serialisation protocols, lol

# ? Feb 24, 2019 10:36

Aramoro: Jun 1, 2012

Soricidus posted:

beans are terrible. hope you didn’t want to have immutable objects, or really to enforce any kind of invariant, because we’re gonna force you to add arbitrary mutation methods to everything!

at least jackson provides a way to use constructors instead of setters if you add enough annotations, so you don’t have to use beans. never use beans.

We have a huge chunk of EJBs and you know its not too bad. Like you have to have the methods but they don't need to do anything. And it's not as if you're serializing/deserializing them yourself. Immutable properties are fine and I don't think I've ever wanted to make an immutable bean for any reason.

Aramoro fucked around with this message at 15:43 on Feb 24, 2019

# ? Feb 24, 2019 15:40

akadajet: Sep 14, 2003

ratbert90 posted:

Inheritance is fine if you ever go more than one layer down.

# ? Feb 24, 2019 15:52

bob dobbs is dead: Oct 8, 2017; I love peeps; Nap Ghost

Paging monocqc, paging monocqc

Work is doing a big rear end state machine that will be the foundation of the business (like, if it goes wahoonie-shaped enough there will be lawsuits)

It seems prudent to test it with property based testing. But it's going to be in a Ruby StateMachine gem dealie and it's like 90% written so probably not gonna be able to redo it in a lang that's got a real quickcheck thing. Ruby has a generator quickcheck lib with shrinking but no state machine testing bit

I was thinking about using one of those calling out to Python from Ruby deals to use Hypothesis but i was wondering if you've seen a similar situation before or have any comments

bob dobbs is dead fucked around with this message at 16:08 on Feb 24, 2019

# ? Feb 24, 2019 16:00

AggressivelyStupid: Jan 9, 2012

the thought of a state machine that isn't on paper is so foreign to me right now

# ? Feb 24, 2019 16:43

MononcQc: May 29, 2007

bob dobbs is dead posted:

Paging monocqc, paging monocqc

Work is doing a big rear end state machine that will be the foundation of the business (like, if it goes wahoonie-shaped enough there will be lawsuits)

It seems prudent to test it with property based testing. But it's going to be in a Ruby StateMachine gem dealie and it's like 90% written so probably not gonna be able to redo it in a lang that's got a real quickcheck thing. Ruby has a generator quickcheck lib with shrinking but no state machine testing bit

I was thinking about using one of those calling out to Python from Ruby deals to use Hypothesis but i was wondering if you've seen a similar situation before or have any comments

yeah I've seen that suff; I've used it as well. Unsurprisingly I did it with stuff like erlport which lets you use Erlang to call out to Python or Ruby -- I had a demo app testing Python from Erlang for that.

So a bridge from python to Ruby for hypothesis would make sense, and it's pretty drat usable as well (probably more than any other framework). They more recently added stateful tests to the lineup (https://hypothesis.readthedocs.io/en/latest/stateful.html) which is most likely where you'll want to go to test state machines. At the core, the whole thing is about coming up with a simpler straightforward model of your actual system and giving random walks through it.

the core of this kind of test is to check if the model successfully predicts what the system does. I'm putting in bold because that's the core of it. You don't just want to random run the system and see "oh yeah that looks like the right output", you want to base a kind of execution schedule based on the model ("if I am in state x and I do a thing, then I get this output and should now be in state y"); the model is essentially your understanding of the state machine, and if your understanding is correct and maps to the system, then you're good. The model's value is directly proportional to its predictive value.

So that should be fine to do, and if you're really feeling risk, you may want to go for even more formalism and use formal model checking. I have never used it, but TLA+ looks really good for that kind of stuff. See Hillel Wayne's talk on it or his book on it.

# ? Feb 24, 2019 16:43

MononcQc: May 29, 2007

AggressivelyStupid posted:

the thought of a state machine that isn't on paper is so foreign to me right now

here's some pseudocode

code:

lamp {
  init() {
    this.state = OFF
  }

  pull_chain() {
    if this.state == OFF:
      this.emit_light();
      this.state = ON;
    else if this.state == ON;
      this.stop_light();
      this.state = OFF;
  }

  private emit_light() {
    print "light is on";
  }

  private stop_light() {
    print "light is off";
  }
}

main() {
  desk_lamp = new lamp();
  desk_lamp.pull_chain(); // outputs: light is on
  desk_lamp.pull_chain(); // outputs: light is off
}

now make sure that all the actions and transitions and calls make sense at the right time.

# ? Feb 24, 2019 16:50

bob dobbs is dead: Oct 8, 2017; I love peeps; Nap Ghost

MononcQc posted:

yeah I've seen that suff; I've used it as well. Unsurprisingly I did it with stuff like erlport which lets you use Erlang to call out to Python or Ruby -- I had a demo app testing Python from Erlang for that.

So a bridge from python to Ruby for hypothesis would make sense, and it's pretty drat usable as well (probably more than any other framework). They more recently added stateful tests to the lineup (https://hypothesis.readthedocs.io/en/latest/stateful.html) which is most likely where you'll want to go to test state machines. At the core, the whole thing is about coming up with a simpler straightforward model of your actual system and giving random walks through it.

the core of this kind of test is to check if the model successfully predicts what the system does. I'm putting in bold because that's the core of it. You don't just want to random run the system and see "oh yeah that looks like the right output", you want to base a kind of execution schedule based on the model ("if I am in state x and I do a thing, then I get this output and should now be in state y"); the model is essentially your understanding of the state machine, and if your understanding is correct and maps to the system, then you're good. The model's value is directly proportional to its predictive value.

So that should be fine to do, and if you're really feeling risk, you may want to go for even more formalism and use formal model checking. I have never used it, but TLA+ looks really good for that kind of stuff. See Hillel Wayne's talk on it or his book on it.

Yeah, i considered the model checking but Hypothesis is much easier to use. The founders are like decades experience compliance veterans, we got a few bootcamp grad noobs to do the literally hundreds of integrations we need, then there's a couple kids like me doing general computer touching, so we are in the weird position of large bits of the codebase being "lol ok if it goes down" and a little bit being "lol no" (the basic reason why we're using Ruby in the first place, also it's all compliance poo poo so no perf requirements). But pbt is great for checking either. Thanks for the advice!

bob dobbs is dead fucked around with this message at 17:00 on Feb 24, 2019

# ? Feb 24, 2019 16:58

akadajet: Sep 14, 2003

MononcQc posted:

here's some pseudocode

code:

lamp {
  init() {
    this.state = OFF
  }

  pull_chain() {
    if this.state == OFF:
      this.emit_light();
      this.state = ON;
    else if this.state == ON;
      this.stop_light();
      this.state = OFF;
  }

  private emit_light() {
    print "light is on";
  }

  private stop_light() {
    print "light is off";
  }
}

main() {
  desk_lamp = new lamp();
  desk_lamp.pull_chain(); // outputs: light is on
  desk_lamp.pull_chain(); // outputs: light is off
}

now make sure that all the actions and transitions and calls make sense at the right time.

new requirement: if you pull on the chain and hold it the light will toggle between 3 different brightness settings.

# ? Feb 24, 2019 16:59

MononcQc: May 29, 2007

bob dobbs is dead posted:

Yeah, i considered the model checking but Hypothesis is much easier to use. The founders are like decades experience compliance veterans, we got a few bootcamp grad noobs to do the literally hundreds of integrations we need, then there's a couple kids like me doing general computer touching, so we are in the weird position of large bits of the codebase being "lol ok if it goes down" and a little bit being "lol no". But pbt is great for checking either. Thanks for the advice!

yeah pbt is a super pragmatic offer there where you get a very practical check of your system but without needing to prepare the whole handling of formal methods and then ensuring that the implementation still sticks and so on.

A piece of advice I would give is to start pbt with a very simple property, like "here are 2-3 calls we allow and know work, and we'll see if it can stay up without crashing". Then iteratively add more calls and more checks and build it up that way. Otherwise, a test failure is usually happening when your "model" and the actual system disagree on what should happen, and it's very hard to know which is wrong as it could be either.

# ? Feb 24, 2019 17:02

Adbot: ADBOT LOVES YOU

# ? Apr 19, 2024 23:47

bob dobbs is dead: Oct 8, 2017; I love peeps; Nap Ghost

this is not in the first single-digit time i've used pbt, it's just the first time in ruby instead of happy happy python-or-functional-lang-land

# ? Feb 24, 2019 17:13

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > YOSPOS > awful programming: feature flags and suffering

«‹›1114 »