現在的人因為智慧型手機汰換很快，手邊越來越多附贈的耳機跟充電線，這些耳機多半具備音量線控、來電接聽、跟麥克風的功能，跟傳統立體聲耳機不太一樣，雖然說很早就遇過插進一般電腦耳機孔左右聲道會有些問題，但也一直沒細究。查了一下才發現這裡頭還有不一樣的標準，雖然都是 3.5mm 接頭，卻又互不相容。
TRS 接頭
TRS 的全名是 tip-ring-sleeve [1]，也就是傳統常見的立體聲耳機接頭，金屬接點分成三段，分別是尖端 (tip)、基部柱狀 (sleeve)、以及中段 (ring)。Tip 跟 ring 這兩個名稱源自古早手動接線的電話系統 [2]，當時並沒有左右聲道，但後來用在耳機接頭時，分別作為左右聲道訊號使用；而 sleeve 則用於接地。至於更古早的單音耳機，因為只需要兩段金屬接點，因此使用的接頭是 TS 接頭。
目前常見智慧型手機附贈的耳機，接點分成四段，稱為 TRRS 接頭。就訊號來說，尖端兩個與 TRS 相同，靠基部這邊的 RS 則又分成 CTIA (又稱為 American Headset Jack; AHJ) [3] 跟 OMTP [4] 兩種標準，前者的 RS 分別為接地與麥克風，後者則剛好顛倒過來。因為聲音輸出時，訊號必須對應接地才能成功推動發聲元件，因此 CTIA 與 OMTP 間混用會因為找不到接地線，而無法正確發聲。
這兩個標準大致上老舊跟山寨的產品多使用 OMTP，像是 SONY ERICSSON 跟 Coolpad/OPPO/ZTE；而 CITA 則廣泛用在現在市面上多數手機，包括 Apple/ASUS/LG/Meizu/SONY/Xiaomi；至於 HTC/MOTO/NOKIA/SAMSUNG 則要看機型而定。
如果需要在電腦上使用手機附贈的耳機，可以購買轉接線完成。
See also:
[1] Phone Connector (Audio)
[2] Tip and Ring
[3] Cellular Telephone Industries Association (CITA)
[4] Open Mobile Terminal Platform (OMTP)
2017-04-20
2017-04-11
Customer Relationship Management (CRM)
一般來說 CRM 系統會包括 3 個主要功能模組：行銷 (marketing)、業務 (sales)、客服 (customer support)；可以直接對應到公司面對客戶時的主要三個階段。其中 CRM 的業務模組通常只提供報價 (quote) 功能，至於成交後的訂單 (order)、合約 (contract)、倉儲 (inventory)、發票 (invoice) 等管理功能，多半會回到 ERP 的模組中，而不在涵蓋範圍中。
這 3 個模組中，又以業務功能為 CRM 的最核心，CRM 的行銷功能往往專注於 target list、bugget planning，輔以更專業的系統負責 custom portal、multi- campaign channel management (newlettter, email, phone call, social networks)、閱讀追蹤、SEO 等功能；而客服系統也往往會拆分出 helpdesk 系統，提供更多案件 (case) 追蹤功能。
上表是 CRM 中常見名詞跟 3 個功能模組的關聯對應，其中 campaigns, opportunities, cases 是分屬 3 個功能模組的活動紀錄，其他則為客戶資料。Accounts 跟 contacts 是相對中性的；targets 是蒐集到客戶資料後的第一階段，經 marketing/sales 資料審核後轉成 leads，視連繫狀況再轉為 prospects，等到報價確定成交成為訂單後，再轉為 customers，由客服模組負責。[1][2]
客戶數在各銷售階段的轉換過程中會逐漸縮小，呈漏斗形，故稱為 sales funnel。一般來說 sales funnel 以 leads 為起點 (更之前的 anonymous 資料未存於系統中)，後續才是 prospects 跟 customers；在 Salesforce 跟 SuiteCRM 的設計中，lead 可轉換為 account，prospect 跟 customer 都被視為是一種 account type [3][4]。
Salesforce 預設的 account type 有 Analyst, Press, Competitor, Prospect, Customer, Reseller, Integrator, Investor, Partner, and Other [4].
部分專營 B2B CRM 的廠商會在 CRM 前再多一個 Marketing Automation Systems (MAS)，負責蒐集潛在客戶資料，經過評分過濾成為 lead [5]。
see also:
[1] Customer Relationship Management: Aspects, Strategy and Use of Technology
[2] What is the Difference between Campaign, Opportunity, and Case?
[3] SuiteCRM User Guide
[4] What are the default picklist values in Salesforce?
[5] B2B Marketing Stack Basics: CRM, MAS, and The B2B Lead Lifecycle
[6] The True State of Open Source CRM
[7] 行銷與業務有何不同？這45件事讓你搞清楚
這 3 個模組中，又以業務功能為 CRM 的最核心，CRM 的行銷功能往往專注於 target list、bugget planning，輔以更專業的系統負責 custom portal、multi- campaign channel management (newlettter, email, phone call, social networks)、閱讀追蹤、SEO 等功能；而客服系統也往往會拆分出 helpdesk 系統，提供更多案件 (case) 追蹤功能。
| Marketing | Sales | Customer Support | |
|---|---|---|---|
| Accounts | |||
| Contacts | |||
| Targets | |||
| Campaigns | |||
| Leads | |||
| Opportunities | |||
| Quotes | |||
| Cases |
上表是 CRM 中常見名詞跟 3 個功能模組的關聯對應，其中 campaigns, opportunities, cases 是分屬 3 個功能模組的活動紀錄，其他則為客戶資料。Accounts 跟 contacts 是相對中性的；targets 是蒐集到客戶資料後的第一階段，經 marketing/sales 資料審核後轉成 leads，視連繫狀況再轉為 prospects，等到報價確定成交成為訂單後，再轉為 customers，由客服模組負責。[1][2]
客戶數在各銷售階段的轉換過程中會逐漸縮小，呈漏斗形，故稱為 sales funnel。一般來說 sales funnel 以 leads 為起點 (更之前的 anonymous 資料未存於系統中)，後續才是 prospects 跟 customers；在 Salesforce 跟 SuiteCRM 的設計中，lead 可轉換為 account，prospect 跟 customer 都被視為是一種 account type [3][4]。
Salesforce 預設的 account type 有 Analyst, Press, Competitor, Prospect, Customer, Reseller, Integrator, Investor, Partner, and Other [4].
部分專營 B2B CRM 的廠商會在 CRM 前再多一個 Marketing Automation Systems (MAS)，負責蒐集潛在客戶資料，經過評分過濾成為 lead [5]。
see also:
[1] Customer Relationship Management: Aspects, Strategy and Use of Technology
[2] What is the Difference between Campaign, Opportunity, and Case?
[3] SuiteCRM User Guide
[4] What are the default picklist values in Salesforce?
[5] B2B Marketing Stack Basics: CRM, MAS, and The B2B Lead Lifecycle
[6] The True State of Open Source CRM
[7] 行銷與業務有何不同？這45件事讓你搞清楚
2017-04-07
Contract, Interface, and API Document
有一些程式經驗的人大多聽過 design by contract 這個詞，意思大致是按照 contract 實作；部份習慣於 object-oriented programming 的人很自然的就把 contract 誤以為等價於 interface，中了 interface-as-contract myth [1]。
Interface 跟 contract 最大的差別在於：interface 是純粹的介面，不涉及實作後的行為，也就是說按照 interface 實作的 client code，只確保能呼叫得到，不能確保呼叫後的行為是否符合預期；但是 contract 是包括 precondition 與 postcondition，比 interface 更進一步限制了實作行為。
但這也並不代表 contract 就能完全涵蓋 interface，主要因為 contract 通常並不涉及實作的語言；例如 interface 可以指定 method arguments 的順序跟型別，但這些通常不會涵蓋在 contract 裡頭。也因此當我們談 test code generation 時，interface 扮演主要角色，而 contract 則在 test case (input/output) generation 扮演主要角色。
最後是 API document ...
API document 主要目的是讓編寫 client code 的人能正確地產生參數呼叫 API，目的在於彌補 interface 的不足，一般會先解釋一下這個 API 的用途，加註各個參數 domain 上的意義而不單只是型別，另外也會描述拋出例外的情況等；因此就意義上偏向 contract 更多一點，但又比 contract 多依賴了特定 programming language 或 protocol 等；甚至可以包括所有 contract 的資訊形成 API contract。
近年來因為 microservice architecture 的大量興起，讓 Web API 又受到重視，許多 interface description language (IDL), API description language, API documentation language 也相繼產生，釐清上面三個的角色跟功能，可以幫助我們回頭檢視這些 description languages 應該有的功能跟後續自動化的可能。
see also:
[1] API Design Myth: Interface as Contract
[2] An API Definition As The Truth In The API Contract
[3] Design by Contract
Interface 跟 contract 最大的差別在於：interface 是純粹的介面，不涉及實作後的行為，也就是說按照 interface 實作的 client code，只確保能呼叫得到，不能確保呼叫後的行為是否符合預期；但是 contract 是包括 precondition 與 postcondition，比 interface 更進一步限制了實作行為。
但這也並不代表 contract 就能完全涵蓋 interface，主要因為 contract 通常並不涉及實作的語言；例如 interface 可以指定 method arguments 的順序跟型別，但這些通常不會涵蓋在 contract 裡頭。也因此當我們談 test code generation 時，interface 扮演主要角色，而 contract 則在 test case (input/output) generation 扮演主要角色。
最後是 API document ...
API document 主要目的是讓編寫 client code 的人能正確地產生參數呼叫 API，目的在於彌補 interface 的不足，一般會先解釋一下這個 API 的用途，加註各個參數 domain 上的意義而不單只是型別，另外也會描述拋出例外的情況等；因此就意義上偏向 contract 更多一點，但又比 contract 多依賴了特定 programming language 或 protocol 等；甚至可以包括所有 contract 的資訊形成 API contract。
近年來因為 microservice architecture 的大量興起，讓 Web API 又受到重視，許多 interface description language (IDL), API description language, API documentation language 也相繼產生，釐清上面三個的角色跟功能，可以幫助我們回頭檢視這些 description languages 應該有的功能跟後續自動化的可能。
see also:
[1] API Design Myth: Interface as Contract
[2] An API Definition As The Truth In The API Contract
[3] Design by Contract
訂閱：
文章 (Atom)