從 2007 年 5 月到 2011 年間, 我的文章都貼在 blog.ofset.org 。 (dotclear 架的、 橘色的那個) 可惜網站年久失修, 越來越常陷入昏迷, 最後就掛點了 :-( 還好當初我不是貼在封閉的 FB、 還好有網路時光機 wayback machine 大神, 很幸慶地撿回 我的數位回憶。 用命令列工具整理過內文的連結網址以便指向新位址之後, 封存在 這裡。 如果有讀者想推薦我的舊文, 現在終於又有新網址可用了。 這個映射應該至少可以用到我退休 :-) [10/27] 圖片跟標籤的連結也整理好了。 但有些圖片連 wayback machine 也沒封存, 那就沒辦法了。
批次轉網址的程式在 這裡。 其中用到一個 對照表, 因為 2007 年間的文章, 網址有點太囉嗦, 趁這個機會把它簡化。
順便一提, 因為現在這個 blogspot 最近開始要求部落客們從 http 升級至 https, 所以很多 (舊的, http 網址的) 圖片都掉了。 但是放在 blogspot 的文章無法批次處理 -- 曾經試過 「批次匯出再匯入」, 但這樣的話 所有文章會用新網址重貼一次。 所以只好想到哪一篇才手工整理一篇, 讀者們可能會發現有些篇章的圖是正常的; 有些則不見了。 你想看哪一張圖, 或是發現哪一篇裡面有壞掉的連結, 請直接在那篇文章下面留言, 我就補上去囉。
部落格 (Blog) 是用時間軸作為分類方式的系統, 而 維基 (Wiki) 是沒有特定分類方式的系統, 可以用不同的目錄頁面很有彈性的組織末端頁面 (每個實際 post 內容), 比起 Blog 的組織方式有彈性而且比較像是一般網頁結構的組織方式.
回覆刪除我是沒有特別偏好, 反正各有優缺點, Blog 比較直覺 (照時間排序), Wiki 比較有邏輯和系統 (沒有限制頁面連結組織方式).
我反而比較想知道貴哥打算怎麼備份呢? (現在貴哥把文章寫到 blogspot). 我原本也是在 blog 服務和自己架站之間掙扎. 因為自己架站如果用自己電腦當 server 的話要懂很多安全常識可是我還不懂.
自己架站的好處是: 部分文章換網址時, 直接用 apache2 的 RedirectMatch 就可轉址, 不需要辛苦地寫 php。 安全防護的話, 目前我都靠 http://newtoypia.blogspot.tw/2016/04/fail2ban.html 好像還過得去,設定也很簡單,有現成的規則可直接套用。 比較討厭的兩點: (1) https 還沒處理 (2) 幾十年後等我掛掉以後,租的網站就要收起來了? 所以現在我租的 frdm.info 只放一些服務 (公車動態、 地圖); 其他靜態頁面全部 redirect 到學校去。
刪除以 「分享知識的文章」 來說的話, wiki 或 blog 比較有人看; 靜態網頁更新訊息要讓讀者知道有點麻煩。 最近我玩 ldap 有心得, 且想寫英文文章 (因為 ldap 的教學文連英文版也找不到滿意的文章)。 但我的部落格沒有英文讀者, 所以貼在國際的 wiki 上比較實在。 可是到 ubuntu 的 wiki 看了一下, 覺得好多規則要遵守, 有點懶惰。 所以最後可能還是回來貼一篇中文版在我的玩具烏托邦就好。 我覺得能夠參與團隊合作的人, 如果可以寫到公共的 wiki 去會很棒; 自己寫爽的就用 blog 比較自由。 自於備份, 我覺得不是問題, 因為 (1) google 不太可能倒 (2) 在它倒掉之前, 可以先匯出: https://support.google.com/blogger/answer/41387?hl=zh-Hant (3) wayback machine 會幫我備份 :-)
如果讓我重來一次, 我可能會學用 github 的 jekyll 當成 blog, 並且用 https://github.com/jekyll/jekyll-feed 產生 rss。 這樣的話, 既有 https, 也不怕網站收掉, 而且有必要時, 需要批次修改文章時 (例如一次更動很多 url) 比 blogger 方便多了。 先前我已把所有的圖片檔搬到 github 去, 就是這個考量。 可惜無法顯示 sozi 簡報。
ps. 說明一下近況 (為何好久沒貼文): 我最近玩 docker、 lxc、 raspberry pi 都有一點小小的心得; 但都沒學很多, 而且這幾個議題, 網路上既有的中文好文已經很多, 所以有好一陣子沒什麼有趣的東西好分享。 等適當的時機, 還是會繼續在玩具烏托邦上面貼文。
恩~ 慢慢寫. 技術一直淘汰和生出真的很讓人煩躁. 光爬文就耗掉所有時間了別說要深入學習.
刪除Top Open-Source Static Site Generators :
https://www.staticgen.com/
jekyll 依然還是第一, 可能是因為 github 的關係吧.
不過靜態網站不知道有沒有辦法建立站內搜尋引擎.
版主關注的技術都很實用,要常常考慮升級和相容性的技術才會讓人崩潰。
刪除靜態網頁很適合放教學文件,youtube可以放教學影片。
朝貴老師給三秒緯的謝師宴祝福短片
https://www.youtube.com/watch?v=KQBrHl9AM34
你好我是新來的訪客,隨意看看覺得這裡很棒。
刪除有點好奇架站方面的東西,所以點進來看這篇文章。
會特地留言,只是看到下面這句話。
我印象裡我好像有看過,所以特地留言分享一下。
@treegb >>>> 靜態網站不知道有沒有辦法建立站內搜尋引擎
我本來以為不太可能可以辦到,直到我遇到 amWiki(https://github.com/TevinLi/amWiki)
我只有試裝起來,搜搜看能不能真的搜尋內文而已。
我親自測是他是真的可以搜尋到內文。
但並沒有深入專研他為什麼是純靜態前端網頁而已,卻可以達到搜尋的功能。
詳細他到底怎麼辦到的,可能要等其他技術比較深入的專家分享XD
不曉得跟 HTML5 有沒有關係。
----
atWiki 是一個小型的純 JavaScript 組成的 CMS。
他的作者有說他的靈感是源自於另一個 小型 CMS: MDwiki(http://www.mdwiki.info)(說白一點就是致敬、改良)
----
我會遇到他單純是因為,我喜歡不用資料庫就可以完成架站的小型 CMS。
最早以前是接觸 DokuWiki(https://www.dokuwiki.org/start?id=zh-tw:features)
有次突然起意尋找支援 Markdown 寫法的類 Wiki 系統,
偶然間遇到 MDwiki(http://www.mdwiki.info)這種純前端的小型 CMS。
跟 DokuWiki 不謀而合他也不用資料庫。
但他的系統卻只依賴 JavaScript 等前端網頁技術,就可以完成所有畫面與簡單功能。
令我吃驚了一陣子,因為連 DokuWiki 都至少還是要 PHP 後端語言來當運作系統。
他還結合了一些框架,所以也可以自動可以滿足 RWD 設計,也直接有燈箱可以用。
後來在探索 MDwiki 網路上的文章的時候,不小心發現了 amWiki。
amWiki 的概念跟 MDwiki 一樣,畫面都由 JavaScript 構成。
你可以先讓你的瀏覽器設定禁止使用任何 JavaScript,
再去瀏覽 https://tevinli.github.io/amWiki/index.html 就可以明白他真的是依賴 JavaScript 完成畫面跟所有功能。
我看了 amWiki 的作者的敘述。
他是當初嫌 MDwiki 使用時,必須要自己另外更新頁面連結的 md 文件,系統不會自動更新產生。
覺得很不方便,所以才自己另外寫一個 amWiki。
所以 amWiki 跟 MDwiki 兩個小型 CMS,主要差別是:amWiki 可以搜尋,新增的文件也可以自動產生導航分類連結。
MDwiki 就比較單純,你寫了什麼 *.md 文件他就呈現什麼。
只是你要記得自己去更新導航連結的內文,把新的文章檔案寫進連結。
內文支援解析 Markdown 語法,也支援原本的 HTML,
所以自然也可以塞你想自由改寫的 JavaScript。
我玩這個叫做 MDwiki 的小 CMS 系統不久。(大約 2016/07 才發現他)
本身也只是興趣玩玩技術沒有很好。
他主要檔案很簡單,就是只有一個「index.html」
其他的 *.md 文件你自己再另外想寫什麼再寫。
感覺真的很輕量很隨興XD
如果要改動到他的系統解析或其他想改的,
通常也是進去「index.html」慢慢加入你要的功能就可以。
目前因為之前想有順便測試不同地區的主機跟不同協定的差異,
所以有將同一份測試網站放在三個靜態架站空間。
以下是我現在還在線上的測試網站
分別是
放在 Gitbub 的 https://synr.gitbub.io
放在 中國 Coding 的 https://landerso.coding.me
放在 日本 的 http://landerso.at-ninja.jp
Coding.me 是中國仿 Github 的一個平台。
因為我還不會正規 Git 用法,所以我都只從網頁端操作更新與上傳。
但他也可以支援 Git 命令去 Push。
只是跟 Github 比起來,他最近開始有限制一個案的總檔案容量上限 100 MB。
超過就算你上傳成功,也無法再自動新網頁畫面。
我會超過 100 MB 是因為我也有在測試 中文 Web font 的應用。
有興趣的話可以從我的測試網站裡,點選字體切換直接測試體驗效果。
(但字體切換技術上還有個小問題沒解決就是,下載字體前他會有短暫空白的空窗期沒有文字)
本來就像 MDwiki 官方網站教學所示,之前 Google Drive 跟 Dropbox。
也能被利用來架設這種純靜態的網站。
但後來 Google Drive 在 2016/08/31 關閉了這項功能。
沒多久 Dropbox 也跟進不支援解析 .html 文件直接用網站的方式開啟。
不然原本官方利益是要讓大家能輕輕鬆鬆,透過隨時上傳網路雲端硬碟。
輕鬆更新私人小型網站。這點比較可惜。
對不起,我不小心分享太多。
但因為這一連串都是互相相關的。
如果你有進去我的測試網站,上面的內容也都是很隨意的內文而已。
只有大概簡介一些 MDwiki 基本是怎樣的東西,
但都是我主觀的個人觀感而以僅供參考。
你這堆文字也應該丟到 MDwiki 裡。
刪除資訊分享 - http://unhosted.org - 不知道對貴哥是否有幫助.
回覆刪除我最近在 DuckDuckGo 的 About 那裡看到 unhosted.org 這個網站, 他主要是推廣 "serverless", "client-side", or "static" web apps.
Definition :
Also known as "serverless", "client-side", or "static" web apps, unhosted web apps do not send your user data to their server. Either you connect your own server at runtime, or your data stays within the browser.
在這頁
http://unhosted.org/adventures/1/Personal-servers-and-unhosted-web-apps.html
裡面, 描述了現在網際網路不管是社群網站還是雲端服務 (SAAS) 的資料 "壟斷" 種種問題, 解決方式是把 web apps 的資料擁有的權利從各個公司移動回個體使用者自以身上, 使用者可以自己選擇信任的儲存空間 (自己架儲存空間? 或存放在信任的儲存服務), 資料不再被其他人控制.
關於應用的工具 (Tools) 可以見
http://unhosted.org/tools/
unhosted.org 是 DuckDuckGo 在 2012 年 donate 的項目之一.
DuckDuckGo 好像在每年都會贊助一些項目, 包括 Tor, Tails, Diaspora, unhosted.org, Freenet, F-Droid, Riseup, I2P, GPGTools ...
對於 unhosted.org 我個人還沒有時間去了解它. 之後我才有時間慢慢研究. 好幾度想要轉換到靜態網頁去但太多因素我遲遲沒有前進, 包括動態互動的潛力問題. 我要看看 unhosted.org 的 web apps 是怎麼樣的一個作法.
哦 這個我有介紹過: https://ckhung0.blogspot.tw/2011/09/homomorphic-encryption-and-unhosted.html 我覺得觀念很讚; 可惜有些 apps 壞掉, 有些不知怎麼用, 有些不是英文~~ 目前要先把上課和管 server 的技術學一學 (aufs 等等) 之後暑假想繼續玩 machine learning, 所以暫時先不會玩這個吧。 還是謝謝囉!
回覆刪除http -> https 簡直是數位印鈔機!
回覆刪除作業系統不支援舊版憑證 , 軟體公司快樂了...
購買https憑證等於另類的網路實名登記制, 官方好滿意...
https需要使用更多運算資源, 舊電腦淘汰, 相關產業利多...
https告訴大家沒$$別想架設私有雲, 沒網路曝光權....
https http/2 html5 , 有規格制定權最棒, 說了大家得跟著走