<travis-ci>
[travis-ci] dkubb/ice_nine#101 (master - 9f552b7 : Dan Kubb): The build has errored.
mbj has joined #rom-rb
<mbj>
solnic: You read my yesterdays message about mutation filtering?
<mbj>
solnic: Would filtering by code be enough for you?
<mbj>
solnic: If you refactor the original source, the mutation "code" will change. So this is an unstable criteria.
<mbj>
solnic: The mutation "code", man I have to rename it to id, is build from the 6first bytes of the sha1 of the mutated source.
lorenzo_off is now known as lorenzo_
namelessjon_ has joined #rom-rb
namelessjon_ has quit [Changing host]
namelessjon_ has joined #rom-rb
namelessjon has quit [Ping timeout: 260 seconds]
skade has joined #rom-rb
postmodern has quit [Quit: Leaving]
snusnu1 has joined #rom-rb
snusnu1 has quit [Quit: Leaving.]
snusnu has joined #rom-rb
mbj has quit [Quit: leaving]
jfredett has joined #rom-rb
breakingthings has joined #rom-rb
snusnu has quit [Quit: Leaving.]
snusnu has joined #rom-rb
mbj has joined #rom-rb
knowtheory has quit [Quit: Computer has gone to sleep]
<kapowaz>
listening to ruby rogues :D
<kapowaz>
solnic: which one is the guy with the really unusual voice?
<solnic>
kapowaz: lol wat? :D
<kapowaz>
around the 9 minute mark he's asking a long question
<kapowaz>
he sounds like he's got a frog in his throat
<mbj>
haha, totally forgot about rubyrouges
<mbj>
tuning in soon
<kapowaz>
most of this is going to go over my head. I'm basically listening in the entirely narcissistic hope that you namedropped me for the logo work, but I suspect most RR listeners don't care about that stuff ;)
<jfredett>
kapowaz: that logo is awesome
<kapowaz>
thanks :) not that I was fishing for compliments! I guess it's just the first time I've done some logo work that's reached a reasonably large audience. Most of my stuff has gone nowhere :P
<kapowaz>
James Edward Gray actually emailed me about doing some work for Ruby Rogues’ (they're trying to get some t-shirts designed), but I just don't have the time to help, sadly.
<solnic>
kapowaz: dooh sorry buddy
<kapowaz>
haha, no no it's fine
<solnic>
I was so stressed out I forgot to say 50% of the things I wanted to say
<kapowaz>
I wasn't expecting a shout out
<kapowaz>
nor should I :)
<solnic>
if logo was mentioned I would definitely say it was your design
<kapowaz>
it's cool though, they all seem genuinely positive about ROM
<solnic>
I will add info about you to the website
<kapowaz>
no rush :)
<solnic>
yeah they are :)
<mbj>
kapowaz: Yeah, helping OSS should list all contributors with archivements!
<kapowaz>
I would still like to contribute to the site somehow, but I have no idea when I'll get time etc.
<solnic>
too bad Josh didn’t make it because he once picked ROM for an episode
<mbj>
kapowaz: I try to do so all the time. But it is HARD.
<mbj>
kapowaz: So I begun to ask people to list themselves via PR :D
<kapowaz>
when I was still at Burberry I found I had time on my hands a lot, but I've changed contracts and now I have far less time.
<solnic>
I’ll be working soon on the website so we could chat about it at some point
<kapowaz>
cool
<solnic>
probably close to the end of the month, currently I’m super busy finishing virtus 1.0.0
<kapowaz>
aye
<skade>
solnic just saw that you added 81 commits :) maybe I should start tracking for my talk :)
<mbj>
solnic: lets merge commit streams for all our projects related to ROM
<mbj>
solnic: We'll look far less DEAD.
cored has joined #rom-rb
cored has joined #rom-rb
<solnic>
mbj: I don’t think anybody thinks we’re dead :)
<solnic>
skade: yeah sorry about that :)
<skade>
solnic: not complaining :)
<solnic>
skade: I can give you a short summary of what changed although the PR’s description should be helpful (?)
<skade>
solnic: the only thing thats a bit unclear to me is how axioms constraints will be handled
cored has quit [Ping timeout: 256 seconds]
<solnic>
skade: they won’t, it’s just meta-data, up to you what you’re gonna do with that
<solnic>
also, dkubb wants to rename axiom-types to something else ;) it’s not really axiom-specific heh
<skade>
okay, that was the missing bitt :)
<skade>
-t
<solnic>
yeah I thing having types that you can extend with custom meta-info should be helpful and make virtus more usuful
<solnic>
s/thing/think/g
cored has joined #rom-rb
cored has joined #rom-rb
<solnic>
see mbj, you have p/d problems and I have g/k problems :D
<mbj>
haha
<skade>
solnic: yes, that sound good
<skade>
by the way, you mentioned on the bugtracker that you might think about removing #attributes and maybe #initialize, is that still planned?
<cored>
hello all
<mbj>
solnic: I'm unhappy with rom-session
<mbj>
solnic: Expect I'll add a big PR to rom-session and rom-relation cleaning up things.
<mbj>
solnic: I think the session should be injected into Rom::Relation
<mbj>
solnic: And Rom::Relation should use by default a noop session.
<mbj>
solnic: If you use a sessionful env it uses the raw Rom::Relations and injects a session via using the original relation and replacing the default noop-session with a rom-session one.
<cored>
there are a lot of small pieces in rom :-)
<cored>
oh
<dkubb>
cored: I did that (partly) for DM1 in dm-ambition, but I would love to see it done for axiom
<cored>
exactly that's what I was talking about
<solnic>
mbj: the reason for proxy and inheritance is that I want the same interface as I said gazillion times
<dkubb>
cored: the idea is the same, it parses the block and turns it into an AST, which can be serialized into a query
<solnic>
you won’t achieve that via injecting things into rom relation
<solnic>
I’m actually surprised we’re discussing this *again*
<cored>
dkubb: so how can this be plugged in inside axiom
<cored>
?
<mbj>
solnic: You'll get it.
<solnic>
no I won't
<solnic>
it’s not possible
<snusnu>
things that are discussed again and again are usually things that aren't completely understood by all parties .. hence discussing them some more is a good thing :p
<mbj>
snusnu: You'll ALWAYS work against a Rom::Relation in my concept
<snusnu>
solnic: <— ^^^^
<snusnu>
:p
<dkubb>
cored: ok, so what would have to happen is a module would be made that adds #select, #reject and #detect to Axiom::Relation
<solnic>
mbj: how are you going to intercept calls to insert/delete/update?
<solnic>
snusnu: no, sorry, I’m too tired discussing things, really
<mbj>
solnic: Lets wait for the PR.
<mbj>
solnic: When I'am in Kenya I have lots of time for OSS.
<solnic>
either refactor everything and make it work now or accept current implementation
<mbj>
solnic: It will have the same public interface.
<solnic>
also, ffs I spent a lot of time on rom-session
<mbj>
solnic: me also
<dkubb>
cored: it would need to parse the proc and turn it into a set of operations to apply to the relation
<mbj>
solnic: And you nuked some of the stuff I need for my ROM :D
<solnic>
so how come you didn’t finish it yet? :P
<mbj>
solnic: And I'm okay :D
<mbj>
solnic: I'm okay you nuked it.
<solnic>
I nuked it because it wasn’t usable, it was missing basic functionality like tracking transient objects
<solnic>
and I’m sorry but now I’m just annoyed because I wanted to add UoW to rom-session
<solnic>
and now I’m gonna just wait for your PR
<solnic>
in order to avoid wasting my time
<dkubb>
I would just let the code speak for itself
<dkubb>
solnic: besides it looks like you've got your hands full with virtus spec rewrites
<solnic>
I’m pretty sure it can’t be done in a different way but I’m curious to see what mbj has in mind
<solnic>
I’m reluctant though because we talked about this so many times
<dkubb>
really too, the external interfaces should be #1 anyway
<solnic>
and yet I haven’t seen the code
<solnic>
session must have the same interface as rom-relation
<solnic>
that’s requirement
<dkubb>
given how early things are still. I would be much more concerned if we got the public interface wrong because it's way harder to change compared to internals
<solnic>
if you inject something into rom relation you will have to complicate rom-relation itself so it talks to some external object
<dkubb>
cored: does working on an Enumerable query interface interest you?
<solnic>
like this no-op session
<dkubb>
cored: it's one of those things that could be started really small, specced, and then expanded as your learning grows. not something that has to be done perfectly right from the start
<solnic>
dkubb: re virtus I’ll be done with it by the end of the month
<cored>
dkubb: it kinda does, yes
<solnic>
mbj: ^
<cored>
dkubb: but as you already know I need some guidence to start up
<dkubb>
cored: it's a super fun problem
<cored>
dkubb: I'm guessig the name will be the same like ambition
<dkubb>
cored: no, you don't have to name it ambition. I just named dm-ambition that because it was inspired by a gem called Ambition released in 2006 or 2007
<solnic>
mbj: can you summerize the concept?
<mbj>
solnic: I dunno why I think I triggered so much with mentioning a different tech approach.
<solnic>
cause I’m seriously intrigued
<cored>
dkubb: got it
<cored>
dkubb: so what should I have to check first?
<mbj>
solnic: Lets stop this, I'll never talk about rom-session anymore. Apart from my PR.
<solnic>
mbj: if you can’t explain this then just do it
<solnic>
just remember that we want to have the same interface
<solnic>
and we don’t want to complicate rom-relation
<solnic>
one more thing, rom-relation should become a proxy for axiom (we talked about it with dkubb)
<mbj>
solnic: I insist of a strong public interface.
<solnic>
this is something to keep in mind when working on session
<mbj>
solnic: But for me the current one is not written in stone.
<mbj>
solnic: So please lets stop this.
<mbj>
solnic: I'll do my stuff and than we can talk.
<solnic>
ok
<dkubb>
cored: first of all, the code in dm-ambition is a bit "spikey", so I wouldn't worry so much in trying to copy it.
<solnic>
mbj: when are you planning to work on it?
<mbj>
solnic: Maybe never.
<solnic>
you could build a POC quickly
<mbj>
solnic: I stop to talk about rom session now.
<mbj>
solnic: Focusing on mutant and dkubb/sql.
<mbj>
solnic: s/maybe never/undeterministic/
<cored>
dkubb: hehehe, you are reading my mind I was about to start from there
<cored>
solnic: I can't relate your face to your voice
<dkubb>
cored: what I would probably do is start with a bit of spiking using the sourceify or parser gem, and using Proc#source_location to understand how you're going to parse the code
<solnic>
mbj: that wasn’t my intention, sorry for sounding so rough, having yet another tough day :/
<cored>
dkubb: let me check those gem's
<mbj>
solnic: Np, I'm under pressure also
<mbj>
solnic: Just make sure my emotions (that are nondeterministic) will not insult someone.
<solnic>
great, now I really want to talk about session, but I won’t ;)
<dkubb>
cored: the main reason I mention parser is that mbj is becoming an expert in it, and there is a sign that some of our other tools will be moving in the same direction
<snusnu>
lol
<solnic>
or maybe I will but with dkubb on the side to not annoy anyone anymore
<dkubb>
heh
<dkubb>
fwiw, I do like the idea of making lots of ROM parts proxies
<solnic>
see mbj ;)
<dkubb>
because it means that improvements to the axiom query interface become supported by ROM
<solnic>
now with the idea of injectible session I really can’t imagine having rom relation as a proxy to axiom
<solnic>
gah, need to think about this, see what you’ve done ;)
<dkubb>
heh
<snusnu>
fwiw, i see no reason why an injected session cannot expose the same interface, in fact, why would it expose anything different? if the public interface is a rom relation, than that can be a proxy and all is well? one less proxy?
<mbj>
I'll close IRC for now. Back later. Avoiding to leak some emotions.
mbj has quit [Quit: leaving]
<snusnu>
lulz
<cored>
dkubb: I see
<dkubb>
cored: I had so much fun writing dm-ambition, but I won't be able to get to something equivalent in axiom for a while still
<dkubb>
cored: dm-ambition was probably the most fun I had working on a dm plugin. if you're interested, be my guest.. I'd gladly give up the fun of writing it if it meant that something could be seen earlier
<cored>
yes
<dkubb>
cored: I also think with some good tests, it would be possible to branch out past where I did and use #map in some simple cases
<cored>
I'm interested because I was checking a .NET application how the develop that and how easly was to implement a similar API between the repository that saves to the database and the one that we had in memory
<dkubb>
cored: a map that contains complex logic, like if/else then it might need to fallback to a "normal" map, but if it's something simple like: relation.map { |tuple| tuple[:id] } then I think it could be parsed and used to configure the query
<dkubb>
cored: yeah, I think you're talking about linq. it's pretty sweet, although a tiny bit too SQL centric, but the syntax is nice
<dkubb>
ok, I've gtg to work, but will bbl
<cored>
dkubb: yes LINQ, but what got my attention in particular was the way they use same interface for implementing query collections indepent of from where they take out the data
<cored>
dkubb: cool, I will checkout the parsers gem meanwhile
<solnic>
snusnu: if we wanted to use an inject noop session in relation
<solnic>
then session becomes the de-facto axiom proxy
<solnic>
and rom relation becomes a proxy to session proxy O_o
<solnic>
trying to wrap my head around it
<snusnu>
solnic: really, i'm not deep enough into session stuff .. my initial thought was this .. ok, the session is "some sort of container stacking up ops" .. if clients only ever use the rom relation which internally uses a session .. what can be the problem with that?
<solnic>
proxying, intercepting certain calls, handling IM
<solnic>
quite a lot of things
<snusnu>
solnic: there's another part to this story tho, and that's the API used to "tell the session about changes" .. there's a few tactics .. one, you (as in the programmer) tell it explicitly .. or, the objects register themselves via some decoupled notification mechanism
<snusnu>
(i tend to like the latter)
<solnic>
it’s pretty dead simple now
<solnic>
session is an extended relation, so it overrides some methods and that’s it
mbj has joined #rom-rb
<mbj>
hehe, I just ate something.
<mbj>
I was totally undershugared.
<mbj>
solnic: This is OSS I'm totally fine with running mbj-session :D
<mbj>
I just was beaten by my GF for not eating something for 10hours.
<mbj>
Was far far away in the devland.
<mbj>
solnic: So soling apoligize if I was "harsh"
<mbj>
solnic: s/soling//
<solnic>
no, I was a bit harsh :D
<mbj>
solnic: So you ate something?
<mbj>
:P
<mbj>
solnic: Lets say it this way I was beginning to become harsh and tried to avoid this.
skade has quit [Quit: Computer has gone to sleep.]
<solnic>
cored: "I can't relate your face to your voice” <= wdym?
<mbj>
solnic: You have a face, and a voice
<mbj>
solnic: And for him it does not FIT
<mbj>
solnic: Its interesting, because I'm always surprised to hear voices for faces or vice versa.
<mbj>
solnic: BTW I was in a very very very very bad mood when we talked about that session thing.
<mbj>
solnic: Got send into the desert by my team again.
<solnic>
mbj: no worries, sorry it turned out this way, wasn’t my intention really
<solnic>
it had a positive side effect though
<solnic>
I’ve been thinking a lot during last couple of hours
<solnic>
and realized that we should treat ROM still as an experimental playground
<solnic>
having said that, I’m not going to spend much time on metrics etc
<solnic>
because it’s wasting time
<solnic>
I can work on full mutation coverage of some small pieces that I know won’t change in the near future
<solnic>
session is clearly not such a thing
<solnic>
I’m aware that it’s a very immature piece of code and the fact I mut-covered it was a mistake
skade has joined #rom-rb
<solnic>
and I’m really intrigued by your injectible session idea but I’m afraid it won’t go in-line with our proxying-to-axiom concept
<solnic>
anyway, this is way too much typing, we should have a hangout to talk this through
<solnic>
I also had a discussion with Henrik on twitter about his experience when building *and using* his minimapper
<solnic>
one of the things he mentioned was that building entire object trees turned out to be a PITA for them, I said - we will have a proxy in front of relations that will lazy load stuff (that’s how it’s done in other DMs)
<mbj>
solnic: So my, lets see what my PR does is - idea fits :D
<solnic>
so, yet another use-case for proxying
<mbj>
solnic: experiment :D
<solnic>
whatever we do, I want us to focus on pushing this forward, I feel like it’s been way too long already
<solnic>
I trust your ideas are good because they worked for you in real world however your use-case was probably a bit specific (I say that after getting to know your session impl)
<solnic>
anyway, if you feel strong about the idea please DO implement it and send a PR but I would love to discuss this in a hangout to be honest with dkubb and martin
snusnu has joined #rom-rb
postmodern has joined #rom-rb
skade has quit [Quit: Computer has gone to sleep.]
<mbj>
solnic: Warning, I love my idea and if it works I'll run mbj-session :D
<mbj>
solnic: Mostly because I already use this pattern for handwritten mappers :D
<mbj>
solnic: I'm very close to "buy out" that code from client :D
jfredett has quit [Quit: Leaving.]
<solnic>
mbj: can you explain it somehow? O_O like…maybe using some pseudo-code?
skade has joined #rom-rb
<mbj>
solnic: include Concord.new(:axiom, :session) :D
<solnic>
mbj: and mapper is what?
<mbj>
solnic: actually it was a session basd mapper
<mbj>
solnic: include Concod.new(:axiom, :mapper)
<solnic>
heh that’s what I suspected
<mbj>
solnic: And it could intercept load/insert/update this way.
<mbj>
solnic: Mapper just was a layer of transformating stuff, like ducktrap
<mbj>
solnic: All opts are dispatched to axiom
<mbj>
solnic: *ops
dkubb has joined #rom-rb
<mbj>
solnic: And but mapped throught the mapper for interception
<mbj>
solnic: I'm talking to my client from that time.
<dkubb>
good afternoon
<dkubb>
whoa, everyone is up late
breakingthings has quit []
<mbj>
dkubb: hehe
<mbj>
tracking down OOM caused by exceptions rescued by a jrubypuma / tomcat
<dkubb>
I haven't used tomcat in production before
<mbj>
hehe
<mbj>
This question is not related to the OOM
<mbj>
its just wierd jruby-rack does not forward contextDestroyed, so a rack app cannot free resources (for example kill threads) on undeploy.
<mbj>
Not that I like the idea the tomcat tries to undeploy a .war and deploy a new.
<mbj>
But my current client is forced to do tomcat, and is forced to allow undeploy.
<mbj>
So I'll most likely end up in forking jruby-rack
<mbj>
solnic: BTW you did a good job at rubyrouges!
<mbj>
solnic: Its really hard to communicate all our concepts/ideas/components/tools and still beeing on topic. Cudos!
<dkubb>
mbj: now we need to get you on the show and explain mutant in more detail
<mbj>
dkubb: Yeah
<cored>
solnic: watch your face in a photo and hearing you talking in the podcast
<cored>
solnic: those two things doesn't seems to match
<mbj>
dkubb: Dunno if such an explanation would be too interesting. The concept is very easy to explain.
<mbj>
dkubb: My talks are full of the mutation testing edge cases
<mbj>
dkubb: False positives, isolation, how to read metrics and how to compare coverage metrics
<dkubb>
mbj: maybe expanded to the development process
<dkubb>
mbj: or something along the lines of including fuzz testing.. so on the "making the code have less bugs" angle
<mbj>
dkubb: I was not exact enough, I dont think the tool matters so much. You have to understand the theory of mutation testing before using the tool.
<dkubb>
yeah
<mbj>
dkubb: And mutation testing is totally new, its goes bejond TDD. And focusing on the actual implemetation is not a good idea.
<dkubb>
it's the mindset, but it helps to have a tool to get started with
<mbj>
dkubb: yeah you got my point.
<mbj>
dkubb: BTW I'm supper happy to see this msifo guy and his PRs.
<mbj>
comment reproduction for unparser *strike*
<mbj>
It does not need that much anymore. Before unparser can be a ROM-stylifier :D
<solnic>
mbj: but you know that this means mapper would now have to become an axiom proxy
<solnic>
which basically leaves rom relation being…what?
<mbj>
solnic: no
<solnic>
no?
<mbj>
solnic: mapper become an axiom proxy => no
<solnic>
but you said it would have insert/update
<solnic>
what that would do?
knowtheory has joined #rom-rb
<solnic>
mbj: ^
<mbj>
solnic: That mapper only maps from tuple => object and object => tuple with doing identity mapp stuff.
<mbj>
solnic: But TBH, I'm not 100% sure anymore.
<mbj>
solnic: Let me rescurect / read that code.
<mbj>
solnic: Or create new.
<mbj>
solnic: For now, I'm not happy and I think we can do better.
<mbj>
solnic: But I think this for mutant/axiom/concord/anima/virtus/rom-mapper etc.
<dkubb>
I'm going to repaste what I sent to solnic in campfire a sec ago:
<mbj>
solnic: I'm never happy
<dkubb>
Piotr Solnica: how do you feel about working on a ROM rubocop config template?
<dkubb>
Piotr Solnica: I like rubocop and I think it would be nice to get a standard template we all use to bring things even closer together. If there are disagreements we can take care of them explicitly in deciding on the config file; sooner rather than later
<mbj>
dkubb: I demand access to that "low latency line to dkubb" also :D
<dkubb>
mbj: I'm most often happy with smaller things
<dkubb>
mbj: come with with bloomcrush! :P
<dkubb>
*work with
<mbj>
dkubb: haha you know that story.
<dkubb>
yeah I know
<dkubb>
maybe we can catch each other later this year
<mbj>
I hope so
<solnic>
dkubb: I’ll get to it
<solnic>
mbj: current design is mostly in-line with the proxy idea
<solnic>
which starts at the gateway level
<solnic>
and could go up through rom relation, lazy proxy and session
<solnic>
and trust me, it’s a very clean and simple solution
<solnic>
I think in this case composition would only make things more complicated
<solnic>
you do remember I tried implementing session like you initially imagine and I failed? right?
<solnic>
I failed because it wasn’t possible to have the same interface w/o basically duplicating it on the session level
<solnic>
mbj: btw why you’re not happy? would it not work for you? if yes then why? what’s missing? what’s blocking you?
<solnic>
or is it just that you have a specific vision and you want to prove that it’s better (which would be absolutely fine)
<mbj>
solnic: its the vision thing :D
<mbj>
solnic: And the inability to track objects by client side generated id over functional style objects.
<solnic>
client side generated id?
<mbj>
solnic: Not tracking by object id.
<solnic>
what we use to track objects could be easily configurable
<solnic>
it’s right now hard-coded but I believe it’d be easy to make it configurable
<mbj>
solnic: I have cases the mapper must decide about the id.
<solnic>
functional style objects? as in immutable ones/
<mbj>
solnic: *the id to track objects under.
<solnic>
?
<mbj>
solnic: jo
<mbj>
solnic: *yes :D
<solnic>
yeah currently session assumes mutable objects
<solnic>
we could extend it to support immutable ones but I’m not sure about the value of such a thing
<solnic>
the whole idea of a session is that you make changes to objects and persist them
<solnic>
what’s the point of using immutable objects there?
<mbj>
solnic: I love to persist immutable DTOs
<solnic>
you should switch to clojure, now
<solnic>
:D
<mbj>
solnic: And load them, mutate them (in functional style) and persist them.
<mbj>
haha
<mbj>
solnic: They dont have mutant :D
<solnic>
I think we could consider supporting that given that it won’t complicate everything now
<solnic>
dkubb: thoughts?
<solnic>
snusnu: ^^
<mbj>
<nitpickforfun>It was supported</nitpickforfun>
<mbj>
But with a big big smile on my face :P
<mbj>
solnic: Du you know: rom is so plugable.
<mbj>
solnic: I said already, I'm totally happy to use mbj-session :D
<solnic>
I like such challenges because if we can easily support immutable objects in session then it would prove that design is flexible but I’m just having hard time wrapping my head around the concept of immutable objects representing mutable data
<solnic>
I mean, I understand the concept I just don’t see the value
<mbj>
solnic: these objects are snapshots
<solnic>
yeah I know
<mbj>
solnic: And lots of domains can be easily via operational transformation
<solnic>
we’d need something that works like datomic
<mbj>
solnic: It has lots of benefits for having the *original* and *future* objects to steer business logic.
<mbj>
s/for/from/
<solnic>
but this way “mutating” an object would have to be an explicit call through session
<mbj>
also an option I did not thought about.
<solnic>
as in, “here session, I’m giving you a new version of an object identified by FOO"
<mbj>
Explicit registration of new state.
<mbj>
Before my mapper was able return an identity for mutated object that would allow the tracker to identify a state change.
<solnic>
which is kinda messy but maybe it would be valuable in some cases when you really want to work with immutable objects
<solnic>
well yeah but it used server-side generated keys
<mbj>
solnic: axiom tuples are also immutable, through they represent mutable data.
<solnic>
well, as I said, it should be easy if not trivial to add registering objects under arbitrary “ids"
<mbj>
yeah
<mbj>
And if we can make this transparent to the rest of the code
<solnic>
this way immutable objects could be tracked too
<mbj>
with delegating the "return me a key to track this object under" to something
<mbj>
I'd be super happy
<solnic>
I actually think it should be possible to do w/o much changes
<mbj>
Yeah
<solnic>
cause it feels like just an addition
<solnic>
rather than a change
<mbj>
hehe
<solnic>
no, I’m serious, but I might be just too optimistic :P
<mbj>
solnic: Interesting question, could you switch to a language without a mutation tester available?
<solnic>
yeah why not?
<solnic>
mutation testing is just a practice that helps in writing better tests and improving design/code quality but I wouldn’t treat this is a blocker to learn a new language
<mbj>
solnic: learn != switch
<mbj>
solnic: Its just intersting for me, I was offered some non ruby gigs, and I realized I wanna do a good job and tooling such as a mutaiton tester becomes more and more important for me.
<mbj>
solnic: And for me mutation testing became "the most important tool"
<solnic>
something worth to mention, and don’t get this the wrong way: it’s *just* a tool
<mbj>
solnic: no way, I understand
<mbj>
solnic: I'm not talking about mutant
<mbj>
I'm talking about an equivalent tool.
<mbj>
With seeing my "before mutation testing" and "after mutation testing" code
<mbj>
I think "this change is not the normal 'you gain experience over time'" ting.
<mbj>
*thing
<solnic>
I think it actually is
<solnic>
maybe not in 100%
<solnic>
but in 90-99% :)
<mbj>
hehe
<solnic>
depending on the actual tool
<mbj>
lol
<solnic>
really, I think over time you will learn how to write tests that will cover most mutations
<mbj>
been there
<mbj>
Than I add new mutations :D
<solnic>
well yeah, but let’s not go too crazy about it
<dkubb>
I can say I'm definately a better tester due to mutation testing
knowtheory has quit [Quit: Computer has gone to sleep]
<solnic>
I’m starting to think the balance is really important too. it adds a lot of extra effort to fully mut-cover a lib so it might not be a great idea to do it in an early stage of a lib
<solnic>
initially I thought it’s great because it helps catching bugs early but now I’m not sure if that’s such a great thing given that it drastically delays releasing things
<solnic>
and by releasing stuff you can actually verify if the code you wrote makes sense
<solnic>
with insanely great test coverage you will only verify if the code you wrote works like you expect it to work but you could’ve made design mistakes that your tests won’t (obviously) catch
<solnic>
so I dunno, just thinking out loud
<solnic>
there are moments where you really really know that what you’re doing is correct but I believe in many cases you only have a gut feel that something is a good idea :P
<dkubb>
I spent well over 10x more time fixing bugs in DM than I did writing the code originally
knowtheory has joined #rom-rb
<dkubb>
the thing is, you never really know if an idea is good until you've used it for a long time
<mbj>
dkubb: So make ideas small :D
<solnic>
we’re building a datamapper, it’s a huge idea :P
<mbj>
haha
<mbj>
yeah
<dkubb>
rom is actually fairly small
<solnic>
dkubb: I hear you, really, I helped you chasing some of the bugs in DM1 a bit and I know it’s hard
<solnic>
but still….what if it turns out there are design flaws in rom/axiom that will be major blockers in many cases and we will have to redesign/reimplement a lot of stuff?
<dkubb>
TDD'ing the code does mean you become the first user of the code, so I would say it's the best first feedback you can have. I wonder if some of the pain we're experiencing is with code that was not properly TDD'd, so it had to go through integration and real world testing before confidence in it could be found?
<mbj>
solnic: I'd bet the average net loc / class is far lower in rom/axiom than dm1, so refactorings should not trigger such a high amount of "descendant code changes"
<dkubb>
rom is tiny compared to DM1 imho
<solnic>
yeah the coupling is so much smaller in dm1
<dkubb>
granted it's because it has less features, but the implementations are simpler
<solnic>
dkubb: you really think TDD will assure you that what you’ve designed and implemented is a good idea? :)
<dkubb>
solnic: not completely, but it's better than having to get something fully working before you can close your feedback loop :P
<solnic>
because, really, if things were that simple…:)
<solnic>
I don’t question values of TDD because it’s something I practice on a daily basis
<mbj>
solnic: TDD feedback loop is fast, compared to "use in production and fail" loop
<cored>
hm
<cored>
comparing dm1 and rom is not fair
<cored>
don't you think?
<cored>
I mean at least at this point in time
<solnic>
yeah you’re right
<solnic>
once we have comparable set of features we can look at the code again and compare
<postmodern>
are we discussing whether to do more of TDD vs. mutation testing API end points?
<solnic>
postmodern: no I’m just questioning keeping 100% mutation coverage at an early stage of a library
<dkubb>
I think we're going around and around where the balance is between release early/release often, and TDD fully
<solnic>
I always TDD but I’m now wondering about 100% mutcov
* cored
wonders how solnic TDD all the time a Rails app
<solnic>
cored: I don't
<solnic>
cored: simple
<cored>
he
<solnic>
cored: I’m talking about lib development
<cored>
got it
<postmodern>
solnic, so i developed a training course, and one of the exercises involved using mutant on some TDD code
<solnic>
postmodern: oh?
<postmodern>
solnic, my TDD style mixes uint and integration
<postmodern>
solnic, the goal was to force the students to test every edge case, so mutant was a sort of fuzzer
<postmodern>
solnic, i did notice that mutant did complain about silly things
<postmodern>
solnic, like not testing the message of a raised exception, when I only cared about the class of the exception
<solnic>
yeah I hate that tbh :)
<postmodern>
solnic, and there are other syntactic things which I've already talked to mbj about
<dkubb>
that specifically could be handled by allowing filtering out of mutations we want to ignore
<postmodern>
also note that currently ROM lacks a TON of tests
<postmodern>
yet mutant passes it
<postmodern>
since most of the tests are for the public API
<postmodern>
i'd encourage shooting for 90-100% mutation coverage, then continue adding tests
<postmodern>
the focus should be on edge-cases and behaviors
<postmodern>
this also makes it easier for developers to contribute back
<postmodern>
since every method and every edge-case has a accompanying test
<postmodern>
that they can run in isolation
<postmodern>
also helps in pin pointing specific locations of regressions
<solnic>
postmodern: I’m only interested in testing my public APIs
<solnic>
guts of the system are implementation details
<postmodern>
solnic, your describing a black box
<mbj>
solnic: Your public api is defined by semantics of the black box (private / protected methods)
<mbj>
solnic: So mutations of the nonpublic api must be killed via observations of the public api.
<solnic>
well, I tried testing everything, it sucked
<solnic>
it sucked so hard, that I hated my own test suites
<solnic>
it sucked so bad, that I stopped enjoying working on those libs
<solnic>
so, I’m sorry, but I won’t be doing that again
<solnic>
once something become a public interface, I will write tests for it
<solnic>
end of story, really
<postmodern>
i find it difficult to contribute to blackbox APIs
<postmodern>
since the slightest mistake bubbles up to the API end-points in odd ways
<postmodern>
also if the project lacks YARD tags, I have no idea what the inputs/outputs of methods should be
<solnic>
well, fwiw the amount of internal private objects are is getting smaller and smaller when the lib evolves
<postmodern>
totally, i suspect we're suffering from DM1 PTSD
bf4 has quit [Ping timeout: 264 seconds]
<solnic>
mbj: killing mutations like that works fine for me
<dkubb>
I need to build that YARD layer that rewrites the methods to add typing information, so that we can make sure our specs pass with it
<solnic>
it leaves room to breath when working on something, I can refactoring stuff w/o changing a shit load of specs and it always moves me towards simpler code, eventually some parts can become public once they become better defined
<solnic>
it’s really simple for me, if I change something w/o changing behaviour and my tests are failing then the test suite is broken
<solnic>
also, with a ton of detailed specs for everything it’s IMHO harder to grasp a project and contribute
<solnic>
so your argument is really weird because from what I’ve seen it’s the other way around, the less tests the better
<solnic>
I also remember that specific case when you wanted to refactor something in rom-mapper and you dropped it because there was no explicit test for that particular object - FWIW this was a very specific case as rom-mapper is at its early stage and you know what? that object was removed eventually heh
<mbj>
solnic: Talking to me?
<solnic>
no, postmodern :)
<dkubb>
it's a balancing act. too many tests, or too many tests of the wrong thing make code too inflexible. too little tests and you can't have confidence that the changes you made are correct
<postmodern>
solnic, also would very much want YARD tags on rom-mapper
<solnic>
oh and btw, blackbox? really? we’re talking about a small % of the library that has on explicit tests
<dkubb>
does rom-mapper have no YARD docs?
<postmodern>
looks like rom-mapper has some tags
<mbj>
rom-session doesnt have them
<mbj>
apart from @api private
<postmodern>
yeah, i was wanting to optimize a ugly method
<postmodern>
but it had no tests or YARD tags
<solnic>
postmodern: and was eventually removed, as I told you, you jumped into a code that was in a flux
<solnic>
ah, so I remembered incorrectly, I removed the class and moved that method to Header
<solnic>
dkubb: both session and mapper has YARD docs
<solnic>
I’m sure yardstick won’t report 100% coverage though
<solnic>
feel free to fix it and maintain it :P
<postmodern>
i guess my argument is that we need more "guidelines" for developers
<solnic>
s/has/have/g
<postmodern>
mutation testing is a good tool to measure the health of the project as a whole
<postmodern>
but developers will be focusing on one specific piece
<postmodern>
in the past, that has been unit-tests and documentation
<solnic>
postmodern: once rom becomes more mature I’m sure the amount of internal private objects will be really small, like 5% small
<solnic>
we will have docs etc
<solnic>
but now I’m more worried to get fundamental things working
<solnic>
like SQL, session with unit of work etc
<solnic>
than to make sure every-single-object-and-method has explicit unit tests
<postmodern>
ah seems fair enough
<postmodern>
then i would just adjust filters on mutant to ignore the minor things
<solnic>
yeah I’m planning to do so
<dkubb>
what would be sweet is something that runs mutant against the code and outputs a config file that has ignore rules for all the unkilled mutations, then you could use it as a todo list much like we do with reek
<solnic>
like mutating warn in virtus :D
<solnic>
dkubb: I like that
<solnic>
sorry but I need to run
<solnic>
good night
<mbj>
dkubb: The reporter has all informations for this.
<mbj>
dkubb: Could be done very easily (if mutant could read a config file :D)
bf4 has joined #rom-rb
<dkubb>
I've thought about this process for other things
<dkubb>
then it's not so much about getting your code to pass a specific metric, it's about reducing the exceptions in the config files
<dkubb>
and this will all be tracked in version control
<dkubb>
I would also suggest that if the config file references something unknown, that should be treated as a warning or error
<mbj>
dkubb: error
<mbj>
dkubb: success / warning / error is so much for me
<mbj>
dkubb: 3 states, like 3 valued logic, should be avoided.
<mbj>
I only place warnings under very rare conditions.
<dkubb>
mbj: that's my preference too
<dkubb>
I just say warning because people don't give me as much opposition if I start with that as a suggestion :P
<mbj>
hehe
<dkubb>
mbj: how would you feel about standardized rubocop config templates?
<mbj>
dkubb: +1
<mbj>
dkubb: rubocop supports config inheritance
<mbj>
dkubb: so our rubocop task could use a devtools shipped one
<mbj>
dkubb: And than we can add overrides project specific