積沙成塔，滴水穿石

d 最近看到了 日本的網站 ，我還滿喜歡他們的設計出場模式。(圖1) 日本網站(圖1) 於是我也來做一個!  由於我沒有要設計比較複雜的svg logo ，就直接用 線上figma 做logo (圖2) figma 製作logo (圖2) figma 有些功能 很像illustrator ，它有個方便個功能是 就是可以直接將鋼筆、文字線條 轉成 vector。在使用figma 的outline 轉成vector的時候，有時鋼筆會跑掉，就需要再做調整。(圖3) 轉成SVG需要調整( 圖3 )  如果有個單字需要調整的特別多，不如就單個字直接重新製作轉vector 會比較快。 設計思維 參考圖1 的動畫設計思維，第一步是先跑出文字的外框做描邊，第二步做內部填色，第三步 動畫，動起來。 第一步-SVG線搞: 在做文字的時候，就不做填色，用stoke設計外框。 figma轉成svg 出來的path 也就是路徑外框，不填色。(圖5) copy svg (圖5) 這時在html上，要確保 看到的 是否和figma 設計的一樣，因為有時候figma 轉成svg 路徑會跑掉。(圖6) 網頁上查看SVG(圖6) 第二步-填色: 這次我想要在H、D、N上做填色，所以就做了HDN的圖層。(圖7) 填色圖層(圖7) 第三步-動畫: 利用了stroke-dasharray 將原本的path 做成虛線，再利用  stroke-dashoffset 遮住虛線，利用兩者 一個顯示 一個隱藏，再搭配逐間動畫 看起來線條會跑起來。(圖8) 讓線條跑起來(圖8) 在設計線在跑的時候，如果stroke-dasharray 切越多，就是虛線越多。 如果看起來要順 可以將 stroke-dasharray 長度調長，大概是文字的長度。 有的時候如果stroke-dasharray 太長，那描邊有跟沒有一樣。(圖9) CSS 動畫設定(圖9) 在這次的設計中，我把文字短的path (A、D、I)，stroke-dasharray 調成300，較長的文字用500，動畫跑約3秒。(圖10) 設定不同的dasharray長度(圖10) 當第一個描邊動畫跑完(3~6秒)，在跑第2個填色動畫，所以第2個的秒數 要delay 4秒(fade-in )。(圖11) 填...

When I met you in the summer  To my heartbeat's sound (音樂-summer) 剛開始接觸到 MERGE INTO，腦中就浮現了一首歌... summer~ met you(merge) 哈哈哈!讀音 超像的~ 前情提要 這次在算一個月的統計使用次數，每天會觸發排程。 設計思維 這次我採用的是inset & update， 如果 今日這筆資料有存在就更新否則新增，以StatisticsDate、更新日期、ID、faulttype 作為主鍵，判斷是否存在過今日計算。 (圖1) 會這麼做是因為避免統計結果，在不小心觸發2次造成當日結果在insert 。 統計表 tblStatistics_Gateways (圖1) 使用方法 在mysql 中 可以用 i nsert update on duplicate key  ，會根據唯一值去更新欄位    UNIQUE  index or  PRIMARY KEY 。 在mssql 中 可以用  Using MERGE  (圖2) mssql 使用merge 更新(圖2) MERGE INTO ： 使用 MERGE 語句將 tblStatistics_Gateways  作為目標表。 WHEN MATCHED THEN ： 如果存在紀錄，則更新 Faults 。 WHEN NOT MATCHED THEN ： 如果沒有紀錄，則執行插入操作。   心得 其實有點像IF..ELSE的變化版，與mysql 的on duplicate 差異是 不需要再多設定unique key，是透過 on  A=B, 蘋果 = 橘子 的方式 去判別組別是否存在。

  前情提要 現在的目的要透過Log 向醫院提出建議與改善。 所以在整理Log的時候，不能再以單純的統計Log數量，而是要去找Log前後的時間差及彼此之間的關係性。(圖1) Log彼此之間的關係性(圖1) 整理過程 這期間勢必會伴隨著資料重新整理在整理，這些資料不光是原本統計而已。(圖2) 原本統計(圖2) 心得 這段期間不斷地重新整理資料、重新清洗，不再是一開始簡單的正規劃資料，反而要在更細的去分析  錯誤原因  那些時間重複log 只能算一筆。 在預處理資料的時候 要很小心，有的時候因為其他原因發生的併發原因，就只能找出 起始的原因，如果用工具統計 就無法找到併發原因了。 工具只是補助，一開始透過工具調查只是初步，下步就需要再透過 初步的調查結果 去找出併發原因 再重新找出 是否有其他的例外。 這2個禮拜 整理了 60份 每份都有10萬筆以上，真的看到頭昏眼花😵😵 最近和朋友聊天，得知她要整理1萬多筆的資料，找出不要重複的資料就行了。 她很苦惱不知該如何下手.... 她:哀~資料好多...有1萬多筆 我：才1萬筆?

 自開始使用LogParse後，在整理log就方便許多了。 在做log紀錄時發現到了一些異常(圖1)。 資料異常(圖1) 有多項錯誤指向「沒有智慧卡讀取器可用」(圖2) 沒有智慧卡讀取器可用(圖2)    去查了一下Log 發現到，H37200070012 這一台 竟然每秒上傳Log (圖3)。      從 2024/12/16  上午8:06 ~  2024/12/16  上午8:10 ，一共上傳了256筆。 每秒上傳Log(圖3) 這樣的狀況不太合理，問前輩後得知「醫院晚上都會關機，早上會在重新開機，不會一直待機」。 那這樣的狀況也只能算是1筆錯誤 。 當每秒都上傳Log時，就需要去注意是否哪裡有異常了、是否包含了哪些情況要去排查 心得 有的LOG 是先發生讀卡機錯誤 緊接著伴隨 上傳錯誤。 有的是 讀取卡片錯誤 導致 讀卡機錯誤。 像是骨牌效應，A錯誤後 伴隨著B、C。(圖4) 如果照以往 單純 用LOG 顯示的警示字 去統計資料會很好統計，但統計出來的資料可能就不準確。 若要真的去找出問題並給予建議 則需要在更細微的去察看到底是哪個環節發生的問題。 骨牌效應的log錯誤(圖4) 這時候就要去看當A發生時 ，是否有受到其他影響。 進而去提出是否該更換 讀卡機、配備....等

這次的專案是做官網切版。 由於時間不多，目前只用2個禮拜做好前台RWD切版，後續還有些細節待條，目前還差後台RWD切版，找時間再切了。 https://www.emmt-system.com/officeweb   目前設計稿也關掉了 開發環境 這次預計使用的開發環境  後台框架是採用laravel (php) 資料庫mssql server 2022 前台框架 React 佈署環境 IIS 

如果是用JS 框架，對於 npm run dev 一定很不陌生。 以svelte 來說，npm run dev  底層是呼叫vite 。 由於在某些情況下，需要關閉HMR(熱模組)做功能上的校條與監控。 這時候 就可以加入 hmr:false ，將熱模組關閉 (圖1) 熱模組HMR關閉(圖1) 這樣子在開發功能上，就可以透過f5 更新來做頁面觀察了。 心得 HMR 熱模組是雙面刃，好處是 不需要時刻更新按f5，有新的功能寫好就會自動更新。 換而言之，在撰寫功能時 時常也會看到404 畫面，因為功能還沒寫好 就自動更新了。 最近因為要觀察背景更新 和writeable 的狀況，就把hmr 關掉 做檢查。 在做檢查時 發現到 打包出來的環境 和 關閉hmr 的開發環境很像。 在檢查 和使用功能時，不仿也關閉hmr 進行測試，會有不少收穫。

 最近找了時間去圖書館，看到了一本書「 易讀程式之美學 」(圖1)。 易讀程式之美學(圖1) 雖然這本書出版很久了，但裡面的內容很值得看。教你怎樣能把程式碼變得更易讀、細微的眉眉角角、為何這樣寫、最好的寫法不代表適合的寫法。 很多時候平時沒注意到或者照舊的寫法，是不是能讓你好閱讀、好理解。 其實做到後期，有很多時候要在code review 或者 重新改架構時，就會需要再花些時間去理解 「前人再寫什麼」 。 「你怎麼蓋房子就會影響之後的使用」 題外話     當我把這本書和師傅分享時，師傅說我在介紹你其它書(4本)，這本書只是擷取其中一部分而已。       師傅：根打穩，不然你永遠都只是在練習 師傅的知識像榕樹一樣，又廣又深.....🙈🙈