02:09
<GitHub141>
[ohm] cyx pushed 1 new commit to txn-plus-callbacks: http://git.io/bgd90A
02:09
<GitHub141>
[ohm/txn-plus-callbacks] Implement the new composable Ohm::Transaction - Cyril David
02:17
<GitHub59>
[ohm] cyx pushed 1 new commit to txn-plus-callbacks: http://git.io/NtYZnQ
02:17
<GitHub59>
[ohm/txn-plus-callbacks] Rename test/callbacks to test/transactions. - Cyril David
05:41
<GitHub195>
[ohm] cyx pushed 1 new commit to txn-plus-callbacks: http://git.io/QexaYw
05:41
<GitHub195>
[ohm/txn-plus-callbacks] Remove the repetition in Ohm::Transaction - Cyril David
08:54
<codebeaker>
hi guys, just stumbled upon ohm, think that's going to help me a lot with passing lists of things such as mails/api calls into redis, and processing them with resque
08:54
<codebeaker>
(but having persistence of the results)
09:00
<soveran>
hey codebeaker
09:01
<soveran>
good to know, feel free to ask any question.
09:01
<codebeaker>
soveran, hi
09:01
<codebeaker>
I have just one query, mostly - redis has been in the stack for a while here, mostly for resque, and we also use it for some really simple list ops, such as recording the last 200 404s, and some other trivial stuff
09:03
<codebeaker>
right now we push something like [123, :like!, "http://
www.example.com/"] into redis, and we pop them all off, and turn that into FbGraph.new(User.find(123)).like!('http://
www.example.com') -- but naturally, pushing arbitrary arrays into resque - we don't get a lot of feedback on how well it worked out :)
09:03
<codebeaker>
(also for favebook, emails, it's a pattern repeted quite often in our app)
09:04
<codebeaker>
as the queue is emptied very quickly, we have absolutely no worries that Redis might not scale (heh.)
09:05
<codebeaker>
it is sane to use Redis as a persistence layer for this kind of thing?
09:05
<codebeaker>
the data isn't hugely valuable, except for debugging, and some indication of health
09:06
<soveran>
we are using it as the only database for a number of projects since 2009
09:06
<soveran>
so I would say yes, go for it
09:07
<codebeaker>
ok, sounds good
09:07
<codebeaker>
and one thing about ohm, speficially - what happens if you change the schema, are unknown atrtibutes simply `nil` ?
09:08
<codebeaker>
(thus, does it make sense to have something like:: def status; attributes[:status] || :queued; end
09:09
<cyx>
they're nil when empty
09:09
<codebeaker>
ok, so far - so good :)
09:10
<codebeaker>
I just need to resolve how best that fits into my app, and dig into some refactoring :)
09:48
<GitHub69>
[ohm] soveran pushed 3 new commits to txn-plus-callbacks: http://git.io/b9GCGg
09:48
<GitHub69>
[ohm/txn-plus-callbacks] Fix tests for transactions. - Michel Martens
09:48
<GitHub69>
[ohm/txn-plus-callbacks] Use merge to preserve the original set (tip by luislavena). - Michel Martens
09:48
<GitHub69>
[ohm/txn-plus-callbacks] Rename blocks to phase. - Michel Martens
10:12
<GitHub117>
[ohm] soveran pushed 1 new commit to txn-plus-callbacks: http://git.io/5rR4rg
10:12
<GitHub117>
[ohm/txn-plus-callbacks] Add minimal documentation for transactions. - Michel Martens
10:26
<GitHub183>
[ohm] soveran pushed 2 new commits to master: http://git.io/mAL2iw
10:26
<GitHub183>
[ohm/master] Merge branch 'txn-plus-callbacks' - Michel Martens
10:26
<GitHub183>
[ohm/master] Unify transaction tests. - Michel Martens
12:22
cinemascop89 joined
13:24
<jano>
cyx: nice example on overriding initialize_id
13:24
<jano>
i wonder if we should make the method public or something
13:24
<jano>
so that we can rely on it
13:25
<cyx>
jano: in ohm docs?
13:25
<cyx>
I guess it's public especially since soveran renamed all "private" methods to start with an underscore
13:25
<cyx>
just a bit esoteric
13:28
vitoravelino joined
13:28
vitoravelino joined
13:41
<jano>
def initialize_id
13:41
<jano>
@id = SecureRandom.urlsafe_base64
13:41
<jano>
end until self.class.all << self
13:41
<jano>
just to be safe
13:47
<soveran>
jano: in the example?
13:48
<jano>
soveran: no, i mean i just implemented it that way
13:48
<jano>
if there was any collision, i'd never find out
13:51
<soveran>
yes, that looks safe
14:01
<cyx>
yep it looks safe
14:02
<cyx>
jano: I still prefer
14:03
<cyx>
but that's me
14:03
<jano>
cyx: you mean because of the base?
14:03
<jano>
'how it looks in the end'?
14:04
<cyx>
well also because I trust UUIDs more not to collide
14:05
<jano>
there's also SecureRandom.hex
14:05
<cyx>
jano: your usecase is to avoid incremental ids?
14:06
<jano>
cyx: exactly
14:06
<cyx>
I did something for a site once
14:06
<cyx>
it basically uses an incr but converts that to sha1
14:06
<soveran>
the goal is hiding sequences or quantities?
14:07
<cyx>
sha1("#{self.class.key[:id].incr}")
14:07
<cyx>
that would hit it
14:07
<jano>
cyx: i just thought about that after you asked me :D good idea
14:07
<cyx>
add a salt to be more unpredictable
14:07
<jano>
soveran: i guess hiding quantities
14:07
<cyx>
even md5 is safe enough
14:08
<cyx>
chances-of-collision wise
14:08
<cyx>
so I'd go with that
14:08
<cyx>
incrementing ID-backed system with salt
14:08
<cyx>
sha1("#{self.class.key[:id].incr}--#{salt}")
14:08
<soveran>
incr + 998012 ¬¬
14:08
<cyx>
soveran: HAHAH
14:09
<soveran>
incr + CHEAT_QTY
14:09
<cyx>
jano: you can also go the bitly route
14:09
<cyx>
incrementing id then convert to base62
14:10
<cyx>
that's masked enough for the normal eye to see
14:12
<jano>
cyx: i guess that's because they still need the result to be short
14:12
<jano>
in my case i don't really care
14:12
<jano>
so md5 or sha1 of number + salt should do...
14:13
<jano>
if the solution is clean and not hackish, maybe we can include it in the docs
14:13
<jano>
alongside the UUID solution
14:15
<cyx>
I've used it many times in the past so I'm comfortable
14:16
<cyx>
for generating invoice codes
14:16
<jano>
that's what i need, hehe
14:18
<cyx>
oh invoice codes exactly?
14:19
<jano>
def initialize_id
14:19
<jano>
@id = Digest::MD5.hexdigest("#{@id} / 998001")
14:22
<jano>
(that's for real)
14:28
<cyx>
User[email: "foo@bar.com"]
14:28
<cyx>
what do you think of that API call?
14:28
<soveran>
visually, I love it
14:28
<soveran>
I don't know if I will like the implementation
14:28
<cyx>
yes visually awesome
14:29
<jano>
visually, nice
14:29
<soveran>
implementation-wise, something like User.by(:email, "foo@bar.com") is better
14:29
<jano>
but i don't like that polymorphic apis
14:29
<jano>
we'd need to check for the type of the argument
14:29
<soveran>
User.with(:email, "foo@bar.com")
14:29
<cyx>
smells like AR.find
14:29
<cyx>
.with is pretty nice
14:35
<soveran>
cyx, jano: let's vote
14:35
<soveran>
for a temp solution at least
14:35
<soveran>
jano: what are you using for that?
14:35
<cyx>
I vote User.with(:email, "foo@bar.com")
14:36
<cyx>
plus it sounds like bi-sexual
14:37
<GitHub185>
[ohm] cyx created unique (+2 new commits): http://git.io/l7Jprw
14:37
<GitHub185>
[ohm/unique] Add a counters test. - Cyril David
14:37
<GitHub185>
[ohm/unique] Initial spike of unique index. - Cyril David
14:37
<jano>
soveran: sorry
14:37
<jano>
soveran: here
14:37
<jano>
soveran, cyx: i was using find_unique(:email, "foo@bar.com")
14:38
<cyx>
clear for sure
14:39
<jano>
i think my reasoning was: if find can give me many, find_unique always gives me one
14:40
<jano>
sorry guys gotta run for a bit
14:41
<GitHub40>
[ohm] cyx pushed 1 new commit to unique: http://git.io/xLyykw
14:41
<GitHub40>
[ohm/unique] Remove vestigial code. - Cyril David
14:41
<jano>
i wasn't following the transactions code :(
16:26
cinemascop89 joined
17:46
cinemascop89 joined
20:14
cinemascop89 joined
21:22
cinemascop891 joined