Wednesday, April 25, 2018

上週五到昨天在練習QGIS,
然後主管提到地段率, 嗯....

大概兩種作法:
1. 用地段率資料->所有地址或宗地->依地籍圖找座標
2. 用地段率資料->道路座標->分段畫出來

不過地籍圖資料跟道路資料就要找地政單位或養工單位了....


雖然想到要硬幹....

從業務端的地址資料庫, 撈出該路段分奇偶數的第一個跟最後一個
例如:
柏油路1號, 柏油路99號
柏油路2號, 柏油路100號

然後丟給Google地圖轉成座標, 再把座標拉回QGIS當基準點, 手動畫直線.
不過Google地圖回傳的座標系可能不同, 或使用建物中心點的座標,
把座標拉到QGIS後實在對不起來....先想想其他辦法.

Monday, March 26, 2018

行動支付繳稅推廣

本網頁僅為個人整理, 引用的資料可能異動而不符現況, 也不代表任何官方說法
行動支付是指使用行動裝置進行付款的服務;為便利民眾,政府也增加使用行動支付的方式繳稅,大約可分為遠端與近端兩種,特點如下:
遠端 近端
名稱 等(不含LINE Pay)
繳稅方式 網路繳稅 臨櫃繳稅
台南市財稅局全功能服務櫃檯:
嘉義區監理所稅務櫃檯:
支付工具
注意: 需搭配支援的手機與信用卡, 信用卡也要支援公務機關信用卡繳費平台才能用
例如: 渣打目前不支援
申請流程
繳稅方式 手機完成綁定信用卡之後, 持手機及稅單到財稅局及監理站據點, 由服務人員引導使用NFC感應扣款.
優惠 台灣Pay金融卡繳牌照稅抽MacBook Pro

可繳納稅目: 牌照稅(4月, 營業用10月再一期), 房屋稅(5月), 所得稅(5月), 地價稅(11月)

常見問題:
  • 台灣Pay: 需要以手機號碼註冊, 收到"簡訊認證碼"之後, 再設定"使用者自己設定的台灣Pay密碼", 要新增金融卡時, 要填寫銀行詢問的問題, 再收到"雲支付金融卡(虛擬金融卡)認證碼", 再設定"使用者這張雲支付(虛擬)金融卡密碼".

其他: 亦可申請約定轉帳納稅等方式.
如果您因為本網頁說明而申辦成功, 敬請回饋申請資料, 以便列入個人推廣業績.

Saturday, March 17, 2018

撈資料與呈現的心得

這次的案例主要是, 人員有分總局跟分局,
分局要看分局所轄駐點全部的資料, 確定都有填報, 所以不管有沒有資料都要顯示.
總局要看全部分局所轄駐點, 但只要顯示有填報的資料.

在資料撈取的結構上, 切成 分局代號 , 駐點代號 , 項目 , 期別 ; 撈取的功能分成 明細 , 單項加總 ; 另外有一項功能是查詢最後修改的紀錄, 也用來判斷如果沒有修改記錄, 就不用再查明細跟加總.

資料結構上, 一個分局有多個駐點, 所以先依登入帳號屬於總局或分局, 撈取的駐點清單就加上條件(若是分局人員, 只撈取分局所轄駐點), 這樣雖然清單都是"駐點", 明細數量卻不同, 而主要程式結構就不變.

撈取駐點後, 依期別撈取所有已填寫的資料, 產生一個"實際填寫的項目(A)"陣列.
再來則是從項目清單與駐點清單, 產生一個"應該要有的項目(B)"陣列.

最後要轉成網頁畫面時, 再依登入人員決定要顯示的項目:
如果是分局, 就把整個"應該要有的項目"都呈現出來, 如果項目已經有填寫, 再顯示填寫的項目. (概念是B left join A)
而總局只需要已經填寫的項目, 所以是以實際填寫的項目, 把顯示的名稱撈出來. (概念是 A join B)

這樣整個程式大架構不變, 只有在物件導向的類別(class)加上參數, 撈取的資料就不同, 而顯示時, 也只要小幅度的判斷要顯示的部分, 其他部分都是讓迴圈自己跑.

而且這樣可以避免一種狀況, 就是有些寫法會先產生應有的項目, 再去資料庫指定要搜尋項目的值, 但這樣如果未填寫的部分, 因為資料不存在時, SQL 會將所有填寫明細表搜尋一次才確定為 NULL , 而花較久的時間.

Friday, March 16, 2018

行動支付, 雲支付, 電子票證, 電子票卡, TaiwanPay, 虛擬卡, 金融網路服務, 銀行網路APP, 銀行網路APP裡面的台灣Pay....

一堆很口語卻沒有架構的名詞, 只會讓行動支付更亂啊....

最傳統的是銀行帳戶(活儲存/活存/口褶), 然後定存(另一個帳戶但可以跟活儲存/活存互轉).
這帳戶的活儲存/活存, 可以透過"金融卡"提款, 之後又可以存款.

美國有兩大信用卡認證機制(VISA/Master), 日本有JCB, 原本是刷有凸起的卡號, 再簽帳(Credit); 在台灣則由透過銀行發行信用卡, 為了便利, 銀行也會將信用卡與自家的金融卡結合.

電子票證原本是為悠遊卡量身定做, 而市面上已經有iCash等業者自己發行的卡, 後來又有一卡通等, 這些卡總算有一個類似的規格, 就都歸類在電子票證, 都是在台灣非銀行業者發行.

信用卡業者也求發展, 所以又有兩種作法: 1. 感應式信用卡 2. 綁金融卡; 感應式信用卡的消費流程跟信用卡一樣, 差別只有刷卡方式; 綁金融卡則是透過信用卡認證, 但認證後直接由金融卡對應的活儲存/活存帳戶扣款(可能先圈存定額再實際扣消費金額.)

而許多公司都有預收會員費等機制, 加上網購平台等業者覺得傳統信用卡對於爭議款項處理麻煩, 而手機上網又開始盛行, 所以就有業者希望透過手機來處理金流, 把不同於以上的方式, 歸類出行動支付.

只是在台灣, 這些錢都需要被財金單位管理, 所以各業者的錢往往要存在指定帳戶內不能隨便動用, 行動支付業者多(目前有6~8間), 店家要處理的成本就高而降低意願.

而台灣Pay前身是T-wallet+, 由中華民國政府xx單位跟官股銀行一起來跟民間搶市場用的....把原本銀行的活儲存/活存, 透過HCE等機制, 產生手機APP內的特殊代碼(token), 想像成虛擬的另一張金融卡, 而可以透過QR code傳送指定的交易類型, 再使用手機內的虛擬金融卡, 由指定的銀行帳戶轉帳.

另外三大手機業者推出的GooglePay, ApplePay, SamsungPay, 則是原本手機內的信用卡付款機制, 除了買手機內的App外, 也建立虛擬的信用卡, 並在支援的店家, 透過NFC傳送手機內的虛擬信用卡(token)給信用卡業者認證, 但是在台灣因為要透過發卡銀行跟業者的刷卡機, 所以往往會出現"F家(合作的卡機業者)支援4間銀行的卡, S家(合作的卡機業者)只支援1間銀行"的限制....

這樣應該可以稍微解釋在台灣的行動支付為什麼這麼複雜了....因為銀行跟政府每個步驟都在檢核啊.... XD

Wednesday, February 28, 2018

廉價刮鬍刀的好幫手: 香皂.

廉價刮鬍刀的好幫手: 香皂.

現在的刮鬍刀大多是拋棄式, 將刀片用塑膠固定; 很少傳統一個刀具, 裡面刀片可以換的款式, 後者大概只有傳統美容理髮店才有了.

而拋棄式刮鬍刀除了刀片外, 也越來越多花樣, 要刮鬍泡沫讓刀子滑順, 或刀片上下有潤滑層, 幾天就會乾掉, 提醒使用者該換刀片了....

回想一下, 潤滑層, 刮鬍泡沫的主要功能? 潤滑啊....

那手邊還會潤滑的還有什麼? KY嗎(x), 就是洗手台旁邊常見的香皂啊.

既然是潤滑為主, 就拿拋棄式刮鬍刀, 先刨一點香皂, 然後沾一點水, 接著要刮鬍子就很滑順了, 刮完鬍子, 一樣用水把臉洗乾淨, 把刮鬍刀沖乾淨, 然後再刨一點香皂, 吸水跟隔絕氧氣, 刮鬍刀就不易生鏽而可以用更久了.

物件導向設計的方便性

物件導向設計的方便性

以前寫過的程式, 雖然會使用函式(function)將通用性的功能包在一起, 不過需要自己設定一些變數, 避免干擾其他程式設定.

看了物件導向的程式範例後, 總算理解: "封裝"不只是把函式分類, 而是透過物件導向語言, 在程式寫成類型後, 語言就會幫忙把程式每次產生的物件分開, 省去寫程式的人自己做標記或加上一堆變數的工作.

比如這兩個月在新工作的其中一個任務, 就是寫一個為民服務統計系統, 在經過幾週的訪談跟取得現有文件後開始分析. 流程還算單純, 就填報人, 核可, 統計; 但是為民服務項目很多樣化, 所以有些以天為單位, 有些以月或季為單位, 有些項目在機關但又有駐點.

所以應用物件導向的設計原則, 後端先把系統用的功能如資料庫連線, 服務管理, 帳號管理, 週期(日, 月, 年), 駐點單位分別建立一個類型.
另外參考MVC結構, 進網站基本上只有一個PHP網頁, 而透過隱藏的參數, 這個網頁再引入其他的網頁內容來顯示.
比如剛開始就是先判斷參數"目前使用者", 推測是否已經登入, 再自動引入登入畫面.

登入後, 依登入者的權限, 顯示相對應的功能, 在填寫服務功能下, 主畫面只有引入服務清單, 然後呼叫服務管理內的判斷是否已經填過, 或已經過期無法填寫, 這判斷就放在服務管理類型下, 每個服務只要直接用 類型::static_function(服務代號,查詢); 就可以了, 實際運作就由 服務管理 這個類型內的動作去處理, 完全不用再考慮到底怎樣處理的, 而 服務管理 類型裡面就包含呼叫資料庫, 也是只有短短幾行, 其他由 資料庫 的類型內的其他程式去處理, 這樣 服務管理 本身就只負責服務相關的處理.

基礎架構規劃好, 實際上寫程式時也就方便多了, 因為填寫資料大概分為表頭與表身存檔, 表頭包括: 期/機關/填寫日/是否鎖定/服務專案, 表身是服務專案內的清單, 以及實際服務人次.

有些服務專案多了駐點, 則評估影響的範圍, 包括填寫網頁內新增第二層清單, 以及服務管理中跟表頭有關的動作, 加上選擇性對駐點的判斷, 程式中有駐點則增加一點動作, 其他程式都不變.

所以主架構完成後, 加上駐點只要一天就完成了, 這就是物件導向程式的方便所在.

Saturday, February 24, 2018

除濕輪(或沸石)除濕與壓縮機除濕簡易比較

除濕輪(或沸石)除濕與壓縮機除濕簡易比較:

1. 原理:

A. 除濕輪空調是用吸水的材料, "捕捉"空氣中的水分子, 然後轉動除濕輪到另一個加熱區, 讓水分子蒸散離開材料, 再因為冷空氣而凝結成水滴.

相近的動作在電子防潮箱也是, 先打開內門讓吸水材料吸收箱內的水汽, 隔一陣子關掉內門, 改開外門加熱, 只是水分子直接蒸散到空間中.

B. 壓縮機空調是利用冷媒的熱脹冷縮, 冷媒管在室內吸熱膨脹, 然後傳到中介區, 由壓縮機壓縮冷媒, 這時候會釋放出原本冷媒中的熱量, 也增加壓縮機運作時的熱量, 不過是排到室外, 因為溫度降低, 冷媒管本身也會沾附水汽, 而在戶外排出.

相近的動作則是室內的除濕機, 透過冷媒的冷熱交換, 把水汽集中到水箱附近.

2. 特點:

這些設備基本動作都在於冷熱交換同時有水分子的移動, 而空調/除濕機的差別, 在於著重的功能不同.

空調是以溫度控制為主, 所以裝在窗戶或冷氣口, 隔開室內/外的冷熱空間, 通常功率也較大一些; 而除濕機著重水分的移動, 有時是裝在浴室, 更衣室等小空間, 不需要控制溫度, 所以功率可能小一點, 而且只隔離水份.

在運作上, 因為壓縮機的除濕是透過凝結, 所以在戶外下大雨, 或溫度很低時, 空氣中的濕度已經飽和, 就不易凝結, 而無法發揮效果(網友經驗大約 20 度 C 以上, 壓縮機除濕才有效果), 也就是一般人常誤會, 以為天氣冷除濕機壞掉了.

而除濕輪在運作上是直接使用吸水材料, 再加熱蒸散, 所以溫度影響不大, 但因為加熱耗能, 所以耗電量通常比壓縮機款式大.

3. 選擇:

這些設備的原理了解, 實際上的應用, 是否需要購買, 則依幾個條件考慮:

A. 家中是否有人容易過敏或貴重物品需要保存, 而需要長時間除濕?

如果是長時間的溫濕度控制, 直接買"冷熱空調", 再視情況加購除濕機, 因為要直接形成一個適合的環境, 所以大功率的空調最必要, 但空調畢竟以溫度控制為主, 如果濕度控制不容易時, 再加裝除濕機補足.

B. 是否已經有壓縮機空調? 平常室內溫度大約多少?

有些住家或租屋本身已經有壓縮機空調, 而只有人在的時候或只有少數物品需要濕度控制, 則可以考慮以壓縮機空調的除濕功能為主, 如果長時間溫度低(網友經驗常在 15 度 C 以下), 再買除濕輪式除濕機, 物品則放在電子防潮箱.