Software Consulting Business (Progress)

回想從 2019 8/11 至今，也做了整整半年的生意。從完全沒有計畫、只憑感覺做，到把 Million Dollar Consulting 一書看完。大致上可以列出下列幾點的進展，我引用 Million Dollar Consulting 一書的重點來說明：

1. Seeing only economic buyers.
   領悟這點滿重要的。我領悟之後，就明白，我的買家大部分是高階主管或是中小企業主。其它人往往都只是 Gate keeper 而已，見他們只是浪費時間。為什麼 economic buyer 很重要呢？最重要的原因是，如果要 charge value-based fee ，只能找 economic buyer 來談。只有 economic buyer 才真正關心 output 。

2. Writing proposals with options.
   我從這一點想出了兩招可以快速幫自己增加利潤的招式：
   (a) 讓渡著作權               + 10%
   (b) brand mark removal  + 20%
   這些都是 options ，選購項目，但是客戶往往有誘因要購買。

3. Charge value-based fee / Conceptual agreement
   Alan Weiss 透過一再地與客戶交談，找出創造價值的契機。他把 value creation、pricing、proposal 合為一體。

   我的話，也是採取類似的精神。和客戶深入地討論軟體的需求、訂出合適的規格、提案、報價 、實作。我的報價，如果一般人只看我寫多少的 code 的話，會覺得真的是非常貴。但是，在這個討論的過程之中，最大的價值創造階段，其實是在「訂定規格」。我寫的每一個功能，都要是真真切切派得上用場的，這件事在訂規格的時候就已經確立了。

   (續) 我後來重看了這部分的章節，覺得自己其實誤讀了一個很重要的部分。我自己在與客戶談需求時，並沒有詳細地去把 conceptual agreement 這一塊談好。如果要提高成交率、且為客戶創造高價值的話，其實應該要對這個部分，下功夫去詳談。conceptual agreement 包含 objectives, metrics, value 三個元件，它也是連結 trust relationship 與 accepted proposal 中間的重要環節。

4. Populating the Accelerant Curve.
   目前的話，最左端的產品服務，是一些不收錢的免費文章
   左二的部分，需要做 open source project 、提供可客製化的軟體解決方案。(半客製化)
   右二的部分，是幫客戶寫軟體。(全客製化)
   最右邊的部分，則是每年收取軟體維護費。 total development cost 的 25%

5. Create marketing gravity.
   通常只有 referrals, speaking, networking 可以短期且快速地帶來客戶。目前我的經驗來講，referrals 和 networking 有成功的案例， speaking 則還沒有…


如果套用 Business Canvas 的九大區塊來分析上述 5 個重點的話：
1 對應到 Customer segment
3 對應到 Value proposition
2, 4 對應到 Customer relationship management
5 對應到 Channel

用 Event Modeling 的方式來描述規格

如何描述規格？

我做軟體做好幾年了，寫程式換過幾種語言。而寫規格書，卻沒有下過功夫去研究。最近一次開發一個比較大的系統，我自己後來寫出來的規格書，大概包含了三個部分：

1. 用講故事 (story telling) 的方式，用人類語言敘述的系統行為。 

2. Database 的 schema 

3. API 的 spec 

後來，仔細想想，這樣子其實也是有問題。其實一個系統的開發，應該拆解成三個階段：

A. 用「非開發人員」也可以理解的方式，書寫的高階系統行為、概述。講的是系統的目的 (purpose)

B. 以程式語言實作系統 (implementation)

C. 寫出該系統的實作規格 (description of implementation)

以我自己的最近一回做的東西來講，story telling 算是 A 。Database schema 和 API spec 都是 C。而系統在與非開發人員溝通，主要是依賴 A 的部分。換言之，其實我做 A 的部分，算是做得很不清楚，因為只有 story telling ，算是相對難以把事情說清楚的。

Event Modeling

Event Modeling 該網站提出的方法，我覺得算是 story telling 的加強版，即 story telling with time。它建議，首先畫一條水平軸，描述「時間」的進展，然後在這個由時間構成的水平軸線上，會放上一個又一個的長方形來描述系統的 story 。

每一個長方形由三個要素構成：
1. Trigger              - 通常是「使用者介面」或是「外部 API」
2. Action               - 通常是要讀或是要寫入系統，分成兩種：Command 與 View 。Command 是「想要改變系統狀態的意圖」、而 View 是系統當下的「報表」、「結論」

3. Event 　　　　   - 寫入硬碟的業務事件 (business fact)

長方形又可以根據 action 與 external states 可以仔細區分成 4 種 patterns

1.  Command   - state change

2.  View          - view

3.  Translation - external state input

4.  Automation - external state output

使用 Datomic 要注意的事： should not expose the entity number

偶然在 stackoverflow 上，看到了這類相關的問題。

When design the system API, it's very important that your input never have any raw entity ids in it, only external ids. Below is the reason:

1. You don't have an entity id until you transact the entity, so you can't create an entity and all its indexes together. You must first transact the entities, see what their entity ids were, then transact the composite index. 
2. It's no longer easy to do your own renumbering. There are datomic techniques which involve taking datoms from one database and transacting them to another, or recreating a db from its datoms or transaction log. The reason these techniques work fairly easily and robustly is because all pointers (refs) are known and can be renumbered. If you store an entity id in a value, you now need more complicated schema-specific logic to re-transact the datoms correctly.
3. Cognitect has said not to rely on stable entity ids because they haven't ruled out the possibility of renumbering them in the future. Right now, however, no renumbering occurs, but I would rather not tempt fate.

nREPL debug

最近研究透過 nREPL 來除錯，發現有幾個重點

1. 透過 nREPL 可以連上 running process ，考慮安全性，通常 nREPL 只監聽 127.0.0.1

2. 如果要在 local 端開 vim 除錯，就得用 ssh 做 local port forwarding

3. 很常見的情況是，deployment machine 不可以用 ssh 直接連上 ，因為中間還又卡一個 kerberos 機。

    這樣子的話，解法還有兩種：

    (a) 我個人會採用的，是直接把 vim, vim-fireplace 灌在 deployment 機上  

         https://github.com/humorless/dotfiles/issues/8

    (b) 使用 DrawBridge

Company of One book review --- 「技能與可行性測試」

書名：「一人公司」
作者：Paul Jarvis


「成長是導致許多初創企業失敗的主要原因，甚至包含很多頂級企業也是。」

「足夠是成長的相反。」

「衡量成功的標準不應該是季度利潤的增加、不斷成長的新客戶取得、或是成功的退場策略(exit strategy)。相反的是，我們可以專注於「生存策略」(exist strategy) --- 以堅持、盈利，以及盡力為客戶提供服務為基礎。」

我最欣賞的段落，節錄如下：
「多數成功的商業人士在進行主題演講時，當他們在分享他們有多明智，選擇投入更充滿熱情的工作生活時，我注意到他們沒有談論到兩個關鍵因素。第一，他們在投入之前就對他們自己所做的事很熟練，而且這些技能非常搶手。第二個遺漏的關鍵因素是，他們在攀登到最高的舞台之前，他們能夠先跨出一小步，為自己即將跨出的一大步試水溫。(確保他們提供的東西有足夠的需求。)」

這個經典的段落談了創業的關鍵要素：技能與可行性測試。

TREVOR JIM blog 啟發

快速地掃了近十篇在 TREVOR JIM blog 上的文章，覺得也滿有啟發的。

比方說：
1.  Remote work is a moon shot. (大家用 remote work 就好，比自動駕駛車好多了)
2. 應該用停用 C/C++ ，因為這類的語言對 security 是一大傷害。應該要用 memory safe 的語言。
3. Parsing is the weakest link in software security. Parsing security 甚至比 buffer security 更重要！

Clojure made simple / What is good software?

Clojure made simple 是 Rich Hickey 用來解釋 Clojure 的 value proposition 的一部影片，仔細看過之後，我覺得影片一開始 10 分鐘的分析，非常的深刻。它提供了 Rich Hickey 對於 good software 的看法。

開頭沒有多久，Rich Hickey 就提到寫程式是一種 economic activity ，換言之，你是有雇客或是老闆的。那…雇客/老闆要什麼？他們要的東西就是兩件事：
(1) Something good
(2) Soon

那怎樣子的軟體算是 Something good 呢？定義該是什麼？Rich Hickey 定了三個條件：(Rich Hickey 有特別去強調， type 或是 tests 只是達成目標的手段之一，不能成為目標的定義。)
(a) Does what it is supposed to do
(b) Meets operational requirements
(c) Is flexible enough to accommodate change

然後，這三個 good software 的構成條件又可以拆解開來：
首先對於 (a)
It is very difficult to determine if large or elaborate or stateful programs do what they supposed to do.
而 Clojure 設計的目標之一，就是 making it easier to understand whether or not your program is going to do what it is supposed to do by making it substantially smaller and also by making it more functional.

對於 (b) ，有下列三個目標：
=> 1. Deployment/environment
=> 2. security
=> 3. performance
Clojure 可以透過 host 在 Java/Javascript 上來達成。

對於 (c) ，達成目標的重點在於 loose coupling