|
How do I get the setings or params of a chain while I am in that chain? for exampleRuby code:
|
# ? Nov 23, 2014 18:42 |
|
|
# ? May 28, 2024 16:22 |
|
Ruby code:
|
# ? Nov 23, 2014 19:22 |
|
MasterSlowPoke posted:
So I want to do current_account.users.my_function and inside of my function I'd like to pluck out the account_id being used. I'd also like to just in general know if there is some meta properties I can inspect to get all the variables currently being passed in to the query maker.
|
# ? Nov 23, 2014 19:47 |
|
KoRMaK posted:Thanks, but I'm not sure this will apply to my situation. Doing current_account.users builds a query that is "select * from users where account_id = 1" (1 being the id of current_account). I'm not sure I understand the question. Ruby code:
Ruby code:
|
# ? Nov 23, 2014 21:15 |
|
At the place I'm working all the view partials are put into concern folders, (like app/views/model_name/concerns/_partials.html.erb). Is this common?
|
# ? Nov 25, 2014 15:47 |
|
MasterSlowPoke posted:At the place I'm working all the view partials are put into concern folders, (like app/views/model_name/concerns/_partials.html.erb). Is this common?
|
# ? Nov 25, 2014 15:53 |
|
MasterSlowPoke posted:At the place I'm working all the view partials are put into concern folders, (like app/views/model_name/concerns/_partials.html.erb). Is this common? No, that's not the right place for them. Partials either live in a views/common or views/model_name depending on their use case. KoRMaK posted:Is concern another name for interface? I can't answer your question, but I noticed "concerns" in the rails lexicon recently and it reminded me of interfaces in like C# or C++ Concern is a fairly new, easy way to extend ActiveModel objects. It's a slightly cleaner method than the normal ruby include methodology.
|
# ? Nov 25, 2014 16:04 |
|
kayakyakr posted:Concern is a fairly new, easy way to extend ActiveModel objects. It's a slightly cleaner method than the normal ruby include methodology. It's actually for anything really. There's app/concerns, app/models/concerns, and app/controllers/concerns. Its for functionality that is reusable across multiple objects (usually of a common type, like a model or controller) but not every object. Its kind of a band-aid around fat controllers and models in my opinion. Once you include them you still end up with a fat controller or model, its just hidden away in another module.
|
# ? Nov 25, 2014 18:43 |
|
necrotic posted:It's actually for anything really. There's app/concerns, app/models/concerns, and app/controllers/concerns. Its for functionality that is reusable across multiple objects (usually of a common type, like a model or controller) but not every object. Its kind of a band-aid around fat controllers and models in my opinion. Once you include them you still end up with a fat controller or model, its just hidden away in another module. Concerns increase modularity and composability, and that leads to better controllers and models and such. It doesn't prevent (or relate to) the problem of making objects that do too much. Whenever you're adding code to a controller or model, do your best to generalize it and move it to a concern, even if it will only be used by that controller (at first.)
|
# ? Nov 26, 2014 01:14 |
|
xtal posted:Concerns increase modularity and composability, and that leads to better controllers and models and such. It doesn't prevent (or relate to) the problem of making objects that do too much. My point is that when you include them the controller/model is still fat, its just hidden. It also adds a pain point in figuring out "okay so Butt.new.make_a_fart works, but where is it defined? lets go see Butt! poo poo, its not there. Okay, which of these 10 modules is it in?". Yes, you can grep 'def make_a_fart', but its taken you more steps to end up finding where its defined than it ever should have. It also has a problem with method name collisions, which are (surprise) silent in Ruby and just take the most recent as truth. Hope you didn't accidentally override some rarely used but important method in your new module! (Yes, tests, because those always exist in the project you got hired to work on)
|
# ? Nov 26, 2014 01:55 |
|
I just skip straight to searching for def method. Of course that only works most of the time, thanks to metaprogramming magic.
|
# ? Nov 26, 2014 08:26 |
|
necrotic posted:My point is that when you include them the controller/model is still fat, its just hidden. It also adds a pain point in figuring out "okay so Butt.new.make_a_fart works, but where is it defined? lets go see Butt! poo poo, its not there. Okay, which of these 10 modules is it in?". Yes, you can grep 'def make_a_fart', but its taken you more steps to end up finding where its defined than it ever should have. It also has a problem with method name collisions, which are (surprise) silent in Ruby and just take the most recent as truth. Last month I was working on building an APN abstraction before having my coffee and thought "send would be a great method name to use for the method that sends an APN!" Whoops.
|
# ? Nov 26, 2014 18:32 |
|
Thalagyrt posted:Last month I was working on building an APN abstraction before having my coffee and thought "send would be a great method name to use for the method that sends an APN!" Whoops. I think this is why you're supposed to use __send for message passing since 1.9, but basically nobody does -_- MALE SHOEGAZE posted:I just skip straight to searching for def method. Of course that only works most of the time, thanks to metaprogramming magic. Yeah, me too. But it's a context switch I would much rather not be necessary.
|
# ? Nov 26, 2014 18:47 |
|
xtal posted:Concerns increase modularity and composability, and that leads to better controllers and models and such. It doesn't prevent (or relate to) the problem of making objects that do too much. Right, I blame travel head for thinking it was from ActiveModel and not ActiveSupport as it is. But I disagree about generalizing things and moving them to concerns if they're only going to be used once. I say wait to generalize until you're about to reuse something. Then again, I also disagree with the idea that code in controllers is something that should be avoided at any cost. I think that's dangerous thinking. I don't like obese controllers, but a controller that maintains a nice healthy weight is more beautiful than a controller that is too skinny.
|
# ? Nov 26, 2014 22:09 |
|
MrDoDo posted:If you want to learn how to be a better ruby programmer I would suggest the books Eloquent Ruby (haven't read it yet but hear great things) Just to let you know that I got the book a few days ago and I can tell you that I enjoy it quite a bit (I'm already at chapter 5). I'm also starting to work on a pet project, using Git and TDD. Thank you!
|
# ? Nov 26, 2014 22:49 |
|
xenilk posted:Just to let you know that I got the book a few days ago and I can tell you that I enjoy it quite a bit (I'm already at chapter 5). I'm also starting to work on a pet project, using Git and TDD. Thank you! Awesome, glad to hear. Getting hands on TDD is a low pressure environment is the best thing you can do. Also there was talk earlier about RSpec vs Test Unit. Starting with Rails 4 the testing framework inherits from Minitest which has a spec style. RSpec can definitely be pretty verbose in my opinion so this gives a pretty decent alternative
|
# ? Nov 27, 2014 00:28 |
|
Speaking of RSpec, I'm having a weird issue with before and let. I have this spec:Ruby code:
code:
|
# ? Dec 2, 2014 20:46 |
|
Pollyanna posted:
code:
|
# ? Dec 2, 2014 21:16 |
|
I could have sworn it was okay to do that. Goddamn, am I confused. Either way, it works now Thanks!
|
# ? Dec 2, 2014 21:30 |
|
Also, don't create database objects in before(:all) blocks. They are executed outside of the transaction, so those rows won't get cleaned up.
|
# ? Dec 2, 2014 21:50 |
|
good jovi posted:Also, don't create database objects in before(:all) blocks. They are executed outside of the transaction, so those rows won't get cleaned up. I caught that a little while ago, but didn't change it for some reason. Fixed!
|
# ? Dec 2, 2014 22:03 |
|
good jovi posted:Also, don't create database objects in before(:all) blocks. They are executed outside of the transaction, so those rows won't get cleaned up. Good to know, I've probably made this mistake on some of my earlier work
|
# ? Dec 2, 2014 22:06 |
|
good jovi posted:Also, don't create database objects in before(:all) blocks. They are executed outside of the transaction, so those rows won't get cleaned up. That's what let is for.
|
# ? Dec 2, 2014 22:56 |
|
Cocoa Crispies posted:That's what let is for. or let! if it must be created before you access the variable.
|
# ? Dec 2, 2014 23:25 |
|
Basically:
Another nice thing about lets is composing your test data. A simple example would be a Ticket that moves through several states from new to resolved, with each state changing the behavior of the record slightly: code:
|
# ? Dec 3, 2014 02:18 |
|
How do people feel about Elastic Beanstalk as a way to deploy Rails applications? I realize Digital Ocean or Heroku is probably a bit easier, but I'd quite like to beef up my knowledge of the AWS ecosystem. Is EB (i.e. orchestrated EC2 + RDS) a good choice?
|
# ? Dec 8, 2014 07:12 |
|
Lexicon posted:How do people feel about Elastic Beanstalk as a way to deploy Rails applications? I realize Digital Ocean or Heroku is probably a bit easier, but I'd quite like to beef up my knowledge of the AWS ecosystem. Is EB (i.e. orchestrated EC2 + RDS) a good choice? Have used it. It was ok. Had to do a decent bit of configuration which was a pain. Didn't like giving up as much control as I did. After a bit, dropped it for dokku and then dropped that for capistrano + DO.
|
# ? Dec 8, 2014 16:25 |
|
Does anyone have experience with subdomains in rails? Basically I have a couple of routes that use the subdomain: /.+/ constraint on the site, the subdomains are only used for a small part of the site. So when the user visits foo.mysite.com the problem is that all the links (e.g. navbar and footer) now link to urls with the subdomain, for instance instead of mysite.com/contact it will be foo.mysite.com/contact. I know I can change the links from relative to absolute path (e.g. my_path_url(subdomain: false) ), but doing that for all the links in my application seems like a bad idea. Is there some way to configure rails to not link to subdomains unless it is explicitly stated or perhaps some other solution?
|
# ? Dec 10, 2014 17:19 |
|
Gmaz posted:Does anyone have experience with subdomains in rails?
|
# ? Dec 10, 2014 17:21 |
|
Maybe I'm not getting something but I don't understand how this will help me with linking. Currently my navbar has something like -- link_to contacts_path, and I always want it to link to mysite.com/contacts. However if the user is on foo.mysite.com that link will go to foo.mysite.com/contacts. I don't need subdomains for most of the site (just on one controller), the parts where I need them record lookup is already done via subdomains.
|
# ? Dec 10, 2014 17:57 |
|
Gmaz posted:Maybe I'm not getting something but I don't understand how this will help me with linking. I see two options:
The first option is more explicit, but requires you to use a new method for nearly all of your links. The second would be more "transparent", but could catch a new developer by surprise.
|
# ? Dec 10, 2014 20:37 |
|
We launched a website for our gems that we use in-house for our Rails consulting apps. You can view the site at: http://gems.agilstyle.com. These gems are all used in production Heroku apps. The current gem list is:
Would love feedback on the gem site (does it explain things well enough? what's missing?), the READMEs (writing docs is hard), the code (everyone has opinions), or anything else you would like to say. A lot of the work is written by our lead developer so the contributor count is low. Normally that scares us off from using another gem (we only use ones with 10+ contributors as a rule) but please don't let that scare you off in giving some feedback! This is our first try at open source and we're really excited (and terrified) to see if what we release can provide value to other developers. hmm yes fucked around with this message at 04:57 on Dec 11, 2014 |
# ? Dec 11, 2014 00:53 |
|
Well I'm definitely interested in the assets gem. Especially since it purports to play nice with ActiveAdmin. I'm on my phone so I can't really dig into it but I'll check it out soon
|
# ? Dec 11, 2014 02:14 |
|
The site is down for me but I'd be interested in checking it out. (And yeah I removed the accidental period from the end of the link.)
|
# ? Dec 11, 2014 03:58 |
|
Site is hosted on GitHub pages, and status says some sites are down, so just try later I guess
|
# ? Dec 11, 2014 04:58 |
|
I'm trying to learn to use rubber - I like it so far, but it seems to get stuck at various points. I'm doing the simplest of test apps right now, and it's been sitting here for quite some time (~ 30 mins):code:
|
# ? Dec 11, 2014 20:48 |
|
Here's a quick question. I have an object foo of type Bar with a string property called prop. I execute the following: code:
original replacement original If I instead execute this: code:
original replacement replacement So, it appears that using sub! with an object property changes the property, but the change doesn't save, whereas setting it as an explicit assignment does. Does anyone know if this is intended behavior, or if there must just be some other, subtle problem in my code making it do this?
|
# ? Dec 12, 2014 17:24 |
|
Model attributes that are not marked as serializable (stuff that is saved as json or yaml strings in the database, usually arrays) are only saved when they are marked to be dirty, i.e. when you use the setter methods. If you mutate the values directly, Rails doesn't know about that.
|
# ? Dec 12, 2014 17:51 |
|
necrotic posted:I see two options: But in any case I appreciate the help.
|
# ? Dec 12, 2014 18:11 |
|
|
# ? May 28, 2024 16:22 |
|
Smol posted:Model attributes that are not marked as serializable (stuff that is saved as json or yaml strings in the database, usually arrays) are only saved when they are marked to be dirty, i.e. when you use the setter methods. If you mutate the values directly, Rails doesn't know about that. While I wouldn't recommend it for this use case, you can force an attribute to dirty by calling foo.prop_will_change!. See the API Docs for more on dirty attributes.
|
# ? Dec 12, 2014 18:53 |