Ruby on Rails Love-In

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

«‹›178 »

stack: Nov 28, 2000

NotShadowStar posted:

If the offices are distinctly independent, then the easiest solution I can think of is multiple instances of the Rails project each with a different database.

No they wouldn't be entirely distinct. Certain information will be shared by all offices. We also want to support dozens or hundreds of offices and with separate apps and databases we'd run into a deployment/support nightmare before long.

Would before_save in the models be the best way to inject the users office id?

# ? Nov 20, 2009 17:28

Adbot: ADBOT LOVES YOU

# ? May 15, 2024 08:27

hmm yes: Dec 2, 2000; College Slice

You could use a hidden_field with value => current_user.office_id

edit: assuming you're using restful_authentication

# ? Nov 20, 2009 17:37

Operation Atlas: Dec 17, 2003; Bliss Can Be Bought

stack posted:

I'm new to rails and need some help in getting my app going the rails way.

The application is for doctor offices and each office should be sectioned off from other data any other office enters. I've added office ids to the various models but now I'm scratching my head.

I have declarative_authorization installed and want to use it to limit things like Patient.save to only the patients whose office id matched the logged in users office id. I also want to err magic in the users office id into all the various models which they create. So if a user creates a new Patient or Schedule record the office id gets put in magically.

How do I accomplish these?

I have an app with a similar thing, and my solution might be a bit hacky but it works. In ApplicationController I have a method called (for your example) current_office (Which would do, say, current_user.office). Whenever I create an object that is a direct descendant (belongs_to) of Office, I put this in the new/update_attributes lines of the controller:

code:

@patient = Patient.new(params[:patient].merge(:office_id => current_office.id))

OR

if @patient.update_attributes(params[:patient].merge(:office_id => current_office.id))

I find it is easier to just force the user to do things for their current office rather than try to detect a hack and raise an error. For things that are more than one level down from Office it gets a bit more complicated, but not that difficult:

code:

@visit = Visit.new(params[:visit])
if @visit.patient.office_id == current_office.id && @visit.save

OR

if @visit.patient.office_id == current_office.id && @visit.update_attributes(params[:visit]

P.S.: There might be some debate as to whether this logic belongs in models or controllers, but I believe that since it involves session data (current_user) it belongs firmly in the controller.

P.P.S: Using a hidden_field is strongly discouraged as it is probably the easiest thing in the entire world to hack.

# ? Nov 20, 2009 18:04

skidooer: Aug 6, 2001

Operation Atlas posted:

@patient = Patient.new(params[:patient].merge(:office_id => current_office.id))

You are on the right track, but you should be making use of the association proxies.

code:

@patient = current_office.patients.build(params[:patient])

# ? Nov 20, 2009 18:18

stack: Nov 28, 2000

doh! Yeah, creating a current_office method in the application controller is going to help. Wanting to save a bit of typing could I get clever and create a mixin or a parent class which will bring in the before_create to all the models which need the office_id?

Something like this perhaps?

code:

def before_create
  self.office_id ||= current_office.id
end

Would current_office be available inside of models?

Thanks to everyone responding btw!

# ? Nov 20, 2009 18:20

skidooer: Aug 6, 2001

stack posted:

Wanting to save a bit of typing could I get clever and create a mixin or a parent class which will bring in the before_create to all the models which need the office_id?

It is best not to get clever. It makes your code that much harder to test and maintain. You will regret it later.

If the amount of typing is really that much of a concern, make your helper method more granular:

code:

def patient
  current_office.patients
end

code:

@patients = patient.all
@patient = patient.find(params[:id])
@patient = patient.build(params[:id])

Although I personally prefer to be more explicit.

# ? Nov 20, 2009 18:39

stack: Nov 28, 2000

skidooer posted:

It is best not to get clever. It makes your code that much harder to test and maintain. You will regret it later.

If the amount of typing is really that much of a concern, make your helper method more granular:
code:
def patient
  current_office.patients
end
code:
@patients = patient.all
@patient = patient.find(params[:id])
@patient = patient.build(params[:id])
Although I personally prefer to be more explicit.

The being clever bit was my understanding that the rails community wanted to type as little as possible to get things done and that they wanted to take that to the extreme. I swear this will click eventually and it'll get through my thick skull. Your def example here is something I'd put in the app controller? Seems like I might be able to change my Patient.new line in PatientsController.create to

code:

@patient = current_office.patients.build(params[:patient])

Or am I going down the wrong path again?

# ? Nov 20, 2009 18:52

Operation Atlas: Dec 17, 2003; Bliss Can Be Bought

skidooer posted:

You are on the right track, but you should be making use of the association proxies.
code:
@patient = current_office.patients.build(params[:patient])

It isn't any more verbose to do it the straightforward way, and it is much clearer. Association proxies generally suck rear end.

Its a philosophical and stupid argument, so I'm not going to keep at it beyond this. However, this is one of the main reasons I don't use ActiveRecord anymore.

# ? Nov 20, 2009 19:21

hmm yes: Dec 2, 2000; College Slice

Operation Atlas posted:

P.P.S: Using a hidden_field is strongly discouraged as it is probably the easiest thing in the entire world to hack.

Can you expand on this? When you say 'hack' do you mean only that a user would be able to post any office_id, or is it something entirely more devious?

# ? Nov 20, 2009 20:14

Trabisnikof: Dec 24, 2005

atastypie posted:

Can you expand on this? When you say 'hack' do you mean only that a user would be able to post any office_id, or is it something entirely more devious?

It is very easy for a hacker to fake hidden_field data since it is just a normal form element.

# ? Nov 20, 2009 20:17

NotShadowStar: Sep 20, 2000

stack posted:

The being clever bit was my understanding that the rails community wanted to type as little as possible to get things done and that they wanted to take that to the extreme. I swear this will click eventually and it'll get through my thick skull.

That's not entirely true. It's not that Ruby and Rails people want to save as little typing as possible, it is the fact that they want to make it as READABLE as possible. Some methods and variables can be quite long but I can take Rails code that I write and give it to a non-programmer and they can understand it because Ruby and Rails is mostly without all the funky symbols and syntax that you get with other languages.

The reason I asked if you could make it distinct is because the problem you're trying to solve (class-based individual record rights) is a pit of hell that I've been successfully avoiding for a long time, but it's going to hit me sooner or later. AR isn't really good for that straight up, so you'll have to do some funky query manipulations like what we've been talking about, write a plugin to patch monkey-patch AR, or do some funky stuff with subclassing AR table classes. None of which would be fun/easy to do if this is pretty much your My First Rails Project.

# ? Nov 20, 2009 20:24

stack: Nov 28, 2000

I've got another question. Debugging ruby 1.9.1 on Snow Leopard. Has anyone gotten it to work?

trying 'sudo gem install ruby-debug-ide' or 'sudo gem install ruby-debug-ide19' both fail after trying to build native extensions.

# ? Nov 20, 2009 22:40

NotShadowStar: Sep 20, 2000

You really want to live on the edge eh? 1.9.1 sometimes doesn't work with C based extensions, and Snow Leopard broke a bunch of stuff, so it's not surprising.

According to this an older version of the gem probably works on Snow Leopard. So 'gem install ruby-debug-ide --version=0.4.7'

# ? Nov 20, 2009 22:50

Operation Atlas: Dec 17, 2003; Bliss Can Be Bought

stack posted:

I've got another question. Debugging ruby 1.9.1 on Snow Leopard. Has anyone gotten it to work?

trying 'sudo gem install ruby-debug-ide' or 'sudo gem install ruby-debug-ide19' both fail after trying to build native extensions.

http://github.com/mark-moseley/ruby-debug

# ? Nov 20, 2009 23:27

acts_as_sentient: Nov 20, 2009

So how many people here use RoR in their production environments at work? I understand that it is used on quite a few large sites, but for a company like the one I work for, I would imagine the constant upgrades/changing API would cause problems with a us as we host many, 520+, sites and are constantly signing up more.

I use RoR for my personal coding and I love it. But I can afford to upgrade the few applications I maintain in order to work with more current code. I think that managing sites that all have different versions would be hard to do in production.

# ? Nov 20, 2009 23:50

Operation Atlas: Dec 17, 2003; Bliss Can Be Bought

acts_as_sentient posted:

So how many people here use RoR in their production environments at work? I understand that it is used on quite a few large sites, but for a company like the one I work for, I would imagine the constant upgrades/changing API would cause problems with a us as we host many, 520+, sites and are constantly signing up more.

I use RoR for my personal coding and I love it. But I can afford to upgrade the few applications I maintain in order to work with more current code. I think that managing sites that all have different versions would be hard to do in production.

I use it at work for production- we're a medical device company. So far we've had no problem getting Rails past the FDA. It has worked out great so far.

# ? Nov 21, 2009 04:26

hmm yes: Dec 2, 2000; College Slice

Trabisnikof posted:

It is very easy for a hacker to fake hidden_field data since it is just a normal form element.

Yeah, I knew this. Doesn't seem that big a deal in many situations.

I use Rails in production and wish I had picked some other framework to specialize in 3 years ago when I started out. Simply put, Rails is a pain to deploy and maintain. This is especially true if you aren't using a VPS where you can put on your server administrator hat. Chances are though, you will be responsible for hosting any apps you write for a client. Ruby is an awesome language to work with but it still operates in this tiny little niche of the internet and it doesn't seem to be expanding out of it.

I still love Rails...but it is one of those desperate, volatile relationships that crime of passion stories are based on.

hmm yes fucked around with this message at 05:34 on Nov 21, 2009

# ? Nov 21, 2009 05:31

skidooer: Aug 6, 2001

atastypie posted:

Simply put, Rails is a pain to deploy and maintain.

Really? That may have been once true, but I don't think it is really a problem anymore. I threw an app up on Heroku for fun. It is incredibly slick in that respect. Deploying your app is not much more difficult than typing "git push heroku master".

# ? Nov 21, 2009 07:04

Operation Atlas: Dec 17, 2003; Bliss Can Be Bought

atastypie posted:

You're doing it wrong.

# ? Nov 21, 2009 07:19

Sewer Adventure: Aug 25, 2004

atastypie posted:

Yeah, I knew this. Doesn't seem that big a deal in many situations.

I use Rails in production and wish I had picked some other framework to specialize in 3 years ago when I started out. Simply put, Rails is a pain to deploy and maintain. This is especially true if you aren't using a VPS where you can put on your server administrator hat. Chances are though, you will be responsible for hosting any apps you write for a client. Ruby is an awesome language to work with but it still operates in this tiny little niche of the internet and it doesn't seem to be expanding out of it.

I still love Rails...but it is one of those desperate, volatile relationships that crime of passion stories are based on.

heroku

# ? Nov 21, 2009 08:48

hmm yes: Dec 2, 2000; College Slice

Heroku is cool, but it is incredibly expensive. Is a fair solution to rails deployment problems 'you just didn't throw enough money at it'? Moving my hosted apps over to Heroku would move my costs from $75/month to $500/month. Eep

Operation Atlas posted:

You're doing it wrong.

Mostly

skidooer posted:

Deploying your app is not much more difficult than typing "git push heroku master".

I can also deploy using capistrano in a similar fashion, and I do. I guess my point was more something like this: ever tried to run a Rails app on something other than your own VPS or rails specialty hosting? It's awful. You are either a server admin or you get hosed on hosting costs. If you're fine with either of those choices, rails deployment/production isn't going to be an issue for you.

# ? Nov 21, 2009 16:55

Hop Pocket: Sep 23, 2003

Figuring out rails deployment with Capistrano and whatever combination of Apache/Nginx & Passenger/Thin/Mongrel really only takes a couple of hours to fully grok it and a little practice. Admittedly, it's not as easy as deploying a PHP application, but I'd say the initial time investment is similar to deploying a Tomcat/WAR application (when you take into account the Ant setup).

In the grand scheme of things, the time investment is negligible compared to the time of app development. Learn it, set up your deployment, and then it's super easy (e.g. cap deploy:migrations).

Deploying to a shared host is a pain and probably will be because of gem dependencies and god knows what kind of crazy setup they have. If you're on a dedicated server or VPS, though, I think that the argument of Rails being incredibly difficult to deploy is probably past its time, especially with Apache/Passenger.

# ? Nov 21, 2009 17:34

Pardot: Jul 25, 2001

Hop Pocket posted:

Rails being incredibly difficult to deploy is probably past its time, especially with Apache/Passenger.

Yeah, it hasn't been bad since we got mongrel, and what's come since has been great.

That fastcgi poo poo was awful though.

# ? Nov 21, 2009 18:44

NotShadowStar: Sep 20, 2000

I loving hate working with Apache but if other people do the pain I'll work with it. I'm moving all of my Rails apps to a more secure facility in the institution where they do the administration and configure things how I want then leave me alone, BUT I don't have root. They use RHEL5 so Ruby is laughably out of date. All I did was:

Build a new Ruby 1.9.1 in the www user dir as ruby-1.9.1(not necessary as the system 1.8.5 Ruby works but...)
Install rubygems in the www user dir
make symlinks in the www dir to the ruby 1.9.1
Install Passenger
Symlink the passenger module

Then
Ask the system administrator to add the Passenger lines to the apache config by using the symlinked Ruby and Passenger
Ask them to make sure AllowOveride All is enabled for the www public folder
Ask them to restart Apache

Done. Now I'm totally independent. If I want to deploy a Rails app sub-uri, I copy the Rails app into the www dir and symlink the public dir from the Rails app to the public dir in the www folder, add PassengerEnabled On in the htaccess for that folder, and boom. Done. I can upgrade/downgrade Ruby at will, add/remove gems at will, and upgrade Passenger. All I need to do is ask the administrator to bounce Apache.

In a shared hosting situation like Dreamhost they do all of everything for you with Passenger, so all you need to do is start deploying Rails apps with PassengerEnabled on in htaccess.

Also, if you're in library hell with Rails, you're doing it wrong. You can freeze EVERYTHING into a Rails app from Rails itself and all the dependencies and have it running exactly the same for absolutely forever from the day you deploy it. The only thing you can't do RIGHT NOW is natively-built gems, but thanks to Yehuda's brilliant Gem Bundler you can do that now, too with a little back-porting work.

# ? Nov 21, 2009 21:27

acts_as_sentient: Nov 20, 2009

But that doesn't really answer my question. At my current job we rely on the codebase that we have been developing on for years. If we were on RoR - then our codebase may break on future versions and then if we needed to backport newer code to older sites, we would have to, yet again, re-write the portions of the codebase for the older RoR install.

So our options are either that or to just not upgrade RoR - but that may lock ourselves out of using 3rd party components that depend on a newer version.

I guess my question is: has this caused others pain? By the sounds of it it hasn't - but I would like to hear it from a person who is in a similar situation as me.

# ? Nov 21, 2009 23:33

Pardot: Jul 25, 2001

acts_as_sentient posted:

But that doesn't really answer my question. At my current job we rely on the codebase that we have been developing on for years. If we were on RoR - then our codebase may break on future versions and then if we needed to backport newer code to older sites, we would have to, yet again, re-write the portions of the codebase for the older RoR install.

So our options are either that or to just not upgrade RoR - but that may lock ourselves out of using 3rd party components that depend on a newer version.

I guess my question is: has this caused others pain? By the sounds of it it hasn't - but I would like to hear it from a person who is in a similar situation as me.

You're going to have that problem with any framework or library though, there's nothing special about rails.

You have 2 options, first wait for big releases, and fix what breaks, or checkout edge rails into your vendor directory and continuously keep updated, fixing little things over a longer period.

# ? Nov 22, 2009 00:02

NotShadowStar: Sep 20, 2000

acts_as_sentient posted:

But that doesn't really answer my question. At my current job we rely on the codebase that we have been developing on for years. If we were on RoR - then our codebase may break on future versions and then if we needed to backport newer code to older sites, we would have to, yet again, re-write the portions of the codebase for the older RoR install.

So our options are either that or to just not upgrade RoR - but that may lock ourselves out of using 3rd party components that depend on a newer version.

I guess my question is: has this caused others pain? By the sounds of it it hasn't - but I would like to hear it from a person who is in a similar situation as me.

I guess I'm not understanding what you're doing. Say you have an app on Rails 1.x. It will continue to work forever. If you need to do some work on it and don't want to keep Rails 1 around, you can then clone that app to your local system since Rails is awesome and self-contains everything, remove Rails 1.x if it's frozen, freeze in the latest Rails to see if things break.

How do you know if things break? Run your tests and fix what fails. Tada, you're now on the latest Rails. If you don't have tests then that's a very good place to start before you even start modifying the app again, because if you're in long term maintenance with a production app you better have tests in or you're going to break things no matter if you update Rails or not.

Rails makes all of this really easy to do. I can't think of how you'd even start to do something like this in a non-CakePHP or non-Spring Java app anyway.

# ? Nov 22, 2009 00:17

acts_as_sentient: Nov 20, 2009

My concern is that Rails changes more frequently then any other framework (that I would consider using) - and certainly it changes more frequently then any other language (for home-brew frameworks). Having 520+ sites in rails land all with a wide variety of versions sounds like a challenge to me; but it may be because I'm not used to thinking in the "Rails-way" in the context of production websites. Perhaps I'll give it a harder look as it doesn't sound like many people have trouble with this.

# ? Nov 22, 2009 00:26

NotShadowStar: Sep 20, 2000

Instead of the philosophy of immediacy pervasive in PHP, production Rails apps should be treated as such:

1) Deploy it
2) Leave it the gently caress alone

Then

-Do I need to modify the app? (Y/N)
N: LEAVE IT THE gently caress ALONE
Y: -Do I need to update rails (Y/N)
Y: Update Rails, fix failing tests if needed. Update libraries if needed.
N: Make app modifications, then go to redeploy step

There's a pervasive attitude towards aspie-like developers. OH RAILS 3.0 SHINY I'LL UPDATE ALL MY APPS gently caress EVERYTHING BROKE. Which is why the first one is so important:

DO YOU NEED TO DO ANYTHING TO THE APP?
LEAVE IT THE gently caress ALONE

# ? Nov 22, 2009 00:57

Mrs. Wynand: Nov 23, 2002; DLT 4EVA

I just wanted to chime in to say that i hate ActiveRecord::Errors. I hate it. Hate it hate it hate it hate it. Actually, Rails' whole approach to validation is kinda misguided, but the errors API and message composition bits in particular are just so loving awful.

I could write at length about this but I'm too busy to really get into it now

I probably will over the winter break though, because there's just not enough political will in the rails-core crowd to fix this poo poo up properly and soon and it really needs doing.

It's been 4 (or 5, i can't quite remember) with rails now, and having been in it close to the ground floor has done truly wonderful things to my employability and salary prospects but I am, more and more, deeply regretting not having specialized in python instead

I know the grass is always greener on the other side but I dunno man, the lib support, the industry take-up, the language development process is soooo much better. Also, let's face it, speed. Whatever neat syntax tricks ruby can show off that python can't quite match simply don't justify the other drawbacks... Have you guys seen SQL Alchemy? It makes ActiveRecord look like a bad joke. Just in general, if you want to do anything other then web dev and scripting with ruby you're not gonna find much, certainly nothing of quality - it's very difficult to branch out to other fields with just ruby. RubyGame really ain't PyGame, let me tell you that. There's no high-performance or low-overhead interpreters suitable for bulk work or embedded systems. Or PEPs - wouldn't it be nice to have REPs or something you know just anything other then poorly translated updates every 3 years of the changelog matz dreamed up since the last release. Figuring out what motivated the changes is of course left as an exercise to the reader.

Anyway, these things are usually not too big a deal and I'll probably stick to ruby for quite a while longer, but some times I just run into what I've come to call "lovely ruby library bullshit" like AR:Errors and it makes me feel :saddowns:

# ? Nov 24, 2009 00:55

NotShadowStar: Sep 20, 2000

Mr. Wynand posted:

Just in general, if you want to do anything other then web dev and scripting with ruby you're not gonna find much, certainly nothing of quality - it's very difficult to branch out to other fields with just ruby.

W...
I...
Bu....
Nuuuuuuuufffff

Click here for the full 400x295 image.

# ? Nov 24, 2009 02:49

Mrs. Wynand: Nov 23, 2002; DLT 4EVA

why what non-web thing do you do with ruby that's so awesome and at least on par with python? genuinely curious

# ? Nov 24, 2009 05:14

NotShadowStar: Sep 20, 2000

Have you even heard of Cucumber?

# ? Nov 24, 2009 05:20

Mrs. Wynand: Nov 23, 2002; DLT 4EVA

Actually yes, we use it extensively - it is quite nice. A friend of mine made a decent python port mind you - cuke itself isn't that complicated. I'd also mention that I've not really seen it be used for anything but testing web apps although I'm well aware it's possible.

Rspec has some neatness to it as well, so let's throw that in as well.

So what else?

# ? Nov 24, 2009 07:31

Operation Atlas: Dec 17, 2003; Bliss Can Be Bought

Yeah the Rails validation thing really pisses me the hell off. There was a ticket and patch for a small change to validations, and I came in and added a whole bunch to it, mostly so that you can introspect the validations (so you can put *required notices next to fields that are required, etc). It was a good patch, well-tested, and got 3 or 4 +1's, but didn't make it in because someone else was "redoing" the entire validation framework. As far as I can tell, that project never got close to completion, and we'll be stuck with the same lovely validation framework for Rails 3.

I've been using CouchDB lately and have written my own ORM with a deliciously simple yet effective error handling system. The fact that ActiveRecord resorts to metaprogramming to solve this very simple problem is emblematic of everything that is wrong with Rails.

I'm hopefully going to be releasing the ORM in the next month or two, but this is what the implementation looks like:

code:

class User < Mudskipper::Model
  string :username do
    identifier
    required
    unique
  end
  password :password
end

As opposed to the AR version, which is a migration, and a nasty User class that looks something like this:

code:

class User < ActiveRecord::Base
  validates_presence_of :username
  validates_uniqueness_of :username
  validates_presence_of :password, :message => "must be at least 6 characters long"

  attr_accessor :unencrypted_password

  require 'digest/sha1'
  def self.encrypt(a_value)
    Digest::SHA1.hexdigest(a_value)
  end

  before_validation :encrypt
  def encrypt
    if !unencrypted_password.blank? && unencrypted_password.size >= 6
      self.password = self.class.encrypt(unencrypted_password)
    end
    true
  end
end

And that's even without salting. Common poo poo like password hashing should be handled by the framework. Blocks are beautiful and AR (and Rails in general) don't use them to their full potential.

Operation Atlas fucked around with this message at 22:54 on Nov 24, 2009

# ? Nov 24, 2009 15:29

Mrs. Wynand: Nov 23, 2002; DLT 4EVA

I took a crack at ActiveModel::Validations myself a while back, especially ActiveModel::Errors. I didn't have the energy to push it through though - rails-core is kinda apprehensive about big changes, and in retrospect I probably should have done something more familiar looking for starters. This is kinda the trouble with fixing it - there's a fair bit of momentum built up behind the existing way of doing things, and although it can be pushed back, it requires more then a little effort to drum up the support (that is on top of actually writing and testing the patch).

Also, I gotta say, I'm actually 100% in favour of migrations. Unless you only have one machine to develop and deploy on, or it's ok for your app to just nuke all its data every now and then, they are way way better then trying to "magically" update the schema when the model code changes. Although there are a few trivial cases you can make a fairly safe guess, like say adding a brand new column, in my experience there's usually more non-trivial operations you need to perform - like say populating that new column from existing data you have to infer or otherwise process. So in the end you really do need something like migrations anyway - and you gotta ask yourself what the auto-migration from the model really buys you, considering those kind of changes, since they are essentially trivial, are trivial to express as regular migration and auto-migrations are still prone to gently caress up and assume the wrong thing.

Even when I was using couch-db with jaxer (a pure js framework) I ended up using something akin to migrations

# ? Nov 24, 2009 23:36

Mrs. Wynand: Nov 23, 2002; DLT 4EVA

I just realized what a grumpy neck-beard I've become

I blame YOU David Heinenmeir Hanson!

# ? Nov 24, 2009 23:38

NotShadowStar: Sep 20, 2000

Yeah I really didn't know what to say to you. It looked like you were doing the argument of 'give me an example, oh well yeah okay now give me ANOTHER example because PYTHON :smug:

' and I wasn't going to deal with it.

Yeah, now that we've been looking at Rails and it's components for a few years there's some warts. Remember that all of Rails including AR was designed by DHH like 5 years ago by himself, so of course another pair of eyes is going to come up with something better on a particular aspect than that one person could think of at that time. But it's impossible to overstate how much Rails changed the way we think about web apps, poo poo even Microsoft's flagship ASP.NET MVC is so similar to Rails I was astonished when I looked into it.

I think with Rails 3 the biggest push is to be more like Merb so it's even easier to use non-defaults. Don't like AR? Use Datamapper. Like some AR and some Datamapper and some Couch? Use all of it, who cares. You can kind of do this already but you have to know what you're doing first. I would guess after sweeping Rails 3 the team would be more apt to thinking about lancing off some warts.

# ? Nov 24, 2009 23:49

Operation Atlas: Dec 17, 2003; Bliss Can Be Bought

With couchdb you don't really need migrations- if you do it right you can keep older objects in the older schema and only update the database record when necessary, and when they get saved they get saved in the new schema.

Kind of hard to explain unless you've done an ORM that does that, but migrations truly aren't necessary if you plan ahead correctly.

# ? Nov 24, 2009 23:52

Adbot: ADBOT LOVES YOU

# ? May 15, 2024 08:27

Mrs. Wynand: Nov 23, 2002; DLT 4EVA

NotShadowStar posted:

Yeah I really didn't know what to say to you. It looked like you were doing the argument of 'give me an example, oh well yeah okay now give me ANOTHER example because PYTHON ' and I wasn't going to deal with it.

Yeah, now that we've been looking at Rails and it's components for a few years there's some warts. Remember that all of Rails including AR was designed by DHH like 5 years ago by himself, so of course another pair of eyes is going to come up with something better on a particular aspect than that one person could think of at that time. But it's impossible to overstate how much Rails changed the way we think about web apps, poo poo even Microsoft's flagship ASP.NET MVC is so similar to Rails I was astonished when I looked into it.

I think with Rails 3 the biggest push is to be more like Merb so it's even easier to use non-defaults. Don't like AR? Use Datamapper. Like some AR and some Datamapper and some Couch? Use all of it, who cares. You can kind of do this already but you have to know what you're doing first. I would guess after sweeping Rails 3 the team would be more apt to thinking about lancing off some warts.

I know that sounded silly but cucumber really is one of the few exceptions... And it really isn't that I think PYTHON is all that hot poo poo, nor that rails far isn't perfect (django seems to have comparable levels of fuckups) - I'm just frustrated at ruby's lack of breadth and maturity and i don't think that's a headexplode.gif-worthy statement :colbert:

But like i already said, these things are usually not too big a deal... usually.

# ? Nov 25, 2009 00:02

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

«‹›178 »