建立 Xcode 的檔案範本

什麼是範本?

Xcode 11 beta 2 新增檔案畫面

在新增檔案的時候,會有預設的這幾種類型可以選擇;而當我們有一些自己常用的架構,如 Coordinator、ViewModel 等,可以自建一個範本來使用。

下面舉例幾個預設的 Swift 檔案

Swift File

位置在
/Applications/Xcode.app/Contents/Developer/Library/Xcode/Templates/File Templates/Source/Swift File.xctemplate

//___FILEHEADER___

import Foundation

SwiftUI View

位置在
/Applications/Xcode-beta.app/Contents/Developer/Library/Xcode/ExtraTemplates/File Templates/User Interface

//___FILEHEADER___

import SwiftUI

struct ___FILEBASENAMEASIDENTIFIER___ : View {
    var body: some View {
        Text(/*@START_MENU_TOKEN@*/"Hello World!"/*@END_MENU_TOKEN@*/)
    }
}

#if DEBUG
struct ___FILEBASENAMEASIDENTIFIER____Previews : PreviewProvider {
    static var previews: some View {
        ___FILEBASENAMEASIDENTIFIER___()
    }
}
#endif

這些是跟著 Xcode.app 走的,而若是我們使用者自定義要使用的,得放在
/Users/UserName/Library/Developer/Xcode/Templates
先建立一個資料夾,或是可以到上述的位置複製一份過來。
需要至少三個檔案

  • FILEBASENAME.swift
  • TemplateIcon.png
  • TemplateInfo.plist

我自己的使用方式是複製系統的 Swift file 來做修改 🔧
也比較好去熟悉可替換文字和 header 的使用方式 👍

Get ETH balance and tokens balance

前言

最近都在處理區塊鏈相關的問題,其中一個就是怎麼直接透過節點(****.infura.io)來取得 ETH 和其他 ERC-20 的地址餘額(balance)。

JSON RPC

ETH 節點所使用的 request body 是依照 JSON RPC 的方式,也就是我們所使用的 request path 都是相同的,像是主要的 https://mainnet.infura.io ;不同的是,我們可以透過不同的 body 內容來區別不同的需求。

基本的 body 格式

{
    "jsonrpc": "2.0",
    "method": "method name",
    "params": [],
    "id": 1
}

取得 ETH 餘額

取得 ETH 餘額的方式較為單純,節點有提供一個 method 是 eth_getBalance,使用起來如下

{
    "jsonrpc": "2.0",
    "method": "eth_getBalance",
    "params": ["你的 ETH 地址", "latest"],
    "id": 1
}

其中這邊的 latest 意思是指向最新的那個區塊取資料的意思;
我們便可以得到 response:

{
    "id":1,
    "jsonrpc": "2.0",
    "result": "0x0234c8a3397aab58" // 158972490234375000
}

其中注意到一點是,result 所回應的是你這個地址有幾聰的 hex 字串,所以當我們取得的時候得注意一下。

ERC-20 的餘額

而 ERC-20 的餘額就沒有上述那麼直覺的取得方式了,我們需要透過別的 method 來完成這個動作。
這邊我們只是需要取得餘額,而沒有更新合約的狀態,所以使用 eth_call 這個 method。

{
    "jsonrpc": "2.0",
    "method": "eth_getBalance",
    "params": [
    {
        "to": "Token 的 contract address",
        "data": "data"
    },
    "latest"
    ],
    "id": 1
}

這邊的重點便是 data 的部分,它的組成為
0x + 8 bits + 64 bits
其中 8 bits 是由 function signature hash 的結果取前 8 bits;
我們這邊所使用的 function 名稱是 balanceOf(address),去做 Keccak-256(SHA-3)hash 可以得到
70a08231b98ef4ca268c9cc3f6b4590e4bfec28280db06bb5d45e689f2a360be
而前 8 bits 便是 70a08231

後 64 bits 則是所要查詢的 ETH 地址,
000000000000000000000000 + 要查詢的地址 40 bits
所以組成起來的 data 欄位就會是:
0x70a08231000000000000000000000000 + ETH 地址
這樣就可以取得相對應的 token 餘額了。

BIP-39 Mnemonic validate

前言

最近處理了一些加密貨幣的問題,其中一個是助記詞的驗證,這邊將會解釋助記詞的生成和驗證方式。

生成助記詞

首先我們這邊所介紹的是助記詞生成方式,先建立一個 128 bytes 的隨機序列,也就是隨機產生 16 個 UInt8 的序列;
主要有分成 128、160、192、224、256 bits(每 32 bits 做為一個區間),而下列會以 128 bits 作為流程解釋。

對隨機序列加密(SHA256)

我們對剛剛所產生的序列做 SHA256 加密,便會得到由 32 個 UInt8 所組成的 Array。

Checksum

用來驗證助記詞是否正確的方式是透過 Checksum 來辨別,而 Checksum 的 size 為序列的長度 / 區間,如我們這邊所提及的 128 / 32 = 4;
意思便是剛剛所加密完的序列,我們取前面 4 bytes 的數值當作 checksum。

產生助記詞

而剛剛的隨機序列(128 bits)加上 4 bits 的 checksum 組成 132 bits,接著我們每 11 bits 作為一個分隔,也就可以得到 132 / 11 = 12 個數字。
而每 11 bits 作為一個分隔的意思也意味著數字的區間落在 0 - 2047 之間,也就是為什麼 12 字的助記詞所支援的單字庫數量為 2048。
接著就到詞庫裏頭撿取相對應 index 的字詞來組成助記詞。

驗證助記詞

驗證的方式就是將上述的流程反過來做,我們先講助記詞轉成詞庫的 index 順序;
接著看最後 4 bits 的內容,也就是這組助記詞的 checksum。
而前 128 bits 以 8 bits 作分隔,接著以 SHA256 加密,判斷前 4 bits 是否和剛剛提及的 checksum 相符。

Change login shells without chsh

前言

最近心血來潮更新了 brew,其中我正在使用的 shells - zsh 也一併更新了,才發現當初在從 bash 轉到 zsh 的時候有指定到版號的部分⋯也就是長得像這樣

/usr/local/bin/zsh-5.6.1

zsh 一更新之後,我的 iterm2 便很合理地打不開,因為找不到 login 的 shells;
當初我是在 bash 裡頭使用 chsh 來變更

chsh -s $(which zsh)

如今打不開 iterm2 該如何更改呢?

使用者與群組

首先先到 使用者與群組

並先解鎖來得到更改的權限

就可以按住 control 並點擊使用者,就會出現 進階選項 可以選擇

最後就可以在 登入 shell 那欄更改即可!

Resign .ipa

前言

我們都知道 iOS 是使用 ipa 檔案來安裝 app,而該如何換掉 ipa 裡頭的憑證呢?

解壓縮

首先,我們先將 Application.ipa 解壓縮,可以得到一個 PayLoad 的資料夾,裡頭包含著一個應用程式 Application

移除舊有的簽章

接著我們透過 terminal 來進行移除的動作

rm -rf PayLoad/Application/_CodeSignature

找出你打算簽章的 provisionprofile

你可以透過 Apple developer 的網頁直接下載,或是查看本機裡頭的檔案,路徑會是在:

~/資源庫/MobileDevice/Provisioning Profiles/

用 Finder 到那路徑之後,可以使用空白鍵來進行預覽,
透過名稱以及 SHA-1 來辨別。

嵌入 mobileprovision 到 app 之中

接著就複製並改名字放入 app 中

cp yourProvisionProfile.mobileprovision Payload/Application.app/embedded.mobileprovision

來製作簽章所需要的 entitlements.plist

先將 .mobileprovision 輸入成 profile.plist

security cms -D -i yourProvisionProfile.mobileprovision  > profile.plist

再來利用 profile.plist 輸出成 entitlements.plist

/usr/libexec/PlistBuddy -x -c 'Print :Entitlements' profile.plist > entitlements.plist\

記得 App Bundle Identifier 得和簽章的名稱一致

/usr/libexec/PlistBuddy -c "Set :CFBundleIdentifier tw.Archie.Application" Payload/Application.app/Info.plist

就可以開始簽章了!

我們先透過 security 來找尋並複製剛剛 .mobileprovision 的 SHA-1

security find-identity -p codesigning -v

這邊記得要從 Frameworks 開始一個一個簽,再來才是 App 本身;
假設你的 mobileprovision SHA-1 為 B77ED97FBFC708A802BDB159CC2ED4E2A4472A09

codesign -f -s B77ED97FBFC708A802BDB159CC2ED4E2A4472A09 --entitlements entitlements.plist Payload/Application.app/Frameworks/someFramework.framework

一個一個簽章完之後,便可以簽署 app 了

codesign -f -s B77ED97FBFC708A802BDB159CC2ED4E2A4472A09 --entitlements entitlements.plist Payload/Application.app/Application

最後確認是否有簽對

我們可以透過 codesign 來查詢

codesign -vv -d Payload/Application.app

如果資訊都沒錯的話,就來輸出吧!🎉

zip -qr Resigned.ipa Payload

題外話,使用 Xcode 安裝

就在 Xcode 之中打開 Devices and Simulators 視窗,並將剛剛最後產出的 ipa 直接拖拉到你的裝置即可!

CoreData with background task

前言

雖然在 iOS 上開發了幾年的時間,但一直到最近才開始使用 CoreData;之前在第一份工作的專案之中是使用 FMDB 來處理資料存取,而後續則是用了 Realm

選擇的原因分別是當時 FMDB 的速度較其餘兩者快速,而後來看上 Realm 的跨平台特色,不過近期開發的感想是能以原生為主的話,就儘量降低對於第三方套件的依賴性。

這篇文章會記錄些什麼

其實這篇文章並不會從頭到尾寫下教學,而把重點放在一些我踩到的雷上,像是⋯⋯

記得要附上 sqlite 的路徑

原先我的 persistentContainer 的產生方式如下

lazy var persistentContainer: NSPersistentContainer = {
    let container = NSPersistentContainer(name: "OfflineWallet")
    let description = NSPersistentStoreDescription()
    description.shouldInferMappingModelAutomatically = true
    description.shouldMigrateStoreAutomatically = true
    container.persistentStoreDescriptions = [description]
    container.loadPersistentStores { _, error in
        if let error = error {
            fatalError("Unresolved error \(error), \(String(describing: error._userInfo))")
        }
    }
    return container
}()

在模擬器上存取了幾次,每次都有 save 且第二次進入畫面的時候,都可以 fetch 得到資料,但是只要重開 App 就會從頭來過⋯⋯

也就是說其實都只是像是存在 NSManagedObjectContext 上,而並沒有實際地轉成 sqlite

補上指定的 URL 即可解決。

...
let documentsDirectoryURL = FileManager.default.urls(for: .documentDirectory, in: .userDomainMask).first
let sqliteURL = documentsDirectoryURL?.appendingPathComponent("OfflineWallet.sqlite")
description.url = sqliteURL
...

performBackgroundTask v.s newBackgroundContext

要實作 backgroundTask 有兩種作法

NSPersistentContainer.performBackgroundTask

persistentContainer.performBackgroundTask { context in
    //do something in background thread
}

NSPersistentContainer 會建立一個 context 在這個 closure 裡頭使用,而重點是當這條 thread 結束之後,這個 context 所管理的物件(NSManagedObjectModel)的所有變數會釋放掉,也就是都會變成 nil

適合用於取得資料並轉型成其他 class / structure 的時候使用。

newBackgroundContext

而如果你必須在後續的程式之中繼續使用 context 所產生的 NSManagedObjectModel 時,你就得要保存其 context;像是建立一個 backgroundContext 並存下來使用:

lazy var backgroundContext = persistentContainer.newBackgroundContext()

//you should use this context to do something what you want
backgroundContext.perform {
//do something like before
}

此時由於這個 context 並沒有被釋放掉,所以其 NSManagedObjectModel 的所有變數便也會持有著;而依然是在其他 thread 上進行,並不會佔據 main thread。

待續

分頁讀取

筆記一下 NSFetchRequest 有提供 fetchLimit 以及 fetchOffset 可以用來做分頁讀取的功能。

SwiftLint

SwiftLint

去年(2018)年末的時候,在 Twitter 上看到一些朋友們在討論著 SwiftLint 的使用,於是便也嘗試在目前公司的專案中導入,來解決 Coding Style 的問題。

Coding Style 的問題

剛進入到這家公司時,最痛苦的事情莫過於毫無章法的 Coding Style,這部分就不一一細數了,詳情可以看前陣子我的 Twitter 動態

專案裡頭每個人寫的格式不同,會造成其他人在閱讀專案時,大幅增加理解彼此想法的成本

簡單來說就是浪費一堆時間在猜你在寫什麼

為了讓專案裡頭的大家有差不多的 Coding Style,可以選擇使用 SwiftLint 來處理這個情況。

實際嘗試

首先先以 SwiftLint 的官方教學來安裝和建構環境,並利用 EthanSwiftLint rules 當作基底來調整,先以別人的規範來看看差異性。

一跑下去便是直接噴了 3000+ issues⋯⋯

可以透過 Rules.md 來逐條看看定義並透過 example 來看怎麼算是 Non TrggeringTriggering;再來一條一條調整改進。

一些心得

目前公司的專案從 3000+ ➡️ 17 warings,而這 17 條是我還沒 refactor 到的 features,所以就還沒那麼急著去調整。

private_outlet 和 private_action

而其中一條規則 private_outlet 給我的感觸挺深刻的,由於我大多數的工作經歷是獨立開發居多,而每個 IBOutlet 都必須為 private 是第一份工作時所踩到的坑;當時公司共有兩位 iOS 工程師,彼此皆為 Junior 的程度,故沒什麼規範和概念,於是便會出現一些神秘的情境⋯⋯

像是不知道為什麼你負責的 UIViewController 刻出來的畫面就是和你想的不太一樣,才發現另一個地方(別人寫的 code)在直接修改畫面的 Layout / value⋯⋯

後來就體會到物件的每個變數和 functions 的 access 問題,而這條規則便是解釋著 IBOutlet 不應該可以直接從其他地方呼叫、修改,像是被這麼做:

fooViewController.fooLabel.text = "Test"

從那時候開始養成的習慣到現在,當發覺其實有其他人也是這麼做,並將它視為一條 rule 的時候真的覺得有點小感動!

整體來說

你可以透過這個 SwiftLint 來反覆思考一些寫程式上的問題,像是 function 的長度、class 的長度以及 Swift 檔案的長度等;如何切割每個物件和 function 等,都是相當值得去思索的習慣問題。

不過也不需要逐條都導入到專案之中,建議是花一些時間找到你最認同的那幾條 rules 來遵循即可!

AWS EC2 with WordPress

前言

Vultr

這個網站原本是在 Vultr 上開一台機器,每個月大概的費用為 USD $6 - 7 元之間,並利用 Certbot 自動更新 SSL 憑證。但後來發現不太會維護那台機器,時常因為記憶體造成資料庫錯誤,每隔兩三天就得去手動重新啟動來解決問題,乾脆就搬家到 WordPress.com 的服務。

WordPress.com

WordPress.com 的好處就是全部幫你處理好好的,然後我使用的是個人版的方案;NT$ 130 / 月,便有提供轉址的功能和一年份免費的網域。不過由於我自己是向 PChome 買 Archie.tw,所以主要是為了轉過去而付費。

但使用服務和自己開一台機器的差異性就在於彈性,像是安裝外掛便被放在商務版的功能之中,而費用為 NT$ 799 / 月。

這樣一用也用了一段時間,直到近期註冊了 AWS 的服務,便決定搬移到 AWS 上。

AWS

在 AWS 上新註冊的用戶可以擁有一年的免費方案,而這個網站目前使用到幾個 AWS 服務分別為

  • EC2
  • Load Balancer
  • Certificate Manager
  • Route 53

這邊來介紹我的流程:

Key Pairs

首先我們先到 EC2 的頁面選擇 NETWORK & SECURITY ➡️ Key Pairs 來建立一組 Key pair,用於之後連接到 EC2 instance

EC2

透過 AWS Markeyplace 開一台新的 instance,使用 WordPress Certified by Bitnami 搭配 t2.micro 的免費方案;而之後若有收費的時候,約為 USD$ 0.012 / 小時,也就是一個月 USD$ 8.64 / 月。
一路照著步驟走,若你本身沒有其他服務要規劃的話,後續的動作都不需要做任何調整,就可以開好一台裡頭已經安裝好 WordPress 的 EC2 了。

這時候你就可以使用那台 EC2 的 Public IP 來開啟你的 WordPress 了!

使用者

在網址的最後加上 /admin 可以開啟管理後台,預設的使用者名稱為 user,而密碼的部分可以透過 EC2 Actions ➡️ Instance Settings ➡️ Get System Log 來查看,裡頭會有標註出密碼的欄位。

綁定個人網域

我們需要透過 Route 53 來處理個人網域的綁定動作,並使用 Load Balancer 和 Certicate Manager 來處理 HTTPS 的連線。

首先先到 Route 53 的 Hosted zones 建立一個 Hosted Zone 備著,其中你會需要將 NS 帶入到購買網域的管理頁面去設定,並進行 Certificate Manager 建立 SSL certificate。

建立憑證的時候,會需要將 CHAME 帶入到 Route 53 裡頭,再來建立一個 Load Balancer 來取得 DNS name,這時候再填入到 Route 53 裡頭便完成了 AWS 這部分的建構。

最後還需要使用最前面所建立的 Key pair 連線到 instance 上,來開啟 HTTPS 的功能。

Bitnami WordPress 詳細的 SSL 圖文教學

⚠️ 幾個需要注意的地方

  • Key Pairs 需要建立在 EC2 instance 之前,且弄丟了你就無法連回去那台 instance 了
  • Route 53、Certificate Manager CHAME 那些設定是需要一些時間轉移的
  • Route 53 和 Load Balancer 是需要收費的功能

整體費用的部分我一個月收再來更新這網站一共得支出多少在 AWS 上,處理完這個之後就可以來補上前陣子的 iOS 心得了!

POSTMAN – Pre-request script

POSTMAN 除了可以發送 request 到 server 之外,也有提供 pre-request script 的功能,讓我們可以撰寫 script 來進行一連串的測試。
舉個例子,我們有三支 API,邏輯為 名稱(Request body)【Response body】:

  • 登入(帳號、密碼)【Token】
  • 取得使用者的消費紀錄列表(Token)【Array<Receipt ID>】
  • 取得單筆消費紀錄(Receipt ID)【Receipt】

在沒有撰寫 pre-request 之前若要取得 Receipt 的話,我們得要先呼叫 登入,接著手動複製 Token 到 取得使用者的消費紀錄列表 的 request body 裡頭,然後再複製⋯⋯(你們應該懂)
這邊就來教教如何先寫好 script,之後只要按最後你想得到的那支 API 就行了!

let account = 'account'
let password = 'password'
let index = 0
pm.sendRequest({
    url: 'https://Archie.tw/login?account=' + account + '&password=' + password,
    method: 'get'
}, function(err, response) {
    let token = response.json().token;
    pm.sendRequest({
        url: 'https://Archie.tw/getReceiptList?token=' + token,
        method: 'get'
    }, function(err, response) {
        pm.environment.set("receiptIdentifier", response.receiptIdentifier);
    });
});

接著在 Params / Body 那邊就可以使用剛剛所定義的環境變數({{receiptIdentifier}})了!
然後請不要真的打範例的 url,是不會有東西回給你的(真的)。

Info.plist localized

一些需要權限的功能都會需要在 Info.plist 裡頭加上說明,而這個說明要實作多語系則是建立一個 InfoPlist.strings(沒錯,名字就是這樣)
然後對相對應得 Key 填寫翻譯,像是:

NSLocationWhenInUseUsageDescription = "說明填寫";

就可以在要使用位置的說明處顯示多語系的結果了。
至於其他的 Key 可以從CocoaKey 官方文件 以及CoreFundationKey找找。