軟體主廚的程式料理廚房

Xamarin.Forms 有很多種 Layouts，其中我先對 RelativeLayout 來進行了解，原因在於 RelativeLayout 標榜的是讓我們可以依照不用的螢幕大小來佈局 UI 控制項，這一點抓住了我的眼睛，我們來看看它要怎麼使用。

上一篇 Xamarin.Forms（Android）接收來自 Firebase Cloud Messaging 的推播通知，當然也要來個 iOS 版本，但是在這個過程當中走了相當多的坎坷路，才知道原來 iOS 模擬器不能模擬東西還不少，為了開發 iOS App 除了買 Mac 用來建置之外，還得買 iPhone 來測試模擬器不能測試的東西，還要為我們的開發者帳號繳至少一年 $99 鎂的費用，著實花了不少錢，說這些都是淚水啊。

剛開始嘗試要用 Xamarin 開發 Android App 的時候，當我打開 Android SDK Manager 要去安裝所需要的相關 Android SDK 套件時...

第一次看到它是在約莫兩年前，觸發了我的選擇恐懼症，於是開始搜尋 Xamarin 的相關教學文章，大都說哪些要勾，沒怎麼對裡面的每個選項多做說明，兩年後想說這樣不求甚解不太行，花了點時間把 Android SDK Manager 裡面的選項查清楚，給有跟我一樣問題的朋友做個參考。

Firebase 目前在 Google 的旗下，是一個支援 iOS、Android、Web 應用程式的後端平台，此篇文章是要利用 Firebase 中的 Cloud Messaging（簡稱 FCM）服務，在 Xamarin.Forms Android 的專案中接收來自 FCM 的推播通知。

某個週末公司某個裝在 Windows Server 上的 Redis 服務掛點，從 Server Log 看到下面這段錯誤：

# Write error saving DB on disk: Invalid argument
# rdbSave failed in qfork: Invalid argument
# fork operation complete
# Background saving error

是在 Redis 做 Snapshot 的時候沒有成功，進而影響到服務的運作，Snapshot 會失敗大概會有幾個原因：

1. 記憶體不足
2. 磁碟空間不足
3. 權限不足

現在我們就來看看是哪一個原因？

程式的生命週期往往比我們想像中的長，通常年紀愈大的程式包袱愈重，後面接手的人肩負的壓力也愈重，如果我們知道有一個字串叫 http://www.xxx.com ，現在因為政策的關係必須改成 https://www.xxx.com ，偏偏 http://www.xxx.com 被到處寫死在資料庫及程式原始碼裡面，除了把寫死的那些找出來改之外，我們還可以怎麼做？

之前有介紹過 SSL 憑證只要放在 Load Balancing 就可以了，不必在每台 Load Balancing 後面的機器都去放置 SSL 憑證，假設我們原有 http://xxx.yyy.com 的網址，在我們打通了 https 之後想要將 http 都強制重新導向到 https，很直覺地我們想到的解決方案就是檢查打進來的 Request URL 如果是 http:// 開頭的就回應重新導向到 https:// 開頭的就行了，但死亡導向之門也就此被打開了。

對於 Web Site 的橫向擴展，有時候我們既定的印象就是多開機器，如果原本的機器就夠 Powerful，而採用的 Load Balancing 又可以對應到後端多個 Port 的話，我們其實可以選擇再新增一個相同服務但不同 Port 的站台。

HTTPS 協定已普及化了，甚至我們的網站如果沒有支援 HTTPS 的話，在搜尋引擎的排名還可能會被調降，本篇文章就在 IIS 8.5 躲藏在 GCP Load Balancing 背後的環境下，一步步去打通 HTTPS。

有這個議題是既有系統的 Cache 邏輯在 Cache 沒有命中的時候，會啟動 lock 機制，然後去執行一個由呼叫端傳進來的 delegate function 去後端資料庫重新取得資料，可是我們都知道每家公司多多少少都有遺留一些「初學者程式碼」，這些初學者程式碼不一定是初學者寫的，但它有時候執行的效能並不是很好，在這種情況再搭配 lock 機制之下，後面進來的 Request 就塞住了，進而影響客戶端的響應速度。