搜尋

搜尋結果

【盧森堡】※景點※ 威廉二世廣場 William Square
走遍世界
80後愛旅行✈️・2024-10-11

威廉二世廣場（William Square）是以荷蘭國王和盧森堡大公威廉二世命名， 盧森堡市政廳和遊客中心都坐落於廣場旁邊，是盧森堡市市中心的主要廣場。 廣場中央有一座威廉二世騎馬銅像，威廉二世騎在馬上，右手拿著禮帽，兩眼正視前方，威武雄壯。 威廉二世廣場 William Square 23 Rue du Fossé, 1536 Ville-Haute Luxembourg

Ceph Storage 水很深
科技新知
MacauYeah・2024-09-25

筆者不才，早前為大家介紹了一篇關於Ceph Storage的最入門安裝教學。但在後續測試中，發現了一些概念上的問題，需要盡早說明，不然就會像筆者一樣，要砍掉重來很多次。 OSD HDD Ceph Storage的主要功能，就是為Contiainer提供外置儲存空間，它對儲存空間有特定的要求。我們最好在建立ceph cluster(cephadm bootstrap)之前，就為每個node上增加合適的HDD 引述官方說明: OSD (Object Storage Daemons) The device must have no partitions. The device must not have any LVM state. The device must not be mounted. The device must not contain a file system. The device must not contain a Ceph BlueStore OSD. The device must be larger than 5 GB. 簡而言之，大家需要準備新的HDD，不要做任何格式化，讓OS見到HDD但不作任何操作。筆者試過，使用hyper-v VM + hyper-v HDD，也是可以做到的。不過之前筆者於教學中用的 multipass 就沒有這個模擬HDD功能，我們需要使用比較強大的VM作為實驗。 若然HDD是在ceph cluster(cephadm bootstrap)建立之前，就存在的。我們可以經過ceph的網頁介面，或經指令自動加入。 ceph orch apply osd --all-available-devices 若然HDD是在ceph cluster(cephadm bootstrap)建立之後，才加入的。那麼ceph有機會沒法自動發現它，筆者當前的dev版本就出現這問題。我們就需要經指令手動增加 ceph orch daemon add osd NODENAME:/dev/sdb OSD 官方說明文件 https://docs.ceph.com/en/reef/cephadm/services/osd/#cephadm-deploy-osds Reset 在我們做實驗時，若我們想回復到上一個狀態，測試不同的參數差異，Ceph指令並不會即時執行。例如前一句的add osd，想倒回來自行刪掉一些osd，即 ceph orch osd rm OSDID 它就會排隊慢慢做刪除。 但這個過程筆者未有成功過，OSD一直處於繁忙狀態。有機會是因為系統需要保持同步狀態，待成功遷移資料前，什麼都不能動，所以一直都在待刪除的狀態中。 同樣地，當我們想要刪除一些node時，我們使用以下指令 ceph orch host drain NODENAME ceph orch host rm NODENAME 最後也是會卡在刪除OSD的情況 Removing Hosts 官方說明文件 https://docs.ceph.com/en/reef/cephadm/host-management/ Static IP 因為 container 技術，很多都需要固定 IP ，我們做實驗之前，最好先了解你的VM engine如果提供Static ip 。以 hyper-v 建立的 VM ，其實可以同時建立兩張網卡的，一張為預設網卡，用於連網用，另一張則設定為內部網絡。在安裝 ceph 時，經 cephadm bootstrap 所引用的IP則設定為內部網絡的IP。之後基本上使用任何一張網卡的 ip ，也可以訪問到cephadm的網頁介面。如果不是在一開始的階段上準備Static IP ，我們又會在重設/解綁cluster時，同樣因為機器繁忙而卡在不上不下的狀況。

軟件發行也需要維修基金？
手機‧電玩
MacauYeah・2024-05-13

筆者參與軟件開發，都己經有好一定年期。面對軟件開發週期，最痛苦的並不是研發階段。好多打機的朋友，可能會以為軟件應該跟遊戲差不多吧，開發完就頂多修BUG，然後全心地投入下一個項目的開發。要持續花時間更新？不可能，微軟不也是幾年要求重買一次新版的Office套裝嗎？幾年也要另外花錢升級OS。概然全部都要另外花錢買，不就是一個全新的項目嗎？ 其實除了微軟這種夠大夠惡的龍頭公司外，其他都不是這樣運作的。例如我們現在很常用的手機OS，不論Android, iOS，其實只要硬件支緩，就不需要用戶成本就可以升級的。其內的App應用，也因為手機OS的升級，也要持續升級。所以不論你是哪一層的開發者，好大機會都要一直維護已發佈的軟件版本，好讓它可以在不同環境下運作。而這個維護成本，就看你低層的供應商有多進取、有多佛心。現在基本免費的供應商都會大刀闊斧地改功能。大家要留意，是改功能，不是加功能。也就是有些功能過去有，現在使用模式整個有改變，你不得不重寫自己的軟件。 所以筆者現在最頭痛的是，如何為公司維護這些沒法帶來新收入，而又要不斷支付時間和金錢的訂制軟件。 技術上，一定有很多討論，但在於只關心行政的老闆的角度下，根本聽不懂。在於開發者的角度，也需要很長期的實務經驗才能有好一點的佈署。扣除技術，在本質上，若然各利害關系人都曾經考慮過，大家應該都會有更好的預期。 軟件有生命週期，而且這個重複得越來越快。由開發到發佈穩定版本的時間、人力、金錢最高。因為環境變遷，重回開發的機會越來越多，不斷地重複。 需求狠心地下架過氣軟件。過氣軟件，要麼更新，要麼淘汰。但不是所有軟件都受歡迎，值得投放時間。這個在老闆視角下，他很懂。但老闆通常做不了的是，狠心放棄升級不了的軟件。老闆經常覺得，只要軟件放著不更新，就不會有成本。錯，因為老闆只會記得倉庫中曾經有一個軟件可以做到某個功能，可以給賣給某個客戶。但當你拿出來時，才發現不能直接用，還是很焦急地找人更新。 軟件開發，跟很多其他類型工程很像。不是隨時看看圖表，就可以回憶前世今生。舊軟件要救，要花時間先摸索當初的開發工具、環境，追查問題原因，或許最後可只改一句指令就解問題，但總體成本會令人無法接受。 軟件的可複制性不如以前。很多老闆會認為，你之前開發過一次，抄過來做點少改動，不就可以當一款新的應用嗎？因為原來軟件沒有維護，大部份過氣的軟件，即使你有原始碼，你也未必能找到適合的編譯環境來做改動。想要改動？還是老老實實做先更新。 所以，大家對於軟件維護，應該要像物業管理一樣，要預留一部份費用為維修基金。可能還是有老闆會講，怎麼可以預留到這麼多錢去做維修？所以，筆者更加建議，不是要做一個完美的萬能軟件，要鎖定核心功能。沒化更新的，就放棄、止蝕。

Coding | Test Case 值得寫嗎?
科技新知
MacauYeah・2023-11-02

很多做軟件開發的朋友，其實都會聽過Test-driven的開發模式。就像Scrum一樣，名氣很高，但試過的人很少。為何會這樣呢？筆者認為，並非開發者懶，而是編寫Test Case的難度真的高。對比開發程式本身的成本，寫Test Case的時間/學習成本一樣高。 造成這些高成本的原因很多。一來是因為開發者並不像過往一樣，慢慢從零寫程式，一般都應用Framework去預構建一些東西，例如打包Database connection pool，Dependency injection。Framework是好用的，但就令你要模擬Mock up特定資源，變得越來越複雜。所以一般中、小型開發，都鮮有人懂得做Test Case(除了大神獨立開發者外)。筆者對於Spring boot等Framework，都摸索了很久，才能模擬一些特定資源。但Framework一更新，就很多部份都要重寫。所以筆者沒有很強調要做Test Case，因為成本認真大。 最近，在摸清一些test case 基本concept後，筆者又重新開始嘗試編寫test case。以下假設用的是object oriented programming 在開發自己的class，為每個public function，都寫test case。很多IDE, 都有提供相關自動生成test case function signature的功能（就是為你的目標function，起一個只有外框的test function。）vscode雖然不是原生支援java，但只安裝基本的java test package，就可以達到同樣效果。 在不依靠framework的情況下，自己class要『引用』的其他class object，不要經過自己使用new來生成object。全部經set function來傳入你要引用的class object。除非你的class是作為Factory Pattern（工商模式）生產某些object，不然你就不會再有new字眼。 在為自己class編寫test case時，就會可以模擬被『引用』Object的行為。這個object在傳統上可以使用oop中的interface類型來達到模擬又不會影響到原結構的做法。實在不想做interface，java還可以用mackito 這個libraray來硬改Object的行為。 同理，自己class要『引用』一些外部資源，那些設定資源的config，都應該要set function傳入。這樣你在test case中才能起一個臨時的模擬外部資源。 在不使用framework的情況，要全數去自行模擬，當然很痛苦，但至少你可以做一些很簡單的測試。 在使用framework的情況下，還有些教學都是教你mockito繼續模疑。但這會是很痛苦的，因為這樣叫做unit test，單元測試，你要模擬所有東西。在折衷的情況下，應該底層元件做unit test，但上層的元件就做integration test，整合測試。 在做integration test時，就差不多等同使用framework行起部份或必要的資源。而那些必要資源，可能指是的database service, network service。我們可以在test case中設立不同的config，從而把framework指向一些備用資源。 Database好貴，腦細不會付錢set up多一套，自己電腦不夠強，也不能跑起多個開發用Database。好在還有h2 database可以幫你，它是memory可以操作的。只要你的framework支緩就好。在初次使用Framework時，你總會覺得為何Database層要設得這些抽像，其實為的就是讓你可以隨時換Database。不論做測試還是做移植，都會少很多問題。 模擬Network service還是沒有銀彈，要麼就mockito硬改行為，要麼就是提供一套測試用service。筆者曾經為模擬別人的Network Http API，也花了相當時間自己建立dummy server，提供模擬效果。無論dummy的效果有多假，有多局限，例如if id == 1，always return true，也是有一定價值。當你做source code refactoring （重構），又或是做framework升級時，還是讓你可以安心一點。

Design Pattern: Observer / Subscribers - Push vs Pull
手機‧電玩
MacauYeah・2023-09-29

相信一般入行IT不久的朋友，都會知道IT系統更新時，有推和拉(push、pull)兩種方式。特別是Programer，對於觀察者模式又或者是訂閱者模式(Observer / Subscriber )會有更多的使用經驗，例如:OS programing要處理event bus，Mobile App要做的推送通知(Push Notification)。 但一般來說，很少人討論推和拉(push、pull)的問題，筆者就著一些踩過的坑來說說差異。 首先，在一個通訊相對穩定的系統中，Push、Pull都很好用。例如同一個OS內，它的socket或pipe可以看作很穩定，可以假設那些要廣播的消息可以正常傳遞出好。但好用歸好用，這個模式對於越來越複雜的交互系統都有一個無法明確處理的問題：怎樣去處理觀察者/訂閱者自己的操作失敗問題。 對於非IT行業的讀者來說，只要你接觸過手機即時聊天程式(IM，如whatsapp, wechat, facebook messenger)應該都會遇到一個問題就是：你收到OS提示通知，但打開聊天程式卻看不到新的對話內容；又者是你連續收到多個同一個內容的提示通知，那怕你已經讀過了。這些都代表了，手機端當初時沒有好好即時回應是否已經操作成功，不需要重複通知的問題。有可能是手機當時掛了，也有可能是網絡不太好。 上述的例子，對一般人來說，可能影響不太。因為重複收到訊息，又或是漏了訊息，也不會怎樣。但對於業務系統，例如定期收費，多收一次又或是少收一次，都會引起某部份關係者的不滿，即使事後有退費機制，但有些匯率問題，始終會有差異。在傳統架構上，有規模的公司系統都可能會使用內部的中央資料庫等做交易(transaction)管理，整個過程，都要嚴謹地記錄廣擴是否成功、觀察者自己的操作是否成功。 在近代，分散式系統又或是微服務的出現，令上述的中央資料庫無法實行。如何好好地重新定義好Transaction管理，就是一大挑戰。筆者最近亦實作了一個要在微服務的上廣播的觀察者模式，但雪上加霜的是，在互聯網的環境下，廣播的消息沒法保證可以正常傳遞出好。觀察者/訂閱者可能已經正常收到消息，也做了相應的操作，只是來不及回應，網路就斷了。這令重複發送信號的可能增加了。 如果說，要以平民的方式去實作這類廣播，Pull會比較有大的容錯。廣播者只是通知觀察者/訂閱者來拉資料，保證廣播當時的資料量可以盡量地少。廣播者開放盡量大的查閱權，觀察者/訂閱者可以自由決定事後更新要取得的資料量。但這樣每個觀察者/訂閱者都要重做一次同步機制，不過好處是，主動權在於他們自己手上。 相對地，Push的容錯就低一點，但要付出的成本也跟Pull差不多。因為網路環境，大家要重現一個基於TCP/IP而有commit/rollback的難度較大。當網路出現斷線，廣播者無法確定是否需要重做。在重複收到訊號時，最後還是需要觀察者/訂閱者來決定怎樣處理重複記錄。但比Pull好的是，Push可以限制單次訊號的傳送量，也可以確保觀察者/訂閱者一定收到特定的記錄。 上述就是筆者在這一年來遇過的坑，如有什麼不足，很歡迎大家一起來作更多討論。

Git Submodule
科技新知
MacauYeah・2023-09-15

Git Submodule 初次實務上使用submodule來同時管理幾個project的更新。如果有任何理解上的錯誤，請在github中提issue或pull request。 Why Submodule 假設你的團隊中有三個人，A君做A Project，B君做B Project，C君做Main Project。如果可以，A，B各提供已編譯的Binary或Library，給C君直接使用就最好。 但要做到好好管理，A，B都要有自己的發佈系統，即是把Binary上傳到某個分享Repo中，這樣C君就能有條理地通過IDE或Compile工具下載對應的版本。如果是javascript，Repo可能就是npm repo，如果是java，可能就是maven repo。這亦代表A，B君對程式編譯、打包、版本命名等都要很熟悉，不能一輩子都命名為v1.0.0。 如果團隊對這些都不熟悉，C君還有什麼方法呢?其實靠著Submodule的功能，C君也可以硬把A，B的Source code取出，做最後打包。 這跟A、B君自己把source code壓縮然後Email寄給C君是有不同的。因為這樣C君並不清楚A，B的git脈絡：C君需要自己做好A、B的版本記錄。想要只回滾A，B的版本普不容易。但經過git Submodule後，C君可以清楚知道現在正使用的是A、B的那一個commit版本。假如有一天，A、B、C三個都更新了，但發現合起來時就跑不動。C君可以保持A、C的版本不變，單獨提取B的某個版本進行測試。當然，你可以說原本Email也可以這樣管理，但始終你不清楚B的版本記錄，Email的日期並不代表Source Code的進度。(因為有時候,Bug Fix是針對舊版本的做更新，新功能的Email日期反而比Bug Fix要早) 同理，如果大家要連結多個沒有發佈系統的文字資料，也可以利用Submodule。例如筆者正在編輯一本書，當中不同的主題，就是使用Submodule的功能串連起。 Command 馬上看來來Submodule可以怎樣做。 假設你已經知道git 怎樣用，也起了git repo。假設你是C君，進入你的本機repo資料夾內，使用submodule參數。 上面的效果，就是把C君當前repo的狀態，連結到B君submodule當時預設分枝(default branch)的最後一個commit 中。然後C君在自己的repo怎樣更新，它引用到B君的submodule版本都不會變。 直到某一刻，B君說他加了一個穩定的新功能，請C也連帶更新一下。C君也做好自己的準備後，使用submodule參數進行更新。 注意，如果C君有多於一個submodule，上述指令會全部一口氣更新。另外，如果你覺得B君的最新版本不能用，還是可以針對B君取得特定的版本。

手機也可以寫攻略
手機‧電玩
MacauYeah・2023-08-11

上期為大家簡介過筆者使用Github + mdBook制作遊戲攻略。未看過上期介紹的朋友，可以在這個連結(https://lifemag.cyberctm.com/zh_TW/blog/macauyeah/13777) 找到上期內容。今期就繼續為大家介紹一些工具讓手機也能協作。 筆者在開始前，先簡單總結為何會選擇Github + mdBook。 Github是協作工具，追查因為歷史修改記錄會比其他工具更成熟 mdBook以純文字方式操作，適合上傳至Github。 mdBook有自動轉網頁方式，Github有寄存簡單網頁功能。 現在剩下的就是如何做編輯。 電腦端 傳統上，如果要用網誌或Google Doc作為編輯媒介，若你有電腦的話，只要使用現代瀏覽器就可以使用，基本上都會有提供自動儲存草稿的功能。即使你在別台電腦中也可以繼續進度。Google Doc等也有提供離線模式，有時候真的網路不通，可以先修改線下版本再上傳回去雲端。網誌就未必有這些功能。 同樣地，Github也有提供瀏覽器直接修改的模式，不過想要離線操作，就需要使用Github客戶端(或其他Git客戶端)。重要的是，mdBook的原始文件其實只是純文字，可以用最簡單的記事簿程式就可以繼續創作。只是最後要經Github轉化為網頁發佈。 說到尾，有電腦在手，其實什麼方案也不算困難。有網路一切事情都可以解決到。 手機端 但在手機上，因為操作空間的限制，一切都變得很艱難。如果對技術不熟悉的朋友，可能用Google Doc已經是最好的方案。 Google Doc手機版已提供相對友善的排版編輯功能，但它真的不能取代電腦版。很多重要的縮排或插圖功能，還是開電腦使用吧。網誌就更不用考慮了，一般它們的編輯功能都不適合在手機上使用。 而Github的手機版，對於編輯純文字還是相對可以用的。而且mdBook對於一般文章排版也是夠用的。但是這個方案沒有暫存功能，對於長一點的文稿，需要離線慢慢創作就不太可能。 幾經辛苦，筆者終於找到一個Git的手機版，可以輕鬆地離線編輯。那就是PolyGit，它的免費版本雖然一天只能上傳Server 3次，但因為可以離線編輯，即使沒有付費，頂多隔天才一口氣上傳。更重要的是它的文字編輯器，可以看懂部份mdBook markdown格式。你在一邊創作時，就會看到基本的Highligh提示。(不過最可惜的是，PolyGit只有iOS版本，Android版筆者未有找到很好的Github替代品。) 這樣，你就可以隨時隨地，任何地方，都可以繼續創作了。以筆者的角度來講，扣除工作環境外，平時會碰電腦的機會真的少之又少。想好好找個時間、找一台電腦來創作，基本上很少可以實現。但手機就不一樣，午飯在餐廳休息時、晚上睡前坐在床邊，什至乎是大解的時候，拿著手機打打打，也是一個不錯的選擇。 PolyGit 官方連結 https://www.polygitapp.com/

Git Co-Work Flow
科技新知
MacauYeah・2023-06-23

Git Co-Work Flow 雖然git面世已很久，但相當一部份澳門朋友都是solo man，很少合作寫code，對git branch始終都有些恐懼。所以這次來解召一個基本原則，至少你不會爛了code救不回來。 若然大家未熟悉git，初次利用git合作寫program，請盡量減少使用共同分支(branch)，可以極大地減少問題。 第一個大原則 - 建立一條自己分支 在一個repo中，為自己建立一條分支(branch)，可以減少Remote repo中有人比你先commit，而令你push失敗的情況。 Code block由於安全性問題，沒有獨立寫了LifeMag 網誌中，請移到github repo。 除非你的隊友故意你用的分支名先commit，又或者你自己有幾台電腦，幾台一起做改動。不然push 應該不會有問題。 第二個大原則 - 用fetch取代pull 很多人在取用Remote Repo的更新時，都會使用pull。但pull其實是fetch及merge的混合，而且merge還要考慮source branch是那條分支的問題，若然大家都有一條獨立branch，那麼這個無腦pull並不存於每人只有一台電腦下的多人協作中。 fetch的過程中，還可以加入參數--prune，順便依照Remote Repo的指示，同步刪掉本機中一些不再存在的origin/branch。 Code block由於安全性問題，沒有獨立寫了LifeMag 網誌中，請移到github repo。 第三個大原則 - Merge前先Commit 經過前述fetch後，其實他人的改動並未加入自己的分支中，必需經過merge才會出現。但並不是沒有conflict就無腦merge。 假若自己有改動，未commit，應該老虎蟹都先commit。這是為了在merge後，還有機會可以無腦reset，回到之前那個commit。這就像是做任何更新前，先做backup。 Code block由於安全性問題，沒有獨立寫了LifeMag 網誌中，請移到github repo。 第四個大原則 - 由某個特定的人來管理master或main branch main branch(以前叫master branch)，是他人下載時的預設分支，也是Github、Gitlab的預設顯示分支。所以該分支存放著的source code，應該在代表信心度比較高。 在協作的環境中，每人都有自己分支，那就代表要有一位人員做管理，他負責checkout main, 然後合併其他已驗證的分支。 Code block由於安全性問題，沒有獨立寫了LifeMag 網誌中，請移到github repo。 在某些比較嚴僅的環境中(例如Github、Gitlab)，main分支可能會被系統機制鎖定，必需通過系統內鍵的Pull Request，才能通過審核，合併到main。另外，也有一些關於開發上的Git workflow，主要針對功能管理、版本發佈、錯誤修正等控制。有機會再為大家介紹。 希望以上的流程，可以有效且容易地讓大家協作。如果有任何command錯誤或更新，都可以經Github Pull Request通知筆者。

崩壞：星穹鐵道｜體驗章節心得
手機‧電玩
MacauYeah・2023-05-26

上一篇推介的RPG手遊作品《歧路旅人：大陸的霸者》，其首發日期，已是兩年多前的作品。大家若果覺得畫面不太適合，想試試別的，實在可以試試米哈遊的最新作《崩壞：星穹鐵道》。筆者在前述的文章也有強調過，要在手機平台推遊戲，就必需配合手機的操作時機，以及同時重現在機制上的可重複遊玩性。更好的是，不要把課金意圖弄得太難看，讓人有試玩的空間。而《崩壞：星穹鐵道》，就最初遊戲的5小時體驗裏，以上的事都做得不錯，所以盡早為大家推薦一下。 首先講講戰鬥系統，遊戲採用回合制， 每次上場，我方可以最多上場四名角色，有直接影響戰鬥的戰鬥屬性分七種，分別是：物理、火、冰、雷、風、量子、虛數。每個角色只會對應一種屬性，而敵人則擁有幾個弱點屬性。若玩家成功攻擊敵人的弱點屬性，不單有大傷害，更可以令敵人崩壞，喪失行動力。遊戲雖然以回合制進行，但每個角色都有不同的速度值，如何運用角色屬性令敵人崩壞，去創造行動優勢，就是這遊戲的遊玩核心。（回合制就像《FF10》那樣，速度高的角色就相較其他角色行動來得頻密。《歧路旅人：大陸的霸者》則是一回合內各角色行動一次，但先後順序不同。） 雖然除弱點屬性外，還有七種角色屬性「命途」，但因為不直接影響戰局，筆者就不再逐個列出。在戰鬥屬性和命途的互相影響，看似有七七四十九種組合，看似要組一隊萬能隊伍，需要很多的課金。但筆者遊玩的時候並沒有這種壓力。因為上場人數的限制，最多只有四人，所以不論你課不課，也頂多只有四種弱點屬性，所以也不必在初期不斷去抽角色。大概有個五種就足以上場（對比《歧路旅人：大陸的霸者》，八種武器弱點加六種魔法弱點，即便八人上場，一人就一種武器，少量角色才有一種魔法，《崩壞》真的沒有那種課金壓逼感） 戰鬥系統的聲畫演出各方面，都比筆者過去遊玩的要強得多。而且遊戲亦有自動保存機制，每走一段路、跟環境或NPC互動後，都會自動保存，那怕是如筆者般的碎片化時間，也能玩得下去。故事亦沒有明顯的小關卡段落，在劇情上的連貫性就表現得比普偏手遊的小關卡制好。（某些手遊的小關卡過場，看多了真的會覺得很造作，在筆者珍貴的碎片化時間中，看看就會選擇完全跳掉）。如果你真的很久沒有試手機上的RPG故事作品，《崩壞：星穹鐵道》絕對可以是一個選擇。 《崩壞：星穹鐵道》官方網頁 https://hsr.hoyoverse.com/zh-tw/

【日本。奈良自駕】※景點※ 奈良公園 Nara Park ~ 當日本鹿遇上紅葉 大人小孩都玩得開心 (下)
走遍世界
80後愛旅行✈️・2023-03-22

在奈良公園內有一所「東大寺」 又名「大華嚴寺」, 是華嚴宗大本山 南都七大寺之一, 距今約有一千二百餘年的歷史。 1998年作為「古都奈良的文化財」的一部分被列為世界文化遺產。 這是「東大寺」的南大門 南大門內有很著名的「雙體金剛力士像」。 東大寺正佛殿正面寬度57米, 深50米。為世界最大的木造建築。 東大寺是全國68所國分寺的總寺院 往「二月堂」方向能夠俯視大佛殿和眺望奈良市區 由南門進來後可以看到一個美麗的鏡池

遊戲手柄Backbone 評測：使用心得及存在之問題
手機‧電玩
MacauYeah・2023-03-13

近年來，手機遊戲的盛行使得手機遊戲手柄的需求逐漸增加，其中一款較為知名的手機遊戲手柄為 backbone 遊戲手柄。筆者早在半年前就想入手，苦在澳門沒有進口，某寶網購亦只有代購一路，所以遲遲不敢購買。但最近，澳門各遊戲店都有入貨，筆者亦急不及代地買了一套iphone款。以下，就分享一下我的使用心得及存在之問題： 使用心得：最美的部份 沒有延遲、也沒有無線干擾：因為Backbone 遊戲手柄使用的是直接以Lightening直連手機，所以流暢度很高，按鈕也沒有網路上所謂的硬（頂多像是Switch Joycon）。也因為是直連手機，沒有舊款藍芽之間那些干擾問題，不會讓你的藍芽耳機斷斷續續。 設計合理：因為沒有使用藍芽，也沒有內置電池，所以跟手機配合起來也不重。能夠大大減少使用者手部的疲勞感，而且長期玩也不怎吃手機電量。也因為足夠輕，即使帶出戶外也不費力。 不夠完美的部份 安裝方便性：雖然是Lightening直連，但每次連接都要拆掉手機保護套。本體的安裝過程其實很方便，但拆套是件很費時、也怕手滑跌手機的事。折衷方法，就是長期手機跟手柄合體，它可以經外置的Lightening 電源，由手柄為手機充電。合體後手機也不算變大很多，還是可以放在公事包中一同出行。 價格偏高：Backbone 的價格有夠高，比常見的8BitDo系列、PS4、PS5系列，都要高。而且亦無其他可以使用的平台，這個價格下的所有功能，只能用在手機上，所以CP值對比其他手柄就差很大。 圖為合體後的大小，因為沒有手機殼，整體不重也不會太大 總體而言，如果你已經無法玩主機遊戲，想在手機上另找出路，你的手遊亦支援手柄的話，這款Backbone一定買得過。不過如果你本身有遊戲主機，又或者你的手遊共不支援手柄，就不用花錢買這個了。 註：如果你想用手機玩PS remote play，也請三思。因為有些遊戲要用Touch Pad和Motion Sensor，而PS Remote Play對這些功能並不友好。例如The Last of Us第一集，就有手搖電筒的問題，你在Remote Play下就是搖不出來。這不是Backbone的問題，這是PS remote play自己的問題。

高質雲遊戲影片 | 最後生還者Part I
手機‧電玩
MacauYeah・2022-12-23

前幾期筆者為大家介紹了攻略收藏，本期就繼續為大家介紹優質的雲遊戲影片。 不知道什麼時候，討論區上開始多了【雲遊戲】這一個詞。那不是指的PS Now / XBox Cloud Gaming，而是指你看直播主玩了某款遊戲，就當成自己玩了一遍:所有遊戲謎題我都看過，都知道解法，劇情也看了，連操作體驗也知道(直播主都做過)。所以，遊戲也玩完了。 其實網上看別人玩遊戲這件事一點都不新鮮，但想好好地體驗遊戲的各個方面就很有難度，特別是單機劇情遊戲，要麼就是無腦剪接，要麼就是直播存檔。想真的讓你看一遍，就看到了整理好的東西，而且劇情不是硬生生地拼出來的，真的不多。因為要做到這些，制作方一定要先玩通遊戲一至兩遍，再重新理順所有事情，再錄影一次。 能做到這些的直播主、Up主、Youtuber不多，有做的也不能全遊戲都做，只能挑一下比較重點遊戲的來做。 筆者找了好久，才遇見一位比較有誠意，在這方面很持續產出的大神 - 那位名為【黑桐谷歌】的大神。 他最近在【最後生還者】的PS5重制版 (PS5版改名為【最後生還者Part I】)，以最高難度解說了一遍，也做了新舊版本的對比，真的並不是一般人可以做到。他勾起了筆者的回憶，也讓筆者體會到原來這個遊戲還有這麼多的機制是當初筆者漏掉的，這遊戲也絕對有二週目的可玩性。一週目看劇情，二週目做收集或難度挑戰。 完整Playlist https://www.youtube.com/playlist?list=PL7PA3hyhaHFIl8tIWkb9A_CbaLmxkOQ1E 黑桐其實也有在更新其他熱門遊戲，例如當時PS4魂系列中大賣的【血源詛咒】 ，不能說很強很強，但故事與攻略方向都頭頭是道。 完整Playlist https://www.youtube.com/playlist?list=PL7PA3hyhaHFKkIlYJl37Po0ck1IGkSc_h 【艾爾登法環】他也有做，但因為筆者未實際看，不敢現在推薦。畢竟不是所有攻略，都一定能講得透徹，而且艾爾登法環的體量也有大，以筆者查看其他紙本攻略來講，能在完整性上做好這遊戲的解說應該相當有難度。待筆者正式看過後，再為大家推薦。

四年的等待-《戰神：諸神黃昏》下
手機‧電玩
MacauYeah・2022-12-09

筆者總算全破遊戲，但感覺上有些失落，劇情上和戰鬥難度上也有些期待的落差。以下部份涉及劇透，不想受影響的朋友趕緊回頭。 本篇以預言來作為故事的引線，但預言的反轉並沒有帶來合理的戲劇張力。 預言中，一直強調『提爾』帶領眾人對抗奧丁。隨着劇情發展，玩家會找到提爾，但最後這個提爾，只是奧丁假扮的。目的就是要從中引誘主角一行人向一個錯誤方向走，而且在重要時刻奪取關鍵道具。但這個詭計，最後並沒有導向成功，也一步一步讓奧丁陷入困局。 這個不明顯的反轉，讓預言變得不像是全知，缺乏自圓其說的戲劇張力（就是缺乏那種聰明反被聰明誤的感覺） 還有，劇情中去找命運三女神的作用就完全不明所以，主角一行人從中知道了海姆達爾會殺死阿特柔斯這個預言，但最後這個預言就如大家所知的一樣，沒有發生（主角怎會死？）。 在這個結構下，本篇中所謂的『預言』，更像很多電影題材中的平行宇宙或者是量子世界： 並不會有必然的後果， 只是在多個平行世界中，通常阿特柔斯會死在海姆達爾中。 當奎爺得知海姆達爾會殺死阿特柔斯，就去做一把新武器對抗海姆達爾，而這把武器的名字居然是德羅普尼爾，是原神話中奧丁的裝備之一。而更讓人感到可惜的，就是奎爺打海姆達爾要做新武器，打奧丁同雷神就不需要，感覺海姆達爾比奧丁更強。 而阿特柔斯方面，因為幫奧丁拿取面具而釋放出赫爾，這段劇情更是令人費解。因為去拿最後的面具碎片，本來是阿特柔斯、斯露德、海姆達爾三人去拿，而到達目的地後，海姆達爾第一時間就離開，而正當阿特柔斯釋放赫爾，海姆達爾又突然回來鬧場，嘲弄他放走赫爾，最後陰差陽錯令任務失敗。這段劇情又是一段令人費解。 全篇劇情都表現得很情緒化，有前一刻希芙一直想阿特柔斯死，後一刻又為斯露德、阿特柔斯化解矛盾；前一刻雷神要殺死阿特柔斯，後一刻因不願再打就被奧丁桶死。最有劇情反轉效果的，就是奧丁分身扮提爾， 但這有讓遊戲的『主軸』變得不夠嚴謹。 而且這集Boss有點少，配不上諸神黃昏的背景，由頭到尾就死奧丁，雷神，海姆達爾以及光明神，就四個神級人物，感覺配不上原著。到最後奎爺做代理神王，希望還能有下一集吧。

【澳門】永安咖啡室
生活在我城
80後愛旅行✈️・2022-11-25

平時除了去high tea，試打卡的Cafe外，去茶餐廳基本是日常。 這間「永安咖啡室」相信很多人都去過，基本上每次週末去門外必定會有等位的人龍！ 「永安咖啡室」位於荷蘭園附近 （網路圖片） 蒜香豬頸肉湯米 平時我一般會叫撈麵，就是因為吃湯麵真的太熱，會吃到流汗！ 但是這裡的湯麵是用碟的，可以散熱！ 黑椒牛柳粒＋蒜蓉肉丁 湯米 其實平時我都會下廚的，這裡的材料都是很常會出現的，而米粉也就是媽媽米， 但不知道為什麼這裡就是弄得很好吃　(¬‿¬) 永安咖啡室 荷蘭園馬大臣街4號聯豐大厦B座地下

收藏高質遊戲攻略 - UCG典藏攻略系列
手機‧電玩
MacauYeah・2022-11-15

早前在5月份的時候，就為大家介紹了UCG這個內地的國產遊戲雜誌。當時筆者購入的攻略典藏並不多，就只有《鬼泣 終極檔案》一本，其他都只屬於設定集，所以並不敢斷言它的攻略質量。直到最近，筆者看了它的【艾爾登法環攻略本】和【掌機王 NS Vol.SP 怪物獵人 崛起】(內地譯怪物獵人，港台譯魔物獵人)後，實在大開眼界，所以不得不再一次推薦它。 先說一說筆者比較攻略質量的準則。首先筆者並不以最快攻略為目準，反而更看重有沒有完整介紹一隻遊戲，再來就是編章整理/找尋資料的難易度。 以各類網媒來說，例如巴哈、HK01、游俠網，這些網站都著重於快速攻略，加上搜尋引擎的幫助，突發地找些資料，總是很方便的找到。但以遊戲指引來說，他們都很少可以從頭到尾有一個體貼的教學，跟著他們走而又想大大地體驗不同支線，要走兩、三週目一定少不了。一來看他們攻略產生的方式都以素人各自編寫為主，二來一切也是用愛發電，能有效校正已正已經很偉大。想要有條理地，盡可能完整地介紹，變得不太可能。 但作為網媒和紙媒混合的UCG來說，推出典藏攻略，就成了他們最有能力的事。作為有資歷的媒體，他們有機會取得遊戲先行版，可以提前開始編寫攻略。而且他們並不是跟網媒拼首發搶流量，不需要隨遊戲發售第一時間就推出典藏攻略(當然他們也有週刊的短期攻略)，他們反而是在遊戲更新穩定後才推出經修訂的典藏版，整體品質高下立見。 以【掌機王 NS Vol.SP 怪物獵人 崛起】為例，它所載的內容是以3.1.0版本為準，而3.0.0是DLC發售前的最後一個遊戲內容正式更新，距離遊戲首發，中間可是經歷了兩個大版本的改變。在以【破關了就封存】的Game迷民俗習慢來說，經歷了一段時間才推出的話，受眾讀者絕不是隨便玩玩的Game迷。就本書而言，它的資料搜集量真的大，各種武器、防具的制作素材都有列出，雖然未能做到配裝推薦，但這份強逼症，而夠顯示制作組的恆心。再來就是怪物攻略要點，對完全沒有接觸過系列作的新人們，很具有參考價值。而且各項練金(迷一樣的遊戲設定)，都以表格條列式解釋。這可不是一般制作組願意附出的努力(對比之前香港的Great Game電玩文庫的魔物獵人世界的狩獵手冊，GG的實在太沒有誠意) 比較遺憾，遊戲的DLC編章還在有序更新中，想要現在就買到對應攻略，應該還要等個幾個月。不過適逢雙十一，筆者亦繼續加購UCG的其他作品。待筆者好好檢閱後，再為大家推介值得一看的書籍收藏品。 (UCG商城連結筆者就不在這裏分享了，大家在某寶上搜【UCG商城】就可以找到，它還有一家【UCG奧特萊斯】，就專賣一些過氣大作的攻略本，價錢上會更有優勢)