分類: 未分類

  • LaTeX for Windows 11 & VS Code

    前一陣子要 re-build 之前用 LaTeX 寫的文章,試了好幾種方法,最後發現只要把 MiKTeX 裝起來就搞定了。基本上隨附的 TeXworks 編輯器也夠好用。

    但如果想要在 Visual Studio Code(VS Code)中編輯,請先安裝 VS Code 外掛 LaTeX Workshop

    若要使用我之前寫的樣版(LaTeX 中英文報告 preamble 設定(2018)),要調成使用 XeLaTeX 來編譯。細節可以參考下列設定(settings.json):

    {
        "livePreview.notifyOnOpenLooseFile": false,
        "editor.unicodeHighlight.nonBasicASCII": false,
        "[python]": {
            "editor.formatOnType": true
        },
        "python.defaultInterpreterPath": "C:\\Users\\show6\\AppData\\Local\\Programs\\Python\\Python311\\python.exe",
        "window.zoomLevel": 1,
        "security.workspace.trust.untrustedFiles": "open",
        "git.openRepositoryInParentFolders": "always",
        "explorer.confirmDelete": false,
        "git.autofetch": true,
        "interactiveWindow.executeWithShiftEnter": true,
        "latex-workshop.latex.tools": [
        
            {
                "name": "xelatex",
                "command": "xelatex",
                "args": [
                  "-synctex=1",
                  "-interaction=nonstopmode",
                  "%DOC%"
                ]
            }, 
            {
                "name": "latexmk",
                "command": "latexmk",
                "args": [
                    "-synctex=1",
                    "-interaction=nonstopmode",
                    "-file-line-error",
                    "-pdf",
                    "-outdir=%OUTDIR%",
                    "%DOC%"
                ],
                "env": {}
            },
            {
                "name": "lualatexmk",
                "command": "latexmk",
                "args": [
                    "-synctex=1",
                    "-interaction=nonstopmode",
                    "-file-line-error",
                    "-lualatex",
                    "-outdir=%OUTDIR%",
                    "%DOC%"
                ],
                "env": {}
            },
            {
                "name": "xelatexmk",
                "command": "latexmk",
                "args": [
                    "-synctex=1",
                    "-interaction=nonstopmode",
                    "-file-line-error",
                    "-xelatex",
                    "-outdir=%OUTDIR%",
                    "%DOC%"
                ],
                "env": {}
            },
            {
                "name": "latexmk_rconly",
                "command": "latexmk",
                "args": [
                    "%DOC%"
                ],
                "env": {}
            },
            {
                "name": "pdflatex",
                "command": "pdflatex",
                "args": [
                    "-synctex=1",
                    "-interaction=nonstopmode",
                    "-file-line-error",
                    "%DOC%"
                ],
                "env": {}
            },
            {
                "name": "bibtex",
                "command": "bibtex",
                "args": [
                    "%DOCFILE%"
                ],
                "env": {}
            },
            {
                "name": "rnw2tex",
                "command": "Rscript",
                "args": [
                    "-e",
                    "knitr::opts_knit$set(concordance = TRUE); knitr::knit('%DOCFILE_EXT%')"
                ],
                "env": {}
            },
            {
                "name": "jnw2tex",
                "command": "julia",
                "args": [
                    "-e",
                    "using Weave; weave(\"%DOC_EXT%\", doctype=\"tex\")"
                ],
                "env": {}
            },
            {
                "name": "jnw2texminted",
                "command": "julia",
                "args": [
                    "-e",
                    "using Weave; weave(\"%DOC_EXT%\", doctype=\"texminted\")"
                ],
                "env": {}
            },
            {
                "name": "pnw2tex",
                "command": "pweave",
                "args": [
                    "-f",
                    "tex",
                    "%DOC_EXT%"
                ],
                "env": {}
            },
            {
                "name": "pnw2texminted",
                "command": "pweave",
                "args": [
                    "-f",
                    "texminted",
                    "%DOC_EXT%"
                ],
                "env": {}
            },
            {
                "name": "tectonic",
                "command": "tectonic",
                "args": [
                    "--synctex",
                    "--keep-logs",
                    "--print",
                    "%DOC%.tex"
                ],
                "env": {}
            }
        ], 
        "latex-workshop.latex.recipes": [
            {
                "name": "xelatex",
                "tools": [
                "xelatex"
                ]
            }
        ]
    }

    測試 OK 的環境:

    • Windows 11 24H2
    • MikTeX 24.1
    • LaTeX Workshop 10.9.1
  • 團隊的幸福感

    前一陣子同事提到了「追求工作的幸福感」這件事,我花了一點時間思考這件事。直接講我初步的結論。一個團隊的氣氛、向心力或默契,也許可以用下列方式來判斷:

    • 首先,先評估自己做為團隊中的一員是不是幸福的?
    • 接著評估團隊中的其它成員是不是幸福的?

    如果上述二者為真,也就是說團隊中的所有成員無論是對於自己或他人都是感受到幸福的,這或許就是一個很棒的團隊。

    如果你也有 Leader 的身份,可能會跟我一樣在「幸福」二字上有不安定感。有人的幸福是做的踏實,有人的是沒什麼壓力;有人的幸福是薪酬高,有人的是早下班。幸福感無法量化,天坪的一端那個有著烏托邦式超幸福的團隊,雖然理性上知道不存在,但這種 100 分的例子反而簡單好討論。若是一個光譜中間、介於幸福與不幸福的團隊,它牽扯從自我、人與人、到對公司之間的互動,這種幸福感的評價會更不可能。

    工作的本質就是大大小小的需求到回應的集合。對於客戶的需求,我們以產品或服務回應;對於主管或同事的需求,我們以解決方案或配套措施回應。你有問題,我幫你解決,簡單來說是這樣。人與人之間擺脫不了上述關係。客戶對廠商、上司對下屬,甚至是家長對子女。

    所謂不在其位,不謀其政。在工作的關係中,做為受託者,最大的榮耀莫過於託付者可以毫無疑慮地把工作交付予你。在公司的軟硬體或架構流程之外,這種信任感建立在對方的能力、專業、經驗、默契,甚至是共同的價值觀上。當整個群體能為了共同價值觀努力,這將是超越默契的無法描述的新的境界。

    回到幸福感。評估「信任感」是否比評估「幸福感」更容易也更具有工作上的效益?我的答案是肯定的:

    • 首先,先評估自己做為團隊中的一員是不是為人所信任?
    • 接著評估團隊中的其它成員是否為你所信任的?

    如果團隊中的所有成員無論是對於自己或他人都是為人所信任的,這肯定是一個有著超默契的高效率團隊。

  • 人情債

    從早上起床趕火車,到晚上回到家裡,你的資產少了二千多塊。在擠翻天的火車上不小心踩到別人的腳,扣五十元;忘了幫同事買早餐,那略顯失望的神情,扣一百二十元;中午休息時間,去便利商店買了杯咖啡,身上的零錢竟然不夠,惹得被店員白眼,扣了三百元。一整天下來,零零總總加起來竟然近二千元。用台灣中位數日薪來算,賺的錢還不到它扣呢。

    如果向造物者提議在所有的地球人身上裝上所謂的道德自律器,一旦引起他人道德上的不良觀感,便需透過某種形式去償還。例如:極強烈的嘔吐、一瞬間肚子被三百磅的拳頭狠揍、拉一整晚而且是辣到菊花開的腹瀉。叫它「天罰」好了。應該滿有趣的。

    我特別建議天罰要延遲奉還。當事人引發他人道德不適,初始自己也只是感覺像是偶發的不適,要過了下班時間回家後才會重重地受罰(我們會看到夜間的路邊一堆人倒在地上嘔吐之類的)。雖然受到懲罰的原因很難直接聯想,然而由於生物的制約效果,就像小狗聽到鐵碗的碰撞聲便知道是吃飯時間了,久而久之便無聲無息地將兩者連接在一起,但身體或大腦可是毫不自知的。道德不良感愈差、次數愈多,不適感就愈強烈。強度要多變態有多變態。

    若是符合資本主義精神,天罰是採用扣錢的呢?套在社畜上,也就是說不需要做任何身體苦難形式上的道德補償,只要記得天天去上班,讓存簿裡面的金額足夠。即使不小心踩到別人,也不至於會有噁心想吐、拉不完的肚子那些症頭。只要乖乖上班賺錢確保荷包滿滿即可?

    造物者先問你:要包多少紅包錢給下個月要結婚的好友?行情是一千八到三千六,或是三千六到六千?認識超久的要不要包個一萬?上次他包一萬,我是不是要包一萬二?欸,這場婚宴每一張宴會桌的開銷?我坐車長距離赴宴的交通費?他的新娘或她的新郎富不富有?原生家庭有不有錢?我的薪水與他(她)的薪水比值?這問題自古以來都哲人難解。

    再問另一種年終歲末要給父母親、兒孫子等等的紅包錢。在父母親面前,紅包的數字恐怕連造物者都不敢置喙?

    人與人之間的交往有不同的深度,會有摩擦也會有相互幫忙,也就是所謂的人情債。如果單把人情債量化,好像就跟道德債是差不多的意思了。

    所以天罰採用扣錢的是好主意嗎?一來恐怕難以量化,二來世界的經濟會完蛋吧。

  • 極簡主義與實用主義

    近幾年看了不少極簡主義的作品。最早是近藤麻理惠的整理魔法,後來偶然接觸到斷捨離的原書,也在 Netflix 上看了幾個美式的極簡主義紀錄片。看了一些專家或網友的說法,有人說極簡不是窮,真正的極簡反而很花錢;有人說整理與減物只是極簡的一半,極簡的重點是在心靈層面上的。雖然我喜歡極簡主義,但我過的不像極簡主義者。若說有什麼我生活上的行為準則比較接近極簡主義的,大概就是我重視複合性延續性

    我認為極簡的表層意含是追求物品的複合性。多合一或是機能性是能有效簡化物品數量的一種方式。科技的進步本質上也是將複雜度封裝起來,以更簡化的形式表現。後人基於前者,將複雜度不斷地封裝,將操作介面不斷地簡化。於是從第一台跟房間一樣大的電腦,到可以拿在手上的智慧型手機,在晶片技術的加持下,使用面向從專業人員漸漸走到大眾。大多數人在日常生活中都可以受益於科技進步所帶來的極簡化。只是要留意的是不要被科技大廠之間的規格競爭給迷惑,需要與想要只是一線之隔。

    我認為更深入一點的極簡是:延續性。如果一個選擇無法維持一段時間,五年、十年或一輩子,那麼這就不屬於極簡的範圍。延續性原則「有可能」能讓我們擺脫日常生活中的諸多煩惱 XD。其中一個例子是極限節食。靠這個方法來減肥對我來說不可能持續一輩子,因此不符合延續性原則;去健身房重訓這事,我通常認為如果不是為了專項的訓練,在家裡就能做的徒手訓練會更符合延續性原則。

    延續性的界線在哪?極限節食的減肥型態也許不符合延續性原則,但若強度低一點的減食能夠同時達到健康的目的並符合延續性,那麼即使是放棄減重的目的也可行的。同理,居家的徒手訓練與健身房的重訓也是不相衝突的例子。

    極簡主義雖然重視「減法」,但並不代表人生的選擇只能是單選,它也可是複合的。同時,人生也會有新的挑戰與需求(例如新的工作或生小孩),這便是與極簡主義共生的「加法」。延續性原則可以在「減法」上給出一個方向;複合性原則可以則可以在「加法」上給出另一個方向,從而補足極簡主義對於生活的實用性

    什麼是實用具體成效才是關鍵,極簡主義無論型式為何,該實作手段若有效,甚至在生活層面上大大有效,它便是可以遵循的原則。這便是結合實用主義的極簡主義流派,姑且稱之「實用極簡主義」(我自創的)。

    以上。

  • LabVIEW 的輸出路徑一覽

    LabVIEW 內建的路徑有這幾種:

    • Current VI’s path
    • Application Directory
    • Default Directory
    • Default Data Directory
    • VI library
    • Temporary Directory

    路徑的呼叫方式可參考下圖:

    把 VI 放在 C:\some-folder 中,執行後的結果如下:

    比較容易有疑問的是 Application Directory。實測後無論是掛在 LabVIEW Project 下或是在 Main Application Instance 下(不透過 LabVIEW Porject,直接開 VI),其輸出路徑都一樣。

    Build 成執行檔(.exe)後再執行,輸出的路徑會有滿大的差異:

    Current VI’s path 整個變了,傳統上在 Build path 時用 “.." 來取得所在目錄的方法會失效。這樣看來,用 Application Directory 來操作路徑會有比較好的相容性,至少將來 build 成執行檔後其目錄路徑不變。

    另外資料或暫存檔分別放在 Default Data Directory 與 Temporay Directory 也會有比較好相容性(路徑不變)。

    再補充一點,Temporary Directory、Default Directory 與 Default Data Directory 可到 Options >> Paths 中修改:

  • LabVIEW 的 Error Case Structure 與 Indicator 的輸出值

    很像是 CLAD 會出現的考題:試問下圖的 In case 值在有 Error 的情況下為何?

    答:是預設值,效果等於 Use Default If Unwired,也就是 In caseOut of case 一樣。

    下面的測試把上圖的程式當成 SubVI 來使用。區域 1 中,可以看到有 Error 時的 Out of caseIn case 輸出都是 0,也可以說 In case 是以 Use Default If Unwired 來輸出。區域 2 把 Error 清掉後 SubVI 的輸出就正常了。

    若把 SubVI 的 Error case 中的 Out of case 給定一個值(如下圖的 9487):

    Out of case 會以給定的值(9487)輸出。In case 則不變,一樣是 0,維持 Use Default If Unwired 的設定。


    結論:以後不用再把 Indicator 拉到 Error Case Structure 外,並特地設定 Use Default If Unwired 啦。

  • 倉頡輸入法 9 個月使用心得

    目前使用倉頡 9 個月,除了新手期之外,到現在都使用 Windows 11 內建的倉頡輸入法。以下來分享使用心得:

    Windows 內建的倉頡沒有良好的候選字/重碼選擇方案。使用這套倉頡在打字時,除了第一候選字外,其它候選字只能透過數字鍵來選擇。例如「果」的第一候選字是「困」,「果」本身是第二候選字。要完整地要打出「果」字的流程:先輸入「WD」,等候選字框出來後,才能按下「2」 來選「果」。候選字的順序並不會因為使用頻率而調整,也不能手動調整。也不能像五代倉頡一樣使用「X」鍵來選字。使用上非常不流暢。

    萬幸的是,如果要選第一候選字,直接打下一個字就好了。例如「困」字,鍵入「WD」候選字框跑出來後,直接打下一個字碼,「困」字會直接出字。(只是 Windows 的候選字順序老是不常用的字排在第一位……,像「快『樂』」、「『引』用」、「『感』覺」,都不在第一順位)

    Windows 內建的倉頡沒有良好的標點符號輸入方案。大部分的全形標點符號在半形模式下幾乎都要搭配 Ctrl 鍵才能打得出來,常用的開關符號像是「」『』()幾乎無法直覺的出字。這個情況對於需要頻繁混打中、英文的人來說非常不友善。看看其它輸入法如 RIME 小狼毫、倉頡平台或 PIME 都有不錯的符號輸入設計。更別說跟無蝦米這種符號輸入王者來比了。

    以下就我個人經驗整理 Windows 內建倉頡的中文標點符號輸入技巧:

    先看最基本的
    ,。…;、
    這些都直接用 Ctrl + , . / ;' 來出字。

    另外 3 個要組合 Ctrl + Shift 才會出字的:
    :?!
    分別是 Ctrl + Shift + ; / 1

    也可以用倉頡內建碼表來出字,不過要強記:
    ZXAH →:
    ZXAI →?
    ZXAJ →!

    開關符號比較麻煩,用倉頡內建的碼表最方便:
    圓括號
    ZXBE →(
    ZXBF →)
    (記憶法:BEF = beef 牛肉)

    引號
    ZXCD →「
    ZXCE →」
    (記憶法:CDE。就英文順序,沒口訣)

    剩下的常用開關符號可以用 Windows 輸入法的 ` 鍵功能(` 鍵是 Esc 下面那顆按鍵):
    `[ → 常用開符號
    `] → 常用關符號

    破折號使用 ` 鍵功能比較簡單:
    `-1`-1 → ——

    雙書名號
    Ctrl + shift + < →《
    Ctrl + shift + > →》

    單書名號很煩:
    `< 後按 1→<
    `> 後按 1 →>
    (上面的 < 與 > 是按鍵的上排符號,要搭 Shift 才能輸出)

    以上應該包含書寫用最常見的標點符號了。


    前面提到的 ` 鍵功能也可以打一些奇怪但實用的符號
    `- → ←、→
    `+ → ±
    `= → ≦、≧、≠
    `| → ↑、↓
    `\ → ↘、↖
    `/ → ↗、↙
    (再次提醒,上面有些是上排符號,要搭 Shift 才能輸出)

    其實滿多符號都可以用這個模式敲出來,大家可以試試。另外在這個模式下,按 Tab 不會展開,也有可能不相容新舊版的倉頡。

    除了上述的標點符號輸入方式,也可以用全形模式(按 Shift + Space 切換)。在全形模式下,大部分的標點符號直接打或最多加 Shift 鍵就能打。不過缺點不少,除了切到英文時會維持在全形模式,要再手動切回半形外,有一些符號像「」還是只能靠 ` 鍵功能來打。對常常用中、英文混打的我來說完全是雞肋功能。

    順帶一提中、英文混打的小技巧。如果上一個字有候選字,而且第一個候選字是你要的,按 Shift 鍵後直接打英文即可。原理是按下 Shift 鍵時會選擇第一個候選字並切換至英文模式,可以少做一個動作。


    其它功能:

    關聯字。目前沒在用。之前用了發現會影響輸入節奏,也許之後再試試。

    萬用字元 * 或 z 查碼的功能。滿方便的,用 * 可以匹配 1 或多個字碼,z 可以匹配 0 或多個碼。可惜的 * 或 z 不能放第一個,所以一定要記得首碼才能查碼。我是覺得用 z 查碼比較方便,因為可以少按 Shift。我建議連注音輸入法也一起啟用,遇到不會打的字可以備用著。

  • 無蝦米轉倉頡半年心得

    本人使用無蝦米輸入法 15 年,去年年未決定改用倉頡。目前已經使用快五個月,打字速度約 30 字/分,日常打字尚可。剩下的就是熟練度的問題了(之前用無蝦米快樂表速約 120 字/分)。

    優缺點先寫

    從我個人的角度來看的優點:

    • Windows 與 iOS 都有內建
    • 開源沒有版權問題,也就是不用花錢買

    缺點:

    • 學習曲線高
    • 打字慢
    • 有版本問題(像現行就有三代與五代)
    • 標點符號輸入很廢

    我改用倉頡為的就是上面兩項優點(其實那兩項可以視為同一項),所以即使缺點遠多於優點,我還是硬著頭學了。

    評估

    當初決定不用無蝦米時,評估了行列、雙拼、速成與倉頡這幾個輸入法。這幾個輸法都各有其優秀之處。個人最後考量的是:主流作業系統要有內建

    我所使用的作業系統是 Windows 與 iOS,速成與倉頡兩者都有內建;雙拼輸入法只有 iOS 有內建;行列則是只有 Windows 有內建。

    速成的學習難度比倉頡低,可視為簡易版倉頡,不過有大量選字的需求,也不像注音或拼音可以智慧選字。

    雙拼的設計很棒,打兩個碼就可出字,輸入節奏很好。搭配良好的自動選字功能未來不可限量。而且想說拆字類型的輸入法用這麼多年,改用拼音類型的換換口味也不錯。可惜 Windows 沒內建。

    行列的設計也很不錯,要背的字根少也不需要背鍵位,打字速度應該是上述選項中最快的。Windows 也有內建。只是當時已經看了倉頡的教材一陣子了,再者行列在 iOS 上無內建。總合評估後,最後選擇了倉頡。

    倉頡三代

    先說 Windows 內建的倉頡相當難用(Windows 10 & 11),因為沒有預覽字的功能,非常不適合新手使用。而且 Windows 內建倉頡只有支援倉頡三代的編碼

    倉頡三代與五代是目前最主流的兩個倉頡版本,二者的細部差異在這邊不贅述。因為現在多數的倉頡輸入法可以相容三代與五代,這意味使用者可以用混用三代與五代的編碼來輸入,這能提高輸入的容錯率,對新手是福音。

    回到 Windows 內建的倉頡,除了只支援三代,部分中文字的編碼也有問題,以及 Windows 新倉頡的惱人的選字設計,讓這套內建的輸入法到處被人嫌棄。

    我個人不建議新手使用 Windows 內建的倉頡。我自己是先裝 PIME 輸入法當做過渡期的輸入法(相容三代與五代)。這之間也試用過倉頡平台與 RIME。

    倉頡平台雖然主打倉頡五代,但可以切換倉頡版本;RIME 預設是五代,但可以另外裝倉頡三代的支援檔。這三個輸入法當中 RIME 使用體驗最平衡,倉頡平台則是輸入節奏最流暢。PIME 則是中規中舉。

    輸入效率

    倉頡最多拆 5 碼,平均可能在 3 至 4 碼之間;無蝦米最多 4 碼,搭配簡碼或簡速字根,平均可能來到 2 至 3 碼。體感上真的有極大的落差。

    另一個跟無蝦米比較大的差別是同形不同碼。例如倉頡的拆碼:
    象 vs 豕 (napo vs msho );
    海 vs 每 (eowy vs owyi)。

    其中「豕」的下半部或「母」這個字的形明明長一樣,卻是不同的拆法。由於無蝦米大根取字的拆字邏輯,前述這兩個形的無蝦米字根分別是 Q 與 M,不管放在什麼字裡面都一樣。

    打字的速度說到底還是取決於單字與肌肉記憶的強度。字根或拆碼的邏輯愈一致,對於肌肉記憶強度的提升愈有幫助。倉頡同形不同碼的特性在這裡就是問題了。

    更別說倉頡的符號輸入被無蝦米屌打好幾條街了。

    iOS 的倉頡

    改用倉頡以來最大的驚喜就是 iOS 內建的倉頡輸入法太好用了。除了預覽字的功能外,某些字只要打 2、3 個碼就可以按空白鍵出字了,出字效率比在 Windows 上好多了;加上強大的智慧候選字功能,打字的體驗比之前裝的第三方無蝦米輸入法好上太多了。而且還相容三代與五代。

    只能說蘋果在這個部分還是比較用心啊。

    一句話的結論

    沒事不要亂換輸入法折磨自己。


    註:這篇文章因為第一次沒存檔而打了兩次。當成是練打字吧。

  • iOS 14 的 App 資料庫

    等了這麼久,iOS 14 新的 App 管理功能「App 資料庫」,終於打破了 App 在安裝數量上的一道超大阻礙。

    App 資料庫/Apple 管網

    在安裝新的 App 後,大家一起以來的習慣是會整理它:可能移到某一個分頁,或者是移到一個已經謹慎取名過的資料夾。例如「遊戲」、「交通」、「美食」等。

    在命名這些資料夾時,總會發現無法歸類或套用的 App。例如某個「時刻表.app」好了,到底要放在「通勤」還是「旅行」,還是放在「交通」?

    因此也發展出很多資料夾管理的手段或風格。最極致的情境是所有 App 都分門別類,主頁上沒有任何落單的 App,一切井然有序;反例則是全然散亂,不在分門別類上下功夫。

    新的「App 資料庫」透過自動化的分類解決上述問題。使用者甚至可以選擇在安裝新的 App 時,讓它不出現在主頁面上,預設只能在 App 資料庫中找到。如果有需要再拉到頁面中。

    這個選項進一步的讓安裝 App 的動作,就像打開網頁或加入書籤一樣輕鬆無負擔。甚至已經安裝的 App 也不需要再「整理」或「管理」了。因為不常用的 App 有可能不會被優先顯示在 App 資料庫中。

    當 iPhone 或 iPad 給你 512 GB 甚至到 2 TB 的容量時。在「App 資料庫」的架構下,使用者只要想著如何抓爆 App 把機器塞滿即可,再也不用去管一狗票的 App 要怎麼收納了。

    所以資料夾管理控們,趕緊解放自己的 App 吧。不過這不是老早就可以做的功能嗎 = =a

  • 貓貓性別疑雲

    去年 2020 年中的時候領養了另一隻公的黑貓:樂事。後來改名叫 Winter。

    Winter 非常活潑好動,基本上任何玩具都逗得起來,而且無時無刻都給逗。個性很親和無害,除了碰到沒見過的生物(例如:狗)可能會暴走誤傷人,無害指數是連用手指來逗貓也不會受傷的等級(警告:用手逗貓是訓貓師最大禁忌)。

    比較早到的賓士貓 Summer,非常的愛找 Winter 作伴。奴才們都笑他是守弟奴。

    不過隨著體型的變大,貓貓的蛋蛋感覺起來好像空空如也(?)。帶去打預防針的時候,在準備詢問醫生前,醫生看著滿屋跑來跳去的 Winter,笑說公貓就是這麼活潑好動。

    大概再過二個月,體型又大一些。奴才們還是弟弟來、弟弟去的亂叫,不過 Winter 的蛋蛋還是沒有任何要露面的意思。

    傳 Line 問了原領養的貓舍,對方回應小時候性徵不明顯,是可能會誤判的。

    等到下一次去到醫院,在診間順利打完第三劑預防針後,我把心裡疑竇透露給醫生。醫生馬上進行檢查。

    果然是母貓。

    所以之前那邊弟弟來弟弟去的,根本就是在搞笑 XD。之後也覺得愈看愈像母貓。

    不過其實這篇只是要炫貓。人再怎麼蠢,帶去結紮那天也會被打醒的。