微風夕語

IRC 聊天室記錄

第一日的 IRC 聊天室記錄可以在 http://logbot.owo.tw/channel/osdc.tw/2013-04-19 看到。

What beginners teach us

第一天的 Keynote，講了很多講者自己教學的心得，但我覺得主要的重點是以下幾個：

1. 在新手心中，一件事有許多可能性，老手則少得多。但新手面對那麼多選擇的時候，常常會不知所措，不知道該選哪一個才是對的。
2. 新手學習時最重要的是學習時的心情曲線，如果習題練不動，程式碼又一改就爛，又沒有其他可以讓他們嗨起來的活動（例如工作坊，社群聚會），那他們很快就會放棄。

The RosettaCode Data Project

RosettaCode 是一個程式語言範例程式碼的 Wiki，上面有將 668 個問題，近 500 種程式語言對於這些問題的解法。換而言之，是個抄程式碼的好地方。（喂

然後講者提到了一個 SNUSP 語言，是 2D 的 brainfu*k 變種，程式碼看起來像這樣，跑的時候你會看到游標順著你的程式圖（？）跑，然後還可以加減速。XD

現在講者在做的事情，是想辦法把 RosettaCode 裡面的資料，用比較友善的方式呈現出來。例如上面的 FizzBuzz 已經有近 150 個程式語言的範例，讓 Wiki 頁面變得很冗長，但你有興趣的可能只有其中幾種程式語言，講者就是正在想辦法做一個比較方便的 UI 給RosettaCode 用。

我如何停止憂慮並愛上 Non-MVC Web Framework

我自己的講題，議程表出來的時候，我本來還擔心在一堆 JavaScript 裡這種冷門的題目會不會沒人要聽，不過還好還滿多人來捧場的……真是謝謝大家啦！:p

然後我在回顧 IRC 的時候，發現 Q&A 的部份的問題我沒有答得很完整，所以在這邊再重新回答一下：

Q: 投影片裡的 Ajax 範例是不是會多了把資料傳回 Server 的負擔？

A:

是的，但投影片裡是簡化過後的範例，只是單純的檢查使用者輸入的字串長度，這個可以直接在前端用 JavaScript 做掉。

但有的時候你的資料一定傳回 Server 端檢查，例如檢查使用者註冊的 EMail 是不是已經用過了，這個時候 Lift 就可以讓你不用任何寫一行 JavaScript 就搞定。

Q: MVC 到底有什麼讓我憂慮的地方？

A:

MVC 真正讓我憂慮的地方是我永遠搞不懂為什麼要有 Controller，所以在學 MVC 的時候，我會覺得為什麼我還要多寫一個 Controller 的動作，然後在裡面又重覆撈著同樣的資料。

相較之下，Lift 的 snippet 就是單純的 Function，我可以在一個模版裡面呼叫無數多個 Snippet，而同一個 Snippet 也可以在不同的模版被呼叫。

這等於是我只要寫了一個購物車的 Snippet 的話，在任何網頁的 Template 裡面插上那段購物中的 HTML，頁面上就會出現購物車，我覺得這比 Controller 符合網頁程式的運作流程。

那些函數語言 Tutorial 沒教我的事

講者認為 Functional Programming 的要件只有一個，就是該程式語言裡 Function 是 First-class value，也就是說你可以把 Function 當做像一般的整數值，把他當成參數丟到另一個 Function，或一個 Function 的回傳值是另一個 Function。

我並不完全同意這個觀點，對我來說，符合了這個條件儘止代表了該程式語言可以用 Functional Programming 典範的方式來寫程式而已。

但我認為一個程式語言是否夠資格稱得上 Functional Programming Language，主要還是要看該語言本身提供的工具和函式庫以及所鼓勵的編程典範。對，C / C++ 有 Function Pointer 可以用，在 Java 裡面你也可以用物件來模擬 Function（Scala 在 JVM 的層次上就是這樣做），但他們內建的函式庫的編程典範都是 mutable data，我實在不覺得他們可以稱得上是 Functional Programming Language。

但我同意講者以下的觀點：

大部份宣稱自己是 Functional 的程式語言不能保證你的程式沒有 Side-effect 或你的 Data Structure 是 immutable data，而你在傳統的程序式語言，如 C++ / Java 等也能夠透過自我規律來達成這件事，可是透過學習 Functional Programming Language，你可以更清楚地了解這些概念。

Functional Programming Using Underscore.js

就像上面我說的……Functional Programming 不止是語言本身可以把 Function 當做 First-class value 來用，函式庫和編程典範也是很重要的。

Underscore.js 就是在提供 JavaScript 裡面缺少的這一塊，例如支援 High-order function 的 Collection，以及讓你可以把函式組合起來的工具 (compose / chain)。

IRC 聊天記錄

第二日的 IRC 聊天室記錄可以在 http://logbot.owo.tw/channel/osdc.tw/2013-04-20 看到。

Future of JavaScript

新版的 JavaScript (EMCAScript 6) 提供了像是 let 以及簡潔的 Function Literal 以及其他比較 Functional 的語法和函式庫，像是本下來面的 JavaScript 程式：

var func = function(x) { x + 3 }

可以變成：

let func = x => x + 3

這真的簡潔很多，不過很可惜的……目前大概只對在後端用 JavaScript 的人比較有用而已，因為如果寫前端的話，該死的 IE 不知道何年何月才會實作這個標準，而 IE6 還繼續在那苟延殘喘，然後目前 Chrome 的話也要手動設定打開實驗功能才能用這個語法。

所以在短時間內，網頁前端的部份還是沒辦法使用這種比較方便的語法。

不過後來的 Demo 真的很吸引人，可以用 OpenGL 硬體加速，有 Battery / WebCam 的控制 API，而且效能上只比 Native 程式碼慢上一倍而已，真的很讓人驚豔。

現在就看 JavaScript 是不是真的能吸引到更多人來開發了，我自己是真的很佩服那些可以持續用人腦和弱型別程式語言來搏鬥的人啊（笑。

Acmeism - Hacking in all Languages at Once

選錯議程了，完全聽不懂講者在幹麻的一場，囧。

ElasticSearch 實戰介紹

把 Lucene 包得成 REST / JSON 介面，並且支援分散式的環境。

API 的部份因為使用 REST 和 JSON，本來就熟悉的話會比直接用 Lucene 的 API 簡單，不過還是要有基本的 Lucene 搜尋引擎架構的概念才行，例如什麼是 Index，什麼是 Docuement 和 Field 還有 Analyzer 等等。

不過由於架構上的問題，如果原本已經有 Lucene 的索引檔，是不能直接倒是 ElasticSearch 裡面去的，還是得用 ElasticSearch 來重新建一次你的資料的索引檔……果然世界沒有那麼美好啊，我本來還期望把原來的 Lucene 索引檔丟進去就有 REST 可用的。XDD

Scala 的愛與恨

沒聽到的閃電秀，是後來看 YouTube 上錄影的。

挺中肯的，不過我自己不認為 Tuple22 是什麼大問題，通常如果 Tuple 長到 3 以上，就會建議用 case class 改寫了（TupleN 本來就是 case class 所以效能上沒啥差，你寫 Tuple[Int, Int, Int] 的話不如寫一個 3DPoint 來得方便清楚），我不相信有人可以記得 22 個沒有名字的 Field 是幹嘛的啦。XD

然後最後一頁型別的問題的話，除非想寫 Library，不然寫單純的 Scala Application 其實很少會去管到那些進階型別的符號。

註解