[開箱] FILCO Majestouch MINILA-R Convertible

  FILCO   MINILA-R 

 

身為一個碼農，對於鍵盤是有一定的要求度；但是在辦公室很少拿機械式鍵盤，原因是很不習慣聽到別人機械式鍵盤敲打的”機械式”聲音 😡，所以自己自然而然也就不會想用機械式鍵盤去影響別人 😅

 

但是這一年來，陸續接觸了紅軸機械式鍵盤，感覺是個可平衡的選項，聲音不大也有敲打機械式鍵盤獨特的段落感，所以陸續使用了

 

·        ROCCAT Vulcan TKL RGB 紅軸

·        LOGITECH G913 TKL 無線 紅軸

 

ROCCAT雖然是紅軸，但是敲打的聲音還是有清脆的反彈聲，雖然很好聽（跟其他家比起來，個人主觀）也讓輸入的過程非常的爽快，但必須接線又考量到聲音，所以目前拿來當FUN KEYBOARD使用。

而羅技的G913使用上非常滿意，因為短軸的緣故，所以輸入非常輕快和輕鬆，也整合了很直覺的音量調節旋鈕和多功能按鍵，可以切換藍芽和無線連接，而且非常順暢，唯一美中不足的是鍵帽的刻印不明顯，雖然我盲打，但是重點是開啟RGB燈效時，完全沒有FU，只看到鍵盤發光，但完全沒有美感（不過我是早期買的黑色版本，不確定後續是否有改善了），這方面還是ROCCAT比較有娛樂性；因為我在家裡同時必須要連接筆電和桌機，所以目前在家裡就以G913為主囉。

 

回到這篇的主角，也就是因為這一年使用機械式鍵盤的心得，所以就開始物色辦公室用的紅軸鍵盤 XDD

目前放辦公室的LOGITECH CRAFT使用上也非常滿意，但是薄膜式鍵盤的回饋力道比較明顯（快速輸入時，會不自覺的很大力的按到底），在經過連續幾個小時的敲打過程後，會讓我的手指開始產生疲累感，也因為它是100%全幅鍵盤，比較佔空間… 好吧，以上可能都是藉口 XDDD，總之研究了一番之後，決定入手FILCO Majestouch MINILA-R Convertible 60% 鍵盤。

 

我是直接從硬派精靈線上訂再貨到付款，從下訂單到送達門市約三個工作天。

 

接下來就直接上開箱照片了，後面再來說明我自己的60% 鍵盤配置。

 

(包裝盒正面)

 

(內容物)

 

 

 

鍵盤很樸素，也沒有RGB燈效，回歸到本質… 就是鍵位、組合和敲擊。

 

 

打了一天，大概知道為何有FILCO信仰了 😎

雖然是紅軸，但是打擊感除了線性也有扎實感，反彈的力道很Q、很舒服。 對於我自己的重點是因為我手指比較粗，所以我的鍵盤上的按鍵兩兩都必須要有一定的距離，可以看到上圖，它的按鍵是兩層的，對於避免誤觸到兩個鍵非常有幫助，而空白鍵兩旁的組合鍵「FN」，設計上是微凸起的，方便區隔。

當然缺點也是有，就是網路上說的按鍵會有油感，就是看起來和摸起來會有一點”油”的感覺，使用了一天的確看起來好像使用了一個月 XDDD，不過我特地回去看其他黑色鍵盤也是會有，只是沒有那麼明顯，所以也有可能是按鍵顏色的關係會看起來比較有油感，不過不影響輸入。

 

接下來說一下我自己的按鍵配置，這一款60%有配置DIP開關，我打開了1、2、6:

 

DIP	Description
1	將「左ctrl」及「CapsLock」大寫鎖定交換
2	將「左ctrl」及「ESC」交換
6	省電模式

 

在工作上大部分使用 VIM 的按鍵方式，所以在其他鍵盤上，我也是會把原本的「CapsLock」變成「左CTRL」，「左CTRL」改成「ESC」， 這樣我按最左上和最左下都是退出的命令。

這鍵盤由於預設「ESC」是沒有直接輸入的按鍵的，必須要使用「FN」+「~」，這是比較不方便的，不過因為原本的習慣就可以接受改按最左下角位置，只是一開始在按「~」會下意識去找左上第二顆 XDD。

 

另外沒有直接的方向鍵，必須使用以下任一種方式：

1.  搭配「FN」去按「E」「S」「D」「F」

2.  搭配「FN」去按 「?/」、「DEL」、「WIN」、「ALT」

3.  打開DIP開關4: 將右下方的「?/」、「DEL」、「WIN」、「ALT」直接變成「上」「右」「下」「左」方向鍵，但原本的ESDF方向鍵功能將失效，也沒有「?/」

 

我是選擇不打開DIP開關4， 因為「?/」在VIM是常用到的按鍵，所以比較需要花時間習慣的是方向鍵的部分。 如果你是WINDOWS用戶，可以透過 Windows PowerToys去調整按鍵配置。 如下圖我額外把「右CTRL」改成「?/」，上面我啟用的DIP其實也可以直接透過這個軟體來設定即可。

 

 

最後拍一下目前服役中的三個不同廠牌的紅軸鍵盤。

 

 

（更新）使用了兩周後的心得。

優點：

1. 極佳的鍵盤敲打體驗。聲音很舒服不刺耳。
2. 60%鍵盤，不占空間。

缺點：

1. 上面提到打了一陣子後，鍵帽會看起來有一些油油的。
2. 切換到不同鍵盤的時候，需要重新熟悉一下感覺，尤其是方向鍵。
3. 方向鍵如果不打開 DIP開關4（右下角模式），因為必須要按著「FN」，所以在一些組合會有點卡，例如切換並選擇當前應用程式（ALT + TAB + 方向鍵）就必須同時用到四隻手指頭。 雖然是可能還不熟練的關係 （這可能熟練嗎 😅）。

其他：

1. 鍵盤比較高一些些，所以建議買一個中型的鍵盤護墊來搭配使用。
2. 別人很大機率無法使用你的鍵盤（由於我自己比較注重衛生，所以別人用過我的鍵盤或滑鼠，我會偷偷地用酒精擦拭一下XDDD，不過我通常會放另外一個也連著電腦的鍵盤備用或別人用）

以上是比較針對FILCO Majestouch MINILA-R Convertible的部分。 而以下幾點是使用大部分 60% 鍵盤會需要熟悉的地方

•  F1 ~ F12鍵必須透過組合鍵觸發（很多開發工具會用到）。
• 「HOME」和「END」其實還滿常用到的，所以如果有沒有獨立按鍵，也是會有點卡。（我一直以為他們不重要 😅）

（再更新）使用了一個月後的心得。

沒想到放在辦公室使用了一個月多幾天，已經完全適應了 FILCO Majestouch MINILA-R Convertible 60% 鍵盤，反而對家裡的80%鍵盤有點不太適應（尤其是方向鍵會想要先去找FN鍵 😅）。 所以... 又入手了一把茶軸的放家裡使用了 😱😱😱

接下來說一下茶軸的差異：

1. 敲打音量我覺得可以說是完全沒差異，一樣是很乾淨，是"咚咚"的聲音，不會是那種"鏘鏘"比較尖銳的聲音。
2. 敲按鍵有一股回饋（反彈）的力道，這是茶軸的特性。雖然力道不大，但是我自己會不自覺多用一點點力氣去敲打，所以個人覺得如果是要長時間快速寫程式或打字，紅軸是比較適合我自己的，但如果你想要有稍微打字機的感覺（就是鍵盤會告訴你... 確實有按下這個鍵的感覺），茶軸就比紅軸適合。 不過話說回來，一切真的都是習慣就好。
3. 茶軸我是選青藍色（照片可能看不太出來差異），想比之下，灰色鍵盤會比較穩重一點。

最後再補上幾張茶軸的 FILCO Majestouch MINILA-R Convertible。 

[markdown] Trivial (冷知識)

 

 

▋Escape special character

 

To escape ` in code snippet, put ` double times and blank before and after a code snippet.  e.q.

`` console.log(`My name is ${name}.`) ``

Notice the format is `` console.log(`My name is ${name}.`) ``

 

▋Center an image

<p align="center">

  <img src="https://xxxx.com.tw/assets/001.jpg" alt="features"/>

</p>

▋Heading Anchors

Here is the example of creating an anchor to a heading in GitHub flavored markdown.

## Heading A

This [link](#heading-b) will go to Heading B.

### Heading B

This [link](#heading-a) will go to Heading A.

 

 

 

 

 

 

[Golang] gqlgen: Get started

    Golang    GraphQL    gqlgen    GORM 

▌Introduction

[Architect] 產品及專案架構設計思維

最近常常被問到，如何為一個產品或專案設計好的架構？ 

我回答得很簡短：「首先要了解目的，然後因應當時的環境、時間和資源，評估可以達成這個目的的架構和流程，就是當時最適合的方式。」

然後就會得到

趁著最近比較有空，我把一些自己的想法整理在這篇文章。
但是在更往下之前，我想先談談自己對於 "架構" 這個詞的定義。

架構

我們知道產品和專案都有自己的生命周期。 而我自己心目中的架構是支撐它們可以在各自生命週期運行良好的軟硬體、流程和方法。  例如：

• 功能開發完成後，團隊可以多久和以多少信心佈署到正式環境？
• 新進員工加入多久，可以獨立開始作業？
• 線上有問題時，流程是什麼？ 
• 不同團隊協作流程順暢嗎？
• 軟硬體架構安全嗎？ 有考慮到業務成長量的對應擴充方式嗎？
• 開發團隊的價值有傳遞給客戶嗎？ 我知道客戶在抱怨還是幫我們說話嗎？

所以如果你期望看到底下有軟硬體架構的解決方案，很抱歉並沒有 XDD
這篇文章講得是我個人的思維。

目的

講到"目的"，通常我們想到的是：「如期如質上線，滿足老闆或客戶（或BU單位）的需求，讓公司營運正常並賺錢。」

這個大方向沒錯，但是我們再切成 "人"、"系統" 和 "業務" 來看的話，可能就沒有那麼單純。 以系統來看我們要達成的目的， 我們至少必須要知道

• 分辨必要（Must have）或是次要（Nice to have）的功能。
• Sizing，未來幾年的業務及系統成長量。
• SLA, SLO。
• 如果是專案，專案合約可能有明訂一些必要的規劃和使用的技術。

至於架構設計為何需要考慮到人（即利害關係人）？ 原因是每一項任務的成因和老闆的期望，可能不是我們想的那麼單純... 

政治因素、外包廠商、專案價格... etc（還有不好說的那部分），都會影響到我們評估要花多少資源在整個架構及任務上。  或許老闆的期望是讓團隊花更多時間在研發上，那我們就可以花更多資源在設計解決方案上。

業務角度也是重點，產品的業務是以套裝解決方案、或客製化收入為主？ 以 SaaS 還是導入客戶端來做為服務重點？ 上線後的維運單位和成本？ 這會影響到我們的架構設計和技術選型。  

當時的環境、時間和資源

試著回想起三年前或最近剛上線的專案，是不是覺得有更多改善的空間？ 肯定是的。
但是當時的情況允許我們用目前更好的架構或方式來建置嗎？ 不一定。

考慮環境，包含法規、公司及部門政策和團隊素質。  如果我們的解決方案和架構，和現行環境有衝突的話，就要回過頭去思考目的和思考必要的 tradeoff`。 

至於時間和資源，就不用多說了，鐵定是要考量的因素。 

我自己衡量的標準是

• 先理解相關利害關係人的期望，在可以完成任務及先滿足擁有權力和資源的關係人（通常是老闆和客戶）的情況下，去嘗試取得更多時間和資源完成團隊的期望。 
• 透過數據、經驗和知識來下決策，有的時候我們必須要堅持對的事情，去和老闆或客戶持續溝通。
• 團隊素質如果高的話，可以在過程中去做更多嘗試和想法，這有利於在架構設計上有更多的選擇和彈性。   

當然現實情況是殘忍的，經常不會有最佳的資源去達成我們想要的方式，仍是取捨問題。 

當時最適合

當時最適合的決策和設計，現在回顧可能是錯誤的；也表示我們現在已經成長了也學習到更多經驗和知識，來理解如何用更好的方式來處理它。 隨著資訊越來越進步、技術推陳出新，團隊掌握更多知識和經驗（不管從內部或外部），可以讓我們更快、更準確的於當下做更適合的決策。  我自己的想法是，勇於改變和挑戰，即使結果不如預期，勝於什麼都不想改變。

[Golang] GORM: Get started

   Golang   GORM    ORM 

▌Introduction

[Testing] Automation flow by Robot Framework, GitHub Actions and Postman Monitor

   Robot Framework   GitHub Actions   Postman Monitor 

▌Introduction

---

 

Due to COVID-19, many people work from home and need to clock in or out online on working days.

Since I sometimes forget to clock in or out online and I am so lazy to open the HR website and enter user ID/PWD each time on it, I decided to make the automation clock in(out) flow by E2E testing stack.

 

I use the stack as following:

ü  Robot Framework

ü  Azure Container Registry

ü  GitHub Actions

ü  Postman Monitor

 

 

   

 

 

 

▌Steps

---

 

▋Record and prepare the E2E automation test

 

I use Katalon Recorder and Robot Framework to have both automation test as clock_in.robot and clock_out.robot.

 

I would like to run the tests in Docker environment, so I made a dockefile and could be built and published the Docker Image to a private Docker registry (e.q. Azure Container Registry).

 

See my previous article, [Robot Framework] Run E2E test by Chrome and SeleniumLibrary in Docker, for the implementation details.

 

Now, I have to find a way to pull the Docker Image and then run the tests automatically.

 

 

▋GitHub Actions

 

GitHub Actions supports amazing and easy way to automate the workflow.

This article, [GitHub] Github Actions - Workflow dependencies, shows how to pull and run a Docker Image by GitHub Actions workflow.

 

Here is the YAML file of workflow that has workflow dispatch event. I will talk about why using workflow dispatch instead of schedule event later.

 

 

▋docker_clock_in.yml

---

name: Docker Clock In

on:

  # schedule:

  #   - cron: '10 0 * * 1-5'

  workflow_dispatch:

    inputs:

      trigger:

        description: "The trigger"

        required: false

        default: "Postman Monitor"

      trigger_datetime:

        description: "The datetime for triggering the workflow"

        required: true  

jobs:

  clock_out:

    name: Clock In

    runs-on: ubuntu-18.04

    steps:

      - name: Print Environment Variables

        shell: bash

        run: |

          echo "Arguments are ${{ github.event.inputs.trigger }}, ${{ github.event.inputs.trigger_datetime }}"

      - name: Docker Run

        uses: addnab/docker-run-action@v3

        with:

          username: ${{ secrets.ACR_USERNAME }}

          password: ${{ secrets.ACR_PASSWORD }}

          registry: ${{ secrets.ACR_REGISTRY }}

          image: ${{ secrets.ACR_REGISTRY }}/robot-bank:latest

          options: --rm --shm-size=2gb

          run: |

            robot /usr/src/rf/tests/ClockInOut/clock_in.robot

 

And my GitHub Actions secrets:

 

 

After pushing the workflow YAML file to main/master branch, I can trigger the workflow (open the headless Chrome, go to HR website and then clock in) in three ways.
(Reference: Manually running a workflow)

1. GitHub CLI: gh workflow run <workflow>

2. Run the workflow in GitHub Actions UI

 

3. Run the workflow by sending the HttpPost request to

https://api.github.com/repos/<user_id>/<reponsitory_name>/actions/workflows/<workflow>.yml/dispatches

Notice that we have to set a Personal access token for Authorization header. 

(See GitHub Docs: Create a workflow dispatch event)

 

 

 

▋Why not use schedule event but workflow_dispatch?

 

I commented out the schedule event in docker_clock_in.yml, and use workflow_dispatch event instead. The reason is that schedule event has a uncertain delay time and won’t be trigger on the schedule time precisely. If your job can tolerates a delay time, schedule event might be a good way to trigger it. However, since I need to clock in before my office hours so I use Postman Monitor to automatically send the request for running the workflow.

 

 

 

▋Postman Monitor

 

Postman Monitor is the collection-based monitor that we can execute a collection of requests and collect the response time and result by scheduled time. Furthermore, it runs on Postman's cloud infrastructure, which is hosted by AWS. In other words, we do not need a live machine to execute the target request(s) by Monitor.

 

The following is my monitoring setup for requesting the clock-in workflow_dispatch API.

After dispatched the workflow, the workflow will pull and run the Docker Image that has automation tests for my clock-in or clock-out.

 

 

▌Summarize

---

 

There are many ways to accomplish this automation job.

I chose the stack/tools is because I don’t want to have extra cost for this routine job and I do want to save my time from it.

 

 

 

▌Reference

---

 ▋GitHub Docs: Events that trigger workflows

▋GitHub Docs: Create a workflow dispatch event

▋GitHub Docs: Manually running a workflow

▋Postman: Monitoring your APIs