popcorny 積分 1 編輯於

有點好奇,KKBOX不用S3而自己管理File的原因? 成本評估便宜很多嗎,還是因為歷史因素?

popcorny 積分 1

說實話這個題目我不太知道要怎麼寫 XD,ingram要不要來貢獻一個章節.. (跪求..)

popcorny 積分 3

可以只貼Link1 嗎? XD 說真的這個挺硬了,算是JVM的實作要求。

popcorny 積分 3

上次講兩場結果準備到累癱,我決定不再做此傻事

popcorny 積分 4

小弟剛剛寫完的一本gitbook,cover了大部分的java寫多執行緒的所需要的知識。歡迎大家打臉.. ><

popcorny 積分 2 編輯於

天啊!! 這東西好複雜,看了好久才知道他在說什麼。

一般來說store.dispatch應該只吃Action1 type,但是透過middleware可以包裝此dispatch變成可以吃Thunk這個型態,此型態的定義在 這裡2 ,簡單講就是一個

function(dispatch, getState)

這種型態的function。透過closure的方式,可以讓在async的地方去call這兩個redux會用到的function,來達到ajax complete的時候,去sync的呼叫dispatch來通知complete。

這個可能對於用redux的人可能會知其然但不知所以然吧,如果沒有搞懂thunk的機制,可能覺得莫名其妙吧。我同意你說的,這些abstraction不太必要,只是讓一且覺得很神奇而已,對於新手入門門檻太高了。

popcorny 積分 2 編輯於

side effect就是改變外面的狀態就是side effect,例如counter++就是side effect。所以以下的increase function就是有side-effect

var myObject = {
    counter: 0,
    increase: function() {
        this.counter++;
    }
}

因為他改變了counter的值了。而no side-effect的版本是

function addOne(counter)  {
    return counter + 1;
}
而redux做的事情是
state = reducer(state);

所以這個assignment是做redux裡面,而非reducer。

事實上在functional language中,assignment is evil XD。所以他們才那麼不同意Imperative programming style。

popcorny 積分 0 編輯於

action感覺比較像是input的包裝,應該沒有邏輯層面。真正邏輯是做在reducer。

所謂的no side-effect,也可以說不會改變外部的狀態。所以在redux中,mutation是交給redux內部去做。而redux會把目前狀態跟action交給reducer,最後再redux內部去改變store的狀態。所以side-effect(mutation)應該說發生在redux內部。

popcorny 積分 2 編輯於

一個page出來的時候應該有initial state,不管是page init state還是server side render的init state。

而每個event都可以改變狀態。例如click event, input event, 甚至ajax complete的event,都可以當做一個讓狀態改變的action。但是reducer只專注於input跟中間的參數,跟應該有的output。

以ajax read more的例子來說。先是ajax request到server,complete的時候增加一個append的action去reduce舊狀態(只有第一頁)到新狀態(增加ajax load的新文章),再呼叫react去render。

所以還是可以保持render跟reduce都是pure的。

popcorny 積分 4 編輯於

好強!

看起來不只是dns route,畢竟你的link中的示意圖已經是給一個IP了,而不是domain name,感覺是同一個static global IP但是在ip routing動手腳 ( Global Fowarding Rule1 ) 。跟用DNS去做GEO去吐不同的IP不太一樣耶。

popcorny 積分 2

小弟小的小小library。會寫這個的理由是因為Java Stream因為是pull mode的,所以aggregation只能做一次,改用Push Mode後,我可以同時寫檔,對兩三種目的做Aggregation。這全部都可以在one pass就解決。

應該是有其他的reactive library都是push/pull都有提供,但是因為想要reuse Collector,所以就刻出這個library出來用 :P

popcorny 積分 0 編輯於

其實想想也不用那麼複雜

var barList = new ArrayList<String>();
final var fooList = new ArrayList<String>();

這樣跟

ArrayList<String> barList = new ArrayList<>();
final ArrayList<String> fooList = new ArrayList<>();

一致不也挺好?

var就特別拿來用在type inference, final就來決定是不是可被assign

popcorny 積分 0

最大的問題是離開Windows後,沒有方便的SQL Server管理工具

popcorny 積分 0

拜託連 List, Map Literal都加進去.. 寫json-like的literal好痛苦啊..

popcorny 積分 2

Materialized View似乎沒有那麼美好耶,會有performance impact

New in Cassandra 3.0: Materialized Views1

Materialized views do not have the same write performance characteristics that normal table writes have. The materialized view requires an additional read-before-write, as well as data consistency checks on each replica before creating the view updates. These additions overhead, and may change the latency of writes.

popcorny 積分 3 編輯於

我對文章中另一篇 Lambda parameter names with reflection1 更有興趣,可以用來簡單定義Literal Map,可惜這要搭配特殊的compile參數。話說Java啥時才會支援Language Level Json Literal,以及Map, List, multiline literal的Support

popcorny 積分 3

完全覺得這個對一般開發者不會有影響吧,很少API會設計出

public static String toString(MyObject obj);
public String toString();

兩種寫法,即便真的遇到,要workaround也不是難事

popcorny 積分 3

小弟寫的小工具。這東西要搭配jq, q, json2csv, csvkit才可以發揮最大功效。對於cassandra adhoc query苦手的可以使用看看。

popcorny 積分 11 編輯於

其實MongoDB剛出來的時候有幾點有吸引到我

  1. Schemaless: 不得不說有些應用用這個很好用。例如你的資料來源本身就是json,並且可能偶而會在來源端修改Schema。例如,Facebook Feed。在之後分析的時候,可以透過特殊的Query語法來達到in json document的query。而且可以針對Document裡面的一個path去做index,甚至可以對array做index,這點那時候的確讓我驚艷。
  2. Sharding: RDBMS這個真的不容易做的好,因為需要Join。而且要怎麼設定Partition key本身就不易。所以NoSQL在這邊比較容易做得好。

但是我覺得最令我詬病的是

  1. Query很難用。永遠背不起來的query語法。而且用json格式真的很難寫。Aggregation pipeline跟sql group by比起來真的難寫爆多的。更何況無法做類似subquery跟join。
  2. 部署困難。如果資料量大到需要Sharding,部署成本難超多。若是要再加上replica set。那更是超難運作。我相信沒有幾個人會想這樣部署。

所以MongoDB對我來想,目前最好的地位是分析資料庫。也就是你可以把一堆的JSON資料塞進去,然後在裡面去做你想要的AdHoc Query。所以對於分析統計semi-structured的資料我想是目前最適合他的角色。但是PostgreSQL9.4出了以後jsonb,又有json的query好處,又可以做傳統的table join,那真的是又比MongoDB更實用,重點是有SQL。

如果往上看收集raw log的需求,MongoDB還是Row-based DB。這種型態的DB就是CRUD都是對同樣一個地方去做存取。就會遇到Data Fragmentation的問題,所以資料量一大,一定會遇到越來越慢。雖然可以透過定時去rebuild database。但是跟cassandra/hbase這種bigtable-like的還是不能比。所以真的有更大資料量的需求,我建議直上cassandra/hbase。或是更極端的用HDFS或是雲端Storage(首推AWS S3, Azure BlobStorage,因為這些Hadoop有內建FileSystem)。

Anyway,MongoDB 3.0雖然改善了很多Storage的效能問題。但是本質上的問題沒有解決,那就是沒有SQL,沒有Reliational的功能,再來是Row-based的本質跟RDBMS差距不大。但在RDBMS越做越強,主流DB都開始支援JSON的情況下,那他的特色就不是特色了。反而是他沒有的反而是他的負面特色。

popcorny 積分 5

對於所有需要DB的系統第一個建言: 所有系統都需要一個RDBMS

等到你某些需求在原本的RDBMS做不到的時候,再來想說用其他類型的Storage來解決。