<mbj>
solnic: If you have any wishes for mutant 0.3 pls tell me soon
<mbj>
I'm nailing down the feature set I'd like to release
<dkubb>
good morning
<dkubb>
mbj: what are you planning for mutant 0.3 ?
<mbj>
dkubb: morning
<mbj>
dkubb: Mostly the transtition to parser/unparser that fixes lots of bugs (you most likely saw the issues closed)
<mbj>
Also we ship the #initialize fixes
<mbj>
And a more pretty report
<mbj>
But now I have to finalize what still is to be done for 0.3
<mbj>
So pls raise your wishes :D
<dkubb>
mbj: I like the change to parser/unparser and bug fixes. I would love to see a 0.3 release earlier with those, deferring new features until 0.4+
<dkubb>
mbj: I assume there aren't any functionality regressions with 0.3 ?
<solnic>
dkubb: morning
<mbj>
dkubb: Also we now have non recursive subject matchers!
<dkubb>
mbj: what does that mean>?
<solnic>
I wish I could run --rspec-unit mode and have it working correctly
<solnic>
that's all I want :)
<mbj>
solnic: This is --rspec-file-per-class :D
<mbj>
--rspec-unit it spec/unit/**/*_spec.rb PER EACH MUTATION
splattael has quit [Quit: Leaving.]
<mbj>
dkubb: Non recursive subject matchers: Given A, A::B, and A::C
<mbj>
dkubb: And a matcher like ::A, it will not recurse into mutating A::B and A::C anymore
<mbj>
dkubb: For this behaviour you must specific ::A*
<mbj>
dkubb: This way you can easily whitelist the subjects (classes, methods) you want to mutation test.
<dkubb>
mbj: why not evaluate the class name passed in as a regexp?
<dkubb>
mbj: it works for ack/grep/etc pretty well
<mbj>
dkubb: Because I plan to got away from matching against ObjectSpace
<mbj>
You also have the option to filter by regexp
<mbj>
nope you have not :D
<mbj>
Thought I wrote this matcher already.
<mbj>
The problem is, some bastards in the community patched Class#name to return NON strins.
<mbj>
*strings.
<mbj>
Nokogiri for example creates Classes where #name is not a String anymore.
<mbj>
I'd like to crawl namespaces via Root.constants in future.
<mbj>
I still could try to use regexp against the names.
<mbj>
Lets add a regexp matcher, but I still need a syntax for the root.
<mbj>
This is up to discussion and I'd love to hear your voices, ideas!
<dkubb>
mbj: well, like I said above I'd prefer an earlier 0.3 release that fixes the issues and uses parser/unparser to any more features
<dkubb>
mbj: zombie would be the next feature I need. I've got a bunch of gems I can't test with mutant because they are deps on it
<dkubb>
mbj: how would you fix that smell, subclass OptionParser and provide introspection to your options instance?
<mbj>
dkubb: Maybe just break this up into a bunch of method calls
<mbj>
dkubb: Each adding an option/group
<cored>
hello all
<dkubb>
cored: hello
<cored>
is there a path that you guys follow to build Rails apps? I've been studying DCI and Object on Rails also most of the things from Destroy All Software
<solnic>
I try to minimize the role of AR but it's hard
<cored>
and I also saw Corey Haine's fast tests, which just let me thinking that's a very bad approach, putting all the behavior on modules and including on a model still breaks SRP and his other method was just putting the logic inside classes and testing in isolation but then again he stubs in the integration tests which leads to fantasy tests
<dkubb>
ugh
<solnic>
cored: agreed
<cored>
DaS go on another direction, creating services for every piece of logic he needs on his system, that's cool and all I was doing that in the first place but I read about the anemic domain model and now I'm clueless
<dkubb>
for me SOLID is realy important.. keeping the code stupid simple, with no trickery
<solnic>
his approach is just working around terrible problems with rails
<dkubb>
solnic: agreed
<cored>
I'm stuyding Object in Rails now, but man a lot of hackery :-(
<cored>
DCI looks nice but stills there's something pretty heavy about that entirely
<solnic>
first we need a new orm :P
<dkubb>
whenever you do something like that you need to ask yourself what you're working around.. you *should* be focusing on building your app around the problem you're trying to solve, not structuring it around problems in your framework
<dkubb>
rails is not your app
<mbj>
dkubb: "rails is not your app" +1
<mbj>
rails is JUST a bloody way to abstract away http
<solnic>
that's the problem, rails *is* your app because of how its designed :P
<cored>
solnic: I saw an article from you and I think that will be my next approach, have some DDD books around to check on that, I want two things from building any new application, creating a solid foundation for maintanability and be able to respond as fast as possible in the beginning
<dkubb>
solnic: well, rails should *not* be your app ;)
<solnic>
rite
<cored>
agree, but there's no way right now where people says 'hey this is the way of building apps'
<cored>
apart from Rails, everyone is pointing out to do scalfolds and stuff like that which points always to a bad design
<solnic>
well, rails is nice too bootstrap a project
<cored>
dkubb: I saw Bob Martin's presentation on the lost arquitecutre
<solnic>
once you need to move away from a prototype that you've built
<solnic>
it doesn't offer a lot in terms of design
<solnic>
sure, it has a ton if neat features
<dkubb>
one of the problems we have, and to some extent we've always had, is that there are too many people screaming "my way is best"
<solnic>
but when you want to decouple stuff, it's HARD to do in a rails app
<cored>
I was watching literature from others communities, Java/.NET in particular they make the programmers to focus on best practice and good arquitecutre they enforce it, even for bootstrapping
<dkubb>
I hate to sound like a luddite, but usually if an approach is brand new it's not "the way" .. it's an alternative to consider, but I would tend to stick with more foundational stuff that's been around for a while
<dkubb>
for me SOLID is one of my foundations
<cored>
solnic: and I agree regarding that a new ORM is needed, there's nothing identical to EntityFramework or Hibernate in the Ruby world at the moment
<dkubb>
I like the stuff in amzn.com/0135974445
<dkubb>
that's one of my foundational books along with PoEAA
<cored>
dkubb: did not know amazon have an url shortened
<cored>
nice
<cored>
dkubb: yes, I have that book also, read it long time ago but will read it again and again until my head just grasp everything
<solnic>
cored: everybody has ;)
<cored>
:-)
<cored>
but after getting a new ORM
<cored>
probably there will be a need of a new web framework also
<dkubb>
DCI, at least the ways I've seen it implemented in ruby, are crazy imho.. maybe there's ways to do it that don't blow your global method cache, but even if it didn't do that I don't like the idea of super wide interfaces
<cored>
probably to make some stuffs automatic on the right way of not letting the framework to mess with your application
<cored>
dkubb: is there any example around of those implementations?
<cored>
dkubb: also are you building Rails app ? which of the approaches that I mention do you follow more closely in combination to your own style?
<cored>
sorry for getting this discussion here, is just like I'm kinda frustrated :-(
<dkubb>
cored: I'm mostly talking about how they define a base instance and then move behaviours out into modules and mix them in at runtime
<cored>
dkubb: did you read Jim Gay's Clean Ruby?
<dkubb>
cored: not yet. I have it, but I haven't gotten to it yet
<cored>
dkubb: that books have an example of doing it in another way, the only downside is that most of his examples are kinda superfluos and very abstract
<cored>
dkubb: I finish the book yesterday, as I said I'm very interesting in those topics, "Building a Rails app with good foundations"
<dkubb>
cored: one principle I like to use in my code, not just my rails app but all my libs, is the idea of complexity being evenly distributed across the code base. you shouldn't have any places where code kind of bunches up and does too many things to make some other later simpler
<solnic>
my conclusion after 2 years of looking for better ways of building rails apps is this:
<solnic>
WE NEED A NEW FRAMEWORK™
<dkubb>
cored: you want homogenous distribution of complexity
<dkubb>
*layer simpler
<cored>
dkubb: found an interview from the Rouges with you, will hear it :-)
<cored>
solnic: yes, but will people switch ?
<solnic>
cored: depends
<dkubb>
cored: in my most recent rails app I have presenters, form objects and services to distribute complexity that normally resides in the models, controllers, helpers and views
<solnic>
rails will be still a great choice for some cases
<dkubb>
cored: I try not to use helpers. in fact in my next rails app I'm probably going to remove helpers completely and put that kind of thing in a presenter
<dkubb>
cored: I don't recall if I spoke about any of that stuff in the rogues podcast
<cored>
solnic: judofyr is building a new framework
<cored>
from scratch
<dkubb>
who cares if people switch. I would only worry about you and your team
<solnic>
yeah 1) no AR models in views, only presenters 2) no ivars in views 3) no LOGIC in views 4) complex business logic in services 5) AR only for trivial persistence-related logic
<dkubb>
if it helps you get the work done better, faster, cleaner then it's good enough
<solnic>
these are my rules ;)
<cored>
dkubb: yes, I think that's the best approach at the moment is the one I'm trying to follow
<dkubb>
solnic: I agree with all of those
<solnic>
cored: I know, I've had access to this repo for some time now
<cored>
dkubb: trying not to use generators and delaying the need to make inherantance from AR to the last minute
<solnic>
I'm not following it closely though
<dkubb>
I try to make my models not know anything about the transport layer
<dkubb>
that means no view or input munging
<dkubb>
I put those in presenters and form objects respectively
<dkubb>
from the pov of my models they could be used in cron jobs
<cored>
solnic: no ivars in views?
<solnic>
cored: yes no ivars in views
<cored>
solnic: how will you present data, then?
<solnic>
locals
<solnic>
only
<solnic>
all the time
<solnic>
everywhere
<dkubb>
I use helper methods in my views
<solnic>
passing locals to views explicitly
<solnic>
yeah me too
<dkubb>
the controller exposes the presenter/model via a method and I reference that in the view
<dkubb>
I usually try to have only one root object too
<solnic>
yup me too
<cored>
helper methds from the controlllers ?
<cored>
I can't see that approach in my head, no
<cored>
I was considering in just setting one ivar in the views
<dkubb>
in this case you define a method on the controller that you can test independently
<solnic>
and sometimes you want an ivar, then you'll switch to local, the conditionally use local if it's present or default to ivar etc
<dkubb>
and you expose it as a helper method in your view
<solnic>
seen this type of shit a lot of times
<solnic>
makes me want to scream
<cored>
sounds interesting
<solnic>
have you ever seen stuff like <%= something = defined?(something) ? something : @something %>
<solnic>
geeez
<cored>
solnic: :-)
<cored>
what about the testing part
<solnic>
it's what happens when you use locals and ivars
<cored>
I normally try to spec my services which have most of the logic
<solnic>
avoid AR methods
<solnic>
like, don't call AR methods in service objects or controllers (if you use AR directly in controllers)
<solnic>
it's the least you can do
<cored>
and just have integration spec for testing the entire thing starting from the services no controllers logic or view, do that with cucumber but I don't like to use the fill_with from capybara there, because I don't think that testing the UI is a good thing
<solnic>
I consider stuff like AR#where too low-level
<solnic>
in a perfect world you'd need very little integration tests
<solnic>
and almost none acceptance tests
<cored>
solnic: well, I just let this in my AR 1) validations 2) relationships 3) scopes 4) wrapped methods for doing AR stuffs and exposing stuffs that I want
<solnic>
cored: have you watched Boundaries talk by Gary Bernhardt?
<cored>
solnic: but you do have then, right?
<cored>
searching for it now
<solnic>
there are some neat concepts there, we're pretty much building ROM this way (more or less)
<solnic>
OO design but functional core
<cored>
have to read a lot :-)
<cored>
but I like it anyway
<solnic>
immutable objects + methods that act like pure funtions
<solnic>
I think immutability in ruby is becoming more and more popular
<solnic>
I have NO CLUE how ruby is gonna behave in heavy environments with lots of immutable objects flying around though
<dkubb>
yeah it's easier to reason about things because state changes are explicit
<solnic>
dkubb: btw I gave a short talk about immutable objects in ruby at a local ruby users group
<solnic>
ppl seemed to really like it
<dkubb>
axiom is probably the largest system in the ruby community that uses immutable objects (oss at least)
<dkubb>
and it works really well
<dkubb>
granted it's a narrow scope
<dkubb>
it's an ast with some basic functionality on each node.. not a business system
<dkubb>
solnic: that's really cool
<solnic>
I think I'm gonna turn it into something bigger and send some proposals to ruby confs later this year
<dkubb>
there's a trend in that direction
<dkubb>
especially as people start to think more about threading and concurrency
<cored>
pretty cool
<cored>
I have to download all the other Gary's videos
<cored>
dkubb: btw, don't know if you saw my PR but mbj told me I'm not in the right direction
<dkubb>
cored: I think I see where you're going.. it's not quite in the right direction, but it's also not completely wrong.. let me back up a bit
<dkubb>
cored: ok, so in axiom an attribute represents two pieces of data: a name and a type
<dkubb>
cored: a type represents only really one thing: constraints an object needs to match to be considered valid
<dkubb>
cored: in axiom an attribute will has-a type.. at least once we go all the way with this refactoring
<dkubb>
cored: right now axiom kind of confuses things because the attribute subclass represents a kind of type.. and the object is doing double duty
<mbj>
dkubb: We are back to 4.0 with mutant :D
<dkubb>
mbj: nice!
<dkubb>
cored: so my plan with this refactoring is not to completely do away with attribute objects, or even the subclasses.. that can come later
<mbj>
dkubb: I'll add mutation reports now, and than we can release a 0.3.beta1
<dkubb>
cored: what I would want is for the subclasses to delegate type related functionality to the type object that it has. there should be a 1:1 correspondence between each Axiom::Attribute subclass and an axiom type
<dkubb>
cored: for the immediate future, we still need the Axiom::Attribute subclasses because there are methods mixed into those subclasses that are needed by axiom.. for example, Axiom::Attribute::String has a #length method, this is so we can do: relation.restrict { |r| r[:name].length.gte(100) } .. the #length method returns Axiom::Attribute::Integer, which has a #gte method mixed into it
<dkubb>
mbj: that sounds awesome. I've got a bunch of gems I can run against it
<mbj>
dkubb: yeah!
<cored>
dkubb: I got a little confuse becuase of the .primitive method stuff
<dkubb>
cored: one way that Axiom::Attribute needs to change is in how it does type inference. it currently introspects the subclass to get the primitive, and then uses some logic to compute if the subclass is a viable candidate. that has to go away. in axiom-types the biggest change I made is that the decision on whether to handle something is compelely encapsulated in the type. it' a black box from the pov of the caller
<dkubb>
cored: each type has it's own logic for saying "yes, I handle this".. I didn't want to push that up to a base class because it would make it too complex, and too hard to extend
<dkubb>
well, actually, there's some functionality it inherits from the parent, but ultimately the type is completely responsible
<cored>
that's the code where that happens
<dkubb>
ok, so I can tell you how that'll change
<cored>
the inference stuff, but I tried several things Axiom::Types.infer Axiom::Types::Type.include?(descendant)
<cored>
but I got Axiom::Types::String back, always
<cored>
which what you want is returning the type from axiom/attributes
<dkubb>
you'll do something like: type = Axiom::Types.infer(operand.class); descendants.detect { |descendant| type.eql?(descendant.type) }
<dkubb>
this means each Axiom::Attribute subclass will get a type class method
<dkubb>
and that class method will return the Axiom::Types instance that corresponds 1:1 to the Axiom::Attribute subclass
<dkubb>
we can optimize that lookup later using a Hash or something, but that's the gist of it
<dkubb>
this is step #1 to get axiom-types integrated into axiom. further refactoring will happen, and potentially Axiom::Attribute subclasses will go away or become greatly simplified, but I don't want to get ahead of ourselves
<dkubb>
if we try to skip a step and go to that it'll be too hard and we'll never complete it
<dkubb>
there's the tendency to see all the steps "A" through "Z" and want to skip right to "Z" because you want to get to the end in sight, but it's more important to progress through in the smallest steps possible so you have working software at every step
<dkubb>
imho anyway. chances are the end goal will change as your understanding grows too
<cored>
I see
<dkubb>
cored: does this all make more sense now?
<dkubb>
I just want to make sure I explained it properly this time. I realize I didn't explain it too well before because I had to run off to work
<cored>
dkubb: yes, it does make more sense
<cored>
but Axiom::Types.infer doesn't exist Axiom::Types::Type.infer do
djsell has joined #rom-rb
<mbj>
dkubb: About reporting
<mbj>
dkubb: I used to report all uncovered mutations just after the mutation
<mbj>
dkubb: I know see the following options, print the mutation report per subject (once finished)
<mbj>
dkubb: Or per run, above the final statistics
<dkubb>
mbj: ahh yeah, that would be nice to have while writing something. usually I would use guard-mutant on stuff that I already got to 100% mutant coverage, or green field dev where I can keep it at 100%
<mbj>
This is what the new "progress looks like"
<mbj>
A line per subject
<mbj>
red F and green .
<mbj>
And a summary
<cored>
dkubb: undefined method `infer' for Axiom::Types:Module
<mbj>
Gibheer: lexing and parsing must be done at *once*!
<Gibheer>
I know, just was interested in the lexer part
<dkubb>
cored: ahh yeah, that's nice. you may even be able to get rid of line 4
<dkubb>
cored: like I said, we can use the same trick in Axiom::Types later on to push lines 6 and 7 into a Hash lookup so it's faster, but it's more important that it work
<cored>
dkubb: but I'm getting undefined method .infer for Axiom::Types
<cored>
which is wierd
<cored>
the spec suite for axiom-types runs fine, but I'm getting that inside Axiom
<dkubb>
cored: maybe that file isn't getting required?
<dkubb>
cored: is Axiom::Types.finalize being called beforehand?
<cored>
dkubb: nop
<solnic>
mbj: dude, I'm sorry but barely anything from your session will be left :P
<mbj>
solnic: lol
<mbj>
solnic: I expect so, just go on.
<solnic>
mbj: I will explain later ;)
<dkubb>
cored: as a test, try calling Axiom::Types.finalize just after requiring axiom-types. the real fix will be to add Axiom::Attribute.finalize and have it delegate to Axiom::Types.finalize in the future, and then require it be called, but I just want to see if that's the issue