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

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

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.

Not invented here: Apple’s secret applications

In case you don’t want to read the whole article, here is the summary: This guy from Computerworld just talking about Apple’s secret on the software titles which Apple is generally using.

Seriously, I’d love to know the list of program that Apple are using, but the theme of that article is just so wrong; the writer tends to wrote in the tone that make Apple, a software company, should write every piece of software that they’re using by themselves.

Don’t believe me? Go back and read it yourself. I’ll sit here and sip a coffee waiting for you.

The Real Truth

One question that I’m going to ask if you’re a developer: What kind of tools you’re currently using everyday? I believe you can give me the list of all sorts of tools that you’re using, such as Adobe Photoshop, Open Office, Netbeans, Vim, Emacs, etc. And since we’re the developer, why don’t we develop our own Photoshop-like application?

Well, because Photoshop is a professional tool, and it’s usable out of the box!¹

In nowadays, there’re so many tools that you can use to develop your application. You could buy it, or use an open source alternative. It just the matter of choice. Those tools are well-created and they’re helping you to get your job done as soon as you can.

Now, looking back at Apple. Do you think Apple has the employee power to write every software they are using? Yes they do! But why aren’t they? ..

Because they believes that they should spend those time creating something else!

What’s I’m really meant to say

Sorry, but I’m not going to say that that post is bullshit misleading. As a software developer, I think you should remember this: If it’s already exists, and working great, then go ahead and use it!

For example, if you’re finding yourself having to write something up, let’s say “authentication system” for example, the first thing you’re going to do is not thinking about how to implements it yourself, but go to GitHub and try to find the one that fits your need.

Why am I suggesting this? Because when you’re developing one yourself, you just wasting your time creating something that’s already written.² Also, you never know that you might left a hole somewhere in your application, which would normally be patched already in those library/plugin. If you found any bug, then contact the developer and help them to get it fixed. It won’t only benefit you; It will also helping out other users that using the same piece of library as you do.

Remember, don’t wasting your time, use something that already exists to create something cool. It will definitely benefits you; and our planet.

[1] I said it’s usable, but I don’t think it’s bug-free. I still getting crashes with cryptic error message once in a while.

[2]: If it’s not exists, then pat yourself in the back, as you’d have to write one yourself.

Box Photo from PC Site @ Flickr under CC-BY-SA

ปล. เป็นรูปเซฟจาก Twitter Stream … แต่ว่ามันไม่ได้ต่อเนื่อง (จบในตอน) เพราะฉะนั้นจะอ่านจากล่างขึ้นบน หรือบนลงล่างก็ตามสะดวกครับ

อ่านแล้วก็ได้ข้อคิดหลายๆ อย่างเหมือนกัน ขอบคุณมากครับ

ถ้าใครเคยเห็น code ภาษา Ruby นั้น คงจะเคยเห็นว่า Ruby นั้นมีทั้ง operator && และ || เหมือนกับในภาษา C แล้วยังมี and กับ or ที่เพิ่มเข้ามาใน Ruby ซึ่งเป็นสิ่งที่ทำให้โค้ดนั้นดูสวยงามขึ้น อ่านง่ายขึ้นตามหลักของ Ruby

ลองดูโค้ดด้านล่างนี้เป็นตัวอย่างครับ

irb(main):001:0> dessert = "Cheesecake"
=> "Cheesecake"
irb(main):002:0> drink = "Coffee"
=> "Coffee"
irb(main):003:0> dessert == "Cheesecake" && drink == "Tea"
=> false
irb(main):004:0> dessert == "Cheesecake" and drink == "Tea"
=> false

จะเห็นได้ว่า && และ and นั้นให้ผลลัพธ์ที่เหมือนกัน ทำให้บางครั้งเราสามารถใช้ and มาแทนที่ && และ or มาแทนที่ || ได้

แต่ entry นี้มันชื่อ Operator Precedence … เพราะฉะนั้นเรื่องราวมันไม่ได้จบแค่นี้ครับ คำถามต่อไปคือ คุณคิดว่าค่าของตัวแปร first_order และ second_order จะเป็นอย่างไร ในคำสั่งต่อไปนี้:

first_order = dessert == "Cheesecake" && drink == "Tea"
second_order = dessert == "Cheesecake" and drink == "Tea"

คำตอบลองดูในนี้เลยครับ:

irb(main):005:0> first_order = dessert == "Cheesecake" && drink == "Tea"
=> false
irb(main):006:0> second_order = dessert == "Cheesecake" and drink == "Tea"
=> false
irb(main):007:0> first_order
=> false
irb(main):008:0> second_order
=> true

อะไรนี่ 0_o!

จะเห็นได้จากบรรทัดที่ 005 และ 006 ว่า ทั้งคู่ก็คืนค่าออกมาเป็น false ทั้งนั้น แล้วทำไมค่าที่เก็บใน first_order กับ second_order มันกลับไม่เหมือนกัน

คำตอบคือ เป็นเพราะ Operator Precedence ของ Ruby ครับ

เหตุผลที่ second_order นั้นมีค่าเป็น true นั้น เพราะว่าใน Ruby นั้น เครื่องหมาย = จะมีลำดับขั้นที่สูงกว่า and และ or ครับ

กล่าวคือ ในการเขียน statement ว่า

>> second_order = dessert == "Cheesecake" and drink == "Tea"

เจ้าตัว Ruby Interpreter นั้น จะทำการ evaluate ออกมาเป็นอย่างนี้

001> second_order = dessert == "Cheesecake" and drink == "Tea"
002> (second_order = dessert == "Cheesecake") and drink == "Tea"
003> true and drink == "Tea"
004> false

เพราะฉะนั้น คำสั่งข้างต้นที่ใช้ and นั้น ถ้าอยากให้มีผลเช่นเดียวกับ && จำเป็นที่จะต้องใส่วงเล็บครอบให้เป็นอย่างนี้ครับ

>> second_order = (dessert == "Cheesecake" and drink == "Tea")

มีคนชอบบอกว่า Ruby เป็นภาษาที่แปลก … ผมเชื่อแล้วแหละว่าแปลกจริงๆ

Post.find(:all)    # หรือว่า Post.all ก็ได้ ใน Rails 2.x

ซึ่งตรงนี้ ถ้าเราไปดูใน Log file จะพบว่า ActiveRecord นั้น จะใช้คำสั่งค้นหาข้อมูลประมาณนี้ครับ

  Post Load (0.1ms)   SELECT * FROM "posts"

(ผมใช่ sqlite3 เพราะฉะนั้น table name/field name จะถูกใส่ไว้ใน quote ครับ)

ถ้าสมมุติในโปรแกรมนั้น เราได้ทำ Association ระหว่าง Post และ Comment (Post has many comments) และระหว่าง Comment กับ User (comment belongs to user)

class Post < ActiveRecord::Base
  has_many :comments
 
  # ...
 
end
 
class Comment < ActiveRecord::Base
  belongs_to :post
  belongs_to :user
 
  # ...
 
end

ถ้าเราต้องการจะแสดงผล comment แต่ละอันด้วย เราก็สามารถทำได้โดยเรียกเมธอด #comments ที่ถูกสร้างขึ้นมาอัตโนมัติโดยการทำ association และเช่นเดียวกัน ถ้าเราต้องการแสดงด้วยว่า comment นั้นถูกเขียนโดยใคร เราก็สามารถเรียกเมธอด #user บน comment เช่นกัน

<% Post.find(:all).each do |post| %>
  <!-- display post -->
  <% post.comments.each do |comment| %>
    By: <%= comment.user.username %>
    <!-- display comments -->
  <% end %>
<% end %>

คราวนี้ สมมุติว่าบล็อกเรามีทั้งหมด 10 Post แล้วแต่ละอันมี 5 comment … SQL ที่ออกมานั้น จะเป็นประมาณนี้ครับ

  Post Load (0.1ms)   SELECT * FROM "posts"
  Comment Load (0.5ms)   SELECT * FROM "comments" WHERE ("comments".
"post_id" = '1')
  User Load (0.2ms)   SELECT * FROM "users" WHERE ("user"."id" = '5')
  User Load (0.2ms)   SELECT * FROM "users" WHERE ("user"."id" = '24')
  User Load (0.2ms)   SELECT * FROM "users" WHERE ("user"."id" = '30')
  User Load (0.2ms)   SELECT * FROM "users" WHERE ("user"."id" = '4')
  CACHE (0.0ms)   SELECT * FROM "users" WHERE ("user"."id" = '5')
  Comment Load (0.3ms)   SELECT * FROM "comments" WHERE ("comments".
"post_id" = '2')
  User Load (0.2ms)   SELECT * FROM "users" WHERE ("user"."id" = '38')
  User Load (0.2ms)   SELECT * FROM "users" WHERE ("user"."id" = '14')
  User Load (0.2ms)   SELECT * FROM "users" WHERE ("user"."id" = '40')
  User Load (0.2ms)   SELECT * FROM "users" WHERE ("user"."id" = '2')
  User Load (0.2ms)   SELECT * FROM "users" WHERE ("user"."id" = '9')
  ...

จะเห็นได้ว่า ในสถานการณ์ที่แย่ที่สุดนั้น (user ที่มา comment แต่ละ post นั้น ไม่ตรงกันเลย เป็นต้น) ActiveRecord จำเป็นต้องทำการ Query ทั้งหมด 1 + 10 + (10 * 5) = 61 ครั้ง ซึ่งไม่มีประสิทธิภาพเลยครับ เพราะเปลือง Query มากมาย

ดังนั้น เพื่อให้ Query ทั้งหมดนี่มีประสิทธิภาพมากขึ้น ActiveRecord จึงมี key หนึ่งชื่อว่า :include เอาไว้สำหรับสั่งว่าให้ ActiveRecord นั้นทำการโหลด Model ที่ associates กับ object นี้ขึ้นมาด้วยพร้อมๆ กันเลย เพื่อประหยัด Query ครับ เพราะฉะนั้นโค้ดในการค้นหาของเราจะเปลี่ยนเป็น

Post.find(:all, :include => {:comments => :user}).each do |post|
  # ... display post
  post.comments.each do |comment|
    By: <%= comment.user.username %>
    # ... display comments
  end
end

แล้วผลของมันน่ะหรอครับ? 61 query -> 3 queries ครับ!

  Post Load (0.1ms)   SELECT * FROM "posts"
  Comment Load (0.3ms)   SELECT * FROM "comments" WHERE ("comments".
"post_id" IN (1, 2, 3, 4, 5))
  User Load (1.3ms)   SELECT * FROM "users" WHERE ("user"."id" IN (5, 24,
30, 4, 2, 38, 14, 40, 2, 9, 23, 41, 48, 50, 32, 10, 48)

เพราะฉะนั้นการใช้ :include นั้น เป็นการ optimize query อย่างได้ผลทีเดียวละครับ โดยจะเห็นได้ว่าเรายังสามารถโหลด model แบบ nested ได้โดยการใช้ Hash และโหลดโมเดลหลายๆ อันพร้อมกันโดยใช้ Array ครับ อย่างเช่นถ้าเราต้องการโหลด Attachments จาก Comment และโหลด Tags จาก Post ด้วย เราก็สามารถใช้คำสั่งอย่างนี้ได้ครับ

Post.find(:all, :include => [{:comments => [:user, :attachments]}, 
:tags])

คำเตือน: Use it, but don’t abuse it!

ในบางครั้ง การใช้ :include นั้น อาจจะทำให้เวลาในการ query นั้นลดลงได้ถ้าเทียบกับการ query object เล็กๆ หลายๆ ครั้งแทน เพราะฉะนั้นมันไม่ใช่สิ่งที่เวิร์คที่สุดครับ ต้องปรับใช้ให้เข้ากับงานซะมากกว่า โดยที่ผมแนะนำให้ใช้ #find method ตามปกติก่อน แล้วจึงค่อยเพิ่ม :include เข้าไปถ้าเราเห็นว่ามีการ query record จำนวนมากๆครับ … ถือซะว่าการใช้ :include นั้นเป็นการ refactor code ครับ และไม่ใช่สิ่งที่ต้องมาคิดตั้งแต่แรกว่าตรงนี้ต้องใช้มันหรือไม่