加jQuery進使用MooTools的頁面

手邊有一些網頁用到了MooTools，不過為了一些需求，需要加進jQuery
看過一些網頁資料，MooTools與jQuery有某種程度的相沖
實際在使用時，jQuery不管加在MooTools前面或後面，原來使用MooTools的功能就出問題
後來經過一些嘗試，把下列這段加在MooTools之前
<script type="text/javascript" src="lib/jquery.js"></script>
<script type="text/javascript">
var $j = jQuery.noConflict();
</script>

這樣$保留給原來MooTools用，而$j供jQuery使用

怪，IE8顯示的資料少了

今天遇到一件怪事，面對同樣的資料來源，IE8的呈現出來的資料筆數竟然與IE11, Firefox, Chrome不同

環境
這是個web-based的系統，browser以AJAX，透過XMLHttpRequest向server取得資料後，再以JavaScript呈現在頁面

問題
以現有的設定應該會顯示出3筆資料，在Firefox, Chrome與IE11都正確顯示，唯有IE8只顯示出一筆資料。

解決過程
用Chrome的development tool來看，responseText拿到的資料是
192.168.10.120/1/1##192.168.10.57/2/1##192.168.10.63/1/5
(我們是用"##"來做分隔號)
但在IE8中，responseText卻是
192.168.10.120/1/1## 
所以，問題就不是在javascript把資料呈現在頁面這段，而是資料來源了。而這就有點詭異了，因為在同一個時間點，這設定是不會變動的，IE8理應拿到的是跟其他browser相同的資料才對。難道IE8有問題？
直接用IE8連結資料源的網址，咦~~，拿到的資料是3筆呀。所以IE8從server拿的資料應該是正確的。那問題是在IE8的XMLHttpRequest把我的資料暗槓了嗎？應該不會才對，其他相同作法的頁面都沒事呀。

在百思不得其解時，突然想起用Wireshark來抓抓兩端間的封包看看，果然有了重大發現。server傳回來的responseText在Wireshark看到的是
192.168.10.120/1/1##\000192.168.10.57/2/1##\000192.168.10.63/1/5

在每個## (分隔號)的後面，都多了\000，也許就是因為這個，IE8的javascript engine解譯為octal null character，對null-terminated string來說，這就是字串的結束，所以把後面的都忽略了；而其他browser的javascript engine則是忽略掉這個null character，所以才有這樣的差別。

看來問題是在server-side的程式了。
查找了一下server程式，果然發現該程式(C language)在把分隔號##寫入response chunk，給的length竟然是3，難怪會多出那個null character。改正後就沒問題了。

結案！

datalist在Chrome跟Firefox的表現

HTML5的datalist在Chrome跟Firefox的表現還真是差別不小
以下面這個例自來看
<input list="states" />
<datalist id="states">
<option value="Kansas">
<option value="Missouri">
<option value="Colorado">
<option value="Nebraska">
<option value="Oklahoma">
</datalist> a

如果在input field中輸入 "o"，在Chrome與Opera中看到的是以o開頭的選項，而且有像select/option的下拉式操作

而在Firefox中所看到的，是選項中含有o這個字母的選項，且沒有下拉的三角形 (不過在input field中用mouse click，還是會有選項出現)

10 Reasons why Java Rocks More Than Ever

我喜歡Java，從2000年開始使用Java到今天已經有14年了。對我而言，用Java來開發各種系統，都是很美好的經驗。

Java，對有些人來說，是種語言。但對我來說，Java不只單單是種語言，她還是個執行平台(JVM)，更是個很漂亮的API。

今天看到這篇文章10 Reasons why Java Rocks More Than Ever，裡面提到的十點，真的點出了我也認同的Java十大優點：

Part 1: The Java Compiler
Java的結構讓Java程式在compile時可以快速且簡易，也沒有複雜的linking問題

Part 2: The Core API
經過十多年來的演進與累積，JDK core API無論在功能與效能上，都有明顯的進步。一般的程式，只要用core API幾乎就足夠了

Part 3: Open Source
這一點對我來說真的是獲益良多。Internet上充滿了一大堆好用的Java open source，你想得到或想不到的功能都有，讓我可以在很短的時間，就能做出符合需求的系統。不過對我也有些困擾，就是有太多類似功能的libraries/frameworks，讓我得花不少時間去評比與測試，來決定用那一個

Part 4: The Java Memory Model
Java在memory的規劃上完全支援了concurrency computing。這個只要用Java寫過threading就能體會它的好，連C++11與C11都加入了這樣的memory model了

Part 5: High-Performance JVM
JVM加上了JIT，讓這個雖然是虛擬機器(VM)，但跑起來卻不笨重。有不少benchmark的評比，Java跑起來的速度不會差C/C++太多，尤其是在server environment，雖然有不少C/C++的忠實者不太同意，不過它的效能在一般用途上真的是夠好了

Part 6: Bytecode
bytecode對JVM來說，其實就是這個VM的machine code。所有的Java程式都要先compile成.class的file，裡面就是可以在JVM上執行的bytecode。現在也有其他語言(http://c2.com/cgi/wiki?OtherLanguagesForTheJavaVm)可以compile成bytecode了，所以不一定只能用Java語言才能寫出能在JVM上執行的程式了

Part 7: Intelligent IDEs
對Java programmers來說，這一點真的很幸福，像Eclipse, Netbeans這些IDE，功能強大，而且不用錢

Part 8: Profiling Tools
由於JVM的結構容易與外界溝通，所以Java的開發者有不少profiling工具，可以來量測CPU, memory等等的使用狀況，幫助做performance的調校

Part 9: Backwards Compatibility
當你寫了十幾二十年的程式，看到好久以前寫的程式，不用修改就能在新平台上執行，你就會知道那是何等值得感動的事
Java就是這麼可愛，不像某家公司，換個版就夠你改得要死

Part 10: Maturity With Innovation
Java從1995誕生至今也快20年了，它的成熟度如何，看看金融界使用的情況就知道了，連在火星上都有它的足跡。Java仍在演進，與時俱進地不斷創新功能，這也是為何有這麼多Java的死忠者願意跟著它走。

你喜歡Java嗎？Java還有很多我都還未接觸過的面，值得大家一起來學習與分享。

OpenSSL的HeartBleed漏洞

最近OpenSSL的HeartBleed漏洞鬧得沸沸揚揚，讓很多使用者與開發者都心存恐懼。那到底什麼是HeartBleed漏洞？

從SSL/TLS的heartbeat機制講起
OpenSSL是SSL/TLS protocol的實作之一。目前這個漏洞也要從這個通信協定談起。詳細的內容大家可以參考wiki的文章，這裡不多做贅述。一般使用者最常使用到的應該就是其上層的https協定了。

當通訊的兩端建立起安全通道(secure channel)後，為保持此通道不會被結束，client端可以送heartbeat信號給server，而server則會回應給client。
如下圖，client會先送任意的內容及此內容的長度給server，server會再將此內容與長度回覆給client。這個內容的最大長度是64K bytes。

這種heartbeat機制是很常用的機制，很多協定或應用都會使用這樣的機制。但為什麼OpenSSL出了問題？

首先，OpenSSL只有1.0.1 ~ 1.0.1f這幾個版本有問題，之前的版本並沒有問題，之後的版本也修復了這問題。

其次，出問題是因為OpenSSL在實作上的問題，不是SSL/TLS通信協定的問題。
OpenSSL在實作上會開一個64K bytes的buffer space，供來自所有clients的通訊共用。當有來自client的heartbeat時，OpenSSL會將送來的內容寫到此buffer，再將符合長度的內容由此buffer回傳給client。
於是，這就產生了問題。如下圖，當有心的client送的內容只有5 bytes長，卻宣稱有25 bytes；OpenSSL server並沒有去查真正的內容是多少，完全信任client所宣稱的長度，所以會老老實實的送回25 bytes的資料給client。

我們可想想，如果client只送1-byte的內容，卻宣稱長度有64K bytes，則等於獲得了整個buffer的內容。再從這裡去過濾所得到的內容，或許就可以得到其他clients與server間的對話內容。(想想網路銀行、購物網站等等，他們不都是用https來傳送你的銀行帳號、信用卡號、識別碼...等等的機密或隱私資料嗎)

雖然對有心人來說，很難預測可以從這64K bytes中取得什麼資料，不過不斷地送heartbeat，再透過程式來自動過濾擷取到的資料，還是可以撈到不少有用的資料。

既然事情發生了，怎麼解決？
對server side的管理者來說，先看看有沒有使用OpenSSL，而且是1.0.1~1.0.1f這幾個版本。如果是，那就儘快換掉。
對client使用者來說，你也不知道那些server是用OpenSSL 1.0.1~1.0.1f這些版本。最好是跟相關網站確認他們有沒有這樣的漏洞以及該如何處理。如果資料已被拿走了，最好的方法可能就是把密碼、信用卡等等的趕快換了。

參考1
參考2