咻咻的筆記小站

「前言」 最近公司內的新人越來越多，而且很多不是相關工程背景的學生，在教導或是說明一些電腦科學的用詞時，很明顯的她們並不曉得是什麼，這依舊是老問題，自己平常熟悉的事物在其他人眼中卻是另一個世界的內容，因此藉這篇文章機會把整個大學中電腦科學課程中所想要傳達跟教導的事情一起描述完。 「建模：描述名詞並且量化之」 >你怎麼描述愛情是什麼？ 這算是種常見的問題，你怎麼完完整整的說明你喜歡某一個人？你可能會說他長得很帥、個性很好、會照顧人、身穿名牌衣服、家裡有錢，既然如此，下一個問題是，你要怎麼把這些資訊放到資料庫裡頭？你要怎麼把長得帥這件事情用資料描述出來？ 這個問題的本質是在談建模（Modeling），要怎麼把東西量化（quant)起來變成可以描述的內容，比較常見的情景是，購買商品的評分，或是谷歌地圖上的地點評價，你在嘗試給予這個地方一個量化的標準，當然一個人的評分會十分偏頗，但如果拉一萬個人一起幫忙的話，效果就會大不同。評分會形成某種趨勢存在，有些人會按1分，有些人會按2分，有些人會按3分等，你會得到某種回歸趨勢，為了得到這個趨勢，你需要先把事情量化並且描述下來，而描述下來的東西我們則可以進行管理。 舉例來說：你會想知道，一間雞舍有多少產能，我這個雞舍有好幾排不同品種的雞正在生產雞蛋，為此你會把雞給個編號，給一個ID 好辨識，同時會說這個雞是黑色的、體重多少、多少年齡，嘗試把對於雞的描述記錄下來。 「管理物品最有效的結構：樹狀結構」 >三年五班七號給我過來！ 有趣的地方來了，萬物總是會被歸納在一起，如果你整理自己的房間一樣，你會把衣服收在一堆，褲子收在一堆，鞋子收在一堆，這也叫做物以類聚。而為了管理你的房間，你會採用樹狀結構的方式管理房間內容。 一樣的管理管理雞社也是，相同品種或是顏色靠近的雞會被收在一起，你會直覺知道雞在那一個排列底下，用樹狀結構管理是一直以來的作法，而且也是方便管理的，回憶一下，生物中的，界門綱目科屬種，也是為了管理自然界中的各種生物，軍隊治理中也是，我們用班、排、連、營、軍團來管理，這也是某種樹狀結構。 「資工重點項目」 >虛擬世界跟真實世界是做相同的事情 「資料結構」旨是在管理空間用的，方才說過，最好管理的方式是樹狀結構，腦中直覺想到的是網狀結構，但效能不佳，鏈狀則是太慢。可以管理空間後，再來就該提升效率了，也就是「演算法」存在...

「前言」 如果我現在給你三個 fact(事實)，是否可以猜出我在說什麼？藍藍的、機器人、喜歡吃銅鑼燒，至此，你一定可以很迅速的猜出我在說的是多拉Ａ夢(doraemon)。為什麼？為什麼你可以只依靠這些資訊來猜到我在說什麼？因為你已經把那份感覺帶進去了，你已經熟悉了，所以當我描述這些 fact 的時候，你可以快速的反應出什麼是多拉Ａ夢。 「從瞎拼ＡＢＣ學講故事能力」 身在台灣，有款綜藝節目一定是經常聽到的，他叫做瞎拼 ＡＢＣ，遊戲方式是這樣的，主持人會抽出題目來考答題者，題目有很多種來源的名詞，可以是人名、家俱等，請來賓也就是答題者猜出這個名詞是什麼。再舉一個例子，這個人身穿燕尾服，善於表演，可以從帽子抓出兔子，你可以講出這個人是個魔術師，如此一來，你就可以在不直接解析那個職業的情況下，讓對方瞭解魔術師的形象與行為。從側面的方式講解中間的答案是什麼，這本身就是一項說故事能力，你可以用在專有名詞解釋上，把整個故事都闡述完之後，對方也可以理解。 「什麼是多拉Ａ夢？多拉Ａ夢是什麼？」 如果我說多啦A夢是一隻藍色的機器人，你會說不對，這樣一竿子打翻一船人，身為藍色的機器人可多著是，例如說：星際大戰中的 R2D2 就是藍色的、經典遊戲的洛克人也是藍色的。很明顯的，這樣的描述方法太過簡易，所以你會嘗試加入更多東西進行更精準的描述，用最近火紅的 AI 來說明，就是給他更多特徵值。R2D2 就是藍色的會行走胖胖的機器人，可能變成這樣，但這樣其實很耗時而且不夠直覺，而且還量大時還要面對 overfitting ，這時該怎麼做呢？將對方帶入整體環境當中。 「學習心智圖」 上述的這套方法我們稱之為心智圖，回到首圖，你可以看到兩者差別是在箭頭的方向，左邊箭頭向外比較像是我們平日在思考的方式，也就是上面那一大段的多拉Ａ夢是什麼？就跟背單字ㄧ樣，當你看到不熟悉的字眼時，會下意識地去找翻譯強行讓自己記起來，例如下圖所示: bear , 有熊的含義、也有生育的含義、更有承擔的意思，這種時候就是數學上的ㄧ對多，難以直接描述。所以上課的英文老師會怎麼跟你說？要你去看下上文，也就是 context，然後去猜那個不懂的文字是什麼涵義，也就是圖表中，箭頭向內的闡述方法，把你自己帶入那個環境中。 「心智圖應...

src: https://kafka.apache.org/intro 「Message queue system 極簡說明」 在遠端呼叫機制中，有一種 pattern 為 publisher - broker - consumer 的方式，publisher 負責產生資料/consumer 負責消化資料/broker 負責handle 雙方吞吐的狀況，而這基本上也是現在大多數的訊息系統 (Message queue system )所實作的方式。 「Kafka 極簡說明」 Kafka 在 broker 的實作上是這樣，從 publisher 來的資料放置在 topic 當中，以 log 的方式存下來，並讓 consumer 來消化它，期間 broker 不會主動去 push 資料給 consumer，而是等 consumer 自己來 pull ，如此一來，就減少許多處理 ack 的問題。 「將 kafka 作為資料庫」 既然資料都在 topic 上面，那為何還需要對其他 DB 作 Query 呢？topic 與 DB 通常主要差異是在資料存放的方式，前者為 log，後者為 transaction，前者是連續時間，後者是片段時間。舉生活例子來說明，請問你昨天在哪裡？ log的系統會回答"每個時間點"你所在的位置，transaction 只有一個，而且會是最新(最後更動)那個點。 kafka 是可以做為資料庫的，並且以 log 方式貯存資料。 「ktable, kstream, etl, connecter」 “現階段”處理 log 是用 kStream ，如果要取得某個片段時間點資料是用 KTable，如果要和其他ＤＢ作 query 則採用 connector，在這套論點當中，會有些文章提出 ETL(Extract-Transform-Load) is dead 的論述， 我覺得這算是某種程度上的 Buzzword 了，ETL 的概念是會一直跟著的，生活中也一直出現過，數學上也常做表達，他會換個方式活著不會就此停止ＸＤ 例如說：KStream 可以是 T, connecter 可以是 E/L

    Beautiful open 主要是收集各種充滿美感設計，開源，開源項目的網站。收集的開源項目大至ＣＭＳ管理系統，小到Javascropt library 都有，而且收集的量還在逐漸上昇中，如果是從事設計，網頁開發的朋友，這個網站可別錯過～     網站截圖 參考資料 http://beautifulopen.com