跳到主要內容

2009東京自由行 Day 1

出生二十幾年來,從來沒有那麼關心颱風過,禮拜三整天都在看颱風資料。一直在想雨天備案。但是那天因為怕掛不上行李,只好坐夜車上去(最早一般高鐵到了也八點45到機場也快9點了,10點的飛機)。

IMG_3395

Eason 一上車就非常有經驗的,吹靠枕,看來是統聯的常客。

IMG_3397

機場裡的柿子先生,看來也是著名景點。

沒想到班機延遲一個小時,早知道就不用那麼辛苦了。車上斷斷續續的睡,根本就沒有睡好。到了機場反而睡不著,還請Eason還上網查颱風狀態,但似乎颱風路徑不變,暴風圈持續籠罩東京。上午5點多到機場,等到了快八點掛完行李,就進去逛免稅店了,海關的入口免稅店是香水店,這裡大家逛了好久,我一整個就是在收集香水試聞卡的,半點免稅的商品都不想買,但是因為背包被水弄濕了,試聞卡片都毀了,唉。

IMG_3413

我們搭往日本的飛機,因為終點是舊金山,所以飛機還蠻大的,不像是前年飛往北海道的較小型班機。

IMG_3422 

飛機上的唯一選擇,雞肉飯,肉很少。機上的服務人員都很資深...,雖然延遲一個小時出發,但是機長似乎在飆機,提前半小時到機場。

IMG_3428

沒想到東京天氣好的很,萬里晴空。一掃害怕第一天行程毀掉的陰霾。雖然飛機僅比預定的時間晚到半個小時,但是電車因為颱風天每班都停,結果還整個行程整整晚了一個小時。

DSCF7949 DSCF7954 DSCF7955

整台車,只有我們。                  玩過火,車子一開,行李就溜走了。Eason的也是,哈哈!

到了茅場町從地鐵一上來,大家的敏感雷達就是藥妝店,看到第一家藥妝店,很多人都躍躍欲試想進去比價。茅場町要到飯店時,遇到一個很熱心的中年婦人,問我們要到哪裡Check in,比手畫腳講了半天,耽誤了一個紅綠燈,他一直認為我們走錯了,後來給他看飯店名字,他才發現自己報錯了。很熱心但似乎幫倒忙。

IMG_3455

其實房間還不錯,只是有點小,這次沒有一個人有照房間,真是奇怪,Check in 完,Morris和Joy就去秋葉原買吉他了,而我們就要趕到台場吃晚餐和泡溫泉。

IMG_3458 IMG_3460

那天運氣很好,百合海鷗號駕駛座的位置,剛好沒人,坐起來感覺好像在開電車,一整個很妙。這是跟團沒有的體驗,做百合海鷗號經彩虹大橋到台場的風景真的很棒。

IMG_3462 IMG_3467

在台場路過的一家店,好像是寵物店。    當天我點的晚餐牛肉蛋包飯 台場 Pomme-no-ki的招牌約1500日票。吃完飯也快八點了,從賣場出來,買完大江戶的票,剛剛有免費接駁公車,但是我想去看看彩虹大橋和自由女神像,想說下一班再坐。

P1000640 P1000652

彩虹大橋                                                 自由女神像

結果八點那班是免費巴士最後一班,為了省錢結果從Aqua City一路走到,大江戶去。第一天腳就快爆了。

P1000687   P1000720

途中經過的船的博物館                               走了半個小時終於看到大江戶。唉!不該省錢的。而且當天只營業到11點,我們九點到,他說溫泉只有開到10點,網頁寫的時間都不準,可惡!

DSC02451 DSC02436

可以選浴衣來穿,穿浴衣洗溫泉才有Feel阿!這是途中請也是台灣的旅客幫我們照的。

DSC02444   P1000731

嗯!你今年流年不利,要不要花點錢來排解一下。沒怎麼泡到的足湯,我才照一下像,工作人員就開始趕人了。

大江戶溫泉物語真的很棒,可惜的是那天太晚來了,大部分吃的店都關了,也才1200日票,值得再來一遍。那天有個小插曲,要結帳走人的時候,我們才發現要還鑰匙來結帳,但是我們都插在置物櫃上,結果回去找,Gina和Joyce的都還在,但是我的卻不見了,翻了半天,一直找不到,只好硬著頭皮去找工作人員說鑰匙不見了,結果工作人發現了,已經回收了,害我嚇死了。

IMG_3558

回到茅場町,想說西瓜卡儲值一下,我選儲值兩千,我想說是不是連續塞兩張一千的進去,先塞一張後,機器就開始在叫了。站務員風風火火的跑過來處理,退了1000給我。第二次Joyce也想儲值2000,想說一張一張不行,就兩張一起塞好了,結果機器想當然也開始叫了,站務員一臉不爽的又跑過來,退兩千給Joyce,他就站在機房旁,等Joyce儲值,Joyce儲值完,換我想再儲值,沒想到他手腳超快,立刻讓機器出現這畫面XD

那天回到飯店也快12點了,想說跟Morris確認一下,明天集合時間,我們先敲門,結果沒人回應,我想說可能還沒回來,快1點時再打電話,還是沒回應,最後睡前再打,Morris才一副睡著後接電話的口氣,我想他們回飯店動作怎麼那麼快,一下就入睡了!第二天Joy才揭曉,原來前兩次,Morris死都不肯接,最後被我煩到起來接。

留言

這個網誌中的熱門文章

解決 CI Trust Issue:Target Must Be Enabled Before It Can Be Used

📱 iOS開發 | 🔧 CI/CD | 💻 Xcode | 🐛 除錯筆記 🔴 問題描述 這兩天在跑 CI 時突然出現錯誤訊息: Package@swift-6.0.swift:PACKAGE-TARGET:CasePathsMacros: error: Target 'CasePathsMacros' must be enabled before it can be used 🤔 嘗試過的解法 💬 Claude 的建議 首先詢問了 Claude,得到以下步驟: 先更新 swift-case-paths 到最新版本 確保使用 "Up to Next Major Version" 執行 File → Packages → Reset Package Caches Clean Build Folder (Cmd + Shift + K) 重新 Build 結果: 一看就知道沒用 😅 🤖 ChatGPT 的建議 接著試了 ChatGPT 的解法,主要是降低引用到的 package 版本。繞了一圈,還是沒用。 ✅ 最終解決方案 最後還是回到 Google,找到了真正有效的解法。針對這個 macro fingerprint validation 問題,有三種解決方式: 📌 方法一:本機開發用(Terminal 指令) defaults write com.apple.dt.Xcode IDESkipMacroFingerprintValidation -bool YES 📌 方法二:xcodebuild 參數 在執行 xcodebuild 指令時,加上 -skipMacroValidation 參數 📚 參考連結: https://vocus.cc/article/690779ebfd89780001859b14 📌 方法三:CI 正統做法 ⭐️(推薦) 步驟 1: 在專案根目錄建立資料夾 ci_scripts 步驟 2: 在此資料夾中建立腳本 ci_post_clone.sh ,內容如下: #!/bin/zsh mkdir -p ~/Library/org.swift.swiftpm/security/ cp macros.js...

用 AI Debug 的迷思:當建議越改越糟時

現在許多開發者習慣用 AI 來協助 debug,但在實務上常遇到一種情況: 依照 AI 建議改了兩三輪後,錯誤仍然存在,甚至越改越複雜。 這種狀況其實有幾個常見的盲點,值得特別注意。 1. 先回到「上一個正常版本」 當你已經按照 AI 的方向修了好幾次但問題仍未解決時,最有效的第一步是: 回到上一個正常工作的版本,縮小問題來源。 許多 bug 並不是你正在看的那段程式碼造成的,而可能是: 同事剛好修改了某個底層模組 某個 shared component 產生 side effect Auto Layout 層級重新 layout 時觸發 crash 如果只是盯著眼前的 function 修,反而容易被誤導。 2. AI 沒有看到你的整個專案 AI 通常只能根據你貼出的片段判斷問題,這代表它不知道: 你的 view hierarchy 裡是否有其他 constraint 影響 layout 某些 model 是否被 extension 修改過 父層或子層邏輯是否干擾目前的行為 整個專案採用的 concurrency 模型是什麼 因此,AI 可能會朝著完全錯誤的方向修,導致反覆修改卻無法解決。 3. Swift 6 例子:錯誤真正原因常不在你修改的那一行 例如開發者常遇到的錯誤: passing closure as a 'sending' parameter risks causing data races 許多人(包含 AI)會開始從 function 內部調整,但這類錯誤真正的關鍵通常是: 傳進去的物件沒有實作 Sendable。 也就是說,你不是要改 function,而是要回頭檢查: 傳入的 model / struct / class 裡面是否有 non-Sendable 成員 是否需要標註 @unchecked Sendable 如果 AI 沒看到相關檔案,自然很難找到正確方向。 結語:AI 是工具,不是預言機 AI 很適合用來: 解釋概念 協助產生測試程式 提供重構建議 釐清你已懷疑的方向 但在 debug 狀況下,以下三件事更重要: 回到上一版,縮小差異範圍。 釐清真正問題來...

借助 AI 除錯:解決登出時的解密錯誤

  前言 最近遇到一個有趣的 bug,趁這次機會試試看用 AI 來協助除錯。整個過程蠻有收穫的,分享給大家參考。 問題發現 Bug 描述 在測試登出功能時,發現 app 會發生 crash。追蹤後發現是在登出時,API 會呼叫底層的解密函式,但解密用的 key 明顯有問題,導致解密失敗而引發錯誤。 由於這段流程是另一位同事負責開發的,程式碼邏輯比較複雜,短時間內看不出根本原因。於是先採取防禦性做法: 如果 key 為空值,就將解密失敗的錯誤吃掉不處理 。判斷後認為這樣不會影響 UI 操作,因為登出後 key 會重新取得。測試後確認沒問題,就先把這個 bug 暫時壓下來了。 深入追查 第一回合:初步分析 趁著有空檔,決定詳細釐清這個問題。想試試 AI 的能耐,於是下了第一個 prompt: 分析 SessionManager 的 processEncryptedData 方法中,為何會發生 bytesToTrim > currentLength 的錯誤?從呼叫該方法的地方分析可能發生的原因。 AI 給出了幾個可能的原因: 加密數據損壞或截斷 網路傳輸過程中數據包丟失或損壞 API 回應中的加密字串不完整 解密後的最後一個字節值異常大 錯誤的加密算法或密鑰 使用了錯誤的解密密鑰或 IV Session key 交換失敗,但程式繼續使用無效密鑰解密 解密產生亂碼 Hex 字串轉換錯誤 包含非法字符、長度不是偶數、部分缺失等問題 AES CBC 解密失敗但沒有檢查錯誤 Whitebox 密鑰準備失敗 IV 不匹配 數據長度不符合 AES 塊大小要求 PKCS7 Padding 格式錯誤 加密時使用了錯誤的 padding 方式 最後字節不是有效的 padding 長度值 (1-16) 多重解密處理錯誤 數據被重複解密或解密順序錯誤 記憶體緩衝區問題 緩衝區大小分配錯誤或溢出 AI 也分析了呼叫鏈: API 回應 → DataTransformer → CryptoHandler → decryptSessionKey → processEncryptedData 評估: 這些分析大多是從相關函式內部找錯誤,但沒有太大用處,...