typelevel cats 學習筆記 2

前陣子把 Scala with Cats 這本由 underscore.io 寫的 typelevel-cats 的書看完了。

看完前兩章的第一個想法是這群傢伙怎麼時間這麼多,把整個 Scala Collection Library 內的 === |+|  map fold 等函式,重新用 type class 實作一次,時間是不是太多了。

然後再深想一下,這麼累的原因是 FP 跟用 OOP 寫成的 collection library 不相容,無法幫任意的 case class 加上額外的功能,因此要用 Type Class (過去叫 Pimp My Library 或 Enrich Class)的方式,來幫任意的 case class 加上一些通用的行為。

那這些行為有那些呢?


Eq: ===
Semigroup: |+|
Functor: map
Monad: flapmap
Foldable: foldLeft
Semigroupal: (F[A], F[B]) => F[(A, B)]

然後還有一些 FP 特有的 Writer , Reader Monad

最後還有大魔王 Monad Transformer ,至於 Monad Transformer 是幹麻的呢?你可以想像是幫你把兩層的 Monad 撥殼用的,利如

for (
a <- Future(Option(1));
b <- Future(Option(2))
) yield (a + b)

如果沒有 OptionT 的存在幫你撥殼的話,上面這段程式碼會變得很噁心。

推薦一本書 Raising a Bilingual Child ,相對於訪間口耳相傳的八卦,本書是由學者寫成,引用美國數個研究單位的研究成果,來告訴大家如何教養出雙語的兒童。

書中主要引用的研究資料是來自佛羅里達,因為佛州有眾多的西語系移民,家庭的社經環境各種都有,所以在統計上去掉一些其它因素的造成的誤差。

我讀到目前讀到比較有用的有幾點:

五歲以下的移民,在上 K5 前,若是只用母語,並不會影響未來的英語學習,反過來,若是在上 K5 前就開始學習雙語,只有 20% 的小孩未來還能學好母語,某一天就會轉成用英語為主。

母語的學習,並不會影響到英語的學習成果,既使是五歲才開始學習英文,到十一歲後,就在統計上看不出來英語學習的差易。

如果要學習好母語,除了日常對話外,還是要增加字彙的種類,雙語學校(immersion school)的教學就很有幫助。

以高中及大學 GPA 來看,雙語的學生表現跟英語的學生一樣好。但是很不幸的是, SAT 的測驗中,雙語的學生會比英語的學生低 50 分,這是未來 SAT 要努力的方向,為什麼測驗沒有鑑別能力。

typelevel cats 學習筆記

最近在學 typelevel/cats 底下這一行程式碼,想了兩天才理解為什麼要寫成這樣,Functional Programming真的是太困難了,有點回到大一學遞迴的感覺。

(Either[Throwable, A]) => Unit) 是一個 Callback function / Listener interface , (CB => Unit) 表示這個 Callback function 可以在不同的 Thread 執行。

為什麼要寫成這樣?我還在想….

谷歌、臉書大當機

接連兩天谷歌、臉書大當機,稱機會講一下我淺到不能再淺的淺見。

矽谷這邊的公司很喜歡講平台化、雲端化、大數據,把不管是企業內部還是外部,四散的資料集中管理,本來每一間私人公司都要請個 MIS,專職備份管理企業資料,等到雲端化自動化後,一個人可以管一千個企業的資料庫,可以利用經濟規模降低成本。

但是經濟規模可以一直無上限下去嗎?有種東西叫邊際效用遞減,等到規模大了後,自然有規模大的問題,像是領英堅持整間公司共用同一個hadoop cluster,光Gossip Protocol的口水就可以淹死你,不能再加機器,所以做了個”大象醫生”出來看有沒有人濫用資源。所有人要共用一個 git server ,結果當然是撐不下去,所以弄了個 git master-slave 的架構出來,偶爾 build system 拉到的資料不是最新版而已。

平台化可以達到經濟規模是正確的,但是問題的複雜度也會一直上昇,所以這些平台公司請一堆業界頂尖的人來解問題,可是業務量有可能一不小心就超過系統原始設計的上限,在新解法出來前,就只能請客戶多擔待些了。

使用 Workflow Engine 來實作 Microservices SAGA pattern

最近離開了領英,比較有空閒讀讀書,想想到底之前在實作上出了那些的問題,跟要怎麼處理這些問題。

先推薦兩本書 SOA PatternsMicroservices Patterns ,這兩本書都有提到怎麼在微服務下處理 transaction 的方式,兩本書的方法都是 SAGA pattern + CQRS + idempotent 。

但是如果你有實作過 SAGA Pattern 的話,就會知道使用 Message Driven 的方式在兩個微服務間溝通的話,整個程式碼的可讀性會非常的低,除了原先溝通並實做細節的兩位工程師外,大概不會有第三個人能夠理解整個交易是怎麼完成的。


註:本文圖片取自 https://microservices.io/patterns/data/saga.html

在實作細節上,使用MDA的架構,微服務要提供sync & async API使用,是額外的成本,在領英,所有的微服務預設都是只有提供 sync API 的,你要請對方多開一個 async 的界面,是要求爺爺告奶奶的。

因此,在技術上管理上比較可行的,就是把流程的管理都拉到自己管理的微服務當中,在裡面使用 orchestrator 來管理對外乎叫的狀態記錄處理跟錯誤重送。

當然,這又免不了要寫一大堆 glue code 把所有的東西黏在一起,然後在資料褲裡面又要開一堆的 Table 來記錄運行的狀況,這非常的花功夫,在實作上很花時間又不好進行修改沒有彈性。

今天早上看到 InfoQ 的一則新聞 Experiences Moving from Microservices to Workflows at Jet.com 突然腦洞大開,是啊 orchestrator saga 可以使用如 Apache Camel 等的 workflow engine 來實作,微服務還是只需要提供 sync API ,交由 workflow engine 來做狀態追蹤跟錯務重送,然後中間的狀態,可以透過 Camel 存在 ActiveMQ 之中,然後整個流程的定義,可以透過 Camel Java/Scala/… DSL 高階語言來編寫,整個可讀性大增。

  from("file:src/data?noop=true")
      .choice()
          .when(xpath("/person/city = 'London'"))
              .to("file:target/messages/uk")
          .otherwise()
              .to("file:target/messages/others");

原來我在 2014 年左右就找到答案並且在飛向的程式碼中實作過,只是這幾年我自己被領英的專案壓力追著跑(每一季都同時跑五個以上專案),忙到忘掉了。

大公司裡面的技術債是怎麼來的?

大公司裡面的技術債是怎麼來的?

就像一個房間一樣,有一個角落積了一些灰塵需要打掃,主動跟主管說要打掃,主管會問你,打掃這個跟其他的事比起來重要嗎?我們先來測量一下這角落有多髒,打掃完有什麼效果,然後再來跟其他的工作事項比比看優先權該放在多高。

當然結論是不重要不需要掃,然後下次換另外一個角落髒了,再來測量一次再來排一次優先權,然後放棄打掃。

以上過程重複數次之後,主管大叫,這房間怎麼這麼髒,我們來制定打掃計劃,把過去的角落清潔計劃全部翻出來更新一次,再來全部重排一次優先權,做個環境整潔總檢討計劃。

然後大老闆跑出來說,你這房間在的髒亂,來跟整棟大樓的整潔比比看髒亂的程度,再來排個優先權,然後我們晚點再開會討論看看要不要納入明年的工作項目。

為什麼我不用 Google 搜尋

還在用 Google 嗎,該轉用 Bing/duckduckgo 了

希拉蕊的郵電門是美國 2016 年的選舉大新聞,理當也是熱門關鍵字,至少跟據 Google 自己的統計, email 是比 emoji 熱度高出十倍,但是 Google 的推薦選項,卻捨去熱門的關鍵字而選了冷門的 emoji

你跟我說 Google 沒有政治偏好,我說你腦袋壞掉

 

NOTE:

平衡報導一下,連結是谷歌的回應說法,不過我是不清楚 email 算是什麼骯髒的字眼就是了

https://www.fengli.com/news/23211879.html

Grooveshark shuts down after years of legal troubles

舊文重貼,原文寫於 2015/04
事後的發展是,Grooveshark的 co-founder 於 2015/07/19 自殺,只能說 startup 歹路難行,不要挑錯了產業,又投入了十年的青春導致無法自拔退出。

我在同類型的公司工作過幾年,老實講,Grooveshark 走到這一步,不意外。比較意外的是他能撐這麼久,三年前他們 CEO 就情緒崩潰過一次 ,沒想到還能再多撐個三年。

Grooveshark 成立於 2006 年,當時的市場環境已經跟 Napster 成立的 1999 大不相同,自從 DMCA 數位千喜年法案通過之後,音樂服務已經有不少都走向付售權費合法化的路上,只有 Grooveshark 一家走不同的路。

Grooveshark 是群大學生一起做的,所以大家自己省一省,不用跟 VC 要錢,就可以開業。

也許是一開始走的太順,所以他們就想要這麼一直走下去,不去跟音樂公司談授權問題。

當然這樣造就的結果是,每次他們一要談下一筆增資案,律師信馬上就來,增資的錢跟本就是花在律師費上面。

我常常在想,Grooveshark能活這麼久,說不定是五大音樂公司故意的,反正把 GS 搞倒了也沒用,還會有下一家跳出來做,還不如讓 GS 吃不飽餓不死撐在那邊,擋住潛在中想做非法音樂這塊的人,同時也警告這些人,你做非法音樂是沒錢賺的。

最終搞倒 GS 的,我想除了是創業團隊已經累了之外,另外就是美國工程師行情太好,小本經營的 GS 請不起人了

極權主義與環保主張

做個筆記一下,暫時還沒有動力把想法全寫下來。

最近讀到許多東西,與在加州這個極左的地方生活經驗結合起來,才理解到環保主張跟極權主義是分不開的,甚至是反過來說「環保主張」只是「推行極權主義的工具」,為了推銷極權主義才打著環保的旗子,跟環不環保跟本無關。

以最近的「禁用塑膠吸管」來說,因為禁用塑膠吸管後,造成珍珠奶茶的飲用問題,因為替代的紙吸管強度不夠,喝幾口就破了,所以又開發了不鏽鋼吸管來替代,當然不鏽鋼吸管的問題又更多了。

其實,如果「環保主張」、「塑膠吸管對環境有害」真的是那麼被大眾所接受的話,那麼就兩種吸管都提供就好啦,不用禁用塑膠吸管,需要用到塑膠吸管的地方,大眾自然會選用塑膠吸管,當可以使用較環保的方案時,大眾自然會選用環保的方案。

唯一的問題,就是需要時間去推廣「塑膠吸管不環保,而且有替代方案」的觀念,這樣子把環保觀念深化到大眾人身上,雖然時間會拉的較長,但是影響會更深遠,等未來有其他議題時,民眾會更容易接受。

然而環保主義者,確選擇了不相信人性,用大政府的力量去全面禁止使用塑膠吸管,不管某些場合上無法使用替代方案,選擇走了極權的方向,讓我對「環保主張只是推行極權主義的工具」這件事又多了一點認同。