<dkubb>
I'll make a tiny shim to make it work with axiom
<solnic>
yup
mbj has joined #rom-rb
mbj has quit [Client Quit]
<dkubb>
solnic: ok, I'm off to bed now. good night
<solnic>
good night dkubb!
mbj has joined #rom-rb
machuga|away is now known as machuga
postmodern has quit [Quit: Leaving]
solnic has quit [Quit: Leaving...]
machuga is now known as machuga|away
knowtheory has joined #rom-rb
solnic has joined #rom-rb
<dbussink>
mbj: ping?
cored has joined #rom-rb
<mbj>
dbussink: busy, sorry
<dbussink>
mbj: ah ok, for when you have time, looked at that lchmod stuff, but we do have that on rubinius, so not sure what is up then
snusnu has joined #rom-rb
solnic has quit [Quit: Leaving...]
solnic has joined #rom-rb
<mbj>
dbussink: You can reproduce with a git source like: gem 'mutant', :git => 'https://github.com/mbj/mutant', :rev => '3e47dd363ba8c95e7a6b1f2c948df755eca1a9db'
<mbj>
That rev is the one before I removed the symlinked executable from gemspec.
<mbj>
Or install mutant 0.3.0.beta21
<mbj>
better beta20 :D
<dbussink>
mbj: hmm, just installed successfully :S
theCrab has joined #rom-rb
<mbj>
oha
<mbj>
wich version?
<dbussink>
mbj: tried 0.3.0.beta20 on both os x and ubuntu 12.04 64 bit
<dbussink>
mbj: both worked fine
<mbj>
mhh
<mbj>
dbussink: can you try the git source?
<dbussink>
ah, then it fails
<dbussink>
weird stuff
<dbussink>
gem install is fine
<dbussink>
but bundle seems weird
<dbussink>
does bundler have a mode to print backtraces etc.?
<mbj>
dbussink: --verbose or --backtrace
<mbj>
I tracked it down to file_utils but dunoo rember
<mbj>
There it calls File.lchown
<snusnu>
yo mbj
<snusnu>
mbj: quick substation question: do you agree that a failure_chain makes no sense for outgoing processors? essentially, the failure chain should be invoked when a processing stepp produced an application error (error in business logic, not exception) .. so once the pivot got invoked, nothing can go wrong, logic wise .. agreed?
<dkubb>
snusnu: I wonder if we should try building a few systems with ROM and Substation before any wide releases.. like a status page thing
<mbj>
dkubb: yeah
<dkubb>
mbj: rackspace has offered a vm for us to host with, I just need to do a bit of setup on my end
<mbj>
dkubb: nice, never used their service, I need to host within european legislation.
cored has quit [Quit: leaving]
cored has joined #rom-rb
kpwz has quit [Read error: Connection reset by peer]
kpwz has joined #rom-rb
cored has quit [Ping timeout: 268 seconds]
cored has joined #rom-rb
cored has joined #rom-rb
mbj has quit [Quit: Lost terminal]
mbj has joined #rom-rb
cored has quit [Ping timeout: 264 seconds]
cored has joined #rom-rb
therabidbanana has joined #rom-rb
<snusnu>
dkubb: yeah, that sounds like a plan! imo the the status page would be a perfect fit, if rackspace allows us to host those, even better
<snusnu>
dkubb: i was also talking to mbj earlier on, about the possibility to revive alfred using rom and substation
<dkubb>
that would be neat
<dkubb>
I think what we should do is think about any tools or things we need to aid ourselves in development, or to help the community
<dkubb>
for example, say we were using github issues with milestones, we could aggregate that across all our projects and show how close or far away we are from a release
<dkubb>
or just showing the current travis build status for all our projects and keeping it all green
<dkubb>
having something like http://status.aws.amazon.com/ but showing the status of everything and being able to see where we need to focus on
<snusnu>
yeah, that was the idea for alfred too, back then … it should've involved into something every oss project (org) can use to track progress, centralize dynamic information and therefore help communicate to interested devs
<dkubb>
showing trends so we know when we've broken the build on master in the last week, etc
<dkubb>
yeah
<dkubb>
I would like something that aggregates all our issues in one place
<dkubb>
something I can check and make sure is kept to a minimum, etc
<snusnu>
yeah that'd be sweet
<dkubb>
I would also like to aggregate stackoverflow questions too
<dkubb>
because those go unanswered sometimes for DM
<dkubb>
while I sometimes try to answer them I find it hard to always check up on because it's not at the top of my mind
<snusnu>
absolutely
<dkubb>
I'd like to see links to new SO questions on ROM posted to this channel
<snusnu>
i realize that building an app adds to our workload, but imo the benefits outweigh the costs (even if the costs are delivering our components a bit later)
<snusnu>
we need a reallife testbed for the stuff we develop anyway
<dkubb>
we need to get some real-world feedback on the whole stack
<snusnu>
yeah
<dkubb>
I've used many of the pieces individually on my own projects
<dkubb>
with good results
<dkubb>
but you never know how a full system is going to work until you try it
<snusnu>
right
<dkubb>
individually the components could be awesome, but they could suck because the integration isn't good yet
<dkubb>
obviously I think we're capable of fixing this kind of problem, otherwise I probably wouldn't be involved in this, but we need a good feedback loop
<snusnu>
yeah, and i have the feeling, that with rom especially, we plus others, need some kind of "role model" app to look at … the approach to designing an app will be substantially different from what peope are used to doing
<snusnu>
heh yeah
<dkubb>
snusnu: I was saying to solnic yesterday they he should snusnu-ify the ROM::Relation docs
<dkubb>
snusnu: it would be nice for us to come up with a template for our README files
<therabidbanana>
Woah, totally missed out on hearing about substation - this project looks very much to what we've been doing internally with our app, but with better conventions.
<dkubb>
keeping the README succinct and on point, while giving people a jumping off point to do deeper
<dkubb>
I need to do something with substation
<dkubb>
snusnu: how do you like rubocop?
<dkubb>
snusnu: for multiline let() blocks do you use do/end or {} ?
<snusnu>
dkubb: i agree with your thoughts on shared parts in a readme
<snusnu>
dkubb: currently, the substation readme is too big, and sadly also kinda out of date
<snusnu>
therabidbanana: feel free to ask me anything about substation
<dkubb>
snusnu: yeah, I don't know if the solution is to put those kinds of docs in the wiki, or if we should have executable examples that we use to generate html docs somewhere
<snusnu>
therabidbanana: it's still under heavy development, but i'm starting to get happier and happier with it
<snusnu>
dkubb: i dunno why, but i don't like wikis that much
<dkubb>
I kind of am attracted to the idea of describing an example, and then making sure it is tested
<snusnu>
absolutely, that'd be most awesome
<dkubb>
then the examples can be run as part of the specs
<dkubb>
and you'd know right away if they break
<snusnu>
that would be so cool
<dkubb>
I've actually thought about some way to extract the @example blocks and then run them as specs
<dkubb>
on the API docs side of things. those can tend to get out of date too
<snusnu>
dkubb: yeah, i've seen this over and over again :/
<snusnu>
dkubb: re rubocop, i really like it
<snusnu>
dkubb: apart from its ability to configure exceptions from its rules, it's great
<snusnu>
dkubb: s/ability/missing ability
<snusnu>
or, inability
<snusnu>
heh
<snusnu>
therabidbanana: fwiw, substation actually is an implementation of the chain of responsibility pattern .. that's what it provides, plus a "dispatcher" on top, that allows for easy calling of any named chain
<snusnu>
therabidbanana: also, the readme is somewhat out of date, but i will fix that with the next release
<therabidbanana>
snusnu: I think I read about the pattern before when I was trying to figure out if there were any good concrete ruby examples, but couldn't really find any.
<snusnu>
therabidbanana: it feels like a really fitting pattern for request/response cycle apps
<therabidbanana>
Our take on it is somewhat more loosely defined, uses a more callback oriented approach. Rather than returning a response with success/error states, we let the actions call back a success or error function.
<therabidbanana>
But yes, it's been very helpful for keeping a clean code base in our web app. It fits very well to that use case.
<dkubb>
therabidbanana: I use a chain of responsibility in axiom-optimizer
<dkubb>
it allows me to specify a series of optimizers for each kind of relation type. they are applied in series and the result of one is fed into the next
<dkubb>
an object basically enters the chain, and at the other end it comes out optimized
<dkubb>
or it just passes through if it's already optimized
<dkubb>
each object in the chain has a way to test if it should apply any logic, it can choose to forward the object on or return a new equivalent object
<snusnu>
therabidbanana: maybe that callback like functionality is present in substation by using failure chains .. you can register a failure chain with every incoming *processor*, that will get invoked if your app encounters an application error, i.e. an errorneous state according to your business logic … in addition to that, every *chain* has a failure chain, that gets invoked in case of an exception in "client" code .. i.e. a bug
<dkubb>
I should watch that talk
<therabidbanana>
snusnu: does substation make it easy to add processors that cover every incoming action? That's another difference I'm seeing from our pattern - rather than defining what observes each action up front, we just have a bunch of observers that watch for events they care about.
<snusnu>
the "funny" thing is, substation only evolved to be a chain of responsibility .. i didn't have that in mind .. but after some time i noticed that it actually implements that pattern ;)
<therabidbanana>
So we'd have an email observer that only cares about when a new campaign is created and sends an email out for that event, but otherwise just passes the event on down the chain of observers.
<snusnu>
therabidbanana: not entirely sure if i understand your question … every chain in substation represents a usecase in your app .. the pivot handler of every chain, *implements* the usecase .. incoming processors are there to "prepare" the user input so that your domain model can invoke the usecase
<snusnu>
therabidbanana: you can then register observers for any pivot (usecase)
<snusnu>
therabidbanana: they get passed the response of the usecase, and can do things based on wether the response was a success or a failure
<therabidbanana>
snusnu: But do those end up having to be set up individually on the router, or can you set catchall observers to listen to all responses and only act on the ones they care about?
<dkubb>
snusnu: I would like to find a way to run rubocop against the code in @example
<snusnu>
therabidbanana: interesting .. if i understand it correctly, currently there's no way for the "catch all" you're describing
<snusnu>
therabidbanana: altho thinking about it .. you could always register an outgoing processor, that inspects the response, and does stuff .. it could be the same for every chain
<snusnu>
therabidbanana: outgoing processors are the stuff that "prepare" your domain model output to be consumable by clients of the app .. say, serializing to json, rendering html, etc
<snusnu>
dkubb: interesting, good idea i think .. it's code that should love up to the same standards as every other code .. even more so, once it's used as a spec
<snusnu>
@dkubb i absolutely agree with that, for all the reasons you mentioned!
<snusnu>
dkubb: i especially like the #fetch like behavior
<dkubb>
snusnu: I'm actually not against "humanifying" query methods, but I'd like to keep them simple and single purposed until we get more real-world testing. for now I'd want to focus on the simplest possible thing that can work, and providing one way to do anything
jessekempf has quit [Quit: Leaving.]
<dkubb>
I'm not a huge fan of TIMTOWTDI, despite my perl background. from an API design pov I identify more with python's "There should be one-- and preferably only one --obvious way to do it"
cored has quit [Remote host closed the connection]
cored has joined #rom-rb
cored has joined #rom-rb
<snusnu>
dkubb: yeah, one way to do it is nice oftentimes, less stuff to remember
<dkubb>
it's also easier to maintain
<dkubb>
and easier to learn
<snusnu>
absolutely
<dkubb>
I remember coming from perl to ruby originally in 2005, and I couldn't believe how simple the language was
<dkubb>
I was like "what I don't have to memorize all these edge cases"
<snusnu>
hehe
<dkubb>
granted it was a good experience starting with perl, my brain did get used to complex language so that now when I see other languages almost all of them are simple syntactically in comparison
<snusnu>
heh, i basically only did c++/java before coming to ruby, well, and a nice niche language, actually called "Nice" :)
<dbussink>
mbj: ah, wait, i was confusing lchown with lchmod
<dbussink>
mbj: the latter is indeed not available on linux
<dbussink>
so i guess mri emulates it somehow
<dbussink>
or just uses chmod maybe
<mbj>
dbussink: oha
<mbj>
dbussink: Most likely this is not part of rubyspec?
<solnic>
I also realized one thing - ROM::Relation exposes query interface w/o actually mapping attribute names...
<solnic>
that kinda...sucks :)
<solnic>
I completely forgot about this
<dkubb>
oh I see, should it be delegating that to the mapper?
<solnic>
yes
<dkubb>
hmm
<solnic>
as in, "hey mapper gimme attribute names on the axiom side for these names"
<dkubb>
actually, you know, the mapper *could* use the axiom rename stuff
<solnic>
ok?
<dbussink>
mbj: ugh, crap
<dkubb>
so ROM::Relation hands the mapper a relation, the mapper uses rename on it to map the axiom attributes to your domain attributes, and then hands it back to you
<dbussink>
mbj: lchmod actually compiles on linux
<dkubb>
then all your inserts/deletes/queries can use the domain attribute names
<dbussink>
but always returns -1 and Function not implemented as error message
<dbussink>
so even detecting whether it works isn't easy
<dkubb>
so then you're not having to pipe every read/write or whatever through mapper
<dkubb>
that was kind of my intention with axiom relation's rename stuff
<dkubb>
it can map the names up-front. of cours dump/load can do other things, like coercions, but they shouldn't necessarily have to do all sorts of stuff with attribute renaming
<dkubb>
solnic: axiom relations will propagate writes to the renamed attributes down to the original attributes btw. it'll also propagate restriction, projection and everything else
<dkubb>
solnic: originally do you get the relation from the mapper instance? like does it have a default mapper? if so, then you can do the rename up-front and then every operation to it from then on will use the new names
<mbj>
dbussink: I hate this kind of stuff :D
<dkubb>
s/does it have a default mapper/does the mapper have a default relation/
<mbj>
dkubb, solnic, snusnu1: STOP TALKING ABOUT ROM NOW
<mbj>
my backlog becomes longer and longer :D
<dkubb>
HAH
<dkubb>
sorry
<mbj>
lulz, this is a joke man :D
<dkubb>
I'm in the middle between two contracts, so I'm doing lots of oss stuff today
solnic has quit [Quit: Leaving...]
skylar_ has joined #rom-rb
solnic has joined #rom-rb
kapowaz has quit [Ping timeout: 246 seconds]
<solnic>
dkubb: no, mapper has only the header
<solnic>
it has its own header which wraps axiom header
<dkubb>
solnic: ahh I see. where does the relation come from? some kind of registry?
<solnic>
mbj: no
<solnic>
dkubb: from schema
<dkubb>
solnic: I would assume the mapper knows the mapping of the original to new attribute names?
<solnic>
yes
<dkubb>
ok that's what I thought
<solnic>
mbj: NO*
<dkubb>
solnic: so you could have a method that accepts a relation, renames it to match, and returns a renamed relation?
<solnic>
dkubb: pretty much
<solnic>
I could have mapper.rename(relation)
<solnic>
so restrict would do sth like new(mapper.rename(relation.restrict(*args, &block)))
<dkubb>
solnic: ROM::Relation#initialize could be: def initialize(relation, mapper) @mapper = mapper; @relation = @mapper.rename(relation); end
<dkubb>
then you don't have to do any special renaming
<dkubb>
solnic: from then on mapper's #load and #dump can assume the attributes will at least line up. there might be more like coercions to be done, but it'll at least be equal
solnic has quit [Read error: Connection reset by peer]
solnic has joined #rom-rb
<dkubb>
dbussink: that is awesome, thanks for that
<dbussink>
dkubb: linux and lchmod is a ghetto :P
<dkubb>
solnic: maybe mapper#rename isn't the best name though. you may want to also do a projection of the attributes you're mapping
kapowaz has joined #rom-rb
<dkubb>
solnic: I don't know if you had any plans to allow the mapper to configure any special transformations on the relation.. like say restricting things.. say you had an ActiveUserMapper you might want to do relation.restrict(active: true) or something
<dkubb>
solnic: even if it was just mapper#relation(relation) .. and by default it did a projection/rename that would be good, then you could override it and do: def relation(*) super.restrict(active: true) end
<dkubb>
solnic: although I do wish I had a better name than just #relation
<mbj>
dkubb: That is the bug I was speaking about. Adamantium redefines new on the singleton and calls super, if you alias new to something other and call the alias super dispatches to the aliased, not the original name.
skylar_ has quit [Quit: skylar_]
<mbj>
dbussink: rubinius is sane :D
<mbj>
dbussink: And thx for the lchown fix.
skylar_ has joined #rom-rb
<jessekempf>
mbj, dkubb: How would you prefer I handle a problem in parser that causes noop mutations to fail? The MRI is quite happy for someone to say [1, 2, 3].reduce([]) { |arr, _| next(arr) }, but parser doesn't seem to know that next can take an argument.
<mbj>
I'll have to keep the --zombie flag, mostly because symlinks do not work well in the jvm world.
<solnic>
dkubb: yeah the mapper isn't anything special so you can do whatever you want with the relation there
skylar_ has quit [Client Quit]
skylar_ has joined #rom-rb
<solnic>
dkubb: for things like restricted relations you can just do that on the schema definition level
<mbj>
jessekempf: I just ran ruby-parse -e "[1, 2, 3].reduce([]) { |arr, _| next(arr) }"
<mbj>
jessekempf: And parser correctly handles this.
<mbj>
jessekempf: Can you show me original and reproduced code?
<dkubb>
solnic: ok, I just wondered if the mapper was allowed to specify more than a rename.. like if it was going to restrict the relation to some subset for the mapping
skylar_ has quit [Client Quit]
skylar_ has joined #rom-rb
<solnic>
dkubb: up to us
<solnic>
what do you think?
<solnic>
I'd say it could be done on the schema level
<mbj>
jessekempf: So it does not seem to be parsers fault!
<solnic>
so that mapper deals only with...mapping :)
<solnic>
I used the word #rename but I meant something that will map relation, do something with it, and that it would be always called in certain moments in rom::relation
<dkubb>
solnic: ok. so if we just have it be something simple like this, and don't do too much work in it besides projection/rename, then we'll be ok? or do you think projection isn't even necessary
<dkubb>
I kind of asumed we would be projecting only the attributes we map, or are we going to pass-through anything we don't explicitly map?
<mbj>
jessekempf: and released as unparser-0.0.13, bundle update and happy mutating :D
<solnic>
oh I want to have projection; it's something that was missing in the initial mapper prototype
<dkubb>
ahh ok
skylar_ has quit [Client Quit]
<solnic>
because you can configure mapping to be only a subset of what's inside the relation
<dkubb>
keep in mind, projecting away required attributes with no defaults makes the relation read-only
skylar_ has joined #rom-rb
<solnic>
like, only id, name and email on user relation for example
<dkubb>
I think that goes without saying, but I want to make sure everyone knows it
<solnic>
actually no, I didn't know that :)
<solnic>
but it makes perfect sense
<dkubb>
yeah if you project away id, then you can't update or delete a user
<solnic>
well, when I thought about adding projection support I only thought about read-mode anyway
<dkubb>
well, in theory you still could if there was still a unique key
solnic has quit [Read error: Connection reset by peer]
skylar_ has quit [Client Quit]
solnic has joined #rom-rb
skylar_ has joined #rom-rb
<solnic>
dkubb: huh sorry I was disconnected
<dkubb>
no worries
<dkubb>
my last statement was 'well, in theory you still could if there was still a unique key"
<solnic>
right
<solnic>
well, let's start with read-only
<mbj>
okay guys moving locations, asked txus about handing over channel to me.
<dkubb>
solnic: what about an interface like: mapper#remap(relation) -> new_relation
<dkubb>
then we don't confused people with #map
<solnic>
hmm or mapper#call(relation)?
skylar_ has quit [Client Quit]
skylar_ has joined #rom-rb
snusnu1 has quit [Quit: Leaving.]
skylar_ has quit [Client Quit]
<dkubb>
solnic: actually that might be even better, especially since it is the main responsibility of the mapper
skylar_ has joined #rom-rb
<solnic>
dkubb: + snusnu never liked the word "remap" :)
<solnic>
esp that it doesn't always mean re-mapping
<dkubb>
solnic: then people can duck-type a mapper using a proc for testing
<solnic>
yes that too
skylar_ has quit [Client Quit]
skylar_ has joined #rom-rb
<solnic>
dkubb: ok so to re-iterate; mapper#call(relation) is used in ROM::Relation#initialize when assigning relation ivar rite? and all it does for now is to call relation#rename for attributes that needs renaming
<solnic>
this way we axiom will give us back tuples with expected attributes
skylar_ has quit [Client Quit]
skylar_ has joined #rom-rb
<solnic>
and it'll also work with insert/update/delete
<mbj>
Yeah injecting procs is also nice for debugging.
<dkubb>
solnic: yes, although one extra thing. I think it should do: relation.project(mapping.keys).rename(mapping) .. assuming mapping is a Hash where the key is the old name, and the value is the new name
<solnic>
dkubb: I have this info inside special mapper header
<dkubb>
obviously I don't know what it's actually called
<dkubb>
ok
<solnic>
it wraps axiom header and adds mapping-related info on top of it
skylar_ has quit [Client Quit]
skylar_ has joined #rom-rb
skylar_ has quit [Client Quit]
skylar_ has joined #rom-rb
travis-ci has joined #rom-rb
<travis-ci>
[travis-ci] mbj/mutant#584 (master - 64d8ee0 : Markus Schirp): The build was broken.
<snusnu>
dkubb: note how there's an lvar named processors, and the class has a protected attr_reader :processors too .. and @processors is (must) already be assigned
skylar_ has joined #rom-rb
<snusnu>
dkubb: i bet that's the issue
<dkubb>
snusnu: hmm, yeah, that shouldn't matter
<snusnu>
dkubb: it shouldn't, but it might cause the bug?
<dkubb>
snusnu: are you changing it to: processors.each(&method(:<<))
<snusnu>
dkubb: yes
skylar_ has quit [Client Quit]
<snusnu>
dkubb: and even if i do puts(method(:<<)) in #initialize i get the same error ..
<snusnu>
dkubb: ah, i see .. i was just about to ask if you consider using &method(:<<) important enough to impose such a "limitation" on the code .. i mean, suddenly, something that's more or less free where wrt its source location, becomes dependent on it, only because of using that idiom
mbj has quit [Client Quit]
<snusnu>
dkubb: i realize how it needs to be after #initialize anyway, so yeah, maybe it's still worth keeping the idiom, and either define it at the bottom of the class, or just as you did with axiom, after requiring the complete lib
<dkubb>
snusnu: yeah, I would generally do it at the bottom. not just because of the idiom, but because you have to do it somewhere, and in the middle would be worse than the bottom imho
<dkubb>
snusnu: although in top-level lib file is fine too
<snusnu>
dkubb: true .. it already felt a bit weird, having it right after #initialize
<snusnu>
dkubb: then again, that class ends with a private section, which would make sticking it at the bottom of the class even weirder
<snusnu>
dkubb: so i guess i'll go with the approach you took in axiom
<cored>
hello all
<cored>
which is the fastest way to add devtools to an existing project?
<snusnu>
cored: hey
<snusnu>
cored: there's an executable now, just call "devtools init" and it should copy all default configs to your project dir
<dkubb>
because devtools won't have copied the Gemfile.devtools file over yet
<dkubb>
so I would add it to my gemfile, bundle (install), then devtools init
<snusnu>
dkubb: right, thx for correcting my lazy response :)
<snusnu>
dkubb: btw, i just read through the hexagonal design link therabidbanana posted … interestingly enough, this is almost precisely like substation started out initially, for reference, the code is still there at https://github.com/snusnu/substation/tree/rails-integration
<snusnu>
dkubb: the only *very interesting* difference is, that publish/subscribe idea to communicate with the rails controller
<snusnu>
dkubb: i went down the guy's initial path .. injecting the rails controller into my action class
<snusnu>
dkubb: at that point in time, substation did something else too .. it automatically created a class from a controller "macro" like: handle :index .. what it would do, was to generate a stub index action class, give it rails default index behavior, and define SomeController#index so that it simply invoked the Index class
<snusnu>
dkubb: once we decided to ditch rails completely, i started rewriting substation to what it is now
<dkubb>
snusnu: that presentation he pasted is quite good actually.. not just the article
<dkubb>
interesting
<dkubb>
snusnu: does it depend on rack?
<snusnu>
dkubb: while it can be used inside rails, i have no intentions to actually make that integration particularly easy .. all that's needed is rack and a router
<snusnu>
dkubb: it doesn't no, but it can be hooked into rack easily
<dkubb>
ahh, that's what I meant
<dkubb>
it uses the rack interface
<dkubb>
or is it decoupled from http/rack?
<snusnu>
dkubb: the eventual plan is to use rack, and a router, plus mbj/request and mbj/response … the first incoming processor will turn the rack env into an mbj/request .. and the last outgoing one willl create an mbj/response
<snusnu>
it is completely decoupled
<dkubb>
ahh I see
<snusnu>
it knows nothing about rack
<dkubb>
I'm curious to see how that works out
<snusnu>
me too lol
<snusnu>
the good thing is .. mbj already does that in production
<snusnu>
!
<dkubb>
not that I have any doubts, but I don't think I've seen an app built like that
travis-ci has joined #rom-rb
<travis-ci>
[travis-ci] mbj/mutant#586 (strict-constant-lookup - b894958 : Dan Kubb): The build was broken.
<snusnu>
dkubb: thinking about it, using substation behind rails would probably be very easy .. you'd need to build your app, without any rails knowledge .. and then, from every rails action, you'd use the substation dispatcher to dispatch to the respective action .. you'd probably pass rails params to the chain, and the incoming processors would need to transform them into a form your application can consume
<snusnu>
dkubb: if you come up with some sort of a macro like i had initially .. that would probably boil rails controller down to nr_of_actions+2 loc
<snusnu>
heh
<snusnu>
only, at this point, i see no more value in rails :)
<dkubb>
hehe
<snusnu>
dkubb: what i like about substation, is that it's really nothing more than a (dare i say) quite elaborate implementation of a chain of responsibility, plus a few conventions (mostly, everything needs to respond to #call)
<snusnu>
dkubb: that makes it very easy to hook it into anything else
<snusnu>
dkubb: it needs input, and will produce output, and it will allow to fail gracefully using failure chains and the exception chain .. pivot handlers (the actual action) can also have observers registered .. i can't think of much more one needs
<snusnu>
dkubb: the nice side effect is, that by doing separate steps in separate processors, you almost can't violate SRP, at least not within the repetitive "http shell" crap
<snusnu>
dkubb: that's also hugely thx to mbj's vanguard and ducktrap
postmodern has quit [Quit: Leaving]
<cored>
dkubb: great will do that, thanks
dkubb has quit [Ping timeout: 264 seconds]
<cored>
snusnu: hi, sorry did not see your message because was on another terminal ;-)
dkubb has joined #rom-rb
<snusnu>
cored: heh no worries, dkubb had a much better answer anyway ;)
postmodern has joined #rom-rb
<cored>
ditto
<cored>
I want to see how bad is my old code for an old project
<cored>
also I know it should be pretty bad, I'm mostly doing some sort of forwardable calls between a bunch of a class methods
<cored>
maybe that's why I haven't finish that code is kinda hard to move it forward
<dkubb>
cored: remember too, it's not necessarily about measuring the current state of the code, it's more about the direction the code is moving.. it helps make sure you're only ever maintaining or raising the bar
<dkubb>
snusnu: flay isn't perfect either
<dkubb>
snusnu: I consider the old code boilerplate, but I'd guess that flay might score "&" and method() higher
<cored>
dkubb: got it, basically I have to know if the code is improving or if not knowing the reasons why
<dkubb>
cored: yeah, and it'll tell you if anything falls below the thresholds you set. I think our approach using thresholds is the main difference between how we use metrics and how most people use them
<dkubb>
I don't think reporting is enough. people ignore reports all the time
<dkubb>
it's human nature. but if the build breaks then you get feedback on what you're doing
<dkubb>
although it's good to try to interpret the results and understand why something was flagged. sometimes it's wrong, like in the case snusnus was just talking about
<cored>
yes
<cored>
I like that also
<dkubb>
it's good sometimes to try to think "hmm, why does the author of this tool, a person who obviously cares about code quality, decide that this code needs to be flagged"
<dkubb>
it can lead you down into learning things like Feature Envy for example
<snusnu>
dkubb: out of curiosity, on github you're saying: There are cases where "or" is better (compared to ||) … define "better" please ;)
<dkubb>
I'd heard about it before starting this process, and thought I understood it, but I didn't really understand some of these code smells until I saw real examples in my own code
<dkubb>
snusnu: I thought I mentioned the specific cases
<dkubb>
snusnu: basically "and" and "or" were designed for control-flow, and "&&" and "||" were designed for boolean operations.
<cored>
dkubb: isn't the same thing?
<cored>
oh sorry
<cored>
I mis read
<snusnu>
dkubb: ah ok, i didn't get that, i thought those were your *personal* preferences (not to lessen that in any way)
<cored>
dkubb: is that a syntatic rule?
<dkubb>
snusnu: "and" and "or" were borrowed from perl originally, and they are used to control statement order when the return value is not as important .. the boolean operators are for evaluating (and sometimes short-circuiting) methods that return true or false
<dkubb>
cored: no, people seem to use them interchangably
<dkubb>
cored: I like to use them in the way they were originally designed
<cored>
I see
<cored>
agree, I feel like I'm learned like 150% more than my latest job just to read conversations on this chat :-)
<snusnu>
dkubb: ok, that sounds fair enough .. so i wonder, why do rubocop authors go against the original purpose?
<dkubb>
snusnu: I dunno really. I think in some cases, peolpe don't really understand those operators so they decide to just choose a subset
<dkubb>
snusnu: maybe it's because some devs use them incorrectly because they don't understand that the precedence of "and" is different than "&&", and they cause bugs, so people think not using them is going to solve the bugs
<dkubb>
I think bugs are best solved by understanding the language
<dkubb>
and through education
<dkubb>
being aware of operator precedence is a great thing to have
<dkubb>
it allows you to write code and understand how each part of an expression is going to be evaluated so that you can write it in the simplest possible terms
<dkubb>
and/or debug code written by others
<dkubb>
cored: yeah, I typically learn way more doing oss than I do at any job I've ever had
<dkubb>
cored: not that I choose easy jobs, but I can choose to target difficult projects and/or work on projects where I will be challenged to learn somethign new
<postmodern>
C has braindamanged me, i use explicit if/unless for those types of statements
<postmodern>
and use || && otherwise
<cored>
dkubb: :-)
<dkubb>
maybe my usage of "and" and "or" shows I have been brain damaged by perl
<snusnu>
hah
<dkubb>
snusnu: btw, I noticed how you're using detect there. do you think you should be overloading an Enumerable method? maybe having the name be something like get() .. or renaming your #[] method to #fetch() and what you previously had as #detect become #[]
<dkubb>
snusnu: in my Enumerable classes I generally try to avoid overriding Enumerable methods unless I support the same interface
jdsiegel_ is now known as jdsiegel
<snusnu>
dkubb: nice catch! i forgot about that when extracting the class .. the class it was extracted from wasn't enumerable
<dkubb>
snusnu: I try to adhere to the Liskov Substitution Principle when inheriting or mixing in functionality from elsewhere
<dkubb>
snusnu: which is why this came to mind viewing this code
<snusnu>
dkubb: i need to think about that in those situations, thx for the tip