LOCO FOOD 超好吃蛋餅

這不是甚麼網誌文，

單純我想記錄而已。

只點了漢堡蛋餅和奶茶而已，

奶茶很普通竟然要30塊!

漢堡好吃但也普普，

唯一心動的就是蛋餅，

加了點它們的辣椒更好吃。

好想再吃可是桃園怎麼沒有!

Vector 類別與 Array 類別的比較

文章來源:http://help.adobe.com/zh_TW/as3/mobile/WS4bebcd66a74275c3a0f5f19124318fc87b-7fff.html

如果可能，請盡量使用 Vector 類別，而非 Array 類別。(跟c++差好多)

Vector 類別比 Array 類別能更快速地讀取與寫入存取。

簡單的基準測試可顯示 Vector 類別優於 Array 類別的益處。下列程式碼顯示 Array 類別的基準測試：

var coordinates:Array = new Array(); 
var started:Number = getTimer(); 
  
for (var i:int = 0; i< 300000; i++) 
{ 
    coordinates[i] = Math.random()*1024; 
} 
  
trace(getTimer() - started); 
// output: 107 

下列程式碼顯示 Vector 類別的基準測試：

var coordinates:Vector.<Number> = new Vector.<Number>(); 
var started:Number = getTimer(); 
  
for (var i:int = 0; i< 300000; i++) 
{ 
    coordinates[i] = Math.random()*1024; 
} 
 
trace(getTimer() - started); 
// output: 72 

此範例可進一步最佳化，方法是將特定的長度指定給向量並將其長度設定為固定：

// Specify a fixed length and initialize its length 
var coordinates:Vector.<Number> = new Vector.<Number>(300000, true); 
  
var started:Number = getTimer(); 
  
for (var i:int = 0; i< 300000; i++) 
{ 
    coordinates[i] = Math.random()*1024; 
} 
 
trace(getTimer() - started); 
// output: 48 

如果沒有事先指定向量的大小，則會在向量用盡空間時增加向量的大小。每次增加向量的大小時，就會配置新的記憶體區塊。而向量目前的內容會複製到新的記憶體區塊中。但這些額外的配置和資料複製作業將妨礙效能。上述程式碼藉由指定向量的起始大小來最佳化效能。不過，此程式碼並無法最佳化可維護性。若同時要改進可維護性，請在常數中儲存重複使用值：

// Store the reused value to maintain code easily 
const MAX_NUM:int = 300000; 
  
var coordinates:Vector.<Number> = new Vector.<Number>(MAX_NUM, true); 
var started:Number = getTimer(); 
  
for (var i:int = 0; i< MAX_NUM; i++) 
{ 
    coordinates[i] = Math.random()*1024; 
} 
  
trace(getTimer() - started); 
// output: 47 

請盡可能嘗試使用 Vector 物件 API，因為其執行速度較快。

北市賞櫻網站

http://flowers.taipei.gov.tw/Sakura/

連接池(Connection Pool)介紹

對於資料庫的概念實在很不熟，還在想pool是甚麼，游泳池嗎.....
轉貼下Wallace Hu 寫的介紹，

Connection Pool Introduction

Connection Pool(連線池) 是一種資料庫連線管理的機制，它介於應用程式與資料庫之間；
集中管理資料庫的連線，能有效提升應用程式存取資料庫的效能及減少連線的錯誤。
為什麼要有Connection Pool呢？
如圖一，一般沒有使用Connection Pool的程式，當需要存取資料庫時，
便要建立一個直接與DB相連的連線(Physical Connection)。

圖一 Application_without_ConnectionPool

此做法比較不好的地方在於：
1.資料庫連線的建立成本是昂貴的，故當有許多Thread都需要建立connection時，
其資源的耗費是龐大的。
2. 一個成本昂貴的connection在程式使用完後，馬上就被Close掉,在使用上並沒有達到效益極大化。
3. 程式中請求建立的總連線數可能超過DB允許的連線數而發生Exception。
4. 程式中關於connection的使用若有不恰當的地方,如Statement或Connection沒有close，
並沒有額外的機制提供保護。
當然目標若只是建立小型的AP，可預期的連線數也不多時；其實是不需要Connection Pool的。
而若目標是建立能處理同時間大量連線請求的AP時，Connection Pool就是不可或缺的機制了。
AP中加入Connection Pool後，其運行機制如圖二所示。程式啟動時，
Connection Pool會先跟DB建立好連線(連線數可設定)，並且keep住這些連線；
當程式需要使用Connection時，pool便會將手上可用的Connection借給程式，
程式使用完後再歸還給Pool即可。

圖二 Application_with_ConnectionPool

使用Connection Pool的好處有:
1. Pool會keep住與DB的連線。程式需要使用時跟pool要即可。
不用再重複地跟DB建立連線然後又釋放掉。
2. 可設定與DB最大的連線數，避免超過DB所能負擔的連線數。
3. Pool可幫忙驗證Connectin是否還正常，若不正常時，便再與DB建立好的正常連線，
確保程式取得的Connection都是正常可使用的。
4. 額外功能的提供。如幫忙檢查Connection State或幫忙關閉Statement等。
不同的Connection Pool其額外提供的功能當然也會有所不同。

在node.js裡使用node-mysql middleware 的基本query用法

node-mysql 下載及使用。 初始設定

var mysql      = require('mysql');
var DATABASE = 'xpec';
var TABLE ='member';

var connection = mysql.createConnection({
  host     : 'localhost',
  user     : 'aaa',
  password : 'xpec',
  database : 'xpec'
});

基本查詢表格印出表格內容

//connection.query()已經建立連建，不用再寫connection.connect()
connection.query('SELECT * FROM ' + TABLE, function(err, results){
      if(err) throw err;
      console.log(results);
});
connection.end(); //結束連線

table插入資料

connection.query('INSERT INTO ' + TABLE +' SET ? ',{User: 'jjjj', Psd:'123'},function(err, result){
  console.log(result.insertId);
});
connection.end();

修改update table資料

connection.query('UPDATE ' + TABLE + ' SET ' + 
'Psd=? WHERE id=?',['45645646',1],function (err,result){
  if(err){
    console.log(err);
  }else{
    console.log(result.affectedRows);
  }
});

刪除table資料

connection.query('DELETE FROM ' + TABLE +
 ' WHERE id = ? ',[3] ,function(err, result){
  if(err){
    console.log(err);
  }else{
  console.log(result.affectedRows);
  }
});

在Windows環境下MongoDB搭建和簡單指令

碰到資料庫就不悅!

http://fecbob.pixnet.net/blog/post/38498257-%E5%9C%A8windows%E7%92%B0%E5%A2%83%E4%B8%8Bmongodb%E6%90%AD%E5%BB%BA%E5%92%8C%E7%B0%A1%E5%96%AE%E6%93%8D%E4%BD%9C

session的兩個種類(集中式，cookie-based)

session因儲存的方式不同分為兩個種類:

集中式:

Server發ID給client。

舉例:在最原始的 Session 設計，大多開發者都將資料存在 Server 上，也就是你點了什麼飲料，都是記錄在 Server 裡，可能是 Database、記憶體或是檔案，可以以任何一種形式儲存。然後，當你去領飲料時，店員會輸入你的號碼，用你的號碼得知你是否點過餐、點了什麼東西。

問題:

client進入不同的server的話，資料無法共享。

一般的小網站，這樣的解決方案並沒有什麼問題。但是對今天這種超大流量的網站服務來說，因為他們有無數台對外的 Server，有如無數個服務窗口，讓顧客總是隨機進入其中一個窗口來兌換飲料，所以後端怎麼存放和共享這個 session 資料，又要兼顧效能和方便維護，就變成是很大的問題。

cookie-based:

server直接把資料存在client，用client的cookie儲存session。

舉例: 就是把你點什麼飲料，通通直接寫在號碼牌上。Server 就可以直接看你的號碼牌上寫了什麼，而不必花大量時間去後面建立大規模的 Server 來處理 Session 。

問題:Session 資料放在 cookie 裡比較快，還是放在 Server 上的資料庫比較快？。

答案是放在cookie比較好。以現在頻寬限制來說，多了4k資料也不算甚麼。答案通常會是放在 cookie （以現在的頻寬限制來說，就算多了 4K 資料也不算什麼）。因為你可以省下每次 Client 連線後，去檔案或是資料庫裡挖出 Session 資料的步驟。

而cookie-based只需要直接把 Client 給Server的 cookie 打開，把資料解密後取出就好，是兩次 Database 存取和一次存取的差別。

什麼是 Session 傳值？

時常會聽到『使用 Session 傳值』這類說法，其實就是利用 Session 機制儲存資料，讓不同頁面之間可以互相傳遞資料。其原理通常是使用 Query String 或 POST body 等方法，把資料往 Server 傳之後，在 Server 端將 Client 上傳的資料存在 Session 之中。之後的連線或開啟其它頁面時，因為你拿的號碼牌是同一個，所以在不同的頁面之下，仍然可以讀到前一次所儲存在 Session 的狀態。

轉自:http://fred-zone.blogspot.tw/2014/01/web-session.html