<postmodern>
solnic, although i suspect PoEAA has a different definition
<solnic>
postmodern: yes
<postmodern>
solnic, speaking of which what's up with ROM, seems like everyone is super business with their respective jobs/side projects
<solnic>
postmodern: I took a break from OSS
<postmodern>
solnic, btw congrats on becoming lead of gitorious, the project needed some attention
<solnic>
postmodern: others kept working
<solnic>
postmodern: oh thanks, yeah we're gonna work on pushing it to the next level
<postmodern>
solnic, also have you thought of getting a professional audit done?
<postmodern>
solnic, i mean you could easily learn secure code auditing for ruby and do it inhouse
<solnic>
postmodern: no not yet
<postmodern>
solnic, having refactored most of the code is a double edged sword
<solnic>
postmodern: we haven't refactored most of the code
<postmodern>
solnic, you probably killed some old vulns, but might have introduced new ones, depending on what new features were introduced
<postmodern>
oh i stand corrected
<solnic>
we mostly ported it to work with rails3 and ruby 1.9
<solnic>
and updated views and front-end to match with the new UI
<solnic>
there's a lot of old code there still
<solnic>
we fixed a ton of issues with db too
CraigBuchek has joined #rom-rb
<solnic>
we still have stuff to do wrt stability
<solnic>
postmodern: re ROM, I think I need to build an app using it and add missing stuff as I go
<postmodern>
solnic, good idea
<solnic>
I think we've been in an experimental-phase for too long
<postmodern>
solnic, i also need to use more of the ROM tooling to add my 2c
<solnic>
I diverged a bit when it comes to development style lately so I'm not sure how it's gonna work with the rest of the guys
<postmodern>
solnic, i concur, seems to be held back by connecting the major layers
<solnic>
we'll see
<solnic>
yeah that too
<solnic>
in fact I'm wondering if it wouldn't be better if we built a monolithic working prototype and extract stuff from it
<postmodern>
yeah the work bench approach is useful
<solnic>
I know dan prefers to build things bottom-up though but I am not entirely sure if that can work with such a big thing as a DM
<postmodern>
also remember that simplicity is subjective (i prefer minimalism which is an art term)
<solnic>
rom itself is going to be an integration point which pretty much boils down to a bunch of dsls just to configure things
<solnic>
the heavy work will always happen somewhere else
<solnic>
maybe with the exception of the session component
<postmodern>
i tend to be cautious when approaching massive dependency trees, each library may be simple but their interactions are not
<solnic>
yeah I agree, you can easily go overboard with slicing things into pieces
<postmodern>
goal shouldn't be small libraries, but minimal set of layers?
<postmodern>
or minimal set of connections between layers
<solnic>
when it comes to layers I think current architecture is pretty good
<solnic>
I'm still a fan of the proxy approach: axiom => adapter => rom-relation => rom-session
<solnic>
we have different ideas how session should work though, I think mbj wanted to build an alternative impl to what I did
avdi has joined #rom-rb
<solnic>
I am not sure if that's required though, his motivation was to support immutable objects and I think my impl can support that easily with very little changes to the code
<postmodern>
solnic, i'd be happy with just transactions :)
<solnic>
yeah session will provide transactions
<solnic>
that's gonna be passed down to axiom adapter though
<postmodern>
also bubbling up of validation errors to cancel transactions
<solnic>
yeah we'd like to support that
<postmodern>
btw how much throw/catch vs. raise/rescue are you using?
<postmodern>
or is it all just return values all the way down?
<solnic>
huh wdym? I don't have statistics :D
<postmodern>
nm i should probably git grep myself
<solnic>
no we have lots of custom errors
<solnic>
anyhow, we were thinking about using ROM in gitorious
<postmodern>
good application
<solnic>
for reading stuff from git repos, we have a missing abstraction there and ROM could be useful
<solnic>
that would only be for reading, so that's a perfect scenario since ROM's read support is way more mature than write ;)
<solnic>
I do want to try it in an app that requires writing too so that I have a good candidate to experiment with the session
<solnic>
my biggest motivation right now is to see it working so that I can confirm the direction we're heading is correct
<solnic>
I can't really tell that now based on our spec suites :P
<postmodern>
a write-only app would be interesting, esp for performance considerations
<solnic>
I'm not even sure how well our immutable stuff will affect things at run-time
<solnic>
we do freeze a lot of things after all
<solnic>
knowing ruby we may see some odd things happening
<solnic>
anyhow, I definitely want to move things in a more productive manner during this year
<postmodern>
i remember rubinius developers mentioning that MRI doesn't optimize around froozen objects
<solnic>
focus less on the whole metric setup etc and do more experimentation
<solnic>
with fast feedback on short iteration cycles, preferably :)
<solnic>
postmodern: no it doesn't, there are some improvements in 2.1 wrt freezing strings though
<solnic>
I'm not too worried about it though, sooner or later this should work better in MRI
<solnic>
this == freezing
<postmodern>
word
<solnic>
postmodern: I know mbj used his mapper/session on production with immutable objects and didn't have much trouble, that's kinda reassuring
<postmodern>
ah yes i forgot about that
<solnic>
I would love to see rom working in gitorious too
<solnic>
this should be valuable for us
<postmodern>
mbj has a 1/3 of the stack actually, ducktrap etc
<postmodern>
given mbj's uses of existing ROM components, the interfaces are probably somewhat tested
<solnic>
not really, he had his own mapper and session
<solnic>
I mean, on the higher level it is very similar to what we have now in ROM
<solnic>
for instance we have loader/dumper separation in rom-mapper
<solnic>
it's the same concept as he used, just naming is a bit different
<solnic>
his mapper is rom-relation and his transformer is rom-mapper ;)
<solnic>
not important
<solnic>
we will port rom-mapper to use morpher soon btw
<solnic>
that's gonna be nice
<solnic>
but my biggest concern is session, it's so tricky that I need to just start using it and see what makes sense
<solnic>
oh and I just did state tracking, there's the whole UoW missing :)
<postmodern>
ugh yeah dirtiness tracking
<solnic>
postmodern: it's more stable than in DM1 though, we compare a whole dumped object now
<solnic>
so you can mutate stuff in-place and you will see it as dirty
<solnic>
I'm talking about cases like user.books.concat(new_collection)
<postmodern>
ha nice
<solnic>
I'm actually really happy with rom-session even though it's just a prototype
skade has quit [Quit: Computer has gone to sleep.]
skade has joined #rom-rb
lfox has joined #rom-rb
dkubb has joined #rom-rb
postmodern has quit [Quit: Leaving]
breakingthings has quit []
breakingthings has joined #rom-rb
mbj has joined #rom-rb
<mbj>
dkubb, solnic: I'd love to create a mutation testing cheat sheet. As the start for better mutant documentation.
<solnic>
mbj: what would it include?
<solnic>
I think the best thing to do is to come up with a bunch of really solid examples
<solnic>
not sure if that would fit a cheat-sheet style
<mbj>
solnic: For example some general "how to kill a mutation sequence of steps"
<mbj>
solnic: If you have a mutation do A, than B, than C etc.
<solnic>
I suspect good docs for mutant might as well be turned into a thick book
<solnic>
this is a huuuuge subject
<solnic>
and to me it's very strictly connected with tdd and a lot of general best practices in testing
<solnic>
so really, a meterial for a book
<mbj>
Yeah
<solnic>
material even
<mbj>
I tried to summarize all that stuff to my wife, she just said: Write a book instead of wasting all that time telling it 100x times ;)
<solnic>
plus it's also very subjective
<solnic>
stuff that you think is great might be really wrong for others
<mbj>
solnic: I whent to a local ruby meetup and we discussed with 20 people for 2hours. Lots of interesting work.
<mbj>
Yeah, thats a point.
lgierth has quit [Quit: Ex-Chat]
<mbj>
I think mutant need to mature a lot before thinking to write a static pice of information (book)
<solnic>
I agree
<solnic>
esp when it comes to finding which tests to run :)
<mbj>
:D
<solnic>
I'm STILL on the fence wrt test-file-per-method btw
<mbj>
solnic: Trust me, I'll do this ASPAP. But OSS time is sooo limited.
<mbj>
solnic: Its not test per file anymore.
<mbj>
solnic: Its "test per public method".
<mbj>
solnic: Wich is the same, but does not force you to write n files for n methods.
<solnic>
yeah that's actually what I meant, practically
<solnic>
yeah sure
<mbj>
solnic: I write 1 file with a test per public method per class.
<mbj>
Because I can reuse spec setup easier this way.
<solnic>
I find jumping between those files really terrible
<solnic>
if I want to learn how to use an object
<solnic>
and I need to jump between multiple files...geez, terrible
<solnic>
mbj: so, future mutant will be able to expand the scope right?
<mbj>
solnic: yeah
<mbj>
solnic: You'll have kill expressions with longest prefix match.
<solnic>
I really think killing mutations through tests for AN OBJECT is a reasonable practice
<solnic>
even though in probably most of the cases all mutations for a given method WILL be killed via tests for that specific method
<solnic>
I still think making it a constraint and telling it's a good practice is wrong
<mbj>
solnic: You'll be able to configure it.
<solnic>
that's great can't wait for it
<mbj>
solnic: Basically I love testing "per method" on mature libs, while spiking I do implicit coverage "solnic style".
<mbj>
solnic: Morpher will probably move to "per method" soon.
<solnic>
this isn't implicit coverage
<solnic>
stop calling that please, that's misleading
<mbj>
solnic: s/implicit/indirect/
<mbj>
We need to come up with good nameing.
<solnic>
I test objects, I don't test methods
<mbj>
I need to name it in our discussions somehow.
<mbj>
I tests methods, on mature libraries.
<mbj>
;)
<solnic>
I don't think level of maturity of a lib is important here, if you have an object that is supposed to serve some purpose then you have tests to verify if it behaves correctly in various scenarios
<solnic>
you want to use it in some way and that way is described by your test
<solnic>
going crazy on per-method testing leads to too many tests, that's been my horror for the past couple of yaers
<solnic>
years even
<mbj>
solnic: My lib, my rules :D
<mbj>
solnic: I'll not force you to do it the way I like.
<solnic>
dude, you do whatever you want, I'm just telling you my thoughts
<mbj>
yeah
<mbj>
And feel free to keep doing it.
<solnic>
I'm almost 100% certain you'll change your mind
<solnic>
mbj: btw I was looking at morpher specs today, still can't tell how the thing works based on tests
<mbj>
solnic: the specs should not tell how something works.
<mbj>
solnic: The specs should make sure something works.
<mbj>
How is the code ;)
<solnic>
see, that's the thing, I disagree, the tests should tell you exactly how something works
<solnic>
that's why rspec has its dsl to describe how stuff works
skade has quit [Quit: Computer has gone to sleep.]
<mbj>
solnic: What is your "how" ?
<solnic>
how to instantiate an object, what are its dependencies, how to use its interface
<mbj>
For me how is the acutal code, the algo I choose to implement, the primitives of the language I assemble.
<mbj>
AHH
<mbj>
Naming problem, my and your HOW differed.
<mbj>
*is differend
<solnic>
I would read the code if I found the bug
<solnic>
otherwise code is not interesting
<solnic>
or when tests are not readible :D
<mbj>
"how to instantiate an object, what are its dependencies, how to use its interface" is exaclty what my style does.
<mbj>
solnic: Idea, lets pair on morpher developent for an hour.
<mbj>
so we can argue while seeing the code we are about to change.