|
I don't get the hate for rspec. I love it...
|
#
?
Aug 30, 2013 05:20
|
|
|
|
| # ? May 9, 2024 03:23 |
|
|
I wanted to like RSpec but after using it for a while I realized my Test::Unit tests were way more maintainable. When it comes down to it all you really need in a testing framework is "assert", the DSL frameworks like Cucumber are just trendy conventions created for and by idiots.
|
|
#
?
Aug 30, 2013 17:48
|
|
|
Novo posted:I wanted to like RSpec but after using it for a while I realized my Test::Unit tests were way more maintainable. When it comes down to it all you really need in a testing framework is "assert", the DSL frameworks like Cucumber are just trendy conventions created for and by idiots. I'm at about ~100 examples written for this app so far and haven't yet encountered many problems at all with RSpec. What makes RSpec specs less maintainable than Test::Unit tests?
|
|
#
?
Aug 31, 2013 04:02
|
|
|
Deus Rex posted:I'm at about ~100 examples written for this app so far and haven't yet encountered many problems at all with RSpec. What makes RSpec specs less maintainable than Test::Unit tests? Nothing. All of the frameworks do essentially the same thing. Just use whichever one you find most readable and the easiest to understand.
|
|
#
?
Aug 31, 2013 16:44
|
|
|
Right, when I said that my RSpec test were less maintainable than my Test::Unit tests, I literally meant that the way I found myself writing RSpec over time (trying different ways of structuring my assertions, trying to apply DRY, etc) was less maintainable for me than the way I found myself writing Test::Unit tests. Follow your bliss.
|
|
#
?
Sep 1, 2013 01:27
|
|
|
Can someone please explain the difference between belongs_to: through: and has_and_belongs_to_many:? This guide says belongs_to: through: is better if I need to actually use the relationship model, whereas I don't have to with has_and_belongs_to_many -- but I need to remember to create the joining table. So, what's the difference? I'd assume if I were making a joining table I'd then be able to use the relationship model, as with belongs_to: through:, so where's the benefit of the latter choice? Is there any way for RoR to create the join table automatically? (Edit: I think I understand now, but just to be certain: with a belongs_to: through: I need to create another model in Rails, but with has_and_belongs_to: I just need to create a join table in the migrate file / directly in mySQL?) Secondly, is there a good resource out there for how to use an existing MySQL database with Rails? Everything I've seen assumes I'm setting up and migrating from scratch, but I have the database already set up and populated and just need to know how much of the structure I need to declare for Rails. rohan fucked around with this message at 08:36 on Sep 1, 2013 |
|
#
?
Sep 1, 2013 08:28
|
|
|
Baron Dirigible posted:(Edit: I think I understand now, but just to be certain: with a belongs_to: through: I need to create another model in Rails, but with has_and_belongs_to: I just need to create a join table in the migrate file / directly in mySQL?) You are correct. habtm does not have an associated model while hmt does. Baron Dirigible posted:Secondly, is there a good resource out there for how to use an existing MySQL database with Rails? Everything I've seen assumes I'm setting up and migrating from scratch, but I have the database already set up and populated and just need to know how much of the structure I need to declare for Rails. rake db:schema:dump will create a schema from the database. You'll have to create all the models manually.
|
|
#
?
Sep 1, 2013 17:16
|
|
|
Baron Dirigible posted:Can someone please explain the difference between belongs_to: through: and has_and_belongs_to_many:? This guide says belongs_to: through: is better if I need to actually use the relationship model, whereas I don't have to with has_and_belongs_to_many -- but I need to remember to create the joining table. So, what's the difference? I'd assume if I were making a joining table I'd then be able to use the relationship model, as with belongs_to: through:, so where's the benefit of the latter choice? Is there any way for RoR to create the join table automatically? kayakyakr posted:You are correct. habtm does not have an associated model while hmt does. I was confused about this recently, too. Both habtm and hmt need and use a join table in the database, right - it's just that one doesn't use or require a corresponding Rails model? Also, you have to create the join table in both cases, don't you? I'm assuming that they only point it out in the habtm case because it would be easier to forget it, since you don't have a model for it to remind you of its existence.
|
|
#
?
Sep 1, 2013 21:39
|
|
|
Peristalsis posted:I was confused about this recently, too. habtm is a bit of that Rails magic that you must know about to use. You have to create a table in both cases, and that table must include id's from both sides of the relation. The difference is that habtm doesn't have an id for itself and there is no model for it. I'd say that hmt doesn't use a join table because that table represents something else in your database other than just a join between the two tables. If the join between the two has no context (ie the only thing you'll ever be doing is joining the two) then the proper relationship to use is habtm. The join table is not really a reminder thing, it's necessary to make the habtm work
|
|
#
?
Sep 1, 2013 23:51
|
|
|
kayakyakr posted:If the join between the two has no context (ie the only thing you'll ever be doing is joining the two) then the proper relationship to use is habtm. This is, of course, never true unless it's the simplest throwaway project. Assigning a name, model, and behavior to the relationship between two entities not only provides for future extensibility, but it helps you understand and reason about the relationship better.
|
|
#
?
Sep 2, 2013 00:41
|
|
|
Novo posted:the DSL frameworks like Cucumber are just trendy conventions created for and by idiots. You know, it's possible to say you prefer Test::Unit without insulting everyone who likes to use different tools.
|
|
#
?
Sep 2, 2013 00:53
|
|
|
no this is ruby we have to be insufferable social retards
|
|
#
?
Sep 2, 2013 01:10
|
|
|
Look all I'm saying is there's two ways to write your views: the HAML way and the lovely programmer way.
|
|
#
?
Sep 2, 2013 01:14
|
|
|
Cocoa Crispies posted:This is, of course, never true unless it's the simplest throwaway project. Assigning a name, model, and behavior to the relationship between two entities not only provides for future extensibility, but it helps you understand and reason about the relationship better. I disagree, but that's probably because I wrote SQL in my past life.
|
|
#
?
Sep 2, 2013 07:02
|
|
|
kayakyakr posted:You are correct. habtm does not have an associated model while hmt does.
|
|
#
?
Sep 2, 2013 10:23
|
|
|
prom candy posted:You know, it's possible to say you prefer Test::Unit without insulting everyone who likes to use different tools. Can I still make fun of Windows and PHP?
|
|
#
?
Sep 2, 2013 18:57
|
|
|
I just switched from a Windows machine doing dev stuff in a Linux VM to a Mac. Anything I should know or keep in mind about doing dev stuff on one? I've never used a Mac before other than just casually.
|
|
#
?
Sep 4, 2013 22:12
|
|
|
EAT THE EGGS RICOLA posted:I just switched from a Windows machine doing dev stuff in a Linux VM to a Mac. Anything I should know or keep in mind about doing dev stuff on one? I've never used a Mac before other than just casually. The buttons are on the left instead of the right.
|
|
#
?
Sep 4, 2013 22:31
|
|
|
Get Alfred and take the time to learn the Mac hotkeys.
|
|
#
?
Sep 4, 2013 22:54
|
|
|
EAT THE EGGS RICOLA posted:I just switched from a Windows machine doing dev stuff in a Linux VM to a Mac. Anything I should know or keep in mind about doing dev stuff on one? I've never used a Mac before other than just casually. homebrew is a pretty nice thing, but you'll probably end up compiling more things from source than you're used to. I recommend not trying to outsmart homebrew with the permissions it wants (at one point it was asking you to chmod /usr/local). It sounds kind of awful, but dealing with the alternative is much worse. good jovi fucked around with this message at 02:03 on Sep 5, 2013 |
|
#
?
Sep 4, 2013 23:18
|
|
|
Keep using your VM.
|
|
#
?
Sep 4, 2013 23:53
|
|
|
Anyone ever have the absolute pleasure of having to integrate Omniture with their Rails apps? I found a gem for it but it has no documentation whatsoever so I don't know what it does. As it stands we have a lot of Omniture massaging code in our controllers and it just feels wrong. I'm thinking maybe moving the prep code into Javascript and then just outputting the necessary objects into a data tag?
|
|
#
?
Sep 5, 2013 04:41
|
|
|
prom candy posted:Anyone ever have the absolute pleasure of having to integrate Omniture with their Rails apps? I found a gem for it but it has no documentation whatsoever so I don't know what it does. As it stands we have a lot of Omniture massaging code in our controllers and it just feels wrong. I'm thinking maybe moving the prep code into Javascript and then just outputting the necessary objects into a data tag? Would encapsulating the omniture "massaging" into models work better?
|
|
#
?
Sep 5, 2013 15:37
|
|
|
Newbie question: I had trouble getting into RoR a couple years back after casually chatting with some web developers at the company I worked at. I found the path to "Hello, World" a bit too abstract and gave up shortly after. Fast foward to yesterday and I had a neat idea for a web app, and spent a good part of the night looking into Zend Framework 2 (seriously wtf) and Code Igniter before I remembered RoR. I've been doing some Java game dev in my spare time recently, and I've picked up a lot about OOP and MVC, so it makes more sense now. But there's only one problem: my site on Lithium Hosting (goon discounts  ) doesn't support anything higher than rails 2.3.18. Here's the environment:Ruby version 1.8.7 (x86_64-linux) RubyGems version 1.8.25 Rack version 1.1.6 Rails version 2.3.18 Active Record version 2.3.18 Active Resource version 2.3.18 Action Mailer version 2.3.18 Active Support version 2.3.18 Application root /home/blah/blah Environment development Database adapter sqlite3 Database schema version 0 A lot of the more recent modules for, let's say security, that I've been seeing in this thread and around the net need at least Rails 3 for the most recent versions, which fix critical security flaws and the like. Can I get away with using an older version of Rails or should I find another way to start developing? Some of the main feature additions to Rails 3-4 sound neat, albeit mostly beyond me. It actually reminds me of another issue I had, that this community moves so drat fast recommended modules and programming concepts seem out-dated in many of the undated articles I read. It's another one of those things that raise the barrier of entry. Are there any updates guides or wikis on current best practices / gems?
|
|
#
?
Sep 5, 2013 19:24
|
|
|
androo posted:Newbie question: I had trouble getting into RoR a couple years back after casually chatting with some web developers at the company I worked at. I found the path to "Hello, World" a bit too abstract and gave up shortly after. You should just use Heroku if you're getting started (http://heroku.com) for hosting. It'll take whatever Rails version you throw at it, and you get a dyno and small database instance for free.
|
|
#
?
Sep 5, 2013 19:34
|
|
|
androo posted:A lot of the more recent modules for, let's say security, that I've been seeing in this thread and around the net need at least Rails 3 for the most recent versions, which fix critical security flaws and the like. Can I get away with using an older version of Rails or should I find another way to start developing? Some of the main feature additions to Rails 3-4 sound neat, albeit mostly beyond me. You could just use Heroku for now? One-dyno + a small database is free.
|
|
#
?
Sep 5, 2013 19:34
|
|
|
androo posted:A lot of the more recent modules for, let's say security, that I've been seeing in this thread and around the net need at least Rails 3 for the most recent versions, which fix critical security flaws and the like. Can I get away with using an older version of Rails or should I find another way to start developing? Some of the main feature additions to Rails 3-4 sound neat, albeit mostly beyond me. Don't use 2.3. With the release of 4.0, 2.3 will no longer be receiving severe security patches. It's a bad idea even before you start tearing your hair out trying to find compatible gems to do anything. If you're married to Lithium, check with them about your options; most cPanel hosts offer some kind of workaround for cPanel's horrendously out-of-date Ruby and Rails. If you're not married to Lithium, there are a variety of PaaS hosts including Heroku and Red Hat OpenShift that offer free or super-cheap plans at the entry level. Molten Llama fucked around with this message at 19:46 on Sep 5, 2013 |
|
#
?
Sep 5, 2013 19:43
|
|
|
Cocoa Crispies posted:Would encapsulating the omniture "massaging" into models work better? We have some presenters for doing just that but we still end up instantiating them in the controller, whereas I would prefer the controller have no knowledge about Omniture.
|
|
#
?
Sep 5, 2013 20:07
|
|
|
prom candy posted:We have some presenters for doing just that but we still end up instantiating them in the controller, whereas I would prefer the controller have no knowledge about Omniture. Could you instantiate the presenters in a helper on demand? Ruby code:You could also use a before_filter I suppose. Molten Llama posted:If you're married to Lithium…
|
|
#
?
Sep 5, 2013 20:44
|
|
|
Heroku is trash. Don't use Heroku. If you just care about getting your app live and not about system administration (and are comfortable paying a premium for that luxury) use cloud66 or another alternative.
|
|
#
?
Sep 5, 2013 22:57
|
|
|
I have to write a wrapper related to an api that will be used by complete beginners that are interested in learning, and I'm not sure how to write it so that it's as easy as possible to understand rather than as elegant/ruby-esque as possible. The annoying part of the api that I'm going to wrap has 5 different types of api calls. wrapping it in one method would require each of the following calls: api_call - to pull the whole top level db api_call(var_one) - to pull a sub db based on which top level db was called api_call(var_one, var_two) - same situation as the previous one api_call(var_one, var_two, var_three, offset=0, results=100) - this is where it's annoying, the offsets are irrelevant everywhere except for this api call api_call(var_one, var_two, var_4) - here the parameter names go crazy and they're included in the same api endpoint even though they're not logically related at all I can write this in one method and have it be confusing to a beginner, then write descriptive methods that reference it and get rid of the confusion while leaving a "magic box" in which will reduce repetition, or I can write it in a bunch of smaller, descriptively named methods (which will require repetition but which will make each individual method much more easily understood) What do I do to make it most clear to a beginner? I kind of want to go with the second option but it's really bugging me in terms of repetition. Also this might make no sense and I might sound crazy.
|
|
#
?
Sep 6, 2013 04:12
|
|
|
Cocoa Crispies posted:Could you instantiate the presenters in a helper on demand? That's kind of what I was thinking of doing, yeah. On the one hand it's kind of a lot of responsibility for a view helper but I suppose if I offload enough of it into the presenters it won't be too bad. View helpers always feel kind of wrong to me but I mean, these kinds of analytics are a front-end concern so the view is probably the most obvious place for them to go if I'm not going to go full-bore and rewrite everything in Javascript. Thanks for your input, glad to see someone else come up with sort of the same idea 
|
|
#
?
Sep 6, 2013 04:21
|
|
|
xtal posted:Heroku is trash. Don't use Heroku. If you just care about getting your app live and not about system administration (and are comfortable paying a premium for that luxury) use cloud66 or another alternative. Heroku is good enough for small projects. It has gotten worse over the last few years, or maybe it's only S3 that has gotten worse, but it's still perfectly fine to recommend. Cloud66 is really interesting. Can you talk about your experience with it? We run about ~12 apps on Heroku and would consider switching, but we sure as poo poo don't want to be doing any ops. edit: oh cloud66 is $9/mo per app and not per server, as it won't spin up more than a single app per server. Still cheaper than Heroku but not by as much as I thought. Here I was imagining a big ol' server running a bunch of apps on it, or multiple instances of one app on a single server, but nope hmm yes fucked around with this message at 05:21 on Sep 6, 2013 |
|
#
?
Sep 6, 2013 05:00
|
|
|
Heroku is absolutely fine for babby's first Rails site. It's straightforward enough and there are tons of docs and help available for getting set up on it. Since the poster was asking about shared hosting, my impression (please correct me if I am wrong) is that this is a hobby/side project. Cloud66 doesn't offer a free plan so you would have to pay at least $9/mo (or $7/mo amortized if you buy a year of service), whereas the Heroku free tier is definitely good enough for screwing around with until you're more comfortable with Rails and have built something people are actually using. Unsubstantiated vitriol is pointless and unhelpful and I wish there were less of it on the internet when people ask for help.
|
|
#
?
Sep 6, 2013 05:13
|
|
|
Heroku has done a lot for Rails and other technologies (like Postgres, thanks Pardot!) but I haven't been impressed with their performance. We just moved a client off of $300/mo worth of workers to $50/mo worth of dedicated virtual servers and we're comparable, often better, performance. That being said their free tier is fine if you don't want to add "learning how to manage a dedicated server" to the end of a long list of things you need to do to build and launch a Rails app.
|
|
#
?
Sep 6, 2013 05:22
|
|
|
I've been using amazon's elastic beanstalk, another service that you can get free (for a year). It's ok. I mean, it's pretty poo poo because it's amazon micro, but it's ok and not hard to deploy to.
|
|
#
?
Sep 6, 2013 05:27
|
|
|
Deus Rex posted:Cloud66 doesn't offer a free plan so you would have to pay at least $9/mo (or $7/mo amortized if you buy a year of service), whereas the Heroku free tier is definitely good enough for screwing around with until you're more comfortable with Rails and have built something people are actually using. Closer to a $20/mo minimum. Cloud66 is only providing the management. It's BYOIaaS; you've still got to pay for the Rackspace/AWS/Linode/whatever instances it's managing for you. Heroku's definitely the better (cheaper) option for screwing around.
|
|
#
?
Sep 6, 2013 08:14
|
|
|
Molten Llama posted:Closer to a $20/mo minimum. Cloud66 is only providing the management. It's BYOIaaS; you've still got to pay for the Rackspace/AWS/Linode/whatever instances it's managing for you. Heroku's definitely the better (cheaper) option for screwing around. I'm sticking with Heroku for now, but those other options are interesting. Thanks for the info, everyone.
|
|
#
?
Sep 6, 2013 13:46
|
|
|
atastypie posted:Heroku is good enough for small projects. It has gotten worse over the last few years, or maybe it's only S3 that has gotten worse, but it's still perfectly fine to recommend. It's a buttload cheaper than Heroku. Adding a DigitalOcean worker is $5 compared to $36, and you just pay a $9 surcharge. It's cheaper and more performant in every possible combination with the exception of Heroku's free tier, which spins down your app after 15 minutes of inactivity. For any website being used by more than its author, that's unacceptable. Plus Heroku lies to their customers and is down all the time and stuff. But if it is just for the author, then it doesn't really matter! xtal fucked around with this message at 22:22 on Sep 6, 2013 |
|
#
?
Sep 6, 2013 22:16
|
|
|
|
| # ? May 9, 2024 03:23 |
|
|
For someone that is new and messing around, which seems to be the case here, Heroku is free. I wouldn't run something that got any level of traffic off of it, but to play around and maybe easily deploy a prototype?
|
|
#
?
Sep 7, 2013 03:46
|
|