kleech has quit [Remote host closed the connection]
kleech has joined #rom-rb
snusnu has joined #rom-rb
snusnu has quit [Quit: Leaving.]
cored has joined #rom-rb
d-snp has joined #rom-rb
d-snp has left #rom-rb [#rom-rb]
skade has joined #rom-rb
knowtheory has quit [Ping timeout: 256 seconds]
knowtheo1y has joined #rom-rb
breakingthings has joined #rom-rb
kleech has quit [Remote host closed the connection]
kleech has joined #rom-rb
skade has quit [Quit: Computer has gone to sleep.]
jfredett has joined #rom-rb
snusnu has joined #rom-rb
jfredett has quit [Client Quit]
jfredett has joined #rom-rb
kleech has quit [Remote host closed the connection]
kleech has joined #rom-rb
<mbj>
snusnu, solnic: Time for beeing critic on a a thought experiment of mine? 5min
<snusnu>
mbj: ok, if you promise to never ever write Snusnu again
<snusnu>
:p
<mbj>
snusnu: sorry
<mbj>
snusnu: I realized this to late
<snusnu>
mbj: hah no worries, i just hate the look of capital S
<mbj>
snusnu: So my thought experiment.
<mbj>
snusnu: Given a domain model, implemented in java.
<mbj>
snusnu: And a nice set of service objects exposing interfaces for all use cases.
<mbj>
snusnu: And most of these use cases take primitives or DTOs, and return primitives or DTOs
<mbj>
snusnu: The DTOs a re POJOs
<mbj>
snusnu: Setup done :D
<mbj>
snusnu: And I'm programming against this service objects from ruby, obviousely I'm under jruby.
<mbj>
snusnu: And I hate the jruby round trip and the additional penalty of loading the domain model and service object instances, (spring context).
<mbj>
snusnu: So I begun to "mock" the service objects interfaces in a PORO mock, so 95% of my unit tests and most of the integration tests can run against the mock under "fast round-tip MRI"
<mbj>
snusnu: So I had to duplicate the java DTOs.
<mbj>
snusnu: Also I mapped some of the "java only" constructs to ruby semantics etc.
<mbj>
snusnu: Now this mapping code grew a lot. And I'm planning to write a declarative DSL
<mbj>
snusnu: Where you can map java DTOs to ruby DTOs and wrap java ServiceObjects to service objects that behave like they where POROs.
<mbj>
snusnu: Currently I do this by "hand", and it grew over 2k loc, gross.
<mbj>
snusnu: This DSL would also be able to "check" the mapping via java reflection API.
<mbj>
snusnu: It would not allow to map a ruby object into a java.lang.String for example.
<mbj>
snusnu: Would this DSL/project have a use outside of my domain?
jfredett has quit [Quit: Leaving.]
<mbj>
snusnu: Is this a common enough scenario to pulish it as opensource?
<mbj>
snusnu: I hope you could follow me.
<snusnu>
mbj: i can follow you, but i have no idea if that's common enough
<snusnu>
mbj: i just know that *i* wouldn't need it
jfredett has joined #rom-rb
<mbj>
snusnu: hehe
<mbj>
snusnu: I think I could use ducktrap
<mbj>
snusnu: For that DTO mapping
<snusnu>
mbj: imo you should ask yourself this: does it really help *you*? or is it an "excuse" for doing what you like more, where eventually your client is the only one who "benefits"
<snusnu>
mbj: not everything that can be done, should/must be done … :)
<mbj>
snusnu: I'm asking myself the question :D
<mbj>
snusnu: That is the reason for a thought experiemnt.
<mbj>
snusnu: The benefit, a strong and separated lib to do the mapping will do the job FAR better than my ever growing handcoded mapper.
<snusnu>
mbj: i would ask myself at least this: can *i* reuse it at some point? and even more, do i *want* to do that kind of thing again, therefore implying a need for it in the first place
<snusnu>
mbj: don't get me wrong, i see the benefits for that particular client project, and i see how you'd like to code such a thing more than continuing hand written stuff … i wonder tho, do you want to do that more than other oss projects of yours?
<snusnu>
mbj: and of course, there's the question of will the client pay for it :p
<mbj>
snusnu: The client would accept I externalize the mapper
<snusnu>
mbj: i dunno dude, it's up to you obviouly, of course it could be done
<mbj>
snusnu: And I'm thinking if this could/should be part of ducktrap.
<snusnu>
mbj: depends, ducktrap certainly needs *nothing* that particularly makes some specific java/jruby scenario easier
<mbj>
snusnu: Whats your opinion? (ducktrap-extension)
<mbj>
snusnu: It would be an extension
<snusnu>
mbj: of course you're free to do whatever with ducktrap :) … but yeah, normally, in our oss projects, we generalize when we've faced the same situation at least a couple of times
skade has joined #rom-rb
<snusnu>
mbj: so yeah, i dunno, i can totally see how you're tempted to generalize this for your app, i've no idea how useful it would be outside of that
skade has quit [Quit: Computer has gone to sleep.]
<mbj>
snusnu: Thx. I'm thinking a littebit sharper about this prob now.
kleech has quit [Remote host closed the connection]
skade has joined #rom-rb
skade has quit [Quit: Computer has gone to sleep.]
knowtheo1y is now known as knowtheory
skade has joined #rom-rb
kleech has joined #rom-rb
kleech has quit [Ping timeout: 256 seconds]
jfredett has quit [Quit: Leaving.]
bf4 has quit [Ping timeout: 248 seconds]
jfredett has joined #rom-rb
bf4 has joined #rom-rb
snusnu has quit [Quit: Leaving.]
snusnu has joined #rom-rb
<mbj>
snusnu: Any news from rubyrouges recording with solnic?
<mbj>
snusnu: Click the link NOW and I'm confused.
<mbj>
snusnu: But I expect you nuked backports +1
<snusnu>
mbj: heh sorry, didn't wait for an answer, it was too obvious that this is a leftover, there wasn't even a dep on backports anymore
<mbj>
snusnu: hehe
<mbj>
snusnu: But after I clicked the link I was "!!!"
<snusnu>
heh
<mbj>
:P
<snusnu>
and then you read the commit msg ...
<mbj>
Than did time calculus
<mbj>
And I was like "YEAH" :D
<snusnu>
mbj: wdyt about
<snusnu>
Deprecate expect { }.not_to raise_error(SpecificErrorClass) or expect { }.not_to raise_error("some specific message"). Using these was prone to hiding failures as they would allow any other error to pass. (Sam Phippen and David Chelimsky)
<snusnu>
taken from rspec changelog
<snusnu>
i get shitloads of warnings when running mutant on rbnacl (which was the reason i had to remove the require backports from anima)
postmodern has joined #rom-rb
<snusnu>
imo rbnacl should have 100% mutation coverage
<mbj>
snusnu: its okay to remove not_to raise_error, but keep to raise_error
<mbj>
snusnu: As they did.
<snusnu>
mbj: so we can't expect correct error messages anymore?
<snusnu>
(trying to remember what i do with my own stuff here, heh)
<snusnu>
mbj: also btw, how does mutant handle code that depends on ffi anyway?
<mbj>
snusnu: We can expect on error messages and expections
<mbj>
snusnu: note the "NOT" in the changelog
<mbj>
snusnu: they only depreciated the expectation of the inverse :D
<mbj>
snusnu: as I read the changelog expect(expression).to raise(Foo, "message") will still work.
<mbj>
snusnu: From mutants POV its just ruby code.
<mbj>
snusnu: The tag was after the push on a rev that wasnt on gh
<snusnu>
ok, so it's tagged and released properly i assume
<mbj>
jo
<mbj>
jo
<mbj>
Just changed gem.description pls review
<snusnu>
mbj, namelessjon_: mutant results for rbnacl (to be taken with a grain of salt cause of the enumerator.so exceptions): http://pastie.org/8317720
<mbj>
snusnu: I expect these numbers are totally invalid because of the crashes :D
<snusnu>
probably, yeah
<snusnu>
mbj: can i help with any info, so you can fix mutant or report a ruby bug if need be?
<mbj>
snusnu: minimal reproduction
<mbj>
snusnu: So output the mutated code somehow, change the code and run it.
<snusnu>
damnit i knew you would say that
<mbj>
snusnu: If it still crashes you have a ruby/ffi bug.
<mbj>
snusnu: If not its also a ruby/ffi bug. Because mutant does literally NOTHING that that chould crash ruby in this way.
<snusnu>
ok that's too much for now, but i'll not forget about it
<mbj>
snusnu: its easy peasy
<mbj>
:D
<mbj>
I'll show you,
<snusnu>
not if you'd see the output it produces
<mbj>
mom
<snusnu>
i literally don't feel like searching the offending stuff