Ruby on Rails Love-In

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Ruby on Rails Love-In

Sivart13: May 18, 2003; I have neglected to come up with a clever title

k-selectride posted:

My question is how to craft the update_rank method? I don't think it's possible to do that kind of thing with just a single SQL query. Is there a way to avoid loading every Post instance into memory and updating them individually? Alternatively, I would be open to another method for time-decaying of rank.

I might be wrong, but I feel like this hand-baked SQL would be pretty close (I have not tested it on anything)

code:

ActiveRecord::Base.connection.execute(<<-SQL
  UPDATE posts
  SET rank = rank * exp(-1 * ( (#{Time.now} - created_at) / #{tau} ) )
SQL
)

(you may have to do some other little dance to ensure Time.now and created_at are in compatible units so that subtraction and division would actually work)

... in PostgreSQL, anyway, which has a native 'exp' function. I don't know a lot about sqlite.

Sivart13 fucked around with this message at 19:28 on Apr 9, 2012

# ¿ Apr 9, 2012 19:26

Adbot: ADBOT LOVES YOU

# ¿ Apr 29, 2024 08:53

Sivart13: May 18, 2003; I have neglected to come up with a clever title

kayakyakr posted:

Controller specs have been abandoned like the red-headed stepchildren they are. Better off writing an integration test with capybara and poltergeist or webkit-headless.

I write a ton of tests at work, and I don't think that's true at all. Controller tests still work fine in Rails 5, you just need the rails-controller-testing gem if you want to test the instance variables assigned by the controller.

Capybara tests are great, but they're slow as hell and run into all sorts of async issues that can make your suite flaketastic in a hurry.

A good test suite has coverage at EVERY level, with high-level acceptance tests covering the a subset of all paths while lower-level service and unit tests handle the edge cases. See http://martinfowler.com/bliki/TestPyramid.html for more words on the topic I generally agree with.

# ¿ Aug 22, 2016 07:35

Sivart13: May 18, 2003; I have neglected to come up with a clever title

Hey Rails thread, first time long time.

For any of you out there who've tried to upgrade an existing app to Rails 5 you may have noticed the need to change test code like

code:

get :users, search: 'staraptor', format: :json
expect(response).to be_success

code:

get :users, params: { search: 'staraptor' }, format: :json
expect(response).to be_success

in all your tests. Since that can be a real pain in the rear end, I wrote a tool called rails5-spec-converter to do it for you.

I'd really love it if any of y'all tried it out on your next upgrade, or told any Rails5-upgrading friends about it. Hopefully the amount of time it might eventually save will exceed the time I spent writing it

# ¿ Aug 22, 2016 07:53

Sivart13: May 18, 2003; I have neglected to come up with a clever title

Does your element show up in the full list of elements retrieved by

code:

all("input[type='checkbox']")

?

"all" is immediate, so if your checkbox is created via JavaScript, it might not be in the initial content retrieved by "all".

If you use "find" instead, like

code:

find("input[type='checkbox'][data-dfID]")

it will do an implicit wait for 2-5 seconds, polling the page to see if that thing exists.

Otherwise there maybe is some quirk between Capybara vs jQuery's interpretation of the selectors. Worst case, you should always be able to get the full list of checkbox nodes from "all" and filter them in Ruby for the ones with the right data attribute.

# ¿ Sep 16, 2016 20:47

Sivart13: May 18, 2003; I have neglected to come up with a clever title

KoRMaK posted:

Yea, well I think they both exist: The Rails Way is layered on top of the Ruby Way. I like both of them very much. Why are they bad?

I would take any of these 'Rails is over' sort of opinions with some salt.

Rails is still very popular and used to make a lot of popular websites. Just because some people are writing their backends in Go doesn't mean everyone is.

It's hard to get a picture of how popular anything is in the Grand Scheme of Things, I think we all have our little windows into the world. But my experience tells me even if something is no longer the Most Popular Thing, it may still have a very long tail.

xtal posted:

Ruby is cool for ad-hoc tasks but if you're investing enough in this to learn a language don't make it Ruby. You might as well start with PHP.

Ruby is a great beginner language. C and the like are fine if you're a comp sci person but it's 2016 over here, I'm not gonna malloc an array or whatever unless I have to.

Waroduce posted:

It would be really cool to get into programming but I'm 27 and maybe too old?

Maybe in a decade you might be too old to get into programming
Talented Junior devs in SF can start at $100k+ out of a bootcamp but this place is a crazy bubble and they really aren't worth that much to the business at the time
Programming is cool and it's cool to use it to solve problems. It's especially good to use them to solve mundane business annoyances like the thing you're talking about, though so far I haven't managed to make heads or tails of what you're trying to do from your description.

# ¿ Dec 7, 2016 06:56

Sivart13: May 18, 2003; I have neglected to come up with a clever title

Stupid question: why are they two separate projects? This kind of stuff is easier when everything is smooshed together, though there are understandable reasons not to.

How does the frontend project work exactly? Does it access the JSON API in JavaScript-land or server side? Is it mostly a JavaScript SPA or a bunch of different Rails views? Does it keep state on the server?

What I've done recently is:
* Write Capybara tests where the 'main' server is the backend one (so I can load data in it using factories, because I like factories)
* The Capybara tests have a global `before(:suite)` which spawns the frontend server (in such a way that it knows how to talk to the backend server that Capybara just spun up automatically)
* The Capybara frontend server URL is set to something that hits the frontend server, so `visit '/'` loads data from that server

The challenges here are
* Getting Capybara to load the backend rails app, if you don't want to put these tests in the backend repo
* Starting your frontend server and making sure it dies with the testrunner process whether the tests finish successfully or not
* Being able to configure your frontend server on boot to hit a custom backend endpoint URL

Though when I did this, the 'frontend server' was just a development server written in Node that served a static React app, so there may be more or different challenges with what you're doing

I haven't seen many gems that help with this problem, other than specialized solutions like `ember-cli-rails` (for Ember apps with a Rails backend) which help you write Capybara tests that spin up a frontend and backend server automatically.

# ¿ Jun 5, 2017 01:47

Sivart13: May 18, 2003; I have neglected to come up with a clever title

CI should do whatever gets the DB up fastest while still somewhat resembling reality. Typically a `schema:load` is faster than running all the migrations, so I would normally do that.

Running the migrations might get you a little test coverage for the migration files, but the only thing that will ever give you real confidence that the migrations work is running them against production data.

If you were using the same database everywhere, I'd say you don't have much to worry about with schema.rb. But since you're split between sqlite and oracle, there are legit concerns. Using the `schema.rb` workflow will only really work if you're strictly using stuff that's supported by both DBs

Some examples of things that might not work
* Configuration statements for your DB (like 'CREATE EXTENSION' in postgresql) might not be dumped into the schema file
* Foreign keys (not supported by SQLite, `add_foreign_key` will run but isn't dumped into the schema file)

The best practice is to use the same DB in test that you use in production, for a lot of reasons, but I understand this is probably easier with MySQL and PostgreSQL than Oracle.

Individual migration files shouldn't live in the code forever because they're just cruft that you'll have to ignore in your searching and linting tools.
The practice I've been following is to squish all migrations once a year or so into the initial migration file. There's a gem that does this: https://github.com/jalkoby/squasher
But if everyone typically loads the DB from schema, I guess it doesn't matter if you just outright delete the migrations you think never need to run again.

# ¿ Oct 5, 2017 02:56

Sivart13: May 18, 2003; I have neglected to come up with a clever title

xtal posted:

This is correct, so you should tackle those low-hanging fruit first if they are applicable. Once the code is perfect, there is still the problem that each and every Rails app eventually has a slow test suite.

There's slow, and there's slow.

Teams can still be very productive working on an app with integration tests that take hours to run single-threadedly, as long as they can run the whole suite fast in a parallel environment like CircleCI.

Depending on the size of the app, nobody's /models/ folder should take hours to run locally. My wild-rear end guess regarding the stated "3-5 seconds" figure is that every test is blowing away the whole DB and building a shitload of fixture data. For reference, a given test in the app I work on takes ~300ms even though it creates 10+ records.

Ideally a model test that touches the database should make as few database records as possible to exhibit the model behavior. Two paradigms I've seen are:
* The database starts out empty, and the test makes whatever it needs via factories
* The database starts out full of fixture data, and tests run in a transaction so they can bring it back to the normal state between tests

My guess is that your app is doing both, starting from zero and adding a ton of predefined "fixture" records that are slow to create.

You could try running something like this after the last assertion in a test to see if a lot of stray data is lying around:

code:

ActiveRecord::Base.descendants.each do |sc|
  if (sc.try(:all).try(:size) rescue nil || 0) > 0
    puts "#{sc.name}: #{sc.all.size}"
  end
end

# ¿ May 5, 2018 01:55

Sivart13: May 18, 2003; I have neglected to come up with a clever title

necrotic posted:

I'm in favor of flattening after some time period but everyone I've worked with is against it.

I've never worked on a code bases where migrate from zero works.

You are correct and you should hold this fact over your co-workers (and I've worked on tons of apps where migrate from zero works)

Migrations only need to live until they've run on most extant system with data (staging, production, developer machines), after that they only exist to gunk up your IDE's search index. Toast 'em.

The only reason you MIGHT want to keep them around longer is if your app was deployed on a lot of systems you didn't control, like on-premise in many client's own infrastructure. Then you might have to support an upgrade path from tons of prior versions.

Otherwise, if you really needed to run a very old migration you can find them in git.

Sivart13 fucked around with this message at 03:51 on Jun 7, 2018

# ¿ Jun 7, 2018 02:38

Sivart13: May 18, 2003; I have neglected to come up with a clever title

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.

Taking a minute to run a single spec is definitely a JRuby-specific issue (or some other global test setup that ought to be worked through) and the main thing that made me want to stop using JRuby on a previous project.

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: May 18, 2003; I have neglected to come up with a clever title

The Journey Fraternity posted:

Which puts our massive codebase completely out of any support.

God I need a new job.

you don't want your job to be upgrading the massive codebase to Rails 6?

what kind of job is this that has all the rails but not wants to upgrade it

# ¿ Aug 19, 2019 04:53

Sivart13: May 18, 2003; I have neglected to come up with a clever title

Jaded Burnout posted:

There's not much of an IDE culture with Ruby, it's mostly just text editors with convenience plugins.

That probably depends on who you work with, I and most of my coworkers have used RubyMine for many years. If you can stomach paying money for software it has a lot of features that are really helpful.

# ¿ Sep 14, 2020 17:41

Sivart13: May 18, 2003; I have neglected to come up with a clever title

I've been using Rails on the backend for the last 10 years and would prefer to keep doing it. But it is somewhat limiting in that most similar webdev jobs seem to have node backends these days for some godawful reason.

I don't think it merits deleting from your resume though?

# ¿ Oct 7, 2023 17:12

Adbot: ADBOT LOVES YOU

# ¿ Apr 29, 2024 08:53

Sivart13: May 18, 2003; I have neglected to come up with a clever title

I'm just now leaving a 6 year stretch in pure Rails server side development for a JS/TS job.

I've avoided learning any of the Hotwire stuff because we only had a very limited amount of interactivity required and it was doable with JS/jQuery stuff.

When I look at descriptions of Hotwire technologies, it makes sense to a point, but "turbo streams" are they start to lose me and then stimulus is a Whole Thing.

The Stimulus example on that page looks nasty in that you gotta learn a whole funky grammar that wouldn't translate to any other framework. Maybe there are advantages over Doing A React, but I would have to see a more complicated example to know how far it can be pushed with this syntax.

They say it's only for "interactions that are relatively small" -- I presume you couldn't use Stimulus to implement something like a drag-drop list that persisted back to the server on every drop?

# ¿ Nov 19, 2023 06:45

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Ruby on Rails Love-In