<robertjpayne>
dkubb: I was looking at either ArangoDB or FoundationDB
<robertjpayne>
I'm a mobile app developer trying to develop my own PaaS that has a transactional NoSQL data store.
<robertjpayne>
I'm sick of these horrible MongoDB implementations to have no regards to data integrity :(
<dkubb>
robertjpayne: to get started, wdyt about working on the ArrangoDB with mbj? that might be easier than starting from scratch yourself
<robertjpayne>
dkubb yup
<robertjpayne>
I like ArangoDB more than FoundationDB seems more complete for what I'm attempting to do too
<dkubb>
yeah, I mean, I think we would support a MongoDB implementation but I totally get the data integrity issue
<dkubb>
mbj's experience with ArangoDB was pretty awesome
<dkubb>
also, one of the Arango devs is starting to get involved with rom development too
<robertjpayne>
dkubb: MongoDB has great purposes, I love it for certain things.. just the lack of transactions really makes developing backend APIs a bit of a mess.
<robertjpayne>
cool
<robertjpayne>
rom looks awesome thus far once you wrap your head around it
<dkubb>
yeah, I feel like we're on the right track
<dkubb>
it's still early, but the pieces we have are fairly high quality, well tested, etc.. I'm also very confident that some of the processes and tools we're using will result in better code and stronger systems.
<dkubb>
my hope is that we "prove" it with ROM and then we have something we can point to when trying to spread these ideas to the wider community
<dkubb>
we've all already proven it to ourselves with the smaller gems, and with client work, but this will be a bit larger
<robertjpayne>
dkubb: Would be great, the ability of ORMs to map to multiple backends these days I feel is imperative.
<dkubb>
robertjpayne: yeah, also, it's not just mapping either. axiom gives us the ability to actually join data from multiple backends
<dkubb>
it's one thing to have a model that is backed by an rdbms, and another model that is backed by arrango, but we should be able to do things where a model's "static" parts are backed by an rdbms, and their more dynamic parts are backed by arrango
<robertjpayne>
mapping a cache with a static store would be epic
<dkubb>
so an obvious example would be a User model with first/last name, email, address coming from an rdbms, and then free-form type data about them coming from arrango
<dkubb>
so enough trying to sell you on it, which I think you already are :) you probably want to get in touch with mbj and see where he is with the arango adapter
<robertjpayne>
I've always preferred the mapper pattern over the active record pattern so doesn't take much to sell me
<dkubb>
it includes two basic adapters, one for github and one for yaml
<robertjpayne>
Does rom have any way to deal with transactions yet? for databases that support it?
<dkubb>
they don't do everything but they should give you some indication of what can be done
<dkubb>
not yet, no. how I think it will be, and solnic may correct me, but we have a concept of a session in rom. I think session maps really closely to transactions
<dkubb>
I think we should be able to make it so when you open a session, a transaction is opened at the same time, and when the session is flushed that's when we'll commit the transaction
<robertjpayne>
Yea that should work really well, SQLAlchemy on Python's end of things works that way sorta
<dkubb>
in many ways I think sessions and transactions are kind of parallel. a session being the interface you interact with on the software side, and the transaction being the datastore interface
<dkubb>
yeah, I'm a big fan of SQL Alchemy
<dkubb>
in many ways I want ROM to be SQL Alchemy for ruby
<dkubb>
at the same time I want the underlying system to be more based on clean Relational Algebra concepts, and be usable outside of ROM altogether
<robertjpayne>
yup
<dkubb>
my ideal end goal would be a set of gems that work really well together, but can be taken apart and assembled differently. a kind of ORM toolkit that fits the developer, rather than the developer having to contort their own code to match the framework
mbj has joined #rom-rb
<dkubb>
I think it's doable. I always wanted to do this with DataMapper (which I maintain) but it was too tightly coupled to the AR way of thinking
<dkubb>
mbj: btw, was just talking to robertjpayne and he's interested in helping with the axiom arango adapter
<robertjpayne>
Potentially helping* heh my ruby isn't the best
<mbj>
dkubb: nice, there ist still lots of work to do with arango
<mbj>
robertjpayne: hey
<robertjpayne>
I'm also pretty new to Arango as in I just installed it today
<mbj>
robertjpayne: The arangodb adapter was fully functional at the time I wrote it.
<dkubb>
robertjpayne: we go pretty good code reviews here, so we can probably help you if you want
<mbj>
robertjpayne: It was sponsored work by the company behind ArangoDB
<mbj>
robertjpayne: I'll reshape it and make it compatible with current ROM soon.
<mbj>
robertjpayne: So we both could/should team up :D
<dkubb>
mbj: did you see that moonglum is starting to contribute to develry now.. it's cool to see him using it on the arango client lib
<mbj>
dkubb: Yeah
<mbj>
dkubb: When I started axiom-arango-adapter I mentioned some smells in his code, and told him "devtools will help"
<mbj>
dkubb: Or lets reparse as "Devtools related coding style" :D
<mbj>
dkubb: Now he gives talks about composition > inheritance :D
<mbj>
The one he gave at FrOScon was good, but in german.
<dkubb>
mbj: sweet, do you have any links to his talks?
<dkubb>
oh.. heh
<mbj>
And I did my best mutant talk, but the mic was dead, so my recording does not have any sound :(
<dkubb>
you need to give a talk somewhere that confreaks is recording
<mbj>
dkubb: Where?
<mbj>
dkubb: I'd love to travel a bit :D
<dkubb>
there's lots of conferences in the US where they record
<dkubb>
maybe start submitting talks and asking if the talk is being recorded
<mbj>
How often I can recycle this talk?
<mbj>
dkubb: I'd prefer a conference you visit, is there anything on your shedule?
<dkubb>
mbj: I dunno. I think you can give it more than once to different audiences. if it's recorded, then perhaps less often
<dkubb>
mbj: but really, mutation testing is *so* new, it should be of interest to at least 4-5 conferences
<mbj>
dkubb: So while eurucamp is preparing Video releases I still have a chance :D
<dkubb>
mbj: I don't have anything yet, but I could book something in North America this year or next
<mbj>
dkubb: Nice
<mbj>
"If dkubb cannot be flown to europe, rom team has to fly to north america" :D
<dkubb>
you've gotta remember too, unless you're a Chad Fowler or DHH, people might not just search out your videos. chances are unless people were explicitly looking for info on mutation testing they won't have come across your talk already
<dkubb>
haha
<mbj>
heh
<dkubb>
my wife will kill me if I go to Europe without her
<dkubb>
which also requires bringing the kids
<mbj>
Same here
<mbj>
I'll have to bring my wife and child
<dkubb>
before I know it, the cost to fly my family in is like $6k
<mbj>
But that is not really an issue
<mbj>
my wife is employed ad my company
<mbj>
so my company can pay for her trip
<dkubb>
hehe
<mbj>
(This lowers our annual taxes btw)
<dkubb>
if you give a talk, sometimes you can get them to cover the flight or hotel
<dkubb>
or both, depending on the conference
<dkubb>
or neither, also depending on the conference ;)
<mbj>
dkubb: So once you stuble over a conf with active/pending CFP, that is also of your interest. Let me know.
<mbj>
*stumble
<dkubb>
mbj: yeah I will. I'm kinda surprised there's no notification service in the ruby community about this
<dkubb>
mbj: a place where speakers can sign up, and then conference organizers can send CFP requests that get sent to the speakers
<mbj>
good idea
<dkubb>
there's gotta be something like this already
<mbj>
And will open confs to many more speakers with better mixed audience.
<dkubb>
I bet you could target ruby, rails and even general testing conferences
<mbj>
nice
<mbj>
I'll try
<dkubb>
you may even be able to target python or js conferences, with an angle like "what we can learn about testing from the ruby community"
<dkubb>
because even though people might not be mutant contributors, getting people interested in mutation testing helps everyone.. like a rising tide lifts all boats
<mbj>
hehe
<dkubb>
of course it's up to you
<mbj>
yeah, makes sense
<mbj>
dkubb: That lanyrd list ist NOT compleate. For example the eurucamp 2013 CFP is missing.
<dkubb>
oh yeah
<mbj>
Seems it is not used widely
<dkubb>
I'm sure there are other similar services too
<dkubb>
I think it would be hard to get lots of users
<mbj>
We can also ask twitter if there is any north american ruby conference with open/pending CFP.
<dkubb>
yeah
<dkubb>
there's also other talks you can submit besides mutant: writing axiom adapters, working with ROM, Metrics Driven Development, on and on
<mbj>
There is TON off stuff to talk about.
<mbj>
I realized this when talking to some folks at eurucamp
<mbj>
Remember when I was unsure about "is mutation testing interesting enough" ?
<dkubb>
yeah
<mbj>
I'm totally convinced it is.
<mbj>
And all the other stuff we are doing.
<dkubb>
yeah, I think also because it's something new
<mbj>
Because it differs from the mainstream with "reason".
<dkubb>
fuzzing too is neat and interesting
<dkubb>
it's also lots of fun
<dkubb>
finding holes in your tests you never could find on your own
<dkubb>
well, you could, but it won't happen for 2 years and it'll take you a week of pulling your hair out
<mbj>
Yeah, a company producing webgames contacted me with a nice testamonial.
<dkubb>
oh yeah?
<mbj>
"We would have created a big money hole wihtout mutant" - Thx.
<mbj>
I need to summarize testamonials somehere.
<dkubb>
I'm convinced mutation testing should be elevated to the same level as TDD in developer's toolsets
<mbj>
*somewhere
<dkubb>
it's still early. lots more tooling and articles and information needs to be written
<dkubb>
I'm really excited to see if we can prove ROM as a whole works with these techniques
<mbj>
The only problem I see: We are slow (from outside POV)
<dkubb>
I know
<solnic>
morning
<dkubb>
keeping the bug count down, etc. I have a twitter search for ActiveRecord and it's hilarious to watch
<mbj>
And need to clearly communication: We are slow because this is work in our free time.
<dkubb>
every hour something is freaking out about it
<dkubb>
if ROM was sponsored it would go 5-10x faster
<mbj>
*communicate
<mbj>
My brain misses coffee :D
<dkubb>
AR is sponsored, and so is Rails
<dkubb>
even Sequel is sponsored actually.. the developer is allowed to work on it during company time
<mbj>
heh, so ROM is also sponsored (somehow). All time I do on ROM/mutant is from my potential companies time :D
<mbj>
solnic: morning
<dkubb>
it doesn't count when you self-sponsor :P
<robertjpayne>
I'm self employed here.. if I get too involved I could be living n the streets but ROM could be awesome??
<dkubb>
then I could say DataMapper was fully sponsored
<dkubb>
hehe
<solnic>
yeah mbj that doesn’t count :)
<mbj>
solnic: Was thinking about attending a conf in north america. For a) visiting b) giving a talk c) physically meeting dkubb
<solnic>
if I could make a living from working on ROM - that would be sponsored work
<mbj>
solnic: *order does not matter
<dkubb>
yeah, so I basically took a year off to work on DataMapper in 2008-2009, that doesn't mean it was sponsored by anyone :P
<mbj>
solnic: Maybe we should team up :D
<solnic>
I’m planning to go to RailsConf and StrangeLoop next year
<dkubb>
I would love to go to StrangeLoop
<dkubb>
lmk when you see if tickets go on sale. I'll do the same
<solnic>
we could meet there
<solnic>
awesome
<mbj>
yeah
<dkubb>
I should go to RailsConf too. I haven't gone since 2009, and that's because they paid for my ticket
<solnic>
my family lives in St Louis so that’s another +1 for me to go there
<dkubb>
but I had a blast there
<solnic>
re sponsored work, there’s hope some companies will get interested once ROM proves itself to work with SQL and NoSQL
<solnic>
as in, once companies start using ROM and see the potential
<mbj>
I'm planning to do lots of ROM work when I go to Kenya in mid October.
<solnic>
they might get excited and want to boost the development
<dkubb>
yeah, I think once we start getting ROM contracts we'll be able to get some sponsorship
<dkubb>
the big shops will be the first
<mbj>
Ive no gig during this time, and eating / visiting will not make my brain busy :D
<dkubb>
since they have the most complexity to manage
<solnic>
yup
<dkubb>
mbj: that should be lots of fun
<solnic>
I’m gonna experiment with a git adapter that would be useful for gitorious
<solnic>
this could be a nice use case
<solnic>
and I could spend some time improving ROM this way
<dkubb>
solnic: did you see that article where the guy migrated his repo to github and ended up spamming his entire userbase?
<dkubb>
solnic: when I read about that my thoughts were that you should build a tool that can act like a hub between Google Code, Github and Gitorious.. something to make migrating (or even syncing) between services easier
<dkubb>
solnic: someone in that HN thread asked "why does github not have an import from google code" feature, and others said it's probably because enterprise customers make up most of their business.
<dkubb>
solnic: however, in your case an easy to migrate from github to gitorious app might be worthwhile
<dkubb>
I think, especially in the hacker community, if you make it easy to leave a service it actually boosts people's trust and is likely to result in far more users joining than leaving
<solnic>
dkubb: yeah ‘1 click migration’ is on our list :)
<mbj>
solnic: Tell me once it is ready. I'll be your first early adopter. Talking about the new versions, the current one is suboptimal.
<dkubb>
the hardest thing is going to be combating the network effect
<dkubb>
solnic: obviously my thought was that ROM might be able to help abstract the different datasources ;)
<dkubb>
ok, I'm going to hit bed tonight. tomorrow i'm going to hack on nested relations more. I've almost got something to commit for grouped relations. I'll probably merge it early into master once it passes mutation testing so that others can try it out
<mbj>
snusnu: But TBH reek is "unfixable", saw the code once to fix a problem and thought: OMG, noo. I'll not even try.
Guest64140 is now known as lorenzo_
<mbj>
snusnu: I think I could write a tool like reek in a week with all the smell detectors and less loc.
<snusnu>
mbj: :)
<mbj>
snusnu: BUT I dont have the time. So lets help ;)
bf4_ has joined #rom-rb
bf4_ has quit [Client Quit]
skade has joined #rom-rb
breaking_ has joined #rom-rb
breakingthings has quit [Ping timeout: 240 seconds]
jfredett has quit [Ping timeout: 240 seconds]
breaking_ is now known as breakingthings
jfredett has joined #rom-rb
jfredett1 has joined #rom-rb
jfredett2 has joined #rom-rb
jfredett has quit [Ping timeout: 264 seconds]
jfredett has joined #rom-rb
jfredett1 has quit [Ping timeout: 240 seconds]
jfredett3 has joined #rom-rb
jfredett has quit [Disconnected by services]
jfredett3 is now known as jfredett
jfredett2 has quit [Ping timeout: 248 seconds]
jfredett has quit [Read error: Connection reset by peer]
jfredett has joined #rom-rb
jfredett has quit [Read error: Connection reset by peer]
jfredett has joined #rom-rb
jfredett has quit [Ping timeout: 264 seconds]
jfredett has joined #rom-rb
jfredett has quit [Ping timeout: 264 seconds]
jfredett has joined #rom-rb
jfredett1 has joined #rom-rb
jfredett has quit [Read error: Connection reset by peer]
lorenzo_ is now known as lorenzo_off
<snusnu>
mbj, solnic: got some time for a somewhat explorative discussion about how to "steer" domain models in a ROM app? "specifically" about the way of organizing domain models in such a way that they expose functionality that relies on a session with a datastore, without feeling like a transaction script?
<snusnu>
i imagine my domain model to expose, say, Company#add_employee .. obviously this would need a session to really persist .. but i don't want to just have "raw DTOs without behavior", because then "steering" them would feel almost like a transaction script .. the "behavior part" of the domain model would move somewhere else (a transaction script)
<solnic>
snusnu: sorry busy ;)
<snusnu>
i.e., i don't want a "script on top of my model" that knows about how to query/assemble my otherwise behaviorless domain objects
<snusnu>
solnic: ok
<snusnu>
solnic: think about it once you have time tho :)
skade has quit [Quit: Computer has gone to sleep.]
jfredett1 has quit [Quit: Leaving.]
jfredett has joined #rom-rb
<mbj>
snusnu: Action::AddEmploye.run(new_employee_from_somewhere), in case of no code duplication was spotted.
<mbj>
snusnu: Action::CreateCustomer::OnlineShop.run(new_customer_from_somewhere), in case some code duplication could be abstracted into CreateCustomer base class
<mbj>
snusnu: What would Company#add_employee do? Send notification emails, nope, the company does not know the interface to do it.
<mbj>
snusnu: A domain model that has behavior, makes lots of sense for objects calculating something.
<mbj>
snusnu: But most "CRUD" work is not able to "trigger" a *real* domain model from my refactoring cycles.
<snusnu>
i hear you
<mbj>
snusnu: Your domain has to be "complex" enough for a domain model.
<snusnu>
i'm not so sure about that, i.e. i don't want implementation details (where to put persistence) to guide my modelling
<mbj>
snusnu: services_root_object.run(Action::AddEmploye, new_employee) if you have services can can be selectively injected
<mbj>
snusnu: So dont do it.
<mbj>
snusnu: I'm totally okay my domain model consumes / produces DTOs.
<snusnu>
mbj: fwiw, i have code like you suggested, but i want to question it some more, justify it
<mbj>
snusnu: The "outer world interfacing" code does setting up my session and flushing.
<mbj>
snusnu: For example if my outer world interfacing code is HTTP, I'll spawn a new sesson per request, and flush it afterwards (if chain was successful).
<mbj>
snusnu: Or flush it at some domain specific points, sending emails after saving a shopping order.
<mbj>
snusnu: I have to admit I'll have to explore it.
<mbj>
snusnu: BTW I named a namespace DTO::{Here,The,Subjects,Of,My,Domain}
<mbj>
snusnu: This is NOT an anemic domain model, for two reasons
<mbj>
snusnu: Reason A) the namespace is called DTO :D
<mbj>
snusnu: Reason B) the domain logic, the use cases that consume / produce Dtos live in a layer I presented above
<mbj>
snusnu: And these are heavily optimized (in sense of DRY) for injecting inputs and outputs and producing new DTOs
<mbj>
snusnu: Sometimes these actions have to know about persistance, the email after save case.
<mbj>
snusnu: Sometimes not.
<mbj>
snusnu: I'm beginning to use "angular style" in my code.
<snusnu>
calling it "angular style" (even tho i know what you mean) makes no sense imo, you have a registry of services (most likely inside your application env object), and you access those … i do that too
<mbj>
snusnu: Yeah
<mbj>
snusnu: Just needed a reference to decorate my "use :foo" examples.
<snusnu>
i also structure my code like you explained above, but yeah, i wanted to question that
<mbj>
If my call becomes to "complex" I spin out more objects.
<mbj>
Mostly for calculating stuff.
<mbj>
They wrap DTOs as inputs
<mbj>
and query methods present the results.
<mbj>
And because I use domain specific "calculation" objects, I think its a domain model.
<snusnu>
what "worries" me, is that it looks like almost all of the business logic, is in another layer, not bundled with the domain models themselves
<mbj>
For that reason I call them domain DTOs
<mbj>
My domain is what is *done* to the models.
<mbj>
Not what the models look like.
<snusnu>
i know, i know the reasoning behind that (our) "style" .. i'm just trying to look at it from different angles
<mbj>
sure
<mbj>
And I accept it.
<mbj>
Trying to invalidate your concerns via new naming etc.
<snusnu>
i "know" one thing … a domain model that incorporates the behavior too (because that's what objects typically do, encapsulate data AND behavior) .. would be more expressive
<snusnu>
it feels like there's a very sharp distinction between data and behavior in our current approach
<snusnu>
it also might be due to the functional nature of our oop style
<mbj>
But if a domain model knows about logic, it has to know about persistance.
<mbj>
And eighter you inject persinstance per use case
<snusnu>
right, and i'm not entirely sure if that's necessarily a bad thing
<mbj>
Or you have the logic in a separate class.
<mbj>
And if you have the logic in a separate class it does not really show your behavior is separated from the models.
<mbj>
It is all about accessibility!
<snusnu>
it feels like some aggregate roots could be backed by persistent collections .. an uow which performs "self registration" might come in handy .. there might still be a distinction between raw DTOs and more behavior rich objects
<mbj>
snusnu: These rich objects typically NOT get persisted.
<mbj>
Because they are rich of behavior
<snusnu>
but i wonder if it's really cool that anything that actually *does* something .. lives in a "functional" object .. and tries to emulate operation names via class names, when they could/should be method names on some different kind of (domain) object
<snusnu>
exactly
<snusnu>
(re typically not persisted)
<mbj>
What about dynamically created proxies where you *can* model behavior with?
<snusnu>
i guess my point boils down to this .. our code that *does* something, typically contains the operation name in the class name, and the "doing" is exposed via #call … it just feels like too much indirection sometimes
<mbj>
I think we'll have an AR (pattern) like layer for simple cases.
dkubb has joined #rom-rb
<snusnu>
i think i know what you mean, although i wouldn't reference AR (the pattern) in that context
<dkubb>
good morning
<snusnu>
hey dkubb
<mbj>
Its all about complexity, if complexity is to less, we dont trigger a "domain model" from refactoring cycles.
<mbj>
I have to run, sorry guys.
<mbj>
Back in 20-30min from train
mbj has quit [Quit: leaving]
<dkubb>
solnic: so with axiom-types, currently the key/value for Hash has to be another Axiom::Type instance, not a primitive. I could make it so that it coerces a non-Axiom::Type instance into an Axiom::Types::Object instance if that helps
<dkubb>
I could do the same for enumerable stuff too
<snusnu>
and bye dkubb, maybe i'll bbl :)
<dkubb>
haha
<dkubb>
was it something I said? :P
<snusnu>
hah
<dkubb>
it's cool though, I only stopped in for like 5 minutes before getting back to work
<snusnu>
not at all :) just found it funny that both me and mbj needed to leave exactly once you joined :)
<snusnu>
dkubb: if you're interested, i posted a question about how to do a domain model in a typical ROM app here in the channel .. mbj and i were just discussing it a bit
<dkubb>
it's alright, I just wanted to drop that note for solnic and I'll be checking back later
<snusnu>
dkubb: i'd be interested in your opinion, if you find the time at some point .. but as i said, i have to leave now too, anyways
<dkubb>
sure, I'll checkout the backlog
<snusnu>
thx
<dkubb>
ok, I've gtg too. ttyl
<snusnu>
have a good day
dkubb has quit [Client Quit]
snusnu has quit [Quit: Leaving.]
jfredett has quit [Read error: Connection reset by peer]
jfredett has joined #rom-rb
snusnu has joined #rom-rb
postmodern has joined #rom-rb
snusnu has quit [Read error: Connection reset by peer]
snusnu has joined #rom-rb
snusnu has quit [Client Quit]
breakingthings has quit []
jfredett has quit [Read error: Connection reset by peer]
jfredett has joined #rom-rb
breakingthings has joined #rom-rb
mbj has joined #rom-rb
mbj_ has joined #rom-rb
mbj has quit [Ping timeout: 245 seconds]
mbj has joined #rom-rb
mbj_ has quit [Ping timeout: 245 seconds]
jfredett has quit [Read error: No route to host]
jfredett has joined #rom-rb
jfredett has quit [Read error: No route to host]
jfredett1 has joined #rom-rb
mbj has quit [Read error: Connection reset by peer]
jfredett1 has quit [Ping timeout: 245 seconds]
mbj has joined #rom-rb
<solnic>
mbj: how can I see which specs are being run by mutant?
<solnic>
it shows many alive mutations in virtus but when I check it manually specs fail
<mbj>
solnic: No way
<mbj>
solnic: Does not have this feature :(
<solnic>
dude
<mbj>
solnic: *BUT* you can easily monkepatch it in.
<mbj>
Needs to be added in reporting.
<solnic>
mbj: works fine with my patch that you guys hated so much ;)
<solnic>
I’m telling you, mutant w/o this auto-expanding will be very unfriendly for 99% of the cases
<solnic>
I have pretty solid coverage right now but if I were to kill all those mutations with spec-per-method I would’ve written ~10x more tests which is stupid
<mbj>
solnic: Feel free to nail down a specific rev
<mbj>
solnic: As I said I'll add this as an option!
<solnic>
yeah that’s the plan for now
<solnic>
please add it back and turn it on by default, it’s what most people will want
<mbj>
solnic: Each unkilled expansion will blow up execution time. Because in the worst case all specs need to get run.
<mbj>
solnic: So it should be an option.
<solnic>
it should be, sure, but turned on by default :)
<mbj>
Remember what happened to Axiom::Types and Axiom.
<solnic>
dude
<mbj>
infinite runtime
<solnic>
that’s such a specific case
<mbj>
Its easily reproducible
<solnic>
1) Axiom::Types are being mutated
<solnic>
which is obviously sth that should not happen
<solnic>
2) Axiom has a gazillion of tests
<mbj>
All 50% covered code will suffer from this.
<mbj>
You dont notice that problem because your lib is so solidly covered.
<mbj>
Just rm -r half of your spec suite and suffer :D
<solnic>
I just did buddy
<solnic>
I removed entire test suite in virtus
<solnic>
rewrote it almost from scratch
<mbj>
This does not could because 0 spec suite == 0 rspec execution time
<mbj>
Also your specs are well written :D
<solnic>
I believe even if you have a very poor coverage you still kill roughly 50% of mutations
<mbj>
Not with fully uncovered modules in size of Axiom::Types
<solnic>
well, I’m just saying what I observe while using mutant
<mbj>
And a full spec suite that runs around 10sec (like axiom)
<mbj>
So let me add an option and we are all happy
<mbj>
expansion level
<solnic>
well, I think the ultimate solution is that line-cov tracking you mentioned
<solnic>
it sounds like a great solution
<solnic>
I think mutant should adjust to the tests
<solnic>
not the other way around
<solnic>
I’ve seen results of such thing (heckle) and guess what, I just nuked entire spec suite and rewrote it from scratch :P
<solnic>
I literally couldn’t stand tests in virtus
<mbj>
That line cov tracking is not a universal solution: Because some lines are covered from specs with implicit coverage do not count.
<solnic>
and really, if you can make mutant to be smart about picking up tests then wow, it’s gonna be perfect
<mbj>
Heckle worked like it.
<mbj>
?
<mbj>
I read half the heckle source and did not found a sign of line tracking.
<solnic>
no idea how heckle worked, I just know what kind of specs we had to write to make it pass
<solnic>
and that’s my point, it made us write and organise things in a special way
<solnic>
ultimately I think it was a major PITA
<solnic>
and the reason why I was so reluctant to using it for so long
<solnic>
Thank Markus we have Mutant now :D
<solnic>
…but it still needs some teaking ;_
<solnic>
hah! speaking of which, mutant is already finding dead code in virtus :)
<solnic>
*I love it*
<mbj>
hehe
<mbj>
working with mutant and devtools is like inifinite dkubb.fsck :D
<mbj>
solnic: heckle did not had this feature, remember why we had that tasks/heckle.rake ?
<mbj>
solnic: Because it could only run the full spec suite by default.
<solnic>
yeah of course
<mbj>
solnic: Also it hals lots of "false coverage"
<mbj>
solnic: Because a mutation that could not be teared down (global state) leaks into later mutations.
<solnic>
I’m gonna repeat myself but I believe running mutant in parallel is the best thing to do now
<solnic>
I’m telling you once again, forcing people to structure their specs like we do (well, me partially) is not a good idea
<mbj>
solnic: Yeah, but it is not the best thing to code next :D
<solnic>
yeah I hear you :/
<solnic>
I must say I keep going back to thinking about this spec-per-method and I’m still on the fence
<solnic>
I’m too tired to discuss further today though so don’t worry :P
<mbj>
solnic: Trust me, if I could spend more time on mutant we'd already have mutcov.{org,com} parralel execution, more test framework integrations, inverse lcov targeting, ...
<mbj>
mutation-grid
<solnic>
just sit down and do it, I’m happy to help buddy
<mbj>
zeromq based mutation broker
<mbj>
jruby integration (possible isolation without fork)
<solnic>
mutation testing is one of the best things I’ve learned during the last couple of years
<solnic>
I want to promote it
<mbj>
yeah
<mbj>
selective kill tarkets (like saying mutations in Foo::Bar* are killed via Foo::Baz#bot
<mbj>
nice to make unparser "fast"
<mbj>
project specific test targets
<mbj>
so you can subclass / compose your own target selector
<mbj>
good for algebra stuff like axiom, ducktrap, unparser
<mbj>
etc
<mbj>
Its a huge field of ideas
<mbj>
But I have to steear my time it helps my commercial projects and reduces overall coding time.