抬起頭，小公尺電視上寫著"2023年 辛丑年"，那麼下一年呢？辛寅年？查了下，是"壬寅年"，天干地支都挪了一位。
我們知道，天乾共有10個，分別是甲乙丙丁戊己庚辛壬癸；地支對應生肖，共有十二個，分別是子丑寅卯辰巳午未申酉戌亥。那麼天干地支記年法將二者結合，按道理是120年乙個迴圈，但是實際上，乙個迴圈只有60年，也就是經常聽到60年乙個甲子。
所有的年號如下圖，
那麼問題來了，對於\(m*n\)的格仔，從左上角開始，往右下方掃，假設第\(i\)年的行號row和列號column滿足：\(row = i\%m\)， \(column = i \% n\)。那麼整個\(m*n\)格仔可能被填滿，比如\(6*7\)的格仔；也有可能填不滿，比如\(12*10\)，只填了一半；也有可能只填乙個對角線，如\(10*10\)；
那麼填的情況和\(m\)、\(n\)之間存在規律嗎？
經過多次畫圖，得到乙個初步的結論：填多少取決於\(m\)、\(n\)的最大公約數，如果\(m\)、\(n\)的最大公約數是\(r\)，那麼任何一行，都是每\(r\)個格仔會有乙個被掃到，任意一列也是這樣。這個結論和上面的\(10*12\)、\(6*7\)、\(10*10\)的三種情況也都不違背。
然而這個想法並不是最優的，想太複雜了，直接取最小公倍數除以二者的乘積就行了，12和10的最小公倍數為60，所以經過60年會出現乙個迴圈。
有時候乙個人的想法會因為自身的經歷、所學而陷入乙個死胡同，這個時候多看看別人的想法，通過交流可以得到進一步的提高，所以閉門造車不可取。
由框架中乙個BUG引起的
今天加班在給new guys做培訓的時候，發生了乙個莫名其妙的問題，幾經周折，才發現是公司現有框架的乙個bug。xml converter valueobject objectid lib class com.icsc.tm.mscdao.tmjcs03vo type unique converte...
乙個由有符號下標引起的bug
先看段 if s d i 這裡的d是乙個char 的記憶體buffer，s是乙個256長度的bool陣列。上段 邏輯是，s已進行過初始化，其作用是過濾位元組，有些位元組對應true，有些位元組對應false。明顯，d i 有256種可能。上面的邏輯正確麼？上面的 其實就是我專案裡的一段 看似沒有問題...
乙個糾結的2023年
今年裡，自己基本上沒寫過部落格，相信新一年裡不會這個樣子了。只不過這第一篇就是要說那2014年的總結，這些都是我在2013年就確定下來的並在2012年就計畫好的。按照往年的慣例，自己還是從工作 生活 學習三個方面來總結一下自己。也希望對遇到和我有同樣情況的剛踏入職場的人有些幫助。今年的轉變比較大，應...