今天啟用 WordPress ActivityPub plugin 試試看效果如何。
正在開發的自家產品對於 ActivityPub 協定支援也很重視(另一個重點則是 RSS feeds/Atom),多一個參考實作可以借鏡學習,是件好事。
今天啟用 WordPress ActivityPub plugin 試試看效果如何。
正在開發的自家產品對於 ActivityPub 協定支援也很重視(另一個重點則是 RSS feeds/Atom),多一個參考實作可以借鏡學習,是件好事。
長期以來,我都在忍耐 MediaWiki 架在 DreamHost shared hosting 上的低效能,因為領教過更誇張的 Drupal,所以耐受度也拉高了,覺得多等個幾秒也還好。
但是最近開始認真將 MediaWiki 當成網路筆記本後,就愈來愈覺得,每次再這樣多等個幾秒,除了浪費時間,剛剛得到的靈感恐怕也就忘了,所以就稍稍研究了一下把效能稍加提升的方法。
在沒有登入 MediaWiki 的情形下,$wgUseFileCache = true;的效益很大,會生出靜態頁面,省掉了「到資料庫撈資料出來,再生成頁面」的昂貴開銷。這個在未登入、單純查看筆記的場景下確實是加速很多。
但是如果在登入的狀態下,由於各人的變數不同(即使這個 Wiki 只有我一個使用者),所以如果要生成靜態頁面,要處理的毛多很多,就有點不實際。不過 MediaWiki 另外有個設定 $wgCacheDirectory 會將比如 L10N 的資源編成快取檔,也省下了不少的 DB 操作。把這個路徑設定弄好,也能在登入的狀態下,換到不少的效能。
除了這兩項設定,$wgMainCacheType = CACHE_ACCEL;也很明顯,如果 CACHE_ACCEL 不適用,CACHE_DB 可以碰碰運氣,看看業者的 MySQL server 效能撐不撐的起來(但是別抱太大希望)。
筆記一下:
列出系統上安裝的過時版本的 Linux kernel:
dpkg -l --no-pager | grep "^rc" | awk '{print $2}'
確認無誤後,一舉移除這些過時版本的 Linux kernel:
dpkg -l --no-pager | grep "^rc" | awk '{print "sudo apt purge -y "$2}' | sh
原先認為投入 Android NDK 是個不錯的轉身方向,但是現在想來,當初實在太過天真。
以為競爭者會比較少,會比較講求實戰經驗與能力,實際上呢?競爭者會比較少,因為需要用到 Android NDK 的單位也沒多少;而在寥寥可數的職缺當中,要求 CS 本科系學位的,卻也並不罕見。
但是這幾個月並沒有徒勞,學會 Kotlin 語言、更新了比較 modern 的 Android 開發思維、把多年前的心願實現、證明自己確實有能力從內部程式到 UI/UX 顧及到各方面,設計出一個產品,找回自信心,都是紮紮實實的收穫。
真要說完全沒有機會找上門,也是有欠公允的。至少在 SNS 上,就有幾個老朋友,或僅有一面之緣甚至素未謀面的網友,介紹職缺給我,只是如果再顧及到工作地點與時間,這些機會需要長途通勤或是有 core hours,都會再回到我疼痛症狀發作的老問題,以及家庭照護的衝突。
如此一來,找沒有限制 core hours 的遠距工作機會,或是自己創業,就成了不得不為之的方向。做 Web 還是做 Android,做純軟還是軟硬整合,在這個方向之下,就都不是前提。
再簡單交代一下,我覺得「不如歸去」的思路: