Reader

《古典音樂入門指南》

在大多數人眼中，古典音樂是既晦澀又抽象的存在，不僅沒有歌詞以助於理解作曲家想表達的内容，甚至還有更複雜的結構和更多的信息量。本文旨在讓你在讀完之後就能邁進古典音樂的大門，再也不會聽不懂古典音樂—— 這 是 不 可 能 的！

雖然不能讓你在讀完之後聽 懂 古典音樂，但是本文確實系統性地介紹了一些古典音樂的知識。當然，不瞭解這些知識也不影響你找個流媒體軟件上的古典音樂歌單作爲做其他事情時的背景音樂，比如工作、學習，或者只是單純地放空大腦休息。甚至，你願意的話還可以根據自己聆聽時的情緒體驗對這些古典音樂進行分類。這實際上也是 非常棒的聆聽，並不需要爲自己聽不 懂 而感到愧疚。如果這樣對你來説就足夠了，那麽這篇文章讀到這裏也就足夠了。

但如果你并不滿足於此，而是希望能更進一步，切實踏進古典音樂的大門，那麽相信這篇文章可以對你有所幫助。

寫在前面 – 1

首先的首先，非常建議在認真聆聽古典音樂之前，爲自己準備一個比較好的聲音回放環境。或者説，購買一些 通過聲音進行溢價的聲音回放設備。又或者説，買副好點的耳機/音箱。

因爲本文并非此類設備的選購指南，這裏只給出一點簡單的建議：根據自身的經濟情況準備 ￥500~2000 購買適合自己聽音環境的 入耳式耳機/頭戴式耳機/音箱 即可。上文提到的通過聲音進行溢價的聲音回放設備指 Hifi/監聽 耳機/音箱，并不包括 Beats 一類通過作爲奢侈品牌而進行溢價的設備。

爲什麽我們需要更好的聽音環境？在古典音樂中（事實上很多現代音樂也有此類需求），低音是非常重要的，并且常常有動態很大（也就是最小音量到最大音量有相當大的差距）的樂曲或對準確定位樂器位置有較高要求的樂曲。在比較差的聽音環境下，這些樂曲裏的重要内容無法被完整展現，會影響聽音者對於樂曲的感受。當然，並不是説沒有更好的環境就完全無法享受古典音樂，但我認爲如果有條件，在這方面進行投入是絕對值得的——你會發現音樂和以往完全不一樣了。

寫在前面 – 2

有1就有2，這一節主要介紹一些網絡上可以獲取的、與本篇文章内容有關的資源。

• 視頻：一次认识所有最常见的管弦乐团乐器

  這條可以搭配 認識樂器 一節食用，來感受一下不同的樂器的聲音特點。

• 視頻：古典乐体裁分类技能快来Get吧！

  這條可以搭配 認識體裁 一節食用。

• 書籍：《聆听音乐》[美]Craig Wright （鏈接為dropbox）

  這本書是耶魯大學的同名課程的教科書，内含一些音樂組成内容的介紹，和以音樂史為脈絡進行的樂曲特點分析與鑒賞。雖然需要一點基本的樂理知識（能認五綫譜就行），但是不失爲一本優秀的入門教材。

配套CD：2CD, 6CD 。這是書配套的CD（喜馬拉雅FM），具體的使用方式看書本的前言。

配套视频课程：聆听音乐（23集全）-耶鲁大学- 。這就是 那個 同名課程。注意，他們授課是默認學生已經提前預習過書本内容的，如果直接看視頻會感覺信息比較散。

• 视频：【中央音乐学院】音乐鉴赏（全54讲）

  這是中央音樂學院的周海宏老師的課程，淺顯易懂、幽默風趣，但默認學生有一定的樂理知識和音樂素養（畢竟都是央音的學生了嘛！）。另外這個視頻的收音質量非常差，建議在鑒賞樂曲的環節暫停視頻，然後自己在常用的流媒體平臺搜一下曲子來聼。

漫長的前言到這裏就結束了。從下一節開始，就是本文的正文了。另外要提的一點是，古典音樂不僅僅有以器樂爲主的曲子，當然也包括聲樂爲主的曲子（如大量需要人聲的宗教音樂、一些音樂歌曲等），以及兩者的混合（比如包括引入了人聲的一些交響樂，像是 貝多芬第9號奏鳴曲“合唱”）。本文主要 不介紹 聲樂爲主的曲子，因爲…不熟。

認識樂器

古典樂曲中常見的樂器可以被分爲以下幾類：鍵盤樂器、弦樂器、吹奏樂器（管樂器）以及打擊樂器。

• 鍵盤樂器 keyboard

主要包括鋼琴 piano 和管風琴 organ（以及鋼琴的“古代變體”羽管鍵琴/大鍵琴）等。鋼琴我想應該不需要過多介紹，管風琴則是一種非常龐大的樂器，一般在建築建造時就鑲嵌在建築體中，常見於教堂。

• 弦樂器 string

主要是提琴家族，包括小提琴 violin、中提琴 viola、大提琴 cello 以及低音提琴 double bass。這四種樂器長得都差不多，在音色上也比較接近（要我説，他們的特點就是沒有特點），主要區別就是音域的高低。其中，小提琴經常作爲獨奏樂器，一般也會在樂團中負責主要旋律，而大提琴和低音提琴則主要負責填充低音聲部。除此之外，還可能會在部分樂曲中找到豎琴 harp 的身影。

• 吹奏樂器 wind

吹奏樂器主要分爲木管樂器 woodwind 和銅管樂器 brass 兩大類，主要的區別是銅管樂器使用號嘴吹奏，而木管樂器一般使用簧片，或是直接往氣孔中吹氣。

木管樂器主要包括長笛 flute（及其變體短笛）、單簧管 clarinet、雙簧管 oboe 和巴松管 bassoon。它們的聲音各有特點，長笛清亮，巴松管低沉而詼諧，單簧管有著木管的基本特色，而雙簧管比起來聲音更加纖細一些。此外，爵士樂中常用的薩克斯 saxophone 也屬於木管樂器。

銅管樂器則主要包括小號 trumpet、圓號（法國號）French horn、長號 trombone 以及大號 tuba。小號、長號以及大號主要區別在音域的不同，整體而言小號比較嘹亮，而大號多作爲低音聲部為樂曲填充低音綫條。而圓號與它們相比，聲音更加洪亮且圓潤，比起其他三個刺激的金屬音，聽起來會更像號角的感覺一點。

• 打擊樂器 percussion

打擊樂器的種類十分繁雜，功能也不固定，大體上而言是提供更多的音色選擇，或者進行一些節奏上的表達。這裏只能介紹一些常見的：定音鼓、大鼓、軍鼓，鑔/鑼，三角鐵，木琴等。具體的聲音可以在視頻裏感受。

認識管弦樂團

管弦樂團的組成一般包括上述除鍵盤樂器以外的所有樂器，其中弦樂器的演奏者佔樂團中的大多數，管樂器以及打擊樂器因爲能量相較弦樂器強得多，因此在樂團中并不會配置太多。此外，小提琴一般會分爲第一小提琴和第二小提琴，分別擔任不同的角色，真是備受寵愛的樂器呢。鍵盤類樂器被排除出管弦樂團之外的理由可能是，他們太全能了，反而不適合在樂團這種分工合作的地方幹活。

另外簡單講講指揮的作用。指揮除了在演奏時進行節拍以及一些細節処的指示以外，最重要的是在排練時把樂團調教為能表達自己内心的音樂的樣子。不同的指揮對音樂的理解不同，指揮出來的樂曲表達就會有所區別。此外，樂團中如此多的人從接觸新曲子開始要如何協調，這也是指揮需要努力的地方。

認識體裁

體裁，可以大致上理解爲樂曲的類型。本文中，體裁會以兩種角度來介紹：規模和内容。

首先是規模。大體上來説，樂曲可以被分爲三種規模：大、中、小。

• 分類爲 小 的樂曲，那當然就是獨奏曲啦，基本上由鋼琴 piano 和小提琴 violin 演奏。奏鳴曲 sonata 就是一種獨奏曲，但是要注意的是，除了鋼琴以外，其他樂器的奏鳴曲大多都有樂器伴奏（想想人家在管弦樂團裏都只能承擔一個角色，想要有豐富的樂曲當然是要伴奏的！），而這個伴奏的樂器…多半就是萬能的鋼琴。
• 分類爲 大 的樂曲，那就是需要動用交響樂團的曲子，主要有兩類：交響曲 symphony 和協奏曲 concerto。交響曲就是一整個交響樂團通力合作所演奏的曲子，而協奏曲則是在交響樂團的基礎上，再有獨奏樂器一起演奏。在協奏曲中，獨奏樂器有時和樂團合作，有時和樂團對抗，但一定少不了讓獨奏樂器突出表現的段落。
• 分類爲 中 的樂曲，又有一個單獨的名稱：室内樂。這類樂曲一般有數人到十數人一同演奏，規模遠遠比不上交響曲，但也比獨奏曲要豐富得多。像弦樂四重奏 string quartet 就是一種室内樂，一般包括 2把小提琴+1把中提琴+1把大提琴（低音提琴被踢到爵士樂那邊啦！）。

而根據内容來分，那就複雜了。因爲太複雜了這裏就不介紹了。 但不管從内容上怎麽區分，一定都可以通過規模進行重新分類。

• 早期的區分可能是各地舞曲、康塔塔、彌撒這種帶有濃厚的民族或是宗教氣息的區分。那個時期的曲子一般都沒有標題，現在都是以後人的編號來稱呼，如 XXX的第X號XXX曲。
• 到偏後期思想解放后，作曲家們覺得“我爲什麽不能創造自己的分類呢？”，於是就有了很多諸如敘事曲、狂想曲、幻想曲、夜曲、音詩、交響詩等等等等千奇百怪的分類，也有把以往的練習曲、前奏曲、歌劇序曲單獨拿出來發展爲一個分類的。雖然不同的分類有一定的區別，但我覺得有心的話可以在遇到的時候查一下，或許有助於加深對曲子的理解。

在這一節的最後，來簡單介紹一下曲子的 名字。比如這樣一首曲子 Violin Concerto No.2 in D Major, Op.15 "blingbling": I. kirakira - Allego，這是什麽意思呢？

• Violin Concerto：這是一首小提琴協奏曲
• No.2：這是這位作曲家（是誰？）的第 2 首這類曲子
• in D Major：這首曲子寫在 D大調 上（這是什麽意思？）
• Op.15 "blingbling"：作品編號 15，作品名 blingbling。作品編號一般是後人整理了 一位作曲家的作品 後標上的，一般按照作曲時間排序。編號體系有好多種，在大多數作曲家身上用的是 Op 體系，也有像巴赫的 BWV、莫扎特的 K，等等等等。一般而言，可以通過作曲家和作品編號唯一地確定一首曲子。
• I. kirakira - Allego：這是這部作品的第 1 樂章（這又是什麽意思？），樂章名 kirakira，并且這一樂章應以 快板 Allego 的速度演奏（這些用以標注速度的詞來自意大利語）

可以看到，其實只有作品編號是用來確定這首曲子的，其他的内容都只是描述一些信息。等等？最重要的作曲家呢？很遺憾，一般在樂曲的名稱中是不會標注作曲家的，作曲家是額外的信息，需要單獨説明。

再來解釋一下剛才提到的樂章和D大調。樂章是對一首作品的分割，不同的樂章一般有不同的樂曲結構和速度，也會有明顯不同的主題和内容。而D大調，就現在而言比起注意D，更應該注意 大調。

在古典音樂中，樂曲一般會明確地在大調或者小調上寫作。通過一些一兩句話説不清楚的手段，大小調有著明顯的聼感差異：大調更加明亮、爽朗，而小調更加陰暗、憂鬱。也就是説，觀察曲名中的大小調，可以瞭解到這首作品的基本聼感取向。不過在一些大規模的作品中，并不會從頭到尾都堅持一個調，可能會進行大小調之間的 轉調，來創造更加豐富的色彩。

另外，作品名和樂章名并非每一部作品都有，也並不是每一部作品都會分樂章。如果這位作曲家只寫了一首這類曲子，那多半也不會有 No.X。

音樂史

不對啊？我們不是來聼曲子的嗎，怎麽要講音樂史了？

在音樂的不同發展時期，作曲的基準是在改變的。不同時期的音樂有不同的特點，當然也應該用不同的方式來欣賞。這裏不會展開太多，只是簡單介紹一下。

• 巴洛克時期：這時音樂剛剛從純粹的宗教音樂中走出來，從教堂裏走到…教堂和宮廷裏。但整體而言器樂音樂的發展還不太成熟——除了那位變態（褒義）的巴赫。這一時期的音樂主要比較華麗，但一般而言沒有什麽非常深刻的内容，以形式美居多。這一時期是復調音樂（簡單來説就是有多條旋律綫）的極盛時期，其中最具代表性的音樂體裁就是大名鼎鼎的賦格。這一時期的代表人物有巴赫。

• 古典主義時期：這時候正是生產力擡頭的一段時期，音樂逐漸走向普羅大衆。因此這一時期的音樂開始往“好聽”上發展，主調音樂（簡單來説就是一條旋律+伴奏，現在的流行音樂基本上也是這樣的形式）逐漸成爲主流。這一時期的音樂大多沒有非常需要解讀的内容，主要是音樂本身以及音樂中的情緒的表達。這一時期的代表人物有海頓、莫扎特、貝多芬（維也納樂派）。

貝多芬晚年屬於古典主義和浪漫主義交接時期，因此他後期的作品明顯帶有一定的浪漫主義色彩。

• 浪漫主義時期：這時候正是工業革命+啓蒙思想的時間，生產力極大發展的同時，思想也逐漸解放。作曲家們開始想，“我爲什麽不能在曲子裏放入更多我想表達的内容呢？”，并且發現舊有的體裁太過掣肘，沒辦法自由地塞入自己想表達的内容。因此這一時期，樂曲體裁大量增加，并且樂曲中開始不僅僅只是樂音、情緒的傳達，還會帶有更多作曲家想表達的内容，比如有些是敘事，有些是寫景，等等。大多數我們能叫上名字的作曲家，都屬於這一時期。

• 印象主義：印象主義（實在不能算一個時期，但是也有著舉足輕重的地位）主要是和美術中的印象派同一時期，兩者都有一些相通的特點：都與傳統理論有非常大的差異，并且都通過獨特的手法準確地表達出了所描繪對象的“印象”。印象主義的曲子大多給人一種漂浮、夢幻的感覺，這是通過一些傳統理論中禁止的内容創造出來的。印象主義的代表人物主要是德彪西、拉威爾。

• 現代主義（表現主義）：我聼不懂。我真的聽不懂。這一時期已經是20世紀中後期了，突出一個在理論上探索更多可能，但是聽起來真的…不太美妙。你可以嘗試一下，但是我不聽。

可以看到不同時期的曲子特點都不盡相同。如果在欣賞古典主義時期的曲子，那就不太應該去追求“作曲家想表達什麽？”這樣的閱讀理解；如果在欣賞巴洛克時期的曲子，就更應該去追尋樂音中的形式美；而浪漫主義、印象主義的曲子，有相當一部分帶有一個標題（稱爲 標題音樂），這個標題有助於傳達作曲家想要表達的内容（譬如德彪西的《大海》，理查德施特勞斯的《死與變容》，斯美塔納的《我的祖國》，柴可夫斯基的《1812序曲》等等）。區分作品所屬的時期（或者説 曲子的特點 所屬的歷史階段）有助於更好地欣賞古典音樂。

聆聽音樂

終於到了這一節了，但實際上到這裏反而能説的沒那麽多了。可以跟著（上面提到的課）學習一下，這裏只簡單地給出幾個我個人覺得比較適用的要點：

• 比什麽都重要的：請務必騰出專門的時間專注地欣賞！ 只是把古典音樂作爲一種背景音樂，是無法專注地進行欣賞的。當然這也是一種無可非議的享受音樂的方式，但是這與本文提到的欣賞或者說是鑒賞并無關係。

• 作品所屬的歷史階段的特點：剛剛才提到過，有助於瞭解這部作品應該 從什麽角度 欣賞

• 標題音樂的標題：剛剛也提到了，如果有，説明這是一種可能比較標準的 切入點

• 大小調：前文也有提到過，這有助於瞭解作品的 大體情緒基調

• 情緒：在聆聽過程中情緒會自然變化——旋律往高處走就會興奮，往低處走就會低落、平靜；音符移動的距離近會覺得平緩，移動得遠會覺得激烈；音符組合和諧會覺得歡快明朗，不和諧會覺得痛苦糾結；高的旋律會聯想到其他感官的“高”，低的旋律則會聯想到其他感官的“低”……諸如此類的感覺是音樂 獨有的，是其他文藝作品難以直覺性地傳達的。情緒的表達可以説是音樂最重要的部分，注重自己在聆聽過程中隨著樂曲的變化而產生的情緒，我認爲是欣賞古典樂曲中 非常非常重要 的一環。

• 主題：古典音樂中 主題 是非常重要的，會被 反復重複 的一個部分。辨識出作品的主題（可能不止一個），并且在樂曲展開、發展、推進的過程中找到主題，對於欣賞古典音樂來説是非常重要的。我個人認爲能夠準確地辨識主題，就能從樂曲形式上理解 50% 之多。

• 曲式（非必要）：雖然用了一個比較專業的詞，但其實就是樂曲内的結構。這首曲子是 ABA 的三部曲式？還是 ABACAD… 的回旋曲式？還是A A' A'' A'''… 的變奏曲式？又或者是更加複雜的奏鳴曲式？還是與這些傳統曲式無關的特別的結構？這些信息可以在聆聽之前查好， 也可以在有了一定知識積纍之後在欣賞的過程中辨識。如果能抓住主題，哪怕辨別不了曲式，也不會有太多損失；但如果能辨別出曲式，那對於樂曲的理解肯定是更深刻的。

這篇文章到這裏就結束了，這也是我自己在欣賞古典音樂的時候的一些心得體會。希望看到這裏的你能從這篇文章中得到一些幫助，也希望你在閱讀完之後能夠更好地欣賞古典音樂，體會到古典音樂的美麗之處。

《使用 WriteFreely 搭建聯邦宇宙博客站點》

WriteFreely 是一個能通過 ActivityPub 協議接入聯邦宇宙的博客實例框架，使用 Go 進行實現（沒想到啊沒想到）。實話説搭建起來基本上沒有難度，最簡單的實現就是裝個 MySQL 然後直接作爲服務啓動，完事。但是由於太久沒折騰服務器了，再加上又想挂反代又想搞 Docker，結果折騰了將近一天（中間睡了一覺）才把這玩意建立起來。

WriteFreely 自身是不支持上傳圖片的，想要在 blog 中插入圖片就需要一個外部的圖床。一不做二不休，乾脆也在服務器上部署了 Piwigo 來進行支持。

簡述

Nginx + WriteFreely + Piwigo + MySQL，支持 http 和 https，最終域名為 blog.penguinsoup.me。

MySQL in Docker

首先要先把服務器設置起來。考慮到其他的應用也可能用這個 MySQL，因此最後沒有選擇將其合并到 Docker Compose 中，而是作爲一個單獨的容器，通過 3306 端口暴露自身的服務。另外，還考慮使用 Docker Secrets 來傳遞用戶密碼。

--- working_directory
 |--- docker-compose.yaml
 |--- config
 | |--- my.cnf
 |--- secrets
 | |--- mysql-root

由於 MySQL 某個（某個）版本加入的改變驗證方式的默認設置（*企鵝粗口*），因此需要修改一下默認設置來使通過密碼登入賬戶成爲可能：

# config/my.cnf
[mysqld]
mysql_native_password=ON
default-time-zone='+00:00' # writefreely required

再就是在 secrets/mysql-root 中放入管理員賬戶的密碼，並準備好 docker-compose.yaml：

version: "3"

services:
  mysql:
    image: mysql:8.4.2
    container_name: mysql
    ports:
      - 3306:3306
    networks:
      - mysql-bridge
    volumes:
      - /path/to/working_directory/config:/etc/mysql/conf.d/
      - /path/to/working_directory/logs:/var/log/mysql
      - /path/to/working_directory/secrets:/run/secrets
    environment:
      - MYSQL_ROOT_PASSWORD_FILE=/run/secrets/mysql-root
    restart: unless-stopped

networks:
  mysql-bridge:
    external: true

配置 Docker Network 並啓動：

$ docker network create --driver bridge mysql-bridge
$ docker compose up -d

$ docker inspect mysql-bridge
...
  Container {
    "hash code": {
      "Name": "mysql",
      "IPv4Address": "172.xx.xx.xx" # that's mysql host addr in other containers
    }
  }
...

從外部連入（即便 client 就在服務器，的也需要手動指定爲 remote）：

mysql -u root -h localhost -P 3306 --protocol=tcp -p # client on server

最後按照 WriteFreely 和 Piwigo 的指引設置好相關的數據庫，並創建一個給外部連入用的賬戶即可：

CREATE DATABASE writefreely CHARACTER SET latin1 COLLATE latin1_swedish_ci;
CREATE DATABASE pwigo;
CREATE USER '${USER}'@'%' IDENTIFIED WITH mysql_native_password BY 'y0Ur_p^sswD';
GRANT ALL PRIVILEGES ON writefreely.* TO '${User}'@'%';
GRANT ALL PRIVILEGES ON piwigo.* TO '${User}'@'%';
FLUSH PRIVILEGES;

由於其他容器訪問 MySQL 都是通過 Docker

Nginx

接下來要設置好反向代理（如果服務器只提供一個網頁服務就不用，但一般不會有人租個服務器就單單搭一個 blog 吧，嗯？），這樣就可以把通過不同域名映射到同一 IP 的同端口請求轉發到不同的實際應用上進行處理。

--- working_directory
 |--- {blog,img}.penguinsoup.me.conf
 |--- includes
 | |--- {proxy,ssl,gzip}.conf
 |--- ssl
 | |--- yourdomain.{crt,key} # use acme.sh or something to issue
 |--- logs
 | |--- {blog,img}.penguinsoup.me
 |   |--- {access,error}.log # created by nginx

配置文件如下：

# proxy.conf
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_http_version 1.1;ssl_session_timeout 1d;

# ssl.conf
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

# gzip.conf
gzip on;
gzip_types
  application/javascript
  application/x-javascript
  application/json
  application/rss+xml
  application/xml
  image/svg+xml
  image/x-icon
  application/vnd.ms-fontobject
  application/font-sfnt
  text/css
  text/plain;
gzip_min_length 256;
gzip_comp_level 5;
gzip_http_version 1.1;
gzip_vary on;

# blog.penguinsoup.me.conf
server {
    # listening server:port
    listen 80;
    listen [::]:80;
    listen 443 ssl; # optional: https
    listen [::]:443 ssl; # optional: https
    server_name blog.penguinsoup.me;

    # optional: logs
    access_log /path/to/working_directory/logs/access.log;
    error_log /path/to/working_directory/logs/error.log warn;

    # optional: enable compression
    include /path/to/working_directory/includes/gzip.conf;

    # optional: https certificate
    ssl_certificate /path/to/working_directory/ssl/blogpenguinsoup.crt;
    ssl_certificate_key /path/to/working_directory/ssl/blogpenguinsoup.key;
    include /etc/nginx/includes/ssl.conf;

    # webfinger proxy
    location ~ ^/.well-known/(webfinger|nodeinfo|host-meta)/ {
        include /path/to/working_directory/includes/proxy.conf;
        proxy_pass http://localhost:8080; # default port of writefreely
        proxy_redirect off;
    }

    # static files
    location ~ ^/(css|img|js|fonts)/ {
        root /path/to/your/static;
        expires 12M;
    }

    # main proxy
    location / {
        include /path/to/working_directory/includes/proxy.conf;
        proxy_pass http://localhost:8080; # default port of writefreely
        proxy_redirect off;
    }
}

# img.penguinsoup.me
server {
    # listening server:port
    listen 80;
    listen [::]:80;
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name img.penguinsoup.me;

    # logs
    access_log /path/to/working_directory/logs/img.penguinsoup.me/access.log;
    error_log /path/to/working_directory/logs/img.penguinsoup.me/error.log warn;

    # enable compression
    include /path/to/working_directory/includes/gzip.conf;

    # https certificate
    ssl_certificate /path/to/working_directory/ssl/imgpenguinsoup.crt;
    ssl_certificate_key /path/to/working_directory/ssl/imgpenguinsoup.key;
    include /path/to/working_directory/includes/ssl.conf;

    # main proxy
    location / {
        include /path/to/working_directory/includes/proxy.conf;
        proxy_pass http://localhost:7999;
        proxy_redirect off;
    }
}

別忘了生成域名對應的 HTTPS 證書並安裝到 ssl/ 下面，具體的操作方式可以參照 這篇文章。

Nginx 就不扔進容器了，這個還是放在 host 上比較方便一點。通過包管理器或者別的方式安裝之後，在 /etc/nginx/site-enabled 下面創造 blog 和 img 配置文件的軟鏈接，最後記得重新啓動 service。

Piwigo in Docker

直接上 docker-compose.yaml：

version: "3"

services:
  piwigo:
    image: lscr.io/linuxserver/piwigo:14.5.0
    container_name: piwigo
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Asia/Shanghai
    volumes:
      - /path/to/photos:/gallery
    ports:
      - 7999:80
    networks:
      - mysql-bridge
    restart: unless-stopped

networks:
  mysql-bridge:
    external: true

啓動后訪問一下，設置好就可以了。別忘了 MySQL 的地址是上面 inspect mysql-bridge 的時候的地址。

WriteFreely in Docker

最開始的時候我是想把這個丟進 Docker 裏面的，然而因爲預編譯版本扔進容器會缺依賴跑不起來，然後又懶得在容器裏編譯了，最後就直接用預編譯文件跑在 host 上了。後面因爲某個（某個）圖床把整個 Docker 搞崩潰了，想著就弄一下吧，結果在官方倉庫的 docker-compose.yaml 裏面發現了這麽一行

image: writeas/writefreely:latest

好啊！原來你們有鏡像啊！那就老規矩，docker-compose.yaml：

version: "3"

services:
  writefreely:
    image: writeas/writefreely:latest
    container_name: writefreely
    volumes:
      - /path/to/working_directory/config.ini:/go/config.ini
      - /path/to/working_directory/keys:/go/keys
      - /path/to/working_directory/static:/go/static
    ports:
      - 8080:8080
    networks:
      - mysql-bridge
    user: "0:0"
    restart: unless-stopped

networks:
  mysql-bridge:
    external: true

目錄結構：

--- working_directory
 |--- docker-compose.yaml
 |--- config.ini # created by wf
 |--- keys
 | |--- # files created by wf
 |--- static # copy from binary package

接下來要進行設置，然而問題來了：沒有 config.ini 與 keys 就不能啓動，但是不啓動就沒有這些配置文件（）。所以，此時要先直接啓動容器來進行配置：

$ docker container run -it --rm \
> -v mount config.ini \
> -u "0:0" \ # start up as root
> writeas/writefreely:latest --config
# don't forget: database host is the addr found in `inspect mysql-bridge`

$ docker container run -it --rm \
> -v mount keys \
> -u "0:0" \ # start up as root
> writeas/writefreely:latest --gen-keys 

接下來要修改一項 config.ini 中的設置，否則無法在容器中運行：

bind = localhost
     ->
bind = 0.0.0.0

最後 compose up，然後就可以愉快地使用啦！

《使用 acme.sh 簽發 HTTPS 證書》

請選擇進行單人副本時的難度：非常簡單

安裝

$ curl https://get.acme.sh | sh -s email=${YOUR_EMAIL}

這條命令會將 acme.sh 自動安裝到 ~/.acme.sh 下，並創建一個每天檢查證書是否即將過期的 cronjob。

簽發並安裝證書

這裏從 Let's Encrypt 簽發：

$ sudo ./acme.sh --issue -d ${YOUR_DOMAIN} --standalone \
> --keylength ec-256 --server letsencrypt --force # when sudo: --force

接下來將證書安裝到提供服務的目錄下：

$ sudo ./acme.sh --installcert -d ${YOUR_DOMAIN} \
> --fullchain-file /path/to/your/directory/${YOUR_DOMAIN}.crt \ # certificate
> --key-file /path/to/your/directory/${YOUR_DOMAIN}.crt \ # encrypt key
> --reloadcmd "if needed" # reload service after renewed

實際上無論是證書還是密鑰，其文件名都是隨意的（只要提供服務的應用正確引用了就行），這裏僅僅是提供了一個方便管理的實例。

男性凝視，又稱男性視角，其含義是“以男性異性戀的觀點，把女性視爲性對象來表現或再現，滿足異性戀男性觀看者的愉悅”（摘自维基百科）。存在“視角”這一説法的前提是以文藝作品為媒介，而非是具體的人對待具體的人。用大白話來説就是，帶著男性偏見在文藝作品中進行角色的塑造與呈現，以及因此引發的觀衆的感受。

文藝作品中的視角

在文藝作品中有三種視角（摘自维基百科）：

1. 角色的視角
2. 鏡頭的視角
3. 觀衆的視角

其中角色的視角和鏡頭的視角往往存在一致性，尤其是在小説中，鏡頭視角往往就是主角的視角（極端例子：私小説）。而在影視作品中往往會有一個較爲明顯的分離，因此也具有一定的誤導性：鏡頭視角乍一看是一個客觀視角，但實際上其往往不僅會體現導演的凝視，還常常能反映主角的凝視。

而觀衆的視角是最難以分析的。首先是觀衆有著個體意識，難以一概而論；其次，觀衆會受社會文化的影響，雖然帶來了一定的可預見性，但與此同時要在分析中引入社會文化的因素；最後，觀衆必須通過鏡頭視角才能觀看文藝作品，這就導致觀衆有被誤導的可能性。

總結一下，三個視角能夠通過三個方式進行分析：角色視角通過角色塑造，鏡頭視角通過角色呈現，而觀衆視角比較複雜，一方面要考慮社會文化因素，另一方面也要對具體的人群做具體分析。

色情作品中的男性視角

回到色情作品，這裏先以 Porn 為例。在談論男性視角前，首先要談論的是與之相對的女性視角（考慮到主題一般是異性戀男性與女性，排除同性戀或其他情況）。

女性視角在我淺薄的人之中，一般會比較注重氛圍與體驗，與之相對的，男性視角中可能會更注重征服感和主體感。但這兩類感官在呈現上并不是完全對立的，常常是一體兩面的：比如在 Porn 中對女性的反應進行呈現，一方面可以說是注重女性的體驗，另一方面也可以説是男性通過帶給女性性快感來進行征服，或者説是在男性視角中女性被塑造成了一種“會因爲男性而感到性快感，會因爲男性帶來的性快感而被征服”的形象。

那麽怎麽進行區分呢？個人認爲可以從對女性的呈現方式上來區分，也就是引入鏡頭視角進行分析。雖然同樣是女性因男性而感到快感，但無論是從影片的流程、節奏，還是女性的表現方式、鏡頭語言，甚至是環境的差異都能帶來不一樣的感官。具體例子在這裏就略過了，請自行想象。

最後，引入觀衆的視角來進行分析。通常 Porn 會被按照“性別+性取向”的方法進行分類，而能這樣分類的前提是此類影片一般對目標觀衆群體進行了預設，在此基礎上再進行的創作。也就是説，一定程度上通過對不同分類的 Porn 進行分析，就能夠瞭解不同的觀衆群體之間的視角差異。不過，在引入女性觀衆的態度是必須明確一點：社會文化的主流是“客體化女性、主體化男性來進行文藝作品的創作”，因此許多女性的個人視角中是會受這一因素的影響的。

具體到個人，有些女性看男性向 Porn，會因爲其中的女性被征服的畫面而感到興奮，這是否是一種不夠女權主義的體現呢？不一定。首先女性觀看到其他女性產生快感，將其投影到自己身上而感到興奮，這是非常自然的生理現象。其次，由於存在上文所述的根深蒂固的社會文化，女性在長年纍月的接觸中被影響、被規訓，這是非常常見的現象。就算不是色情作品，繪畫呢？文學著作呢？這些都會帶來潛移默化的影響。總之，女性個體會對這些男性視角呈現的内容感到興奮與喜愛，都不能算是不女權的表現。

但如果將考察的範圍放大到整個群體中的時候，情況則會變得相當有趣【此处的考察没有调查报告的支撑，仅仅是本人的臆断】：女性群體對於此類内容的反應中，除了喜愛的情感，還會呈現出相當比例的厭惡。而如果是對男性群體進行考察，得到的結果多半是喜愛和無感。兩相對比可以得到一個結論：放大到群體的角度，就能明顯發現男性視角與女性視角的對立性，尤其是考慮到女性視角中存在被男性視角規訓的情況。那麽如果將這種整體的表現視作一種自然，再放到女性個體身上進行解釋，是否可以認爲女性個體對這種内容感到喜愛，本質上可能只是一種糞中淘金？

另一個案例：色圖

色圖和 Porn 不同，作爲一種靜態的文藝作品，色圖被明顯地分爲了兩大類：一類是有何客體女性進行互動的，這類型主要存在於繪畫作品中，其性質與上文分析的 Porn 基本一致，因此不再贅述；另一類是僅僅呈現了女性客體的，也是後面的段落要著重進行分析的。

此類色圖同樣可以從三個角度去進行考量：角色視角，圖片中的女性是以男性喜愛的方式來塑造的嗎？鏡頭視角，拍攝是以男性喜愛的角度進行的嗎？觀衆視角，我覺得或許可以引入生殖崇拜，準確地說是生殖器崇拜的角度來進行考察。

首先是角色視角，由於此類色圖中基本只有被呈現的客體，因此可以這樣認爲：在這種情況下，隱含的男性角色實際上就是鏡頭，也就是説，這時候鏡頭視角和角色視角是一體的。考察女性客體的塑造，其實我們會發現，許多塑造方式是不分性別地被喜愛的。當然這也可能是文化規訓的結果，但從觀衆的反應來看，一部分作品確實是有著不加性別視角因素的吸引力的，而另一部分則會像 Porn 一樣有著性別上的態度分化。對於前者，目前可以近似地認爲并沒有收到男性凝視的明顯影響，但考慮到文化規訓的影響，這個結論實際上是不准確的，在後文分析觀衆視角的時候會對其進行補充。

如果考察鏡頭視角，會得到一個明顯的區分：女性視角會往往更傾向於對美感的呈現，而男性視角通常會更喜愛隱含客體被征服，或者客體能夠挑起男性征服欲望的鏡頭語言。當然考慮到文化規訓的影響，此處也是做了一定的去除重複，保留差異的處理【再次强調，本文中所有的現象都沒有具體的調查依據，僅憑個人臆斷】。

最後是觀衆視角，對於觀衆來説，可以觀察到一個現象：男性觀衆群體之中普遍存在著生殖器崇拜，也就是對女性的胸部、屁股、私處甚至大腿等往往能與生殖關聯起來的器官有著異樣的偏好。如果將這部分内容作爲男性視角的自然，那麽回到角色視角的部分，繪畫作品中對於這類器官的異樣呈現、出版刊物對於這類作品的偏好，以及色圖創作者（無論性別）創作的此類作品佔全部作品的高比重（反過來説就是，不符合這種視角的作品被創作的情況較少），都可以體現出一種男性視角的影響。

總結

綜合以上，觀看色圖、消費色情文藝作品本身并不能作爲一種男性凝視的體現，而是應當結合具體的情況進行分析：比如對具有不同特點的作品的偏好，對作品中呈現的要素的態度等等。如果僅僅是因爲消費以女性為客體的色情文藝作品就對其加以批判，顯然是有失偏頗的。

簡單總結一下離象近一年都在忙什麽。其實主要是因爲自己搭的梯子一直和餅乾米不太兼容，就沒怎麽來了（喂）。如果各位餅乾米香油有意自己搭梯子的話，餅乾米的服務器應該是在德國。

因爲畢業的時候沒找到工作，但是又不想回家（因爲家裏環境很差，居住環境差、信號差，房間還收不到wifi），家裏又無力或者説是沒有意願支撐我自己出去住，所以就跑出去打了8個月的工（）。

這8個月真的是我超級後悔的8個月，我*企鵝粗口*就不該去，至少不該去這家！是去的一家營業時間從8am到次日1am的，奶茶店。是的，8am~次日1am…月休3天，上班是輪班制，早中晚三班，基本上輪班是晚轉中轉早，再轉晚然後休，休完接著上早班。比如，12pm或者1am下班的晚班，第二天轉中班的時候就是11am上班，而9pm下班的中班，轉早班基本上是7:30am或者8:30am…就連每個月只有3天的休息，也要盡量排成晚班後面休，休完上早班……完全就是把個人的休息時間壓榨乾净的排班，唉，資本家。

（更恐怖的是在這種排班中，第二個月還用了半個月的時間和對象一起肝了一個她的課業項目，我好像貢獻了3k行還是多少）（後面的日子裏再也沒有這樣的精力了）

好不容易5月結束跑路了，爲了準備找工作就在狠狠地寫項目。是用Go寫一個從學習使用Go開始的activitypub sns服務器，目前進度堪憂，但已經寫了10k行左右了…目前預計寫完得到20k+，不過應該有1/3都是測試代碼。現在還有一個idea是想搞一個能在github pages上部署，然後又能和聯邦宇宙聯動的博客框架（這個放在最底下聊）。

總之項目是寫了大概有50多個工作日了（中間摸魚也不少，6月7月寫得最多，前段時間還搞了一個涉及3k行的大重構），雖然基本上思路都有，但目前是打算放棄能在找到工作前完成的想法了。

8月中旬的時候我的房子到期了，我又沒有收入，就搬走了。但是之後就尷尬了：我沒地方住了。輾轉去了深圳找我爸但那邊也沒地方給我住（因爲一些原因，家裏是不願意出錢給我出去住的），又回了一趟這輩子都沒回過的老家住了半個月（誰能想到有鵝就帶了一個背包的東西就能住半個月啊），現在就回到家裏和我媽住一起了，是的就是前面提的那個環境很不好的家……

説回找工作，之前雖然做了簡歷，但是前段時間又去看了下具體的簡歷攻略（我説我爲什麽早不看啊！），感覺就是…完全重寫吧。再加上要狠狠復習一些已經忘得差不多了的專業課知識（説到底就是重學）（謝謝obsidian，你給了我記筆記的動力）+刷題，這段時間也挺忙的……希望能在國慶假期之前把簡歷搞定開始投，10月中旬之前把這些都準備好，之後就繼續寫我的項目吧…

以上。

番外篇：github pages + fediverse blog

目標：

• 支持模板化頁面 + md轉html
• 通過git push來更新内容，github action來將md轉換成html
• 通過github action來將内容通過activitypub分發給followers

目前的問題：

• 模板化怎麽做？目前的主流實現似乎是通過類似vue.js的方法，如何合并到這個項目裏還需要研究一下。
• 如何接受follow request？這是最大的問題，因爲github pages原則上應該是無法接受income request的。

或許可能的實現方式：

1. 通過關聯一個賬戶，每次更新都通過action來自動地發送一條嘟嘟到賬戶上。但這不可避免地會讓賬戶的令牌泄漏到github公開倉庫中。
2. 用一個本地脚本同時執行md轉html、push，以及用一個存放在列入.gitignore文本文件中的令牌來推送。但考慮到令牌可能過期，因此可能無法綁定在個人的主賬戶上。或許需要一個專門的bot賬戶來進行blog推送？