上個月底終於把出毛病的ADATA S511拿去送修~~~
(應該拖了3~4個月有了XD 反正確定保固內沒差www)
然後就過了漫長的等待...
還真的是兩個星期多才回來 OTZ
(禮拜五收到通知 過了18天...)
很不意外的回來的不是S511 XDD
畢竟SSD沒在修都直接換
而S511又早就停產www
回來的是SP900 同樣還是SF 2281主控
顆粒從Intel變Micron 不過都非同步顆粒XDD
但共通特色都是有超過500MB/s的可壓縮資料跑分
多媒體檔案的讀寫有200 / 100 MB/s就不錯了www
不過當初是拿來組RAID0當系統碟 便宜而且有基本速度就夠了~~~
要說的話還是現在的M5S比較爽快XDDD
對SSD本身倒是沒啥太大抱怨啦
不過為了省成本所以把原本送的鋁合金3.5"轉接架
換成塑膠製的整個質感暴跌 這怨念超大...
(尤其外觀設計感覺很強調這就是塑膠製品...)
順便偷偷期望一下另外一顆S511在保固期內出毛病
這樣可以再換一顆新的XDDD
2013年10月21日 星期一
2013年8月31日 星期六
學校停電之鬼混計 (!?
當現代人的依靠被切斷之時
中央校園被黑暗襲擊了
同時陷入了無人的寂靜
理應如此
但巨大的聲響也同時入侵了校園
破壞了這片安寧
(此人因停電發瘋了請無視
說真的...
之前停電咱都睡死(雖然好像都是上午?)
所以也沒注意過學校到底有那些發電機
但這次發現校內幾乎遍佈著極大量啊OAO!
話說因為忙完回宿舍(真的不該順路逛中壢夜市-3-)
剛好是12點所以停電了...
一片漆黑的浴室實在不適合洗澡
沒冷氣又全身不大舒服根本睡不著
所以就難得大半夜跑到校外鬼混去了XDD
一開始衝到了麥噹噹去
吹到冷氣瞬間復活XDD
還很爽快的灌了整杯可樂
(東西還是一樣不是給人吃就是)
吃完後立馬衝新都市
第一次大半夜到新都市
當然自然是走到幾乎被K社佔據的音樂機台區XD
雖然18禁那區的機台也算熟悉...
算家庭背景因素?
而且這還是第一次打到K社的E-PASS伺服器關機呢www
(北部貌似沒啥開24HR的點啊OWO?)
雖然說關機後貌似有會爆能力的八卦
不過沒存檔開過的歌就沒試了
關機後開始瘋狂還能連的MaiMai
~~~題外話~~~
發現這一代的MaiMai Green跟咱同步率有點可怕的高啊
那歌曲打完後的貓叫聲...
害咱每次都自主性的跟著叫一次了XD
咱就常在亂喵叫了 這根本開了總開關啊XDD
中央校園被黑暗襲擊了
同時陷入了無人的寂靜
理應如此
但巨大的聲響也同時入侵了校園
破壞了這片安寧
(此人因停電發瘋了請無視
說真的...
之前停電咱都睡死(雖然好像都是上午?)
所以也沒注意過學校到底有那些發電機
但這次發現校內幾乎遍佈著極大量啊OAO!
話說因為忙完回宿舍(真的不該順路逛中壢夜市-3-)
剛好是12點所以停電了...
一片漆黑的浴室實在不適合洗澡
沒冷氣又全身不大舒服根本睡不著
所以就難得大半夜跑到校外鬼混去了XDD
一開始衝到了麥噹噹去
吹到冷氣瞬間復活XDD
還很爽快的灌了整杯可樂
吃完後立馬衝新都市
第一次大半夜到新都市
當然自然是走到幾乎被K社佔據的音樂機台區XD
雖然18禁那區的機台也算熟悉...
算家庭背景因素?
而且這還是第一次打到K社的E-PASS伺服器關機呢www
(北部貌似沒啥開24HR的點啊OWO?)
雖然說關機後貌似有會爆能力的八卦
不過沒存檔開過的歌就沒試了
關機後開始瘋狂還能連的MaiMai
~~~題外話~~~
發現這一代的MaiMai Green跟咱同步率有點可怕的高啊
那歌曲打完後的貓叫聲...
害咱每次都自主性的跟著叫一次了XD
咱就常在亂喵叫了 這根本開了總開關啊XDD
2013年8月5日 星期一
Long Polling 之 隨興實作
上次終於得知Long Polling之後
原本只覺得應該只是知道 短時間內沒機會用到...
結果今天點歌系統做個小改版發現其實頗適合用的XDD
原本點歌系統點播清單那塊是隨著換曲時重載
(因為每次換曲點歌數一定會減少啊XD)
不過這樣要是別人點了歌並不會馬上更新
除非自己手動更新或換了歌才會知道
這樣不就不符合即時系統了嗎!!!!!! (請無視此人的發瘋
所以就開始準備動手修改一下
但... 很明顯的用polling絕對不是好方法(理想大概要1s的間隔吧...)
所以就來弄弄Long Polling啦
因為Long Polling會有相當數量的持續連線
當然不能用PHP寫啦~~~ (其實用PHP寫daemon應該可行?)
這回用的是node.js 順便來玩玩這用JS來寫Server XDD
(題外話... 原本想要裝forever來跑這server 不過好像npm registry被衝爆了...)
因為需求上是點歌系統點的一首歌後送出訊息要求客戶端更新
設計上只要一個簡單的訊息交換就夠了
所以這js還頗小的www
server.js
整體就很簡單的訊息交換而已
而點歌頁面也做了對應的調整
只需要反覆的ajax請求就好
要是伺服器端沒有支援的話,這可是比Polling還糟糕啊XDD
最後後台點歌的PHP檔只需要在點歌成功後外加一個CURL請求就好
就沒多放程式碼啦~~~
這永遠BETA的點歌系統又往正式版前進一步了~~~
(這句話矛盾的很嚴重啊XDD
原本只覺得應該只是知道 短時間內沒機會用到...
結果今天點歌系統做個小改版發現其實頗適合用的XDD
原本點歌系統點播清單那塊是隨著換曲時重載
(因為每次換曲點歌數一定會減少啊XD)
不過這樣要是別人點了歌並不會馬上更新
除非自己手動更新或換了歌才會知道
這樣不就不符合即時系統了嗎!!!!!! (請無視此人的發瘋
所以就開始準備動手修改一下
但... 很明顯的用polling絕對不是好方法(理想大概要1s的間隔吧...)
所以就來弄弄Long Polling啦
因為Long Polling會有相當數量的持續連線
當然不能用PHP寫啦~~~ (其實用PHP寫daemon應該可行?)
這回用的是node.js 順便來玩玩這用JS來寫Server XDD
(題外話... 原本想要裝forever來跑這server 不過好像npm registry被衝爆了...)
因為需求上是點歌系統點的一首歌後送出訊息要求客戶端更新
設計上只要一個簡單的訊息交換就夠了
所以這js還頗小的www
server.js
// http var http = require("http"), url = require("url"); http.globalAgent.maxSockets = 200; var pendingRequests = []; // 客戶端連線時讓連線進入等待狀態 function processPendingRequest(request, response) { // 連線被強制關閉時移除 response.on('close', function() { clearTimeout(this.timeout); var id = pendingRequests.indexOf(this); if (id != -1) pendingRequests.splice(id, 1); }); // force reconnect response.timeout = setTimeout(function (){ response.writeHead(200, { 'Content-Type': 'application/json', 'Access-Control-Allow-Origin': '*' }); response.write(JSON.stringify({ "message": "" })); response.end(); var id = pendingRequests.indexOf(response); if (id != -1) pendingRequests.splice(id, 1); }, 30000); pendingRequests.push(response); } // 送出訊息時針對所有等待中連線送出訊息 function processSendingRequest(request, response) { var u = url.parse(request.url, true); var msg = u.query.msg, dat = u.query.dat; while (pendingRequests.length > 0) { var element = pendingRequests.shift(); clearTimeout(element.timeout); element.writeHead(200, { 'Content-Type': 'application/json', 'Access-Control-Allow-Origin': '*' }); element.write(JSON.stringify({ "message": msg, "data": dat })); element.end(); } response.writeHead(200, { 'Content-Type': 'application/json' }); response.write("{\"result\":\"complete\"}"); response.end(); } // 建立HTTP伺服器 http.createServer(function(request, response) { var u = url.parse(request.url, true); if (/* 此處為訊息傳送端驗證 */) processSendingRequest(request, response); else processPendingRequest(request, response); }).listen(13453);沒有寫的很複雜
整體就很簡單的訊息交換而已
而點歌頁面也做了對應的調整
function polling_call() { $.ajax({ cache: false, dataType: 'json', type: "GET", crossDomain: true, url: "http://live.sbsstudio.twbbs.org:13453/", error: function () { setTimeout(polling_call, 15000); }, success: function (p) { switch (p.message) { case "NeedUpdateRequireList": requestlist_call(); break; } polling_call(); } }); }Long Polling的客戶端總是很簡單XD
只需要反覆的ajax請求就好
要是伺服器端沒有支援的話,這可是比Polling還糟糕啊XDD
最後後台點歌的PHP檔只需要在點歌成功後外加一個CURL請求就好
就沒多放程式碼啦~~~
這永遠BETA的點歌系統又往正式版前進一步了~~~
(這句話矛盾的很嚴重啊XDD
2013年7月28日 星期日
Long Polling 之 很殘念的到了最近才知道啊...
是說這是第一篇文耶!!! (還不是某人真的讓這成了蚊子館XD
雖然標題是Long Polling來著
不過其實不全然是呢XDD (遭毆
以下正文(?
雖然這技術有段時間了
不過說真的不久前才剛知道啊XDD
得知起因莫名簡單的(?
主要是因為tlk.io這服務而起的XD
是個簡單的聊天室服務
雖然功能簡單樸素 不過技術倒不怎簡單啊www
存粹某天閒閒沒事對著他開了GC的開發者工具
(用了GC得到了這工具之後的習慣XD)
然後發現...
等... 竟然有個始終pending的連線? 而且status code還是101 !?
好奇的看了下URL... ws:// 這啥? 見都沒見過
所以就順手Google了一下...
恩... HTML5的新協議之一 WebSocket
原來這一直希望能有的東西被加進來啦OWO
恩... GC從6開始就有在實作了 (正確來說是4開始 不過貌似6才稍微比較完整?)
等... 咱看到啥了
咱可是只差最初的1沒用的GC死忠用戶啊(正式版前的版本無視XD)
老早就支援了咱竟然都沒注意到!!!!!!!!?
不過各瀏覽器支援仍然不大相同
看來還不適合實際使用
不過就像剛才說到的
tlk.io倒是用上啦XDD
(自然有其他fallback啦 不支援的狀況應該還是long polling)
然後這是新技術
自然會有對應的舊技術啦~~~
總不可能在哪邊每秒reload或者AJAX request的啊XD
(這就是polling 雖然之前確實這樣想的... OTZ
找資料的同時也發現了
除了polling這種爛到爆的方法外
還有comet&long polling
comet雖然可行 但終究不理想
所以就出現了long polling
這方法倒是意外的簡單說www
主要在伺服器端
收到客戶端的連線後就先丟著 讓他進入pending狀態
等到有資料要送的時候在送出去
而瀏覽器收到後就結束連線處理資料
然後又一個新的request送出繼續等待
不過這會有霸著連線的問題
自然得要靠event driven的後端
不然用apache連線直接被吃滿滿還要服務嗎XDD
照慣例的簡單試了下~~~
longpolling.php

(上面只是示範 如果真的拿來用的話Web Server會炸掉的XDD)
說實話
還真是沒想到現在使用的技術是如此的簡單啊XDD
果然好方法真的不一定是複雜的方法呢www
不過還是期望WebSocket能盡速普及啦
畢竟相較之下仍然是個比較好的方法XD
不過實際上也有SPDY這個方案呢www
總之看狀況啦~~~
反正寫網頁還是要看使用者啦
(望向那令種網頁設計師反感的IE 不過最近也好很多啦XD
雖然標題是Long Polling來著
不過其實不全然是呢XDD (遭毆
以下
雖然這技術有段時間了
不過說真的不久前才剛知道啊XDD
得知起因莫名
主要是因為tlk.io這服務而起的XD
是個簡單的聊天室服務
雖然功能簡單樸素 不過技術倒不怎簡單啊www
存粹某天閒閒沒事對著他開了GC的開發者工具
(用了GC得到了這工具之後的習慣XD)
然後發現...
等... 竟然有個始終pending的連線? 而且status code還是101 !?
好奇的看了下URL... ws:// 這啥? 見都沒見過
所以就順手Google了一下...
恩... HTML5的新協議之一 WebSocket
原來這一直希望能有的東西被加進來啦OWO
恩... GC從6開始就有在實作了 (正確來說是4開始 不過貌似6才稍微比較完整?)
等... 咱看到啥了

咱可是只差最初的1沒用的GC死忠用戶啊(正式版前的版本無視XD)
老早就支援了咱竟然都沒注意到!!!!!!!!?
不過各瀏覽器支援仍然不大相同
看來還不適合實際使用
不過就像剛才說到的
tlk.io倒是用上啦XDD
(自然有其他fallback啦 不支援的狀況應該還是long polling)
然後這是新技術
自然會有對應的舊技術啦~~~
總不可能在哪邊每秒reload或者AJAX request的啊XD
(這就是polling 雖然之前確實這樣想的... OTZ
找資料的同時也發現了
除了polling這種爛到爆的方法外
還有comet&long polling
comet雖然可行 但終究不理想
所以就出現了long polling
這方法倒是意外的簡單說www
主要在伺服器端
收到客戶端的連線後就先丟著 讓他進入pending狀態
等到有資料要送的時候在送出去
而瀏覽器收到後就結束連線處理資料
然後又一個新的request送出繼續等待
不過這會有霸著連線的問題
自然得要靠event driven的後端
不然用apache連線直接被吃滿滿還要服務嗎XDD
照慣例的簡單試了下~~~
longpolling.php
<?php $time = rand(2, 5); sleep($time); echo json_encode($time); ?>longpolling.html
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> <head> <script src="//ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"></script> <script> function pull() { $.getJSON("longpolling.php", function(result) { $("#pullresult").append("<p>waiting time : "+result + "</p>"); setTimeout(pull, 100); }); } $(document).ready(function() { pull(); }); </script> </head> <body> <div id="pullresult"> </div> </body> </html>結果~~~

(上面只是示範 如果真的拿來用的話Web Server會炸掉的XDD)
說實話
還真是沒想到現在使用的技術是如此的簡單啊XDD
果然好方法真的不一定是複雜的方法呢www
不過還是期望WebSocket能盡速普及啦
畢竟相較之下仍然是個比較好的方法XD
不過實際上也有SPDY這個方案呢www
總之看狀況啦~~~
反正寫網頁還是要看使用者啦
訂閱:
文章 (Atom)