|
Related question to Heroku spinning down - how does this work on the Cedar stack? If I have 1 web dyno and 1 worker dyno, is it possible for that web dyno to spin down (i.e. do I need to have at least 2?)
|
#
¿
Apr 13, 2012 13:08
|
|
|
|
| # ¿ May 16, 2024 00:54 |
|
|
Personally, I think the best way to solve stuff like that is add an updated_by to the model in question. It's useful to know who the last person that changed something was without needing to consult a history table, and it makes grabbing the user who changed something in a before_save easy. If you really don't want to add that column to the database, it's still totally possible to add a plain old attr_accessor to a model in Rails and use that for the before_save. Then you'll have the value available in the model but it won't be saved to the DB. Also, I'd probably set up those changes as an association and build them rather than create them in the before_save. Right now that wouldn't work for a new record.
|
|
#
¿
Apr 18, 2012 12:03
|
|
|
I'm saying use changes.build. You're doing it in a before_save filter anyway, so you might as well let Rails handle saving the change models for you. Plus if there was ever a case in the future where a change might be invalid, you could move your change building to a before_validate and let the change validation be dealt with by the parent model. Plus if an excercise model doesn't save for whatever reason (either a bug or an honest-to-god business rule that your change code isn't aware of), you don't have any ghosted change models around that don't represent an actual change. I could be wrong on this, but I think that it might even be transactional if everything is contained within one save. enki42 fucked around with this message at 13:21 on Apr 19, 2012 |
|
#
¿
Apr 19, 2012 13:18
|
|
|
BonzoESC posted:I'd be tempted to invert it and have an ExerciseChange model that then updates the Exercise model as appropriate. From the looks of it it's a polymorphic relationship between changes and whatever, and figuring out a way to represent that RESTfully in controllers that doesn't seem completely crazy is making my head hurt.
|
|
#
¿
Apr 19, 2012 13:19
|
|
|
I'd add on one thing to what Molten Llama said. Once you have your schema.rb in development set, delete all of your migrations, and create a single new migration with the contents of your schema.rb file in the up method. He's right that you shouldn't really need the past migrations going forward, but if you're going to leave your migration folder in a state where it technically can't bring a database up to it's current state, you're asking for trouble - what if a developer does try to create a new DB through migrations and something is left in a broken state (and worse yet, you guys are ping-ponging on schema files since he's missing an important column)? Alternatively, if you don't want to lose your migrations folder, you could have just gone back into git and found the old migration and recreated it - so long as the identifier at the beginning matches, Rails won't re-run the migration (or, if you need to get REALLY fiddly with what you want torun, you can manipulate the contents of the schema_migrations table in your DB)
|
|
#
¿
Sep 19, 2012 12:00
|
|
|
Physical posted:Thanks, that seems to do what I wanted. Found this too https://gist.github.com/762526 I'm sure from your example that this probably isn't a concern, but keep in mind that tap and using aren't really similar outside of the "locally scoped shorthand variable" sense. There's not really a fixed way of dealing with disposal in Ruby (most things generally have some sort of block-like syntax, but it's purely convention), and you shouldn't expect any cleanup or anything short of the variable being descoped when leaving a tap block.
|
|
#
¿
Nov 20, 2012 13:10
|
|
|
Obsurveyor posted:I don't think so. This is the real code using the tip from Physical: This looks like it works and is probably reasonable if you have a limited number of votes, but you should be able to do the following if you still want to pull this from the DB: Ruby code:quote:That's probably faster than hitting the database anyway. Actually, unless there's an include that's being omitted for brevity, it's probably way slower and an N+1 to boot. You're going to make a seperate DB call for each and every vote (to pull the idea). I didn't even notice that when I originally wrote the reply, but you should absolutely fix that at a bare minimum, that's the sort of thing that WILL bite you in the rear end if you're not careful with it. enki42 fucked around with this message at 12:29 on Nov 30, 2012 |
|
#
¿
Nov 30, 2012 00:00
|
|
|
quote:Thanks for this. However, released? is something I had to write. How do I check for null instead of false? nil? To be honest, this is the most I have had to deal with ActiveRecord since I started using ruby. So far, I haven't had any use for a relational db, mongodb has been well suited to everything I have done. I have plenty of legacy PHP stuff that uses relational dbs and needs their functionality, just nothing with ruby so far. Yup, you can just pass :released => nil and it will do the right check. If you have to check false or nil, unfortunately it can get a little gross. You need to either use Arel or the following SQL fragment: code:quote:Yeah, I'm well aware of the ramifications of doing it the way I am. I'll switch it out for the single database call if it becomes an issue. Pre-mature optimization and all. Once I check out how the production database looks, I'll make the call on which one to use. I didn't write this app, and this is not something that is going to be used when users interact with it, so it's not a big deal if it's a little slower but more readable if I have to come back and modify it in the future. Fixing N+1's doesn't count as "premature optimization". At the very least include the associated model when you pull down the votes. There's really no reason that you should ever have one in your code, and it takes really small amounts of records before you start noticing significant slowdowns.
|
|
#
¿
Dec 2, 2012 05:21
|
|
|
raej posted:On a form, is there an easy way to pass values as integers instead of strings? I don't think the problem you're running into has to do with strings vs. numbers. Rails isn't expecting a number, it's expecting a full-fledged Artist object. It looks like your form might be passing in a key named "artist" rather than a key named "artist_id". Could you maybe post what parameters are being passed into the form (from the logs) as well as the relevant portions of the view?
|
|
#
¿
Dec 6, 2012 14:36
|
|
|
Pardot posted:Hoollyyyy poo poo learning rails from having no programming experience is overwhelming. I'm coaching a RailsGirls event today, and I can't believe how many different things you have to know. I'm currently teaching a 3 month course for people who have never programmed before, and holy poo poo yes. Our second class was just an overview of what MVC is and where all the various bits fit in, and I think half of the classes eyes were bleeding at the end. quote:Yeah, which is why somewhat skeptical of the concept. Teaching programming is hard enough already, but when the first thing you show them is a big, complex framework like Rails, it's a lot of things to learn at once. We've taken the approach of mixing together teaching Ruby and Rails. Every class has like an hour of Ruby stuff, just enough to teach what you're going to learn on the rails side, and then dig into it with Rails examples. For instance, for our models class, we'll spend an hour going over classes, methods, variables, symbols, hashes, and arrays, and then applying them in making a model (which you don't really NEED stuff like blocks, looping, even conditionals for the most basic models. Then something like controllers would introduce blocks (to explain respond_to), and conditionals (which you pretty much need in an update method). I find starting 100% with Ruby just gets people frustrated that they're not actually making something useful. Plus if you're just going with pure Ruby, people won't be motivated to experiment with stuff outside of direct exercises you give them. Another good thing we've found is to "reset" the project once in a while, or have a few projects to work on, where you can start off fairly sloppy but get to nice, TDD, well structured code by the end. Our first "project" was 100% scaffolded, where people literally didn't modify code outside of "rails generate". The second wasn't TDDed, and was really basic in structure. The third is going to be fully tested from the start. enki42 fucked around with this message at 00:39 on Jan 27, 2013 |
|
#
¿
Jan 27, 2013 00:36
|
|
|
Lexicon posted:Devil's advocate: Why not base a course off something like projecteuler.net (or equivalent - adjust for your audience's interests)? I find that people are surprisingly intrigued to find out that programming opens up a whole world of problem solving that was previously inaccessible. The short answer is that we've tried this, and ultimately it does end up a bit frustrating for people to not be able to "do anything" with the programming knowledge they've learned over the course of a lesson. I think there's a couple of extremes here - I don't think anyone would argue that you shouldn't dive straight into Rails with absolutely no understanding of Ruby, and also that you don't have to know the language inside and out before you're even allowed to touch Rails. For us, calling out Ruby seperately and introducing concepts a little at a time, and tying them to practical examples has been extremely helpful. quote:It was really awesome that by the end of the day they could share the app with their friends after pushing it live. I was super impressed at how far they were able to get. This is basically the reason that we went with. When we ran pure Ruby workshops, people were excited but a little frustrated that they hadn't really "made" something. When we ran a course that started with something as basic as just scaffolding out a project, people were way more excited, even if they didn't understand everything that was happening. Sinatra is kind of a weird case - on one hand, it's REALLY easy to get something incredibly basic up. On the other hand, once you start to extend that beyond basic applications, you hit a bit of a wall where you need to understand how a lot of stuff works and how to best structure an application. I kind of disagree with the idea that Sinatra is a good tool to teach new programmers beyond the most basic "Hello World" sites.
|
|
#
¿
Jan 28, 2013 17:27
|
|
|
The funny thing about teaching Ruby from a rails concept is that a lot of those assumptions don't really apply though. 1. There isn't an "entry point" for a typical Rails application. I mean, obviously there is, but it's not something that you really need to know about off the bat, and thinking of a Rails app in terms of a normal procedural program can be confusing for newbies. The "main loop" is even more obscured and isn't something any Rails user is likely to encounter pretty much ever (seeing as it isn't even really in Rails per se) 2. You can actually go a long way without loops in Rails, but it does demand that you know some other programming concepts before that. Here's what we do: Models - Learn classes, methods, arrays, hashes, variable scoping Controllers - Learn conditionals, boolean logic Views - Learn loops (to deal with the .each that you're going to have in your index view), talk about blocks a bit.
|
|
#
¿
Jan 28, 2013 18:23
|
|
|
It's apparently Sprockets related, so I guess it depends on how heavily you're using that.
|
|
#
¿
Mar 21, 2013 16:37
|
|
|
This would probably work if you wanted to do that ordering by a scope:code:It sounds like what you're really trying to accomplish is to have the rules for when a person is updated include whether they have had a feed entry created. It might just be simpler to change the person's updated_at when the feed entry is created and avoid all this crazy joining in the first place: code:
|
|
#
¿
Jun 28, 2013 11:49
|
|
|
My general rule for migrations is that unless I'm really interested in maintaining uptime and modifying the app to deal with both scenarios like dexter mentioned, you should always use one migration. Migrations are transactional so by using one you're not going to leave your DB in a weird state where half of the migration is applied if something fails.
|
|
#
¿
Jul 17, 2013 16:54
|
|
|
I thought you were going to be really pedantic and say that sqlite doesn't have transactions. MySql doesn't? Everytime I learn something new about that database, I wonder why anyone ever uses it in the first place.
|
|
#
¿
Jul 17, 2013 21:00
|
|
|
The best possible e-mail regex is:code:
|
|
#
¿
Jul 25, 2013 02:57
|
|
|
DreadCthulhu posted:Very lazy question: does Rails do a detailed logging of SQL queries in production mode, similar to what it looks like in development? Or actually, even better, does Rails log at different levels depending on RAILS_ENV? By default I think production logs at a fairly high level (maybe warn? I could be wrong on this), but you can change your log level by changing config.log_level inside the appropriate environment file (in this case, production.rb). SQL queries would be on the info level, I think. If you're on Heroku, I think you might still need to do some magic to get the Rails logger to log to STDOUT and heroku logs to pick it up.
|
|
#
¿
Sep 7, 2013 15:31
|
|
|
Sub Par posted:I'm building a simple search form and trying to determine if this approach is safe from an SQL injection point of view: Nope, you're good. params[:search] could have SQL injection stuff, but the ? prevents any of it from being treated as executable SQL code.
|
|
#
¿
Sep 10, 2013 11:56
|
|
|
prom candy posted:I'm going to be mentoring at the Ladies Learning Code Ruby event in Toronto this Saturday. Come and say hi if you're there as a mentor or a student, I'll be the white nerdy guy with glasses. And if anyone knows any women who are interested in learning to code you should tell them about this event (or other LLC events) as they're apparently really good! Awesome! I'm mentoring there too. It is a really awesome event, Dessy (the instructor) does an amazing job with the course. I'll try to find you. (white nerdy guy with glasses is a bit of a broad category with LLC mentors..)
|
|
#
¿
Nov 20, 2013 13:12
|
|
|
yoyodyne posted:This partially works, but (1) it doesn't automatically redirect to the login screen, and (2) because of the way some of the ember stuff is set up, only upon clicking certain links does it redirect to the login page. I could be wrong, but it sounds like you're all set from the cookie side, and you just need to detect whether the user is logged in or not from the javascript side, and redirect to the login page once their session has expired. I think you'd probably need some sort of "heartbeat" type call on a controller that could tell you whether you have an active session, and ping it every minute or so to see if your user is still active. If you don't get a "logged-in" status from that service, redirect to the login page.
|
|
#
¿
Mar 17, 2014 11:35
|
|
|
Anveo posted:You don't need a heartbeat, just make sure your app is sending the proper response to any request with an expired session - probably a 401 in this case. How you handle that depends on your front-end setup but you will add something like an ajax response hook or ember route error handler where you will inspect the response code and do whatever logic you need like redirecting the user or popping up an auth modal. Normally you don't, but the yoyodyne's problem was that his app wouldn't redirect to the login page unless the user clicked a link - if you want your app to redirect to the login page without any interaction from a user when a session expires, you need some sort of timed request that checks login.
|
|
#
¿
Mar 18, 2014 12:41
|
|
|
What's the name of your database in the test section of database.yml? Development and test store their settings differently, and if the name was accidentally duplicated between your two apps, you'd see this behaviour (and development would still work perfectly fine)
|
|
#
¿
Mar 31, 2014 17:23
|
|
|
Sitting Bull posted:Rails 4/Mongoid 4 question: If you're just trying to meet the requirement of "I can pass an individual ID, or an array of ids", .where supports that out of the box: code:
|
|
#
¿
Apr 10, 2014 02:09
|
|
|
FWIW, I use Vue in an app that's 100% progressive enhancement (everything works 100% without JS but we augment certain things), and it works pretty well. Occasionally you'll run into some awkwardness needing to duplicate things in ERB and Vue, but it's more rare than you think.
|
|
#
¿
Jul 1, 2020 09:52
|
|
|
Alpine looks pretty cool, I'm going to check that out. So far, bundle size hasn't been a big concern. I should stress our JS usage is pretty minimal (we use it for things like adding typeahead searches, modals, better file upload components, etc.), but we're only at about 86KB gzipped (our CSS is currently a much larger concern).
|
|
#
¿
Jul 4, 2020 14:55
|
|
|
I don't think that's bootstrap, that's standard for all the _tag vs form instance methods - the value is by default derived from the form's object and so you never pass it in (although you can override it with a value option). Think of it this way - if that method had 3 arguments, you'd have to unnecessarily pass the value every time, when 95% of the time you just want to use the current value of whatever your model is. To be honest, I'd consider reworking your form a bit anyway so that the controller initializes a model (without saving it), and build the form off that. That way you can specify your default values in your controller (or even your model or your DB if it's a universal default), which is going to be less buried when you come back to it, can be tested if you needed to for some reason, and you can share the same form for editing and creating if you need to do both.
|
|
#
¿
Aug 29, 2020 13:22
|
|
|
Peristalsis posted:This is a form that is collecting metadata to use to create multiple objects. It takes in a base name and the number of objects desired, and creates them. So, you pass in "My Object", and 3, and when you click submit, the system creates 3 objects, named My Object 1, My Object 2, and My Object 3. So, there is no single model to initialize in the controller before calling the form. I'm certainly open to better ideas, but using form_tag seemed the easiest way to make a form to collect data that isn't directly related to a single model. Yeah, for situations like that that can be a good approach. If things got complicated, you could consider making a form object by including ActiveModel::Model on a new class and building the form around that. (ActiveModel::Model is basically the model stuff without any ActiveRecord logic, so you'd make a new model that represents that metadata and do the saving of the various objects inside the save of that model).
|
|
#
¿
Sep 1, 2020 10:26
|
|
|
barkbell posted:Tech lead brought me in on a side project app for secure log sharing. It's a rails app and I've never done it before. Java/Angular is my day job and I do my own side projects in node/react. This erb stuff looks like php. If you can invest the time, going through Michael Hartl's tutorial (https://www.railstutorial.org/) is pretty comprehensive and will take you far enough to confidently navigate any Rails project.
|
|
#
¿
Sep 14, 2020 15:27
|
|
|
Yeah, we're in the process of moving over to Turbo (not even streams yet, just "go grab this partial and shove it here" with frames), and it's pretty great, it's like a well-thought out version of buggy code I've hacked together tons of times to load part of a view through AJAX.
|
|
#
¿
Feb 4, 2021 18:59
|
|
|
Also, I know this doesn't directly solve your problem, but we recently subbed out render_async for Turbo, and it's a way smoother experience IMO (it also natively supports things like not loading a tabs content until it's visible in the DOM, so you can take a lot of that javascript work off your plate). But even in the render_async world, you need to make sure that whatever page initialization code you might run listen for an event indicating that the page has loaded, and then run them. If you're using render async with turbolinks, it will fire a "turbolinks:load" event on the document. In our codebase, we set up a list of events to be run on pageload, and then trigger them with this (we're using turbo instead of turbolinks, but this all works the same with a different event name): code:enki42 fucked around with this message at 13:32 on Feb 19, 2021 |
|
#
¿
Feb 19, 2021 13:28
|
|
|
The core is pretty much the same as it was from back then, but there's a lot more nice little side things added:
I'm sure I'm missing others, and there's probably a billion tiny little things, but for the most part, it will feel pretty familiar to 2015 Rails with a couple "oh, neat!" type things.f Also if you want straightforward deployment and infrastructure management, there's still absolutely nothing wrong with Heroku for most projects and you're not going to get any easier than that. If AWS is a must, Cloud 66 puts a layer over it (or other cloud providers) that makes it feel like heroku and hides most of the complexity away from you.
|
|
#
¿
Jul 24, 2021 14:59
|
|
|
If you literally want just the external_reference_id and nothing else, pluck is better than select, so you don't have to hydrate the whole tree of objects.
|
|
#
¿
Apr 27, 2022 10:43
|
|
|
A MIRACLE posted:turbo is cool. I haven't gotten to the "stimulus" part of "hotwire" yet. is all this really better than doing a create-react-app ? It really depends, they are different tools for different use cases. A react SPA is definitely going to be a better fit for highly interactive applications, if you were making something that looked like Google Maps, or Figma, or anything else where most interactions don't really feel like navigating pages, that's going to be a pain in the rear end with "vanilla" Rails even with all the Hotwire stuff. If your app feels like navigating between pages primarily and has smaller bits of interaction sprinkled in, and especially if you're not working on a team that splits into front-end and back-end developers, you'll be way more productive with Rails. There's honestly not that much to Stimulus and more and more I find that you can often do things more effectively with Turbo. Any stimulus controller that communicates with the backend is a smell IMO.
|
|
#
¿
Nov 19, 2023 13:13
|
|
|
Yeah, it's definitely one part of Hotwire that you can take or leave, it doesn't really tie into the other stuff much at all. I can't imagine heavy use of React and Turbo playing nice together though. React generally wants to control the DOM of anything it's mounted on and have JS fully control what the user sees, and Turbo is built around the server generating HTML and adding that to the DOM so they're pretty fundamentally different approaches.
|
|
#
¿
Nov 20, 2023 12:54
|
|
|
Yeah, that's definitely possible, and can work. Where I've found it falls flat is when dealing with forms and submitting data to the server. Rails really wants to use a traditional HTML form, and React really wants to do server interaction via fetch. It's possible to make either do the unnatural thing, but you miss out on a lot of tooling and hit some sharp edges. But I used React to build a media player in an otherwise JS light Rails app and it worked great. I like Stimulus but I agree when I try to do something complicated with it I want to use React. It's good for the "once in a blue moon I will want to write 30 lines of Javascript for a particular interaction" but if it's more than that it's painful.
|
|
#
¿
Nov 25, 2023 15:16
|
|
|
|
| # ¿ May 16, 2024 00:54 |
|
|
You could throw it in an initializer, and check if ::Rails::Console is defined:code:
|
|
#
¿
Mar 12, 2024 11:42
|
|