2021年4月29日 星期四

20210425 中嘉寬頻+第四台

選了 60MB + 第四台方案, 599/月, 最怕的就是這個 60MB 速度不夠快, 在網路上查的資訊, 很看運氣, 有的區域速度快, 有的區域很慢, 不過實際測試之後的速度還不錯。之前門市人員一直在推薦 100MB 方案, 看來在我們這個地區, 60MB 就不錯用了。

fig 1. 有線速度


fig 2. 無線速度


比想像中還要好, 當然看 youtube, 串流影片也沒問題, 非常流暢。也把手機 4g 的約改為 99, 不需要用吃到飽方案。省下 700, 多付 70。

師傅來安裝時, 大約花了 40 分鐘左右, 算是快的, 有聽師傅說 2 小時還是搞不定的。

需要安裝一台 modem, 一台機上盒, 現在的機上盒也己經進步, 除了有第四台的功能之外, 也有 android tv 的功能, 所以就不需要便當盒了。師傅把舊的機上盒回收, 相比起來真的是太舊了, 還會有過熱問題, 倒置無法看第四台。

另外的 modem 也有了無線的功能, 所以我那台 fon 也派不上用場, 師傅 (一般會說工程師吧) 會把分享的 ap/password 設定好, 這樣手機、電腦就可以用 wifi 連線。

這些新的設備都比之前要來得好, 時代真的是進步了。如果沒有這次的調整, 還在用那些老舊的設備。

2 條網路線、hdmi 線都是中嘉提供, 退租時, 這些都要一一歸還。

由於都整合在一起, 只要用遙控器切換, 就可以在第四台、android tv 切換, 相當方便, 不過這個機上盒不能安裝 netflix app (不知道為什麼), 有這需求者要先確認清楚。

之前是用第四台寬頻, 後來改用 4g 吃到飽, 現在又回到第四台寬頻, 但整個使用體驗已經完全不同了, 時代的進步真是驚人。

師傅最後會收 2 個月的費用, 不過卻不會開任何收據, 這邊的處理覺得比較不好, 這樣怎麼證明使用者有付款? 不過還是繳了。

fig 3. 舊款機上盒, 很容易熱當。

2021年4月17日 星期六

中鋼解套

套了10年的中鋼終於解套。最早的一張好像是 2010, 30 塊買的。最近不知道為什麼大爆發, 一般給的理由是原物料上漲, 我相信這只是表面的理由, 更深入的內幕你我小民是不可能知道的, 我懷疑有個我們不知道的組織, 可以操作股票, 我們有幸跟上, 就可小賺一筆。

次貸危機時買了中國信託理專推薦的連動債, 一張10萬, 她只推薦一張, 我自己自作主張又請她再推薦一張, 也是10萬, 一年之後結算剩下2萬的樣子, 記不太清楚了。這就是自己買了不懂的金融商品下場。

從此之後我很小心理專推薦的金融商品。所以我才會去查「富邦人壽優利人生變額年金保險」。

最近賣在
2021/3/09 25.65
2021/4/08 27.7
2021/4/14 32.75
2021/4/16 35.4
2021/4/19 38.25
當賣出 25.65, 27.7 之後我就不慌了, 因為這樣就已經解套了, 如果股價往下, 已經變成小賠, 不用那麼擔心, 所以我就可以安心等上漲在賣出就好。果真如果預期, 愈賣愈高, lucky。2011/4/22 到了 41, 我沒賣。

依照慣例, 大家在剛解套的時候一定會趕緊賣出, 然後就會得到一個經驗, 為什麼股票總是在我賣出之後開始漲, 因為我們沒有預測的能力, 當你解脫時, 只會想趕緊賣出, 哪裡等得住再往上的高點呢?

我認為這不是巧合, 有個說不出的原因, 那不是我們一般民眾可以理解的內幕。所以我就一次賣一張, 果然越賣越高, 以目前中鋼 35 來計算, 和定存10年相比, 大概多了 4 萬, 投資報酬在 30%, 老實說, 這不算是很高的報酬, 因為我的美股遠超這個報酬率, 也一樣是累積 10 年, 那還是被扣了 30% 的股利。美股和台股一樣採用買進持有, 但台股的中鋼得到了很糟糕的結果, 如果沒遇到中鋼大爆發, 還是虧的。但美股只是運氣好, 不是我厲害, 但我現在要改為指數投資, 不再持有個股。

mo 是我報酬最差的美股 40%, 持有 11 年, 如果我 11 年 (2010) 前買 vti, 到 2021 報酬是 150% (還沒有包含配息), 但我的美股報酬遠遠落後這個數子, 指數再次大勝。

現在改用綠角投資法, 這次賣出的部份全部要轉換為富幫50。現在盤中可以買零股, 資金不用像之前一樣那麼緊, 目前也才累積 300 股, 但可以用定期定額手動買入。

2021年4月14日 星期三

第一次使用 buyee 代購

yahoo.jp 台灣人幾乎無法註冊, 需要日本門號/信用卡, 參考:「 日本Yahoo ID帳號的申請流程(免電話號碼)」, 這樣的環境產生了一個生意模式, 代購網站的產生, 感覺蠻故意的。

但是沒辦法, 外國人想買 yahoo.jp 的東西就得透過這種代購方式, 目前有幾個這樣的網站。 只要逛 yahoo.jp 就可以看到 buyee 的廣告, 按下之後便會直接代換 yahoo.jp 網頁, 是最方便使用的型式。

buyee 是廣告最大, 但評價很差的系統, 請參考:「buyee代購有陷井要留意啊

一般被認為匯率差、手續費高, 收費名目多, 服務也不好, 但因為之前只知道這個, 所以第一次買 yahoo.jp 拍賣的東西還是用了 buyee。

buyee 會需要把卡號存在它的系統中, 這樣作法讓我很擔心, 不喜歡這樣的設計, 結束購買之後我就移除了。

我自己在意的點是運送時的追蹤流程, buyee 有幾個國際運送方式, 我是選 buyee 自己的國際運送, 會有追蹤號碼, 會給一個網址讓買家查詢目前進度, 但是這個追蹤紀錄不是很精確, 所以都會擔心能不能正常收到, 這樣感覺很不舒服。

這次購買的東西是 2 顆娃頭, ddh-08, ddh-04, 對娃頭的預算盡量控制在 3000 ~ 5000 台幣。yahoo.jp 上有很多恐怖價位的娃頭, 50 萬日幣之類的, 這些我看看就好, 不會想購買這個價位的娃頭。50 萬日幣對日本人來說大約是 5.5 萬台幣 (50萬/9, 考慮匯率和所得), 但對台灣人來說是 17 萬台幣 (50萬/3, 考慮匯率和所得), 台灣人怎麼拼得過。

交易/交付
  1. 等待發貨 (2021年1月18日 22:39)
  2. 已出貨
  3. 抵達倉庫
費用明細
  • 付款方式信用卡
商品價格
  • 得標價格
    9,750日元
9,750日元 (2,750台幣)
手續費・方案費用
  • 付款手續費200日元
  • Buyee手續費300日元
  • 基本方案500日元
1,000日元 (283台幣)
合共金額 10,750日元 (3,033台幣)




ddh-08 本體為 9750日元 [含稅價]

到倉庫之後有30天的保管期限, 之後又標了 ddh-04, 等到 buyee 倉庫之後在合併寄回台灣。




得標數量1個
合共金額
9,768日元 (2,760台幣)
 
 
信用卡
商品價格
  • 得標價格
    8,768日元 [含稅價]
8,768日元 (2,476台幣)
手續費・方案費用
  • 付款手續費200日元
  • Buyee手續費300日元
  • 基本方案500日元
1,000日元 (284台幣)
合共金額 9,768日元 (2,760台幣)
 




buyee 費用為:
付款手續費200日元
Buyee手續費300日元
基本方案500日元


DD オプションヘッド メイク済み 2010Ver. DDH-04 アイホールオープン 本體為 8768日元 [含稅價]

buyee 費用為:
付款手續費200日元
Buyee手續費300日元
基本方案500日元
出品地域:宮城県
賣家 bookoff2014, 看起來是 bookoff, 我以為 bookoff 只有賣二手書而已, 難怪包裝有 bookoff 的字樣。
fig 3. book-off 包裝字樣

成功結標之後會從之前存在 buyee 系統的信用卡扣款, 再來就是運送回台灣。這時候會計算另外的費用。

包裝費
日本國內運費
到台灣的國際運費
還真的是蠻多費用是吧!

    國際運費明細
    ID 	日本國內運費
    (從賣家寄往Buyee倉庫) 	消費稅
    l648852960 	680日元 	0日元
    h499410648 	710日元 	0日元
    合共 	1390日元 	0日元

    國際運送費用 (從Buyee倉庫寄往顧客指定地址)
    ※ 國際運費中已包含宅配服務費 (350日元)
        1300日元
    集中包裝手續費
        500日元
    日本國內運費
    (從賣家寄往Buyee倉庫)
        1390日元
    運送相關費用合共
        901台幣 (3190日元)
全部費用: 10750 + 9768 + 3190 = 23708 日圓
換算為台幣之後:
3033+ 2760 + 901 = 6694

在 buyee 成功結帳的物品連結上可以找到對應原本的 yahoo.jp 連結, 方便查看資訊。

20210124 把這 2 樣物品集中寄回台灣, 20210202 收到。

再來談談運送追蹤系統, 完成寄送之後, buyee 會發一封 email 通知如何追蹤包裹。
包裹號碼
G2101249051
您可以透過以下網頁,查詢包裹的運送狀況。
https://track.hangyang.com.tw/
但是查詢的結果很奇怪, 也有可能查不到任何資訊。

fig 5. 查不到任何資料 fig 6. 有查到資料, 20210130,
但我是在 20210128 那天查的

fig 5 顯示查不到; fig 6 是查詢的結果, 但我在 20210128 查詢時, 顯示的資料卻是 20210130, 超級詭異。之後查詢也是類似, 有時候查不到, 有時候查得到, 狀態也會更新, 但內容都不是很精確, 只能知道確實有在運送, 有人簽收的話最後也是會正確顯示。要報關時, ezway 也會顯示, 收到時也沒有被課關稅。

ddh-08 有含眼睛, 還有一張照片, 不過我沒有照片中的假髮, 無法有類似的裝扮, 弄了個馬尾頭, 微微的開嘴, 算是比較特別的點, 整體看來也還不錯。

當然和價位更高的娃頭比起來可能有些失色, 但這種東西很主觀, 沒有一定是越貴的娃頭就一定怎麼樣, 這個娃頭我可以接受就是。那種恐怖價位的娃頭, 我就當個欣賞者就好, 不一定要擁有。



出品地域: 佐賀県, 在 yahoo.jp 上買娃頭, 希望買到的是日本妝師畫的頭, 所以會看「出品地域」來確認是海外的還是日本人的妝頭。

fig 9 ddh-04 
ddh-04 我覺得是很難打造的一顆頭, 要弄的好看不太容易, 而且偏向蘿莉型的頭, 這個應該是ボークス官方出品的, 2010 的頭, 到了 2021 被我購入, 還是未拆封狀態, 沒有附上眼睛, 頭殼是硬的版本, 我不知道怎麼裝入頭中, 可能要用吹風機吧!

過了整整 11 年, 才被我購入, 就知道這顆頭不怎麼受歡迎, 競標時也沒有人和我競爭, 出價一次就買到。

而我不愛蘿莉型的風格, 所以沒有購買 mdd 身體, 裝上眼睛之後, 還是用 DD 身體來接, 看了一下, 勉強還可以。

台灣拍賣很少有娃頭可以選擇, 我在台灣拍賣上買過幾顆, 不知道為什麼台灣的妝師很少放台灣拍賣, 台灣人在 yahoo.jp 買東西很麻煩, 又要花上額外的費用, 寄送時間的等待又是一個折磨, 如果不是什麼特殊物品, 我完全不想在 yahoo.jp 買東西。

2021年4月2日 星期五

gcc link 順序

大家可能都有遇過 link 時, 檔案的順序會影響 link 是不是成功, 我也一直搞不懂是怎麼回事, 這次來搞懂他。

m2.c
1 #include "a1.h"
2 
3 int main(int argc, char *argv[])
4 {
5   a1();
6   return 0;
7 }


a1.c
1 #include <stdio.h>
2 
3 #include "b1.h"
4 
5 void a1()
6 {
7   printf("a1\n");
8   b1();
9 }


b1.c
1 #include <stdio.h>
2 
3 void b1()
4 {
5   printf("b1\n");
6 }


a1() 有呼叫 b1(), 如果 link 順序會會影響錯誤 link 的話, 應該是怎麼樣呢?

會出錯的情形是使用 lib, 我們來把 a1.c, b1.c 做成 static library。
gcc  -c a1.c 
ar rcs liba1.a a1.o
gcc  -c b1.c 
ar rcs libb1.a b1.o
gcc -o m2 m2.o libb1.a liba1.a # link error
liba1.a(a1.o): In function `a1':
a1.c:(.text+0x14): undefined reference to `b1'
collect2: error: ld returned 1 exit status

gcc -o m2 m2.o liba1.a libb1.a # link ok

加入 --start-group, --end-group 也可以正確解決
gcc -o m2 m2.o -Wl,--start-group libb1.a liba1.a -Wl,--end-group


如果直接 link .o 沒有順序問題, 以下2個順序都可以成功

gcc -o m2 m2.o a1.o b1.o
gcc -o m2 m2.o b1.o a1.o


有點納悶, 是吧!

我推測是這樣:

gcc -o m2 m2.o libb1.a liba1.a # link error

處理到 libb1.a 時, 沒有把 b1.o 複製到最終執行檔, 因為從 m2.o 得不到這個資訊,

readelf -a m2.o
1 Relocation section '.rela.text' at offset 0x1c8 contains 1 entries:
2   Offset          Info           Type           Sym. Value    Sym. Name + Addend
3 000000000015  000900000002 R_X86_64_PC32     0000000000000000 a1 - 4
4
5 Relocation section '.rela.eh_frame' at offset 0x1e0 contains 1 entries:
6   Offset          Info           Type           Sym. Value    Sym. Name + Addend
7 000000000020  000200000002 R_X86_64_PC32     0000000000000000 .text + 0
8
9 The decoding of unwind sections for machine type Advanced Micro Devices X86-64 is not currently supported.


relocation symbol 只有 a1, 所以在這個時間點, linker 不會去複製 b1.o 到最終執行檔, 等到處理 a1.o 時, 才發現 b1 不存在。

readelf -a a1.o
 1
 2 Relocation section '.rela.text' at offset 0x1f8 contains 3 entries:
 3   Offset          Info           Type           Sym. Value    Sym. Name + Addend
 4 000000000005  00050000000a R_X86_64_32       0000000000000000 .rodata + 0
 5 00000000000a  000a00000002 R_X86_64_PC32     0000000000000000 puts - 4
 6 000000000014  000b00000002 R_X86_64_PC32     0000000000000000 b1 - 4
 7
 8 Relocation section '.rela.eh_frame' at offset 0x240 contains 1 entries:
 9   Offset          Info           Type           Sym. Value    Sym. Name + Addend
10 000000000020  000200000002 R_X86_64_PC32     0000000000000000 .text + 0
a1.o 有一個 relocation symbol b1, 但之後已經不會再去搜尋 libb1.a 了, 而 --start-group, --end-group 會在回頭找 libb1.a, 所以就找到 b1() 了。

ref:
gcc/g++鏈接時.o文件以及庫的順序問題

2021年3月27日 星期六

作業系統之前的 scheme

the 1st edition: 20141127 (4)
the 2nd edition: 20210327 (6)
會選擇 c++ 來開發 scheme, 最主要是因為 c++ 的標準程式庫有很多好用的 class: string, vector, map, list ... 不用為了這些基本的東西傷腦筋; 但這次要開發的是 - 在作業系統之前的 scheme (開發平台是 stm32f4discovery), 這些好東西通通派不上用場, 沒有 malloc/new, 又怎麼能用這些東西呢! 甚至連 global object 都不能用, 所以幾乎和使用 c 一樣, 不過還是能用上點 c++ 的特性。

原本程式中用到 list, vector, map 的部份, 通通要改, 全部改用 array, 不夠彈性, 但容易實作, 至於 input/output function, 需改用 uart 這部份的程式碼, 所以直接把之前搞定的 uart 程式碼複製一份過來修改。

getline 我得換成 getchar uart 的版本, cout 也要換成 myprint uart 的版本, 這之前都做過了, 把以前的努力都集合起來就可以, scanner 的作法則改為一次讀一個 byte 來轉成 token, s-express 不複雜, 但我覺得還是不容易, 沒想到花點時間竟然搞定, 感謝两周自制脚本语言的 scanner 這節提供的知識。

再來是 malloc Cell* 的部份, 由於在重寫 struct Cell 時, 我就考慮到在 stm32f4discovery 開發板上執行, 也就是沒有 os 的環境, 所以才使用了 array pool 來得到一個 Cell 的記憶體。雖然沒有彈性, 但能簡化問題, 再搭配一些人工手法, 可以減低 pool 可能會不夠用的問題。

我先在 qemu stm32 p103 emulator 上測試, 等成功了再上到 stm32f4discovery, 減少 flash 讀寫次數。也的確有必要, 光在模擬器上就測試了無數次, 減少了多次的 flash 讀寫。

在製作 p103 emulator 的版本階段, 出了一個 link 問題:

git@github.com:descent/stm32_p103_demos.git stm32_p103_demos/demos/uart_echo git commit: 6b2df2c6e62f3c48a6c6dc20c76367124c1ca447

bss_to_big
1 /home/descent/arm-cs-tools/lib/gcc/arm-none-eabi/4.7.3/../../../../arm-none-eabi/bin/ld: mymain.elf section `.bss' will not fit in region `RAM'
2 /home/descent/arm-cs-tools/lib/gcc/arm-none-eabi/4.7.3/../../../../arm-none-eabi/bin/ld: region `RAM' overflowed by 34085848 bytes
3 collect2: error: ld returned 1 exit status


我以為我已經很了解 link 的問題了, 這應該難不倒我, 就是哪個 section 太大, 整個記憶體空間不足嘛! 嚇不了我的。但隨著時間的過去, 我還是無法處理這問題, 亂 google 找問題, 我 - 開始緊張了, 原來我還有沒搞懂的東西。

當然最後還是搞定了, 原因是: bss 竟然需要 34M 的記憶體空間, 嚇壞我了, p103 只有 20K ram, 把 main.ld 的 RAM 從 20K 改成 48M 就可以編過, 但想也知道, 放入 flash 執行, 一定掛掉。

main.ld  MEMORY {   FLASH (rx) : ORIGIN = 0x00000000, LENGTH = 128K   RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 20K -> 48M } ... ...


我當然是不會用這麼蠢的改法。程式中用到相當多的 global variable (global variable 不一定佔據 bss, 得找對才行), 來把他們減少, shorten_bss L32 的效果最好,

/bin/ld: region `RAM' overflowed by 877288 bytes collect2: error: ld returned 1 exit status

從 34M 降到 877K, 效果不錯, 可是還不夠 ...

shorten_bss
 1 diff --git a/cell.h b/cell.h
 2 index d7238ea..eb36b5c 100644
 3 --- a/cell.h
 4 +++ b/cell.h
 5 @@ -11,7 +11,7 @@
 6  
 7  using namespace std;
 8  
 9 -const int MAX_POOL = 1000;
10 +const int MAX_POOL = 70;
11  
12  enum PairAttr {HEAD, FIRST, SECOND};
13  enum CellType {STRING, SYMBOL, NUMBER, PAIR, PRIMITIVE_PROC, NULL_CELL, INVALID};
14 @@ -21,7 +21,7 @@ struct Environment;
15  struct Cell;
16  typedef Cell *(*ProcType)(Cell *);
17  
18 -const int MAX_SIZE = 256;
19 +const int MAX_SIZE = 20;
20  // a variant that can hold any kind of lisp value
21  struct Cell 
22  {
23 diff --git a/s_eval.h b/s_eval.h
24 index 37048ac..2da9ae5 100644
25 --- a/s_eval.h
26 +++ b/s_eval.h
27 @@ -4,14 +4,14 @@
28  #include "cell.h"
29  #include "token_container.h"
30  
31 -const int MAX_ENVIRONMENT_POOL = 1000;
32 +const int MAX_ENVIRONMENT_POOL = 10;
33  
34  #ifdef USE_CPP_MAP
35  typedef std::map<std::string, Cell*> Frame;
36  #else
37 -const int FRAME_LEN = 128;
38 +const int FRAME_LEN = 56;
39  
40 -const int LINE_SIZE = 256;
41 +const int LINE_SIZE = 128;
42  
43  struct EnvElement
44  {
45 @@ -29,7 +29,7 @@ struct Environment
46  
47      Frame frame_;
48  
49 -    char name_[255]; // for debug
50 +    char name_[12]; // for debug
51      int free_frame_index_;
52    private:
53  };


胡亂修改後, 總算 link 成功。

機器上的記憶體有 20K, 程式本身有 19K, 載入到記憶體後, 可以正常執行的嗎? 不一定, bss 區域不會佔據程式本身, 但是會佔用載入時的記憶體位址, 所以還得加上 bss 佔用的記憶體, 若 bss 佔據了 2K, 19k+2k = 21k, 記憶體就不夠用了。

這便是 link 不過的原因。

還有問題二:

高興的將程式載入模擬器後, 準備欣賞自己的傑作, 發現:

repl 的第一個參數 prompt, 不知道為什麼會被 TokenContainer tc 所影響 (傳進來的參入位址會變成 0), 我把 TokenContainer tc 改成 global variable 才正常 (原本是 auto variable)。

我猜測是 stack 被覆蓋了, 不過沒有認真追, 也有可能是其他問題。

再來還有一些後續的小問題, 克服他們後, 就是下面影片的成果。



應該離成功不遠了 ...

真實機器篇 - stm32f4discovery



事情果然沒那麼順利, 在我將模擬器的程式移植到 stm32f4discovery 後, 沒什麼問題, 提示符號出來了, 但是打下 (+ 1 2) 之後, 程式沒有印出預期的 3, 而是停止不動。猜測是 stack 問題 (又是 stack), 將 stack 改大一點就正常執行了。在 x86 記憶體很大, 不太容易遇到 stack 太小的問題, 但在 stm32f4discovery, 記憶體不大, 只有 192k, 考驗我的程式能力。

下面影片是在 minicom 的執行結果:



後來知道了 ccm 這東西, 把 stack 移到 ccm, 成功擠出更多記憶體。

支援 backspace



這個常見的的功能還真沒那麼簡單, call library 果然比較舒服, 思考良久之後, 決定使用 deque 來完成這個功能, 我參考了 c++ 的 std::deque, 實作了一個 MyDeque, 雖然我用的是 c++, 不過作業系統之前沒有 std::deque 可以用。

MyDeque 提供以下 member function:
push_front() 給 ungetch() 用
pop_front() 在 getchar() return 時傳最前頭的 char
push_back() 把輸入的 char 存到這個 deque
pop_back() 提供了 backspace 的功能

因為這個 mydeque 需要成為一個 global variable, 所以沒有提供 ctor, 避免 compile 不過的問題 (你很疑惑為什麼吧?), 不過這不是什麼難題, 我使用了 init() 來變通, 得自己呼叫 mydeque.init(); 來作初使化的動作, 也如你預期的, 我老是忘記 call .init(), 每每在驚呼「為什麼?」之後才想到自己的疏忽。

使用了一大堆 global variable, 完全不是 c++ 哲學, 就跟你說了, 這是一個長的很像 c 的 c++ 程式。

為了支援 backspace 沒想到要多做一個 class, 這是經過深思熟慮後的想法, 也才決定用 deque (念做 deck), 這還真是個神奇的資料結構。

下面影片顯示支援 backspace 的操作:



不過這個實作還有點問題, 超過 MyDeque 的大小, 就會有問題, 所以我把 MyDeque 設到 128 個 int 大小, 暫時躲避這問題。

line edit history



20141115 我加上了 line edit history 的功能, 按下 up/down 就會把之前打過的指令取出來, 很基本的功能吧! 但要實作這個功能可花了我好大的力氣。

我寫了一個 deque 的 template 的版本, 一個 CString class 用來支援這樣的功能, 所以前面那個 MyDeque 被移除了。我第一次覺得 c++ template 這麼好用, 感動到痛哭流涕。雖然 c++ 現在複雜的不像話, 不過程式員只要選擇自己要用的部份就好了, 重點是把程式寫出來, 而不是用上什麼新特性。這個程式沒有 malloc/free 還不是照樣可以完成。

偵測 up/down key 是個小問題, 答案分別是: up: 27 '[' 'A' down: 27 '[' 'B' right: 27 '[' 'C' left: 27 '[' 'D'

要抓出 3 bytes 才能判斷是哪一個方向鍵。

而 scanner 程式整個重新改寫。辛苦完成的 MyDeque 派不上用場了, 以下影片示範這個功能:



當做出 history 功能時, 自己都覺得很酷, 這個功能真是無敵好用。

這個程式集 os 觀念和 scheme interpreter 之大成。是繼 simple os 之後的心血, 所有的東西都自己打造, 很有成就感。

這裡有篇履歷的文章: How the HR department and a programmer reads your resume? 我結合 os, interpreter, 可以加 20 分嗎?



疑, 這次怎麼沒有提供 source code, 因為這次的 souce code 分佈在 3 個地方, 太麻煩就不列了。有興趣的朋友一定會自己發問的。

寫下這篇文章很久之後, 我終於整合好所有程式碼,

source code:
https://github.com/descent/simple_scheme

可以使用 p103 這個平台編譯, 這是跑在 qemu 模擬器上。

好久沒做烘焙產品了, 該來做一個蛋糕慶祝一下, 犒賞自己。

2021年3月25日 星期四

20210325 台灣缺水, 大家一起來節約用水

大概從 202010 月以來, 台灣的降雨就很少, 到了 20210325 時, 有些區域已經開始要停水供應了。

作為台灣一分子, 提供一些省水方式:
改為2天洗一次澡
尿尿累積多次再沖水

fig 1 是我在洗手台放個小碗, 這個是買外食的時候附的碗, 我留下來做這樣使用, 洗手時, 就可以把水裝起來, 倒入 fig 3 的水桶, 然後拖地用。

fig 2 則是在洗澡時, 熱水還沒熱之前的冷水裝在臉盆, 之後可以沖馬桶或是花盆。

這些是我一直都在做的, 所以不會不習慣, 若你是第一次這麼開始, 可能會有一點不習慣。

fig 1.
fig 2
fig 3


ref:
整理包/不只苗栗、台中!「供五停二」限水節水影響區域、臨時供水站一次看

2021年3月24日 星期三

將來銀行的消息討論

App有上百個bug、IT不會寫程式!將來銀行劉奕成被臨陣換將,背後原因大解密

台灣媒體消息報導的可信度/正確性/內容度, 大家心裡有一把尺, 這個人說不定就是很單純被內鬥掉的, 也不用扯那麼多理由。但身為資訊人員, 對其中一些敘述很不爽。

資訊團隊只有不到一半的人有金融背景

究竟為何將來銀行的資訊系統,會有這麼多的狀況呢?事實上,將來銀行的資訊系統是委託大股東中華電信協助開發,知情人士表示,中華電信沒有開發金融系統的經驗,工作的方法與文化,與金融背景出身的同仁之間,存在的許多矛盾與衝突。

據了解,將來銀行的資訊團隊成員,只有不到一半的人有專業的金融背景,其他的人才大多來自其他非金融領域,多元人才在許多網路產業是很平常的事情,但將來銀行IT部門跨業人才的合作度不足,導致欠缺金融業要求穩定度至上的觀念


資訊團隊除了去銀行挖之外, 怎麼可能會有金融背景, 其他金融背景的員工是幹什麼吃的?

他會要求那些有金融背景的員工要有資訊背景嗎?

不就是要資訊背景和金融背景的人一起努力嗎? 感覺把鍋都給資訊人員背了。

某銀行高層觀察,金融業管理的是客戶的金錢與財產,必須有非常強烈的「穩定」概念,而將來銀行多數的資訊團隊員工並沒有,導致產品開發狀況多。舉例來說,金融背景的人,會認為系統必須內部確認100%沒有問題,再請金管會來審查,但是部分資訊部門的人卻認為,就算有一些Bug,也沒什麼關係,事後再來修改就好了。


所以那些部份的資訊人員是高層囉! 要不然怎麼有 bug 的系統可以發布, 小小工程師沒這樣的權利吧! 感覺又要甩鍋給資訊人員呢! 另外在說不可能有沒 bug 的系統, 會說 100% 沒問題的人, 一定不是真正開發系統的資訊人員, 如果是, 你得要小心這個人說的話。如果真要沒 bug 才能發布的話, 那世界上大概沒有軟體可以用了。windows 都會有藍色畫面, linux 都會有 kernel panic, android app 也會有閃退, 所以這些系統不能發布嗎? 不是, 在這之間要取得一定平衡, 這是資訊人員和金融人員集體的智慧。

資訊人員本來就不一定要會寫程式, 整個金融系統那麼龐大, 不會全部都是需要寫程式的技能, 「將來銀行」自己的資訊求職人才有些也沒特別指出要會寫程式。

【資訊】資訊處專案管理師 Project Manager 03/22更新
將來商業銀行股份有限公司 本公司其他工作
儲存應徵
 11~30人應徵
工作內容

1.負責計劃、指揮及協調各項專案相關事宜。 
2.管理專案品質、時程及預算。

職務類別
軟體設計工程師 、Internet程式設計師 、軟體相關專案管理師
工作待遇
待遇面議 (經常性薪資達 4 萬元或以上)
工作性質
全職
上班地點
台北市大安區敦化南路二段95號 
管理責任
不需負擔管理責任
出差外派
無需出差外派
上班時段
日班
休假制度
週休二日
可上班日
一個月內
需求人數
3~4人
條件要求

接受身份
上班族
工作經歷
 3年以上
學歷要求
 大學以上
科系要求
 不拘
語文條件
 不拘
擅長工具
 不拘
工作技能
 不拘
其他條件
 工作專長及經驗:
1. 實際參與專案管理三年經驗以上。
2. 具備以下相關經驗尤佳:
(1) 具PMP 證照。
(2) 熟悉金融銀行產業,或信託財務管理業務。


將來銀行有沒有將來我不知道, 但如果是純網路, 沒有實體的銀行, 搞成這樣, 我是覺得不太有信心。王道銀行至少還有實體銀行, 出了事情至少還可以殺到實體銀行, 純網路銀行要是不能給人信心, 真的會覺得害怕。

ref: