<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:webfeeds="http://webfeeds.org/rss/1.0"><channel><title>javascript on 林協霆醫師</title><link>/tags/javascript/</link><description>林協霆醫師 (javascript)</description><generator>Hugo -- gohugo.io</generator><language>zh-tw</language><image><url>https://htl.physician.tw/favicon-32x32.png</url><title>林協霆醫師</title><link>https://htl.physician.tw/</link><width>32</width><height>32</height></image><webfeeds:icon>https://htl.physician.tw/favicon-32x32.png</webfeeds:icon><webfeeds:logo>https://htl.physician.tw/android-chrome-512x512.png</webfeeds:logo><webfeeds:accentColor>5bbad5</webfeeds:accentColor><lastBuildDate>Mon, 04 May 2026 00:00:00 +0000</lastBuildDate><atom:link href="/tags/javascript/index.xml" rel="self" type="application/rss+xml"/><item><title>vghtpe-uro：北榮泌尿部以 Google Sheets 與 clasp 實作的線上排班系統</title><link>/blog/vghtpe-uro-2026-05-04/</link><pubDate>Mon, 04 May 2026 00:00:00 +0000</pubDate><guid>/blog/vghtpe-uro-2026-05-04/</guid><description>&lt;h2 id="introduction引言" >
&lt;div>
&lt;a href="#introduction%e5%bc%95%e8%a8%80">
#
&lt;/a>
Introduction（引言）
&lt;/div>
&lt;/h2>
&lt;p>醫院排班是高頻、多人協作且容錯空間極小的行政工作。多數科部至今仍以 Excel 加群組訊息的方式操作，導致版本混亂與責任歸屬不清。對於外科系科部如泌尿部而言，每日多種班別（值班、門診、刀房、會診）交錯，使紙本與 Excel 難以維持。本專案將北榮泌尿部排班遷移至 Google Sheets 並以 Apps Script 進行可程式化擴充，實現真正的多人即時協作。&lt;/p>
&lt;h2 id="methods方法" >
&lt;div>
&lt;a href="#methods%e6%96%b9%e6%b3%95">
#
&lt;/a>
Methods（方法）
&lt;/div>
&lt;/h2>
&lt;p>系統以 Google Sheets 作為主要使用介面與資料儲存層，利用其原生的多人即時編輯、變更歷史與權限管理功能。Apps Script 處理規則檢查、自動填表、產出班表 PDF 與通知等延伸功能；所有程式碼透過 clasp 同步至 Git 倉庫，享有版本控制、Pull Request 審核與測試環境隔離等現代軟體開發實務。&lt;/p>
&lt;p>設計著重於：與既有臨床流程相容（讓使用者在熟悉的試算表介面操作）、規則可被非工程同仁理解（以 Sheets 內表格定義）、以及能在突發情況下快速調整。整體不需要額外伺服器，運維幾乎為零。&lt;/p>
&lt;h2 id="results結果" >
&lt;div>
&lt;a href="#results%e7%b5%90%e6%9e%9c">
#
&lt;/a>
Results（結果）
&lt;/div>
&lt;/h2>
&lt;p>專案已能取代部分既有以 Excel 為主的排班流程，提供協作即時性與歷史可追溯性。clasp 版本控制讓每次規則變更都有可審計紀錄，避免「神秘自動化」現象。對於小型臨床單位而言，本架構展示了在不引入大型醫院資訊系統的前提下，仍能達成現代化協作。&lt;/p>
&lt;h2 id="discussion討論" >
&lt;div>
&lt;a href="#discussion%e8%a8%8e%e8%ab%96">
#
&lt;/a>
Discussion（討論）
&lt;/div>
&lt;/h2>
&lt;p>本專案實踐了「臨床近端 IT 工具」的可能性：以最低成本但符合臨床工作流的方式，迅速解決排班痛點。限制方面，Google Sheets 在大量行列下效能會下降；Apps Script 配額對重度使用者亦可能成為瓶頸。未來可擴充為跨科部排班協作模板，並引入 LLM 進行自然語言調班請求的解析。&lt;/p>
&lt;h2 id="連結" >
&lt;div>
&lt;a href="#%e9%80%a3%e7%b5%90">
#
&lt;/a>
連結
&lt;/div>
&lt;/h2>
&lt;ul>
&lt;li>GitHub：&lt;a href="https://github.com/htlin222/vghtpe-uro">htlin222/vghtpe-uro&lt;/a>&lt;/li>
&lt;li>主要語言：JavaScript（Apps Script）&lt;/li>
&lt;li>最後更新：2026-05-04&lt;/li>
&lt;/ul></description></item><item><title>pdf-presenter：在瀏覽器中提供完整簡報模式的輕量 PDF CLI 工具</title><link>/blog/pdf-presenter-2026-04-18/</link><pubDate>Sat, 18 Apr 2026 00:00:00 +0000</pubDate><guid>/blog/pdf-presenter-2026-04-18/</guid><description>&lt;h2 id="introduction引言" >
&lt;div>
&lt;a href="#introduction%e5%bc%95%e8%a8%80">
#
&lt;/a>
Introduction（引言）
&lt;/div>
&lt;/h2>
&lt;p>學術演講與醫學會議仍以 PDF 投影片為主要交付格式，但 PDF 缺乏專業簡報模式：演講者無法同時看到備註、下一張投影片與計時器。商業簡報工具（如 PowerPoint、Keynote）雖支援此功能，但要求原檔同步而難以分享給他人；網路工具則常需上傳檔案至雲端。本專案以「在本地瀏覽器中還原專業簡報模式」為目標，提供開源輕量替代方案。&lt;/p>
&lt;h2 id="methods方法" >
&lt;div>
&lt;a href="#methods%e6%96%b9%e6%b3%95">
#
&lt;/a>
Methods（方法）
&lt;/div>
&lt;/h2>
&lt;p>工具以 JavaScript 撰寫並打包為 CLI：使用者於命令列指定 PDF 路徑，工具即啟動本地伺服器並在瀏覽器中載入投影片。介面提供四個核心功能模組：講者備註區（從 PDF metadata 讀取或外部檔案掛入）、下一張投影片預覽、可暫停／續啟的計時器、以及錄音整合並產出時序對齊資料。所有元件以可調整大小的窗格呈現，使用者可依場域偏好排版。&lt;/p>
&lt;p>設計重點在於「不離本機」：所有檔案處理皆在本地完成，避免醫療簡報意外上傳雲端。錄音整合為一大特色：演講後可獲得錄音與每張投影片切換時間點的對齊資料，便於後製與重複利用。&lt;/p>
&lt;h2 id="results結果" >
&lt;div>
&lt;a href="#results%e7%b5%90%e6%9e%9c">
#
&lt;/a>
Results（結果）
&lt;/div>
&lt;/h2>
&lt;p>工具可被快速部署於任何具備 Node.js 環境的電腦，無需安裝額外簡報軟體即可獲得專業簡報體驗。對於學術演講者，錄音與時序對齊功能特別有價值：演講結束後可直接產出可被切片重用的素材，作為日後線上課程或文章發表的基礎。&lt;/p>
&lt;h2 id="discussion討論" >
&lt;div>
&lt;a href="#discussion%e8%a8%8e%e8%ab%96">
#
&lt;/a>
Discussion（討論）
&lt;/div>
&lt;/h2>
&lt;p>本專案展示了「以最小工程改善高頻場景」的思維：簡報是學術人最頻繁的活動之一，任何改善皆能放大時間收益。限制方面，瀏覽器投影片的視覺一致性仍受 PDF 渲染品質影響；備註的擷取需要使用者預先以工具支援的方式準備。未來可加入即時 Q&amp;amp;A 投影、串接 LLM 自動產生簡報摘要，並支援 Markdown 為原始格式。&lt;/p>
&lt;h2 id="連結" >
&lt;div>
&lt;a href="#%e9%80%a3%e7%b5%90">
#
&lt;/a>
連結
&lt;/div>
&lt;/h2>
&lt;ul>
&lt;li>GitHub：&lt;a href="https://github.com/htlin222/pdf-presenter">htlin222/pdf-presenter&lt;/a>&lt;/li>
&lt;li>主要語言：JavaScript&lt;/li>
&lt;li>最後更新：2026-04-18&lt;/li>
&lt;/ul></description></item><item><title>image-step-by-step：可編輯場景與 metadata 匯出的本地圖片步驟標示工具</title><link>/blog/image-step-by-step-2026-04-08/</link><pubDate>Wed, 08 Apr 2026 00:00:00 +0000</pubDate><guid>/blog/image-step-by-step-2026-04-08/</guid><description>&lt;h2 id="introduction引言" >
&lt;div>
&lt;a href="#introduction%e5%bc%95%e8%a8%80">
#
&lt;/a>
Introduction（引言）
&lt;/div>
&lt;/h2>
&lt;p>醫學教學常需要在同一張圖（如 X 光、心電圖、組織切片）上呈現多個重點區域，並依步驟揭露給學員。傳統 PowerPoint 的動畫雖可達成此目的，但維護成本高且不利版本控制。線上工具又常涉及上傳敏感影像。本專案提供一個本地網頁 GUI 工具，將「逐步揭露重點」的場景以結構化方式儲存，便於重複使用與分享。&lt;/p>
&lt;h2 id="methods方法" >
&lt;div>
&lt;a href="#methods%e6%96%b9%e6%b3%95">
#
&lt;/a>
Methods（方法）
&lt;/div>
&lt;/h2>
&lt;p>實作以 JavaScript 為主，以本地伺服器運行，使用者可載入圖片並以介面標註多個「場景（scene）」，每個場景對應一個重點區域與對應說明。所有場景以 JSON 格式儲存於本機，可被版本控制管理。匯出時可選擇靜態圖序、互動式 HTML 或包含 metadata 的封包，便於整合至既有簡報或教學平台。&lt;/p>
&lt;p>設計重點為「資料即內容」：場景定義與圖片內容分離，學員看到的逐步揭露其實是同一張圖加上不同遮罩的呈現。如此使內容易於更新（例如修改說明文字不需重做整張圖），亦便於不同教師共用素材。&lt;/p>
&lt;h2 id="results結果" >
&lt;div>
&lt;a href="#results%e7%b5%90%e6%9e%9c">
#
&lt;/a>
Results（結果）
&lt;/div>
&lt;/h2>
&lt;p>工具可被臨床教師在門診教學、晨會討論或考前複習中使用。對於影像判讀類主題（如胸部 X 光、骨髓塗片），逐步標示的形式比一次性框出全部重點更能訓練學員的觀察順序。本地運行的特性也滿足醫療影像不離院的隱私要求。&lt;/p>
&lt;h2 id="discussion討論" >
&lt;div>
&lt;a href="#discussion%e8%a8%8e%e8%ab%96">
#
&lt;/a>
Discussion（討論）
&lt;/div>
&lt;/h2>
&lt;p>本專案展示了「以最少工程改善高頻教學情境」的價值。其貢獻在於提供一個輕量、可重複使用、可版本控制的圖片步驟標示工具。限制方面，當前僅支援靜態圖片，影片與 3D 影像尚未涵蓋；介面設計仍以工程友善為主，對非技術使用者門檻偏高。未來可加入 LLM 自動產生標註說明，並支援多人協作與評論。&lt;/p>
&lt;h2 id="連結" >
&lt;div>
&lt;a href="#%e9%80%a3%e7%b5%90">
#
&lt;/a>
連結
&lt;/div>
&lt;/h2>
&lt;ul>
&lt;li>GitHub：&lt;a href="https://github.com/htlin222/image-step-by-step">htlin222/image-step-by-step&lt;/a>&lt;/li>
&lt;li>主要語言：JavaScript&lt;/li>
&lt;li>最後更新：2026-04-08&lt;/li>
&lt;/ul></description></item><item><title>casey-schedule：個人排程管理的 JavaScript 私有實驗專案</title><link>/blog/casey-schedule-2026-02-23/</link><pubDate>Mon, 23 Feb 2026 00:00:00 +0000</pubDate><guid>/blog/casey-schedule-2026-02-23/</guid><description>&lt;h2 id="introduction引言" >
&lt;div>
&lt;a href="#introduction%e5%bc%95%e8%a8%80">
#
&lt;/a>
Introduction（引言）
&lt;/div>
&lt;/h2>
&lt;p>時間管理工具市場上選項眾多（Google Calendar、Notion Calendar、Fantastical 等），但每位使用者的工作節奏與優先序皆有微妙差異。對於同時兼顧臨床、研究、教學與個人生活的醫師，現成工具常需多種變通用法才能契合現實，導致工作流複雜化。本專案是作者個人嘗試以最少程式碼建立屬於自己的排程管理工具，作為理解「我究竟需要什麼」的實驗素材。&lt;/p>
&lt;h2 id="methods方法" >
&lt;div>
&lt;a href="#methods%e6%96%b9%e6%b3%95">
#
&lt;/a>
Methods（方法）
&lt;/div>
&lt;/h2>
&lt;p>實作以 JavaScript 為主，採取迭代式開發：先建立最簡單的事件儲存與顯示，再依實際使用感受逐步增加功能（重複事件、優先序、與既有日曆同步、提醒）。每次新增功能皆要求自己回答「為何商用工具不夠用」，避免重複造輪。&lt;/p>
&lt;p>設計重點為「先有用再美觀」：UI 簡陋但邏輯緊密，使用一段時間後再依痛點優化視覺。所有資料留存於本地，避免綁定特定雲服務；可選地以 ICS 或其他開放格式與既有日曆軟體交換。&lt;/p>
&lt;h2 id="results結果" >
&lt;div>
&lt;a href="#results%e7%b5%90%e6%9e%9c">
#
&lt;/a>
Results（結果）
&lt;/div>
&lt;/h2>
&lt;p>雖屬探索專案，但累積過程已澄清作者個人在排程上真正在意的特性：對「待辦」與「事件」的清楚區分、對「能量水準」（能量高低時間）的標註、以及對「重複行為的儀式化」需求。這些觀察可能成為日後選擇正式工具或客製化現有工具的依據。&lt;/p>
&lt;h2 id="discussion討論" >
&lt;div>
&lt;a href="#discussion%e8%a8%8e%e8%ab%96">
#
&lt;/a>
Discussion（討論）
&lt;/div>
&lt;/h2>
&lt;p>本專案展示了「以自製工具理解自身需求」的實踐。其價值不在最終產品，而在過程中累積的需求洞察。限制方面，自製工具難以追上商用產品的功能廣度；維護成本對個人開發者長期構成壓力。未來可選擇將獲得的洞察反饋至既有開源排程工具的擴充模組，而非堅持自管完整應用。&lt;/p>
&lt;h2 id="連結" >
&lt;div>
&lt;a href="#%e9%80%a3%e7%b5%90">
#
&lt;/a>
連結
&lt;/div>
&lt;/h2>
&lt;ul>
&lt;li>GitHub：&lt;a href="https://github.com/htlin222/casey-schedule">htlin222/casey-schedule&lt;/a>&lt;/li>
&lt;li>主要語言：JavaScript&lt;/li>
&lt;li>最後更新：2026-02-23&lt;/li>
&lt;/ul></description></item></channel></rss>