分類
React Native

[React Native] xcrun: error: unable to find utility “instruments”, not a developer tool or in PATH

Situation

使用 React Native 0.55.4 搭配 Xcode 13 執行 npx react-native run-ios 出現以下錯誤訊息,

xcrun: error: sh -c '/xxx/Xcode/Xcode_13.app/Contents/Developer/usr/bin/xcodebuild -sdk /xxx/Xcode/Xcode_13.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -find instruments 2> /dev/null' failed with exit code 17664: (null) (errno=Invalid argument)

xcrun: error: unable to find utility "instruments", not a developer tool or in PATH

重點在於 xcrun: error: unable to find utility “instruments”, not a developer tool or in PATH

Action

出現以上錯誤的原因在於Xcode 13的 xcrun 已經沒有 instruments 參數,可以使用 xcrun simctl list 來取代。

接著說明如何修改以及修改哪個檔案。

首先當你輸入 npx react-native run-ios 指令後,node 會執行ReactNative專案目錄/node_modules/react-native/local-cli/runIOS/runIOS.js。(這也是我們要修改的檔案)

打開 ReactNative專案目錄/node_modules/react-native/local-cli/runIOS/runIOS.js,移動到下方區塊

const devices = parseIOSDevicesList(
   child_process.execFileSync('xcrun', ['instruments', '-s'], {encoding: 'utf8'})

這就是出問題的位置。把 execFilesync方法的第2個參數改為 ['simctl', 'list'] 即可,如下

  child_process.execFileSync('xcrun', ['simctl', 'list'], {encoding: 'utf8'})

Result

錯誤訊息不再出現,通過編譯!!

分類
React Native

[React Native] Cannot initialize a parameter of type ‘NSArray *’ with an lvalue of type ‘NSArray> *__strong’

Situation

使用Xcode 13建置React Native專案的iOS項目出現錯誤訊息,發生在ReactNative專案/node_modules/react-native/React/CxxBridge/RCTCxxBridge.mm,如下

Cannot initialize a parameter of type 'NSArray<Class> *' with an lvalue of type 'NSArray<id<RCTBridgeModule>> *__strong'

Action

解法參考 https://www.jianshu.com/p/7d78792ef9d8

注意以上解法有分版本,我的情況為低版本。解法為修改 RN專案/node_modules/react-native/React/CxxBridge/RCTCxxBridge.mm – line.634 如下

//- (void)_initModules:(NSArray<id<RCTBridgeModule>> *)modules 改為下方
- (void)_initModules:(NSArray<Class> *)modules

Result

錯誤訊息不再出現!

分類
React Native

[React Native] ld: in /xxx/AppCenter(MSChannelUnitConfiguration.o) building for iOS Simulator , but linking in object file built for iOS, File xxx for architecture arm64

Situation

使用Xcode 13建置ReactNative專案的iOS目錄(執行Xcode的Build)後且在建置過程出現以下錯誤訊息

ld: in /ReactNativeProject/ios/Pods/AppCenter/AppCenter-SDK-Apple/iOS/AppCenter.framework/AppCenter(MSChannelUnitConfiguration.o), building for iOS Simulator, but linking in object file built for iOS, file '/ReactNativeProject/ios/Pods/AppCenter/AppCenter-SDK-Apple/iOS/AppCenter.framework/AppCenter' for architecture arm64

Action

解法參考 https://stackoverflow.com/questions/63607158/xcode-building-for-ios-simulator-but-linking-in-an-object-file-built-for-ios-f

簡單的說就是到Xcode的Build Settings -> Excluded Architectures -> 加入Debug 和 Release 為 Any iOS Simulator SDK 等於 arm64 的設定,如下

Result

錯誤訊息不再出現

分類
Uncategorized

[Tool] 跨裝置共享滑鼠鍵盤軟體 – Synergy

因為工作的關係,我最少也會使用3台實體裝置(Win + Mac + Ubuntu)。

但在不同實體裝置之間共享鍵鼠其實是相當麻煩的事,我也嘗試過KVM,KVM最大的缺點說是你必須空出一隻手點擊切換按鈕,而且切換按鈕點久了壞掉也等同整組KVM掛掉。

所以大概在5~6年前我就找到Synergy作為共享鍵鼠的工具(那時候還有免費版,現在應該已經沒了)

以下為Synergy的推坑文,先說兩個重要的前置條件,

首先沒有免費版,一般個人版大約800多台幣,專業版1000多台幣。(我是用一般個人版)。官網售價

第二,要共享鍵鼠的裝置必須處於同個區網,也就是說遠端就沒辦法了。

接下來就是基本的使用過程。

Step 1.首先到官網下載並安裝Synergy,安裝完就會提示你輸入License,License可在你的官網帳號資訊取得。(當然,前提是你已經在官網註冊帳號並付費完成)

Step 2.在每台你想共享的裝置重複Step 1.步驟

Step 3.決定並在Synergy上設定“主要分享裝置“及”其他共享裝置“。這個”主要分享裝置“就是實體的鍵鼠安裝的裝置。至於”其他共享裝置“則會共享”主要分享裝置“的鍵鼠。

預設只要讓主要分享裝置和其他共享裝置位於同一個區網並勾選哪個是”主要分享裝置”,哪個是”其他共享裝置“即可。不必調整任何IP設定,設定非常間單!(官網設定連結)

Step 4.開始使用!

預設的使用方式只要把滑鼠移到目前裝置的螢幕以外位置,就會自動進入其他裝置。你也可以自行設定熱鍵方便跳轉不同裝置

分類
React Native Uncategorized

[React Native] React Native version mismatch

Situation

終端機輸入 npx react-native run-ios 後,啟動iOS模擬器出現錯誤訊息 “React Native version mismatch”

Action

關閉所有終端機並重新開啟位於專案根目錄的終端機

Result

在新開啟的終端機輸入 npx react-native run-ios,不再出現該訊息

分類
iOS

[IOS] 需要更新「App名稱」此App的開發者需要更新App才能與此IOS版本搭配使用

Situation


iPhone(iOS 15) 安裝App之後出現以下錯誤訊息

需要更新「App名稱」此App的開發者需要更新App才能與此IOS版本搭配使用

點擊確定之後程式無法執行,只能保留或刪除。詳細原因可以參考這裡

但解法還必須加上這篇 

以下為重點摘要

出現該問題的原因是使用iOS 15, iPadOS 15, tvOS 15, and watchOS 8的裝置在執行安裝檔之後會檢查安裝檔是否有包含DER(Distinguished Encoding Rules)檔案,若沒有包含DER就會出現以上的錯誤訊息。

而Xcode13或以上版本在編譯過程中預設就會加入DER(Distinguished Encoding Rules)檔案,所以不必調整。但Xcode版本若小於13,編譯過程中不會加入這個DER檔,因此我們就必須使用其他方式加入。

目前Survey有以下幾個解法可以選擇

  • 1.將Xcode直升13:

限制是Xcode 13的最低Mac OS 為Big Sur 11.3。如果你的Mac太舊,基本上沒辦法升到Big Sur 11.3。

除非是透過Patch方式強制升級,但Patch之後就個人感覺而言系統極不穩定,很常出現自動關機或藍屏(沒錯! Mac也會藍屏)。之後就再也開不起來。

  • 2.一鍵resign軟體:

該軟體號稱可以幫你一鍵resign解決問題。但問題是你根本不知道該軟體做了什麼事。對於安全性有極大的隱憂。

  • 3.自行手動resign:

也是本篇的重點,基本上你會了解發生什麼事,如何解決。(順利的話 3 行指令可解決!)

Action

如果不想詳細了解問題或解法,可以按照以下步驟來解決。

  • 1.建立測試用資料夾並拷貝.ipa檔

建立一個空的資料夾(test_resign)並把出現錯誤訊息的.ipa檔(old.ipa)複製到test_resign中

  • 2.重新命名old.ipa為old.zip

滑鼠右鍵點擊old.ipa -> 重新命名 -> old.zip

  • 3.解壓縮old.zip

滑鼠右鍵點擊old.zip -> 打開檔案的應用程式 -> 封存工具程式 -> 解壓縮完成後出現Payload目錄

  • 4.查詢可用的codesign identities

開啟終端機先移動到test_resign目錄,再輸入

security find-identity -v -p codesigning


從出現的結果中挑選”Apple Distribution”的identity,只要記住40碼的數字即可

  • 5.使用codesign工具resign app

終端機輸入

codesign -s "第4步驟查到的40碼數字" -f --preserve-metadata --generate-entitlement-der 
./Payload/app名稱.app


應該會出現以下訊息,直接忽略它!

Warning: default usage of –preserve-metadata implies “resource-rules” (deprecated in Mac OS X >= 10.10)!

  • 6.將Payload目錄壓縮為.ipa檔

終端機輸入

zip -ru resignedApp.ipa Payload


(resignedApp可自行定義)

  • 7.完成

最後resignedApp.ipa就是重新簽名的app了

Result

在iPhone安裝重新簽名後的App,錯誤訊息 “需要更新「App名稱」此App的開發者需要更新App才能與此IOS版本搭配使用“ 不再出現,App也可正常執行。

分類
Delphi

Delphi 翻新之旅 – 啟程

公司有一套大約10~15年的物料管理兼APQP兼WIP以及一些阿撒不魯組合的Delphi應用程式。

經手開發者不詳,文件也不詳(感覺一整個就是不祥)。

因為目前唯一Maintainer(老D大)也是要退休的年紀,只好抓幾個勇者當先驅,準備轉WinForm。

小弟當仁不讓(來不及跑)也列隊在勇者中。

不過,想當勇者還得看本事,老D大給的第一個勇者試煉就開始啦!

解任務前當然要先準備武器和防具,所以小弟找了一些Delphi電子書和安裝Delphi7
(推薦 Delphi 7 基础教程.宋一兵 / Delphi 7应用教程.童爱红)

再花1~2天寫個哈囉握來掌握基本語法和特性,就可以開始打怪啦。

哈囉握

初步了解Delphi之後,我只能說Delphi是個嚴謹(繁瑣)的語言。

除了事件驅動和基本型別跟C#差不多以外,剩下的就是一堆特色(限制)。比如說

  • 宣告順序是變數 : 型別 -> first: Integer;
  • 方法分為 function 和 procedure
  • 左右大括號變成 begin 和 end
  • 判斷式要加上 then
  • 區域變數必須寫在方法的開頭
  • 賦值的寫法為 :=

諸如此類等等,但只要有寫過微C#或微Winform,再花一點時間熟悉特性,要上手其實也不太困難。

分類
JavaScript

[JavaScript] window.location.href 不支援 Chrome

Situation:

在 Chrome 使用 window.location.href(“xxx.aspx”) 無法跳轉 xxx.aspx,但在 IE 可以!

Action:

改用 window.location.assign(“xxx.aspx”) 在 Chrome 和 IE 都可使用!

Result:

可成功在 IE 和 Chrome 跳轉

分類
Architectural Pattern Techniques

[架構師][技巧] 技術雷達

甚麼是技術雷達?

技術雷達是一種評估工具,用來判斷軟體領域中各種技術並對這些技術應採取什麼行動的方法。(來源為 ThoughtWorks,參閱這裡)

象限

技術雷達本身是一個切割成4等份的圓形,這4等份各為技巧(左上),工具(左下),語言框架(右上),平台(右下),代表技術種類(在官方網站中稱為象限)。

技術種類如下:

1.工具
軟體開發的各種工具,範圍很廣,包含IDE,資料庫,版控等等。

2.語言框架
大部分是開源的程式語言,函式庫,框架等等

3.技巧
可強化軟體開發的實務技巧,包含各種設計實踐(模式/原則/開發法/建議/演算法)

4.平台
可在其上建構技術的多樣平台,包含作業系統,微服務,分散式系統

要注意的是象限並不是雷達的重點,只是放置技術的分類。

圓環

在圓形中從圓心由內而外分為四層,各為採納(第1層)(最內層),試驗(第2層),評估(第3層),暫停(第4層)(最外層),代表採取行動。(在官方網站中稱為圓環)。

採取行動如下:

1.採納
已被證實成熟,應該立即使用的技術,但要注意並不代表應該在任何情況下都使用,必須經過評估。

2.試驗
可以使用的技術,但還未被充分證明。重點在知道如何使用這項技術,可以在一些無關緊要的專案實施。

3.評估
可以了解並釐清未來是否會對組織造成影響。進行Survey,開發探索,研究計畫,會議,但還不需要實施在專案中。

4.暫緩
可能是技術不夠成熟或被錯誤使用,別在專案中引入。

項目

出現在雷達上的單一圓點就是項目,代表目前出現的軟體技術。項目位置會不斷變化代表其應該採取的行動

在 ThoughtWorks 實際的技術雷達如下

Radar From ThoughtsWork

透過這四層及四等份就可列出應該對什麼技術採取什麼行動,畫成表格如下

技術種類\進行動作採納試驗評估暫停
技巧應該採用的技巧應該試驗的技巧應該評估的技巧應該暫停的技巧
工具應該採用的工具應該試驗的工具應該評估的工具應該暫停的工具
語言框架應該採用的語言框架應該試驗的語言框架應該評估的語言框架應該暫停的語言框架
平台應該採用的平台應該試驗的平台應該評估的平台應該暫停的平台

建立雷達的策略

ThoughtWorks 每半年會更新一次雷達,基本上可以根據該雷達來挑選想採取的行動和技術,也有提供建立私人雷達的方式,參閱這裡

另外每個不同的組織都有不同的商業目標,要發展的軟體策略也不盡相同,因此最好自行建立組織本身需要的技術雷達。

對於架構師而言,廣度應該優先於深度(但不代表深度不重要),在加入項目的策略上應該盡量讓項目平均分佈在四個象限,而不是讓項目全集中在某個象限或某個象限只有一個項目。

也要特別注意別輕易引入暫緩的項目。若採納的項目和自己專業有關但還很陌生,也請花一些時間進行了解(測試式學習是一個好的開始)。

分類
書摘

[書摘] 系統設計面試指南

無論是參與面試或釐清需求,系統設計常常令人感到困惑,不知如何進行。

我想,原因大概有兩種。

首先,不同領域的系統通常都有不同的設計要素,如何找出這些要素進行提問?

其次,即便提出疑問找出重點,接下來要如何針對這些要素進行高層設計或規劃?

《系統設計面試指南》對於系統設計的初步規劃或高層結構提供合適的解決步驟。

這些步驟包含如何尋找系統設計的要素以及如何對這些要素進行設計規畫,對於經驗不足或想加強系統設計高層結構的相關經驗者會有很大的幫助

作者提出的解決步驟分為以下四個流程,

1.了解問題並確定設計範圍

2.提出高階設計並取得認可

3.深入設計

4.彙整總結

書中分別提到各個流程概要內容為

1.了解問題並確定設計範圍

請認真思考系統本身且提出問題,這些問題是用來釐清需求的條件和假設。千萬不要立即提出解決方案,這只會讓你迷失方向,重要的是務必了解需求的具體內容並釐清這些內容中不明確的地方。
有幾個幫助提出問題的清單:
a.系統需要那些特定功能
b.使用者數量
c.擴展速度(3個月 / 6個月 / 1年)和擴展規模
d.可以使用那些現有技術來簡化設計

2.提出高階設計並取得共識

這個流程的目標為設計出系統的高層規畫並和需求者(可能是面試官)達成協議。
a.提出設計藍圖並要求需求者提供回饋
b.在紙或白板上用方框圖畫出關鍵元素,這些關鍵元素可能是客戶端,API,Web伺服器,資料庫,快取,CDN,訊息佇列等等
c.用粗略估算評估設計藍圖是否符合需求中的條件

3.深入設計

大多數的情況下會根據步驟 2.的高層設計藍圖,進行各個要素的擴展。 因為系統在不同情境下關注點也可能不同,有時候可能關注於高層設計,有時候可能關注於效率瓶頸,此時就必須和需求者(可能是面試官)對設計中的各個元素達成共識並確認優先順序。

另外要注意的是請小心時間管理,不要陷入瑣碎細節。

4.彙整總結

最後的步驟需求者會對後續情況提問或自由討論關於系統的其他主題,可以關注的方向如下:
a.系統瓶頸和改進作法
b.重新檢視設計
c.討論系統異常情況(伺服器故障/網路斷線等等)
d.規模擴增該如何處理
e.其他改進方案

談到這裡,如果對本書有興趣的話,還需注意以下兩點:
1.本書談論高層設計,所以只會有非常少量的程式碼。
2.討論的系統種類還不夠全面,有點可惜。

方格子 – 同步發文

Matters – 同步發文