搜尋

搜尋結果

爲何我們不相信靈媒?
宗教玄學
熊神進・2025-05-28

#問米,有人是不相信 做學術研究的時候,有一學生向我表示 「我不相信“問米婆”告訴我的話」("I don't believe what the medium told me"),這種反應體現了人類認知處理中的“確認偏誤現象”。根據Kahneman's System 1 and System 2 Thinking 的雙系統理論,筆者理解爲,當「問米」訊息與個人既有信念或期望(那位學生找過問米婆問事)不符時,大腦會自動啓動防禦機制,表現爲對抗、拒對方的說話。 Festinger的a theory of cognitive dissonance 進一步解釋,當“問米婆”(靈媒)的說話與當事人期望産生矛盾時,"不相信"成爲减輕心理不適的最直接策略。 臨床心理學研究顯示,人類對負面訊息的處理存在顯著的negativity bias,大腦對潜在威脅的反應强度是正向訊息的2-3倍。這解釋了爲何當靈媒預測 「某年某月將出現凶事」時,或問米婆幷沒有按你的提示正確回答當事人的問題時會産生本能排斥。 筆者在日本進行風水勘輿的經歷顯示,玄學文化必須重視社會和諧,這與講座時爲何所有的師傅「被」要求「只說好話」的行爲相符。 靈媒作爲cultural mediator的角色,其社會功能可透過Durkheim的集體表徵理論解讀。當靈媒聲明「所言皆鬼神指示」時,實質啓動了宗教行爲中的神聖代理機制,有效降低當事人的認知抗拒。問米屬靈媒的一種,靈媒透過神靈附身于人的身上來問卜、預言禍福,負責與鬼神溝通。由于靈媒充當仲介角色,幷不具備化解方法,因此不存在利益衝突。他們所言皆爲鬼神的指示,與一般算命有所不同,至于是否相信,則需個人權衡。 建議我的學生以認知靈活性看待問米訊息,理解不同文化系統背後的解釋邏輯,而非簡單二分「信」與「不信」。這既符合心理適應原則,也體現文化智慧的積澱。

練手的膠 - 1| HG EXIA能天使
手機‧電玩
MacauYeah・2025-03-24

之前筆者一直在分享膠模制作上的選擇,這期筆者就來分享一下自己踩過的坑,也許我們可以當作一個系列來分享。筆者參考一位內地up主,分享低價位的橂型,挑選適合練手的素材。不過筆者也只是一名新手,只可以從一些素組、打磨、補色方面,為大家導覽某些套件。筆者也不會限制於低價位的素材,只要有做過,也適合練手的,就會分享。有興趣新入坑的朋友,可以趁著再販期,一起入手筆者的舊套件,一起來體驗一步一步制作的過程。 第一期要介紹的,是2007年的推出的HG EXIA。Gundam.info的Youtube 頻道在2025年初,免費播放OO動畫,為這年的OO系列再販商品帶熱潮,筆者也想當然地趁著這個機會補票入貨。EXIA現在1/144比例中,可以通販買到的,就RG15、HGOO 01、HGOO 44,這三款。因為早期RG軟骨的問題,就沒有考慮RG,只有選擇HG。不過該HGOO 01是2007年的商品,真的不是一般的樸素。除了套件中原有的補色貼紙外,還需要進行多處補色。所以我們除了需要準備滲線、打磨工具外,還需要上色。不過筆者是簡化派,盡可能只用Marker筆補色,就結果來講,效果還不錯。 筆者就直接附上照片,指出這些補色的位置。 補色主要是天藍、深灰、淺灰、紅、黃、白 詳細圖片請見筆者IG 或者小紅書 https://www.instagram.com/p/DHfyseAvP8z/?igsh=MTc4Y3c5d29ydnJwOQ== http://xhslink.com/a/6d6BFOdGRzr8 留意手部前臂,後期滲線有機會流入透明件的地方。要先滲線再補色,最後才上透明件。 補充,條件許可的話,最後還是需要噴上保護漆,因為筆者用的是水性Marker筆,極易刮漆,多層保護漆,後期拿上手,壓力少一點。

Ubuntu 24.04 試用報告-更新
科技新知
MacauYeah・2024-05-21

上期為大家介紹了一些ubuntu docker, multipass的一些改動。本期再繼續介紹一些其他的更新。 apt中的source.list 的位置更新了,格式也更新了,從/etc/apt/sources.list在指向了/etc/apt/sources.list.d/ubuntu.sources,格式變得更親民,就像如下所示 Types: deb URIs: http://mo.archive.ubuntu.com/ubuntu/ Suites: noble noble-updates noble-backports Components: main restricted universe multiverse Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg Types: deb URIs: http://security.ubuntu.com/ubuntu/ Suites: noble-security Components: main restricted universe multiverse Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg 承上更新,雖然格式好看了,noble-security的部份卻故意折開了。而且在live-cd初次安裝時,大家若要改mirror(鏡像站點),只能修改noble noble-updates noble-backports的位置,noble-security還是會指定在官方的位置。筆者猜測它的用意是針對安全性更新,大家應該要直接訪問官方網站,不要等mirror慢慢更新。此一更新,不單影響ubuntu 24.04,連ubuntu 22.04也受一併折開了,只是22.04還是使用舊版。如果有需要變回統一的方向,減少日後自動化的修改,可以像以下修改 ubuntu 24.04的修改 Types: deb URIs: http://mo.archive.ubuntu.com/ubuntu/ Suites: noble noble-updates noble-backports noble-security Components: main restricted universe multiverse Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg ubuntu 22.04.04的修改,刪除/etc/apt/sources.list,新增/etc/apt/sources.list.d/ubuntu.sources (對齊ubuntu24的位置) Types: deb URIs: http://mo.archive.ubuntu.com/ubuntu/ Suites: jammy jammy-updates jammy -backports jammy-security Components: main restricted universe multiverse Signed-By: /usr/share/keyrings/ubuntu-archive-keyring.gpg

辰就是龍,三月有十二條龍起舞
宗教玄學
熊神進・2024-04-09

2024年陽曆2月4日後就是立春,立春後干支是「甲辰」,按照曆法「五虎遁月」甲己之年丙作首,2024年第一個月是丙寅月,二月是丁卯月,第三個月是戊辰月,戊辰是農曆二月二十六日開始一直至三月三月二十七日,在這個月裏我們不難發現出現3次“龍年龍月龍日龍時”,這是古文化使用干支紀法來標記年、月、日、時形成的一個循環現象,當中有一個小秘密,我們要注意一下。 今年爲甲辰龍年,所謂龍月、龍日、龍時即是辰月、辰日、辰時,我們將遇到3個“龍年龍月龍日龍時”,分別在4月10日、4月22日和5月4日的早上7時至9時。原來在生肖學說「龍」是沖「狗」,所謂沖,簡單解釋就是「不喜歡」「厭惡」「結怨」等等情緒,說起來,原來它們在《三世書》中有一段因果。 龍當年跟狗是一對情侶,二者甚爲相好,可是狗出身貧窮,龍是有機心的,牠想當皇后,不想跟狗小弟平淡老實過一生,于是牠就變心,找上鳳王,鳳即是鶏,鳳王跟龍住在一起,狗很自卑,天天流泪,如果你問狗是不還愛著龍,《三世書》幷沒有明確交代,只是寫了一句“狗輪回前在三生石上刻了龍的名字”,我不想作太多假設,看懂的人,自然會解讀。 狗是沖龍,這是一種「得不到」的苦,「人生の本當の顔」在輪回前repeat,我們最後都是一次又一次的放下,愛也好,恨也罷,如果命的交點是重迭,狗的心裏仍是愛著龍,願龍也是。 4月10日、4月22日和5月4日的早上7時至9時,一共有12條龍出現,十二是一個完美地支,也是大愛的體會,犯太歲的四生肖(龍狗牛兔),我們可以做烟供,布施一些受病痛折磨離世的有情衆生,只有行大愛,法布施,才可以無畏受福,福慧雙修。

Git - 持續整合策略 | Git - Continuous integration strategy
科技新知
MacauYeah・2024-02-23

對於原始碼的管理,平常筆者也有在用gitlab的Continuous integration,針對每次提交(commit),都會有自動編譯和測試。但當一個專案中,有很多關聯庫(dependency library)的引用時,光是專案中每個commit 行auto build就不夠用了。更嚴重的是,若然大家有很多微服務micro service,它們的更新不會反映在commit中。 所以定期重跑動動編譯和測試,是筆者認為可以緩解關聯更新的問題,至少可以提高知道問題所在。 筆者先做了一些功課,參考別人怎樣思考Night build (定期重新編譯)這件事。 每次整合新功能到穩定分支(stable branch)之前,都需要做自動測試。 當專案複雜性越來越大,每次自動測試都把全部測試跑一次,就會遇到效能瓶頸。 所以考慮commit時做單元測試(unit test),然後每個固定的時間問隔做整合測試(integration test)。那個固定的時間間隔就是Night build。 而筆者的問題並不是來自於效能瓶頸,而是涉及關聯性更新問題。這些要麼就有是經code base 層面引發關聯性自動試測,要麼就是Night build重複測試。這兩個功能,gitlab都有提供,只是筆者初步構想下,Night build比較易設定。因為要考慮micro service的於沙盒環境的部署,最簡易的Night build只需要一個共用的環境就夠。但也同樣意味著,Night build需要進行多個不同的分支測試。就需要多個不同的環境。 Night build的測時時機也是一個問題,因為測試當下,並不能百份百對應關聯micro services的提交狀況,大家就更需要做好發佈的版本號語意管理。 不知道看完筆者的策略之後,大家又有何看法?歡迎大家一起加入git筆記的編輯。