發表文章

目前顯示的是 4月, 2013的文章

Zero Wiki Host - WikitPage

圖片
假日開發的專案∼給大家參考: 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成本架站喔!

PrepareStatement vs "?"

圖片
     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&

Cloud Performance

圖片
想上雲端的人,通常都在意著效能,今天聽到一個校能的計算方式,覺得滿有意義,跟大家分享: 我們知道雲端與實體主機的最大差別就是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層的架構也同時帶來了些好處,例如風險分散...

是樹大招風嗎...最信任的CloudFlare也.....

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

Facebook Home for Android

圖片
算是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