Ruby on Rails Love-In

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

«‹›178 »

8ender: Sep 24, 2003; clown is watching you sleep

BrokenDynasty posted:

I've had great experience with SpeedyRails. Their support is pretty quick and very responsive.

I have four servers with them right now and they're amazing. I think they're robots because someone named Doan or Maykel are on my poo poo within 5 minutes even at 2am. Servers are fast and I haven't experience a second of downtime since I started with them six months ago.

Best part though: They are a fully managed VPS service. This means you can horse around installing gems and such but if poo poo hits the fan or you run out of talent they can take it from there. I had them installing an SSL certificate a month back while I was in a junkyard pulling car parts just using my phone to forward the right emails to them. There is something magical about that.

# ? Nov 20, 2010 22:39

Adbot: ADBOT LOVES YOU

# ? May 13, 2024 23:39

Tomed2000: Jun 24, 2002

NotShadowStar posted:

You want has_many :through

HABTM is mostly for legacy join tables and are pretty fragile.

Building many-to-many forms is complex and I recommend [url=github.com/justinfrench/formtastic] Formtastic to take a lot of the pain out of it, at least figuring out how it's supposed to be constructed.

Thanks, I got pretty far with this but had another question or two.

When a user creates a new Item they can add users that they want to send it to:

I'm basically just saying <%= f.input :users %> and it's showing some weird reference to the users -- how do I tell it to show each user's email, for example?

Once I figure out this I guess the next step is to move away from a select list and implement the "to:" field as a text box where you're able to input some number of email addresses separated by white space or a semicolon. Any direction here would be much appreciated.

Thanks!

edit: fixed the first problem by adding a to_s method to the User model. Not sure if this is the proper way to fix it but it seems good. Still could use some help with the second task.

Tomed2000 fucked around with this message at 20:49 on Nov 21, 2010

# ? Nov 21, 2010 20:07

NotShadowStar: Sep 20, 2000

Tomed2000 posted:

Thanks, I got pretty far with this but had another question or two.

When a user creates a new Item they can add users that they want to send it to:

I'm basically just saying <%= f.input :users %> and it's showing some weird reference to the users -- how do I tell it to show each user's email, for example?

Once I figure out this I guess the next step is to move away from a select list and implement the "to:" field as a text box where you're able to input some number of email addresses separated by white space or a semicolon. Any direction here would be much appreciated.

Thanks!

edit: fixed the first problem by adding a to_s method to the User model. Not sure if this is the proper way to fix it but it seems good. Still could use some help with the task.

Yeah, I use a to_s method as well when using Formtastic. There's an option in the formtastic builder somewhere that I forget, but to_s is a convenient thing to have in your models.

You're going to either have to have your controller parse the text field and populate the model appropriately on create or update, or have some Javascript going to make the text field just a dummy entry field for searching like any other webmail like thing and populate hidden fields with recipient IDs.

# ? Nov 21, 2010 20:45

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

Anveo posted:

You can also just use it locally in development mode. Just browse a few pages and then go to /newrelic. It will at least give you more context than just eyeballing the code and logs.

I'll try to keep you guys up to date on what my method ends up being, I'm going to try and avoid newrelic for now. It seems to be the go to application for my specific use request, but I'm feeling a little bit heretic.

Thanks everyone for the advice, I really appreciate it. Serious.

# ? Nov 23, 2010 20:17

BrokenDynasty: Dec 25, 2003

8ender posted:

I have four servers with them right now and they're amazing. I think they're robots because someone named Doan or Maykel are on my poo poo within 5 minutes even at 2am. Servers are fast and I haven't experience a second of downtime since I started with them six months ago.

Best part though: They are a fully managed VPS service. This means you can horse around installing gems and such but if poo poo hits the fan or you run out of talent they can take it from there. I had them installing an SSL certificate a month back while I was in a junkyard pulling car parts just using my phone to forward the right emails to them. There is something magical about that.

Oh god I heart Maykel (Doan's great too, but he's not the one for me). I am pretty sure they are the most advanced form of AI the world have ever known. All I know is, I already anticipate the sadness where they are popular enough that their service level starts to slip

But that doesn't stop me from spreading the wealth.

# ? Nov 23, 2010 20:22

8ender: Sep 24, 2003; clown is watching you sleep

BrokenDynasty posted:

Oh god I heart Maykel (Doan's great too, but he's not the one for me). I am pretty sure they are the most advanced form of AI the world have ever known. All I know is, I already anticipate the sadness where they are popular enough that their service level starts to slip But that doesn't stop me from spreading the wealth.

Yeah Doan is okay, Maykel is a sweetheart :allears:

I'm also hoping their service never slips. Its a fantastic setup and their service alone lets me hire lots of developers without worrying about infrastructure people.

# ? Nov 23, 2010 22:31

smug forum asshole: Jan 15, 2005

HAML is going to make me roughly a thousand times happier and more productive and have a more enjoyable time writing code for the web and make me a better dude using ruby.

This is really how I feel after taking like 30 minutes and learning what I was doing, and converting a project. It's no longer obnoxious to write views. I feel like I'm being freed from the constraints of thinking about rails as rail--i am more able to think of it as ruby code.

smug forum asshole fucked around with this message at 22:43 on Nov 25, 2010

# ? Nov 25, 2010 22:41

8ender: Sep 24, 2003; clown is watching you sleep

I've got a strange problem with some checkboxes and could use another set of eyes. I've got three models that are sort of like this:

code:

class Plan < ActiveRecord::Base
   has_many :plan_requirements
   has_many :requirements, :through => :plan_requirements
   accepts_nested_attributes_for :plan_requirements, :reject_if => proc { |attributes| attributes['requirement_id'] == '0' }
end

class PlanRequirement < ActiveRecord:Base
   belongs_to :plan
   belongs_to :requirement
end

class Requirement
   has_many :plan_requirements
   has_many :plans, :through => :plan_requirements
end

Requirements are a static list of requirements. I'm using accepts_nested_attributes to allow a checkbox list of requirements when a plan is being created.

The controller new method has this bit of code in it:

code:

    @reqs = current_org.requirements.find_all_by_enabled(true)
    @requirements.each do |r|
      @plan.plan_requirements.build(:requirement => c)
    end

Which lets me have a nice fresh list of requirements with checkboxes, using this view code:

code:

  <% f.fields_for :plan_requirements do |f_req| %>
      <div class="requirement">
        <%= f_req.check_box :requirement_id, {:checked => false}, f_req.object.requirement_id %>
        <label class="req_name"><%= f_req.object.requirement.name %></label>
      </div>
    <% end %>

This all works really well. Checking off requirements and saving them adds them to the join table just fine using the create method. All is well until its time to edit the plan later. I use a different bit of code here:

First the edit method of the controller uses similar code but I'm removing requirements that already exist in the Plan to avoid duplicates:

code:

    @reqs = current_org.requirements.find_all_by_enabled(true)
    @requirements.each do |r|
      @plan.plan_requirements.build(:requirement => c) if !@plan.plan_requirement.include?(c)
    end

and then the view code, which is also a bit different so that the requirements already added are pre-populated.

code:

  <% f.fields_for :plan_requirements do |f_req| %>
      <div class="requirement">
        <%= f_req.check_box :requirement_id, {:checked => @plan.plan_requirements.include?(f_req.object.requirement)}, f_req.object.requirement_id %>
        <label class="req_name"><%= f_req.object.requirement.name %></label>
      </div>
    <% end %>

I know this code is pretty inefficient right now, but I'm not even at the stage of making it fast because when it goes to update I have a big problem.

That reject_if I have in the model earlier? It just doesn't seem to work properly during an update. What is happening is that if I uncheck a requirement when editing it simply replaces the requirement_id with a zero for that row in the join table and leaves it at that instead of actually deleting the record.

I've tried turning on :autosave amongst other fixes. The only fix I have working right now is an :after_save method in the PlanRequirement model that checks for a zero value and destroys the record.

I feel like this is a really lovely solution and I'm really making this hard in myself. I also know that once I put proper unique constraints on that join table my hackly fix is going to crash and burn. I've been fooling around with this stupid code for a few hours now and I just know I'm missing something obvious here. Any ideas?

8ender fucked around with this message at 03:48 on Nov 26, 2010

# ? Nov 26, 2010 03:45

NotShadowStar: Sep 20, 2000

For one, you have to be careful with checkboxes. Although they might make better sense from a UI perpsective, they're hell on the HTTP level. This is because by HTTP design an unchecked box is never submitted. Rails gets around this by creating a hidden field, described here. Read it carefully, it has implications for mass assignment that you're trying to do.

A cleaner option that's a bit more clumsy on the UI side but much nicer on the development side is to have a multiple select instead of checkboxes.

# ? Nov 28, 2010 17:56

8ender: Sep 24, 2003; clown is watching you sleep

Oh I'm definitely aware of the hell that is checkboxes. I used to manually do the hidden field thing when I coded in PL/SQL.

Problem is that the UI is already built around the checkboxes. I really don't want to redo it.

Has anyone here successfully used checkboxes in rails 2 for both creation and editing a has_Many through association? I feel like this is something that would have come up before.

# ? Nov 28, 2010 18:50

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

smug forum rear end in a top hat posted:

HAML is going to make me roughly a thousand times happier and more productive and have a more enjoyable time writing code for the web and make me a better dude using ruby.

This is really how I feel after taking like 30 minutes and learning what I was doing, and converting a project. It's no longer obnoxious to write views. I feel like I'm being freed from the constraints of thinking about rails as rail--i am more able to think of it as ruby code.

One of the truly surprising things I've found out about haml recently is that it renders nearly as fast as erb. The increases in development speed and tidiness easily makes up for what imperceivable differences in speed there allegedly are, in my opinion.

Variables and colour maths in sass are great:

code:

$green = #00FF00

.bordered
  :border-color $green -20
  :background-color $green + 20

Makes a darker border and light interior for a box.

I love it

Haml should be bundled with rails...

# ? Nov 29, 2010 02:17

smug forum asshole: Jan 15, 2005

Nolgthorn posted:

Haml should be bundled with rails...

can someone please explain why haml isn't literally the default markup system used in rails?

# ? Nov 29, 2010 02:21

NotShadowStar: Sep 20, 2000

Some people really, really, really hate significant whitespace. It's true.

Also ERB makes things less confusing for newcomers as it's like ASP or JSP templates. Trying to decipher HAML, which is pretty Ruby centric and learning the Rails framework would be confusing as gently caress to Java plebeians :smug:

It's really not that big of a deal. gem 'haml' in your gemfile, bundle install on a new project and you're off. If you're using some generator-like thing that only spits ERB, html2haml fixes it right up.

# ? Nov 29, 2010 02:30

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

8ender posted:

I feel like this is a really lovely solution and I'm really making this hard in myself. I also know that once I put proper unique constraints on that join table my hackly fix is going to crash and burn. I've been fooling around with this stupid code for a few hours now and I just know I'm missing something obvious here. Any ideas?

Your solution feels complicated. Are you sure something more like this isn't really what you want/need? You may have over thought your solution significantly. In plan.rb:

code:

def requirement_ids=(requirement_ids)
  plan_requirements.each do |plan_requirement|
    plan_requirement.destroy unless requirement_ids.include? plan_requirement.requirement_id
  end

  requirement_ids.each do |requirement_id|
    self.plan_requirements.create(:requirement_id => requirement_id) unless plan_requirements.any? { |d| d.requirement_id == requirement_id }
  end
end

Nolgthorn fucked around with this message at 02:45 on Nov 29, 2010

# ? Nov 29, 2010 02:40

8ender: Sep 24, 2003; clown is watching you sleep

Nolgthorn posted:

Your solution feels complicated. Are you sure something more like this isn't really what you want/need? You may have over thought your solution significantly. In plan.rb:
code:
def requirement_ids=(requirement_ids)
  plan_requirements.each do |plan_requirement|
    plan_requirement.destroy unless requirement_ids.include? plan_requirement.requirement_id
  end

  requirement_ids.each do |requirement_id|
    self.plan_requirements.create(:requirement_id => requirement_id) unless plan_requirements.any? { |d| d.requirement_id == requirement_id }
  end
end

Very likely I'm overcomplicating things here. Its a bad habit from Java that I'm still trying to shake. I'm getting better though because at least I know its overcomplicated :unsmith:

I may have run out of talent figuring out your solution here. I see that you're first destroying any requirements that aren't in a set of ids and then creating the ones that are missing. The connection I'm having trouble making is how I'd practically use this with mass assignment. ActiveRecord seems to be doing its own thing here.

Edit: Wait, I think I get it. Rather than going through the trouble of mass assignment I just use the code above as the setter and iterate through the requirements in my view creating a checkbox for each then assign to the model method in my controller?

8ender fucked around with this message at 07:20 on Nov 29, 2010

# ? Nov 29, 2010 05:46

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

8ender posted:

Very likely I'm overcomplicating things here. Its a bad habit from Java that I'm still trying to shake. I'm getting better though because at least I know its overcomplicated

I may have run out of talent figuring out your solution here. I see that you're first destroying any requirements that aren't in a set of ids and then creating the ones that are missing. The connection I'm having trouble making is how I'd practically use this with mass assignment. ActiveRecord seems to be doing its own thing here.

Edit: Wait, I think I get it. Rather than going through the trouble of mass assignment I just use the code above as the setter and iterate through the requirements in my view creating a checkbox for each then assign to the model method in my controller?

I'd just create checkboxes (named "plan[requirement_ids][]") that work the traditional way, where unchecked ones do not get sent with the form. Make sure there's one checkbox for each requirement. Part of the idea is that this then gets sent to the plan model when you save, as if it were a column in the plan table. Um er, except it's an array! And we capture that/override the default behaviour so that upon assignment we iterate through each of the ids and create or destroy a plan_requirement object for it.

So, er that's all you need.

It'd look something like this:

code:

class Plan < ActiveRecord::Base
   has_many :plan_requirements
   has_many :requirements, :through => :plan_requirements
end

class PlanRequirement < ActiveRecord:Base
   belongs_to :plan
   belongs_to :requirement
end

class Requirement
   has_many :plan_requirements
   has_many :plans, :through => :plan_requirements
end

code:

def edit
  @plan = Plan.find(params[:id])
end

def update
  params[:plan][:requirement_ids] ||= []
  @plan = Plan.find(params[:id])
  if @plan.update_attributes(params[:plan])
    flash[:notice] = 'Plan was successfully updated.'
    redirect_to :action => 'edit', :id => @plan
  else
    render :action => 'edit'
  end
end

code:

<% Requirement.find(:all).each do |requirement| %>
  <div class="requirement">
    <input type="checkbox" name="plan[requirement_ids][]" value="<%= requirement.id %>" // Table breakage
<% if @plan.requirements.include?(requirement) %> checked="checked" <% end %>>
    <label class="req_name"><%= requirement.name %></label>
  </div>
<% end %>

That is probably a big mess.

I hope I'm not screwing you up, this is a really really old method of doing this. You need to include "params[:plan][:requirement_ids] ||= []" at the top of your update method, in case no checkboxes are selected. It assigns requirement_ids to an empty array if no array exists, so that the model will destroy anything that used to be checked.

Ah now that I've done this I'm sure there's a more modern way. Manually constructing checkboxes feels wrong. Then again I've moved to Rails 3. Maybe the solution today is a Rails 3 method. Or even still. Maybe there is a newer solution that DOES use the 1/0 automatically generated checkboxes and this solution I've posted is just a horrible hackish out of date embarrassing crappy solution.

:black101:

Nolgthorn fucked around with this message at 15:22 on Nov 29, 2010

# ? Nov 29, 2010 15:16

8ender: Sep 24, 2003; clown is watching you sleep

Nolgthorn posted:

Ah now that I've done this I'm sure there's a more modern way. Manually constructing checkboxes feels wrong. Then again I've moved to Rails 3. Maybe the solution today is a Rails 3 method. Or even still. Maybe there is a newer solution that DOES use the 1/0 automatically generated checkboxes and this solution I've posted is just a horrible hackish out of date embarrassing crappy solution.

Its kind of funny because one of my developers used something just like this for checkboxes in another project and I was going to speak to her about it today because I felt it seemed like kind of a round about way to do it. Now I'm being hoisted by my own petard here because the Rails approved way doesn't work without hacks and this manual way stops the bad data from even hitting the database. It may be an old and brutish method but it certainly looks like it gets the job done in a much more straightforward way. Thank you.

Looks like I'm well on my way to being the :corsair:

boss that shouldn't be allowed to touch the code anymore. :v:

8ender fucked around with this message at 15:24 on Nov 29, 2010

# ? Nov 29, 2010 15:22

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

Respond_to is one of my other very favourite things in the world aside from haml/sass.

code:

before_filter :find_blog_post, :only => [:show, :edit, :update, :destroy]
respond_to :html

def index
  @blog_posts = BlogPost.order("created_at DESC")
  respond_with(@blog_posts)
end

def show
  respond_with(@blog_post)
end

def new
  @blog_post = BlogPost.new
  respond_with(@blog_post)
end

def edit
  respond_with(@blog_post)
end

def create
  @blog_post = BlogPost.create(params[:blog_post])
  respond_with(@blog_post)
end

def update
  @blog_post.update_attributes(params[:blog_post])
  respond_with(@blog_post)
end

def destroy
  @blog_post.destroy
  respond_with(@blog_post, :location => root_url)
end

protected
def find_blog_post
  @blog_post = BlogPost.find(params[:id])
end

# ? Nov 29, 2010 15:45

8ender: Sep 24, 2003; clown is watching you sleep

Ooh, I like that one too. One thing I really like about Ruby and Rails is that the community seems so concerned about good technique. Standard operating procedure for Java was to either write code until a problem goes away or dive so deep into the object oriented rabbit hole that your code became a sort of wondrous Rube Goldberg machine that would confuse and frustrate other developers.

On that note, one more question. The technique Nolgthorn just posted looks great, but it looks like adding code to respond with XML as well would leave you in almost the same place as the "official" scaffold generated code. Do most of you separate your API and HTML code or try to double duty like the scaffold code does?

# ? Nov 29, 2010 15:54

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

respond_to :html, :xml

bwahahahaha.

Here is a great example of how it works. http://railscasts.com/episodes/224-controllers-in-rails-3

# ? Nov 29, 2010 16:13

8ender: Sep 24, 2003; clown is watching you sleep

Lookit you fancy pants with Rails 3. No wonder I didn't know about that. :mad:

# ? Nov 29, 2010 16:24

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

Aw I'm only joking. If it weren't for Java developers going through what I would consider hell for so long we would not be where we are today with Rails.

I appreciate you. :glomp:

# ? Nov 29, 2010 16:42

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

I just watched the Railscast for Mongoid and MongoDB. Now I am considering updating my entire almost complete very complicated Rails application to use it.

http://railscasts.com/episodes/238-mongoid

Will that be a mistake? Time-wise? Should I stick with what I have and consider updating later on? Will that be impossible? Is there really a lot less benefit to using MongoDB than I am imagining? Will I benefit more than I could ever imagine from updating? Is Mongoid too new and will restrict me too much? Is there a guide for moving to Mongoid?

Currently I am using ActiveRecord and Postgresql. Thank you for the advice.

# ? Nov 29, 2010 17:18

enki42: Jun 11, 2001; #ATMLIVESMATTER

Put this Nazi-lover on ignore immediately!

Nolgthorn posted:

respond_to :html, :xml

bwahahahaha.

Here is a great example of how it works. http://railscasts.com/episodes/224-controllers-in-rails-3

With InheritedResources it gets even more insane. Here's an entire REST controller, that talks HTML, json and xml. It auto-wires up everything to do with manipulating the models provided that your controller and models are named well.

code:

class CampaignsController < InheritedResources::Base
  respond_to :html, :json, :xml
end

# ? Nov 29, 2010 20:09

bitprophet: Jul 22, 2004; Taco Defender

Nolgthorn posted:

I just watched the Railscast for Mongoid and MongoDB. Now I am considering updating my entire almost complete very complicated Rails application to use it.

[...]

Currently I am using ActiveRecord and Postgresql. Thank you for the advice.

The general rule of thumb is that if you have to ask "should I use (Mongo|Couch|Cassandra|Riak|whatever)", you don't need to use (Mongo|Couch|...). NoSQL is not a magic panacea that will suddenly make your application more awesome or sparkly or whatnot.

Such tools fill a specific niche of use cases (and all of them slightly different ones, too) and it seems that most legit uses are are situations where the devs go "ugh, my current application/infrastructure using an RDBMS is falling down here and there and oh man, if only I had a distributed key-value store, I could do this and it would work so much better!". Can't say for sure without knowing more, but that doesn't sound like you

Honestly, by using Postgres instead of MySQL you're already ahead of the game, I'd stay there. Playing with NoSQL is always great, but I sure as hell would not switch a production or near-production app to a NoSQL setup without a clear understanding of what RDBMS failings you're addressing by doing so.

# ? Nov 29, 2010 20:16

8ender: Sep 24, 2003; clown is watching you sleep

Nolgthorn posted:

Your solution feels complicated. Are you sure something more like this isn't really what you want/need? You may have over thought your solution significantly. In plan.rb:
code:
def requirement_ids=(requirement_ids)
  plan_requirements.each do |plan_requirement|
    plan_requirement.destroy unless requirement_ids.include? plan_requirement.requirement_id
  end

  requirement_ids.each do |requirement_id|
    self.plan_requirements.create(:requirement_id => requirement_id) unless plan_requirements.any? { |d| d.requirement_id == requirement_id }
  end
end

Just an update to this. It works, but only on an update. On create ActiveRecord gets huffy because the parent model hasn't been created yet. So I modified it:

code:

after_save :assign_requirements

def requirement_ids=(requirement_ids)
  @new_requirements = requirement_ids
end

def assign_requirements
  plan_requirements.each do |plan_requirement|
  plan_requirement.destroy unless @new_requirements.include? plan_requirement.requirement_id
end

 @new_requirements.each do |requirement_id|
    self.plan_requirements.create(:requirement_id => requirement_id) unless plan_requirements.any? { |d| d.requirement_id == requirement_id }
  end
end

Works awesome. The technique may be old but its reduced the amount of code in my controller and model significantly. Its also a few less db queries. Good stuff.

# ? Nov 29, 2010 20:18

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

bitprophet posted:

The general rule of thumb is that if you have to ask "should I use (Mongo|Couch|Cassandra|Riak|whatever)", you don't need to use (Mongo|Couch|...). NoSQL is not a magic panacea that will suddenly make your application more awesome or sparkly or whatnot.

Such tools fill a specific niche of use cases (and all of them slightly different ones, too) and it seems that most legit uses are are situations where the devs go "ugh, my current application/infrastructure using an RDBMS is falling down here and there and oh man, if only I had a distributed key-value store, I could do this and it would work so much better!". Can't say for sure without knowing more, but that doesn't sound like you

Honestly, by using Postgres instead of MySQL you're already ahead of the game, I'd stay there. Playing with NoSQL is always great, but I sure as hell would not switch a production or near-production app to a NoSQL setup without a clear understanding of what RDBMS failings you're addressing by doing so.

I dunno what to say, I'm sort of flying off faith right now. Switching to using a document oriented data store just feels right for my project.

My project has tons and tons of places in models that are abstracted out. Like there are a ton of thingys that all are "watchable" and some of those those watchable thingys are items which can by ordered via a polymorphic join and all this type of stuff. For example:

code:

thought.rb
class Thought < ActiveRecord::Base
  include UniqueToken
  include Itemable
  include Linkable #link_submitted
  include Commentable
  include Watchable

  attr_accessible :content, :link_submitted
  validates :content, :presence => true, :length => {:maximum => APP[:max_default_content_length]}

  scope :has_includes, include_item
end

concerns/unique_token.rb
module UniqueToken
  def self.included(base)
    base.before_create :create_new_unique_token
    base.after_create :set_unique_token
  
    def base.find_unique_token(unique_token)
      result = self.find_by_unique_token(unique_token)
      raise ActiveRecord::RecordNotFound, "Couldn't find object with unique token: #{unique_token}" unless result
      result
    end
  end
  
  def to_param
    self.unique_token
  end
  
  protected
  def create_new_unique_token
    until @new_unique_token and (self.class.where("unique_token = ?", @new_unique_token).count == 0)
      @new_unique_token = ActiveSupport::SecureRandom.hex(10)
    end
    self.unique_token = @new_unique_token
  end
  
  def set_unique_token
    self.update_attribute(:unique_token, @new_unique_token)
  end
end

concerns/itemable.rb
module Itemable
  [...]
end

etc.

And each of those includes at the top of my models has a different set of functionality that some models have and other models don't have.

I mean the whole unique token concept just by itself, which is the user facing key appears to be pretty much standard functionality in MongoDB. The tons and tons of eager loading I do and the huge tables I have in some places... it all feels like I'm using the wrong tool for the job. With all the rave reviews about how document oriented storage 'fits better' with object oriented programming makes it sound good. Regardless of how little I know about it. (I don't know anything about it.)

If document oriented storage is the new hotness I feel like I am missing out by not noticing it before now. I have never liked table-storage. I also feel like if this new hotness keeps progressing and becoming the norm then it would not be good to be trapped using SQL in such a complicated application. Potentially I would be much better off using MongoDB instead.

Potentially it could benefit, right?

# ? Nov 29, 2010 20:45

rugbert: Mar 26, 2003; yea, fuck you

edit - nvm

rugbert fucked around with this message at 21:42 on Dec 1, 2010

# ? Nov 30, 2010 18:54

h_double: Jul 27, 2001

Can somebody recommend a good to-the-point guide on setting up a basic blog-style site with Rails?

# ? Dec 2, 2010 23:23

rugbert: Mar 26, 2003; yea, fuck you

Im looking for a good text editor like tinymce, that can insert images and links from a controller. So if I had my array of images in @images and click the insert image button, it would give me a list of images.

# ? Dec 3, 2010 23:43

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

h_double posted:

Can somebody recommend a good to-the-point guide on setting up a basic blog-style site with Rails?

code:

rails new blog
rails g scaffold Post title:string content:text
rails s

Then visit your site using localhost:3000 in a web browser.

Well it's almost that easy.

Honestly I don't think a blog style-site example has been done since way back in Rails 1. That was the original tutorial that was intended to pull everyone over to Rails.

Someone should re-do that original tutorial.

Edit: Here is an up to date guide on the Rails website: http://guides.rubyonrails.org/getting_started.html#creating-the-blog-application

Nolgthorn fucked around with this message at 04:52 on Dec 4, 2010

# ? Dec 4, 2010 04:47

enki42: Jun 11, 2001; #ATMLIVESMATTER

Put this Nazi-lover on ignore immediately!

h_double posted:

Can somebody recommend a good to-the-point guide on setting up a basic blog-style site with Rails?

railstutorial.org is the canonical online tutorial, and a twitter style site really isn't that far off a blog (allow more characters than twitter and don't let everyone sign up for an account)

# ? Dec 4, 2010 15:27

Tomed2000: Jun 24, 2002

I feel like this is a stupid question but I can't figure out how to do it in Rails. Some background:

I'm working on a project that emulates email. Basically you can create an "email" and send it to other people on the site. I do this through a has_many :through association like so:

code:

class Item < ActiveRecord::Base
  has_many :users, :through => :emails
end

class User < ActiveRecord::Base
  has_many :items, :through => :emails
end

class Email < ActiveRecord::Base
  belongs_to :user
  belongs_to :item
end

Creating an "email" looks like this:

Once you select some users to send an email to, it populates the item's user_ids array which is available because of the association.

What I want to do is change the select box (which I'm using formtastic to produce) to a text field where you can enter email addresses separated by commas (like GMail) and parse the string in the controller. The problem is that if I just put in some random text_field (for example a text_field titled ":tofield") then it will just give me an error like "Model Item does not respond to tofield".

Basically how do I make make a text_field that isn't part of the item model so that I can parse the string in the controller?

# ? Dec 4, 2010 17:07

NotShadowStar: Sep 20, 2000

text_field_tag

# ? Dec 4, 2010 19:21

rugbert: Mar 26, 2003; yea, fuck you

Does anyone know why using the jquery version of tinyMCE would prevent me from being able to update any fields using it. I dont get any javascript errors in firefox error console, and the ruby console shows that the update action IS being called, but the tinyMCE'd field remains unchanged.

edit - Got it. Including the javascript file twice fucks everything up.

rugbert fucked around with this message at 22:17 on Dec 4, 2010

# ? Dec 4, 2010 22:09

czarmonger: Aug 16, 2008; ask me about my brothel

I wouldn't be posting here as well if the "Hire a Developer" thread had more activity. I am sorry if this is ban-worthy, I just wanted as many ruby developers looking for work to see this as possible.

I need a Ruby-On-Rails developer. Check out my post to see the deets.

# ? Dec 5, 2010 00:04

Nolgthorn: Jan 30, 2001; The pendulum of the mind alternates between sense and nonsense

I want to take a minute and gush about Mongoid and MongoDB. Partly because I'm still working to learn it as I implement it into my site. Partly I'm really not experienced enough to write what my progress is on any kind of professional blog. Partly there doesn't seem to be very many people using this technology yet and there should be.

Mongoid is solving all kinds of problems I was having, right off the cuff. For one thing, it's way way faster.

Every user on my site has unique whitelists and blacklists of who they want to see. With all of the comments which appear underneath of any object in my application, those need to be filtered for each user individually. So, for instance it is difficult to determine what page of the comments someone should be sent to, in order to pick up from where they were last reading. Every user had a different number of comments showing. The solution of course is to perform two queries to get the comments. The first is a count of all the comments that are needed and the second is a collection of the comments that are needed to display.

Due to the fact that the comments in Mongoid are embedded with that object they are associated with, I only need one query to get not only all the comments but also the object which all those comments are embedded in. That is in contrast with the three queries I needed otherwise. That doesn't take into account all the other data it is now possible to associate and embed directly with the object that has comments on it. So there's not any eager loading or multiple queries, it's a beautiful thing.

There isn't a great deal of changes I need to make to my controllers to fit in the new db, because it still uses nearly the same querying structure as Active record. It works differently behind the scenes more so than through direct modification of my code. An object would be acquired and all associated data comes with it. When I ask for the comments where the user is such and such there is no further query required. It just parses the information which is already logged in memory.

I love the way that inheritance and the openness of polymorphic associations works in Mongoid. I have a lot of different objects that all used to be associated with a polymorphic table that I used to get all the objects together and display in a sort of feed. Now I can simply have an Item model and have my other objects all inherit from it. Then I can use 'Item' later to get all of the objects, or I can still specify the individual types of objects instead if I need only a certain type.

It's like magic!

The more I think about it, the less I understand how it possibly all works, but it works well. Good job Mongoid and MongoDB teams. I'll keep you updated as to when I hit the inevitable too good to be true part.

# ? Dec 5, 2010 04:04

Tomed2000: Jun 24, 2002

NotShadowStar posted:

text_field_tag

Thanks, got it working!

Tomed2000 fucked around with this message at 21:44 on Dec 5, 2010

# ? Dec 5, 2010 19:21

8ender: Sep 24, 2003; clown is watching you sleep

Nolgthorn posted:

The more I think about it, the less I understand how it possibly all works, but it works well. Good job Mongoid and MongoDB teams. I'll keep you updated as to when I hit the inevitable too good to be true part.

I'm excited to hear more about this. When I play around with things like MongoDB I feel more and more that there is a possibility that in the future the "database" might just be completely built into the Rails stack rather than being some standalone entity that Rails queries.

I wonder how big this NoSQL thing will get before Oracle, Microsoft, and IBM start to meddle?

# ? Dec 6, 2010 02:43

Adbot: ADBOT LOVES YOU

# ? May 13, 2024 23:39

NotShadowStar: Sep 20, 2000

Approximately never, they have people too tied into selling DB2/SQL Server/Oracle Enterprise. Huge entities with enormous customer bases don't tend to latch on to newer better technologies well.

Although I wish that the latest trend in shoving javascript into loving EVERYTHING will go away, like having it be the front-end to your database store that these new and shiny NoSQL things have. What the HELL.

_{You can make Javascript decent but why bother when there's Lua, IO, Lisp and much better functional languages about}

NotShadowStar fucked around with this message at 04:57 on Dec 6, 2010

# ? Dec 6, 2010 04:55

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

«‹›178 »