Activity Graph

Page 1 of 5 | Next »



[00:15:27] krainboltgreene: has joined #RubyOnRails


[10:46:37] krainboltgreene: Ping timeout: 256 seconds
[10:49:35] krainboltgreene: has joined #RubyOnRails


[03:43:57] krainboltgreene: Ping timeout: 256 seconds
[03:46:40] krainboltgreene: has joined #RubyOnRails
[03:51:26] krainboltgreene: Ping timeout: 260 seconds
[05:41:39] krainboltgreene: has joined #RubyOnRails
[05:56:24] krainboltgreene: Ping timeout: 256 seconds
[06:16:23] krainboltgreene: has joined #RubyOnRails


[02:47:48] krainboltgreene: has joined #RubyOnRails


[09:07:17] krainboltgreene: ...Is there any way to change the fact that rails expects the app directory to be called `app/`?


[02:28:57] krainboltgreene: has joined #RubyOnRails
[02:29:43] krainboltgreene: Okay, am I losing it or is there no way to do "has one via a join table"?


[10:37:59] krainboltgreene: has joined #RubyOnRails



[20:31:41] krainboltgreene: Ping timeout: 258 seconds
[20:34:34] krainboltgreene: has joined #RubyOnRails


[05:25:41] krainboltgreene: Ping timeout: 260 seconds
[05:32:10] krainboltgreene: has joined #RubyOnRails


[08:45:44] krainboltgreene: Ping timeout: 250 seconds
[08:50:46] krainboltgreene: has joined #RubyOnRails


[13:24:11] krainboltgreene: has joined #RubyOnRails


[03:33:27] krainboltgreene: Ping timeout: 246 seconds
[03:38:47] krainboltgreene: has joined #RubyOnRails


[18:04:46] krainboltgreene: has joined #RubyOnRails
[18:05:20] krainboltgreene: I have a weird situation. Adding `default_scope { order(created_at: :desc) }` creates a really weird `WHERE` query.
[18:05:36] krainboltgreene: `... WHERE "v2_activities"."id" IN (SELECT "v2_activities"."id" FROM "v2_activities" ORDER BY "v2_activities"."created_at" DESC)`
[18:05:42] krainboltgreene: I'm not sure why it's doing that.
[18:09:34] krainboltgreene: tubbo: That's what I said, yes.
[18:12:21] krainboltgreene: Right? Like, as soon as I remove the default scope it goes back to normal.
[18:12:39] krainboltgreene: Plus, now I'm noticing all the queries relating to this model have a huge space between the order and the query.
[18:16:57] krainboltgreene: tubbo: I mean, what's the alternative? `id` isn't a good sort for me.
[18:17:19] krainboltgreene: Adding a scope is annoying, I'll look into the postgres thing.
[18:19:32] krainboltgreene: Well yeah, I know how to manually order haha.
[18:20:11] krainboltgreene: Sure, here you go smathy:
[18:20:38] krainboltgreene: To be fair, I could care less about ordering in an update_all.
[18:20:46] krainboltgreene: I guess it can't figure that out without being More Smart.
[18:20:56] krainboltgreene: smathy: It absolutely does.
[18:21:36] krainboltgreene: smathy: It adds 8s to the query?
[18:21:51] krainboltgreene: This is a pretty big table.
[18:22:10] krainboltgreene: I've opted to just remove the default scope.
[18:22:43] krainboltgreene: Can yall stop sending me links? :P
[18:23:04] krainboltgreene: smathy: Definitely indexed.
[18:23:22] krainboltgreene: It's a very large table.
[18:23:31] krainboltgreene: We went overboard on tracking activities, haha.
[18:24:49] krainboltgreene: tubbo: I doubt my job is dependant on the links I receive D:
[18:25:01] krainboltgreene: I'll have to re-read my contract!
[18:25:22] krainboltgreene: Wait, is this because update all can't take an order?
[18:25:31] krainboltgreene: So like, arel is doing it's best to include an order?
[18:25:42] krainboltgreene: Haha, wonderful.
[18:26:27] krainboltgreene: Honestly, I've been neck deep in node ORMs and I miss all the thinks AR is smart about.
[18:26:35] krainboltgreene: But this is kinda funny, anyways thanks all!
[18:31:10] krainboltgreene: In this case the activities have a primary key that isn't orderable.
[18:31:18] krainboltgreene: So the real default order, by `id`, is useless.
[18:35:58] krainboltgreene: If I added a scope that only hurts just because of first, that's hilarious.


[00:44:29] krainboltgreene: has left #ruby: ()
[00:44:52] krainboltgreene: has left #ruby-offtopic: ()
[00:45:06] krainboltgreene: has left #RubyOnRails: ()


[20:14:14] krainboltgreene: has joined #ruby-offtopic
[20:59:32] krainboltgreene: has joined #ruby
[21:00:16] krainboltgreene: It's pretty obvious.


[00:09:16] krainboltgreene: What are the premo rails job sites these days? Everyone I used to know about has dried up.
[00:15:52] krainboltgreene: That's the choice place, eh? Surpises me. I never saw them as a good channel.
[00:16:47] krainboltgreene: Radar: And the reverse?
[00:17:17] krainboltgreene: Radar: When you're looking for hires.
[00:17:56] krainboltgreene: Well at least everyone is having the same problem.


[23:23:03] krainboltgreene: has joined #ruby
[23:23:27] krainboltgreene: has left #ruby: ()


[18:11:58] krainboltgreene: has joined #RubyOnRails


[00:23:47] krainboltgreene: Anyone have a good rspec setup for testing rspec with an sql database? Thinking SQLite specifically.
[00:24:04] krainboltgreene: Er, for testing a gem with rspec, using SQLite.
[00:31:04] krainboltgreene: Exactly what I was looking for:
[06:27:44] krainboltgreene: It's so weird coming back to Ruby and realizing that nearly all of Array's methods mutate.
[06:38:24] krainboltgreene: Grumble. Neat trick with Array[] doesn't work with Hash[]. Booo.


[10:25:22] krainboltgreene: Read error: Connection reset by peer
[10:45:37] krainboltgreene: has joined #RubyOnRails


[10:36:48] krainboltgreene: Ping timeout: 264 seconds
[10:37:35] krainboltgreene: has joined #RubyOnRails


[16:00:12] krainboltgreene: Ping timeout: 264 seconds
[16:01:59] krainboltgreene: has joined #RubyOnRails


[15:41:45] krainboltgreene: has joined #RubyOnRails
[16:48:05] krainboltgreene: has joined #RubyOnRails
[18:41:53] krainboltgreene: Remote host closed the connection
[18:52:58] krainboltgreene: has joined #RubyOnRails


[11:36:46] krainboltgreene: Ping timeout: 240 seconds
[11:39:39] krainboltgreene: has joined #RubyOnRails


[08:29:37] krainboltgreene: has joined #RubyOnRails


[21:26:45] krainboltgreene: Read error: Connection reset by peer
[22:09:01] krainboltgreene: has joined #RubyOnRails


[00:04:38] krainboltgreene: has joined #RubyOnRails
[10:42:49] krainboltgreene: has joined #RubyOnRails
[10:47:03] krainboltgreene: has joined #RubyOnRails


[08:17:36] krainboltgreene: has joined #RubyOnRails
[08:24:59] krainboltgreene: has joined #RubyOnRails
[22:51:21] krainboltgreene: Remote host closed the connection
[23:12:15] krainboltgreene: has joined #RubyOnRails


[21:16:09] krainboltgreene: radar: It's a chat thing, for repositories.
[21:17:14] krainboltgreene: Hmm, good question. I may have not understood what they were asking for. Mind rejecting? I was trying to make a room for redis-store/redis-store, but they haven't updated my list of repos.
[21:17:22] krainboltgreene: Or since I'm not a owner, I may not have permission.
[21:19:30] krainboltgreene: radar: Oh right I did it for that org too.
[21:19:33] krainboltgreene: Yeah, just reject it.
[21:22:55] krainboltgreene: Radar: If you could setup gitter for redis-store, paranoia, and forem that would be nice.


[05:38:13] krainboltgreene: Anyone have any experience or tips on using Arel::InsertManager with JSON values?
[05:38:24] krainboltgreene: It's annoyingly triple quoting my json.
[05:38:47] krainboltgreene: I think because I'm passing JSON.dump -> ActiveRecord::Base.sanitize -> Arel::InsertManager.insert()


[03:58:15] krainboltgreene: Radar: Hey, as per my email I'd love to read a postmortem to that blog post.
[03:58:40] krainboltgreene: I don't think I've ever seen that done, except as fallout from a death :/
[03:59:39] krainboltgreene: Radar: Things like the number of responses, who handles what, and what their plans are if you got any details.
[04:00:44] krainboltgreene: I maintain dante because dante's owner just...stopped and I had a huge PR. Hamster was (I think) because I was twitter friends with the owner.
[04:01:36] krainboltgreene: VCR was strange. Myron tweeted about it, I said hello, then he wanted to do a volunteer thing, but then no one actually did anything, so it just "defaulted" to me.
[04:03:22] krainboltgreene: It's cool to be alive during the time of programming maturation, where maintainers change and not because of a government contract ending.
[04:19:57] krainboltgreene: Radar: Getting into that sort of thing now. If you get anyone elses name for forem let me know. I don't use it, so I would be a poor forward thinker for it. I can do much more good communicating and cleaning up.
[04:33:04] krainboltgreene: I figured you might be getting swamped.
[04:35:26] krainboltgreene: Radar: Note I don't have access to redis-store yet, so...


[05:51:11] krainboltgreene: Ping timeout: 250 seconds
[10:20:30] krainboltgreene: Ping timeout: 252 seconds
[10:26:43] krainboltgreene: has joined #RubyOnRails


[04:58:02] krainboltgreene: Radar: Hey, I have a sitaution that you've probably run into. I want to take a record, modify the associated records in memory (including subsets of those associations), and then be able look at that soft application without re-evaluating associations.
[04:58:56] krainboltgreene: This is in the context of an advanced promotion code system, where I want to "soft apply" the promotion mutations, and then offer up the soft-applied cart (and related items). Problem: Every time I look at the relationships on the soft applied object, it redoes the SQL.
[05:00:40] krainboltgreene: I'm betting radar will get it.
[05:01:21] krainboltgreene: matthewd: I'd rather not touch the database at all, I just want to modify the object graph.
[05:07:31] krainboltgreene: Anyone know a gem that'll give me the diff between two active record object graphs?
[05:08:24] krainboltgreene: rhizome: record.diff(record.clone)
[05:08:27] krainboltgreene: Radar: No worries.
[05:09:05] krainboltgreene: (That would return an empty diff, but eh)
[05:09:41] krainboltgreene: Radar: If I get to FOSS this project I think it would be valuable for spree, fwiw.
[05:10:09] krainboltgreene: matthewd: Yeah, that's probably going to be my next step. Recursive #attributes.
[05:10:18] krainboltgreene: radar: Oh shit, I had no idea!
[05:11:12] krainboltgreene: Heh, fancy lightbulb people.
[05:11:30] krainboltgreene: matthewd: I bet I could use #changed
[05:11:35] krainboltgreene: Oh shit I bet that would work well.
[05:11:38] krainboltgreene: recursive changed.
[05:13:00] krainboltgreene: matthewd: Still, thanks! I think this might be close enough.
[05:13:45] krainboltgreene: matthewd: Amusingly I think identity-map would have helped?
[05:14:01] krainboltgreene: I mean the big issue is that AR is doing the right thing: I'm asking for all associations and it can't tell what I had in memory.
[05:14:54] krainboltgreene: Well I wouldn't need it at that point, right?
[05:15:08] krainboltgreene: Cus cart.items would return identity-mapped objects and new objects.
[05:35:36] krainboltgreene: matthewd: So for record's sake, I solved the issue by using #includes and dropping scopes for ruby enumerable methods.
[05:36:14] krainboltgreene: The includes puts things in memory, then (if you're using no scopes) it makes no sql calls, which doesn't bust the object graph.
[05:36:41] krainboltgreene: Sadly it means a scope is done in Ruby rather than SQL, mainly because I don't think I can do scopes in #includes.
[05:55:26] krainboltgreene: I wish Ruby's Array had non-mutating methods
[06:10:03] krainboltgreene: This would be much easier if changed reported relationship changes.
[06:26:25] krainboltgreene: Here's an abstract of my problem, if anyone's interested:
[06:40:45] krainboltgreene: What don't you get?
[07:22:02] krainboltgreene: sevenseacat radar: Fair enough I guess, the problem is that calling the last line breaks the object graph in memory, killing the change of the brand value.
[07:24:22] krainboltgreene: Which means that soft applying changes to the object graph becomes impossible with scopes, possible with eager loading and no scopes. Eager loading has it's own problems in that saving the root object doesn't save changed nested objects in the graph.
[07:24:42] krainboltgreene: Also, you know, eager loading.
[07:31:30] krainboltgreene: radar:
[07:32:35] krainboltgreene: Anyways, that's the issue. relationship scopes break in-memory object graphs.
[07:53:34] krainboltgreene: Okay so this is cool af:
[07:53:49] krainboltgreene: And basically lets me solve this issue. Woo.


[20:34:18] krainboltgreene: has left #ruby: ()


[21:34:31] krainboltgreene: Radar: Oh shit that joke is brilliant haha.


[10:18:43] krainboltgreene: goldbug: Tell you what, I've done a lot of Ruby and a lot of Rails, I have never seen anything like that.
[10:19:15] krainboltgreene: That's an entirely foreign format for me.
[10:19:28] krainboltgreene: FailBit: No, the gist.
[10:20:31] krainboltgreene: goldbug: Huh, well look the top line leads me to believe you've got a wild nil going around.
[10:20:41] krainboltgreene: `action#NilClass, *args#Array`
[10:21:06] krainboltgreene: It's displaying the class by each, where action is a NilClass (aka nil) and args is an Array (*, so makes sense)
[10:21:43] krainboltgreene: Why that gives you a SLTD I have no idea.
[10:22:04] krainboltgreene: Oh, maybe you defined a variable that has the same name as a AD method?
[10:22:27] krainboltgreene: It might then be in the metamagic of the controller.
[10:22:43] krainboltgreene: I've never fully read the Routes source.
[10:23:10] krainboltgreene: goldbug: Any chance you can gist the routes + people controller?
[10:26:43] krainboltgreene: Well as a side note
[10:28:59] krainboltgreene: goldbug: Well, that's the genius of their suggestion: Accounting for that complexity results in a single, length unspecified, text column.
[10:29:17] krainboltgreene: In regards to your problem, I don't see any specific issues.
[10:29:31] krainboltgreene: Nothing is eyeball wrong with your controller or routes.
[10:29:43] krainboltgreene: Your view doesn't even come into play.
[10:30:07] krainboltgreene: So either I'm wrong about the controller, you're not telling us everything about the routes, or something strange is going on in that model code.
[10:30:37] krainboltgreene: Likely to do with translates, globalize_accessors, or globalize_attribute_names


[00:13:38] krainboltgreene: has joined #ruby
[00:13:46] krainboltgreene: has joined #RubyOnRails


[17:48:59] krainboltgreene: Because I'm fairly sure I've never seen this done, here's a showcase of destructing an array:


[00:00:46] krainboltgreene: I wish I could just do Account.conccurent(10).each(&:reset_password) and have it use 10 threads.
[00:02:48] krainboltgreene: smathy: Yeah, can't use update_all
[00:03:31] krainboltgreene: smathy: Then I run into connection pool problems :/
[00:05:10] krainboltgreene: I could compute the bcrypt early, turn it into [id, encryped_password], then junk those into connection.execute.
[00:05:16] krainboltgreene: The former is threadable.
[00:12:46] krainboltgreene: Kinda wanted to avoid the overhead of resque worker/resque server, but if I have to...
[00:15:51] krainboltgreene: Well I'm not going to bring in a new worker framework for one thing haha.
[20:46:17] krainboltgreene: has joined #RubyOnRails
[20:46:20] krainboltgreene: has joined #ruby
[22:09:17] krainboltgreene: Remote host closed the connection
[22:27:47] krainboltgreene: has joined #ruby
[22:27:47] krainboltgreene: has joined #RubyOnRails


[23:54:51] krainboltgreene: Account.find_each(&:reset_password) on a whole ton of records is really slow, is there an easy interface for doing concurrent writes via ActiveRecord?


[18:14:28] krainboltgreene: This is going to sound silly, but what's an easy (preferably corelib|stdlib) way of taking a long (20..90 characters) string and shortening it? base64 is alright, but not really short enough.
[18:15:19] krainboltgreene: RxDx: There are a lot of reasons, but really it's because you're normalizing beer attributes onto the core object, and attributes for a beer are not the same as a beer.
[18:15:41] krainboltgreene: Okay, real reason: It makes it easy to write generic code for that style of normalization.
[18:17:04] krainboltgreene: FailBit: I mean I'm getting shorter values I think.
[18:18:12] krainboltgreene: FailBit: Oh wow, yeah, it's longer, it just seemed shorter.
[18:18:59] krainboltgreene: RxDx: What's the difference between beer as a normalized set of values (beer_attributes) and beer as a struct (stored say in postgres as hstore or jsonb)
[18:19:09] krainboltgreene: To the server there's no way to tell generically.
[18:19:34] krainboltgreene: So the conceit is that _attributes tells rails what the difference is.


[00:32:26] krainboltgreene: Best. Thing. Ever:
[00:32:49] krainboltgreene: I cut 20% off my per-request memory footprint.


[08:02:33] krainboltgreene: has joined #ruby
[08:02:33] krainboltgreene: has joined #RubyOnRails


[08:53:52] krainboltgreene: Remote host closed the connection
[09:02:37] krainboltgreene: has joined #ruby
[09:02:37] krainboltgreene: has joined #RubyOnRails


[00:21:59] krainboltgreene: What the hell is that?
[00:22:45] krainboltgreene: What I wouldn't give for pre-send-to-channel hooks for ops.


[01:01:35] krainboltgreene: Radar: Yeah, we've got it ticked on now, it's actually how I know the # of allocations/request.
[01:01:45] krainboltgreene: Average 800k, high 1.2m
[01:02:53] krainboltgreene: I guess if you ever started hating money.
[01:03:42] krainboltgreene: If we ever got that many requests/min I think we'd be paying for 20perf dynos.
[01:04:42] krainboltgreene: Right? That's pretty impressive. Kudos.
[01:05:54] krainboltgreene: Alright, off to coffee, thanks people :)