Kyo's coding life

最近用 Java 8 在寫 Android 的 Side Project, 由於因為工作的關係比較熟悉 C#，寫一寫覺得很多地方很不習慣，除了 Json 要使用 Gson library 來做序列化以外，還有 C# 的 LINQ 在 Java 用發也差很多。 這裡特別紀錄一下 C# 中 LINQ 的 Select() var result = productList.Select(x = > x.name).ToList(); Console.WriteLine(result); 在 Java 中 有 Stream() 可以用。例如  String result = productList.stream() .map(p -> p.name) .collect(Collectors.toList()); System.out.println(result); 來完成，之後如果使用到更多的功能，再來補充吧~

之前有紀錄過開發的網站遇到 CSRF token 認證的問題，事實上解決的方法就是讓使用者盡量存取同一個 Pod 來避免從 A Pod 取得 token，但卻在 B Pod 驗證 token。在 K8s 上可以針對 ingress.yml 裡面去做設定  apiVersion: extensions/v1beta1 kind: Ingress metadata: name: hello-ingress annotations: kubernetes.io/ingress.class: "nginx" nginx.ingress.kubernetes.io/affinity: " cookie " nginx.ingress.kubernetes.io/session-cookie-name: "hello-cookie" nginx.ingress.kubernetes.io/session-cookie-expires: "172800" nginx.ingress.kubernetes.io/session-cookie-max-age: "172800" nginx.ingress.kubernetes.io/ssl-redirect: "false" nginx.ingress.kubernetes.io/affinity-mode: persistent nginx.ingress.kubernetes.io/session-cookie-hash: sha1 spec: rules: - host: DOMAIN.NAME http: paths: - path: / backend: serviceName: hello-service servicePort: hello-port 這邊要強調的是 affinity : "cookie" 以及 affinity-mode: persistent。透過設定 persistent 的模式可以令 Po

最近開發網站碰到一個問題，有時候可以登入成功，有時候不行。但明明帳密都是 Google 記憶的，不可能打錯帳號密碼。後來猜想到是 CSRF 認證的問題，由於網站是透過 k8s 建立的，且 replicas: 2。很大可能性是因為拿 token 是跟 A Pod 拿，但登入是跟 B pod 登入，造成 token 無法驗證成功。 想證明這個問題，我們必須去紀錄 Log，由於我們是透過 C# 的 ValidateAntiForgeryToken Attribute 實作 CSRF 的防禦，因此一開始想法是寫一個 ExceptionFilter 去攔截例外。但發現無法攔截 CSRF 的問題。後來找了一段時間發現，CSRF 並不是丟出例外，而是結果回覆 HttpStatusCode 400。查到可實作 IAlwaysRunResultFilter 攔截結果，並判斷是否是 IAntiforgeryValidationFailedResult 的一種。 程式碼如下:  public void OnResultExecuting(ResultExecutingContext context) { if (context.Result is IAntiforgeryValidationFailedResult result) { // Log here } } 但是這樣還不夠。還必須要強制關閉客戶端錯誤的轉換才行，這樣才可以精準的把結果視為 IAntiforgeryValidationFailedResult 至於怎麼關閉則是在註冊 MVC 服務的時候設定 Config SuppressMapClientErrors = true 即可。      services.AddMvc().ConfigureApiBehaviorOptions(options => { options.SuppressMapClientErrors = true; }); 詳細可以參考 MSDN

掌握正規表達式 一直以來偶爾都會使用正規表達式，但是都沒有一個完整的認識，每次都是問Google大神。最近剛好有一個需求需要大量用到正規表達式，下定決心要把他玩到熟透!因此上網找到一個不錯的網站來訓練 regexone.com  是我找到的一個很不錯的網站，從簡單的到困難的慢慢的讓你快速的得到feedback 又可以測試自己的想法。 透過這個網站的練習，我們可以知道正規表達式可以分成三個程度 第一階段是透過簡單的標記方式來取得模糊搜尋。例如 .(dot), \d, \w, [a-z], [0-9]來限制symbol，透過 ^, +, *, ?, {m,n}, *, ?, {m,n}來限制次數。 第二階段是透過 (...) 來擷取 Group match 第三階段是pattern match ?=.

重複的程式碼 最單純的 Duplicated Code 就是[同一個 class 中的兩個函式含有相同的算式(expression)]，這時候最簡單的做法就是Extract Method。提煉出重複的程式碼，然後讓這兩個地點都呼叫提煉出來的那段新的函式。 透過 Resharper Ctrl + R, M 可以快速的重構擷取方法喔! 高階一點的重複，就是抽象之後看起來是重複的，例如檢查密碼，檢查帳號，檢查長度等等，這些抽象看起來就是檢查，這也是一種重複，可以透過某些設計模式來解決。

工作上用到 Docker 也一段時間了，剛接觸到 Docker 時常常會聽到別人這樣解釋，" Docker 的 Container 技術，類似於 VM 。差別是 Container 比較小，沒有包含 OS，而 VM 會包含 OS"。 這段話我覺得不算是全錯，所以我一開始也是這樣去解釋給別人聽，直到我聽到我同事在面試求職者時問了這句話，"如果 Container 比較快，比較輕量，優點這麼多，為什麼 VM 沒有被淘汰?" 我才忽然意識到，我並沒有真正瞭解這兩種技術的差別。 事實上，這件事情要從解決問題的角度上出發去理解。任何技術的產生應該都是為了解決某些痛點，從這點來思考的話網路上就有很多文章可以查到了，我把我查到的最清楚的文章連結放下本文最下方，有興趣的可以去看看。 VM 是為了解決硬體的資源共享的問題所產生出來的技術，而這個需求仍然存在，並不會因為有了 Docker 的 Container 技術就取代了。這個可以回答為什麼 VM 沒有被淘汰。因為要解決的問題不一樣，事實上很多 Container 還是跑在 VM 裏頭，可謂是相輔相成。 那 Docker 是為了解決什麼問題才發明的呢? 我的消化與理解是 "解決建置環境的複雜度" 而發明的，每個 Dockerfile 會指定使用的映象檔(image)，然後寫下需要安裝的 Tool 指令。按照這個 Dockerfile 上面列下的指令去安裝與建置，就可以重現執行這個 APP Runtime 所需要的環境。這解決了以前工程師常說的那句話 "在我的電腦上跑得好好的，為什麼在正式環境就行不通" 的問題。   參考連結