|
I'm having an issue writing a controller test. My app uses Knock for handling JWTs, and my test looks something a little like this:code:
code:
I'm aware controller tests are supposed to be deprecated, so is this why it's happening? I can accomplish these tests as a request test instead, though I'm curious as to what I'm doing wrong / what's going on. EDIT: Missed this earlier -- explains a way to force an auth header through pre-request in a controller test: https://github.com/nsarno/knock/issues/174 GeorgieMordor fucked around with this message at 17:53 on Feb 19, 2019 |
# ? Feb 19, 2019 16:25 |
|
|
# ? May 15, 2024 02:32 |
|
GeorgieMordor posted:I'm having an issue writing a controller test. My app uses Knock for handling JWTs, and my test looks something a little like this: Yes, it's happening because it's a controller test. Your link even explains why (controller tests don't include the same "get" helper). You don't seem to be doing anything that requires a controller test? Just use a request test, it'll save you pain in the long run.
|
# ? Feb 19, 2019 18:19 |
|
kayakyakr posted:You don't seem to be doing anything that requires a controller test? Just use a request test, it'll save you pain in the long run. Totally. Request tests should be more than adequate, especially since this is an API app anyway. I was just running through some RSpec refresh and thought I'd give the controller tests a go just for sharpness' sake. Out of curiosity with controller tests being soft deprecated what's an example of some functionality that would merit a controller test these days?
|
# ? Feb 19, 2019 18:59 |
|
GeorgieMordor posted:Totally. Request tests should be more than adequate, especially since this is an API app anyway. I was just running through some RSpec refresh and thought I'd give the controller tests a go just for sharpness' sake. Historically controller tests were used to ensure that certain instance variables were set in the controller before rendering any sort of views and it made it easier to retrieve values that were created/updated. Multi-mode servers have gone out of favor and feature and request specs cover the use cases better most of the time.
|
# ? Feb 20, 2019 00:52 |
|
I made a models graph of our monolith with railroady and the resulting image is 1.7ft by 224ft large.
|
# ? Feb 22, 2019 21:16 |
|
Pollyanna posted:I made a models graph of our monolith with railroady and the resulting image is 1.7ft by 224ft large. Hello do you work for Shopify
|
# ? Feb 25, 2019 08:01 |
|
Nope, we just do dumb poo poo like autogenerate classes for a variety of types X namespaces. poo poo that shouldn’t be modeled via OOP, or at least inheritance. The codebase is very much Baby’s First OOP Project in certain ways. Our specs take 15~20 minutes to run when split across 24 Docker containers running in parallel. I have since come to the conclusion that our slow, lovely specs are a symptom and not a cause. That reminds me to ask: what tack should I take in trying to refactor heavy interdependencies between AR-backed models? Our specs are slow because we have a lot of models that depend on long chains of associated models existing in the database in order to be valid, do work, etc. For example, an Ad requires a Campaign to exist in the database, a Campaign requires a Customer, a Customer requires an Advertiser, etc. This is a common pattern throughout our entire codebase, and that means an individual model needs to write its whole line to the DB to be testable. I have no idea how to fix this short of rearchitecting the app from scratch. Pollyanna fucked around with this message at 18:21 on Feb 25, 2019 |
# ? Feb 25, 2019 17:45 |
|
That sounds strikingly similar to an ad platform I worked on a couple years ago.
|
# ? Feb 25, 2019 18:44 |
|
I wouldn’t be surprised if it’s pretty common among big companies.
|
# ? Feb 25, 2019 23:46 |
|
Pollyanna posted:That reminds me to ask: what tack should I take in trying to refactor heavy interdependencies between AR-backed models? Our specs are slow because we have a lot of models that depend on long chains of associated models existing in the database in order to be valid, do work, etc. For example, an Ad requires a Campaign to exist in the database, a Campaign requires a Customer, a Customer requires an Advertiser, etc. This is a common pattern throughout our entire codebase, and that means an individual model needs to write its whole line to the DB to be testable. I have no idea how to fix this short of rearchitecting the app from scratch. 0. Ensure you have the proper indices set up on the foreign keys (SQL EXPLAIN) 1. Eager load that long chain of dependencies with one query with something like `Ad.includes(campaign: { customer: :advertiser }).find(id)` 2. Use an in-memory database or disable fsync with eatmydata I don't think that having a lot of foreign keys and stuff is inherently a design problem; in fact, it's often either a choice between having a long chain of dependencies, or having one table with a long list of messy, unrelated columns. When you use joins and eager loading properly, the performance is nearly the same, but the design is far cleaner. xtal fucked around with this message at 00:22 on Feb 26, 2019 |
# ? Feb 26, 2019 00:18 |
|
It’s actually more that it can take up to 1.25 seconds to instantiate and persist a single valid model from a factory in some cases, most notably the models used in our 10-minute feature test. Retrieving associated records is a whole different ballgame that is itself a loving trash fire, but for different reasons than a simple it { is_expected.to validate_presence_of :advertiser } taking .5~1 seconds.
|
# ? Feb 26, 2019 15:22 |
|
I would try and measure how much time is spent in CPU versus IO. If you're writing your validations and callbacks using fast algorithms and no IO (which is recommended) then you would need hundreds and hundreds of validations to get that slow. So, I think you either have a quadratic algorithm in there somewhere, which you can find using profiling tools; or, you're doing IO such as DB or HTTP, which you should remove from the model and move to a higher level of abstraction. Installing the Bullet gem might help too. If you have a lot of one-to-many relationships, and aren't careful with your preloading, you will get n+1 queries, which are a huge performance killer for Rails apps.
|
# ? Feb 26, 2019 17:53 |
|
What do folks use for serialization these days?
|
# ? Mar 6, 2019 01:55 |
|
GeorgieMordor posted:What do folks use for serialization these days? If you're following json:api, https://github.com/Netflix/fast_jsonapi
|
# ? Mar 6, 2019 04:22 |
|
Fastest freeform I've worked with was Grape::Entity. Was using it in a normal rails API app, not with Grape.
|
# ? Mar 6, 2019 16:54 |
|
I have been working on developing my internal toolset in ruby and rails, and have been slowly improving with my techniques, built my own internal gem for some modules, etc Is the general opinion on this that I should be doing this in python instead at this point? Is Ruby falling apart into decay? Python immediately turned me off by being column/space dependent giving me COBOL flashbacks, was really hoping not to have to deal with that poo poo or line terminators ever again.
|
# ? Apr 25, 2019 13:35 |
|
Partycat posted:I have been working on developing my internal toolset in ruby and rails, and have been slowly improving with my techniques, built my own internal gem for some modules, etc No, it’s fine. Ruby’s not going anywhere. They just previewed some upcoming features in Ruby 3 that sound quite neat, too. If you want to do a different language, try something with a very different paradigm. Expand your mind a bit. Like, say, clojure, or perhaps an Elm frontend for your rails app. Vastly different languages like that actually complement each other better in your brain, in my experience. Seeing other ways of doing things is going to make you a better programmer. Going from Ruby to Python is just going to make you focus on piddly poo poo like indentation. The fact that you’re even asking the question suggests that you’re not going to be applying for any jobs where they’d expect you to have really deep, specialized knowledge about a particular language. So get some breadth.
|
# ? Apr 25, 2019 15:03 |
|
So, I'm confused. In Rails 5, where do best practices dictate I should be testing for a cookie being set? I have a method in my ApplicationController that sets a cookie, and I want to make sure this is working correctly in my spec.
|
# ? May 7, 2019 17:33 |
|
GeorgieMordor posted:So, I'm confused. Just to make sure, you're talking about an extra cookie, separate from the session cookie? You could do a features spec, and do the full stack request and then look at the `response_headers` to see the Set-Cookie header. Probably, I haven't done that specifically, but I have that to ensure some CSP headers are set, so it's probably similar.
|
# ? May 7, 2019 17:40 |
|
GeorgieMordor posted:So, I'm confused. This has always kinda felt like a code smell/antipattern type thing, but I have used this gem in the past and it's worked out. https://github.com/nruth/show_me_the_cookies
|
# ? May 7, 2019 17:46 |
|
Pardot posted:Just to make sure, you're talking about an extra cookie, separate from the session cookie? Yep, this is a separate cookie from the session one. Good call sniffing the response headers. I did it that way, and then ran an include? method on the Set-Cookie string that returns and find the expected value in there. The Milkman posted:This has always kinda felt like a code smell/antipattern type thing, but I have used this gem in the past and it's worked out. I saw this too, and share the smell sentiment but this honestly didn't seem like a bad route either.
|
# ? May 7, 2019 18:02 |
|
So, how do you access a global app variable in a feature test? For instance I'm setting something myself in my ApplicationController, and want to make sure it's being set correctly. Previously I was using the assigns() method , but that's for the apparently dare-not-speak-their-name controller tests. In general and at least for me, with the deprecation of controller tests, I'm finding it tricky to find best patterns / practices recommendations for replacing stuff.
|
# ? May 7, 2019 18:16 |
|
I hope this is a simple question to answer, but I can't quite find it elsewhere. I have an index page with some filter params. There's a link on the page to download a csv version of the page, so the controller looks roughly like this: code:
code:
Changing the link like so, <%= link_to(items_path(format: 'csv', filters: params[:filters]) %> leads to unable to convert unpermitted parameters to hash.
|
# ? May 13, 2019 21:54 |
|
Sounds like an issue with Strong Parameters: you need to permit(:filters) before you can use it (and probably a permit! on that to allow everything under that key).
|
# ? May 13, 2019 22:05 |
|
I’m trying to set up a relationship from a record to records it isn’t associated with. Imagine the following:code:
code:
Tea Bone fucked around with this message at 13:20 on May 15, 2019 |
# ? May 15, 2019 13:18 |
|
Tea Bone posted:I’m trying to set up a relationship from a record to records it isn’t associated with. Imagine the following: code:
code:
If you're looking to fill out a list of books on each reader's non-books array, well, I think that the N+1 may be the best you can get because rails has to break that down to apply it to the object anyway.
|
# ? May 15, 2019 17:44 |
|
If you're using postgres, you probably don’t want `not in` due to some caveats about nulls. Instead do the antijoin with `left join` and an `is null` or (and I prefer) `not exists` https://explainextended.com/2009/09/16/not-in-vs-not-exists-vs-left-join-is-null-postgresql/
|
# ? May 15, 2019 18:01 |
|
My company has a large Ruby on Rails app that's 6+ years old, but thankfully is relatively up-to-date version wise (currently running on Rails 5). During the initial production, we chose to use JRuby + puma for performance reasons. This works fine in production, but one of the biggest issues our devs have with the codebase is how slow development is. Between JRuby (especially startup time) and poorly written specs, it takes 35-45 minutes to run all our specs. This makes it really annoying to wait for our CI to go green even for very small changes. Despite having no prior experience with Ruby or Rails, I'm working on digging into options to speed up spec time. One of the easiest wins is to switch from JRuby to Ruby MRI. Currently very little of our code actually requires JRuby and the parts that do can easily be updated to not. The benefits seem to be a better supporting Ruby implementation, faster turnaround on bug fixes and new features, and an improved dev process. Is there a reason in 2019 to continue to stick with JRuby? Obviously if I go forward with this, I'd do a gradual rollout (we have our app distributed on multiple servers and scaling up/down is practically trivial) to get performance metrics of our actual app/loads for comparison. I'm just looking for any high-level opinions between the two to decide whether this is worth pursuing further.
|
# ? May 15, 2019 23:59 |
|
As you said, you'll want to check your specific app's performance. The other reason it's used is because it can easily interop with Java libraries and SDKs. If you're not doing that or using JRuby-only gems that you can't replace, it's definitely worth an experiment. MRI 2.6 is definitely quite a bit faster than 1.9.3 was.
|
# ? May 16, 2019 04:16 |
|
Aquarium of Lies posted:My company has a large Ruby on Rails app (currently running on Rails 5)poorly written specs, it takes 35-45 minutes to run all our specs. This makes it really annoying to wait for our CI to go green even for very small changes. This is normal, not great, but normal. We had something like 4 team city agents running around the clock to service 12 engineers on ~200k loc Once your specs get > 4 hours is time to worry or consider breaking up the monolith
|
# ? May 16, 2019 05:42 |
|
Aquarium of Lies posted:My company has a large Ruby on Rails app that's 6+ years old, but thankfully is relatively up-to-date version wise (currently running on Rails 5). During the initial production, we chose to use JRuby + puma for performance reasons. This works fine in production, but one of the biggest issues our devs have with the codebase is how slow development is. Between JRuby (especially startup time) and poorly written specs, it takes 35-45 minutes to run all our specs. This makes it really annoying to wait for our CI to go green even for very small changes. I don't know anything about JRuby, but if you're not already doing it, this gem can parallelize your tests. It's not especially smart about how it divides up the tests between threads/processes, but it does shorten our test runs by quite a bit. I believe Rails or RSpec is supposed to be parallelized by default in a not-too-distant release, too.
|
# ? May 16, 2019 15:52 |
|
Peristalsis posted:I don't know anything about JRuby, but if you're not already doing it, this gem can parallelize your tests. It's not especially smart about how it divides up the tests between threads/processes, but it does shorten our test runs by quite a bit. I believe Rails or RSpec is supposed to be parallelized by default in a not-too-distant release, too. Rails 6 has parallel testing built in which we’re looking forward too Other devs have tried parallelizing in the last without much luck so I’m curious to see if it’ll work better with 6. Hadlock posted:This is normal, not great, but normal. We had something like 4 team city agents running around the clock to service 12 engineers on ~200k loc I’ve heard other people say this but it’s still really annoying to go from my other work projects where I can run a specific test in seconds to Rails, where it’s at least a minute if I want to run a single spec. My workflow isn’t quite TDD but I rely heavily on test feedback as I’m developing features and it is affecting my productivity.
|
# ? May 16, 2019 16:39 |
|
Aquarium of Lies posted:I’ve heard other people say this but it’s still really annoying to go from my other work projects where I can run a specific test in seconds to Rails, where it’s at least a minute if I want to run a single spec. My workflow isn’t quite TDD but I rely heavily on test feedback as I’m developing features and it is affecting my productivity. If you're ambitious you could try hacking up the test suite so it could run in either JRuby or MRI, maybe using an environment variable to work around any interpreter-specific behavior. Could give you that MRI feeling without having to cut hard away from JRuby.
|
# ? May 17, 2019 01:12 |
|
Sivart13 posted:If you're ambitious If you're even more ambitious you could ditch bundler for gel https://github.com/gel-rb/gel
|
# ? May 17, 2019 01:53 |
|
Aquarium of Lies posted:Rails 6 has parallel testing built in which we’re looking forward too Other devs have tried parallelizing in the last without much luck so I’m curious to see if it’ll work better with 6. We've been using this: https://github.com/grosser/parallel_tests with Rspec with great results. We run a Drone instance locally with 4 workers to chew through the test suite.
|
# ? May 17, 2019 15:27 |
|
Rails gurus, I am in a dire need of your help. Could somebody break it down Mickey Mouse style. How the heck can I create a link, something like code:
code:
insert the file_id parameter into the right places (so I can display file_id.pdf file and make it bootstrap collapsible), render it and show it to the user. I have asked my co-workers but they all say わかんないAJAX使ったら? and I am like poo poo, I have been writing ruby for like 2 weeks only. What the hell am I supposed to do? I don't get what AJAX and controllers do either... I have searched for hours now and now I am dying. Please don't ask me to post my controllers or something, I am a mess right now and it's my twelfth hour in the office.
|
# ? May 22, 2019 11:28 |
|
Piano Maniac posted:Rails gurus, I am in a dire need of your help. https://www.rapidtables.com/web/html/link/html-anchor-link.html basically, if you're putting the # in front of the ID on the target, then you're doing it wrong.
|
# ? May 22, 2019 15:15 |
|
That might be part of it, but it sounds like there’s even more logic than core Rails handles.
|
# ? May 22, 2019 15:23 |
|
Thanks for the thoughts & prayers, I managed to solve it with the help of my genius CTO. It was as easy as AJAX!
|
# ? May 23, 2019 09:34 |
|
|
# ? May 15, 2024 02:32 |
|
One of the senior engineers on the team says that some of our service code shouldn’t actually set any default values for a given model (which needs it to build the form), and that the default values for the new model should instead be determined by whatever the form partial defines as the defaults. I really dislike the idea of our views being the ones in charge of default values, but I don’t know if I’m being too dogmatic about it. Am I overly concerned about this?
|
# ? May 30, 2019 21:12 |