Activity Graph

Page 1 of 41 | Next »


[19:14:46] yorickpeterse: has joined #ruby
[19:17:07] yorickpeterse: has joined #ruby


[10:25:58] yorickpeterse: has joined #ruby-offtopic
[10:25:58] yorickpeterse: has joined #ruby


[23:04:22] yorickpeterse: has joined #ruby-offtopic
[23:04:22] yorickpeterse: has joined #ruby
[23:48:51] yorickpeterse: Quit: WeeChat 2.3


[13:23:55] yorickpeterse: has joined #ruby
[13:24:37] yorickpeterse: has joined #ruby-offtopic
[13:25:55] yorickpeterse: has left #ruby: ("User left")
[13:25:59] yorickpeterse: has left #ruby-offtopic: ("User left")


[23:46:41] yorickpeterse: has joined #ruby
[23:46:42] yorickpeterse: has joined #ruby-offtopic
[23:54:58] yorickpeterse: Quit: WeeChat 2.3


[16:56:01] yorickpeterse: has joined #ruby-offtopic
[16:56:01] yorickpeterse: has joined #ruby
[17:27:27] yorickpeterse: Quit: WeeChat 2.3


[18:56:58] yorickpeterse: has joined #ruby-offtopic
[18:56:58] yorickpeterse: has joined #ruby


[23:16:54] yorickpeterse: has joined #ruby-offtopic
[23:16:54] yorickpeterse: has joined #ruby
[23:46:10] yorickpeterse: Quit: WeeChat 2.2


[15:50:13] yorickpeterse: has joined #ruby-offtopic
[15:50:13] yorickpeterse: has joined #ruby
[16:59:37] yorickpeterse: Quit: WeeChat 2.2


[17:00:40] yorickpeterse: has joined #ruby-offtopic
[17:00:40] yorickpeterse: has joined #ruby


[14:53:29] yorickpeterse: has joined #ruby
[15:24:19] yorickpeterse: Quit: WeeChat 2.1


[14:46:02] yorickpeterse: has joined #ruby
[20:10:40] yorickpeterse: Quit: WeeChat 2.1
[20:15:02] yorickpeterse: has joined #ruby
[22:39:09] yorickpeterse: Quit: WeeChat 2.1


[20:00:30] yorickpeterse: has joined #ruby
[21:21:12] yorickpeterse: Quit: WeeChat 2.0.1


[18:09:37] yorickpeterse: Quit: yorickpeterse
[18:11:23] yorickpeterse: has joined #ruby-offtopic
[18:11:23] yorickpeterse: has joined #ruby
[19:45:59] yorickpeterse: has joined #ruby
[19:47:15] yorickpeterse: has left #ruby: ()
[19:48:31] yorickpeterse: has joined #ruby-offtopic
[19:48:31] yorickpeterse: has joined #ruby
[19:52:05] yorickpeterse: has joined #ruby-offtopic
[19:52:05] yorickpeterse: has joined #ruby
[19:57:40] yorickpeterse: has joined #ruby-offtopic
[19:57:40] yorickpeterse: has joined #ruby
[20:03:20] yorickpeterse: Quit: WeeChat 1.9.1
[20:07:24] yorickpeterse: has joined #ruby-offtopic
[20:07:24] yorickpeterse: has joined #ruby
[20:18:38] yorickpeterse: has joined #ruby
[20:19:29] yorickpeterse: has joined #ruby
[20:19:30] yorickpeterse: Read error: Connection reset by peer
[20:29:36] yorickpeterse: has joined #ruby-offtopic
[20:29:36] yorickpeterse: has joined #ruby
[20:34:50] yorickpeterse: Quit: WeeChat 1.9.1
[20:36:25] yorickpeterse: has joined #ruby-offtopic
[20:36:25] yorickpeterse: has joined #ruby
[20:38:51] yorickpeterse: has joined #ruby-offtopic
[20:38:51] yorickpeterse: has joined #ruby
[20:47:39] yorickpeterse: Quit: WeeChat 1.9.1


[22:15:01] yorickpeterse: Ping timeout: 240 seconds
[22:24:21] yorickpeterse: has joined #ruby-offtopic
[22:24:21] yorickpeterse: has joined #ruby


[12:42:38] yorickpeterse: has left #RubyOnRails: ()


[12:05:29] yorickpeterse: has joined #RubyOnRails
[12:06:27] yorickpeterse: I'm running into a case where using `SomeModel.eager_load(:bla).first.bla` returns nil, but `SomeModel.includes(:bla).first.bla` returns the expected object. Does #eager_load have additional requirements for this to work?
[12:07:38] yorickpeterse: https://gist.github.com/YorickPeterse/99419a942229c796bb0bb2b1a94a9db1 for example
[12:08:41] yorickpeterse: The underlying SQL query used for #eager_load is fine and includes the expected data
[12:08:48] yorickpeterse: but for whatever reason Rails doesn't set the association
[12:08:57] yorickpeterse: but it does for other models, to make things weirder


[23:56:41] yorickpeterse: has joined #ruby-offtopic
[23:56:44] yorickpeterse: has joined #ruby


[18:18:49] yorickpeterse: adam12: no problem, glad you enjoy using it


[23:29:49] yorickpeterse: cahoots: you mean you'd end up with something like `params = self.params`?
[23:30:34] yorickpeterse: the name you'd give both method and variable really depends on what the method does
[23:34:49] yorickpeterse: if the result of the method is always the same you could store it in an instance variable
[23:34:58] yorickpeterse: `def params; @params ||= ...; end`


[20:19:30] yorickpeterse: cahoots: $? is scoped per thread
[20:20:13] yorickpeterse: actually, seems behaviour contradicts the source
[20:20:43] yorickpeterse: ah no, that was just Pry messing things up
[22:55:27] yorickpeterse: I'd argue Pry is no more confusing than IRB


[14:51:44] yorickpeterse: dminuoso: works fine with universal-ctags
[14:52:08] yorickpeterse: I use it in combination with vim-gutentags, works really well


[10:48:58] yorickpeterse: dminuoso: he pops up in the comments on /r/programming quite often
[10:49:02] yorickpeterse: and usually gets downvoted pretty hard


[15:57:28] yorickpeterse: dminuoso: shevy is now mostly being a weirdo on /r/programming


[21:43:34] yorickpeterse: I'm shocked there's no financial related gem called makeitrain


[10:26:56] yorickpeterse: dminuoso: you mean pure as in it won't GC?
[10:47:38] yorickpeterse: dminuoso: So the answer to that is "yes and no"
[10:48:04] yorickpeterse: You may cross a threshold that would schedule GC, but this usually only happens in so called "GC safepoints"
[10:48:43] yorickpeterse: These safepoints are typically at the start/end of a function, maybe before starting a loop, etc
[10:49:26] yorickpeterse: Such a safepoint is necessary because e.g. VMs may keep objects off the stack (e.g. as a local in a function body in the interpreter)
[10:49:38] yorickpeterse: so if a GC would occur at that point it could end up GC'ing live-but-invisible objects
[12:18:01] yorickpeterse: Winter_Foxo: https://github.com/rubysec/bundler-audit
[12:59:20] yorickpeterse: I think typically in FP that "no side effects" doesn't cover GC
[12:59:40] yorickpeterse: we have it hooked up in GitLab's CI
[13:00:04] yorickpeterse: mikecmpbll: I don't think Ruby's built-in Time/Date methods can parse in a custom timezone
[13:00:09] yorickpeterse: they either use UTC or localtime
[13:00:25] yorickpeterse: not sure what today's go-to Gem is for date + timezone parsing
[13:00:54] yorickpeterse: If so nothing could be side effect free, since allocating memory would technically also be a side effect
[15:47:00] yorickpeterse: eam: re that mysql2 issue, briefly scanning suggests it's more about fork() than GC
[15:47:05] yorickpeterse: fork() is hell
[15:48:19] yorickpeterse: and yeah, the rest of MRI specifics leaking into the language is true
[15:48:36] yorickpeterse: same goes for various parts of the stdlib, they're just lightweight wrappers around POSIX APIs
[15:48:40] yorickpeterse: Don't get me started on the Socket API
[15:49:31] yorickpeterse: Ruby's GC overall is a bit odd, until recent years it was years behind others
[15:49:37] yorickpeterse: now it's still behind but not so much
[15:49:57] yorickpeterse: I found it in particular funny how around 2.0 they had this big announcement about bitmap marking and what not
[15:50:08] yorickpeterse: which is something that has existed (and has been used) for at least 20 years?
[15:50:25] yorickpeterse: kind of the same as every Go GC announcement
[15:50:36] yorickpeterse: Lots of big words, but under the hoods it really isn't as revolutionary
[15:51:17] yorickpeterse: In fact, I'd argue the only exciting GC changes in recent years were: Immix and Azul's pauseless GC
[15:51:24] yorickpeterse: even though IIRC Azul's pauseless GC isn't actually pauseless
[15:51:34] yorickpeterse: and requires special purpose hardware to work at its best
[15:51:47] yorickpeterse: and makes a whole bunch of other trade-offs
[15:52:49] yorickpeterse: Immix is nice because it's pretty boring: it basically takes M&S and makes it suck less
[15:53:03] yorickpeterse: though I'm still grumpy the paper doesn't include any proposals for finalisation
[15:56:05] yorickpeterse: Ah, according to the GC handbook bitmap marking originated in 1988
[15:56:44] yorickpeterse: So in 2013 (when 2.0 came out) they were only behind 25 years :D
[17:45:49] yorickpeterse: dminuoso: to be fair I think guilds are the wrong approach
[17:46:01] yorickpeterse: I'd rather see them for once remove the fucking GIL
[17:46:33] yorickpeterse: either they have to do that with 3.0, or Ruby will eventually become irrelevant
[17:46:40] yorickpeterse: since 4.0 is probably still 20 years away
[17:46:48] yorickpeterse: by then nobody cares any more


[10:37:57] yorickpeterse: gokul_mr[m]: typically private methods are used as "helpers" for public methods
[10:38:03] yorickpeterse: Personally I really hate protected/private
[10:38:39] yorickpeterse: mostly because more often than not those helper methods can be incredibly useful to expose, and because there isn't really any harm in doing it either
[10:38:49] yorickpeterse: plus you can workaround private/protected anyway
[10:39:35] yorickpeterse: I feel it also leads to weird API design. That is, you have a public API that depends on a whole bunch of private/custom APIs _instead_ of re-using other public APIs
[10:39:54] yorickpeterse: basically you're hiding useful things from the user, with no real good reason


[00:09:02] yorickpeterse: "turns out the SQL interface is largely irrelevant" I disagree
[00:09:24] yorickpeterse: you can gain a lot by using more than just some dumbass ORM that only supports a basic set of SQL operations
[00:09:34] yorickpeterse: e.g. random feature that's really useful for certain things: CTes
[00:10:00] yorickpeterse: I agree on triggers/stored procedures, though triggers can be very useful for a limited set of tasks
[00:10:22] yorickpeterse: e.g. at GitLag we use them for certain data migrations to ensure things are in sync
[00:10:33] yorickpeterse: but they only stick around for the duration of a migration, after which they're nuked
[00:12:30] yorickpeterse: constraints in turn are more used for things like "This string can only contain X, Y, Z"
[00:12:53] yorickpeterse: not for cross table guarantees, though I think you could technically do that (but I certainly wouldn't recommend it)
[00:13:41] yorickpeterse: what I personally hate in Pg is that going from one minor to another requires downtime basically
[00:13:56] yorickpeterse: since the data format is not guaranteed to be compatible you have to run pg_upgrade or w/e it was to upgrade the cluster
[00:14:07] yorickpeterse: you can work around it with logical replication, but fuck me it's annoying
[00:14:15] yorickpeterse: (have yet to look into pglogical and such)


[06:36:37] yorickpeterse: eam: aaah, cascading replication
[06:36:48] yorickpeterse: haven't worked with that myself, but the same should apply
[06:37:02] yorickpeterse: that is, you create replication slots on the primary and any other replication "origins"
[06:37:18] yorickpeterse: hm come to think of it, not sure if you actually can create a replication slot on a secondary


[09:09:03] yorickpeterse: adam12: both I think
[09:09:22] yorickpeterse: initially our process was a hit and miss, but it's pretty good now
[09:09:42] yorickpeterse: but we ask for both PostgreSQL and Rails (or similar frameworks) experience, and more often than not we get DBAs
[09:09:59] yorickpeterse: e.g. people who spent 10 years managing servers for customers, but last wrote code 5 years ago
[09:10:05] yorickpeterse: which isn't quite what we're looking for
[15:02:05] yorickpeterse: eam: we got a bunch of people who seemed to have good Postgres DBA experience
[15:02:12] yorickpeterse: but we're not looking for DBAs :/
[15:02:25] yorickpeterse: ljarvis: lol that fork
[15:03:04] yorickpeterse: That reminds me of this: https://libraries.io/rubygems/oga-without-the-wimpiness
[15:03:09] yorickpeterse: it got yanked of RubyGems unfortunately
[15:03:40] yorickpeterse: disagree? better create a passive-aggressive fork
[15:07:11] yorickpeterse: Regarding goto, technically I think you could dynamically recompile bytecode then use goto in the bytecode :D
[15:07:19] yorickpeterse: ACTION gets the razorblade
[15:10:51] yorickpeterse: bare metal Ruby
[15:48:09] yorickpeterse: eam: not even DBA
[15:48:16] yorickpeterse: just somebody with good PostgreSQL knowledge
[15:48:32] yorickpeterse: the position involves doing a lot of performance fixes for anything DB related
[15:48:49] yorickpeterse: dminuoso: I'd say 5+ years of experience or so?
[15:48:53] yorickpeterse: Depends a bit on what the person has been doing
[15:49:27] yorickpeterse: https://about.gitlab.com/jobs/specialist/database/ :P
[15:49:33] yorickpeterse: apeiros: yes, that's required
[15:51:47] yorickpeterse: dminuoso: e.g. sometimes it's as simple as adding an index, other times you'll end up re-writing entire parts to perform better
[15:52:00] yorickpeterse: e.g. I made a bunch of changes to the code we use for figuring out what you can access, which ended up making it a lot faster
[15:52:21] yorickpeterse: but there's also infrastructure work, e.g. testing pgbouncer, finding the right settings for it, deploying it, etc
[15:52:35] yorickpeterse: dminuoso: our PostgreSQL cluster itself is pretty vanilla
[15:52:43] yorickpeterse: we don't have any custom extensions or anything
[15:53:01] yorickpeterse: it's basically PostgresSQL + pgbouncer + streaming replication, with a custom DB load balancer built into GitLab
[15:53:15] yorickpeterse: we're working on setting up repmgr for automatic failovers, but that's not done yet
[15:53:22] yorickpeterse: apeiros: trigrams are so-so
[15:53:44] yorickpeterse: They're useful, but very heavy to maintain
[15:55:59] yorickpeterse: Updating them is expensive, at least for larger tables
[15:56:04] yorickpeterse: and they take up quite a bit of space
[15:57:09] yorickpeterse: Nah, no manual work needed
[15:57:38] yorickpeterse: 6.4 GB to index all GitLab.com comments using trigrams :D
[15:58:02] yorickpeterse: meanwhile the btrees are ~1GB for that same table
[15:58:23] yorickpeterse: To be fair, it's usually OK for writes to be a bit slower
[15:58:48] yorickpeterse: apeiros: so you want to search by addresses?
[15:58:52] yorickpeterse: or parts of them
[15:59:21] yorickpeterse: I'd probably use PostgreSQL's full text search for that to be honest
[15:59:59] yorickpeterse: I used it in the past for a company management tool for search companies by name, addresses, etc
[16:00:07] yorickpeterse: I think it was a combination of FTS and trigrams thugh
[16:00:19] yorickpeterse: Ah, trigrams won't help with that very much
[16:00:30] yorickpeterse: at least I don't think they will
[16:01:15] yorickpeterse: dunno if PostgreSQL's text search does Swiss though
[16:02:27] yorickpeterse: well it supports German, that's close enough :D
[16:03:20] yorickpeterse: personally I can't wait for the day we drop MySQL support in GitLab
[16:03:23] yorickpeterse: it would make things so much easier
[16:07:14] yorickpeterse: apeiros: right now we can't always fix things as well because there are no MySQL equivalents
[16:07:31] yorickpeterse: recently we did drop nested groups support on MySQL so we could do it better on PostgreSQL, with probably more to come in the future
[16:07:35] yorickpeterse: basically we're taking baby steps
[17:41:17] yorickpeterse: eam: euh, that sounds really sketchy
[17:41:32] yorickpeterse: if a replica fails this should have no impact on either the primary or other replicas
[17:41:51] yorickpeterse: If you don't want to re-run pg_basebackup you'll need to use replication slots so WAL data isn't removed prematurely
[17:42:28] yorickpeterse: if you're using synchronous replication there's a variety of strategies you can use to make problems less annoying
[17:42:48] yorickpeterse: e.g. you can configure PostgreSQL to only wait for a few replicas to acknowledge a write, instead of all of them
[17:42:54] yorickpeterse: but overall I'd use async replication
[17:43:01] yorickpeterse: and maybe 1 replica with sync replication for failover purposes
[20:38:22] yorickpeterse: eam: re basebackup: if you use replication slots it's not necessary
[20:38:42] yorickpeterse: basically each replica is given its own replication slot, the primary in turn won't remove WAL data until all replicas have it
[20:51:48] yorickpeterse: you only need pg_basebackup if you're setting up a new replica from scratch


[23:10:15] yorickpeterse: man hiring people is fucking hard
[23:18:41] yorickpeterse: of the 208 people that applied for our DB specialist position to date, only 1 made it to the last stage
[23:18:47] yorickpeterse: only to drop out because they got a counter offer :<
[23:19:28] yorickpeterse: 174 didn't even make it past the initial screening/reviewing (which is just checking if they meet the requirements in terms of years, etc0
[23:19:46] yorickpeterse: one very candidate is still going through the steps, really hope we get to hire that person
[23:19:53] yorickpeterse: * very promising candidate
[23:20:04] yorickpeterse: ljarvis: come work with me now that loco2 is acquired :D


[17:27:25] yorickpeterse: ljarvis: I typically use `each` instead of `map` if I have to skip over certain values
[17:27:35] yorickpeterse: instead of the anti-pattern that is `map { ... }.compact~
[17:27:48] yorickpeterse: I basically have map + compact PTSD at this point
[17:29:58] yorickpeterse: elomatreb: you're creating 2 arrays in that case
[17:30:10] yorickpeterse: which more often than not doesn't matter, but I still am not a fan of it
[17:30:25] yorickpeterse: something like select_map would be nice
[17:30:37] yorickpeterse: then alias it like filter_map :troll:


[18:04:01] yorickpeterse: Maybe you need to learn more Haskell


[05:26:50] yorickpeterse: has joined #ruby-offtopic
[05:26:50] yorickpeterse: has joined #ruby


[00:23:12] yorickpeterse: has joined #ruby


[22:42:38] yorickpeterse: nacsurte: I don't think that's possible no


[10:19:16] yorickpeterse: because without it prototype OO sucks