« Back to channel list

#RubyOnRails - 25 February 2019

« Back 1 day Forward 1 day »
[00:06:19] Technodrome: has joined #RubyOnRails
[00:08:32] mangold: has joined #RubyOnRails
[00:51:17] ariedler: has joined #RubyOnRails
[01:00:49] wethu: has joined #RubyOnRails
[01:05:13] bruul: has joined #RubyOnRails
[01:08:03] sevenseacat: has joined #RubyOnRails
[01:14:06] ariedler: has joined #RubyOnRails
[01:36:16] ariedler: has joined #RubyOnRails
[02:01:15] gambl0r3: has joined #RubyOnRails
[02:10:35] NeXTSUN: has joined #RubyOnRails
[02:16:46] kvda: has joined #RubyOnRails
[02:36:53] ariedler: has joined #RubyOnRails
[02:39:04] nativetexan: has joined #RubyOnRails
[02:40:46] nativetexan: was thinking about using ruby rail cms
[02:41:05] nativetexan: or maybe word press or joomla
[02:42:39] nativetexan: has left #RubyOnRails: ()
[03:11:25] NeXTSUN: has joined #RubyOnRails
[03:21:23] gambl0r3: has joined #RubyOnRails
[04:09:03] braincrash: has joined #RubyOnRails
[05:03:27] v01d4lph4: has joined #RubyOnRails
[05:50:08] uksio: has joined #RubyOnRails
[05:59:57] mangold: has joined #RubyOnRails
[06:01:08] srinidhi: has joined #RubyOnRails
[06:15:19] conta: has joined #RubyOnRails
[06:19:13] reber: has joined #RubyOnRails
[06:42:04] tdy1: has joined #RubyOnRails
[07:04:53] armyriad: has joined #RubyOnRails
[07:30:00] srinidhi: has joined #RubyOnRails
[07:37:00] kvda: has joined #RubyOnRails
[07:43:19] armyriad: has joined #RubyOnRails
[08:05:25] tdy2: has joined #RubyOnRails
[08:13:57] kvda: has joined #RubyOnRails
[08:29:05] srinidhi: has joined #RubyOnRails
[08:30:40] cgfbee: has joined #RubyOnRails
[08:50:35] mikecmpbll: has joined #RubyOnRails
[09:05:44] Ergo: has joined #RubyOnRails
[09:08:04] Aherin: has joined #RubyOnRails
[09:53:20] srinidhi: has joined #RubyOnRails
[09:53:53] segy: has joined #RubyOnRails
[10:04:55] srinidhi: has joined #RubyOnRails
[10:17:31] apparition: has joined #RubyOnRails
[10:32:43] lxsameer: has joined #RubyOnRails
[10:38:00] hadifarnoud: has joined #RubyOnRails
[11:00:21] conta: has joined #RubyOnRails
[11:03:08] phaul: has joined #RubyOnRails
[11:08:36] crankharder: has joined #RubyOnRails
[11:12:09] phaul: has joined #RubyOnRails
[11:15:02] KeyJoo: has joined #RubyOnRails
[11:17:00] kidPalooma: has joined #RubyOnRails
[11:18:08] beholders_eye: has joined #RubyOnRails
[11:19:54] kidPalooma: Hello, I need a multilingual taggable system for my app. I am already using globalize and I like how acts_as_taggable_on works, particularly the ability to have multiple tag types. I've read https://github.com/mbleigh/acts-as-taggable-on/issues/755 but it looks like it leaves some regressions. Is there an actually multilingual tagging solution for Rails?
[11:20:10] phaul: has joined #RubyOnRails
[11:29:44] beholders_eye: has joined #RubyOnRails
[11:46:59] lankanmon: has joined #RubyOnRails
[11:52:36] nakuku: has joined #RubyOnRails
[11:53:09] nakuku: Hello. Is it bad to use `User.first` in tests? Like, i have integration test on POST /posts endpoint
[11:53:20] nakuku: Some resource is created in the background
[11:53:32] nakuku: i dont return it in JSON
[11:53:55] nakuku: and i want to test if `User.first` match(hash_including(expected_attributes))
[11:55:05] nakuku: But i've heard you should not use User.first in the test because you aren't sure if it's this record for sure
[11:55:34] ariedler: has joined #RubyOnRails
[11:55:53] nakuku: Personally i have a feeling that these are some weird rules made up to make one feel better but maybe someone can convince me?
[11:57:00] ariedler: has joined #RubyOnRails
[12:05:48] mikecmpbll: has joined #RubyOnRails
[12:35:42] kvda: has joined #RubyOnRails
[12:51:10] Aherin: has joined #RubyOnRails
[12:56:51] Aherin_: has joined #RubyOnRails
[13:00:25] Aherin: has joined #RubyOnRails
[13:05:05] Aherin: has joined #RubyOnRails
[13:16:37] ariedler: has joined #RubyOnRails
[13:18:37] crankharder: has joined #RubyOnRails
[13:19:14] hadifarnoud: has joined #RubyOnRails
[13:38:54] segy: has joined #RubyOnRails
[13:39:12] beholders_eye: has joined #RubyOnRails
[13:41:07] srinidhi: has joined #RubyOnRails
[13:42:33] bijan_: has joined #RubyOnRails
[13:43:22] gambl0r3: has joined #RubyOnRails
[14:18:18] bijan_: has joined #RubyOnRails
[14:24:39] gambl0r3: has joined #RubyOnRails
[14:31:46] andywww: has joined #RubyOnRails
[14:33:51] andywww: I’m having a bit of an issue with representations coming from rails/active_storage/representations after deploying a new release with capistrano
[14:34:42] andywww: but i can’t seem to find the directory structure in the app that I need to link with cap
[14:34:56] andywww: am i missing something obvious?
[14:36:13] sphalerite: has joined #RubyOnRails
[14:37:39] crankharder: has joined #RubyOnRails
[14:44:24] segy: has joined #RubyOnRails
[14:51:01] andywww: has joined #RubyOnRails
[14:52:23] Technodrome: has joined #RubyOnRails
[15:01:08] v01d4lph4: has joined #RubyOnRails
[15:06:04] Sylario: has joined #RubyOnRails
[15:10:32] sphalerite: has joined #RubyOnRails
[15:12:17] gambl0re: has joined #RubyOnRails
[15:14:27] kidPalooma: has joined #RubyOnRails
[15:21:01] jobewan: has joined #RubyOnRails
[15:29:35] bijan_: has joined #RubyOnRails
[15:30:15] kidPalooma: Hello, I'm trying to override a class which is declared within a module in a gem in one of my initializers. When I boot my rails console, the module is not yet defined and I get 'uninitialized constant'. I am requiring the gem in my initializer and base modules are defined but this one is nested and I can't seem to get it to work. How do I make sure that the module has been loaded before I run my initializer's code?
[15:41:10] conta: has joined #RubyOnRails
[15:43:14] conta: has joined #RubyOnRails
[15:43:31] tdy2: has joined #RubyOnRails
[16:09:19] conta: has joined #RubyOnRails
[16:13:34] bruul: has joined #RubyOnRails
[16:20:19] crankharder: has joined #RubyOnRails
[16:33:23] conta: has joined #RubyOnRails
[16:40:28] GodFather: has joined #RubyOnRails
[16:43:41] conta: has joined #RubyOnRails
[16:45:40] segy: has joined #RubyOnRails
[17:00:36] Saukk: has joined #RubyOnRails
[17:15:55] quazimodo: has joined #RubyOnRails
[17:25:50] defsdoor: has joined #RubyOnRails
[17:27:20] [Butch]: has joined #RubyOnRails
[17:35:30] szulak_: has joined #RubyOnRails
[17:46:11] mikecmpbll: has joined #RubyOnRails
[17:51:24] Technodrome: has joined #RubyOnRails
[17:51:40] ravenous_: has joined #RubyOnRails
[17:52:18] bruul: has joined #RubyOnRails
[17:53:22] ravenous_: has joined #RubyOnRails
[17:54:28] ravenous_: has joined #RubyOnRails
[17:55:30] sameerynho: has joined #RubyOnRails
[17:58:30] ravenous_: has joined #RubyOnRails
[18:00:18] sagax: has joined #RubyOnRails
[18:02:20] bijan_: has joined #RubyOnRails
[18:09:16] _phaul: has joined #RubyOnRails
[18:09:51] bijan_: has joined #RubyOnRails
[18:09:52] conta: has joined #RubyOnRails
[18:13:06] v01d4lph4: has joined #RubyOnRails
[18:23:32] bijan_: has joined #RubyOnRails
[18:35:55] SteenJobs: has joined #RubyOnRails
[18:38:16] agent_white: has joined #RubyOnRails
[18:39:36] bijan_: has joined #RubyOnRails
[18:48:08] bijan_: has joined #RubyOnRails
[18:50:07] ravenous_: has joined #RubyOnRails
[18:50:59] Technodrome: has joined #RubyOnRails
[18:57:20] Net: does anyone know of a definitive guide to auto-[re]loading lib/ in Rails 5?
[19:04:38] tdy2: has joined #RubyOnRails
[19:15:18] SteenJobs: has joined #RubyOnRails
[19:42:18] conta: has joined #RubyOnRails
[19:47:08] ivanskie: has joined #RubyOnRails
[20:08:26] cnsvc: has joined #RubyOnRails
[20:32:54] ravenous_: has joined #RubyOnRails
[20:32:54] dviola: has joined #RubyOnRails
[20:35:05] ivanskie: has joined #RubyOnRails
[21:07:44] wethu: has joined #RubyOnRails
[21:12:18] gambl0re: has joined #RubyOnRails
[21:12:56] jobewan: has joined #RubyOnRails
[21:19:23] bruul: has joined #RubyOnRails
[21:19:49] Fernando-Basso: has joined #RubyOnRails
[21:25:30] lunarkitty: Is it a bad idea to use sprockets and webpacker together?
[21:25:53] lunarkitty: I'm wondering if I should move everything over to webpacker on this new project
[21:33:18] Radar: GOOD MORNING
[21:33:23] Radar: lunarkitty: webpacker is the future
[21:33:36] Radar: Net: Step 1. Don't.
[21:33:44] Radar: thank you that will be $400
[21:34:47] Radar: (but more seriously: you can add certain directories to config.autoload_paths... but it is usually better to require files as you need them, and that way it's explicit about what's required where. Rails provides "require_dependency" for this sort of thing too -- it will reload things in between requests (iirc))
[21:35:56] Radar: In related news: my juniors are finally learning Rails this week.
[21:38:04] tdy2: has joined #RubyOnRails
[21:42:39] v01d4lph4: has joined #RubyOnRails
[21:48:09] conta: has joined #RubyOnRails
[21:50:02] hahuang65: has joined #RubyOnRails
[21:51:41] wethu: has joined #RubyOnRails
[21:51:50] jaddison: has joined #RubyOnRails
[21:55:29] wethu: has joined #RubyOnRails
[21:58:46] _aeris_: has joined #RubyOnRails
[22:09:44] w0rd-driven: has joined #RubyOnRails
[22:14:59] gambl0re: has joined #RubyOnRails
[22:33:01] kvda: has joined #RubyOnRails
[22:48:44] SteenJobs: has joined #RubyOnRails
[22:49:36] ellcs: has joined #RubyOnRails
[23:01:17] Net: Radar: Why do you consider it better to be explicit with loading?
[23:02:33] Net: I wonder why it's not documented that require_dependency sets up reloading
[23:03:02] Radar: Net: Because autoloading has caused me a lot of pain in the past. It will load things that I do not expect it to load. Whereas I can intuit the behaviour of "require", I cannot intuit the behaviour of autoloading because a lot of how it loads things is hidden from me.
[23:03:23] Radar: With "require" I know that there is a $LOAD_PATH. I guess with autoloading there is autoload_paths, but it still isn't as clear to me.
[23:03:39] Radar: Maybe recent React experience has tainted me where everything _must_ be imported at the top of a file ion order to be used.
[23:04:40] Net: Radar: pain from constant resolution or something more?
[23:05:32] Net: I'm almost always in favor of explcitness, but I'm inexperienced with Rails autoloading and don't know problems
[23:05:48] Radar: Net: pain from incorrect constants being loaded. Most recently: we had a module in `lib/authorization.rb` called Authorization, but we also had a model with the same name (unknowingly). Autoloading loaded the model _first_ because app/models is higher up the autoload_paths than `lib` was, and so our module and its related code was never used.
[23:05:58] Net: I'd expect your love for Elixir would've biased you towards of eager loading
[23:06:31] Radar: However, if we were _explicit_ about doing "require 'authorization'" we would've had this module loaded, and it would've conflicted with the model -- because the model is a class, and not a module -- so we wouldn't have had the exact same problems.
[23:06:35] Technodrome: has joined #RubyOnRails
[23:06:37] Net: I can see that. Seems like a major flaw in Ruby's constant resolution.
[23:06:54] Radar: autoloading is one of ruby's worst features in terms of POLS. It is constantly surprising to me.
[23:06:56] Net: String::Array => Array is terrible
[23:07:03] Radar: And then Rails complicates it by DEFINING A FUCKING MODULE automatically.
[23:07:16] Net: what do you mean by that?
[23:07:23] Radar: https://github.com/rails/rails/blob/master/activesupport/lib/active_support/dependencies.rb#L459-L467
[23:07:30] Radar: Rails autoloading will define modules if it cannot find them.
[23:08:01] Net: what have I gotten myself into
[23:08:16] Radar: that log line on 463 is new. I guess there is some sort of autoloading logging now in Rails master
[23:08:20] Radar: about god damned time
[23:09:06] Net: in practical terms, does require_dependency just require + set up reloading?
[23:09:24] Radar: This most recent autoloading bug with Authorization took down production for us. It could've been prevented if we weren't relying on autoloading to load constants for us, and instead required things that we needed.
[23:09:46] Radar: Net: I think require_dependency does something to track that the file / constants defined by it need to be reloaded on requests.
[23:10:29] Net: What do you think about storing domain logic that doesn't fit nicely into the default Rails categories in lib/?
[23:10:33] Radar: https://github.com/rails/rails/blob/7d7372c14df4ad5b546f012a82538753c5991905/activesupport/lib/active_support/dependencies.rb#L237-L253
[23:10:47] Radar: I think that is fine to do
[23:10:53] Net: even logic that depends on app/?
[23:11:37] Radar: Well, depends on what the logic does. In Exploding Rails (leanpub.com/exploding_rails) I advocate for classes outside of regular MVC, but I put them under app/ because they're a part of the application and depend on other pieces from that .
[23:11:52] Radar: `lib` just is treated like a dumping ground so often
[23:12:04] Net: where in app?
[23:12:15] Radar: app/transactions, app/repositories, app/schemas,
[23:12:26] Net: FooTransaction or Transaction::Foo?
[23:12:36] Net: s/Transaction/Transactions/
[23:12:46] Radar: app/transactions/projects/create.rb, where the constant defined is Projects::Create
[23:12:56] Net: is rails happy with that?
[23:13:02] Radar: For the same reason it's "Project" and not "Models::Project"
[23:13:26] Radar: app directories are added to the autoload path. so projects/create.rb matches Projects::Create
[23:13:52] Net: I think I'd prefer lib/transactions/ so I'm not mixing design pattern grouping and semantic grouping
[23:14:01] Net: as in models, controllers, etc, are design pattern groups
[23:14:18] Net: unless transactions are the same
[23:14:26] Radar: Yes, they are a design pattern
[23:14:52] Net: what about lib/users/, lib/companies/, etc/
[23:14:58] Radar: I use dry-transaction there. All the logic for "transactions" in my application lives in app/transactions, and I can call that from wherever I wish. Controllers then primarily deal with requests/responses
[23:15:04] Radar: What would go under lib/users?
[23:15:19] Net: modules and classes related to the handling of users
[23:15:38] Radar: Thinking similar to how Phoenix structures its projects?
[23:16:07] Net: though personally not a fan of phoenix dictating and naming that pattern
[23:16:19] Net: too rails-y :)
[23:16:24] Radar: Yeah I can see the benefits of doing that. I think it falls apart in a Rails application slightly ... because of the Active Record pattern. There is no real clear separation between structs and database queries.
[23:16:57] Net: Is it expected that most domain entities will be models, regardless of persistance?
[23:17:10] Radar: In my most recent Rails (side) project, I've been using the repo pattern with rom-rb and it's working out really nice.
[23:17:20] Net: looks lovely
[23:17:22] Radar: Net: Yeah, most of the domain entities represent some form of data or another from a database
[23:17:52] Radar: well, even in rom-rb
[23:18:16] Radar: AR does it too. But then it makes it easy to call out to the database whenever you want. N+1 happens in the view way too easily that way.
[23:18:33] Radar: But with rom-rb and separate structs that are actually not capable of making such database queries... well, the amount of footguns goes down
[23:19:10] Net: I like that
[23:19:19] Net: So, you categorize all files by behaviour?
[23:19:24] Net: (not specifically with rom-rb)
[23:19:57] Radar: Typically categorise them in terms of domain entity, but put them in directories corresponding to their ... function? app/transactions/projects/create.rb
[23:20:04] Radar: It's a transaction for creating projects.
[23:20:18] Net: That seems limiting to me. Do you encounter cases where you're not sure what directory a file should belong in?
[23:20:22] Radar: I think the directory path gets more specific left to right
[23:21:06] Radar: Not yet. I usually try out a few places and see what fits. If I can't decide I create a new directory. I don't have to live only within the bounds of what Rails provides. But still typically under app because everything else is there too.
[23:21:31] Radar: What I'd put under `lib` would probably be things that are pure-r Ruby, maybe they talk to HTTP endpoints to get back data. Or maybe 3rd party thigns.
[23:21:42] Net: For example, let's say you need to write some classes/modules to parse and write Excel files. Where would you put them?
[23:22:28] Net: What if (for some unimaginable reason) they need to rely on app models or transactions or repositories
[23:22:50] Radar: They typically don't though. app/transactions code depends on them
[23:23:28] Radar: The things then passed into the ExcelParser come from the models. ExcelParser wouldn't know how to fetch those things itself.
[23:25:29] Net: What if you had an Excel file model that you wanted to use to represent Excel files after they're parsed and before their written?
[23:25:58] Radar: I'd be tempted to put it into app/models, because it is a model of some data.
[23:26:04] Radar: even if it isn't a traditional model
[23:26:12] Net: in app/models/excel_file.rb?
[23:26:14] Radar: sorry, traditional _Rails_ model
[23:26:20] Radar: yeah, something like that
[23:26:34] Net: or app/models/excel_file/parser.rb ?
[23:26:34] Radar: It's a class that encapsulates business logic of a particular data struct. So probably app/models.
[23:26:52] Radar: The parser isn't a model. It acts on models. It would go into lib/excel_file/parser.rb.
[23:26:58] Radar: I know, it's not consistent.
[23:27:38] Net: How does the parsed data become an instance of ExcelFile?
[23:28:32] Radar: Guessing the file is uploaded somehow. I might wrap that logic in a Transaction class. It accepts a file, then passes that file to ExcelFile::Parser, which returns a Hash of the data. That Hash then gets passed to ExcelFile to get turned into a proper object.
[23:29:23] Net: Do you think that's better than the parser constructing the ExcelFile directly?
[23:30:05] Net: I hope I'm not wasting too much of your time. This is extremely helpful for me :)
[23:30:11] Radar: You could argue either way. I can see the merits of either returning a Hash or an ExcelFile object.
[23:30:31] tdy2: has joined #RubyOnRails
[23:30:54] Net: When you said "I think it falls apart in a Rails application slightly ... because of the Active Record pattern. There is no real clear separation between structs and database queries.", what did you mean?
[23:30:58] Radar: ACTION agonises over returning hash or object
[23:31:22] Net: what structs and database queries were you referring to?
[23:31:43] Radar: same as I said previously: traditional rails models combine database querying, business / domain logic all within the same class. Your business logic can either intentionally or unintentionally make further database queries. This is the #1 reason of degraded performance in every Rails app I have worked on.
[23:32:07] Radar: By making "accidental" database queries harder by making the classes simply represent the data + business logic, you can prevent this sort of problem from occurring.
[23:32:46] Radar: Structs == simple classes representing data returned from a repository. In the repository pattern there's one extra layer between the model + the DB and it makes _all_ the difference. The same pattern Ecto follows. You probably know it already.
[23:37:37] Net: I'm imagining a pattern where models handle DB queries and simple data holding, but where most buisness logic has been moved out of the models to other classes or modules that reside in lib/
[23:40:37] Net: So the models are simple value-holding entity representations—usually tied to a db table—which are acted upon by more conventional logic outside of rails patterns.
[23:40:38] Radar: yeah, business logic can be moved to different classes other than the model :)
[23:40:55] Net: Like how you wouldn't build your buisness logic inside the String class.
[23:41:06] Radar: Wellllllll\
[23:41:25] Radar: I'd usually have classes that act on strings
[23:42:18] Net: I'd like to treat app/ and certain patterns in it as building blocks for more conventional, less pattern-oriented code.
[23:42:54] Net: It's rare to find people who think this is a good idea, which makes me think it's not.
[23:43:24] Radar: maybe they haven't caught up with our genius yet? ;)
[23:44:11] Net: sometimes feels that way, but it's less arogant to believe I'm just not in the Rails mindset
[23:44:34] Radar: I think it's okay to break out of it.
[23:44:43] Radar: I argue for doing that here: https://www.youtube.com/watch?v=04Kq_9scT1E
[23:45:08] Net: Thanks, I'll watch it later :D
[23:47:21] blackmesa: has joined #RubyOnRails
[23:54:35] armyriad: has joined #RubyOnRails
[23:58:42] cnsvc_: has joined #RubyOnRails
[23:59:06] spectra: has joined #RubyOnRails