After I found that Heroku actually supports HTTP Post hook, I spend 2 hours reading API and hacking into hoptoad_notifier code. And now, I would like to presents you Hoptoad ❤ Heroku.

What is it?

It’s a middleware application that will converts parameters from Heroku’s HTTP Post hook to parameters that Hoptoad would understand.

How to use it?

You just add the HTTP Post deploy hook to your Heroku project. It should look something like this:

heroku addons:add deployhooks:http url=http://hoptoad-loves.heroku.com/YOUR_HOPTOAD_API_KEY/YOUR_RACK_ENV

You’d then substitute YOUR_HOPTOAD_API_KEY and YOUR_RACK_ENV to match your configuration.

You can find more information on GitHub or the site itself: http://hoptoad-loves.heroku.com/

(Please note that Hoptoad deploy tracking feature is only available in their paid plans.)

I hope you found it useful for your project. All of the code is hosted on GitHub. Contributions and feedbacks are always welcome.

         new_user_session GET    /users/sign_in(.:format)          {:action=>"new", :controller=>"devise/sessions"}
             user_session POST   /users/sign_in(.:format)          {:action=>"create", :controller=>"devise/sessions"}
     destroy_user_session GET    /users/sign_out(.:format)         {:action=>"destroy", :controller=>"devise/sessions"}
            user_password POST   /users/password(.:format)         {:action=>"create", :controller=>"devise/passwords"}
        new_user_password GET    /users/password/new(.:format)     {:action=>"new", :controller=>"devise/passwords"}
       edit_user_password GET    /users/password/edit(.:format)    {:action=>"edit", :controller=>"devise/passwords"}
                          PUT    /users/password(.:format)         {:action=>"update", :controller=>"devise/passwords"}
 cancel_user_registration GET    /users/cancel(.:format)           {:action=>"cancel", :controller=>"devise/registrations"}
        user_registration POST   /users(.:format)                  {:action=>"create", :controller=>"devise/registrations"}
    new_user_registration GET    /users/sign_up(.:format)          {:action=>"new", :controller=>"devise/registrations"}
   edit_user_registration GET    /users/edit(.:format)             {:action=>"edit", :controller=>"devise/registrations"}
                          PUT    /users(.:format)                  {:action=>"update", :controller=>"devise/registrations"}
                          DELETE /users(.:format)                  {:action=>"destroy", :controller=>"devise/registrations"}
        user_confirmation POST   /users/confirmation(.:format)     {:action=>"create", :controller=>"devise/confirmations"}
    new_user_confirmation GET    /users/confirmation/new(.:format) {:action=>"new", :controller=>"devise/confirmations"}
                          GET    /users/confirmation(.:format)     {:action=>"show", :controller=>"devise/confirmations"}

As you can see, all of the routes are defined under /users path. So, I’ve modified my devise route block to this:

devise_for :users, :skip => [:registrations, :sessions] do
  # devise/registrations
  get 'signup' => 'devise/registrations#new', :as => :new_user_registration
  post 'signup' => 'devise/registrations#create', :as => :user_registration
  get 'users/cancel' => 'devise/registrations#cancel', :as => :cancel_user_registration
  get 'users/edit' => 'devise/registrations#edit', :as => :edit_user_registration
  put 'users' => 'devise/registrations#update'
  delete 'users/cancel' => 'devise/registrations#destroy'
 
  # devise/sessions
  get 'signin' => 'devise/sessions#new', :as => :new_user_session
  post 'signin' => 'devise/sessions#create', :as => :user_session
  get 'signout' => 'devise/sessions#destroy', :as => :destroy_user_session
end

Which will yield these routes:

    new_user_registration GET    /signup(.:format)                 {:action=>"new", :controller=>"devise/registrations"}
        user_registration POST   /signup(.:format)                 {:action=>"create", :controller=>"devise/registrations"}
 cancel_user_registration GET    /users/cancel(.:format)           {:controller=>"devise/registrations", :action=>"cancel"}
   edit_user_registration GET    /users/edit(.:format)             {:controller=>"devise/registrations", :action=>"edit"}
                    users PUT    /users(.:format)                  {:action=>"update", :controller=>"devise/registrations"}
             users_cancel DELETE /users/cancel(.:format)           {:controller=>"devise/registrations", :action=>"destroy"}
         new_user_session GET    /signin(.:format)                 {:action=>"new", :controller=>"devise/sessions"}
             user_session POST   /signin(.:format)                 {:action=>"create", :controller=>"devise/sessions"}
     destroy_user_session GET    /signout(.:format)                {:action=>"destroy", :controller=>"devise/sessions"}
            user_password POST   /users/password(.:format)         {:action=>"create", :controller=>"devise/passwords"}
        new_user_password GET    /users/password/new(.:format)     {:action=>"new", :controller=>"devise/passwords"}
       edit_user_password GET    /users/password/edit(.:format)    {:action=>"edit", :controller=>"devise/passwords"}
                          PUT    /users/password(.:format)         {:action=>"update", :controller=>"devise/passwords"}
        user_confirmation POST   /users/confirmation(.:format)     {:action=>"create", :controller=>"devise/confirmations"}
    new_user_confirmation GET    /users/confirmation/new(.:format) {:action=>"new", :controller=>"devise/confirmations"}
                          GET    /users/confirmation(.:format)     {:action=>"show", :controller=>"devise/confirmations"}

I think my new routes is much better. For example, I think user would prefer a path to sign in page to be /signin than /users/sign_in, as it more memorable.

I hope this post would inspire you more about customize Devise’s routes to fit your need.

class Person
end
 
class Student < Person
end
 
class HighSchoolStudent < Student
end

If you’re calling some method that’s undefined, let’s say we’re calling HighSchoolStudent#name Ruby will try to call the method in this order:

1. HighSchoolStudent#name
2. Student#name
3. Person#name
4. Object#name
5. Kernel#name
6. BasicObject#name
7. HighSchoolStudent#method_missing
8. Student#method_missing
9. Person#method_missing
10. Object#method_missing
11. Kernel#method_missing
12. BasicObject#method_missing

From this example, you can see that not explicitly define method and capture it in method_missing might not be good in terms of the performance. So, what should you do?

I think the best way to do it, if you know that this method will get called again, would be define the ‘real’ method after it gets called. That will reduce the call stack starting from the second run, resulting in faster code.

# Let say we're defining method for #*_with_id here
def method_missing(name, *args)
  super if name !~ /_with_id$/
 
  define_method "#{name}_with_id" do
    instance_variable_get(:id) + "-" + instance_variable_get(:name)
  end
end

Hope this will make your code run faster, while still DRY.

• Omniauth — a middleware that help you authenticate user to various SSO sites, such as Facebook Connect, Twitter, Google Account
• Devise — fully-functional authentication system. If you write an app that need authentication, this should be the solution for you. Writing your own authentication is discourage now. More on this later.

I feel like I was saying 3 of them, but I can’t remember the other one. Anyway, don’t forget to dig into RubyGems to find out some great gem to use in your project.

You can download it if you want. This slide is CC-BY-NC-SA (as some photo I use require share-alike license.)

One good question actually was the difference between module and class. Actually, it just that simple — you cannot create object from a module.

Module exists in Ruby to help you DRY up your code.

When you write several classes which have the same functionality, you better take that portion of the code out and put it in a module and include them back into your classes. That’s actually something Ruby coder loves to do — DRY up your code, and make it more maintainable.

If you have any more question, feel free to post them in the comment section. I actually fumbled on my word a lot, because I didn’t get enough sleep last night. If you also want me to clearify something up, please let me know. Anyway, I hope you enjoyed it.

RailsCamp (Thailand) 2010

ดีใจ + ตกใจนิดหน่อย เพราะเป็นโปรเจคที่คิดไว้ตั้งแต่เมื่อ 2-3 ปีที่แล้ว ตั้งแต่เมื่อตอนที่เขียน Rails ใหม่ๆ ว่าอยากให้มีงานที่เป็น Ruby on Rails Community ของคนไทย … ในเมื่อมีคนทำแล้ว ผมก็ขอสนับสนุนเต็มทีครับ ผมคงจะเตรียมเรื่องไปพูดนิดหน่อย ไม่แน่ใจเหมือนกันว่าเรื่องอะไร แต่ถ้าดูจาก Schedule ปัจจุบัน อาจจะได้พูดเรื่อง Behavior Driven Development using Cucumber หรือไม่ก็ Devise เพราะว่าเรื่องใหญ่ๆ อย่าง Rails 3 กับ Ruby 1.9 ได้อาจารย์ @rawitat กับคุณ @neokain พูดไปแล้ว

ไปเจอกันโลด วันเสาร์ที่ 13 พฤศจิกายน 2553 เวลา 9:30-17:00 น. ณ Opendream

ปล. ได้เวลาปัดฝุ่นโปรเจคลับแล้วสินะ

Consider that Post having :title attribute and

class Post < ActiveRecord::Base
  validates_presence_of :title
end

Well, what do you think would be the result of the following expression?

if Post.create(:title => nil)
  puts "Saved!"
else
  puts "Validation error ..."
end

Somehow, I expected "Validation error ..." message from it, but I got "Saved!" Why?

Return value of #create

You need to remember that #create method always return the object itself, which have the id as nil. This, evaluates to true and make our code fail. The solution for this problem would be using #new to create object, and then using #save:

post = Post.new(:title => nil)
if post.save
  puts "Saved!"
else
  puts "Validation error ..."
end

For you one-liner, I think you can do this:

if post = Post.new(:title => nil) && post.save

or (as suggested by shr)

if Post.new(:title => nil).save

The timing couldn’t be better, as we’re celebrating #whyday (@celebratewhyday) tomorrow (Aug 19.) On that day, you would get hacking on something great! It’s the best time to trying to test out your application, or hacking something, using Ruby 1.9.2.

So what’re you waiting for? Download it, install it, and running your application on it. Go grab it while it’s hot!

By the way, if you’re using the awesome RVM (And why shouldn’t you??) Just go ahead and do:

rvm update --head && rvm reload && rvm install 1.9.2 && rvm 1.9.2 --default

And have fun riding on this shiny Ruby! I warn you, it’s slippery.

หลังจากที่ผมนำเสนอเรื่องของการ deprecate options ทั้งหมดของ ActiveRecord#find แล้วเปลี่ยนเป็นเมธอดที่ทำหน้าที่คล้ายๆ กับ named_scope กันไปแล้ว ตอนนี้ผมไปเจอข้อมูลจาก @lifo ซึ่งพูดเพิ่มเติมในเรื่องของเมธอดที่จะถูก deprecated และเมธอดที่ให้ใช้แทนครับ

สิ่งที่จะถูกถอดออกไป

การเรียกใช้ #find โดยมี option hash นั้นจะ deprecated ออกไป

User.find(:first, :where => {:status => "suspended"})

แต่อย่างไรก็ตาม #find method จะยังคงอยู่ โดยคุณสามารถใช้มันเพื่อหา record ตาม ID ได้แทน เช่น

User.find(1)
User.find(3,4,5) # ให้ argument เป็น array ได้แล้ว

การใช้ #find(:first), #find(:all) จะถูกแทนที่ด้วยเมธอด #first, #all

User.find(:first) # => deprecated
User.first # use this

และการใช้เมธอดสำหรับการคำนวณทุกอันนั้น ก็จะไม่รับ argument ที่เป็น hash แล้วเช่นกัน

User.count(:id, :conditions => {:status => "suspended"}) # => deprecated
User.where({:status => "suspended"}).count # use this

แต่ยังคงยกเว้น #count ที่ยังคงรับตัวเลือก :distinct อยู่

นอกจากนั้นการกำหนดค่า named_scope โดยใช้ option hash และเมธอด #scoped_by_xxx และ #default_scope ก็ถูกถอดออกเช่นกัน

# all lines here are deprecated
named_scope :suspended, :conditions => { :status => "suspended" }
default_scope :conditions => "status != 'deleted'"
User.scoped_by_status("suspended")

เมธอดใหม่ทั้งหมด

ActiveRecord ใน Rails 3 นั้น จะมีการเพิ่มเมธอดเหล่านี้

• where
• having
• select
• group
• order
• limit
• offset
• joins
• includes
• lock
• readonly
• from

เมธอดทุกอย่างนั้นสามารถ chain เข้าหากันได้ เพราะฉะนั้นคุณก็จะสามารถทำอย่างนี้ได้

User.where(:status => "suspended").includes(:event_log).limit(15).order(:name)
User.where(:name => "john_doe").joins(:profile)

และเนื่องจาก result ของมันเป็น lazy-loading หมด ทำให้คุณสามารถนำมันไปเก็บในตัวแปร หรือว่าเพิ่ม condition เข้าไปทีหลังได้ โดย SQL จะถูกส่งไปยัง server เมื่อคุณเรียกใช้ #each, #first, #all เท่านั้น

suspended_users = User.where(:status => "suspended")
latest_suspended_users = suspended_users.order("id DESC").limit(5)
 
User.where(:status => "suspended") # ยังไม่ query
User.where(:status => "suspended").all # query แล้ว!

เพราะฉะนั้นถ้าคุณไม่สนใจในเรื่องของการ lazy loading และต้องการจะโหลดข้อมูลลงมาเก็บไว้ใน array ก่อน คุณก็เพียงแค่ใช้ #all ตามหลัง query ของคุณเท่านั้นเอง

suspended_users = User.where(:status => "suspended").all # ข้อมูลถูกเก็บใน suspended_users

named_scope ยังเปลี่ยนไปเป็น scope อีก

นอกจากที่กล่าวมาข้างต้นนั้น ยังมีการเปลี่ยนชื่อเมธอดของ named_scope ให้เป็น scope และรองรับการใช้เมธอดใหม่ของ finder เพราะฉะนั้นจากโค้ด

named_scope :suspended, :conditions => { :status => "suspended" }

ก็ต้องเปลี่ยนไปเป็น

scope :suspended, where({ :status => "suspended"})

นอกจากนั้นยังมีการเพิ่มเติม with_scope และ with_exclusive_scope ซึ่งโค้ดในบล็อกที่ให้มานั้นจะมี scope ตามที่ระบุไว้แทน

with_scope(where( :status => 'suspended')) do
  ...
end

with_exclusive_scope(User.online) do
  ...
end

แล้วเมื่อไรจะต้องเปลี่ยนละเนี่ย …

คุณไม่จำเป็นต้องรีบเปลี่ยนโค้ดในส่วนของการใช้ finder เพราะใน Rails 3.0 นั้น ทุกอย่างยังคงจะใช้ได้ตามปกติ โดยที่มีกำหนดการว่าเมธอดเก่าๆ นั้นจะถูกนำออกไปใน Rails 3.2 ครับ เพราะฉะนั้นคุณก็ยังคงสามารถใช้โค้ดเก่าๆ ในการ query ข้อมูลมาได้ แต่ผมแนะนำว่าค่อยๆ ไล่เปลี่ยนไป ก็จะทำให้โค้ดของคุณพร้อมสำหรับการ upgrade ไปยัง version ใหม่ๆ ครับ

เมื่อก่อนนี้ ถ้าหากเราต้องการที่จะทำ cookie ที่ไม่มีวันหมดอายุ (เช่น remember me) เราจำเป็นที่จะต้องกำหนดเวลาหมดอายุของ cookie เอง เช่น

cookies[:authorization_key] = {
  :value => @user.authorization_key,
  :expires => 20.years.from_now.utc
}

แต่หลังจาก commit ของ DHH อันนี้ ทำให้เราสามารถเขียนใหม่ได้เป็น

cookies.permanent[:authorization_key] = @user.authorization_key

นอกจากนั้น เพื่อเพิ่มความปลอดภัยให้กับ Cookie เราก็ยังสามารถที่จะจับมัน signed หรือพูดง่ายๆ ก็คือเข้ารหัสมันไว้ได้ โดยการใช้เมธอด signed

cookies.signed[:user_id] = @user.id

ที่เยี่ยมไปกว่านั้นคือ การที่ทั้งสองเมธอดนั้นสามารถเชื่อมต่อกันได้ เพราะฉะนั้นตัวอย่างข้างต้นสำหรับ remember me นั้น เราก็สามารถแก้โค้ดให้เป็น

cookies.signed.permanent[:authorization_key] = @user.authorization_key

ซึ่งจะทำให้ cookies[:authorization_key] นั้นถูกเข้ารหัสก่อนที่จะส่งไปยัง web browser

แล้วมันเข้ารหัสกับอะไรล่ะ?

เป็นคำถามที่ดีครับ! Application ใหม่ๆ ที่ถูกสร้างมานั้นจะมีไฟล์ชื่อ cookie_verification_secret.rb อยู่ใน config/initializer ซึ่งมันจะมี key ที่ใช้ในการเข้ารหัสเมื่อใช้คำสั่ง cookies.signed อยู่ เพราะฉะนั้นถ้าเป็น application เก่า สิ่งที่คุณต้องทำก็แค่สร้างไฟล์นี้ขึ้นมาแล้วเพิ่มบรรทัดนี้

ActionController::Base.cookie_verification_secret = 'z3cret';

อย่าลืมเปลี่ยน token ของคุณให้เป็นข้อความยากๆ ที่เดาไม่ได้นะครับ

แล้วถ้ามีการแก้ไข cookie ที่ถูกเข้ารหัสละ?

มันก็จะ verify cookie ไม่ผ่าน แล้วก็จะโยน exception ActiveSupport::MessageVerifier::InvalidSignature มาครับ

ยังมีอะไรอีกเพียบเลยครับที่ยังเหลือให้เขียนถึง อย่าลืมติดตามอ่านตอนต่อๆ ไปนะครับ