<travis-ci>
[travis-ci] rom-rb/rom-mapper#112 (master - 2f0f167 : Piotr Solnica): The build was broken.
<snusnu>
solnic: sweet!
<solnic>
snusnu: I also updated travis configs to use recent names of ruby VMs and allowed failures on 2.1.0 as there's a bug causing a segfault (in the MRI, fixed in head)
<solnic>
oh and all rom-* projects run metrics:coverage on CI from now on
<snusnu>
solnic: does that do simplecov?
<solnic>
feel free to fix stuff like rubocop offences or reek or whatever else on your own by running it locally of course
<solnic>
I will be doing that from time to time when I feel like it makes sense
<solnic>
snusnu: yes it runs simplecov
<snusnu>
solnic: ok, tbh, i don't care much about simplecov, but anyway, fine with me
<solnic>
snusnu: I don't care about it too, I mean, all I care about is passing tests, really
<snusnu>
same here
<solnic>
I'm ok with turning it off and just running rake spec
skade has quit [Quit: Computer has gone to sleep.]
<snusnu>
i'll be using mutant locally when i have the feeling that i need it, so yeah
saller has quit [Remote host closed the connection]
lfox has joined #rom-rb
poltoranin has joined #rom-rb
vsamson has joined #rom-rb
poltoranin has quit [Ping timeout: 261 seconds]
<snusnu>
mbj: time for a quick ducktrap question?
vsamson has quit [Ping timeout: 264 seconds]
<snusnu>
mbj: if i want to load an ID from a params hash, and it's given as string, can i do a hash_transform that checks that it's a string, but dumps it as an Integer? or do i need to do a custom trap
lfox has quit []
lfox has joined #rom-rb
cored has quit [Read error: Connection reset by peer]
snusnu has quit [Ping timeout: 246 seconds]
mkristian has quit [Ping timeout: 252 seconds]
mkristian has joined #rom-rb
snusnu has joined #rom-rb
snusnu has quit [Client Quit]
snusnu has joined #rom-rb
mkristian has quit [Quit: bye]
snusnu has quit [Quit: Leaving.]
snusnu has joined #rom-rb
jfredett-w1 is now known as jfredett
<mbj>
snusnu: yo a dustom trap
<mbj>
snusnu: I'd love to support strong coercions in ducktrap/mapper.
<avdi>
that's one of my mappers using the hand-rolled DM stuff I've been using
<avdi>
the fun thing about it is that one #process_associations callback handles both load and store
<avdi>
it gets called during both store and load, but during load it gets called with an AssociationLoadOperation
<avdi>
and during store it gets called with an AssociationStoreOperation
<mbj>
avdi: Is this backed by some kind of a Unit of Work to be flushed out later?
<avdi>
mbj: not currently, but it doesn't really have to be right now
<avdi>
I kind of like this because it's reasonably declarative BUT it's just a method to be overridden. You can easily see where in the load/store sequence it gets called
<avdi>
as opposed to class-level declarations where it's not clear what they actually do
<mbj>
avdi: Got it.
<mbj>
avdi: My plans for instantiating a ROM schema, or mapping is all about instantiation. Not producing anything on a singleton/class level.
<avdi>
not saying this is better, but it struck me as an interesting approach to play with
<mbj>
avdi: Not arguing here, just exchanging opinon ;)
<mbj>
s/opinion/ideas/
<avdi>
yeah, that's why I brought it in here. I hadn't seen this approach used before.
<mbj>
avdi: it could be argued such information does not belong encoded into an inhertiance tree.
<mbj>
such information as the "schema" of a db mapping.
<avdi>
mbj how do you mean?
<avdi>
remember, this is a mapper class, not a model class
<mbj>
avdi: compiling answer, moment.
<avdi>
I'm following the pattern laid out in PoEAA where there's a mapper class per model class (more or less)
<mbj>
avdi: forget my claim. #process_associations is a callback.
<mbj>
I misread it.
<mbj>
Its not something that gets overridden.
<avdi>
I started out with each mapper class having its own #load/#store, and have been gradually pushing more and more up into the DataMapper module and just keeping callbacks in the individual mapper classes.
<mbj>
avdi: thats an interesting pattern. Can you post more code?
<avdi>
ooh, I just realized I have a little more work to do for that association
<avdi>
I'm still doing a little association-related processing in the #persistable_attributes callback
<mbj>
avdi: When does an instance of the TokenMapper get created?
<avdi>
right now I just do it manually. token_map = TokenMapper.new(...)
<avdi>
I've just moments ago introduced the concept of a mapper registry (which is just a Hash) so that mappers can find other mappers based on model class in a late-bound way.
<mbj>
avdi: so one mapper per db connection?
<mbj>
If "db" represents a db connection in your code.
<avdi>
mbj: nope, db is a required argument of the mapper constructor
<avdi>
so I have to inject a db to get a mapper
<avdi>
although in that code you can see that it does default to an app-wide db connection
<jgaskins>
avdi: i dig it. what's the `op` argument, though?
<mbj>
avdi: so the instance of your mapper is your interface to the mapped type. Really thin mapping layer I like it.
<avdi>
jgaskins: it's either an AssociationLoadOperation or an AssociationStoreOperation
<avdi>
depending on context
<avdi>
mbj: yeah in my head I think of it as TeenyMapper
<jgaskins>
avid: ooh, okay. i was thinking "operator", but i see above where you mentioned the operation class, too.
<jgaskins>
avdi*
<avdi>
I'll paste some more in a sec
<jgaskins>
autocorrect tries to "fix" your name every time i type it.
<mbj>
avdi: You could try to inject an IM wrapping the store/load operators.
<mbj>
avdi: With same interface, so your mapper does not *know* its talking to the identity map.
<mbj>
avdi: that IM aware operator could use a hash based on object identity that could be instanciated per session.
<mbj>
session is the "db interaction session" not a user session.
<mbj>
I dont know the rest of the code ;)
<avdi>
yeah I know what you mean by session
<avdi>
I'm already using an IM
<mbj>
How does it look like?
<mbj>
You dont have to reveal all your code now. I'm just always curios.
<avdi>
it's a thin layer over Ara's Map, but in retrospect I think I want to just make it a Hash
<mbj>
How you define object identiy? My mappers typically have an Mapper#identity(object)
<avdi>
mbj: I haven't abstracted that *yet*, although I plan on it. Right now it's defined pretty concretely as class + the attribute named "id".
<mbj>
avdi: So "new" objects without a db generated id wont be tracked somewhere? (Not needed if you dont have an UoW anyways).
<avdi>
As soon as I have a table where the primary key makes sense to be something other than a a serial "id" field I'll abstract the concept of keys and identity
<avdi>
mbj: not at the moment, no
<mbj>
avdi: do you have dirty detection and differencial update operations?
<avdi>
mbj: I'm strongly considering making any UoW I do for this be explicit registration only. Not sure yet.
<avdi>
mbj: nope
<mbj>
avdi: In my mappers I capture the db side representation of an object (with RDBMS a tuple, NOSQL the document) and compare it to a "newly dumped via mapper" representation of the object.
<avdi>
mbj: right
<mbj>
Both for dirty detection and to be able to generate adapter specific differencial updates.
<mbj>
Also this way you dont need to associate the persistance state with the object. That would be an AR.
<mbj>
I did an external state tracker for this.
<mbj>
That also does IM.
<avdi>
yeah I'm weighing if I want to get into that area. Probably not for what I'm doing now.
<jgaskins>
mbj: that's kinda cool. i did a lot of brainstorming for how i wanted to store the DB id and i ended up injecting it into the model.
<mbj>
avdi: it was fully mutation covered at the time I lastly touched it. But mutant improved al lot :D
<mbj>
avdi: I dunno if its actually usable for you. But it powers some domain specific mappers for my apps.
<avdi>
I'm also thinking about simplifying things by just assuming that I'll always use this with an aggregate root object. So one top-level load and one top-level store per session, with the store persisting the whole association tree.
<avdi>
this is all an exercise in KISS data-mapping, which I know is kind of an oxymoron, but I'm trying anyway
<mbj>
We called this the "environment" in ROM.
<mbj>
That thing that references all instanciated mappers, axiom relations etc.
<mbj>
No "readers on singletons at all".
<avdi>
mbj: I'm not talking about something that references all the mapper stuff
<avdi>
mbj: just a top-level domain object
<mbj>
avdi: Rereading your statements with that in mind. (I'm not a native speaker).
<mbj>
avdi: I missed that "store persisting the whole association tree" part.
<avdi>
so rather than trying to track what has changed, just making sure that for any given use case there's a top-level object which encompasses all the data needed in that use case
<avdi>
anyway, I just wanted to see what y'all thought of that. It entertained me that I could write one callback method to handle both load and store of associations :-D
<mbj>
avdi: these are transitive operations. It does not really surprise me.
<avdi>
sometimes I think we write too many class-level "macros" in Ruby, just because we can
<mbj>
If both operations are the inverse of each others its a sign of good design there is lots of code sharing.
<mbj>
Like with block ciphers, you just initialize the algo in a differend way to switch from encrypt to decrypt.
<avdi>
they aren't *quite* opposites, but close
<avdi>
right
<avdi>
I guess technically this is an application of the builder pattern
<avdi>
and each operation class is a different builder
<mbj>
Yeah
<avdi>
send two different builders through the same blueprint, and you get two different results
<mbj>
avdi: BTW In ROM I'm plannign a specialized layer that deals with DomainObject vs db representation problem.
<avdi>
yeah?
<mbj>
avdi: So what if an attribute is an integer in Domain but a string in the db ?
<mbj>
avdi: Or in the DB you need some additional information such a float value (for db side sorting) where the requirements dictacte you need to store a rational.
<mbj>
I found many of these impedance mismatches in the "tricky" parts of my mapping domain.
<mbj>
There are dozens of other examples (I can shamefully not remember).
<mbj>
The gist is: IMHO we need an composable algebra that allows to specify an transformation from Object to DB side representation and vice versa.
<mbj>
Because this stuff gets complex and keeping transformers the inverse form each other: I did some inversable data transformation algebra.
<mbj>
Sounds more than it actually is.
<mbj>
But it allows to define the "domain to db representation" stuff and generate an inverse (with some constraints).
<mbj>
It works really well with mapping domain objects into (denormalized) document trees for document databases.
<mbj>
Where a normal object relational mapper is not flexible enough.
<mbj>
There is a branch of rom-mapper using the v1.0 of that algebra.
<mbj>
Dunno if that is the right direction, just an idea that worked really well for some projects, and sucks on others ;)
<mbj>
avdi: At least it passes the specs, and reduces 200loc :D
<mbj>
avdi: But that is version 1.0 of the idea.
<mbj>
avdi: I'm wrinting 2.0 (with rename from ducktrap to morpher).
<mbj>
avdi: That supports building such inversible evaluation trees from an AST representation.
<mbj>
avdi: You can also use the OO interface, but for "handwriting" some transformations s-exp syntax like s(:foo, s(:bar)) etc is nicer.
<mbj>
also AST based optimization is easier than with an evaluation tree represented in an OO interface.
<avdi>
true
<mbj>
I totally dont know if all this stuff is "to much" for a system like ROM. But I'm using parts of ROM in production (especially the ducktrap) where it reduced LOC and improved correctness.
<mbj>
Ducktrap/morpher can be used as an XSD for YAML/JSON (or any other tree of primitives/objects).
<mbj>
I'm using both to transform API requests into DTOs in a relihable way.
<mbj>
Because I saw so many people trying to validate the strucutre of an parsed JSON like this
<mbj>
if !params["foo"].empty?
<mbj>
do_some_important_logic(params["foo"])
<mbj>
end
solnic has joined #rom-rb
<mbj>
Problem: both {"foo":"1"} and {"foo":[1]} pass this test.
<mbj>
Resulting in undefined behavior and possibly exploits. :(
<mbj>
solnic: hila
<mbj>
*hola
snusnu has quit [Quit: Leaving.]
xybre has joined #rom-rb
mbj has quit [Ping timeout: 272 seconds]
denchitto has joined #rom-rb
mbj has joined #rom-rb
skrynov has joined #rom-rb
skade has joined #rom-rb
mbj has quit [Ping timeout: 252 seconds]
skrynov has quit [Ping timeout: 246 seconds]
<xybre>
So I was looking through the logs so I didn't ask a boring question about Perpetuity and I ran across snusnu mentioning not using virtus but using anima and ducktrap instead. I'm trying to figure out how/why. I see the example on the ducktrap page, but it seems a lot messier in practice.
mbj has joined #rom-rb
<jgaskins>
xybre: it's okay to ask boring questions about perpetuity, I promise.
<xybre>
Ohai, I was just going to ask what the guys thought of it, I didn't know you were still here :D
<jgaskins>
:-)
<xybre>
I was reading the honeybadger post about perpetuity and it reminded me I hadn't dropped in here in a while. It seems a quicker-to-the-finish line type project, while ROM is a bit more idealistic.
<jgaskins>
We kinda started off on different ends. I went from the API in whereas they started building a foundation first. I wouldn't call it idealistic. I'd say they're taking better approaches to a few things, actually.
<jgaskins>
The main reason perpetuity went a bit faster to release was because it started out as a proof of concept. I didn't plan on making it a real gem until last year.
<xybre>
I tend to approach things API-first, and after sketching that out, then tackle the underpinnings. This might be a good opportunity to get the best of both worlds however.
<jgaskins>
it's the reason i hang out in here. we discuss a lot of the different ways we handle things, which helps both projects.
<xybre>
I approve. I'd like to see an axiom-like system in perpetuity, and while some have had success using ROM for non-database work, the consumer documentation hasn't been consolidated yet so its all over the place.
<solnic>
mbj: hey
<solnic>
sorry I was away
<mbj>
solnic: np
<solnic>
mbj: I just read the logs
<solnic>
mbj: that thing you mentioned about mapping is so true. we kinda used to have an assumption that an object returned from the lower level adapter is already in a correct state in terms of types
<mbj>
solnic: Yeah
<solnic>
which it seems like is not really a good assumption
<mbj>
solnic: Its okay for 90% of the time.
<solnic>
yeah
<solnic>
that was one of the biggest issues in DM1
<solnic>
when it comes to custom adapters
<solnic>
and generating queries
<mbj>
solnic: But I think we win a lot with havin the possiblity to inject arbitrary complexity there.
<mbj>
solnic: BTW I remember a discussion between you and me about this stuff.
<solnic>
yeah I think it is actually REQUIRED
<mbj>
solnic: In #datamapper
<solnic>
I don't :) but my memory likes to play tricks on me ;)
<mbj>
solnic: Where I presented exactly the same thing. And you told me "this is to much to include in core".
<mbj>
solnic: Nice you changed your opinion here ;)
<mbj>
solnic: Maybe my memory tricks me also.
<solnic>
hmm that would be weird if I said this
<solnic>
because I came to this conclusion while working on the mongo adapter for dm1
<solnic>
which was years ago already
<solnic>
but it doesn't matter
<solnic>
maybe I did say this
<mbj>
solnic: Maybe I presented it in a wrong way.
<solnic>
completely unrelevant now :)
<solnic>
mbj: one comment re rom-mapper ducktrap branch - it removed LOC that must be reintroduced in some incarnation because rom-session relies on rom-mapper interface
<solnic>
I know that snusnu planned to do so
<solnic>
it's very likely those interfaces will be moved somewhere else though
<solnic>
but for now I want to have them there just to, well, keep things working
nsmoliak has joined #rom-rb
<mbj>
solnic: I think we can reduce more loc with morpher.
<mbj>
solnic: Its *far* more easy to integrate than drucktrap.
<mbj>
solnic: I have a local integraiton for mutant with morpher.
<mbj>
solnic: For subject filtering. And "any filter you gonna request".
<mbj>
solnic: Also I'll implement the kill expressions (configurable scope widening) via these stuff.
<solnic>
xybre: we're gonna speed up development this year ;)
<xybre>
solnic: :D I'd help, but every time I sit down to do so I feel like I jumped into the deep end of the whirlpool and there's wicked undertow. Like, there's jsut a lot of context I don't have.
<xybre>
2
<xybre>
(ignore the 2, bumped my keyboard)
<mbj>
xybre: The problem: Its not an easy domain. And we dont even have a 100% shared vision now.
<mbj>
xybre: There is still *LOTS* of experimenting.
<mbj>
xybre: But we have some nice side effects of our process, small gems that turn out to be usefull for all ruby projects.
<mbj>
xybre: Or tooling, mutant as an example.
<mbj>
xybre: I wrote it to replace crappy dev experience with heckle.
<jgaskins>
data mappers are hard. let's go shopping.
<mbj>
:D
<xybre>
mbj: A lot of those old tools need replacing, so I consider it a great service, even if I still have to use AR/Mongoid in the meantime ;)
<xybre>
I have used Virtus for things, and I've been trying to work in equalizer and a couple others too.
<jgaskins>
xybre: the thing that keeps me motivated to continue working on perpetuity is being required to use AR at my day job.
<jgaskins>
mbj: the fact that data mapping is hard is actually the reason some things in perpetuity seem a bit too simple sometimes.
<solnic>
jgaskins, xybre: re API-first (or going top-to-bottom if you will) is IMHO a better approach than trying to imagine lower level details (whether it's a lower level library in a bigger stack or a private lower level thing inside a lib)
<xybre>
jgaskins: last year I had to dig around in the guts of AR to build an Octopus replacement customized for our needs. That wss months of work mostly spent trying to not break AR's fragile global state and inflexible architecture.
<solnic>
and yes, getting full-stack DM implementation is hard work :)
<solnic>
esp if you want to support ANY data store like we do ha-ha-ha
<xybre>
(I had a working prototype in a couple weeks, but there were so many rough edges, and it was so difficult to test..)
<jgaskins>
solnic: not being able to assume certain things about your data store makes things so much worse. you can't even expect the queries to be the same type. :-\
<solnic>
that's why dkubb built axiom (amongst other reasons)
<jgaskins>
solnic: for example, the mongo driver expects hashes and SQL queries are strings. that part drove me up a wall.
<solnic>
I hear you
<solnic>
rom talks to axiom and it's all the same there and then an adapter will translate axiom relation into *whatever* a given driver requires, then things get back from the db and axiom builds tuples that will look the same no matter what returned them
<solnic>
jgaskins: ^
<solnic>
there's a caveat though, which was already mentioned by mbj today - the mapping layer needs to be able to perform additional transformations/coercions sometimes :)
nsmoliak has quit [K-Lined]
<solnic>
that's where morpher can help us (initially we thought it would be virtus but we actually need something more low-level)
<solnic>
fwiw I plan to make virtus 2.0 use morpher internally
<jgaskins>
for coercions?
<solnic>
for everything
<jgaskins>
ah, okay. i haven't looked into what all it can do yet.
<solnic>
primitive coercions will be handled by coercible (which morpher will use anyway)
mbj has quit [Ping timeout: 248 seconds]
<solnic>
virtus already uses coercible but we're not happy with its interface (it was a copy-paste from virtus codebase, mostly)
<solnic>
that's the fun part, when you extract something that seems to be very cool it may turn out that it can actually be done even better
<solnic>
mostly because suddenly other libs could use it but...the interface is not as good as it could be
<solnic>
which is the case with coercible
<jgaskins>
solnic: it sounds less terrible if you say "unfinished extraction" instead of "copy-paste" ;-)
<solnic>
it is an unfinished extraction from virtus
<solnic>
HAPPY NOW?
<solnic>
;)
mbj has joined #rom-rb
<jgaskins>
solnic: it's a reflex caused by explaining to clients when i have to do something terrible because of their unrealistic constraints. :-)
<jgaskins>
solnic: i really like that you guys are creating a whole ecosystem out of ROM. it'll really help adoption, i think.
<solnic>
jgaskins: btw have heard about micro-rb initiative?
<xybre>
Whats micro-rb? Other than ungoogleable.
<jgaskins>
lol!
<solnic>
xybre: it's a new thing and I haven't promoted it yet
<solnic>
hence - not googlable
<solnic>
also, lol
<solnic>
anyway, I'm gonna try to promote our approach to development - small, focused libs and composing higher-level frameworks using those libs
<solnic>
and I pretty much stole the micro-js idea (it's a website collecting small js libs/frameworks)
<solnic>
there are some cool people that got involved and we're gonna work on it this year
<xybre>
I'm pretty sure thats nearly identical to what OOP was supposed to be, but it never caught on.
<solnic>
there's microrb channel on freenode where we hangout and github.com/microrb
<mbj>
solnic: I never said it explicitly, but I like the idea a lot.
<mbj>
solnic: Consider me a supporter!
<solnic>
org is empty, almost - just a PoC of the website
<solnic>
mbj: thanks man :) everybody is welcome there of course, we first would like to define what we want to do exactly, ideas include actuall support from the microrb community to help people in development and maintenance of small libs, focus on docs is also important etc
<solnic>
we've been brainstorming so far :)
<mbj>
solnic: ping me if you need one of my skills.
<mbj>
solnic: I'm not a designer. Nor marketing guy.
<mbj>
solnic: I can help mutation cover the libs ;)
<solnic>
mbj: start with finishing morpher ;)
<mbj>
solnic: lulz
<mbj>
solnic: you actually like morpher. Nce.
<mbj>
*nice
<solnic>
I probably do
<solnic>
haven't used it but sounds like something cool
<solnic>
:D
<mbj>
hah
<mbj>
solnic: Its actually the first time I'm implementing something that I did not found it was invented somewhere before.
<mbj>
solnic: I expect someone did it already, or its just an instance of a well known public idea.
<solnic>
maybe
<mbj>
solnic: But I "found" this one for my own. And I like it.
<solnic>
it's funny that practically every ORM needs sth like that
snusnu has joined #rom-rb
<solnic>
yet you're the first one who realized that and implemented it
<elskwid>
solnic: There's nothing funny about ORMs.
<mbj>
solnic: Yeah. And ORMs that does not have this layer. Or a "small" version of it.
<elskwid>
nothing.
<solnic>
elskwid: right, it's all scary shit, and sad
<solnic>
elskwid: hey :)
<elskwid>
Put your Enterprise face on.
<solnic>
elskwid: just did
<mbj>
elskwid: morhper is usable outside ORMs.
<mbj>
Its far more general.
<mbj>
snusnu: hi
<elskwid>
solnic: HA
pavkentius has joined #rom-rb
<elskwid>
mbj: I know, I've been waiting for you to remove that "spike" comment from the README before I drop it in someplace.
<solnic>
elskwid: btw I love you for Pretty Lights
<solnic>
elskwid: cannot stop listening to this music
<elskwid>
solnic: I do what I can. There's some good stuff there!
<mbj>
elskwid: hah
<elskwid>
solnic: I took my sons to his show when he came through Reno. Pretty Lights was Pretty Amazing.
<elskwid>
(the crowd was a little, um, young, and not wearing enough clothing)
<solnic>
elskwid: I remember your tweets about it :)
<solnic>
damn, can't wait to take my sons on a gig :D
<elskwid>
solnic: I told my wife it was like a high school dance without a dress code.
<elskwid>
solnic: It's great. Beck was the first concert my sons went to.
<mbj>
elskwid: done ;)
<elskwid>
mbj: OH SNAP
<solnic>
haha
<elskwid>
mbj: Great, now I have to understand it. shit.
<solnic>
nice move mbj
<solnic>
I hope you added a commit message like "IN YOUR FACE ELSKWID"
<solnic>
;)
<elskwid>
solnic: LOL
<mbj>
solnic: Github refused to compleate @elskwid
<mbj>
solnic: And I could not remember correct spelling of the nick, and was lazy.
<elskwid>
Being trolled from half a world away is what the Internet is all about!
<elskwid>
xybre: you can stay.
<solnic>
word
<mbj>
elskwid: LOL at tweet ;)
<xybre>
I've spent much of the last year or two listening to Pretty Lights and associated acts, was a totally unexpected musical about-face really.
<elskwid>
xybre: He takes what I liked about early RJD2 and then blows that out of the water.
<elskwid>
xybre: esp in regards to his last album ... man oh man.
<xybre>
re the tweet, I forked the anima projct to rewrite the readme, there's some bugs in the example code D:
<mbj>
xybre: sorry
<solnic>
elskwid: I've been listening to their latest and oldest albums
<mbj>
xybre: I'm a bad readme writer.
<solnic>
that's what I like to do with new bands
<solnic>
that I didn't know before
<mbj>
xybre: Please PR. I'll merge.
<elskwid>
solnic: yes, same.
<solnic>
I like to see evolution, some times
<solnic>
unless it's Cannibal Corpse
<solnic>
omglolthatwassofunnyright
<jgaskins>
solnic: sorry, was on the phone with my mother. :-) i've seen you mention microrb on Twitter, but i didn't catch much other than that.
<xybre>
elskwid: Color Map of the Sun or one of the singles?
<jgaskins>
solnic: also, still catching up with that whole conversation
denchitto has quit [K-Lined]
<xybre>
mbj: Its cool, its like the one thing I feel comfortable doing haha
<elskwid>
xybre: Color Map. He basically recorded his own albums to get material for that release.
<mbj>
xybre: IT helps.
<xybre>
elskwid: Yeah I read about it, I've been tempted to do that for vocal samples, "what movie is that from?" "one I made in my backyard just for the album"
<elskwid>
xybre: I'm in a band and we're actually doing that now so our keyboard/programmer can take vocals from us and our friends and use them like found sound for a song.
<xybre>
elskwid: Cool. I'm a "producer", used to be in bands and DJ, but I started out making electronic music and I feel most at home doing that.
<elskwid>
xybre: Carson, our keyboardist is exactly the same. He just wanted to play with some instruments too. :)
snusnu has quit [Quit: Leaving.]
<mbj>
xybre: I'm gonna go to sleep soon.
<mbj>
xybre: If you wanna feel pressure: PR within the next 10min, and I'll merge it.
<mbj>
xybre: Else I'll merge it tomorrow ;)
<xybre>
mbj: Don't worry about the PR, it'll be a few hours before I push it :)
<jgaskins>
New reality game show: First contestant to finish their code and PR with tests passing gets their code merged.
<mbj>
jgaskins: Hah
<mbj>
jgaskins: And add devtools for more punishment ;)
<mbj>
jgaskins: With mutant ;)
<xybre>
elskwid: I liked having access to a drumkit out of all the instruments, there's something great and dynamic about real drums.
<jgaskins>
mbj: That's what the audience will want to see. Reality TV is all about taking normal, everyday things and slathering it with drama.
<elskwid>
xybre: By March I'll have my kit setup at home, let me know if you want some tracks. I plan on playing as much as I can and with whomever I can this year.
<elskwid>
xybre: Currently set is at our studio so not accessible 24/7.
<xybre>
jgaskins: that would be cruel. 100% test coverage, mutation passing, throw some complexity metrics on it too.
<jgaskins>
xybre: Must maintain 4.0 on Code Climate
<mbj>
jgaskins: 4.0 is too easy if you do devtools.
<mbj>
jgaskins: I rarely push something that loweres my score below 4.0.
<jgaskins>
elskwid: what kind of kit do you have?
<mbj>
jgaskins: But thats not because I'm brilliant, its more about having a local codeclimate with devtools.
<elskwid>
jgaskins: It's a DW custom. It's a lot of fun. Currently lusting over c&c drums (all kinds... *sigh*)
<jgaskins>
mbj: nice. i just use code climate. if it drops below a 4.0 for reasons that i can't justify, cleaning up later isn't such a bad thing.
<xybre>
elskwid: I'll keep that in mind, thanks :D
<jgaskins>
elskwid: i'm only just getting back into drumming after about a decade. i used to have a nice Ludwig Rockstar set that i had to sell for rent money in college.
<elskwid>
jgaskins: mmmm, Ludwigs are nice. Good classic sound.
<elskwid>
jgaskins: Basically, I want drums to sound like Jim Eno's kit (from Spoon).
<jgaskins>
elskwid: i decided i wanted to get back into it, but i live in an apartment so i had to go with an electronic set.
<mbj>
solnic: Wroclove "Confronting Ideas"
<elskwid>
jgaskins: What did you get? I too have been considering some alternatives.
<mbj>
solnic: So true ;) - We'll discuss our development mantra differencies ;)
<elskwid>
jgaskins: Also, yay for you coming back into the "fold".
<jgaskins>
elskwid: i'll have to check him out. i haven't heard of him before. but yeah, i do that a lot, too. "i want this guy's snare, this one's ride, this one's …"
<elskwid>
jgaskins: Yes. More than once I've gone snooping through YouTube videos, magazine photos, interviews, etc to find out what equipment is used. I wish drummers would just publish their dotfiles.
<jgaskins>
elskwid: hehe thanks. :-) it's a Roland TD-11. 5-pc, 3 cymbals. not bad, holds up really well. infinitely more time-consuming to set up than an acoustic kit.
<jgaskins>
elskwid: lol!
<jgaskins>
elskwid: yeah, about the only way i ever found out who uses what was to read Modern Drummer.
<xybre>
elskwid: dotfiles++
<elskwid>
jgaskins: yeah, I just can't do it. It feels too sponsor heavy, you know?
<xybre>
I always get excited about whats on stage at a show, I'm like "oo have one of those" or "uhg, why that one?"
<elskwid>
xybre: precisely
<elskwid>
Or, I always hated those but they sound amazing. Now what?!?
<elskwid>
*double sigh*
<jgaskins>
elskwid: it is. i tried to read one while waiting for the guy to get my drum set at Guitar Center and it was like every other magazine. just jammed with ads. a lot more than it used to be back in the day.
<xybre>
For some reason I'm always happy when there's a JP-8000 on stage. Odds are its going to be a good show for whatever reason.
<jgaskins>
anyway, fantastic chat, everyone. off to forage for dinner.
<elskwid>
jgaskins: we need a zine or let's start up a site where we do the musician's version of usesthis.com
<mbj>
gonna sleep & have fun!
<mbj>
cu
mbj has quit [Quit: leaving]
<solnic>
jgaskins: re microrb, it's still just an idea, we haven't done any concrete work yet
jgaskins has quit [Quit: This computer has gone to sleep]