2013年11月29日 星期五

Project Marai 2 開箱!

先上OP~~~~  跟後面的學習帳也有關www

【初音ミク Project mirai 2 テーマ曲】アゲアゲアゲイン By Mitchie M

水管~~~
NicoNico
http://www.nicovideo.jp/watch/sm21965634


說起來...
我差點就沒買到特典版了XDD
好在剛好有瞄到巴哈&PTT有人說Marai 2的消息
才想到好像快發售了XDD

匆匆問某店還有沒有拿得到的特典版
結果剛好還有www

原本是說訂完當天馬上就能寄 (星期三)
結果也確實隔天就送到了 (宅配員call咱起床了XDD)
結果學校整理信件名字給我打錯...
所以沒收到領信通知
就想說可能還沒整理完等明天再看看...

結果竟然是Key錯名字! ┴┴︵╰(‵□′)╯︵┴┴
不過至少是順利拿到了 030


拿到時~~~
~~~易碎品+籠車~~~
(雖然好像沒那麼容易碎 別壓到就好XDD)
就這樣抱著這個箱子從文書組走回到宿舍
反正也看不到裡面是啥XD

打開外箱理所當然是塞一堆東西
不過這填充物...
這是雜誌啊!
不要可以送我啊 不用拆也無所謂

把這些垃圾雜誌屍體排除後
包著氣泡袋的本體啊!!!!!!!!!!
不過膠帶黏得有點多 不是太好拆www

東西出來啦!
初回特典+限定版maria 2  +  店家另外送的小黏土人

對了 還夾了張傳單XDD
還好咱對PVC基本上免疫...
(其實是跳不下去...)

總之先來拆送的小黏土人
外盒上的封口貼紙有撕過的痕跡
很不易外的這種隨機的東西幾乎都會被拆過XD
是大姊~~~~
不過看了下就收回去了
宿舍沒地方擺www

再來是特典
說真得這有點奇妙XDD
學習帳
會買的基本上用不到吧www
這是要留給孩子用的嗎XD
來幫ミク上色~~
這是ミク呦 是你的媽媽 要記好喔

附了mirai 2的OP歌詞



拖了一堆 現在進入本體啦!

可以看到限定版小黏土人+遊戲盒(&貼紙 大概還看得到吧?)

先拿出小黏土人啦~~~
這盒確定沒開過痕跡(廢話
開盒!!!!....


等...
這啥?
有必要包成這樣嗎XDDD


拆開氣泡袋
不過最後還是收回去了XD

貼紙其一&被推倒的遊戲盒
貼紙其二

遊戲盒正面~~~
 背面(順便拆了塑膠套~~~)
 盒背


開盒啦!!!!!
(好多盒XD)

內容物:
說明
AR卡組*2
SEGA問卷
SEGA SONIC廣告
mirai 2宣傳單?
任社CLUB點數

(別忘了還有卡帶 和... 盒子?

這次的盒子在盒子挖洞處塞了人物圖www
圖案數和盒子的洞數一樣
想到任天狗要拆下來才能全看到 030

說明書兩面
任社說明書電子化
盒子裡大部分不會有整本的說明書了OwO


然後是AR卡~~~
這次的AR卡還是雙面的呢www

不過...
想到舊版&PDf的AR都被我那鬧水災的背包殘害過...
還好看起來沒啥痕跡就是



最後的最後~~~
這才真正重點啊!!!!
(咦? 重點不是前面那些特典?
卡帶本體!!!
卡帶上還是滿滿的商標啊...

插上3DS啦~~~
可以開始玩遊戲啦~~~



接下來遊戲的部分就跟咱無關啦XD
逃~~~~~~~~~~~~~~




不過雖然敗了
但依照最近卯起來當提督瘋狂摧殘鑑娘們的這狀況
不知道有多少時間能玩就是www

2013年10月21日 星期一

SSD終於回家啦~~~~~~ (雖然好像不是同一顆XD

上個月底終於把出毛病的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年8月31日 星期六

學校停電之鬼混計 (!?

當現代人的依靠被切斷之時
中央校園被黑暗襲擊了
同時陷入了無人的寂靜

理應如此
但巨大的聲響也同時入侵了校園
破壞了這片安寧
(此人因停電發瘋了請無視



說真的...
之前停電咱都睡死(雖然好像都是上午?)
所以也沒注意過學校到底有那些發電機
但這次發現校內幾乎遍佈著極大量啊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
// 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
<?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
總之看狀況啦~~~
反正寫網頁還是要看使用者啦
(望向那令種網頁設計師反感的IE 不過最近也好很多啦XD