上週的PHPConf Taiwan，有幾位朋友在會後問我CoffeeScript要怎麼樣跟 jQuery 之類的 framework 整合在一起，會不會打架? 基本上是不會的，CoffeeScript 寫出來的東西就是 JavaScript，如果會打架，那表示你即使不用 CoffeeScript 來寫也一樣打架了。

我們來看看要怎麼把 jQuery 跟 CoffeeScript 放一起。

請注意，本文有許多個人自以為是的內容，不一定適合每個人，所以請謹慎服用。

我之前工作的某個老闆跟我說過「每次的上台簡報就是一場表演」，這句話我一直記在心裡。既然是表演，表演內容固然很重要，但"說故事"的方法也很重要，不然內容也許真的很棒，但台下卻睡成一團。

不久前看了我的偶像之一Lindsay Fallow(a.k.a Stray)的一份簡報Robotlegs 2 and your brain，真的感覺會做投影片的人就是不一樣，即使人不在現場聽演講，簡報裡也沒有太多的文字說明，光看簡報就能大概知道作者想要表達的意思，這很酷!

所以這回在第一屆的 PHPConf Taiwan上用的投影片，我也想來試一下不同的簡報風格。

我常會笑我老爸老媽每天晚上守著劇情扯到不能再扯的八點檔，然後討論誰的小孩是誰誰誰的私生子，然後誰又是誰的小三。但我自己也好不到哪裡去，即使再忙，也是幾乎每天在看影集。

忘記是從什麼時候開始，我的影集大盤商介紹一些好看的美國影集之後，我就陷入了這個影集無窮迴圈。剛好最近跟朋友們吃飯聊到，於是就來整理一下列表，順便看看我到底浪費了多少生命在上面。

變數

在開始講流程控制之前，要先來看一下在 Python 的變數。

What is Python?

Python 的老爸是，Guido van Rossum，聽說是他在 1989 年的時候的某個聖誕節無聊，然後就設計出這套程式語言，1991 年放出來給大家用，到目前已經有將近 20 年的歷史了。

為什麼要寫 method?

程式碼就這樣一行一行的寫不好嗎? 當你的程式碼超過一定的行數的時候，一行一行的寫就不會是個好的寫法。通常我們會用一個抽象的名詞，來把一群連續或複合的動作給包在一起，這樣一來程式碼變得有系統了，心情也會變得比較好，重點是，會寫 method，就容易會有種變成高手的錯覺!

雖然這也許是玩笑話，但把程式碼整理到 method 裡，程式碼會變得比較好維護，而且也更容易可以重複使用。

不管你用的 Linux/FreeBSD/MacOS/Windows..etc，目前 Python 均有實作品，請至 http://python.org/getit/ 找到適合的平台並下載安裝。

不過，我不得小小抱怨一下，Python 在 Windows 上實在是不怎麼友善，包括我們之後要講的 Django，原本也有給 Windows 的懶人安裝包(Instant Django)，但專案似乎也斷頭了。不過也不是沒有解決方法，如果只是要在 Windows 做練習的話，可參考下一章。

如果你安裝完成，請打開你的終端機視窗，輸入python就可以進入 interactive shell 來試玩一下：

$ python
Python 2.6.1 (r261:67515, Jun 24 2010, 21:47:49)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> "hello python"
'hello python'
>>> 1 + 2
3

在這個 shell 裡面，你可以很容易的就測試一些簡單的程式碼，看看執行結果是不是跟你想像的是一樣的。有趣的是，如果你在 shell 裡輸入 import this 的話：

>>> import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

你可以看到 Tim Peters 寫的 The Zen of Python，內文大概說明了 Python 世界的設計哲學。至於 import 是做什麼用的，我們在後面的單元會再做說明。

除了 shell 之外，我們更常把程式碼儲存成一個檔案，附檔名是 .py，例如我們把下面這段很簡單的程式碼：

#!/usr/bin/python
print "Hello, Python"

用任何文字編輯器打完之後，存檔為 hello.py，然後回到終端機視窗，輸入 python hello.py：

$ python test.py
Hello, Python

每種程式語言一定都要不免俗的來一下 Hello World 打個招呼的，如果在 Java，你可能為了要輸出一行簡單的字，還得寫個類別或方法才行，在 Python，只要一行 print 就搞定了，相當簡單吧 :)

其實老是 Hello World 也沒什麼意義，接下來我們來看一點稍微複雜一點的..

剛好昨天有朋友問到，就順便筆記一下。

Ruby 官方文件很多，但有時對入門的朋友來說，常會遇到「我想看看 XX 方法的詳細用法，我該找哪個類別或模組的文件?」的問題。簡單的說，「常翻文件」就是這個問題最好的答案啦，除此之外，你也可以使用 Object#method 來找。

例如我想要知道 puts 這個很常用的方法是定義在哪邊的：

print method(:puts) # <Method: Object(Kernel)#puts>

它會回傳一個 Method 類別的實體，並且寫著 Object(Kernel)#puts，表示這個 puts 方法是被定義在 Object 的(事實上是在 Kernel，透過 Mixin 混到 Object 裡的)

回傳的這個 Method 類別實體其實也可以直接呼叫，例如：

my_puts = method(:puts)
my_puts.call("Hello Ruby")

另外在寫 Rails 的時候，有時候想要知道某個好用的方法或 helper 是放在哪邊，想看看原始碼是怎麼寫的，也可以透過這個方式(Ruby 1.9 限定)：

require 'active_support/all'
puts 10.day.method(:ago).source_location

# ["/Users/eddie/.rvm/gems/ruby-1.9.2-p180/gems/activesupport-3.0.9/lib/active_support/core_ext/numeric/time.rb", 63]

Method#source_location 會回傳一個陣列，裡面放著檔名以及在第幾行。

參考資料：

Ruby API – Method 類別