後來請前輩幫忙看了以後發現,因為 ssh 對檔案/目錄權限控管非常嚴格,因此要 check 以下幾點:
- ~/.ssh 目錄的權限必須是 700
- ~/.ssh/authorized_keys (/etc/ssh/sshd_config 中的預設金鑰檔) 的權限必須是 644
嗯...實際測試之後似乎都不是這些問題,或應該是說,這些都不是主因
坎尼不死心地減少關鍵字,找到了這篇討論串 (其實前面放的討論串也有解法)
解法:在 Web.config 中,把 Compilation 的 batch 屬性設定為 false
batch 屬性在官方文件的說明為
"If True, eliminates the delay caused by the compilation required when you access a file for the first time. When this attribute is set to True, ASP.NET precompiles all the uncompiled files in a batch mode, which causes an even longer delay the first time the files are compiled. However, after this initial delay, the compilation delay is eliminated on subsequent access of the file."
大意大概是說:當需要該檔案且為第一次進入時才會 compile,以免造成 compile 時間過長,開發人員及客戶都會不爽
所以坎尼猜測就是因為這原因造成下列狀況
然後系統就混亂了『為什麼有兩個同名的人住在不同的地址,那我到底該去哪個地址找這個人?』
『這個地址明明就住大中天,你還要說你是小中天』
從外表看起來除了 UI 不美觀似乎沒啥大問題
但一打開請修項目:喔喔喔喔喔
幾百個選項一起跳出來,真是令人嘆為觀止 我眼睛也為了找修理項目眼花…
很明顯的,這個請修項目大概只做了第一正規化
坎尼直覺其實可以分為:大類、次類、問題說明 (上圖)
這樣 user 在找的時候可以先選水電類,接著可以找到日光燈,接著再填寫問題
像目前系統做法,日後要是又多了100項
那豈不是要讓下拉選單突破天際瀏覽器邊框了?
當然也有正規化太複雜,導致效能降低的情況,這時候就是要反正規化
但坎尼相信這些資料的量應該還不至於因為正規化而產生瓶頸
當然同頁面的請修地點也有同樣的問題存在
剛好最近又蓋了新宿舍,選單瞬間又加了幾十間房間 orz
(1421的同學抱歉啦,如果有看到這篇可以私信給坎尼,再請你們喝飲料)
另外還有個問題,最前面的 610421 很明顯是 primary key 之類的資訊
基本上對使用者是無用的,而且還曝露出自己系統設計原則
設計對白「我是610421的學生,想問幾個問題 (下略)」
除非客服有很好的資訊系統輔助
不然除了通靈之外,鬼才會知道 610421 代表什麼
最近因為工作關係,遇到要用 Google Form 及 Google Sheet 所以研究了 Google Sheet 裡的一些 function 怎麼用 首先,分享一下如何在 Google Sheet 裡用規則運算 :D