昨晚突然出現大量的Exception，發現是某個IP攻擊網站，所以就直接使用IIS擋IP方式阻擋該IP的攻擊，但是設定之後，發現Exception還是一直出來。但是束手無策....直到一個多小時後才停止攻擊。

事後翻出IIS Log看結果



發現IIS擋IP有發揮作用(status:403) 但是會有漏網之魚(status:302-其實status是500)
檢查 "23:10:46" 一秒內受到 36 次攻擊 但是漏掉了 8 個 -> 失敗率約兩成

結論:
1. 對於阻斷攻擊，可能還需要程式上做處理，例如 begin_request 時檢查
2. Log Parser 真是看 log 最佳工具....

對於PC版大尺吋的螢幕，當網站要 feed 資料到 facebook 時，可以使用 javascript SDK 的
FB.ui => method:'feed' 方式處理，參考位置。此方法會popup小視窗讓user可以分享資料出去。

但是遇到手機版網頁就有點麻煩，實測上手機版的 chrome 會出現轉不停的情況，無法分享；而iPhone則是另開新頁面處理，可以成功但是會多一個分頁。所以手機版網頁建議使用 redirect 方式處理分享機制，參考位置
​

    var fbUrl = "https://www.facebook.com/dialog/feed?" +

    "app_id=122465741241119&display=touch" +

    "&link=" + encodeURIComponent("http://www.shopunt.com/tch/FixPage.aspx?id=525") +

    "&picture=" + encodeURIComponent("http://www.shopunt.com/tch/event/2014-nail-enrollment/fb_200x200.jpg") +

    "&description=" + encodeURIComponent("市價不斐的光療DIY教學，UNT傾囊相授！10場巡迴免費教學，讓妳輕鬆掌握光療DIY訣竅，並搶先體驗秋冬最新流行色！現場打卡，再送時尚美甲工具組") +

    "&redirect_uri=" + encodeURIComponent("http://www.shopunt.com/tch/event/2014-nail-enrollment/Handler.ashx?fun=FBCallback");

​

當然以 redirect 處理與 javascript 方式處理是兩種不同的方式，redirect 方式的 callback 網址 (redirect_uri)要接收facebook 導回的 post_id , javascript 方式則是 callback function 處理 post_id

半夜被老闆 Line，跟我說網頁發生錯誤，他無法看統計報表，會出現作業逾時的錯誤 我查了一下網頁程式，發現是這筆SQL指令跑太久

 Select Id, (IsNull(Total, 0) - IsNull(CouponDiscount, 0) + IsNull(CouponAdd, 0)) as Total, Buyer_Email, EN_Packing_List_Status, EN_Order_Source, En_Stock_Status, Create_Date

From V_Order_main With(Nolock)

Where Id in (select Order_Id from Ad_Trace With(NoLock) where (Parameter_Id = 14278))

AND Create_Date >= '2014/10/3' And Create_Date < '2014/10/12' 

--> 跑了50秒~ 1分鐘

 Select Id, (IsNull(Total, 0) - IsNull(CouponDiscount, 0) + IsNull(CouponAdd, 0)) as Total, Buyer_Email, EN_Packing_List_Status, EN_Order_Source, En_Stock_Status, Create_Date

From V_Order_main With(Nolock)

Where Id in (select Order_Id from Ad_Trace With(NoLock) where (Parameter_Id = 14278))

--> 拿掉日期限制 > 秒殺，  結果跑出 47 筆資料

跑一下執行計畫 原來子查詢的 Ad_Trace 沒有建立Index造成


加上 Index 之後，再跑第一支SQL --> 秒殺

奇怪的地方:
明明訂單日期欄位(Create_Date) 跟 Ad_Trace 沒有多大關係，但是加上日期限制之後，居然會引發 Ad_Trace 搜尋過久的現象
他好像是先依照訂單日期找出所有訂單，然後再從子查詢 Ad_Trace 裡面搜尋有無符合的條件訂單
而不是先跑子查詢找出 Ad_Trace 所有的 Order_Id，再去找符合 Create_Date 的訂單

SQL內部運作的機制真是有點讓人想不透，幸好有評估計畫可以看出問題在哪裡
這讓我想起以前學SQL時的一句話 => 盡量用Join來取代子查詢
使用子查詢真的是效能殺手啊

------繼續補充--------------------------------------

上面的SQL在雙11活動後，由於當日訂單過多，一樣造成SQL timeout 的現象，研判還是子查詢造成的問題

Select Id, (IsNull(Total, 0) - IsNull(CouponDiscount, 0) + IsNull(CouponAdd, 0)) as Total, Buyer_Email, EN_Packing_List_Status, EN_Order_Source, En_Stock_Status, Create_Date

From V_Order_main With(Nolock)

Where Id in (select Order_Id from Ad_Trace With(NoLock) where (Parameter_Id = 14720))

And Create_Date > '2014-11-10' And Create_Date < '2014-11-11'

--> 跑了51秒

所以先將子查詢拿出來跑出一串字串 865828,865890,865901,865903,865928,865955,865990,865993,866005,866035.....
(共1452筆)
再把他拼入sql跑   --> 7秒
 

1. 名詞解釋

DPI - dots per inch (每英寸點密度)
PPI - pixels per inch (每英寸像素密度)

簡單來說，DPI是邏輯解析度，PPI是實體解析度(各家手機的螢幕解析度)

以圖像顯示或字型來說：MAC螢幕預設常用DPI為72、windows系統則是96或120；印刷用的DPI常用為300


2. Device Pixel Ratio(裝置像素比)

以 iPhone 為例
http://www.paintcodeapp.com/news/iphone-6-screens-demystified

視網膜解析度與css背景圖
http://weedygarden.net/2010/10/retina-display-and-css-background-images/

字型光柵化
http://zh.wikipedia.org/wiki/%E5%AD%97%E4%BD%93%E5%85%89%E6%A0%85%E5%8C%96

以下網站可測試此螢幕的裝置像素比
http://www.devicepixelratio.com/


3. 利用css media query 針對不同像素比顯示不同的排版

測試該瀏覽器能使用media query的功能語法
http://cssmediaqueries.com/overview.html

1. 先登入 Skype 的網路版。

2. 找到帳戶設定，把 Microsoft 帳戶連結移除即可。

 
 

一般在製作手機版或是自適應性網站時會加一個meta tag: <meta name="viewport" content="width=device-width,initial-scale=1.0">
但是這樣在IOS系統時，字體的大小會隨著螢幕轉向(螢幕解析度改變)而變大或縮小



解決辦法： 在css的body中加入"-webkit-text-size-adjust:100%;"

自從網站上了 net4.0 之後，網站會有為數不少的 "潛在危險" 的 exception
大都來自不友善的攻擊，想要測試網站的漏洞
網站做這層防護是好事，只是這個東西太敏感了，連簡單的冒號 & 符號都會跳 exception
更慘的是 Google Analytics 會在一些 user cookies 寫入xml文字 ( __utmz=... )
導致正常的 User 都不能正常瀏覽我們網站

解法有兩種:
1. 直接在 web.config 直接設定 不檢查

<system.web>

    <httpRuntime requestValidationMode="2.0" />

    <pages validateRequest="false" />

</system.web>

2. 自訂 RequestValidate (4.0以上才可以用)
請參考此文章 http://msdn.microsoft.com/en-us/library/system.web.util.requestvalidator(v=vs.100).aspx

後者比較算是正解 基本上處理掉 <script 我想 XSS 就解決一大半
 

一般在崁入youtube影片時，影片的寬高是固定的

隨著螢幕大小自動調整寬高的方式：


CSS：
.video-container {
    position: relative;
    padding-bottom: 56.25%;
    overflow: hidden;
}
 
.video-container iframe,
.video-container object,
.video-container embed {
    position: absolute;
    top: 0;
    left: 0;
    width: 100%;
    height: 100%;
}


HTML：
<div class="video-container">
    <iframe src="http://www.youtube.com/embed/dFVxGRekRSg" frameborder="0" width="560" height="315"></iframe>
</div>

calc()是CSS3的一個計算長度單位的新功能，能使用數學四則運算方式。

1. 使用“+”“-”“*”“/”四則運算；

2. 可以使用百分比、px、em、rem等單位；

3. 可以混合使用各種單位進行計算。

例：
.thing {
  width: 90%; /* fallback if needed */
  width: calc(100% - 10px);
  width: calc((100% - 12px) / 2);
  width: calc(100%/3 - 2*1em - 2*1px);
}

4. 使用時，"+" & "-" 兩邊需加空格(一定要加)， "*" & "/"兩邊是不用加空格(要加也是可以)

5. 瀏覽器的支援：IE9+ , Firefox4.0+ , Chrome , Safari , iOS Safari6.0+ , Android Browser 4.4+
   寫法： width: -moz-calc((100% - 12px) / 2);
              width: -webkit-calc((100% - 12px) / 2);
              width: calc((100% - 12px) / 2);
 

 .mobile-share_fb{ display:block; background:url("http://www.shopunt.com/css/mobile/images/mobile-s9398562778.png") no-repeat; background-position: 0 -1648px; height: 80px; width: 80px;} 

 .shrink-attr{ background-size: 152px 2104px; width: 40px; height: 40px; background-position: 0 -824px;} 

 .fb-test{ display:block; background:url("http://www.shopunt.com/images/logo_welcome.jpg") no-repeat; background-size:50% 50%; width: 105px; height: 105px;}