如果開發者有寫作的習慣,建議擁有專屬的技術網站。首先,我們要做的是:買個專屬網址,然後,使用Markdown寫作,透過靜態網站產生器來生成內容。
我的網站黑歷史
就今日來說,開發者可以找到許多關於開發者寫文件的好處。在撰寫這篇專欄的時間點,iThome鐵人賽也已經進入第13屆完賽的階段,這是個很有意義的活動,誕生出許多高品質文章,還催生出不少技術書籍,為臺灣的中文技術書籍注入一股活水。
由於擔任鐵人賽評審的關係,這陣子我剛從審閱文件地獄爬出來,每次估量參賽者文件時,我始終都回想最初是怎麼開始寫文件?差不多是2003年吧!那時,只是在個人電腦上架個基於PHP的BBS系統,透過包月制的ADSL,用免費網域銜接動態IP位址的服務,就這樣架設起我的技術網站了。
很快地,有人覺得我寫的文件還不錯,然而,網站速度很慢,畢竟ADSL上下傳輸速率不對稱,別人的下載速度是受限於我的ADSL上傳,於是,我找了一家虛擬主機商,使用附贈的免費網址,架設基於PHP的Wiki系統,將文件重新整理為Wiki的形式。
由於虛擬主機共享運算資源,當時使用的Wiki系統有時佔用過多運算,不久之後,被虛擬主機商警告耗用太多資源,後來心裡想:基本上,我不需要動態頁面(JavaScript那時還是未翻身的鹹魚),乾脆全改成純HTML檔案,用所視即所得的HTML編輯器來寫文件。
不久之後,臺灣網路日益普及,部落格文化興起,我的網站流量也突破了單日萬人訪客數,沒想到突然遇上主機商停用免費網址的狀況。是的,我竟然都沒想過要買個專屬網址,雖然主機商給了我三個月緩衝時間,不過,更換網址畢竟太傷,免費網站停用之後,單日訪客數一下子腰斬。
無論如何,後來網站繼續存活,然而,以HTML來儲存文件,讓內容維護越來越麻煩,那陣子正好Markdown興起,評估後決定用Markdown來寫文件,自己寫了程式,可設置樣版,將Markdown依樣版轉為HTML頁面,而樣版套用了Pure.CSS方案的Responsive Side Menu,並整合了Google的code-prettify為程式碼著色等,於是,這些成為目前我網站頁面的生成方式。
至於舊有的HTML檔案,我寫了另一個轉換器,試著抽取出必要內容來套用新樣版,不過,所視即所得HTML編輯器生成的HTML滿混亂的,因此,轉換後的文件在後續還是花了不少時間手動修正。
考慮專屬文件網站
每次看鐵人賽的文件時,若參賽者的水準不錯,我會試著找看看他有沒有自己的技術網站。用心的參賽者為了更能表達內容,除了會符合要求而在iThome邦幫忙發表,通常也會附上自己網站的連結,若參賽者水準不錯,卻沒有自己的網站,我都會覺得有點可惜。
若已有寫作習慣,開發者可以考慮擁有專屬的技術網站,如果你正打算這麼做,就我過去近二十年的經驗而言,第一件該做的事不是選擇WordPress、Medium之類的平台服務,而是買個專屬網址。
你可能不會像我這麼笨,一直使用免費的網址直到被停用,不過你可能會換平臺服務,與其後來再去煩惱流量重導的問題,不如一開始就有自己的網址,日後就算更換存放位置,只要能將內容架構重現,重新綁定網址,流量就自動導過去了。
接著是決定寫作的格式,無論如何,請不要用所視即所得的HTML編輯器來寫文件,這會造成日後維護或轉移文件格式的麻煩,就開發者而言,使用Markdown格式是目前最佳的選擇,如果還沒有任何的偏好,請使用標準Markdown,因為可支援的內容管理系統、plugin、編輯器或程式庫等最多,甚至還有機會轉換為PDF、ePub等電子書格式。
選用Markdown的另一個好處是,事先不用太多考慮外觀問題,寫作的環境是越單純越好,因為想表達的主體是內容,至於外觀,存在許多樣版或轉換器之類的方案,視你選擇的方案而定,甚至還有成套的佈景主題可以使用。
至於文件要放在哪,取決於你還需要的額外功能,像是想使用哪個內容管理系統、資料庫等,以及預算的問題;然而,如果可以的話,找個能放HTML等相關靜態資源的地方就可以了,靜態資源的話,基本上,也不太需要煩惱下載流量,現在的虛擬主機或雲端方案在流量限制上都很寬鬆,真的不想花錢的話,放在GitHub也可以。
考慮靜態網站產生器
因為內容才是最重要的,網站只是個便於瀏覽的地方,放在上頭的資源越單純越好,就我個人經驗而言,就算是當年用所視即所得HTML編輯器寫文件之後,就幾乎沒煩惱過任何後端維護的問題。
當年自己寫Markdown轉HTML,只是為了迴避虛擬主機運算資源共享的問題,後來在技術圈裡,有人開始推廣靜態網站產生器,我第一次看到時,心想這不就是我現在網站的運作模式嗎?
現今靜態網站產生器的選擇非常多,各主流語言都有相關的方案,而且,多半都有許多佈景主題可以選擇,如果單純想撰寫文件,可依據自己組織文件的架構、風格,先看看有無適合的佈景主題——這會比選哪個語言來實作重要,在最簡單的情況下,安裝好產生器與佈景主題、建個專案,之後就可以寫文件、生成、發布網站了。
當然,身為開發者總是會想修修改改,這時可選擇自己熟悉語言的實作方案,看相關佈景主題的活躍度,例如,近來想重新整理網站的文件與風格,因為對Go語言算有一定程度的熟悉,就選擇Hugo,並結合、修改了Relearn佈景主題,弄了與目前網站相近風格的新版面。
修改佈景主題,甚至是修改產生器本身?這樣不是在寫作以外的事情分心?不會的!調整完成後,幾乎不用理它們,當年我寫了Markdown轉HTML,也只是單純使用,幾乎不需去調整它。
當年之所以必須自行寫Markdown轉HTML,主要是因為尚未興起靜態網站產生器,所以,不得不自行整合Markdown、Pure.CSS、code-prettify等,那時的程式是用Java寫出來的,如果你有興趣了解,可參考Markdown2Template這個repo。
今日各種靜態網站產生器,基本上,都已經將相關需求整合在一起,但身為開發者,自己寫靜態網站產生器依舊是選項,而且出發點並不困難。如果有興趣,你可以參考〈Writing a small static site generator〉,作者示範如何用Python來寫靜態網站產生器,其中也談了些Frontmatter等現代靜態網站產生器會用到的概念。
內容的掌控權
擁有自己的技術網站,才能擁有對內容的掌控權,也就是不會因為平臺服務等因素,導致內容的消失,或者是轉移平臺服務時發生困難;而對內容有掌控權,也包含了內容不被寫作時採用的技術所綁架,所以,這也是我推薦Markdown的原因──就目前而言,它在各種技術間轉移最為方便,就算只是開啟Markdown檔案本身,也依然能夠閱讀內容。
對內容有掌控權還包含了開發者自身,不用分神去處理網站等維護問題。總而言之,雖然是架設技術網站,然而技術上越簡單、越單純,在寫作時越能讓你集中心力的方案,就是最好的選擇。
專欄作者
熱門新聞
2024-12-03
2024-11-29
2024-12-02
2024-11-20
2024-12-02