知識過客

假日開發的專案∼給大家參考： Github Page: http://peihsinsu.github.io/wikitpage/ Github:  https://github.com/peihsinsu/wikitpage 目的主要利用Github Page以及Github GFM(一種Markdown)語言來做到免費Host網站在Github上面，內容管理直接使用Github的md檔即可，當然也直接借用Github的Editor來編輯拉∼所以，嚴格上來說...真的是0成本架站喔！

     VS    在寫程式一樣的時候，prepare statement是我們不可或缺的一向工具 透過？來動態置入查詢參數，讓SQL語句可以發揮得更淋漓盡致... 問題是....如果有不需要置換的？怎麼辦... 下面是個例子： select concat(' http://www.google.com/search?q= ', param0, '&aq=f') as q,   param1, param2 ... from some_table; 這邊希望？是sql產出值的一部分，然後透過SQL直接組織產出成為一個url string，當然，string中包含有？是url終場見到的...，此時，單純的query不會有問題，但是若在此時加上where子句，並且改寫成prepare statement格式... select concat(' http://www.google.com/search?q= ', param0, '&aq=f') as q,   param1, param2 ... from some_table where condition1 = ? and condition2 = ?; 如果上述SQL以及對應的條件送進prepare statement查詢的話，系統會很明確的告訴你...EXCEPTION! 嘗試了一下，總覺得可以透過某些方式讓SQL變成合理... 最後腦筋動到MySQL的ASCSII上面...透過 MySQL的官方文件 說明，可以透過CHAR這個Function來置換ASCSII的字元，而要知道字元的ASCSII碼，則可以透過ASCII Function來查詢...做了一個簡單的測試: select ASCII('?'), CHAR(63) 執行結果如所預期... :D，修改上面的Prepare Statement後： select concat(' http://www.google.com/search ',CHAR(63),'q=', param0, '&aq=f...

想上雲端的人，通常都在意著效能，今天聽到一個校能的計算方式，覺得滿有意義，跟大家分享： 我們知道雲端與實體主機的最大差別就是Pay by use，需要的時候生一台主機，不需要的時候就移除... 因此雲提供商的"大容量"，就是吸引我們上雲端的一大要素，而上雲端的我們，需要注意到的是怎麼去衡量流量帶來主機效能的衝擊，怎麼在經濟效益下去增加與減少機器... 而講到效能，我們知道雲端主機都是虛擬出來的，虛擬主機是share實體主機的CPU而達到運算的功能，所以不論標榜怎麼有效能的雲端主機，都還是差過實體主機，最能接近實體主機效能的虛擬方式：Bare-Metal也是如此... 因此有人把虛擬化與實體化做一各比較，假設一台同等及虛擬主機效能是一台同等級實體主機效能少20%，也就是"1實體主機 X 0.8 = 1虛擬主機"，但以提供服務的架構來看，我們通常會為了要分散運算，提高效能而把AP層服務橫向擴展，假設雲端上主機開三台，效能就約是3倍(相當於可以容納3倍的HTTP Request，這個數據原則上不是線性，仍需要關乎後端是否有DB、Storage...而定)，因此以雲端架構展開的服務來看，效能就會是0.8x3，也就是2.4... 勝過實體主機2倍半... 這樣的比較似乎不太公平....但是卻印證了中國古代智者的一句話... "三各臭皮匠，勝過一各諸葛亮"，各位在展開雲端架構的同時，也該考慮到這個議題喔... 而展開AP層的架構也同時帶來了些好處，例如風險分散...

雖然只有短短幾分鐘... 

算是Android陣營的一劑強心針吧∼ http://www.winandmac.com/2013/04/focus-on-people-facebook-home-for-android-is-officially-launched/ 在普羅大眾還沒搞清楚Phone, Phonblet, Tablet的時候... APP的戰爭延燒到Launcher去了... 針對FB設計的介面，只能說...有點想要FB一下了... 希望FB的設計有全方位考慮到其他尺寸的使用者拉 :D