Page 1 of 514 | Next »
[21:46:29] Radar: RJ2: I wrote an interface to Elastic Search here using the HTTPotion package: http://github.com/radar/elastic
[21:49:54] Radar: Slogger: Ah rightio. I have an example with Capybara that I could share if you were using that. I dont' know about AD:IT
[21:50:34] Radar: Juniors loved the React + Rails work we did last week. I'm now planning some GraphQL work for them to do next time we catchup (Apr 8th). I think they'll really enjoy all the tooling around that.
[11:04:15] Radar: In the topic it says "this channel is logged", but doesn't say _where_. Is it more a general "some people might be logging this channel"?
[11:07:57] Radar: Nicd-: I happen to run an IRC bot that does logging, which is why I asked :) The bot itself is written in Ruby, but the site where the logs are shown is in Phoenix: http://logs.ryanbigg.com/p/Radar/activity and http://logs.ryanbigg.com/RubyOnRails are two example pages.
[21:04:01] Radar: > Is Elixir/Erlang considered superior to Go for writing high concurrency web servers?
[21:19:22] Radar: I used to use it a bunch to find cheap airfares when I was Spree's community manager
[21:21:50] Radar: sylario: it's okay it is still early morning in some parts of the world. You are forgiven
[23:02:26] Radar: DigitalDarwin: `bundle exec rspec` is the common way to run them. You can use that to target a particular test too: `bundle exec rspec spec/models/user_spec.rb`
[21:08:22] Radar: hahuang65: Then you can probably do a require at the top of ApplicationHelper and then include that module directly into ApplicationHelper
[21:10:40] Radar: Could you possibly have a controller action within your own project which then redirects to the 3rd party URL?
[21:10:52] Radar: then in app helper you could have a rails routing helper which goes to that controller
[21:12:56] Radar: (i.e. it's defined with a self. prefix or you explicitly called module_function before that)
[21:33:05] Radar: srruby: But seriously tho: https://gist.github.com/radar/5b1a913028a23b9610663ea78df3e1c3
[21:33:28] Radar: srruby: describe is used to describe the behaviours of the class / methods. The "#permissions" thing here would be an instance method called permissions
[21:33:45] Radar: srruby: context is used to describe different... situations, contexts? When <something is different>...
[02:19:53] Radar: and I've used hub pull-request in the past to build a new PR off an existing branch
[02:20:08] Radar: and at spree I used `hub am -3` to pull down PRs to my machine frequently to test them out
[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))
[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: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: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:54] Radar: autoloading is one of ruby's worst features in terms of POLS. It is constantly surprising to me.
[23:07:23] Radar: https://github.com/rails/rails/blob/master/activesupport/lib/active_support/dependencies.rb#L459-L467
[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: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:33] Radar: https://github.com/rails/rails/blob/7d7372c14df4ad5b546f012a82538753c5991905/activesupport/lib/active_support/dependencies.rb#L237-L253
[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:12:46] Radar: app/transactions/projects/create.rb, where the constant defined is Projects::Create
[23:13:26] Radar: app directories are added to the autoload path. so projects/create.rb matches Projects::Create
[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: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: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:22] Radar: Net: Yeah, most of the domain entities represent some form of data or another from a database
[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: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: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: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: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: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:30:11] Radar: You could argue either way. I can see the merits of either returning a Hash or an ExcelFile object.
[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:45:58] Radar: naeemarsalan: Can we see some code that will cause this same issue to happen on our machines?
[23:21:54] Radar: yoshie902a: in the past when I have attempted to do this, I have found putting that code inside a view not only reduces the duplication, but also makes it much, much easier to read.
[23:27:09] Radar: the content_tag here doesn't have brackets around its arguments. Ruby is probably having a hard time parsing where the content_tag starts + ends.