<solnic>
postmodern: gotta step away for a second, brb
<postmodern>
solnic, thank you
<postmodern>
these things might not be immediately solvable, but that's no reason you shouldn't try
<mbj>
morning
<mbj>
postmodern: Do you realize that if you dont like some code its your responsibility to fix it in OSS? If its a bug, or a misbehavior I think its the authors responsibility.
skade has joined #rom-rb
<postmodern>
mbj, no it's not my responsibility
<mbj>
If you want to have it fixed it is ;)
<postmodern>
mbj, i didn't like rbenv, it's not my responsibility to re-architect it
<postmodern>
mbj, sure i will try to fix minor things
<mbj>
If you are not happy. Dont use it.
<mbj>
I have my reasons for indirections in morpher via an AST.
<postmodern>
mbj, but it's not my responsibility to refactor complex code that i didn't write, since the more changes I make the less likely you will accept it
<mbj>
Because I use it for many other domains and I need a shared IR, to not write optimizers / analisers over and over again.
<postmodern>
mbj, plus i have a very demanding day job :(
<mbj>
postmodern: Same here.
<mbj>
postmodern: I write the code to solve my problems.
<postmodern>
mbj, yeah which is why i was advocating writing simple code that easy to maintain
<mbj>
postmodern: If these code helps stuff like ROM I'm more than happy.
<postmodern>
mbj, instead of this over-SRP primitive-phobia code
<mbj>
postmodern: My code is very simlpe. You dont see it. Because you did not even took a look in the reasons behind morpher.
<postmodern>
mbj, see again, it looks perfect to you because you wrote it
<mbj>
postmodern: Feel free to write a mapper backend other than morpher.
skade_ has joined #rom-rb
<postmodern>
mbj, there's a cognitive dissonance here
<mbj>
Hehe, No I dont think so.
<postmodern>
mbj, I'm not talking about a full on mapper
<mbj>
You wanna force a certain style of coding on me.
skade_ has quit [Client Quit]
<mbj>
And I dont agree with a reason.
<postmodern>
mbj, talking about specific libraries that are not the full mapper
<mbj>
And you try over and over again. Wount work.
<postmodern>
right because there's a cognitive bias
<mbj>
If you dont like my stuff: Feel free to not use it.
<postmodern>
you wrote the code using the style you believe it
skade has quit [Client Quit]
<postmodern>
thus criticism of that style is meet with defense
<mbj>
Nope, my style shifts from day to day.
skade has joined #rom-rb
<postmodern>
yet, the complexity of the code is difficult to maintain
<mbj>
I have a feedback loop because I use that stuff.
<mbj>
In production.
<mbj>
If you dont use it: You have a non closed feedback loop.
<postmodern>
with your current workload you do not have adequate time to work on these libraries, because development requires so much time investment
<mbj>
Get the feedback loop closed, report from production / whatever project you use.
<postmodern>
this to me indicates complexity
<mbj>
Than write your own version if mine is not suitable for you
<mbj>
If you dont like them: Dont use them.
<postmodern>
yet, even with my heavy workload, i am able to maintain my libraries because they are designed in a minimal fashion
<mbj>
This is OSS.
<mbj>
We are free to explore.
<postmodern>
yes, but you are writing general purpose libraries
<mbj>
For me that builder makes sense, that AST IR makes sense.
<postmodern>
not expirements
<postmodern>
what makes sense to you, might not to others
<mbj>
Feel free to tweet: Dont use mbj/* it sucks so hard and never use it in production.
<postmodern>
and you want others to help contribute to and maintain your libraries
<mbj>
So you did your job in warning people from my overcomplex nonfuctional stuff.
<mbj>
I do not care. I write the stuff to use it.
<mbj>
For myself OSS, is only a side-effect.
<postmodern>
i wasn't warning people, this is not an attack on you
<postmodern>
you are not your code
<mbj>
mbj/* is a selector for the code.
<postmodern>
OSS is about community
<mbj>
Not the person.
<postmodern>
see this is exactly what I was talking about
<postmodern>
criticism about code is treated as personal criticism
<mbj>
I dont see your point. You think my code is overcomplex. I dont think so, its actually quite simple. Its a matter of style.
<mbj>
I prefer to read ivars over passing arguments around.
<mbj>
You not.
<mbj>
No way, I dont feel insulted. I only think that you should accept the code the way it is.
<postmodern>
instead of listening to my criticism, thinking about it, extracting valid points which you might consider working on
<postmodern>
i get attacked
<mbj>
Where I attacked you?
<postmodern>
well more like any criticism i have is immediately challenged
<mbj>
postmodern: You tell me its possible to write the code in a less complex way.
<mbj>
I tell you: In my opinion, with my style the current complexity level is lower.
<mbj>
So your metric is "complexity", and we see differend values on the bar.
<mbj>
Instead of talking about "push arguments to ivars, is that a good pattern", we are iterating over non code topics.
<mbj>
I like to argument on code, that works, that is tested.
<mbj>
Anything else is noise, and yeah it goes to some kind of /dev/null here.
<mbj>
Because it'll not bring the discussion forward.
<mbj>
You showed me the builder class and told me: I can replace it with a 4 loc method.
<mbj>
Thats what you should do. Replace it with a 4 loc method. Than I'll see your point.
<postmodern>
let's try an experiment
<solnic>
wooohaaa
<solnic>
I was away for too long
<solnic>
;)
<solnic>
postmodern: man, I'm so with you on that community bit
<solnic>
maybe you haven't noticed but I was saying similar things recently
<postmodern>
solnic, i mean if all of ROM support libraries want to be only for ROM, they should sport the rom- prefix
<solnic>
support libs are general purpose stuff
<mbj>
postmodern: You know that ROM is NOT finished?
<solnic>
I use it on production
<solnic>
s/it/them/
<postmodern>
mbj, and probably never will be at this rate
<solnic>
I agree!
<mbj>
postmodern: I dont care. Because I solve my problems with the libs already.
<mbj>
I write domain specific mappers for a living.
<mbj>
So all the time I see a pattern I extract something that might be usable for others.
<mbj>
Eventually it is.
<postmodern>
mbj, that's good, except there's all these other users who want to use ROM
<solnic>
postmodern: fwiw I don't think amount of supports libs was a problem
<mbj>
postmodern: I do not optimize for a hypothetical concept "user of ROM". I optimize for myself. If its not usable for me, why it should be usable for others?
<solnic>
the way they were developed was/is a problem
<postmodern>
solnic, well there is overlap between some of the libs and morpher
<mbj>
postmodern: Which one?
<solnic>
postmodern: what overlap?
<postmodern>
solnic, coercible
<mbj>
postmodern: You do not follow this channel close enough.
<postmodern>
solnic, you can configure coercible to map arbitrary inputs to boolean values, that feels like a morpher feature
<mbj>
postmodern: We already talke about porting the important coercions to morpher.
<solnic>
the plan is to either replace coercible with morpher or integrate it with morpher
<mbj>
postmodern: But make them more strong.
<mbj>
So coercible acceppts "10e10" as Fixnum input.
<solnic>
coercible comes from DM1 :)
<mbj>
Morpher will not do this.
<solnic>
it's the same code in 90%
<solnic>
we no longer like it
<mbj>
postmodern: You see an in process state without transaction isolation. Sure there are some inconsistencies at this point.
<postmodern>
mbj, i've been following ROM since it's announcement
<solnic>
postmodern: re rate of development, things are speeding up a lot, I work on it every Friday and I'm making really nice progress, I'll start using ROM in production before end of the month as we already have use cases for it at work
<solnic>
it will take more time to add crucial missing features but for reading it will be already pretty useful
<solnic>
postmodern: I do agree that simplifying things to make it more contribution-friendly is important
<solnic>
that's why I raised my concerns about rake ci in the past
<solnic>
about the way mutation testing was practiced
<postmodern>
solnic, also not only allowing you to maximize dev ROI
<postmodern>
solnic, currently it seems you invest too much time into ROM and don't get adequate results
<mbj>
postmodern: I measure dev ROI only in terms of usability for my commercial/OSS projects.
<mbj>
postmodern: That feedback loop is faster and more relihable but subjective.
<solnic>
postmodern: no, that's no longer true but it used to be
<mbj>
postmodern: I can live with that as a trade off.
<postmodern>
mbj, yet you always seem to be overburdened with your work load
<mbj>
postmodern: I have limited OSS time, yeah.
<solnic>
mbj: I think that's exactly the point postmodern is trying to make
<solnic>
simplifying things in order to get more done in our limited time
<solnic>
because the ROI would be bigger
<mbj>
postmodern: I did some more adanced stuff in top of axiom + morpher than publically known. The knowlege will feed-back the code not (commercial).
<solnic>
that's why I suggested merging support libs into one, this would simplify stuff, that's why I suggested removing many sources of friction in the dev cycles too like rake ci and failing builds on metric violations etc etc
<mbj>
solnic: I cannot work on OSS currently without having an eye on relations to my commercial projects. And I'm okay with htat.
<mbj>
solnic: Its easier for me to manage n small libs than one big.
<solnic>
mbj: I do the same thing, things I build are driven by the needs of my project at work
<mbj>
solnic: People are not the same, so you might be better in managing one bigger lib. I'm not.
<mbj>
solnic: So for ROM, you could merge that libs in one if you want. I'll not use it, but if it speeds up your development: Do it.
<solnic>
mbj: I'm confident that merging support libs into one would result in less time spent because dep management is drastically reduced
<mbj>
solnic: I never had big dep management issues so far.
<mbj>
solnic: Again, I'd love you try it.
<mbj>
its the only way to know
<solnic>
I won't try it w/o you guys agreeing to it
<solnic>
because I'm not going to maintain those libs myself
<skade>
wasn't that the big problem of datamapper?
<solnic>
so far it's been OK
<solnic>
skade: no it's a bit different
<solnic>
here we're talking about many small support libs
<skade>
i mean, a lot of the tangential libs got poor support, because they were always out of the scope of the main project
<solnic>
libs that mostly help in getting rid of boilerplate code
<postmodern>
mbj, I have sent you a PR, specs pass on my end
<solnic>
in DM1 we inherited a ton of abandoned projects that we never had the time to maintain properly
<postmodern>
also dm-core was heavily coupled
<postmodern>
the slightest change in it would ripple across everything
<solnic>
yeah it wasn't a good separation of concerns anyway
<solnic>
as I said, it's a different story
<postmodern>
also splitting apart the dm-more libs didn't help because of the coupling
<solnic>
yep that's true
<skade>
okay
<solnic>
we hoped to find new maintainers fwiw
<solnic>
we didn't then we lost interest in DM1 altogether as we decided to build DM2 and then you know the story ;)
<postmodern>
i thought about rewriting DM1 using pieces of ROM
<postmodern>
piecemeal style
<skade>
still, but the approach "thats for me and mine is the validation" also won't help in finding maintainers for ROM
<solnic>
probably not a good idea
<solnic>
DM1 is an AR after all
<solnic>
skade: I agree and my approach differs from mbj's here
<solnic>
I know I just said I currently add features that I need
<solnic>
but that doesn't mean I ignore everybody else
<solnic>
I mean see issues I'm responding to, I do care about needs other people have
<solnic>
I'm not going to ignore things because I don't need something
<mbj>
postmodern: thx. I see a way to improve the amound of LOC saved. Currently we have multiple descendant.instance_exec blocks next to each other. What about to move it into one?
<solnic>
and really, trust me, I'm very concerned about a development environment that's contributor-friendly
<mbj>
postmodern: Should have the same semantics and save even more loc.
<mbj>
postmodern: And the #included(descendant) method would be as short as I like.
<postmodern>
mbj, combined
<mbj>
postmodern: I like that PR. Historically we did each aspect fo anima infection into one method. We saw the duplication of passing the descendant around. If we only use one instance_exec block we'll not have this issue. And that solution is better than the builder.
<mbj>
postmodern: Thats the kind of discussion I like.
<postmodern>
mbj, also consider moving more of the anima helper methods out into modules, like InstanceMethods
<postmodern>
mbj, however it took like 20 minutes to merge this code back together carefully, and it's 2:50am
<mbj>
postmodern: See, its quite easy if we talk about that code.
<postmodern>
mbj, it's way more easier for me to point this stuff out, than go around simplifying code
<postmodern>
mbj, and i have to wake up soon
<postmodern>
mbj, essentially i wasted sleep time to simplify your code
<mbj>
postmodern: I did not saw it the first time. (And you also, since I needed to point out to use one instance_exec block)
<mbj>
postmodern: Thats a collaborative efford.
<solnic>
postmodern: heh NOW I see what you mean with the builder stuff (after seeing that PR)
<mbj>
postmodern: Wasted?
<mbj>
postmodern: I take that PR, why your time is wasted?
<postmodern>
solnic, see, SRP doesn't make sense for meta-programming
<solnic>
postmodern: but man I really agree
<postmodern>
meta-programming should be declarative, since it's mutating something else
<solnic>
that builder was absolutely not needed in anima
<postmodern>
SRP makes more sense when your composing the return values of multiple methods/classes
<mbj>
postmodern: you also did not spotted to merge the instance_exec blocks
<mbj>
postmodern: At the time this was not known, the builder was the better option.
<postmodern>
mbj, right because i was just merging the code as is, instead of going deeper
<mbj>
postmodern: k
<postmodern>
mbj, i did a bottom up merge
<postmodern>
mbj, copy/pasted until it was all in #included
<mbj>
postmodern: Yeah, the history of that code was multiple methods with passing descendant around.
<solnic>
so this kind of builders is overengineering for sure
<mbj>
postmodern: So nobody spotted before to merge the instance_execs
<postmodern>
plus you weren't really using the instance state of Builder
<mbj>
I'm happy its spotted now.
<mbj>
We did.
<mbj>
The descendant
<postmodern>
just a way to pass in anima, names and descendant
<postmodern>
which you could using block arguments
<mbj>
the descendant and anima had been the instance state.
<mbj>
The whole point of the builder was to get a rid of passing the arguments around.
<mbj>
Since nobody spotted the #include method could be simplified that much when we only use one instance_exec block.
<mbj>
We stuck into a local maxima.
<postmodern>
again i am very against the idea of separating that logic into a separate Builder class
<postmodern>
it doesn't make sense since you do not care about getting back a Builder instance
<mbj>
postmodern: If we find a nice solution like this +1
<postmodern>
unlike a true DSL Builder
<postmodern>
which returns you a built DSL object
<solnic>
like in ROM :)
<solnic>
brb
<postmodern>
exactly
<postmodern>
mbj, also please stop applying SRP to methods :)
<postmodern>
mbj, SRP is really about isolating responsibility to classes
<postmodern>
i feel like single-line methods work best when you care about their return values
<solnic>
yeah I've seen a lot of too SRPish stuff
<solnic>
like splitting a simple method into 4 anemic methods
<postmodern>
all those methods can be merged into one block with single-line comments for each
<solnic>
WAY harder to follow such code
<postmodern>
exactly
<postmodern>
think about optimizing code for people debugging it
<postmodern>
solnic, wonder if you could hook it up to github services
<postmodern>
would be nice to distinguish between a Travis CI fail and a Rubocop fail
<solnic>
I suggested that 1.5 year ago
<solnic>
I was dismissed :P
<solnic>
I repeated countless of times - code smells != broken code
<mbj>
solnic: It wasnt dismissed!
<mbj>
solnic: use rake spec if you want to silence code smells.
<solnic>
rake ci is still being run on travis
<solnic>
the builds are failing because of metrics
<solnic>
so, nothing changed
<mbj>
solnic: ?
<mbj>
solnic: You can change what is run on travis quite eaily.
<solnic>
??
<mbj>
*easily
<solnic>
I can and I did
<solnic>
you didn't
<solnic>
:D
<mbj>
solnic: yeah, because I like exactly that feedback.
<postmodern>
you should schedule code reviews separately
<mbj>
solnic: I'm not done once the specs pass.
<postmodern>
like run robucop every week or month and email back the results
<solnic>
postmodern: I suggested something like that
<postmodern>
as a way to identify technical debt
<postmodern>
instead of doing it on every commit
<solnic>
revisit feedback but don't let it desiturb our every day dev cycles
<solnic>
mbj: you are done, metrics is cosmetics in most of the cases, often times things can and even should be ignored
<mbj>
solnic: me != you ;)
<mbj>
solnic: We dont have to agree on that stuff.
<solnic>
yeah, let's not go through this again ;)
<solnic>
even though we already did that lol
<solnic>
but then again, postmodern raised exactly same concerns that I had
<mbj>
solnic: A good disagreement is sometimes better than a weak compromise!
<solnic>
so I couldn't resist
<postmodern>
i say disable code metrics
<postmodern>
add CONTRIBUTING.md files that list basic syntax
<solnic>
I did that in ROM months ago
<solnic>
shit, I forgot about CONTRIBUTING.md
<mbj>
postmodern: Please dont PR that metrics disable stuff to my repos :P
<postmodern>
maybe do basic syntax scans for obvious non-Ruby syntax (like tabs)
<mbj>
I'll not take it.
<postmodern>
but save the complex code metrics for weekly/monthly scans
<mbj>
I'm off for lunch.
<postmodern>
as a way to identify problem areas
<solnic>
yeah that would be an improvement
<postmodern>
since problem areas take time to develop, you wont catch them on every commit
<solnic>
I'm sure mbj will get there at some point ;) again, don't wanna sound arrogant, just saying as somebody who went through this process already (blah, feeling really arrogant now :D)
<postmodern>
it's a valid view point
<postmodern>
the more i work on larger projects, the more i realize it's a process
<solnic>
I guess making a code audit before every major release would be sufficent
<postmodern>
yeah, you want to separate per-commit checks from pre-release checks
<postmodern>
micro vs. macro
<solnic>
yep
<solnic>
watching the trend is a good thing, if things are improving then we're good
<solnic>
or at least not getting worse
<postmodern>
now there's a thought, does a service exist that charts your code metrics?
<postmodern>
instead of failing builds
<solnic>
I'm not aware
<postmodern>
that way you can chart your velocity
<solnic>
there's metric-fu gem
<solnic>
it's maintained again
<postmodern>
codeclimate might have something
<postmodern>
but they just give you a grade letter
<solnic>
really, CC is all I need these days
<solnic>
but we could look into something more powerful...one day...maybe ;)
<solnic>
well, no, you can see some charts there too
<solnic>
+ they added test coverage just yesterday
<solnic>
blah, I really need to go to work :)
<solnic>
postmodern: thanks for the chat, I really appreciate it
<postmodern>
solnic, your welcome, hopefully this resulted in something actionable
<postmodern>
also i would like to contribute to ROM, but even the small libraries have a considerable barrier to entry
<solnic>
postmodern: not the ones under /rom-rb or /solnic
<postmodern>
solnic, come on Virtus Builder :)
<postmodern>
solnic, reminds me of early RSpec code
<solnic>
well I would accept a PR that improves that
<postmodern>
solnic, you know I have this day job and projects of my own :)
<solnic>
you'd be surprised how many usecases have to be handled there
<solnic>
+ virtus 2.0 will be a rewrite anyway
<postmodern>
solnic, i don't think it's fair to put the burden of simplicity on me, since i didn't write that code and thus have to first understand it
<solnic>
virtus is low on my priority list anyway
<solnic>
the code handling things is simpler now and we have more power so it was a win for me :)
<postmodern>
yeah, ROM still needs write support
<postmodern>
to make it fully functioning
<solnic>
I'm focusing on adding missing parts on the mapping/reading level for now
<solnic>
but very very soon I will move on to writing
<solnic>
which involves SQL gem with a hanging PR :(
<postmodern>
yeah once we can do full reads and writes, to at least on major SQL DB, ROM will be a viable ORM
<postmodern>
even if we don't have UoW, it's still on the same level as AR or DM
<solnic>
I will probably fork axiom/sql under rom-rb and continue there until dkubb gets back
<solnic>
he can cherry pick from my commits if he finds them to be good
<solnic>
postmodern: yep UoW is also very low on my priority list
<postmodern>
a nice to have, maybe as a plugin
<solnic>
we could use it without UoW, that's gonna be a bit more verbose from the client's code pov
<solnic>
postmodern: what time is it on your side? :D
<postmodern>
solnic, 4am currently
<solnic>
gah ;)
<postmodern>
i should eat some food and go to bed ASAP
<ptico>
Hi guys. Just finished read your epic conversation and want you to know that having a lot of small SR libraries is good. For example i use many of them on the different commercial projects.
<ptico>
I mean some of them in one project, some of them in another. Merging them in one big will lead to new ActiveSupport
<snusnu>
yeah ptico, i agree
<mbj>
ptico: I fully agree. I fear that people try to judge our approach without having tried it.
<snusnu>
(i wasn't part of the convo, but i just read it myself)
<mbj>
ptico: Its eays to say $foo is wrong, without trying $foo once.
<mbj>
ptico: I'm very proud of the fact we are NOT discussing the public API. We are discussing implementation details.
<ptico>
This is about programmers psychology – why i will use library X if similar, but purer functionality already contains library Z
<mbj>
ptico: This is a sign our public API must not be soo bad.
<mbj>
ptico: And I care about specifing the public API in a way all private stuff is fully mutation covered. Thats actually the only quality bar I'm really interested in.
<mbj>
ptico: It includes all the other stuff: Less code is easier to mutation cover. Deduplicated code is easier to mutation cover. ...
<mbj>
ptico: Also I think that people dont get we are NOT done. Its quite natural to do more iterations. We could simplify animas internals without changing the public API. That is the effect of our approach. Not the smell!
<mbj>
ptico: I'd love people would evaluate morpher and its code, there is much more opportunity to cleanup / improve than on small libs like anima.
<mbj>
ptico: Morpher is sadly medium sized. I'll try to reduce it.
<ptico>
The only one lib can be merged (my very own opinion) is memoizable/adamantium
<ptico>
Like Memoizable::Frozen or something like this
<mbj>
ptico: I'm okay with having it separated.
<mbj>
ptico: Its easy to merge stuff, but uneasy to separate.
<ptico>
But this is because i don't met a project which needs only one of them yet
<ptico>
Anyway thank you guys
<mbj>
ptico: There is a project.
<mbj>
ptico: the twitter gem.
CraigBuchek|921 is now known as CraigBuchek|afk
<mbj>
ptico: It only uses memoizable but not adamantium.
<ptico>
mbj: btw, did you ever had a problem with memoizable and mutant? I mean when mutant stops seeing the specs for memoized method?
<mbj>
ptico: I had before I fixed them.
<mbj>
ptico: Are you using the latest mutant?
<ptico>
Oh cool
<ptico>
Not sure
<mbj>
ptico: The point where admanatium depenended on memoizable mutant was not aware there was a memoizer it needs to readd.
<mbj>
But #== is a coercing operator. And you should specify for it.
<mbj>
In 99% of the cases where I used #== i wanted #eql?
<ptico>
Ok, will try and give feedback in #mutant
<mbj>
ptico: k, much apprechiated.
vsorlov has joined #rom-rb
CraigBuchek|afk is now known as CraigBuchek
<ptico>
mbj: btw, i have a question regarding morpher
CraigBuchek is now known as CraigBuchek|mtg
<mbj>
ptico: shoot
<ptico>
I have some classes in my system which transforms received API data (Hash) to internal objects. They are basically PORO classes and i want to replace them with something more declarative
<mbj>
ptico: morpher at your service ;)
<mbj>
ptico: If you can pair on this I offer free support.
<mbj>
ptico: Do you need bijective transformations?
<mbj>
ptico: That specific example (moving a key down) is not modelled in morpher actually.
<mbj>
ptico: I can add such a node, but maybe I should see the big picture.
<mbj>
ptico: I *always* found in such situartions that I'm doing something wrong.
<mbj>
So I explicitly do not added a node for such stuff in morpher.
<ptico>
This is most complex example
<ptico>
Usually its more simple transformations
snusnu has quit [Quit: Leaving.]
<mbj>
I think you should write a domain specific node that does that transformation, that only adds minimal behaviour around what morpher can do for you.
<ptico>
I see
<ptico>
Here is another thing: transform { cargo: 'ttx1234,ml1212' } to { cargo: 'ttx1234', meta: 'ml1212' } the divider between cargo number and meta info can be also ; and :
mbj has quit [Ping timeout: 258 seconds]
snusnu has joined #rom-rb
mbj has joined #rom-rb
<ptico>
mbj: RE: Here is another thing: transform { cargo: 'ttx1234,ml1212' } to { cargo: 'ttx1234', meta: 'ml1212' } the divider between cargo number and meta info can be also ; and :
<ptico>
How to reach this
<ptico>
?
<mbj>
ptico: Custom node.
<mbj>
ptico: That stuff is uncommon IMO. Morpher allows you to reach 90% of the job. But you'll have to get your hands dirty on inline signalling like this.
<ptico>
What about example in repository with custom node?
<mbj>
ptico: It should remove the burden to get that 90% right.
<mbj>
ptico: Just look at the existing nodes and how they work.
<ptico>
Because i understand the concept but steel feels like a fool :)
<mbj>
ptico: Again, I'm interested to pair with you on that one.
<mbj>
ptico: I'd show you what we have, and how I think that custom one should handle it.
<ptico>
Great! I need to finish some work before, lets return to this a little bit later
<ptico>
Thanks
<mbj>
ptico: Not today. I'm busy.
<mbj>
ptico: What about Saturday / Sunday?
<ptico>
I mean like next week or maybe weekend
<mbj>
k
therabidbanana has joined #rom-rb
<mbj>
ptico: Actually I think all cases you showed me will look nice in a custom node.
<mbj>
ptico: Once we see a pattern, we can merge them back to master. This is how I created the set of nodes that are in master currently.
<ptico>
Will be happy if this helps to make morpher better
<mbj>
ptico: sure
<mbj>
I need to focus, cu
mbj has quit [Quit: leaving]
skade has quit [Ping timeout: 245 seconds]
skade has joined #rom-rb
snusnu has quit [Quit: Leaving.]
robmiller has quit [Quit: Leaving.]
jordanyee has quit [Quit: MacBook went to sleep.]
CraigBuchek|mtg is now known as CraigBuchek|food
lgierth has joined #rom-rb
sferik has joined #rom-rb
skade has quit [Ping timeout: 240 seconds]
snusnu has joined #rom-rb
CraigBuchek|food has quit [Quit: Leaving.]
jordanyee has joined #rom-rb
mbj has joined #rom-rb
mbj has quit [Client Quit]
sferik has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
snusnu has quit [Quit: Leaving.]
cored has quit [Ping timeout: 265 seconds]
cflipse_ has joined #rom-rb
cflipse_ has quit [Client Quit]
sferik has joined #rom-rb
vsorlov has quit [Ping timeout: 276 seconds]
jordanyee has quit [Quit: MacBook went to sleep.]
snusnu has joined #rom-rb
postmodern has joined #rom-rb
snusnu has quit [Quit: Leaving.]
snusnu has joined #rom-rb
solnic has joined #rom-rb
snusnu has quit [Quit: Leaving.]
lgierth has quit [Remote host closed the connection]
jordanyee has joined #rom-rb
<postmodern>
solnic, at work, but you should put together a technical slide-deck and present it over skype to us
<solnic>
postmodern: ok I'll prepare something
<solnic>
postmodern: I usually have time on Fridays
lgierth has joined #rom-rb
jordanyee has quit [Quit: MacBook went to sleep.]
jordanyee has joined #rom-rb
jordanyee has quit [Client Quit]
skade has joined #rom-rb
jordanyee has joined #rom-rb
jordanyee has quit [Ping timeout: 276 seconds]
<elskwid>
postmodern: It’s been great to see your point of view regarding community, OSS, and the rest over the last two days. I hope you aren’t too exhausted.
<postmodern>
elskwid, na work is occupying all my time
<postmodern>
elskwid, a little annoyed that i couldn't communicate my point, and was easier to just send a PR in the end
<postmodern>
elskwid, could have saved a lot of tweets in the beginning
<elskwid>
postmodern: I think you did an admirable job with both.
<elskwid>
postmodern: perhaps. I am interested in learning more about the differing viewpoints.
<elskwid>
postmodern: I won’t drag it out. Just wanted to chime in and say that there’s positive outcomes from the discussion.
<elskwid>
which is neat
solnic has quit [Quit: Leaving...]
skade has quit [Ping timeout: 258 seconds]
snusnu has joined #rom-rb
lgierth has quit [Ping timeout: 250 seconds]
lgierth has joined #rom-rb
skade has joined #rom-rb
sferik has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]