"Like" mechanism.

My DropThot project will primarily be driven by a "like" system. Thots will be ordered by likes and by time-span, and comments on thots will also be ranked by likes. I know there are gems out there that implements this (e.g. act_as_votable), but for learning purposes I'm coding everything by hand.

I thought implementing likes would be very straight forward, but it's a little bit more complicated than I thought. In my case, I'm using a polymorphic association for my Like model because I need to implement likes for both thots and comments. I'm sure there are other ways to do it, such as a Likable class/model that the Thot and Comment models inherits from, but I think this is my preferred way of doing it.

Here's how my Like spec looks like so far:

describe Like do
  let(:user)  { FactoryGirl.create(:user) }
  let(:other) { FactoryGirl.create(:user) }
  let(:thot)  { other.thots.build(content: "This is an interesting thot.") }

  before { @like = user.likes.build(likable: thot) }

  subject { @like }

  it { should be_valid }
  it { should respond_to :likable }
  it { should respond_to :likable_type }
  it { should respond_to :user }
  it { should respond_to :user_id }

  its(:user)    { should == user }
  its(:likable) { should == thot }

  describe "liking your own thot" do
    before do
      own_thot = user.thots.build(content: "This is my own thot.")
      @like = user.likes.build(likable: own_thot)
    end

    it { should_not be_valid }
  end
end

I initially ran into a problem with FactoryGirl with creating multiple users (since users cannot have same username or email). A quick google helped solve this.

Instead of:

factory :user do
  name "Alex"
  email "alex@ucla.edu"
  password "uclabruins"
  password_confirmation "uclabruins"
end

Do:

factory :user do
  sequence(:name)  { |n| "Alex#{n}" }
  sequence(:email) { |n| "alex#{n}@ucla.edu" }
  password "uclabruins"
  password_confirmation "uclabruins"
end

The sequence method in factories.rb makes it so that you can continue creating new users via FactoryGirl without running into validation problems.

This was just a quick blog post to help me outline my thinking process and to jog my brain for next steps; which will be to finish the like mechanism and the proper buttons. After that's done, it should open the doors to the rest of my app's functionality.

DropThot, my next web app.

I'm attempting to build a web application (dropthot.herokuapp.com) similar to ruminations.com before it closed down. Basically it's going to be an app where people can post their random day-to-day thoughts, upvote thoughts, and follow other users. More info on the project's Github page: http://github.com/alexsung/dropthot

This time I'm actually doing test-driven development, with RSpec, and trying out the new Rails 4.0!

I've been using Michael Hartl's tutorial (ruby.railstutorial.org) as a reference, since my app's functionality is somewhat similar to his. However, I've ran into a few issues so far.

For example, testing in RSpec:

describe "when email is already taken" do
    before do
      user_same_email = @user.dup
      user_same_email.name = "different_name"
      user_same_email.save
    end

    it { should_not be_valid }
end

Running this spec caused a problem, because the 4th line saves user_same_email to the test database, and then fails more specs the next run because of the persisting duplicate email address in the database.

Running "rake test:prepare" seems to fix it temporarily, but running the specs more than once results in a failure. I didn't have this issue when I was using Rails 3.2 on Michael Hartl's tutorial, so I'm assuming it's because of Rails 4. It makes sense because my tests run much faster in Rails 4 than in 3.2, so I'm guessing Rails 4 doesn't automatically clear the test database each time you run your specs. (edit/correction at the bottom of post)

I enjoy the fast test times since I can't get Spork to work with Rails 4, so I'm okay with this as long as I find a simple solution.

describe "when email is already taken" do
    before do
      @user_same_email = @user.dup
      @user_same_email.name = "different_name"
      @user_same_email.save
    end

    it { should_not be_valid }
    after { @user_same_email.destroy } # Changed to instance variable due to variable scope
end

That works.

Edit: It appears that the version of RSpec I was using (2.13.0) was the problem. I have updated my RSpec to 2.14.0.rc1 and it now works fine; my tests run equally fast and the test database clears between each run as expected.

The First Post: Why Ruby on Rails?

It was a few months after graduation in 2012 when I discovered Ruby on Rails. I was immediately impressed by the community and also surprised at how pleasant it was to code in Ruby. Having taken classes in Java and C++  in high school and college, I've always had a somewhat misguided impression of what programming really was.

However, learning Ruby showed me that programming can actually be fun, expressive, and even artistic.

So after some contemplation, I decided, "forget finance and marketing. I'm going into web development."
Because I knew this was something I would actually enjoy doing full-time.

Well, that and also the fact that the current job market clearly needs more web devs. I'm always looking to learn new things, so why not learn some new valuable skills and contribute to a great demand? All the resources I need are already at the tip of my fingers.

I have learned basic programming and made websites before all of this, but I really started to dig into web development in late 2012. Since then, I've been studying everything from Ruby to jQuery. Needless to say, it has been quite an overwhelming experience, but I think I'm beginning to have a solid foundation for everything.

A couple examples of web apps I've built:
www.lightshow.me, a for-fun project I built using Wordpress and PhpBB3 before getting into Rails.
And during my self-education for the past many months, I developed a real Ruby on Rails app for my mini-business, www.inkmasks.com. It was done using the Spree Commerce gem which took care of most of the e-commerce functionality, so it felt a bit like cheating. That's not to say I didn't learn a lot; I definitely gained valuable experience taking a real application from scratch to production.

The next step will be for me to build a Rails app the old-fashioned way—implementing the main functionality with my own code instead of using a gem.