跳到主要內容

發表文章

避免落入預期解法的死胡同

買錯票某天我要去台北,卻發現自己前一天起迄站買反,買成台北 —> 台南,但是搭車前才發現,詢問服務台人員,只得到回覆說發車前 30 分之前才能退票,自己也依稀記得規定是如此,因此只好認栽,誰叫自己買票沒看清楚,趕緊自己去重買一張到台北的車票。後來老婆提醒我也許可以換票,再至服務台詢問,服務小姐說若是錯過班車,可以當天的票搭乘較晚班次的自由座,但是我給她看我的票是早上出發,卻要搭晚上的車,我就解釋是因為我買錯票,她猶豫了一下,竟然說了一個聽起來可以幫我換票的說詞(我忘了他確切的用詞),我雖然感到驚訝但是我已經買了到台北的票,只能說來不及了,她就建議我仍然採用換搭自由座的方法。預期解法 - 退票這件事我也犯了一個跟某些客戶常犯的錯誤,就是「沒有提供背景資訊」,或說「預期解法」。我心理預期我的問題的解法只有「退票」,因此我只問了特定的「退票」事宜,發現不能用「退票」解決,就以為沒有解法了。如果我能第一時間提供比較完整的背景資訊(也就是買錯票的狀況)給服務台,因為服務小姐擁有較完整的解決方案,她可以從我的背景資訊中,更清楚我的需求,進而幫我想到其他解法。破除方法 - 主動探詢當然服務是雙方的,如果服務台小姐可以在我第一次詢問時,就更主動探詢更多的背景資訊,她也就有機會促使我講出原本的問題,並從中找出其他解法,最終就提供了一個更好的服務體驗。回到原始問題在 ZK 技術支援上,有時客戶問到一個特定的功能可否做到某個效果,問題很簡短,也沒有交代需求或應用情境。如果該功能確實可以達到該效果,我通常會簡短肯定回覆,只是確認或補充說明。如果無法做到,或是該功能跟客戶預期的效果沒有什麼關聯,我會在信末提說:「如果你能告訴我們你的應用情境,也許我們能找到其他解法」。因為我推測這位客戶已經落入「預期解法」的思維,他已經認定這個特定的功能就是解法,如果不能做到他的要求,就是不能解。我問的那句話就會促使客戶描述原本的應用情境,我可以據此去找到另外的替代方案或更好的解法。
最近的文章

專業的提問

Photo by rawpixel.com from Pexels客戶未提供必要資訊某天去了一家從未去過的麵店,因為趕時間看一眼菜單就點「乾麵加蛋」,付款時發現店員可能聽成「麵加蛋」,因此做成「外帶、肉羹麵加蛋」。我的確是忘了說我要「內用」,店員如果只聽到我點「麵」,而店裡提供兩種麵,要避免做錯,他應該要問我:肉羹麵還是乾麵?外帶還是內用?其實客戶未提供必要資訊是可以理解的。提問是種專業技術支援上經常遇到這種情形,客戶通常不會提供他所遇到的問題的完整或必要的資訊,甚至只會說「頁面不會動」這種很籠統的描述。因此我們要根據每個不同案件,來提出必要的問題。有人也許會擔心問客戶問題會不會讓人覺得不專業,好像我們應該要能直接吿知答案。但冷靜想想,不管是誰都無法在缺乏必要資訊的情況下找出問題所在或提供精準的服務。其實遇到問題的客戶是擁有完整資訊、最接近問題的人,畢竟問題就發生在他眼前,只是他不知道哪些資訊能解決問題。而我們提問代表著我們對問題狀況的熟悉與專業,知道需要哪些資訊來解決問題,因此良好的提問能夠有以下效果:引出關鍵資訊釐清描述不清的現象確認彼此認知是否一致因此能夠問對問題也是一種專業。

[Tomcat] 自動部署

問題如果 WAR 檔很大,部署的時候,解壓縮 WAR 如果需要 30 秒,這段時間應用程式就會停止服務。解法減少部署過程中 ,應用程式無法服務的時間。undeployOldVersions
https://tomcat.apache.org/tomcat-8.0-doc/config/host.htmlwar naming
http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Naming綜合以上兩種設定,我們可以在已經部署
myapp.war
的情況下,再部署新版
myapp##2.war
待新版部署完畢,Tomcat 就會自動移掉舊版。

Chrome 放棄請求

有人遇到 Chrome 放棄 (abort) ajax 請求 (request) 的狀況,但原因不明。只知道 XMLHttpRequestEventTarget.onabort 被呼叫了。有人查了 Chrome 的程式碼與也有人歸納自己的經驗,發現有以下幾種情形 Chrome 會放棄請求:發出請求的 DOM 元素已經被刪叫例如說 <img> 將要載入圖片,但在載入發生之前,<img> 就被刪掉了。做了某件事造成不需要該請求例如載入一個 iframe,但卻改變 src 屬性,因此原本要載入的內容就不需要了。多個請求中的第一個失敗了架設有多個請求陸續發到同一個伺服器,先發的某個請求因為網路問題失敗了,例如 DNS 錯誤、400 等,那後續的請求就會被取消Self-signed certificate 不被 android Chrome 信任你發出一個請求到一個 self-signed 網站,因為 SSL certificate 不被 Chrome 信任,因此它就悄悄地取消該請求,也沒有任何訊息。要下載與安裝該 certificate 到 Chrome 中才能解決。點擊在 form 中的 <button>若點擊在 form 中的 <button> 要發出 AJAX 請求,也會被瀏覽器取消。
你可以改用 div 或 span 。如果必須要用 button,必須呼叫preventDefault()。ajax 請求違反 same origin policy參考資料:https://stackoverflow.com/questions/12009423/what-does-status-canceled-for-a-resource-mean-in-chrome-developer-tools/13459106#13459106http://twincreations.co.uk/ajax-request-canceled-status-with-no-http-header/

[Maven] 增加建構 (build) 過程的資訊到 Manifest 中

自動產生建構相關的資訊在部署到伺服器後,有時會弄不清楚這個到底是根據哪一個 commit 發布的、何時發布的、某個函示庫使用哪個版本,或是不想一直修改版號,想要用發布時間代替版號頻繁的部署到伺服器,甚至部署到不同的伺服器,你想知道目前這個伺服器上目前到底是哪一版、或執行哪個 commit 的 code這時你可以把建構過程的資訊加入 manifest 中,再由程式讀出來顯示在適合的地方。用 buildnumber 產生 git commit, git 分支 (branch) 等資訊<plugin><groupId>org.codehaus.mojo</groupId><artifactId>buildnumber-maven-plugin</artifactId><version>1.4</version><executions><execution><goals><goal>create</goal></goals></execution></executions><configuration><revisionOnScmFailure>0</revisionOnScmFailure><useLastCommittedRevision>true</useLastCommittedRevision></configuration></plugin>用 build-helper 產生台灣時間 (GMT+8)。因為 project.build.timestamp 是 UTC+0 時間。<plugin><groupId>org.codehaus.mojo</groupId><artifactId>build-helper-maven-plugin</artifactId><version>1.9.1</version><executions><execution><id>timestamp-pr…

testcafe 除錯

某次用 testcafe 測試時,呼叫某個 library 的函數後,整個瀏覽器就沒反應,也無錯誤訊息,完全無法得知發生何事。這時只好追蹤進該函數才能知道發生何事,以下兩個參數可以啟用 node.js server 端的除錯器:testcafe --inspect --debug-brk chrome ./test.ts
參考 All the tricks that help you debug TestCafe tests只要在程式碼中寫下
debugger;該除錯器就會幫你停在那ㄧ行,接下來你就可單步執行去找問題。最後發現是 Promise 中的 lambda function 內有錯誤:
fs.copyFileSync 是 undefined,因為從 node 8.5.0 之後才存在該函數。後來發現這兩個參數其實是 node.js 的除錯參數,看來 testcafe 本身也是執行 node.js。

2018 台灣領袖高峰會心得 - 面對失敗

幾乎每個講者都提到失敗。

對個人來說,不要害怕失敗,要勇敢面對,甚至要把失敗當做養分,當作天然資源一樣運用,從中我們可以學習、並改進,進而成長。不要把失敗當做是對自己的否定,那只是你人生中必然會出現的一種狀況。

一個例子
我想到前陣子一個發生在我自己身上的事。

某次我在試用公司產品時,發現了一個缺陷,回報給產品團隊時,他們卻說他們那邊無法重現這個問題,但我這邊卻能很明確用幾個步驟產生該缺陷。我與同事花了不少時間找原因,比較我跟產品團隊的環境差別,後來才突然發現我電腦上的客戶端程式與產品伺服器版本不同,因此連線上產品伺服器去操作的時候才會產生該缺陷,然而必須要使用客戶端程式與產品伺服器相同版本才能正確運作。

剛發現原因的時候,又陷入過往錯誤的思考模式,開始否定自己,覺得丟臉,感覺是自己犯了愚蠢的錯誤,弄錯版本給同事找麻煩。過了一會,冷靜一想,其實使用者操作的時候看不出伺服器版本,如果用錯誤的版本連上伺服器也不會立即產生什麼錯誤,大部分功能都可以正常使用,只是就是會在特定情況發生該缺陷。因此未來客戶也可能會跟我犯一樣的錯誤而不自覺,而這樣會導致我們跟客戶之間花費大量時間除錯。於是我建議產品團隊要增加一個版本不一致警告,當客戶端連上一個不同版本的伺服器時,會主動跳出警告顯示兩方的版本,就能避免意外使用不同版本而造成難以除錯的狀況。而主管也都同意增加此功能。