近期在重刻部落格時，也面臨挑選一個適合網站的字型，主要針對繁體中文及英文兩種語言。
在選擇時，就有必要先了解一下字型的基本知識，以及怎麼把這些字型加入到網站當中。
在英文字型中，有一些常見的分類，例如：Serif、Sans、Mono。
在印刷品中，常常會用有襯線的字型，所謂 Serif 就是襯線的意思。例如經典的報紙字型 Times New Roman，給人的感覺會比較正式、古典一些，因此適合作為印刷品的字型，或是長文閱讀使用。
之前除了純數學的內容，在計算機科學的領域也時常會需要用到一些數學。例如推導某演算法的時間複雜度，加密原理、或是機器學習中的某些理論證明，都要能列出數學式子來表達。
在撰寫更專業的學術刊物上，通常使用 LaTeX 作為排版和產生數學式子等內容的系統。而想在網頁上渲染 LaTeX 的數學式，則有常見的兩種 Libraries 來做選擇：KaTeX 或是 MathJax。
今天就來聊聊在 Astro 中如何套用數學渲染 Library 吧，主要以 KaTex 來做介紹。
上一講提到文章列表，能夠透過動態路由 .../[page].astro 搭配傳入 getStaticPaths({ paginate }) 中的 paginate() 函式來產生分頁，將所有的文章分成多頁。
但如果我們想製作能分頁的文章標籤（Tag）的列表呢？例如有 blue、red 標籤，每個標籤下會有多篇文章，所以有類似 /tag/blue/1、/tag/red/1、/tag/red/2 這樣的 URLs，該如何使用 Astro 來開發呢？
這便會用到我們今天要聊聊的巢狀分頁。
當文章數量多到一定的程度（幾十篇、上百篇）時，在瀏覽文章列表時通常就要考慮分頁了。
這是因爲就如部落格這類內容導向的網站，人們決定是否要閱讀全文，除了標題可能不太足夠，因此當加上文章的摘要或前言後，要把數十篇「標題加摘要」的文章塞入一個列表內，會顯得資訊量太大。
除了對讀者的資訊量過大，將所有文章摘要塞入一個頁面，一次要下載的內容量也會過大，進而導致載入速度慢，甚至無法載入成功。因此，今天就來聊聊文章列表的排序及分頁功能！
前一篇文章我們討論了如何透過 Astro 的 Layouts 並使用 Markdown 來建立文章，而這些文章如果是放在 src/pages/ 下，則能夠自動被 Astro 產生對應的 URL，進而能在瀏覽器中讀起。
但是要建立部落格，則勢必要有個入口的頁面來羅列這些文章的標題和連結，如果要每次新增一篇文章的時候都修改這個入口頁面，顯然不太方便，偶爾新刪修文章時忘了修改這個頁面，標題連結等資訊就會對不上了。
一個合格的 Static Site Generator 都會包含「取得文章列表」的功能，那就讓我們來看看 Astro 是怎麼做到這件事的。
由於要架設一個部落格，核心是以內容為本，我們需要專注在內容的撰寫之上。如果在寫文章的同時還要重新寫一整段 HTML、調整部分內容的 CSS，就算是把舊的複製貼上，一樣會很沒有效率。
因此，Astro 理所當然的有提供稱作 Astro Components 及 Astro Layouts 的基礎元件，讓我們做完版面的定義後，就可以專心在內容的產出了。
今天便來聊聊如何用 Markdown 來撰寫文章，並套用自定義的 Layout 來渲染文章內容。
由於我目前使用的 Blog 框架 Hexo 已經是個有點歷史的框架了，更新的並不頻繁，並且當我想嘗試客製化一些前端的小功能時，發現 Hexo 其實彈性相當低。
因此在搜索了一陣子之後，找到了 Astro 這個近幾年蠻紅的新框架，也是所謂的 SSG（Static Site Generator），不但可以搭配 React 來開發，還標榜 Fast by default！於是乎我就來開始研究這個框架。
Astro 是一個 Content-driven 的 Framework (Astro - Why Astro)，相較於主流 Frameworks（如 React, Vue）的 SPA 架構需要在第一次瀏覽時載入幾乎整個網站的 HTML + JavaScript；而 Astro 的目標是盡可能提供單純的 HTML，並透過 Islands Architecture 來最小化 Client-Side 執行 JavaScript，因此載入的 Bundle 小、前端執行的程式碼短，便造就載入速度快速。
接下來的內容便來記錄一些安裝的流程。
最近，隨著一些在維護 Python 專案的規模越來越大，正所謂合久必分，為了讓專案主要的功能可以有效率地使用系統資源，我們計劃將這些 Python 專案依據不同的功能拆開。
拆專案的過程中，免不了會有模組間的依賴問題，例如一些 Utility 類的工具、定義的資訊等等。
除了怎麼拆比較乾淨之外，我們也要考慮「定版」的問題，因為當被依賴方（如 Utility）更新的時候，應該由依賴方（如 Project A）主動更新所引用之版號，否則被 Utility 一旦更新就有可能直接讓所有的依賴方 Project A 和 Project B 壞掉。
今天我們就來探討將共用模組拆分出來的主要邏輯！
上一講，淺談個人保險（一）我們從風險四象限聊了為什麼需要保險，是因為透過購買保險，可以將一些可能性小，但是會讓損失較大的風險給「轉嫁」到了保險公司身上。例如發生意外而受傷時，能夠獲取理賠從而讓我們在無法辦法工作時不需擔憂經濟問題。
那麼，我要花多少錢來買保險？以及這先些錢能讓我有多少的保障？回答這些問題之前，我們先從基本概念探討起來，聊聊一份保單的基礎元素。
最近在看到了 LeetCode 1922. Count Good Numbers 的題目後，發現幾乎是一題純數學的題目，需要理解 Modular Exponentiation（模冪運算）這個技巧才能夠順利解題。
想當初在學習非對稱式加密的核心技術 RSA 時，所接觸到的 Euler’s Theorem（歐拉定理）就大量用到模（Mod，取餘數）運算。
這次的題目正巧也需要對於模運算性質有所理解，才能得出有效率的解法。在理解完題意之後，結論是需要透過程式來計算以下算式：
$$
(5^x \cdot 4^y) \bmod (10^9 + 7)
$$
其中題目限制 $x, y \leq 10^{15}$，這也就意味 $5^x \cdot 4^y$ 的數值可能相當大，遠大於絕大部分的程式語言中單一變數能儲存的數字上限。